|
> So how do software engineers manage all that? They use better languages than assembly. Well, better languages than assembly, yes, but the situation is not so simple. In the past 40 years or so in the software industry, there were two, and exactly two, language-related major productivity leaps in the production of "serious" software: C and Java. Java didn't add too much in expressivity over C (in fact, it added less than C++ had), and neither did C add a lot of expressivity over assembly (more convenient syntax but not too many new abstractions) -- but both added a lot in terms of safety, modularity, portability and the like. The problem is that we haven't been able to make yet another significant jump. Much of current PL research focuses on expressivity and proof of correctness -- two things that aren't the really painful problems for the software industry these days, and aren't what made C and Java such productivity boosters, either. In both cases, productivity was enhanced not through some clever language syntax design, but through the ecosystem the language supported (i.e. extra-linguistic features). Yes, some other languages like Ruby added some productivity benefits, but mostly in the "toy" application department -- the same kind of applications people used to use MS Access or VB for, or other "application generators" prior to those -- and you see Ruby shops transitioning to Java as they become "serious". The thing is that with modern hardware, even toy software projects are quite usable, but this isn't the case with hardware design. |
Anyway, yes I agree the ecosystem is key. This is why a lot of new languages are either running on the JVM (like Clojure and Scala) or are interoperable with C (like Rust and Nim). In other cases, languages have managed to create an entire ecosystem very rapidly (Node.js and Javascript in general, Ruby and others).
> The thing is that with modern hardware, even toy software projects are quite usable
You're right. I must admit I'm not a big fan of this "throw more at the problem" approach, and I wonder for how long this approach will work. After all, Moore's law is slowing down, as the unit cost per transistor has stopped decreasing after 28nm.
> but this isn't the case with hardware design.
Yes, for one because if you design hardware that is sub-optimal, in other words that requires more transistors, that translates into higher costs, and lower margins. That's some powerful incentive IMO. Not to mention that if the hardware is not powerful enough, the toy software projects that you mention will have trouble running ^^
Therefore I think a central question is the loss of performance compared to the gain in productivity. A naive translation of C to assembly leads to disastrous performance. For years (decades?) people had to resort to assembly for speed-critical routines, and you can still find assembly in video decoders for instance. But the productivity is so much higher than the loss of performance is acceptable.