Really appreciate this article. Some languages feel like their syntax was designed by developers and others feel like it was designed by designers. It seems totally appropriate that the UI (language design) should be a different skill and created with a different mindset than the back end (language implementation). I hope that this focus can lead to more beautifully designed languages, not just faster languages.
Most technologists don't seem to believe that design applies to programming languages at all. Programming languages are tools and tools are typically designed for efficiency, which is measurable - but you'll still hear things like 'syntax is personal'.
- It's worth optimizing for more people than fewer.
- There are a thousand times as many future programmers than there are existing ones.
- One can measure how easy it is for a clean-room human to read and create software in different languages and build something for them.
I'd be happy to just have less variation in the syntax corresponding to established semantics; if you're designing a new language, please don't make some 'nifty' new way of typing out dictionaries. All this does is force me to hunker down with several beginning chapters of your programming language book instead of just skipping to the relevant differences from languages I already know.
If there's a good reason for the difference, by all means, go for it. But if there isn't, please reconsider.
So that leaves little room for alternative language paradigms then. If you want dictionaries to look like JS or Python then what are languages like Lisp and APL to do, not use coherent syntax. Or what about just making different use of the limited number of symbols on the keyboard to make the use more consistent?
Id rather have a more consistent language or one that introduced new concepts than one familiar in syntax just for the sake of being familiar.
>So that leaves little room for alternative language paradigms then. If you want dictionaries to look like JS or Python then what are languages like Lisp and APL to do, not use coherent syntax.
Yes, but what about the benefits from the regularity and uniformity?
Sure, I understand. But it's not just a case of new languages coming up and reusing concepts from the set of all currently-available syntaxes; they in fact invent wholly new ones.
Edit: further to your point, I agree that my gripes are merely about an up-front cost, whereas consistency can be helpful throughout your use of a language.
Edit again: I essentially seek consistency within and among languages. I don't mean to state one should come at the cost of the other at all times.
If you're a programmer now, you're a secondary audience to the masses of people who will program in the future. If the language is going to have the most impact, what they prefer supersedes what you (and I) prefer.
> If there's a good reason for the difference, by all means, go for it.
Of course and agreed. Nothing should exist without reason. Antoine de Saint Exupery etc.
This seems to be blurring a use of "design". Not all design is chrome on top of things. Some literally leads to better use. Some design is required for safe use.
I think it is oversold, but the book "Design of Everyday Things"[1] goes over this for many common items. There is a long section on doors with many interesting points to consider.
Apologies, that is exactly what I was trying to say. Specifically, I was arguing against "Most technologists don't seem to believe that design applies to programming languages at all."
I was speculating that this belief is from folks that think design is just chrome.
I disagree. Most technologists agree design is important in PX (PL + tools), but programmers are more willing to put up with poorly designed experiences in exchange for the latest technology.
The original syntax for lambdas in D worked, but it was so clumsy nobody used it, and people even said "D doesn't have lambdas". Changing it to a much simpler syntax changed everything.
old:
function double(double a, double b) { return a + b; }
new:
(a, b) { return a + b; }
Currently, the syntax for in/out contracts is being revised for usability:
