arvyy

I used opportunity to learn about devcontainers. I've only recently started using llms and it's possible I'll change my mind later; but so far I quite like the approach in part because it 2-for-1 also gives benefit of easy to setup coding env for people who don't care about ai.

it's a very old idea. I first saw this on https://www.squidi.net/three/entry.php?id=56

one of the players he persistently harassed, Daniel Naroditsky, ended up dying, which surely gave an extra push

It took 6 turns for opus 4.8 to attempt to make an illegal move in chess against me.

Yes you can setup guardrails and validations and other things, but as long its primary brain is demonstrably full of holes, I feel obligation to at very least be always be capable to take over the code. To me this means it should stay human-maintainable, and that's for humans to decide what is and isn't, one review at a time.

Almost all of these problems are due to scheme being so absurdly fractured, it's a real shame. It's already niche, but then on top of it instead of having 2-3 robust implementations with robust cli / messages / docs / etc, you have 20 (not a hyperbole[1]), each one receiving diluted effort compared to what it could have been.

Probably the one bit that isn't strictly fracturing's fault is stacktraces -- scheme has TCO, which is nice for alot of things but it absolutely destroys dx as it relates to stacktraces. Other languages with TCO are similarly awful in that regard, including haskell (ghc has `HasCallStack` to try help it, but it's still awful to use).

[1] https://get.scheme.org/

doubtful, or at least not useful ones. Like, you could describe some invariant along the lines of "the position is winning for the side-to-move, iff there exists move, such that position' := ApplyMove(position, move) is losing for the (now other) side-to-move". But that's just restating minimax algorithm that people have known for 50 years.

As someone dabbling abit around chess engine development, I'm very often impressed by the many intricacies and observations made by people who pushed the envelope. It just doesn't sound plausible people wouldn't have discovered these killer invariants by now if they existed

the vars are usually compiled to the moral equivalent of a global variable holding a pointer to a function. This allows you to update the function if the developer redefines it in the REPL, but it comes at a performance cost (the JVM can't inline it or otherwise optimise it)

might be out of my depth but I find it surprising; I thought compilation through invokedynamic should be able to handle redefinition while still allowing inlining and other jit optimizations

if the language used statement delimiters

I mean, it does. White-space sensitive syntax is entirely opt-in when you chose to omit delimiters. Here's an explicit delimiter example:

    let {
      a = 1;
      b = 2
    } in a + b

kawa is unfortunately a somewhat shoddy project. Alot of halfbaked features / abstraction ideas (eg trying to support CL for whatever reason), dubious tooling for a java project (autotools), unclean and inconsistent code formatting. It's missing some features that are expected in a real scheme like multishot continuations; someone wrote research about it as a MSc thesis, but due to mentioned shoddiness its integration to upstream stalled and hadn't been merged.

At some point I thought of forking it to then cut out and polish the core, but then my attention got caught by graal's truffle framework as a plausibly better path for implementing scheme in java

you as the customer are too dumb to not spill hot coffee over yourself

presuming you're referring to the hot coffee lawsuit, maybe read details of the story. McDonalds wasn't at all blameless, and the plaintiff had reasonable demands

it feels OpenAI know they've lost, and their only hope is getting saved by USA military complex. I have a more restrained opinion about other AI companies and LLM tech more broadly; but for OpenAI specifically I hope they go bankrupt sooner rather than later

hardly new, I've used it before advent of llm popularity, and I wasn't alone

CS undergrads write parsers for some toy lisps or other straight forward syntax. C isn't as trivial https://faultlore.com/blah/c-isnt-a-language/#you-cant-actua...

(a small remark, but to be clear I'm not terribly impressed by AI showcase of the c compiler, nor with browser before that, as it stands)

I knew one person reporting gcc bugs, and iirc those were all niche scenarios where it generated slightly suboptimal machine code but not otherwise observable from behavior

hopefully a legal action is taken against such abhorrent project blatantly violating users' privacy

Performance concerns are WIP, it's too early to meaningfully benchmark. I did some napkin benchmarking against sbcl for curiosity and it was ~7 times slower

I see where you're coming from, and the naming was quite unimaginative, indeed. I saw that "truffle ruby" called itself that and copied it.

However, the fact it's based on truffle is the selling point -- truffle enables interop between languages on the framework. So, for example, you can take truffle JS implementation, import express library or whatever, and then as part of the implementation do

````

let fn = Polyglot.eval('islisp', '(lambda (x) (+ x 1))');

fn(1);

````

(toy example. But this interop can happen in all directions, it's not limited to js but can be used from truffle python, ruby, java, etc; and it also isn't limited to just primitive values, you can pass around functions as well).

If you aren't looking for a specifically a truffle lisp, it would make more sense to use one of the established common lisp implementations.