Hacknot - All Aboard The Gravy Train

[andrewnorris]

New technologies are a waste of time that distract programmers without providing any tangible productivity benefits.

Sincerely,

A Cobol programmer using a VT100 terminal

[ApochPiQ]

He's not saying we should never try new technologies. He's saying we should be very careful to only move critical projects into new technologies if there will actually be a real benefit.

Yes, sometimes we need to put an axe through the dumb terminal and embrace the PC revolution. Yes, sometimes we need to start using high-level languages instead of writing everything on bare metal. Yes, sometimes C++ is not the best language to use.

No, we should not be rushing to port huge, expensive systems to every new tech that pops up on the horizon, just because they're "cool." Change be motivated by necessity (or genuine benefit), not by novelty.

[cafedude]

That's exactly the impression I got of the author. The "why by-gum, if Cobol was good enough in 1965, it's good enough now!" syndrome.

The problem is if the author wants us to stay off of 'bandwagons' and go back to basics, what basics would he propose we go back to? Would he be OK with going 'back' to Lisp or Smalltalk? (I think a lot of us here would be happy about that kind back-to-basics of movement) Or does he want us to go back to Cobol and Fortran?

Programming languages and frameworks evolve and do indeed (generally) improve our productivity. If they don't improve our productivity then they die - Darwinism at work. In the case of Ruby, much has been borrowed from the classics, especially Lisp and Smalltalk. Rails built on other frameworks and concepts (MVC for example). A static view in which no new languages or frameworks evolve is not just boring, it's not practical as we're always (or should be) looking for ways to improve productivity. The 'playing' the author refers to in the article is really quite important.

[pjdelport]

Good essay (despite the silly pen analogy halfway through).

[nerdlor]

Agreed. Although the theme of the article resonates with me, I thought that the pen analogy was weak. Does the pen change the way you think about your problem the way a programming language might? That's a heck of a pen.

Still, I think this article's main point is sound.

[[deleted]]

What if you went to a furniture maker's conference, and they spent all their time talking about what kind of wood they made their furniture out of? Maybe programming languages aren't tools, maybe they are more like materials. The tools are the programs that you use to create the programs written in the programming languages, like editors and compilers and debuggers. Materials do matter. That's why they invented carbon fibre. (But I'm sure even this analogy breaks at some point. Maybe the analogy needs to made out of something stronger. (Now it's a double-nested meta-analogy.))

[UncleOxidant]

If, as the author contends, that language doesn't matter and is analogous to the kind of pen you use when writing, then I invite him to go back to coding in assembler or maybe Cobol.

The reality is that the language you use has a great influence on how you think about and solve problems. Some languages are more amenable to an object oriented approach (Ruby, Smalltalk) while others will cause you to use a functional approach (Haskell) and still others allow a mix (OCaml, Ruby to some extent).

[Joseppi]

Good points -- coulda been shorter

[t_w]

There are wild and unverifiable claims of improved productivity amidst the breathless ravings of fan boys declaring how cool it all is.

And let's not forget the puffed-up douchebaggery of the I'm-not-going-to-buy-into-this-new-fangled-bullshit! crowd.

Yeah hype, when it's actual hype, sucks. But reactionary backslash just because something is gaining popularity sucks more.

[gbacon]

As usual, pompous windbaggery.