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

51–60 of 168 posts

Re: Why Racket? Why Lisp? (2014)

#51

Post by dang »

yoanizer wrote: post #32

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

Many people agree with you but I have the opposite view. Of course you can write any program in any Turing complete language, but the programs people do write in a given language tend to have a family resemblance to one another. Therefore if we want different kinds of programs we should have different languages.

A given language makes certain ideas easier or harder to formulate, and thus easier or harder to have in the first place. So the language constrains not only how you think about your program, but what you think—and thus what the program itself becomes.

Platforms, communities, and culture also help determine these things, but they're not independent of the underlying language.

Re: Why Racket? Why Lisp? (2014)

#52

Post by mbrock »

innguest wrote: post #41
j2438 wrote: post #37

Earlier quoted context omitted.

Have not yet learned to use or appreciate macros. The idea of everyone having to come up with their own syntax for such commonly-needed things as, say, hashes, seems counter-productive to me. That would lead to everyone's code looking like a different language.

I never said "with lisp, everyone has to come up with their own syntax for commonly-needed things". But it sounds your mind is already made up by hypothetical prejudices. You said you stick with Clojure over Scheme on account of some syntax. I said you can have that syntax in Scheme. You then said the non-sequitur "the idea I created in my mind of each individual user coming up with their own syntax is absurd", which…

It might work better to tell your own story about using Racket. How do you work with data structure literals? Perhaps you've found that Racket's built in functions are good enough. In that case, maybe show an example demonstrating that fear is unwarranted.

Trying to please everyone—or convince everyone—is not a fruitful method of language advocacy.

Re: Why Racket? Why Lisp? (2014)

#53

Post by PopsiclePete »

codeshaman wrote: post #36

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.

Re: Why Racket? Why Lisp? (2014)

#54

Post by PopsiclePete »

How does Racket stack up against Clojure? I like some of the special extended reader support for data structures, I dig the immutability, some of the concurrency stuff....I don't think immutability/concurrency is that typical for LISPs...for people who've tried both, which one do you prefer?

Re: Why Racket? Why Lisp? (2014)

#55

Post by prabhasp »

Toenex wrote: post #35
j2438 wrote: post #18

I have so far stuck with Clojure instead of a Scheme primarily because of the nice literal syntax for maps, sets, vectors, and regexes that Clojure supports. I don't want to give that up and just use cons/car/cdr. And also, last time I looked at Racket, it seemed very focused on academics. I just wanted to write some simple Scheme in a .scm file and try it out (a script), but I think I had to choose a language first…

There are also some practical reasons to favour Clojure over Racket, specifically if you work in Java shop. The inertia to move to Clojure but remain on the JVM is going to be considerably lower than moving to whole new infrastructure as would be the case with Racket (indeed the language interoperability offered by the JVM was probably one reason why Scala gained such ground). However, even with Clojure I'm going to…

Also, Clojurescript.

Re: Why Racket? Why Lisp? (2014)

#56

Post by herdrick »

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…

I think it compiled to MzScheme first.

Re: Why Racket? Why Lisp? (2014)

#57

Post by pmelendez »

PopsiclePete wrote: post #54

How does Racket stack up against Clojure? I like some of the special extended reader support for data structures, I dig the immutability, some of the concurrency stuff....I don't think immutability/concurrency is that typical for LISPs...for people who've tried both, which one do you prefer?

I think people tend to use Clojure more because it has the Java VM and platform as support, which is a nice thing to have given its extension.

The .Net world has IronScheme which is very stable and interesting too.

Re: Why Racket? Why Lisp? (2014)

#58

Post by striking »

codeshaman wrote: post #36

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

Reminds me of this article: http://www.lambdassociates.org/blog/bipolar.htm

Re: Why Racket? Why Lisp? (2014)

#59

Post by mkozlows »

Scarbutt wrote: post #42

How production ready or mature are Racket libs for creating CRUD web services? skimming through the Racket website one can see Racket has the basics, a http server and a library for interacting with databases like postgresql, as someone relative new to programming/webdev, would I face to much "reinvent the wheel" versus Clojure or Javascript?

Depends what you're doing. It doesn't have the depth of libraries of the JVM or JS, so there'll be lots of "oh, can't use that technology" or "is this 3-year-old unmaintained library still going to work with Mongo?" moments.

Re: Why Racket? Why Lisp? (2014)

#60

Post by informatimago »

marijn wrote: post #15
adrianm wrote: post #12

Earlier quoted context omitted.

Indeed. Common Lisp is similar with regard to the proliferation of mutation.

It in fact takes it to amusing extremes, allowing you to mutate even the strings associated with symbols. (setf (char (symbol-name nil) 1) #\U) (Though I guess that could be taken as being the same thing as doing nonsensical pointer arithmetic in C -- you simply should know better.)

Actually, this expression is non-conforming: you must not try to modify the string returned by cl:symbol-name.

"non-conforming" means you will get different results in different implementation, perhaps something like a nasal dragon, or perhaps an error signaled, or perhaps some more benign behavior.

    $ clall -r '(progn (setf (char (symbol-name nil) 1) #\U) (quote nil))'
    CLISP                          Attempt to modify a read-only string: "NIL" 
    ECL                            Detected access to an invalid or protected memory address.
    Clozure Common Lisp            --> #|symbol not found in home package!!|#COMMON-LISP::NUL
    Armed Bear Common Lisp         --> COMMON-LISP::NUL
    CMU Common Lisp                --> COMMON-LISP::NUL
    SBCL                           --> COMMON-LISP::NUL
Some implementations will gladly and blissfully modify the symbol name, and your program will break because it cannot intern the original name anymore (not the best behavior for an implementation IMO); some implementation will detect the non-conforming access. Worse could have happened (remember, you are on the Internet so you can be located by geoip/gps/wifi, and missiles silos can be hacked by botnets).

But otherwise indeed in general, mutable lisp objects are mutable, and you can implement mutating algorithms as well as purely functional algorithm. Foremost, you can have an hybrid approach, using what's best to solve the current problem.

Post reply on HN