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

Racket 7.3

download.racket-lang.org

Post reply on HN
Print view View original

41–50 of 58 posts

Re: Racket 7.3

#41

Post by mruts »

bjourne wrote: post #35
chriswarbo wrote: post #27

Earlier quoted context omitted.

Typed racket isn't slow (as far as scripting languages go). Maybe you're thinking of Racket's "contract" system? AFAIK typed racket does type-checking during compilation (via raco); the resulting code is no slower than normal Racket, although I'm not sure if it's faster either. The contract system is different; it works on normal, untyped Racket code and performs checks at runtime; similar to using Python decorators…

I'm referring to Takikawa et al (2016), who reported performance 50-100 times worse performance numbers by mixing typed and untyped Racket code together. Actually 100 times slower execution. They used type annotations on the module level. Would be interesting to know if Racket developers have proven them wrong and if so, how. http://www.ccis.northeastern.edu/home/types/publications/gra...

Takikawa is a core racket dev, I believe.

Re: Racket 7.3

#43

Post by GeoffKnauth »

nerdponx wrote: post #2

And yet I'm still too stupid to understand the macro system. Oh well. I also didn't know there was a Chez version. Racket already has a native AOT compiler, right? What would the advantage be to run on Chez, faster or smaller compiled code?

Another way to learn about all this stuff from the experts themselves is Racket School: https://school.racket-lang.org/

Re: Racket 7.3

#44

Post by NikkiA »

pyb wrote: post #11
nerdponx wrote: post #2

And yet I'm still too stupid to understand the macro system. Oh well. I also didn't know there was a Chez version. Racket already has a native AOT compiler, right? What would the advantage be to run on Chez, faster or smaller compiled code?

A few people exist who are genuinely able to use Racket macros, but they all have a PhD in CS. As opposed to the larger group who think they understand them. I was once in that group, but now I've just given up.

Racket's macro transformers are about as easy as hygenic macros[0] get unfortunately, I can occasionally manage to make a er-macro-transformer based macro in chicken work how I want.

defmacro was a lot easier, but I understand the aversion to it, even if it was rare that it was/is a problem.

[0] syntax-rules based macros are cake, naturally, but they're also incredibly limited, although I have seen people implement massive complex OO systems using a sort of ad-hoc state machine built in pages upon pages of syntax-rules rules.

Re: Racket 7.3

#45

Post by chriswarbo »

bjourne wrote: post #35
chriswarbo wrote: post #27

Earlier quoted context omitted.

Typed racket isn't slow (as far as scripting languages go). Maybe you're thinking of Racket's "contract" system? AFAIK typed racket does type-checking during compilation (via raco); the resulting code is no slower than normal Racket, although I'm not sure if it's faster either. The contract system is different; it works on normal, untyped Racket code and performs checks at runtime; similar to using Python decorators…

I'm referring to Takikawa et al (2016), who reported performance 50-100 times worse performance numbers by mixing typed and untyped Racket code together. Actually 100 times slower execution. They used type annotations on the module level. Would be interesting to know if Racket developers have proven them wrong and if so, how. http://www.ccis.northeastern.edu/home/types/publications/gra...

Yes, that fits with my own experience. I've not used Typed Racket itself, but I've used contracts in untyped Racket. I found them so slow that I ended up using a macro which discarded them unless it was a run of the test suite.

Figure 3 in that paper is enlightening: the fully typed version takes 0.7x as long as the untyped version, so Typed Racket is slightly faster than normal Racket. Most of the partially-typed versions take 50x to 100x as long, as you say, showing that it is indeed the contracts that slow everything down.

Re: Racket 7.3

#46

Post by NikkiA »

fiddlerwoaroof wrote: post #39
lenkite wrote: post #23

Earlier quoted context omitted.

Yes, it's a bit of a pity that great functional languages like Scheme and even the veteran common LISP are loosing out to modern languages like Kotlin because of lack of support in these critical, functional areas. Especially when REPL based development is so amazingly productive.

Common Lisp has real threading with a standardized interface via Bordeaux-threads and, with some limitations runs on most of the desktop and mobile operating systems one would expect (the limitation being that most workflows have you write the GUIs in a different language and then call into CL, although EQL is an exception to this rule: https://www.cliki.net/EQL

Does EQL still depend on smoke like common-qt does? Because smoke is so deprecated now that I simply gave up trying to get it to build common-qt on a recent distro.

Re: Racket 7.3

#47

Post by [deleted] »

Veen wrote: post #19
stesch wrote: post #13

Font looks like shit in Firefox on macOS X.

For reasons I find difficult to understand, the text is between tags and uses a monospace font (Inconsolata). It is curious that a project that cites Matthew Butterick as a contributor should make such poor decisions about typography, especially when the rest of the documentation is above average in that area.

[deleted]

Re: Racket 7.3

#48

Post by fiddlerwoaroof »

NikkiA wrote: post #46
fiddlerwoaroof wrote: post #39

Earlier quoted context omitted.

Common Lisp has real threading with a standardized interface via Bordeaux-threads and, with some limitations runs on most of the desktop and mobile operating systems one would expect (the limitation being that most workflows have you write the GUIs in a different language and then call into CL, although EQL is an exception to this rule: https://www.cliki.net/EQL

Does EQL still depend on smoke like common-qt does? Because smoke is so deprecated now that I simply gave up trying to get it to build common-qt on a recent distro.

I don’t think so, it’s built on ECL, so the lisp is compiled to C and then linked to Qt. However, I’m not sure how all the details work.

Re: Racket 7.3

#49

Post by fiddlerwoaroof »

fiddlerwoaroof wrote: post #48
NikkiA wrote: post #46

Earlier quoted context omitted.

Does EQL still depend on smoke like common-qt does? Because smoke is so deprecated now that I simply gave up trying to get it to build common-qt on a recent distro.

I don’t think so, it’s built on ECL, so the lisp is compiled to C and then linked to Qt. However, I’m not sure how all the details work.

And, there’s a qt5 version.

Re: Racket 7.3

#50

Post by soegaard »

Veen wrote: post #17
Labo333 wrote: post #12

I am really excited by Racket. Unlike most minimalist LISP languages with a community of individual hackers who each have their own macros and packages, this one is battery included while still being the most flexible with the #lang header. Seriously, it comes with awesome data structures (actuelly more than Python). The only thing that prevents me from using it as much as Python or C++ is the lack of tools for major…

Emacs has a decent Racket mode with most of the functionality of DrRacket.

These days racket-mode for Emacs is more than decent!

Could wish for similar modes for SublimeText and VisualCode though.

Post reply on HN