A discussion I've often had, that old technologies never disappear altogether, there's always an interest, revivals inevitably occur especially among the younger generations to whom the old stuff is new.
Not too long ago I overheard a conversation among a group of college-age artists chattering about the merits of silver-based vs. digital photography. Basically, in their eyes digital was old hat, the familiar way to make images while film photography was intriguing, exotic by comparison.
Of course as a genuine old guy I found their view amusing but refreshing. Having used film, and spending way too many hours in stuffy darkrooms I knew all about the subject. It was fun to talk a bit with a few of the students, but I understood they wouldn't hear it from me. No, they'll have to learn for themselves about the merits and tradeoffs of the old ways vs. the contemporary.
In programming as in all other arts, it's good once in a while to revisit the trails our forbears traversed. We should all travel there as part of an education, it gives us a greater appreciation of what we have now. And sometimes even us old hands will have the urge to revisit the dusty past, though likely choose not to linger there.
Once in a while we should touch ancestral ground, it's a worthy ritual to honor our ancient heritage, lest we forget how far we've come.
Computing actually has a very chaotic evolution compared to other fields. Where most can be seen as linear progressions, computing is heavily prone to stasis and regressions.
Revisiting ancestral ground in programming actually makes you think how little we've come, not how far.
Although my self-teaching of programming began in Python it ended up veering through Racket and Smalltalk. I almost regret learning Smalltalk after experiencing what a joy it is to program in. Writing a webapp in Seaside, with all of its great features for live inspection and debugging, and then experiencing Django and Node was an eye opener.
>>>Once in a while we should touch ancestral ground, it's a worthy ritual to honor our ancient heritage, lest we forget how far we've come.
Yeah. I really like the way you put this, and would add...
There are merits in the past ways of doing things. Here's a simple, non software related example:
Unfolding sheet metal parts. This basically is calculating the flat sheet shape needed to produce a bent part of the proper dimensions. Metal stretches when bent, meaning the flat shape is not a 1:1 representation of the 3D bent part.
Modern software does this with solid models. We make the part we want, and then the software produces a flat pattern for us. While this process is very simple, it does require one to have software, model in solids, and so forth...
What gets lost here is the actual dynamics of the metal.
Further, the analytic geometry methods go unused in most modern solutions, which actually makes unfolding more complex, organic shapes difficult and CPU intensive as they get broken down into polygons...
Don't get me wrong, much is gained too. Analysis, ability to work in context, and automation come with new methods. In the vast majority of use cases, these gains make the overall current path superior.
However, going back to analytic geometry and manual pencil and paper means to produce these parts allows for some extremely efficient workflows and it gives people the means to check their software work, debug problems, and in the case of just wanting to make something quickly, the ability to do so by hand with only basic tools.
The most interesting part about this transition for me, as I was there doing it old school and transitioned to new school, is the demand for the basic methods comes up time and time again, despite the software being capable. People just don't always know why, just what.
From time to time, I teach mechanical CAD design. When this topic comes up, I go to the white board and show them the classic methods and basically produce a complete part on a white board with no computer assist. Once they see the why, a whole lot of software use issues go away and trust / confidence in the tools goes way up.
For this particular discipline, it's not taught, but can be found in old books, or from manufacturing people who have learned it from others.
For most engineers, going through this grants them the ability to visualize the sheet, and or catch a lot of simple errors without having to employ verification software. "It just looks wrong" becomes part of their tool set, and we all know how valuable that basic intuition is.
The same can be said for most manufacturing techniques. Going back to the manual, hands on means and methods explains so much about what we do today, even though the methods themselves may not be viable in the context of modern automation and production.
We have come a long way indeed! And on a basic level, just experiencing that perspective is gratifying sometimes.
Not too long ago I overheard a conversation among a group of college-age artists chattering about the merits of silver-based vs. digital photography. Basically, in their eyes digital was old hat, the familiar way to make images while film photography was intriguing, exotic by comparison.
Of course as a genuine old guy I found their view amusing but refreshing. Having used film, and spending way too many hours in stuffy darkrooms I knew all about the subject. It was fun to talk a bit with a few of the students, but I understood they wouldn't hear it from me. No, they'll have to learn for themselves about the merits and tradeoffs of the old ways vs. the contemporary.
In programming as in all other arts, it's good once in a while to revisit the trails our forbears traversed. We should all travel there as part of an education, it gives us a greater appreciation of what we have now. And sometimes even us old hands will have the urge to revisit the dusty past, though likely choose not to linger there.
Once in a while we should touch ancestral ground, it's a worthy ritual to honor our ancient heritage, lest we forget how far we've come.