Another year of Clojure

http://spootnik.org/entries/2012/07/04_another-year-of-clojure.html

by pyritschard • 14 years ago

162 71 14 years ago

This article has a similar pattern like the other "we're trying a new language" articles.

Sometimes I do wonder why people decided to use a new language for a critical/important piece of their product while learning on the go as well.

pyritschard• 14 years ago

In my case at the previous company it was rather simple. The language known to the team didn't fit the bill. So after a trial period we decided on one.

pnathan4• 14 years ago

Well, because the current language & tech stack simply does not cut it.

edwinnathaniel5• 14 years ago

Unable to deliver is different with completely unable to solve the problem.

zenogais• 14 years ago

At several companies I've worked at (and my current company) there have been severe limitations on future growth with the existing technology choices. It's more important to be able to remain agile and have a high ceiling for growth than to use the most familiar thing always.

jballanc• 14 years ago

You know that saying that "the moment you drive a new car off the lot, its value depreciates by half"? Well, the moment you ship a product, the cost of upgrading the underlying technology stack doubles.

lkrubner2• 14 years ago

I feel like the writer of the above article answers part of your question when they write:

"My experience is that when you tackle big problems, that go beyond simple execution but require actual strong engineers, hiring will be a problem, there's just no way around it. Choosing people that fit your development culture and see themselves fit to tackle big problems is a long process, integrating them is also time consuming. In that picture, the chosen language isn't a huge deciding factor."

As to the issue of change, you go with something else when the current stack is bad and/or unable to do something you need. Colin Steele wrote about this when he decided to switch Hotelicopter to Clojure. He first wrote about how the existing PHP stack needed to be re-written:

"For example, at that point, the site ran out of one ginormous subdirectory with hundreds of PHP files scattered like chunks of gorgonzola on your salad, sticking to one another with tenacious glee. There was a “lib” directory, which you think would hold much of the supporting library code, but a good fraction of that actually lived in “site”, and some in “server”. The previous programming staff had felt it good and worthwhile to roll their own half-assed MVC framework, including a barely-baked library for page caching (which broke and took the site down at regular intervals), and components for database abstraction that only worked with - wait for it - MySQL. Every single goddamn file was littered with SQL, like bacon bits on this demonic salad. There was a “log” directory, but the search logs weren’t kept there, they were in “server”. Etc., etc. It made you want to eat a gun."

http://www.colinsteele.org/post/23103789647/against-the-grai...

There are certainly situations where the codebase calls for a complete re-write, and, as the writer says in the quote above, finding good engineers is hard, and the choice of language is a side issue compared to the difficulty of finding good engineers.

edwinnathaniel5• 14 years ago

Colin could've re-written it using Java. He didn't do that because he doesn't like Java ;)

Language may have not be a huge deciding factor until it does.

My question is focused more toward the existing team that probably has some pretty good skill in, let's just say, Java and OOP and now they're turning 180 degree to pure functional like Clojure as opposed to Scala (not that I'm a big fan of Scala or anything like that, but just as an example).

If it were that easy to learn new languages, we wouldn't have issue with hiring as most of the job opening requires the candidate to know specific language however we would like to believe it was not the case.

themckman• 14 years ago

> Sometimes I do wonder why people decided to use a new language for a critical/important piece of their product while learning on the go as well.

Because flying by the seat of your pants, making shit up as you go and putting something into production without any real understanding of what the fuck is about to happen is one hell of an adrenaline rush.

zmmmmm• 14 years ago

One of the advantages of JVM based languages is that you always have a safety net - worst case you are going to fall back and do parts in Java or some other JVM based language which, while perhaps painful, is not going to destroy your entire company the way locking yourself into a poor technology choice might in other circumstances. Of course, the JVM has its own limitations, but it's been around long enough that at least they are known quantities.

bitcracker• 14 years ago

IMHO there is no better and faster way to learn a new programming language in-depth than to use it seriously in a project. Of course you have to be an experienced developer to do that, and you have to have the time and freedom to afford it :-)

This article motivated me to consider Clojure for a new business project. Clojure can use the JVM infrastructure, that's a big advantage. Java has become too boring for me (C# also).

chetan51• 14 years ago

If you were trying to build the world's next major operating system, would you go with Clojure as one of the core languages, specifically the one that developer-created apps are written in? And could Clojure be fast enough to power the actual OS itself too?

With all the new excitement around Clojure, I'm just trying to understand the theoretical and practical limits of the language.

runevault• 14 years ago

Personally not sure I would try an OS until Clojure has a compile to target like C, unless you'd try writing an OS in Java.

ConstantineXVI• 14 years ago

There is this[0] that gets Clojure[Script] to C via Gambit Scheme, still doesn't seem like something to build an OS on top of.

[0] https://github.com/takeoutweight/clojure-scheme

praptak• 14 years ago

> would you go with Clojure as one of the core languages, specifically the one that developer-created apps are written in?

Only after detaching it from the JVM. Forcing all apps to run on JVM would obviously be too limiting.

> And could Clojure be fast enough to power the actual OS itself too?

It is definitely possible to get C-grade control over machine code with a Lisp, as evidenced by GOAL/GOOL. Not sure though if it is worth it.

masklinn3• 14 years ago

> It is definitely possible to get C-grade control over machine code with a Lisp

Well you could also have machine code be a lisp (as did many lisp machines, which used lisps from the microcode up).

monkeyfacebag• 14 years ago

Well, it's hosted on the JVM, so, no, it probably would not be a good language to write an operating system in.

That said, Clojure is quite fast compared to Python, Ruby et al, but this is primarily a side effect of running on the JVM. FWIW, Java is even faster.

dons• 14 years ago

It would be a controversial step to write an OS without a type system.

aphyr6• 14 years ago

Luckily, Clojure has a type system. Actually, several of them, which work together:

http://clojure.org/protocols http://clojure.org/datatypes http://clojure.org/multimethods http://clojure.org/java_interop#Java%20Interop-Type%20Hints

Cosman246• 14 years ago

Much of the excitement around Clojure seems rather buzzwordy. You should check out some of its criticism, such as http://jng.imagine27.com/index.php/2009-08-19-011225_clojure... and http://www.loper-os.org/?p=42

gauravk92• 14 years ago

These language enthusiasts forget that the best language is the best one for the task at hand. They'll get it eventually IMHO.

dkersten2• 14 years ago

The loper os guy hates all languages that aren't the Symbolics flavour of common lisp and all systems that aren't Symbolics' Genera. His criticism of clojure is based only on those two facts and not on actual real problems or gripes with the language. He doesn't back up any claims and seems to hate clojure because its not Symbolics lisp.

If I hate all food but pancakes, then my opinion on steak is hardly relevant.

aphyr6• 14 years ago

The author claims this first article is satire, but in case you were tempted to take it literally, allow me to rebut:

Why not simply add support for concurrent programming as a library instead?

Clojure's concurrency primitives are libraries. You don't have to use them; it's perfectly OK to use, say, kilim or java.util.concurrent, and many do.

Why not provide both immutable and mutable versions of the same data types?

The mutable variants of these structures are already there in java.util, and the stdlib is designed to interact well with java interfaces like List, Map, etc. [1]

Also when writing real-world software, what about the effort required to align the multitude of Java libraries that assume an imperative environment with Clojure?

I've used nontrivial Java libraries in Clojure: it looks about the same as the Java code, only shorter and with fewer parentheses. Yes, fewer.

Can these libraries be used easily, safely and with the same performance?

Yes. Obviously the Clojure parts won't run quite as fast as the Java parts, but interop is complete, concise, and well-designed. InvokeVirtual is InvokeVirtual either way.

Meanwhile Clojure makes obvious improvements over CL in reader forms for readability: the vector, set, map, and regex literals make it much easier to write and understand. It may not be as pure as some other Lisps, but it's a competent addition to the family.

[1] A property I miss in Scala. :-(

Ygg2• 14 years ago

I'd be the first to think that they would like Clojure for bringing Lisp to the "masses". What does irk me about it is that language outputs some really bizarre stack-traces and that 4clojure.com (which people recommended but it's learning curve jumps after a couple of exercise like it saw Chtulu). Speaking of learning Clojure, anyone got a good book/tutorial/demo?

dmpk2k2• 14 years ago

Clojure's memory consumption is extreme, which excludes it from many realms of software development.

It's primarily useful for sovereign applications (e.g. precludes utilities) which do not require high memory density (e.g. precludes databases).

I'm quite fond of Clojure's model, but some tradeoffs had to be made.

canttestthis• 14 years ago

> Clojure's memory consumption is extreme, which excludes it from many realms of software development.

Is this solely because it runs on the JVM? Because per the alioth comparison tests, Java 7 uses much less memory than Clojure too.

fshen• 14 years ago

Why write an OS with clojure. It's not designed to do that. Clojure is better suited to write application, low level system software does not fit.

anuraj• 14 years ago

If I am writing an OS, I will still go back to C without an iota of doubt. I need to touch the metal down there.

masklinn3• 14 years ago

You could touch the metal in clojure, by implementing clojure on "bare metal"[0]

[0] http://en.wikipedia.org/wiki/Lisp_machine

dmpk2k2• 14 years ago

In theory. In practice, doing that (with Clojure specifically) would be a bit silly. A lot would need to change with the language to make it suitable for OS development, at which point Clojure would lose a lot of the attributes that make it Clojure.

swah• 14 years ago

Funny how, when a language only has one implementation, we easily forget the two things aren't the same.

eragnew• 14 years ago

Thought this article had a number of good tips and insights. Much appreciated.

Another year of Clojure

Related Stories