As Jean Yang point out the HCI and Human Factors community having worked on this for a long time, and it is indeed the case.

Here is one of my preferred paper from that community on that exact problem https://ieeexplore.ieee.org/document/1363742

> How do you get promoted?

This is a great open ended question to uncover what really motivates someone rather than asking someone what feature(s) they use / care about.

If you are in a position where promotion matters you are probably not in a position where you can choose the language that you're working with (other than by switching to a new position).

If your goal is to get a new programming language adopted, you should be interviewing a very restricted set of users: originators of major open-source projects, technical founders of successful startups, early engineers on a new product, and freelancers. Those are the people who are in the position to choose a new language. They often choose the language for very mundane reasons, eg. "It was the only option available for iOS development", "I understood its documentation the best", "This library that solved 80% of my problem was only available in it", or "I'd used it on my previous hobby project and it worked out well." Everybody else is working within the technology choices set by this group, so their opinion doesn't matter (for adoption, at least; you can still try to optimize happiness with them).

Agreed. Or: How do you get motivated? Some people (like me) don't care too much about promotion and only want to seek happiness from a technical world.

> My strong belief is that programming languages research does not value usability because there currently is no satisfying, agreed-upon way of evaluating it.

This is talking about usability of the programming language - or of a language that incorporates whatever conclusions the research reaches. This matches something I've been thinking a lot lately, that software engineering is a different animal than computer science. If your PL advance is the greatest CS thing since sliced bread, but it isn't usable for actual programmers working to write programs, then... who cares?

The ergonomics of computer languages is not what computer scientists think it is. CS types complain about how stupid the field is to use languages that don't reflect the best CS research. The reality is, the CS researchers are too ignorant to grasp what actually makes languages useful in the field.

Strongly stated but I think there's some truth here. Most serious programming languages have a bias towards concepts explored in the academic study of programming languages. Of course academic theories sometimes provide a great foundation with some pretty solid ideas but they needn't be the only source of good ideas.

Programming is a design exercise and figuring out how to help humans think and explore design is something I think practitioners have more to say on than theorists. Or at least if not more to say, they certainly have more of a contribution to make in this space than we've seen so far. (disclaimer: I'm a practitioner without a CS degree working on a programming language)

CS Research : Programming, Physics : Engineering ? I think you can level this criticism, and yeah, you have a point, but I think there has to be constant back and forth between the practitioners and those who develop theory or else both sides seriously lose out.

The author of this post is a computer scientist, who is explicitly talking about adding these measures of usability to experimental evaluations to PL papers

Sure. I'm talking about the bulk of the CS PL field as a whole, and I don't think I'm disagreeing with the author of the post. (Do note, however, that the author left academia and is now in the field...)

I have been thinking a lot about this myself lately as I'm designing a programming language and want to solve for things many of them simply don't; Like accessibility.

I'm curious of your views on accessibility in programming languages. Since programming languages are ascii text, shouldn't a screen reader do well with it?

Imagine writing lisp and trying to fix a mismatched paren with a screen reader.

I see your point, but nesting has to be expressible somehow with ascii. I suspect this is better addressed by an IDE or a customized screen reader.

BTW, I find the parens in Lisp to be hopeless even as a sighted person, and even spending considerable effort trying to format it to make it clear. It's one reason why I customized my text editor with a "matching paren" command, which is a life saver. (It also matches braces and square brackets, even #if/#ifdef/#ifndef/#else/#elif/#endif.)

Your comical bumbling with basic code editing is difficult to grasp.

Auto-indentation and parenthesis matching has been a standard feature of any decent programming editor for decades.

Vim matches parentheses and C #ifdef out-of-the box, and indents Lisp. It did all that very well in the year 2000 when I started in Lisp.

A parenhesis matching command (the % key) has been in Vi since the 1970's, and the same is true of the Lisp mode (:set lisp) that handles the bulk of the indentation semantics. When you load a .lisp file, Vim turns on Lisp mode. That ancient invention is what does the indentation.

Nobody spends "considerable effort" formatting Lisp. Not even buffoons like me who use a Vi derivative, and who are ridiculed by Emacs users.

Oh I know I didn't invent paren matching, though I did add it to my editor in the 80's. I can claim invention of #if matching, though, as I implemented that in the 80's, too. Don't know of any prior art on that.

Vim was vi at the time :-) and didn't have a Lisp mode at the time that I was aware of, and I haven't messed with Lisp since the 80's.

And yes, I still find Lisp difficult to read, regardless of how its formatted. Infix reads much better for me.

I guess it is the same as trying to fix mismatched curly bracket on a C declaration or code block.

Have you been in this situation? Will you please say more if so?

I’m sighted - I’ve pretty much only used screen readers when testing accessibility feature for software I’ve built.

There was a bit of a learning curve, but actually the interface isn’t bad if the software is built for it.

When it’s not though, it’s absolutely agonizing.

Funny enough, I was imagining patterns used in “visual” programming languages might be helpful for people who use screen readers.

That is - make valid syntax and its composition first class UX entities, rather than just a freeform stream of hopefully parseable text.

Strictly visually programming languages can be pretty tedious, but maybe some hybrid where symbols/names can be keyed in, but scoping elements such as a function definition, a module scope, and maybe a parenthetical would be added as an indivisible unit.

Same. I'm actually building a programming language for non-programmers. Trying to create a language for UI designers, which requires a unique sensitivity to complexity in order to feel inclusive.

I'm also curious what you mean by this - do you mean accessibility in the sense of what languages like Elm try to do?

I'm in industry, and sorry, I think most of industry is far too stupid for large-scale feedback to be a good idea.

Please stick to your ivory towers unless you are really sure of who you are talking to.

> One of the biggest challenges security engineers face is getting software engineers to fix their bugs.

Oh my, don't get me started on that. Usually it's not worth talking to maintainers who don't understand security implications. Either walk away and choose something else or maintain a fork with your fixes. This is usually the easiest. And trivial with git to automate.

But hiring penetration testers just to convince some moron that this bug is exploitable? Come on!