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

Racket Compiler and Runtime Status

blog.racket-lang.org

Post reply on HN
Print view View original

91–100 of 102 posts

Re: Racket Compiler and Runtime Status

#91

Post by jnxx »

flavio81 wrote: post #90
jnxx wrote: post #86

Earlier quoted context omitted.

It is a very multi-dimensional issue. While all these languages belong to the same family, they also take some time to learn, and each has its specific strengths. It is probably very helpful to think about what matters most to you, and pick what matches your needs best for the first language. Here some axes of distinction: 1. supported programming styles 2. support for concurrency 3. performance of generated code and…

> Clojure uses Leiningen which runs on top of Maven to automatically retrieve libraries, it works very well. In the same way, Common Lisp uses Quicklisp, which runs on top of ASDF to automatically retrieve and compile libraries. It works very well.

I generally agree.

One difference is that Quicklisp + ASDF often needs to be set up manually which can be a little bit more complicated (it is, however, contained in Debian as a package, for example).

Leiningen and Maven relay on version numbers for dependencies.

My understanding is that Quicklisp in practice uses a "rolling release" model similar to Arch Linux - you get a current distribution, where all packages are at their newest version, and if needed, one can also roll back to earlier versions of the whole distribution. That this works with elegance is related to one aspect of Common Lisp culture which is very, very different from, say, Python or Go: Common Lisp puts a lot of importance on backward compatibility and stable APIs, it is possibly the most backward-compatible of all dynamic languages.

Further, while Leiningen is a de facto standard which makes working with Clojure libraries essentially frictionles, Quicklist is just one modern way of multiple ways to include Common Lisp libraries.

This difference is owed to the trait that Common Lisp is much more an open system (which I consider a good thing), while Clojure is more uniform and "managed".

Re: Racket Compiler and Runtime Status

#92

Post by kazinator »

gypsyharlot wrote: post #8

I am interested in LISP-type languages, but I have a serious case of decision paralysis. GNU Guile? Common Lisp? Clojure (JVM)? Racket? Judging by my understanding of the difference between Common Lisp and Scheme, I think I am more of a Scheme type (I prefer C over C++, I like Go more than Java, etc).

Though people use Clojure for real work (just like PHP, Perl, Bash or Fortran), it has a narrow ideological focus which is radically different from the multi-paradigm nature of historic Lisps. It can be described as a domain-specific language for processing several kinds of immutable data structures as generic sequences, with Lisp-like syntax and meta-programming. You may learn something about Lisp from Clojure, but the big picture is missing; Clojure is "its own thing", mostly disconnected from the Lisp history, culture and practices. Clojure expertise will not transfer well to Lisp and vice versa.

Re: Racket Compiler and Runtime Status

#93

Post by kazinator »

yw3410 wrote: post #10
gypsyharlot wrote: post #8

I am interested in LISP-type languages, but I have a serious case of decision paralysis. GNU Guile? Common Lisp? Clojure (JVM)? Racket? Judging by my understanding of the difference between Common Lisp and Scheme, I think I am more of a Scheme type (I prefer C over C++, I like Go more than Java, etc).

If you want live image reloading stick to a Lisp like SBCL rather than Scheme. If you care about startup times or FFI then don't pick Clojure. YMMV between Racket and Guile; I would say Racket is better insofar as the culture of documentation is really very good. In practice, once you learn a Lisp, you can jump between them without too much trouble.

If you learn Clojure, you will not jump into Lisp without too much trouble.

Re: Racket Compiler and Runtime Status

#94

Post by fulafel »

yw3410 wrote: post #10
gypsyharlot wrote: post #8

I am interested in LISP-type languages, but I have a serious case of decision paralysis. GNU Guile? Common Lisp? Clojure (JVM)? Racket? Judging by my understanding of the difference between Common Lisp and Scheme, I think I am more of a Scheme type (I prefer C over C++, I like Go more than Java, etc).

If you want live image reloading stick to a Lisp like SBCL rather than Scheme. If you care about startup times or FFI then don't pick Clojure. YMMV between Racket and Guile; I would say Racket is better insofar as the culture of documentation is really very good. In practice, once you learn a Lisp, you can jump between them without too much trouble.

You can have FFI and fast startup times on Clojure and ClojureScript.

Re: Racket Compiler and Runtime Status

#95

Post by yw3410 »

jnxx wrote: post #86
gypsyharlot wrote: post #8

I am interested in LISP-type languages, but I have a serious case of decision paralysis. GNU Guile? Common Lisp? Clojure (JVM)? Racket? Judging by my understanding of the difference between Common Lisp and Scheme, I think I am more of a Scheme type (I prefer C over C++, I like Go more than Java, etc).

It is a very multi-dimensional issue. While all these languages belong to the same family, they also take some time to learn, and each has its specific strengths. It is probably very helpful to think about what matters most to you, and pick what matches your needs best for the first language. Here some axes of distinction: 1. supported programming styles 2. support for concurrency 3. performance of generated code and…

This is a very good post; kudos for writing it up.

Another thing which may be nice to talk about is where the communities are for each language (Racket on Slack and the mailing lists, Common Lisp has an irc...).

Re: Racket Compiler and Runtime Status

#96

Post by bjoli »

iainctduncan wrote: post #89
jnxx wrote: post #86

Earlier quoted context omitted.

It is a very multi-dimensional issue. While all these languages belong to the same family, they also take some time to learn, and each has its specific strengths. It is probably very helpful to think about what matters most to you, and pick what matches your needs best for the first language. Here some axes of distinction: 1. supported programming styles 2. support for concurrency 3. performance of generated code and…

This is very good, I agree with almost everything. I would add the following: Guile and S7 are great for embedding in C programs. S7 is similar to Guile but permissively licensed. Gambit and Chicken compile down to C if you want to work that way. Gambit is very fast, Chicken is extremely well documented and beginner friendly. Clojure has by far the best books out for enterprise development and web dev if you want to…

S7 is similar to guile 1.8, which was an interpreter written in C. Now guile has a pretty nice VM, a bytecode compiler, a JIT and is written in a lot more scheme.

Re: Racket Compiler and Runtime Status

#97

Post by jnxx »

kazinator wrote: post #93
yw3410 wrote: post #10

Earlier quoted context omitted.

If you want live image reloading stick to a Lisp like SBCL rather than Scheme. If you care about startup times or FFI then don't pick Clojure. YMMV between Racket and Guile; I would say Racket is better insofar as the culture of documentation is really very good. In practice, once you learn a Lisp, you can jump between them without too much trouble.

If you learn Clojure, you will not jump into Lisp without too much trouble.

I would love to learn more why you think this - I am sure you have good reasons!

Isn't Clojure in some significant aspects similar to Schemes?

Re: Racket Compiler and Runtime Status

#98

Post by jnxx »

bjoli wrote: post #62
sevensor wrote: post #43

I have a slow-moving side project in Racket. I picked it up for its reputation for being the Python of the Scheme world, but I think the analogy doesn't hold up and you're better off accepting Racket on its own terms. Racket doesn't have the standard library of Python, nor does it have the syntax, nor would you structure a program in the same way. Indeed, I think the idea of bringing a more Python-like syntax to Rack…

Anyone writing scheme/racket like python is in for a bad time. I think languages either tend towards mutability or immutability. In clojure for example there is much emphasis on parallelism, which reflects itself in its choices of immutable data structures and atomic updates. In scheme, despite not being traditionally multithreaded as a standard, any computation can always be returned to several times due to call/cc.…

> I think languages either tend towards mutability or immutability. In Clojure for example there is much emphasis on parallelism, which reflects itself in its choices of immutable data structures and atomic updates.

Clojure with its focus on immutability and its purely functional data structures makes it much easier to write correct parallel and concurrent programs.

However, there is a subtle point: One typically wants concurrency and parallelism for one of three objectives:

1. Concurrency in servers

2. Graphical user interfaces

3. exploiting multiple cores for complex parallel computations, like number crunching

It turns out that Clojure is great for the first application, and that it works very nicely for the second one (once you bind a GUI written in, say, Swing, to Clojures promises and actors).

However it is not that great for the third area of interest. The reason is performance. For example, sequences in Clojure are always lazy, and floating point numbers passed in function arguments are often boxed. Also, it is not possible to pass even small objects by value. These things put a lot of pressure on the garbage collector.

And the result of that is that a single-threaded program which does things like massive number crunching written in Common Lisp will be faster than a parallel program written in Clojure.

This is a drawback which is rooted by the implementation.

But I still think that immutability in-the-large is the right way to go. Common Lisp libraries and Schemes are already adopting purely functional data structures, and I think this principle will become more important in the future and their possible offspring.

Re: Racket Compiler and Runtime Status

#99

Post by jnxx »

kazinator wrote: post #92
gypsyharlot wrote: post #8

I am interested in LISP-type languages, but I have a serious case of decision paralysis. GNU Guile? Common Lisp? Clojure (JVM)? Racket? Judging by my understanding of the difference between Common Lisp and Scheme, I think I am more of a Scheme type (I prefer C over C++, I like Go more than Java, etc).

Though people use Clojure for real work (just like PHP, Perl, Bash or Fortran), it has a narrow ideological focus which is radically different from the multi-paradigm nature of historic Lisps. It can be described as a domain-specific language for processing several kinds of immutable data structures as generic sequences, with Lisp-like syntax and meta-programming. You may learn something about Lisp from Clojure, but…

Clojure with its focus on immutability and its purely functional data structures makes it much easier to write correct concurrent programs.

It is clearly geared to servers, for example sequences are always lazy. This is not always the best thing but for servers, it seems in general better.

However, there is a subtle point about parallelism: One typically wants concurrency and parallelism for one of three objectives:

1. Concurrency in servers

2. Graphical user interfaces

3. exploiting many cores for complex parallel computations, like number crunching

It turns out that Clojure is great for the first application. It also works for the second one.

However it is not that great for the third area of interest. The reason is performance. For example, floating point numbers passed in function arguments are often boxed. Also, due to the JVM it is not possible to pass even small objects by value. These things put a lot of pressure on the garbage collector, even if the Clojure compiler partially tries to work around this.

And the result of that is that a single-threaded program which does things like massive number crunching written in Common Lisp will be faster than a parallel program written in Clojure.

But I still think that immutability in-the-large is the right way to go.

Re: Racket Compiler and Runtime Status

#100

Post by SnTJoy »

jnxx wrote: post #86
gypsyharlot wrote: post #8

I am interested in LISP-type languages, but I have a serious case of decision paralysis. GNU Guile? Common Lisp? Clojure (JVM)? Racket? Judging by my understanding of the difference between Common Lisp and Scheme, I think I am more of a Scheme type (I prefer C over C++, I like Go more than Java, etc).

It is a very multi-dimensional issue. While all these languages belong to the same family, they also take some time to learn, and each has its specific strengths. It is probably very helpful to think about what matters most to you, and pick what matches your needs best for the first language. Here some axes of distinction: 1. supported programming styles 2. support for concurrency 3. performance of generated code and…

Nice article. I think using Racket shoud be avoided because of its problematic community. I've had disgusting experiences interacting with people from Racket community in the past, but so far I thought I was the only one. Unfortunately, it doesn't seem that way. Recently, a computer Scientist Leandro Facchinetti described in his video his ugly experiences with top people in Racket community. The experience was such that he completely gave up his PHD and the use of Racket forever. You can view the video here: https://www.youtube.com/watch?v=_wY7FBtr7_c In the video Leandro Facchinetti says: Speaking of people, it's very sad that I had same bad experiences with some people in the Racket community, especially the people up top because they are the kind of people who are smart and they know about it and they will not lose a chance to tell you. I'll give you some examples: I was at the Racket conference having dinner with one of the creators of the language and some other attendees and the creator of the language had some very good points about higher education and how it is kind of a scam in the U.S. but to prove his point he decided some questions to the waiter that were kind of uncomfortable and everyone at the table kind of cringed. Of course, the waiter was gratious about it but still...

As another example, I was talking to another one of the creators of the language and he called one of my collaborators a doofus and the educators at my university, which used to be John Hopkins University, a bunch of donkeys. I understand that he had some points to make about how educators work but this is not the way you make them, right?

It comes to a point that when I was talking to the students of these people, they're kind of afraid of talking to their advisors and I must admit that spending time with these people is one of the reasons why I decided to drop out of the PHD and leave academia all together, because if that's how it looks like to be successful in these communities I think I prefer to try to be successful somewhere else.

Post reply on HN