I really like Fexl ( https://github.com/chkoreff/Fexl ) but I'm not sure it's quite what I want. Not quite data-friendly enough? It's doing very good things with syntax though - I love the ; for list pivot. Very very useful - it makes all the difference between "parenthesis spaghetti" and "actually readable code". PicoLisp can do something similar.
PicoLisp, Retro Forth, Fexl, Dialog, and maybe Red seem like a handful of languages that "get" the idea of radical simplicity. But there's room for more.
I'm reasoning about this topic too.
I was wondering how to teach #Jehanne to my daughters (it's pretty simple compared to other OS) but it's still full of arcane words, with ugly syntax and weird semantics.
I'm pretty sure we should know better: what wrong assumptions arr poisoning the future of computing?
(Yeah, capitalism apart...)
Why we cannot even think simpler languages (and systems) without so much glibberish?
All programming languages use weird syntax, one way or another, to "maximize programmer productivity" (for some definition of it, if any) with multiple equivalent ways to express a computation.
All use complex type systems (as system F and derivatives) that most people cannot really understand.
Or they use complex runtime rules to counter-balance the lack of any type system.
All scripting languages use different syntaxes, all use different data format (converging to json, that sucks in many ways...), all have different command line switches...
We can do better for sure!
It is a hard problem for sure. It is super easy to add complexity to systems - just put two systems that can interact next to each other and instantly you have a combinatorial complexity explosion. Then add a third system to patch up the edge cases and whoops, another combinatorial explosion.
It is super hard to remove complexity and still have a working system. But the less complexity at the base, I'm sure is better.
I really like the Jehanne motto: "You just have to make it both simpler and more useful."
I think that's at the heart of simplicity. Usually complexity arises because the core system wasn't quite useful enough, so we keep layering systems on top.
But also, often that core system wasn't useful enough because it wasn't simple enough - it added extra things that blocked things people needed to do.
If we fix the core, sometimes we can vanish multiple levels of complexity at once.
I'd say that most of current day software complexity is unneeded but it's always either accidental or actively pursued to gain one sort of artificial and undue power over people (reduced to "users") or another.
But both accidental and pursued complexity usually stem from underlying systems (hardware included) that do not provide orthogonal abstractions to build upon.
Imagine if you had to define circles on a plane but with non-orthogonal axes.
The simple x²+y²=r² would not work anymore and you'd have to invent the weirdest tricks to get a formula that works.
And anything you'd have to build on top of such formula would be even more complex.
So the pursuit for simplicity is first and foremost a pursuit for orthogonal axes that can effectively describe any computation (a space that is way more complex than a plane) in the simplest (but exahustive) possible way.
That was what I was looking with #Jehanne, but I'm still unhappy of it.
Not just because of the lack of time to work on it or because of plain (but very expensive) errors like GCC.
It's still too complex and arcane. 😥
