Live data from Hacker News

Why Racket? Why Lisp?

practicaltypography.com

261–270 of 295 posts

Re: Why Racket? Why Lisp?

#261

I dislike this notion that Lisp (or Haskell or OCaml or ...) owe it to everyone else to explain and enunciate why it can be more productive to use Lisp. """ That’s ask­ing too much. If Lisp lan­guages are so great, then it should be pos­si­ble to sum­ma­rize their ben­e­fits in con­cise, prac­ti­cal terms. If Lisp ad­vo­cates refuse to do this, then we shouldn’t be sur­prised when these lan­guages re­main stuck near…

> Lisp doesn't really have [efficient persistent data structures]

It does now: http://www.ergy.com/FSet.html

Re: Why Racket? Why Lisp?

#262

Earlier quoted context omitted.

Type systems are the one exception, but it still remains broadly true that Lisp was way ahead of everybody. There are many things we could talk about besides type systems: Lambda expressions - just now reaching Java and C++, been in Lisp forever Garbage collection – (obviously) Turing-complete (edit: fully evaluating) macro systems – I've heard C++ is moving in this direction (not sure to be honest) but Lisp is still…

A couple of quibbles with your list: > Multiple inheritance – I think this is coming to Java finally But it's been in C++ for a very long time. > Functional programming techniques (map, reduce, etc.) – Still ahead Still ahead of who? Haskell? How so?

Multiple inheritance is much more complicated and restricted in C++ than in Common Lisp. As with many things in C++, you really have to know what you're doing to use it correctly. In CLOS it pretty much just does what you expect, and only when you want to do something unusual do you have to learn the finer points.

Re: Why Racket? Why Lisp?

#263
post #127
post #108

Earlier quoted context omitted.

Sure, but is there a one-stop framework that lets you write a CRUD web application as fast as you can with Rails? Was there such a thing in the '90s?

Framework: Caveman2[0] or Ningle[1], which run on Clack[2] (like Rack/WSGI), which supports five backend servers. Templates: Djula[3], closure-template[4]. ORM: Crane[5], Postmodern[6]. [0] https://github.com/fukamachi/caveman [1] https://github.com/fukamachi/ningle [2] https://github.com/fukamachi/clack [3] https://github.com/mmontone/djula [4] https://github.com/archimag/cl-closure-template [5] https://github.com/e…

Don't forget Weblocks[0]! The learning curve is imposing, but once you climb it, it's a very productive environment to work in.

[0] http://weblocks-framework.info/

Re: Why Racket? Why Lisp?

#264
post #114
post #35

Earlier quoted context omitted.

That is also a sore point from the Lisp community in regard to Clojure. Clojure devs are willing to compromise a bit to allow a good integration within the JVM and other implementations, thus allowing some shops to buy into Clojure. Whereas many in the Common Lisp community will not, no matter what.

>Whereas many in the Common Lisp community will not, no matter what. Common Lisp on the JVM: http://abcl.org/ Common Lisp/Java bridge: http://foil.sourceforge.net/

Usually the arguments I see being tossed around is Clojure's deviation of using [] and {} besides ().

Also the direct use of Javas API instead of more Lispy ones everywhere.

Re: Why Racket? Why Lisp?

#265

It seems most people here have never used (and not tried) racket. I decided to use racket for my little sides projects, as replacement for scala and clojure. I choose it because it was clear for me i can't stand limitations other language impose to me in way of style and boilerplate, the racket macro (aka syntax transformer) system is the most advanced i know to reduce the boilerplate to a minimum and so just write w…

Ah, someone with Clojure experience. I wanted Clojure to be my next language to learn, so now I'm curious why you ditched it in favor of Racket?

Especially:

- Whats the concurrency story for Racket?

- If I wanted to code my REST endpoints in Racket, are there competitive libraries available?

Re: Why Racket? Why Lisp?

#266

Some practical features I enjoy in CL: 1. Conditions and restarts : As far as error handling in programs go this is the most rock-solid system I've encountered. You can tell the system which bits of code, called restarts, are able to handle a given error condition in your code. The nice thing about that is you can choose the appropriate restart based on what you know at a higher-level in the program and continue that…

"CLOS allows me to dispatch based on the types of all of the arguments." But can it dispatch based on the return value?

Given that you can define your own custom method dispatch mechanisms in CLOS I'm pretty sure you could do something like this - you'd have to define the return type of each method somehow (can you use ftype with CLOS methods?) and have a way of specifying the return type you want back - but none of that sounds hugely difficult.

Mind you - its 20 years since I was paid to write Lisp/CLOS so take this with a grain of salt :-)

Re: Why Racket? Why Lisp?

#267

It seems most people here have never used (and not tried) racket. I decided to use racket for my little sides projects, as replacement for scala and clojure. I choose it because it was clear for me i can't stand limitations other language impose to me in way of style and boilerplate, the racket macro (aka syntax transformer) system is the most advanced i know to reduce the boilerplate to a minimum and so just write w…

Ah, someone with Clojure experience. I wanted Clojure to be my next language to learn, so now I'm curious why you ditched it in favor of Racket? Especially: - Whats the concurrency story for Racket? - If I wanted to code my REST endpoints in Racket, are there competitive libraries available?

Regarding the Racket concurrency story, it has places; http://docs.racket-lang.org/reference/places.html.

"A place is a parallel task that is effectively a separate instance of the Racket virtual machine. Places communicate through place channels, which are endpoints for a two-way buffered communication."

So places are somewhat like Erlang processes.

Distributed Places are also interesting: http://docs.racket-lang.org/distributed-places/index.html

Re: Why Racket? Why Lisp?

#268
I am learning Perl's FP features and really liking it, and teaching myself common lisp. I enjoyed the article quite a lot actually.

I find it is very hard to define functional programming for many people but this is what I have come to explain to people:

Functional programming means thinking in terms of mathematical functions in the f(x) sense. Once you get that basic promise, that for any given input you have a single correct output, then it transforms the whole way you think about and designing your software.

The better I get with lisp, the more everything else changes. I may have to try Racket.

Re: Why Racket? Why Lisp?

#269

Earlier quoted context omitted.

Ah, someone with Clojure experience. I wanted Clojure to be my next language to learn, so now I'm curious why you ditched it in favor of Racket? Especially: - Whats the concurrency story for Racket? - If I wanted to code my REST endpoints in Racket, are there competitive libraries available?

Regarding the Racket concurrency story, it has places; http://docs.racket-lang.org/reference/places.html . "A place is a parallel task that is effectively a separate instance of the Racket virtual machine. Places communicate through place channels, which are endpoints for a two-way buffered communication." So places are somewhat like Erlang processes. Distributed Places are also interesting: http://docs.racket-lang.o…

Places are about parallelism. For concurrency specifically, the most interesting features are threads, channels, and futures and can all be found here: http://docs.racket-lang.org/reference/concurrency.html

Distributed places is pretty cool, however!

Re: Why Racket? Why Lisp?

#270

I dislike this notion that Lisp (or Haskell or OCaml or ...) owe it to everyone else to explain and enunciate why it can be more productive to use Lisp. """ That’s ask­ing too much. If Lisp lan­guages are so great, then it should be pos­si­ble to sum­ma­rize their ben­e­fits in con­cise, prac­ti­cal terms. If Lisp ad­vo­cates refuse to do this, then we shouldn’t be sur­prised when these lan­guages re­main stuck near…

On the syntax transformation side....

I have started to get really into what you can do with closures and coderefs in Perl. It isn't a macro in the lisp sense but it really works well and you can do some incredible things with it, and with closures and lexically scoped variables....

I suppose I should probably at some point blog about it.

I think a big part of the problem is that these are not tools you had to a beginner. They are things which take a lot of time to really master.

Post reply on HN