4 ms·

You could get all the features of Rust by just taking features from an ML-family language and adding some low level memory manipulation capabilities, plus the t

by nnq 7y ago

You could get all the features of Rust by just taking features from an ML-family language and adding some low level memory manipulation capabilities, plus the theoretical work on lifetimes and all. It wouldn't "look like C" but it would be the same things. You could get to any modern dynamic optionally typed language by just starting from Common Lisp, dropping the s-expressions and macros, and replacing default datatypes with something saner and easier to learn/teach. There's a huuuuge bunch of intermediate steps that could've just been skipped. Maybe C isn't one of them, it was inevitable - of you wanted a portable higher assembler usable on 80s computers you could've only invented something like C. But Go, D, Julia etc. only repackaged existing knowledge...

Strom 7y ago
> But Go, D, Julia etc. only repackaged existing knowledge... Sure but you could also say that Google (the search engine) only repackages existing knowledge. Not much different from that famous HN comment [1] which says yould could use FTP & CVS instead of dropbox. If we take Go as an example, sure code style guidelines were old news when Go came out, yet gofmt is still considered one of the best features of the language, because it removes bikeshedding and dictates the one true standard. In other words, like in cooking, it's not so much about the ingredients but how you package them. -- [1] https://news.ycombinator.com/item?id=9224 https://news.ycombinator.com/item?id=9224
ddragon 7y ago
I don't know if any language can exist solely as repackaged knowledge. Sure, a language can very well start that way, but you now have n features that need to be integrated with each other in a still unknown way, which brings new challenges and new knowledge. And no language is static and no technique is completely generic, so any complex software will have issues that will need custom solutions that will again lead to the creation of new knowledge. For example Julia didn't invent multiple dispatch, but it's intention to use it to high performance numeric computing meant different constraints from Dylan or CL, which led to the creation of it's own unique paradigm around type specialization and promotion to make it work. But eventually people had troubles with extremely complex dispatch rules, so, thanks to the language also having repackaged the Lisp knowledge in itself, the language designers were able to create a unique macro to make dispatch rules turing complete (generated functions). And then people realized it could be used for source to source manipulation, for example in the state of the art ML project Zygote. You'll certainly find many examples like that in any minimally ambitious language.
pkroll 7y ago
"There's a huuuuge bunch of intermediate steps that could've just been skipped." Except they couldn't have just been skipped. In retrospect? Maybe. But I suspect we'll see another several thousand languages in the next 20-30 years, most of which will be very, very much like what came before, and a very few that ultimately matter. I don't think there's any way around that except in hindsight.

by nnq 7y ago

Strom 7y ago

> But Go, D, Julia etc. only repackaged existing knowledge... Sure but you could also say that Google (the search engine) only repackages existing knowledge. Not much different from that famous HN comment [1] which says yould could use FTP & CVS instead of dropbox. If we take Go as an example, sure code style guidelines were old news when Go came out, yet gofmt is still considered one of the best features of the language, because it removes bikeshedding and dictates the one true standard. In other words, like in cooking, it's not so much about the ingredients but how you package them. -- [1] https://news.ycombinator.com/item?id=9224 https://news.ycombinator.com/item?id=9224

ddragon 7y ago

I don't know if any language can exist solely as repackaged knowledge. Sure, a language can very well start that way, but you now have n features that need to be integrated with each other in a still unknown way, which brings new challenges and new knowledge. And no language is static and no technique is completely generic, so any complex software will have issues that will need custom solutions that will again lead to the creation of new knowledge. For example Julia didn't invent multiple dispatch, but it's intention to use it to high performance numeric computing meant different constraints from Dylan or CL, which led to the creation of it's own unique paradigm around type specialization and promotion to make it work. But eventually people had troubles with extremely complex dispatch rules, so, thanks to the language also having repackaged the Lisp knowledge in itself, the language designers were able to create a unique macro to make dispatch rules turing complete (generated functions). And then people realized it could be used for source to source manipulation, for example in the state of the art ML project Zygote. You'll certainly find many examples like that in any minimally ambitious language.

pkroll 7y ago

"There's a huuuuge bunch of intermediate steps that could've just been skipped." Except they couldn't have just been skipped. In retrospect? Maybe. But I suspect we'll see another several thousand languages in the next 20-30 years, most of which will be very, very much like what came before, and a very few that ultimately matter. I don't think there's any way around that except in hindsight.