Skip to content

Comment on Shall We Use Clojure?parent

Comments

At the price point we can afford?

Just a quick note: from personal experience, I've been a lot more productive in Clojure than in Java, and I have written a lot of Java code. Things like the REPL, STM or FP speed you up a lot, I would say by a factor of at least 2 - 3, maybe more. I have no data to back it up but this is my perception.

So hiring one programmer instead of 3 and paying him 2x more is already good for you.

Everyone claims this about their favorite language. If I were a manager, I sure as hell wouldn't believe it.

Good you're not a manager then.

When I switched from C to Java, I experienced a considerable bump in development speed. Just the collections framework was a godsend, not to mention things like GC etc.

Quite literally I would write things in days instead of weeks. Same thing goes for Java -> Clojure. And just to be clear, it is not my favorite language.

neutronicus should read the Blug Paradox in pg's Beating the Averages (http://www.paulgraham.com/avg.html).

Funny story. I programmed briefly in C and went to Java. I had almost five years of experience there. Due to circumstances, my sister now needs some help coding some stuff in C (note these aren't same types of problems I had). And I noticed that I am now so much more productive in C compared to what I was before. Hell I make less mistakes than in Java (granted problems are a bit easier).

My point is - are you sure you just aren't better programmer overall and attributing that (somewhat underservedly because GC and a huge choice of collections) to Java/Clojure/<insert language>?

Partly, sure. If I had to write some C again I would surely try to do it as functionally as possible, and with the added experience I have gained in the last years I would now probably be a better overall C programmer. But had I sticked with C and not moved on to other languages I probably wouldn't be much better now than I was before.

I'd hazard a guess that this had less to do with java and more to do with your lack of c experience. collections in c is a solved problem, there are numerous libraries (glib, for example) out there that are all similar to Java's collections.

C++ has stl with many of the same collections, and if you want to use auto_ptr, you don't even need to remember to call delete.

I am not saying there are not productivity gains to be had from using java, but as in this case, it typically comes from not having the relevant experience elsewhere.

Automatic memory management, instantaneous compilation, no portability issues, (easier) polymorphism. Maybe weeks -> days was an overexaggeration when it comes to C -> Java but I definitely experienced a big productivity gain, and it wasn't because of a lack of C experience.

From a quick glance at the docs glib looks good but it is still too low-level for normal app development (for example, the size of a hashing table created by hcreate() is fixed; so you have to create & copy & destroy a hash table if you want to add more elements than it can hold at a time) and it should be, that's the whole point.

C++ is a whole other story, sure.

Everyone claims this about their favorite language. If I were a manager, I sure as hell wouldn't believe it.

Well, it's been known for awhile that languages and environments can have a 2X or 3X influence on programmer productivity.

http://www.qsm.com/resources/function-point-languages-table

However, it's also widely held that individual programmer ability and the cultures of certain groups can have even larger affects on productivity.

Switching languages is hard. Managing groups is hard. Dealing with the rest of a large organization is hard. If a group can do fine without switching languages, why would any manager be in a hurry to do it?

I've never heard anyone say this about C... If I've heard it said about C++, that was a long, long time ago.

But you're depending on 1 programmers instead of spreading your risk into 3 different developers.

Lots of angles to consider not just in terms of monetary. Human's behaviour/attitude/mindset is a very large unknown despite however hard we tried to make a "human" as static as a "resource".

Sure, but a 3x faster programmer will still be more efficient than 3 other programmers, because there is no communication overhead and opportunities for misunderstandings.

I would rather hire somebody really good for $6k / month than 3 people for $2k each.

Sure but people need to go on vacation, multiple projects need to be worked simultaneously, developers may leave their jobs, etc.

There are lots of good reasons to have multiple developers on a project other than simply throughput.

Maybe you don't want to replace three java programmers with one clojure programmer, but it might not be so bad to replace fifteen java programmers with five clojure programmers.

I would definitely agree with all the advantages of having less (less people to manage, less communication, less lines of code) provided that you can find the ideal situation.

But alas, finding the ideal situation is like winning the NBA Championship trophy: you need all the stars to line up including "Lucky" star.

These really good people are quite unstable (moving on or burning out), so the risk is higher.

Me too, unless ofcourse I only have $2k in which case I'll be forced to just higher the the later kind of programmer.

Clojure and Java aren't really direct competitors. The appropriate comparison is to Python, Ruby, or Perl. I strongly doubt there would be a 2-3x difference in that case.

Personally speaking, even though I really wanted to love Clojure, I was forced to conclude that Python is more productive.

Well, it depends. For example, look at core.logic and show me something comparable in Perl or Python. The ability to just code up a DSL in no time, with the same syntax as the rest of the language is a really powerful tool, and I've yet to see a language that comes even close to Lisp's metaprogramming support.

Python has logic programming (Pyke). But, in principle, yes: you can't add new syntax to non-homoiconic languages. You can use macros (even C has macros), but they are more limited in a nonhomoiconic language.

In my experience, though, metaprogramming is of limited use as anything other than syntactic sugar. And it often leads to very confusing code.

Other language features are far more fundamental and important: libraries, good integration with the shell, coherent error messages (!), readability, tooling, deployment, etc. As a language Clojure is beautiful, but as an ecosystem it has very far to go.

I'm not aware of many non-Lisp non-Prolog logic programming libraries like core.logic. core.logic can trivially operate on the terms of language which it is defined in. Meaning core.logic itself can be used for metaprogramming.

In my experience, metaprogramming is a wonderfully powerful utility for controlling complexity and confusion.

As far as the ecosystem - I used Python for a couple years, it's good. But the Clojure ecosystem is doing pretty darn well itself these days.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.