klibertp

4,939 karmajoined 14년 전

I'm a programmer and a programming language (both in theory and practice) geek. I advocate polyglot programming and have a site dedicated to it: https://klibert.pl/

Contact: The best way to contact me is to send an email to piotrklibert of fastmail.com domain. Or you can leave a comment here: https://klibert.pl/articles/contact.html or ping me on Discord: piotrklibert

Take a look at https://klibert.pl/articles/about.html for more info about me.

comments

12시간 전discuss

Yeah. In my GToolkit setup, I started with giving it eval. At first, it tried to "rebuild the world" for each task, but we gradually settled on a set of images for specific tasks that can be rebuilt as a separate step and are otherwise cached. That gave us fast eval, and it kinda snowballed from there. I thought I would need to implement some IPC into a live image, but the startup is fast enough that it doesn't matter too much. The agent now has both the textual source (in Tonel) on disk and can easily query a live image via CLI.

What do you think about making the agent write type annotations? There are built-in forms in CL, and in Smalltalk, I settled for pragmas for now. They are not checked, but since I started using them, I think the rate of one- or two-shotting solutions has gone up.

13시간 전discuss

> how relevant it was to share the same programming experience across environments.

Right. If you view the language as just a part of a bigger "programming experience", you can do with a worse language with better tooling (pathological example: (lack of) namespaces in many Smalltalks to this day). If you focus on language design above all else, you end up with either something pretty on paper (but never implemented) or something practical and (kind of) elegant, but it'll take 40 years to get the tooling to where you want it (and still won't cover many important capabilities).

Also, it's easier to swap languages if you focus more on tooling. From what I read, many Lisp and Smalltalk IDEs/environments were (and some still are) polyglot. I sadly didn't have access to them at the time, but I imagine switching from Turbo Pascal to Turbo C++ was easier than going from Turbo C++ to Visual C++? That said, tooling tends to break if the language actively fights it, so it's not like PL design is completely irrelevant.

> Which is why, given their linage, JVM and CLR are the closest big mindshare ecosystems that somehow still have traces of those features when using their IDEs and runtimes

Yes. The only problem is that those concepts/features become niche black magic (somewhat unavoidable for advanced features in "big mindshare ecosystem"). You can definitely compile Java classes dynamically at runtime, install them, and use them normally; however, outside of frameworks/IDEs/JVM languages, the ClassLoader is used mostly for loading static assets, and even simple reflection is viewed with suspicion.

Using Smalltalk or Lisp directly puts those powerful concepts "front and center", which a) is good for education; and more importantly, b) feels good when things click :) It could be an advantage for small groups of programmers, but from what I understand, it becomes a liability in large organizations. Pharo is especially bad at it, and GToolkit doesn't fix everything (they do a good job at providing tools, but don't want to maintain too large a patch set for Pharo, which is a good trade-off given their limited resources). But I'm replying to "Why Lisp (or When)", and in this context, Smalltalk is (IMO) the better direct alternative than JVM/CLR.

Depends very much on your harness and effective use of tools. For vibe-coding, stick to Python.

It can get good with the right setup. I made Codex work with GToolkit (similarly underrepresented, but technically impressive and a seemingly good fit for LLMs), but it took a lot of tweaking of the project structure, extensive instructions in AGENTS.md, and some custom skills (some borrowed from Gt4Llm, the GT's built-in model harness). Out of the box, it burned tokens and took way too long to implement even basic things.

YMMV - as with everything LLM-related - but I think without a similar setup, an agent instructed to write CL/Clj/Scheme/Racket will have the same issues. It might be better in an established, large project - but starting from an empty Git repo, I suspect you'll have to fight your way to productivity.

> So why Lisp (or when)

> [...] among its extensibility, its interactive environment, the REPL, and a lot of other features we haven’t touched yet. It is the combination of all of them that makes Lisp programming what it is.

Agreed. However, although the alternatives are few, they do exist. Today, I'd like to convince you (whether you're OP or a commenter) to give one of them a try. I'm talking about GToolkit[1]: Smalltalk/Pharo-based reimagining of Smalltalk as a productive environment for modern system design, analysis, and implementation. It's based on Pharo and its VM, but with GT-specific extensions and replacements, developed on GitHub in both Smalltalk and Rust.

I used both Common Lisp and Smalltalk over the years for some of my side projects. Technically, the environments are comparable: image-based, live, interactive development is central to both. Lisp is easier to fit into modern workflows: it's still just files on disk. If you ignore the REPL and treat the image as a bundler, you can have a Java- or Python-like development workflow. You can gradually adopt the more interactive ways of working with the codebase. Smalltalk was historically more of an "all or nothing" approach, but nowadays it supports Git-based workflows as first-class, with GToolkit providing additional tools directly. GT is tied to a single IDE, but that IDE is genuinely powerful, pragmatic, and easy to customize: the entire IDE is Smalltalk code[2] that lives in the image beside your code, so you can live-edit any part of it at any time.

The languages differ, most obviously in the object model (single inheritance and message sends in Smalltalk, and multiple inheritance with multimethods in CLOS), but I don't think one is strictly better than the other for the vast majority of code. You just need to structure your code differently. Both systems are very dynamic, so neither is like Java or C++. After quite a few projects in both, I am convinced that this difference doesn't matter.

Both languages have very simple syntax. Smalltalk doesn't have macros; instead, it has an extensible/replaceable compiler for method bodies. This capability is used, for example, for compiling grammars into parsers/lexers in SmaCC. It's not as convenient for control-flow abstraction as CL's macros, but Smalltalk tends to make them out of blocks (lexical closures with non-local exits) plus actions on thisContext. In practice, I never found either language too limiting in what I could express, and both have small, regular basic syntax.

TL;DR: Common Lisp and GToolkit Smalltalk offer comparable technical merits, with the most pronounced difference being GT's built-in, high-quality IDE, which open source Lisp lacks.

The IDE (and the capability to build cross-platform, but natively rendered GUI apps) is the major selling point of GToolkit, but the bigger reason to consider it is social. Lisp had a bit of a renaissance from 2005 to 2015, but ~it has since died down~ (EDIT: After checking a bit, it's more like there are similar levels of development now, but it's just varied, and I personally hit a few areas where nothing new happened for a while. Or in other words, the hopes of CL getting catapulted to mainstream by the wave of adoption didn't materialize, and the adoption seems to have largely plateaued, with a slight upward trend since then.) A lot of great things for Lisp appeared in that time: ASDF and Quicklisp being prime examples. Unfortunately, the momentum was lost, and since then, the rate of development has plummeted. It's still a solid proposition because of its stability, which means a lot of old code still works perfectly well, but it's a double-edged sword: it would take a hundred miracles in a row for CL to get a plausible M:N concurrency story, for example. This isn't true for Smalltalk, and doubly so.

There's a small but active community around Pharo, mostly academics and hobbyists (IME; and it's from a decade ago, so YMMV). Pharo itself is already a "Smalltalk-like" language, and it regularly gets features that are not in original Smalltalk (stateful traits and slots (reification of class and instance variables) are good examples). It continues to evolve, and each version brings notable improvements to the language, the VM, and the class library. In CL, since there are many implementations maintained by various groups and the standard is set in stone, adopting extensions to the standard is incredibly hard and time-consuming. You can, of course, commit to a single implementation, but there are only 2 or 3 implementations that are actively developed and trying to do something "new"; they are all experimental and incomplete. And while SBCL has quite a few nice features, its codebase was a bit hard for me to grok (read: days on end of banging my head against a wall, then giving up; I'm much more comfortable messing with Smalltalk bytecode compiler).

Secondly, GToolkit is driven by a group of coders[3] who have established a profitable consultancy. It's being developed around a single vision that the authors swear helps them achieve their projects' goals. Even if you're not sold on moldable development[4] as a methodology, GToolkit gives you all the tools you might need in a modern development and then adds tons of domain-specific tools and utilities that might be useful after just a bit of adjustment. The whole environment is built to make such adjustments as painless as possible, too.

The only problem I experience with GToolkit is the lack of structured, book-like documentation. The GToolkit book is closer to the PHP wiki or a bundle of tutorials than something like the Rust book. It's not that the docs aren't there - they often are, but finding them effectively is a bit challenging. I found that simply cloning all the repos that GT consists of (tens, if not hundreds, but there's automation for that) and pointing an agent to the directory with them is often enough to quickly find what I'm looking for (if the built-in Spotter fails and I'm too lazy to construct an in-image search).

TL;DR: GToolkit/Pharo move much faster than the CL world, and while the number of maintainers might be similar (honestly hard to estimate, though), the effort on the GT side is more centralized and, in my opinion, heads in a better direction. If you want an extensible, live, dynamic environment that shares many of Common Lisp's strengths, but is more polished, more actively maintained, and feels more modern, take a look at GToolkit.

(Disclaimer: no affiliation, just a programmer who likes to explore unpopular languages).

[1] https://gtoolkit.com/

[2] Some parts are implemented as Rust dynamic libraries and called from Smalltalk via FFI.

[3] https://feenk.com/

[4] https://moldabledevelopment.com/

3일 전discuss

Yesterday, Codex helped me resurrect a project[1] from 2013, where the code was published, but trapped inside an exotic format that can only be read by a single application. That application had ~14 breaking releases (rewrite everything!) over the past 13 years. Needless to say, no current version of the app can read the 2013 file, and no current system can run version 2.0 (it's now at version 14) of the app in 2026. Codex helped me create a containerized environment that pulled dependencies from that era, connected the container to my host GUI session, and successfully exported the code to normal-ish text files. It took half an hour (of Codex time, not mine) to check changelogs and try different version combinations. I was quite happy with the results.

Today, I wanted to capture screenshots every 5 seconds on a Windows machine. Codex created a dotNet project that compiled to a (self-contained!) bundle. It worked, of course, and I even ended up using it. The problem was that the bundle was 167 MB in size, held together by lots of XML config, and implemented the "RBGA-bitmap to PNG file" dumping from scratch; the whole thing was close to 1.5k lines of code. 30 LOC of PowerShell would be a perfectly acceptable solution here. I was... well, not impressed, and I would never show this solution to anyone, but it at least works and I didn't need to brush off my PS skills as a result, which is kind of good enough in this specific case.

As a programmer, I can immediately recognize when the LLM output is something nobody should ever see. It doesn't matter if nobody's going to see it anyway, I agree - yes, "one-user applications" fall in that category. However, when you mention <<"real" software>>, that changes the perspective. How would you know whether your software is "real"(-ish) or not? "Hey Claude, are we production ready enough right now?" That won't work.

TL;DR: requirements for code quality are hard to estimate, and code quality is something many professional programmers struggle to consistently recognize (not to mention achieve). Until the models get good enough to make good code a baseline, "real" software will remain hard to write, and better left to people who can recognize bad code quickly. That doesn't mean only professional programmers: plenty of hobbyist coders are "non-technical" in general. But at least for now, you still need to be a coder yourself to get consistently good results from the AI.

[1] https://pleiad.cl/research/software/gradualtalk

3일 전discuss

I think the end goal the author describes:

> I can imagine soon-to-arrive interfaces where you just drag and drop components while narrating your desires with your voice, the models able to perform the “brainstorming,” “planning,” and “work” — operations that can take ten minutes or longer today — in mere seconds tomorrow.

Is impossible without ASI and more. This very vision failed to materialize in the past (4th-generation languages?) and still routinely fails, not only with models/agents, but also with humans and entire teams of humans on the other side. For a model to be that useful, ASI is the first enabling factor, but it also needs to develop mind-reading hardware and software and convince people that it's not breaching their privacy. I don't think this is going to happen. Not this millennium, at least.

There is a good case for prototypes, MVPs, and personal mods. I can imagine more and more users making use of the freedom to modify the open-source code. Technically, it was always possible, but for a normal user, it was not a realistic choice (learn to code (long and hard) or hire a programmer (expensive and inconvenient)). Even for me - a programmer by trade - fixing bugs in random pieces of software I might use (or not) once in a while was something I very rarely had the spare time and energy to do. The capabilities of the current crop of AI models/harnesses make this WAY easier: cheap on a subscription and requiring much less of my time. But that's for personal code modification. Pushing vibe-coded changes to anywhere outside of my machine is still something I wouldn't do, because I can see how mediocre the output code is. Unless the models can always write code as good as the top 20% of human-written code, their output will remain a liability. It's OK if I'm the only user; it's wrong to push such a problem to others. The issue here is that non-programmers cannot recognize when the code is good enough, which is why I used the word "always" - otherwise, pushing LLM code to others is a coin toss whether it's helpful or detrimental (for the project, the maintainers, and other users).

4일 전discuss

I don't think this is true. Computers are still computers, and code executes (mostly) deterministically. What computers struggle with is making sense of unclear inputs, precisely because of their determinism. OCR, speech-to-text, and computer vision all proved extremely limited when tackled purely deterministically. The whole "ML revolution" before LLMs was about recognizing that messy, noisy data can be interpreted with some accuracy using statistical methods. LLMs are the continuation of that: they are even harder to measure and completely impossible to prove, but they bring capabilities we have been unable to achieve any other way for decades. Should they be used to handle deterministic logic? No, obviously not - but they do enable computer systems to start working in contexts where they either couldn't at all before, or were just bad at them.

5일 전discuss

> you're going to get worse output from them

Not completely true. Giving developers hardware that is too beefy is the main reason why so much software breaks down when run on users' machines, which are generally old, on spotty Internet connections, and RAM-starved. Devs just don't need to think about performance unless it's really asymptotically bad, while the users bear the full brunt of inefficiencies.

5일 전discuss

I came to appreciate typos, slightly ungrammatical sentences, and creative plays on common phrases. They are completely absent in LLM output without a specialized prompt (and they seem to struggle to make believable language mistakes even when prompted), so they can serve as a signal when judging whether the text I'm reading was written by a human.

As an aside, I observed my stance on proper English use changing in real time over the past 2-3 years. I used to be proud of writing clinically correct prose, and found mistakes in grammar and vocabulary grating. Now, I kind of welcome them and have stopped caring at all about committing such language crimes. I used to cringe when someone didn't capitalize the first words in their sentences - not anymore. I think we're years away from LLMs convincingly faking human-like mistakes (since all the work currently goes into avoiding them), so it's going to remain a useful signal for a while.

5일 전discuss

There's a chance it's this: https://github.com/dhilst/algae

5일 전discuss

As you note, being constrained in where you can go at level 1 is not a bad thing in itself, but it is a trade-off. Yes, as much as I personally don't mind it, I see how some players/designers might find such a limitation unfit for their game or not working for their playstyle.

You can still work around this without resorting to level scaling. You can give players an exploration option that avoids fighting, but sacrifices something else (ie., you can explore as a ghost, but can't take any loot with you). You can give low-level players some kind of newbie buff that will keep them alive (but won't allow them to win). You could make the perception of the world level dependent. You could also just scale locations or regions once, so that if a player reaches it at a low level, it'll become easier, and if you get there at a high level, it'll become the de facto endgame area. You could also just not implement leveling at all: The Bard's Tale (remake) was a bit like this.

Leveling up is not fun if it doesn't have an impact on how your character interacts with the world. If you're going to use level scaling to make leveling a no-op, it's often better to just go the action-adventure route and not pretend the game is an RPG. Seriously: what's the point of pumping my Strength stat if Villager A always has enough vitality to offset any gains on my part? It's especially grating if it's the same village and the same villager, revisited 40 hours later, and it still takes 3/4 of your health in a hit.

I don't think naive level scaling (Oblivion/Skyrim-style) is the right solution for "let the player go anywhere they want from the start". It's certainly a solution, but not a good one. A more nuanced mix of story justification, natural movement limitations (distance, special skills needed to get somewhere), level/area design (make areas with harder enemies less likely to be visited first), some non-combat exploration options, etc. all seem like a better way of letting the player experience open-world freedom without taking away the RPG progression "from zero to hero" from them.

I played a lot of Might and Magic VII back in the day (a few years before Morrowind IIRC). It was a huge world and you could go anywhere after getting off the tutorial island. Some endgame areas were gated behind lengthy quests, some areas were inaccessible without reaching them "the hard way" for the first time, others were impossible to reach without special skills or items, and there were skills/spells (invisibility, fly) that allowed safe passage through high-level areas if needed. Taken as a whole, it gave you a lot of options in terms of where to go at any given time, protected you to some extent from getting insta-killed because you made a wrong turn, but didn't make exploration trivial or level progression pointless. When you give players freedom, you should also allow them to commit suicide by charging at a horde of dragons while underleveled and underprepared. Trying to make the whole world immediately accessible is the kind of handholding that is actually limiting in the long run, and takes away an important part of the RPG experience. I don't think there are many CRPGs outside of TES that use level scaling - personally, I only experienced one in Wizardry 8, and it was way less absurd than Oblivion (areas had level ranges - you won't get an endgame area mob to be level 1 if you happen to reach it at that level yourself, and Villager A in starting area won't ever get to level 20 if you revisit it later).

So, between some limited/partial scaling and all the other design choices you could make, using Oblivion-like level scaling to "make the world accessible" is just bad, lazy design to me.

6일 전discuss

I hate level scaling in games with passion. An argument in favor I heard is that it's supposed to make it easier for the player to go anywhere from the start. Maybe, but coming from classic CRPGs and some TRPG background, I just can't bring myself to understand that impulse: you see a world-ending dragon god destroying a castle, and you think it's a good idea to chase it to its lair... at level 1?? With a plank in hand and with a shirt as your armor??? It's absurd!

Then there's the "level up by doing" mechanic, which is a mixed bag. It can be done well, but in Oblivion, it only resulted in putting a book on the spacebar. Voila, my character literally jumps around and looks utterly idiotic, but Acrobatics levels rise.

Being unable to just go fight a dragon at level 1, and then progressing to routinely curbstomping dragons (Baldur's Gate 2 - solo Sorcerer run is my favorite example: "I see, you're resistant to magic. Let me introduce you to the Magic Sequencer with Lower Resistance x4. Time stop. Horrid wilting. Wish rest. Oh, I didn't need to, you're dead already.") by the end. It's not the only selling point of RPGs, and it can sometimes be omitted entirely (e.g., Disco Elysium). But if there is a classic leveling system, I expect it to work, from zero to hero. It's not as fun if the numbers going up don't translate into real changes in how your character interacts with the world.

7일 전discuss

> I'm not sure Gleam belongs on Wikipedia if Odin does not...

They both don't belong there, TBH. I'm a PL nerd and have been one for nearly 20 years. Wikipedia is the last place I would search for information about even the TIOBE Top 20 languages, let alone anything newer or more niche. The only reason new/niche languages have a Wikipedia page is for advertising - they all hope to attract new users and convey an impression of being mature enough for serious work. It's a failure of Wiki that some pages like that were not flagged and deleted quickly enough. Enthusiasts will keep creating those pages as long as there's a chance they'll fly under the radar long enough to make them hard to delete. If they put that effort into RosettaCode (also a wiki) pages, we'd be all the better for it.

7일 전discuss

> I've never heard of it before [...] but I've definitely heard plenty about Rust and c++ topics.

Programming is a very broad and deep discipline. If you're a programmer for some time, chances are you know of very niche projects (10 stars on GH) in your domain/stack/platform. It says nothing about your familiarity with much less niche (10k stars on GH) projects outside your domain/stack/etc.

The only ways for you to learn about Odin are to be interested in programming languages in general or to be working in the specific niche Odin tries to conquer (+ some luck).

In other words, a "normal programmer" not knowing about one of literally hundreds of languages out there is expected, but says little about the notability of said language.

> maybe I just happened to miss it?

You did: https://news.ycombinator.com/item?id=43970800 But that's normal - it's impossible to keep track of domains you're not interested in. Programming language development (for languages that don't pay your bills) is not something programmers need to follow. It's a conscious choice to become interested in this very specific, deep, and niche domain. If you were interested in PLs, you'd almost certainly know about Odin - you probably still wouldn't know Odin itself, unless you're specifically interested in "ergonomic, low-level C replacement" languages and, for some reason, concluded that Zig is not for you.

8일 전discuss

Steam with Proton made gaming on Linux viable. Just for that, they deserve my money. That some of it goes to game devs is a happy coincidence ;D

8일 전discuss

Nice! Thank you, that explains it. FreeBSD was my first *BSD and the only one I had long-term contact with, so I unconsciously use it as my "BSD standard". My bad on that :)

8일 전discuss

I'd like to know, too!

DbC is an actual superpower. Coupled with a gradual type system, especially one that provides type refinements (not sure if that's a Racket-specific[1] or generic term), DbC covers a wide variety of problems and either eliminates them or makes debugging them a lot easier. The problem is that only two/three languages are built around DbC (Eiffel, Racket, Ada/SPARK). There are a few others (e.g., Clojure, Raku, Scala) that provide some degree of support, but their capabilities are incredibly basic compared to what, for example, Racket offers. And for mainstream programming languages, there are libraries, but it's a coin toss whether authors even understand the idea (I once asked in a ticket for some Python contract library about contracts for callables and was met with "what?" - as if specifying range constraints on ints was all DbC was about).

Unfortunately, Racket is tiny, barely a blip in the training data. In theory, you could probably get agents to a new level of reliability by making them write Racket; in practice, though, you'll burn a lot more tokens on every single edit, because the agent will need to rediscover how to do things in Racket much more often than in Python.

I had some hopes that LLMs and agents based on them would be an opportunity for less popular, but technically advanced languages. So far, it doesn't seem like it's happening; the ridiculous per-token API prices mean that you need a really good agent harness for your language - and what niche PL has resources to focus on building one?

[1] https://docs.racket-lang.org/ts-reference/Experimental_Featu...

8일 전discuss

I subscribe to Reuters. I've been using it as my primary source of non-tech news for the past 5 years.

Compared to the Guardian or CNN, the reporting is much less subjective and less editorialized, and, outside of Breaking Views, I've yet to find an article with an obvious ideological bent.

It's not ideal, but it is better. Sure, it's probably still a bucket, but at least the lid isn't tightly shut, and there's no fire beneath it that's going to slowly cook you over time. I switched to Reuters when the war in Ukraine started: it was the only source of news that wasn't very obviously, in-your-face biased. It's not the best source for longer-form reporting, but for news, I'm much happier in this bucket than in the alternatives I tried.

8일 전discuss

> wow, i guess you got hooked :-)

Maybe a little :D REBOL line of languages has been on my radar for a long time - I've been a PL nerd for 20 years now - but I always found reasons not to engage with them. So it was a bit of a blind spot: I knew some basics, considered it a pretty elegant and powerful design, but the REBOL3 fiasco, the proprietary nature of REBOL2, and the various facts about Red (pivot to it being a "blockchain native" solution was painfull to watch, dependency on REBOL2 for the toolchain/no self-hosting after almost 15 years in development, etc.) made it hard to dive deeper into the language(s). I had some time yesterday, and your comment touched on something I'm already interested in (interactive CLI/universal REPLs), so I took the opportunity to finally learn more about the language.

> i am not actively trying to create a new shell, but i am exploring languages for their potential to design a shell language without having to reinvent the whole syntax from scratch.

As for me, I tried making shells a few times. All those failed, of course, mostly because I wanted to do something a bit different: a text-based computing environment with network transparency, basically a single-player MUD/MOO that would treat the filesystem as a world. I got quite far with Smalltalk - but GNU Smalltalk that I based it on collapsed under me :( I tried Elixir, Io, and Python, and all would require much more work than I was willing to put in. A pity, because I think that would be the best possible environment for LLMs/agents... I'm still thinking about this idea often, and I started working on a new implementation, using Pharo Smalltalk/GToolkit. Parsing is the easier part, actually: it's the liveness of the whole thing (hot reload, adding functionality from within the environment, mapping the environment back to source code, etc.) is the part I had the most problems with, and Smalltalk seems like the most promising platform for implementing it.

8일 전discuss

> I think GP is confused why the ftp command also handles http(s) :)

Exactly - I even suspected for a second that `ftp` on NetBSD is something else entirely, not an actual FTP client with HTTP/HTTPS URLs bolted on. It's not - it still accepts a host as an argument and opens a CLI if there's an FTP server to talk to.