Why learn Racket? A student's perspective(micahcantor.com) |
Why learn Racket? A student's perspective(micahcantor.com) |
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))
Basically the floodgates are open, even if the river is still a bit barren. Every confusing language feature in existence can be added to Racket. The only saving grace is that anyone, including you, can replace it with less confusing syntax / evaluation orders if they so desire.
I wrote a Macro which adds identifiers to your program based on a SQLite database's column names. [0] If the database isn't found your program does not compile. How is that for confusing alternative evaluation order? If that's your nightmare, my point is made.
[0]: http://tech.perpetua.io/2022/01/generating-sqlite-bindings-w...
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... :)
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.
(defop said req
(aform [w/link (pr "you said: " (arg _ "foo"))
(pr "click here")]
(input "foo")
(submit)))
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.
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.
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...
https://docs.racket-lang.org/gui/
The first "side-project" I ever did was a tic-tac-toe program in Java AWT during my first year of programming in high school. AWT wasn't even part of the curriculum, it was just what I gravitated towards as a 13-year-old whose experience with computers consisted entirely of graphical applications.
Maybe the kids these days would be more interested in building a web app or something, but frankly I don't think it's surprising that writing code that primarily consumes and emits text at a terminal is not interesting to students who have never had any need for a terminal before.
[1]: https://htdp.org/
You mention SICP, but I’m wondering if you are using HTDP http://htdp.org/ ?
I’ve always been struck by the vision the authors state in the preface;
> everyone can design programs
>
> and
>
> everyone can experience the satisfaction that comes with creative design.
>
> Indeed, we go even further and argue that program design—but not programming—deserves the same role in a liberal-arts education as mathematics and language skills.
>
> A student of design who never touches a program again will still pick up universally useful problem-solving skills, experience a deeply creative activity, and learn to appreciate a new form of aesthetic.
I’m not a good programmer - I’m not even a average one, but the book and learning Racket has made me better.
That being said I think learning programming in an "expressions only" environment can enable the student to deal with more complex problems earlier, merely by making certain types of errors impossible.
I think the Elm programming language is the sweet spot for that.
- it does have elegant (Haskell like) syntax
- it has still a simple syntax because it deliberately omits certain features (namely typeclasses, do-notation)
- it has a self contained build system (compiler, package manager, repl, dev server) with a rich ecosystem of libraries
- it is comparatively easy to ship something tangible because it compiles to JS for the browser
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.
As a counter-example you can't do much of anything in Java without introducing class and public-static-void-main-string-args.
Sure, Racket has facilities to make implementing languages easier (that's the whole point), but that simply makes it _easier_ to implement BSL, etc. I could certainly, with more effort, implement BSL in Java or in any other language: the language that students are using really has nothing to do with the _host_ language. Things are somewhat confused by DrRacket (or, made simpler, depending on your perspective); the IDE is somewhat mixed up with everything else, but again, this functionality can and does exist in other editors: I could implement a mode for my BSL implemented in Java in, say, VS Code, with comparable features to DrRacket.
Or, to take a completely different tack, implement the IDE via the web a la WeScheme or, if you want an actual concrete example of something that isn't Racket hosted, Pyret.
I think it's fine to bag on languages like Racket, but a good engineer should be able to hop across any language and at least be able to read and understand what they're doing.
I think it's a bad choice if this is your only programming course during your studies, then it would be much more helpful to learn something that is a safer bet you'll be using in your life continuing forward. Yes, even JavaScript. If you're interested, you'll pick up another language and apply what you learned here - but if not, then I think there's a better chance you'll recall what you learned with the mainstream model and work from there.
This is my unscientific opinion, but it's based on all my experience with non-programmers where you can be happy if they learned _something_ at all, they'll most often see themselves as "I learned some Python" for example, and are willing to expand from there, but they're more reluctant to transfer the knowledge to learn a new language. I don't think it's completely off, either, even drawing a parallel to learning natural languages (to a small degree, not full working proficiency).
Comment related to the article: I always wanted to dive deeper into functional programming languages. Especially, because I more and more run into stuff, that is just simpler to model in a recursive pattern. Maybe I'll give it the a new try within the next weeks and see how far I come.
And I'd definitely recommend it, programming in FP languages has been a bit of an addiction for me.
I have spent a lot of my professional life using Lisp languages. Not as popular as Python, Java, etc., but Lisp (and other languages like Haskell) have a good effect on how we think about computation.
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.
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.
Honestly that speaks to the caliber of programmers at play here. Sure, the average bootcamp grad probably can’t use a recursive function, but a real software engineer should have mastered it during any serious intro class. Without recursion I’m not sure how we would even be programming (think of all the parsers and grammars relying on it!).
> 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.
It sure is a code smell if the average programmer in a given org can’t understand it.
I don't know if you mean that literally or just as a rhetorical exaggeration, but it's absolutely false. The first example that came to mind is Quick Sort, search for the iterative version of the algorithm and compare it with the traditional recursive version, easily a 10x factor. The increase in complexity isn't linear in code size either, the code that replaces the simple recursive calls is full to the brim with loops, state and conditional mutations, i.e. Free Bugs, yummy yummy.
>Few languages offer tail-call optimization.
I was hacking on a (non-tail-) recursive solution to a problem a couple of days ago in a repl.it container, and a buggy solution exploded after consuming 15000 stack frames. The repl had 1024 MB RAM as a max limit. The point is, absence of tail cail optimization is rarely if ever a real problem in a language that has loops, its a big, big problem if the language doesn't have loops, but as long as the language has loops and relegates recursion to the "Side Role" its so good at, its just not that of a big deal.
This also fails to consider why recursion is such an attractive algorithmic construct, tail recursion is absolutely trivial, it can be transformed to loops mechanically, it rarely adds anything of value to the readability and expressiveness of code.
The vast majority of interesting and useful uses of recursion is the non-tail-recursive variety, where you have to use a stack anyway, at this point the whole argument reduces to whether you can maintain a stack more efficiently and readably than the machine, which in my view ends in you losing to the machine 9 times out of 10.
>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.
If those programmers were asked to instead maintain the explicitly iterative version of the code, I bet it would end even more badly. Recursion, after the initial cost of watching a few tutorials, is less confusing than loops. It's about hiding state, how on earth is explicitly managing all that state yourself better? This is like saying that "2+46/(3+1)4" is best calculated as a long sequence of 2-argument assembly instructions because its more explicit that way, its more explicit, true, but - paradoxically - way more obscure.
>Many safety regulations covering vehicles from cars to spacecraft explicitly ban recursion because of these issues.
Embedded Systems safety regulations and conventions ban a lot of things, recursion is not special at all. One thing is dynamic allocation, another thing is multiple returns out of a subroutine. Are you ready to give up those 2 things?
It makes no sense to take the conventions of a very specific and idiosyncratic industry like that and try to derive from it universal rules that should govern all software.
It Will usually offer simpler opportunities to parallelise too.
Ironic that you should post this, having not done any due diligence on your own part.
Shriram Krishnamurthi, who, incidentally, was one of the original members of the Racket team, is at the forefront of CS education research, and one thing he thinks about is how to introduce people to computer science. This, of course, includes the choice of language. He, as well as his wife and two former students, wrote and recently published the book "A Data-Centric Introduction to Computing" (DCIC) [1], which is meant to be a new kind of CS 101 textbook.
In section 1.8, "Our Programming Language Choice" [2], the authors write about how Python is now a common introductory language choice that also enjoys industry use, but it can lead to frustrations for new students of computing, so they didn't want to use Python. Instead, they developed their own language, Pyret, for teaching. (Pyret is also used in another initiative of Shriram's: Bootstrap [3].) It's worth pointing out that although Pyret is very similar to Python in many regards, its spiritual heritage certainly includes Racket. Racket was designed at the outset as a language for teaching programming, and this desire to invest effort in tools for beginners has stuck with SK for the duration of his decades-spanning career. I'd suggest looking through his publications, blog posts, and Twitter feed for works/notes about CS education with regard to language choice. He's certainly not quiet about it.
All this is to say: people are working on getting to a solid answer about what language is best for introductory material. We just haven't come to a definitive conclusion yet.
However, I think we should leave all that aside and focus on something else: the original blog post for this HN thread is not a "debate", as you've suggested. It's one student's perspective. They are absolutely allowed to think aloud to the internet and share their resulting perspectives. They didn't claim to have all the answers. I think their post was rather well-written, exploring things that this student felt made learning programming easier. If that's not worth discussing, I'm not sure what is.
[2] https://dcic-world.org/2022-01-25/part_intro.html#%28part._....
That said, the HtDP curriculum that they were involved in, and led to Bootstrap and a host of their other projects, was not grounded in any kind of data collection or treated as an empirical research project. Smart people with good intentions built something and threw it into a classroom. Intentionally so, by design [1].
Their subsequent work with Pyret is much better grounded and well-informed, and I've been absolutely fascinated by it. Their data science curriculum delights me, and I have often thought that if I had more time I'd translate it to Python. I think their more recent proposal about a Table Abstract Data Type is just inspired. But we are still VERY far from ever proving things like, "Racket is easier for students to learn". I'm fairly sure it's not even worth doing.
I appreciate the original article was just one student's perspective. It's a perspective I don't entirely disagree with. Nonetheless, they make interesting claims not backed by any kind of published, empirical data. They hypothesize that Racket is virtuous to learn because of how it presents recursion, and because of its simplistic syntax. Cool theory, but not proven using Randomized Controlled Studies. I mean, most things in CS Ed aren't, so I don't think it's a surprising thing to point out. But that doesn't mean we should just sit back and accept these claims.
Personally, I have seen the HtDP curriculum do damage. I have also seen it firsthand do a lot of good. My Racket relationship is complicated [2]. The author makes a great point of the potential value of these models, and also mentions how this whole debate is sort of pointless. I believe that at the end of the day, the CS1 language is simultaneously very important and yet somehow unimportant - it's all just the psychology of the people involved. That, too, is an unsubstantiated claim.
But please, tell me more about how I have not done my due diligence. Would you like to cite some actual RCT papers that back up the claims founding all this stuff? Or do you want to keep citing textbooks like that somehow proves something?
[1] https://felleisen.org/matthias/Thoughts/Measuring_education.... [2] https://github.com/acbart/myracketrelationshipiscomplicated....
Indeed. On one automotive project, we could not use C++ strings, due to the hidden dynamic allocation.
From [2] (2012 version) (warning : annoying ads and misleading download button takes you to registration, but it's the only free source I could find with detailed rationale in each rule) :
Rule 15.5 : A function shall have a single point of exit at the end
Rule 21.3 : Memory allocation and deallocation functions of <stdlib.h> shall not be used.
From [3] (2004 version) (pdf) :
Rule 14.7 : [Same as Rule 15.5 of [2]]
Rule 20.4 : Dynamic heap allocations shall not be used
[3] is a pdf containing the 2004 version of the conventions, but no rationale is given for each rule.
>governments had neither insight nor competence to decide such matters.
On the contrary, things like banks, medical devices, aerospace and defense are heavily regulated by the government, source code is just another component in the whole system, why shouldn't it be regulated like hardware ?
As for competence, the government is not all bureaucrats and officials, they can hire specialists to do their inspections.
[1] https://en.m.wikipedia.org/wiki/MISRA_C
[2] https://www.academia.edu/40301277/MISRA_C_2_012_Guidelines_f...
[3]https://www.google.com/url?sa=t&source=web&rct=j&url=https:/...