gritzko

6 ms·

91.
by gritzko 5mo ago
That is interesting. I make LLMs write C with the general hope that a simpler language they can manage well. That is not entirely true, though. They reason about C fluently indeed. The problem is, Claude pumps lots of bad C into the codebas
92.
by gritzko 5mo ago
I think I did not get to that level yet where I trust Claude to create its own VMs. But one day I will.
93.
by gritzko 5mo ago
What is the feasible way to test code against the matrix of compilers/oses?
94.
by gritzko 5mo ago
https://en.wikipedia.org/wiki/Fundamental_theorem_of_softwar... My point, more or less. Of course, a heap is different from append-only array, on higher level. On lower level, these are bit strings. Which is handy, if
95.
Three Years with Abstractionless C(replicated.wiki)
1 points by gritzko 5mo ago|0 comments
96.
by gritzko 5mo ago
That is the entire point, yes. Reasoning about layers of completely imaginary entities is what demotivates me about C++ and Rust. Meanwhile, hardware bits are very real (and getting more expensive recently). Having implemented slices and ge
97.
Three Years of Abstractionless C(replicated.wiki)
7 points by gritzko 5mo ago|3 comments
98.
by gritzko 5mo ago
In this day and age, the value of C standard library is approaching zero. Is is basically an unfirm looping trajectory of CS thought left over 50 years. That amount of code can be recreated pretty quick today. So why bother. Unless it is a
99.
by gritzko 5mo ago
I use a C dialect with (ptr,ptr) slices and (ptr,ptr,ptr,ptr) buffers. Effectively a different programming language, still uses standard C compiler. https://github.com/gritzko/libabc In this day and age, the top proble
100.
by gritzko 5mo ago
- a metal bar always sinks - unless you are trying to sink it in mercury. then it floats - unless it is an uranium bar - go sink uranium bars in mercury yourself
101.
by gritzko 5mo ago
That better be marked "historical". At least, Lemire says: On recent Intel and 64-bit ARM processors, data alignment does not make processing a lot faster. It is a micro-optimization. Data alignment for speed is a myth. /&#x2
102.
by gritzko 5mo ago
C of course is ancient. It remembers the Cambrian explosion of CPU architectures, twelve-bit bytes and everything like that. I wonder if it is possible to codify some pragmatic subset of it that works nicely on currently available CPUs. Cau
103.
by gritzko 5mo ago
I do not think Gemini can relieve a developer from knowing what he is doing.
104.
by gritzko 5mo ago
I just had a Claude episode. Instead of trying to fix the bug, it edited the data to hide the bug in the sample run. This kind of BS behavior is not rare. Absolutely, if you do not understand every bit of what's going on, you end up wi
105.
by gritzko 5mo ago
In fact, GitHub URIs are a good example of overusing paths: https://github.com/gritzko/beagle/blob/a7e17290a39250092055f... - user gritzko, - project beagle, - view blob, - commit a7e17290a3925009
106.
by gritzko 5mo ago
In my current project I use URIs to refer to absolutely any entity in a git(-ish) repo. Files, branches, revisions, diffs, anything. URI turns out to be a really good addressing scheme for everything. Surprise. But the most used and abuse
107.
by gritzko 6mo ago
2027: "GitHub is up!"
108.
by gritzko 6mo ago
The most annoying thing about git is its jungle of commands. I had an idea of ordering all the turns and twists in some sort of "periodic table of VCS commands". Now I use it daily https://replicated.wiki/blog&#x2F
109.
by gritzko 6mo ago
Lived there. Baltic weather, not too sunny. Must be a great place for wind generation though.
110.
by gritzko 6mo ago
I recently implemented a diff driver as part of git-dogs. The integration part Claude one-shotted. Mine is token based: https://replicated.wiki/blog/img/difflet.png The set of git tools itself, very much in devel
111.
by gritzko 6mo ago
I was giving students an assignment to import git repo into fossil and the other way around. git was a tad faster, but not dramatically.
112.
by gritzko 7mo ago
It can use multiple cores for a full reindex. On each commit, it reindexes affected files.
113.
Spot – Git repo code search, replace, diff and merge(github.com)
2 points by gritzko 7mo ago|3 comments
114.
Spot – git repo AST-aware index, search and replace(replicated.wiki)
1 points by gritzko 7mo ago|0 comments
115.
by gritzko 7mo ago
In 2007 Bram said to me that my Causal Tree algorithm is a variant of weave. Which is broadly correct. In these 20 years, the family of weave-class algos grew quite big. In my 2020 article, I devoted the intro to making their family portrai
116.
by gritzko 7mo ago
Fresh account, no history, AI avatar, a vibed project suspiciously similar to some existing project. Is this the new norm? https://github.com/gritzko/librdx/tree/master/be
117.
by gritzko 7mo ago
I recently created my own low-overhead binary JSON cause I did not like Mongo's BSON (too hacky, not mergeable). It took me half a day maybe, including the spec, thanks Claude. First, implemented the critical feature I actually need, t
118.
by gritzko 7mo ago
When I was starting my research into collaborative editing as a PhD student 20+ years ago, rebase-and-resubmit was well known. It was used in one Microsoft team collab product (I forgot the name). It is 100% legit algo except intermittently
119.
by gritzko 7mo ago
At least Yjs, Loro and Automerge must handle some degree of operation reordering. Either causally-consistent or virtually any order.
120.
by gritzko 7mo ago
One way to minimize impedance mismatch is to work with DOM-like or JSON-like structures mostly immune to transient bugs, which I am doing currently in the librdx project. It has full-CRDT RDX format[1] and essentially-JSON BASON[2] format.

More ›