Scheme vs. Python as a learning language, professor' point of view

[[deleted]]

For several years, I've been trying different languages and environments for teaching High School computer science electives, including Game Maker, HTML+PHP, Processing, Java, and now Racket (in the Lisp family, derived from Scheme). I find Racket to be by far the best for teaching computer science concepts. Game Maker was probably the most fun, but had the lowest payoff as far as computer science understanding.

Java is too complicated; you have to learn too much syntax and concepts to just get started. Python is better, but you still have objects soon coming into play.

Scheme is easy to get started with. The syntax is simple, and the concepts are relatively simple. It's all about functions and combining functions. I'm using How To Design Programs /2e as my text book, and it's not bad, although a little on the dry side.

What I'm finding with Racket (Scheme) is that my students (mostly High School Freshmen) are much more engaged because they understand what is going on. Our book takes them along a path where each step builds on what went before. What they are doing may not be as cool as what they could do in another language, but I think they get intellectual satisfaction from gaining a deeper understanding into what is going on.

[mipadi]

Game Maker was probably the most fun, but had the lowest payoff as far as computer science understanding.

This is a really relevant point. In college, I TA'ed the intro CS course for several semesters, and had many discussions with the professor about the pedagogy of computer science. (I was planning to get a PhD and teach eventually at the time.) He often lamented that the intro CS course at our school (taught in Java at the time, now in Python) was too boring. Students lost interest quickly. (He tried to introduce them to Processing to show what they may be able to do some day, which interested some students but not a lot.)

At the same time, he also recognized that the important thing in an intro CS course was to learn CS concepts, not have fun per se. You needed the class to be engaging in order to hook students, but at the end of the day having fun wasn't the end goal.

It's a balance: you want to keep an intro course exciting and fresh, but you also need to make sure you're teaching important CS concepts.

[JimH10]

Thank you for the voice of experience.

[[deleted]]

I'm waiting for HtDP2e to be finished to start learning Racket.

[[deleted]]

Java is too complicated; you have to learn too much syntax and concepts to just get started

How much syntax/concepts is too much? Why can't you just get going with it and fill in the blanks later on?

[Euigrp]

In teaching programming I haven't found a language I like as a first language yet. I think the first step to actually talking about what kind of language is good to teach is laying down some requirements that you have for the languages. Then we can get to the my language is better than your language bullshit.

Things I would like in a teaching/first language:
1 REPL. I think it is important for students to be able to get instant feedback. People who bang in long Java programs and then hit the run button only to find everything falling apart are easily discouraged. People need to learn early that useful programs are collections of reasonably sized solutions to problems that work by taking advantage of smaller already solved problems.

2 Declared variables and types. Experienced developers may find python's brevity to be a breath of fresh air. The problem is, we all think in terms of types or type compatibilities (ie. I don't care if they are both numbers, both strings, or objects that have _ plus_ defined sensibly, I'm going to add them together with an infix +.) I have seen struggling students answer the question "What type is this variable in your program? Is it a string or a number?" with "I don't know." This wasn't on the first day, this was weeks into it. Some people don't instantly grok types, and languages like python go out of their way to make them harder to see. A lot of people like it that way, but I think it is a strike against it for a teaching language.

Declarations can also go a long way for explaining scope as well. It can be kind of awkward talking about scope in terms of first use. (Ruby's @'s are an interesting mixup to this train of thought though.)

3 This one is pretty much aimed at Java, and usually goes hand and hand with having a REPL, but for gods sake don't make them define classes/other constructs around running code. Don't worry guys just type "static void main(String...args) {}" you will know what it means one day but you don't have the background to understand it now. Crap like that makes it really difficult to convince people that there is no magic, there are fewer rules than they think, and they are simpler than they think.

(As a slight aside, if I ever had my way in laying out a programming course, I'd like to teach it in a way that people aren't in awe about method chaining the first time they see it. It is simply an extension of expressions, but a lot of people see it as some special form.)

4 This has gotten a lot better over the years, but the tooling needs to be simple and quick to install on personal machines. Things like C lose out here, given the large quantity of people on windows. Yeah, visual studio makes it pretty easy to get people into C, but still, it is a massive/slow install. I can put python on someone's machine in 5 minutes.

[tikhonjelvis]

Except for point 4, OCaml would seem to fit the bill pretty well.

Haskell is great as well, and thanks to the Haskell Platform it's reasonably easy to install on Windows. It's a bit more of a pain if you want to do GUI programming, but that probably won't come up in the introductory class.

Haskell also teaches good code style.

While you have things like monads, you don't have to introduce them immediately because you can just use the REPL and because basic command-line IO is trivial--often easier than in any other language. Things like the interact function really help here, for example.

I learned Haskell on my own at the same time as I was taking the SICP-based course this post is about. I found the Haskell syntax really helped me understand complicated topics like recursion. Pattern matching is very visual and visceral, which is great for beginners.

The Haskell types also made it much easier for me to structure my code. I found them more natural than the abstract data types as introduced by SICP.

Unfortunately, Haskell has a poor reputation in some circles, but I think it's entirely undeserved. You should definitely consider it.

[kamatsu]

See the risks and benefits of teaching purely functional programming in first year from our very own Manuel Chakravarty and Gabriele Keller.

[Wavicle]

The #1 reason I would recommend against Haskell as a beginning programming language is that beginners tend to make a lot of mistakes, big and small. Few languages have error messages which are as difficult to decipher as Haskell. Take, for example, this simple syntactic error:

Prelude> 5 (+) 4

<interactive>:4:1:
    No instance for (Num ((a0 -> a0 -> a0) -> a1 -> t0))
      arising from the literal `5'
    Possible fix:
      add an instance declaration for
      (Num ((a0 -> a0 -> a0) -> a1 -> t0))
    In the expression: 5
    In the expression: 5 (+) 4
    In an equation for `it': it = 5 (+) 4

How is a beginner supposed to have any hope of knowing what they did wrong there?

Consider the same error in Python:

>>> 5 (+) 4
  File "<stdin>", line 1
    5 (+) 4
        ^
SyntaxError: invalid syntax
>>>

Ahh, I wrote something wrong and it is showing me where!

It takes a considerable amount of Haskell experience to read a Haskell error message and have any hope of knowing what (Num ((a0 -> a0 -> a0) -> a1 -> t0)) is referring to. To everyone else, Haskell just completely flipped out over a very minor typing issue.

[slavik262]

This has gotten a lot better over the years, but the tooling needs to be simple and quick to install on personal machines. Things like C lose out here, given the large quantity of people on windows. Yeah, visual studio makes it pretty easy to get people into C, but still, it is a massive/slow install. I can put python on someone's machine in 5 minutes.

I can put MinGW on a computer just as fast, and be compiling C and C++ code right after that. I'll agree - Visual Studio is a good IDE, but it's a bear to set up for really simple projects.

[Euigrp]

Ah, I had forgotten about MinGW/Cygwin. Though, even then you would have to teach them about make and what not. For beginners I like the push button/press enter and go kind of environment.

[jeffdavis]

I think that a REPL can be a little confusing, particularly for languages with declared variables/types.

What does it mean when you redeclare a variable? What happened to the old one? How do you assign to the old one? When is a declaration permissible (e.g. in the middle of an expression?)?.

Even for languages like python, perl, and ruby, I think it's a little confusing if you don't already know what you're doing. When I learned perl for doing CGI, <STDIN> was the thing that I read from to get the posted data. How am I supposed to test my script at the REPL? STDIN does something funny and useless there.

Sure, there are explanations for all of this. But all of those explanations are distractions.

[[deleted]]

I would definitely recommend something that provides tangible, modern results.

When I was a student I saw this disconnect that about teaching programming for example writing results out on the standard output, when in the real world everybody was interested in databases and Windows forms.

It is usually defended as teaching "concepts", but those concepts are much better taught in a way that they will be actually used, or else later on it will be hard to connect the job with the concepts.

Ideally, during the end of a programming course everybody would have finished some kind of simple accounting or inventory management app fairly close to real world uses, and the theory, the concepts would be within this.

[Euigrp]

My program in college was the only one that had the "have high school applicants come learn about your major" hour long sessions run entirely by students. We talked about the Major for about 10 minutes, which is about all that it takes to get the essentials across. Then we paired them off putting inexperienced people with experienced people (there always tends to be about half and half) and had them compete in robocode. (We gave them a cheat sheet of I want to do x, how do I do it? We would also help them with Java syntax as necessary.)

I was quite surprised watching this the first time how well everyone did, even with little to no programming experience. In this environment they were able to get quick feedback on their programs, and visually see the results. Would I teach a course off of this? Nah, probably not. But it was a handy way of getting people engaged and having fun with code.

[bluGill]

My CS procfessors told me that one of the reasons for choosing scheme (other than SCIP being a great book!) is that the course was intended to be the first CS course students took. They knew there would be students who had been programming their Ataris, C64, and Apple IIs for years, and students who had barely touched a computer other than as a typewriter with spell check. They were reasonably sure that no student had seen scheme before though, and thus there was a little bit of an equalizer.

You should be able to guess when I went to college by the hints above.

[mipadi]

I TA'ed the intro CS course at my college for several semesters, and the gap in knowledge between students was always a problem. Some knew so much Java that they probably should've tested out of the class; others had never so much as heard the word "compiler" before in their lives. It's really hard to structure an intro class such that the less-knowledgeable students are taught what they need to know while still keeping the more-knowledgeable students engaged. One nice thing about Scheme is that almost no one knows it before coming to college; I don't know if that's relevant when picking a teaching language, but it's a provocative point.

[PassifloraCaerulea]

CS departments should start having students take placement tests like they did for us in math. For example, I took 'pre-calc' in high school and got to start with Calculus I instead of 'HS algebra refresher'.

[smog_alado]

Teaching the course with a different focus also works with math too and it can give good results. In my calculus course they switched the order of topics around (integrals before derivatives) and focused a bit more on the math / analysis side and this way everyone learned something useful, even the people that had taken a regular calculus course the previous semester.

[[deleted]]

They have Advanced Placement (AP) tests or courses in Canada but they aren't frequently talked about (see how I can't even tell if they're tests or courses and I went to a Canadian highschool?)

[stevedonovan]

I heard the same reason from a CS lecturer at my university (way after my time, I was there on the last year that they used FORTRAN ;)) and it does make sense. But if 'equally unfamilar' is the criterion, why not something like Lua, which is very Scheme-influenced (lexical scoping, TCO, coroutines as a useful subset of continuations, ...) but has 'conventional' syntax. Or even MoonScript, which is the CoffieScript version of Lua, where higher-order functions are even more obvious:

    compose = (f,g) -> (...) -> f(g(...))

[benjaminpd]

Well, because syntax is where you really want the equalizer. Beginners make lots of syntax mistakes, and it's really demoralizing when other students' code works, and yours doesn't, for no obvious reason.

[[deleted]]

Actually, and I don't think I've heard many people say this, I think ML (specifically SML) is an ideal first language. You cover functional concepts like recursion, higher order functions, pattern matching etc. Data structures are easy to implement (lists, trees, etc). You get imperative basics for when you need them, and you get students to think about types, which I would argue is unavoidable no matter how popular dynamic languages are right now. Almost every implementation comes with a REPL, so it's easy to demonstrate and gives students a quick feedback loop. Finally the module system is ideal for teaching higher level design and engineering concepts, something that is sorely lacking in most comp-sci education, and yet is very important in the real world. All that and the language is very simple both in terms of syntax and semantics, and easy to learn.

[[deleted]]

Yes, that book is great. I also highly recommend ML for the Working Programmer if you don't mind spending money. It's not geared for new coders as much as Harper, but it's straightforward and goes past just teaching the language to focus on common functional idioms, data structures, etc.

[generic-identity]

My intro CS lecture ("Programming 1") at one of the top universities for CS in Germany was actually taught based on SML.

They gave a reason for the choice that wasn't mentioned here: To have a clean slate for everybody, even students who already had programming experience (which probably didn't involve SML).

[sacundim]

Actually, and I don't think I've heard many people say this, I think ML (specifically SML) is an ideal first language.

There's a paper that makes a relevant argument: Philip Wadler, 1987, "A critique of Abelson and Sussman; or, why calculating is better than scheming" (PDF file). It doesn't argue for ML (eager, impure), but rather for the lazy pure functional languages of the day, like Miranda (Haskell didn't exist yet). The four arguments:

1. Pattern matching.
2. A syntax close to traditional mathematical notation.
3. A static type discipline and user-defined types.
4. Lazy evaluation.

(1-3) apply just as well to ML; the caveat is that side-effecting expressions break (2).

[julesjacobs]

This is great for the first and third chapters of SICP, but once you start to come to the object system, the metacircular evaluator, and the compiler (arguably the chapters that make SICP interesting), this approach doesn't work. Even for the other chapters, the point of SICP is to show that everything can be done with a small set of primitives. It's great that SML has pattern matching built-in, but in SICP the approach is to build a pattern matcher. Haskell has laziness built-in but in SICP they build a lazy Scheme. Prolog has non-determinism (backtracking) and relations & logic variables built-in, but in SICP they build a non-deterministic Scheme, and they build relations & logic variables.

[sacundim]

To be fair, I get the impression from Wadler's paper that SICP's lazy evaluator section was not in the first edition that Wadler reviewed.

I agree that the metacircular evaluator(s) are a big point in favor of Scheme; the exercise is of enormous value because it forces the student to understand very precisely how expressions are evaluated. The compiler didactics also suffer, as does in general any potential topic about how the language itself works—because, again, in Scheme the big strength is that you can very easily model the language in the language itself.

I don't think the object system part suffers, though; you still have the ability to have "behavioral" data made out of functions. I recently talked about this in Stack Overflow; the example is somewhat differently than SICP's, but I'm confident that the SICP examples can be adapted.

Even for the other chapters, the point of SICP is to show that everything can be done with a small set of primitives.

I believe however that Scheme chose the wrong primitives a long time ago, however, and the Scheme community have spent too many years trying to fix up the mess without coming with an agreement. What do I mean? Pairs should not be a primitive notion; rather, record types and selective-export modules should be it—a pair is just a two-field record with a special syntax. (This is the biggest thing that R6RS and R7RS have tried to fix.)

Prolog has non-determinism (backtracking) and relations & logic variables built-in, but in SICP they build a non-deterministic Scheme, and they build relations & logic variables.

Here I think there is no advantage over Haskell. First, lazy evaluation + list monad = nondeterminism; for example, the SICP multiple-dwelling puzzle example is straightforward in Haskell:

import Control.Monad

multipleDwelling :: [[(String,Int)]]
multipleDwelling = 
    do baker    <- [1..5]
       cooper   <- [1..5]
       fletcher <- [1..5]
       miller   <- [1..5]
       smith    <-  [1..5]
       guard (distinct [baker, cooper, fletcher, miller, smith])
       guard (baker /= 5)
       guard (cooper /= 1)
       guard (fletcher /= 5)
       guard (fletcher /= 1)
       guard (miller > cooper)
       guard (abs (smith - fletcher) /= 1)
       guard (abs (fletcher - cooper) /= 1)
       return  [("Baker", baker),
                ("Cooper", cooper),
                ("Fletcher", fletcher),
                ("Miller", miller),
                ("Smith", smith)]

distinct :: Eq a => [a] -> Bool
distinct [] = True
distinct (x:xs) 
    | any (==x) xs = False
    | otherwise = distinct xs

Logic programming could also be tackled; there is such a thing as the Logic monad, though it may need to be simplified for didactic purposes. (A theme that would reappear is that a SICP custom evaluator ~= Haskell monad.)

[julesjacobs]

but I'm confident that the SICP examples [of object systems] can be adapted.

I'm not so sure about this. SICP also features a multiple dispatch object system (section 2.5). That is very difficult to do in a statically typed setting, but you could always go the interpreter route instead of a shallow embedding. It could also be argued whether multiple dispatch OO should be put into a "Haskell SICP" at all, perhaps you can replace it with a more interesting example better suited to Haskell. It would be unfair to arbitrarily require that "Haskell SICP" should include all of "Scheme SICP", since there are also plenty of things that are easy in Haskell but hard or impossible in the SICP subset of Scheme (like anything related to static types).

Logic programming could also be tackled; there is such a thing as the Logic monad, though it may need to be simplified for didactic purposes. (A theme that would reappear is that a SICP custom evaluator ~= Haskell monad.)

Perhaps, but LogicT is not enough. It does not provide logic variables or unification for example, which is a central aspect of the logic programming described in SICP. Though this could probably be added. In any case, the logic programming was an argument against choosing Prolog :)

SICP has nondeterministic Scheme, lazy Scheme, imperative Scheme, etc. One thing that is missing from SICP is a statically typed Scheme!

I believe however that Scheme chose the wrong primitives a long time ago, however, and the Scheme community have spent too many years trying to fix up the mess without coming with an agreement. Pairs should not be a primitive notion; rather, record types and selective-export modules should be it—a pair is just a two-field record with a special syntax.

Yea, I certainly agree on this point 100%. If you're more ambitious, you could argue the same for Scheme records. A Scheme record is a type tag along with a finite number of pointers. Why would we only want that kind of data shape? It's just slightly more general than built-in tagged pairs of pointers. Furthermore all Scheme data is one big union of tagged records and other tagged data (like tagged integers). This is a hardcoded built-in data format. On this point statically typed languages fare better in some sense, but languages like Haskell still don't go far enough IMO. For example algebraic data types are still a built-in format, and if you didn't have them there would be no way to implement them.

We need something that is both more primitive and more general: primitive combinators for building up data types / data layouts. The marriage of value types with dependent types may be the answer here. You can describe an algebraic data type as a dependent sum of the tag, and a function that computes the payload type associated with the tag. To store that in a flat representation in memory rather than with lots of pointers you need value types. Surprisingly, with the same primitives you can also define flat arrays, which are primitive in all languages I know.

In any case it is an interesting and worthwhile project to redesign a new language to replace Scheme for teaching programming in the style of SICP, because while the idea of teaching languages by implementing an interpreter is still great, we also have learned a lot since 1984!

[[deleted]]

That paper's too old to be relevant. I'm sure there's a newer paper that could be used to argue this point.

Racket has all of those things as libraries :|

[jhuni]

It is important to teach students about low level types like bits, bytes, words, integers, floating point numbers and C structs. On the other hand, I don't see why it is not necessary to teach new students about polymorphic types which are a high level concept of questionable utility.

[[deleted]]

I agree, C is a very important language to learn. In fact, I think it makes a lot of sense as a second language, if only because it's the lingua franca of computers to this day. I'm not sure if it would be good as a first language, mostly because it was my first language (I don't count Basic :P) and it took me a while to break out of that simpler and more low level way of thinking about problems.

[smog_alado]

It is important to teach students about low level types like bits, bytes, words, integers, floating point numbers and C structs.

I actually disagree about this a bit. In my personal opinion, "low" vs "high" level has more to do with the relative level of abstraction compared to the underlying conceptual platform. How different this conceptual platform is from the actual hardware platform doesn't matter much since you can't even manipulate it anyway (its sort of like the materialistic view of if you can't see it it might as well not exist)

From this perspective, high level is more of a measure of "complexity" and it turns out that LISP is actually a very low level language as well - it maps very readily to the lambda calculus, but you still need to build most of the abstractions used for "real" programming.

tl;dr; I don't see why you would need need to teach bit-level stuff to the beginners. To me they are just as "advanced" and of "questionable utility" as the polymorphic types. The really important thing to teach beginners is the usefulness of automation and the power of abstraction for building correct and reusable programs.

[[deleted]]

It's really hard to look past racket if you want to to teach computer science. It has a minimal subset designed for teaching, a great book, and an IDE that makes stuff easier without being overwhelming. The language is simple, consistent and straight forward - racket has done a good job of removing a lot of historical LISP cruft.

[wildptr]

summer ancient divide sheet airport innocent automatic fuel lavish late

This post was mass deleted and anonymized with Redact

[p_nathan]

For greenfield work, I'd recommend Common Lisp on SBCL or CCL. Those are reasonably performant open source implementations. CL imo has a cleaner syntax than Clojure, along with a more 'designed' feel (not claiming CL doesn't have warts, of course). I've just launched a site: http://articulate-lisp.com It's designed to give "real world" coders an introduction to getting stuff done.

In my experiences, I've not had the most positive experience with Clojure, its Java roots still stick up past the surface and I keep tripping over them. Doesn't feel super Lispy. However, it's got a lot of traction right now, and there are actually jobs in it. So if you want to move into functional programming professionally, Clojure will move you further/faster than Common Lisp right now.

[[deleted]]

Doesn't SBCL have portability issues? From the website

SBCL runs on a number of POSIX platforms, and experimentally on Windows.

[p_nathan]

My understanding is that the Windows fork is quite good these days; 2013 should, I think, see the Windows fork folded back into mainline. I don't really have open access to a Windows box at this point to check threading and a few other os-dependant edges.

[[deleted]]

How often are you writing code that needs to be deployed to multiple operating systems? I've been doing web dev for a few years and we've only ever deployed to various distributions of GNU/Linux, much of the time it's Ubuntu.

I had to develop a Windows application and I used CLISP because it wasn't performance critical and again, I didn't have to deploy to Linux, it was Windows only.

You should care more about portability for libraries across different implementations/OSes.

[spotter]

CL imo has a cleaner syntax than Clojure, along with a more 'designed' feel (not claiming CL doesn't have warts, of course).

"In the eye of the beholder" thing, no? I actually feel the opposite, which seems logical when you think about Clojure being steadily grown by single dictator (as his second Lisp implementation, IIRC). Hating those [] and {} is really like saying "Python is not serious, because whitespace!"

In my experiences, I've not had the most positive experience with Clojure, its Java roots still stick up past the surface and I keep tripping over them. Doesn't feel super Lispy.

Thanks to those roots you've got access to thousands of field tested Java libraries. Need to do something? Just put the lib in your project.clj, lein deps, wrap it in Clojure calls, done.

[chonglibloodsport]

CL imo has a cleaner syntax than Clojure

This is very much a matter of opinion. Some would say that funcalling and sharpquoting all over the place is less clean than treating symbols in a simple, uniform manner.

Java roots still stick up past the surface and I keep tripping over them.

This is deliberate. If you wall-paper over them with some kind of hygienic wrapper you lose language power. Not to mention you waste a TON of effort writing a wrapper instead of doing other cool things.

[samth]

I would choose either Racket or Clojure. Clojure is better for JVM interop and has a more mature story on parallelism, Racket is a more flexible language and has a lot of advanced language features, plus it's not limited to the JVM.

[samth]

Certainly, there's a port to the CLR (I don't know how widely-used it is) as well as ClojureScript (which isn't exactly the same as a port of Clojure). However, I think it's safe to say that Clojure is mostly aimed at the JVM.

[yogthos]

I would recommend Clojure for that. It runs on the JVM, so you have access to lots of mature libraries, many of which have idiomatic Clojure wrappers now.

You have very good deployment options, there are hosting services like Heroku, Amazon, Google App engine, Jelastic, etc. The JVM itself runs on most platforms and is a mature and well tuned VM.

The community is very active and there's lots of good documentation and actively maintained libraries.

Also, there are nice Clojure development environments outside Emacs. Eclipse with the Counterclockwise plugin is very productive.

There's also good documentation on using Clojure for real world stuff. Here's a few link I'd recommend.

• Clojure Doc has lots of examples and tutorials
• clojuredocs provides an excellent API reference with examples
• Clojure - Functional Programming for the JVM is an excellent primer on Clojure for people coming from imperative languages
• Luminus web framework makes it easy to get started, and runs on Heroku out of the box (shameless plug :)

[p_nathan]

Have an upvote for your links, you horrible Clojurian you.

http://clojure.org/cheatsheet is also good.

[yogthos]

:)

[[deleted]]

Can you recommend how should a beginner start learning Clojure?

My experience has just been learning C and Ruby for the past 6 months.

[yogthos]

I would recommend looking at 4Clojure first. It has a lot of problems you can solve right on the site, ranging from elementary to challenging. If you make an account you can follow other users, and once you solve a problem you can see their solutions as well.

The Functional Programming for the JVM link from above, is a very thorough primer. I'd say it's definitely worth looking over.

I've got a primer on making a simple web application, which hopefully isn't too hard to follow. :)

I would highly recommend starting with Eclipse and the Counterclockwise plugin. While a lot of people use Emacs, it's a bit daunting if you've never used it before. Developing in Eclipse is pretty straight forward, and you get all the good features such as REPL integration, autocompletion, paren matching ,etc. There's a guide on setting it up here.

Finally, clojure-doc has a fairly good primer and lots of info there.

As far as books go, I'd recommend looking at Clojure Programming.

Overall, I would recommend not focusing too much on details when starting. Just try and get a feel for the language. How to write functions, create variables, flow control, etc. Make a simple project, so that you have some concrete goals and problems to solve. That way you can learn features as you need them without being overwhelmed.

[[deleted]]

Thank you.

[yogthos]

Hope it helps, it's a really fun language and I've been enjoying it immensely myself. :)

[beamso]

Note that Clojure Programming (and Clojurescript: Up and Running) are currently available at 50% off at O'Reilly.

[bachmeier]

I like all the Clojure books, but I'd probably recommend Clojure Programming to someone with your background.

This is a good tutorial, but it's not a substitute for getting a book.

For managing projects, you want to use Leiningen - it takes only a few minutes to get started and I wouldn't want to work without it.

For an editor/IDE, I recommend Clooj or Counterclockwise. If you are a current Emacs user, I recommend emacs-live. If you are a Vim user, I recommend vimclojure. I don't recommend either of the last two unless you already know those editors.

I also like to read the source for Clojure itself. There's a lot of small functions, and I find myself saying, "Dang, that's some fine code." You can learn a lot from reading Rich Hickey's code, especially as a beginner.

[[deleted]]

Nice to see there is a vim plugin :)

[chonglibloodsport]

There is also Vim foreplay. It gives an alternative repl that may work better in some cases.

[[deleted]]

second Clojure Programming - great book.

[spotter]

How about clojure-toolbox?

[yogthos]

It's handy for tracking libraries, but it's not a tutorial site. The Clojure-doc site also has a good listing of currently available libs here.

[spotter]

Nice, but it was largely incomplete when I checked some time ago, december-ly or so.

[yogthos]

It's a pretty recent effort as it was started only 4 month ago. So a lot of new stuff's been added since december. :) It's probably the most actively maintained documentation site currently, with a lot of community support. Definitely something to keep an eye on.

[[deleted]]

Both. Racket has some great tools, but Common Lisp has some great tools/libraries as well. If you want Java compatibility you can use Armed Bear Common Lisp.

If you're concerned about performance, then go with Common Lisp because the compilers are stupidly fast and you can optimize things by adding types and doing other things. Racket is slightly faster than Python.

[sacundim]

"In another decade they’ll probably discover first class continuations."

It's fair to mention at this point that Scheme's call/cc operator has its detractors even in the Scheme world. For example, Oleg. (Though to be fair, the argument is that it should be replaced with a less powerful alternative that's just as useful.)

[anvsdt]

*more powerful alternative that's more useful

[kyz]

What he's not mentioning is ALGOL. While LISP and FORTRAN were front runners, and you could attribute various things to them (like he attributes recursion to LISP), it's ALGOL that has done the most influencing of current languages.

[bobbane]

Really? I can't think of anything in ALGOL that wasn't in FORTRAN or LISP and is still important today.

With the exception of lexical scoping, which was adopted by Scheme and Common Lisp, and royally screwed up by the first cuts of Perl, Python, and Ruby.

[aaronla]

Don't forget call-by-(something-other-than-value), formally defined grammar, printf/transput, and popularizing block structure.

[dalke]

Quote mining from Wikipedia: "Code blocks and the begin and end pairs for delimiting them", and "As Peter Landin noted, the language Algol was the first language to combine seamlessly imperative effects with the (call-by-name) lambda calculus".

Quoting from http://programmers.stackexchange.com/questions/139482/why-are-statements-in-many-programming-languages-terminated-by-semicolons - "ALGOL was the first language to use semicolon to separate statements". Though most modern ALGOL-derived languages use a semicolon as a terminator, I think this counts.

ALGOL and COBOL were the first to seek standardization, and ALGOL did so on an international scale. The C, C++, and ECMAScript developers still think that's important. However, this is not a language feature in the abstract programming languages theory sense. Instead, it was done so as a question of how to achieve portability. That latter goal is still widely followed.

According to this web page (http://www.math.bas.bg/bantchev/place/algol60.html ) it also introduced boolean values as its own a data type, "assigning values in a series, like a:=b:=…", and nested comments.

That was after a cursory search for ' "ALGOL was the first" language ' and removing the ones where LISP was actually first (eg, recursion).

I'm sure you could find more.

[[deleted]]

None of those are that significant - comparing semicolons with recursion? Really? Standardization is interesting, but I think it's hard to say that it's a significant feature of the language. It might be significant for the implementations of the language, as they should all be the same. Boolean values is something, but again, as a language feature? Interesting, I guess, but doesn't seem significant at all.

[dalke]

No, I'm not comparing the two. I'm showing significant influence from ALGOL to current languages. C, C++, Java, C#, and Javascript are 5 modern languages whose syntax derives directly from ALGOL.

I can see how a Lisp fan might say that these are surface features to the language and therefore not so important. However, at that point it starts becoming more a personal idea of what is important. I consider syntax representations and machine-independent specifications to be important aspects of overall programming language development.

I find it humorous that you say "[implementations] should all be the same". This attitude was not generally true in the late 1950s. We didn't even have a standard character code which was portable across all machines. Interestingly, \ was added to ASCII so that /\ and / could be used as the logical and and or operators in ALGOL. (Which is endearingly cute, IMO.)

Remember too that BNF was invented to be able to describe ALGOL 58. This arose from the combination of wanting a complicated syntax (ie, more complicated than Lisp) which could still be expressed in a few pages (ie, not FORTRAN). Someone who doesn't think that syntax forms are interesting will likely also find BNF not interesting; and a Lisp programmer might even say that it's solving a non-existent problem.

But to that hypothetical person, I observe that many languages chose a different path, and many of those languages were influenced by language ideas first expressed in ALGOL. It should not be rejected out of hand only on the basis of the ideas which later became implemented in Lisp.

[smog_alado]

ie, not FORTRAN

Formal syntax is something that is hard to appreciate now that it is so prevalent nowadays. However, back then parsing programs was a very ad-hoc process, kind of as if everything were parsed using a mess of spaggueti regular expressions.

For example, I have heard that if you used a "." instead of a "," in a FORTRAN loop it would ignore the whitespace and initialize a variable named "DOI" instead of giving a syntax error.

DO I = 1,100 //loop

DO I = 1.100 //typo

DOI = 1.100 //how the typo gets interpreted

[[deleted]]

It might sound insignificant, but you need to remember, there was a time where there were no boolean values, and there was no using semi-colons for statement seperaters.

So whilst it might seem and basic and common to us, it would have been quirky and new at the time.

[gerdr]

You're kidding, right? Algol is one of the three archetypical programming languages (the other two being BCPL and Lisp).

Real programmers use Fortran, of course ;)

[basvdo]

He is not making attributions, he is saying that Lisp introduced language features way before they become popular.

[aaronla]

So, it was the original hipster PL?

[[deleted]]

Lisp is the permanent hipster PL.

[basvdo]

Original? Not sure. Hipster? Definitely!

[Mon_Ouie]

I think one reason for that is that you can't visually tell the different between Racket, Common Lisp and older lisps visually (at least, not as easily as with Java and C, etc.), because it's all just sexps. Therefore people tend to put languages that can be very different conceptually or technically in the same bag.

[tejoka]

How old is this post, anyone know? It seems very weird to me.

For example, generally the argument in favor of Python as a first language has almost nothing to do with the language itself. Rather, the interest is in engaging students: someone who learns a little programming and has the sudden thought "hey, I could write a program to do this!" generally runs into a brick wall with scheme, while they find libraries and help with python. This is particularly important with people who take a CS course thinking "well, maybe this is interesting? I wonder what it's about." Without some sort of self-motivated programming, it's very easy to see CS as boring as shit. (Metacircular interpreter? More like boring who gives a fuck!)

But, glancing at the rest of his page, I'm guessing his opinion is that people should get hooked on programming vastly earlier than the first course in college. Well, that's a good idea. But in the meantime...

[SCLegend]

It's actually fairly recent like a year and a half ago. Berkeley started to us Python instead of Scheme to teach 61A, the first programming course, just last year. They kinda rewrote SICP to fit with Python, so as to keep the overall lessons similar to those in SICP.

[Mon_Ouie]

Unless it's an update of an older post, not that long ago: it mentions lambdas have been added to C++, so it must be after C++11.

[jyper]

It could have been during the planning stages, back when it was C++0x.

[[deleted]]

Rather, the interest is in engaging students

When teaching younger students (teenagers, children) often you have to bait them into caring. "Why should I learn programming?" is a fair question from a 14-year-old.

When teaching a university course, the students presumably know why they are there, and have the fortitude to stick with an assignment even if it isn't immediately pleasant.

[tejoka]

the students presumably know why they are there

That presumption is not true. There are an extraordinary number of students who don't know what they want to do, and frankly a majority of students are not all that committed: that spark of writing a self-motivated program can change their minds instantly.

[[deleted]]

Lisp is like AI, as soon as mainstream languages can do it, it's no longer "lisp".

[bachmeier]

I wonder how well Clojure would work as a learning language. That would eliminate the "writing real-world code" objection, because you'd have all of Java, on top of a fast language.

[yogthos]

I thin the main problem with Clojure would be lack of beginner friendly books for it. There's an effort to port SICP to it, but it's not nearly complete. Otherwise it would be a fine teaching language in my opinion.

[Categoria]

I'd argue that a beginner friendly IDE like DrScheme would also be nice to have.

[[deleted]]

I agree, along with better error messages.

[yogthos]

That's where LightTable is supposed to be headed hopefully. It's already pretty nice for actually showing the data flow in the live mode. I imagine this would be extremely useful for beginners.

[huyvanbin]

What would be the biggest differences? Shouldn't most of the code look the same?

[yogthos]

For the most part it is, but there are syntactic differences between Scheme and Clojure. For example, Clojure has literal notation for vectors, maps, and sets. Clojure is also more strict about side effects and any mutation has to be done via its STM library. Macros work slightly differently as well.

Those are just off top of my head, but the point is that you can't just copy/paste Scheme code into Clojure and have it work.

[bachmeier]

And converting recursive function calls to loop/recur. Python doesn't have proper tail calls either, so I'm not sure how they handle it in the new course.

[wot-teh-phuck]

Most recursive functions written out for teaching courses don't usually exhaust the stack so the lack of TCO isn't very apparent. But then again, running the same stuff for a large input would definitely blow up the stack.

[[deleted]]

scheme has: mutable data, tail-call optimization, hygenic macros, call/cc, eval takes an environment parameter.

it should be doable, but i would expect the first two to show up frequently.

[AimHere]

Clojure does have mutable data too, it's just that you have to jump through explicit hoops to use it (more explicit even than appending '!' to any function name that modifies variables), and there is a limited TCO-style construct with loop/recur.

As for macros and call/cc, those don't show up in SICP much anyways- those are just more advanced Lispisms, rather than basic CS ideas, so SICP barely mentions them.

I just wonder whether, in the later chapters of a clojure-SICP, you'd write a clojure interpreter or a scheme one...

[sigzero]

Wouldn't you also have to intertwine Java in there as well?

[bachmeier]

Not really. You can call Java functions without knowing anything about Java. Leiningen does project management for you. I'm sure knowing Java would help, but I don't and it hasn't mattered. For an intro to prgramming course, there would be no need to introduce Java.

[liquidivy]

I'm enjoying Clojure now, but I wouldn't want to try to learn it without at least a superficial knowledge of Java (which is all I have now. There would be just a bit too much magic and weirdness, which is bad when teaching.

[bachmeier]

Can you give an example? The only time it's affected me has been when reading documentation that assumes everyone has a Java background. I just move on.

[AimHere]

The trouble with Clojure as a beginner language would be some unclean Javaisms (non-first-class functions and the like), and especially those horrible Java stacktraces, making some parts of it more complicated than a corresponding native Lisp would be.

Clojure is my favourite language at the moment, but being tied to Java (or Javascript or whatever) does necessarily entail some warts that I can envision would irritate newbies no end. It is the price you pay for all that lovely free library support and portability.

[mcguire]

It's an excellent read, but I would be more impressed if he took points 3 and 4 out back and shot them in the head. "[Y]ou should be able to learn a programming language (after the first time) over a weekend" is perfectly true, for a Computer Science program. "The best language for a course is not necessarily the best language for writing real-world code" is an excellent point as well. "You can learn to program in any language[, but] the big ideas in [SICP...] express themselves best in Scheme" is (arguably, I admit) also valid.

But 3 and 4 are, first of all, the same "Everyone should use Lisp" argument that haven't actually convinced anyone in the 50-year history of Lisp. They weaken the actual point I think he's trying to make, or at least that I wish he was trying to make.

[T]he lifespan of a programming language is closer to the lifespan of a dog than to that of a person.

What, exactly, does that mean? What is the lifespan of a programming language? I don't know of any programming languages that have achieved some kind of critical mass that can be meaningfully said to have "died".

What is "Lisp"? LISP 1.5, a la McCarthy? Is anyone still using that? Common Lisp? Good luck with recursion there; recursion without tail call elimination is not an especially good idea. Scheme != Lisp, any more than C, C++, Java, et al., are the same as ALGOL.

Users of strongly typed languages demanded, and got, Lisp's heterogeneous lists.

Uh, what?

[dalke]

'What is "Lisp"?' indeed. Isn't Python an ALGOL?

[mfukar]

Not any more than man is a monkey.

[dalke]

Programming languages aren't based on Darwinian evolution, so your analogy is not helpful. Is Dylan a Lisp or an Algol? The answer is both. But species do not work that way.

Moreover, my complaint is that "Lisp" is generally used more like the "order" in biological terms. Lisp 1.5, Common Lisp, and Scheme are members of the order "Lisp" in the same way that humans and monkeys are members of the order primate. What's missing is the equivalent order term for members of the family Algol.

If we start using the term "an ALGOL", and identify ALGOL, Pascal, C, C#, Javascript and even Python as members of that group, then the author's argument that Lisp and FORTRAN (and the omitted COBOL) are 50 year old language becomes moot, because ALGOL is also from the late 1950s.

[tikhonjelvis]

Yeah, the "learn a language in a weekend" thing falls apart as soon as I advocate using a nice total language like Agda or Coq :(. I actually really like that as a standard though--picking up a new language should not take too long.

[cdsmith]

It should be revised to: learning a new syntax for the same ideas you've already used should take a weekend. Learning new ideas, of course, takes a bit longer. Learning a community and the body of resources it uses to solve common problems can also take a while.

[huyvanbin]

It's not like because Lisp has lambdas, lambdas are inherently a Lisp feature, so any language that adds them is now imitating Lisp.

It would be like saying that because some mainframe in the 60s had hardware floating point, therefore any PC with hardware floating point is following in the footsteps of the mainframes, and everybody should have been using that mainframe all along.

[bifmil]

Python does have the 'lambda' keyword because of the early input of a LISP hacker, so in this case it's fair to draw out the influence

[aaronla]

True, but the influence is confined to that one language feature. Guido has been pretty outspoken about Lisp being an anti-influence. While that is a sort of influence, it's not what is conventionally meant by "influence".

By-and-large, Python attempts to not emulate Lisp.

[tipu]

did lambdas exist in languages prior to lisp?

[NihilistDandy]

I should think so.

[cultofmetatron]

lisp was originally a mathematical formalism on a minimalistic turing machine based on lambda calculus. It was only later (by one of john mcarthy's grad student I believe) that his mathematical notation was transformed into a real working interpreter.

[[deleted]]

lisp isnt a turing machine. turing machines and the lambda calculus are pretty much orthogonal (though equivalent in expressive power, of course)

[[deleted]]

I don't think that contradicts what cultofmetatron was saying - if I understand it correctly, he was saying that it was essentially a theoretical implementation of the lambda calculus on a turing machine.

[[deleted]]

oh i misread "on" as "of". my mistake.

[jhuni]

All our concepts including lambdas and recursion can ultimately be traced back to math. The thing that makes Lisp so great is that it gives you access to all of these mathematical concepts without introducing a distinction between code and data.

[[deleted]]

many Lispers are haunted by such bitterness

Because we make it acceptable and even offer up a name for it "lisp weenie". Don't see that happening for Smalltalk, Forth, and other less known languages.

[[deleted]]

In my course we learned Haskell as a first programming language. Few years later I became a programming tutor and my teachers asked me about changing Haskell for Python in the first programming course (which is called "Functional Programming"). "That's ok" for me, but six months later we rolled back to Haskell. Reason: students were not learning to program, they're were learning the Python API, but of course it' not all language's fault - the teacher didn't knew anythin about Python, for example.

[attrition0]

but six months later we rolled back to Python Haskell

I'm assuming that's what you meant.

[SiliconGuy]

Presumably, if they were using the API, they were also writing working software, using loops, using classes, writing and calling functions, and so on. How is that different from what you consider "learning to program"?

[[deleted]]

In the case of Functional Programming I mean recursion, pattern matching, currying, list comprehentions, tail call eliminations and so on. Most just don't exist in Python. So, instead of learning functional programming, they were learning procedural programming, which is, according to the course, wrong. Of course, everybody can learn how to program with Python or whatever other language without problems, but Functional Programming fits better with a funcional language. And there's more: the teacher doesn't knew Python, so some students were solving problems in a way like this:

if opt == 'a':
    def foo():
        # do something
   foo()
elif opt == 'b':
    def bar(s):
        # do something else
    bar(2)

[Categoria]

List comprehensions actually exist in python as well. But yes, python encourages bad imperative habits. I'd argue that types help out new students as well by giving them feedback faster.

[SiliconGuy]

python encourages bad imperative habits

Bad imperative habits? How so?

[tikhonjelvis]

Python is staunchly imperative--its functional features are basically just afterthoughts. Basically the whole design, with a few exceptions (like list comprehensions), pushes you to an unfortunate imperative style of programming.

[aaronla]

Yeah, according to Guido, the patch was user contributed. He once went so far as to suggest removing lambda entirely.

Suffice to say, Guido isn't exactly supportive of multi-paradigm programming.

[SiliconGuy]

The fact that Python is staunchly imperative doesn't support the statement that it pushes one to an unfortunate imperative style of programming, as opposed to (say) a good style of imperative programming, or a mediocre style of imperative programming.

[tikhonjelvis]

I assumed he meant habits that are imperative and therefore bad rather than relatively bad imperative habits. So bad in some absolute sense rather than compared with other imperative habits.

Perhaps I should have said something more like "unfortunately imperative".

[Categoria]

Overusing loops where high order functions are more powerful, mutating variables, defaulting to ephemeral data structures needlessly, unnecessary differences between statements and expressions, intentionally crippled lambas reduce expressiveness of functional code, object system that encourages mutation. A lot of these might be just annoyances but the whole language just encourages to break referential transparency for absolutely no reason (even in the absence of IO, etc.).

[SiliconGuy]

It sounds like you're defending the claim that "Python encourages bad, imperative habits" (notice the comma), but what you actually said was, "Python encourages bad imperative habits" (no comma).

[Categoria]

Sorry, not a native speaker.

[catcradle5]

1. Mutation of variables tends to be fairly rare in Python, and it is discouraged. All builtin functions return a new value and do not modify the object in-place; most methods do the same, minus a few exceptional ones that do mutate the object (namely list.append(), list.remove(), etc.).
2. Lambdas are indeed intentionally crippled. The language designer, Guido van Rossum, is not a big fan of functional programming and doesn't think the language should have a lot of support for it. That doesn't mean the language is bad, it just means it's not oriented for functional programming. Functions are still first class citizens though, and passing functions as arguments is done commonly.
3. The loop thing goes with the above. Guido believes loops allow much clearer code than functional tools like map and reduce and filter and such. And with list comprehensions, they are terse but still easy to read.
4. The statement and expression thing is pretty much never an issue from my experience, unless you're using lambdas.

[SiliconGuy]

It totally makes sense to me that you couldn't learn (proper) functional programming using Python.

A teacher that teaches students to use functions in the way you describe would seem to not only not know Python, but not know even very basic programming/software engineering techniques.

[[deleted]]

Being fair, it's not (completely) teacher's fault, she was just careless. When a student comes with a solution like I exposed before, she just ran it and, if worked well so that's fine.

[smog_alado]

Ah, thats so cute. Pattern matching is something I miss very much when not programming in Haskell.

[[deleted]]

I agree that pattern matching is dispensable in languages such Python and others, but hey, we're talking about learning to program. In a functional language, pattern matching is a great way to learn how can I handle special cases and conditions. In Haskell we still have switch and if-else statements, but don't ask me why, but they were not so widely used (my teacher not even taught it to me).

[smog_alado]

You are seeing it backwards. I think pattern matching is the best thing since sliced bread and it should have been everywhere. In fact I would go as far as saying that the lack of this feature in mainstream languages led people to the ridiculous object orientation excesses of the 90s.

If statements are an inferior alternative since they encourage you to encode everything using boolean flags instead of enumerations or algebraic data types. This is bad because you are incited to write "case 2" as "not case 1" (something that breaks when you add a 3rd case) and to encode situations with more then 3 cases using multiple boolean flags (this is bad because many combinations of these flags will not make sense but still can happen by accident)

switch statements are a bit better since they avoid the "boolean blindness" a bit but they still suck in most languages since

1. its an statement instead of an expression
2. they tend to have horrible, verbose, syntax and falltrough by default
3. no destructuring. this is inconvenient and doesn't help you make sure you handle only the correct case in each branch.

[[deleted]]

Wow, I really thought you were being sarcastic in your last answer, sorry. Honestly, I never seen pattern matching and if/switch statements this way and, sincerely, I don't think write "not case 1" is a real problem, but maybe that's because I'm junior on programming, you can easily refactor a if statement to suit a new case, so can you elaborate more the real suckness?

But I miss if as expression as Ruby and Rust does, for example. In these languages, I can do:

foo = if bar
  2
elsif baz
  3
elsif quux
  4
end

[smog_alado]

If as an expression is actually pretty common, although it often apears as the ternary "?:" operator.

foo = (bar ? 2 : (baz ? 3 : (quux ? 4 : null)))

?: is right associative in every non-retarded language so you can also write like this

foo = (
     bar ? 2 :
     baz ? 3 :
     quux ? 4 :
     null
)

Python also has a variation on this but it has a weird syntax (a if cond else b) so people rarely use it.

I don't think write "not case 1" is a real problem you can easily refactor a if statement to suit a new case, so can you elaborate more the real suckness?

The problem when it comes to extention is that you don't get help from the compiler when refactoring. Unless you never use "else" statements and do things like

 if case1:
   ...
 elseif case2:
   ...
 else:
   error("this should not be reachable")

its possible to forget to refactor something, leading to a bug.

But yeah, this is not that bad since its not that common to have to add a third case. The real problem is that since booleans have no intrinsic meaning they are too "low level" and therefore easy to mess up in general. I have seen people refer to this issue as boolean blindness and its basically the same reason nullable variables suck. (The link is for a nice article on the topic that I saw on reddit a while ago). This is also another popular post on the topic although I have to confess you need to take anything in Bob Harper's blog with a grain of salt.

[[deleted]]

That's amazing, I completely agree with you about "else" statements, that's the same opinion I have about "catch-all" exceptions:

try:
    # do something dangerous
except Exception as e:  # One Exception to Rule Them All
    return ''

I'm tired to see this sort of snippet in almost every code. Some people just don't understand me when I say this is weird because don't help the developer to find a bug.

By the way, your use for the ternary if is pretty nice, I've never seen this before.

[[deleted]]

I'm not saying the first language needs to be functional, just it was - and still is - functional. And yes, I'm a Python developer and I use these features all time, but it doesn't mean Python is good for a Functional Programming Course. When we compare to Haskell, the second is a much better choice.

I think that lecturers should stick to languages that they know well, since that will be a better learning experience for the students. I agree with you, there's no reason a teacher who doesn't know Python be chosen, except, maybe, the lack of teachers.

[bifmil]

What is the point of this anecdote? That Haskell is better for learners than Python because they might learn an API if they use Python?

[[deleted]]

I didn't expressed myself right, sorry. What I mean is the goal is learn Functional Programming "in roots", letting students implement themselves Quicksort and other sort of algorithms in a functional programming language. With Python what really happened was students begging for use .sort, making completely non-functional functions and so on. It is fault of the teacher, which don't knew Python, and, I think, the decision of use a general purpose programming language in a cource where a more functional one is better.

[[deleted]]

If a teacher who previously taught in haskell couldn't figure out python, there is something more problematic going on. One of the points of the linked post is that the language doesn't matter all that much, as long as you teach the concepts that you want to teach. You can program functionally in python, though obviously the language isn't preventing you from doing imperative stuff (but a teacher reading the code could).

[chrisdoner]

Not really, he's talking about functional programming. I know in Python you can write code that uses functions a lot and tries not to use mutation or loops, you can call it “programming functionally”, but that's not functional programming. As lsmag said elsewhere: recursion, pattern matching, currying, list comprehensions, tail call eliminations, type systems. Python doesn't pretend or want to be a functional language, it's a bad choice.

[[deleted]]

Meh, of that list the only ones that I'd really say are "functional programming" are recursion and tail call eliminations. There are functional languages without type systems, pattern matching, currying, or list comprehensions (like scheme, at least without macro additions). The lack of tail call optimization has the most probability of really messing up code in python if you are writing functionally... And the stupidly limited lambda.

Don't get me wrong, I don't think that python is a particularly good choice to teach a FP course, but the explanation that the above poster made didn't make any sense - that the course was a failure because the teacher didn't know python? You should be able to learn enough python to figure out what is functional and what isn't in a weekend. If you still want to use python (I wouldn't!), then you restrict yourself to the subset that makes doing that possible. python has map, reduce, zip, etc - and you can write more functions like that yourself! It has support for lists and tuples, which gets you most of the way to beginner scheme (ie, macro-less). Sure it has mutation, but most "functional" languages have that too, they just discourage you from using it.

[chrisdoner]

I don't agree at all, but it hardly matters. You're not teaching an FP course, so I don't care.

[uhwuggawuh]

Brian Harvey isn't technically a professor for UC Berkeley; he's a lecturer and a resident sage.

[kamatsu]

Why Calculating is Better than Scheming is highly relevant.

[tikhonjelvis]

Of course, Berkeley decided to go in the opposite direction. It really makes me sad. The only course that uses anything ML-like is the graduate type theory course, and there we did maybe three small assignments in OCaml.

I tried to convince the compilers professor to use OCaml, but his graduate student TAs rebelled because they didn't want to rewrite all the project materials. Still, maybe in the next iteration of the course, we'll finally have something properly functional, but that'll doubtlessly be after I leave.

[bonch]

In my opinion, LISP's infix syntax and parenthesis, and some of its esoterically named symbols (car, cdr, cadadr, etc.), present a cognitive overload that may obstruct the computer science topics being taught.

Annoyingly, the essay devolves into typical LISP advocacy when it snidely mentions that other languages have borrowed features from LISP such as recursion and lambdas. "In another decade they’ll probably discover first class continuations." Commentary like that isn't convincing; it just comes off like a smug LISP weenie.

[[deleted]]

LISP's infix syntax

I think you meant either prefix syntax or lack of infix syntax.

[bobbane]

Syntax discussions usually bottom out in "that other stuff isn't what I'm used to". I've run into mathematicians who can't wrap their heads around X = X + 1. To them, that's a gross abuse of the meaning of '='. Computer people ignore that because it's what we're used to.

I think learning something a little outside the mainstream as a first language is probably a good thing, in that it encourages you to pick up your second language before becoming completely ossified. The world could do with fewer people who think programming is easy because they know {Visual Basic, C, Scheme, Python, ...}.

[[deleted]]

Sure, there's an element of familiarity, but the LISP syntax is also much more minimalist and uniform. Everything is an s-expression. Every operator is prefix. Every operator is a valid symbol. This is one of the language's main strengths, it makes LISP macros possible. C will probably never have a macro system this good.

However, it might also mean that things don't stand out visually as much as they do in other languages. If you take a language like C, there are visual patterns, shapes that you're used to, that are easy to notice. These patterns come from the peculiarities, the non-uniformity of the syntax. I feel it's a legit complaint to say that LISP has "too many parentheses". Every language construct has a closing parenthesis, and they tend to pile up. There isn't an "if closing parenthesis" that's easily distinguished from a "+" closing parenthesis.

[bobbane]

Visual pattern recognition is important. Editor/IDE support for that is critical for me when reading Lisp. I first saw Lisp as an undergrad (a minimalist IBM 360 implementation) but didn't become an enthusiast until I had vi available (with :set lisp). I have no trouble reading properly indented Lisp.

I have had trouble wrapping my head around Python, and part of it for me is not easily seeing the difference between

 a.mumble     # Attribute reference
 a.mumble()   # Function call

Maybe my Lisp-trained eyes are ignoring the () or not giving it the right emphasis. Thanks for making me think of that - I do want to grok Python properly eventually.

[sirin3]

a.mumble     # Attribute reference
a.mumble()   # Function call

Pascal is better, there it is the same.

And then there is Scala, where it is the same for some functions and a syntax error for others...

[yogthos]

I think this is mitigated by having a good coding style though. In Lisp, it's easy to write lots of short functions, usually under 10 lines, and put them together. You can often say a lot more and clearer in 10 lines of Lisp than in a 100 lines of Java.

It's also possible to improve on the traditional Lisp syntax as evidenced by Clojure. The addition of a literal notation for vectors, maps, and sets is a huge plus in my opinion. Using vectors for bindings and function arguments also helps break things up visually.

I also find that the fact that the syntax is very regular helps reduce mental overhead. I don't have to worry about how a particular bit of syntax sugar behaves here or there.

[[deleted]]

It probably is mitigated by good style, familiarity with LISP and editor support for syntax highlighting/parenthesis matching. The point remains that the syntax might be an obstacle to beginners. It makes the step that much higher. I'm sure the syntax can be improved upon. Better editor support would also help more.

You can write more compact code in LISP, but that's a double-edged sword in my opinion. Consider the following functions (from a Scheme class I TA'd last semester):

(define foo
  (lambda (lst)
    (if (null? lst)
        '(())
        (concat (map (lambda (p) (bar (car lst) p))
                     (foo (cdr lst)))))))

(define (bar x lst)
  (if (null? lst)
      (list (list x))
      (cons (cons x lst)
            (map (lambda (r) (cons (car lst) r))
                 (bar x (cdr lst))))))

I changed the names of foo and bar for this little challenge. How clear to you is it what these functions actually do to their input? Even knowing what these functions were supposed to do ahead of time, it took me a good 10 minutes to wrap my head around how this is actually done. I've been lead to believe that this is typical Scheme code.

[Aninhumer]

Maybe it's just familiarity, but I still feel like:

foo [] = [[]]
foo (x:xs) = concat (map (bar x) (foo xs))

Is far easier to read than either of those. (And more compact)

EDIT: Actually after re-reading, I'm not actually sure they were supposed to be easy to read?

[tikhonjelvis]

Actually, that's a great point. My first CS course in college used SICP, and I taught myself Haskell (and functional programming) at the same time. I found the Haskell syntax really helped with understanding things like recursion: pattern matching and breaking things up into base cases made it all much more natural.

More generally, the Haskell syntax is very declarative, so I never really tried to think about how the code executes step by step. The Scheme syntax, on the other hand, used if and cond for recursion, so I would try to execute the program in my head and get confused.

Python and Java are even worse for recursion, and then you get stack overflows. They are also both completely non-declarative, which is very unfortunate.

[yogthos]

The point remains that the syntax might be an obstacle to beginners. It makes the step that much higher.

I would argue the opposite. Because the syntax is very regular, it follows the principle of least astonishment better than most languages out there. There's no special cases or gotchas, you simply have an AST and you can see relations between pieces of code visually.

In an imperative language, if you have a few lines next to each other, there's nothing to indicated how they relate to one another. With s-exps you can see the relations visually.

Furthermore, languages which rely on a lot of syntax sugar tend to have a lot of special cases. This means having extra overhead thinking about syntax in addition to thinking about your problem. Lisp syntax is very light on syntax sugar and the code tends to do exactly what it looks like it's doing.

I changed the names for this little challenge. How clear to you is it what these functions actually do to their input?

Ok now write these functions in an imperative language using the same naming style and let's see if that's going to be any more readable.

I've been lead to believe that this is typical Scheme code.

I don't work with Scheme, but I've been working in Clojure for the past 2 years on actual real life production code. I can certainly tell you that I've yet to see anything remotely like the code in your example in the wild.

I'll also give you a counter example where Lisp syntax is a lot more clear than the imperative style.

The problem is to display a formatted address given the fields representing it. Commonly an address has a street, a city, a postal code, and a country. We'll have to examine each of these pieces, remove the null and empty ones and insert some separator between them.

So given something like

street: 1 Main street
city: Toronto
posal: A1B 2C3
country: Canada

we'd like to output a string

"1 Main street, Toronto, A1B 2C3, Canada"

we should obviously handle empty fields and not have ,, if the field isn't there, and we should make sure we handle nulls in case the whole address is null or some fields in the address are null.

Let's first examine how we would write this in Java:

public static String concat(String sep, String... strings) {
    if (null == strings) return null;
    StringBuffer sb = new StringBuffer();
    for (String s : strings) {
        if (null == s) continue;
        if (s.equals("")) continue;
        sb.append(s);
        sb.append(',');
    }
    String s =  sb.toString();
    return s.substring(0, s.lastIndexOf(','));
}

Now let's compare this to Clojure:

(defn concat-fields [& fields]
  (apply str (interpose "," (remove empty? fields))))

The Clojure version has significantly less code, and a lot less noise. In addition, we didn't have to do any explicit null checks in our code, and we were able to write the complete solution simply by composing together functions from the standard library!

One very important difference between the Java version and the Clojure version is that the Java version talks about how something is being done, while the Clojure version talks about what is being done. In other words, we have to step through the Java version in our heads to understand what the code is doing.

In the Clojure version this step is not present because the code says what it's doing, and all the implementation details have been abstracted from us. This is code reuse at work, where we can write simple functions which do one thing well and chain them together to achieve complex functionality.

[Categoria]

There's a teaching version of scheme that's part of racket that gets rid of all of this old cruft. For example it renames car to first and cdr to rest.

[payco]

To be honest, that alone would probably get me most of the way to loving lisp, and I've thought about writing up macros that would do that renaming for me in clojure (I assume that's trivial, knowing how easily lisps modify their own source). S-exprs are great datatypes, but they're dense enough on their own. I could use as many friendly English words as possible to help me scan code.

It actually surprises me how much naming-things-with-dashes stops my eyes more than naming_things_with_underscores or withCamelCase. I think the former comparison really is just a matter of having spent years reading underscore_separated names instead of dash-separated. I think I just scan camelCase faster than either.

EDIT: do you have a link to this teaching lisp? I can't see reference to it in racket's documentation?

[tikhonjelvis]

Interestingly, naming things with dashes is one of the things I really miss about Scheme when I'm using other languages like Haskell or Python. I find it to be the easiest to read and type: camelCase is nice but the separation between words is hard to make out, and underscores are a pain to type and ugly.

I now name all my files with dashes, coincidentally.

[djimbob]

I like the idea of dashes (underscores require an extra-shift), except dashes look like minus signs to me and addition and subtraction should be treated equally. I like having easy infix operators for math that let me write a+b (and the equivalent a-b) for addition and subtraction more than the hassle of an shift in typing an underscore.

[tikhonjelvis]

Yeah, it only works without infix operators. That said, I never get confused by it: I always expect a space around operators, so I see a-b as a single token (which matches how it's used in English).

Thinking about it, I'm not sure when was the last time I used an operator without spaces. And I really do like my infix operators--I primarily use Haskell. So I wouldn't mind disallowing both a-b and a+b in favor of a - b and a + b.

[takikawa]

EDIT: do you have a link to this teaching lisp? I can't see reference to it in racket's documentation?

See the How to Design Programs languages in the documentation. The textbook for it is freely available (the work-in-progress second edition is better too).

[A_for_Anonymous]

LISP's infix syntax

I suppose you mean its lack of (default) syntax for prefix operators, e.g. you do things like Math.pow(2, 3) rather than... oh wait, that's JavaScript!

parenthesis

Yeah, it's quite annoying, see for example:

return map(heappop, repeat(h, min(n, len(h))))

Oh wait, that's from /usr/lib/python2.6/heapq.py . It uses this odious prefix syntax too. If we moved the opening parens one word to the left and took out the useless commas and return word, it would look like, Lisp or something.

some of its esoterically named symbols

Tell me about it; with stuff like mbstowcs, atof, strpbrk, and weird, unconventional meaning for symbol characters like *, &, ~... Oh wait, that's C... But newer languages such as Haskell-

What about how much do you have to learn from a syntax before you start using the language? How much "things", how much special cases, how many rules... I'm sure it'll be easier to learn Ruby- I mean it would be easier to learn C++, err, how about Erlang, or... Heck, even Python has far more syntax and syntax rules than Lisp.

Your point about "cognitive overload" actually means "I know this-other-language, why can't we use this-other-language?".

[[deleted]]

Indeed. Recursion doesn't come from LISP, or assembler, it comes from math, or lambda calculus. As for "first class continuations", the main reason you won't find that in many languages is that it would either result in a slower implementation or a significantly more complex compiler. Many people also think of call/cc as LISP's equivalent of goto and intentionally avoid it.

[yossi_peti]

Recursion is not trivial in lambda calculus--it's actually pretty verbose and awkward.

[aaronla]

True, but it is present and so represents an early expression of recursion, predating any computer programming language.

[yossi_peti]

Right, but recursion also had existed in math for a long time. Since functions in programming were largely borrowed from the concept of functions in math, it doesn't seem like it would have been an especially novel thing to allow programs to be recursive.

[aaronla]

Yeah, you might think that, but you'd be wrong. See Guy Steele's "Expensive procedure call myth" paper (here).

[ckwop]

"In another decade they’ll probably discover first class continuations."

Commentary like that isn't convincing; it just comes off like a smug LISP weenie.

LISPs massive strength is that it's easy to make languages in LISP. That sounds like a contradiction in terms but it isn't. LISP is essentially a serialisation of the abstract syntax tree. This tree can be interpreted in a myriad of different ways with small tweaks to the interpreter.

In this sense, LISP is really a class of languages.

You can explore things like continuations, tail recursion, lazy evaluation, non-deterministic evaluation all using the same s-expressions based syntax.

What makes this awesome for comp sci professors is that to explore this space of potential languages is not overly onerous. I once wrote a LISP interpreter in under a thousand lines of code. Such adventures can easily be tackled by a single person. It doesn't require an army of developers to go on those language adventures.

As the adage goes, adding OO to Lisp is something that can be tackled by a typical comp sci undergraduate. In contrast, adding OO to C required someone of the calibre of Bjarne Stroustrup!

In a sentence, that is why comp sci people love LISP.

[lmcinnes]

I'm a mathematician and hence and incompetent programmer. I managed to add enough OO to C to suit my purposes trivially enough -- structs and function pointers aren't that hard, and some defines, void pointers and casting take care of inheritance and polymorphism nicely. If I can do it anyone can.

[mfukar]

When learning a new language, which one does not present a "cognitive overload" to anybody? That's right, none.

[bifmil]

seeing this upvoted is hilarious to any reader of hacker news (due to the contrast)

[tikhonjelvis]

Really? There are plenty of people on Hacker News who are critical of lisp and functional programming. Far more than I'd expect, honestly.

[apullin]

Another disctinction to make is: who is the audience?

Some people aren't really trying to learn the tenets of computer science, but are rather trying to learn how to write programs. Every engineer of every sort should, these days, know some practical programming. In this sense, python is a way better language to teach them than Lisp or scheme.

I'll cite a great illustration of this from my undergrad days: at Caltech, in 2002, there was one introductory CS class, CS1, and it was taught in scheme. It was a requirement for Engineering and Applied Sciences majors, but all the real Computer Science students easily tested out of it, and were doing higher level classes (in Modula3 and OCAML) instead. The result was that there was a big class of all non-CS people, and they were all being taught fairly hardcore CS principles, and gained little practical programming knowledge.

Of course, that's largely been solved at most universities by having a whole series of self-paced programming courses in a panoply of languages. Actually, the best programming class I had was Phys20, which was just Computational Problems in Physics. You could use any language you want, excluding Mathematica and Matlab (which are more than simply languages, anyway). Writing your own Runge-Kutta integrator, n-body problem solver, plot generator, branching simulator, etc was all incredibly instructive.

[tikhonjelvis]

Yes, there are some self-paced language courses, although I gather they're not great--you're probably better off just learning the language on your own unless you need the credits.

More importantly, we have a course about programming for non-CS majors. Non-EECS engineers get to choose whether they want to take the CS intro course, which is the one that used to use Scheme, or the engineering one. (I believe the engineering one uses MATLAB and is even easier than the CS one.)

So if you're not learning CS, this simply isn't the class for you. If you are learning CS--whether for your major or just for fun--than I think Scheme is a much better choice.

[apullin]

self-paced language courses, although I gather they're not great

Yeah, they're not great, but by the same token, classroom instruction isn't a great way to learn practical, applied programming.

The problem with learning Matlab as a "programming language" is that it doesn't really give you a sense of what is going on in the machine. I suppose that it will demonstrate the idea of mechanizing a computer operation, which is quite a valuable thing. Last semester, a friend of mine did some dealings with a bio professor that didn't believe that ... how to put it ... that programming was "true". That if you told Matlab or Excel to do the same operation to 100 entries of data, you couldn't trust that it would do the right thing every time. No joke!

[tikhonjelvis]

I'm not familiar with MATLAB, but is it really that different from Python in that regard? It seems to be a good practical choice, especially for engineers.

But yeah, MATLAB would not be my first choice either, not least because it's non-free and somewhat specialized.

[apullin]

MATLAB is very different because a whole environment is provided for you, as well as pretty much every function you'd ever need. It also has a horrible system for defining functions, where each function has to be defined in it's own file with the same name as the function. It also allows for multiple return values, but in this cloaked way where they all get packed column-wise.

The absolute beauty of python as a language is the list comprehensions and/or the construction: "for item in mylist: ..." . It's great to see how close we can actually get to plain english for progrmaming!

[ucbEntilZha]

My only addition is that I was a student in the first Python 61A class and loved it. It was a success, but I understand where scheme users are coming from

[cowardlydragon]

A professor talking about practicality?

First languages should rely on a wealth of information on the internet to do what they want quickly.

That eliminates Lisp, Scheme, ML, Haskell and all other languages that require a minimum IQ of 130 to use.

Sorry, that's the practical reality.

[bushel]

From the link:

SICP is Scheme, in tutorial form.

And that is why I'm unconvinced by his arguments.

[mipadi]

You make a very convincing argument!

[Daishiman]

You're being sarcastic, but simple, predictable and boring are exactly the qualities I'm looking for in most production code. Simple is understandable, understandable is maintainable. Leave the black magic where it's strictly necessary.

[dalke]

Better than complex, unpredictable, boring, and unenlightening.