3 ms·

I disagree with several of these. But I guess that's why 1) I am working on my own language, and 2) Walter Bright is a lot more successful at that than me. So y

by krig 11y ago

I disagree with several of these. But I guess that's why 1) I am working on my own language, and 2) Walter Bright is a lot more successful at that than me. So yeah. He's probably right, and I'm probably wrong. However: I'm doing this entirely for my own pleasure, and I don't want success as he defines it (popularity means having to cater to the whims of others). Disagreements: I think minimizing keystrokes is important, and I think the notion that code is primarily read, not written, is idealistic but completely wrong. The purpose of programming languages is to be writable by humans and readable by machines. There is value in making them readable by humans and writable by machines, but only secondary value. I think there is value in easy parsing, if nothing else because every single editor out there can highlight your language even if it isn't popular. I think the focus on popularity as the measure of success is wrong. Tried and true is overrated. There are plenty of examples of programming languages that break the tried and true rules and are successful either because of this or despite this. Either way, it doesn't seem to matter as much as people seem to think, but staring too hard at the success of Java might make you think it does. Anyway, feel free to disagree with me, go ahead and design your own language. I sincerely hope you are successful, regardless of what your definition of success is.

deleted 11y ago
[deleted]
kazagistar 11y ago
In practice, writing code consists mostly of reading; either to (re)understand how some other part of a large system works, or to figure out why the code is incorrect.
- PeCaN 11y ago
  I would argue that it's easier to understand short, even excessively terse, code than it is to understand long code. I can look at a few lines of Haskell and even though deciphering it may take me some time, the cognitive overhead of anything other than working out what the code is doing is very low (the most I'd have to do is look up some operators). I can see a significant chunk of logic all at once and piece together the system as a whole. Meanwhile I could look at 3 files full of Java and have no idea what the system is actually doing.

by krig 11y ago

deleted 11y ago

[deleted]

kazagistar 11y ago

In practice, writing code consists mostly of reading; either to (re)understand how some other part of a large system works, or to figure out why the code is incorrect.

PeCaN 11y ago
I would argue that it's easier to understand short, even excessively terse, code than it is to understand long code. I can look at a few lines of Haskell and even though deciphering it may take me some time, the cognitive overhead of anything other than working out what the code is doing is very low (the most I'd have to do is look up some operators). I can see a significant chunk of logic all at once and piece together the system as a whole. Meanwhile I could look at 3 files full of Java and have no idea what the system is actually doing.