[GuiA]

I originally posted this (in 2013! reposted today prompted by HN's second chance pool) because it struck me how, with very few modifications, this exact article could be republished today. I find it fascinating that we can be having the same arguments that people a half century ago were having, with little to no awareness that we're repeating the exact same things. It makes me realize that perhaps software is not as young a field as we like to sometimes pretend (it's common to read on HN that e.g. software is so young and immature compared to civil or electrical engineering, etc)

It's also interesting to dig into the author's name - apparently a half century ago he had some reputation in tech circles, but as far as I can tell he's mostly forgotten today.

https://www.theatlantic.com/technology/archive/2016/05/what-...

He sadly seems to have passed a couple years ago:

https://www.legacy.com/obituaries/name/erik-sandberg-diment-...

[User23]

> it's common to read on HN that e.g. software is so young and immature compared to civil or electrical engineering

Just a nitpick, but civil engineering is at least two orders of magnitude older since it goes back to Babylon.

The really cool thing about programming's scientific maturity is that it's entirely constructed. We know all the ground rules because we created them. The engineering challenge is not making a mess of things despite having a potentially perfect understanding of program semantics. So despite building aqueducts being a couple order of magnitudes older than building programs, we actually understand the abstract rules of programming better than we do hydrodynamics.

[throwaway0a5e]

> I find it fascinating that we can be having the same arguments that people a half century ago were having, with little to no awareness that we're repeating the exact same things. It makes me realize that perhaps software is not as young a field as we like to sometimes pretend (it's common to read on HN that e.g. software is so young and immature compared to civil or electrical engineering, etc)

True, a lot of these arguments have been beaten to death but times do change though. Every now and then some fundamental assumption on which arguments are underpinned changes. Often times these changes come from other industries. It's worth re-assessing the basics from time to time.

[ghaff]

On the one hand, it's easy to dismiss any new proposal with the argument that "we've heard this 20 times before and it's never worked" and you'll usually be right.

But public clouds, for example, aren't really like histrical timesharing. Because the underlying tech, capabilities, and demand are so different that things really are different this time.

[thisisnico]

One of the big differences between now and then is network capacity. Once we've gone past basic text and into 3D, Photo, Video, Timesharing could not work effectively over the internet at the time, the bandwidth wasn't there yet. The only way to continue was to bring the hardware home. Now that we have the network capacity to handle almost anything, we're seeing things go back..

[astrobe_]

I am not sure why networking and could computing is in this thread. This is certainly the last thing you want to try or use (except for Internet access and all its learning resources) when learning to program. And it won't let you become as familiar with common computers logic as programming, say, a Tetris.

[ghaff]

It depends on what your objective is and what you're trying to accomplish.

For a lot of people trying to just accomplish some specific goal, learning to program in C (as per the article) is probably not the best approach unless they're into OS kernels or embedded programming. Instead, they might well be better off stitching together some cloud services of various types. Not everyone has as an objective passing a leetcode whiteboarding interview at some ad tech company.

[ghaff]

Yes, connectivity is a huge difference. On the other hand, as there's more and more data-intensive activity happening outside the data center, we're actually seeing a general trend away from everything happening "in the cloud" as was being promoted in the late 2000s. See e.g. Nick Carr's The Big Switch.

[spaetzleesser]

I agree that we tend to forget previous lessons learned and to rediscover decades old ideas as innovation. But on the other hand I can't think of any engineering discipline where the fundamentals have been changing as rapidly for such long time. I am pretty sure civil engineering would be thrown into some confusion too if concrete doubled its strength every two years for decades making old bridge designs obsolete.

[cgh]

Small nitpick: 1984 was significantly less than a half century ago. But otherwise yes, the greater point is history tends to teach us nothing.

[armadsen]

Having been born in 1984, I'm definitely not ready to be 50 just yet.