Comment by tetha | Hacker News Reader

Comment by tetha | Hacker News Reader

Parent Full thread

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

Reply on news.ycombinator.com