Live data from Hacker News

Why Racket? Why Lisp? (2014)

practicaltypography.com

131–140 of 168 posts

Re: Why Racket? Why Lisp? (2014)

#131

It's about a month since I've started seriously diving into lisp. The last couple of weeks I've spent my days reading 'The joy of Clojure', Structure and Interpretation of Computer programs, lots of tutorials and documentation, playing around in the repl + experimenting with all kinds of frameworks and libs in clojure (eg. Om). I've spent today implementing the brainfuck interpreter in Racket. I can't explain it, it'…

Every once in a while, I like to sit with a cup of hot tea or coffee, in my bathrobe, in read about Clojure. Algorithms, ideas, data structures - it's so .... just...clean and well thought out. There's something really nice about LISPs, and it's drawing me into it as well. I still do C#/Javascript/Java/whatever in my day job, but LISP is just...sexy. And for those that hate parens - Emacs paredit. Nuff said.

>parens

If you include the curly braces, I'm not sure C/C++ has fewer parens than Lisp does, to be honest. Not much fewer, anyways.

Re: Why Racket? Why Lisp? (2014)

#132
post #67

I have a feeling people tend to over estimate the importance of language choice. Might be just me though.

Think about this: What kind of code do you think people will be writing 10,000 years from now? What will they be able to do that you can't? What will they have that you don't?

One of the most useful things I've gleaned from pg's essays is learning to think like that.

"Will people still be doing X in the same way Y years from now?"

If not, what will make that change possible? What will drive it? How can you help it along? Is that a startup idea?

Re: Why Racket? Why Lisp? (2014)

#133

Earlier quoted context omitted.

Why do you expect things that really improve your life to come with sales pitches?

People are usually eager to recommend things that they feel really improved their life. If you, for example, read HN, you see "sales pitches" (in the broad sense) all the time.

Yes, that's true. But it's both naive, arrogant, and rude to require those "sales pitches" to be good. At the end of the day, it's up to you to decide what's better for you. If you try to outsource it, you'll discover that the best sales pitches around are for dead-end technologies.

At the other side of it, people giving you those recommendations really have no better way to explain it. PG has an well known essay about language power, but even that isn't very precise. Some kinds of knowledge you really have to know before you understand what they are good for.

Re: Why Racket? Why Lisp? (2014)

#134
post #47

It's about a month since I've started seriously diving into lisp. The last couple of weeks I've spent my days reading 'The joy of Clojure', Structure and Interpretation of Computer programs, lots of tutorials and documentation, playing around in the repl + experimenting with all kinds of frameworks and libs in clojure (eg. Om). I've spent today implementing the brainfuck interpreter in Racket. I can't explain it, it'…

It's not so sudden. HN itself is written in a LISP [1], and Paul Graham's pre-YC claim to fame was Viaweb, a store platform written in LISP that became Yahoo Stores. This community has been above-average LISP friendly for a long time. LISP's also has a long history of popping up all over the place because they are extremely implementation-friendly (if you want to write a simple language; if you want to make things fa…

> LISP's also has a long history of popping up all over the place because they are extremely implementation-friendly

This is a LIE.

I get tired of hearing this over and over. Broken Lisps are easy to implement.

Try implementing a real s-expression parser in C. I'll wait.

For example, this library: http://sexpr.sourceforge.net/ takes 5000+ lines of code. And it doesn't even handle dotted pairs! (For good reason, handling dotted pairs without recursion is extremely difficult.)

I have written entire languages in that number of lines. So, have many others.

Lisp does not count as small.

Re: Why Racket? Why Lisp? (2014)

#135
post #48

"Paul Graham’s programming language Arc, a dialect of Lisp, was built on top of Racket." Since that statement occurs in a section about Racket languages, I should probably clarify. Arc isn't technically a Racket language—that is, it doesn't use any of Racket's facilities for defining new languages. It compiles to Racket (and so you're all using it right now), but has its own distinct implementation. Historically, Arc…

This is Matthew Butterick. I wrote “Why Racket? Why Lisp?” As I allude there, Paul Graham’s writings about Lisp (mostly in Hackers & Painters) helped persuade me to explore Lisp languages. (Those writings have also persuaded many others.) In particular, Arc's reliance on Racket persuaded me to take a serious look at Racket. So leaving aside quibbles about what “on top of” means — is Clojure not built “on top of” the…

I couldn't agree more!

Re: Why Racket? Why Lisp? (2014)

#136
post #112
post #82

Earlier quoted context omitted.

>But never have I experienced this kind of mental strain/obsession as I do now with lisp. That's why it's so valuable as a right of passage. If you've spent your career writing simple iterative imperative loops, suddenly you're a newb again with map/filter/reduce this, partial that, and recursion and lambdas and closures and finally after your 20th time staring, dazed at 3 measly lines of nested composed recursion -…

Try typed functional languages next. You'll be a newbie again.

Indeed. The language that would eventually become Racket was my first true love, but my first encounters with the ML family were revelatory as well. I'm wondering, though, if I should go back to Racket again and see if there's anything new to learn there now that I'm older and more used to infix notation.

Knowing me, though, I'll probably just recklessly abuse hygienic macros until the sun burns out.

Re: Why Racket? Why Lisp? (2014)

#137

Why hasn't XML been matched to Lisp very much? I think it's because Lisp programmers recoil in horror from XML. I mean, if you're already used to S expressions, XML looks disgusting. As verbose as Java, and less expressive. So I think most Lisp programmers look at XML and think "Ugh, don't get any of that on me..."

Tho in its infancy, Kawa scheme can "paper over" some of the XML in Android dev[0].

[0] https://www.gnu.org/software/kawa/Android-view-construction....

Re: Why Racket? Why Lisp? (2014)

#138
post #112
post #82

Earlier quoted context omitted.

>But never have I experienced this kind of mental strain/obsession as I do now with lisp. That's why it's so valuable as a right of passage. If you've spent your career writing simple iterative imperative loops, suddenly you're a newb again with map/filter/reduce this, partial that, and recursion and lambdas and closures and finally after your 20th time staring, dazed at 3 measly lines of nested composed recursion -…

Try typed functional languages next. You'll be a newbie again.

Very true. I got into Racket three years ago and had an experience similar to the OP. Then I did some Clojure and I loved the data structures and destructuring, but I'm not too fond of the Java bits, although I understand the benefits. Now I'm learning Haskell, and it's another world again. I'm glad I took the route I did because the Haskell is coming a lot easier than it would have without the Racket/Clojure background.

Right now I'm converting some old Clojure code from a couple of years ago into Haskell, and I much prefer the Haskell static type checking to the dynamic typing of Clojure. I still have a lot more to learn to get my Haskell powers up to what I could do in Clojure, but I think it's worth the work.

Re: Why Racket? Why Lisp? (2014)

#139

I find all his digs at javascript funny since, at least the way I use it, javascript is basically an ugly-looking scheme. Javascript is responsible for my 'lisp enlightenment' with the language using first-class functions and closures, and the wide variety of precompilers. It strikes me as fashionable to hate on javascript. Java on the other hand, now that's a horrible language ;) ;)

I too am amused by his opinion of JavaScript. A professor was moved enough to translate most of SICP to JavaScript and writes in its first chapter, "Above beyond these considerations, programming in JavaScript is great fun" [1]. I agree, and I'm enjoying going through this SICP/JS moreso than the original, as I can write solutions to the exercises in any old browser JavaScript console and paste them into a gist for safekeeping.

[1] http://www.comp.nus.edu.sg/~cs1101s/sicp/

Re: Why Racket? Why Lisp? (2014)

#140
post #134
post #47

Earlier quoted context omitted.

It's not so sudden. HN itself is written in a LISP [1], and Paul Graham's pre-YC claim to fame was Viaweb, a store platform written in LISP that became Yahoo Stores. This community has been above-average LISP friendly for a long time. LISP's also has a long history of popping up all over the place because they are extremely implementation-friendly (if you want to write a simple language; if you want to make things fa…

> LISP's also has a long history of popping up all over the place because they are extremely implementation-friendly This is a LIE . I get tired of hearing this over and over. Broken Lisps are easy to implement. Try implementing a real s-expression parser in C. I'll wait. For example, this library: http://sexpr.sourceforge.net/ takes 5000+ lines of code. And it doesn't even handle dotted pairs! (For good reason, hand…

I'll be the first to agree with you that most 'minimal' lisp implementations are going to be missing important features (efficiency, memory management, ..), but is the parsing of s-exprs comparatively a difficult task?

At just a glance, it appears that the library is slurping the expression and avoiding recursion instead optimizing for speed, memory usage, and error reporting, but it seems like you could implement a recursive descent parser if you weren't as concerned with those. If the author took their same approach to parsing s-exprs for a grammar like C, I'm not sure how successful they would be.

I haven't really looked at grammars / compilers in a long time, but I'm curious if I'm off-base in thinking s-exprs are relatively easy to parse. Some grammars like brainfuck or assembly would obviously be easier.

Post reply on HN