4 ms·

But if you could learn some things from the history and use that to your advantage, why wouldn't you? Everyone would be doing so. And yet somehow it doesn't wor

by zzzcpan 10y ago

But if you could learn some things from the history and use that to your advantage, why wouldn't you? Everyone would be doing so. And yet somehow it doesn't work like that, outdated things are in fact outdated and you can only take away very little from them. Things that were designed with trade offs for very expensive slow synchronous machines during the times when programmers were not bound to languages, because everyone had to develop everything from scratch, don't really make much sense today. Direct experience of the last decade is a lot more relevant with a lot more lessons to learn that were never even on the radar in the past.

barrkel 10y ago
There's a variety of reasons. It's often because our languages are too low-level and the architecture too opaque, such that you need to study a codebase for a long time to understand what works well and what doesn't work so well. The hill you need to climb to reach an epiphany is sufficiently steep that people much rather build their own hill, and learn their own lessons. The trade-offs come around and around, the lessons are not as inapplicable as you think. We used to struggle to run programs on small machines; those struggles came back again with mobile, and come back again in a slightly different guise in clusters (where the program is too big to fit on any one machine). They recur on different scales, too. Just the other day I was looking at dependency injection. Dependency injection solves the problem of coordinating dynamic program composition; the reason the program needs to be composed is because it was decomposed for testing. But this is just another iteration of the same pattern come around again. It's been done before in a large variety of ways; sometimes through ambient configuration (global variables), sometimes with patched jump tables (dynamic linking), sometimes statically (module instantiation). The emphasis is different - testing - but the solution is not structurally novel in the least.
oblio 10y ago
> But if you could learn some things from the history and use that to your advantage, why wouldn't you? Everyone would be doing so. Hah! Reasons for not learning from history: * history is hidden behind NDAs, bad licences and patents * history is hard to access due to its environment (printed on out-of-print books, stored on tapes, HDD and other forms of storage in someone's basement) * history is written in a programming language nobody knows anymore * history is written in an incompatible programming language, one for which there are no stable bindings to your favorite language (or for which there aren't any bindings, period)... just think how many times the String class or data type has been written and rewritten just in something like C, let alone the copies in Java, PHP, Ruby, Javascript, Go, Rust, etc., etc. There's a ton of (somewhat) valid reasons history is forgotten and most of them aren't "history was bad, let's just forget it".
- pjmlp 10y ago
  True, but many of those hurdles are easy to overcome when one is curious about history of computing, specially since many libraries have been scanning old books and papers. For example, I have collected the majority of Xerox and DEC research papers that I could get hold of.
sbov 10y ago
> Direct experience of the last decade is a lot more relevant with a lot more lessons to learn that were never even on the radar in the past. Do you make that statement with the experience to back it up? Or do you make it because "if it were useful someone would have done it"? What if everyone is thinking the same thing as you are? Beyond what other people have said, we are also a relatively young industry. There aren't that many people with 30, 40 years experience in the field. When I got my CS degree, 13 years ago now, there was no such thing as a "software engineering" degree, and CS was mostly focused on CS rather than the sort of thing you're talking about. I also wonder how much collective knowledge we throw away with pushing developers into management. Or the outsourcing in the late 90's and early 00's. Or ageism. We are purposefully driving people with knowledge out of the industry.
- pjmlp 10y ago
  > When I got my CS degree, 13 years ago now, there was no such thing as a "software engineering" degree That is country specific. I took my degree around 20 ago and is it called "Degree in Software Engineering", certified by our Engineering Society. http://www.fct.unl.pt/ensino/curso/mestrado-integrado-em-engenharia-informatica http://www.fct.unl.pt/ensino/curso/mestrado-integrado-em-eng... Created in 1977.

by zzzcpan 10y ago

barrkel 10y ago

There's a variety of reasons. It's often because our languages are too low-level and the architecture too opaque, such that you need to study a codebase for a long time to understand what works well and what doesn't work so well. The hill you need to climb to reach an epiphany is sufficiently steep that people much rather build their own hill, and learn their own lessons. The trade-offs come around and around, the lessons are not as inapplicable as you think. We used to struggle to run programs on small machines; those struggles came back again with mobile, and come back again in a slightly different guise in clusters (where the program is too big to fit on any one machine). They recur on different scales, too. Just the other day I was looking at dependency injection. Dependency injection solves the problem of coordinating dynamic program composition; the reason the program needs to be composed is because it was decomposed for testing. But this is just another iteration of the same pattern come around again. It's been done before in a large variety of ways; sometimes through ambient configuration (global variables), sometimes with patched jump tables (dynamic linking), sometimes statically (module instantiation). The emphasis is different - testing - but the solution is not structurally novel in the least.

oblio 10y ago

> But if you could learn some things from the history and use that to your advantage, why wouldn't you? Everyone would be doing so. Hah! Reasons for not learning from history: * history is hidden behind NDAs, bad licences and patents * history is hard to access due to its environment (printed on out-of-print books, stored on tapes, HDD and other forms of storage in someone's basement) * history is written in a programming language nobody knows anymore * history is written in an incompatible programming language, one for which there are no stable bindings to your favorite language (or for which there aren't any bindings, period)... just think how many times the String class or data type has been written and rewritten just in something like C, let alone the copies in Java, PHP, Ruby, Javascript, Go, Rust, etc., etc. There's a ton of (somewhat) valid reasons history is forgotten and most of them aren't "history was bad, let's just forget it".

pjmlp 10y ago
True, but many of those hurdles are easy to overcome when one is curious about history of computing, specially since many libraries have been scanning old books and papers. For example, I have collected the majority of Xerox and DEC research papers that I could get hold of.

sbov 10y ago

> Direct experience of the last decade is a lot more relevant with a lot more lessons to learn that were never even on the radar in the past. Do you make that statement with the experience to back it up? Or do you make it because "if it were useful someone would have done it"? What if everyone is thinking the same thing as you are? Beyond what other people have said, we are also a relatively young industry. There aren't that many people with 30, 40 years experience in the field. When I got my CS degree, 13 years ago now, there was no such thing as a "software engineering" degree, and CS was mostly focused on CS rather than the sort of thing you're talking about. I also wonder how much collective knowledge we throw away with pushing developers into management. Or the outsourcing in the late 90's and early 00's. Or ageism. We are purposefully driving people with knowledge out of the industry.

pjmlp 10y ago
> When I got my CS degree, 13 years ago now, there was no such thing as a "software engineering" degree That is country specific. I took my degree around 20 ago and is it called "Degree in Software Engineering", certified by our Engineering Society. http://www.fct.unl.pt/ensino/curso/mestrado-integrado-em-engenharia-informatica http://www.fct.unl.pt/ensino/curso/mestrado-integrado-em-eng... Created in 1977.