Asking as a CS major who first learned C, then C++, and didn't touch LISP and Prolog until the upper divs, how difficult is it to learn a functional language as your first programming one? Wouldn't it be trippy? When I first learned that Berkeley students had to learn Scheme first, it made me think of them as hardcore... though I may be overestimating its difficulty.
> how difficult is it to learn a functional language as your first programming one? Wouldn't it be trippy?
As easy as learning a dysfunctional one if not easier.
Now scheme may not be the best example of this as its syntax is entirely alien (then again all syntax is, when you've never developed), but the canonical is the following statement:
x = x + 1
If you've never developed before, the only place where you've seen something like this is maths, and in maths this is completely nonsensical.
So learning imperative programming does require lots of deprogramming and reprogramming of your brain. Which make up most of the hurdles of learning an FP (or logic, or dataflow, ...) language later on: your brain (or its section that has to do with development) has been baked in imperative idioms and methods, FP languages not only don't use these but use completely different techniques to solve the same problems, so you have to "unlearn" the old ones and "relearn" the new ones.
I can corroborate that for people with no prior programming experience, but a significant math background (engineers, stat and math majors), the statement "x = x + 1" is befuddling to them. They have no concept of time in a sequence of imperative statements. That is, they don't intuitively understand that statements get executed, and that the state of the program changes (potentially) after each statement. It takes real effort on their part to internalize this idea.
Now, I'm sympathetic to your final paragraph, but having never taught functional programming to anyone, I can't corroborate it. Personally, I went through something similar when first learning how to think functionally.
You are overestimating its difficulty. It is actually the other way around: C and C++ are harder than Scheme since you have to deal with all kinds of silly syntax rules, inconsistencies (from the view of a Schemer), memory management, pointers and other diversions.
It is akin to writing a text in your favourite text editor versus writing a text in Word. The latter will distract you with mark-up, random auto-'correction' and other diversions I'm still repressing.
The best thing one can do is get The Little Schemer[1], download DrRacket[2] and go through the book.
My school taught Haskell as the intro language to math majors, and my basic observation was that people who had never programmed before and people who where really good at programming already got it pretty quickly. On the other hand people in the middle that had programmed a bit before and where competent, but not great, where really confused and never really got it.
In the second half of the course, where you learnt Java and OO, was totally confusing to most those who'd just learnt Haskell as their first language and many people who got great grades on the Haskell part failed the Java part.
So it would seem that whatever you learn first is easy and normal and whatever you learn after that is confusing and difficult.
Scheme(or LISP dialects in general) is not just functional; it's multiparadigm. It sure is trippy, but gives a very solid foundation for later stages of academic and professional life.
The difficulty could be due to the brain damage C++ causes. Before I get incinerated, I have to remind you of Dijkstra quote about BASIC ("mutilates the mind beyond recovery").
Both BASIC and C++ (and Java, Smalltalk and so on) fixate several ideas about computing that make it harder to understand very different concepts. In a sense, that qualifies as mild brain damage.
I learned programming with BASIC on an Apple II+, went through FORTH (GraFORTH), C, Pascal, APL (The write-only language) and FORTRAN (in college) and later learned OOP with Smalltalk (and worked a bit with Actor). Did a lot of VB too (I had bills to pay), Perl, Java and Python. For obvious reasons, I don't completely agree with Dijkstra on the BASIC thing. I never liked C++ much, possibly because I learned OOP with Smalltalk and C++'s OOP seemed to me a misappropriation of the acronym. All things considered (it took me 8 years and a job offer to decide to learn C++) Smalltalk damaged me beyond recovery.
I made an abortive attempt to learn C++ by myself long ago, and was frankly scared of programming for a while because of it (was fine with BASIC, but.. a good idea of how I felt: http://www.qwantz.com/index.php?comic=1178).
But a couple months ago I decided to give it another go with Scheme and I have been pleasantly surprised by how much more natural it seems to me. I'm having fun!
"As I see it, a software engineer who hasn't worked through SICP with Scheme, a basic editor and command line, is like a surgeon who has never dissected a frog and faints at the sight of blood." -- Priceless !!! Great comment, Stephen.
I'd better get my mint copy of SICP off the bookshelf then. Being a SE able to dissect frogs and not faint at the sight of blood apparently doesn't mean anything these days ;-)
I think the point is that, with Scheme, the tool you use is less important than the thinking you do. With Java, you have to worry about your environment before you can worry about programming.
That's really not fair. To start, beginning Java developers (or developers of any language) shouldn't be using a full IDE. Anything more than syntax highlighting (yes, even compiling for you), and you're losing important steps.
That said, the amount of boiler plate code to do anything in Java can make it quite confusing... though, Scanner has made the input easier, and System.out.println() doesn't seem too much more than memorization.
I don't see the point of your argument. You say Java developers should intentionally cripple themselves, because they're losing "important steps". What does that even mean? I don't see why I'd lose rename, automatic inherited method shells, auto imports, generate constructors/getters/setters etc... When you buy a car, do you insist that it has manual windows and no power steering?
With Java, you have to worry about your environment before you can worry about programming.
You have to download the jdk and set an environment variable. Then open a text editor. That's about all the 'worrying about the environment' that you have to do before you can start programming in Java.
No, you also have to think about various command-line tools invocation (java and javac for starters) and all the boilerplate that goes around what you want to write (create a file, name it correctly, put the same name inside with a `class` statement whatever that means, then put braces everywhere and a `main` and a `String[]` which you don't know jack about) and then you have the joy of wondering why you don't see anything when you run your program (assuming you got it to compile and run) and learn about `System.out.*`.
With scheme, you download Racket or whatever (equivalent to downloading the JDK), you open it, and you start typing and getting instant feedback in your window.
I'm not sure I understand you. You can't just start typing and getting instant feedback in Java simply because Java is not interpreted (well, actually, it is, but you have to compile to bytecode first). So, what you're saying about Java goes for just about any compiled language.
No, you also have to think about various command-line tools invocation (java and javac for starters)
Use "javac" to compile to byte code. Use "java" to run your compiled program. This is all you need to know about these tools to start programming. There are various options for using java and javac, of course, but it's not like you can't compile and run a simple program without these options.
As for this part of your comment:
create a file, name it correctly, put the same name inside with a `class` statement whatever that means, then put braces everywhere and a `main` and a `String[]` which you don't know jack about
Yeah. You have to know a bit of Java before you actually start programming in it. If that's one of Java's shortcomings, well then, there are a lot of languages with the same shortcoming.
>I'm not sure I understand you. You can't just start typing and getting instant feedback in Java simply because Java is not interpreted (well, actually, it is, but you have to compile to bytecode first). So, what you're saying about Java goes for just about any compiled language.<
This is not true. There are statitically typed languages, usally functional, with a read-eval-print-loop. Haskell, Ocaml, SML, F#, Scala are the main ones I can tink of. There are many more. I will also note that your parenthetical is slightly inaccurate in that jvms usually JIT bytecode and don't just inteprete it straight.
Lunaryom is correct. There are no 'interpreted' and 'compiled' languages, just different implementations.
So, I was wrong in my original post. It would appear that you can just type and get instant feedback in Java (if you use Beanshell, for example).
I noticed the possibility of that semantic ambiguity, that is why I switched to noting static/dynamic typing instead of retaining your distinction on compiled/intepretated.
The barrier to entry is certainly higher for Java, C++ and C than it is for, say, Scheme or even Python. Of all, I think Java has the highest barrier to entry. I have taught both Java and C++ to beginners (using the C subset with C++ I/O).
Several weeks into the semester for Java, a student asked me what "public static void main" meant. I started giving him the correct answer when I stopped myself: his background did not prepare him to even understand my answer. I then told him, "I'll give you the real answer in a moment, but don't worry if you don't understand it. For now, it's the magic you have to tell the compiler to get your program to work."
I call it "magic" because it is something the student have to write without understanding what it means; for them, it is indistinguishable from a magic incantation. The less magic a student has to recite to get a working program, the lower the barrier to entry.
> You can't just start typing and getting instant feedback in Java simply because Java is not interpreted (well, actually, it is, but you have to compile to bytecode first).
This is a great excuse, but uninteresting in discussing the relative fitnesses of Java and Scheme for teaching. Unless you want to take Java down one more peg.
> So, what you're saying about Java goes for just about any compiled language.
That's not even correct, many compilable languages also have REPLs, any compiled language can be interpreted (you just have to compile it on the fly). Haskell and OCaml can be used in a REPL, so can Erlang (though the Erlang console is quite far from a full repl).
> Use "javac" to compile to byte code. Use "java" to run your compiled program. This is all you need to know about these tools to start programming.
That's actually quite a lot, compared to "launch this, and then start playing". And you have to invoke `javac` for every single source file and with the correct options (the main issue for beginners generally being the classpath configuration).
> There are various options for using java and javac, of course, but it's not like you can't compile and run a simple program without these options.
You can run a trivial program without most of these options, but to reach simple you'll very likely need -cp early on.
> Yeah. You have to know a bit of Java before you actually start programming in it. If that's one of Java's shortcomings, well then, there are a lot of languages with the same shortcoming.
Yep. And that makes them worse teaching languages. I am happy you agree.
Exactly. If it's starting from scratch, I have to download the scheme source, build it, resolve all compile problems within my environment before I can use it.
The usual distribution package of scheme is the source package. The usual distribution of JDK is the installable bundle. If the argument for scheme is that it's already installed and set up by the admin, then the same thing can be said about JDK. In term of ease of setup or installation to the end users, it's about the same.
Once the JDK and environment have been set up by the sys admin, the tools are just available to the end users.
Same point PG made in one of his essays about text editors vs IDE's. With the former you learn and master the language, with the latter you learn the editor and features like code completion substitute for mastering the language.
This is utter bull, even if PG said it. I've learned a huge amount about Java by using an editor (Intellij) that has real time static analysis of my code and points out when I'm making common mistakes with corners of the language (calling overrideable methods during object construction, for example). It's incredibly useful and informative.
Perhaps out of date now, given what IDE's can do, though I personally still prefer to learn a language and toolchain with a text editor, then graduate to Eclipse for the benefits you mention.
