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

Racket – Lisp beyond Clojure

slides.com

Post reply on HN
Print view View original

81–90 of 179 posts

Re: Racket – Lisp beyond Clojure

#81

Post by sgeisenh »

jnordwick wrote: post #66

Unhappy with the current state of functional programming. I know I should't be. I have a lot of options. I went to school at UC Berkeley. My first language was Scheme. Then Elisp. CLOS was in the first few too. I really didn't learn C or C++ until second semester. A few months ago I had to pick up enough Scala to figure out what some code did in a project and I wasn't really happy with the language. I realize it is m…

Have you tried learning an ML variant? SML and OCaml are great, and Haskell isn't too bad, either.

Re: Racket – Lisp beyond Clojure

#83

Post by jnordwick »

sgeisenh wrote: post #81
jnordwick wrote: post #66

Unhappy with the current state of functional programming. I know I should't be. I have a lot of options. I went to school at UC Berkeley. My first language was Scheme. Then Elisp. CLOS was in the first few too. I really didn't learn C or C++ until second semester. A few months ago I had to pick up enough Scala to figure out what some code did in a project and I wasn't really happy with the language. I realize it is m…

Have you tried learning an ML variant? SML and OCaml are great, and Haskell isn't too bad, either.

Yes. Years ago I learned OCaml (and I really didn't care for it. Seemed like a big mess of random stuff). I haven't touched it in years though. I used to learn a new language about every other year. My resume even used to be written in hand coded PostScript.

Re: Racket – Lisp beyond Clojure

#84

Post by tikhonj »

jnordwick wrote: post #66

Unhappy with the current state of functional programming. I know I should't be. I have a lot of options. I went to school at UC Berkeley. My first language was Scheme. Then Elisp. CLOS was in the first few too. I really didn't learn C or C++ until second semester. A few months ago I had to pick up enough Scala to figure out what some code did in a project and I wasn't really happy with the language. I realize it is m…

Haskell and OCaml are both great. I've had a fair amount of experience with both of them as well as Racket and, while I rather liked Racket, I would definitely order them Haskell > OCaml > Racket. (I did 61A in Scheme too, coincidentally.)

I'm using Haskell professionally now and, while there are still a few things I miss from Racket and even OCaml, Haskell delivers the best overall programming experience I've encountered.

Re: Racket – Lisp beyond Clojure

#85

Post by jnordwick »

DigitalJack wrote: post #78
jnordwick wrote: post #66

Unhappy with the current state of functional programming. I know I should't be. I have a lot of options. I went to school at UC Berkeley. My first language was Scheme. Then Elisp. CLOS was in the first few too. I really didn't learn C or C++ until second semester. A few months ago I had to pick up enough Scala to figure out what some code did in a project and I wasn't really happy with the language. I realize it is m…

I guess I don't understand what the big deal is with tail call optimization. Could someone give an example where it really shines and clojure's loop/recur just doesn't? If you are looking to put time into a programming language that is interesting in and of itself, I'd suggest Haskell.

Looping is fine for imperative languages. It should be the norm for performance sensitive things since that is how the CPU works. It is just easier than trying to make a smart compiler turn your recursion into looping constructions.

However, for functional languages you really want TCO to work properly so you can write your algorithms in a properly functional way. And you don't just want self-calls to work, but full mutual recursion (A calls B that calls A etc) to be properly optimized too.

Re: Racket – Lisp beyond Clojure

#86

Post by shakna »

dasmoth wrote: post #29

This is addressing a question I'm interested in, but on first read I'm struggling to see the value that's being presented here. - "parameterize" is great, but seems exactly the same as Clojure's "binding" on a dynamic variable. [Edit: modulo being "sticky" with regard to continuations... but Clojure doesn't have continuations, so it's a pretty subtle difference.] - Reader macros are an interesting feature, but do mov…

The place where I've found Racket to shine is the reader macros.

More specifically, a project can be broken up to be expressed in a way that makes sense, using what looks like, on the surface, multiple languages.

Most of what I have done in Racket used #lang racket for the core, and lazy or typed everywhere else.

Contracts and laziness made debugging a breeze.

Edit: My clumsy hand hit reply before I was done.

Re: Racket – Lisp beyond Clojure

#87

Post by thothamon »

jnordwick wrote: post #66

Unhappy with the current state of functional programming. I know I should't be. I have a lot of options. I went to school at UC Berkeley. My first language was Scheme. Then Elisp. CLOS was in the first few too. I really didn't learn C or C++ until second semester. A few months ago I had to pick up enough Scala to figure out what some code did in a project and I wasn't really happy with the language. I realize it is m…

Well, of course you're limiting yourself to lisps (except Scala, about which I share your dislikes). How about F#, which is a very practical functional language with good tooling on all platforms? Or Ocaml, or Haskell?

Re: Racket – Lisp beyond Clojure

#88

Post by lisper »

brandonbloom wrote: post #40
kd0amg wrote: post #28

Earlier quoted context omitted.

While reading someone else's program that uses a DSL may be superficially easy, but the minute you try to get under the surface, you're left scrambling to understand what a given term or idea meant to the author. There is no language definition to rely on for common understanding. I have generally found that this is the same problem as with user-defined functions, and it has the same solution: programmers need to doc…

Agreed. I have two follow up thoughts: 1. Badly designed functions can do less design damage per-function than badly designed languages per construct, but user-defined functions tend to have much higher volume than both language constructs and their usages. 2. Powerful techniques, including DSLs, lead to denser code. Denser code takes more time to read per unit of code. Total reading time may be either more or less,…

> Badly designed functions can do less design damage per-function than badly designed languages per construct

Really? When was the last time you successfully used a C library without reading the documentation?

Re: Racket – Lisp beyond Clojure

#90

Post by optforfon »

jnordwick wrote: post #85
DigitalJack wrote: post #78

Earlier quoted context omitted.

I guess I don't understand what the big deal is with tail call optimization. Could someone give an example where it really shines and clojure's loop/recur just doesn't? If you are looking to put time into a programming language that is interesting in and of itself, I'd suggest Haskell.

Looping is fine for imperative languages. It should be the norm for performance sensitive things since that is how the CPU works. It is just easier than trying to make a smart compiler turn your recursion into looping constructions. However, for functional languages you really want TCO to work properly so you can write your algorithms in a properly functional way. And you don't just want self-calls to work, but full…

the CPU is just doing a jump to an instruction at the end of each iteration.

When you do tail call recursion you are doing just that. The assembly jumps to a tag and in recursion you jump to a function name, which is also effectively a tag.

So it's not really about mapping better to the CPU instructions or anything like that

The added benefit is that with tail call recursion you can have mutually recursive function (function A calls function B at the end and function B calls function A at the end), which isn't possible with a simple iterative loop, so the functional style is actually more powerful than an iterative approach and still maps directly to "the way the CPU works"

Post reply on HN