"Is Lisp as hard as people say it is? No. Lisp is actually the simplest programm... (2024)

wes-exp on July 10, 2014 | next [–]

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.

bsilvereagle on July 10, 2014 | parent | next [–]

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/

sejje on July 10, 2014 | parent | prev | next [–]

> 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.

But is it?

nohaxplz on July 10, 2014 | root | parent | next [–]

Sounds like you just got told you're not one of the best programmers in the world and are still in shock about it.

nightski on July 10, 2014 | root | parent | next [–]

Simple syntax does not a simple programming language make.

gre on July 10, 2014 | root | parent | next [–]

Simple syntax "Hello world!"

 ++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>---.+++++++..+++.>>.<-.<.+++.------.--------.>>+.>++.

AnimalMuppet on July 10, 2014 | root | parent | prev | next [–]

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.

sejje on July 10, 2014 | root | parent | prev | next [–]

I'm not one of the best programmers in the world, no shock there.

I'm learning and enjoying clojure, though!

gre on July 10, 2014 | parent | prev | next [–]

The DSL for string formatting certainly doesn't look simple.

 (format t "~{~@(~A~)~^ ~}, because ~{~A~^ ~} is easier!" llthw (cddr llthw))

ScottBurson on July 10, 2014 | root | parent | next [–]

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.

gre on July 10, 2014 | root | parent | next [–]

It's just disingenuous to say that LISP has extremely simple syntax and then show the DSL for format, which is anything but LISPy or simple.

CatMtKing on July 10, 2014 | root | parent | next [–]

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.

Avshalom on July 11, 2014 | root | parent | next [–]

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.

ScottBurson on July 10, 2014 | root | parent | prev | next [–]

I don't know if it's disingenuous, but I'll agree that it may not be good marketing :-)

gaigepr on July 10, 2014 | root | parent | prev | next [–]

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.

wglb on July 10, 2014 | root | parent | next [–]

There is a loop embedded in the lisp version.

mcosta on July 10, 2014 | root | parent | prev | next [–]

I do not understant it, but with changing ~ with % I can imagine what it does.

rtpg on July 10, 2014 | parent | prev | next [–]

Simplicity of syntax does not translate to ease of use. Or else we'd all be programming in one-instruction Turing Tarpit.

kazinator on July 10, 2014 | root | parent | next [–]

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.

mkautzm on July 10, 2014 | parent | prev | next [–]

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. f*ck, 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 bullsh*t. 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.

agentultra on July 10, 2014 | root | parent | next [–]

How much of your argument is cognitive bias?

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!")

PuercoPop on July 10, 2014 | root | parent | next [–]

You could even just write "Hello, world!"!

kazinator on July 10, 2014 | root | parent | prev | next [–]

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.

kazinator on July 10, 2014 | root | parent | next [–]

^ Why would someone downvote facts? Because they conflict with their religion, of course.

kazinator on July 10, 2014 | root | parent | next [–]

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.

AnimalMuppet on July 10, 2014 | root | parent | next [–]

I think you're missing the point and/or wrong.

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.

kazinator on July 10, 2014 | root | parent | next [–]

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.)

kazinator on July 11, 2014 | root | parent | next [–]

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.

tormeh on July 10, 2014 | root | parent | prev | next [–]

Parseable by humans, not compilers/interpreters.

PuercoPop on July 10, 2014 | root | parent | prev | next [–]

> 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. f*ck, 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 bullsh*t. 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.

catern on July 10, 2014 | root | parent | prev | next [–]

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.

tormeh on July 10, 2014 | root | parent | next [–]

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.

kazinator on July 10, 2014 | root | parent | next [–]

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!

wes-exp on July 10, 2014 | root | parent | prev | next [–]

totally unparsable

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.

tormeh on July 10, 2014 | root | parent | next [–]

Parsable for humans, I believe he meant. And there's something nice about line-by-line execution.

PuercoPop on July 10, 2014 | root | parent | next [–]

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.

fisher-lebo on July 10, 2014 | root | parent | next [–]

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.

kazinator on July 10, 2014 | root | parent | prev | next [–]

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.)

AnimalMuppet on July 10, 2014 | prev | next [–]

Well, let's see.

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".

kazinator on July 10, 2014 | parent | next [–]

I believe that Lisp requires years to master.

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.

nmrm on July 10, 2014 | root | parent | next [–]

I think the whole enlightenment thing w.r.t. lisp is overblown.

nmrm on July 11, 2014 | root | parent | next [–]

lol @ random downvotes for criticizing lisp. Set and match.

emiljbs on July 11, 2014 | root | parent | next [–]

I don't think that any Lisp programmer downvoted him.

kazinator on July 10, 2014 | root | parent | prev | next [–]

From what vantage point?

nmrm on July 11, 2014 | root | parent | next [–]

I worked through SICP years ago and used scheme as my primary language for a couple of years. I write in an ML dialect at my day job.

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.

lispm on July 11, 2014 | root | parent | next [–]

The Lisp language syntax is not motivated by 'ease of parsing'. It is motivated by the 'code as data' idea, which enables a lot of useful source transformations to be implemented AND used in a relatively easy way. One of the applications of that are macros.

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.

nmrm on July 11, 2014 | root | parent | next [–]

Lisp's macros don't even get variable binding right. Treatment of bound variables was one of the explicit purposes for the development of lambda calculus in the first place. Imho if you get something as fundamental as this wrong, you don't get to play.

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.

lispm on July 11, 2014 | root | parent | next [–]

Given that macros 'don't get variable binding right', they are still amazingly useful.

> 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.

nmrm on July 11, 2014 | root | parent | next [–]

I mean, a really solid understanding of substitution is probably one of the major contributions of lambda calculus. For what's effectively an implementation to get that wrong is pretty pathological. And also, there's no reason to defend it. It's a bug. Period. Yet here we are.

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).

lispm on July 11, 2014 | root | parent | next [–]

> 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.

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.

nmrm on July 11, 2014 | root | parent | next [–]

Right, okay, so lisp is primarily a programming language for practical software development. That's really my whole point.

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.

Blackthorn on July 10, 2014 | root | parent | prev | next [–]

I'm not the above poster but I think the power of macros is way overhyped and not nearly as strong as people claim. I see the claim of "you can write a macro to do it" for any imaginable feature all the time, but it is simply not true.

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.

lispm on July 11, 2014 | root | parent | next [–]

> I see the claim of "you can write a macro to do it" for any imaginable feature all the time, but it is simply not true.

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.

Blackthorn on July 11, 2014 | root | parent | next [–]

You'll note that I never said it was not useful, but rather it was not this powerful magic sauce that can do anything.

> Which is not surprising. Actually nobody with a clue makes such a claim.

Most Lisp books make this claim.

lispm on July 11, 2014 | root | parent | next [–]

> Most Lisp books make this claim.

For sure not.

kazinator on July 11, 2014 | root | parent | prev | next [–]

That's right; macros need a target language to expand to, and that target language needs to seamlessly inter-operate with the surroundings and with the forms that are inserted into it. Some semantics is simply not available without transforming the entire program in which the macro call occurs.

Blackthorn on July 11, 2014 | root | parent | next [–]

Yes, exactly my point. Macros are very powerful but not a magic sauce that makes Common Lisp infinitely extendable. Some things you actually need to change the underlying implementation for.

terminus on July 10, 2014 | prev | next [–]

> It's like a never-ending stream of lies, every word being a little more absurd than the last...

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.

JasonFruit on July 10, 2014 | prev | next [–]

Could you enumerate the lies for us? Your comment is arresting but not enlightening without more information.

Tloewald on July 10, 2014 | parent | next [–]

I wouldn't say "lies" so much as overly optimistic opinions.

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.

ScottBurson on July 10, 2014 | root | parent | next [–]

The only thing that makes programs easy to deploy is the popularity of the language/environment they're written for. If the language you're using is popular enough that you can download the implementation using your system's package manager, deployment is easy. If not, it's harder.

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.

Tloewald on July 11, 2014 | root | parent | next [–]

The old joke with Common Lisp used to be if you've developed a program for one version of Common Lisp, you've developed a program for one version of Common Lisp.

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.

Blackthorn on July 10, 2014 | root | parent | prev | next [–]

This is only telling half the story. It is perfectly true for, say, Python (still a pain to deploy on Windows, or at least it was the last time I tried), but newer languages that are less popular like Go do not have this problem. Even Rust, a language that is only in alpha, does not have this problem!

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).

lispm on July 11, 2014 | root | parent | next [–]

If you want to create something that you can link into C program, there are several options:

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.

ScottBurson on July 10, 2014 | root | parent | prev | next [–]

Well, sure, if all your programs need is the OS and common libraries, deployment is easy.

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.

kazinator on July 10, 2014 | parent | prev | next [–]

I'm an Lisp programmer, so I can. The language ANSI Common Lisp certainly has its fair share of "syntactic cruft". For instance numerous "macro dispatch characters" like #'func #:sym #c(2.0 4.1) #(vec tor). None of the syntactic cruft requires a LR(1) algorithm to work out; most of it is based on recognizing a character or two of prefix material and dispatching a read function. When the dispatch involves two characters, the first one is almost always # (though for programming your own nonstandard read syntax, that is not a fixed rule.) Read syntax is not even considered "real" syntax by Lisp programmers; "real" syntax is the structure of macros. But since macro forms are unambiguously written as nested lists, they already express the phrase structure almost directly; there is no phrase structure that needs to be applied to get a syntax tree.

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).

mkautzm on July 10, 2014 | parent | prev | next [–]

Lisp is the hardly the simplest language. It has way less 'stuff' to learn, but that 'stuff' in imperative languages is generally useful abstractions that you don't to learn, but instead simply know of. By that measurement, x86 Assembly is really the simplest language of them all, but I don't think I need to explain why that's equally absurd.

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.

noblethrasher on July 10, 2014 | root | parent | next [–]

What you mean to say is that Lisp is simple but not easy, but that's true of a lot of things.

You might enjoy this: http://www.infoq.com/presentations/Simple-Made-Easy

nilved on July 10, 2014 | prev | next [–]

I think the sentence is poorly put together, but there aren't any lies. Clojure syntax is by far more simple (and thus easier to learn) than C-style languages or Python or Ruby. But the language is harder to jump into because it places particular emphasis on programming principles that are confusing to new programmers, like function purity, recursion and higher-order functions.

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.

jfarmer on July 10, 2014 | prev [–]

"simple" isn't the opposite of "hard," it's the opposite of "complex."