[Rochus]

> Usability is similarly ill-defined and hard to measure.

Human factors are very well studied and standardized, and there is a well-established discipline called "Human Factors Engineering", which also provides established test and evaluation methods. Human Factors research is considered solid and well-established because it has been built on rigorous experimental psychology and engineering principles developed over more than a century, with systematic methodology and empirical validation. Even if much of it is unknown or ignored by computer science or programming language design, there are many disciplines where Human Factors Engineering is critical (see e.g. ANSI/AAMI HE75).

Usability is therefore neither ill-defined nor hard to measure. Several ISO 9241 series standards address textual and command-based interaction directly relevant to programming language assessment. ETSI EG 202 116 provides extensive human factors guidelines for command language style. ITU-T Recommendation Z.361 provides guidelines for Human-Computer Interfaces in telecommunications management, incorporating the ISO 9241-10 dialogue principles. ISO/IEC TR 24772 addresses programming language vulnerabilities specifically from a human factors perspective.

E.g. Ada did have substantial human factors considerations documented in its design rationale, directly contradicting the notion that such principles don't apply to professional developers or programming languages. It's rather that computer science seems to continue ignoring established fields ("Not invented here"). Human factors in software development have been overlooked by researchers in the software engineering and development research areas, despite their obvious relevance. So what is lacking is primarily interest or willingness, not the fundamentals and means.

[saghm]

Honest question: given the relatively niche status of Ada compared to other systems programming languages, and similar diminished levels of popularity for other languages mentioned in this thread (Pascal, Perl), does this really prove that these principles are particularly effective for programming languages? I understand that this is a relatively small sample size, but I feel like that could be just as well used to argue that other factors might have been more important to the successes of languages designed like Ada than the more rigorous approach to human usability. It doesn't feel particularly obvious to me that we know these principles actually work well for programming languages but choose to ignore them rather than them not fitting the domain particularly well at all, or maybe something in between where we don't really know whether they apply well yet or not, and more attempts at using them might not actually be as successful as one might hope.

[Rochus]

I didn't claim that usability features were "important to the successes of languages designed like Ada". But Ada at least explicitly considered human factors in their design (even if mostly based on expert judgment and established principles, not practical studies), which also seems very appropriate given the criticality of most applications written in Ada. But as my ergonomics professor at ETH Zurich, Helmut Krüger (successor to the renowned Étienne Grandjean), used to say: people get used to even the most ergonomically terrible systems. The "level of suffering" experienced by most people is probably simply not great enough to systematically take such aspects into account. But there are still industries where it is important to reduce the human tendency to make mistakes by taking appropriate measures. Ada was created for such an industry from the very beginning.

[saghm]

> I didn't claim that usability features were "important to the successes of languages designed like Ada".

This kind of seems like it's focusing too much on my exact word choice and less the actual intent of my question behind it. The question I have is why following established principles should matter; I don't think it should be particularly surprising that someone might assume that making a language more usable for humans would be related to the number of humans who end up deciding to use it, and if that's not the case, I wanted to understand why my intuition is wrong.

> there are still industries where it is important to reduce the human tendency to make mistakes by taking appropriate measures. Ada was created for such an industry from the very beginning

This is a good point that I hadn't considered; it definitely makes sense to me that some domains might be less tolerant to human errors than others, and those domains would better reflect how well-designed a language is for humans.

> The "level of suffering" experienced by most people is probably simply not great enough to systematically take such aspects into account. But there are still industries where it is important to reduce the human tendency to make mistakes by taking appropriate measures.

Reading this part a couple of times, I think this might be where the nuance lies. My colloquial understanding of what it means for something to be ergonomic (and even by the idea of what"level of suffering" would mean) isn't quite the same as the measurement of how likely it is for something to induce human error. This might just be a case where the common use of the term isn't the same as how it's used inside the field of study, but I would have expected that the ergonomics of a language and measurement of the "level of suffering" would be with respect to the programmer, not the one experiencing the use of the software that's developed as a result. That isn't to say I disagree with the idea that the end-user experience should ultimately be more important, but I think that might account for the disconnect between what you're describing here and what I would have expected from a discussion around "programming language ergonomics" (which also might explain the difference between Ada and the other languages mentioned in this thread).

[Rochus]

> The question I have is why following established principles should matter

Apparently I still don't understand your question, sorry. For what I understand, following established principles is part of the engineering profession; it has proven to be the right thing to do over decades, and it is part of engineering education.

> I would have expected that the ergonomics of a language and measurement of the "level of suffering" would be with respect to the programmer, not the one experiencing the use of the software that's developed as a result.

Usually not the "level of suffering" is measured in human factors engineering, but the time needed and degree of fulfillment of typical tasks a typical representative of a test group is suppost to perform. You can do that with different designs and can then conclude which one meets the performance requirements best. Human factors typically enter a specification as performance requirements (what functions shall the system implement and how well). Given a programming language, you could measure how long a typical programmer requires to complete a specific task and how many errors the implementation has in the first version.

[saghm]

> Apparently I still don't understand your question, sorry. For what I understand, following established principles is part of the engineering profession; it has proven to be the right thing to do over decades, and it is part of engineering education.

I agree that following established principles is important, but my understanding is that the principles get established because they're better at leading to desirable outcomes. I'm trying to understand what the outcomes are that the principles you describe are intended to lead to. From your most recent two replies, my best interpretation is that it leads to fewer errors overall in the programs produced, but that wasn't as apparent to me from your first comment. I do think I understand now though.

[Rochus]

> I'm trying to understand what the outcomes are that the principles you describe are intended to lead to.

The application of the principles of Human factors engineering to the design of systems reduces human errors, increases productivity, and enhances safety, health and comfort when interacting with these systems. For a programming language, taking human factors into account appropriately means that the target group of language users (i.e. programmers) is sufficiently capable of performing their tasks in all phases of a program's life cycle, e.g., they are not cognitively overwhelmed, and the likelihood of misunderstandings or mistakes is reduced. However, they should neither be unnecessarily restricted or hindered in their work, because also this creates unnecessary extraneous cognitive load that exhausts the programmer's limited working memory capacity. Human working memory can hold only 3-5 "chunks" of information simultaneously. This is a well-documented, hard biological constraint; when programming languages impose excessive formalism, they force programmers to juggle more mental "chunks" than working memory can handle. Self-explanatory code (which includes avoiding incomprehensible abbreviations or confusing syntax) reduces the cognitive load on the programmer. Ada's explicit human factors principle states: "Code is read more than written"; over a program's lifetime, especially in large, long-lived systems, code is read orders of magnitude more often than it's written; Ada's formalism optimizes for the more frequent activity (reading and maintenance) at the expense of the less frequent activity (initial writing). As a language designer, you therefore have to find the right balance, which of course is a function of your target audience, and the primary activities they will perform with the language.

[btilly]

There is a giant https://www.dreamsongs.com/WorseIsBetter.html phenomena here. The word "good" should never be accepted at face value. It implies a question. Good for what?

ADA was designed with a goal of improving software reliability. Potentially at the cost of other factors, like programming speed. Real life projects using it demonstrated that the error rate of large ADA projects was around half of equivalent C or FORTRAN projects.

However popularity is determined by other factors. Such as personal productivity, and accessibility for novices. These other factors are often in direct opposition to long-term maintainability. It is good for productivity to be able to do things in whatever way is convenient. But that flexibility is a burden for the maintenance programmer. Likewise novices frequently create useful code, which becomes hard to maintain down the line. (Excel spreadsheets are a classic example of this.)

The result is that ADA was a good fit if you have a large project, time to market was not your top issue, and reliability and maintainability were top concerns. Many defense projects have these exact characteristics. Which is why ADA was developed and used there.

But consider a startup. Projects are small. The top concern is time to market. Maintainability will only become an issue if your product launches, gets to market, and succeeds. That's a future problem that can take care of itself.

That's why, when you look at startups, you find a high density of scripting languages. Which language has changed over time. For example Amazon used Perl, Facebook used PHP, and Instagram used Python. But all scripting languages share the similar characteristic of having fast initial development times, and poor long-term maintainability. (Yes, even Python. Internal data showing that is why Google began walking away from Python around 15 years ago.)

[mfru]

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

[Rochus]

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.

[bluGill]

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.

[Rochus]

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.

[kthielen]

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

[fuzztester]

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.

[Rochus]

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

[bluGill]

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.

[fuzztester]

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

[pjmlp]

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

[agumonkey]

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)

[btilly]

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.

[IAmBroom]

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

[pjmlp]

I think Eiffel would be one of them.