Clojure as first language

[Terje Dahl]

I believe that the simplicity of Clojure's syntax in combination with its clean functional nature and prefix notation makes it ideal as a "first language" for anyone who wants to start programming - including, and perhaps especially kids.

Is there anything written about this?
Arguments ... experiences ... perhaps even research ...?

[Val Waeselynck]

I believe there was a Clojure programming environment released exactly for this... but can't see to find it on Google.

I too believe it is great for beginners, except for maybe 2 aspects:

• if Clojure is your first language, the 2nd language is likely to be painful :) - I heard feedback about a guy who learned to program in Clojure and found Python pretty messed up afterwards.
• because of Clojure's hosted nature, most learning resources today presume some programming experience.

You should maybe contact Chris Granger if you want to invest some time in this, what with Light Table and Eve he's probably one of the persons who have given this topic most thought.

See also the work of Elena Machkasova who has taught introductory CS classes with Clojure: https://www.youtube.com/watch?v=k5erDyDPzgc.

I personally believe one of the most important features for learning is the REPL. Declarative data notation plays a great role too, and built-in documentation is the cherry on the cake.

Personal feedback: In France, in prep school, we learn programming with OCaml - which is indeed great especially for the kind of mathematical / algorithmic stuff we do, but I think Clojure has the advantage of targeting platforms suited to a wider range of applications (including websites).

HTH,

[Val Waeselynck]

And of course, let's not forget about Clojure Bridge!

[Lee Spector]

I've given a fair bit of thought to this because I teach beginning programmers and I also teach Clojure, but my Clojure classes currently require at least one prior programming course. 

I'd love to start with Clojure, and to my mind the main obstacle is indeed that the programming environments that are available, while continually improving with respect to beginner-friendliness, aren't quite there. 

After switching among many of the alternatives over the last several years (during which I've been very grateful to the tool developers who have always been responsive and helpful), this semester I am trying something new, using just leiningen + a version of Gorilla REPL modified to allow the opening of any .clj file. So far I am really happy with this, which is working well for my class and also giving me more hope for teaching total novices Clojure in the future.

The need for occasional Java interop is also an issue, but in my experience it's a minor one that can be dealt with on a case by case basis.

And documentation that assumes too much knowledge can also be an issue, but again, this is improving and less of a problem, I think, than the programming environment issues.

One little feature of the core language itself that I find to be difficult for beginners is the way that regular parentheses () are used in printed values for different data types... But I know this can't change, and I don't know if anything can be done to make that less confusing.

 -Lee

PS I second the shout out to Elena Machkasova's work! 

--
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
---
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+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Lee Spector, Professor of Computer Science

Director, Institute for Computational Intelligence
Hampshire College, Amherst, Massachusetts, USA
lspe...@hampshire.edu, http://hampshire.edu/lspector/, 413-559-5352

[Walter van der Laan]

Check out the presentation that Tommy Hall gave at EuroClojure: https://vimeo.com/100425264

From slide 12 onward he describes his Clojure implementation of geomlab and how it can be used to teach children how to program

[Elango Cheran]

You should also look at clojure-turtle, which is a port of Logo into Clojure:

https://github.com/google/clojure-turtle

We often use Logo to teach kids how to program for the first time, and Logo is a Lisp (!).  Logo has reinforced its relevance with Scratch, which is a GUI-based, less-textual version of Logo.  So we should be able to connect Logo to Clojure without too much contortion, and we should also be able to use the turtle graphics paradigm to teach kids & beginners Clojure.  

Those are the motivations for the clojure-turtle project.  

As you progress through the project's Readme, the line between Logo's intro to function calls and Clojure's FP paradigm gets subtly blurred.

The project has also inspired the turtle graphics-based content in the latest ClojrueBridge curriculum overhaul.

On Sun, Feb 21, 2016 at 11:28 AM, Walter van der Laan <walterva...@fincite.nl> wrote:

Check out the presentation that Tommy Hall gave at EuroClojure: https://vimeo.com/100425264

From slide 12 onward he describes his Clojure implementation of geomlab and how it can be used to teach children how to program

[Attila Domokos]

I started teaching my 7 yo son programming in Clojure. I blogged about our first 2 sessions here: http://www.adomokos.com/2016/02/teaching-clojure-to-7-year-old.html

Hope you'll find something useful in there.

[Michael Sperber]

Terje Dahl <te...@terjedahl.no> writes:

> I believe that the simplicity of Clojure's syntax in combination with its
> clean functional nature and prefix notation makes it ideal as a "first
> language" for anyone who wants to start programming - including, and
> perhaps especially kids.

There's a lot of research out of the PLT and DeinProgramm projects on
this. You'll find the relevant ones here:

http://deinprogramm.de/publications.html

These are not about Clojure per se, but discuss Scheme, which is close
enough.

tl;dr: No, Clojure is not an ideal language for teaching beginners. For
teaching beginners, you should use a language specifically engineered
for beginners, such as the teaching languages that come with Racket.
(The transition to Clojure from these languages should be quite easy,
though.)

--
Regards,
Mike

[Daniel Kersten]

In my experience running the local clojure user group, a lot of clojure beginners (NOT programming beginners) struggle with two things: the paradigm switch (immutable data etc) and clojure's error messages.

I think if a beginner to programming started with clojure, they may be able to sidestep the paradigm switch (because they haven't yet learned any alternative approaches), but would struggle even more with the error messages. Java stack traces are rather daunting at the best of times, but I can imagine a beginner seeing something cryptic like wrong arity followed by a 20 line stack trace would be rather demoralising.

Since this is a problem even seasoned programmers (but new to clojure) have, I feel this needs to be improved before I'd be comfortable recommending the language to absolute programming beginners.

Beyond that, as long as you introduce the concepts one at a time (should be relatively easy, since clojure is all about untangling the various concepts), then I think clojure would make a pretty interesting language to teach programming with. When I tutored first year CS students in the past, the biggest issue was introducing too much at once, but I feel that most of clojure can be drip-fed as needed.

[Mark Engelberg]

Racket is a language that is explicitly designed for creating other languages.  DrRacket is a remarkable pedagogical IDE.  For those who are interested in providing a smooth learning path to Clojure, one of the best ways to do that would be for our community to invest some effort in building a "Clojure language mode" for DrRacket.  It wouldn't have to be incredibly efficient, and wouldn't have to support the full range of Clojure constructs, just a nice pedagogical subset of Clojure.

Racket-implemented languages interoperate with each other and with the IDE, so beginning programmers could use DrRacket and get great error messages and graphical stack traces in the IDE, as well as access to all its great teachpack libraries (such as the functional graphics/animation library) and the ability to use the various curricula designed by the PLT group.

The transition from Racket to Clojure already is fairly small, but this way, beginners could then work through a tried-and-true curriculum using Cloure syntax for a truly seamless transition to full-blown Clojure once they are ready.

I believe this would be far easier and more useful than trying to build a robust set of features for beginner programmers into Clojure (given that the DrRacket team has already spent decades on this problem, so we're better off figuring out how to leverage their work than trying to reinvent and reimplement it).

[Lee Spector]

When I taught with DrScheme back in the day it was a very good experience overall, and while I haven't taught with DrRacket I understand that the team has continued to do great things, and that this is probably a perfect first environment for many teaching contexts. FWIW in my context the restricted language subsets were more of a hinderance than a help, but since we could get around them, and since everything else about the environment was so nice, I was quite happy with the experience overall.

But I nonetheless think that actual Clojure can also be a great first language. Although it would take a *lot* work to do all of the things that the PLT/Racket people have done, I think that we're already on the cusp of having sufficiently good Clojure environments for beginners. For me, I think we'll be over the threshold for teaching Clojure as a first language as soon as the "quick real start" story gets a little better, making it trivial for total newbies to set up an environment and start coding, with a few essential features like auto-re-indenting and as few unnecessary sources of confusion as possible. Once we're over that threshold (and many projects are quite close, but not yet quite there IMHO) I think that Clojure-first will be a reasonable path, and that things will then get even better as the work that people are doing on improved error messages etc. can be incorporated. 

So I hope that Clojure tool developers will continue to push in this direction too! 

 -Lee

PS if anyone is curious about how I've been using just lein + Gorilla REPL as a teaching environment, which I mentioned earlier, you might want to look at my brief notes at http://faculty.hampshire.edu/lspector/temp/Secrets-of-Gorilla-REPL.pdf. Note that this is still missing one key feature for more general use: Save Without Markup. Right now, any edited file will be "polluted" with markup, which would obviously be problematic in many situations. A student in my group is looking into adding this feature.

[Matching Socks]

Zach Oakes gave a bracing talk about Clojure-as-a-first-language, unpedantically entitled "Making Games at Runtime with Clojure", at the 2014 Clojure conj.

https://www.youtube.com/watch?v=0GzzFeS5cMc

[Daniel]

> I heard feedback about a guy who learned to program in Clojure and found Python pretty messed up afterwards.

If love to read this if you can dig up a link.

[Matching Socks]

The post-Python effect came up briefly in another Conj talk -- in 2015 -- given by Elena Machkasova and two students, one of whom had had Clojure first and the other Python.  Their school offered it either way.

https://www.youtube.com/watch?v=n0yN1GauxCA

[blake watson]

In a lot of ways, Clojure is a good first language: Except for project.clj files (which you don't absolutely need right off the bat), it's not too hard for a novice to look at a simple Clojure program and not see 40 things he doesn't understand. (I don't know if it's still like this, but the initial C# programs I wrote came with pages of boilerplate, though hidden.)

In other ways, it's less good: any language discouraging state is going to face the "what just happened?" challenge.

Clojure, in particular, has a weakness in its multi-page stack dumps, and its "Null Pointer Exception". The former is an awful thing to force a beginner to confront. The latter can be just plain mysterious.

I've had good luck with Smalltalk.

On Tue, Feb 23, 2016 at 2:53 AM, Matching Socks <phill...@gmail.com> wrote:

The post-Python effect came up briefly in another Conj talk -- in 2015 -- given by Elena Machkasova and two students, one of whom had had Clojure first and the other Python.  Their school offered it either way.

https://www.youtube.com/watch?v=n0yN1GauxCA

[Terje Dahl]

Blake.

Would you elaborate on this last comment about Smalltalk?
What did you do?
What was the outcome relative to expectations?
What were some good and bad aspects of Smalltalk?
And how might this compare to Clojure?
Any links/references?

Terje

[Terje Dahl]

Michael.

I what ways do the teaching languages in Racket differ from Clojure?
What would *you* "hide" or change in Clojure to make a more suitable teaching language?
Based on the Racket languages...
Based on your experiences and/or opinions...


Terje

[Terje Dahl]

Elango.


The turtle graphics concept is often used as a basic teaching tool.  Logo, Scratch, etc.
It seems easy to understand for children, and is a good way to get started.

I have some additional questions to that, though:
How long before children get tired (bored) with the concept?
How would one move on from Turtle graphics?
What other concepts or paradigms might also be used?
Are there other different approaches that might work equally well (or better)?
Any personal ideas/suggestions?

Terje

[Terje Dahl]

Val.

You (and others) mention Clojure Bridge.
I am familiar with the concept.
But do you know where I might find one or more compendiums or course curriculums used as part of Clojure Bridge?

Terje

[Terje Dahl]

Lee.

About the confusion with parens - do you mean that an output-ed list/seq looks exactly like a callable s-expression?
Please elaborate.

Terje

[Gary Verhaegen]

On Friday, 26 February 2016, Terje Dahl <te...@terjedahl.no> wrote:

Lee.

About the confusion with parens - do you mean that an output-ed list/seq looks exactly like a callable s-expression?
Please elaborate.

Terje

Yes. If you print the list (1 2 3) it prints as a callable form, and then you have to get into reading, evaluation, etc.

Aphyr's Clojure tutorial series went there. IIRC the second or third chapter was devoted to that.

On the other hand, in the Racket curriculum, they define limited subsets of Scheme used as teaching languages; when the student first learns about lists, they construct them using cons and they print as cons forms, i.e. the (in-memory) list '(1 2) would print as

(cons 1 (cons 2 (cons ())))

This is the kind of simplifications that are done in the teaching languages and that allow the course to avoid a number of advanced topics in the beginning. It avoids a lot of confusion at the cost of a small lie and an extra effort when you want to introduce macros and the "code is data" idea. (Which you usually don't want to do in an introductory course anyway.)

For a short (and, I found, very enlightening) peek at the HTDP curriculum, you can skim through the Systematic Program Design course by Gregor Kiczales on edX:

https://www.edx.org/xseries/how-code-systematic-program-design

This is by a wide margin the best introductory programming course I have ever seen.

Re: ClojureBridge, the curriculum is on GitHub:

https://github.com/ClojureBridge/curriculum

[Vardhan]

On Fri, Feb 26, 2016 at 1:58 AM, blake watson <dsblak...@gmail.com> wrote:
> Clojure, in particular, has a weakness in its multi-page stack dumps, and

export JVM_OPTS="-XX:MaxJavaStackTraceDepth=1"

-Vardhan

[Val Waeselynck]

https://github.com/ClojureBridge/curriculum/blob/gh-pages/TEACHING.md

[Lee Spector]

Gary: I'm not sure that's actually what I meant, although I'm not 100% sure what you mean so I'm not sure :-). FWIW I *do* always want to introduce "code is data" to my beginners, albeit with eval, not macros, and I'm generally not on board with the whole concept of restricted teaching languages for the contexts in which I teach, although I understand that others find them useful.

Terje: What I mean is just that if you type something like (map inc (range 10)) into a REPL you'll get (1 2 3 4 5 6 7 8 9 10), which sure looks like a list but is really a lazy sequence. In most cases it doesn't matter, as it behaves as it would if it were a list. But sometimes it does matter, e.g. (str '(1 2 3 4 5 6 7 8 9 10)) => "(1 2 3 4 5 6 7 8 9 10)", whereas (str (map inc (range 10))) => "clojure.lang.LazySeq@c5d38b66". I can't recall other specific situations in which it matters right now, but usually when I teach a class using Clojure, students run into this and are pretty confused. Once they figure out what's going on they often think that doall will help, but it doesn't, and I show them that they can apply list to the lazy sequence to get a real list. As I said, I know this can't change, and it's not the biggest problem in the world. But the fact that different kinds of things have identical printed representations is a less-than-lovely aspect of the language for beginners, in my experience. One of the the few!

 -Lee

--
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
---
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+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Steve Miner]

> On Feb 26, 2016, at 9:53 AM, Lee Spector <lspe...@hampshire.edu> wrote:
>
> But sometimes it does matter, e.g. (str '(1 2 3 4 5 6 7 8 9 10)) => "(1 2 3 4 5 6 7 8 9 10)", whereas (str (map inc (range 10))) => "clojure.lang.LazySeq@c5d38b66"

There’s a bit of subtlety around `str` vs. `pr-str`. In many case, pr-str will give more intuitive results. Unfortunately, it’s not easy for beginners to discover.

[blake watson]

>>Would you elaborate on this last comment about Smalltalk?

Smalltalk, as a language, is very simple. Its syntax is, essentially, "object message" embellished with keyword parameters, like "player attack: monster with: sword using: slash". The environment, unfortunately, is cluttered, and its version of Clojure's stack is stacks of DNU (do not understand) windows. So I used Stephane Ducasse's "Squeak: Learn Programming With Robots" (currently freely available online) which provides a sandbox where you can test out the effects of various commands on "robots". (The "robots" here are much like the "turtle" of yore.) 

>>What did you do? What was the outcome relative to expectations?

My kids were around 10 at the time. The oldest is now 20 and a pro programmer who seems to be able to pick up whatever language is thrown at him (Javascript, Java, Clojure, Ruby, just in the past six months). The others pursued more artistic interests, but they were able to grasp the concepts and not be intimidated.

>> What were some good...aspects of Smalltalk?

The good aspects of Smalltalk are simplicity of syntax, and a lot of friendly tools. Avdi Grimm has an amusing screencast "In Which I Make You Hate Ruby In 7 Minutes"[1] which gives a taste. (My understanding of Ruby is that Mats wrote it to be Smalltalk without the "weird stuff", only later realizing the value of the "weird stuff".) Besides Robots, there is Etoys[2] which is programming through drawing pictures and "assembling" (with literal pieces) code. There's another pedagogical environment, much like Etoys, called "Scratch" which was written in Smalltalk and then (alas) rewritten in Java, but a version for Pharo Smalltalk exists ("Phratch" [3]). Phratch can be used with Mindstorms, though I can't speak to the quality of it.

Among the "weird" aspects of Smalltalk are those that can be classed as "good" or "bad" depending on point-of-view. All the great tools, the IDE, the debugger, the graphical interface exist because Smalltalk is a living, breathing environment on top of the VM. The IDE is part of the environment; there will be no emacs vs. vim flamewars because you'll use the built-in editor. There are no files, per se. When you create a class, you've created a living thing that responds to messages. When you create an object, that object lives and persists in your "image". Something like the Flappy Bird figwheel demonstration in Clojure is de rigueur in Smalltalk. (A modern take on this is agile visualization[4].) 

Everything is an object. This is more of a problem for seasoned programmers who sometimes have trouble sending messages to numbers. Hence the "for" loop in Ruby. In Smalltalk, there's no special syntax for it. A number takes the "to" message with the end parameter, followed by a block of code to execute.

1 to: 5 do: [ :i | Transcript show: i]

A lot of little things like that, akin to the Lisp parentheses horror that many people seem to have (or the consistent, but unusual, use of semi-colons in Pascal) can be off-putting.

>> What were some...bad aspects of Smalltalk?

The worst thing about Smalltalk, in my experience, is that its learning curve is sort of square-wave shaped. You can grasp, intellectually, the syntax in literal minutes, and get comfortable with it in a few days. I assume that ease was what inspired Mats, which is the height of irony, given the jungle of Ruby syntax. But then it's often a huge leap to grasp the object library. (Exception being the collection classes, which are a thing of beauty.) You can build an Etoys app, again, in minutes. But when you've gone past what Etoys will give you out of the box, you're must then go into the full environment (and you can't really transition Etoys projects to regular Smalltalk). Etoys is a novice tool, extending it is a master's task.

Much like Lisp, expert Smalltalkers have absorbed so much about their beloved tools, they can't always see the problems a beginner will have. The (rather friendly) community's size is an issue here, though the Pharo[5] branch is much more aggressive about answering questions and being responsive to change. The old guard is Squeak[6]. Pharo takes a "fail fast" approach whereas Squeak is almost like "Smalltalk-80 forevah!". (Those are extreme characterizations, though.)

Because it's a live environment, it's possible to get stacks of DNU windows, which can be intimidating, and it's too easy to donk up your image (some version of ST are better or worse in this regard), though fixing is pretty simple.

It's not really a career path. Smalltalk has a strong emphasis on pedagogy, but (creator) Alan Kay's focus is on education =generally=, i.e., using computers to grasp math, physics, biology, etc. It has the same sort of fallout as other great tools, in that while you =can= adapt easily to new languages, you also end up missing the amazing place you came from.

>> And how might this compare to Clojure?

Smalltalk, in some ways, is the anti-Clojure. If Clojure despises state, Smalltalk is =all= state. The image is, in essence, a big ball of state. It suffers, then, from Rich Hickey's complected-ness (and how!). But state + debugger makes for a powerful teaching tool. Smalltalk has some functional stuff (select, collect, reject, inject, detect—which map roughly to keep, map, filter, reduce and (some #{...}) and it is genuinely used (not just lip service) but the philosophy is definitely "objects are responsible for their own state, and you must trust that", with the footnote that, well, if you don't trust it, you can change it. The whole system is right there in your image.

Tougher concepts to grasp, like laziness, transducers, asynchronous programming are less "up front" in ST than in Clojure. (Actually, ST doesn't even have built-in laziness or transducers.)

(Side note: I'd love to make a Clojure for the ST VM.)

>>Any links/references?

In addition to the footnotes, you've there's:

Dolphin Smalltalk on Github: https://github.com/dolphinsmalltalk/Dolphin

Lots of free Smalltalk books: http://stephane.ducasse.free.fr/FreeBooks/

Amber is to Smalltalk what ClojureScript is to Clojure: http://amber-lang.net/

Javascript done Smalltalk style: https://www.lively-kernel.org/

Mini-Squeak in the Browser: http://bertfreudenberg.github.io/SqueakJS/demo/simple.html

That last is Squeak 2.2 but if you've got a powerful enough machine running a decent browser, you can run up to Squeak 4.5 in the browser.

Hope this helps!

===Blake===

[1] http://devblog.avdi.org/2015/05/11/in-which-i-make-you-hate-ruby-in-7-minutes/

[2] http://www.squeakland.org/

[3] http://www.phratch.com/

[4] http://agilevisualization.com/

[5] http://pharo.org/

[6] http://squeak.org/

--

[Benjamin Van Ryseghem]

On 1 Mar, 2016, at 22:54, blake watson <dsblak...@gmail.com> wrote:

>>Would you elaborate on this last comment about Smalltalk?

Smalltalk, as a language, is very simple. Its syntax is, essentially, "object message" embellished with keyword parameters, like "player attack: monster with: sword using: slash". The environment, unfortunately, is cluttered, and its version of Clojure's stack is stacks of DNU (do not understand) windows. So I used Stephane Ducasse's "Squeak: Learn Programming With Robots" (currently freely available online) which provides a sandbox where you can test out the effects of various commands on "robots". (The "robots" here are much like the "turtle" of yore.) 

Just a side note, do not go for Squeak, try Pharo (a Squeak fork), the UI looks a to better, same goes for the IDE.

Stef wrote several books about Pharo that can be freely found online.

>> What were some...bad aspects of Smalltalk?

The worst thing about Smalltalk, in my experience, is that its learning curve is sort of square-wave shaped. You can grasp, intellectually, the syntax in literal minutes, and get comfortable with it in a few days. I assume that ease was what inspired Mats, which is the height of irony, given the jungle of Ruby syntax. But then it's often a huge leap to grasp the object library. (Exception being the collection classes, which are a thing of beauty.) You can build an Etoys app, again, in minutes. But when you've gone past what Etoys will give you out of the box, you're must then go into the full environment (and you can't really transition Etoys projects to regular Smalltalk). Etoys is a novice tool, extending it is a master's task.

There are Squeak By Example and Pharo By Example to try to tackle that.

Much like Lisp, expert Smalltalkers have absorbed so much about their beloved tools, they can't always see the problems a beginner will have.

+1

The kinda old community makes it a bit weird on that side. Expect people there to have done Smalltalk and Smalltalk only for the last 30 years.

Because it's a live environment, it's possible to get stacks of DNU windows, which can be intimidating, and it's too easy to donk up your image (some version of ST are better or worse in this regard), though fixing is pretty simple.

I think this is really to compare to most Lisp that also have a live environment where you can break things ;)

First thing you learn though is that an image is “disposable”.

I think the image based approach is a big issue when it comes to adoption, but I also think it’s the best debugging experience I have ever had.

It's not really a career path. Smalltalk has a strong emphasis on pedagogy, but (creator) Alan Kay's focus is on education =generally=, i.e., using computers to grasp math, physics, biology, etc. It has the same sort of fallout as other great tools, in that while you =can= adapt easily to new languages, you also end up missing the amazing place you came from.

Pharo is trying to bring (back) Smalltalk to company.

But I think the VM is the biggest constraint on this nowadays.

My 2cts,

Ben

[Elango Cheran]

Hi Terje,

Answers in line below:

The turtle graphics concept is often used as a basic teaching tool.  Logo, Scratch, etc.
It seems easy to understand for children, and is a good way to get started.

I have some additional questions to that, though:
How long before children get tired (bored) with the concept?
How would one move on from Turtle graphics? 

What other concepts or paradigms might also be used?

I just posted a blog post on the subject of Clojure + teaching kids programming + Logo:  http://google-opensource.blogspot.com/2016/03/teaching-kids-to-program-in-their.html  

The timing of that post and this email thread is fortuitous.  The post should address the above points.  But to briefly summarize, the point of the clojure-turtle project is to have a version of Logo that shows that we can build a bridge between kids learning Logo (a Lisp) and solving more complex problems using Clojure (a Lisp).  

What the post didn't say is that the project's Github front page README shows examples that start to very subtly insert and blend in more Clojure functions and functional programming ideas.  I believe that a lot more work can be done to turn subtle hints of a Logo-FP bridge into a fuller, more comprehensive course of instruction.  

If carried out and executed well, I think we can avoid what is described in this page under the section "The Tragedy of Logo" - http://c2.com/cgi/wiki?LogoLanguage -- "most of the schoolkids who learned Logo hit the ceiling of their instructors' knowledge before they reached any limit of the language's capabilities ... a six-year-old can learn the basics of turtle control in a matter of minutes, but can continue building on those fundamentals indefinitely, and eventually use the same tools to master advanced programming concepts"

 

Are there other different approaches that might work equally well (or better)?
Any personal ideas/suggestions?

I haven't yet read the original book Mindstorms by Seymour Papert, but that's the next thing to do.  I believe he proposed a much, much richer, tactile, multi-sensory turtle experience than *just* a sprite on a 2D graphics plane.  It's a simple idea but a very powerful one.  I think it is worth exploring to the fullest, and my intuition is that doing so will produce the most return for the effort given.  It's funny that our notion of Logo is a subset of all that he originally proposed, and that our common usage of Logo is a small subset of the language's full power.

[Terje Dahl]

Thank you all for your wonderful feedback.
It is both insightful, varied, deep.

I intend to consolidate your feedback and more into some sort of report or paper which I will then publish.
I will post back when I have something ready.


Terje

[Paul Gowder]

As a clojure beginner and programming semi-beginner (advanced beginner? I'm decent but not pro dev level at Python and R and have messed around with a few others), switching to clojure because the functional style feels more natural than all that object ick, I can speak from personal experience here:

1. Yeah, the stack traces are horrible.
2. The other big beginner barrier I feel is the tooling. In lots of ways, leiningen is amazing (particularly the automatic grabbing of dependencies), but the forced project structure is really painful. It feels like a massive barrier to not just be able to throw up some code and have it run without having to set up a whole directory structure and all the rest. (It would be nice in particular to be able to use gorilla-REPL without having a project for it---maybe with lein-try somehow??) Been thinking about trying boot to make this simpler, but since every library seems to be documented in terms of leiningen, that means just means learning two tooling systems instead of just one.

So just from my standpoint, those are the two big things to work on to make clojure appropriate as an absolute beginner language.

[Lee Spector]

> On Mar 11, 2016, at 9:43 PM, Paul Gowder <paul....@gmail.com> wrote:
>
> 2. The other big beginner barrier I feel is the tooling. In lots of ways, leiningen is amazing (particularly the automatic grabbing of dependencies), but the forced project structure is really painful. It feels like a massive barrier to not just be able to throw up some code and have it run without having to set up a whole directory structure and all the rest. (It would be nice in particular to be able to use gorilla-REPL without having a project for it---maybe with lein-try somehow??) Been thinking about trying boot to make this simpler, but since every library seems to be documented in terms of leiningen, that means just means learning two tooling systems instead of just one.

Is "lein new app foo" that complicated?

I'm using just leiningen + Gorilla REPL for a class I'm teaching it now, and this doesn't seem to be a barrier. In fact I'm using a modified version of Gorilla REPL that can open any .clj file, and we've set things up so that "lein new gorilla-app foo" creates the Gorilla-enabled project. I'm very happy with the setup, and I haven't seen the student confusion that I've had with every other tooling setup. FYI here's a little auxiliary document that I give students to help get them going: http://faculty.hampshire.edu/lspector/temp/Secrets-of-Gorilla-REPL.pdf

One feature that needs to be added to the modified version of Gorilla REPL to make this useful more generally is "Save without markup," since currently any file that you open and then save will get markup added, which you won't want in many cases.

-Lee

[blake watson]

On Sat, Mar 12, 2016 at 2:42 PM, Lee Spector <lspe...@hampshire.edu> wrote:

> Is "lein new app foo" that complicated?

If I understand Paul correctly—and am not just imposing my own similar feelings on him—the problem is not that "lein new app foo" is complicated, it's that it creates a directory structure that is complicated for the beginner. Clojure is by far not the worst in this regard, but a new app creates seven folders (root, doc, resources, src, test, src/root and test/root) and nine files (.gitignore, .hgignore, CHANGELOG.md, LICENSE, project.clj, README.md, intro.md, core.clj and core_test.clj). This is a lot for someone just trying to grasp "Hello, world."

The less you have to say to the student ("you can ignore all that for now") the better. The less you have to tell the user to toggle mysterious switches (as with the JVM stack options) the better.

What would be good would be a "lein new beginner foo" that had a truly minimal setup. It looks like this has been tried over the years, though I don't see any currently working templates that fit the bill. If I can't find one, perhaps I'll build that.

[gvim]

On 21/02/2016 10:45, Terje Dahl wrote:
> I believe that the simplicity of Clojure's syntax in combination with
> its clean functional nature and prefix notation makes it ideal as a
> "first language" for anyone who wants to start programming - including,
> and perhaps especially kids.
>

> Is there anything written about this?
> Arguments ... experiences ... perhaps even research ...?
>

For kids and student maybe but for anyone setting out to earn a living
from programming Clojure would be a bad choice right now as the job
market is overwhelmingly OOP-dominated and once you grok Clojure OOP can
become intolerable. Better to get a foundation in Javascript,
Python/Ruby and Java first then add Clojure later. According to
Indeed.co.uk there are only 21 jobs in the UK with Clojure in the title.

gvim

[Lee Spector]

On Mar 17, 2016, at 11:10 AM, blake watson <dsblak...@gmail.com> wrote:

On Sat, Mar 12, 2016 at 2:42 PM, Lee Spector <lspe...@hampshire.edu> wrote:

> Is "lein new app foo" that complicated?

If I understand Paul correctly—and am not just imposing my own similar feelings on him—the problem is not that "lein new app foo" is complicated, it's that it creates a directory structure that is complicated for the beginner. Clojure is by far not the worst in this regard, but a new app creates seven folders (root, doc, resources, src, test, src/root and test/root) and nine files (.gitignore, .hgignore, CHANGELOG.md, LICENSE, project.clj, README.md, intro.md, core.clj and core_test.clj). This is a lot for someone just trying to grasp "Hello, world."

Understood and agreed. But I just show my students where core.clj is and say to ignore everything else, except project.clj which we'll use only to add dependencies to use libraries. This seems to be simple enough, in my experience. 

[Mark Engelberg]

On Thu, Mar 17, 2016 at 11:12 AM, gvim <gvi...@gmail.com> wrote:

Better to get a foundation in Javascript, Python/Ruby and Java first then add Clojure later.

Disagree.  It's easier to go from functional programming to imperative programming than vice versa, so it is better to teach functional programming first.

The reason is that imperative programming can be thought of as a small, added layer, an extra mutation capability beyond writing pure functions that can be used judiciously to achieve certain effects.  Grounded in functional programming, it's easy to go to imperative programming, because you are *adding* a capability.  You can still write pure functions in an imperative language (although the language gives you less support for doing so), so your prior knowledge applies.

On the other hand, if you learn imperative programming first, you learn a way of writing code that uses mutation in everything.  You develop no awareness of the boundary between the set of things you can compute with and without mutation.  From your perspective, everything requires mutation.  When you try to make the move to functional programming, you feel completely lost and completely hamstrung, because a capability you imagine is essential for writing any code is now missing.  You have to completely relearn how to think about coding, figuring out how to write code without mutation.  You are subtracting a capability from your language, which is much, much harder, because all your instincts about how to code no longer apply.

[Val Waeselynck]

Really depends on how the brain of the programmer is wired IMHO. To some people, the intuitive part of programming is fiddling with bits, to others it's all about abstraction.

--

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

You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/i1CUQKROJ5U/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.

[Colin Fleming]

Have you come across any new programmers who think in terms of bit twiddling? I agree with Mark - this tends to be intuitive once you've learned that that is all there is. This might have been the case long ago when people started programming by learning about how CPUs work, but computers are so complex now that very few people start out that way any more.

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+u...@googlegroups.com.

[Raoul Duke]

one word: redstone.

[Paul Gowder]

On Thursday, March 17, 2016 at 12:10:21 PM UTC-5, blake watson wrote:

On Sat, Mar 12, 2016 at 2:42 PM, Lee Spector <lspe...@hampshire.edu> wrote:

> Is "lein new app foo" that complicated?

If I understand Paul correctly—and am not just imposing my own similar feelings on him—the problem is not that "lein new app foo" is complicated, it's that it creates a directory structure that is complicated for the beginner. Clojure is by far not the worst in this regard, but a new app creates seven folders (root, doc, resources, src, test, src/root and test/root) and nine files (.gitignore, .hgignore, CHANGELOG.md, LICENSE, project.clj, README.md, intro.md, core.clj and core_test.clj). This is a lot for someone just trying to grasp "Hello, world."

The less you have to say to the student ("you can ignore all that for now") the better. The less you have to tell the user to toggle mysterious switches (as with the JVM stack options) the better.

Partly this, yes.  And partly also that there's a lot of semi-documented magic behind the scenes.  For example: leiningen has "new" and "new app." The tutorial says that they're different, and that one is appropriate for applications and the other for libraries, but doesn't offer any clue why, or what the differences might be---and it's hard to see, even coming from other languages, why there might be a reason for the difference. Is it something about namespacing and some kind of "main" path through the code for applications?  That's just my guess... 

Or the classpath.  Apparently this is a JVM thing, and leiningen hides it from the user, but sometimes it breaks, and then it's kind of a guessing game why unless one knows Java.  

And it doesn't help that it also makes unintuitive default decisions for one sometimes.  For example, I actually just spend several hours last night beating my head against the REPL's refusal to let me use core.matrix in a library I'm working on---it took a SO post plus some good luck to learn that core.matrix requires clojure 1.7+, and then notice that for some mysterious reason the version of leiningen I didn't install all that long ago defaulted to 1.6.   (The REPL, of course, didn't actually throw an error that gave any hint that there were version problems; the dependency just silently failed, and then when I tried to use the namespace that required core.matrix, it just threw an incomprehensible error claiming that it couldn't find the file --- see http://stackoverflow.com/questions/36051140/clojure-classpath-troubles-loading-code-and-dependencies-with-leiningen/36052171#36052171 --- that's just unfriendly behavior.)

Don't get me wrong. I'm not complaining. The more I learn about leiningen, the more I like it---the power to just swap out language versions altogether by changing one line in a config file, for example, is wonderful---and makes a lovely contrast with, for example, the Python 2/3 craziness. But the fact that there's a ton of machinery going on behind the scenes to actually get anything running, even with good tools that abstract it away (when they work right), makes the ecosystem less beginner-friendly, because when something goes wrong it's a beast to figure out why. 

[Paul Gowder]

Thinking about this a little more, it seems to me that the real beginner-unfriendly bits of clojure that actually are a problem for basic learning (so not legitimately difficult stuff like quoting and macros) all come from the JVM. Errors that are incomprehensible? JVM. Classpath confusion? JVM. Need for tooling and complex directory structures? That's probably the JVM too. Having to wrap half of the verbs you use in anonymous functions in order to get them to map and filter and reduce and such because they're really methods that have arcane and incomprehensible rules about whether they're "static" or (whatever the opposite of static is) and have to be attached to nouns to make them do work? Oh hai JVM. Lack of tail call... Well... Yeah.

So... what do folks think about something like Hy for beginners instead? All the Lispy goodness, all the "hey there's a serious batteries-included library back here" hosting, but with a kind and gentle Dutch hug behind them instead of the punch in the face that is the JVM? After all, the slow performance of Python isn't a big deal for total beginners, and total beginners also don't need all the sexy advanced stuff like concurrency that makes Clojure worth the JVM pain.

craxy thought... But not insane?

[Val Waeselynck]

On 17 March 2016 at 22:25, Colin Fleming <colin.ma...@gmail.com> wrote:

Have you come across any new programmers who think in terms of bit twiddling?

I probably expressed my thoughts poorly - maybe 'bit twiddling' is not the right name for it, maybe it is place-oriented programming or just imperative programming - let's just call that imperative programming for what follows.

I have come to believe, from observation, that to a significant number of programmers, imperative programming offers more accessible building blocks than functional programming as embodied by Clojure, and many of them never make it past this initial comfort.

This changes nothing to the fact that, in my opinion, beginners are much closer to building robust programs on the whole if they start by learning functional programming, just like swimming is a more efficient way to move in water than walking, although much less intuitive.

This saddens me, and I hope I'm wrong. I personally found Clojure much easier to learn than any imperative / OO language, but having a Mathematics background there's little merit in that - high-level abstractions is what I find easiest in programming. Not so for everybody unfortunately :/

This is just my very limited personal experience, I would love to see actual studies on this topic.

[Woo]

For many years, MIT taught engineers the Scheme dialect of Lisp as a first language (see: The Wizard Book.) They appear to have moved to Python to get wider access to libraries and infrastructure. I was discussing with a friend recently what would have happened if Clojure had arrived in time.  Both sets of lectures are available free online.