All Languages Are Created Equal?
By Alex Bunardzic under Languages on 27. December 2005There seems to be a big disconnect between the bureaucratic-minded developers and the so-called hackers (’hackers’ in Paul Graham’s sense of the word). This disconnect is getting exacerbated lately by the explosive success of the hackers’ business model (witness the juggernaut that is Ruby on Rails, 37signals, etc.)
Bureaucrats obviously dislike languages that require thinking. Bureaucrats prefer to migrate expertise from the individuals and into the prescribed ’system’ (by prescribed ’system’ we mean faceless, nameless policies and procedures). This is precisely why bureaucrats insist that only languages such as Java and C# are worthy of their attention. They despise any languages that cannot easily be offloaded onto some mechanical device, such as Eclipse’s Modeling Framework, or onto some overseas organization.
Hackers on the other hand tend to despise any mechanization, or industrialization of the process of creating software. Hackers are not buying into the possibility of drawing a picture that could be used to generate the machine executable code. Real hackers know that programming is like higher mathematics — it’s too abstract to be ever faithfully expressed visually.
What’s interesting is how bureaucrats use FUD to push forward their agendas. First they insist that all programming languages were created equal. After all, it’s all ones and zeros, so what’s the big fuss?
But then they turn around and claim how all languages were actually not created equal, because in Java we have the pinnacle of simplicity — in Java, you can do something in one, and only one proper way (so, the simplicity in Java turns out to actually be rigidity). The FUD bureaucrats are spreading is so lame, so desperate, that it would be hilarious if it wasn’t so bloody damaging to our industry.
It’s definitely going to be an uphill battle for the hackers. I firmly believe that creativity will, in the end, win. But lots of people are going to try and kill creativity, no matter what the price.
I predict that it’s going to get very ugly. Much uglier than it already is. The time is slowly coming for us to make the decision — are we going to support the creative way of doing it, or the bureaucratic way?
Chiaroscuro:
It’s not that the hackers don’t like mechanization. Hackers love mechanization since it frees up brainpower for the really creative issues. The problem with the bureaucrats is that they mechanize the wrong things: they make processes out of things what should be left agile and they don’t mechanize what could easily be automated :-)
comment at 27. December 2005
Bob:
Not having seen the pro-Java arguments Alex has in mind, it is hard to judge the accurracy of his analysis of their rhetoric. But I don’t believe I’ve ever come across someone who thought that Java and Ruby were fundamentally much the same (in the way that, say, C and Pascal are). Nor do I recall being able to do something “one - and preferably only one - obvious way” being a touchstone in the Java world.
However, these points do bring to mind recent arguments on the relative merits of Ruby and a certain other language. Is there an antipathy that dare not speak its name, Alex?
comment at 27. December 2005
Kevin Smith:
I also have not heard “only one way” as being a commonly cited advantage of Java. I keep hearing about “scalability” and “maturity”. It would be great to see some links to the FUD that led to this blog entry.
The battle, it seems, is more about agility vs. control; about small teams vs. large; and about (elegant) simplicity vs. (needless) complexity. Once you win those battles, it’s a lot easier to win the battle of language.
comment at 27. December 2005
M Lauer:
The maturity level in the blogosphere is about 9 years old on a good day. Now we have a battle between control-minded bureaucrats pushing Java and freedom-loving scripters fighting for truth and sunlight. Puhleeze! I was told when I was getting my CS degrees that I would wind up working for CIS types, and now I see why: you can’t leave decision making powers in the hands of demented little freaks like this.
There are lots of good areas on which to debate the virtues of various languages: as a current Python developer who has been a certified Java programmer since ‘97, I can see and make arguments all along the spectrum. As a development manager with current projects in Java, Python, and C++, I can assure you that different languages are optimized to solve different sets of problems in different areas, so the trick is to pick the right one for the job, considering all the relevant factors.
In the meantime, for God’s sake, please grow up!
comment at 27. December 2005
Greg:
Deep down, both hackers and “bureaucrats” really know the truth, but are afraid to admit it — that all programming languages stink. Take this challenge: find a paragraph of your code, in any language, that you are really proud of, as a hacker. Show this code to someone who has never seen it before, and time how long it takes for that hacker to really grock it, to the extent that the code can be modified in some way. When we have programming languages that can be read and grokked as fast as natural languages, then we will have progress.
comment at 27. December 2005
Alex Bunardzic:
Kevin Smith wrote:
That’s also a very important aspect, although it’s more about the logistics. Yes, the logistics are important, but once we’re settled on it (settled on the team size, on the level of desired simplicity, agility etc.) we’re still open for debate on how creative do we want to be.
Most bureaucrats I’ve worked with favor the push-button ’solutions’. If we could arrange to have a button pushed, which would somehow generate the implementation (be it by using some code generating framework, or some code generating Indian company), we’d be laughing on the way to the bank.
Hackers, on the other hand, argue that the push-button ’solution’ cannot help but be inferior. It is superior in the bureaucrats’ minds because it is predictable. But hackers ethics is that predictability is not desirable. Instead, they favor unpredictability, which is just another word for creativity.
Hackers are the renegades in this battle. No one can predict what unpredictability will bring. Bureaucrats are scared poopless at even the slightest possibility of such a prospect.
My argument is that without embracing unpredictability, we won’t be able to advance the quality of our offerings. And I’m convinced that the bureaucrats will fight this introduction of unpredictability every step of the way.
comment at 27. December 2005
Chiaroscuro:
I agree with Greg.
Readability is also an issue of control. Can you control (read, change) the code that you have got? Bureaucrats look for ‘control’ by settling on some standards, hackers are always striving for better forms of ‘control’ often leaving behind them a trail of different ’styles’ and approaches to code. This is certainly good for personal development, but I still have to decide if it is a good thing from the point of view of a company.
How would you guys decide for the right trade-off between continuous innovation and stability in a project?
comment at 27. December 2005
beza1e1:
In Leadership courses i heared of three phases for projects and there are different types of leaders needed. Perhaps this applies for languages as well. Then the solution would be different languages, which can be compiled to one another.
The leader types would be: Innovator/Loonatic, Negotiator/Perfectionist, Preserver/Ultraconservative
In Programming Languages: Ruby/Python, Lisp/C, C++/Java
While Upper Management is mostly busy in stage three(Big Corporations), Hackers (especially in Grahams sense) are in stage one (Startups). Probably M Lauer is in between - stage two: Use the best tools for the job.
comment at 27. December 2005
Alex Bunardzic:
Greg wrote:
While I absolutely agree with you, I don’t think this is really an issue. To me (being a musician), it’s the same as saying that each and every music notation known to man, sucks. Yes, it’s true, there is no perfect music notation (each notation system manages to miss incredibly huge vital portion of the music); still, we have no other recourse but learn to use the music notation of our choice.
Same is with programming languages — they are an approximation of the way we think in abstract terms. Far from being perfect, but we have no choice but use them.
I wouldn’t hold my breath waiting for some future programming language that will read like a natural language.
comment at 27. December 2005
Alex Bunardzic:
Chiaroscuro wrote:
All the bureaucrats I know seem to not feel this is an issue at all. For example, all the bureaucrats love using products such as Microsoft Office, SAP, PeopleSoft, etc. How readable are those products? They are 100% opaque, since they are protected, under the death penalty threat, by the law. No one in the world is supposed to read them. We’re all supposed to take them at a face value and cherish them.
In my company, continuous innovation is the only guarantee of the stability in a project.
comment at 27. December 2005
Greg:
I’m glad you made the music reference. First, I think that music notation sucks much less compared to programming languages. For one thing, the music folks have had several thousands years to work on their notations. For another thing, music notation has a rich typography that transcends the linear ASCII notation of all serious programming languages.
Just to be clear, I’m not advocating programming in a natual language. However, all the languages mentioned above are so fundamentally similar to each other, that it is just silly to be arguing their relative merits. The fact that hackers get into these endless languages wars though is a result of deeper, more fundamental issues.
comment at 27. December 2005
Alex Bunardzic:
Greg wrote:
Yes. These issues are as follows: there are programming languages that are tailored toward producing repeatable results. And then there are programming languages that are more tailored toward producing novel results. In other words, some languages change the ways we think about the problem domains.
The language wars you speak of are merely symptoms of the much deeper repeatable/unpredictable war going on. Some people feel uncomfortable if the solution offered to them is not necessarily easily repeatable.
For example, DHH came up with an innovative solution (Ruby on Rails) in a very unpredictable manner — he first developed Basecamp, and then went back and extracted Ruby on Rails from it. What made that bravado possible is Ruby (he wouldn’t have been able to accomplish that using PHP or Java, and not for the lack of trying).
How repeatable is that process? Can David now predict with any degree of certainty that the next product he develops will be again used for extracting a brand new and a very innovative framework?
comment at 27. December 2005
Chiaroscuro:
Alex, now you are talking about products and not languages.
In most cases products don’t need to be readable and I can more easily accept (and sometimes actively welcome) standardisation in this case. When we are talking about languages it’s a whole different issue.
You use languages to provide for new business requirements within a company. In this case the faster you do it without losing face due to stupid errors, the better it is. If the problem is new and not trivial faster usually means star developers with dynamic languages and test-first design. That’s the way I have seen it done in the finance and telco industry.
In the end, as you say, the only way to guarantee stability is to innovate continuously. A business that doesn’t change (that cannot change!) quickly is also a dead business.
In the Red Queen Country “it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!” :-)
comment at 28. December 2005
Aristotle Pagaltzis:
Hogwash.
comment at 28. December 2005
Greg:
Huh? The history of programming language design is ripe with examples like this. Stroustroup developed C++ because he was trying to write simulation code in C, and didn’t have Simula. Then he created cfront as a standalone entity. The Java folks developed it because they wanted to code for mobile devices, and C++ wasn’t cutting it. Later, they realized the language had more value than their gizmo. Larry Wall developed perl after building a version management system based on usenet news with it.
And please stop using the “i” word. Microsoft has killed it for everyone.
comment at 28. December 2005
Alex Bunardzic:
Greg wrote:
No one can kill it for me. And if we now stop using the “i” word, then clearly the terrorists have won.
comment at 28. December 2005
benoitstpierre:
Category theory is quite abstract and can be faithfully expressed visually. This is an old myth : syntactic tools are not (that much) more expressive than graphical ones. Humans tend to like the use of both : one has just to open an illustrated dictionnary to remember it. A diagram is not just visual, anywho. Maybe the author wish to say that real hackers are gifted in abstraction, so do not need to visualize.
A Real Programmer would say that GUI is not even useful. Since a Real Programmer would never consider writing in Pascal, why would care for Less Code ? Maybe the author wished to say that an agile thinker would never try to model before trying to code directly, maybe even litterally.
Less coding requires the acceptance of our limited rationality. Bureaucrats try to rationalize their way down. They tend to forget we are not well equiped to work that way. Besides, this is just to risky : I would not invest a minute in a project that could lead to nowhere ?
comment at 19. January 2006