Functional programming paradigms? Matching? Complex syntax? Sorry but either I've missed the point, or you've lost me. If we're trying to create tools for non-Developers to build software, this isn't it. You can pretty much already just ask Claude/Codex/whatever and it'll build you a thing™ and it'll probably work. You don't even need to read the code.
Surprisingly, I've met non-programmers who easily learned languages considered "strange" or difficult to understand by professional programmers (Forth is even somewhat popular among astronomers, but I've also met people using Prolog for their programming needs, even J).
I've worked quite a bit with scientists who mostly use Python for their programming-related tasks. To me, it seems that the reason to work with Python has very little to do with the qualities of the language, rather the tools and the community around it. There's nothing specially intuitive or helpful about Python when it comes to doing scientific stuff, not anymore than, say, in PHP or Lua etc. languages from the same general category (which we don't see used in the same setting). It's the libraries / tools like NumPy and Jupyter that make the difference.
From just looking at EYG, I can't tell if it's a good match for the problem or not. But, really, the language design doesn't seem to play an important role in this context. If it somehow manages to win popularity among the people it's trying to engage -- great! But, unless one has an army of "evangelists" and the marketing budget rivaling GDPs of smaller countries, the success seem to be completely random and unpredictable (with quite low success rate).
> Sympathy for the machine only exists in developers. They will happily explain why integer overflows need to happen. The average human response to integer overflows is “WTF, that’s not how numbers work”. We have BigInt and 99% of the time the WTF response is the correct one.
Forget sympathy for the machine; the real reason we need programming languages that prevent issues because we should have sympathy for the poor humans who are incapable of reasoning about anything but the simplest code without hitting the limits of their hardware. I'd argue that for virtually all humans (whether developers or otherwise), the brain is like the world's worst runtime for code imaginable. The maximum memory is absurdly low (how many variables can you really remember at once?) and prone to corruption that makes C look like a heaven-sent solution to undefined behavior (how many parents of multiple children do you know who never accidentally call kids the wrong name? my average length between calling one of my cats by the name of the other is like, a day at most), and the speed is laughable (time for a single division operation is on the order of entire seconds).
The widest integers in the world will not stop us from writing buggy code, and I think we have bigger fish to fry than BigInts
I generally don't think it's a good idea to develop a language for non-developers. It was tried before multiple times and the end goal has not been achieved. Sooner or later one realizes, that professional developers are still necessary, even for languages initially designed for "normies". But such a language is typically not good enough for them, it lacks necessary abstractions, flexibility, performance or something else.
We have a lot of examples for this, like COBOL, SQL, Visual Basic.
By your logic ... BASIC is useless.
By your logic ... people are born a programmers.
Yet BASIC was literally a first stepping stone for small kids into the World of programming.
Most of what we have now is because some 6-7yo kids in 80's and 90's had BASIC and could figure out stuff by themself, without external help.
So you’re saying everyone should stop doing what they’re doing bc someone failed at it in the past? If something doesn’t interest you or motivate you it doesn’t mean it’s not worth doing
How can you say that when millions of non-programmers are using AI to write programs all of a sudden? The problem isn't with non programmers it's with the languages they've been given are usually written by people who are keen to write languages that conform to their sensibilities rather than the programmer's.
For example: I would say that 1-based indexing is pretty much required for a language targeting non-developers; Excel, SQL, R, Matlab, Cobol, Mathematica, Lua are all 1-indexed and all target non-developers. Most PL devs refuse to do this citing how unnatural it is for themselves to reason about, and how Dijkstra was right about the beauty of 0-based indexes. Sorry, but all that is irrelevant when you're trying to convince a non dev that "Actually it makes a lot of sense that the first thing is called 0". They hear that and they tune out because it asks them to abandon their familiar assumptions too early, and they're unwilling to do that on promises of it getting better.
So the first problem people have in making languages for non-developers is they make it like Python, because Python is considered an easy language for beginners. Big mistake, because then you've only appealed to people for whom Python is appealing. Those are not the people we're trying to get with a non-dev language, and besides we already have Python for that.
You look at the top languages used by non devs and you can see that they appreciate aspects of languages that devs do not, so that's why devs fail so regularly at this. But there are some success stories you point out.
Then there's of course the biggest example you forgot: Excel. And it's not a surprise this one is always forgotten by programmers because despite being a programming language it doesn't follow typical programming language conventions, and as a design artifact it sits well outside the design hornet's nest that is the C/C++/Java/Javascript/Python which comprise most of mainstream programming.
Finally there is LOGO - This one is often missed, but it's a lisp-like language that allowed small children to program complex applications like differential physics coursework which grad students find difficult to program, and they're able to do it simply by reframing the program into something they are familiar with like their own body rather than abstract concepts like integration.
They called this "body syntonic reasoning" and it was impressive because the language itself contained the pedogogical framing to enable this. If it hadn't and just said "Here's what a for loop is, now write programs!" it wouldn't have worked. This shows you in order to get non-developers to code, you have to approach them with an uncommon level of empathy for how they thin, and I don't know if most lang developers are up to that task.
I don't understand your reasoning; LLMs and programming languages are different things. Like humans, LLMs use programming languages as tools, so the existence of LLMs doesn't obviate programming languages.
23 comments
[ 3.4 ms ] story [ 7.3 ms ] threadI've worked quite a bit with scientists who mostly use Python for their programming-related tasks. To me, it seems that the reason to work with Python has very little to do with the qualities of the language, rather the tools and the community around it. There's nothing specially intuitive or helpful about Python when it comes to doing scientific stuff, not anymore than, say, in PHP or Lua etc. languages from the same general category (which we don't see used in the same setting). It's the libraries / tools like NumPy and Jupyter that make the difference.
From just looking at EYG, I can't tell if it's a good match for the problem or not. But, really, the language design doesn't seem to play an important role in this context. If it somehow manages to win popularity among the people it's trying to engage -- great! But, unless one has an army of "evangelists" and the marketing budget rivaling GDPs of smaller countries, the success seem to be completely random and unpredictable (with quite low success rate).
Anyhow, will enjoy discovering EYG as well.
Forget sympathy for the machine; the real reason we need programming languages that prevent issues because we should have sympathy for the poor humans who are incapable of reasoning about anything but the simplest code without hitting the limits of their hardware. I'd argue that for virtually all humans (whether developers or otherwise), the brain is like the world's worst runtime for code imaginable. The maximum memory is absurdly low (how many variables can you really remember at once?) and prone to corruption that makes C look like a heaven-sent solution to undefined behavior (how many parents of multiple children do you know who never accidentally call kids the wrong name? my average length between calling one of my cats by the name of the other is like, a day at most), and the speed is laughable (time for a single division operation is on the order of entire seconds).
The widest integers in the world will not stop us from writing buggy code, and I think we have bigger fish to fry than BigInts
We have a lot of examples for this, like COBOL, SQL, Visual Basic.
Yet BASIC was literally a first stepping stone for small kids into the World of programming. Most of what we have now is because some 6-7yo kids in 80's and 90's had BASIC and could figure out stuff by themself, without external help.
Though you might argue that the "programming language" part was rather accidental
For example: I would say that 1-based indexing is pretty much required for a language targeting non-developers; Excel, SQL, R, Matlab, Cobol, Mathematica, Lua are all 1-indexed and all target non-developers. Most PL devs refuse to do this citing how unnatural it is for themselves to reason about, and how Dijkstra was right about the beauty of 0-based indexes. Sorry, but all that is irrelevant when you're trying to convince a non dev that "Actually it makes a lot of sense that the first thing is called 0". They hear that and they tune out because it asks them to abandon their familiar assumptions too early, and they're unwilling to do that on promises of it getting better.
So the first problem people have in making languages for non-developers is they make it like Python, because Python is considered an easy language for beginners. Big mistake, because then you've only appealed to people for whom Python is appealing. Those are not the people we're trying to get with a non-dev language, and besides we already have Python for that.
You look at the top languages used by non devs and you can see that they appreciate aspects of languages that devs do not, so that's why devs fail so regularly at this. But there are some success stories you point out.
Then there's of course the biggest example you forgot: Excel. And it's not a surprise this one is always forgotten by programmers because despite being a programming language it doesn't follow typical programming language conventions, and as a design artifact it sits well outside the design hornet's nest that is the C/C++/Java/Javascript/Python which comprise most of mainstream programming.
Finally there is LOGO - This one is often missed, but it's a lisp-like language that allowed small children to program complex applications like differential physics coursework which grad students find difficult to program, and they're able to do it simply by reframing the program into something they are familiar with like their own body rather than abstract concepts like integration.
They called this "body syntonic reasoning" and it was impressive because the language itself contained the pedogogical framing to enable this. If it hadn't and just said "Here's what a for loop is, now write programs!" it wouldn't have worked. This shows you in order to get non-developers to code, you have to approach them with an uncommon level of empathy for how they thin, and I don't know if most lang developers are up to that task.
I strongly agree with the approach of making programming more accessible with a simple, deterministic feature set.
https://cucumber.io
"Cucumber lets you write automated tests in plain language."
I wonder if has been integrated with ClaudeCode yet?