Summary
Dumbing down the language by not providing more powerful expressions is a way of promoting to a wider audience. However, is it the only way of supporting communities?

Advertisement

Matt Quail writes about the new complexities of JDK 1.5 extensions. He points to this blog which quotes:

The real point is that LFSPs (Language for Smart People) have a much greater support for abstraction, and in particular for defining your own abstractions, than LFMs (Language for the Masses).

Half a year ago a few bloggers made the recomendation of adding Hygienic Macros into Java as an alternative to adding language features piecemeal. We received this response from Gilad Bracha, the resident Computational Theologist at Sun.

Thanks for the suggestion. Yes, we do know what macros are, and we may have even heard of Lisp. Seriously, some formulations of macros are well structured enough to prevent the onerous kinds of abuse that have given macros a dubious reputation in the C culture.Nevertheless, we don't plan on adding a macro facility to Java any time soon. A major objection is that we do not want to encourage the development of a wide variety of user-defined macros as part of the Java culture.

He goes on further to explain what he means by Java Culture:

The advantages of Java is that it easily serves as a lingua franca - everyone can read a Java program and understand what is going on. User defined macros destroy that property. Every installation or project can (and will) define its own set of macros, that make their programs unreadable for everyone else. Programming languages are cultural artifacts, and their success (i.e., widespread adoption) is critically dependent on cultural factors as well as technical ones.

We are catering to the Java culture, while trying to manage things well on the technical side at the same time. In general, once can contrast the Scheme-like philosophy of using a small number of very general constructs, with the more mainstream approach of having a great many highly specialized constructs, as in C or Modula style languages.

Java is clearly in the latter camp. Most Java developers are happy to have dedicated, narrowly focused solutions that are tailored to a specific problem. I am keenly aware of the drawbacks of such an approach, but I don't see it changing very quickly.

A little while later William Grosso puts together a presentation that makes this insightful observation:

The single best measure of whether a programming language is worth using is: how well does it support communities. The social aspects of the language dominate the technological aspects of the language

Dumbing down the language at the cost of not providing more powerful expressions is a way of promoting to a wider audience. However, is it the only way of supporting communites?

Anyway, Gilad's comments are in a nutshell the guiding principles of the Java language. Could you say it's a Idealist style of thinking?

Dumbing down the language at the expense of providing more powerful expressions is a way of promotint to a wider audience. However, is it the only way of supporting communites?

No. Well, Yes, but in a roundabout way. If you hamper language growth you'll end up losing developers to another language, thereby improving that other langauge's community.

Still, it is entirely possible to have a language that has both neat, high-level features while employing a basic syntax that makes it easy for newcomers to get going. Ruby is like that, and has a tremendous community to boot.

In fact the Ruby community has picked up a fair number of ex-Perlers, and I'm sure a good number of Java converts, precisely because some people got tired of waiting to see certain features offered in their original language of choice.

I think this is the crux of the difference between Java and, say, Ruby: the creators of Java don't trust the end-users (java developers). The creators of Ruby do (I can override + if I want, no problem).

One of the things that I like is that Java is largely about protecting me from myself. Strong types, garbage collection, things must be initialized, no pointer arithmetic, etc. etc. Operator overloading, with the exception of String, in a polymorphic language seems like just asking for trouble, I'm glad they left it out.

I don't trust other programmers to get these and other things right. Heck I don't even trust myself to get it right, and I'm the best programmer I know! (kidding..)

Also, I think the point about defining deployment-specific "sub-languages" is really the strongest one, and one that didn't seem addressed by the linked article presenting the macros. (disclaimer, I skimmed it for about sixty seconds. If I've missed it, please correct me...)

I was pointed here by a friend, and while we could say a lot about macros in technical terms, I would only add a note about the original theme 'language for the masses'.

This made me remind of a rather obscure conference I attended, called Europal 90 (where btw the paper 'worse is better' also appeared).

In front of the full audience, after a question by a German software manager saying 'lisp, ok, it's nice, but my programmers say me that macros are difficult to understand', Dick Gabriel, then still at Lucid, simply answered, 'well, simply let me know their names so that I will not hire them'.

... on my side I believe macros are almost the only thingh that make me think about lisp sometimes, but java looks like amost reasonable, at the end. As for the masses, history will tell ...

Dumbing down the language at the cost of not providing more powerful expressions is a way of promoting to a wider audience. However, is it the only way of supporting communites? I wonder, though, if having a large corporation with Big Marketing Dollars (and a We Hate a Certain Redmond Company adgenda) can do anything to invent a community?

Sure, but why not have features that protect you from yourself, and add features that let me do whatever I want? They could simply add a compile switch to enable or disable macros, then we're all happy.

Bottom line, Java is a corporate language, meant for corporate development. Sure, sure, there are plenty of individuals that use it, with great success, but Sun didn't create Java for hackers any more than office buildings are meant as bachelor pads.

What's interesting is the nature of this discussion and the way the developer community has evolved. What Paul Graham says in his various blogs and articles, is that hackers are, in some ways, potential pioneers. Well, hackers have been hacking for some time now and it's arguable their skills, developed through hacking, have contributed a great deal to both their world and the world around them by becoming, by virtue of their capability and presence, a force to be reckoned with in the context of a culture that has made computer technology, through the Internet, a mainstream, everyday resource.

This wasn't the case not so many moons ago. By extension, I don't see anyone on any blogs arguing that Cobol should be the lingua franca of hackers. Everyone understands what Cobol is for.

Sun doesn't want to add macros because they don't care about hackers, not really really. They care about hackers as a means to attract advocacy, but they mostly care about businesses developing software for business. What good is it to Sun and other members of the Java community, a body of corporate bodies, if they make a language that has the capabilities of Lisp? Because they're right about one thing, add macros and everyone will develop them. Why? Because macros can be powerful, but mainly because, like mountains, they would be there.

One final observation: Macros don't seem particularly OOP friendly. Generics can exist in an OOP world just fine, but macros, employed in a large way, start to compete with objects and object methods in a large way, but in a sort of sticky, code-as-glue manner that can get, well, sticky, like peanut butter all over your keyboard. Not that macros aren't great and all. Just that, if you're gonna be macro-guy, then you may want to argue for Lisp more in your spare time, because the Lisp environment and way of thinking really favors macros as language extensions.

> I think this is the crux of the difference between Java and,> say, Ruby: the creators of Java don't trust the end-users (java> developers). The creators of Ruby do (I can override + if I want, no> problem).>> Why not trust the people who use your language?

The problem is that you're conflating macros with powerful features andtrust in the user of a language. Python makes it easy to override +(and do lots of other things), but Guido has made it very clear thatmacros (particularly at the syntax-modifying level) will never make itinto Python.

In the case of +, for example, there's a defined name-basedinterface that any object can use (any object with an __add__()method can participate in a + operation). But you can't create a newoperator called @.

What people have to get past is thinking about convenience verses what allows the are of software to progress. There are perhaps 100,000 people that are interested in the topics discussed in forums such as this. There are perhaps 10,000 of those that could actually make sense of the issues, and perhaps 1,000 that could actually execute correctly using macros 100% of the time, and understand where to draw the line.

Many people will use macros as a convenience because it makes it possible to not write a function/method to do something where you have a lot of variables involved and you get tired of changing method signatures. Or, when there are many side effects of an operation, people put that into a macro because of the singular return value confusion.

C, C++ and Java (and other procedural languages) let you return whatever you need to return. If you need to return more than one value from a method, you need to refactor your code most likely. The operations you are lumping together into a method are too complex to be either out of the main line code, or done with method local data.

A select few will draw the line at the right places. This is similar to the issue of speedlimits on highways. Many people can drive at higher speeds than posted on the highways, and not heighten the risk to others of injury or death. While others don't really get it, and think that you just drive faster because you can push on the pedal, and the vehicle will go faster. By the same token, there are people that think it is okay to drive slower than traffic if they want, and they heighten the risk of injury to others because their actions force other drives to take unexpected action to switch lanes, slow down or otherwise avoid the slower traffic.

There is a whole lot of reasons why we as a community need to provide adequate boundries for ourselves and for those around us that might take risks that can cause us injury or death.

Most of the easy things have been programmed repeatedly using all the languages you can imagine. We've done Regular Expressions over and over. Text processing languages abound. Functional Programming has been around for ages, but doesn't have a tremedous following because it takes a different mindset, and we can't apply those tools everywhere, while procedural languages are everywhere.

The next steps in computing will involve more people, with less experience writing code that we depend on more. Look at the people at M$. They have written more bad C code with more buffer overruns than we have wanted to deal with. Even the old crufty sendmail program is still riddled with security problems.

Computer software engineering is a science right up until you let people type in the code. Then, it becomes an Art! If you give people complete artistic freedom, without technical limits, you will get a wide range of software stability and compatibility.

The efforts that Sun, and others in the community make to hold back the creaping featurisms into Java are what will keep the language capable of truely being a cross platform language that finally allows all of us to create new, amazing software solutions to unsovled provlems.

Everytime a new procedural language gets invented, a few thousand (if not million) man years get wasted creating all the old tools and APIs again, before new problems can actually be solved. I really dislike this fact, and I find it amazing that we (the software community) still get excited about new procedural (with or without OO) languages come crawling out of a university project somewhere.

Nothing new has really been invented in language control or computational capabilities in decades. Instead, we have ways to do the same things differently. Java finally put into one place, two extremely key things. Garbage collection finally gets rid of memory reference related subtilties that used to 'sometimes' cause crashes when you were lucky, and compute wrong results otherwise. And what I think is even more important, is a code level security model that lets me control what software I an running while exploiting mobile code, and true distributed applications.

The RMI security model introduced in Jini 2.0 makes it possible for a truely amazing set of controls to be put in place, and thus, Java, peer to peer mobile code applications can now float across the internet with the receiving JVM being able to completely control what code arrives and executes.

The language constructs are not what enabled this kind of revolution. Instead, it was smart people employing the powers of the language and its runtime security controls to make something completely new possible! Now that is truely great computer science, and a step forward, without having to create a new language...

I think the best way to improve productivity in your organization is to foster elitism rather than cater to the masses.

Or perhaps we simply underestimate the masses. Java is actually a ridiculously complex language for what it does. The syntax is butt ugly (honestly new Object[] { thing1, thing 2 } is clean?), inner classes are bizarre, and the packaging/deployment rules are just silly (and take up an inordinate amount of time to get right).

As an experiment, perhaps those saying Java is good for the masses ought to get a copy of VisualWorks, hire a qualified trainer, and instruct a team in developing elegant applications simply. The syntax ought to take all of 30 minutes for them to absorb and the class library is no more complex than java's.