Hacker News Reader

Comment by mfru | Hacker News Reader

Apart from ADA, what are languages / stacks with most aspects of "Human Factors Engineering" considered?

Niklaus Wirth designed Pascal (1970) with explicit pedagogical and human factors goals documented in his seminal paper "On the Design of Programming Languages". Wirth explicitly stated his belief that "insights gained from educational considerations could benefit programming language design in general, and that the simplicity and clarity he was striving for should be a guiding principle for all language design, serving equally pedagogical and development purposes". But - as with Ada - I'm not aware of any notable human factors engineering studies to validate design decisions.

Also Alan Kay and the Xerox PARC team designed Smalltalk (as Papert did before with Logo) with profound human-centered considerations, and they even "tested" their early concepts with children.

Also some other languages explicitly state human-centered design goals (e.g. Python, Eiffel), but as with Pascal or Ada the approach was more based on expert judgment, formal analysis, and established principles, not practical studies.

Human factors studies on programming languages are really hard to do right. It is easy to study someone seeing a language for the first time. However programming well requires a high level of expertise and so the real question isn't how easy it is for a beginner, it is how easy it is for someone who has been doing it for years. Or maybe how much different is someone after a week vs month vs year (that is at what point do the experience gains plateau)- in all this you have to be careful to ask different tasks - since good programmers will abstract when they need to do something twice.

I think it's not more difficult than identifying representative user groups (at least five members per group) and defining typical tasks for a usability test, focussing on the specific features in question. It's just a lot of work and requires experience and training.

You make a very good point, and maybe a problem here is that “human factors studies” are set up like market research rather than anthropology.

People who’ve spent a long time programming have spent a long time optimizing everything about their work, and they’re willing to talk about it (most of them won’t shut up about it, even).

Perl is one obvious one, as anyone will realize, if one has read some of Larry Wall's articles about his (and later the team's) motivations for the (syntax and semantics) design decisions they made about the language. For example, in his annual State of The Onion talks, he often discusses these points.

They may not have used standards such as the gp comment mentions, but they definitely considered human factors a lot.

E.g. TIMTOWTDI - There Is More Than One Way To Do It.

But that's not the only area in which they applied it.

Perl presents a fascinating counterexample: Larry Wall, trained as a linguist, explicitly cared about human factors, but his linguistic philosophy produced a language that empirical tests show performs poorly on readability and learnability measures (see e.g. http://dx.doi.org/10.1145/2534973 or https://doi.org/10.1145/2089155.2089159).

I haven't used Perl much, but my impression it is much easier to learn if you already know awk and sed - his original target was people who knew awk and sed well but were running into limitations using the two as separate tools. However the language quickly spread to people who don't know either of the previous tools and then it is difficult to learn.

>I haven't used Perl much, but my impression it is much easier to learn if you already know awk and sed - his original target was people who knew awk and sed well but were running into limitations using the two as separate tools.

Yes. In fact, in the early days, there were tools with names like sed2perl and awk2perl, or similar, IIRC. And those could convert code between their respective source and target languages.

And even easier if you know C and Unix.

Just like human dialects, across the same main language, :)

I'm gonna read your links but I assume that 90% of the programming population doesn't grasp linguistic approaches to representing knowledge and logic (not saying this as a superiority thing, more as a cultural gap too wide)

I'm sorry, but both of those studies are a joke. They are taking novices who can't program, and are asking them to perform basic programming tasks in languages that they haven't learned. They are essentially testing how steep the initial learning curve is when you first see a language.

A far more important measure is something like function points per month of developer time. See page 49 of https://www.ifpug.org/wp-content/uploads/2017/04/IYSM.-Thirt... for some data on that. ADA 95 did pretty well, around 11. Perl beat it with 15.

Of course that measure isn't perfect. Excel trounced both with over 30. But Excel is only appropriate for some kinds of projects.

Obviously, COBOL as a human-friendly improvement over Assembler, and BASIC as a more natural (English-friendly) improvement over COBOL, qualify.

I think Eiffel would be one of them.

Reply on news.ycombinator.com