3 ms·

The thing that the author of this rant and every other rant like it don't understand is that computer science is hard. While tools like functional programming

by tensor 15y ago

The thing that the author of this rant and every other rant like it don't understand is that computer science is hard. While tools like functional programming may indeed deliver on the promise of a 60% code reduction, they have a correspondingly higher barrier to learning. Evolving algorithms? Automatic programming? These problems become theoretically intractable so quickly it's not even funny (I currently do research on a very related problem). He wants compilers to just insert the semicolon for him? I'm glad mechanical engineers of the world don't have the same attitude about nails and screws! Most of his complaints in truth have nothing to do with computer science at all. They have everything to do with sloppy engineering. There are all sorts of obvious reasons why computer engineering is sloppy. A few examples: 1) Developers for open source project usually are not paid. It's not surprising that documentation is weak. 2) Reliability and turn-key operation are expensive to develop and nobody wants to pay. I'm sure the author of the article doesn't either. 3) Bugs have lower impact. Screw up a building foundation and you might end up in jail. A clunky install process? Probably all that will happen is a scolding and a new issue in the tracker. 4) Things change so fast that standards can't keep up. The same goes for most other engineering frameworks that would solve many of the problems Morris complains about. We've made and continue to make huge progress in the field of computer science. Computers have and continue to replace people in jobs all over the world. Morris should be happy they haven't replaced his job yet. Not working may sound nice, but having an income is also nice. That has nothing to do with computers. Computers have made our lives easier. If I went back 10 years and told my younger self what I can do today with just my mobile phone, I doubt my younger self would even believe me. The problem is not that progress is bad. It's that progress is moving too fast for engineering to keep up with. The state of the art is constantly changing.

loup-vaillant 15y ago
> While tools like functional programming may indeed deliver on the promise of a 60% code reduction,[…] Most code is badly written C++ that could have been written in, say, Ocaml, Haskell, or Lisp. This is easily a 10 fold reduction. And the guys at http://vpri.org/ http://vpri.org/ are doing at least five times better than that (50 fold reduction compared to well written C). On your point 3, Bugs have lower accountability. Meaning, lower impact for those who commit them. If they have lower impact as well, that's because they forced us to distrust software.
- loup-vaillant 15y ago
  (The downvote suggest I may have to clarify my statement. I suppose unqualified bashing isn't exactly a good idea.) By the LOC count of currently maintained projects, most code is definitely badly written, and in a low-level or otherwise unsuitable language such as C++ (C++ is fast, but most of the time we shouldn't even care.) Most code I see (beware selection bias) is indeed badly written C++ (I even authored some of it). Now, if you count by project times end-user popularity, then you have a completely different story. It is a poor proxy for programmer's work quantity, however. Regarding the 10 fold reduction, just know that I experienced first hand 5 fold reductions when doing my best with C++ and Ocaml respectively. A 10 fold reduction is not unrealistic at all when we talk about badly written C++. For instance… …I currently write plugin for a 2 million-lines program. The exposed interface alone weights 80,000 lines. Many classes have hundreds of methods, and the inheritance hierarchy is generally 5 levels deep, sometimes up to 8 or 9. And, it actively deals with no less than 6 different types for handling strings (std::string, char* , old Pascal strings of 3 different types, and some String type that inherits std::string). Oh, and it's slow. C++ didn't even help here. We are past the point where we can talk about technical debt: it's a Big Ball of Mud. For such a program, I expect a 20 fold reduction. And I bet there are other Chtulu abominations out there that make look this program like a little diamond.
perfunctory 15y ago
> He wants compilers to just insert the semicolon for him? I'm glad mechanical engineers of the world don't have the same attitude about nails and screws! Yes! I guess we could learn a lot from other engineering disciplines.
groovy2shoes 15y ago
Semicolons in a grammar are nothing like nails or screws. Nails and screws hold things together. The vast majority of the time, semicolons in code are only visual indicators of the end of a statement; another perfectly good visual indicator is a newline. Many languages that require semicolons could (with minor modifications to the grammar) be cleanly parsed without any sort of statement terminator. See the Lua grammar for an example: http://www.lua.org/manual/5.1/manual.html#8 http://www.lua.org/manual/5.1/manual.html#8

by tensor 15y ago

loup-vaillant 15y ago

> While tools like functional programming may indeed deliver on the promise of a 60% code reduction,[…] Most code is badly written C++ that could have been written in, say, Ocaml, Haskell, or Lisp. This is easily a 10 fold reduction. And the guys at http://vpri.org/ http://vpri.org/ are doing at least five times better than that (50 fold reduction compared to well written C). On your point 3, Bugs have lower accountability. Meaning, lower impact for those who commit them. If they have lower impact as well, that's because they forced us to distrust software.

loup-vaillant 15y ago
(The downvote suggest I may have to clarify my statement. I suppose unqualified bashing isn't exactly a good idea.) By the LOC count of currently maintained projects, most code is definitely badly written, and in a low-level or otherwise unsuitable language such as C++ (C++ is fast, but most of the time we shouldn't even care.) Most code I see (beware selection bias) is indeed badly written C++ (I even authored some of it). Now, if you count by project times end-user popularity, then you have a completely different story. It is a poor proxy for programmer's work quantity, however. Regarding the 10 fold reduction, just know that I experienced first hand 5 fold reductions when doing my best with C++ and Ocaml respectively. A 10 fold reduction is not unrealistic at all when we talk about badly written C++. For instance… …I currently write plugin for a 2 million-lines program. The exposed interface alone weights 80,000 lines. Many classes have hundreds of methods, and the inheritance hierarchy is generally 5 levels deep, sometimes up to 8 or 9. And, it actively deals with no less than 6 different types for handling strings (std::string, char* , old Pascal strings of 3 different types, and some String type that inherits std::string). Oh, and it's slow. C++ didn't even help here. We are past the point where we can talk about technical debt: it's a Big Ball of Mud. For such a program, I expect a 20 fold reduction. And I bet there are other Chtulu abominations out there that make look this program like a little diamond.

perfunctory 15y ago

> He wants compilers to just insert the semicolon for him? I'm glad mechanical engineers of the world don't have the same attitude about nails and screws! Yes! I guess we could learn a lot from other engineering disciplines.

groovy2shoes 15y ago

Semicolons in a grammar are nothing like nails or screws. Nails and screws hold things together. The vast majority of the time, semicolons in code are only visual indicators of the end of a statement; another perfectly good visual indicator is a newline. Many languages that require semicolons could (with minor modifications to the grammar) be cleanly parsed without any sort of statement terminator. See the Lua grammar for an example: http://www.lua.org/manual/5.1/manual.html#8 http://www.lua.org/manual/5.1/manual.html#8