vanderZwan
Joined 13 years ago
Karma
19,410
Submissions
5,806
Member since
Feb 4
Recent submissions
Comment · 11 hours ago
Then it's the elders' responsibility to warn the newbies whom they can and can't trust.
Comment · 11 hours ago
IMO that's applied Sayre's Law though. And my explanation for that is that the more niche (and therefore fragile) an academic topic gets, the more defensive people are.
I've heard stories of friends working in (say) such a niche part of fluid dynamics that there's two professors and a few dozen PhDs in the entire world who get it, and the professors refuse to work with anyone who ever cited the other in one of their papers.
On the other hand, I've worked as a programmer for molecular neurobiologists who were working on multi-million dollar research projects mapping out all cell types of the brain using single-cell RNA sequencing, and collaboration seemed much more common there.
The stakes don't get much higher than running the country you're from.
EDIT: Also, the city of Groningen elected a city council of young students and put a 24 year old in charge of the city’s traffic and urban development policy. We still brag about being one of he most bike-friendly cities in the country that was the result.
[0] https://en.wikipedia.org/wiki/Sayre's_law
[1] https://www.theguardian.com/cities/2015/jul/29/how-groningen...
Comment · 11 hours ago
Nice example of Poe's Law. I genuinely can't tell if this is a sincere comment written by someone who spent too much time in the start-up bubble, or a satirical comment on that type of person said by someone who very much aware that start-ups are just one of many ways humans can organize themselves and who knows that parliamentary politics is nothing like that for very good reasons.
But I do find it hilarious that apparently everyone assumes it to be the former, and that is quite telling about how most of this site's visitors think the other visitors of this site look at the world.
Comment · 3 days ago
Since you're working on your own thing that may or may not be like a traditional Forth at all, and also mention Uxn, you might find some ideas in Ben Bridle's Bedrock worth stealing:
https://benbridle.com/projects/bedrock
In particular the reasoning for what he changed compared to Uxn might be insightful:
Comment · 4 days ago
See his answer to the seventeenth question in this interview:
https://www.informit.com/articles/article.aspx?p=2213858&WT....
> Don Knuth: As you say, I've come to believe that P = N P, namely that there does exist an integer M and an algorithm that will solve every n-bit problem belonging to the class N P in n**M elementary steps.
Comment · 5 days ago
I think we should blame the elders for teaching people new to the trade wrong.
Because "heavyweight SPA for a static blog" isn't exactly a rare problem.
Comment · 6 days ago
There was some discussion about this in the Goose discord a few days ago.
One idea that came up was this: you could define a particuda function name as the "landing pad" for handling particular error kinds. Then you "wrap" calls to the library in a function with this name. Here's a part from a larger worked example:
fn catch_io<F: fn()>() -> IoError {
F();
return IoError{ message: "", ok: true }
}
let err = catch_io() { c(); };
Mind you, this was just discussion, no experience with how well this would work in practice.
Comment · 6 days ago
That removes the allocation but keeps the overhead of a pointer, a capacity and a fixed buffer.
And these strings in Goose are 6 bytes, while the ones in C++ are apparently 16 to 24 bytes each.
Comment · 6 days ago
Apologies, I wasn't trying to be dismissive, it was meant to be a joke that the sentence read like an (earned) humblebrag.
For context: I'm very active on the Goose discord (and have been following WvO's languages since Lobster was announced on Google Groups eons ago). I goof around there too, and forgot for a moment that outside of that chat it wouldn't be obvious that I'm being tongue-in-cheek.
Comment · 7 days ago
Well, my dayjob is writing JavaScript and I've having a blast writing Goose code by hand in my spare time in the last weeks, so it can't be that bad.
Comment · 7 days ago
Hmm, well the benchmarks always use an explicit "faster than idiomatic C/C++ and safe Rust". Similarly it also notes that in theory you could write equally fast C/C++ (since Goose compiles to C), but it would be an unreadable, unsafe mess.
Note also the fact that e.g. array indexing has bounds checks without escape hatches for the programmer, but the compiler can elide quite a few of them, and the language has tools to help the programmer write code that is guaranteed to be check-free.
I think that suggests the ambition is to compete with Rust in the domain of combining safety with not compromising on performance.
Comment · 7 days ago
> From what I can see, the #1 way an AI produces "good code" is to simply work in the context of existing good code.
"Just Git Gud First" - Wouter van Oortmerssen
Comment · 7 days ago
I think what you might be missing is that you can also do a sort of livenes analysis to determine how many dynamically-sized variables are "awake" at the same time at most. Then you only need to create as many stacks as that number, because you can reuse the stacks of "sleeping" variables (since the "awake" variables are guaranteed to be freed once their block goes out of scope, and threads don't share any memory so no data race worries regarding those stacks).
For example, suppose we have a function with a growable array that calls another function (without passing said array) that also uses a growable array as some temporary scratch space. Then the first function's array isn't being used when the second is sleeping, so the inner function's array could safely share the stack because it will all be freed with a single pointer restore once the second function exits.
Now, I actually don't know how the compiler works but as I understand it does things similar to my example to optimize the number of stacks needed (but let's wait for WvO to confirm or deny whether my understanding matches reality).
Comment · 7 days ago
Well, "safety" is a lot of things so you have to be a bit more specific than that about your use-cases. And I can't really answer it either way - I think WvO has to chime in about that himself - but I can point to some things that might give you some idea of what to expect. Here's what WvO wrote a few weeks ago when he shared Goose on twitter:
> Goose: my latest programming language. Safer, faster and less memory than Rust/C++ for algorithms where tightly packed, flat data structures matter.
> It can represent more kinds of data structures as flat, pointer-free bytes than any language I know.
https://xitter.cf/wvo/status/2107979660558766351
So one way to answer might be: how often do you reach for unsafe when using Rust? If you don't I guess Rust is safer. If you do… it gets trickier.
As for UB, I guess you could try looking through the spec and/or the reference? Like, the code is mostly generated by Claude after WvO wrote a specification. If it were anyone else I'd be worried, but given WvO's cv I actually suspect that means the spec leaves basically no ambiguity.
However, Goose compiles to C. Does that by definition mean UB sneaks in, or is there a "UB free" C subset? I don't write C, so I don't really know.
Comment · 7 days ago
*one of, you mean: