Hacker News Reader

I totally agree with this. Forcing users to stay in the REPL, poking simple toy examples is just boring and useless.

Just telling, a lot of people got into python, because they wanted to solve a certain problem (I know of an RSS scraper and a state machine framework prototype), and these people just started with a book about python and NO knowledge and after around 3 days, they knew a large amount of python and were sold, because the problem was solved and the language 'felt very good'.

I think generally, programming language designers should stop assuming that their language is novel, or different or whatever and people will be clueless learning about the language.

If you know like Java, C#, Python or Ruby, NO object oriented language will present you with really large surprises (until you meet Javascript with prototypes, and things turn around a bit and common lisp with generic methods and things warp a bit, but still, the basic concepts behind the language are nothing surprisingly new, I still have my objects which receive objects and do things depending on the message receveid).

If you know something along ML, Haskell or some other functional language, it will be really, really hard to surprise you with a functional language. Cool, oCaml has references? Cool, Haskell has monads? That is true, those things might be a bit different, but the basic concepts of immutability, functions and recursion is all the same, no matter what happens.

So, tl;dr? You language is not novel, your language is not new, I have used a language which is similar to your language, I will just be bored if you throw me into Programming 101, because your language is new and I will probably just walk away.

I think this is actually something Microsoft did "right" in regards to C#. One of the first things I read on C# back in 2003 was "C# Programmer's Reference". It was available directly on MSDN, it was easy to get to, and it was a no-holds-barred, for-experienced-programmers-only, introduction to C#. It didn't go into any philosophical discussion on why you should like C#, why you should like its features, etc., it just assumed "you're here already, so you must have reasons for being interested, let's just get down to business." It didn't go into explain "what are integers" or "what are classes", it just assumed you knew what these common concepts were and explained their specific details as they related to C#. After reading that and working for a while, I then read the technical spec, which filled in the gaps around the edges. I was a competent debugger in a week, a competent developer in a month, and an expert in a year.

Mastering the .NET class library took a lot longer, but that is a different issue, and I'm actually rather glad it's a separate issue (but that's a story for another day).

With Lisp and Python, I've tried to take a similar approach. Some of the PLT Scheme documentation -- excuse me, it's "Racket" now -- was very clean and concise. I also tried concurrently reading the R6RS spec, which was productive, though not quite as much as I wanted. Python, unfortunately, has full-programming-noob intros and a technical spec. The spec isn't bad, but it's difficult to parse down into the most important features. I scan through the tutorials, skipping most of the text evangelizing the language. That seems to work for now, but it's taken a lot more conscious effort on my behalf to stick to it.

I don't think such an approach can work with Clojure since the concepts that you bring from other OO languages do not really apply. I originally tried learning on my own by just using the documentation that is there and what I already know. That did not work. I needed something like Programming Clojure to go over all of the basics because Clojure basics and C# basics are different. Without understanding the Clojure basics you cannot do much. Granted someone with more of a background in Lisp or other languages could get started quicker and jump right in.

My point is, everyone has a "standard model" in their head about how all programming languages work. Kind of like how the same system of DNA works in all species. We extrapolate that model based on our exposure to different languages. Being exposed to only OO languages can lead to false assumptions about the over-arching framework of language, but such is the same for strict functional, procedural, or declarative exposure. As exposure to new ideas increases, the underlying assumptions dissolve into a better understanding, and the knowledge helps inform the programmer not only on the new language but on the old languages as well.

For example, I started my journey into programmerdom with JavaScript. Going to C (strict C, not C++) was a major mind-f*, and I didn't make the transition well. When I went to Java, I became much more productive. Learning the finer details of how Java tracks references and performs parameter passing, I suddenly understood C a lot better. Once I knew C better, I realized a metric ton of flaws in my JavaScript. All because greater exposure to language informed my underlying assumptions about what language means. The jump from Java to C# enhanced my understanding of event-driven programming (merely because of how C# provides syntactical features for delegates separately from the class system). I then realized I understood WIN32 events in C a lot better. A similar experience followed my forays into F# (failed attempt into functional programming, but not unproductive), back into C#, into C++, back into Java (briefly), back into JavaScript (this time with the knowledge of first-class functions), and then into Scheme (finally a successful foray into functional programming).

A parallel can be drawn from almost any feature in one language to another feature or application of features in another. It's the essence of Turing completeness, we can emulate any system in any other system (yes, albeit not efficiently).

This seems like an obvious and easily attainable goal, but in fact, it isn't. The article suggests Python and Ruby provide a better n00b experience and that is far from true. For instance, Ruby becomes a nightmare as soon as you start mixing your own gems with gems installed by the packaging system. That situation is hard to avoid, as distros usually only support outdated Rails gems and the n00b that thinks 'let me just grab the latest stable Rails version from github' is in for some nasty surprises concerning incompatible combinations of gems. We solved this by moving to Enterprise Ruby and keeping everything local and selfcontained, but it is definitely not very n00b-friendly either. With Python I've had similar experiences: when I was in need of a decent XPath library (mind you, this was over 4 years ago), the best one I could find (4Suite) needed to be installed manually, with all the usual problems of missing -dev libs, install paths and whatnot.

A summary of the problem is: the configurations people run are so diverse that it is hard to provide installation instructions that work for all, or even most, of them. As soon as someone wants something not covered by the simplest of tutorials, many of them will run into issues.

I think the only solution is documentation. The only thing that works is catalogueing all known problems people have encountered, so that others can easily find solutions to those problems. The largest problem of this solution is that n00bs need to understand their systems and they often don't.

While that's true, I think you're misinterpreting the usage of "n00b" here. People who are new to the language will be developing something small from the start, not trying to mix-and-match bleeding-edge, custom, distro-provided and language-specific-installation-tool-provided packages to achieve large or complex goals. "As soon as someone wants something not covered by the simplest of tutorials", they'll have the confidence in the language required to attack the problem in full force.

Think of it like a school system: the required years of school (the problems that everyone has to deal with, starting off) should be streamlined and easily-digested, with a lot of thought and care put into the user experience. Secondary education (the problems that individuals have once they're doing something complicated and meaningful) is allowed to be more free-form, because the user now has a base of skills to fall back upon.

While true - Clojure,with it's java dependencies, is a good few notches harder to figure out by brute force - or at least it feels that way.

I picked up Ruby basics in a weekend of hacking around. I know there are still some things to figure out re: gems and big project management... but none feel insurmountable.

Python - same deal.

Clojure, on the other hand - has all this buzz on the net, but it's just that-much-more-complex to make even a seasoned language n00b a bit put-off. (if you don't have your head firmly around the java build process and basic librarires, it's hard to get past the repl in clojure)

The best thing I found so far is clojure-box: Clojure Box is an all-in-one installer for Clojure on Windows. It's inspired by the Lispbox: you simply install and run this one thing, and you get a REPL and all the syntax highlighting and editing goodies from clojure-mode and Slime, plus all the power of Emacs under the hood at http://clojure.bighugh.com/

BUT it is based on emacs, and unless you're familiar with emacs, its not going to be too friendly...

Then, if you want web-apps, you'll have to get your head around ring, compojure or some other library. If you want graphics, at this stage you are kind of limited to whatever java can provide, and there is no easy IDE inspector to show you what's available / defined at any given moment...

There are many ways to get around all of these, but they all seem to require a fair bit of digging around, google-fu and whatever else is needed to make it go.

Maybe what clojure needs is a simple executable wrapper that handles the java classpath requirements, provides a simple (but extendable) IDE, provides some common sample projects like a simple web app (blog), graphics (temp converter), maybe multi-threaded (the ants.clj example) all complete with good documentation.

I know that would have made my life a bit easier...

This is something node.js has done very well. Anyone with basic javascript experience (and really, isn't that everyone?) can go from zero to fast, functional web server in 2 minutes. Then hit github and figure out which simple web framework to play with (the fragmentation is either a problem or benefit depending on your view) and voila, another 5 minutes later, a full, integrated, single language web stack. Very good for noobs.

"When teaching someone a programming language, your first goal should always be to get them to the point where they've made something real in a domain they understand"

There are steps before that! The user's first concern is how to run the damn thing. If they can't get past this stage, they will give up and never return. The user should be able to download, install, and copy/paste/run "Hello, World!" with no bullshit. No IDEs, no configurations, no REPL. You have time later to sell all of that. A programmer who can't run from a file is tethered to your tutorial, even if they want to write more permanent code. Give them that freedom immediately, and give them a win immediately.

After they can actually run a program, then give an interesting example or two, and provide live links to up-to-date tutorials. It's irritating to see "official" links that are three versions out-of-date, and I see it too often. Examples should include a little bit of magic from the language, so the curious programmer thinks "Hm, that's not familiar. I wonder how that works!"