raganwald
Sunday, July 13, 2008
  My analyst warned me, but metaprogramming was so beautiful I got another analyst
Try to imagine a world where every programmer you know is a wannabe language designer, bent on molding the language to their whims. When I close my eyes and imagine it, I have a vision of the apocalypse, a perfect, pitch-black storm of utterly incomprehensible, pathologically difficult to debug code.
Jeff Atwood

Whereas I have a vision of a world not too much different than the one we live in today. A few people invent ridiculous things, incomprehensible things. Most people carry on doing what they’ve always done. And a few people invent new, worthwhile things that move us forward.

In my world, a few people inventing great things more than makes up for a few other people inventing ridiculous things. If we get Rails out of the deal, isn’t it worth giving Ick a bemused smile, tousling the creator’s hair and encouraging him to “keep trying?”

Jeff goes on to put some smart people on a pedestal, prostrating before their greatness. I admire them as well, but I don’t confer a priesthood upon them. Once upon a time, reading and writing was not something plebeians did. Even the bible was a closed book, you only heard what was recited in Church.

Does anyone doubt that democratizing the written word—through education and especially Gutenberg’s invention—has been a force for good?


I imagine that if we traveled back in time we would find monks bewailing what would happen if anyone was allowed to write. People—the monks would stammer—people might write doggerel! Pornography!! Graffiti!!!

But of course, they will also write beautiful things. And useful things. Like theories of Astronomy that violate what the priests “knew” to be true. And that is the point: if you leave things up to the priesthood, all you get is stuff that is neatly aligned with what they already know. You cannot make progress by subjecting new ideas to scrutiny in a committee, even a smart and well-educated committee. Maybe especially not a smart and well-educated committee.

If it were up to educated people, do you think there would be personal computers today?

Language design in programming is the same thing. Yes, it creates an opportunity for misunderstanding. Yes, you can make an amazing amount of trouble for yourself and for others. But to put it under lock and key in the Church where only the priest are permitted to mention it in hushed tones… this is wrong.

The message is clear: You and I are worker ants. We do not think. We do not question our tools. We simply use them as we are directed by those in control. I find that far more horrifying than just about anything else I can imagine coming out of giving people more freedom.

Come on. Really. Let’s get ahold of ourselves. As a wonderful movie’s last line went:

“You have to have a little faith in people.”
 

Comments on “My analyst warned me, but metaprogramming was so beautiful I got another analyst:
There are parallels here with Clay Shirky's "Here Comes Everybody". Now that meta-programming has become easily available to everyone (via JavaScript, Ruby, etc..) we're starting to see an increasing number of frameworks which apparently extend, if not re-write, their host language. On good days I'll confess to being a meta-programmer (however poorly), so I love this trend, but on bad days I'm with Atwood and start thinking fondly of Fortran where you couldn't do squat -- except "squat" worked, sometimes on the first compile. Fortunately I can delude myself into believing I have more good days than bad, so I'm with Raganwald.
 
I read Jeff's post first I could almost predict you'd write a response :)

I think you both make good points, but they have different perspective. I feel like Jeff is talking about the practical side of things where people making changes to a language in the context of a specific project is horrible.

You are saying in the grand scheme of things it's good to allow people to make these changes because at some point, some good will come of it.

You don't want someone to try and rewrite those astronomy books while they are taking an astronomy class. But they should definitely have the ability to contribute to them when it's appropriate.
 
I think Jeff Atwood manages to take a fundamental misunderstanding of what it really means to extend a language to it's logical bullshit conclusion.

He and many other people conflate standard libraries with languages over and over. Adding new methods to String does not change the language one bit! It doesn't change the syntax (even superficially like with macros), and it sure as hell doesn't change the semantics or the execution model.

If you can do it in the language itself natively and easily — if there's a fucking keyword for the mechanism of action — you're using the language, not extending it.

You're extending the language if you're modifying the parser / compiler / runtime or writing a truly new language inside another (it's not a 'DSL' if it's parsed naïvely as the host language). For almost all languages adding another ternary operator would count as the former, and things like LINQ count as the latter.
 
"Does anyone doubt that democratizing the written word—through education and especially Gutenberg’s invention—has been a force for good?"

A written book does not need to be maintained.

And usually a book is not rewritten. Think of people needing to rewrite Shakespeare. There are books written as wikis, but they don't invent their own words.

Thinking about that, most books don't invent their own words, or a least less than a percent of an percent of the words. And if one of the collaborative writers would invent his own grammar and words, I guess the effort would be doomed.

Software on the other hand is written by dozens of people at the same time.

"Adding new methods to String does not change the language one bit! It doesn't change the syntax (even superficially like with macros), and it sure as hell doesn't change the semantics or the execution model."

Well it does. When 50 developers add to String, you end up with 100 methods. That's not lean, that's not effective, it's more confusion I think.

We'll see in ten years when big Rails system hit the maintenance wall as Java applications hit some years ago. It wasn't a beautiful sight seeing Millions of lines Java apps hit that wall, my gut feeling tells me it will be much uglier for dynamic languages.

As I moved Perl and Python applications out of that trouble in the late 90s, I guess the is money to be made in a not to distant future.

Peace
-stephan

http://stephan.reposita.org
 
I'm never sure what to think of articles like Jeff's. I think he's wrong, but it doesn't really matter - nobody can prevent me from writing whatever code I want. Maintaining that right is important to me, but I don't feel like it's threatened, and certainly not by some random dude far away on the internet.

I'm in the give the convo a bemused smile and get on with my life camp.

To be clear though, this isn't to say that it isn't a convo worth having. I get how it's important and interesting to some people. The main value I extract though is learning of things I "shouldn't" do so I can go ahead and try them out :)
 
"The message is clear: You and I are worker ants. We do not think. We do not question our tools. We simply use them as we are directed by those in control. I find that far more horrifying than just about anything else I can imagine coming out of giving people more freedom."

This statement (for me) made the printing press analogy (and the wonderful Stephen Fry video) a bit ironic. All those books, published in English, used the same language.

I will readily admit that the language itself has evolved (Shakespeare made up several words in common usage today), however most of the basic syntax and grammar remain unchanged.

I think the larger point is that languages should be extended and modified in subtle ways that allow them to be more useful as they evolve, but mucking about yet another String method is often an exercise in futility.
 
Stephan, you are wrong about hitting maintenance wall. Lisp and Smalltalk systems appear to have been running fine for a long time and many of the Lisp/Smalltalk shops must have dealt with the problems of dynamic languages before, and hey, maybe some of them even wrote about the experience so that the unwashed masses (Java/C#/new-dynamic languages programmers) can learn from them!

Those who fail to learn from history are doomed to repeat and I'm very certain this argument about monkeypatching has been played out many times over, 20+ years ago.

By the way, Perl and Python aren't very well-designed, so it isn't saying much that they hit a wall.
 
The one aspect of the ongoing monkeypatch discussion that's always troubled me is that those who seem to complain loudest about it put the onus on the wrong person to be responsible for the management of it. Jeff does as well:

"I was just looking at random PHP plugin code the other day, and it was, frankly, crap. But that's because most code is crap.... I can only imagine what that PHP plugin code would have looked like, had its developer been granted the ability to redefine fundamental PHP keywords and classes at will."

So can I, and were I thinking of using it I'd be inclined to read the code and discard it if I didn't like what I saw.

The onus of responsibility is not on other developers to make the code you use conform to your whims, it is on you to only use code that you like.

Other people's monkeypatches do nothing to my codebase unless I let them (and to those who proclaim "I can't possibly be expected to understand _all_ the plugins and libraries I want to use!" I suggest to you that is tantamount to signing a waiver accepting all personal liability.)
 
I read Jeff's post first I could almost predict you'd write a response :)

Disclaimer;: I consider the Raganwald and Coding Horror blogs to be Frenemies: we pretend to disagree on a great many things, but the debate serves to further our common objective of getting programmers excited about programming.
 
Atwood (and a few others) are self-proclaimed priests (masquerading as industry professionals). A fellow armchair-philosopher and programmer has proposed a description of "misintegrator" (see Peikoff's D.I.M. hypothesis).

After all, has Jeff ever really used or studied any relatively advanced or deep programming language? Any related theory at all? The answer is a resounding no. Simply do not assign these guys any authority in your own mind and move on. I bother with this comment because I know you're smart enough; don't be sucked in.

The parallels to religion do not end here though - not by a long shot. Do you know about the ever-common problem of the rationalist skeptic making a public refutation against the pseudo-scientific nonsense? Watch what happens next.
 
I'm with Chris here. Take responsibility. Read the code of the plugins you're about to use. Read the tests. Change it - it' open source after all - or don't use it, if you don't like what you see.

As a good side effect you might even learn something while reading other ppls code.
 
Awesome. Perfect response. Jeff's post makes me think of this scene from Remains of the Day:

http://youtube.com/watch?v=CWuVDxD5SnI

Quod erat demonstrandum
 
This statement (for me) made the printing press analogy (and the wonderful Stephen Fry video) a bit ironic. All those books, published in English, used the same language.

Except that during the time when only the priests wrote books, all the books were written in Latin.

If you want to take this metaphor further, think of Robbie Burns and Langston Hughes.
 
When 50 developers add to String, you end up with 100 methods. That's not lean, that's not effective, it's more confusion I think.

I agree wholeheartedly that a culture of relentless unscoped monkepatching by amateur asshats (like what's going on with the Rails people) is unsustainable. It can rape the standard library that other programmers expect.

But it does not change the language at all, even to the extent that macros or templates do — it's fully a feature of the language, not an extension of it.
 
Well, I think you're both right from different perspectives. OO programming dictates that you do not need to, nor should you attempt to understand how the object you are using works. Its like me using my car. My carburator and transmission work, and I don't care why, nor am I going to take the time to find out. It seems like the opposite of this are the motor heads that buy a car and instantly start tweaking with the manufactured product out of box in order to tweak some extra performance gain by changing a few things. It depends on what you are comfortable with. I can see Jeffs point in that if you take a standard library, and make it non-standard what is the point? Then the other camp takes the out of the box functionality and tweaks it for WHAT WORKS FOR THEM, and then everyone else can take it or leave it for what it is.
 
To blame for metaprogramming capabilities of a language for a mess one may end up with is typical but misguided. If you give a razor to an ape, the results may turn out messy, but the razor is hardly to blame.
It would be more productive to fight ignorance and absence of common sense in IT than to pick another pseudo-guilty party du jour.
 
Couldn't agree more: leaving things to the priesthood is a bad thing. In programming, technology, politics, the economy (communism, anyone?) and culture.

As I wriute this I am reading St. Augustine's "Confessions". Lighten up, man!
 
I've actually been bitten by this sort of thing, when an asshat co-worker altered the behavior of some core Rails classes without telling anyone. It broke a couple of library methods I needed, and the errors it produced were very obtuse. I ended up finding a workaround for it so that I could at least get back to work.

A few days later he fixed the broken code, which blew up my workaround... which is when we finally found out what he'd done.

I personally think that allowing monkeypatching will inevitably do far more harm than good, because we have too many low-quality programmers out there writing low-quality code and playing with nifty language features because they're nifty.
 
Rakesh:

See now, while I am far more optimistic than you are about my colleagues, I am far more pessimistic than you are about the people you call “low-quality programmers out there writing low-quality code:”

To me, there is no restriction on language features to save you from such people. Tech will not solve people problems: you need people solutions such as training people, motivating people to want to learn, and yes, selecting people you can trust a little.

Such measures will not work for all of the programmers, all of the time, but I suggest to you that nothing works for all of the programmers, all of the time.

Technology is in a race with the Universe to create bigger and better idiot-proof devices, while the Universe is trying to create bigger and better idiots. So far the Universe is winning.

In my experience, idiot-proof programming tools fall under the umbrella of “devices.”
 
"Technology is in a race with the Universe to create bigger and better idiot-proof devices, while the Universe is trying to create bigger and better idiots. So far the Universe is winning."

One of the best quotes on technology that I've read in a long time.
 




<< Home
Reg Braithwaite


Recent Writing
Homoiconic Technical Writing / raganwald.posterous.com

Books
What I‘ve Learned From Failure / Kestrels, Quirky Birds, and Hopeless Egocentricity

Share
rewrite_rails / andand / unfold.rb / string_to_proc.rb / dsl_and_let.rb / comprehension.rb / lazy_lists.rb

Beauty
IS-STRICTLY-EQUIVALENT-TO-A / Spaghetti-Western Coding / Golf is a good program spoiled / Programming conventions as signals / Not all functions should be object methods

The Not So Big Software Design / Writing programs for people to read / Why Why Functional Programming Matters Matters / But Y would I want to do a thing like this?

Work
The single most important thing you must do to improve your programming career / The Naïve Approach to Hiring People / No Disrespect / Take control of your interview / Three tips for getting a job through a recruiter / My favourite interview question

Management
Exception Handling in Software Development / What if powerful languages and idioms only work for small teams? / Bricks / Which theory fits the evidence? / Still failing, still learning / What I’ve learned from failure

Notation
The unary ampersand in Ruby / (1..100).inject(&:+) / The challenge of teaching yourself a programming language / The significance of the meta-circular interpreter / Block-Structured Javascript / Haskell, Ruby and Infinity / Closures and Higher-Order Functions

Opinion
Why Apple is more expensive than Amazon / Why we are the biggest obstacles to our own growth / Is software the documentation of business process mistakes? / We have lost control of the apparatus / What I’ve Learned From Sales I, II, III

Whimsey
The Narcissism of Small Code Differences / Billy Martin’s Technique for Managing his Manager / Three stories about The Tao / Programming Language Stories / Why You Need a Degree to Work For BigCo

History
06/04 / 07/04 / 08/04 / 09/04 / 10/04 / 11/04 / 12/04 / 01/05 / 02/05 / 03/05 / 04/05 / 06/05 / 07/05 / 08/05 / 09/05 / 10/05 / 11/05 / 01/06 / 02/06 / 03/06 / 04/06 / 05/06 / 06/06 / 07/06 / 08/06 / 09/06 / 10/06 / 11/06 / 12/06 / 01/07 / 02/07 / 03/07 / 04/07 / 05/07 / 06/07 / 07/07 / 08/07 / 09/07 / 10/07 / 11/07 / 12/07 / 01/08 / 02/08 / 03/08 / 04/08 / 05/08 / 06/08 / 07/08 /