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

31–40 of 58 posts

Re: Racket 7.3

#31

Post by nerdponx »

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…

A Racket language server would be great. I wonder if some DrRacket internals could be spun off.

Re: Racket 7.3

#32

Post by FraaJad »

lenkite wrote: post #20
rgrau wrote: post #16

Earlier quoted context omitted.

LambdaNative is a cross-platform development environment written in Scheme, supporting Android, iOS, BlackBerry 10, OS X, Linux, Windows, OpenBSD, NetBSD, FreeBSD and OpenWrt. http://www.lambdanative.org/

LambdaNative is a wrapper and abstraction over Gambit Scheme. It does not support multi-core threading.

but do all applications need multi-core threading? Languages like Python get around this using multiprocess module, which is not the same as "multi-core" threading, but it is probably good enough for a majority of applications.

REPL based development, Interactive development are also features. Multi-core isn't probably the top most thing on everybody's list of things.

Re: Racket 7.3

#33

Post by gus_massa »

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?

For the macros, I prefer to recommend to start with very straightforward macros that use `define-syntax-rule`. For example

  #lang racket
  
  (define-syntax-rule (run3times code ...)
    (begin
      (begin code ...)
      (begin code ...)
      (begin code ...)))
  
  (define x 0)
  
  (run3times
    (set! x (add1 x))
    (display x))      ; shows ==> 123
As other comment said, you have to find some good opportunity to use a simple macro.

(In this case, it is better to use the build-in `for`. Actually, `for` is defined in a macro, it is not part of the internal "secret" low level language.)

Once you are confident and you grok the difference between a macro and a function, you can try the other ways to define macros. These other ways are more flexible and can make weirder macros, and have better support when the macro is used wrongly. There are good links in the sibling comments.

Re: Racket 7.3

#34

Post by bananaoomarang »

lenkite wrote: post #23
rgrau wrote: post #22

Earlier quoted context omitted.

Well, that was my best shot :(. I'm sorry I don't have an answer then. You were asking for threads, and gambit has lightweight threads, so I assumed there was a way to use them via ln. Multi-core threading is a different story though.

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.

I know it's no Scheme, but Clojure seems to be doing OK (+ has solid multi core threading, REPL driven development, is a Lisp etc).

I guess at the end of the day it's very hard to compete with the JVM.

Re: Racket 7.3

#35

Post by bjourne »

chriswarbo wrote: post #27
bjourne wrote: post #21

Is typed racket still very slow? I'm interested in hearing how Racket's gradual typing works.

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

Re: Racket 7.3

#36

Post by velcrovan »

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.

Matthew is a contributor, doesn't mean he is the Jony Ive of every single web page they publish.

Re: Racket 7.3

#37

Post by dragonwriter »

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.

It's wrapped in 
 tags because it is preformatted text of the type that would be used in email, etc., announcements (probably becauae it's the exact text from those media, without transformation), so not using 
 would lose significant formatting.
Of course, the formatting is broken anyway, because two of the continuation lines of bullet-pointed lines are underindented by one space.

Re: Racket 7.3

#38

Post by ctas »

Munksgaard wrote: post #30
ctas wrote: post #28

Earlier quoted context omitted.

No they don't. AFAIK they moved away from Racket. I once contacted them for potential open positions I could list on racketjobs.com (I'm the creator).

Is the site down? I'm getting an empty page in Firefox currently.

Might be that non-www doesn't get redirected. Thanks for letting me know. Try this https://www.racketjobs.com.

Re: Racket 7.3

#39

Post by fiddlerwoaroof »

lenkite wrote: post #23
rgrau wrote: post #22

Earlier quoted context omitted.

Well, that was my best shot :(. I'm sorry I don't have an answer then. You were asking for threads, and gambit has lightweight threads, so I assumed there was a way to use them via ln. Multi-core threading is a different story though.

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

Re: Racket 7.3

#40

Post by maxiepoo »

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

Just to make it clear, the authors of that paper (including myself) are all to some extent Racket developers. Some big improvements have been made but there are still pathological cases. For the latest published on this see this paper: http://users.cs.northwestern.edu/~robby/pubs/papers/oopsla20...

But also it's important to note that it's not Typed Racket or Racket in isolation that are slow, but the inter-mingling of the two due to contract overhead.

Post reply on HN