6 ms·

What a load of hot air. Reducing the differences between programming languages to their performance/productivity and then claiming the choice is just bikeshedd

by ysleepy 10y ago

What a load of hot air. Reducing the differences between programming languages to their performance/productivity and then claiming the choice is just bikeshedding. Have fun with your ruby pacemaker, js air traffic control and life without static typing in 10mioLOC codebases. Why do I feel like i have to apologize for my negative view on this? He has a commercial interest in maintaining his guru status.

SkyMarshal 10y ago
Was my first thought too. He's judging "workload" by how much time it takes up front to write a program, which may be an important metric for "move fast, break things" social/mobile/local/web apps and the like. But he doesn't mention error rates, maintenance costs, LoC, or any other metric that mission/safety/life critical systems prioritize. The world view underlying this post is one of the reasons for shoddy software and all the breaches, data thefts, etc. that have successfully exploited systems flaws in recent years.
- agentultra 10y ago
  Software doesn't have to be safety critical in order to do harm. Security vulnerabilities, data loss... these all cause harm to the public interest. Whether by snooping, lost profits, online harassment -- these are problems we would be seeing less of if software developers took the view to construct software with fewer errors in the design stage. We simply do not because the practice of writing high-level specifications in the form of mathematical models or proofs is not common. I think the tools have become sophisticated enough and the maths approachable enough that it should be and can be used in the construction of non-safety-critical systems.
- lightcatcher 10y ago
  I also think his upfront time estimates were off. He estimated Ruby to be ~15% more productive than C. I don't write Ruby, but I do write a lot of C and Python. I'd estimate that it takes 5x less time for me to write a program in Python than C. Even if the 5x number is off, it's still a way larger reduction factor than 15%!
kazinator 10y ago
you> Have fun with your ruby pacemaker, js air traffic control and life without static typing in 10mioLOC codebases. Unless I misunderstood the article, the claim which the article works toward is that Ruby and Js do not have an advantage at all, if the compile times for the static alternatives are short (which strongly implies that we shouldn't bother using them). Quote: article> But you said before that Ruby reduces the workload over Java. article> I think it does; but only if the cycle time is long. If the edit/compile/test cycle time is kept very short, then the effect is negligible See? The argument, astonishingly ignorant as it may be, is basically anti-dynamic: the advantage of dynamic is "no compile time", and that's it. Make compile time so fast that you hardly notice it, and the advantage is wiped away.
- Silhouette 10y ago
  The argument, astonishingly ignorant as it may be, is basically anti-dynamic: the advantage of dynamic is "no compile time", and that's it. I think that's more an argument that imperative vs. compiled isn't a significant difference any more. In the modern world of JIT-compiled runtime environments and fast, incremental recompilation, it's actually one of the few points I agreed with in this article. His premise that almost nothing else matters as long as the above is true and all programming languages allow very short write-test cycles is absurd, of course.
  - kazinator 10y ago
    Also, the premise is violated by the article's own observation that higher level compiled languages (slow build time) beat assembly language (lightning fast build time). I.e. there can be differences not linked to fast cycles. Just, please take it on faith, not between Ruby and Java.
- ysleepy 10y ago
  He also reduces their differences to this point. - Which I find most ridiculous. For one thing, interpretation vs. compilation is in the end an implementation issue (see all the AOT compilers and Cerns ROOT/Cling). The advantage is, that you CAN compile moderately statically typed languages, they all can be equivalently and probably more easily than dynamic ones be implemented in an interpreted fashion. But even then, eclipse compiles while editing, and I never have to wait (The only thing I like about eclipse haha ). So the whole article was just written while intoxicated, or he is missing the deeper connections about language features beyond 2kloc ROR CRUD apps, like being able to find out callsites of a function, and being able to make assumptions about others code (which becomes critical in even moderately large codebases).
raverbashing 10y ago
While I don't agree with the text and I'm not a big "static typing fan" you are absolutely right > He has a commercial interest in maintaining his guru status. This. I suspected before clicking that it was a load of hot air, but gave him the benefit of the doubt
- k__ 10y ago
  On the other hand he only compares nominal type systems (C++, Java). Which I found rather cumbersome too. Structural type systems (Go, TypeScript) felt a bit like dynamically typed languages with cheap safety features. Also there are algebraic type systems, which aren't mentioned. Elm seems to eliminate all runtime errors etc.
  - raverbashing 10y ago
    Ah yes, the Go (and Rust type system, I might add) are interesting. They still feel a bit weird to me but it's something useful
- deleted 10y ago
  [deleted]
Silhouette 10y ago
This is also the man who suggested not so long ago that we'd now explored the entire space of possible programming languages and paradigms and there were no more significant improvements to be found. I don't know why people regard Robert Martin as any sort of authority. As far as I can tell, he spends a lot of time telling other people how they should program (often needlessly insulting anyone who doesn't do things his way) yet has neither much hard data nor exceptional personal experience working on software projects of his own to support his positions.

by ysleepy 10y ago

SkyMarshal 10y ago

Was my first thought too. He's judging "workload" by how much time it takes up front to write a program, which may be an important metric for "move fast, break things" social/mobile/local/web apps and the like. But he doesn't mention error rates, maintenance costs, LoC, or any other metric that mission/safety/life critical systems prioritize. The world view underlying this post is one of the reasons for shoddy software and all the breaches, data thefts, etc. that have successfully exploited systems flaws in recent years.

agentultra 10y ago
Software doesn't have to be safety critical in order to do harm. Security vulnerabilities, data loss... these all cause harm to the public interest. Whether by snooping, lost profits, online harassment -- these are problems we would be seeing less of if software developers took the view to construct software with fewer errors in the design stage. We simply do not because the practice of writing high-level specifications in the form of mathematical models or proofs is not common. I think the tools have become sophisticated enough and the maths approachable enough that it should be and can be used in the construction of non-safety-critical systems.
lightcatcher 10y ago
I also think his upfront time estimates were off. He estimated Ruby to be ~15% more productive than C. I don't write Ruby, but I do write a lot of C and Python. I'd estimate that it takes 5x less time for me to write a program in Python than C. Even if the 5x number is off, it's still a way larger reduction factor than 15%!

kazinator 10y ago

you> Have fun with your ruby pacemaker, js air traffic control and life without static typing in 10mioLOC codebases. Unless I misunderstood the article, the claim which the article works toward is that Ruby and Js do not have an advantage at all, if the compile times for the static alternatives are short (which strongly implies that we shouldn't bother using them). Quote: article> But you said before that Ruby reduces the workload over Java. article> I think it does; but only if the cycle time is long. If the edit/compile/test cycle time is kept very short, then the effect is negligible See? The argument, astonishingly ignorant as it may be, is basically anti-dynamic: the advantage of dynamic is "no compile time", and that's it. Make compile time so fast that you hardly notice it, and the advantage is wiped away.

Silhouette 10y ago
The argument, astonishingly ignorant as it may be, is basically anti-dynamic: the advantage of dynamic is "no compile time", and that's it. I think that's more an argument that imperative vs. compiled isn't a significant difference any more. In the modern world of JIT-compiled runtime environments and fast, incremental recompilation, it's actually one of the few points I agreed with in this article. His premise that almost nothing else matters as long as the above is true and all programming languages allow very short write-test cycles is absurd, of course.
- kazinator 10y ago
  Also, the premise is violated by the article's own observation that higher level compiled languages (slow build time) beat assembly language (lightning fast build time). I.e. there can be differences not linked to fast cycles. Just, please take it on faith, not between Ruby and Java.
ysleepy 10y ago
He also reduces their differences to this point. - Which I find most ridiculous. For one thing, interpretation vs. compilation is in the end an implementation issue (see all the AOT compilers and Cerns ROOT/Cling). The advantage is, that you CAN compile moderately statically typed languages, they all can be equivalently and probably more easily than dynamic ones be implemented in an interpreted fashion. But even then, eclipse compiles while editing, and I never have to wait (The only thing I like about eclipse haha ). So the whole article was just written while intoxicated, or he is missing the deeper connections about language features beyond 2kloc ROR CRUD apps, like being able to find out callsites of a function, and being able to make assumptions about others code (which becomes critical in even moderately large codebases).

raverbashing 10y ago

While I don't agree with the text and I'm not a big "static typing fan" you are absolutely right > He has a commercial interest in maintaining his guru status. This. I suspected before clicking that it was a load of hot air, but gave him the benefit of the doubt

k__ 10y ago
On the other hand he only compares nominal type systems (C++, Java). Which I found rather cumbersome too. Structural type systems (Go, TypeScript) felt a bit like dynamically typed languages with cheap safety features. Also there are algebraic type systems, which aren't mentioned. Elm seems to eliminate all runtime errors etc.
- raverbashing 10y ago
  Ah yes, the Go (and Rust type system, I might add) are interesting. They still feel a bit weird to me but it's something useful
deleted 10y ago
[deleted]

Silhouette 10y ago

This is also the man who suggested not so long ago that we'd now explored the entire space of possible programming languages and paradigms and there were no more significant improvements to be found. I don't know why people regard Robert Martin as any sort of authority. As far as I can tell, he spends a lot of time telling other people how they should program (often needlessly insulting anyone who doesn't do things his way) yet has neither much hard data nor exceptional personal experience working on software projects of his own to support his positions.