Live data from Hacker News

Why Racket? Why Lisp?

practicaltypography.com

271–280 of 295 posts

Re: Why Racket? Why Lisp?

#271

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

I think your explanation is excellent for getting the point across. All other nice things that we get in FP derive from the "mathematical functions" fact you stated. It's also good in the sense someone can then ask you "how is it that using mathematical functions transform the way you think" and now you have their attention and interest. :)

Re: Why Racket? Why Lisp?

#272

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…

Great post.

> It is accessible to those who are intently curious about theoretical aspects of software development, especially abstraction

Agreed. That's why I think it's disingenuous when people complain that Haskell folks are in an "ivory tower" or they think they're the elite. I just think they're more curious and that's why they learned it.

> And I don't like the attitude that because a group G doesn't understand it, and group H does, that H owes it to G to spoonfeed the information. That's not the case.

Exactly. I always think 'I should write this and that tutorial and then people will finally see why FP is so much easier and then perhaps...' but then immediately I think 'but I learned fine with the existing tutorials, why can't others?'.

The answer is, because most people don't care or aren't curious enough. The moment I learned of Lisp and Haskell and people gushing about it I knew I had to learn them just to see what the fuss is all about, and whether people are right in their praise. And they are right in their praise.

It takes time to learn but so does everything (for me, at least), but in the end you invariably get there, and it's more than worth it.

Re: Why Racket? Why Lisp?

#273
post #94
post #58

Earlier quoted context omitted.

> ... in a way that an imperative language could not Perhaps a nitpick, but sometimes nomenclature is important. Clojure (like all Lisps) is an imperative programming language. "Imperative" languages are contrasted with "declarative" languages[1]. Where does functional fit in and what is the name for "non-functional"? Well, that's not clear, as "functional" (in the PL sense) doesn't even have an agreed upon definitio…

Taken to the extreme like you are doing, no language could ever be considered "functional" because in the end, they all need to perform io and ordered execution to be of any use. Instead, the commonly understood meaning of the word "functional" is that the language's design emphasizes and encourages use of immutable data and Clojure fits that meaning.

"They all need to perform IO" - why does a programming language need to perform IO?

Haskell does not have a function that performs IO. For instance, `putStrLn "hello world"` returns an IO action, but it does not print anything to the screen.

In order to "perform IO" you have to name an IO action 'main'. Then the compiler understands that you want that action to take place in the Real World. But Haskell does not know about the Real World and so it cannot do IO.

This difference is important, otherwise there is a misunderstanding that Haskell is just "minimizing IO". It's not - there's no IO.

Re: Why Racket? Why Lisp?

#274

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…

A couple comments:

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

There are a couple reasons why I think this happens. The first is that people who use Lisp (or any other technology) will rightfully get excited about using it. Sometimes this translates into trying to evangelize it to other people, which is not a bad thing.

The second reason is that Lisp has a long history of 1) incubating major contributions to the field and 2) being continually marginalized by commercial practice. In many cases, this marginalization is warranted... there have been many good reasons not to use the language. In that kind of environment, it's easy to see enthusiastic users of Lisp getting a little defensive and writing apologetics about their tooling.

> What the hell is an X-pression?

He describes it, in some detail, directly in his post.

> Opportunities to participate. ... Nothing to do with Lisp again.

I do think this is an area where Lisp has unique advantages. Good Lisp systems tend to have good online documentation, good access to the underlying source code, and good interactive facilities for modifying a system.

Just as an illustration, I tend to think that Emacs couldn't really work as a closed source software package, and I don't think it would be nearly as powerful as it is with a different language than Emacs Lisp. (Eclipse is also open source, written in a very different language, and not nearly as easy to extend as Emacs.)

Re: Why Racket? Why Lisp?

#275

Earlier quoted context omitted.

It benefits both groups to to enlighten G. Since G is so much larger, that's how we would increase the library count from 2727 to 27280.

The best way to demonstrate it is to write interesting software, not to flounder on some abstract explanation about the greatness of G's favorite language.

The original author of the blog post _did_ write some interesting software in Lisp, used it to write a book, and then he wrote his blog post.

To me this is a good example of something languages have to have to make progress: users and evangelists/educators, with a large overlap between the two.

Re: Why Racket? Why Lisp?

#276
post #269

Earlier quoted context omitted.

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!

Thanks. So basically we get most of what Java has to offer plus thread mailboxes, which is nice. Not sure what to make of Places though - zeroMQ exists and has Racket bindings, is there something Places is better at?

Re: Why Racket? Why Lisp?

#277

Earlier quoted context omitted.

Technically, if a language can produce side effects, it's considered imperative. However, nobody really is going to say that Haskell is imperative.

The language called Haskell cannot produce side-effects. You see the side-effects when you execute a program. That is, you cannot create side-effects within the language (except for escape hatches for FFI purposes). This is different from other languages in that saying "what to print" is an actual command (hence, imperative) and not a value, as it is in Haskell (things that "will be commands when the program is run"…

> The language called Haskell cannot produce side-effects. You see the side-effects when you execute a program.

This is a rather meaningless distinction -- indeed, you can say the same thing about any other language on the planet. Programs written in C, Python, Ruby, ML, R, and Brainfuck only have side effects when you execute them. Obviously a C program just sitting on your hard drive unexecuted doesn't have any side effects.

Re: Why Racket? Why Lisp?

#278

Earlier quoted context omitted.

Good call on the diamonds. Echoing everyone else, basically, your other points are a bit shortsighted. You never need code that edits itself - completely true. Completely missing the point. Most programming features fall into this category; you don't -need- them, you could always use assembly instead. The point is that once you get them into your brain as an option, problems that might otherwise be tricky or time con…

hmm... c = sqrt(a*a + b*b) (setf c (sqrt (+ (* a a) (* b b))))

Amusing... but to be fair, this is also an operator precedence issue where C is letting you drop several pairs.

Re: Why Racket? Why Lisp?

#279

Earlier quoted context omitted.

The language called Haskell cannot produce side-effects. You see the side-effects when you execute a program. That is, you cannot create side-effects within the language (except for escape hatches for FFI purposes). This is different from other languages in that saying "what to print" is an actual command (hence, imperative) and not a value, as it is in Haskell (things that "will be commands when the program is run"…

> The language called Haskell cannot produce side-effects. You see the side-effects when you execute a program. This is a rather meaningless distinction -- indeed, you can say the same thing about any other language on the planet. Programs written in C, Python, Ruby, ML, R, and Brainfuck only have side effects when you execute them. Obviously a C program just sitting on your hard drive unexecuted doesn't have any sid…

No. It's a very meaningful distinction, actually.

Compare:

Ruby:

will_print = puts "hello world" # it already print to the screen! and will_print does not have any meaningful value -- indeed it's nil

Haskell (demonstrated on the repl, which runs inside the IO monad):

let willPrint = putStrLn "hello world" -- nothing gets printed!

willPrint -- now the string gets printed (only because the repl is inside the IO monad which promises to execute action values)

Haskell (not in the repl):

willPrint = putStrLn "hello world" -- nothing gets printed!

willPrint -- this returns the same that 'putStrLn "hello world"' returns - an action value that, when run inside the IO monad, will execute its actions - so this still doesn't print anything, and we can pass willPrint around without side-effects, and compose values with willPrint

main = willPrint -- now the compiler will make good on its promise to execute any action value that is named 'main', and "hello world" will be printed to the screen.

The point of this is that you cannot print inside the Haskell language (nor do any other side-effect) - when you try to print you get this "action value" thing that you as a programmer cannot execute. Only the compiler can. So you can pass Ruby's equivalent of "puts 'hello world'" around, which you can't in Ruby.

So the distinction is quite clear.

> Programs written in C, Python, Ruby, ML, R, and Brainfuck only have side effects when you execute them.

They clearly don't. That's why when I write in Ruby:

puts "hello world"

Then the next line of code will be executed in a world where 'hello world' has already been printed to the screen.

Likewise, when in Ruby I write:

a = 5

a += 1

Then the next line of code will be executed in a world where a is 6.

So every line of code you write depends on the side-effects that came before it. Therefore, Ruby and most other languages have side-effects before code is executed. This is not the case in Haskell. Hence, no side-effects.

Re: Why Racket? Why Lisp?

#280

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?

I ditch clojure because i wanted something with a more meta-language capabilities (syntax object + racket macro), it also as a llar parser and a lexer lib which i needed when i made the choice.

For the libraries you can checked out yourself at http://pkgs.racket-lang.org, for what i do i don't need one of the library.

For concurrency keep in mind that racket use green thread where clojure use jvm thread so OS thread in openjdk.

I don't what you want to do with clojure, but i think it is a best choice than racket. Clojure as a very opiniated way of how you should write a program and this view reflects in propably every clojure library. The documentation in clojure is lacking but it provide the implementation (on the web page) so the learning is imho faster especialy if you are new commer to functional programming. The other advantage is the leverage it get from the jvm in term of performance use of the java lib.

Post reply on HN