Just because Lisp looks foreign doesn't mean that it's harder. The syntax is different, but it is also very simple. If this were untrue, Scheme wouldn't have survived as a teaching language all these years.
At first I thought the Dr. Scheme (now Dr. Racket) program was crazy to choose a Lisp like language. Then as I learned more languages I realized how much easier it is to think about programming since I started out with Dr. Scheme.
How To Design Programs for those interested in picking up Scheme: http://htdp.org/
> The biggest secret to Lisp is that it is actually the simplest programming language ever created—and that, coupled with its expressiveness and elegance, is why it is favored exclusively by the best programmers in the world.
Sounds to me like the GP is in shock about such an over-the-top claim. And it sounds like you're trying to pretend to read his/her statement for something other than what it is.
It's complex because it's powerful. ~A is the most common directive; it simply prints an object. '~{...~}' (braces) iterates over a list, applying the directives within it to the list elements. Within that construct, '~^' exits if the last element of the list has been consumed; it's used here to keep the separating space from being printed after the last element. '~@(...~)' (parens) capitalizes words in the output of the directives it contains, downcasing the non-initial character of each word.
So there's a lot more power here than in 'printf' control strings. If you find the more exotic notation unintuitive -- and you certainly wouldn't be alone -- you don't have to use it.
It's disingenuous to claim a DSL is part of the language syntax. E.g. I would not consider the regex formatting specification as Python syntax. I mean, if we follow that line of thought, it's like saying Jinja is Python syntax.
If you're going to need to teach it for students to read and write programs in the wild than it's irrelevant whether it's 'part of the language syntax' or the ecosystem's syntax. 'Loop' is another one.
Lisp as an idea has a simple syntax but Common Lisp isn't even close to that platonic ideal.
I am only recently a lisp user but honestly, how is the format function far from:
printf("something %s then %d finally %f!", "asd", 1, 1.2)
As mentioned, there is a loop built into format. Since lisp also has a (list) function eg: (list 'a 'b 'c 1) I still don't see an argument beyond familiarity with the C style printf syntax for why format is bad/unreadable.
That's right; Lisp's syntax is not only simple; it is simple while retaining the power to combines together and express any syntax tree. If you put on special Lisp goggles, you can see S-expressions inside the syntaxes of other languages.
It's less about it being 'foreign' and more about it being totally unparsable.
The thing with imperative programming is that you don't really need to know the language to at least get an idea of what's happening.
Lisp is so dense that while you can pack an unbelievable amount of programming into a small chunk, approaching it as a beginner is daunting. There isn't a really good way to 'build' on an algorithm and learning it is significantly harder than learning C# or Java or even better yet, Python.
It's like saying, 'Linux is easy to learn! You can do so much in so few characters! It's so powerful! And look, robust manual pages for all!'
Yeah, that's true, but handing a user some pipes and greps isn't going to explain what the hell they actually do or better yet, how to leverage that into something useful. It's just going to look like greek to anyone who sees it and a huge effort has to be made to get to the point where you can even begin to understand what's happening.
Imperative programming doesn't ask you of much. 'Here is a class. Here is the main method. Write some stuff in here. Here are some basic methods in the default libraries and their expected inputs. It's going to execute line by line. Go nuts.'
And that's really the difference here. Lisp asks a lot of the user up front. Python doesn't. C# doesn't. Fuck, Python is so loose that you don't even really need to know what any of the structure is to start writing something that kicks back some output. Yeah, as a group that understands Lisp and Scheme and Haskell and F#, it's really easy to say, 'Lisp isn't THAT hard', but that's bullshit. Lisp IS that hard. Lisp is a very difficult language to pickup when you are starting at square one and it's only marginally easier if your background is purely imperative languages. Misrepresenting that is a bold-faced lie.
From what I understand the hardest thing to teach new programmers coming to Java or Javascript or even Python is assignment and mutability. That has a huge cognitive overhead.
Contrast that with the lambda-form structure and substitution method of evaluating expressions in Lisp.
(function arg1 arg2...)
It's consistent and simple. You can introduce mutable variables and iteration later. With just the substitution method you can go very far as demonstrated by Gerald Sussman in the SICP lectures.
You color your argument with a preference for imperative programming by over-simplifying Java; arguably one of the more difficult languages to teach beginners. The venerable, "Hello, world!" exercise is an illustrative example.
Again contrast that with:
(format t "Hello, world!")
I think it is possible that Lisp is not that hard to teach as we're meant to believe by arguments like this. Java is a fine language but it requires a fair amount of expertise to use effectively. The same can be said of C. Python and other dynamic languages of the sort might come close to lowering the "difficulty" bar but I wouldn't discount Lisp just because it seems foreign to you.
Lisp is totally parseable. So much so, that no LALR(1) approach is required to conquer it. It consists of an unambiguous parenthesized notation, plus some simple prefix-basd notations (and only a small modicum of non-nesting infix, like the consing dot and the colon in "package:symbol". You do not run into any issues of associativity or precedence. Moreover, indenting Lisp so that it looks good, readable and "canonical" is very simple; it is based only on a couple of heuristics that can be applied to small expressions or large functions alike.
There is not so much difference between "parseable by humans" and "parseable by compilers". What is hard for the machine is hard for you also. For instance, if you're asked to sort a deck of 1000 randomly shuffled cards, each printed with a unique integer, you will not do better than O(N log N).
Take any LALR(1) defined programming language. Now write it in one line without indentation. How easy is it to parse (for you, human)? We rely on other clues to grok languages, like indentation. You cannot really "cheat" in parsing; if the machine requires a 600 state transition graph with a push-down stack, that translates into difficulty for you, also.
Lisp is obviously parseable by humans; there are people who easily write and maintain large, complex Lisp programs.
First, I don't want to have to turn myself into an LALR parser to read some code.
> What is hard for the machine is hard for you also.
But what's easy for the machine may well not be easy for the human. LZW isn't very hard for a computer, but good luck reading it.
Syntaxes that may be equivalent to the computer may well not be for the human. Yes, a human can train itself to read that stuff, but if the language designer made more humane choices, the language would be easier for the humans.
Note that this does not directly address how hard it is for humans to read Lisp. It merely addresses the parent's comments.
My point is hinting at that Lisp is readable when it is properly written with indentation and alignment. And when good coding practices are followed, like writing reasonably small functions, using good variable names and so on.
Humans do not count parentheses and keep track of nesting levels when reading Lisp, any more than they go through LALR(1) state transitions when reading C++.
We structure the code in 2D, and use visual cheats.
With Lisp, there is no clear distinction between "language" and "library".
In any language, code is hard to understand when it uses a lot of external symbols from a library.
No matter how well you understand C, if I suddenly give you a tarball of the USB subsystem of a kernel you've never worked with, and open a random file, it will look like gobbledygook, even though you "understand" the declarations at the "language level".
Most operators in Lisp code are essentially library symbols; and if you're missing some key symbol (such as the outermost one), you might not be able to understand it at all.
Lisp readability requires not only nice code structure, but a decent working vocabulary: enough vocabulary that you're not tripped up by the standard things that are in the language, and you know what is in the language and what is defined by the program.
For instance if you see some (macrolet ...) form and you have no idea what that means, you may be stuck. What is macrolet? Did the program define that somewhere? An experienced lisper doesn't bat an eyelash. Of course she knows what macrolet is: it's a binding construct for making lexically scoped macros, doesn't everyone?
(But at least you know from the unambiguous syntax and formatting clues what goes with what: what parts of the whole thing are arguments to that macrolet, and which are outside that macrolet! So when you look up macrolet in the reference manual, you know exactly what is being passed to it and can figure it out without any undue difficulties.)
And, about that vocabulary point: different Lisp dialects differ in their vocabulary. Common Lisp vocabulary will not get you very far in understanding Scheme. Emacs Lisp vocabulary will serve you only so far if you'e reading Common Lisp. A dedicated Schemer will be tripped up reading EuLisp, and so on. In languages that have a big divide between "built in" and "library", we see this kind of variation at the library level. For instance C is mostly the same on Unix or Windows, but the libraries are mutually foreign languages. `CreateProcess` with umpteen arguments versus `fork` and `exec`, and whatnot. Since C doesn't have built in data structures, everyone rolls their own, creating effectively a different "C with lists" dialect.
> Lisp asks a lot of the user up front.
Like what? Last time I checked you get a repl and type away. If you have a mac you can install CCL from the app store and don't even have to use the terminal to get to a repl.
> Python doesn't. C# doesn't. Fuck, Python is so loose that you don't even really need to know what any of the structure is to start writing something that kicks back some output.
again, not unlike lisp.
> Lisp isn't THAT hard', but that's bullshit. Lisp IS that hard
Care to back up that claim? AFAIR The SCIP barely spends a page explaining the semantics. The CONCEPTS in teaches are hard(er) but they are not lisp. In fact one of the reasons the SICP was written in Scheme is so that you _don't_ have to waste half a semester teaching the language before you can get to the fun, important, useful stuff. The little schemer doesn't spend much time teaching lisp either.
I don't find your argument to be very compelling.
Let me guess: you learned imperative programming first, you're most familiar with it, and you only have limited experience with Lisp, if any?
The fact that you find imperative programming easy (because you know it well) and Lisp and functional programming to be hard, is not very informative about which of imperative or Lispy or functional programming is easiest to learn.
The only thing that was hard with imperative programming that I can remember was "=". That was absurd, to put it simply. "x = x + 1"? As someone who has seen these symbols in math class and think they know what they mean that notation kind of suck.
Oh man, yes! One of my earliest memories from when I started coding, at 10 years old, was when I saw "X = Y + 10" in a program, and a similar thing in the next line. My first reaction was: what is that? It looks like a system of equations that the machine is supposed to solve!
Wrong either way. Because it is so easy to parse by computers it is easy to use them to format it. Have you tried reading foreign (as in not written by anyone you know) lisp code? IME It is not hard(er) than any other language.
For example, IME delving into the codebase of hunchentoot was way easier than django's.
All of this stuff is subjective. I've coded Python for some time, and I've done an entire project in Clojure.
Because I've done more Python working, reading Django's source is much easier for me than most Clojure code (even my own), but that's not to say the same for everyone else.
These are after all languages (even if they are artificial). The human brain is really good at understanding a wide variety of linguistic constructs, the main issue is familiarity and that changes from person to person.
Even if you don't understand Lisp (the meaning of various operators), the structure of a Lisp function is already clear. All you have to understand is symbols, spaces, and parentheses; a lot of that comes from Western writing systems already (which use symbols separated by spaces (and parentheses)). The one piece of common knowledge that you dno't get to apply in Lisp is the writing system for infix arithmetic. (It can be easily put in as a small library module, but nobody ever uses it.)
