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

11–20 of 55 posts

Re: Why learn Racket? A student's perspective

#11

Post by srcreigh »

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…

Another example... this Arc code doesn't finish evaluating until a couple round trips with a web browser are finished. Absolutely cursed

    (defop said req
      (aform [w/link (pr "you said: " (arg _ "foo"))
               (pr "click here")]
        (input "foo") 
        (submit)))
(If you didn't know, Arc is implemented in Racket, and powers this site...)

http://paulgraham.com/arcchallenge.html

Re: Why learn Racket? A student's perspective

#12

Post by kjander79 »

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…

One thing to note: The reason why SICP uses Scheme is not that the resulting programs are simpler. But instead, the mental model of what is happening under the hood is simpler, and easy to refine as you go along. This makes it possible to come to the end of the class, ready to create your own Scheme interpreter. I don't think that's possible with any of the alternatives, like Python.

I am sure this result was rare, of course, even when it was the introductory at MIT. And as you point out, Racket has changed a lot also. I think it has been some years that Racket stopped calling itself Scheme, feeling the changes they have made have deviated too far.

Re: Why learn Racket? A student's perspective

#13

Post by moron4hire »

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 to get wrong. It's easy to end up in an infinite loop that ends in an obscure error with a confusing, verbose, needle-in-hay-stack stack frame that over complicates debugging. And frankly, lots of programmers don't have a good handle on it, even the ones who studied CS in college, so asking them to maintain recursive code written by someone else usually ends pretty poorly.

So when we consider that, actually, no, it's not true that using an explicit stack takes "a lot more code" (it's like, three extra lines), recursion starts to look more and more like a code smell, a smell indicating the originating programmer is more a temporarily-embarrassed mathematician than an engineer.

To be clear, I have no problems conceiving of and implementing recursive solutions to problems. But every single one of my recursive solutions has eventually failed to survive contact with real life data. It might be next week when the code goes to production or it might be a year from now when the data processing needs grow, but I've eventually replaced them all.

I'm not the only one with this opinion. Many safety regulations covering vehicles from cars to spacecraft explicitly ban recursion because of these issues. We need to just stop with the fetishising of math in software development.

Re: Why learn Racket? A student's perspective

#14

Post by dbpatterson »

So... unless Grinnell does things very differently, the author did not learn Racket, they learned (Beginning/Intermediate/Advanced) Student Language, and that's the point.

Racket is a complicated language, designed primarily in order to support the easy creation of other languages: it would be as bad a choice (perhaps worse) for a first language as any other. All of the simplicity, focusing on learning to program, programming structurally based on data, that comes out of HtDP, is enabled by the restricted language.

It's too bad that this naming confusion persists, as I think it hurts the effort to focus on teaching _programming_ in intro classes, vs. teaching X language (I don't want to teach people Racket any more than I want to teach them Python or Java. They can learn those on their own -- they'll probably learn at least a half dozen other languages over their career, all on their own, if they stick with it). This curriculum is about figuring out how to most effectively teach people to program: the language was created, after the fact, to support that.

Re: Why learn Racket? A student's perspective

#15

Post by neilv »

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…

In my (abandoned) Racket book (which had a very specific positioning), I was going to introduce some of the non-Scheme iterators like `for/list` at the start, to help people do commercial work on the first day... and then later teach some more old-school Scheme-idiomatic ways to do things, with named-`let` and avoiding mutations to shoehorn. (Then, once people were comfortable with the less-familiar way, they could decide when to use which.)

Re: Why learn Racket? A student's perspective

#16

Post by [deleted] »

dbpatterson wrote: post #14

So... unless Grinnell does things very differently, the author did not learn Racket, they learned (Beginning/Intermediate/Advanced) Student Language, and that's the point. Racket is a complicated language, designed primarily in order to support the easy creation of other languages: it would be as bad a choice (perhaps worse) for a first language as any other. All of the simplicity, focusing on learning to program, pr…

[deleted]

Re: Why learn Racket? A student's perspective

#17

Post by neilv »

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 didn't introduce a DSL or syntax extension.

In my (abandoned) Racket book, I intended to get people commercial-grade productive the first day, and introducing syntax extension wouldn't come until calendar weeks/months later. (Related: there'd be an entire chapter at the end, entitled "Don't Use `eval`", starting out like: https://lists.racket-lang.org/users/archive/2014-July/063597... :)

Re: Why learn Racket? A student's perspective

#19

Post by soegaard »

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…

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 underflows the saved stack is reinstated. [At least this is a rough idea of how it works - implementation details differ to make it process efficient.]

This means that you can rely on recursive solutions even when the recursive call occurs in a non-tail context.

This idea (no stack overflows) could be used in more traditional languages too. As you write in traditional languages there is a real risk to bump into the stack limit.

Re: Why learn Racket? A student's perspective

#20

Post by xhevahir »

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!
Post reply on HN