________________________________________________________________________________
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
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.
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?
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.
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.
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.
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...)
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!