It's frustrating that innovators are constantly having to justify "why yet another". Folks should just be able to freely innovate without fear of getting spammed with xkcd#927. You wanna make yet another programming language, compiler, JSON-alternative, container format, or trivial FTP+SVN killer, go for it! This is how we innovate.
When people write "why yet another", they usually mean "why this one specifically". And that's the case here, where the author lists what they think are the weaknesses of the state of the art, and explains why they think their innovations help with these problems. Innovation on its own isn't particularly interesting - I want to know why the author is innovating.
> innovators are constantly having to justify ... This is how we innovate
Quite the opposite.
Having to explain the benefits of an idea do not thwart innovation - if anything it promotes it.
The software industry is littered with novelties that have little innovative value other than being the new shiny thing that people want to put on their CV.
Churn is at a historical high.
Providing solid reasons for adopting new technology is a breath of fresh air.
Agreed! Even if the new thing doesn't reach mainstream adoption it might still cause change in the mainstream choices - like how redux was inspired by Elm
Secondly I think it's sad that someone building something will be asked to justify their decision in terms of economics. If it makes that person excited and happy to build a thing then I don't think any further justification is needed
In my experience, people believe that programming languages are a solved space, and we should stick with what we have. It's an unfortunate view.
Languages are actually very polarized today. I think there's a lot of room for a mainstream language that could be safe, fast, and most importantly, easy. Today's languages are generally two out of three.
Luckily, a lot of languages are exploring that space!
* Vale is blending generational references with regions, to have memory-safe single ownership without garbage collection or a borrow checker. [0]
* Cone is adding a borrow checker on top of GC, RC, single ownership, and even custom user allocators. [1]
* Lobster found a way to add borrow-checker-like static analysis to reference counting. [2]
* HVM is using borrowing and cloning under the hood to make pure functional programming ridiculously fast. [3]
* Ante is using lifetime inference and algebraic effects to make programs faster and more flexible. [4]
Languages are not that polarized. Most languages are in fact compromises, design-wise, rather than very principled (polarized). Rust[1] and ATS are the only no-compromise newish (this century) languages that are very principled. (EDIT: in the high-level with low-level control category.)
Being supposedly easier is also easier (design-wise) than being principled, since you are able to compromise on whatever dimension (like e.g. memory safety) as long as you make things just a bit easier than the competition.[2] A language like Rust, on the other hand, has to (1) make Safe Rust memory safe and (2) make make it possible to create Safe Rust APIs using Unsafe Rust.
Polarized design is the road less travelled.
[1] All your examples mention “borrow checker”…
[2] For propaganda purposes, a subjective criteria like “easier to use” (than e.g. Rust, if that is applicable) is better than a technical criteria like being memory safe.
I suppose you could add a few to this list:
Koka has formalised side-effects, and thanks to that can do in-place mutation after static analysis, similar to HVM. It also uses static analysis to manage memory with elided reference counting.
Lastly, koka has managed to utilise static typing with dynamic binding, contrast with cell-lang which avoids dynamic binding (which has it's use cases).
https://koka-lang.github.io/koka/doc/book.html#sec-effect-ty...
Flix does something similar to cell, though the typing is worked out better as lattice types ensure that there is an unambiguous top and bottom type. Addditionally where cell cannot compute dependent values, Flix can as it uses constraint modelling rather than reactive computation ie. the algo computing the rules is formally worked out to cover the edge cases.
https://flix.dev/principles/
Maude handles subtyping and typechecking of said subtypes through equational and rewrite logic. It has the concept of purely functional modules as well as impure (system) modules, but adds to that the math theories that represent the modules, so you get a lot of formal verification techniques at your disposal while programming.
http://maude.cs.illinois.edu/w/index.php/Maude_Overview
Kali makes a good job of migrating processes - where cell restricts the ability to do closures due to the extended value set, kali can walk the call tree to migrate all linked state.
http://community.schemewiki.org/?Kali-Scheme-Revival
I think cell looks interesting, but there seem to be restrictions here to simplify/avoid some of the harder problems. That in itself is not a bad thing, but it's worth noting given that some of these problems have been tackled individually above.
I'm not quite ready with a blend of these techniques, but it looks as though they are compatible with each other.
Mainly reading threads here :)
I make a stab at looking at the top headlines. There's a pattern in a headline eg. Mentions of GC, datalog and so on which I flag.
The exceptions are Composita and Maude. Composita is off the back of Oberon, which is one of the smaller language-based OSes. Maude I found on a keyword search around formal verification- I'm looking to build a new language so interesting stuff keeps coming up when you go down the rabbit holes ;)
I don't see this as a problem. If someone is creating something new they have a reason, something that is motivating them. Explaining these reasons lets others know if the project is something that interests them or not. This is especially important for collaborative projects to attract people whose goals meet your own and who can contribute additional ideas that you wouldn't have thought of without being a distraction because they are trying to pull the project in different direction than you had in mind. It is also important to attract users if that is something you want.
I think the reason for the justification is because in a field like programming where we have so many different languages, if there are any newcomers you'd want to know what sort of gap they have found which existing languages do not fill.
As others have pointed out, there's a difference between creating something just for the experience of it, and creating something because no other similar solutions exist. This project seems to fit in the latter category hence why a justification has been offered.
IMO it’s important to distinguish between projects that are following a well beaten path just to follow it (I.e. writing a toy lisp), and projects that are intentionally trailblazing. If you want to find innovation you want to follow the later projects rather than the former.
I find it valuable that they spelled out their motivations and agenda for creating this language, which will help prospective users to decide whether they need to take this language seriously or not. This helps attract users, and arguably the main value of any language is how well users can interoperate with it.
Folks can freely create anything, but it might be a shame for such efforts to go to something that only few people will use.
