Clojure as a first programming language?

[Towle]

Hi all,

Thanks for taking the time to read my post. I'm interested to get some
opinions from experienced Clojure programmers on whether the language
would be a good first language to learn, or rather to learn in-depth.
I have minimal experienced with more common languages like Java, HTML,
and C++, but having the personality I do, felt compelled to shop
around a bit before choosing a first language to learn seriously on a
deep and intuitive level-- perhaps my odd notion of there being a
connection between a programmer and the first language s/he
understands on that high of a level. So after shopping around
thoroughly and picking up bits about on theoretical computer science
and the history of programming languages, I decided to pick up a Lisp;
I'm intrigued by the greater concept/idea behind the Lisp family of
languages.

After a long while trying to figure out which of the Lisps would be a
good first choice, I stumbled across Clojure and immediately thought
it a brilliant idea, conceding of course that at my current level of
knowledge, I likely have no idea what a brilliant idea in computer
programming looks like. Regardless, it still feels brilliant.

As I see it, among other features of the language, the idea of a Lisp
designed to be a capable choice for "real-world" code applications,
that is a Lisp which embodies the spirit of that family of languages
yet one which resolves many of the "practicality" complaints which
stand as hurdles on a Lisp's path to real-world use. For my situation,
that of a student who wants both a) to learn a first language I can
have a real, intellectual appreciation for and b) to begin the journey
to "expertise" in a language it would be practical to code web
applications in.

So, Clojure programmers, am I wrong? Should I pass on Clojure in favor
of another langauge? Or learn Common Lisp or Scheme first, then try my
hand at Clojure? Am I mistaken for a different reason? Or perhaps
there are some criteria I should consider before diving in?

Thanks in advance, and again for taking the time to read.
--Towle

[Adrian Cuthbertson]

Hi Towle,

Judging by the articulateness of your post, I would say that Clojure
would definitely be an ideal language for what you are looking for. It
is not "handed to you on a plate" and you will have to engage deeply
to achieve your goals, but if you do so, along with the increasingly
prolific documentation available, the archives of this forum and the
on-going posts here, you will be able to learn and apply just about
any technique that has ever been addressed regarding advanced
programming, best computer science practices and very practical
applications.

- Regards, Adrian.

> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

[Geoffrey Teale]

Hi,

I don't post here much and so you may see that as a reason to discount
what I say. Infact that would probably be a good plan. I generally
talk a load of twaddle. With those caveats firmly in mind here's my
tuppence worth.

I'd hate to think your first language is defining as you suggest. I,
like most people of my age, wrote mostly BASIC and assembly code for the
first five or six years of my programming experience. In my case that
was all for the Zilog Z80 and later the Motorola 68000. While I have
fond memories of those times I generally wouldn't want to go back to
those languages or tools, and most of my work exhibits a functional
style that is far from idiomatic for the average BASIC or assembler
programmer. I suspect that what Clojure programmers have in common is
not their programming roots, but the openness of their minds and a
desire to continuously learn and improve. A large number of
programmers learn one language and then try desperately to avoid
learning anything else. Another group are keen only to learn new
skills they think are marketable (they tend to be the ones who are
always begging to go on the latest training course in Microsoft this or
Oracle that in my experience). I would tell you to avoid being in
those groups, but I think it's useless - you will develop in accordance
to your character. That you are here is probably a good sign though.

So.. back to your actual question. Here's my thoughts. Clojure is a
relatively young language and there's still a lot about the landscape
that is evolving. This in turn means that some things are hard to
work out, and only documented in the most superficial way. This is
both a joy (after all you need a challenge!) and occasionally a pain in
the bum. In fact it is quite reminiscent of those days of assembly
programming I had back in the 1980s. Whether this is something you want
in your life only you can tell, and perhaps the answer is too try.
Prepare to be frustrated and prepare to get good at asking questions -
two elements that are unavoidable in life, so why not practise! If you
think you have the interest and the will power to get through those
things then Clojure would indeed be an excellent place to throw your hat
into the ring.

Before you dive in there are some other aspects to consider. Although
there are new libraries being written all the time, it is not at all
uncommon to drop directly into the world of Java libraries when doing
productive work in Clojure. This is a great strength of Clojure and
also a weakness. Dropping into Java space can make it harder to realise
the benefits that Clojure offers. There also a danger that, in order
to get things done, what you'll end up learning is the java libraries,
not the idiomatic Clojure way of doing things. Furthermore Clojure
inherits some of the complexities of Java. The word CLASSPATH could
easily haunt you for the rest of your life. There are easier
environments to work in!

So I guess the answer is this: if you're looking to get the most from
Clojure as a language the first step might be to become proficient as a
functional programmer - if you get there then the way Clojure does
things will mostly just make sense. In terms of the materials
available to you a better language to learn functional programming in
might be Haskell, or if it really must be a Lisp (which is certainly not
a bad idea!) then I would look to Scheme. Then, armed with that
knowledge come back to Clojure.

Now, please forget everything I just told you and go out and make your
own mistakes - it's the only way to learn!

--
Geoff Teale

[John Harrop]

So, Clojure programmers, am I wrong? Should I pass on Clojure in favor
of another langauge? Or learn Common Lisp or Scheme first, then try my
hand at Clojure? Am I mistaken for a different reason? Or perhaps
there are some criteria I should consider before diving in?

I, for one, think Clojure might be an excellent choice. 

[Tayssir John Gabbour]

Hi,

As an occasional Clojure user, and someone who's used Common Lisp a
lot, I'd venture that Clojure is a good first choice. But let me
metion areas of difficulty first. Geoffrey Teale discussed the big
things, so let me mention some little ones:

- Java's classpath currently demands that you respect its
inflexibility. If you have a problem with a library which seems to
work for everyone else, the classpath is a big thing to check.

(Clojure's add-classpath should increase its flexibility. But people
aren't supposed to depend on it; and I noticed it interacts weirdly
with Java's database manager, JDBC. Last week, JDBC promised it knew
of my MySQL lib which I loaded using add-classpath; but when it came
time to actually pull data, it complained that it didn't have the
library loaded.)

- Also, Java prioritizes security over usability. Which I also
recently ran into:
<http://my.opera.com/karmazilla/blog/how-to-grab-the-certificate-from-
a-website-and-import-it-with-java-keytool>

That said, I would've been best served by learning Clojure or Common
Lisp first. (Or flexible ancestors like Lisp Machine lisp. Not Scheme
though.) Due to whatever quirks in my personality. For me, Clojure can
be engrossing like a good video game; I'm not always happy (maybe I'm
coasting along and then the big boss kills me a few times, and I have
to figure out how to defeat or bypass it), but it's at least not
unnecessarily boring.

In addition to the all-important video game metric, you get to interop
with the normal world through Java/.net/etc, and I'm sure you'll meet
with the approval of at least some theoreticians. Clojure may also
help you evaluate other languages better.

There's some advantages Common Lisp holds over Clojure (and vice-
versa), but the ones most important to me are dwindling. For instance,
CL's multimethods have really nice features. I use them regularly for
web programming. However, Mikel Evins is releasing an interesting
Clojure library for this called Categories. (Not that I know much
about it.)
http://mikelevins.livejournal.com/


Hope this helps,
Tayssir

[CuppoJava]

There are more qualified people than me on these boards, but I can
offer my own personal experience, which is to say, as a first language
I would still recommend going the C/Java/Basic/Assembly route first
before going with a Lisp.

Because simply, I couldn't appreciate functional programming until I
did a fair bit of imperative programming first. And because imperative
programming is closer to the raw machine, I find that reasoning about
functional programming requires, in a lot of instances, to think about
the equivalent code in an imperative language.

For example, why is Laziness a good idea? What are the inherent
limitations of Class-based object-oriented programming? Why is single
inheritance limiting? How can multiple-inheritance come back to haunt
you? What is "hanging" onto your head? Why does this really elegant
functional code run so slowly? Why is "eval" a bad idea?

So I think avoiding an imperative language means that there's too much
fundamental understanding about the machine that you would skip over.
Not to mention, that most libraries will be using an imperative
language, so you'll be having to learn it eventually in order to read
the libraries even if you don't plan on writing any imperative code
yourself.

These points are especially important with Clojure, which is designed
to interoperate closely with its underlying Java. Many people on these
forums have already expressed the opinion that it's too impossible to
understand Clojure completely without knowing Java.

Just my 2 cents
-Patrick

PS: If you decide to go ahead anyway and learn Clojure, and find it an
easy and enjoyable trip. I would be glad to hear about your
experiences. I am preparing to teach an introduction course in
programming and I'm still debating what language to use as an intro.

[Base]

My 2 cents (probably only worth 1 cent...) as someone who is learning
Clojure right now is that it is a great language, but there are a lot
of great languages and all have their strengths and weaknesses. Given
your curiosity and apparent thirst for knowledge, you wont learn just
one language and that is the way to go, IMO. Programming languages
are, to me, tools to accomplish goals, and what is right in one
situation is not necessarily the best in another.

I started programming using SAS (statistical software), which is
likely not the avenue of most of these people. I moved into web
stuff, then Java,etc. What is great about Lisp(s) is that it is
different conceptually from many of the other languages out there
(i.e.- Java), in how you think, but still flexible enough to encompass
many problems. That is the coolest part of it to me.

So in that regards I totally agree with Lisp as a choice. The
difficulty with Clojure is (as others have mentioned) that the
interoperability with Java (which is so great) also means that you
have to learn Java as well - and really do so simultaniously. That
will be a challenge, but you will be better for it, for sure.

I rhighly recommend you check out SICP (free HTML book here....http://
mitpress.mit.edu/sicp/full-text/book/book.html and videos here
http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-lectures/)
and prepare to have your mind blown. They use Scheme in this class
(though I hear they have just switched to Python for this calss
now...!) which is just another Lisp with slightly different syntax.
It was a good place for me to start.

Good luck!

[Constantine Vetoshev]

On Dec 1, 12:38 am, Towle <towle.m...@gmail.com> wrote:
> So after shopping around
> thoroughly and picking up bits about on theoretical computer science
> and the history of programming languages, I decided to pick up a Lisp;
> I'm intrigued by the greater concept/idea behind the Lisp family of
> languages.

In your research, did you find Abelson and Sussman's book, Structure
and Interpretation of Computer Programs? The full text is freely
available at http://mitpress.mit.edu/sicp/, and video lectures from
the class are at http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-lectures/.
I have never seen a better introduction to programming and computing
than SICP. It uses Scheme, but you do not need to study the language
separately; you'll learn it naturally as you go through the book. Be
sure to do the exercises. :)

You can certainly go through SICP using Clojure, but you'll have to
deal with semantic differences between Scheme and Clojure (especially
in laziness and sequence behavior), so I don't recommend it. After you
have gone through the book, you'll pick up Clojure in no time at all,
and will probably find it an enjoyable language for real-world
programming.

[Geoffrey Teale]

Just want to second everyone pointing to SICP. A better in-depth
introduction to programming has yet to grace my desk. There are also
video lectures available on line:

http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-lectures/

If this material had been so readily available in the late 80s I would
have saved myself a long, long path to enlightenment :-D

--
Geoff

[Chouser]

On Tue, Dec 1, 2009 at 10:29 AM, CuppoJava <patrick...@hotmail.com> wrote:
> There are more qualified people than me on these boards, but I can
> offer my own personal experience, which is to say, as a first language
> I would still recommend going the C/Java/Basic/Assembly route first
> before going with a Lisp.

I think understanding how computers work (Von Neumann machines,
I suppose) is indeed important. If you're serious about being
a good programmer, you need to understand pointers, memory
allocation, virtual memory, IO scheduling, etc. You at least
need to be aware of all the fiddly bits that modern programming
environments try to abstract away, so that when they fail to
behave well, or just plain fail, you have a fighting chance of
understanding what's going on.

But do you need to learn all that *first*? I don't think so.
I didn't -- I learned BASIC and didn't know anything about
pointers. Then I learned Pascal and pointers, and didn't know
anything about malloc or process scheduling. Then I learned
C and some operating system internals.

So I think there's no harm in learning a nice clean high-level
language first, as long as you eventually learn some C and OS
stuff. Maybe you'll find you like C and get into hardware driver
development. Or more likely you'll be happy to tuck away the
C knowledge and do mid- or high-level work in a language that
allows you to (most of the time) ignore such details. Clojure is
designed to be a good place to end up in this more likely case,
and I think is largely succeeding.

I think the biggest down side to learning Clojure as a first
language, as others have mentioned, is its relationship to the
JVM. Although this is a strength when it comes to actually using
Clojure to get real things done, especially while Clojure is
still so young, I fear it's a weakness for a first language.
Currently doing almost anything interesting requires not only
knowledge of Clojurey things (immutable collections, functional
style, lazy seqs, etc.) but also Javay things (static methods,
method inheritence, classpaths, javadocs). This is one reason
why I recommend http://projecteuler.net -- it allows you to
accomplish *something* with nearly pure Clojure, even though you
don't get to do anything graphical or webby. So I *hope* that's
good enough for Clojure to be a good first language -- after all,
why not start off where you should end up? -- but I worry that
it's not.

If you're tenacious and hungry for knowledge, I'd say "go for it."

--Chouser

[Tayssir John Gabbour]

Interestingly, there's this book which is a crash course on building a
computer stack from the ground up: from logic gates, to a compiler, to
an OS. And the simulator, in which you build all these things, is in
Java.

Nisan/Schocken's _The Elements of Computing Systems_:
<http://www1.idc.ac.il/tecs/>

Luke Gorrie mentioned porting the circuits he wrote (not, and, or,
xor, mux, dmux, half-adder, full-adder, adder) to Clojure.
<http://lukego.livejournal.com/17711.html>

So... there may be a strange loop here where a good path to learning
these low-level things is a counter-intuitive one.

I agree that Java-y things (static methods, method inheritence,
classpaths, javadocs) are an issue; maybe there should be a little
tutorial for people that surveys "What's a .jar file?" and "public
static void... whuh?"


All the best,
Tayssir


On Dec 1, 5:19 pm, Chouser <chou...@gmail.com> wrote:

> why I recommendhttp://projecteuler.net-- it allows you to

[Harold Ancell]

At 09:42 AM 12/1/2009, Base wrote:
>[...]

>
>I rhighly recommend you check out SICP (free HTML book here....http://
>mitpress.mit.edu/sicp/full-text/book/book.html and videos here
>http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-lectures/)

Note that while quite useful and fun, these lectures are based
on the first edition of SICP.

>and prepare to have your mind blown. They use Scheme in this class
>(though I hear they have just switched to Python for this calss
>now...!)

Actually, they dropped 6.001/SICP and much if not most of
the material it teaches.... :-(

>which is just another Lisp with slightly different syntax.
>It was a good place for me to start.

Also check out the Open Courseware versions of 6.001; this
is the most recent and there is an earlier archived one
linked off of it:

http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-Computer-Science/6-001Spring-2005/CourseHome/index.htm

or http://tinyurl.com/845qq

Includes lots of useful stuff such as a pointer to the On-Line
Tutor, where you can among many other things do problem sets
and have them automagicly checked.

- Harold

[John Newman]

I actually posted on this subject back in August.

http://groups.google.com/group/clojure/browse_thread/thread/7146112187d8468c/89ad67c6b7ec3b5c?hl=en&lnk=gst&q=clojure+as+a+first+language#

Seems like Java is the biggest bar-to-entry for programming novices learning Clojure at this time.

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

--
John

[Fogus]

> Because simply, I couldn't appreciate functional programming until I
> did a fair bit of imperative programming first.

As did I, but for a different reason... the end of a long stretch of
torture.

Seriously though, I'm probably like many programmers (at least in the
states) in that my first experience started at home plucking away on
my old Commodore 64. However, by first language outside of BASIC was
Lisp in undergrad and I have to say that it was a great start. In
many ways I think it's better for the neophyte programmer to think
algorithmically and use a language that closely models that thought
process. To me, Lisp/Scheme/Clojure fits that model and so I would
without hesitation recommend Clojure as a starting point. Don't get
me wrong, I think learning C (it was my 3rd language) is likewise
important, but it's heavy in incidental complexities that just muddle
the problem at hand and probably not good as a start. New programmers
need to solve as many problems as they can as soon as they can --
Lispy languages let them solve the *actual* problems and C-like
languages force them to solve the actual problems *plus* a whole bunch
of ancillary problems.

-m

[Alex Osborne]

I think it's hard for anyone experienced in subject to give a
recommendation on how to get started, as there's just so much knowledge
you always assume. Maybe if you've tried teaching programming using a
variety of languages you can.

I'm a little younger than the C64 guys, I first taught myself
programming (would have been while I was in primary school) in QBasic
using the builtin reference documentation, an old GW-BASIC reference
manual and a book on Pascal. I didn't have a Pascal compiler or
GW-BASIC, just the qbasic.exe that came with DOS so I used the Pascal
book as a conceptual introduction. I then figured out myself how to
translate some of the Pascal stuff, by looking at the example programs
(gorillas.bas, nibbles.bas) that came with QBasic.

I don't think it matters too much where you start, but it's absolutely
critical to learn several languages. I routinely write code in Clojure,
C, Java, Python, Ruby, JavaScript, various shell-scripts, ELisp and from
time to time x86 and ARM assembler. Be very careful not to fall into
the trap of thinking your first language "does everything", even if it
is a lisp.

Clojure would be challenging language to start with, as (all?) the books
and documentation are aimed at people who are already programmers. But
if you like a challenge then perhaps that's even a good thing. If
you're already a techie type person and are happy to fiddle around in
configuration files and the command-line I don't think it should be that
much of an obstacle.

CuppoJava wrote:
> Because simply, I couldn't appreciate functional programming until I
> did a fair bit of imperative programming first. And because imperative
> programming is closer to the raw machine, I find that reasoning about
> functional programming requires, in a lot of instances, to think about
> the equivalent code in an imperative language.

Quite a number of universities teach Haskell or Scheme as a first
language, as functional programming can be easier to understand (as it's
more maths-like) and you can get up and running quickly with a program
that actually "does something". They then later do a high-level
imperative language, often Java or Python. Then in second year they
usually have some more low-level courses like system architecture,
operating systems, or high performance computing that cover C and
assembler and processor internals. They usually cover the computation
theories (automata, turing machines, lambda calculus, combinatory logic)
in second or third year as well.

I think it's important to get experience with all of these at some stage
if you want to be a good programmer.

> For example, why is Laziness a good idea? What are the inherent
> limitations of Class-based object-oriented programming? Why is single
> inheritance limiting? How can multiple-inheritance come back to haunt
> you? What is "hanging" onto your head? Why does this really elegant
> functional code run so slowly? Why is "eval" a bad idea?

I don't think these questions are at all suitable for a beginner. I
think you'd need several languages under your belt before you could even
understand the question, let alone be able to formulate a good answer to
them. But I also don't think you need to be able to answer them to be
able to write beginner-level programs in Clojure.

> So I think avoiding an imperative language means that there's too much
> fundamental understanding about the machine that you would skip over.
> Not to mention, that most libraries will be using an imperative
> language, so you'll be having to learn it eventually in order to read
> the libraries even if you don't plan on writing any imperative code
> yourself.

I don't think you need to learn an imperative language first, but you
must learn one at some point.

Cheers,

Alex

[John Harrop]

On Tue, Dec 1, 2009 at 8:30 PM, Alex Osborne <a...@meshy.org> wrote:

Clojure would be challenging language to start with, as (all?) the books
and documentation are aimed at people who are already programmers.  But
if you like a challenge then perhaps that's even a good thing.  If
you're already a techie type person and are happy to fiddle around in
configuration files and the command-line I don't think it should be that
much of an obstacle.

Actually, you can download Netbeans and install it with a few mouse clicks, and Enclojure with a few more, and then have a working REPL to try short code snippets at with a few more. No mess, no fuss, no manual configuration file hacking, no command line (excluding the REPL prompt of course).

[Tayssir John Gabbour]

Oh, I forgot a major issue -- some unhelpful error messages, at the
moment. (There's nothing wrong with making errors; they provide
feedback on unusual or unexpected situations.) Unfortunately, I
suspect you'll have a hard time with Clojure's error messages.
Particularly if you're not used to lazy sequences (but rather eager
ones), where code doesn't necessarily execute until the last moment.

There's a couple ways I deal with this. For one thing, when something
unexpected happens when I'm hacking something out, I use a more
conservative approach, where I think things through more carefully and
modularize things better. Because the debugging cost of a bug has
increased. Other possibilities include using asserts (code which
signals an error when an assumption of yours is violated), and better
testing.

Also, I stick types onto data, and customize how they print to screen.
So for instance, an eBay order might print like this:
#<eBay 132 paid>
emphasizing only order# and payment status, rather than its in-memory
representation as a big XML structure. And when I do want to examine
big representations, I use a "pretty printer" to format them readably.


Tayssir



On Dec 1, 4:00 pm, Tayssir John Gabbour <tayssir.j...@googlemail.com>
wrote:

> about it.)http://mikelevins.livejournal.com/

[Geoffrey Teale]

On 12/01/2009 08:51 PM, Fogus wrote:
---- %< -----

> I think learning C (it was my 3rd language) is likewise
> important, but it's heavy in incidental complexities that just muddle
> the problem at hand and probably not good as a start. New programmers
> need to solve as many problems as they can as soon as they can --
> Lispy languages let them solve the *actual* problems and C-like
> languages force them to solve the actual problems *plus* a whole bunch
> of ancillary problems.
>
> -m
>

I would argue that Clojure is equally encumbered with ancillary problems
- they just aren't usually in the code. It is perfectly possible to use
clojure to run simple scripts, or just to work at the REPL, but to get
to that point you have to do more work than you would have to in python,
for example. Even if you go down the route of using something like
Enclojure you have do the following:

- Find out that Enclojure exist
- Find out that Enclojure needs netbeans,
- Get and install netbeans.
- Find out how to install netbeans extensions
-Get and install the Enclojure extension.
- Find out how to start a clojure project or REPL in enclojure.

All of those things are good learning experiences if you want to learn
how to setup an IDE to do productive work in clojure, but they are all
ancillary to your primary goal of learning about programming. Every
one of those steps is an opportunity to fail, to misunderstand, to
become disheartened and to give up.

I don't mean to criticise projects like Enclojure, but I think IDE's are
a symptom of complexity, not a cure. When you work in an IDE the
solutions to your problems are easy to find and execute (usually) but no
easier to understand. As an analogy think about the network settings
dialog in Windows or Mac OS X - the information there isn't any easier
to understand because it's in a GUI, TCP/IP didn't get easier, a netmask
is still a netmask. What got easier was finding out that these
concepts exist - knowing how to fill them in is a whole other problem,
and your ISP telling you what to put in those boxes won't help you
understand how networks work.

Something that has changed since the days when I started programming is
the normal interface people have with the machine. When I worked on my
Sinclair Spectrum I was faced with BASIC as my primary control mechanism
for the machine. If I wanted to run a program that process began with
issuing the BASIC command to load a program from tape. I had an
operating manual that came with my computer and it was a natural
progression to try other commands. As a six year old one of my primary
activities was to write small programs that drew very blocky, 8 colour
pictures. I was only vaguely aware that this was programming, I was
just using the computer. It was a simple, direct interface to the
capabilities of the machine.

To do similar things in a language like Clojure you would have to go out
of your way to make use of a graphical API delivered by the platform -
it's far from a natural way of working with the computer. Perhaps this
is why there is a roll for an environment like DrScheme, but still I
think we lost something along the way.

But perhaps I am just an old fool dreaming of blue remembered hills.
--
Geoff Teale

[Nur Azhar]

Hi,

it's almost 8 years later and I am going to ask these same question since it wasn't really answered

Thanks for taking the time to read. I’m interested in trying out Clojure for my first programming language--at least, the first programming language in which I intend to commit myself to becoming proficient.

http://stackoverflow.com/questions/10509283/clojure-as-a-first-programming-language

I hope someone replies

[Ryan Waters]

It's a question simply stated with an answer that depends on a lot of things. And, as is often the case with the person giving an answer, without asking other people I can only relate it to my own experiences with clojure and programming in general.

The fun and freeing thing about clojure is the flexible ways it allows you to program and think about programming challenges.  There's a number of reasons that make this true.  Languages I've used in the past at times felt like their design was limiting, usually in the form of making easy things easy and hard things harder than necessary.  Maybe they provided too much "help" and turned inner workings into a difficult-to-know black box, or they provided concurrency building blocks without providing a safe framework to prevent a novice programmer from shooting themselves in the foot, or they were designed in such a way that locking in developer mindshare was a primary motivator.  I don't think clojure has these problems.

Diving into a new language requires good learning resources, particularly in the ways you find most natural to use.  Are you self-sufficient?  Is documentation enough or would it be faster and more useful to be able to ask someone questions?  Do you have any higher education in programming?  Buy some clojure books and spend time with them.  The mailing list, IRC and slack, et. al. can all be resources for specific questions but more general questions (even this one) can be more difficult to answer.

Pick something you want to make and explore what different languages have to offer and you'll naturally find one that resonates with you.  I love clojure.  It's not perfect but it's still smarter than I am, which I appreciate.  It rarely gets in my way.

--

You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to

clojure+unsubscribe@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

---

You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nathan Smutz]

If you're new to tooling, and want to try Clojure right away, I strongly recomend Oakes' Nightcode. Install the JDK and Nightcode, and you'll have Clojure with its popular build tools (Leiningen and Boot) built in, beginner-friendly parenthesis management, LightTable-like instant evaluation in the margins, and a connected REPL when you run your project.
https://sekao.net/nightcode/

Stack-vomit error messages are the main reason I'd have to think hard before recommending Clojure as a first/educational language.
Apart from the clarity of the smidge of relevant info in there, there's the aggravation of having to stop thinking about your problem to play Where's Waldo, the Line-Number Edition.

I've heard there have been some attempts at error-mesaage translators. Does anyone have a recommendation?

[Lee Spector]

> On Dec 4, 2016, at 7:17 PM, Nathan Smutz <nsm...@gmail.com> wrote:
> I've heard there have been some attempts at error-mesaage translators. Does anyone have a recommendation?

Colin Fleming has done some nice work on this in Cursive.

He gave a talk on it at Clojure Conj 2015: https://www.youtube.com/watch?v=kt4haSH2xcs

> If you're new to tooling, and want to try Clojure right away, I strongly recomend Oakes' Nightcode. [...] beginner-friendly parenthesis management [...]

Nightcode used to be my recommendation for total newbies, and I used it in my courses to teach beginners. But in the current versions of Nightcode, parinfer is always on, which in my opinionated opinion is the antithesis of beginner-friendly parenthesis management. It is wonderfully clever and some people love it, but in my experience it's not at all beginner-friendly to interfere with the student's existing typing skills and expectations in the way that paredit does, or especially in the way that parinfer does.

I spend a fair bit of time evaluating and re-evaluating clojure environment options for new programmers. There are a bunch of really great tools out there, but from my perspective none of them currently quite nails all of the requirements in this area. FWIW my currently favored approach is to use a modified version of Gorilla REPL: https://groups.google.com/d/msg/clojure/Rqsc8j3rJS8/ehAw4ut4BwAJ. But I am always on the hunt for better alternatives, and I am currently planning to revisit Proto REPL (in Atom), following a nice talk on it by Jason Gilman at Clojure Conj 2016: https://www.youtube.com/watch?v=buPPGxOnBnk

-Lee

[Colin Fleming]

On 5 December 2016 at 02:56, 'Lee Spector' via Clojure <clo...@googlegroups.com> wrote:

Colin Fleming has done some nice work on this in Cursive.

Sadly that work is not in Cursive proper yet, although I'm planning to get it in there soon once I work out what I'm doing with spec.

However I think macro errors are only a part of what Nathan is asking for. It's true that they cause some of the more confusing stacktraces, but there are other errors which cause stack traces but which are really compiler errors. I've been considering some kind of pattern matching system to try to work out from a stacktrace what the problem really is. After all, experienced Clojure developers can often work out easily what the issue is from a stacktrace, so I'm sure a machine can too. However although I'm considering this, I don't have it at the proof of concept stage yet.

 

... I am currently planning to revisit Proto REPL (in Atom), following a nice talk on it by Jason Gilman at Clojure Conj 2016: https://www.youtube.com/watch?v=buPPGxOnBnk

I agree, that talk was great and Proto REPL looks lovely. I think it would probably be a great match for your needs.

 

Cheers,

Colin

 -Lee