No. Lisp is actually the simplest programming language, and has no syntactic cruft. While it wasn't designed to be “easy to learn” like Swift, Python, Ruby, or Basic, there is less overall to learn and you will be writing real, useful programs in Lisp sooner than you could with other languages."
It's like a never-ending stream of lies, every word being a little more absurd than the last...
But is it?
++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>---.+++++++..+++.>>.<-.<.+++.------.--------.>>+.>++.I'm learning and enjoying clojure, though!
How To Design Programs for those interested in picking up Scheme: http://htdp.org/
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.
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.
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.)
Completely and utterly false. Lisp's s-expression syntax is trivial to parse because it is so regular.
The thing with imperative programming
Common Lisp is multi-paradigm, as mentioned in the site's FAQ. You can write imperative code all you want.
For example, IME delving into the codebase of hunchentoot was way easier than django's.
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.
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...)
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!")
> 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.
(format t "~{~@(~A~)~^ ~}, because ~{~A~^ ~} is easier!" llthw (cddr llthw))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.
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.
Lisp as an idea has a simple syntax but Common Lisp isn't even close to that platonic ideal.
Lisp has no syntactic cruft? It has (almost) no syntax, so there's less room for cruft. That said... cons? car? cdr? That's your syntax? That's not cruft? Seriously? There may be less total cruft, but the percentage of cruft might still be higher...
There's less overall to learn? If you mean to master the syntax, sure, that's true.
You'll be writing real, useful programs in Lisp sooner than you could with other languages? That's a much more arguable point. There's more to being able to effectively program in Lisp than learning the syntax (as there is for every language). Is that "more" easier to learn for Lisp than for other languages? I have no data, but for the web site's claim, I'd at least say "citation needed".
If you're a bright developer, who puts in time eagerly, it will take at least six months before you begin to "get it".
At that time you may start itching to evangelize to others, but those who have not put in the time will not get it.
It's not realistic to try to make someone see in one or two e-mails or postings what took you a year to see for yourself.
A recent example from personal use is continuations. Scheme has them as a first-class object. Common Lisp does not, but a common claim is that you can write macros to provide continuations. Some people have: there's "cl-cont" available on Quicklisp, which is a macro that will code-walk your functions to turn them into continuation-passing style and thus allow you to use continuations in those functions.
So that's great, right? Common Lisp now totally has continuations? Not at all. In order to get this feature, you need to wrap ahead of time (specifically, at compile time) the functions you want to be continuable, and all of their callers, in this macro. You cannot simply use a function that you've been given as part of a continuation, it had to have been compiled under this macro.
That's where the power of macros completely falls down and, in my opinion, gets completely overblown. Yes, your language is extendable, but your extensions are limited to computation and source-to-source transformation at compile time. You can't apply any of that power to already-existing artifacts.
Which is not surprising. Actually nobody with a clue makes such a claim.
Still, Lisp macros have a wide variety of very useful applications.
> Yes, your language is extendable, but your extensions are limited to computation and source-to-source transformation at compile time.
Still quite useful. From relatively simple stuff which makes to code more readable to complex macros like ITERATE.
> Which is not surprising. Actually nobody with a clue makes such a claim.
Most Lisp books make this claim.
For sure not.
1. lisp got a lot of stuff wrong; there's really no reason not to use scheme.
2. lisp syntax is more something to overcome than something to become "enlightened" about. Language syntax no longer has to be motivated by ease of parsing.
3. Dynamic typing only gets so enlightening. At the end of the day, type theories are where the rubber hits the road.
4. Macros don't excite me much. I mean, they're cool, sure. Okay.
At the end of the day, there's a lot more exciting stuff out there (e.g. any math class beyond the calculus sequence or so) that people get way less worked up about.
It's possible to understand lisp, think that there are important ideas there, but not go around evangelizing. Most smart people who study something non-trivial don't evangelize.
Scheme got a lot wrong from a practical perspective. Use Lisp instead.
Type theories are over-hyped. 99.99% of all software is written in languages without advanced type systems.
Macros are nothing for 'excitement'. They are a tool. They enable the user to write source transformations, which has several applications in Lisp: control structures, compile-time computation, etc etc.
But Im not going to get into a language war.
Stepping back to the original point, there are other significantly important/powerful ideas in the world, and lisp users are somewhat over-the-top in their significance-to-hype ratio.
> Stepping back to the original point, there are other significantly important/powerful ideas in the world, and lisp users are somewhat over-the-top in their significance-to-hype ratio.
Many of the powerful ideas in software development are available in Lisp.
And there's a whole hell of a lot more in the world than software development...
To the extent that lisp captures any of these other foundational ideas/theories/techniques, type theory does better (which is what I was pre-empting with my original reference, not the role of type systems in the world of practical software development).
Lisp is not a version of lambda calculus. It's a programming language. Macro programming in Lisp works fine in many cases.
> type theory does better ... not the role of type systems in the world of practical software development).
Lisp is about practical software development.
I'd argue that there are lots of other settings with ideas a powerful or more powerful than whatever it is each individual evangelist feels someone should get out a lisp. Yet none of these other things have enlightened evangelists pushing the product.
That's all I'm saying.
It's been my experience that most things are tractable once you spend long enough staring at them.
If you care enough about a subject to have strong sentiments like "never-ending pack of lies" then your time would perhaps be better served by spending time with the "adored" object, rather than these comments.
There isn't any syntactic cruft in Lisp that will have you scratching your head as to what goes with what.
There are semantic head-scratchers related to syntax, like working out the implied actions of complicated, nested backquotes. There is never a question of syntax, though: nested backquotes are not ambiguous syntactically: they are just nested lists, with some sprinkling of a simple prefix-based notation throughout (splices and unquotes).
Lisp is a difficult language due to it's density and unreadability.
Useful stuff hasn't been built in functional languages until very recently, exception being some AI. Haskell and friends are making functional languages cool and useful (and that's great!) but if you want to build something useful as soon as possible, learn .NET, Java, Python or Ruby.
You might enjoy this: http://www.infoq.com/presentations/Simple-Made-Easy
The idea that you can write a useful program in Lisp faster than in other languages is pretty unsupportable. For most users, the time and effort spent getting Lisp up-and-running on their machine of choice will already have lost. Incidentally, I played with the interactive REPL and it wouldn't advance beyond the second page.
And, if you do write a useful program in Lisp, you run into the deployment problem. The deployment problem is pretty bad. Apple's Advanced Technology Group at one point had one of the highest concentrations of Lisp-heads in the world and produced a bunch of stuff like Dylan, Sk8, etc. that was intimately tied to their Lisp implementation. Not only was this not cross-platform, and pretty hard to distribute and deploy even on the platform it was created for (680x0 Macs) it was killed by the transition to PowerPC.
This isn't as big a problem if you're writing server software, but it's absolutely disastrous if you're writing desktop or mobile software.
One could show someone how to do something useful and deployable in Python, PHP, Perl, Javascript, or whatever in a few minutes and chances are they could have a usable dev environment set up in a few minutes.
And for any language that's popular now, there was a time that it wasn't yet popular, and deployment was a pain.
So I think you have it backwards: Lisp is not unpopular because it's hard to deploy; it's hard to deploy because it's never cracked the popularity threshold.
Why is this? It's because they can live in, and interact with, the common linking and loading ecosystem that the rest of the world lives in: the C ABI. If you can link your output into something that respects the C ABI, you can deploy it[1].
Common Lisp implementations could immediately solve their deployment problem by living in this ABI. So far, the only one that has done so is ECL (which is an excellent project).
[1] A few alternatives exist. The Java and .NET ecosystems are also viable link targets (as I think Clojure has proved).
But this only restates the point. It's easy because those things are popular. Try deploying an executable that requires a shared library that you can't download with your package manager, and you're pretty much back into the same pain.
Using the C ABI helps if you want to link against other code that uses it, though it isn't strictly necessary (pretty much all these language implementations have foreign call mechanisms). But this is a development issue, not a deployment issue.
ECL does make it convenient to build standalone executables, but most CL implementations can also do this.
Lisp systems like LispWorks can generate typical platform shared libraries.
Many can easy embed C-code.
Some compile to C, which than can be embedded. ECL is only one example. Others are mocl or the ECL-related systems.
Lisp is notoriously hard to deploy. Code is not portable between different lisp implementations. Apple's ATG ended up axing many projects because they had so much trouble moving their lisp from 680x0 to PowerPC.
The fact you talk about "your system's package manager" ignores my point -- I'm not saying Lisp is especially hard to deploy to servers (although it is -- but this is, as you say, a popularity issue; and it would be far worse if the world of servers hadn't converged on a small number of very similar platforms). I'm saying it's hard to deploy to desktops and mobile, which is where most of the "useful" programs people might want to write still live.
A huge part of Lisp's problem is fragmentation. Which Lisp? Aside from fragmentation in Common Lisp itself, there's all the not-quite-Lisps around, ranging from Arc to Scheme to Clojure to sheesh-I-really-have-no-idea. And of course this is because once you start coding in Lisp there's an overwhelming urge to abstract away difficult things in your own clever way, perhaps even hacking the language itself, and pretty soon your little world is utterly unique.
Another great, simple language in the exact same boat is Forth.
Keep in mind too that different Lisps have different syntax. The only thing in common between them is Polish notation, S-expressions and a macro system. A Clojure program and a Common Lisp program look and feel very different.