Hacker News Reader

Comment by btrask | Hacker News Reader

Fantastic article. We need more deconstruction of "fads" (which I don't mean in a pejorative sense) so that we can quickly understand them without sacrificing tens of thousands of man-hours slowly coming to terms with each one. It would be much better if we could reason about the exact differences and benefits instead of getting bogged down in new terminology, etc.

More examples I've been thinking about:

- Goroutines (fibers are equivalent to threads, but coroutines are different)

- Safety and the unsafe keyword in Rust (not sure but the effective difference seems to be default-allow versus default-deny)

View on HN

Regarding those two examples, more than having explanations about them, it would help if people cared about IT history and it was more accessible.

Coroutines are easily explained in Modula-2 literature.

Safe keyword in Rust goes back at very least to Ada and Modula-2. Also in Oberon and its derivatives, Modula-3 (which inspired C#). The literature for those systems also has lots of examples.

Being an old IT dog, that started when those technologies were new it is sometimes hard to me to see how new generations fail to find such information, even though it is available on the web. I guess the main cause is thatbone needs to know what to search for.

Tech is strangely ahistorical. Not just practitioners not reading the literature, but it seemingly being forgotten entirely. Possibly this is a side effect of so many of us being self-taught.

In another thread I've just been arguing with someone who thought that the DOOM code should have been thread-safe.

I would say cyclical. Every day we read about a similar framework working in a popular language when that solution already existed for long time.

But this happens in other areas outside computer science. For example, modern medicine rediscovering old medicine "recipes".

The problem in our field is when people talk all day about Docker while surpressing LXC from the discussion.

I think it happens for different reasons though.

With medicine it boils down to a dismissal of folk remedies as placebo.

But with computing its because the old ways were developed on mainframes and minicomputers in an environment that current generation may only have heard stories about.

This because the micro-computer era was pretty much a mental reboot for computing, as little if any software crossed over (until fairly recently).

i think being a young industry doesn't help with that regard either. Think about how the medical industry was in the middle ages! And tech is even younger than that time - a mere 70 or so years tops.

That is why I always look forward new technologies. We are very far away from reaching any tipping point.

Regarding IT history, on my case it helps to have been part of it since the mid-80s and my history desire to delve into available documentation from Egyptian, Greek, Roman days and apply the same process to IT.

> it is sometimes hard to me to see how new generations fail to find such information, even though it is available on the web

As someone who has attempted to go back and find old articles and concepts for which I remember only the generalities, I understand this completely. The problem, IMHO, is that search engines put too much emphasis on the publication date of an article - you'll get recent musings on the topic on the first ten pages, and then if you're lucky you'll get the original material on the eleventh.

However, you're frequently unlucky in this regard, since the search engines will devolve into poor-yet-recent matches before looking further back in time.

Ironically, the internet is forgetting, because we've too finely tuned the algorithms to value newness and community guesses over authority.

> I guess the main cause is thatbone needs to know what to search for.

It is common misbelief (particularly among yang people), that all in IT changing so fast, that any technology created more than 20-30 years ago is outdated and don't worth to study. The wheel reinvented many times.

I'm a huge fan of docker, but I've also drawn a comparison to linking in the past: some people are using it to defer (not solve!) Dependency management and distro ecosystem complexities. Fossilizing dependencies is not the future; that's just like static linking. And just as in static linking, if you hide in the corner, avoiding your distro's dependency and patch and package management systems, this ultimately creates more avoidable pain.

So I've recently reimplemented some of our applications service dependencies in docker for the main reasons of mitigating dependency issues and allowing for for developer local consistency.

I fully admit this is deferring solving these issues fully (solr 1.4.1 really?) but it has allowed for minimizing the issues the existing backlog was causing us. Arguably its also brought more consistency to our environments vs the chef/puppet/hand rolled management tools. We could have used these tools with a different process to achieve similar results though.

Yeah, I totally get it - I realized I'm a hypocrite when I posted this; just a few weeks ago I put a custom build environment together with an obscure version of gcc because I'm dealing with some code that depends on some of those "bugs".

I just don't think it's healthy to embrace this as an alternative to proper maintenance.

"Fads" are only un-useful when you don't understand them. But once you go over the edge from rejection to application, the fad state desists and you end up with a useful, cutting edge tool.

There are very few fads which persist long unless they are understood and used. So I would say that the "fad"-gadget'ization of our technology world is a subjectively-borne reality.

It doesn't matter if you don't understand it - some do. That's why its out there in the first place: someone had a use for it.

Reply on news.ycombinator.com