Three Comments from a Conversation on a Mailing List
The conversation began regarding the productivity advantages offered by Smalltalk. While not necessarily entirely accurate, given that productivity in software development is notoriously difficult to measure, the most reliable measures we have place Smalltalk at about 32x the productivity of assembler, which is used as the basis for comparison. JavaScript is virtually identical to assembler, on average about 1.2x as productive; C shows up at about 3x as productive; Java appears at nearly 11x.
I’m noting this simply in terms of understanding what the initial argument, which these three quotes both continue and diverge from, was based on; while specifically not predetermining what its relevance might be.
Comment #1:
First: I’d say the question itself is not a question but an excuse. I am not arguing there are enough Smalltalkers or cheap ones. But I think the question is just a way of saying “we don’t want to do it for reasons that we ourselves cannot really express”. If you are a good developer, learning Smalltalk is easy. If you are a good developer you’ve heard the sentence “we’ve taken the good parts from x, y, z and Smalltalk” at least twice a year. So, you most likely would want to learn it anyway.
A shortage of developers doesn’t exist. What exists is an unwillingness of companies to get people trained in a technology. If Smalltalk was cool and great in their opinion, they wouldn’t care. It’s that simple. As a consultant, I’ve heard that argument so often. Not ferom Startups, but from insurance companies, Banks or Car manufacturers who spend millions on useless, endless meetings and stuff instead of just hiring somebody to teach a couple of developers Smalltalk. It’s just a lie: the shortage of Smalltalk developers is not a problem.
And, to be honest: what is it we are better in by using Smalltalk?
Can we build cool looking web apps in extremely short time? No.
Can we build mobile Apps with little effort? No.
Does our Smalltalk ship lots of great libraries for all kinds of things that are not available in similar quality in any other language?
Are we lying when we say we are so extremely over-productive as compared to other languages?
I know, all that live debugging stuff and such is great and it is much faster to find & fix a bug in Smalltalk than in any other environment I’ve used so far. But that is only true for business code. When I need to connect to things or want to build a modern GUI or a web application with a great look and feel, I am nowhere near productive, because I simply have to build my own stuff or learn how to use other external resources. If I want to build something for a mobile device, I will only hear that somebody somewhere has done it before. No docs, no proof, no ready-made tool for me.
Shortage of developers is not really the problem. If Smalltalk was as cool as we like to make ourselves believe, this problem would be non-existent. If somebody took out their iPad and told an audience: “We did this in Smalltalk in 40% of the time it would have taken in Swift”, and if that something was a must-have for people, things would be much easier. But nobody has.
I am absolutely over-exaggerating, because I make my living with an SaaS product written in Smalltalk (not Pharo). I have lots of fun with Smalltalk and like you am convinced that many parts of what we’ve done so far would’ve taken much longer or even be impossible in other languages. But the advantage was eaten by our extremely steep learning curve for web technologies and for building something that works almost as well as tools like Angular or jQuery Mobile.
Smalltalk is cool, and the day somebody shows me something like Google’s flutter in Smalltalk, I am ready to bet a lot on a bright future for Smalltalk. But until then, I’d say these arguments about productivity are just us trying to make ourselves believe we’re still the top of the food chain. We’ve done that for almost thirty years now and still aren’t ready to stop it. But we’ve been lying to ourselves and still do so.
I don’t think there is a point in discussing about the usefulness of a language using an argument like the number or ready-made developers. That is just an argument they know you can’t win. The real question is and should be: what is the benefit of using Smalltalk?
_____________________________________________________________________________________
Comment #2:
There are other, related questions, that are more relevant to me:
Do I give a f*** about cool looking web apps? No, I don’t use web apps if in any way I can avoid it.
Do I give a f*** about mobile apps? No, the screen’s too small to read anything longer than a twit, implying anyone with nothing worthwhile to say.
Do I give a f*** about the number of libraries in other languages? No, because most of them are crap in every language I’ve had to work in. The base languages are never properly finished or consistent, so they must keep changing radically, and libraries and frameworks therefore must also change, and as a result never get significantly better. The few that are worthwhile I can use from Smalltalk without a problem (viz: Blender, ACT-R and Synapse, since every other library/framework I’ve used outside Smalltalk has cost as much time, at minimum, as it’s saved).
Do I give a f*** about implementing a complex piece of machine learning software in 22 hours, compared to 3 months for the Java version? Well yes, I do, because that was 3 months of my life down the toilet for something too slow to be useful in Java in any case.
Any argument depends on your priorities. I’ve written tons of web apps, because I needed to get paid. I’ve written better shitty mobile apps than the average shitty mobile apps. However, I’m not going to do any of that any longer in crap that never improves, because after 26 years the irritability it produces is more than it’s worth.
A few weeks ago, a recruiter that specializes in Smalltalk called me about a job, although they were aware I live 1500 miles away from the city I lived in when I had worked through them, to see if I’d be willing to move back there for a job. That sounds like another ‘there aren’t enough Smalltalk developers” trope, but it isn’t. The job didn’t involve writing code in Smalltalk. It involved writing code in Java.
The person hiring apparently wouldn’t look at any candidate who didn’t write code in Smalltalk. The reason given was that “people who grew up with Java don’t know how to write object code”. I don’t necessarily agree with that. I’ve known a (few) good Java developers. I would say, though, that I’ve known far more incompetent ones than good ones, and I can’t think of any incompetent Smalltalk developers off the top of my head.
I’ve ever heard a developer in Smalltalk, or Haskell, or LISP, or even C, and rarely in Java, complain about how hard maintaining state is or coming up with various hacks to avoid it, which seems to be the main point of every JavaScript based ‘technology’. An application is by definition a state-machine. In itself that implies plenty about average JS developers.
If you’re a good developer you can write good code in (nearly) anything, I’m by no means disputing that. My question is why would you want to write in anything that quite often doesn’t work? A better question than “why aren’t there enough Smalltalk developers” is why aren’t there more good developers in any language? Particularly if you grant the notion that given how much originated in Smalltalk or its ecosystem, “any good developer would want to learn it”.
Those things, by the way, include unit testing, test driven development, the majority of Agile methodology, design patterns, model driven development, refactoring, JIT compilation, live environments and live object debugging., all the way to the graphical user interface itself.
Amazing how a single niche environment (and I’m not claiming it isn’t) managed to originate most of the “best practices” that are applied in nearly every environment? It’s not difficult, though, to understand that environments that cause more frustration than assist in writing reliable code are not conducive to the type of thinking that does originate better methodologies.
Every project I have been able to do in Smalltalk, though, has had one thing in common, the “shit has to work”. Companies do use it, in fact I could name 4 large enterprises I’ve worked for who’ve written their own dialects, and they all use it only when “shit has to work”. They know it’s more productive, they also know using it for more things would increase the availability of Smalltalk developers and the visibility and perceived relevance / popularity of the environment.
Why do they not do it? One reason, though it takes a while to recognize it, because management doesn’t admit even to themselves why they do it, or not very often. Being inefficient, if it doesn’t ‘really’ matter, is an advantage to large enterprises because they have resources smaller competitors don’t.
Why don’t their competitors do it? Because they can’t see past an hourly rate, what’s fashionable, or just new, or because their customers can’t. Put more generally, average stupidity that isn’t corrected by the market. Fashion affects smaller companies more than larger ones, because they can’t afford a few customers walking away because they wanted an app in Electron, even if they can’t give any relevant reason for wanting it, and even the samples on the Electron site don’t work.
Enterprises can, and do use Smalltalk when it matters. When it doesn’t, it’s to their advantage to promote things that are inefficient, buggy and unreliable.
Cost is relevant, but not in the simple way people look at things. A crucial but rarely mentioned perspective on its relevance is that while Java based software runs TV set top boxes, Smalltalk based software runs things like medical equipment, automated defense systems, tanks, etc. Cost becomes largely irrelevant when ‘shit has to work’.
Productivity is primarily relevant to less talented developers, in an inversely sense, since unproductive environments and attitudes have a leveling tendency in general, and more specifically make accomplishing what the less talented are capable of in any environment sufficiently laborious for them to have a role. Capability in Smalltalk, as implied by the person hiring for the Java role I mentioned, is a decent means of judging whether someone is a so-so developer or a good one.
The productivity argument is realistically only relevant in the context of an already higher hourly cost. Given that it is relevant at that point, companies that know Smalltalk is more productive would use it outside things that must be 100%, if their own productivity were relevant to the same degree that competitors’ productivity is inversely relevant.
All these ways of looking at it are contingent on a specific circumstance. Yes, if the number of libraries is relevant to you, Smalltalk is less attractive, but that’s a contingent phenomenon based on the relative popularity of Java and JavaScript, as a result it can’t be used as explanatory for that popularity. All the ways of looking at it that are determinate are determinate via contingencies of that kind, which for the most part are precisely the other perspectives, including productivity, cost, availability of developers, and most fundamentally, popularity. But none of them, popularity included, is anything but a result of the others.
If availability of developers is contingent on popularity (and further, popularity contingent on industry attitudes, which are themselves based largely on a ‘gut feeling’-type assessment of popularity), to use an example already mentioned in Joachim’s post, then the simultaneous posit of library availability as a cause, is if anything even more contingent on popularity, so positing it as a cause rather than a result or even merely a correlate of popularity is incoherent.
We can go one step further, and demonstrate that even when large enterprises make something that works reliably available, they fail to promote and support it, which destroys the market for reliable tooling, simultaneously owning that market while not promoting it (something IBM is particularly good at). But IBM can’t operate that way without the tacit agreement of the industry, and if IBM can’t, neither can any other company.
To understand it in a more general way, software development must be looked at in the context where it occurs, and how it’s determined to a large degree by that context, with a specific difference. That difference is itself implicit in the context, i.e. capitalism, but only purely effective in software development.
It’s a result of virtualization as an implicit goal of capitalism, and the disruptions implicit in the virtual but so far only realized completely in software. In terms of that understanding, the analysis of virtualization and disruption as inherent to capitalism is better accomplished in Kapital than in any more recent work.
Or one can simply decide, as I’ve done recently, that working in ways and with tools that prevent doing good work in a reasonable timeframe isn’t worthwhile to you, no matter how popular those ways and tools might be, or what the posited reasons are, since at the end popularity is only insofar as it already is. What those tools and methods are depends to a degree on your priorities, but if developers are engineers those priorities can’t be completely arbitrary. Engineers are defined by their ability to make things work.
Software as virtual is inherently disruptive, and the software industry disrupts itself too often and too easily to build on anything. A further disruption caused by developers, as engineers, refusing to work with crap that doesn’t, i.e. insisting on being engineers, while in itself merely an aggravation of the disruptive tendencies, might have an inverse result.
Using a stable core of technologies as the basis for a more volatile set of products, in the way nearly every other industry does, is the best means we know of to build things both flexibly and reasonably efficiently. The computer hardware industry is the extreme example of this, while the software industry is the extreme contradiction.
_____________________________________________________________________________________
Comment #3:
By being able to prototype quickly I have improved my research, both the experience of it and the results, which is a way to improve research (self) funding.
Also, activists, journalists, researchers and others interested in data storytelling and visualization, care little about popularity of the language or being able to make apps (mobile or web). What they care is about being able to tell their story, and Pharo, agile visualization and moldable tools have a lot to offer on this front. They’re easy to learn and quick to adapt to fit specific needs of the problems behind those stories, as we have done with Grafoscopio.
It’s nice to be part of a common “trend”, (data science, reproducible research, data storytelling and data visualization), since we can learn by others’ successes and failures, while not being entrenched in a means that doesn’t provide tools that work for you and the freedom they enable, in turn due to the ideas they embody, their affordability, and the added value they create for you and your community.
Being in Latin America allows us to bootstrap ourselves into an alternate future by using alternative infrastructures and tools, without worrying about deep investments, both money and expertise, in popular but inefficient and bloated technologies, since we don’t have any such investments.
We can learn from the experience of the “Global North”, without recreating the problems that result from following its path. Instead taking a critical approach to the causes of those problems, such as overly complex, non-dynamic, bloated technologies and their inverse counterparts, overly simplistic, indeterminate and feeble technologies.
On the community front, it is important to break the circular logic of popularity: i.e. Smalltalk is unpopular, so we don’t get developers, so we don’t have libraries, which makes Smalltalk unpopular.
We can do so, since we are a nascent community of data storytellers and activists, learning how to use technology to help tell our stories and augment our voices, and needing to be able to modify that technology quickly to tell specific stories in the most potent and fluid ways.
What we’ve accomplished so far has been without direct support from industry or government, and with very little from academia. Despite of the fragility of our space, it has been done in a consistent way for almost two years (I started to learn Pharo, in a sparse way, 3 years ago). Only by using a set of base technologies we can afford, that were developed in a reliable enough way to count on, could we have accomplished anything at all.
There are ways to break the circular logic and bootstrap communities around the advantages of Pharo where it can be aligned to both specific needs and current trends, yet avoids pitfalls that may be affordable to established communities, but that new, small communities cannot in any way afford.
Using a niche “that really works” and bootstrapping communities into it via quickly written, but reliable and customizable tools, is a way to demonstrate the argument for Pharo via a concrete example, which is a difficult thing to counter.
Prior to coming across Pharo, we tried several of the technologies most often posited as alternates for this type of project, including Ruby, Python, Perl, and JavaScript. Nothing useful was accomplished, nor could be given the available resources in a reasonable time.
If it couldn’t be done within such a community using technologies at least some of which are the closest thing outside Pharo available for such work, the argument for Pharo in such communities and contexts becomes nearly impossible to counter.
