I did a similar thing but with backend-heavy code, and I agree with this assessment:
> In particular, I asked ChatGPT to write a function by knowing precisely how I would have implemented it. This is crucial since without knowing the expected result and what every line does, I might end up with a wrong implementation.
In my eyes, it makes the whole idea of AI coding moot. If I need to explain every step in detail - and it does not "understand" what it's doing; I can virtually the statistical trial-and-error behind its action - then what's the point? I might as well write it all myself and be a bit more sure the code ends up how I like it.
Not really - there's a difference between having the docstring of a function available for you to read, and a model which has learned from thousands of examples how to use a particular API and integrate it into a larger set of instructions. The latter is vastly faster and takes much less human work than the former.
Except when it consistently gets said particular API wrong. I was using it to do basic graphql-yoga setup with R1 and then Claude Sonnet 3.5 and they both output incorrect usage, and got stuck in a loop trying to fix it.
If it can’t do something that basic and that common using a language and toolset with that much training data, then I’m pessimistic personally.
I’m yet to see Copilot be useful for any of my juniors when we pair, it gets in the way far more than it helps and it is ruining their deeper understanding, it seems.
I’ll continue trying to use these tools, but I swear you’re overselling their abilities even still.
At this point with Cursor you can have it index the online docs by giving it a base URL and have it automatically RAG the relevant content into the chat (using the @ symbol to reference the docs). Both Windsurf and Cursor also support reading from URLs (iirc Aider does too).
I’ve had better luck with manually including the page but including the indexed docs is usually enough to fix API mistakes.
Begs the question again: if you need to go out of your way to find an example of correct usage of the api to paste into the prompt, why are you even bothering?
I find copilot useful when I already know what I want and start typing it out, at a certain point the scope of the problem is narrowed sufficiently for the LLM to fill the rest in. Of course this is more in line of “glorified autocomplete” than “replacing junior devs” that a keep hearing claims of.
That's an entirely client-side web page you can use to open a PDF which then converts every page to an image (using PDF.js), then runs each image through the Tesseract.js OCR program and lets you copy out the resulting text.
That's a nice little self contained example. I have yet to see this approach work for the day job: a larger codebase with complex inter-dependencies, where the solution isn't so easily worded (make the text box pink) and where the resulting code is reviewed and tested by one's peers.
We actually had to make a rule at work that if you use an LLM to create an PR and can't explain the changes without using more LLMs, you can't submit the PR. I've seen it almost work - code that looks right but does a bunch of unnecessary stuff, and then it required a real person (me) to clean it up and ends up taking just as much time as if it were just written correctly the first time.
It's faster if all you're concerned with can fit in a static html file but what about for more complex projects?
I've struggled with getting any productivity benefits beyond single-file contexts. I've started playing with aider in an attempt to handle more complex workflows and multi-file editing but keep running into snags and end up spinning my wheels fighting my tools instead of making forward progress...
Yeah thats the trick I've been using too, but by that point I get a better result by implementing it myself... of course, I've had two decades of practice and I don't have to communicate what I want lossily to myself, so it's an unfair comparison, but perhaps I've just not found the right use-case yet. I'm sure it exists, I've just not had much luck over the past couple years yet (including just this past weekend).
That is far more likely to happen when it is relying on compressed knowledge of documentation and usage for an API it would have seen (comparatively) only a few times in training. That is where the various types of memory, tool calling and supplementary materials being fed in can make them significantly more situationally useful.
The LLMs you mention are first and foremost a “general knowledge” machine rather than a domain expert. In my opinion, Junior developers are the least likely to benefit from their use because they have neither the foundational understanding to know when the approach is wrong, nor the practical experience to correct any mistakes. An LLM can replace a junior dev because we expect the mistakes and potentially poor quality, but you don’t really want a junior developer doing code reviews for another junior developer before pushing code.
The expectation for junior devs will probably change as well and they’d do a lot more shadowing while learning the product. Experience is gained in time.
There are tons of use cases. E.g. if you know an algorithm (take any pseudocode description from a moderately complex algorithm on Wikipedia for example) and you know the programming language, you still may be looking at an hour or two of typing just to get that pseudocode down into code using your own language, variable names, libraries.
But this is the kind of thing a LLM excels at. It gives you 200 lines of impl right away, you have a good understanding of both what it should look like and how it should work.
Slow and error prone to type but, but quick and easy to verify once done, that's the key use case for me.
It’s a better, faster, personalized Stack Overflow. Just like SO you might be led down the wrong path by an answer, but if you’re a programmer and you say you don’t get value out of Stack Overflow I don’t believe you.
I don't know exactly what these BSD things did, but there is a super easy way nowadays to get the stack for any process:
eu-stack -i -p $(pidof ...)
Thanks to debuginfod this will even give you good backtraces right away (at the cost of some initial delay to load the data from the web, consecutive runs are fast). If you get a "permission denied" error, you probably need to tweak kernel.yama.ptrace_scope=0
the bsd things still work; you can install a bsd in qemu or a spare laptop and try them
from your reference to kernel.yama.ptrace_scope (and your apparent belief that bsd belongs to the distant past) i infer that eu-stack is a linux thing? this looks pretty awesome, thanks for the tip!
Oh, that's easy: "founder mode" means the founder is hyperfocused (or in the oldspeak, obsessed) on his work (with his company) and optimizes (micromanages) everything. We know that already. Perfection demands micromanagement. Steve Jobs was actually doing that - reaching down the ranks and directly helping (molesting) people doing some piece of a larger product he particularly cared about.
It also often causes (or is caused by) eccentric behavior (or mental issues) - but it's been done since forever, and when it's successful, we call it "visionary." When it's not, we call it "toxic."
Not natively, but you have a tools to run multiple brokers manually (run them together at lifespan hooks). In the nearest future we will add this feature at the framework core.
It's curious to see how times have changed. Soft-updates are indeed a very clever solution to the problem of file system consistency in the face of possible failures like OS crashes or power outages.
While journaling "simply" writes a journal of FS ops to a continuous area of the drive (especially important for mechanical drives) which is fsynced faster than random writes across platters, Soft-updates opts to be really clever with the way FS ops ordered, so that what's actually on the drive is always consistent, even with decent amount of write caching. It doesn't guard file content, though, just the file system itself.
Soft-updates is what enabled the BSD's to support short-lived files never touching the physical drive. You could create a file, write to it, read it, close and delete it, and if this was done in a reasonably short amount of time, no writes whatsoever got to the actual hardware. It was wonderful with software which used to generate a lot of temp files, like building C software.
OTOH, if a write got trough to the hard drive, Soft-updates guaranteed that file system structures get written in a way so that if an OS crash or a power failure happened at any single time, the only downside could be some unreferenced blocks, which could be garbage collected later; assuming hardware doesn't lie about fsync, of course...
I think ext4 supports this kind of short-lived-files-never-touch-the-drive caching.
There is a port of Hammer2 being worked on for OpenBSD/NetBSD/FreeBSD/Linux.
I can only hope the developer delivers this to OpenBSD and someone then maintains it since the developer, based on the readme, doesn’t appear to want to maintain OpenBSD or NetBSS longterm.
- Row-level anything introduces write alignment and fsync alignment problems; pages are easier to align than arbitrary-sized rows
- PostgreSQL is very conservative (maybe extremely) conservative about data safety (mostly achieved via fsync-ing at the right times), and that propagates through the IO stack, including SSD firmware, to cause slowdowns
- MVCC is very nice for concurrent access - the Oriole doc doesn't say with what concurrency are the graphs achieved
- The title of the Oriole doc and its intro text center about solving VACUUM, which is of course a good goal, but I don't think they show that the "square wave" graphs they achieve for PostgreSQL are really in majority caused by VACUUM. Other benchmarks, like Percona's (https://www.percona.com/blog/evaluating-checkpointing-in-pos...) don't yield this very distinctive square wave pattern.
I'm sure the authors are aware of these issues, so maybe they will write an overview of how they approached them.
> - Row-level anything introduces write alignment and fsync alignment problems; pages are easier to align than arbitrary-sized rows
OrioleDB uses row-level WAL, but still uses pages. The row-level WAL becomes possible thanks to copy-on-write checkpoints, providing structurally consistent images of B-tree. Check the architecture docs for details.
https://github.com/orioledb/orioledb/blob/main/doc/arch.md
> - PostgreSQL is very conservative (maybe extremely) conservative about data safety (mostly achieved via fsync-ing at the right times), and that propagates through the IO stack, including SSD firmware, to cause slowdowns
This is why our first goal is to become pure extension. Becoming part of PostgreSQL would require test of time.
> - MVCC is very nice for concurrent access - the Oriole doc doesn't say with what concurrency are the graphs achieved
Good catch. I've added information about VM type and concurrency to the blog post.
> - The title of the Oriole doc and its intro text center about solving VACUUM, which is of course a good goal, but I don't think they show that the "square wave" graphs they achieve for PostgreSQL are really in majority caused by VACUUM. Other benchmarks, like Percona's (https://www.percona.com/blog/evaluating-checkpointing-in-pos...) don't yield this very distinctive square wave pattern.
Yes, it's true. The square patters is because of checkpointing. The reason of improvements here is actually not VACUUM, but modification of relevant indexes only (and row-level WAL, which decreases overall IO).
> In particular, I asked ChatGPT to write a function by knowing precisely how I would have implemented it. This is crucial since without knowing the expected result and what every line does, I might end up with a wrong implementation.
In my eyes, it makes the whole idea of AI coding moot. If I need to explain every step in detail - and it does not "understand" what it's doing; I can virtually the statistical trial-and-error behind its action - then what's the point? I might as well write it all myself and be a bit more sure the code ends up how I like it.
link: https://www.linkedin.com/feed/update/urn:li:activity:7289241...