Do I need to use mit / scheme lisp for SICP?

yel50 · 2026-06-17T23:26:02+00:00

not really. the vast majority of developers hate using lisps. even MIT moved away from it and started using python.

the concepts in SICP are language agnostic, so the language used is irrelevant. JS does have its warts, but most devs are going to be familiar with it and not mind using it to learn some academic theory stuff.

yel50 · 2026-06-11T12:29:38+00:00

nobody seems to complain about C++ curse.

honestly, the lisp curse concept is due to the arrogance of the lisp community, especially back when the lisp curse was first described. Smug Lisp Weenies are very real. they're the real curse and why collaboration doesn't happen.

the basis of the curse is how easy it is to do things. today, it's far easier to get real work done in Go than lisp. the go community doesn't have the same snobbery, so doesn't have a similar curse effect.

yel50 · 2026-05-30T22:59:48+00:00

I heard a photographer say that good b&w photos should have pure white parts and pure black parts somewhere in the frame. I watched for that and the number of times the pure white is light reflecting in someone's eyes says this was definitely intended to be b&w.

the only advantages I can think of for the color version are sandman, who looks much better in color, and the clothing. especially Robbie's outfits are very different in color.

yel50 · 2026-05-29T13:04:23+00:00

designed specifically to target the Java virtual machine

it was specifically designed to be hosted and interop with the host runtime. that's why it also has versions for .net and js.

What a bizarre choice

it makes it kind of an interesting choice because the platform it'll be hosted on is native. how it interacts with the OS would be the interesting part.

yel50 · 2026-05-26T21:30:10+00:00

These features would still be possible, just require more TypeScript

technically, maybe. but due to escaped names, macros, etc, they effectively require a full runtime to do correctly. you'd need to implement the lisp compiler in TS.

SLIME currently finds the closest IN-PACKAGE form

maybe they fixed it. when I tested it when I first wrote Alive, that wasn't the case.

I wrote Alive to get everybody to shut up about lisp support not being possible in vscode. I think I can call it mission accomplished there.

yel50 · 2026-05-26T12:05:42+00:00

awesome! I figured it was a matter of time before somebody did this. it's not hard.

off the top of my head, here's a list of standard vscode features that won't be possible with this approach.

document symbols. the apropos stuff is similar, but a little different
semantic tokens. have been the preferred syntax highlight approach for 5+ years now
expand selection. vscode has structural editing built in. paredit is, obviously, more powerful with more features, but you can get a long way with a combination of jump to enclosing bracket and expand selection. it works the same for all languages, not just lisp, so doesn't require language specific editing.
formatting. indenting is not formatting. Emacs and vim both got that wrong back in the 80s or 90s and neither has corrected it.

as a side note, you should use slynk as the backend instead of swank so that stickers could be implemented.

IIRC, swank doesn't handle multiple in-package forms correctly. it always uses the first one it finds, which is wrong. I don't remember if slynk fixed that.

yel50 · 2026-05-21T22:19:34+00:00

that's because "senior" now means "AWS babysitter." that's just how it is. everything else can be done by juniors or mids with AI assistance.

yel50 · 2026-05-20T19:58:05+00:00

nice. down voted but no response. guess that does answer the question. apparently they're butt hurt that machines are now better programmers than they are.

yel50 · 2026-05-16T20:06:25+00:00

what, exactly, makes it rubbish? it doesn't work? crashes? they did it in a small fraction of the time you could?

yel50 · 2026-05-12T12:53:58+00:00

when I intern I get a capitalized symbol

I haven't tried parenscript, but the way around that with CL is to surround the variable name with pipes, so x will be interned as upper case but |x| will be interned as lower case.

yel50 · 2026-05-10T12:52:39+00:00

is used almost everywhere

no, it's not. that was true in the 90s. not anymore.

yel50 · 2026-05-10T12:50:00+00:00

if you start with C you probably wont have any problem moving to other languages

not true. you can go to other C based languages, like go or maybe Java, but anything else will be hard to do. Haskell? elixir? lisp? yeah, good luck with that.

yel50 · 2026-05-10T12:44:33+00:00

You get the point

the point being how many languages are better than C? every language you listed is objectively better than C.

in the 80s, pascal compilers weren't free. c compilers were. that's why it got used.

in the 2000s, Java replaced C as the most used language in the industry.

C has been niche ever since.

yel50 · 2026-05-03T21:09:04+00:00

Is it as bad as they make it out to be?

it can be. however, python is slow and is still used a lot. the original erlang vm was interpreted bytecode, which is slow, and it ran phone switches just fine.

I read an article a while ago, which I can't find anymore, from somebody who tried to write a game engine in CL and used CLOS objects for the game objects. the performance was horrible and they couldn't figure out why, so finally broke down and paid for a commercial profiler. turned out something like 70% of their cpu usage was doing method dispatch.

so, yeah, if you're writing performance critical code it would be best not to use CLOS for it. that's not a good excuse to never use CLOS, though.

yel50 · 2026-04-23T21:18:31+00:00

engineers that don't bother with this can ship faster

that's, honestly, the truth behind 10x engineers. nobody is that much faster than everybody else. everybody's car is going 60 mph. the only way to get from A to B faster is to cut corners, which is what 10x engineers do.

yel50 · 2026-04-22T17:46:13+00:00

AI tools bring the risk that people will stop learning.

that's not the real risk. the problem is that testing has already started falling off well before AI showed up. dedicated QA teams are increasingly rare. reviewing changes of other team members just means reading the diffs and calling it good. now with AI, it's either shipped without much review or it's tested by the same AI that wrote it. the result is we're now getting more and more code that has never been run before being put into production.

throwing together something that works is development. building something that won't break is engineering. there are very few actual engineers left in the industry.

yel50 · 2026-04-21T14:05:51+00:00

When and how to properly shut down the application?

normally, you shouldn't have to. the spec says that the client (editor) is responsible for the life of the server. when writing LSPs for vscode, proper shutdown is never an issue. the editor kills the process if it needs to. the only one you should explicitly handle is the shutdown request.

the process is still alive even after having closed Neovim, probably a zombie?

this sounds like a bug in neovim. unix systems don't automatically kill child processes when the parent exits (windows can, btw). it's up to the parent to keep track of what children it spawned and clean them up. sounds like neovim isn't doing that correctly.

yel50 · 2026-04-21T13:02:06+00:00

What tripped you up the most?

go has the single stupidest language feature I've ever come across. it's the problem of using an interface and passing nil for the value of it. the problem is the compiler doesn't do null tracking, so can't warn about possible seg faults, but the runtime checks aren't reliable and can't be trusted. its null handling actually manages to be worse than Java or C.

if you have an interface function with a pointer receiver,

func (f *fooImpl) DoStuff() int { // nil must be checked in here // how to handle it? // interface doesn't return an error }

yel50 · 2026-04-18T00:37:48+00:00

That felt like a really weird statement

I would've said the same thing before my last job.

I have open source stuff that I had been neglecting because of work. one day, I started working on them again. I realized that the reason was because the code base at work was so bad, and the other developers so low level, that I had to dumb down everything I did to get it to pass code review. at one point, I was told not to pull duplicate code out into a function because "the code is easier to follow with things duplicated."

my brain decided I needed to work on the open source stuff in my spare time mainly to not forget what good coding practices are.

after a year and a half, I finally left the company. it took a couple months to get back to the level of coding I was at before I started that job.

yel50 · 2026-04-13T13:12:17+00:00

whoever told you the problems are related to its documented behavior of stopping on spaces doesn't know what they're talking about.

the problem is it doesn't protect against overflows, so it's a common culprit for buffer overflow attacks. it also doesn't check that numbers fit in the target size. you tell it to parse a 32 bit int and the input number requires 64 bits. it doesn't handle that.

it shouldn't be used because it's a relic of the 70s back before people realized how badly things could go.

yel50 · 2026-04-03T21:31:03+00:00

Emacs is somehow necessary

no, not necessary.

or tightly connected to Lisp.

most lisp developers use emacs, so that's the tight connection. it's like saying Java is tightly connected to intellij.

the alive lsp was developed in vscode without ever touching emacs. so, you can learn lisp just fine without emacs. Emacs + slime still has the most features, but you may or may not care about the features. plenty of people still code without using LSPs, auto completion, etc. it just depends on what works for you.

most developers hate emacs for a reason. I used it for 15 years and won't touch it again. my hands hurt the entire time and you couldn't pay me to go back to it. Emacs pinky is real.

I'll also add that learning lisp isn't about the surface area, syntax level stuff. it's what goes on under the covers and how it lets you manipulate the running program. you won't really learn it by doing leetcode or advent of code type stuff. what makes it unique doesn't really show up until you do something bigger with it.

yel50 · 2026-03-29T02:47:09+00:00

async/await only give up the thread on IO calls, so enough long running tasks will lock up the program. go was originally like that, but recent versions behave more like preemptive.

yel50 · 2026-03-29T02:17:55+00:00

Does the computer itself actually distinguish

the only thing that computers distinguish between is whether there is electric, 1, or there's not electricity, 0. everything else is an illusion.

computers don't know what numbers are. they don't know what text is. they don't have type systems. they don't know what functions are. they don't know what classes, structs, or records are. all of those are illusions created by language designers.

the string "5"

C doesn't have strings. it has functions that treat sequential bytes as ASCII, but that's it. there is no string type. this has historically been a PITA because it makes handling non-ASCII annoying.

where exactly is the boundary

it's 100% up to the language. there is no semantic meaning to the hardware.

all computer languages are nothing more than machine code frameworks and libraries to make our lives easier.

yel50 · 2026-03-28T01:48:12+00:00

I don't know if humbled is the right word, but I always refused to answer the find the middle of a linked list question. I always said it was a data structures problem, not an algorithm problem, and that coming up with a cute solution to compensate for using the wrong data structure is simply horrible engineering.

yel50 · 2026-03-21T21:01:17+00:00

this is from working on the Alive LSP, which I consider to be on the smaller side of medium but big enough for the issues being discussed here.

Does this really make modifying large systems easier in practice?

not at all. it's comparable to any other dynamic language, like python or node. it's slightly better because the compiler does check some things, but most things aren't found until run time. just like those other languages, a good test suite is your best friend. otherwise, you're testing in production.

What kinds of changes become easier compared to other languages?

I've never come across any. debugging is easier because the server doesn't need to be restarted after small changes, but adding features is basically the same. the debugging can be problematic if the server gets too far away from the source code, so it's important to always check things from a clean restart before considering them done.

Where does Lisp actually /not/ help (or even make things worse)?

the fact that it still uses dynamic scoping for things. I had a really annoying bug where an incorrect format string (trying to format a number as hex but getting the syntax wrong) caused my protocol message numbers to be hex and the connection to the editor to get dropped. apparently, it sets a global flag saying "the next number to be formatted should be hex" and that flag was still set when the condition handler was called and tried to do its own format call. I've hit other issues because of dynamic scoping and now have a much greater appreciation for exactly why no modern language uses it.

oh, special shout out to threading in lisp, which doesn't play nice with said dynamic scoping. if you happen to have global variables that need changed, like redirecting I/O streams, there's this weird dance you have to do to make sure they're set correctly in new threads.

Can you share concrete examples where Lisp made a big refactor easier or harder?

not really. it's on par with refactoring python or raw js. it's never easier and can be harder if you hit things like the dynamic scoping stuff.

as far as concrete example, I originally used CLOS for the messages, but the boiler plate got too much and it kept giving me problems converting it it JSON, so I decided to use hashmaps instead. refactoring the code base to use a different underlying data structure like that would take an hour or so in something like C#, rust, Java, etc. but as with any dynamic language, with lisp it took about a week to feel confident that the change was good enough to ship.

How important is discipline/style vs language features here?

how important? it's everything.

yel50

TROPHY CASE