Clojure Made Simple

I want to thank everybody for coming.
The title of this talk is Clojure, Made Simple.

On the brochure, they left out the comma.
So it's not "Clojure made simple"

In other words, a tutorial on Clojure,
or an easy explanation of Clojure.

It's not actually a comprehensive explanation of Clojure at all.
But I'll look at a slice of what Clojure's about.

And a way of thinking about why you might want to use it.

So, I am the person who made Clojure.
I currently work on a database called Datomic,

which is kind of a functional database. It was written in Clojure, it runs on JVM architecture.

I'm a co-founder of Cognitect, which builds Datomic
and sponsors the development

and stewardship of Clojure.
But the main point I wanted to make about myself

to this audience was because in this talk I might
seem somewhat skeptical of Java and

object-oriented programming, is that I've done and absolute ton of that.

That's what I did for two decades before I said, 'if I still
want to be a programmer, I don't want to do it

this way anymore.'
So I know exactly how apps are built using Java

and C++ and C# because that's what I used to do.

That doesn't mean that what I think about them is correct,
but that's my experience.

But I'm wondering about you.
How many people program in Java here?

How many people are happy about that?
How many people are actively unhappy about that?

I'm looking for alternatives.
[laughter]

Okay, great. How many people have tried Clojure at all?

Ok, great. How many people have never heard of Clojure and are in the wrong room?

[laughter]

How many people have tried Clojure and are trying to get to use it at work, but not yet? A few.

Maybe this talk will give you some ways of talking about Clojure's value proposition that could help you.

How many people actively use Clojure?
and somehow are accidentally at JavaOne?

[laughter]
Okay, and the rest couldn't get into Brian Goetz's talk.

I shouldn't even mention that Brian Goetz has a talk
right now, because we're going to have people

filing out. Or maybe you're just tired of
Brian Goetz talking about immutability.

In which case, you're definitely in the wrong room.
[laughter]

No, I like him. Brian's a good friend. And his talks are great.
So I appreciate your being in this one.

So, there were very few people who had never
heard of Clojure. So I'm not going to

spend a lot of time on it.
Oh, I had one more question:

How many people have talk, "Simple Made Easy?"
How many people have not?

Okay, a few. So, I may spend a minute describing what
I mean when I say 'simple.'

Clojure is a programming language
that runs on the JVM and JavaScript.

And a substantial subset of Clojure runs on JavaScript.
So it's a programming language with which

you can target both.
But originally it only targeted the JVM and the CLR.

There's still a port to the CLR that's maintained,
but it does not see wide use.

I released it first in 2007. It's had surprising adoption.
Especially from my perspective since then,

given its characteristics. Because it's a lisp,
it's functional, it's data-oriented,

and it has a lot of things that make it seem
not like the kind of language that would succeed.

And this talk will really be about the data-orientation of Clojure.

So, a lot of the best programmers, and the most productive programmers I know are writing everything in blank

and swearing by it, and then just producing ridiculously sophisticated things in a very short time.

And that programmer productivity matters.
So Adrian Cockcroft was Cloud Architect at Netflix.

Now he's at Battery Ventures.
How many people think Java goes in the blank?

Okay. So we know, we know this.
There's something about Java that makes it

not suitable for this blank. Of course, he was saying closure.

And this talk is about "how could this me true?"

What makes closure different and possibly a better fit for that blank?

So the first thing I want to talk about it that I think we have this tendency in programming

to think about ourselves just a ton. And our languages, and our tools, and our techniques

are all me, me, me. What we're doing, whatever. We lose track of the fact that we're

all working for somebody else who's - or ourselves - but for a business or an organization

that's trying to accomplish something in the world and the software is completely secondary

to that task, right? It should be measured always in terms of the cost-benefit ratio, the

return on investment, right, how quickly can we get a product to market, and "is what

we're doing profitable?" If we're not doing that, we're not being good

participants in our businesses and our organizations.

So what do the stakeholders want?

They really want two things:

they want something good and they want it soon.

So, something good - we think we know how to make things good

We have these techniques and something is good when

they techniques are successful with them, right?

So when our types check and our tests pass,

we have something good. But, of course, we all

known that with out best efforts in those things, which

I'm not saying are bad activities by the way, but

no matter what we do there, we end up with programs that don't work.

We all know we have programs that type check and test pass

and they don't work. And they don't work from the

perspective of the stakeholder. In other words they

don't do what the program was supposed to do, and what is was

supposed to do was conveyed between people or through

documentation or papers or things that are not in programming languages.

They have to meet operational requirements, and they have to be flexible.

Now there are some times when people just want something soon

and they don't want something good. Now there are

actually better languages than Clojure for that.

Right? Just give me something fast, that I'm absolutely

definitely going to throw away; will not grow; will

not expand; will not take me further.

So these first two things are means, right, they're good but they're

only good insofar as they help ensure the latter three things.

So if we break it down, what
is it supposed to do?

Again, it's a perspective thing.

If the stakeholder thinks it's doing
what it's supposed to do, they're fine.

And of course, they're gonna have
expressed concerns about software,

what it should do, 'it should do this
when I push this button,'

and they're gonna have unexpressed
presumed things, like

'It should be secure', 'it shouldn't cause
the computers to go on fire'

'...because it's so slow', 'it shouldn't
require three new data centers,'

'it should keep running and not
stop for an hour every day'.

Those are sort of the unstated
presumptions of something being good.

But it ends up that if you build large,
elaborate, stateful programs,

it's extremely difficult to ascertain
whether or not they are going to do

what they're supposed to do.

And in fact, if you build any one
of those things,

if you just build a very large program,
or a very elaborate program,

or a very stateful program,
it will be as hard to figure out

if it's going to do what it's
supposed to do.

So one of the things Clojure is
oriented at is making it easier

to understand whether or not your program
is going to do what it's supposed to do,

mostly by making it substantially
smaller,

and also by making it more functional.

In terms of operational requirements,
there's a boatload of things,

there's a boatload of unstated
requirements of software.

You know, [?], can I deploy it
in a normal way with all my stuff

with the people who know how to
run my machines and everything else.

And that's one of the targets of Clojure.

Clojure was meant to be hosted,
it's just a JAR,

it runs in the environment, it's easy
to sneak in, right?

It's just one more JAR,
and then we're running.

But it's not a small thing.

If you wanted to adopt common lisps, say,
Pascal,

you would be asking your ops team and
your deployment team

to start manipulating something completely
alien

whose characteristics they
don't understand.

In terms of security, everything that's
available from the JVM for security

is available via Clojure.

And then of performance and other
concerns --

A very important thing though is that
now we can also reach the browser,

so having people write applications where
some part of the overall system

touches the browser.

So right now, you use two
different things,

and I almost definitely
use two different things.

And I think it's the strength of Clojure
that we're delivering, the same

value of proposition in both places,
both on the server and in the client.

Even if there are separate devs,
the value of proposition is necessary,

and almost more so in the browser

which is one of the most complex
places ever.

In terms of performance, a lot of times
a lot of times, you might look at the

dynamic language and say 'Oh, how can
it be whatever?',

but Clojure is right down there
with the fast languages.

Admittedly, the benchmark game,
which is a benchmark in a game,

but it says we can reach that.

On JavaScript, we have a very
interesting result here.

So Om is a Clojure script library,
so Clojure script is Clojure on JavaScript