4 ms·

We have a lot more layers of abstraction, in the name of productivity. That's certainly more complex, and from a certain point of view, more sophisticated. Mea

We have a lot more layers of abstraction, in the name of productivity. That's certainly more complex, and from a certain point of view, more sophisticated. Meanwhile (I can't be the only one who's noticed this?) it seems like it takes a team 5x as large 2x as long to write a program that does the same thing as some 80s or 90s equivalent. I'm not sure what to make of that.

retrac 5y ago
> it seems like it takes a team 5x as large 2x as long to write a program that does the same thing as some 80s or 90s equivalent. While I can't attest to team performance, I wrote a toy compiler over the long weekend here just now. There were wizards who could do that 30 years ago in a weekend, of course. But I'm not one of them. It occurred to me that if I hadn't used Haskell and some great libraries, built with a compiler that takes hundreds of MB of RAM to run, and was instead using C or assembly even, I'd probably still be trying to get integers parsing correctly. The productivity increase of modern development tools seems real enough to me.
- swiley 5y ago
  I've written parsers in C, you get used to it. It would probably take you as long to write an integer parser in C as it would take me in Haskell.
  - retrac 5y ago
    It's literally two lines, yet it handles hexadecimal and octal too. :) Of course, if you set up some parser combinators with a nice library in C, it could be a one liner in C too. I figure it's not the language, so much as the libraries and tooling around the language. Back in the day, one couldn't stick a term in the project definition, have the compiler automatically download and assemble a library, then invoke it with one line in the program code, all within 10 seconds. You'd have to start with "is this a digit?" and build up from there, like I did back in my CS courses with Pascal, once upon a time.

retrac 5y ago

> it seems like it takes a team 5x as large 2x as long to write a program that does the same thing as some 80s or 90s equivalent. While I can't attest to team performance, I wrote a toy compiler over the long weekend here just now. There were wizards who could do that 30 years ago in a weekend, of course. But I'm not one of them. It occurred to me that if I hadn't used Haskell and some great libraries, built with a compiler that takes hundreds of MB of RAM to run, and was instead using C or assembly even, I'd probably still be trying to get integers parsing correctly. The productivity increase of modern development tools seems real enough to me.

swiley 5y ago
I've written parsers in C, you get used to it. It would probably take you as long to write an integer parser in C as it would take me in Haskell.
- retrac 5y ago
  It's literally two lines, yet it handles hexadecimal and octal too. :) Of course, if you set up some parser combinators with a nice library in C, it could be a one liner in C too. I figure it's not the language, so much as the libraries and tooling around the language. Back in the day, one couldn't stick a term in the project definition, have the compiler automatically download and assemble a library, then invoke it with one line in the program code, all within 10 seconds. You'd have to start with "is this a digit?" and build up from there, like I did back in my CS courses with Pascal, once upon a time.