The Old Joel on Software Forum: Part 3 (of 5)

Counterculture junkies

The YAML thread & the fashion article had me thinking - our industry has a constant turmoil of "the best new thing which is better than the popular new thing"

Five years ago, Java was the "underappreciated red-headed stepchild"; now Java is a "bloated architecture" and it's all about Python or PHP.

Like the litany of *nix implementations - "Linux is better than Windows" then "Slackware is better than Redhat" then "BSD is better than Linux"

Look at the YAML thing - to me it really seems like a case of "Let's support something that's not XML so we can be rebels"

I don't have a problem with "opposing the establishment" - what bugs me is the relentless nature of always living on the bleeding edge and never taking a breath. Okay, if the new thing really solves some problems, that's fine, but so often it feels like "Pink is out, blue is the new pink"

Just a rant/observation.

Philo

Philo
Monday, October 6, 2003

Brad Wilson is the new Philo!

Yoyoma
Monday, October 6, 2003

> Look at the YAML thing - to me it really seems like a
> case of "Let's support something that's not XML so
> we can be rebels"

Look at the SOAP think - to me it really seems like a case of "Let's support something that's not CORBA (COM, RPC) so that we can seem to be innovative and get more cash".

Here is a quote which might be close to the subject:

Any man who is under 30, and is not a liberal, has not heart; and any man who is over 30, and is not a conservative, has no brains.

Winston Churchill

Alexander Chalucov
Monday, October 6, 2003

1998 called. It wants its anti-counterculture rant back.

Sorry, I couldn't resist. :)

Matt Latourette
Monday, October 6, 2003

Ooops. I mean SOAP thing. It's too late ...

Alexander Chalucov
Monday, October 6, 2003

THat's always the case, though. Have you looked at teenagers these days? Their idea of fashion consists not of what looks good, but entirely of either (but never both) of (1) what is everyone else wearing? and (2) what *isn't* everyone else wearing?

There's always 4 people that do something different because it could be better, and there's always N who do it because it's "l33t" and to "stick it to the man".

So let's all use python to stick it to the man.

Mike Swieton
Monday, October 6, 2003

I always thought SOAP/ROPE/SUDS was just an attempt to get suits to talk with all seriousness using silly acronyms.

Seems to have succeeded, too.

Philo

Philo
Monday, October 6, 2003

> 1998 called.

So THAT's why the phone doesn't stop ringing.

I'm waiting for the day when Microsoft is the cool counterculture underdog.

Mark T A W .com
Monday, October 6, 2003

I'd say that the Lisp and Smalltalk people are the true counterculture in programming languages, not Python or PHP.

Python and PHP are newer and upcoming languages, they're the indie artists that might make it onto a mainstream label one day soon. Lisp and Smalltalk are the artists who never really made it big and now only have the diehard fans.

So it's too early to tell whether Python will become like Java and become mainstream, or become like Smalltalk and become counterculture. It's still in its growth stage I think.

Programmers do seem to be a bit like the MTV generation though ... 5 minute attention span as the next shiny thing comes along and they grab onto it.

MTV certainly isn't counterculture though. Which I guess sums up my thoughts on whether programmers are counterculture junkies. That is: not at all, they're pop culture junkies prone to fanboy adulation of technologies like teeny-boppers do with pop music artists.

Sum Dum Gai
Tuesday, October 7, 2003

It's all just to confuse people and prevent them delivering solutions... ;)

Joel hits it on the head here, with his fire and motion article: http://www.joelonsoftware.com/articles/fog0000000339.html

The trick is to learn to ignore it all and stay focussed on delivering value every day using whatever technology you can (preferably technologies that you know well and understand the shortcomings of); whilst keeping track of things that might be useful in the future and continually learning... Hmm...

Then, if you can manage that, the 'hard' part is convincing some clients that they don't necessarilly need all of the bleeding edge stuff in their system...

Len Holgate (www.lenholgate.com)
Tuesday, October 7, 2003

> 1998 called

As I read somewhere else, calling 1998 is so 2001. Admittedly, calling 1998 2001 is so 2002, but calling calling 1998 2001 2002 is absolutely fresh.

Konrad
Tuesday, October 7, 2003

Len... SHHH. you don't expect people to actually get things done do you? Damn, you let the cat out of the bag.

Mark T A W .com
Tuesday, October 7, 2003

Oops.

Len Holgate (www.lenholgate.com)
Tuesday, October 7, 2003

God forbid we become technologists, interested in improving the status quo...

I suppose this topic was meant as a rant, but I could just start another about "Reactionary straights." I mean, XML's young, it's the best time to complain about it. Even if the complaints were somehow flawed, there's nothing wrong about considering something better.

hieranonymous
Tuesday, October 7, 2003

Have no fear though.

The MTV generation will forget everything Len wrote in 5 minutes, counting from .... now!

Ori Berger
Tuesday, October 7, 2003

Philo,

I have the impression that you're relatively new to this line of work. 5-7 years??

What is happening is that you're becoming one of the 'old' guys. You think everything is XML & SQL & .NET yada yada.

Soon young punks will look on you with the same curiousity that your age group looks to mine (C & Unix) or my age group looks to the one before (COBOL & VMS).

That's just the way this business has always been. Tech for tech's sake.

staying power
Tuesday, October 7, 2003

Mike, is there ever a time when teenage fashion WASN'T determined by what everyone else is/isn't wearing? The more things change, the more they stay the same...

Just remember to give yourself a punch in the head whenever you seriously start a sentence: "These kids today..." :-)

Chris Winters
Tuesday, October 7, 2003

Admittedly I'm currently .Net, SQL & XML. But I don't have a problem migrating to new things if they have value.

I generally try to stay one step behind the bleeding edge - I don't adopt every great new thing as it comes along, but if something gets established and seems worthwhile, then I may move in that direction.

For example, Python shows a lot of promise and I'm starting to learn it. I'd learn PHP if I had to support a client with a Unix base.

Honestly, I've always been conservative about technology, always being suspicious of the latest snake oil. Now that I've got more experience I simply find the counterculture fanboys amusing, growing to annoying when they create enough noise to make my job difficult (like spending two days putting together a point paper about MySQL vs. Oracle in 1999, when MySQL was NOT ready for prime time).

I guess the bottom line is that I don't mind "hey, check out Python, it's pretty cool." But I have issues with "YAML is the perfect replacement for XML" - if that actually takes hold then suddenly we're in 1998 again - usage growing faster than specs, no tools, and being asked to build entire houses with this brand new hammer.

Philo

Philo
Tuesday, October 7, 2003

> "Let's support something that's not XML so we can be rebels"

You said this on the YAML thread again and again, but without any support for it, other than the accusation itself.

I, and several other people, pointed to aesthetics -- it's one of the reasons that people like Python and Ruby. The code is compact, expressive and clean, much more so than Java or C#. I don't know if you looked at some of the examples on the YAML wiki, but the code to manipulate YAML files is also very clean and simple.

While there may be people who like Python, Ruby, YAML, etc just to be new, fashionable, ahead of the curve or rebellious, *some people like the technology for its aesthetics* (ie, the aforementioned simplicity).

You really just do not seem to understand this, and the more you natter on about how they solve the same problem, the more you prove this to be true.

And I should emphasize, *again*, that I am well aware that business considerations trump aesthetics, most if not every time. It's why I work with XML on every project I do, and recommend it to customers. If I were doing another Oopen Source project, though, I'd probably be using YAML.

Finally, you also do not seem to be down with how the hype machine works. Technology is *always* over-rated at first, and it's used in places that it never should be, *until it finally grows into them*.

Windows NT is a good example: the versions before 4.0 were excruciatingly bad, laughable even; 4.0 showed some promise, although it crashed much too often; and 2000 and 2003 are actually pretty good. Plenty of people hitched their star to NT early, though, and never looked back.

I guess what this coda is saying is that you're already close to enlightenment: treat the folks who are trying to be ahead of the curve with amused tolerance, not hostility. End of sermon :)

Portabella
Tuesday, October 7, 2003

If you want to know *how* to think about software aesthetics, it's this: imagine that you had to solve the problem, whatever problem it is, without any business considerations at all. What's the simplest and cleanest way to address just the problem itself; a way that your fellow engineers could use in their work?

You say you're in a business, and you don't think that way?

Well, haven't you already learned to "think like the customer", and perhaps "think like your manager" as well? Or "think like another developer who is going to use your code"? Then what's wrong with adding yet another view? The way I see it, you don't lose anything by doing so.

By all means, keep the hard-headed "Is it ready for prime time?" view that you have; it's served you well so far, and doubtless will continue to do so. But please *don't* mistake attempts to resolve the problems of software engineering as being *solely* about rebellion or counterculture.

Portabella
Tuesday, October 7, 2003

SOAP is out, DIRT is in...

Cletus
Tuesday, October 7, 2003

"If you want to know *how* to think about software aesthetics, it's this: imagine that you had to solve the problem, whatever problem it is, without any business considerations at all. What's the simplest and cleanest way to address just the problem itself; a way that your fellow engineers could use in their work?"

And therein lies the rub. Software without business considerations is pure research, and one could generally question the utility of the pursuit.

Or the way I generally put it: "Act the way the world is; do not act as you wish it was."

Yes, I will make efforts to change my surroundings. Yes, I will push for acceptance for new tools that offer productivity increases.

No, I will not throw out an entire markup and its support infrastructure just because something else is *prettier* but offers zero incremental value.

But yeah, I'm just an old fuddy-duddy. ;-)

Philo

Philo
Tuesday, October 7, 2003

I want to be different, like all the other different people I want to be like. - King Missile

Obsure Quote Man
Tuesday, October 7, 2003

I think that "the best new thing" is driven by several factors. Some people adopt the new thing because they are counterculture anti-establishment types. Some like the excitement of being on the bleeding edge of hot, new, cool technologies. Some are idealists looking for the 'perfect' solution. Some are so frustrated with the current way that they are willing to try something new (a lot of these folks are also idealists).

There's a crossover point where "the best new thing" becomes popular. Most best new things never reach that point. They die out, replaced by some other best new thing.

My personal philosophy is to keep myself informed of the new things, but not adopt them myself until they become popular.

-Thomas

Thomas
Tuesday, October 7, 2003

You didn't address my point, though; what's wrong with considering (at least!) two views: the view of the problem domain, *and* the business point-of-view? I've said that throughout this thread, and in the YAML one.

Where do you lose by trying to actually *understand more*, instead of just namecalling?

You keep trying to paint this picture of business in one corner and the problem in another, and it just ain't so.

> No, I will not throw out an entire markup and its support infrastructure just because something else is *prettier* but offers zero incremental value.

Instead of prettier, substitute "solves the problem in a cleaner and simpler way", and we'll be more or less in agreement,at least in what we believe, if not in attitude.

And in some cases (again, look at that YAML wiki) the value is immediate; less time spent on the accidents of programming like futzing with XML, more time on the problem domain itself.

> My personal philosophy is to keep myself informed of the new things, but not adopt them myself until they become popular.

Mine is to adopt them *when appropriate*. That may be early or late, depending on the circumstances.

Portabella
Tuesday, October 7, 2003

That's kinda the point I was getting at though.

You're not delivering any business solutions with your .NET/Windows that I couldn't deliver with my C/UNIX or that the other guy with his VMS/COBOL couldn't deliver.

Admittedly, yes, I am exaggerating. But by how much? I don't think by much. Very little of what is out there adds real business value. UNLESS- you're talking about adding value to the tool vendor's bottom line.

staying power
Tuesday, October 7, 2003

"""Five years ago, Java was the "underappreciated red-headed stepchild"; now Java is a "bloated architecture" and it's all about Python or PHP."""

Actually, I thought Java was bloated in 1997, which is why I've been using Python since then. :) As some folks have said, it's a matter of aesthetics, not counterculturalism. (Also note, Python and Java had their first public releases in the very same year!)

I'm actually pretty conservative about technology; Roger (my old boss) used to say we should use "one-year-old technology", which was just another way of saying "be not the first by whom the new is tried, nor yet the last to lay the old aside." Python was already at least 5 years old when I first picked it up, 6 years ago.

Every technology has fanboys, though. People get excited about a new (to them) idea. You just need to see the tech through the eyes of veterans, not raw recruits. Or, to put it another way, don't believe somebody's rant about how great something is unless they've tried at least one other way to do it. :) This is why I'm not rushing to use Ruby, because Python veterans are effectively saying there's nothing there worth moving for. Meanwhile, the fanboys rant on.

Phillip J. Eby
Tuesday, October 7, 2003

" less time spent on the accidents of programming like futzing with XML"

This is the other point you keep bringing up, but you bring it up regarding a markup that doesn't allow tabs and is whitespace-sensitive. Let's talk real life for a second - those two are a pure formula for introducing user errors. Except instead of validating your markup against a schema and a validation tool, you've got nothing.

Now as for accepting YAML, it's simple - the advocates of YAML have the burden of convincing me it is worth the time and effort of learning it; that it fills a niche not filled by XML, or does something better.

You could argue "easier to write parsers for," except that for XML I don't need to write a parser - they already exist.

Philo

Philo
Tuesday, October 7, 2003

This seems to have become more of a discussion about is YAML adoption rebellious or not :)

The comments about whether or not to consider “another viewpoint” are quite interesting. I believe considering a cleaner, simpler or more *whatever* solution has its merits; it leads to better understanding in most cases.

But this is basically an analytical exercise, isn't it? And let us be honest about it: you *don't* really need YAML, Ruby or {insert cool tech here} to consider the problem in this way (we have mathematics hehe ;). It is a cute exercise to think about how it would look in YAML, but what does it ADD in value?

And if I adopt something cute / cool / elegant / simple clean without considering my client, I'm being a shit. Sure, I can go on about how elegant and simple the solution is ("this will make it easier to maintain") but one day I'll have to maintain this without it being in vogue. And if I can't find developers readily to do this, I've really let my vanity screw something up.

So. Personally, I'd go for something that has long-term value. This means adopting technology that maybe isn't as cool or elegant, but at least my client can still get people to maintain their systems even after my company got hit by a bus or something :)

For the record, I do consider the advantages of the nice technologies. But this is done at home, in my time, and should not influence my decisions regarding providing a service to my clients.

If anyone has any concrete examples of how YAML adoption (or any other lesser-used tech) has created a tangible benefit, I'd like to know. Please share :)

Gerrie Swart
Wednesday, October 8, 2003

> So. Personally, I'd go for something that has long-term value.

And so do I (as I've said all along).

But I do understand why people like technologies like Python, Ruby and YAML, and just saying that they're only doing it to be different, which is what Philo is trying to do, is *wrong*.

Furthermore, just dismissing new tech across the board as "fashion junkies" is a dangerous stereotype. Like many stereotypes, it has some basis in fact; but it's far from the whole story.

> You could argue "easier to write parsers for"

Did you even look at the examples? Or are you just talking out of your ass?

(Hint: Look at the YAML in 5 minutes tutorial on the Wiki. The "parsers" are already written; that's what the YAML implementations are. You simply use arrays and hashes to access the elements you want).

> Let's talk real life for a second

Sure.

I've worked a lot with really verbose XML manipulation code, and the possibilities for error are huge, just by virtue of the complexity. And that's *before* you add XSLT transformations! A simpler approach: less code, smaller documents, has the immediate virtue that *there's less to go wrong*.

This is not a *new* idea: almost immediately after XML was introduced, there were "simple XMLs" with *less* features, and "micro-parsers".

> the advocates of YAML have the burden of convincing me

Convincing people is a mug's game.

"My mind's made up, don't bother me with the facts!"

In any case, I'd rather convince the people reading the thread, than you.

Portabella
Wednesday, October 8, 2003

Portabella,
I understand your point about not using blanket definitions to ascribe motives to people.
I know most people like the cool tech because, it is, well cool :), fun, clean, a nice exercise, a lovely break from the tedious stuff at work.

My home stuff is like that, and my most frequently used tool is one of the evil things ;) mentioned in this thread. I'll not mention which, since I want to keep another religious war away.

What I'm interested in is: where does the cool stuff cross over into the realm of truly useful? When does it start adding value to non-tech people? What criteria do you use to assess the validity of the technology, and most importantly and most difficult: how do you know it will last long enough?

Gerrie Swart
Wednesday, October 8, 2003

"What I'm interested in is: where does the cool stuff cross over into the realm of truly useful? "

As soon as you do something useful with it, I suppose.
For instance, I recently wrote a UPC barcode scanning tool using Ruby. This was then used in a project where a client had to scan in 1000 barcodes.

"When does it start adding value to non-tech people?"

As soon as you do something useful with the technology. See above.

" What criteria do you use to assess the validity of the technology, and most importantly and most difficult: how do you know it will last long enough? "

The barcode scanner worked, so the technology was valid. I have no idea if Ruby will last "long enough" and I don't really care. It took about 4 hours to both 1) install and learn ruby and 2) write the barcode scanner.

I've noticed a weird attitude amongst some technical people (like philo, for instance) that somehow by exploring a new technology you are setting yourself up to be fucked for life if something goes wrong. Learning and trying out a new technology in real life is not the same as deciding to spend 12 years in medical school, then betting your life savings on a roulette game in vegas. It really takes not much time or money to learn a new technology and apply it, unless you are completely incompetent. Instead of ranting, it might be more productive to just try out various technologies for a few hours. If it doesn't work out, move on.

I've wasted more of my life in various traffic delays than I have experimenting with new technologies.

rz
Wednesday, October 8, 2003

"that somehow by exploring a new technology you are setting yourself up to be fucked for life if something goes wrong."

I'm all for exploring and trying out new stuff

The problem is that on projects which are not short prototypes (like you say, who really cares how it's done if its just 4 hours work), buying into a new technology long-term really does set you up for blame if it doesn't go well.

No one has mentioned the attraction of the Dark Side of the Force: neophilia as serving your own interest, instead of the business (I can hear the boos and hisses already). The project is crashing and burning, so you introduce C# and .NET. It still crashes and burns, but you walk out with new skills, to say nothing of Lessons Learned.

Let's face it, we often /learn by making mistakes/, and while seasoned pros can take the use-it-when-its-popular-enough stance, the way you get to be a seasoned pro is often by doing and trying -- and inevitably going wrong a few times. I certainly did :)

I personally would advocate sticking to tried-and-true for the core parts of projects, while allowing some innovation on parts of the project that are not terribly important.

If it's an internal application that needs some simple config files, using YAML may be perfectly reasonable. If you only spent a few hours on it, then /you can always change it to XML later/. It's a bit riskier than doing everything in the most well-understood way possible, but it also gratifies the desire to explore and try new things, in a harmless way.

Join Me, Luke
Wednesday, October 8, 2003