
Smalltalk’s Productivity - mpweiher
https://medium.com/smalltalk-talk/smalltalk-s-proven-productivity-fe7cbd99c061
======
robertkrahn01
The notion of the function point metric is explained in [1]: "the amount of
business functionality an information system (as a product) provides to a
user". The IFPUG report in the article explains it further and also mentions
the inaccuracies across different variations of that metric [2].

As a Smalltalk programmer I certainly agree with having an increased
productivity when programming in Smalltalk. But in my opinion this does depend
less on the language and much more on the development environment. Having
worked with multiple Smalltalk-like environments for JavaScript I can
(anecdotally) report the same kind of productivity for programming in JS.

I think the right tooling around a PL influence productivity a lot, maybe even
more than the language itself. Of course, certain tooling features depend on
meta interfaces of the programming language and its runtime.

[1]
[https://en.wikipedia.org/wiki/Function_point](https://en.wikipedia.org/wiki/Function_point)

[2] page 9, [http://www.ifpug.org/wp-
content/uploads/2017/04/IYSM.-Thirty...](http://www.ifpug.org/wp-
content/uploads/2017/04/IYSM.-Thirty-years-of-IFPUG.-Software-Economics-and-
Function-Point-Metrics-Capers-Jones.pdf)

~~~
ianbicking
Hmm... Smalltalk isn't quite as productive as MUMPS. The numbers seem pretty
suspect.

If the business functionality being provided is "deliver networked application
to customer" then JavaScript would probably do well. If it's "create 3D
rendering engine" then other language orderings are likely. How can you
normalize the fact that different languages are appropriate for different
domains? Do you have to come up with numbers that compare the business value
of very different tasks.

~~~
coldtea
> _How can you normalize the fact that different languages are appropriate for
> different domains?_

There's nothing that makes Javascript especially appropriate for web apps,
except for the fact that it's bundled as the default and only language on web
browsers.

So there's always that. Such accidents of history play more important role on
what ecosystem and thus perceived suitability a language has, than the
language's own merits.

Judged purely on language merits, Smalltalk would have made an excellent
language for web apps and more over JS.

~~~
ianbicking
Take Smalltalk, throw away the image, or go over further and throw away the
standard library (it's important that JavaScript never really had one), and
what would you have? Take the database away from MUMPS and it's not even
MUMPS.

Languages and runtimes can't be separated, because you can't just transplant a
language to a different runtime and maintain the same experience.

~~~
coldtea
> _Take Smalltalk, throw away the image, or go over further and throw away the
> standard library (it 's important that JavaScript never really had one), and
> what would you have?_

Still a damn fine language.

That said, I don't think it's necessary to drop the standard library to make
Smalltalk a web language, nor that it's "important that JavaScript never
really had one".

It would have been much better if it came with a better "batteries" for all
basic stuff (parsing urls, string manipulation, making requests, etc) from the
start.

Ditto for the image -- one could very easily have web images, in fact that's
part of what WASM would eventually achieve.

------
mpweiher
Remember the Caper Jones Function Point study of 30 years ago? It has a "30
years on" follow-up[1]. Smalltalk once again did exceedingly well, as pointed
out by this article, as did some other surprising contenders.

[1] [http://www.ifpug.org/wp-
content/uploads/2017/04/IYSM.-Thirty...](http://www.ifpug.org/wp-
content/uploads/2017/04/IYSM.-Thirty-years-of-IFPUG.-Software-Economics-and-
Function-Point-Metrics-Capers-Jones.pdf)

------
sixtypoundhound
Visual Basic's relatively strong ranking is interesting; my recollection was
while VBA could be an extremely productive language, it was also a very
"brittle" one.

I recall many VBA projects where I was flying along using my favorite toolkit
/ framework for a specific domain, until we hit something that wasn't "in the
manual" \- at which point, peering inside the beast became very hard. So 30%
of time spend cranking out useful code and 60% of the time spent clearing some
arcane roadblock because a client wanted something that didn't neatly fit the
standard.

Python's standard library has always seemed much more flexible (and when
necessary, comprehensible) in comparison...

~~~
ryanbrunner
VBA and VB are very different languages that share a syntax. I agree
wholeheartedly with your assessment of VBA, but in VB you had much better type
support (by no means perfect still), better tooling, better static analysis,
proper compilation (It's been a while so I can't remember how it worked under
the hood, but you'd at least be aware of type errors early).

------
piaste
From the cited "metrics":

Forth — 14,636

Haxe — 14,636

Lisp — 14,636

C++ — 12,697

Go — 12,697

Java — 12,697

PHP — 12,697

Python — 12,697

I wonder, is there a technical term for this bullshit practice of using
pointlessly large numbers to make your measurements appear more accurate and
detailed than they actually are?

Because if their metrics actually carried five significant digits' worth of
information, there's _no chance in hell_ seven vastly different languages
could share two scores.

~~~
afranchuk
Overprecision or false precision seem to fit the bill.

------
progman
According to the Namcook Analysis all the IT world should switch to Excel
since it is placed 13 places ahead of Smalltalk. And according to my personal
experience Lisp is not that unproductive. And other business languages like
OCaml are not even mentioned.

Rank 1/Asm 6/C 26/Lisp 65/Smalltalk 78/Excel

------
cdevs
Seems weird to put some of these languages up against each other when most of
the time they are use in completely different project types games vs web vs
apps vs front end vs desktop vs whatever.

------
nwienert
Unfortunately these stats likely mean nearly nothing when you separate them
out on some more important dimensions.

Javascript productivity is likely incredibly variant as you have such a
diverse set of tools/libraries/build-systems within it. At the top end you
have people using async/await, Typescript, hot reloading, and a litany of
libraries and patterns they have learned over years, test suites that
encourage writing more tests more easily (Jest, Ava), and huge downstream
efforts in tooling like the recent profiling improvements in Chrome devtools
or profiling/errors in React.

In the end my best guess at what roughly equates to real-world productivity
ends up being much more centered around the following metrics:

\- Richness of developer debugging tools

\- 3rd party library maturity

\- Online community, documentation, examples (chat + q&a)

\- Ability implement better design patterns easily

\- Type systems

\- Feedback loops (hmr, auto-restart, easy package writing)

Further, lines of code is a poor metric for effectiveness. As an example in
JS, I much prefer a more explicit, less functional, and more spaced out style
of code as it is really quite easy to read and debug and in effect takes no
more time to write than the more dense functional style.

Caveat: I only skimmed the attached paper, but writing these thoughts to
provide a counter to what I assume is the claim there.

~~~
codemac
You should really read the attached paper. The whole point is that it takes
total cost of ownership (i.e. all those other metrics / factors you list) into
account, and function points instead of lines of code..

Capers Jones measures these things in a fairly sophisticated way, and has been
working on it since the late seventies. Spend some time and read his work
before making these surface level comments that are refuted directly in the
source.

~~~
nwienert
Actually that applies only to a small part of what I wrote, which is why I
still posted it. The bulk of my argument remains valid.

~~~
codemac
... no, it doesn't. He evaluates productivity in terms of the total cost,
including all of those development tools & practices you list.

The bulk of your argument is valid, but it's by definition included in what
Jones' calculates as "productivity". It's a enormous red flashing light that
says "I didn't read the linked references".

------
wglb
I on two separate occasions had the opportunity to professionally program in
Smalltalk. It was very rewarding, and satisfying. One measure was that at the
end of an 8 hour day, I was exhausted, as it was full-time programming. No
compile breaks for swordplay or other ruminations.

But it did give a different model of the world from a programming point of
view.

------
throwaway7645
How is C++ more productive than Lisp? Sheer library power?

~~~
verdex_phone
I imagine the types of things you do with the respective languages as well as
the number of people in the communities have a pretty big impact.

For example if you're using c++ to implement an interface for some hardware
then maybe you can just quickly follow a spec. But with lisp you're more
likely to try and implement some sort of ai thing that requires a lot of
stopping and thinking.

With respect to community size, if you have a bunch of people then you're
going to get more accurate numbers but if you have a small community then you
might end up with a lot of outliers.

Finally people are probably more likely to have a significant amount of
practice with c++ vs lisp and that probably has an impact.

~~~
tomcam
Why the hell was this downvoted?

------
fwip
By the cited metric, Smalltalk loses to MUMPS and barely places above Visual
Basic.

~~~
derpydev
Having worked heavily in MUMPS for almost 3.5 years at a previous job, I'd
actually agree with MUMPS being a very productive environment. I think the
main reason for this is that the semantics for working with in-memory and
persisted data is identical, but still explicit due to the naming convention.
This combined with the extremely limited language resulted in code that always
was straightforward to read and modify as long as the previous author used
decent variable names. I certainly wouldn't advocate for MUMPS, but I have
been longing for something similar to its database access semantics since I
stopped using it.

~~~
specialist
Do you consider Intersystems’ Caché to be a MUMPS? I ask because that stack us
the worst I’ve ever used professionally. A syntax error borking the compiler
can bork your entire runtime.

~~~
derpydev
While we used Caché as our MUMPS runtime, it was policy to not use any of the
language extensions in case we ever needed to switch to GT.M, so I can only
speak to what is in the ANSI spec[1]. I never looked into the Caché
functionality as a result, but it looks like if you used their ObjectScript
then you definitely had a different experience than me. The closest thing to
relational objects we had was that we had an internal standard for defining
the structure of our globals (databases) such that they could be accessed and
iterated over in a consistent way using an internal library of functions that
made it kinda feel like working with tables; though even that was designed
primarily to avoid bugs caused by simple typos. The vast majority of the code
I wrote/worked with involved primarily for loops and basic CRUD with some
locking code that was also simplified via an internal function library.

As for your syntax error woes, I don't recall ever running into a massive
issue like that, but then again by the time I was working at this company they
had decades of time to figure out a stable MUMPS dev environment and even an
internal IDE for it, and for the most part they seem to have succeeded. I
still wouldn't say I like MUMPS; if it had first class functions and the
ability to use an entire tree as a return value (or at least a pointer of some
kind) rather than only the value of the root node then I'd probably say I like
it.

[1]
[http://mumps.sourceforge.net/docs.html](http://mumps.sourceforge.net/docs.html)

------
SwellJoe
I haven't read the whole paper yet, but looking at the list, I wonder if
programmer experience is a confounding variable?

e.g. Smalltalk, and many of the other languages that scored well, are
generally older languages that aren't super-popular or trendy. e.g. Perl
scores very well, much better than one would expect given the reputation Perl
has (which I think is somewhat unfounded, but I'm in the minority in thinking
Perl is a pretty good language for programming in the large). While Python
scores relatively poorly, despite the fact that many consider it a very good
language on most of the metrics this kind of ranking ought to reflect. Perl is
used almost exclusively by old coders with a ton of experience, Python is
relatively trendy and has a lot of new programmers working in the language.
JavaScript is a perfect storm of newbies with little experience writing
gazillions of lines of code, seeming to further support my theory; I'd wager
there are more programmers with <2 years programming experience working in
JavaScript than any other language, and probably a higher percentage with no
formal programming education, as well.

Smalltalk, is, of course, an old language with a lot of old and experienced
programmers working in it. Not many new programmers are taking up Smalltalk.

It seems almost as if this one thing can explain the ranking, or at least a
big percentage of the difference. Even if they controlled for experience with
the language, they may not have controlled for programming experience in
general...which is, I think maybe even more relevant to the results. The best
Python programmer I've ever worked with was a Java programmer for years, and
hadn't really worked with Python at all until a year or two before I met him.
Smalltalk people have been around. MUMPS people have been around. Perl people
have been around. Eiffel people have been around. (Many of the languages that
ranked high are also used in specific, stodgy, industries where the
reliability requirements are very high...medicine and finance, for example.
Those industries favor experienced programmers with credentials to back them
up.)

There's occasionally studies about average developer salaries, as well, and
they look a lot like this list, even though they seem to imply it's the
_language_ that's setting the price, I think it's the experience and age of
the coders working in them. (And, based on this and other studies about
relative productivity, the old timers pushing up the average salary for those
older languages are probably still underpaid.)

In short: Is this really measuring the language or the programmers working in
those languages? (It probably doesn't matter for the people reading this
study, as they just want reliable software developed quickly and within
budget, and choosing a language that scores well might get them the developers
that make reliable software quickly within budget. So, cause and effect might
be matched up so closely that it doesn't invalidate the study for it to
actually be about the programmers rather than the code.

But, maybe they did cover this variable and I just haven't read deep enough to
see it; I've only skimmed the paper, so I could be talking nonsense.

~~~
mpweiher
They got very similar results in the original paper 30 years ago.

~~~
SwellJoe
Sure, and I guess C is an old language with old programmers, and it scored
very, very, poorly...which, I think, is safe to blame on the language. So,
yeah, more than one factor at play here.

------
dmitriid
There’s one simple answer to such claims, whether they are made by Smalltalk,
Erlang, Haskell, or whatever.

The answer is: where are the accomplishments?

Show me the Kafkas, the Cassandras, the Hadoops, the Kuberneteses, the
nginxes, the jettys, the (a myriad of other projects)s.

After literally tens of years of claiming/boasting that they are the best, and
that other languages suck, I’ve yet to see any of these claims turn into
anything but empty posturing.

~~~
throwaway7645
There's actually a ton of business software written in Smalltalk. I think 2/3
of the world's shipping industry is controlled via Smalltalk for example. It
isn't super low level like C, so I wouldn't use it for something that needs to
be blazing fast. I believe Smalltalk pioneered the JIT technology that Java
uses (hotspot...if I recall correctly). It isn't a silver bullet, but seems
like a neat language.

~~~
akhilcacharya
>I think 2/3 of the world's shipping industry is controlled via Smalltalk for
example

Which system?

~~~
nunb
It's on this page in the shipping section [1]. I remember it had something to
do with live object databases too, back when Avi Bryant of DabbleDB [2] was
heavily pushing the Ruby world towards Smalltalk in the 2007-2010 timeframe
with Maglev [3].

[1]
[http://www.cincomsmalltalk.com/main/successes/](http://www.cincomsmalltalk.com/main/successes/)

[2] [https://techcrunch.com/2006/03/11/dabbledb-online-app-
buildi...](https://techcrunch.com/2006/03/11/dabbledb-online-app-building-for-
everyone/)

[3] [http://pragmati.st/2007/05/19/avi-bryant-
keynote/](http://pragmati.st/2007/05/19/avi-bryant-keynote/)

------
acscott314
Presumably, to consider productivity the purpose is to get the most bang
(output) for your buck (input).

The cost, C, to create app, A, that generates income I, varies with the pool
of talent that will actually do the work. Also, consider the entropy of the
system A targets, the C to modify A, and the time value of I. Once complete,
if your org can live that long, if your A is faster, higher quality, more
pleasurable to use, more cachet, more media coverage, more support, more
money, more envy than a set of competitors, then the language it's written in
becomes the next hot thing--if the word gets out.

Anyway, the ability for a junior programmer to pick up the code, create
valuable improvements and grow with the organization (a super-specialized
language requiring continual self-training is counter to that quality), and be
productive, is a very important factor sometimes. So output can include very
many, different things.

Function points may correlate to lines of code. If that's the case, then also
consider the lines of code does not necessarily correlate with output. For
instance, having to guess the correct search term to find the library you are
needing to write that one line also takes time. Making sure the version of the
library you are using plays nice with other libraries, the language syntax
targets the version of the compiler, interpreter, hardware, architecture,
platform, kernel, and standards also impacts output.

It is an interesting attempt to measure productivity with function point
analysis. But, and you knew that was coming, there are so many more factors
involved before you it is justifiably reasonable to draw a conclusion on
productivity of a language.

