> When I write a blog post, I'm writing for an imagined reader who has arrived at this specific URL because they're interested in this specific topic
to me, this is the key point. it often gets conflated with whether the blog has "real time" readers who subscribe to the feed and read the articles as they come out, but I think there is real value in just having a blog engine be your static site generator and/or cms.
chicken scheme compiles to c as well. it's a pretty convenient compilation target, you get to use all the compilers and tool chains out there and you don't add a dependency on llvm
I love CHICKEN Scheme! Nice to see it mentioned. Though I think it's worth pointing out it compiles to something pretty far from handwritten C, to my understanding. I think this is true of both performance and semantics; for example you can return a pointer to a stack allocated struct from a foreign lambda (this is because chicken's generated C code here doesn't really "return", I think. Not an expert).
Of course you can always drop to manually written C yourself and it's still a fantastic language to interop with C. And CHICKEN 6 (still pre-release) improves upon that! E.g structs and Unions can be returned/passed directly by/to foreign functions, and the new CRUNCH extension/subset is supposed to compile to something quite a bit closer to handwritten C; there are even people experimenting with it on embedded devices.
Chicken indeed interoperates with C quite easily and productively. You're right that the generated C code is mostly incomprehensible to humans, but compiles without difficulty.
The Chicken C API has functions/macros that return values and those that don't return. The former include the fabulous embedded API (crunch is an altogether different beast) which I've used in "mixed language" programming to good effect. In such cases Scheme is rather like the essential "glue" that enables the parts written in other languages to work as a whole.
Of course becoming proficient in Scheme programming takes time and effort. I believe it's true that some brains have an affinity for Lispy languages while others don't. Fortunately, there are many ways to write programs to accomplish a given task.
I don't think there is any correct incentive for "do unpaid labour for someone's proprietary model but please be diligent about it"
edit: ugh. it's even worse, lmarena itself is a proprietary system, so the users presumably don't even get the benefit of an open dataset out of all this
lots of fun! the fact that the walls spill over the square boundaries is very annoying though, i would love to have an option to just make a wall a filled in square without the 3d effect.
"mathematics can be fun" was one of my favourite books when I was a kid. I remember spending a lot of time on this particular puzzle, wrapping my head around the various rotational motions of something both rotating around its axis and orbiting something else. there was also the related puzzle of how many rotations a coin makes when rolling around another identical coin.
not sure why so many people feel like factoring fun into what job you want to take is so unthinkable, or that it's just a false dichotomy between the ideal job and unemployment
it's a trade-off; you need a job but you typically interview at several places, collect offers, and weigh them according to various criteria. all the pro-fun posters are saying is that "enjoy the job" is a very highly ranked criterion for us.
it's definitely a privilege to be able to find a fun job! but note that I'm not saying that everyone should hold out until they find one, I'm pushing back against the dour people who are convinced in their heart of hearts that "it's a job, it's not supposed to be fun" and that you are being an idiot for thinking it's even possible to find a job you really enjoy.
one of my perpetual quests is more books like "dreamsnake", so I was definitely disappointed not to see it in there (it's an older book, but it did win both the hugo and the nebula)
"fast, ephemeral, concurrent dev environments" seems like a superb idea to me. I wish more projects would do it, it lowers the barrier to contributions immensely.
> "fast, ephemeral, concurrent dev environments" seems like a superb idea to me.
I've worked at one (1) place that, whilst not quite fully that, they did have a spare dev environment that you could claim temporarily for deploying changes, doing integration tests, etc. Super handy when people are working on (often wildly) divergent projects and you need at least one stable dev environment + integration testing.
Been trying to push this at $CURRENT without much success but that's largely down to lack of cloudops resources (although we do have a sandbox environment, it's sufficiently different to dev that it's essentially worthless.)
Yeah, this is something I'd like more of outside of Agentic environments; in particular for working in parallel on multiple topics when there are long-running tasks to deal with (eg. running slow tests or a bisect against a checked out branch -- leaving that in worktree 1 while writing new code in worktree 2).
I use devenv.sh to give me quick setup of individual environments, but I'm spending a bit of my break trying to extend that (and its processes) to easily run inside containers that I can attach Zed/VSCode remoting to.
It strikes me that (as the article points out) this would also be useful for using Agents a bit more safely, but as a regular old human it'd also be useful.
to me, this is the key point. it often gets conflated with whether the blog has "real time" readers who subscribe to the feed and read the articles as they come out, but I think there is real value in just having a blog engine be your static site generator and/or cms.
reply