Comment by moron4hire | Hacker News Reader

Comment by moron4hire | Hacker News Reader

Parent Full thread

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