Live data from Hacker News

Learn Lisp the Hard Way

learnlispthehardway.org

101–110 of 144 posts

Re: Learn Lisp the Hard Way

#101

Earlier quoted context omitted.

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 b…

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 res…

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.

Re: Learn Lisp the Hard Way

#102
post #72

Earlier quoted context omitted.

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…

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.

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

Re: Learn Lisp the Hard Way

#103
post #69

Earlier quoted context omitted.

That's not the issue. It's about whether you think that Lisp is the only objectively correct answer whenever the question arises "what language are we going to use for this?". Willful ignorance about other languages and their features is as much a cultural failure as, the hypothecial, unwillingness to learn about Lisp.

The point is that other languages added little to what Lisp already had to offer over half a century ago. Every language has its use, but really we ARE wasting time by splitting the worldwide community of programmers in different languages. Look at how most programmers love one language and advocate it's the best there is. That's called a split. Aren't we supposed to not reinvent the wheel?

This view only makes sense if you believe one language is enough. One language that has it all figured out, one language that is the right solution for any task.

Even if such a language existed (be it Lisp or not), which is unrealistic, there is still a second aspect to the whole thing: programmers' brains. Different languages map differently to different kinds of brains, and that's a very good reason to explore multiple concepts in itself.

The Split is the natural way to explore a large search space using different strategies. It happens all over nature, and it's the way human-powered research works as well. Monocultures don't perform nearly as well. Yes, there is some effort wasted, but you can rarely ever come to an objective consensus where this waste actually occurs - except, typically, in hindsight.

Also, there is quite a bit of cross-pollination of ideas happening among different environments and languages, so advantageous traits do get passed around beyond their initial ecosystem.

I imagine cross compilers and common runtimes will get more popular, too, now that we have the processing power - and that's also a good strategy do deduplicate effort.

The only thing that really strikes me as a bad strategy is militantly advocating one programming language as the master race. You're not even doing the "pure" in-community a favor by denying that concepts from the outside world might occasionally be useful. Instead members are reduced to armchair criticism along the line of "yeah, nice library, but you didn't write it in Lisp, so at the end of the day nothing at all was achieved."

Re: Learn Lisp the Hard Way

#104
post #96
post #83

I really hope Colin finishes this as I've always thought Lisp would be a better beginner language if there was a book like mine for it. You've either got "The Little Schemer" series, which is annoyingly written for little kids but close to the style, or you have giant academic tomes that only hard core geeks would bother reading. A "trainer" book like mine would definitely solve this gap. The intro is a little bit co…

http://landoflisp.com/ is a nicely informal book on learning lisp that is easy to get into. Pretty sure I've seen it highlighted here a few times.

I like Land of Lisp, and I own the ebook+paperback, but I don't think that it's well suited to beginning programmers. I think the "let's make a game" approach actually works better for programmers who are coming from a different language and trying to understand concept translations, rather than novel concepts themselves.

edit : I can't reply to you, but re-read what I said. I am making the point that I believe Land of Lisp to be for people coming from other languages, whereas I think that "learn X the hard way" is better for people new to programming altogether.

The parent of my reply is pointing out to zedshaw that "Land of Lisp" is a good beginners book. I am adding that it's my opinion that it's a good "beginner at lisp" book, and not an overall "good-for-beginner-programmers" book.

Re: Learn Lisp the Hard Way

#105
post #72

Earlier quoted context omitted.

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.

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.

Re: Learn Lisp the Hard Way

#106

"Lisp is, at its heart, a very mystical language, that blurs the line between programming and magic." I like lisp, but this kind of mystical gobbledeygook is not helpful. It's worth noticing that mystics and lisp-ninnies are alike in a very important way: promising much, and delivering little. The people who actually accomplish things in lisp (Yann LeCun, Richard Fateman) do not speak in this preposterous mouth foamy…

Yann leCun does not use Lush anymore.

Re: Learn Lisp the Hard Way

#107
Ok i started this. How long before I can condescend to the rest of you barbarian peons?

But seriously - i've been wanting to learn a lisp for a while now and this seems like an accessible way to go about it.

Re: Learn Lisp the Hard Way

#108
Wow. The response on here has been amazing---yes, the criticism too. I was really shocked last night with the spike in traffic from Reddit, but I had no idea what to make of getting to the front page of Hacker News. TBH, I'm feeling pretty overwhelmed about the whole thing.

Just to put my two cents in, as a general reply to a lot of comments here... this is a very, very early draft in progress, and I didn't expect anyone to pay attention to this project, let alone post it everywhere. It needs a lot of work, particularly in toning down the Lisp Evangelism, and staying true to the methodology without accidentally parroting Zed Shaw's voice.

Zed Shaw: it means a lot to me to get your perspective here. Yes, you and your series ultra-inspired me. I've wanted to write a book on Lisp for a long time, but it wasn't until I was pointed to your series that I felt like I could give Lisp the perspective it was missing. I'll make a point of editing the Preface more carefully---everything that's up there so far, I wrote off the top of my head with very little editing, so I guess in following your method and format I accidentally used some of your words as well.

Thanks everyone!

Re: Learn Lisp the Hard Way

#109
post #104
post #96

Earlier quoted context omitted.

http://landoflisp.com/ is a nicely informal book on learning lisp that is easy to get into. Pretty sure I've seen it highlighted here a few times.

I like Land of Lisp, and I own the ebook+paperback, but I don't think that it's well suited to beginning programmers. I think the "let's make a game" approach actually works better for programmers who are coming from a different language and trying to understand concept translations, rather than novel concepts themselves. edit : I can't reply to you, but re-read what I said. I am making the point that I believe Land…

Uh, the land of lisp has the let's make a game approach as well. I'm not sure I understand what aspect you're talking about.

Re: Learn Lisp the Hard Way

#110

Earlier quoted context omitted.

From what vantage point?

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 continua…

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.
Post reply on HN