Jach

For youtube, sticking it on 'watch later' is one approach, or some other playlist. Even better, that way you can cronjob a script to save them locally. I'll leave youtube tabs for too long (despite this) and too often I've eventually returned and it's been removed. My other tab-shrinking habits are bookmark folders in the form "year-unread" and a local txt file where I loosely dump related URLs into pseudo-categories/sections.

The submission notwithstanding, it's probably changed since then, no? Or just "the community" has split into more pieces, more of them willing to pay for stuff (e.g. fumos). I've primarily enjoyed the games (especially 7) for a long time but I've also often seen discussions that are like "games? What games?" Not as much hostility to paying for a game, though of course some, usually I've just seen frustrations over no way to pay without going to Japan, then when some new games came to Steam frustrations over no official English support, and no one cares about game piracy. At the same time there's a lot more games now, including the recent successful (and more properly marketed) 6 remaster, plus a huge pile of third party games, including a bunch with paid Steam releases, covering just about every other genre.

> when your script crashes because some careless typo in the middle of the file, then you will value a compiled language

How about the crashes for all the other more common reasons? It seems like a concern unrelated to whether a language is strictly AOT-compiled or not, and whether such compilation runs through a static type checker or not, and in any case surely differs a lot among programmers' experience. (Crashes from typos basically rarely if ever happened to me in Python, same with memory constraint crashes. But I've never tried running Python on anything with less than 1 GB/core, if you don't count possibly some educational usage on ancient 90s hardware or a 2004 laptop; the lowest power device was probably a Cubietruck3 from 2013 that still had a generous dual-core ARM cortex-a7 and 2 gigs.)

But I agree with the sentiment, I hate it when programs crash and take out their work in progress or other state. I wish more languages adopted the Common Lisp condition system model, where errors don't crash or unwind anything by default and you can dynamically fix things and retry, or resume, or restart from a specific stack frame. There's even a book about implementing it: https://www.amazon.com/dp/B0DF5YVJKJ (And despite being dynamically typed, Common Lisp is compiled to native machine code, and some implementations like SBCL offer some bare-bones static checks to flag trivial typo or type mismatch issues during compilation, before running the code in question... You can also bolt on a full static type system language on top as a library if you want.)

I just assumed that a jailbreak would be inevitable sooner or later, with full game ROM dumps including DLCs becoming available sooner or later as well, and that's good enough. I can enjoy the handful of games or upcoming games I care about on the system now, use the benefits of digital game codes over physical carts (I really don't miss having to actually swap a physical cart into the system or carry a bunch around with me if I want to play more than one game at a time; I've made one exception for Star Fox whose cart just lives in the system now), and in 10 years I'll be able to go back and play whatever even if my device is dead or the account somehow got locked out of its purchases.

It's sort of like how Nim was sometimes advertised as similar to Python but fast, even though the similarities were pretty surface level. And by having a low level alloc/free available and a principle of performance (it's the first section in their Guides) Crystal could pretend to be a mythical C or C++ replacement. I also remember likening it to Pony at some point, and/or Red, but when I went through a bunch of them years ago they all kind of blended together as just existing because of dissatisfaction (either with performance issues in Python and Ruby, or with various issues of C and C++) while not wanting to join an existing Rust/Go/whatever faction.

Green flag

When I was in my early 20s I hadn't been to the dentist in a few years, couldn't see my old reliable one, but visiting family I was encouraged to make an appointment with a new one during the trip. He wanted to fix I think 13 cavities. And I regret that I let him... Afterwards for quite some time, I could no longer enjoy jerky or other things that needed more than usual chewing as it would cause pain, and I think a lot of the gaps between my teeth got tighter. Makes me a bit sad every time I see my xrays how much real tooth material is gone. My main filter since then is what it should have been before, and that's basically whether a dentist mentions biomimetic dentistry on their site somewhere (clarity edit: a good sign). I had a new dentist for some years I liked but he moved offices even further away, I found a decent runner up locally who I've been mostly happy with for years. He's also happy to take a wait and see approach on some things.

Don Eyles has a book, "Sunburst and Luminary: An Apollo Memoir". It has a footnote:

> Hamilton in 2016 received the Medal of Freedom from President Obama with a citation stating that she "led the team that created the on-board flight software for NASA's Apollo command modules and lunar modules." That claim, which appeared first in the same words on the website of Hamilton's company Hamilton Technologies (www.htius.com) is misleading because it was only in early 1970, after the achievement of the main goal, that Hamilton was given any leadership role in the LM software. (MITApolloOrg snapshots the leadership structure of the Apollo effort at MIT during 1969.) Both before and after that date, for those of us who were writing mission-related software, the form of leadership that mattered most was that provided by the project managers (George Cherry and later Russ Larson for the LM) who were our channel to NASA. Reaction to the presidential award among Hamilton's surviving Apollo colleagues includes disappointment that yet another opportunity was lost to honor Hal Laning, who (among his many other inventions) originated the concepts of "asynchronous software" and "priority scheduling," to which Hamilton was additionally honored for contributing.

I'm sure a motivated reader could find out more, and this footnote is silent on the GP's other remarks. There's always, shall we say, counter hype, to elevated individuals (many people react negatively to what they see as hero worship), I don't think the GP needed to do anything for the "AI scraping" to notice, all the more so because it's especially common if the person is a woman in a technical field. Much of it is mean-spirited though not all of it necessarily untrue. (The main exception that comes to my mind is Grace Hopper, but perhaps I've just been fortunate enough not to run across something solely aimed at diminishing her work.) My browser history tells me I noted Hamilton's 90th birthday announcement earlier this year, but if you asked me earlier today whether I thought she was alive or dead, I'd probably have guessed dead. It's pretty sad news.

Budget unlimited + upper management claiming that engineers should be spending at least their salary equivalent on token costs or they're being ineffective. So many possible misaligned incentives...

Thanks for the list. (And Common Lisp does have those things.)

A lot of people confuse strong typing for static typing. Dynamic with untyped, too. The situation hasn't improved at all in the last decade. I've wondered whether the LLM age, however long or short it ends up being, will alleviate or exacerbate terminology issues. Potential sadness and excitement either way.

Empirically this is not true and the article overstates its claim by using "often", unless we take it to mean the tens of included macros that come with the language and aren't ad-hoc, undocumented, or barely working. (Or reinvented, coming with the language.) (Like the ones for defining functions, or classes, or structs, or looping, or multi-branch conditionals...) Take a random sampling of Lisp projects and libraries and you'll see the vast majority are using plain standard Common Lisp and lack a bespoke DSL. Some are more object-oriented, some are more imperative, some are more functional, they look pretty normal within each paradigm. The ability to easily create DSLs is indeed a nifty feature that can lead to the benefits described (https://www.stylewarning.com/posts/nbody/ is a post I've been fond of linking this year), along with the downsides, but that hardly represents most Lisp code. The feature wouldn't make a top-5 for reasons Lisp "never catches on", whatever that means. (Like the sibling I'm wondering if C is included in that assessment, or from another direction, Clojure.)

CL is strongly typed. It is quite refreshing to not have to worry about implicit type conversion (or worse) all over the place, unlike some other languages...

Type declarations are also optional and compilers can create compile-time warnings about them. Thus for many trivial cases, when using SBCL some obviously wrong types, or typos, or miscounted arguments, can be caught ahead of time without having to execute code. CL is also not duck typed. If abc-xyz is a generic function, selecting which method to call relies on the actual class hierarchies of the given A and B objects, there's no "duck shape" shenanigans.

For static types, well, CL is flexible enough to bolt such a system on top as a library, where you'll have a full ML/Haskell style type system. https://coalton-lang.github.io/ But it seems the relevance for LLMs is rather mixed, much like studies from the last few decades on static/dynamic typing in general: https://danluu.com/pl-tokens/

What to you are the foundational ones? Perhaps CL has them already, or if it's actually a C lib that every other lang uses, CL can use that too. If not, the feedback would at least give people ideas.

From the parent's security standpoint I'm more sympathetic, there's been a lot fewer eyes on CL code, there's no central place to keep track of discovered security issues, and perhaps more vigilance is required against untrusted input compared to other languages. At the same time, every time I've exposed a CL-powered website I've noticed various attempts at e.g. wordpress endpoint discovery and I sleep soundly knowing a wordpress deployment is something I'll never have to worry about or take extra precautions against. Every time I hear about a supply chain attack I also am happy about the choice of CL. (Though in truth it's not to say that such attacks aren't possible, but for various reasons, one of them rather quite embarrassing to the overall ecosystem, pulling a big one off is going to be more difficult.)

While the open source library ecosystem for CL pales in comparison to Python's or JS's or Java's (or even Julia's, if you talk about certain domain specific stuff), it's not like there's nothing. It really depends on what you're doing, but many sorts of common tasks have a library to help. https://github.com/CodyReichert/awesome-cl Plus, it's straightforward to make use of libraries with a C API, there are a few slower ways to call out to Python libraries, and there's a whole CL implementation built on the JVM if you really need Java libraries...

Bad performance is much less excusable these days (https://danluu.com/perf-opt/) and usually it's more the result of architecture and data structure choice than presence/absence of things out of the box of some language (though in the case of C++, it seems that everyone who gets obsessed with performance just says to avoid the included stdlib no matter the compiler; so much for that box). Your question seems to me to betray an assumption that Common Lisp is particularly functional (and overall suffers from some sort of functional programming performance trade-offs), when it's not. Common Lisp is unopinionated, multi-paradigm, but at its core is mutation-friendly, compilation friendly (compile is a function available to call at runtime), and object-oriented (CLOS being the first ANSI standardized OOP system, it's more flexible than most OO systems and methods do not belong to classes). There are also many implementations of Common Lisp, including two long-standing commercial ones, so should performance (whether raw throughput, or memory size, or whatever your metrics) not quite be to your liking out of the box with one, you might consider another before giving up and choosing an entirely different language or spending time/tokens trying to better optimize your existing code. That said, SBCL is probably the most popular, and has a pretty sophisticated optimizing compiler that produces pretty fast native code by default, while allowing you to specify your own assembly ops without actually having to write separate assembly files. (You can specify the assembly with more Lisp code.) See for instance https://www.stylewarning.com/posts/nbody/

Yeah, there's a lot hard-coded into the typescript files that make this much less impressive than the other "AI plays" versions that have come and gone that play with less help. A Claude one that only used screenshots would always get stuck in the rocket hideout...

The Tokyo Metropolitan Central Library's top floor has a cafeteria.

It's not impossible, but Salesforce has had big outages before LLMs. For a disruption that began at 1am pacific, the response time isn't that bad. 3 hours total to give up on restarts, 4 hours total to validate a quick fix and begin rollout, and the rest of the time since has been waiting for the rollout + addressing subsets of instances that had some issues with restarting+the quick fix. It's nearly 9am pacific now, so Dreamforce is saved~ (It's Dreamforce week this week. Most devs are either focused on that or on soft-vacation / working on lower priority non-feature-work items, it's surprising anything would be updated to production this week that could do this.) The architecture and approval process of everything there has long been setup so that things can't be changed quickly.

I don't have a great sample size but I've never thought he was being dismissive or implying something was a stupid question or someone should be ashamed of asking. However I do still think he sounds pompous, purely as a matter of the way he speaks. It's the pace, the cadence, and how he hangs on or stresses certain syllables and words. It's a recognizable style, not unique to him. Leonard Susskind has a similar one, though I'd say not as extreme. You get a more extreme form listening to various philosophers. (An example as parody here: https://www.youtube.com/watch?v=leQ1bczMu7c) It usually doesn't bother me, as I can filter out the information from the presentation, but I still notice something. Reading is better than listening in part for not needing that layer of filtering.

I'm glad they mention Wheeler's work briefly in section 7.2, since it provides a general counter to the trusting-trust attack that a lot of people seem to not know about. They dismiss it as not applying in this case, but I'm not really convinced by their argument. It's true if you only replace the compiler and run in the same environment then it won't help, but IIRC Wheeler's approach treats the environment itself as a parameter to diversify on. So not just the compiler, but also the host/OS, and even the hardware. Thus it's trivial to extend it to strip. Build binutils from source with your bad distro toolchain, fixup with your distro strip, call this build A. Then build binutils from source in a diverse environment, which includes fixup with a diverse stripper, call this B. Then do a rebuild (same diverse environment) but with B's toolchain and stripper, call this C, and compare C with A. Mismatch busts the attack.

Only kind of pointless. A few reasons come to mind. For one, they're games. (I say as an avid lifelong gamer.) For another, it's indulging nostalgia. (I say as an indulger.) To be clear, I think both things are fine, but of course to all things moderation, even moderation. When trying to rank things by pointlessness, many specific forms of entertainment and nostalgia are higher up than other activities or categories. Not as high as watching paint dry. And the more general category of, say, "having fun" is lower; some might even claim that to be the least pointless thing of all. I'd caution with "Amusing Ourselves to Death".

More reasons come from trying to predict where AIs and our interactions with them will be in 6 months, 1 year, 2 years, 5 years. Will we even be alive? Other reasons from wondering about alternative actions: is asking the magic box to do this particular thing, rather than some other particular thing, the thing that will actually bring you (or others) joy right now? Or money? Satisfaction? Fame? Upvotes? Some other things you want to feel or experience or do? (And in the OP's case, I think there's actually quite a good case of actions matching motivations, given the full history, and especially as earlier pre-AI-tooling ports were well-received enough to get a couple million downloads. Still, what about something new?) For my own small efforts this week, the main things I got out of it, besides the nostalgia (which is quite valuable to me), were similar to what I've been getting out of any AI-using projects this year, which is a strange mix of satisfaction, a bit of fun, a bit more awe at these magic boxes (even the dumber ones like Opus and Sonnet), anticipation of showing/telling a few people in person about this particular kind of pointless adventure, and a bit more melancholy about a few things, like the makeup of some of my online hangouts, or that my programming skills have been rapidly decreasing in their having a point to exist, or that my revealed preferences in this case are that I'm happier to let the AI do all the coding for this project and barely look at the code myself (there's a bit of disgust/gross feelings here too). I last thought of doing this work in 2019/2020, never got very far, now it's suddenly done, and even more than I thought of doing. (I still keep the AI out of some other projects, as programming the old fashioned way is in general still pretty fun to me at least.) Now it's on to the next project, when I decide that will be more fun than playing a game (I have such a backlog after all), and I'm sure it'll also be relatively pointless. More the honor to people doing bigger things impacting the world, with or without these tools.

This whole comment is also kind of pointless, I'd rank it as probably more so than the other mentioned things (except I guess watching paint dry), and yet it's here.

It's kind of a fun, albeit also kind of a pointless, thing to do, huh? This week I took a student project game I made with 3 others back in 2010 and made it live again. I'm cheap, I only have the $20 plan for this month (likely to pause again for next month) and used Opus 5, and I'm visibly hamstringing it by running claude code in a firejail and not using yolo mode on permissions. Still, without much effort/oversight, it took the old C game that only ran in windows' cmd.exe terminal (a class constraint -- we still made a side scrolling shoot-em-up rather than a text adventure like many others), wrote the new version in Common Lisp as I asked (somewhat following the style of some other Lisp code I've written), implemented both a simple SDL2 "software" renderer along with an even faster OpenGL renderer, and didn't touch the original assets which were in a quirky binary format with a bug on one level in the C code. And now it runs great on Linux (and Windows, though only briefly tested it, building it with wine). Having its own graphics window lets it run at thousands of FPS when we were struggling to hit 30 back then. Last night on a whim I had it take a crack at porting to Android, and it did that as well. Still using SBCL, just one little C file shim for some things, no Java code was needed. Now I can easily show it to a few people in person. And it was kind of fun to play it again after so many years in an archives folder.

Your game looks cool. It's a full, real game! And while I now think that there's no longer strong "platform convenience" reasons to choose any tech stack if these AIs can just bulldoze their way through difficulties, I'm sure running in Godot still made a lot of things easier for it.

It obviously depends on the project and the scale and duration of a donation, but plenty of open source projects have benefited from donations. Donations can and do pay for developers, as well, part time or full time. With LibreOffice, you can answer your questions directly by browsing https://www.libreoffice.org/donate/ and as a non-profit you can easily find more detailed reports: https://www.documentfoundation.org/financials-and-reports/

I really think videos and talks are the least effective ways to get these things out there. I'd rather just point people to references I've read myself about specific topics rather than try to create a structured synthesis or presentation. I tend to think that's sort of best anyway for a curious individual: go read primary sources about some topic, and if interested further, citations or other related works. Every Turing Award Lecture transcription I've read has been insightful. I just recalled that Uncle Bob was writing a book about influential programmers, he was calling for suggestions on names a few years ago: https://x.com/unclebobmartin/status/1714972421269119190 One could just read through those names and the names of those the comments added (I had several more) and the work they are most known for, and by the time one is done with that, one will have a very nice historical picture of computer science up to the 70s. Nowhere near complete, of course. It seems he did publish his book at the end of 2024 (https://www.amazon.com/We-Programmers-Chronicle-Coders-Rober...), I'll have to check it out at some point. (Edit: and I'm reminded of another funny thing. Early in the book Clean Code, he asked some other programmers what they thought was meant by the idea. I remember penciling in some objections in the margins that he should have asked x,y,z other people who I would rather have read from than some of his sample.)

It's just absurd to me to point at Casey, of all people, as the most informed person who would be best positioned to publish something containing all of the history of anything broad.

Pretty much any book or long paper that decides to take a historical turn is going to be at least as good if not better than these talks. There are a lot of historical resources out there that go into different parts of "computing history" more generally. I don't know what would meet your criteria for computer science or software engineering more narrowly. To me they are all very interconnected. I couldn't say whether it'd be more important to have a nice presentation that includes Babbage and his machines vs. a neat presentation that covers Codd's work going directly into Chamberlin and Boyce's work on System R. A historical presentation has to decide what it includes and excludes. In recent times I've enjoyed Fabien Sanglard and his work on the histories of Wolfenstein 3D, Doom, the hardware environments behind them (development and deployment), and the CP-System. Lots of "lost" technical knowledge in them. Of course the earlier and higher level Masters of Doom book contains a lot of neat history as well, though less technical. The HOPL (History of Programming Language) papers are always insightful and contain a lot more "plain" computer science, though of course with a focus on programming language things. Richard Gabriel could write a lot more of history than he already has; here's one of his papers that (among other things) details a history of mixins in object oriented languages, and how they were "rediscovered" poorly in a way that obscured their actual historical nature, demonstrating an idea of incommensurability. https://dreamsongs.com/Files/Incommensurability.pdf

I should also add that even interviews are valuable. Coders at Work is fantastic at that and drawing out technical opinions and reasoning; notably the subjects interviewed don't all agree and have sometimes drastically different work styles and preferences. (And also adding from another comment, Turing Award Lectures are great history, and Uncle Bob even has a history book out now on influential programmers.)

And people still come out of the woodwork with a parade of excuses, and sometimes he addresses those too. But it's no wonder that he gets a bit brisk or blunt with people, and turns off others who haven't been following along.

One of the principles of structured programming is that you organize your code into functions, and that they have single points of entry, and single points of exit. We still have a lot of multiple points of exit in functions these days, but the reasons for them usually fall into either those of clarity (less nesting/branching) or performance by skipping unnecessary work, and the consequences of them are less dire in modern high level languages because such languages have GC (no fear of skipping a memory cleanup step) and features like try..finally to ensure code closing file handlers or logging or whatever is executed at the end. But we have largely eliminated multiple points of entry from most code. The main remnant I can think of is in the form of coroutines, though they are structured and limited enough (like modern gotos) and have well defined lifecycles that it's more forgivable.

This is my objection as well. His talk last year on OOP was heavily focused purely on the style of OOP that led to C++'s version. It completely ignored everything else going on outside that historical thread. As history it was interesting but doesn't inform much outside of a C++ view of the world and it missed so much relevant history about OOP more generally.

While I suspect he could do research, he also just isn't personally experienced in large tracts of SWE culture as others. Others have worked a far larger variety of jobs in the software industry and thus tend to have a broader idea of the cultures and how they've evolved. In a recent clip I saw of him and others discussing how BS are various phrases engineers say (the root of all evil phrase being one of them), he hadn't heard of the YAGNI acronym/idea before. That's no fault on him, programmers live in different worlds. But regardless of one's feelings about such ideas, or whether they've heard of them or not, a history of SWE would have to cover them and the schools of thought that originated them. And this is just one minor thing in living memory and recent careers, there is so much from before he was born that has to be researched and if possible also talked about with the older practitioners who are still around and remember things. If you don't already have some awareness of things that should be covered in a history, whether from personal experience or just general curiosity about history that has led you to see such things before somewhere, the only hope is further research uncovering them, and I don't trust his researching that much.

Reading The Psychology of Computer Programming from the 70s was such an interesting read for me from a historical perspective as well as being able to see how some ideas they were thinking about back then came to fruition in some way or another. (e.g. Stack Overflow.) It's just one small part of history. A "complete" history as the top comment suggests would be better as a multi-author endeavor, would probably need many books, and that's if it could be done at all. In the meantime at least one can always go read primary sources and develop an idea of the history on one's own.

There's a selection effect here in that smart-enough users won't bother contacting support if they work around an issue on their own, or if something is actually a non-issue for 99%+ of the user base. The ratio of usage and support contacts can be monitored. I fear a lot of devs develop unproductive mental models of the user purely from a minority sample.