25 ms·

Proclaiming that the syntax only causes problems stands in complete defiance of most people's preferences in programming syntax. We like syntax errors because

by chipsy 11y ago

Proclaiming that the syntax only causes problems stands in complete defiance of most people's preferences in programming syntax. We like syntax errors because they mold thoughts more precisely. Going against that is also going against a lot of "productivity enhancers" - we build them because we expect to have a lot of code, and we want to reduce the kinds of errors that it may contain. That doesn't mean that we should abuse them to write as much code as we can, but it does turn out that way in practice. So in an odd way Moore and co are right - we would be more free if we also constrained ourselves more on this point. But the broader thought is that you can apply such constraints at any time, in tandem with what you already like. And that is more likely to produce an innovation than "just Forth".

Guvante 11y ago
I think that needless compiler errors is an interesting point that isn't discussed often, so that at least is an interesting point. We have those productivity enhancers because the language makes it easy to make a mistake there. Ideally we would want to eliminate those mistakes without the syntactic headache. Although obviously how to do that is a complex exercise, I do think that saying "code bloat is bad" even against "bugs are worse" can provide interesting insights into what we really want from languages.
- dietrichepp 11y ago
  It's discussed fairly often with static analyzers. Static analysis is a powerful tool, but false positives erode user confidence in the tool. I've worked with code bases where thousands of warnings (and even several errors) were left in place, which meant that you had to basically ignore all diagnostic messages every time you compiled. At that point, you might as well be 2>/dev/null. Someone even wrote a wrapper script that would diff the stderr against the "known good" stderr. My general impression of that project was that it was dying a slow death unless someone went in and restored developer confidence in the build process, and the most likely person was me :-/

by chipsy 11y ago

Guvante 11y ago

I think that needless compiler errors is an interesting point that isn't discussed often, so that at least is an interesting point. We have those productivity enhancers because the language makes it easy to make a mistake there. Ideally we would want to eliminate those mistakes without the syntactic headache. Although obviously how to do that is a complex exercise, I do think that saying "code bloat is bad" even against "bugs are worse" can provide interesting insights into what we really want from languages.

dietrichepp 11y ago
It's discussed fairly often with static analyzers. Static analysis is a powerful tool, but false positives erode user confidence in the tool. I've worked with code bases where thousands of warnings (and even several errors) were left in place, which meant that you had to basically ignore all diagnostic messages every time you compiled. At that point, you might as well be 2>/dev/null. Someone even wrote a wrapper script that would diff the stderr against the "known good" stderr. My general impression of that project was that it was dying a slow death unless someone went in and restored developer confidence in the build process, and the most likely person was me :-/