hmijail

I guided Claude Code to build a fuzzer for Obsidian Sync without ever reading the code myself. I got a functional prototype in ~30h, saving an estimated ~10h.

Then I tried to finish it off, and the next ~30h turned into a bug treadmill, where at each turn Claude broke as much as it fixed.

This is the experience report: what went wrong, why research (and Anthropic's own docs) suggest this is to be expected, how an YC-alum AI-tooling founder's public talks tell a similar story, and maybe how to salvage the good bits.

That percentage comparison is fascinating. Say only 1 fighter remains in a tunnel when all the civilians have been finally bombed out and sniped off. By that measure that would mean Hamas is what, 50 times larger than the USA's military?

"What, an human in the loop is slowing down our release? I have just the idea!"

And regarding the concept of architectural mismatch, that goes nicely with another thing I recently wrote about [1]: how applying embedded architectures in high-level languages (Java) seem to yield big gains AND surprise everyone. At the moment I considered it a "lack of vocabulary" in Java, but now I realize that maybe the problem is a bit deeper/more general.

Java's architecture (and architecture idioms) might cause a blind spot (or is it a kind of Someone Else's Problem?); while C's architecture/tools or lack thereof disincentivize overwrought (or plain sophisticated) systems, for good and for bad.

Or more succinctly, Java makes you stop thinking about how things actually work, while C makes you stop thinking about how things should work.

Interesting!

[1] https://hmijailblog.blogspot.com/2018/08/you-could-have-inve...

Regarding [3], I find the paper interestingly underwhelming. Brooks' part of it says that 2 decades have passed (since NSB in 1986) without an order-of-magnitude improvement, and then says "Of the candidates enumerated in “NSB”, object-oriented programming has made the biggest change, and it is a real attack on the inherent complexity itself."

I think this is rather ironic / off-mark, given that the 90s and 00s were so full of OOP - for example, growth of C++ impulsed by Windows, and if anything OOP lately seems to be (thankfully) going back to being just another tool in the toolbox. To me it feels like OOP had its moment/decades in the spotlight, it didn't fulfill hopes/expectations/SB and therefore things keep moving on, in search of that SB. Isn't it? Or is the implication that things were even worse in the 80's?

Note, I'm referring to OOP in the "industry standard" way it's commonly understood, not Alan Kay's message-passing original meaning - about which I'm still trying to learn more.

But, WOW - I just read David Lorge Parnas' part in [3]. I was already reeling from the paper's distilled self-serving, but this guy is crapping in every one, rather directly, and making sense while at it. I have a new hero to research.

[4 - 7] are really interesting, thank you (as is Betley's and McIlroy's mention). And also very interesting to see someone working in those things while developing another iteration of Smalltalk. This is really making me prioritize learning Smalltalk in my to-do queue...

I found this interesting, so after some googling, these are the numbers I found:

  QNX kernel   = 23 KLOC, C [1] 
  Plan9 kernel = 50 KLOC, C [2] 
  Squeak VM    =  9 KLOC, Smalltalk [3] (Squeak is a Smalltalk)

Note, those are the kernels - Smalltalk's 20 KLOC include the whole system (GUI, etc), IIRC.

For clarity, I'm a bit out of my depth here, and I'm assuming that the Squeak VM is a bit akin to a kernel. And surely one could find more authoritative references for it all.

[1] http://www.gelato.unsw.edu.au/IA64wiki/JamieLennox/QNXvL4?ac...

[2] https://news.ycombinator.com/item?id=879101

[3] https://books.google.com.au/books?id=FM-pCAAAQBAJ&pg=PA136&l...

That sounds really interesting. Can you point to any of those reactions?

(Author here)

Actually, I think that talking about Java's multithreading here is a red herring; note that LMAX had to abandon multi-threading because it was destroying performance.

And this is important, because they explicitly made a very interesting point of current architectures being at odds with current thinking about best practices for concurrent programming.

(Author here)

But that's not "Java in the real world". If anything I'd presume that that's "well programmed Java".

(Author here)

"If you program it like it was C then you can get good performance" -> Note that one of the points of the post is that just using "like C" won't magically fix your performance!

If anything, you could say "If you program it like a system with limited memory then you can get good performance". That, I can imagine being a universally applicable thing.

My point is that, for example for the particular case of memory management, there is an associated cost, whatever your language is; and you need to deal with it. Ignorance of the law is no excuse, etc.

(Author here)

I agree. There's much too much "art", religion and cargo cultism in software development, and much too little science/engineering.

And it's hard to even say whether we're improving.

(Author here)

The post quotes both Brooks and Dijkstra; the first managed development of a system and got famous, the second saw the system's actual failures and reported his criticism on it.

So, care to explain what exactly is it that you find lacking? My experience with people who cite "failure to grasp the thinking" has been rather with "architecty" types that can't get past handwaving to make a point, so anything concrete would be appreciated.

For example: you say Dijkstra complains "on overblown marketing material mostly". Citation, please? Sounds like you mean that the marketing overpromised and underdelivered, but to me it looks like Dijkstra was pretty clear about the whole set of ideas being poppycock even if fully delivered; he says that it's fundamentally the wrong way to do things, and does so in a rather smug "told you so" mode.

... unless we want to argue that maybe Dijkstra didn't "grasp the depth of Brooks' thinking" either, nor the functionality of that thinking's actual, first hand implementation?

Thank you so much for those insightful links!