Smalltalk’s Productivity

https://medium.com/smalltalk-talk/smalltalk-s-proven-productivity-fe7cbd99c061

by mpweiher • 9 years ago

93 79 9 years ago

mpweiher3• 9 years ago

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...

nwienert2• 9 years ago

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.

pvg• 9 years ago

lines of code is a poor metric for effectiveness.

That's one of the central arguments of the paper. The metric it uses is not LoC, other than as a comparison to other metrics.

codemac2• 9 years ago

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.

nwienert2• 9 years ago

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.

robertkrahn016• 9 years ago

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

[2] page 9, http://www.ifpug.org/wp-content/uploads/2017/04/IYSM.-Thirty...

tristanho• 9 years ago

Interesting! What makes a programming environment "Smalltalk-like" and what are some examples?

agumonkey• 9 years ago

a kay oop lisp machine, full reification from low levels to gui layers

robertkrahn016• 9 years ago

Smalltalk has a meta API that is designed to allow introspection and modification of both static and dynamic code entities [1,2].

Static entities such as classes and methods (and depending on your Smalltalk implementation namespaces and object versions) can be modified at runtime, i.e. while your program is running you can make a change and get an immediate effect. This is now known as "live" programming, however, it is notably different from your typical "hot reload" implementation in that it knows how to apply changes for individual code entities. E.g. if you modify a method you don't need to reload the entire class or module or entire runtime. For me, this feature alone makes for a big productivity increase.

Dynamic entities such as stack frames can also be reified by the meta interface. This allows to inspect and modify runtime processes, e.g. inside a "debugger" [3]. Note that the debugger allows to modify and create new code while your are debugging. This is a powerful feature because it means that you get access to runtime objects inside of it. Ever wondered what object gets passed into your method at a certain point, what methods it knows, what properties it has? Just try it out and see for yourself!

An interesting analogy to describe this experience: [4].

For a deeper description about the ideas behind that see Design Principles Behind Smalltalk [5].

Also, most Lisp implementations provide the same kind of meta interface, and CLOS arguably provides a more flexible and higher level abstraction of these ideas [6].

As for similar environments I have worked on, there is Lively for JavaScript [7] and cloxp for Clojure [8]

[1] http://sdmeta.gforge.inria.fr/FreeBooks/ByExample/31%20-%20C...

[2] Chapters 16 http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook....

[3] https://www.youtube.com/watch?v=1kuoS796vNw

[4] http://simberon.blogspot.nl/2013/01/swimming-with-fish.html

[5] https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk....

[6] https://mitpress.mit.edu/books/art-metaobject-protocol

[7] http://lively-next.org/

[8] http://cloxp.github.io/

ianbicking2• 9 years ago

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.

coldtea4• 9 years ago

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.

nradov• 9 years ago

Function point analysis is best suited to line-of-business CRUD and batch processing applications with limited algorithmic complexity. Of course it can be applied to other domains but then the numbers get a lot more subjective and comparisons are less accurate.

fulafel• 9 years ago

JS/WebGL is a very productive platform to develop a 3D engine on compared to alternatives. Only some compile-to-JS languages may be better.

nikki934• 9 years ago

What were such envs for JS?

robertkrahn016• 9 years ago

A non-exhaustive list:

- Amber Smalltalk provides a Smalltalk layer on top of JavaScript: http://www.amber-lang.net/

- Indium adds JavaScript tooling support and runtime interaction to Emacs and brings a few Smalltalk features such as object inspection (the project creator and maintainer is a Smalltalker and author of Amber): https://github.com/NicolasPetton/indium

- Lively provides a Smalltalk-like environment (code browsing, editing) as well as object(-graph) persistence, similar to the Smalltalk image idea, and mixes in some ideas from Self: http://lively-next.org/

Lively's meta interface is separately usable via lively.vm and lively.modules: https://github.com/LivelyKernel/lively.vm https://github.com/LivelyKernel/lively.modules

seanmcdirmid3• 9 years ago

There is a small but growing movement in PL academia to study programming experiences rather than just programming languages. Many of us are basically cyborg programmers these days, reliant on our tools and information resources for increased productivity.

fwip• 9 years ago

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

mpweiher3• 9 years ago

Surprising, isn‘t it?

Then again, maybe we should use data to inform our opinions (inform, not determine), rather using our opinions to filter out data?

lispm• 9 years ago

Unfortunately much of the data about function points in programming languages is more or less random, because the 'data' was just a guess decades ago or based on obscure measurements done with unknown projects decades ago.

Take the number in table 16 from the cited paper for LISP. There is no explanation what this LISP actually is and what projects the 'data' comes from. One finds the same data in papers from two or more decades ago. There FLAVORS, an OO system from Lisp Machine Lisp from the 80s, gets a much different value. CLOS, the OO system of Common Lisp, gets another one.

These tables were in part computed/guesses from language variants which were looked at decades ago.

Thus without qualifying the numbers, the tables are for many languages just nonsense. The data behind it is weak and the conclusions are on shaky ground. This amounts to pseudo science.

derpydev2• 9 years ago

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• 9 years ago

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.

sixtypoundhound• 9 years ago

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• 9 years ago

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).

SwellJoe2• 9 years ago

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.

mpweiher3• 9 years ago

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

SwellJoe2• 9 years ago

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.

throwaway76453• 9 years ago

Take a beginner programmer...I guarantee they will get up to speed in Python quicker than Perl. For example, python doesn't require you to remember that the list uses @, but when you want just one element of it you have to use scalar context "$" and other weirdness. With that being said, I think Perl allows the power user a lot of flexibility in building applications and is probably more productive for that kind of expert in small to medium size apps. This isn't to say Python doesn't have power users either. Perl the language gets dramatically powered up by CPAN modules like MOOSE that give it more advanced OO than many OO languages like Python.

cdevs• 9 years ago

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.

dmitriid8• 9 years ago

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.

crispinb2• 9 years ago

A big red flag for lacking real accomplishments is when the only 'real world' examples proffered are (1) run of the mill web apps (which can be thrown together using just about every programming environment on the planet); and/or (2) 'enterprise apps' (a good working definition of which is: 'apps which are only ever launched by order of the boss').

Apocryphon2• 9 years ago

In today's age, aren't those the two major businesses cases for software that aren't embedded or aren't desktop or mobile apps?

throwaway76453• 9 years ago

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.

dmitriid8• 9 years ago

A lot of business runs on top of weird languages.

Quite often they are simply stuck with those languages. Because a non-IT manager got some consultants who promised them 100x results for 1/100 money.

As research/test beds these languages are rather invaluable.

Their other values are frankly overrated.

akhilcacharya• 9 years ago

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

Which system?

vbuwivbiu• 9 years ago

that's like arguing that English is a better language than say Welsh, simply because more great literature has been written in it because it's more popular. But by all accounts Welsh is a great language that happens to be spoken by fewer people.

jacquesm3• 9 years ago

For the Erlang case in your list: every time you pick up a phone and you get a dial tone or your cell phone connection goes through you will have interacted with Erlang code at least several times.

The financial world has a ton of Haskell.

Smalltalk has its successes but most of them are in the past.

dmitriid8• 9 years ago

For the Erlang case in your list: every time you pick up a phone

Yeah, yeah, yeah. AXD301 is the only thing that keeps E going. It was the poster child 20 years ago, it still is the poster child today.

Quite sad if you consider Erlang's claim: Build massively scalable soft real-time systems.

Hint: you can't build a massively scalable system in Erlang any easier than in any other language. For reasons see the RELEASE project

The financial world has a ton of Haskell.

The financial world has much more than a ton of other languages.

Smalltalk has its successes but most of them are in the past.

Indeed.

throwaway76453• 9 years ago

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

verdex_phone• 9 years ago

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• 9 years ago

Why the hell was this downvoted?

wglb• 9 years ago

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.

acscott314• 9 years ago

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.

progman• 9 years ago

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

piaste• 9 years ago

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• 9 years ago

Overprecision or false precision seem to fit the bill.

Smalltalk’s Productivity

Related Stories