4 ms·

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 spamme

by kortex 4y ago

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.

Scandiravian 4y ago
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
- verdagon 4y ago
  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] * D is adding a borrow checker! [5] [0] https://vale.dev/ https://vale.dev/ [1] https://cone.jondgoodwin.com/ https://cone.jondgoodwin.com/ [2] https://www.strlen.com/lobster/ https://www.strlen.com/lobster/ [3] https://github.com/Kindelia/HVM https://github.com/Kindelia/HVM [4] https://antelang.org/ https://antelang.org/ [5] https://dlang.org/blog/2022/06/21/dip1000-memory-safety-in-a-modern-system-programming-language-pt-1/ https://dlang.org/blog/2022/06/21/dip1000-memory-safety-in-a...
  - alexisread 4y ago
    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-types 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/ 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 http://maude.cs.illinois.edu/w/index.php/Maude_Overview Composita covers the idea of removing pointers, and restricting components so you can use concurrency in anger (and managed memory without GC at the component level) https://concurrency.ch/Content/publications/Blaeser_Component_Operating_System_PLOS_2007.pdf https://concurrency.ch/Content/publications/Blaeser_Componen... 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 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.
    - verdagon 4y ago
      Wow, I've never heard of most of these languages, and I consider myself a language expert! How did you learn of these?
goodpoint 4y ago
> 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.
culturedsystems 4y ago
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.
- keithalewis 4y ago
  My Bayesian priors want to know more about the author.
ModernMech 4y ago
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.
thejammahimself 4y ago
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.
pavon 4y ago
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. Its not justification, it is just communication.
omoikane 4y ago
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.

by kortex 4y ago

Scandiravian 4y ago

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

verdagon 4y ago
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] * D is adding a borrow checker! [5] [0] https://vale.dev/ https://vale.dev/ [1] https://cone.jondgoodwin.com/ https://cone.jondgoodwin.com/ [2] https://www.strlen.com/lobster/ https://www.strlen.com/lobster/ [3] https://github.com/Kindelia/HVM https://github.com/Kindelia/HVM [4] https://antelang.org/ https://antelang.org/ [5] https://dlang.org/blog/2022/06/21/dip1000-memory-safety-in-a-modern-system-programming-language-pt-1/ https://dlang.org/blog/2022/06/21/dip1000-memory-safety-in-a...
- alexisread 4y ago
  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-types 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/ 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 http://maude.cs.illinois.edu/w/index.php/Maude_Overview Composita covers the idea of removing pointers, and restricting components so you can use concurrency in anger (and managed memory without GC at the component level) https://concurrency.ch/Content/publications/Blaeser_Component_Operating_System_PLOS_2007.pdf https://concurrency.ch/Content/publications/Blaeser_Componen... 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 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.
  - verdagon 4y ago
    Wow, I've never heard of most of these languages, and I consider myself a language expert! How did you learn of these?

goodpoint 4y ago

> 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.

culturedsystems 4y ago

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.

keithalewis 4y ago
My Bayesian priors want to know more about the author.

ModernMech 4y ago

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.

thejammahimself 4y ago

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.

pavon 4y ago

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. Its not justification, it is just communication.

omoikane 4y ago

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.