Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Racket? Why Lisp? (2014)

practicaltypography.com

Post reply on HN
Print view View original

151–160 of 168 posts

Re: Why Racket? Why Lisp? (2014)

#151

Post by Johnny_Brahms »

leanthonyrn wrote: post #79
dang wrote: 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…

Good discussion of the advantages of Arc versus Racket. http://stackoverflow.com/questions/8555440/the-advantage-of-... "I wish they had implemented Arc as a Racket module language since then you could actually develop in DRracket, debug, and make executables."

Hmmm. The syntax stuff could easily be implemented using macros. I like using rackjure by Greg Hendershott:

http://www.greghendershott.com/rackjure/

Adding the if statements wouldn't be too much fuzz.

Re: Why Racket? Why Lisp? (2014)

#152

Post by bsder »

gjgggk3 wrote: post #142
bsder wrote: post #134

Earlier quoted context omitted.

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

There is nothing difficult about writing an s-expression parser. None of the plethora of Scheme interpreters out there get parsing wrong. Handling dotted pairs is rather trivial compared to, say, getting hygienic macros right. Or implementing call/cc. Quasiquote handling is not even that difficult.

> There is nothing difficult about writing an s-expression parser.

Really? Try it in C.

The Scheme interpreters do very limited dotted-pair parsing until they bootstrap into scheme. There is a good reason for this.

And this is before we even start dealing with things like circular references.

Re: Why Racket? Why Lisp? (2014)

#153

Post by Adlai »

waterhouse wrote: post #141
na85 wrote: post #130

Earlier quoted context omitted.

AFAIK the allcaps "LISP" fell out of favour in 1984 when Common Lisp was introduced, and only the original Lisp implementation and Mac Lisp used the allcaps name. Much like Fortran (no longer FORTRAN), the acronyms became proper names in their own right.

Someone pointed out that Common Lisp is case-insensitive by default, so really they have no grounds to object to the name LISP. ;-)

The CL reader by default[1] converts unescaped characters to uppercase, but only when parsing tokens. The CL printer by default[2] converts everything it prints to lowercase. CL people seem to adopt these conventions as well, although they have been known to :capitalize Lisp on occasion.

[1] http://l1sp.org/cl/2.2

[2] http://l1sp.org/cl/*print-case*

Re: Why Racket? Why Lisp? (2014)

#154

Post by davexunit »

technomancy wrote: post #147
davexunit wrote: post #115

Earlier quoted context omitted.

>commonly-needed things as, say, hashes Hash tables are commonly used in imperative programming, but they aren't needed so often in Scheme where we prefer to use a purely functional style. We usually use alists because they are persistent. When I reach for a mutable hash table, it's usually part of some imperative process where I start from an empty table. Depending on the Scheme you use, there could also be a persis…

Hash tables have nothing to do with imperative programming. It's just a coincidence that some MLs or Schemes don't include purely functional hash tables; Clojure and Racket both include have them.

I mentioned that Guile also has one, called a vhash. I guess my point is that special read syntax for them isn't that useful when you can use an alist and convert.

Re: Why Racket? Why Lisp? (2014)

#155

Post by technomancy »

davexunit wrote: post #154
technomancy wrote: post #147

Earlier quoted context omitted.

Hash tables have nothing to do with imperative programming. It's just a coincidence that some MLs or Schemes don't include purely functional hash tables; Clojure and Racket both include have them.

I mentioned that Guile also has one, called a vhash. I guess my point is that special read syntax for them isn't that useful when you can use an alist and convert.

Sounds like a bit of a turing tarpit if you ask me. Sure there are technically ways to work around the lack of read syntax (I mean, Java didn't have literal syntax for any non-array collections for ages) but that doesn't mean it's a good idea.

Re: Why Racket? Why Lisp? (2014)

#156

Post by _djhrtmn »

chipotle_coyote wrote: post #93
_djhrtmn wrote: post #22

Has anyone tried to use Butterick's Pollen and written about it? The idea of debugging your website with racket as you write markup and styles seemed really interesting alternative to what I do; write styles, refresh, and then refine the stylesheet by incrementally adding changes with the inspector and then copying them to my stylesheet.

I'm working on converting a fiction ebook to web-based with Pollen and may later launch a fiction magazine using it, although I'm undecided about that technology choice. I think Pollen's biggest strength is that you can reprogram its markup -- as its documentation puts it, you can attach behavior to tags. I haven't taken much advantage of that yet, but you can do things like create a "TOC" tag that builds a table of…

Thanks for the response. I might try converting some public domain text to Pollen sometime, any tips for getting around DrRacket's short comings besides separating racket and pollen source?

Re: Why Racket? Why Lisp? (2014)

#157

Post by samth »

ozten wrote: post #127
Scarbutt wrote: post #124

Earlier quoted context omitted.

Javascript isn't Scheme: http://journal.stuffwithstuff.com/2013/07/18/javascript-isnt... If Javascript were only an ugly looking scheme...

Sweet.js brings hygienic macros to JavaScript and follows directly from Scheme R5RS mechanisms AFAICT.

Actually, sweet.js is based almost entirely on various macro innovations developed in Racket (such as the Honu approach to macros in languages without parens).

Re: Why Racket? Why Lisp? (2014)

#158

Post by innguest »

technomancy wrote: post #147
davexunit wrote: post #115

Earlier quoted context omitted.

>commonly-needed things as, say, hashes Hash tables are commonly used in imperative programming, but they aren't needed so often in Scheme where we prefer to use a purely functional style. We usually use alists because they are persistent. When I reach for a mutable hash table, it's usually part of some imperative process where I start from an empty table. Depending on the Scheme you use, there could also be a persis…

Hash tables have nothing to do with imperative programming. It's just a coincidence that some MLs or Schemes don't include purely functional hash tables; Clojure and Racket both include have them.

This is wrong. There are no purely functional data structures analogous to hash tables in terms of performance. Hash tables are inherently stateful and cannot be implemented without state.

Re: Why Racket? Why Lisp? (2014)

#159

Post by lispm »

waterhouse wrote: post #141
na85 wrote: post #130

Earlier quoted context omitted.

AFAIK the allcaps "LISP" fell out of favour in 1984 when Common Lisp was introduced, and only the original Lisp implementation and Mac Lisp used the allcaps name. Much like Fortran (no longer FORTRAN), the acronyms became proper names in their own right.

Someone pointed out that Common Lisp is case-insensitive by default, so really they have no grounds to object to the name LISP. ;-)

    CL-USER 30 > (eq '|LISP| '|Lisp|)
    NIL
Common Lisp knows very well the difference between LISP and Lisp

Re: Why Racket? Why Lisp? (2014)

#160

Post by nickbauman »

jlarocco wrote: post #107
nickbauman wrote: post #9

I think the hardest thing for people to get for programming in Lisp is the immutability. Once you get over that hump, everything is downhill. From the outside, the parenthesis seem pedantic but it's completely superficial. You will stop noticing them in a few hours, if not days.

Lisp is not an immutable language. There's setf and setq for assigning; nconc, nsubst, and the destructive list operations; rplaca and rplacd; etc. It's easy to write Lisp that doesn't mutate (let), or use constructs that hide it (dolist, dotimes, etc.), but mutable data has been in Lisp since the beginning. That said, there are languages in the family that don't allows mutation, but they're a small minority.

Clojure isn't immutable either. It favors immutability, though, and has strong opinions directing the developer away from mutable state.
Post reply on HN