Why we are choosing Clojure as our main programming language

http://appvise.me/2011/03/why-we-are-choosing-clojure-as-our-main-programming-language/

by gislik • 15 years ago

187 138 15 years ago

iamelgringo3• 15 years ago

I know this is heresy around here, but have you looked at F#? It's functional, has type inferencing, even in the dev environment, straight forward parallel versions of functions (pmap vs map), async IO, amazing dev tools, a REPL inside of Visual Studio, access to all of the .NET libraries. And, chances are, it's going to be around for a while.

You're absolutely on the right track. As startups struggle to hire, new startups should be looking to off loading more and more of their work to more productive programming languages.

fogus• 15 years ago

May I ask why F# is considered heresy?

gthank• 15 years ago

Because it means you're (probably) going to be running Windows on your servers, which isn't cheap.

iamelgringo3• 15 years ago

Simply because it's Microsoft. That was partly tongue in cheek. :)

mduerksen2• 15 years ago

You'll have to restrict your servers to run Windows. That's something not everyone wants to do.

icey6• 15 years ago

F# runs on mono, which runs pretty well everywhere Clojure will run.

The F# mono implementation is somewhat slower than the .Net implementation though, so there is that caveat.

runevault4• 15 years ago

Not everyone wants to use the .NET ecosystem for any number of reasons. When doing purely windows development, it is my first choice, but if I want to do cross platform or web development even with Mono out there the appeal just lacks to me.

I will agree though that F# is a beautiful language, and am hoping on getting everyone else at work on board so we can start using it more for our development.

weego• 15 years ago

Is it counter productive in an environment where hiring is difficult to go too niche though?

Our entire server codebase, baring a few external libraries, is Scala (working with Lift) which has been an awesome experience but there is a nagging doubt in my mind that if/when we need to start looking to add in developers we will either need to invest in cross-training a java dev or end up paying out probably more than we could/should afford to get a seasoned java dev who trained themselves in Scala already. If over a short period of time your choice gets some major traction then it will work in your favour, but if not then you could be out in the cold or risking employing someone with no real provable history.

jared314• 15 years ago

You might not want someone who can't learn a new language.

gaius6• 15 years ago

If a developer is so much more productive, why shouldn't you pay a premium for their skills?

Remember in business there is no "cheap" or "expensive". There's only "worth the money" and "not".

MichaelGG• 15 years ago

Well, Jane Street Capital uses OCaml. According to "Caml trading"[1], hiring got easier when using OCaml:

"Personnel is one area in which OCaml has been an unmitigated success for us. Most importantly, using OCaml helps us ﬁnd, hire, and retain great programmers."

1: http://www.janestreet.com/minsky_weeks-jfp_18.pdf

iamelgringo3• 15 years ago

Chances are that basing your startup on Scala/Lift is probably going to be a net plus for you when recruiting new staff. It says a lot about the technology culture at your company that you are using a functional language. It's also something of a weeder. If an engineer can't wrap his head around Scala in short order, you probably don't want to hire him. My guess is you'll probably have to hire a lot less frequently than a typical Java shop.

va_coder3• 15 years ago

I'm willing to keep my mind open.

How long it takes to set up a dev environment and push to cloud service?

With appengine, 1) I sign up in 5 minutes, 2) clone an app in python or Java, 3) use my favorite free ide to edit the code 4) appcfg.py update

Also, if I don't have any of the tools like git I just type: sudo apt-get git-core

Heroku on AWS is just as easy.

Can you provide a link showing how easy it is to get started with F#?

mattmanser2• 15 years ago

Hang on, I thought the author deliberately ruled out GAE because its performance is too ropey.

Also step 2 sounds like magic and a recipe for disaster. Clone an app? What, with all its settings? Random library includes you weren't expecting?

Don't confuse well trod paths with new roads, closure and F# are both new roads, you'll need to do a bit of work yourself.

Also visual studio has a free edition these days.

Anyway, my point is don't compare apples to oranges when the author said he can't use apples.

stonemetal• 15 years ago

Since F# is a .net language any ASP.net web host will be able to serve an app written in it.

cschep• 15 years ago

Definitely check out appharbor.com, I think their goal is to be a "git push" away from deploying any .NET (F#/C#/VB.NET) app. I've not used them though.

gislik6• 15 years ago

To be honest I've never given F# much of a chance. Mainly because I do most of my development on Mac OS X or Linux. But I've seen some cool introductions on F# and the integration with Visual Studio (mainly from CUFP http://cufp.org/videos/keyword/59). I'll be keeping my I on it. Thanks.

pmjordan• 15 years ago

The latest version of Mono apparently ships with F# support:

http://www.mono-project.com/Release_Notes_Mono_2.10#Language...

Now I just need to find the time to try it out...

gtani2• 15 years ago

I think the biggest impediments to F# adoption:

to somebody not already a C#'er is the cost of Visual Studio: You really want that concurrency profiler, which I think is only in the Ultimate SKU (for which MS is giving away licenses in Bizspark, dreamSpark).

And a fair number of Csharpers I've met recently (admittedly a small sample) will tell you FP and the parallel/concurrent libs in C# are good enough: TPL, the .NET 5 Async lib (Basically they'll tell you about all the C# stuff in Petricek's book, without looking into what F# can do for them.

cdavid3• 15 years ago

He mentioned python issues such as deployment and the GIL. While python is my language of choise, I agree those are significant pain points. Unfortunately, he did not mention how clojure solves deployment - is it solved through maven and other java solutions ? It did not strike me as a nice solution either.

true_religion3• 15 years ago

Isn't java deployment as simple as distributing a .jar or a .war----one file? Python deployment on the otherhand is a tarball of several files.

runevault4• 15 years ago

yes all deployment options that work for normal java apps can be done with clojure as well, since in the end it's all bytecode, you just require the one extra chunk that's made up of the clojure.jar and probably contrib to get your baseline to make things work.

runevault4• 15 years ago

Maven is not thrilling, but with lein over the top and clojars for clojure specific jar files, it's reasonably painless IME.

cdavid3• 15 years ago

But what's the difference with python at that point ? Is is because the JVM makes it inherently easier ("one" jvm, one bytecode, no difference between version/build options for C extensions) ?

gislik6• 15 years ago

Just to collaborate a little bit on this point. With leiningen things are not too bad.

A typical deployment instruction file (project.clj) looks like this and with "lein deps" you're all set up in a few seconds.

(defproject leiningen "0.5.0-SNAPSHOT" :description "A build tool designed to not set your hair on fire." :url "http://github.com/technomancy/leiningen :dependencies [[org.clojure/clojure "1.1.0"] [org.clojure/clojure-contrib "1.1.0"]] :dev-dependencies [[swank-clojure "1.2.1"]])

gislik6• 15 years ago

ouch ... formatting is clearly not preserved :(

But take a look at https://github.com/technomancy/leiningen

dylanz• 15 years ago

Good read, and I just read this post while attending Erlang Factory in SF, in the middle of a talk about Lists and Strings :)

I asked the teacher about your comment on String manipulation. Yes, it is pretty in-efficient. There are libraries to make manipulation easier, and, you can always go down to binary types, which is much more performant.

We chose to use Erlang for a variety of reasons, and String manipulation isn't a problem for us (it's definitely a pre-mature optimization point (for us) at the moment).

gislik6• 15 years ago

I resonate well with many of the reasons for why one chooses Erlang in a project. I guess it all depends on the problem domain :)

nivertech• 15 years ago

Erlang strings is just a syntactic sugar over lists.

  1> [104,105].
  "hi"
  
  2> [$h,$i].  
  [104,105]
  
  3> "hi".
  "hi"

Which is efficient for some uses (i.e. iterating over UTF32 characters) and inefficient for others (high memory usage).

You can always use:

  * atoms - for interned strings or enums
  * binaries - for memory efficiency (i.e. UTF8 byte sequences)
  * IO-lists - for efficient appending and IO.

What I would like is a per-module compiler directive/pragma, which will turn every "string" into <<"string">>, while @"string" will remain syntax sugar for list.

jedsmith3• 15 years ago

I won't commit HN suicide by questioning his choice of Clojure (edit: the downvotes and only positive replies are interesting, though), but I will focus on the original impetus: it's interesting to me that a few problems are explained in Python, including solutions of how to fix them, but the author doesn't want to use the solutions. Honestly, it sounds like he wrote off virtualenv without trying it, because he'd have far less complaints about porting and dependencies if he had.

As for the GIL, the author didn't even consider multiple processes -- he explained them away as a solution for some workloads. A Web app is one giant workload where this model makes sense: multiprocessing is the approach you should be taking with a Web application. Tie a request to one core, and spawn enough WSGI applications for the number of cores you have (and then some). That's an elegant solution to this problem, since a request doesn't need to fart around with other requests in most cases. If your app can't handle multiple copies of itself running, how do you expect it to scale?

This reads a little bit like a waffling, like a person who considers a completely different environment and rewrite of the entire stack a solution to some thorns in Python. I'm all for picking an alternative Web stack, but:

> I had written a database loader to import Apple’s Enterprise Partner Feed (EPF) and a web crawler in Python and next up was the web interface.

> It all seemed like a smooth sailing but in the back of my head I was beginning to have doubts about my decisions.

> Why we are choosing Clojure as our main programming language

This being the third blog post for an as-yet-unreleased product, I'd say worry about delivering a product instead of justifying a rewrite of your work thus far on your blog. If I were considering funding your startup, this blog post would be a fairly bad sign to me.

At any rate, a computer language is just a tool to implement an idea, and focusing strongly on the language of choice is busywork itself.

technomancy3• 15 years ago

Starting a "Why we choose X" post with weak token "here's why W, Y, and Z are inappropriate" blurbs can't be chalked up to anything but flamebait.

reinhardt• 15 years ago

Or just fanboyism and shiny-new-silver-bullet-ism.

gislik6• 15 years ago

Thanks for some very spot on points. I do mention multiple processes in the blog: "Fortunately not all problems require concurrent solutions as they are either IO-bound or can be scaled by forking multiple processes." And this can be a solution to many of the scaling needs. Some of the challenges I'm facing are however more CPU oriented and it gives me a warm feeling to have a concurrency model like STM to lean on.

I totally agree with you on the point regarding worrying about delivering a product instead of rewiting the work. That's why the services already written will remain in place and I'll there fore be running Python alongside the Clojure/JVM stack.

jedsmith3• 15 years ago

> I'll there fore be running Python alongside the Clojure/JVM stack.

Yikes, really? That sounds even worse than a clean break. You don't shed your perceived problems with Python and instead get to manage two codebases and stacks. Your operations team will absolutely love you in the future.

Based upon a casual read of what your service does, I'm really stressing to think of a CPU-bound situation that can't be pooled into a multiprocessing pool. All of the heavy work I can think of your service doing -- particularly crawling -- is going to end up network or I/O-bound, isn't it? I'm coming up empty and working with a theory. Perhaps you can share what your CPU-bound process is?

bad_user2• 15 years ago

Also related to the GIL -- the "processing" module in Python takes care of any sharing scenarios you might have and it is mostly API-compatible with the threading API in Python.

And if that's too heavy, there's always stuff like GEvent. Asynchronous I/O and multiprocessing solves 80% of all problems you may have.

I do wish that Python / Ruby would be GIL-free, but for my startup I choose these platforms because they've got no parallel when it comes to rapid-development of web applications, because no matter how cool this and that language is, nothing beats the productivity gained by robust, battle-tested web frameworks (not to mention other stuff, like NLTK or SciPy).

As an early-adopter myself I might try out a couple of projects in Clojure, but I wouldn't bet my business on it unless I saw a clear need that Clojure satisfies and that dwarfs all other disadvantages, like platform immaturity.

F_J_H2• 15 years ago

Good points. After all, "shipping is a feature".

swannodette• 15 years ago

Having built websites in Ruby and Python, I've found Clojure to hold its own in terms of productivity. Clojure's library ecosystem is healthy and growing and you can tap into the battle-tested Java frameworks with ease.

Saying that Asynchronous I/O and multiprocessing solves 80% of the problems is hand-waving away the complexity such approaches might add to a project. Clojure simply gives you more and better tools then Ruby and Python currently do for dealing with concurrency.

You might not bet your business on Clojure, but certainly other people have for a couple years now and they don't seem to take issue with it.

EDIT: removed the defensive bit. My experience, as this thread shows, is that people get touchy about the limitations of the GIL.

ch0wn2• 15 years ago

As web applications usually don't do much number crunching, the GIT is even more meaningless in that decision. Threading to avoid IO-blocking doesn't trigger the GIL at all and that is what you have to deal with in web apps.

ch0wn2• 15 years ago

I meant to write GIL, obviously. Errors like this happen, when you type "git" about 200 times a day.

technomancy3• 15 years ago

Relevant: Why I hate Advocacy: http://www.perl.com/pub/2000/12/advocacy.html

nupark3• 15 years ago

> As for the GIL, the author didn't even consider multiple processes ...

I really hate this argument for its disingenuity. Some things (including message passing) are naturally fastest with shared memory. Multiple processes are not an equivalent substitute.

Clojure, for instance, leverages shared memory to implement its excellent, lightweight STM and related high-level threading constructs, and shared memory is what allows Clojure to easily implement cheap, MVCC functional data structures.

Multiple processes aren't an answer, here. To implement the same high-level constructs efficiently requires re-introducing shared memory through more complex, less efficient mechanisms, and often leaves the problem of sharing access to higher-level constructs (objects, instead of data) unsolved.

Multiple processes are a poor work-around for a lack of support for concurrency, not a solution. They make sense if you're sandboxing, but make little sense for implementing a high-performance concurrent server.

To pre-empt the erlang discussion -- erlang's message passing model does scale, but Erlang's runtime does require support for real shared memory concurrency in order to maximize single-machine performance.

nl3• 15 years ago

> As for the GIL, the author didn't even consider multiple processes ... I really hate this argument for its disingenuity. Some things (including message passing) are naturally fastest with shared memory. Multiple processes are not an equivalent substitute.

This isn't a disingenuous answer at all, since it goes on to point out that A Web app is one giant workload where this model makes sense: multiprocessing is the approach you should be taking with a Web application.

As someone with a strong Java background, I have to continually force myself to be aware of my bias against concurrency-via-multiple-processes.

If you have a stateless application (and if at all possible, statelessness is a good thing [1]), then multiple processes scale vertically reasonably well (on the same machine), but having a multiple-process architecture makes scaling horizontally (across machines) natural and easy.

It's true that shared access to higher-level constructs in a multiple process environment isn't solved, but (a) shared access to data is an anti-pattern [2], and (b) Memcache plus some kind of serialization works pretty well when you do need shared data.

[1] Yes, applications exist where statelessness doesn't make sense. In this case, though the author was originally developing on AppEngine, so I doubt there is much state in the app.

[2] I'm not saying you should never have shared data. I am saying you should avoid it as much as possible.

SeanDav• 15 years ago

Since the OP enjoys Python, I am quite surprised Stackless Python didn't seem to enter the equation.

st3fan2• 15 years ago

It is a myth that Java requires massive amounts of XML that make your eyes bleed.

It is perfectly possible to configure a servlet environment once with 15 lines of XML and then never look at it again.

Look at Google Guice for example, which does awesome Java based configuration and composition of components.

toisanji• 15 years ago

that already massive amounts :)

ww520• 15 years ago

I actually found Java + Play! to be very productive and fun to develop. Have done 3 projects in that combo already.

brown9-2• 15 years ago

I agree with this - it is really weird to me to dismiss an entire language and ecosystem because many of it's popular tools are configured through XML. You don't need to follow along with what everyone else is doing.

nhoj• 15 years ago

I'm writing a java web app without any xml at all. The servlet 3.0 api has some pretty nifty annotations.

st3fan2• 15 years ago

I agree with the Python packaging hell. Things are getting better but it is really hard to beat a simple WAR file that contains all your dependencies.

Deployment is also a breeze. Place WAR file on a server, let operations people grab it and drop it in a servlet container. Done.

Python need to reach a point where it is that simple. I see people around me handle this with Python but it takes a lot of effort to get it right.

nubela• 15 years ago

And why is this hard with virtualenv / pip ? I don't get it. Sure its not as simple as a single WAR file, but if you are unable to initialiaze a virtualenv bottle, perform a pip install with a dependency file, ensure that the python version is the same, you should not be a administrating a server.

otterley5• 15 years ago

It's interesting that the needs of the business don't seem to factor into his analysis at all.

I'll concede that sometimes there are specific cases on which you need to use a new or non-mainstream language or environment. (I'm 99% certain that this business is not one of those cases.) I'll concede, too, that being on the cutting edge is pretty cool and gets you lots of hacker cred.

But if you want your business to survive the departure of the founding team, you need to consider whether you can solve the problem with a mainstream environment. If you don't, don't expect your invention (at least in its current form) to carry any legacy.

Case in point:

People may think Paul Graham is a fucking genius for selling Viaweb to Yahoo!, despite being written in Lisp, but I assure you none of his code still lives on there, not even a fork. His brilliance is as a businessman for getting Yahoo! to fork over $<lots> to him, not for the technical merits of Viaweb itself.

eftpotrm2• 15 years ago

Yahoo bought Viaweb 13 years ago. The challenges then were completely different to what they are now, as were the underlying technologies at all levels. Frankly Viaweb could've been written in the most widely used, predictable technology ever seen and I'd still expect it to have been rewritten in the last 13 years.

otterley5• 15 years ago

Sure, most things are rewritten or replaced in the very long term. But Viaweb's code didn't even last a few years.

anamax• 15 years ago

> His brilliance is as a businessman for getting Yahoo! to fork over $<huge> to him, not for the technical merits of ViaWeb itself.

You forget that he had something to sell. He explains why his choice of lisp helped him with that detail.

chris_j2• 15 years ago

Would you mind expanding on this? All of the responses to this comment so far seem to focus on the last paragraph and Viaweb in particular, which I would guess is not the main part of your argument.

You say: "...if you want your business to survive the departure of the founding team, you need to consider whether you can solve the problem with a mainstream environment." Could you go into more detail about what you mean by a mainstream environment and what advantages it would bring in this case?

otterley5• 15 years ago

With most startups, the (usually very small) team or individual who develops the original implementation doesn't stick around once the business has achieved some level of success; they typically cash in and leave.

But if the business is going to continue to operate, the new development team needs to be capable of tending to the product, as it will need bug fixes, security patches, and perhaps be updated to scale better.

If the product is built on an uncommon platform, finding new developers, especially senior ones, to tend to the product will be difficult and expensive. If a sufficient number of qualified developers cannot be found, the business may have little choice but to rebuild the product using a more mainstream technology. In the meantime, the business takes on a higher risk of continued operation if the current implementation (which is no longer maintainable) is surpassed by its competitors.

TL;DR: short-term optimizations create technical debt, which screws your business in the long run.

there2• 15 years ago

While there are enough programmers that know PHP (which is clearly a plus) there’s just not enough sex going on here.

wat

nickik• 15 years ago

php sux. Thats what he wants to say in a nice way.

there2• 15 years ago

it sounds more like they chose not to use it just because it's not cool, not because of any technical merits.

biznickman• 15 years ago

"While there are enough programmers that know PHP (which is clearly a plus) there’s just not enough sex going on here. As with Perl, PHP really wasn’t in the loop."

How is that a valid argument? "not enough sex going on here" ... if you choose a language because it's sexy and not because of its utility, you are making a poor business decision.

Digg spent a long time revamping their system in new languages and on new databases and look how that turned out (not that the languages were the core part of their failure, but still)

JonnieCache• 15 years ago

>"not enough sex going on here"

I actually thought he meant it in a Darwinian/Dawkinsian(?) sense. That would have been a pretty neat turn of phrase. But yes you're right, he clearly means sexy. Stupid word.

dmoney• 15 years ago

If it means he just doesn't enjoy working in it, and thus might never get the business off the ground, then it's a good business decision.

hendler• 15 years ago

In particular, I appreciate this article as much for "Why not Python". I feel Python could easily be the lingua franca if it could deal better with the version issue. Using Scala for similar reasons (the other being general performance).

Probably the author underestimated node.js though. Using the author's language, it has a lot of "sex".

robbles• 15 years ago

I'm not sure that a "lingua franca" is even possible. Even if one language was so far ahead of the others that discussions like this thread were pointless, there would always be resistance from other developers. People just seem to get too attached to the idea of "There's one language to write everything in, and I pick this one."

enduser• 15 years ago

No judgement here, but from reading this it seems possible that the author did what I and many others have done: overlooked Common Lisp after one or more encounters with Scheme.

pavelludiq• 15 years ago

I did this too, last year i corrected that mistake by learning common lisp and now clojure is my second favorite language :D

vic_nyc• 15 years ago

I have written web applications in Ruby on Rails, PHP and recently Clojure. While I absolutely love Clojure and what it offers, building web apps with it has proven painful, because the library ecosystem just isn't there yet. There is indeed the foundation, as the author mentioned - Ring, the equivalent of Ruby's Rack, and a few other frameworks such as Compojure. But these are very early stage projects, parts of them are still being rewritten and they are relatively poorly documented as of now. If you run into problems along the way "how do you do this?" you would have a hard time finding adequate info online, whereas the amount of information that exists out there for RoR, for example, is incredible (message boards, tutorials, blog posts).

But even if you go through the initial pains of figuring out how things fit together, many tools are still missing. An easy to use templating library, for example. (several exist already but they are still early stages /are being refactored). Also things like the gems and plugins ecosystem in RoR - where you can pretty much find gems for so many things out there. (e.g.: tagging, authentication, etc). There simply isn't a comparison.

So, while I really love Clojure and I believe the community around it is growing - in both size and its contributions, I would say that, let's face it, writing full web apps in it right now cannot be compared to the productivity you would get in say RoR, due to the immaturity of the tools. That being said, I still see Clojure being immensely useful in other scenarios (for example: A.I. algorithms, high performance data processing, etc) and as such I would use it mostly in those settings, while integrating it with a more mature 'front-end' framework.

radu_floricica• 15 years ago

I managed to use Apache Velocity with clojure reasonably easy. Maybe not the sexiest template engine around, but it's what I was used to. Plus I can just plug a clojure bit in the existing java webapp and not have to change anything else.

Probably works with JSP too...

pico303• 15 years ago

I had the exact same experience with a project we started recently.

We jumped from Clojure/Compojure to Erlang/WebMachine with much better success so far. I did in Erlang in two days what Clojure took me two weeks with numerous false starts to accomplish, mostly because the libraries were so poorly documented or incomplete. I spent more time digging through code and trying to assemble a framework to build upon than I did writing useful business logic.

I found the Erlang infrastructure to be well-structured and strongly documented, mostly because of it's maturity. What I surmise is that Clojure is just too young, and its web framework lacks a strong commercial force driving it. Rails has 37signals, Webmachine has Basho, Lift has sites like Twitter and Foursquare. Clojure needs something similar to push it forward.

All arguments and emotions aside, I'd say if you're starting to build a new web site, and you're not considering Rails or Lift, you're doing yourself a major disservice. Like others have said, JRuby nicely avoids some of the issues discussed for scripting languages.

ldh3• 15 years ago

Lack of docs is to be expected, it's early days. That may be a turn-off for some people. On the other hand, it's a great time to get your own preferred features and changes added.

As far as I know, nothing is stopping you from using any of the existing templating systems in the Java ecosystem. They don't have to be written in Clojure to use them with Clojure.

dkarl4• 15 years ago

If library versioning in Python is bad, how would a JVM language be better? In my experience, there is no widely-used post-build-time system for declaring or checking dependencies except for OSGi, which is not spreading like wildfire as I expected it to. The Java model seems to be to bundle all your dependencies into a single deployable app, performing all dependency checking at build time and carefully isolating your app from other apps in an application container. I.e., don't even try to solve the problem of sharing libraries between applications.

Oddly enough, C has superior runtime checks (dynamic library loading using major version numbers) and install-time checks (*nix package dependencies) compared to dynamic languages. It is very, very strange to me that other language communities have neither embraced alternatives such as OSGi nor worked to transfer responsibility to native package managers such as dpkg or RPM. C et al. under Linux have set a standard that other language communities don't seem interested in matching, much less exceeding. As far as I know, the standard answer for deploying a security update to a Java library is to rebuild and redeploy the entire application that depends on it.

herdrick• 15 years ago

Clojure has Leiningen for library versioning / package management / builds. It's excellent.

dkarl4• 15 years ago

It seems to be a compile time only tool. Does it let you safely deploy application code separately from its dependencies? Does it let different applications share libraries when possible? Does it come with tools that let you query the version and dependencies of a deployed library and see how those dependencies are satisfied? Can you push a security fix for a library to servers in the field without completely rebuilding and redeploying every application that uses the library (if you can figure out which ones they are?)

blacksmythe• 15 years ago

  >> carefully isolating your app from other apps in an application container. I.e., don't even try to solve the problem of sharing libraries between applications.

I would argue that this is the most reliable solution, if you can do it.

dkarl4• 15 years ago

It isn't necessarily a bad thing -- it's basically static linking -- but the way it's done, it makes administration and troubleshooting a nightmare. As a platform, Java lacks the tools that a Unix sysadmin takes for granted. For example, with Debian or Ubuntu:

What version of a library is installed, if any: dpkg -l

What's the latest version available to be installed: apt-get update, apt-cache search

Update the library for all applications that link it: apt-get upgrade

These tools are important for administration, security, and troubleshooting. It mystifies me that Java developers and sysadmins managing Java servers don't demand them. Instead, they're willing to muck around in a web interface, go back to their dev box to look at Maven scripts, or go searching through the filesystem just to see what software is installed and running. Even if you're not averse to doing that by hand, how scriptable is it?

If you have a large Java environment with many different services running on dozens or hundreds of boxes, how do you get a report of which boxes have a particular version of a library installed? I know our sysadmins don't know how, and I know our Java developers don't care. They could develop the tools themselves, but they have no interest. The sysadmins do not do web pages; they are not going to spend all day going click-click-click to update a few dozen servers. They have told the Java developers not to expect the same level of support for their applications as our C++ programmers get because Java is an unmanageable platform, and the developers don't care. I really, really do not understand why our Java programmers are not writing scripts to automate any of these basic tasks.

F_J_H2• 15 years ago

I wonder if discussions like this will someday be analogous to a mechanic blogging about "Why we are choosing SnapOn instead of Craftsman as our tools for building NASA cars", or a chef posting on "Why I moved from Cookware X to Cookware Y".

I guess it is important to discuss the tools of the trade, but I wonder how long it will be before asking someone what technology they used to build an app would be like asking a musician what brand her instrument was. ("Hey, great song - is that a Stratocaster?) At the end of the day, does your app enable your business to make money? Heck, I've built a business with revenues in the millions using MS Access as one of the main tools! (A long story there!)

What I have learned, which other commenters have already pointed out, is that issues like maintainability after you are gone, finding resources quickly, the size of the user community, etc. are all equally important and should not be overlooked.

Why we are choosing Clojure as our main programming language

Related Stories