
Amazon is hiring Clojure devs - edem
http://lispjobs.wordpress.com/2014/11/25/clojure-software-development-engineers-amazon-com/
======
mikerichards
I'm surprised at the industry adoption of Clojure. I'm not a Lispy, dynamic
typing guy, but like the anti-OO stance that Rich and Clojure represents.

I wouldn't be surprised if Clojure has more "industry" adoption than Scala at
this point.

Give me Clojure semantics (anti-OO, maps, vectors, and seqs) with some
optional typing and a Python syntax then I'm there *

* that's just my preference, no need to convince me of anything other.

~~~
nutate
From sources... Amazon is a heavy Java -> Scala shop. They are probably
looking at Clojure to diversify as Scala is hitting some growing pains, but
they can still leverage their large JVM expertise.

~~~
codeonfire
Amazon is literally thousands of shops with a libertarian CEO. The fastest way
to end a career there is to try to force a company-wide standard language
although many have tried and failed.

~~~
nso95
Jeff is actually known for being a micromanager.

------
jimmcslim
"CORTEX is our next generation platform that handles real-time financial data
flows and notifications. Our stateless event-driven compute engine for dynamic
data transforms is built entirely in Clojure and is crucial to our ability to
provide a highly agile response to financial events."

Amazon is building a competitor to Bloomberg?

~~~
Adrock
That was my initial reading, too. Further searching for the CORTEX project
revealed that it's probably an internal accounting system.

------
derefr
The first thing I thought when I read the title is that they're going to run a
Datomic-as-a-Service cluster. I'm still not sure that they're not, though a
"stateless event-driven compute engine for dynamic data transforms" sounds
more like something to do with AWS Lambda.

~~~
bkirkbri
I've been dreaming of this since Datomic came out. I recommend it to our AWS
account rep every chance I get.

------
rikf
I wonder what the sable referred to in the job description is referring to?
Could it be SableVM.SableVM is a clean room implementation of the JVM but is
no longer being maintained.

[http://www.sablevm.org/](http://www.sablevm.org/)

~~~
mabbo
Ha, sadly no. Sable is the name of an internal Amazon product that the person
posting the job must have forgotten was internal. Nothing secret afaik, just
not something offered on AWS.

------
bosky101

        coming soon...storm-as-a-service (built on clojure)

------
juol
Sigh.

Implemented a scheme in my undergraduate days (in C), had a small love affair
with LISP in general (but none with girls ... probably related).

I'll be opinionated here:

It's not readable. It really isn't. You have to be in the thick of it to see
the trees. Idiomatic doesn't cut it.

Operator heavy Haskell is more readable. Most of the modern functional
languages read closer to the spoken word.

I'd rather be presented with a legacy OO code base, than an LISP one if the
LOC was anything significant.

I hope I don't come across as disgruntled, I am but a mere man, and I know my
limits.

And still have fond memories of bedding LISP.

~~~
weavejester
_" Implemented a scheme in my undergraduate days (in C), had a small love
affair with LISP in general... It's not readable. It really isn't."_

Hang on. Your opinion is that Clojure isn't readable because you didn't find
_other_ Lisps readable when you were an undergraduate? But you haven't
actually tried Clojure yourself?

I have tried Clojure, and my opinion is that it's easily the most readable
programming language I've found.

Clojure has very strong opinions about _complexity_ , which in Clojure
parlance is a measurement of interconnectedness between components. The
language is built around the idea of reducing complexity, about making things
isolated and independent. Idiomatic Clojure code therefore tends to have a
very flat structure consisting of isolated functions and data structures. It
has a very high degree of code reuse, because it explicitly rejects
encapsulation.

Clojure's syntax may be unusual, and individual forms are more information
dense than many languages, however the _structure_ of Clojure code is often
much easier to understand, and for any non-trivial piece of code, that's the
hardest part of comprehension.

When I come across a new Clojure library, I'll often find myself reading a bit
of the docs, then heading into the source code to get an idea of how it
operates. I rarely do this with an object orientated language, as OOP code
tends to be deeper, more interconnected, and because of encapsulation, have
more methods to understand. Java in particular is terrible for this.

~~~
eccp
I've written applications using Java, Groovy, Clojure and Scala (in that
order) and after Clojure, coding Scala felt specially horrible (yet another
syntax to learn! ++: \ ~> and so on...).

Maybe Clojure feels odd for a few hours when coming from C-like syntax, but it
becomes so obvious later on. I remember I felt terrified by the parens because
I had not written anything serious in it.

~~~
vorg
> I've written applications using Java, Groovy, Clojure and Scala (in that
> order)

I'd say the most natural pathways for Java programmers upgrading their
language skills are:

* from Java, to Groovy, to Clojure

* from Java, to Groovy, to Scala

* from Java, direct to Clojure

* from Java, direct to Scala

Once someone reaches Clojure and Scala, they seem unwilling to give up what
they've gained (the simplicity and macros of Clojure, or the higher-order
typing of Scala) to switch to something else, even when that something offers
more.

