

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

======
edwinnathaniel
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.

~~~
lkrubner
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...](http://www.colinsteele.org/post/23103789647/against-the-grain-aws-
clojure-startup)

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.

~~~
edwinnathaniel
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.

~~~
lkrubner
What do you think people will think when they read this?

"He didn't do that because he doesn't like Java "

Your words imply that somehow the preferences of the top engineers or CTO
should not matter. But why should those preferences not matter? If we are
talking about people who are talented, then we can start with the assumption
that those preferences are probably the distilled wisdom of many years of
experience with particular styles of development. We don't need to re-enact
the millions of debates that have happened regarding whether Java is good or
bad (One side shouting "It is verbose!" the other side shouting: "Type
enforcement is good", etc, etc, until the last syllable of recorded time). It
is enough to know that good engineers have preferences and those preferences
probably have some benefits.

You also wrote:

"My question is focused more toward the existing team..."

What if the current team is terrible? Again, referring to Colin Steele, he
fired/allowedd-to-leave the entire team that existed when he first arrived.

What if we turn your question around and ask it from the other side: is change
ever justified? I'm guessing you would say "Yes".

~~~
edwinnathaniel
By your statement that the preferences of the top engineers should matters is
the time where "language does matter". It matters because it's a personal
choice regardless whether it is the right choice or not.

"What if the current team is terrible" is not the focused of my question hence
providing an example from Colin is arguably not in the right context of this
discussion and I'm going to leave it to that because there's no point to
discuss as anyone could have switched the underlying technology from Java to
Ruby and fire all Java developers and hire Ruby developers.

Colin is a very specific example that is written by the man himself. The
justification is sound. Having said that, I could pick some obscure language
tomorrow (not that Clojure is these days) and forces my own preferences to go
forward as long as I can reach the goal and claim in an article how my
personal preferences were the best thing as well even though it may not be the
case.

But nobody knows the truth... right?

I'm not trying to be negative here but at the same time no human willing to
admit his/her mistakes to be honest. Especially when there are plenty at
stakes.

------
anuraj
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.

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

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

~~~
dmpk2k
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.

~~~
ehsanu1
_A lot would need to change with the language to make it suitable for OS
development_

I keep hearing this, or statements along these lines. But I never see an
explanation for this. Performance? Managing memory from other processes? Bit
twiddling required to create device drivers? Something else? Are these
insurmountable?

~~~
pnathan
To write an OS, you need to have a few things:

\- ability to manually access memory

\- ability to use assembly and translate said assembly into the high-level
language

\- ability to install interrupts

You probably also want the ability to precisely constrain the amount of memory
a block of code uses.

I suppose there are other nice to haves as well: e.g., GC will need to be
fairly controllable.

I see no practical reason why a Lisp can't be used to write an OS, but that
Lisp will need a few extensions from the usual modern Lisp capabilities.

~~~
masklinn
> \- ability to use assembly and translate said assembly into the high-level
> language

Not at all, lisp machines used custom silicon implementing lisp in hardware, I
believe even the microcode was lisp.

> I suppose there are other nice to haves as well: e.g., GC will need to be
> fairly controllable.

If you're coding the hardware to the language, parts of the GC can be
hardware-supported directly.

> I see no practical reason why a Lisp can't be used to write an OS

Especially since it has been used to write OSes, multiple times.

~~~
pnathan
Okay, I was making the assumption of using standard x86-style hardware. :-)

------
chetan51
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.

~~~
Cosman246
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...](http://jng.imagine27.com/index.php/2009-08-19-011225_clojure_the_false_lisp.html)
and <http://www.loper-os.org/?p=42>

~~~
aphyr
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. :-(

~~~
agentultra
_Meanwhile Clojure makes obvious improvements over CL_

I would beg to differ. The features you note are pretty subjective and not
_obvious_ improvements at all. I've done a few small non-trivial prototypes in
Clojure. I cannot stand the syntax for literals. Or the mangled hell that is
the literal for lambda. At least CL lets you define your own reader macros --
something that Clojure cannot do (yet). These features you mention are not
improvements over CL IMO.

~~~
aphyr
Huh, I find the syntax for literals a breath of fresh air--but I also grew up
in languages with rich data structure literals and find the {}, (), [], #"",
#{} distinctions make it much easier for me to understand, at a glance, the
shape of a structure. I also prefer the vector notation for arguments in (fn
[arg1 arg2 & friends])--the brackets make it easier to recognize the argument
boundaries, especially in one-liners.

In general, Clojure code seems to have less nesting, which makes it easier for
me to read and parse. You're honestly the first person I've heard express a
dislike for the reader forms, so I thought it was universally liked.

I think you're right: a lack of configurable reader macros is a problem. I'd
also point to the lack of tail recursion (and consequent mucking about with
(recur) and (trampoline) as a notable flaw in Clojure. Its error messages are
pathologically malicious. On the other hand, I think Clojure's packaging
environment, thanks to lein and clojars, is quite good. There also seems to be
more consistency in Clojure coding... style? preference? than in CL, which I
attribute partly to its young age and small user base, but also, perhaps, to a
more opinionated set of attitudes around mutability and types.

Regarding the #() form, I almost never reach for it, partly because it never
seems to work as expected. (fn) and (partial) feel more natural to me, so I've
never taken the time to understand how #() works.

I also prefer Lisp-1s in general, although I understand that's a more
contentious differentiation.

Either way, my CL experience is minimal, so it was wrong of me to claim these
as obvious improvements. I'll defer to your expertise here: it sounds like
you've used CL enough to understand it better.

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

