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

81–90 of 163 posts

Re: A Haskell Programmer Tries to Learn Racket

#81

Post by klibertp »

toolslive wrote: post #62

he will be amazed when he discovers custodians. http://docs.racket-lang.org/reference/eval-model.html#%28par...

There are many cool features that Racket has out of the box, like very nice module system, delimited continuations, objects and classes and of course macros (both hygienic define-syntax-rule, syntax-case and unhygienic defmacro) and more.

But if I had to show one feature of Racked to make someone amazed, it wouldn't be any of those. It would be a simple program composed of a couple of files, and every file would start with different #lang. Like #lang racket, #lang lazy, #lang typed/racket, #lang datalog.

It's sufficiently mind-blowing that there are this many languages on top of Racket, but the real "killer app" is how seamlessly they integrate with each other.

The next thing I'd show would probably be Danny Yoo tutorial on how you can create even more languages like this: http://hashcollision.org/brainfudge/

Re: A Haskell Programmer Tries to Learn Racket

#82

Post by lispm »

ANTSANTS wrote: post #51
Sean-Der wrote: post #45

Earlier quoted context omitted.

I come from a background using Common Lisp for system and web development so I may see things differently than people who were introduced to it academically. Your code looks great, mine just needed to compile :) The cons pair is a a really powerful primitive data structure, it is the linked list of Lisp. You can build a lot of powerful structures given this great base. I really don't it matters what architecture your…

I mean, it's neat that you can build everything out of cons, in the sense that it's neat that Turing machines and the lambda calculus can perform any computation, but that doesn't mean it's a good idea to so in your code, any more than encoding numbers with Church numerals. Why use alists when you can use hash tables, why use... weird SICP-style struct list things when you could just use structs/vectors, etc. >Hash T…

Named arguments are there to be interfaces to procedures. With hash-tables you know nothing about them. With named arguments, we can ask for argument lists, check for missing arguments, complete arguments, prompt for arguments, ... Much of that can be done in the IDE or at compile time.

Named arguments had been introduced to Lisp with MDL (a Lisp dialect, brought to Lisp Machine Lisp and then to Common Lisp).

Using hash-tables for it is a step back from the view of development support.

Re: A Haskell Programmer Tries to Learn Racket

#83

Post by artyomkazak »

nnq wrote: post #61

This sums up quite a lot about Lisps in general. I'm amazed OP got so fast to this "insight" :) (And this is probably Lisp's greatest weakness as well – with this level of possible diversity, everyone has to use the “common lowest denominator” simply because nobody can agree on what alternative syntax / library / etc. is better and should be used.) Off-topic: it's not enough to give everyone opportunity to improve th…

I think this was a cached thought – a year ago I was reading a bit about Lisp and probably had stumbled upon what is known as the Lisp Curse.

Re: A Haskell Programmer Tries to Learn Racket

#84

Post by lispm »

ANTSANTS wrote: post #77
ICWiener wrote: post #75

Earlier quoted context omitted.

> but a quick search didn't reveal a syntax for hash table literals, which I would consider to be a prerequisite for calling them first class citizens http://en.wikipedia.org/wiki/First-class_data_type Hash-tables are part of the standard, and available in conforming implementations out-of-the-box. (make-hash-table) produces an instance of a table which can be passed as argument to function, be assigned to variables,…

> http://en.wikipedia.org/wiki/First-class_data_type Fair enough, pretend I said "first class syntactic object." > CL allows you to define libraries that can change even the basic surface syntax, for your convenience. Considering that there is more than enough defined in the specification, what benefits would be in having an "official" hash litteral syntax? Reader macros are powerful, no doubt. The benefit of buildin…

Assoc lists make little sense as argument lists. Named arguments are basically like property lists. The point of argument lists for functions in Common Lisp is that they enable a contract. This requires special built-in support in the language. I want to see during compile time if an arg is missing or additional.

Example: the function WRITE takes several keyword arguments, but not :BAR. The compiler complains about wrong use.

    * (defun test () (write "foo" :bar 10))
    ; in: DEFUN TEST
    ;     (WRITE "foo" :BAR 10)
    ; 
    ; caught WARNING:
    ;   :BAR is not a known argument keyword.
Now if you allow a hashtable or some other data structure to be passed, then it would also be great, if one could specify at definition time which keys it takes, their default values, etc. We also may want to find out which values were default values, and which were actually passed.

The keyword argument facility for functions in Common Lisp provides all of that.

This allows you compile-time checks for code and makes interfaces easier to use.

Common Lisp also allows access to arguments as lists. This is simpler and more Lispy than using hash tables. For most purposes lists are useful enough and hash-tables would just add overhead.

Re: A Haskell Programmer Tries to Learn Racket

#85

Post by vitalique »

laichzeit0 wrote: post #71
vitalique wrote: post #65

Earlier quoted context omitted.

Could you please outline your final setup besides using Geiser? I also come from Vim-land, have almost zero experience with Emacs and already understood that, to learn SICP, setting up and learning Emacs is going to be easier than setting up Vim for the task.

Well, I'd suggest if you know nothing about Emacs to install Emacs Prelude: https://github.com/bbatsov/prelude Next, enable the lisp/scheme modules in prelude-modules.el [1]. You need the Evil plugin to get Vim modal editing and probably Evil Leader (so you get Vim style commands). You can look at my config [2], there's nothing really funny except I map Ctrl-H to backspace and Ctrl-[ to ESC as that's what I also use…

Wow, thank you very much for your suggestions and the .els! I guess now I'm really out of excuses not to start with SICP.

Re: A Haskell Programmer Tries to Learn Racket

#86

Post by ANTSANTS »

lispm wrote: post #82
ANTSANTS wrote: post #51

Earlier quoted context omitted.

I mean, it's neat that you can build everything out of cons, in the sense that it's neat that Turing machines and the lambda calculus can perform any computation, but that doesn't mean it's a good idea to so in your code, any more than encoding numbers with Church numerals. Why use alists when you can use hash tables, why use... weird SICP-style struct list things when you could just use structs/vectors, etc. >Hash T…

Named arguments are there to be interfaces to procedures. With hash-tables you know nothing about them. With named arguments, we can ask for argument lists, check for missing arguments, complete arguments, prompt for arguments, ... Much of that can be done in the IDE or at compile time. Named arguments had been introduced to Lisp with MDL (a Lisp dialect, brought to Lisp Machine Lisp and then to Common Lisp). Using h…

  ; CL keyword arg syntax, taken from Practical Common Lisp
  (defun foo (&key (a 0) (b 0)) (+ a b))
  (foo :a 1) -> 1
  (foo :a 1 :b 2) -> 3

  ; hypothetical table keyword arg syntax
  ; clojure defines commas to be whitespace, you can pretend they aren't there if you want
  (defun foo ({a: 0, b: 0}) (+ a b))
  (foo {a: 1}) -> 1
  (foo {a: 1, b: 2}) -> 3
I fail to see why the table syntax would be any less usable or introspectable by compilers or editors. They'd have the advantage (which would be shared with alists, if Common Lisp had used them for keyword args) of sharing the syntax for keyword args with a syntax for optional structure properties (think XML's attributes)

Re: A Haskell Programmer Tries to Learn Racket

#87

Post by oblio »

pavelludiq wrote: post #78
nnq wrote: post #61

This sums up quite a lot about Lisps in general. I'm amazed OP got so fast to this "insight" :) (And this is probably Lisp's greatest weakness as well – with this level of possible diversity, everyone has to use the “common lowest denominator” simply because nobody can agree on what alternative syntax / library / etc. is better and should be used.) Off-topic: it's not enough to give everyone opportunity to improve th…

As a lisper, I can say that this insight is very true, but it is still just a simplification. Most lisps deal with it in different ways. In the scheme world, the way they deal with this is by wasting a decade on making decisions about the language that should have been done in the 80s. The result is that scheme essentially split into scheme and racket. Now we have an awesome language and a nice little ecosystem thats…

At this point we can safely say that any programming language will be with us for many decades. Cobol (http://en.wikipedia.org/wiki/Cobol#COBOL_20XX), Fortran (http://en.wikipedia.org/wiki/Fortran#Fortran_2015), Basic (http://en.wikipedia.org/wiki/Visual_Basic_.NET#2013_.28VB_12...) are still evolving. Heck, Python is already 23 years old and I don't see it going anywhere. I'm not even going to talk about the ubiquitous C/C++ or Java, as they'll probably be around long after we're dead.

Adaption is neat, but I don't see this argument as being a very solid argument in favor of Lisp - it's just the norm.

Re: A Haskell Programmer Tries to Learn Racket

#88

Post by mbrock »

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?

Facebook's React lets you write DOM rendering code that can easily run on both client and server. The framework discourages DOM manipulation, instead promoting a near-declarative style of stateless rendering. Updates to the client DOM are then done by efficient tree diffing. It's very nice.

Re: A Haskell Programmer Tries to Learn Racket

#89

Post by PeterisP »

pavelludiq wrote: post #78
nnq wrote: post #61

This sums up quite a lot about Lisps in general. I'm amazed OP got so fast to this "insight" :) (And this is probably Lisp's greatest weakness as well – with this level of possible diversity, everyone has to use the “common lowest denominator” simply because nobody can agree on what alternative syntax / library / etc. is better and should be used.) Off-topic: it's not enough to give everyone opportunity to improve th…

As a lisper, I can say that this insight is very true, but it is still just a simplification. Most lisps deal with it in different ways. In the scheme world, the way they deal with this is by wasting a decade on making decisions about the language that should have been done in the 80s. The result is that scheme essentially split into scheme and racket. Now we have an awesome language and a nice little ecosystem thats…

To me, "almost completely compatible" sounds similar to "just a tiny bit pregnant". In practice, either it is compatible, or it isn't.

Re: A Haskell Programmer Tries to Learn Racket

#90

Post by tel »

lgas wrote: post #41
tel wrote: post #20

Earlier quoted context omitted.

1. There is a concrete advantage of shared code.

There are multiple concrete advantages. I've recently worked on a few web apps which use ClojureScript/Clojure on the the client/server. Prior to that I mostly worked on web apps that were CoffeeScript/Python. The first difference I took note of was how easy and seamless it was to move EDN structures back and forth between the client and the server. Of course this is a pretty minor difference as it's not exactly hard…

Technical nitpick: Schema does not implement a type system of any kind, but instead a contract system. Typed Clojure would be a type system.

Outside of that (+1) because yes, I completely agree.

Post reply on HN