Friday, November 11, 2011

Weeds, Flowers, and Fruit Trees

Oh, you have a new language that will revolutionize the world?

JVM languages are sprouting. It's getting a bit ridiculous. Fun question for someone with more time than me: are there now more than 100 JVM languages?

Please, grant me the power of a weed whacker. Almost all these new languages are nothing but weeds.

See, you have your staple crops in the garden: wheat, corn, potatoes, etc. This is what Java-the-language (and software ecosystem) is. Not flashy, but it has many compilers, a full runtime, massive IDE support, libraries, and accessible to programmers of many abilities. Just like developed crops are fairly easy to grow, yield well, and basically get used to make white bread. It has decompilers, debuggers, monitoring, tracing, and tons of other ecosystem features.

Then there are the weeds. Sure they may look different or do a few things better than Java, but for the most part they lack IDE tooling, decompilers, monitoring, lots of good examples. Basically, not worth your time, but even worse, they are taking up cropland, water, fertilizer, and other resources that better plants and plant ecosystems could produce.

There are flowers. Oh, these languages look pretty, do amazing things. But you can't eat them, or make textiles, or animal feed. They have all the minuses of the typical weed language, such as crappy IDE support and ecosystems, but you keep them around since you can pluck it occasionally for fun, or for some specific purpose.

Fruit trees would be the best, lots of food, persist year-to-year, solid foundation, but beautiful.

Not a lot of fruit trees.

Anyway, the bar needs to be raised. Your compiler and syntax description isn't enough. A new language isn't a new language until it has:

- compiler
- IDE tooling:
- syntax highlighting
- code completion (assuming it has sufficient static typing)
- syntax error dynamic detection
- line-by-line debugging
- runtime variable/stack/etc debugging during stepthrough
- clean integration with existing java libraries, even if you have your own runtime
- a good set of examples that demonstrate the feature set of the language

That's just the bar for announcing your practical arrival on the scene. That's not even the beginning of being somewhat mature:

- decompilers, well, if the language becomes common enough
- web frameworks, enterprise frameworks, GUI frameworks, etc.
- web services, templating, and a host of other libraries that are specific to your language's style
- unit test frameworks, build frameworks, etc etc etc
- lots of programmers
- I could go on a long time. Basically, look at Ruby's rise and all the things that were necessary for that to not be a toy language: webserver that didn't constantly crash, optimizing VM (JVM basically does that for you), web framework (Rails), templating frameworks, and lots of other things.

And you know what? That's not even good enough. How does your language change the craft of programming? You know what? Ruby didn't do squat for programming. Ruby on Rails changed the craft of programming. Ruby + Rails was a legitimate new language.

My fundamental bitch with new languages is that they fundamentally don't solve problems any better than Java. They don't make it faster, they don't really change most day-to-day programming. Most make programming more confusing to people. Even groovy basically requires you to know java programming before you can learn to groovy. It's IDE plugins still suck (well, under eclipse). I think the typical JSP plugin is more useful, and that's pretty damning.

Java itself is careening toward C++ hell. There is so much in C++, it might as well be impossible to learn all the features. Considering the compilers barely implement all the features at a bare minimum of support (but pray, don't expect, for good compile error reporting). The features are bolted on. Annotations have basically become C macros.

A lot of what made Java great had nothing to do with the language. The language was a C-like dialect engineered solely for being easily understood by the majority of programmers. Java's killer features: JVM, cross-platform, cross-platform runtime library, internet support and applets, namespacing, unicode support, garbage collection, and FREE.

Compared with C programs, you didn't need an unreadable soup of macros for "cross platform" adaptation, didn't need to worry about the actual size of ints, eliminated lots of memory leaks, eliminated a ton of security holes with non-pointer math strings. It was so much easier coding in java, even if the language was boring.

The new languages are really just shifting around chairs on the deck of the cruise ship JVM and it's optimizing runtime, garbage collection, security features, libraries. The JVM provided a

Most languages are just feature-loading more inheritance options (multiple inheritance, mixins) and doing syntactic sugar (closures, autoboxing, type inferring).

What we really need is new ecosystem features: packaging and dependency management (OSGi, ruby gems, linux packaging methods, maven, namespace version tagging), cross-language compiling (coffeescript), monitoring (JMX++), features for modularizing code so these huge dependent codebase package trees don't grow out of control, a new messaging infrastructure for XML/JSON/whatever with integrated parse/query/path lookup, url-based classpath (not filesystem paths, urls, with a local cache), maybe integrate a RESTful storage paradigm like sling and JCR/jackrabbit for code and configuration storage, better dynamic reloading of code support, fundamental support for varied sizes of devices (micro/super-low footprint, smartphone footprint, desktop/server footprint), good support for scaled execution, RMI, multithreading.

Get me a new ecosystem, not a new language.

2 comments:

  1. And since garbage collection is so difficult, how about some options for providing memory usage hints in the language? Let's get some bare-metal options in the JVM, since OSs are so much more similar at the base level now.

    ReplyDelete
  2. How could I forget aspects and other forms of runtime logic injection? In the age of enterprise closed source software or even open source dependencies, there are times I want to change the code execution post-compile, post-packaging. This is a killer app feature of a new software ecosystem. Make aspects fast and injectable at runtime.

    ReplyDelete