This is kind of accurate and funny, but also feels a bit like criticizing the drawing of a 4-year-old kid. :) At least when a language is just someone's hobby project, or some exploration in research.
Programming Language Checklist (2011)
11–20 of 22 posts
Re: Programming Language Checklist (2011)
#12Slashdot answer. Like this one: https://tech.slashdot.org/comments.pl?sid=218300&cid=1771910...
Love these responses.
Re: Programming Language Checklist (2011)
#13This is kind of accurate and funny, but also feels a bit like criticizing the drawing of a 4-year-old kid. :) At least when a language is just someone's hobby project, or some exploration in research.
Isn't this criticizing the discussion of (new) programming languages, not the new languages themselves?
Re: Programming Language Checklist (2011)
#14This is kind of accurate and funny, but also feels a bit like criticizing the drawing of a 4-year-old kid. :) At least when a language is just someone's hobby project, or some exploration in research.
Isn't this criticizing the discussion of (new) programming languages, not the new languages themselves?
Ah, maybe.
FWIW, I actually think syntax is sometimes the hard part about programming, especially when not working with a language frequently. I never worked much with C++, but occasionally come across it. Whenever this happens, it feels like things could be more readable, but maybe I'm biased.
Re: Programming Language Checklist (2011)
#15imv, we're still missing a C replacement-successor There should be a language about as simple as c, with a few additional keywords for safety (type and memory), and a modern standard library -- that works basically everywhere C works, and is backwards compatible with C. ie., we're missing --C++ I think all the supposed successors have approached the problem from the lang-design pov, where for C, it needs to be from-e…
You may find Zig interesting: https://ziglang.org . The language is not C compatible but the tooling can compile C and C++ without hassle.
i'm aware of zig, which is why i included the criteria above that i take to rule it out.
i do think the successor should be src-compt with C
Re: Programming Language Checklist (2011)
#16imv, we're still missing a C replacement-successor There should be a language about as simple as c, with a few additional keywords for safety (type and memory), and a modern standard library -- that works basically everywhere C works, and is backwards compatible with C. ie., we're missing --C++ I think all the supposed successors have approached the problem from the lang-design pov, where for C, it needs to be from-e…
Carbon was a possible successor, only time will tell
Re: Programming Language Checklist (2011)
#17I often wonder what it is about the programmer mindset/psychology that curses such constant reinvention(/reinvention?). Is this an unavoidable side effect of Moore's law? Will we settle on just a few languages in the future? Will llms allow easy translation from less popular languages?
Re: Programming Language Checklist (2011)
#18imv, we're still missing a C replacement-successor There should be a language about as simple as c, with a few additional keywords for safety (type and memory), and a modern standard library -- that works basically everywhere C works, and is backwards compatible with C. ie., we're missing --C++ I think all the supposed successors have approached the problem from the lang-design pov, where for C, it needs to be from-e…
Zig, Odin and Jai are the main contenders.
I don’t think backward C compatibility is a good idea, since the C syntax has issues. Instead a transpilation tool from C could be built.
Re: Programming Language Checklist (2011)
#19To me what’s missing is a functional programming language that is statically typed and has an extreme emphasis on performance. C++ meets Haskell, but not terrible.
Re: Programming Language Checklist (2011)
#20To me what’s missing is a functional programming language that is statically typed and has an extreme emphasis on performance. C++ meets Haskell, but not terrible.
That is OCaml. Not that I claim OCaml is extremely fast, but it has a very predictable performance. Which is imho even more important than being the fastest in certain benchmark problems.