[ams6110]

For me, the thing that gets a bit discouraging at times is the feeling of riding a slow-motion merry-go-round. Every 10 years or so you see the same ideas start to come around again, only with some new paint and landscaping.

I have found myself more than once thinking that learning about some new trendy buzzword is just ultimately a waste of time, since I will barely have mastered it before it's been replaced by the next new/old thing.

On the other hand, it gets easier since none of the concepts are new anymore, and I tell myself, "hey, if you want to pay me to build a client-server app in the browser like it was 1995 (substitute Powerbuilder for Firefox/Chrome), great, happy to take your money."

[derefr]

I see the same thing, but feel much more optimistic about it: it's not, in my mind, that tech is effectively fashion, but rather that there are "futurist" ideas that tech keeps trying and which keep not getting adoption, because it's not their time yet—the state of the art isn't there to make the experience for the average consumer (or the average developer) justify the costs.

An example of what I mean: the Apple Newton, and then 10 years later the Palm Pilot, and then 10 years later Windows CE and flip-phones supporting J2ME, and then 10 years later touchscreen phones and tablets. There have been four generations of "mobile app developers", but only the latest generation has seen any traction for their apps. This time the idea stuck; it will stay around, rather than coming around again.

If something like Paypal's prototype service (beaming money from one Palm Pilot to another) were set in this "revolution" of mobile instead of that one, it would be much more successful.

[smitherfield]

Not to be that guy, but

Apple Newton: 1993

Palm Pilot: 1997

Smartphones: ~2002

iPhone: 2007

Android: 2008

iPad: 2010

[scarmig]

His numbers were in base 5.

[timmy-turner]

And you hopefully have learnt from the mistakes Powerbuilder did back in '95, not making them again. So in theory you're ahead of the crowd of today.

Though that means that you have acknowledge that things were not all that great back then as you remember - which seems to get harder as one grows older.

[tjradcliffe]

I don't see that at all. I started out when "structured programming" and "recursion" were both exciting concepts. OO came along and over a ten year period went from "useful for UI" to "the One Ring To Rule Them All" and while the shine wore off a bit, it really did help.

Today Functional Programming is introducing all kinds of new ideas and approaches, and while I often find FP people over-earnest and irritating, I'm still able to recognize that they offer something new, even if it isn't all they think it is.

Impure functional languages like Haskell have shown that it's possible to get many of the advantages of a purely functional language while still being able to implement side-effects, which is an amazingly cool trick despite Haskeller's annoying insistance that their side-effect-ful "language" is "purely functional" even if they have to redefine "language" to make it true.

This is true of all the supposedly "pure" functional languages, which universally come with caveats that amount to "disregarding all the sex I've had, I am a virgin", but that's just a somewhat off-putting quirk of the community. The languages themselves are full of interesting ideas that are being adopted by less purity-obsessed languages, and this is a good thing in the same way that the OO-purism of SmallTalk drove other more mainstream languages to adopt OO ideas and bring them in adulterated form to the unwashed masses (which had the nice side-effect of driving the purists nuts, and who doesn't want to see that?)

So I personally get the feeling that it's a great time to be alive and active as a software developer. We're barely out of the "bash rocks together to make hammer-like-thing" era of programming, and we get to be part of the most explosive growth phase of the most important technological growth curve in human history: the algorithmization of work.

[silverlake]

Most companies aren't using the trendy new languages and tools. The bulk of jobs today are for C++ ('83), Java ('95), Javascript ('95), Python ('91), and maybe C# (2000).

[sjolsen]

It's a shame, too, since C++14 is a far cry from 1983's C++ (or whatever version the majority of the segment of the industry which uses C++ is actually using), and the others are similar stories.

One the one hand, I suspect ams6110 was referring more to those things we give names like "pattern," "architecture," and "paradigm," maybe even "stack," "platform," or "library" than to languages. On the other, my suspicion may be wrong, and I'd agree with him about it if it were anyway; so little that's been developed in the world of programming languages recently is anything new, and what isn't is as often as not a poor reimagining of something Lisp or ML had figured out pretty damn well ages ago, thank you very much.

Still, though, progress has been made even on the mainstays, even if the industry hasn't quite caught on yet.

[Retra]

C++ dumping ten pages of unreadable error messages on you because you forgot a semicolon or misspelled an import? If that is C++14, I'd hate to see 1983's version.

[mcguire]

1983's C++ didn't have templates.

[tomjen3]

As a young person my biggest concern with hiring old people is that exact attitude: this is just like $IRRELEVANT_OLD_TECH.

Yeah on the surface. $IRRELEVANT_OLD_TECH didn't catch on or it wouldn't be irrelevant but _why_ didn't it catch on? Powerbuilder failed, but was it because you couldn't write a good enough program that way on 1995s hardware? Or because it was ultimately a stupid idea?

Somebody like me who has never heard of Powerbuilder would have to look into the technology, which would take longer but it would prevent me from just dismissing it because "this has been done before".

Remember it isn't what you don't know that gets you, it is what you know for damn sure that just isn't so.

I am not saying this is the case for all old developers, but it would be my concern.

[wedowhatwedo]

Powerbuilder failed? I made a ton of money programming with Powerbuilder back in the 90's. How is that a failure?

Some day a person younger than you will say "this is just like Javascript that failed back in the day".

[vezzy-fnord]

...this is just like $IRRELEVANT_OLD_TECH.

Yeah on the surface. $IRRELEVANT_OLD_TECH didn't catch on or it wouldn't be irrelevant but _why_ didn't it catch on?...

I'm a young person, too. Lipstick on a pig doesn't make a cow, you know.

Arguments like "It's only similar on the surface" I've found tend to give too much credence to incidental properties - this runs on X, it's widespread unlike previous solutions, it's better at specific Y use case, etc. Yet regardless of underlying platform, the concepts do not tend to evolve quickly, and it is all too often the case that their limitations have been discovered either in academia or engineering practice. These limitations will eventually be uncovered again, and no one learns from their failures or successes. Where languages and platforms shift, architecture will always bite you.

As for the reasons why, that's another fallacy. It assumes the status quo always maintains an equilibrium of what is inherently technical superior, and that popularity implies great technical qualities. The reasons can be plentiful, often it's unfortunate historical circumstances.

It's comforting to think we're on to something truly new, but this is rarely the case: http://www.dwheeler.com/innovation/innovation.html

[walshemj]

Amen when I was looking at hadoop it suddenly dawned on me that I had been doing map reduce back in the early 80's for British Telecom.

[wwweston]

> As a young person my biggest concern with hiring old people is that exact attitude: this is just like $IRRELEVANT_OLD_TECH.

Leaving aside the (substantial) ageism issues here, it looks to me like your reading of the GP's complaint is incorrect.

It's not a judgment that $NEW_TECH is going to not catch on or otherwise fail because it's just like $NOW_IRRELEVANT_OLD_TECH.

It's the observation that much of the $NEW_TECH that catches on and succeeds for a time often turns out to offer approximately the same utility as $NOW_IRRELEVANT_OLD_TECH... and similar adoption costs, which we pay over and over again. We rent rather than buy.

There are counterexamples I can think of -- new tools/abstractions/practices I've adopted that have resulted in near order-of-magnitude gains. But the ratio of these to other $NEW_TECH that just sort of shuffles the dirt around... well, that probably approaches another order-of-magnitude relationship.

And there's also the argument about the aggregation of marginal gains (see Brailsford and the British cycling team); approximately the same utility isn't quite the same thing as exactly the same utility and I don't think that should be overlooked. In fact, I think one could put together a specific case that the GP is arguably not correct in making an even comparison between Powerbuilder and webapps on precisely such a basis.

Still, an aggregation of marginal gains approach only ends up helpful if the marginal and opportunity costs are low.

How often do you find that's true for $NEW_TECH over $NOW_IRRELEVANT_OLD_TECH?

And since we're being free with judgments about age here (generalizations, naturally -- not that you or I would ever let such general thinking affect our judgment when it comes to individuals)... do most young developers really have enough knowledge and experience to answer that question effectively?

[mcguire]

"There are counterexamples I can think of -- new tools/abstractions/practices I've adopted that have resulted in near order-of-magnitude gains. But the ratio of these to other $NEW_TECH that just sort of shuffles the dirt around... well, that probably approaches another order-of-magnitude relationship."

Further, most people seem to have little appreciation of the difference between order-of-magnitude gains and shuffling the dirt around. Certainly, there are those who are wrong in assuming anything new is just dirt-shuffling, but for anyone without experience, everything offers an order of magnitude. And this really is an engineering discipline---$NEW_TECH is never as good as its proponents say, but it the best trade off in some circumstances, while $OLD_TECH is never as bad (or good) as the "general consensus" would have you believe, while it is almost certainly inappropriate under some scenarios.