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

A Friendly Introduction to Racket

geometridae.bearblog.dev

Post reply on HN
Print view View original

51–60 of 195 posts

Re: A Friendly Introduction to Racket

#51

Post by jibal »

AnimalMuppet wrote: post #41
dented42 wrote: post #30

Earlier quoted context omitted.

> Wtf kind of intro to a programming language doesn’t include syntax rules? Given that most languages don’t have syntax rules or anything like it, I’m gonna go out on a limb and say that most language introductions/overviews/tutorials don’t mention it.

Most? I question that. In fact, what languages can you say do not have syntax rules?

syntax-rules refers specifically to Racket macros.

Since macros are a very important part of Racket, complaining that a friendly introduction mentions them is [insert non-friendly characterization].

Re: A Friendly Introduction to Racket

#52

Post by jibal »

eru wrote: post #38
WalterGR wrote: post #8

Earlier quoted context omitted.

Homoiconicity.

C has homoiconicity: you can represent C source code as C strings.

You can't run that code within the language so no, obviously not. And even if you could, strings + eval alone is not homoiconicity--programs are not manipulated by the compiler as unstructured text strings.

Re: A Friendly Introduction to Racket

#53

Post by chowells »

WalterGR wrote: post #20
chowells wrote: post #13

Earlier quoted context omitted.

What makes this a desirable feature? From the perspective where local reasoning is the most desirable property a language can have, how does homoiconicity support that? I honestly am curious. I've seen a few examples presented for it, but they always seem like bad software engineering to me. Where's an example that does something in a cleaner way than alternatives present in other languages while remaining compatible…

> From the perspective where local reasoning is the most desirable property a language can have That's a perspective. If you're looking for a low-level language, then Scheme isn't it. (Forget iconicity - Scheme is garbage-collected. And supports continuations!) If you don't program in machine code - which would maximize local reasoning - then you must know the language with the Correct balance of local reasoning and…

That's not at all what local reasoning means. Local reasoning is the property that a piece of code contains (when including the call graph) everything that can affect what it does. All mutation of a value is kept within some scope of ownership of that value. If you want to understand a piece of code, you can do it by understanding that piece of code, not the program as a whole.

Assembly makes non-local reasoning mandatory, as any code can update any location in memory without restriction. All memory accesses are global. References need not even be by name - they can be via computed addresses. There are no restrictions in place allowing the structure of the program to provide boundaries on what pieces of code may be understood as units.

Re: A Friendly Introduction to Racket

#54

Post by Zambyte »

em-bee wrote: post #2

any time the topic of racket comes up, i wonder if there are any interesting apps i could explore. but all i find is libraries and dev tools: https://awesome-racket.com/

One of the more notable apps originally written in Racket is https://news.ycombinator.com.

See: https://en.wikipedia.org/wiki/Arc_(programming_language)#His...

Re: A Friendly Introduction to Racket

#55

Post by jibal »

layer8 wrote: post #19
WalterGR wrote: post #8

Earlier quoted context omitted.

Homoiconicity.

I don’t find it appealing when everything looks the same irrespective of purpose and context.

Does i + 1 look the same as "i + 1"? The first is an expression, the second is a string. In LISP, it's similarly (+ i 1) vs '(+ i 1).

These sorts of shallow complaints can be made of any feature than one is not familiar with, hasn't used, and doesn't know or understand the benefits of. In any case, no one is forcing people to use this language or take advantage of this feature.

P.S. The "response" actually ignores all points made, attacks strawmen, moves the goalposts, and is intellectually dishonest (the original comment was clearly a complaint, and besides it wouldn't matter if some other word like "criticism" or "dissatisfaction" were substituted--my point remains). Again, no one is forcing anyone.

Re: A Friendly Introduction to Racket

#56

Post by so-cal-schemer »

vatsachak wrote: post #6

I've never seen the appeal in schemes other than hot reloadability...

Lisp/Scheme/Racket is a very simple language that is also very fluid and malleable. You can express ideas and computations very precisely, concisely, and intuitively. There really aren't any barriers as they (Scheme/Racket at least) are rooted in the Lambda Calculus which is a theoretical model equivalent to the Turing Machine. Any language feature you'd like can be expressed: Want standard infix math expressions or a borrow-checker? That's a macro. Want lazy evaluation? That's a simple change in a meta-circular evaluator. Want a language that is the simplest and most direct mapping to your problem domain? A DSL.

The syntax lends itself to easy structural editing way before LSPs..

Why Racket? Why Lisp?

https://beautifulracket.com/appendix/why-racket-why-lisp.htm...

Why language-oriented programming? Why Racket?

https://beautifulracket.com/appendix/why-lop-why-racket.html

Creating Languages in Racket: Sometimes you just have to make a better mousetrap.

https://queue.acm.org/detail.cfm?id=2068896

Lisp is clay: the power of composable DSLs

https://fosdem.org/2026/schedule/event/HDE7JZ-lisp-is-clay/

The other powers of Lisps (interactive development, hot reloadability, restarts on error, etc) are more tied to the sophistication of their implementations and runtime environments.

Re: A Friendly Introduction to Racket

#58

Post by layer8 »

jibal wrote: post #55
layer8 wrote: post #19

Earlier quoted context omitted.

I don’t find it appealing when everything looks the same irrespective of purpose and context.

Does i + 1 look the same as "i + 1"? The first is an expression, the second is a string. In LISP, it's similarly (+ i 1) vs '(+ i 1). These sorts of shallow complaints can be made of any feature than one is not familiar with, hasn't used, and doesn't know or understand the benefits of. In any case, no one is forcing people to use this language or take advantage of this feature. P.S. The "response" actually ignores al…

To answer your question, yes it does look pretty much the same in the Lisp version, less so in the string version. Also I didn’t complain; I expressed the opinion that I don’t agree that homoiconicity increases the appeal of a programming language, because the drawbacks outweigh the possible benefits for me. I spent some time programming in Lisp and am familiar with how homoiconicity works there.

The point is that these things are subjective, and there will never be a programming language that everyone likes the best.

Re: A Friendly Introduction to Racket

#59

Post by Zambyte »

gus_massa wrote: post #26
chowells wrote: post #13

Earlier quoted context omitted.

What makes this a desirable feature? From the perspective where local reasoning is the most desirable property a language can have, how does homoiconicity support that? I honestly am curious. I've seen a few examples presented for it, but they always seem like bad software engineering to me. Where's an example that does something in a cleaner way than alternatives present in other languages while remaining compatible…

Homoiconicity makes writing macros easy. If you don't like it, you can try https://rhombus-lang.org/ that is build on Racket and also has macros but uses a Python-like syntax.

Easy is an understatement. Macros and dynamic programming (often done using runtime reflection in other languages) are so trivially easy in Lisps that one can stumble into it without realizing they're even doing it. Anyone who has done these things in more "modern" languages knows these features are not something one can accidentally start doing. They take a lot of deliberate effort relative to standard, static programming.
Post reply on HN