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

Why learn Racket? A student's perspective

micahcantor.com

Post reply on HN
Print view View original

31–40 of 55 posts

Re: Why learn Racket? A student's perspective

#31

Post by srcreigh »

xhevahir wrote: post #20
srcreigh wrote: post #8

The point about simple evaluation models, while true for basic Racket, is actually the furthest from the truth in idiomatic Racket. The idiomatic way to solve a problem in Racket is to develop new syntax (and evaluation orders) which are suited to the problem. In fact, Racket has pythonic list comprehension syntax too: (for/list ([x '(2 4 8)]) (sqr x)) It also has lazy evaluation langs, static typecheck pre-eval step…

You're a lot more pessimistic here than in your blog post!

Not really. I'm just saying the same stuff in a different #lang-- I mean in different words :p

Re: Why learn Racket? A student's perspective

#32

Post by mumblemumble »

neilv wrote: post #17
srcreigh wrote: post #8

The point about simple evaluation models, while true for basic Racket, is actually the furthest from the truth in idiomatic Racket. The idiomatic way to solve a problem in Racket is to develop new syntax (and evaluation orders) which are suited to the problem. In fact, Racket has pythonic list comprehension syntax too: (for/list ([x '(2 4 8)]) (sqr x)) It also has lazy evaluation langs, static typecheck pre-eval step…

Developing domain-specific languages/minilanguages is claimed by many to be idiomatic for many Lisps. And DSL is an especially strength of Racket (especially with the syntax objects, pattern-based syntax transformers, module system and submodules, and `#lang`). But, just to avoid giving non-Racketeers the wrong impression... I don't recall anyone ever calling a piece of Racket code non -idiomatic merely because it di…

I've spent some time looking at Racket open source projects, and I did not come away with the impression that one must start by creating one's own #lang. There are a lot of custom DSLs out there, but it seems to me that most of them come about, not because using Racket compelled the author to create a DSL, but because creating a DSL compelled the author to use Racket. No other platform I know of (not even MPS) seems to even come close in terms of ease of use and number of batteries included.

I could admittedly be projecting here. Wanting to create a DSL is what brought me back to Racket after a long hiatus. But I don't think so. Exhibit B is that, if you go to Racket's Discord or Slack, you'll see that people are mostly discussing how to solve concrete problems with standard language features. The volume of talk about macros and #langs is much, much smaller.

Re: Why learn Racket? A student's perspective

#33

Post by throwamon »

srcreigh wrote: post #8

The point about simple evaluation models, while true for basic Racket, is actually the furthest from the truth in idiomatic Racket. The idiomatic way to solve a problem in Racket is to develop new syntax (and evaluation orders) which are suited to the problem. In fact, Racket has pythonic list comprehension syntax too: (for/list ([x '(2 4 8)]) (sqr x)) It also has lazy evaluation langs, static typecheck pre-eval step…

> I wrote a Macro which adds identifiers to your program based on a SQLite database's column names.

Cool! F# has "type providers" which seem to be similar to this. Do you have any experience with them? I haven't used them but this sounds like an extremely powerful idea that more languages should adopt.

Re: Why learn Racket? A student's perspective

#34

Post by throwamon »

soegaard wrote: post #19
moron4hire wrote: post #13

Earlier quoted context omitted.

After 20 years of software development in a variety of languages and projects, I've come to the opinion that recursion really should be relegated to being a novelty. Few languages offer tail-call optimization. If we look at popularity of languages, then the likelihood any particular solution is going to end up in such a language is vanishingly small. For the remaining languages, fitting into the stack depth is easy t…

It's great to have support for tail recursion when implementing recursive solutions, but it is a tall order to add to more traditional languages. However tail recursion is not the only trick Racket has up its sleeve. In Racket you can't get a stack overflow. At the time a potential stack overflow is detected, the oldest parts of the current stack is copied to the heap and a fresh stack is introduced. When the stack u…

Sounds very good, but you make it sound like there are no considerable downsides. Why aren't more languages doing it?

Re: Why learn Racket? A student's perspective

#35

Post by CraigJPerry »

moron4hire wrote: post #13
melony wrote: post #5

It is interesting that recursion is still considered to be so novel on blogs and forums. From what I have seen of current CS curriculums, recursion is usually taught in the first year immediately after introductory CS. It is almost impossible not to use recursion when dealing with tree structures (using an explicit stack takes a lot more code, most coding interviews don't ask for an iterative solution unless absolute…

After 20 years of software development in a variety of languages and projects, I've come to the opinion that recursion really should be relegated to being a novelty. Few languages offer tail-call optimization. If we look at popularity of languages, then the likelihood any particular solution is going to end up in such a language is vanishingly small. For the remaining languages, fitting into the stack depth is easy t…

And your non-recursive solution will usually be faster too.

It Will usually offer simpler opportunities to parallelise too.

Re: Why learn Racket? A student's perspective

#36

Post by srcreigh »

throwamon wrote: post #33
srcreigh wrote: post #8

The point about simple evaluation models, while true for basic Racket, is actually the furthest from the truth in idiomatic Racket. The idiomatic way to solve a problem in Racket is to develop new syntax (and evaluation orders) which are suited to the problem. In fact, Racket has pythonic list comprehension syntax too: (for/list ([x '(2 4 8)]) (sqr x)) It also has lazy evaluation langs, static typecheck pre-eval step…

> I wrote a Macro which adds identifiers to your program based on a SQLite database's column names. Cool! F# has "type providers" which seem to be similar to this. Do you have any experience with them? I haven't used them but this sounds like an extremely powerful idea that more languages should adopt.

Thanks! I found some type providers docs [0] which is at some level an ML version of my Racket blog post. I had no idea type providers existed. The closest inspiration I had was probably Kotlin SQLDelight or Hibernate java codegen which (probably unnecessarily) requires in-code annotations. Anyway, that's very cool!

The F# type provider looks so stateful ;) Although they are pretty similar, I think the racket pattern syntax is very beautiful. Once you grok the pattern variables vs syntax objects vs quoted lisp data anyways.

Racket actually generates code. It could generate Typed Racket type expressions too. It makes me wonder how LINQ is implemented--my lisp hubris makes me guess it's not as simple as the equivalent Racket macro, but I could be wrong.

I guess Protocol buffers are a mainstream similar system to all this--take CSV file input instead of proto file input. Of course that requires an external compiler for most languages, whereas the racket protocol buffer plugin basically just converts the .proto file to S-expressions and all the codegen happens within Racket ;p

[0]: https://docs.microsoft.com/en-us/dotnet/fsharp/tutorials/typ...

Re: Why learn Racket? A student's perspective

#37

Post by leephillips »

srcreigh wrote: post #8

The point about simple evaluation models, while true for basic Racket, is actually the furthest from the truth in idiomatic Racket. The idiomatic way to solve a problem in Racket is to develop new syntax (and evaluation orders) which are suited to the problem. In fact, Racket has pythonic list comprehension syntax too: (for/list ([x '(2 4 8)]) (sqr x)) It also has lazy evaluation langs, static typecheck pre-eval step…

That is awesome.

Re: Why learn Racket? A student's perspective

#38

Post by keithnz »

srcreigh wrote: post #8

The point about simple evaluation models, while true for basic Racket, is actually the furthest from the truth in idiomatic Racket. The idiomatic way to solve a problem in Racket is to develop new syntax (and evaluation orders) which are suited to the problem. In fact, Racket has pythonic list comprehension syntax too: (for/list ([x '(2 4 8)]) (sqr x)) It also has lazy evaluation langs, static typecheck pre-eval step…

F# has this kind of stuff also, where it will dynamically type data dynamic sources like databases or rest calls, etc. for an example https://fsprojects.github.io/FSharp.Data/

Re: Why learn Racket? A student's perspective

#40

Post by acbart »

Ah, debates about programming language choice for CS1, without evidence. Gotta love the CS1 language wars. Someday some folks will actually gather evidence that really let's us know if these interesting claims about these languages hold any water. I don't think we've made much progress on that as a community. Fortunately, the people involved in these projects are doing more valuable things with their time.
Post reply on HN