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

A Haskell Programmer Tries to Learn Racket

artyom.me

Post reply on HN
Print view View original

31–40 of 163 posts

Re: A Haskell Programmer Tries to Learn Racket

#31

Post by minikomi »

pera wrote: post #19
MichaelGG wrote: post #11

Earlier quoted context omitted.

I keep flipping back and forth, thinking I don't get it, then thinking others don't get it. Single-threaded JS with callbacks. OK? What am I missing? The only thing Node has going for it is a lot of networking libraries. It's not fast, the async style leads to callback hell, JS is a terrible language, and their package management system is slow and bloated (or at least the packages are)[1]. Yet people think it's some…

V8 vs Racket: http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...

Not sure what you're saying with this? That they're fairly equivalent except when you need heavy regex jiggling?

Re: A Haskell Programmer Tries to Learn Racket

#32

Post by ludwigvan »

MichaelGG wrote: post #11
gaigepr wrote: post #3

"...but nothing beyond that. As long as Node.js exists in this world, I can't truly hate anything else." I found this hilarious. I am also rather underwhelmed (to be nice) with Nodejs and a little bothered at its wide adoption. I have also been learning racket recently; my formal language and functional programming class uses it. I had some previous experience with common lisp but the raw nature of scheme still pleas…

I keep flipping back and forth, thinking I don't get it, then thinking others don't get it. Single-threaded JS with callbacks. OK? What am I missing? The only thing Node has going for it is a lot of networking libraries. It's not fast, the async style leads to callback hell, JS is a terrible language, and their package management system is slow and bloated (or at least the packages are)[1]. Yet people think it's some…

Straight from the horse's mouth:

"Node is popular because it allows normal people to do high concurrency servers. It's not the fastest or leanest or even very well put together - but it makes good trade offs in terms of cognitive overhead, simplicity of implementation, and performance. I have a lot of problems with Node myself - but the single event loop per process is not one of them. I think that is a good programming model for app developers. I love Go so much (SO MUCH), but I cannot get past the fact that goroutines share memory or that it's statically typed. I love Erlang but I cannot get the past the syntax. I do not like the JVM because it takes too long to startup and has a bad history of XML files and IDE integration - which give me a bad vibe. Maybe you don't care about Erlang's syntax or static typing but this is probably because you're looking at it from the perspective of an engineer trying to find a good way to implement your website today. This is the source of our misunderstanding - I am not an app programmer arguing what the best platform to use for my website--I'm a systems person attempting to make programming better. Syntax and overall vibe are important to me. I want programming computers to be like coloring with crayons and playing with duplo blocks. If my job was keeping Twitter up, of course I'd using a robust technology like the JVM. Node's problem is that some of its users want to use it for everything? So what? I have no interest in educating people to be well-rounded pragmatic server engineers, that's Tim O'Reilly's job (or maybe it's your job?). I just want to make computers suck less. Node has a large number of newbie programmers. I'm proud of that; I want to make things that lots of people use. The future of server programming does not have parallel access to shared memory. I am not concerned about serialization overhead for message passing between threads because I do not think it's the bottleneck for real programs." https://news.ycombinator.com/item?id=4310723

Re: A Haskell Programmer Tries to Learn Racket

#33

Post by Sean-Der »

brudgers wrote: post #22

As others have said, this does justice to the idea of actually learning a new language...or perhaps because it is Racket a new family or ecosystem of languages. Anyway, if you're still curious about pairs verus lists and why anyone would use dotted pairs, I like to think about it as where Lisps show that they are from the age when running close to the metal was a given. And it all goes back to car and cdr and the fac…

In some cases it makes more sense to store things as an a-list.

A good example would be simple key->value pairs. When working with Hunchentoot it represents HTTP Headers and form POSTs as a-lists. It would be easier to use a hash table though.

Re: A Haskell Programmer Tries to Learn Racket

#34

Post by rdtsc »

MichaelGG wrote: post #11
gaigepr wrote: post #3

"...but nothing beyond that. As long as Node.js exists in this world, I can't truly hate anything else." I found this hilarious. I am also rather underwhelmed (to be nice) with Nodejs and a little bothered at its wide adoption. I have also been learning racket recently; my formal language and functional programming class uses it. I had some previous experience with common lisp but the raw nature of scheme still pleas…

I keep flipping back and forth, thinking I don't get it, then thinking others don't get it. Single-threaded JS with callbacks. OK? What am I missing? The only thing Node has going for it is a lot of networking libraries. It's not fast, the async style leads to callback hell, JS is a terrible language, and their package management system is slow and bloated (or at least the packages are)[1]. Yet people think it's some…

> I'm just confused as to why anyone is particularly impressed with Node or JS.

Low barrier to entry means anyone who used to animate jumping monkeys on webpages and now write distributed back-end systems (all web-scale of course).

Kids haven't seen anything else. Maybe took C++ or Java in college, then they see a kid with piercings and a messenger bag and tight pants talk about this awesome asynchronous callback-futures-based awesome frameworks. There is really nothing to compare it to. So they are impressed.

Next level up, write a benchmark. Compute fibonacci, compare with Java, hey not too bad. Even faster than Ruby! Clearly this is the framework of the future.

Maybe read some place about how threads are bad and callbacks are great. And so on.

> so you end up with 300-character deep paths.

Hehe, too funny. Actually it just needs to be 260 characters, so 'git checkout blows' up on your unfortunate colleague who happens to use Windows.

Re: A Haskell Programmer Tries to Learn Racket

#35

Post by rdtsc »

ludwigvan wrote: post #32
MichaelGG wrote: post #11

Earlier quoted context omitted.

I keep flipping back and forth, thinking I don't get it, then thinking others don't get it. Single-threaded JS with callbacks. OK? What am I missing? The only thing Node has going for it is a lot of networking libraries. It's not fast, the async style leads to callback hell, JS is a terrible language, and their package management system is slow and bloated (or at least the packages are)[1]. Yet people think it's some…

Straight from the horse's mouth: "Node is popular because it allows normal people to do high concurrency servers. It's not the fastest or leanest or even very well put together - but it makes good trade offs in terms of cognitive overhead, simplicity of implementation, and performance. I have a lot of problems with Node myself - but the single event loop per process is not one of them. I think that is a good programm…

> The future of server programming does not have parallel access to shared memory.

Yeah but it could be IO parallelism. There could be two instances of callback chains of sequence C1->C2->C3 started such that the the second starts before the first one finished. As in C1->C2 ran then C1 gets called again. If in those callbacks you update a data structure (a database record?), you now accessed that data in parallel. So you have to protect against that with some kind of a lock/mutex. Yeah context switching doesn't potentially happen at every assembly instruction, the granularity is much higher, but it is still there.

Re: A Haskell Programmer Tries to Learn Racket

#36

Post by ebiester »

vinceguidry wrote: post #29
tel wrote: post #20

Earlier quoted context omitted.

1. There is a concrete advantage of shared code.

How does one share server HTTP-serving code and client DOM-manipulating code?

There's a library called browserify that does it. It's not useful for direct DOM manipulation, but there are other libraries for which it is nice.

Re: A Haskell Programmer Tries to Learn Racket

#37

Post by brudgers »

Sean-Der wrote: post #33
brudgers wrote: post #22

As others have said, this does justice to the idea of actually learning a new language...or perhaps because it is Racket a new family or ecosystem of languages. Anyway, if you're still curious about pairs verus lists and why anyone would use dotted pairs, I like to think about it as where Lisps show that they are from the age when running close to the metal was a given. And it all goes back to car and cdr and the fac…

In some cases it makes more sense to store things as an a-list. A good example would be simple key->value pairs. When working with Hunchentoot it represents HTTP Headers and form POSTs as a-lists. It would be easier to use a hash table though.

I probably shouldn't have focused on data structures when talking about dotted pairs, but some days it's just hard to be a Lisp head...

     > (define (f g)
            ((car g)(cdr g)))

     > (define my-val (cons sqrt 4))

     > (f my-val) 
     4
...and go down the rabbit hole where code and data merge.

Re: A Haskell Programmer Tries to Learn Racket

#38

Post by zhemao »

Crito wrote: post #28
pera wrote: post #19

Earlier quoted context omitted.

V8 vs Racket: http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...

Yeah, but I've basically never seen anybody suggest that Racket is a great language for prod.

Naughty Dog has used Racket as a scripting language in several of their video games for the PS3.

Re: A Haskell Programmer Tries to Learn Racket

#39

Post by tel »

vinceguidry wrote: post #29
tel wrote: post #20

Earlier quoted context omitted.

1. There is a concrete advantage of shared code.

How does one share server HTTP-serving code and client DOM-manipulating code?

Most likely by abstracting both into business concerns which appear in the client (manipulation for implementing a UI) and the server (manipulation for persistence and client-to-client communication).

Re: A Haskell Programmer Tries to Learn Racket

#40

Post by tel »

brudgers wrote: post #37
Sean-Der wrote: post #33

Earlier quoted context omitted.

In some cases it makes more sense to store things as an a-list. A good example would be simple key->value pairs. When working with Hunchentoot it represents HTTP Headers and form POSTs as a-lists. It would be easier to use a hash table though.

I probably shouldn't have focused on data structures when talking about dotted pairs, but some days it's just hard to be a Lisp head... > (define (f g) ((car g)(cdr g))) > (define my-val (cons sqrt 4)) > (f my-val) 4 ...and go down the rabbit hole where code and data merge.

As another Haskeller...

    f :: (a -> b, a) -> b   -- a.k.a. `ap`
    f (a, b) = a b

    myVal :: (Double -> Double, Double)
    myVal = (sqrt, 4)

    > f myVal
    2 -- I hope
In other words, what's different about (a . b) and (a, b)? But then: why not (a, b, c)?
Post reply on HN