Live data from Hacker News

A Friendly Introduction to Racket

geometridae.bearblog.dev

151–160 of 195 posts

Re: A Friendly Introduction to Racket

#151

Earlier quoted context omitted.

I don't see where the above says that Prolog is a "poor general purpose language"? I'd instead say that claim is incompatible with the following paragraphs that rather sing the praises of Prolog as a programming language: Prolog is one of the two classic languages for symbolic artificial intelligence programming (the other classic language being Lisp). Prolog excels at implementing symbolic rule-based systems in whic…

That link wasn't an argument to support my claim, just a related comparison. > So, why do you say that Prolog is a "poor general purpose language"? Big disclaimer: I have almost no Prolog experience beyond a distant university class, so I've no idea what's possible with a pragmatic impl. like SWI-Prolog. Still, this is my uninformed "Emacs vs vim tier" opinion. For the same reason as most other people do so: when you…

That's not my experience of Prolog and I can't see how it's yours if you have "almost no Prolog experience" etc.

EDIT:

I don't want to get into a holy flamewar (vim vs emacs? Oh dear) but I've heard that criticism before. I think the reason is that there's a kind of program that is absolutely trivial to write in Prolog: business logic, rules engines, etc, anything where you can write out the program logic as a set of facts and rules. I mean duh. A Prolog program is a set of facts and rules. But at that point you're* not even trying to use the language. Then of course, if you try to do something more complicated it will take more effort and you will need to really understand how Prolog works; which is not trivial.

So I think it's a bit like mathematics. Yeah, if you just want to add 1 and 1, it's easy. If you want to calculate the amount of fuel it will take to fly to the moon and back, it takes considerably more effort. You can see it as maths being "easy for the easy things but hard for the hard things", but it's just that the hard things are hard and take more work, not the fault of maths as such.

__________

* "You" in the abstract, not you personally.

Re: A Friendly Introduction to Racket

#152

Earlier quoted context omitted.

Still doubt, that they are unaware of Elisp. Bare bones vanilla Emacs is maybe a bit much to get used to these days, so anyone wanting to configure their Emacs will have opened their init.el or so file and will have put some Elisp snippets there.

I've helped such people with their configs. They just know it as "commands" they put in the init file - they don't think of it as a programming language. It's rare for simple init.el files to have things like functions, loops, etc. And, to be frank, most of them don't customize the init.el file. They just want a text editor - not an IDE. The defaults are ugly , but they're perfectly functional. None of these people c…

Why are they then even setting up vanilla Emacs in particular? Not impossible, of course, but it seems like a strange choice to make when not wanting to engage with its configuration. Or maybe another question would be who set them up with vanilla, unconfigured Emacs, if they are not so technical users? Even discovering tramp is not trivial or automatic and for working on a remote machine, isn't Vim much more common?

Re: A Friendly Introduction to Racket

#153
post #16

While the language is interesting, sadly, nobody is using it in the wild. Maybe due to cumbersome deployment options? The ability to produce native standalone executables would boost its usage I believe.

We use it - specifically we use its Scribble package to define self-documented file formats that autogenerate C++ & Python sources.

Re: A Friendly Introduction to Racket

#154
post #109
post #52

Earlier quoted context omitted.

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.

I quite intentionally said "within the language" to preempt nonsense like "Of course, you can. C is perfectly capable of writing C interpreters and compilers."

> What does 'within the language' mean?

It's obvious, and the rest of the comment confirms that:

> Would a variant of C that came with an interpreter in the standard library (but no other changes) count as homoiconic?

I already answered this, so this is clearly bad faith trolling/sealioning:

"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

#155
post #44

Earlier quoted context omitted.

It's not a program, it is (obviously) a totally unrealistic hodgepodge expression for a list of constant values that simply demonstrates the literal syntax for a variety of types of values (real numbers, dotted pairs, rational numbers, complex numbers, polar coordinates, etc. -- Racket is unusually expressive in the types of literals). Your comment demonstrates something typical of HN, and it's not a good thing. It's…

I think in this case it is probably justified, as the claim of "no special syntax" is unfortunately not true. To convey the amount of special syntax, it got crammed into one brief example snippet. Still, far less than most other programming languages, virtue of having parentheses making things unambiguous. Outliers are Smalltalk and maybe (?) Forth.

> I think in this case it is probably justified

What is "it"? The GP clearly doesn't understand that code and utterly misconstrues its nature and the nature of the Racket/Scheme/LISP language. If someone has zero knowledge of the topic at hand (even when it's a seminal programming language that's been around for nearly 70 years), they have an obligation to at least glance at TFA before commenting.

> the claim of "no special syntax" is unfortunately not true

That's a completely different issue than the one I addressed. (And I really don't think the point is made in good faith--the sense in which that phrase was meant is well understood, certainly by the GGP who is so very familiar with Racket's token syntax and quasiquotes.)

I won't respond further.

Re: A Friendly Introduction to Racket

#156
post #44

Earlier quoted context omitted.

It's not a program, it is (obviously) a totally unrealistic hodgepodge expression for a list of constant values that simply demonstrates the literal syntax for a variety of types of values (real numbers, dotted pairs, rational numbers, complex numbers, polar coordinates, etc. -- Racket is unusually expressive in the types of literals). Your comment demonstrates something typical of HN, and it's not a good thing. It's…

First time dealing with developers I see. I’m sorry.

Nonsensical non sequitur ad hominem. (FWIW I've been a software developer for 60 years and have dealt with many of them.)

I won't respond further.

Re: A Friendly Introduction to Racket

#157

Nothing against Lisp, but to correct the record: > For decades, Lisp was the language of artificial intelligence. [...] Then came the "AI winter," funding dried up, and Lisp went from star to cult language. Lisp had fallen from relevance before then. Only the United States was still using it, and mostly out of technical debt and a stubborn refusal to move on. Prolog displaced it in the late 1970s, and even within the…

If anybody reading this branch of the discussion wants to investigate Logic Programming and Nondeterministic Computing further in the context of Racket/Scheme, it is discussed in §4.4 of SICP as a Scheme variant. A variant created by modifying the meta-circular evaluator -- as Ableson says, the real superpower of Lisp, and an excellent display of the usefulness of homoiconicity.

4.4 Logic Programming

https://sarabander.github.io/sicp/html/4_002e4.xhtml#g_t4_00...

4.3 Variations on a Scheme — Nondeterministic Computing

https://sarabander.github.io/sicp/html/4_002e3.xhtml#g_t4_00...

4.1 The Metacircular Evaluator

https://sarabander.github.io/sicp/html/4_002e1.xhtml#g_t4_00...

Re: A Friendly Introduction to Racket

#158

Earlier quoted context omitted.

I've read a large factor was minicomputers and microcomputers running Unix in C became much more affordable, and when the Berlin Wall fell in 1989 DoD funding for powerful and expensive Lisp workstations quickly dried up. And the nascent free software Lisp offerings left a lot to be desired (to be developed). This visualization of relative programming language popularity shows Lisp was the 3rd most popular general pu…

Pascal in 1984 was not just a teaching language. The ranking then was due to Turbo Pascal which came out in November 1983. It was probaly the first IDE and compiler on PCs

Great point for the timeline.

more: https://wiki.c2.com/?PascalLanguage

Re: A Friendly Introduction to Racket

#160
post #16

While the language is interesting, sadly, nobody is using it in the wild. Maybe due to cumbersome deployment options? The ability to produce native standalone executables would boost its usage I believe.

Here is a project using Scheme via GUIX to manage reproducible scientific workflows in high-performance computing (HPC). There are installations using it in France, Germany, The Netherlands, Australia, The United States.

https://hpc.guix.info/about/

https://hpc.guix.info/blog/2026/02/guix-hpc-activity-report-...

Guix-HPC started as a joint software development project involving three research institutes: Inria, the Max Delbrück Center for Molecular Medicine (MDC), and the Utrecht Bioinformatics Center (UBC). Guix for HPC and reproducible research has since received contributions from many individuals and organizations, including CNRS, Université Paris Cité, the University of Tennessee Health Science Center (UTHSC), Cornell University, and AMD. HPC remains a conservative domain but over the years, we have reached out to many organizations and people who share our goal of improving upon the status quo when it comes to software deployment.

Post reply on HN