I've generally preferred AppImages because they're just a single-file (in appearance) binary I can put in a ~/bin folder and run. Flatpaks require using an external tool to run them, and update them, and there's confusion whether you need the --user flag or not, and after every graphics driver update on the main OS you need to upgrade all the flatpaks again... It's so much of a hassle. The permissions isolation is nice in theory but firejail works for that too, arguably better in some ways.
In the space of retro gaming, the DuckStation devs recently had some drama (I think primarily with Arch users) and it resulted in purging the flatpak builds, now there's only an AppImage. I'm sure much righteous rage etc. like this post but against Flatpak or who knows.
My only experience with Flatpaks is on Fedora Kinoite and Silverblue, so YMMV.
Flatpaks are updated at the same time as the system with the GNOME and KDE update GUIs, or in one step from the command line with "flatpak update" (or "sudo dbus-launch flatpak update" when running outside a graphical environment), and I've never run into problems with graphics drivers, though I've admittedly only used them on systems with Intel and AMD GPUs supported by in-tree drivers (but what you're saying makes sense because Flatpak runtimes do bundle user-mode graphics driver components).
While you're not wrong that running Flatpaks requires an external tool, installing them creates both symlinks to wrapper scripts in a common directory that can be added to your PATH and launchable desktop application icons in GNOME and KDE that work no differently than those for applications installed through other means.
The wrapper scripts and symlinks have qualified names, e.g. "io.mpv.Mpv", but that's trivially fixed with an alias or additional symlink if desired.
The only problems I've run into with Flatpaks are limitations due to sandboxing, e.g., the Wireshark Flatpak can't capture packets, which makes it useless in common scenarios.
"--user" is for working with per-user Flatpaks, rather than system-wide Flatpaks, which I've personally never had any reason to use since all my Fedora systems are personal, but it doesn't seem any more confusing than similar switches in other package management systems.
I'll keep using Gentoo, sorry not sorry. I agree that if my goal is to ship something like a game it needs to be easy to run or people won't play it, chucking an ebuild at them would not be helpful.
Pedantic but Lisp is not "untyped". (Neither are JS or Python.) All data has a type you can query with the type-of function. The typing is strong, you'll get a type-error if you try to add an integer to a string. Types can be declared, and some implementations (like SBCL) can and do use that information to generate better assembly and provide some compilation-time type checks. (Those checks don't go all the way like a statically typed language would, but Lisp being a programmable programming language, you can go all the way to Haskell-style types if you want: https://coalton-lang.github.io/)
Not really in the Lisp sense. If you consider how people typically develop and modify Python code (edit file -> run from beginning -> observe effects -> start over) and how people typically develop Lisp code (rarely do "start over" and "run from beginning" happen) it becomes obvious. Most Python development resembles Go or C++, you just get to skip the explicit "compile" step and go straight to "run". The Python "REPL" is nice for little snippets and little bits of interactive modification but the experience compared to Lisp isn't the same (and I think the experience is actually better/closer to Lisp in Java, with debug mode and JRebel).
I agree with you, but a Python REPL in Emacs (using the ancient Python Emacs support) is very nice: initially load code from a buffer, then just reload functions as you edit them. I find it to be a nice dev experience: quick and easy edit/run cycles.
Contrary to the blog author I don't really believe this.
> How does traditional human use the REPL impact AIs ability to use one language over the other?
I don't think it does very much other than it's not the normal workflow for people vibe coding. Lisp doesn't require you to develop with an interactive mindset, but it enables it and it's very enjoyable if nothing else. Vibe coding workflow is prompt -> plan / code generation / edits -> maybe create and run some tests or run program from start -> repeat (sometimes the AI is in a loop until it hits some threshold, or has subagents, or is off on its own for long periods, and other complications). The layer of interactivity is with the AI tool, not with the program itself. You can use this workflow with Lisp just fine. Sometimes an MCP tool might offer some amount of interactivity to the AI at least, e.g. I've never tried to use an AI to do Blender work but I imagine there's an MCP that lets it do stuff in the running instance without having to constantly relaunch Blender. Blender has a Python API so the AI with no eyes might even be decent at some things nevertheless.
Others than the blog author report using something like https://github.com/cl-ai-project/cl-mcp that lets the AI develop more bottom-up style with the REPL, perhaps even configurable to use a shared REPL with the human, where programs evolve bit by bit without restarting. I trust their report that it works though I don't really have a desire to try it. If an AI barfs a bunch of changes across several Lisp files and I want to try them out without restarting, I can just reload the system (which reloads the necessary files) on my own separately. I also don't think representation in the training data is that important at least to frontier models because they express ever more general intelligence which lets them do more with less. This is further suggested by them being decently good at things like TLA+ and Lean proofs, which don't exactly have a lot of data either.
> How do you know this?
I've at times been a Java developer, a C++ developer, a Python developer, a PHP developer, a Lisp developer, and others. I read about and observe how people develop their programs and how commercial tooling advertises itself. Hot reloading tooling technically exists in a lot of places and gets you some of the way towards what Lisp provides out of the box but it's not used by the majority and usually comes with a lot of asterisks for where it will fail. I'd say one of the biggest differences with a lot of Python code vs. other langs is the prevalence of jupyter notebooks, but that's more similar to literate programming styles than Lisp styles, and unlike Lisp or literate programming (though I'm sure there's at least one exception) jupyter notebooks are typically used for tiny few-hundred-lines stuff at most, not large projects.
As an example of what's out of the box in Lisp, compile is a function you can call at runtime, not a separate tool, inspect is another function you can call at runtime that lets you view and modify data, and the mouthful update-instance-for-redefined-class method is part of the standard, so you have optional custom control over class redefinitions modifying existing objects rather than just "invalidating" them and/or forcing them to keep using older copies of methods forever, or filling new fields with default values (though this is usually a fine default), or like default Java debug mode in eclipse/intellij saying "woops, we can't reload this change, you have to restart!". I like to advertise JRebel because it doesn't have as many limitations and goes very far indeed by working with the whole Java ecosystem. e.g. XML files that under normal development are used to configure and initialize objects at program start time, changes to which require a restart, are monitored by JRebel and when changed trigger reinitialization without having to restart anything. That's the Lisp way, though in Lisp you'd have to setup your own XML file watchers for something like that. (Djula is a Django-inspired example for web template files, it does reloading by just checking file modification times. One could use something fancier on Linux like inotifywait. Though some Lisp developers just write their HTML with s-expressions and so changes to a page are just recompiling a function like normal development rather than saving a separate mostly-html template file. Lisp gives you many options of how you prefer to develop and deploy changes to a website. I like to ship a binary.)
I think the prestige, overpopulation, and pollution arguments all suck. The important differences are that the poles are not political free-for-alls that people can just colonize, and everything is still 1g vs. Mars' 0.38g.
I've done some experimenting with running a local model with ollama and claude code connecting to it and having both in a firejail: https://firejail.wordpress.com/
What they get access to is very limited, and mostly whitelisted.
There is already much snake oil sales and marketing going on, it's already enabled by arguments that are not based on bodily autonomy, which suggests that a move towards more respect to bodily autonomy will not noticeably increase such snake oil. The resistance to homeopathy has not gone well. I actually believe the resistance is actively harmed by making legit chemicals harder to get instead of easier. When people can easily get the good stuff that works there's not much of a market for the easy to get snake oil that doesn't.
You can pirate a copy of the DSM-V and see the diagnostic criteria for yourself. It's particularly interesting to me (as I believe the field has "crystalized" more than it has right to) that two people can be diagnosed with "ADHD" but share few overlapping symptoms. Separately, fMRI evidence is still not solid on its own, it has to be paired with stronger science to be at all useful, but even so studies based on it tend to suffer from numerous problems. The most infamous case being a "study" that found brain activity using fMRI of a dead fish. That was in 2009. In 2020, Botvinik-Nezer et al. published a paper about 70 different research teams analyzing the same fMRI dataset and producing wildly different results. It's a blunt instrument but people are deceived into thinking it's really solid; it's not.
What a strange post... The linked sl4 source (http://sl4.org/crocker.html) is short enough it could have been quoted in full. It's Yudkowsky's version, I think this is the first I'm hearing via jandrog's comment that it's not exactly faithful to the original (which I presume originated on an extropian mailing list). On the SL4 mailing list, people would sometimes join and note that they operated under the rules. Stuart Armstrong had an aside to such a declaration once:
"I'm not convinced that Crocker's rules are particularly useful
(rephrasing the same idea to make it more polite doesn't lose
anything, can be more convincing to the target, and will often
generate more insights in yourself than a curt dismissal), but it's up
to everyone to choose their approach."
I think that aside is part of the same strangeness and confusion as this post. Operating under the rules is something you do for yourself -- the "begging" that you're doing to other people is asking them to communicate to you in a manner that is optimized for information, not for being nice. The problem isn't necessarily that people dance around the issues (though that can and often is a problem), the problem is that they simply won't communicate the issues or other information in the first place, and so leave such out, especially if they can't figure out a nice way to say it. Also, if you are writing for someone who is operating under the rules, for you to respect their wishes that doesn't mean you have to be rude or omit politeness or be blunt, it just means you should include all the information you want to say, and not worry about it not being phrased nicely, though of course you can phrase things how you please.
To beg others to follow Crocker's rules is basically saying "I am tired of having to use delicate language and sometimes having to avoid talking about things for you, can't you just grow up and let me be lazy and direct and sometimes rude as I tell you everything I have to say?" There are more sensitive ways to make such requests (and ruder ones too), it's probably better to use such methods if you want people to adopt your preferences in receiving information. It's also important to ask if people want certain information in the first place -- I asked a departing intern once (who sadly ended up not being very strong, at least compared to most interns our team had) if they would like some more candid feedback from me before they left, and they declined. That's fine. I think it's usually better to lead by example and just ask people to be direct if you notice them communicating to you in overly sensitive ways and perhaps leaving important things out, and link them to Crocker's rules if you want. Often the rules aren't needed and you can just create a direct and information-rich culture to begin with, or in specific circumstances (e.g. code reviews) use short hand symbols like "Nit: " or "Blocker: " that compress all the niceties you'd otherwise be encouraged to say. When someone new joins, they can read the room, but pay attention if some people express things like "I wish people were nicer here". Maybe they're a snowflake who needs to grow up, or maybe your environment is just toxic and so unpleasant and full of assholes that it gets in the way of productive work. Again, Crocker's rules is about receiving information independent of nice/rude presentation, it doesn't require rudeness or even directness or bluntness since none of those are automatically implied by efficient communication. (Efficient communication optimized for information is not just a character count.)
A personal example from 12 years ago: after I was rejected after an onsite job interview, with such rejections notoriously (and for sound legal reasons) omitting many details about the precise whys for the rejection, I invoked Crocker's rules in my request for further feedback and actually received some more useful information than the initial rejection. "The particular role ... required more experience ... There was also the sense that the manner in which you had answered questions came off a bit rough around the edges ... We tend to look for engineers who are very curious, passionate, and large drive/motivation to learn more - it seemed we didn't get those senses from you." The last bit especially was kind of an oof, but it was certainly useful feedback that going forward I, believing myself to actually be curious and wanting to learn more (passion has always been a problem though), would need to make more efforts to show those traits.
In the space of retro gaming, the DuckStation devs recently had some drama (I think primarily with Arch users) and it resulted in purging the flatpak builds, now there's only an AppImage. I'm sure much righteous rage etc. like this post but against Flatpak or who knows.
reply