3 ms·

Sometimes, 25 years ago, a solution to the problem wasn't available. I worked on state-of-the-art systems from 25 years ago. We were writing homegrown streaming

by beat 10y ago

Sometimes, 25 years ago, a solution to the problem wasn't available. I worked on state-of-the-art systems from 25 years ago. We were writing homegrown streaming data protocols over raw sockets, parsed with lex and yacc. We didn't have ssh, we didn't have http, we didn't have xml (much less json). A world-class system from 25 years ago would be scrap today... how many bright young junior programmers today could update a lex/yacc parse stream, or handle socket programming or DOS HIMEM? Improvement needs to be continuous. The ability to update individual parts of the system with minimal coupling is vital. But even keeping that as the system evolves is a challenge - and designing for it in advance leads to all sorts of unnecessary "just in case" abstractions in the code. Keeping code alive and running for a generation is a whole different kind of challenge.

ska 10y ago
I agree on the continuous improvement - i wasn't suggesting you do this once and stop thinking about it. But note, 25 years we didn't have the same solutions we might have today, but we had good solutions to lots of common problems. We certainly had solutions to "system is specified by a mixed bag of ASCII and inconsistent EBCDIC files, none alike, all specified 15 years ago. Which is at the heart of the problem OP posited. 25 years ago people were saying exactly the same thing about banking systems in COBOL that beat describes. Exactly. The batch processing OP discusses had already been out of vogue for a decade at least. We had good solutions for nearly all of these problems, what we didn't have was quick, cheap solutions. Just for completeness: we had html. We'd had SGML for a decade (which begat HTML and later XML). We had reasonable streaming protocols. We were a lot worse at connecting heterogeneous systems controlled by different entities and interoperating, but we good at networking and building distributed systems at a smaller scale. Keeping code alive and running for a generation is a very difficult problem, but keeping systems tidy, modular, and evolving is manageable, until you let them go too much. And people are digging the same holes today. It's not technology that is the cause, it never was. It's cost and short term planning.
aeorgnoieang 10y ago
> how many bright young junior programmers today could update a lex/yacc parse stream, or handle socket programming or DOS HIMEM? Almost all of them – if they're really "bright" anyways. Even given that a lot of the important context is missing, bright programmers can do this stuff.
- ice109 10y ago
  that's disingenuous. anyone can do anything given enough to learn the skills. what OP is asking is how many of today's programmers have the skills already. the answer is very few.
  - beat 10y ago
    Indeed. If someone suggested writing a custom stream parser for something as simple as scanned images today, I'd point them right back at the wide array of off-the-shelf, standardized solutions. Sure, a good programmer can learn this stuff. But they shouldn't have to, not these days. There's far more to programming than any one person could ever learn. Choose your battles.
- ExactoKnight 10y ago
  How many programmers could write a functional machine code? The wrong question is being asked. Modern programming techniques work because they have successfully abstracted this complexity.

by beat 10y ago

ska 10y ago

I agree on the continuous improvement - i wasn't suggesting you do this once and stop thinking about it. But note, 25 years we didn't have the same solutions we might have today, but we had good solutions to lots of common problems. We certainly had solutions to "system is specified by a mixed bag of ASCII and inconsistent EBCDIC files, none alike, all specified 15 years ago. Which is at the heart of the problem OP posited. 25 years ago people were saying exactly the same thing about banking systems in COBOL that beat describes. Exactly. The batch processing OP discusses had already been out of vogue for a decade at least. We had good solutions for nearly all of these problems, what we didn't have was quick, cheap solutions. Just for completeness: we had html. We'd had SGML for a decade (which begat HTML and later XML). We had reasonable streaming protocols. We were a lot worse at connecting heterogeneous systems controlled by different entities and interoperating, but we good at networking and building distributed systems at a smaller scale. Keeping code alive and running for a generation is a very difficult problem, but keeping systems tidy, modular, and evolving is manageable, until you let them go too much. And people are digging the same holes today. It's not technology that is the cause, it never was. It's cost and short term planning.

aeorgnoieang 10y ago

> how many bright young junior programmers today could update a lex/yacc parse stream, or handle socket programming or DOS HIMEM? Almost all of them – if they're really "bright" anyways. Even given that a lot of the important context is missing, bright programmers can do this stuff.

ice109 10y ago
that's disingenuous. anyone can do anything given enough to learn the skills. what OP is asking is how many of today's programmers have the skills already. the answer is very few.
- beat 10y ago
  Indeed. If someone suggested writing a custom stream parser for something as simple as scanned images today, I'd point them right back at the wide array of off-the-shelf, standardized solutions. Sure, a good programmer can learn this stuff. But they shouldn't have to, not these days. There's far more to programming than any one person could ever learn. Choose your battles.
ExactoKnight 10y ago
How many programmers could write a functional machine code? The wrong question is being asked. Modern programming techniques work because they have successfully abstracted this complexity.