Saturday, January 22, 2011

The Polyglot Approach



What do folks mean when they speak about polyglot programming? They mean using more than one language to solve a problem. Usually they are talking about larger projects, often denoted with the moniker "enterprise". Many large projects do this already, they use SQL or some type of ORM (often with it's own language) to communicate with the database, a language with great front end libraries like JavaScript or Flash, glued together by a general purpose language like Java or C#, built by something like Rake or Ant. There are many other configurations worth considering but the above mentioned design is common enough that we'll focus on that.

I've heard that the above approach should not be considered "polyglot", because you "have" to use different languages. That's like arguing the sky is blue because it "has" to be. The sky doesn't have to be blue, it is blue. Enterprise programs don't "have" to be built with multiple languages but they often are. People have found advantages to embracing the polyglot approach to large scale projects.

The confusion often comes in regarding the middle layer. If it is built in language X, should language Y be introduced? Without knowing anything about the nature of the business, the problem being solved or the team solving it the answer is obviously no. Introducing a new language will make it too difficult to move programmers around the codebase, new talent may be too difficult to find or train, and language Y does not offer enough of an advantage to validate its presence in the project. I don't even have to name any languages here, there are many folks who hold these truths to be self-evident.

As someone who makes money contributing to the design and implementation of enterprise software I can only hope that my competitors are the ones who take this "one size fits all" approach. Instead of focusing on the languages focus on the business. We are always trying to find the right balance of fast, good, and cheap. Here are a few questions to consider:
  • How much value does language Y add in solving the business problem?
  • How important is it to solve the problem quickly and with a highly flexible solution?
  • How easy is it to isolate the solution to in the codebase?
  • Do you have folks who can come up to speed quickly in language Y?

My issue with posts like this is there isn't a one size fits all solution to enterprise development. The author makes some good points and I have little doubt that the way folks used multiple languages on his project was a problem. However, the author's experiences don't translate to a universal rule for all enterprise projects. I suspect that if the folks that introduced Scala into the project limited its use to a specific area of responsibility or layer and limited the use of more difficult parts of the language then his blog post would have looked a lot different. Just because a language has advanced features doesn't mean you have to use all of them. Good technical leadership should be able to determine a solid combination of languages and libraries that allows the skills of the team to solve a problem.

"Stick to the lowest common denominator languages so it is easy to staff projects." You have now just sacrificed fast and good for cheap. You didn't even pick two! Is that the right business decision for your project? Would your stakeholders agree? I'm sure some would. I'm sure some would not.

When you look further than a project and you are trying to maintain a quality development team there are other considerations. Why are Macs gaining popularity in the enterprise? Why are folks looking at languages like Groovy, Scala and Clojure? Better developers want to use expert tools. They want to accomplish more in less time and be able to respond quickly to changing business requirements. They want to come as close as possible to delivering fast, good and cheap. On the JVM Java is well past its prime. Great for integrations but bad for most projects. Are there exceptions? Sure. I suggest Java for things like embedded systems and highly optimized code. For everything else there's often a much better choice. For example, Groovy is often an easy jump for Java developers and can help folks to deliver business value quickly. After spending some time working with Groovy I noticed I was spending more time thinking about how to solve the problem and less time setting up the plumbing. I've had fairly similar results with Clojure and Scala, more business value can be delivered in less time with greater flexibility than Java. However, it can be fairly difficult for developers to get up to speed with these languages. Depends on the team, your mileage may vary.

For more information on where it makes sense to apply the polyglot approach Venkat Subramaniam does a great job explaining things.

Use common sense and experience to determine the right tools for the job. There is no one size fits all solution.

Thanks to liangjinjian2005 for the photo of folks shaking hands.


Tuesday, September 28, 2010

Expert Tools



Quick snipits on the internet should be taken with a grain of salt and a little bit of thought.

There are two newer languages with a lot of momentum in the software world, Scala and Clojure. Both of these languages have strong pedigrees, Scala from Erlang and Haskel and Clojure from Lisp. Both languages offer great support for functional programming, a relatively new paradigm for most business developers. A direct consequence of the increased power of these languages is the barrier of entry is high for your typical developer who has only worked with object oriented code.

Anyone who was coding business systems around late eighties remembers the shift from pure a pure imperative style of programming (think C) to object oriented programming (think C++ and Java). The recall the skepticism that OO based systems will never perform, they remember the critics who thought the paradigm shift wasn't necessary and would be too difficult for developers to pick up. For those who were around in the late eighties the software climate of today should seem vaguely familiar. It is.

Now back to my first point about quick snipits and thinking. This quick snipit between the author of Scala and one of it's primary contributors was posted up on Artima:

Bill Venners: Some people lately have expressed doubt whether Scala is a language for the average Java programmer. What's your opinion?

Martin Odersky: Scala at the moment doesn't need to be a language for the average Java programmer. The programmers we want to appeal to are the expert programmers—the good programmers. Our aim is to make them much more productive than they are with Java. I believe over time there will be enough teaching materials and enough good tools to also make Scala appeal to more average programmers. But that's not what our immediate aim is, and I think good programmers can become more productive with Scala now.


This post was quickly linked to on Twitter and discussion ensued. Twitter to its credit and detriment, only allows for 140 character posts. This means you don't have to spend a lot of time reading through superfluous text but it can be difficult to explain things. The conversation went like this:

Me:
Both Scala and Clojure are not for the novice. At our last Clojure meetup the consensus was we're happy the barrier of entry is high

That being said I think there is a lot of value in beginner material with a solid progression for both languages.


Smart Developer:
Why would you be happy that the "barrier of entry is high"? I don't see any benefit to that.


Me:
Keeps the tourists at home. If someone takes the time to learn Scala or Clojure then they really want to be a good developer.


Smart Developer:
This is the kind of disturbing elitism that has cast Smalltalk and Lisp into obscurity and irrelevance, Scala deserves better


Woah. The key to my explanation is "wants to be a good developer." Anyone who has spent time developing tools knows that you often have to strike a balance between power and ease of use. Elegance exists when you are able to provide both. Scala has a low barrier of entry for Java developers who want to get started with it. However, to reach the intermediate stage and to be able to understand code written by others Scala presents a high barrier of entry. I personally think this is a good compromise for adoption, allows adventurous folks to get started and you don't pay the complexity penalty until you need it. The only issue is the barrier to intermediate Scala developer is rather high and can be a bit intimidating. However, the power through access to higher level patterns is amazing.

Clojure on the other hand has an initial high barrier of entry. Prefix notation combined with everything being immutable makes it difficult for folks to figure out how to get started. Once someone gets past this initial hump the language gets easier and many folks feel the complexity decreases. During the last Denver Clojure Meetup one of the members commented that they were glad the barrier to entry for Clojure was high, that way you know folks who are trying to learn Clojure are dedicated to taking the next step, to learning advanced tools and to becoming better developers.

I've spent a significant amount of time developing presentations on Clojure for the Denver Java User's Group, the Denver Open Source User's Group, the Boulder Java User's Group, and the Colorado Springs Open Source User's Group. I've presented five times in the past year on Clojure and spend my free time working on teaching examples. I truly want to make Clojure and immutable/functional programming accessible to whomever would like to learn. I stand behind my statement concerning the high barrier of entry, folks need to want to put effort in to gain access to the power provided by Clojure and Scala. If there is an easier way to provide access to these advanced power features I would welcome that level of elegance whole heartedly, it would save me a lot of time spent studying.

Tuesday, July 20, 2010

Adjusting the memory footprint in the Netbeans debugger



A quick little tidbit on something that I should have found a lot easier. If you want to adjust the amount of memory dedicated to debugging sessions in NetBeans you don't look for a debugger setting, rather you adjust the general settings for the project you wish to debug.

  1. Right click on the project
  2. Select properties
  3. Adjust the VM Options

As a first approach I suggest increasing the Xmx option as I have done in the picture below.


If you need more fine grain memory tuning a good place is to start with Ken Sipe's blog entry:

Ken does a good job with his talks on JVM tuning. I have kept an old presentation of his from a NFJS a few years ago and often start there when I need to do some JVM tuning. A more in depth blog entry on the subject can be found on Pete Freitag's blog.

Thursday, April 15, 2010

Denver Java User's Group (DJUG) language panel, featuring Clojure

Last night (April 14th) I had the honor or representing Clojure at the Denver Java User's Group language panel. It was a lot of fun to be presenting next to so really talented folks about one of the most exciting languages on the JVM.

Here are the slides:

Enjoy,
Daniel

Wednesday, February 17, 2010

Greetings

Hello, I'm Daniel Glauser, a software architect living just outside of Denver, Colorado. I work as a software architect focusing on enterprise software solutions mostly on the Java Virtual Machine. I'm currently working with Groovy and Grails, Scala and Clojure. This is my technical blog. You've been warned.