-
Time and Change
I’ve arrived somehow, somewhere over 3 years, at 1000 posts. It might be time to retire.
I had intended to put together something of a “best-of” to mark the occasion, but as I have neither the time nor the coherent strategy to do so, I’ll use the opportunity to thank everyone for the information, discussion, analysis, speculation, entertainment and general energy of engagement that this forum represents at its best.
While some still tend to view this forum as tilted either pro or con, or an open question on Apple’s commitment to professionals, it’s been most useful and interesting to me as a forum to understand the wider context of what editors do and how they do it, and it’s been very unique as a glimpse of disparate workflows and approaches, as well as helping me to articulate some of my thoughts on my own process. In particular, it’s really opened my mind to how diverse and different people’s needs really are, and how any given solution is likely to have it’s unique aspects. It’s great to have such a deep well of knowledge and experience to reference.
Thanks, all, for that.
Here’s the bow on it: I found this posting (arstechnica from the summer) interesting and relevant. It shows what some software developers really think about the value of change and the value of legacy technology by understanding it in a social context, because they’re talking about the tools they rely on; put another way, it illuminates attitudes that those shaping technology have towards change (one of the ongoing, if poorly articulated themes in this forum):
https://arstechnica.com/information-technology/2014/08/keep-a-programming-language-backwards-compatible-or-fix-its-flaws/
Some choice quotes (from article and ensuing comments):“If it is doing what it is supposed to do well and efficiently is it really “old”?”
“Cool, modern features cannot easily be weighed against the price of fragmented installation base in popular opinion, and you run the risk of getting a reputation as an “upgrade treadmill” that requires constant effort …”
“If you change it too much, people will evaluate your competitors, since they’re going to have to spend significant effort switching anyway.”
“There’s a few examples of the change-everything mentality really not working well in programming languages … But on the other hand there’s plenty of examples of languages that keep way, way too much cruft from 20-year-old APIs in their libraries rather than break them. I think it’s a bit of a balancing act. Throwing away all old code in one new release, … will result in most devs just ignoring the new language for years at minimum.”
“Languages which break things too badly tend to lose. Stable languages with incremental improvements tend to win. The mix of steady, reasonable improvements on top of a solid core seems to be the key.”
“Backwards compatibility wins in so many cases it’s not even funny. … backwards compatibility is enough of a reason to keep a CPU architecture alive. x86 has been a monster for years; it’s full of workarounds … that make it cumbersome compared to ARM when considering power consumption or die area. Yet PCs and laptops today are all running x86. And the sole reason is backwards compatibility.”
“The answer is simple: Don’t call new versions that aren’t backward compatible with the same name.”“A rewrite is called for to solve tangible and valuable problems that out weighs all of the problems of starting over. And the smart developers usually hold off 3-5 years before jumping into a new technology or platform; how many platforms, frameworks, and APIs prove to be a dead-end after that time?”
“Personally, when it comes to programming, I think there’s a small window when a language or framework is still new, that one can still break a few things and improve the thing. That works as long as there’s not a lot if baggage. The downside is that shortcoming become apparent only after the language/framework gets some mileage. And sometimes it’s not even about shortcomings, it’s about assumptions designers have made and then people preferring to go a different way.”
“Funny thing, while about computers, this could be said about a lot of other engineering. Inertia, and economics.”It’s interesting to read “programmers” as “editors”, and “languages” as “NLEs” – I had intended to open up this discussion by asking in what ways an NLE as like a programming language (what characteristics the two share, how they differ) (perhaps first appealing to David Lawrence and those that might know).
Thanks, and good luck with the technology and creativity.
Franz.