Full support to the author, I hope they'll be able to keep making things that are interesting and outside the box like Decker and WigglyPaint. I hope they'll find solace in keeping at creative things.
I also wish LLM copies were not crowding out actual artists.
> My concern with TDD is that writing tests necessarily implies designing an API upon which those tests operate
It really forces you to do outside-in testing; I usually describe the kind of API I want when chatting with the agents. For example, the CLI options, the routes that might be useful for an API, etc.
> I look at the code and find a rats nest / ball of mud that will cost 10x more tokens to enhance should I ever need to add a feature.
Agreed, I don't know if there are good forcing functions to avoid complexity. The providers have a huge incentive to have you waste your tokens (for example when it re-outputs the complete file when you ask for a tiny change).
- write a test for method that does not exist, it just calls the method and nothing else
- write method that does nothing
- add/extend test that uses that method <-- this very loop starts
- modify method until tests passes
- go back to loop start until you're done
I always hated it. When I work with LLM i first massage interface that tests, then tests, then implementation until all these tests pass.
> for example when it re-outputs the complete file when you ask for a tiny change).
well with sonnet 3.5 and 4.5 (can't say about 4.6) it often will get stuck in a loop trying to update just the required parts and iether waste tons of tokens doing these updates or waste tons of tokens to a point where restring file from git is required. Tokens get wasted regardless.
I like tests, but I don't bother with TDD because it's so ceremonial. I design the API, or at least sketch it out (using a whiteboard or drafting some notes, and doing research). Then I iterate and refine. I only bother with tests once I can commit or when it's no longer viable to tests manually (edit-compile-run cycle). And a lot of time I follow the table pattern.
Guile has lots of libraries though, and is the language of Guix. This makes it more likely for people to package their stuff via Guix. Guix itself enriches the ecosystem, and Guile projects can use Guix to make them reproducible.
A few problems remain though. A good debugger, a good macro expander (geiser in Emacs is able to expand somehow), and solving the issues with R6RS library syntax and standard library bindings, are what comes to mind.
Racket's multi-core abilities for a long time were mostly heavy weight (places, starting whole new Racket VMs), except for their implementation of futures, but that one was not always useful. I think recently the situation in Racket has improved, but I don't know, whether it is as good as Guile fibers and futures (which are different from futures in Racket).
Except that ecosystem Guix provides is not on Windows nor MacOS, making a serious limitation to anyone who wants to develop guile on those platforms.
I support GNU's mission in general, but I find it ironic that when they push freedom of choice you're forced to make the "right" choice or you're left twisting in the wind.
Better focus on developer platforms, than stretch resources too thin. Even if they managed to pull it off, they would need to maintain it. It is quite the different compile target too. Even if Windows was supported, probably many package definitions would have to change to support installing them on Windows. Ultimately, who is to say how Windows updates/MS will break everything? I really don't think they have the resources at this point to pull that one off. How about MS themselves spends time and effort to make things work on their proprietary platform instead, if they want to deliver a very usable platform?
If Guile had more of the "batteries" from the Gauche standard library it might be the perfect all-purpose Scheme. But for just writing a simple application quickly and easily it's been impossible to beat Gauche for me, it's on par with Python and Ruby in that regard IMO.
I am asking, because I might want to get more familiar with it, if it is great for something like GUI or web app. I know there is Guile Golf, but to me it feels unfinished, and I experienced segfaults and crashes, when not doing things exactly as shown in examples and using standard GTK procedures, so that one is kind of out for me, and guile-gi is still changing and seemed kinda complicated to use. On the web front, there is Artanis, but it is too opinionated for me, not a minimalistic framework. Still can build things on top of guile fibers concurrent web server, but then have to build lots of things myself.
Recently, I used Python and tkinter, which works really well, and I would love to have good bindings for tk in Guile.
On my search for Scheme and GUI, I also found stklos, but I have no idea how ready it is and what kind of libraries I would have available, if I built an application with it.
Racket of course also has a GUI framework, that I have tried to use in the past, but it does not have a treeview widget. Has listbox though, with multiple columns.
What does Gauche have to offer, specifically for application development? (GUI, or web, or other)
I should clarify that the "applications" I write are usually command line tools. I don't think I've ever written a full working GUI application, although now with AI I bet it would be fast and easy to bang something together.
Aside from the debugging & testing I already mentioned, going only through guix is a tough sell considering the very tiny amount of people that use it. It's also incredibly slow and doesn't have many packages available. Even for Emacs, it has this weird way of going around Emacs-installed packages (GNU or MELPA channels). Just like Guile docs, it also doesn't tell you of a good way to do things, it only says "here is what exists" with too little guidance imo. It means people have to figure out how to setup things properly on top of all the rest. It makes for a terrible onboarding.
Guile' backtraces are useless to the point it baffles me how the community can work on anything else, or how it's not the first item on any such lists as above.
Other than Guile as in different Scheme implementations? It's usually not too difficult to port things between Schemes. Especially if you use standard R6RS or R7RS library syntax.
Can you say more? Guile's the only scheme I've tried (attempts at packaging for Guix). Debugging has been difficult, but I figured it was me struggling with new tools and API. Does racket have better facilities for introspection or discovery at the REPL?
Yeah those interested in Wasm topics might find https://spritely.institute/hoot/ interesting. It's not only a Scheme compiler but a full Wasm toolchain available as a library.
For talks which will obviously be popular, go to the talk before it even if it's not as interesting. It's not common to have two super-popular talks in a row in the same room.
That is how it's supposed to be. You can watch the talks at home at any time but the opportunity to meet random yet like-minded people from all over Europe is unique.
Indeed! It's the 3-4x times I'm going to FOSDEM so I'm mainly looking to connect with people doing cool stuff tbh, otherwise I can just watch stuff online for sure.
fossil is really cool for the simple fact that you get your issues, tickets and wiki all stored in an SQLite DB. Feels neat and I wish I had more occasions to use it.
I also wish LLM copies were not crowding out actual artists.
reply