Clojure as a First Language

[John Newman]

First of all, sorry that this post is so long-winded.  I don't have a blog, so this seems like the best place to put to words something I've been thinking about for a while.

One subject I haven't seen discussed is that of Clojure as a "first language."  By that I mean, the programming language that a person first learns before learning any other programming language.  I'm no expert at computer programming, which is why this subject interests me in the first place, but I do think there is a strong case for Clojure's candidacy as a novice's first language.

I'm not sure if I can call Clojure my first language.  I've taken a 101 and 102 course in Java.  I've dabbled in Python, Ruby, and even Io, in order of precedence.  But I've never done any significant work or projects.  I read a lot about programming, I subscribe to many of the programming rss feeds, but I only ever write code when it delights me, not because I have to.  And, of most of the languages I've tried, the languages eventually got in the way and I lost interest.  To my delight, Clojure doesn't get in my way.  I can hack and play and explore with minimal fuss.  I've now written more in Clojure than any other language.

Now, as to whether my positive experience with Clojure is indicative of Clojure's appropriateness as a first language, I have to ask myself whether, in all my years on the sidelines of programming, I've unconsciously progressed and am no longer a novice.  In other words, am I a good subject for this discussion -- a case study on Clojure as a first language?  I think I am, but perhaps other programming novices like me can un-lurk, chime in, and give their experiences.

Seeing as how Clojure is geared towards functional programming, one might think these really advanced concepts of macros, immutability, laziness, etc., aren't suitable for beginners.  In fact, I think languages like Haskel have created a stigma around functional programming.  A friend of mine is in the same boat as I am and I can't get him to try Clojure because he doesn't feel like he can "dive in" to functional programming at this point.  True, Clojure has some advanced concepts, but I've written some neat toy programs in Clojure so far (a small chat server/client, a cellular automaton, some cli tools) and I haven't used any macros, multi-methods, parameter destructuring, or any other gizmos.  I feel confident I'll move on to those when I'm ready.

So yes, Clojure is advanced but it is also simple and easy to understand.  This is due in part to the homoiconicity of Clojure (and Lisp).  As a novice, I can immediately recognize the benefits of homoiconicity, as it lowers the bar to entry – my impression is that it provides a more uniform canvas on which to paint, where I can say "if this works here, then it will also work there."  The transactional memory, as it has often been compared to garbage collection, has also significantly lowered the bar to entry for novices like myself.  I first wrote my multi-threaded chat server/client in Java and my Clojure version is much more readable.  The Java version worked but the Clojure version worked correctly.

I know that it's also been argued in academic circles that Scheme (or some functional language) should be one's first language, not Basic, because it teaches you to think about programming the "right" way the first time.  I can't speak with them as an expert but I can say that if they are right, Clojure makes even more sense.  This has been my experience.  Even as a novice, Clojure's access to Java libraries has enabled me to experiment and learn on my own.  Keep in mind, I'm only doing it because it's fun – There's nothing forcing me to write code.

Now, with that being said, if it's true that Clojure is indeed a good candidate for a first language, is that worth anything?  I hope I've stimulated some thought (and discussion) about the relationship between Clojure and novice programmers, but I also want to argue for taking this aspect of Clojure into account when creating the future of Clojure and it's libraries.  Accommodating novices as a "first language" doesn't have to be a stated design goal, but it should at least be known that the simplicity of Clojure is a win for novices everywhere, and that can only benefit Clojure.

Specifically, I would ask, can Clojure be kept simple?  Can it even move towards more simplicity?  If two future features in Clojure overlap to some degree, can they be combined, for the sake of simplicity?  "More simplicity" might cause a knee-jerk reaction in some people's minds, but it can be argued that simplifying some things, like abstracting the first/rest cons-cell notion from lists on to the rest of Clojure's data-structures, has made Clojure more powerful.  For me, it's also made things easier to understand.

As a side note, I'd like to add that the helpfulness and maturity of the Clojure community is also a win for novices using Clojure.  Please, keep being awesome and helpful and keep gently guiding those of us who are still learning in the right direction.

Thanks for listening and thanks for Clojure!

--
John

[Sean Devlin]

How you teach programming depends a lot on the student. Clojure is a
good choice for many students, but not all of them.

I come from an electrical engineering background, and when I was in
school they taught me C & assembly (on the 6800). This was a very
important experience, because I now have a (vague) understanding of
how code interacts with cricuits. Granted, not everyone needs this,
but it's definitely part of the EE's job description.

Currently, I start most people on Python when I am teaching them to
code. The main reasons are:

* It is one of the more powerful languages available
* It is very easy to read
* It has a lot of books
* It encourages good discipline
* It does a good job teaching a non-lisper a lot about functional
programming
* It is a little easier than lisp (walk before you run)
* Guido designed the language to be a teaching tool

Now, as Clojure continues to mature it will match some of these
criteria. I think the big change will be as more and more books get
written about Clojure. All it really takes is "the next" SICP to use
Clojure, and I think you'll see a lot of adoption in academic circles.

My $.02

Sean

[CuppoJava]

I've also given this subject some thought when I was deciding on what
language I should use to teach first time programmers. In the end, I
ultimately decided against teaching Clojure as someone's first
language, but would like to transition into Clojure as soon as
possible.

---These were my reasons for wanting to teach Clojure:---
-Simple syntax. Students should learn that learning programming is not
learning syntax. I don't want their concepts to be muddled because of
tedious syntax.

-Functional programming. Students should learn how to write programs
in as organized and in as general a fashion as possible. Functional
programming also emphasizes recursion, which is a method of thinking
that should be taught early I think.

-No objects. In my opinion, OOP is taught way too early nowadays,
which results in students writing monolithic inheritance structures.

---These were my reasons finally against teaching Clojure as a first
language.---
-Immutability. I think for a beginner, mutability is easier to
understand. Immutable data structures are quite a bit more
complicated, but most importantly, their advantages are not seen by
someone who has never programmed before. For this reason, Clojure's
STM is unnecessarily confusing for beginners. Imagine trying to
explain why you need the dosync command when trying to set a ref.

-No Syntax. As good as lisp syntax is, it's not what the rest of the
world uses. Algorithms are almost always explained using C, or Java,
or some other C-like pseudocode. Beginner's need to be able to read
these algorithms.

-Less Resources. As great as the Clojure community is, it's still
easier to look and ask for help with a Java program than it is with a
Clojure program. And this is important, because beginners will need A
LOT of help and resources.

-Java interop. One of Clojure's greatest strengths is its seamless
integration with Java. But I found that you require a decent knowledge
of Java first to understand how to use it. For example, (Math/
sqrt ...) and (.add object ..) why do these functions look different
from normal Clojure functions? What's the difference between the two?
What does the (new) command do?
So I found that since you really need to learn Java anyway (to some
degree) to use Clojure, you might as well learn Java first.

Just my thoughts
-Patrick

[Seth]

John,

I hope that learning a Lisp first is a good idea for novice
programmers, because I intend to inflict Clojure on my poor children.
(They didn't take to http://scratch.mit.edu/ and Google's rehash of
BASIC is a non-starter).

So far I have just a few reasons for picking Clojure as a first
language:
* Like big dogs, hopefully growing up with parentheses teaches the
kids to respect instead of fear them.
* The syntax is minimal, consistent, and as you noted designed with
simplicity as a priority.

Obviously my lesson isn't ready yet, but the course has been charted.

Seth

[Lauri Pesonen]

Seth,

2009/8/6 Seth <seth.sc...@gmail.com>:

>
> I hope that learning a Lisp first is a good idea for novice
> programmers, because I intend to inflict Clojure on my poor children.
> (They didn't take to http://scratch.mit.edu/ and Google's rehash of
> BASIC is a non-starter).

There was a post recently on LtU about a paper by Matthias Felleisen
et al. (of Little Schemer fame) about a functional teaching language
that they've been using in schools and freshman classes to teach kids
how to program. I'm still reading it, but so far it sounds pretty
cool. AFAICT it's built on top of DrScheme. It basically provides a
very simple framework for writing graphical apps that can handle
keyboard and mouse events. There's also some distributed aspect to it,
but I haven't gotten to that yet in the paper. Kids seem to like to
write games with it.

http://lambda-the-ultimate.org/node/3540

Not saying that you shouldn't use Clojure, just pointing you to some
other resources for comparison ;-)

> Seth

--
! Lauri

[cody koeninger]

On Aug 6, 3:22 am, Lauri Pesonen <lauri.peso...@iki.fi> wrote:
> There was a post recently on LtU about a paper by Matthias Felleisen
> et al. (of Little Schemer fame) about a functional teaching language
> that they've been using in schools and freshman classes to teach kids
> how to program. I'm still reading it, but so far it sounds pretty
> cool. AFAICT it's built on top of DrScheme.

Scheme pretty much owns this niche, IMHO.

http://htdp.org/

http://world.cs.brown.edu/

[John Newman]

Thanks for all the responses, both on the list and off.

Many good counter-arguments were given, but I think the most compelling one was the issue of Java-interop.  Without a doubt, at least some knowledge of Java is necessary to really do much of anything interesting.  It's unfortunate that such a strength, Java-interop, is also such a dependency in terms of knowledge.  I guess I took my Java knowledge for granted.

So it seems like, as it stands now, Clojure is a tool made for people already preoccupied with getting things done and not so much a tool for learning to program.  It's designed for a certain purpose and that's OK.

Perhaps a better argument at this point would be that, if you are a novice programmer and you already know Java, Clojure should be your next language :) 

[Tchalvak]

As a Noob to clojure, one thing that scares me is the comment-to-code
ratio. I mean, the meaning that can be packed into clojure can be
immense, which is great, but it seems like that means that a lack of
commenting is all the more dire of a problem. The best commented
clojure code that I've seen so far is probably the github clojure
repository, and that seems to have devolved to the minimum comment
density of a single comment per function. Maybe I've just been
looking at the wrong pieces of clojure code, but so far it's been a
turn-off in the code that I've looked through.

[Luc Prefontaine]

A bit of history (or archaeology ?)

We are now back to the old times were we used to struggle about comments in the code.

When I started coding, code was "self-understandable" according to the legend, especially assembly code.
If you could not understand the code without comments, you did not even merit the privilege of
modifying it. That led to the God syndrome which I still suffer from today :)))

Of course that's an extreme and that does not make sense most of the time. Having the ability
to read and understand systems of 100,000 un commented code lines and above is great but
you still have to work with teams of mere mortals if you want to achieve something significant
today, so it's best to keep away from that drug :)))))))))

There is a balance between the # of code lines versus the # of comment lines but it's more based
on the quality of the comments and the language being used than the actual ratio.
Assembly code required most of the time one comment every two lines, Lisp much more less.

Today some will say, we have JavaDoc like tools to save us...

The OO approach can lead to myriads of objects and that requires a tool just to navigate in all the references in the code.
But that automation does not capture the essence, just the ground level details.
JavaDoc is very verbose about the insignificant details but useless in understanding the core behaviour of all these objects floating around
and their interactions because most developers do not want to write decent synopsis in each class with all these HTML tags.
That's why we see all these books written on how to use this framework, this library, ...
That's good for them, they get paid to write their comments in a book instead of the code, why not ?

JavaDoc tries to fill the voids by spitting so many details of microscopic scope that I find it better to read the source code when available to get a better understanding
on how the components interact.

Here we typically in Clojure code use a module header comment block and a function comment block plus some single comment
lines if the code becomes a bit obscure. Each module comment block has a number of items: title, synopsis, author, history
and each function comment block contains a synopsis, warnings, ...

We emphasize explaining what the major chunks do (modules, functions). Clojure being expressive, no need to get
entangled in the details IF the module and function goals are described with sufficient details.

In this context being concise in comments makes sense. You can read the code much more like a book, you just print it
and that's it (I read on paper, never was able to stand reading documents on my computer screen for very long times).

Of course, I used to write 30,000 lines of code and more using a simple text editor (no language sensitivity),
a compiler, a text search tool (no regexp), a linker and it's cross reference facility... I am used to travel lean and this approach is similar to the one
I used in the last 25 years:)))
I remember a custom tool a customer wrote to extract the detailed specs document directly from the code comments
and processing this in a text processor to obtain a clear and well formatted document.
It also made the code quite clear to read as is.

I totally agree no comments is not good at all but JavaDoc style comments in Clojure ? I pray you all, please stay away of it :))))

Luc

Luc Préfontaine Armageddon was yesterday, today we have a real problem...