8 ms·

This post is a great oversimplification. Normally something like that could be ignored to get the bigger point across, but it kinda is the point, so I call BS.

This post is a great oversimplification. Normally something like that could be ignored to get the bigger point across, but it kinda is the point, so I call BS. Have 10000 experienced ruby programmers and 10000 experienced java programmers solve different tasks. I'm pretty sure that rubyists are going to solve their problems using 50% less time with at least 30% less LOC just by the virtue of having a more expressive language. Now I'm not trying to argue that ruby is strictly better than java, I know both languages' deficiencies. However, the metric author uses is development time, and by that metric more expressive languages will always win, hands down.

kordless 10y ago
There's no BS to call here. The point of the post is to show diminishing returns are occurring with ever evolving languages. The argument one should use X language because you can develop in it faster is increasingly not useful to discuss. You are stuck in the weeds arguing X will always win, when the point is there's nothing to win.
- xentronium 10y ago
  I disagree. Many programming languages are here just because they're good enough, not because they are perfect. For example, C is a good enough systems language. However, when compared to Rust, it's worse at most important criteria, including being more error-prone and less expressive (it's absurdly simple, though). Now you say there's nothing to win, but to me the advantages are obvious: I can avoid several classes of critical vulnerabilities and at the same time not substantially lose any performance. How would that be possible without search for the holy language grail?
  - adwn 10y ago
    > it's absurdly simple, though C is only "absurdly simple" as long as you don't touch undefined behavior, which is nearly impossible in non-trivial programs.
pka 10y ago
And now have those 10k programmers work on a single project. I bet the 10000 Ruby guys are gonna create a big, unmaintainable, broken mess. Even Java's primitive type system would be a big help when it's about software development at scale. Yes yes, TDD :)
- twblalock 10y ago
  This is a big advantage of static typing that people miss -- the restrictions it puts on developers help them to learn the codebase they are working with. In the real world, where engineers contribute to existing codebases more often than they start projects from scratch, this is a pretty important benefit.
  - majewsky 10y ago
    A thousand times this. When I was assigned to an existing Ruby on Rails project of about 30 kLOC, I needed around a month to get productive because it was nearly impossible to follow calls around the system because of auto-generated, not properly typed methods all over the place.
- krisdol 10y ago
  I felt like I spent roughly the same amount of time working around Java's type system with copious amounts of boilerplate as I did fixing wrapping my head around type-related bugs in ruby, especially at scale because of how inflexible every Java architecture seems to become after 5 years. Java's types give you so, so little additional real world "safety" but easily require 10x the verbosity to express the same logic as a dynamic language. You still end up getting hit with null pointers and invalid argument errors. I think Rust and Swift and Elm strike the right balance between developer productivity and a strict type system that actually improves the quality of production software.
  - twblalock 10y ago
    > You still end up getting hit with null pointers and invalid argument errors. Those are not the kinds of problems a type system is intended to solve. Those are problems of data, not of types. The amount of boilerplate in a Java program is pretty low if you aren't trying to abuse or work around the type system. It certainly is not 10x what you end up with in Ruby or Python. Java 8 has made significant improvements, but it wasn't that bad before in many cases. Instead of trying to work around Java's type safety, you should learn to use it properly. Good programmers think about types whether or not they are forced to by the language, so the restrictions imposed by Java should not be burdensome -- in general, you should already be mentally applying some of those restrictions to your code so you can avoid passing the wrong types around.
adrianN 10y ago
You make a compelling argument, but I'm not totally convinced. I think for many real world problems, writing the actual program is not the hard part, it's understanding the requirements and managing changing requirements. I'm not sure that a more expressive language is necessarily better here. Boring code that is easy to understand but twice as long is sometimes better than an elegant solution with fewer lines.
- xentronium 10y ago
  Expressive does not always mean "unnecessary clever", having less boilerplate is enormous advantage by itself. Consider that java until very recently didn't even have lambda expressions. You might say: but IDEs help with boilerplate! True to a point. Someone still has to sift through the tons of unnecessary generated LOC crap just to get to the issue at hand. Again, I'm not writing this to bash on java, I'm simply trying to show that search for "holy grail of programming languages" is far from fruitless, and it fills me with joy when I see more languages being developed and tried in different niches (clojure, rust, go, elixir — these are all different and awesome at the same time).
  - TeMPOraL 10y ago
    > You might say: but IDEs help with boilerplate! True to a point. Someone still has to sift through the tons of unnecessary generated LOC crap just to get to the issue at hand. Yeah. IDEs may help with writing boilerplate, but most of the time you're not writing code - you're reading it. And every small bit of boilerplate Java adds pretty much everywhere (and C++, and C#, and other similar languages) is a bit you have to read, parse and decide if it's relevant. It obscures the meaning the code was supposed to express and make understanding the code a much more cognitively demanding task. (IDEs could help by detecting and folding boilerplate, but if they could do that, then why not just write your code in that folded-boilerplate language directly?)
- novembermike 10y ago
  The problem is that Java code tends to be both boring and hard to understand. More lines of code doesn't make something more clear.
mikkom 10y ago
> Have 10000 experienced ruby programmers and 10000 experienced java programmers solve different tasks. I'm pretty sure that rubyists are going to solve their problems using 50% less time with at least 30% less LOC just by the virtue of having a more expressive language And the solution is goint to be at least 10x slower than the java one.
- nhumrich 10y ago
  > And the solution is going to be at least 10x slower than the java one. Even if that was true (there are many ways to make ruby/python faster), who cares? Hardware is like 1/100 of the cost of an engineer. Use more/better hardware, and problem solved. Optimize for your most expensive resource. Sure maybe 20 years ago that was processing time, but now in days your end user can't tell the difference. I mean does 10ms really feel any different from 100ms? Not really. (OK, there are some times when processing time DOES matter, but that's the exception, not the rule. No premature optimization please)
- informatimago 10y ago
  Do the same with 10000 experienced Common Lisp programmers, and the solution will be 70% less time, 70% less LoC, and will be 10x FASTER than the java one (since there are CL native compilers that attain the same efficiency as C or C++ compilers).
twblalock 10y ago
> However, the metric author uses is development time, and by that metric more expressive languages will always win, hands down. Fair enough, but development time is a small factor in the life of an important project. If you want to prototype and get your minimum viable product out the door, go ahead and use dynamic languages. You'll probably end up rewriting it later, but that's a tradeoff you have to weigh. It's a viable approach taken by many startups. On the other hand, if you are working on a project that will live for years, you will be more concerned about maintainability, adaptability to changing requirements, interaction with other services, quality tooling, and runtime speed than you will about the time it takes to write the first release version.
edwinnathaniel 10y ago
Not if that language is JavaScript. I work with 200+ other developers using JavaScript (90% codebase approximately) on daily base developing a SaaS product...

kordless 10y ago

There's no BS to call here. The point of the post is to show diminishing returns are occurring with ever evolving languages. The argument one should use X language because you can develop in it faster is increasingly not useful to discuss. You are stuck in the weeds arguing X will always win, when the point is there's nothing to win.

xentronium 10y ago
I disagree. Many programming languages are here just because they're good enough, not because they are perfect. For example, C is a good enough systems language. However, when compared to Rust, it's worse at most important criteria, including being more error-prone and less expressive (it's absurdly simple, though). Now you say there's nothing to win, but to me the advantages are obvious: I can avoid several classes of critical vulnerabilities and at the same time not substantially lose any performance. How would that be possible without search for the holy language grail?
- adwn 10y ago
  > it's absurdly simple, though C is only "absurdly simple" as long as you don't touch undefined behavior, which is nearly impossible in non-trivial programs.

pka 10y ago

And now have those 10k programmers work on a single project. I bet the 10000 Ruby guys are gonna create a big, unmaintainable, broken mess. Even Java's primitive type system would be a big help when it's about software development at scale. Yes yes, TDD :)

twblalock 10y ago
This is a big advantage of static typing that people miss -- the restrictions it puts on developers help them to learn the codebase they are working with. In the real world, where engineers contribute to existing codebases more often than they start projects from scratch, this is a pretty important benefit.
- majewsky 10y ago
  A thousand times this. When I was assigned to an existing Ruby on Rails project of about 30 kLOC, I needed around a month to get productive because it was nearly impossible to follow calls around the system because of auto-generated, not properly typed methods all over the place.
krisdol 10y ago
I felt like I spent roughly the same amount of time working around Java's type system with copious amounts of boilerplate as I did fixing wrapping my head around type-related bugs in ruby, especially at scale because of how inflexible every Java architecture seems to become after 5 years. Java's types give you so, so little additional real world "safety" but easily require 10x the verbosity to express the same logic as a dynamic language. You still end up getting hit with null pointers and invalid argument errors. I think Rust and Swift and Elm strike the right balance between developer productivity and a strict type system that actually improves the quality of production software.
- twblalock 10y ago
  > You still end up getting hit with null pointers and invalid argument errors. Those are not the kinds of problems a type system is intended to solve. Those are problems of data, not of types. The amount of boilerplate in a Java program is pretty low if you aren't trying to abuse or work around the type system. It certainly is not 10x what you end up with in Ruby or Python. Java 8 has made significant improvements, but it wasn't that bad before in many cases. Instead of trying to work around Java's type safety, you should learn to use it properly. Good programmers think about types whether or not they are forced to by the language, so the restrictions imposed by Java should not be burdensome -- in general, you should already be mentally applying some of those restrictions to your code so you can avoid passing the wrong types around.

adrianN 10y ago

You make a compelling argument, but I'm not totally convinced. I think for many real world problems, writing the actual program is not the hard part, it's understanding the requirements and managing changing requirements. I'm not sure that a more expressive language is necessarily better here. Boring code that is easy to understand but twice as long is sometimes better than an elegant solution with fewer lines.

xentronium 10y ago
Expressive does not always mean "unnecessary clever", having less boilerplate is enormous advantage by itself. Consider that java until very recently didn't even have lambda expressions. You might say: but IDEs help with boilerplate! True to a point. Someone still has to sift through the tons of unnecessary generated LOC crap just to get to the issue at hand. Again, I'm not writing this to bash on java, I'm simply trying to show that search for "holy grail of programming languages" is far from fruitless, and it fills me with joy when I see more languages being developed and tried in different niches (clojure, rust, go, elixir — these are all different and awesome at the same time).
- TeMPOraL 10y ago
  > You might say: but IDEs help with boilerplate! True to a point. Someone still has to sift through the tons of unnecessary generated LOC crap just to get to the issue at hand. Yeah. IDEs may help with writing boilerplate, but most of the time you're not writing code - you're reading it. And every small bit of boilerplate Java adds pretty much everywhere (and C++, and C#, and other similar languages) is a bit you have to read, parse and decide if it's relevant. It obscures the meaning the code was supposed to express and make understanding the code a much more cognitively demanding task. (IDEs could help by detecting and folding boilerplate, but if they could do that, then why not just write your code in that folded-boilerplate language directly?)
novembermike 10y ago
The problem is that Java code tends to be both boring and hard to understand. More lines of code doesn't make something more clear.

mikkom 10y ago

> Have 10000 experienced ruby programmers and 10000 experienced java programmers solve different tasks. I'm pretty sure that rubyists are going to solve their problems using 50% less time with at least 30% less LOC just by the virtue of having a more expressive language And the solution is goint to be at least 10x slower than the java one.

nhumrich 10y ago
> And the solution is going to be at least 10x slower than the java one. Even if that was true (there are many ways to make ruby/python faster), who cares? Hardware is like 1/100 of the cost of an engineer. Use more/better hardware, and problem solved. Optimize for your most expensive resource. Sure maybe 20 years ago that was processing time, but now in days your end user can't tell the difference. I mean does 10ms really feel any different from 100ms? Not really. (OK, there are some times when processing time DOES matter, but that's the exception, not the rule. No premature optimization please)
informatimago 10y ago
Do the same with 10000 experienced Common Lisp programmers, and the solution will be 70% less time, 70% less LoC, and will be 10x FASTER than the java one (since there are CL native compilers that attain the same efficiency as C or C++ compilers).

twblalock 10y ago

> However, the metric author uses is development time, and by that metric more expressive languages will always win, hands down. Fair enough, but development time is a small factor in the life of an important project. If you want to prototype and get your minimum viable product out the door, go ahead and use dynamic languages. You'll probably end up rewriting it later, but that's a tradeoff you have to weigh. It's a viable approach taken by many startups. On the other hand, if you are working on a project that will live for years, you will be more concerned about maintainability, adaptability to changing requirements, interaction with other services, quality tooling, and runtime speed than you will about the time it takes to write the first release version.

edwinnathaniel 10y ago

Not if that language is JavaScript. I work with 200+ other developers using JavaScript (90% codebase approximately) on daily base developing a SaaS product...