I like to ask LLMs to find problems o improvements in 1-2 files. They are pretty good at finding bugs, but for general code improvements, 50-60% edits are trash. They add completely unnecessary stuff. If you ask them to improve a pretty well-written code, they rarely say it's good enough already.
For example, in a functional-style codebase, they will try to rewrite everything to a class. I have to adjust the prompt to list things that I'm not interested in. And some inexperienced people are trying to write better code by learning from such changes of LLMs...
I asked Claude the other day to look at one of my hobby projects that has a client/server architecture and a bespoke network protocol, and brainstorm ideas for converting it over to HTTP, JSON-RPC, or something else standards-based. I specifically told it to "go wild" and really explore the space. It thought for a while and provided a decent number of suggestions (several I was unaware of) with "verdicts". Ultimately, though, it concluded that none of them were ideal, and that the custom wire protocol was fine and appropriate for the project. I was kind of shocked at this conclusion: I expected it to behave like that eager intern persona we all have come to expect--ready to rip up the code and "do things."
If you just ask it to find problems, it will do its best to find them - like running a while loop with no return condition. That's why I put some breaker in the prompt, which in this case would be "don't make any improvements if the positive impact is marginal". I've mostly seen it do nothing and just summarize why, followed by some suggestions in case I still want to force the issue
I guess "marginal impact" for them is a pretty random metric, which will be different on each run. Will try it next time.
Another problem is that they try to add handling of different cases that are never present in my data. I have to mention that there is no need to update handling to be more generalized. For example, my code handles PNG files, and they add JPG handling that never happens.
Pycharm does not have good type checking. It has the best type inference, but its type checking is very basic. It’s not strict, that’s why you don’t see a lot of errors. When complex types don’t much, it won’t complain.
Yeah, but I was doing the same thing 10 years ago with include mixed with extends and blocks. I can just include a file inside a template or render it directly.
you're kinda right, {% partial ... %} vs {% include ... %} is not a big difference, but my mind was vaguely thinking that "includes" have often been seen as large templates, whereas partial have been after the component era with the idea of making small blocks. (my 2 cents)
> A change made to how Cloudflare's Web Application Firewall parses requests caused Cloudflare's network to be unavailable for several minutes this morning. This was not an attack; the change was deployed by our team to help mitigate the industry-wide vulnerability disclosed this week in React Server Components. We will share more information as we have it today.
I always suspected RSC was actually a secret Facebook plan to sabotage the React ecosystem now that their competitors all use it to some degree. Now I’m convinced.
> A change made to how Cloudflare's Web Application Firewall parses requests caused Cloudflare's network to be unavailable for several minutes this morning. This was not an attack; the change was deployed by our team to help mitigate the industry-wide vulnerability disclosed this week in React Server Components. We will share more information as we have it today.
I tried OpenAI models for coding in Go, but they constantly say your syntax is not correct. Let me rewrite your whole file without `any`.`any` was introduced in 2022. It takes some time to adopt it in codebases, but they should not be doing stuff like that at the end of 2025.
What's the current best resources to learn assembly? So that I can understand output of simple functions. I don't want to learn to write it properly, I just want to be able to understand on what's happening.
You can select the assembly output (I like RISCV but you can pick ARM, x86, mips, etc with your choice of compiler) and write your own simple functions. Then put the original function and the assembly output into an LLM prompt window and ask for a line-by-line explanation.
Also very useful to get a copy of Computer Organization and Design RISC-V Edition: The Hardware Software Interface, by Patterson and Hennessy.
A lot of C# and Java code is oriented towards web backends, too. Which are quite big and complex. So it seems natural that languages in the same design space (trad OO) converge on similar features. I think the only exception these days is Go.
I think these days you could change "You can write Fortran in any language" to "You can structure your code like Spring in any language"…
I don't see how making a language more complex can help with that. Complex languages makes sense for system programming where you want to squeeze some performance.
Still, even if it was "just" the web, why wouldn't it evolve? It's a great language, with a big user base, and there's always room for improvements and to increase the developer experience
I downvoted you before reading the fine article. I'm back to correct that.
The new array_first() and array_last() functions are nice, everything else is either reimplantation of existing features or "features"which will make maintainability more difficult. The pipe operator is one such example. I don't need it - these nested methods are not really an issue in any codebase I've seen. The new syntax only works for unary functions, so higher arity functions must be wrapped in an arrow function. It's a mess and more bug prone than just nesting the functions.
Many of the newer features have this problem. Like the match keyword, enums, closures etc. They are half-baked versions of what could be powerful and expressive features.
Meanwhile it seemingly abandoned features and unique selling points, like the in-built templating, associative arrays with value semantics and the fact that it integrates well with C or the simple fact that it can be used to write web server scripts very easily. To me, many of these cool features have been largely ignored or even moved away from.
>Like the match keyword, enums, closures etc. They are half-baked versions of what could be powerful and expressive features.
The problem is that the php project is maintained by (mostly) unsponsored contributors. There’s not a giant corporation behind it. Each of these new features are designed by a couple people (per rfc) and then discussed and voted by other contributors. The match keyword, for example, is consider as the future scope of this rfc which is still being worked on: https://wiki.php.net/rfc/pattern-matching
Also, a lot of these half baked features are designed to be implemented in steps because of what I said in my other paragraph and to increase the odds of being accepted (it’s well known that it’s hard to get an rfc accepted and a lot of good ones haven’t been able to pass the voting phase).
When you consider this, it’s amazing that we get so much from so little.
To be fair, PHP's internal development was once heavily sponsored by a corporation. That corporation's sponsored developer(s) were the primary source of resistance against BC breakage and forced the language to stagnate for years.
I don't understand how this is more bug prone. The nesting is a HUGE problem because it's extremely unreadable. The arrow is much more readable, and array functions are very simple too.
How many tubes does that appear in any codebase you've worked on? Those types of constructions are typically hidden away in "helper functions" that are straightforward to understand and debug. They are certainly not typical in business logic.
Now we have two syntax to be familiar with and maintain. And you just know the clowns are going to come along and convert one syntax to the other because they can, which completely ruins the git commit and you can't tell what actual functionally was changed at a glance. There will be bickering and bikeshedding about "modernizing" codebases.
I don't know, I think it's really fine. It's very typical to compose a bunch of array functions together and, honestly, I think that's good form most of the time. This makes that a little bit easier.
I'm sort of on the opposite side. I'm unconvinced by extra functions for arrays in the global namespace and I'm happier about syntactic improvements and debugging improvements.
A lot of people behind APTs are low-skilled and make silly mistakes. I worked for a company that investigates traces of APTs, they make very silly mistakes all the time. For example, oftentimes (there are tens of cases) they want to download stuff from their servers, and they do it by setting up an HTTP server that serves the root folder of a user without any password protection. Their files end up indexed by crawlers since they run such servers on default ports. That includes logs such as bash history, tool logs, private keys, and so on.
The security world overemphasizes (fetishizes, even,) the "advanced" part because zero days and security tools to compensate against zero days are cool and fun, and underemphasizes the "persistent" part because that's boring and hard work and no fun.
And, unless you are Rob Joyce, talking about the persistent part doesn't get you on the main stage at a security conference (e.g., https://m.youtube.com/watch?v=bDJb8WOJYdA)
For example, in a functional-style codebase, they will try to rewrite everything to a class. I have to adjust the prompt to list things that I'm not interested in. And some inexperienced people are trying to write better code by learning from such changes of LLMs...
reply