Ending the Era of Patronizing Language Design
blog.objectmentor.com
blog.objectmentor.com
C++ coddles programmers and Ruby doesn't. Really? That sounds like a sensible thing to say?
C++ avoided reflection because it would be misused by programmers? Only a profound misunderstanding of the design goals of C++, or having never actually used it, could inspire such a claim.
ActiveRecord is a Rails innovation that took decades to realize? What? Why would you think this?
because:
a) You're awesome, as long as you're using Ruby no matter how ridiculous you look when seen without rainbow colored glasses - http://www.infoq.com/presentations/ford-large-rails
b) The "you're doing it wrong crowd" will shout you down the moment you admit having troubles - http://glu.ttono.us/articles/2007/04/15/on-twitter-rails-and...
c) Most failed Ruby (which in all fairness usually means Rails) projects never gain any publicity.
d) Ruby projects coming close to the gargantuan scope of some of the bigger Java projects are (thankfully) exceedingly rare (if not non existent).
Lastly I had no clue that Saeed al-Sahaf is now working for Object Mentor, awesome!
Disclaimer: I worked for 3 years as a Ruby developer, including on one of the bigger (> 50.000 loc) Rails projects out there and I encountered some crashing and burning myself (I know I did it wrong).
From what I've read plenty of people have done just that in Ruby because of monkeypatching.
Rubyists most certainly DO hang themselves with monkeypatching, quite often. You just don't tend to hear about the ones that to that, because the sites they build that way don't survive long enough for anyone to notice, assuming that they even launch them successfully, which is rare.
I think in fact that because Ruby is a much more forgiving language than, say, C++ (the same goes for Python), the average caliber of Ruby developers is FAR lower than the caliber of, say, C++ and Lisp developers. My experience with Ruby and Python developers hasn't been positive -- in fact, working at a Python shop gave me an intense distaste for the language, and my experience at a Ruby shop lead to similar sentiments among a lot of the senior developers who worked there.
Oh, and having interviewed C++ developers, I am not sure I can agree that the average C++ programmer is of higher caliber than the average Ruby programmer. C++ is something that these people learn because they think they will get a high-paying job in the financial sector. Ruby is something people learn because they think programming is cool. (Admittedly, the Ruby community's aggressive marketing has gotten a lot of people that shouldn't be programming into programming, and that's bad for their community. But wanting to be a cool Rubyist like _why causes a lot less damage than wanting to have a high-paying job.)
Anyway, Ruby is fine when used by someone with a clue. C++, not so much.
In my experience this is a myth or a at least a stereotype more prevalent in the marketing of Rails than reality.
I had the strong impression during my stint in the Rails world that Ruby was mostly learned as a signaling device. Young developer slaving away at some random Java or PHP job dreaming of making it big in a startup, with the mistaken believe that simply hanging around the in-crowd will magically catapult him in the top 5% of their profession.
Sure there are good people in this community, but they became good by working hard for a very long time and not by writing a trivial Twitter client using the currently hot testing framework/NoSQL database on their MacBook Pro in a Starbucks after skimming through the pick axe book.
wanting to be a cool Rubyist like _why causes a lot less damage than wanting to have a high-paying job
Why should chasing fame be inherently better than chasing money?
Just speaking from my own experience, I learned way more from cynic mercenaries than from wannabe rockstars and I can't see why emulating e.g. Obie Fernandez will cause less damage than aiming for a position as a technical fellow.
I'm not confused at all. Rubyists sunk the project, plain and simple. I actually still like Ruby, because I had a chance to do some cool stuff with it before our inferior rubyists wrought their havoc, and I agree that had we had decent management, they'd have been fired.
My only criticism of Ruby is that because it's easy, it allows vastly inferior programmers to program, which lowers the bar drastically. I believe that a number of the other senior developers there won't touch ruby at all now, I'm not one of those.
However, given one of the jobs I received e-mail about, I'd say that the salaries that rubyists can get puts them in the worst of both worlds -- it attracts people who want to be cool, and people who want high-paying jobs. Plus, it's easy to learn badly, which sets the bar very low.
Wrong. Every language allows this. Have you ever read enterprise Java or C++ code?
Ruby programmers get themselves into plenty of trouble. Of course, so do Java programmers, or any other programmers. The problem is people, not programming language features. (Except manual memory management, as per C. That's a language problem.)
Than you seem to have had much more luck than I did.
Some succeed, some fail.
Rather like using pointers, in most ways, which can also cause some pretty unmaintainable messes, but don't if you're really, really careful :-)
Your argument seems to have a slight inconsistency.
Tends to be the people who think of modifying open classes as "monkeypatching" who fuck it up because they still see it as some sort of quirk in the language rather than just another part of the language ecosystem.
I would much rather do something the wrong way and be burned by it (and probably learn a lot in the process), than be prohibited outright from using certain techniques.
Edit: To quote a great comment on the article,
> Invariants make software more reliable. Weaker languages have stronger invariants. There’s less stuff to test.
The truth, from the language designer and compiler author's perspective: programmers should be protected from their own worst instincts, and programming languages that do this well are of a higher quality than languages which don't. Patronizing, to a point, is good. The flip side is that features whose use should be encouraged should be included in the box, turned on by default, made easy to use, etc.
Ruby is patronizing because it's memory safe. C and C++ programmers don't like this kind of patronization. Ruby, and Python, are unlike C and C++ in this way: they are rigid and uncompromising in their type safety, disallowing unsafe casts and operations.
Michael makes some category errors in his rant. For example, he says:
"[...] we’ve made the assumption that some language features are just too powerful for the typical developer -- too prone to misuse. C++ avoided reflection"
The problem with this abutment is that C++ avoided reflection in its quest for power (or what C++ users thought was power), rather than its avoidance of power: C++ users wanted to hew to a philosophy of pay only for what you need. The problem with that philosophy is that if you make certain features optional, or pay as you go, then the community in general cannot assume that everyone is using available features. Instead, third-party library authors must assume that only the lowest common denominator set of features is available if they want to maximize usage.
Java and C# have avoided multiple inheritance for good reason; and Michael's rant is not a good reason for them to reintroduce that feature, because it remains problematic.
"The newer breed of languages puts responsibility back on the developer"
This is simply untrue, and bizarrely myopic, in my view. The developer always has responsibility, but the responsibility has shifted to different places, as the emphasis on abstraction level in programming languages has shifted. To take Michael's thesis at face value, you would need to believe that C mollycoddled the user and didn't bite their fingers off when they didn't take care of their pointers, or carefully handle their strings, or foolishly used fixed-size buffers for dynamic input.
Of course C put responsibility in the hands of the developer for these things. But guess what? Ruby, Python, C#, Java etc. all take away responsibility from the developer for these things! Michael says that dynamic languages like Ruby hand over the power of monkey-patching etc. to the developer, and that this is a new development; but to get equivalent power of dynamic behaviour overriding in a C application, you'd be using very abstract structures, likely looking like a Ruby or Python interpreter behind the scenes, where you would have a similar degree of responsibility. But not only that; you'd also be responsible for the dynamic runtime, as well as the memory management and all the other unsafe stuff that comes with C.
In fact, it was behind a lot of Java's decision to take that power out of the developers' hands. I would argue that Java was an overreaction. It corrected the safety issues, but also removed a lot of the ability to create abstractions. Want a global variable? Those are bad, don't use them. Want multiple inheritance? That's bad, don't use it. Want operator overloading? That's bad, don't use it.
The problem is that the fact that those things are bad in some cases (even arguably most cases), doesn't mean they should be forbidden. I know what I'm doing. If I want to use a global variable I should be able to. I know what I'm writing. The language designer doesn't.
In other words, to make a long story short: I don't think he was trying to say that responsibility needs to be in the developers' hands in all cases. But I think that he makes a valid case that newer languages are right in moving some of that responsibility back to the programmer.
Multiple inheritance and operator overloading aren't bad, but at the time Java was designed, nobody had any idea how to use them properly. Python 2 gets MI right (though Py3 fucks it up a bit with magical super()), and Haskell provides a clean implementation of overloading, but it'll be years before these improvements filter through to Java (if they ever do).
Really? I was coding C++ using multiple inheritance and operator overloading around then, and AFAICT was using them properly.
It's not hard to figure out a better the way to do it than not doing it at all with a few hours thought. And in fact Dylan got both multiple inheritance and operator overloading right before Java existed.
Method ordering is the most significant problem with multiple inheritance. You arrive at the simple (just use the lexical ordering of the superclass list) or the more complex (Dylan's method ordering, now also in Python) purely by reasoning logically. I'm pretty sure someone like Guy Steele would be able to figure this out.
Operator overloading: what could possibly be worse than x.multiply(y)? You either have a fixed list of operators that you can override by defining a method in a class, or you have an expandable set of operators for which you can specify the precedence and which way it associates. This is not a hard problem.
The human element ranges pretty far, from the neophile trying to grasp every piece, the seasoned veteran evaluating a new language, the maintainer considering what part to improve, or what patch to consider, and so on.
Not every lawn needs a thousand pink flamingos, even if they're better than no flamingos at all.
I think this is an example of the kind of reasoning Feathers was talking about. Perhaps it did make sense at the time, but that's largely irrelevant. What is relevant is that the idea that programmers aren't capable of making decisions on their own isn't a good idea these days.
For example, if anything might be a pointer and you can point to an offset inside a struct, then you can't have deterministically perfect garbage collection and you can't have garbage collection that moves things, for example to compact the heap. Java solves this by only allowing references to "the top of" objects, and stopping you casting pointers. Consequently, Java's runtime knows what's garbage and it can move things around with impunity.
Or consider Clojure, where immutable data means that you can grab a snapshot of a value without read-locking.
More rigid languages don't lead to less astonishment under complexity. A given line of code may contain less astonishment, because there are fewer possibilities for what it might be doing, but what matters is global understanding, not local. The meaning of a program is not the sum of the meaning of its parts. Otherwise we'd all be writing in assembler; it's easy to say what this is doing, locally:
mov eax, [ebp + 8]
But the set of problems for which a well-behaved and consistent program is readily writeable is not the same for all languages.
But this is just wrong-headed thinking, to my mind. UI definitely influences user behaviour. One thing currently in vogue is game mechanics; the whole point of using game mechanics in your UI is to encourage certain kinds of behaviours, and it works, dagnabbit! Most UIs that have any coherence to them at all have a way of working with their grain, and many more ways of working against their grain. If they're good UIs, working with the grain ought to reduce your non-essential work load and make working a pleasure. If they're poor, you'll have to work against the grain, fighting the design, to get your job done.
Programming languages are directly analogous to this.
However, the two specifics we're talking about are well-behaved code and consistent code. Most language in theory make it ridiculously easy to re-use code, to make code DRY. Languages like Ruby actually give you more tools for making code consistent than languages like Java.
Yet, there is a lot of awful Ruby code and some elegant Java code. I've seen some amazing assembler code. It seems that somehow languages don't seem to have a lot of influence over what we might call architecture.
Perhaps the issue is that languages are hand tools, but programs are cathedrals.
p.s. If I had to bet, I'd say there is more of a correlation between languages and architecture than a causal relationship. Paul wrote about this some time ago: http://www.paulgraham.com/pypar.html
My instinct suggests instead that languages differ as to the standard deviation of quality of code written in them.
The problem with saying "you can do things in whatever
way you want in Ruby" is that the moment you have more
than one developer it collides rather drastically with
the "principle of least astonishment".
Not every problem requires a technical solution. Social solutions often work just fine.
One of my favorite stories is we had hired a bright young dev many moons ago. Months into his work we were trying to fix this terrible memory leak, and it looked like most of it was coming from his code. We asked him, "Where do you free this memory, we can't find it anywhere -- you clean up everything else." His response, "Wait, how do you free memory?"
You live, you learn. We picked it up remarkably quickly in the end, basically because the company had their process working right: clean codebase, solid testing, and regular code reviews.
Or do you really write monolithic 1M+ line apps?
http://www.vanderburg.org/Blog/Software/Development/sharp_an...
The money quote here is this:
"Weak developers will move heaven and earth to do the wrong thing. You can’t limit the damage they do by locking up the sharp tools. They’ll just swing the blunt tools harder."
Which is so very, very true in my experience.
Designing a language around the idea of protecting weak developers from bad choices is a recipe for failure and mediocrity. Instead, look toward designing in a way that guides experienced or at least thoughtful developers toward greater success.
tl;dr: Don't make bumper cars for people who can't be trusted to drive, make nomex suits and roll-cages for race car drivers.
Langauges like, say, C# are complicated _and_ patronising. That's the sort of language I thought the article was comparing Ruby with.
Yes, he was. In a way, though, isn't Dijkstra's sort of "designing for simplicity" and even the goal of making a language "easier to understand" the very definition of "patronizing"?
I also don't find a goal of "easier to reason about" particularly patronising; it makes the rather un-patronising assumption that the target audience is willing and able to reason about the matter at hand.
The language features I find patronising are the ones that make it hard to do things a certain way, regardless of how carefully considered my reasons are.
Any in particular that you have in mind? Historically, many people have had very carefully considered reasons for using features like goto, type puns, etc. but many languages exclude them as problematic. Is it patronizing to exclude such features even from the toolbox of programmers who carefully consider their use?
In answer to your second question, I think it depends. Including gotos in a language is problematic for reasons other than the fact that programmers tend to misuse them. I think it comes down to the rationale. With the C# feature I mentioned, the stated reason was, inter alia, that programmers tended to misuse inheritance. I found that patronsing. That leaving out goto makes it easier to formally prove a language correct I do not. Leaving out goto because programmers tend to misuse it, that I would find patronising.
> My current least favourite patronising language feature: in C#, you can only override a method if the base class lets you.
My recollection from the design of Java is that such "finality" is necessary to allow the type system to reject code that attempts to override security-sensitive methods: is that not still true of C#?
> I think it comes down to the rationale. With the C# feature I mentioned, the stated reason was, inter alia, that programmers tended to misuse inheritance. I found that patronsing.
What of a language that eschews inheritance entirely, both because it makes reasoning about software more difficult and because the vast majority of programmers cannot use it correctly?
"Patronizing" seems to indicate that a designer considered himself smart enough to use a feature, but determined his "subjects" were not. What of designers who recognize their own limitations and remove features they know to be error prone in their own practice of programming? Is that still patronizing, or does it deserve a different descriptor?
That's still true. The "feature" I has in mind is that methods in C# are not virtual by default. This is in direct contrast to Java where they are. This interview has a discussion on the motivation behind this (IMO incredibly tiresome) feature: http://www.artima.com/intv/nonvirtual.html.
My view is that the real issue is that inheritance is all too often used when composition is more appropriate, which problem this change does nothing to help.
> What of a language that eschews inheritance entirely, both because it makes reasoning about software more difficult and because the vast majority of programmers cannot use it correctly?
If it only makes the language better for "bad" programmers, I would consider it patronising. It also comes down to the intent of the language designer, by definition.
> "Patronizing" seems to indicate that a designer considered himself smart enough to use a feature, but determined his "subjects" were not. What of designers who recognize their own limitations and remove features they know to be error prone in their own practice of programming? Is that still patronizing, or does it deserve a different descriptor?
I think that's worthy of a different descriptor. A failure to anticipate the needs of programmers who are smarter or more disciplined or whatever - which is what such an omission seems like to me - may be a problem, but I don't see it as patronising.
Like the creators of sitcoms or junk food or package tours, Java's designers were consciously designing a product for people not as smart as them. Historically, languages designed for other people to use have been bad: Cobol, PL/I, Pascal, Ada, C++. The good languages have been those that were designed for their own creators: C, Perl, Smalltalk, Lisp.
From here: http://www.paulgraham.com/javacover.html
To me that's the definition of building a language for yourself. You actually write a language that you need to solve a specific problem you have.
And I find his categorization of good vs bad languages somewhat absurd. What actually makes Ada, C++, and Pascal bad? His lack of understanding? What makes C, Perl, and Lisp good? The inverse?
While I have my own personal prefernces with respect to languages, I fully believe a large part of it is familiarity. I've NEVER met anyone who could argue why a particular language was truly bad. They usually are just passionately arguing religion, and I find that tiring. It was cute when I was in high school, but those debates are getting tired.
[1] http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html
With C, for example, there's a predefined model for the callstack based around having a fixed set of arguments for function calls and singular return values.
Forth, on the other hand, treats words as simple nested subroutines, keeps data on a global stack, and lets the data carry over from one word to the next. No explicit arguments or return values are necessary.
C can be characterized as "safe," while Forth is "flexible," depending on your use case, but in terms of pure performance both models have strengths and weaknesses.