...because your work projects are bigger, there's only so big a black box can get before you lose all comprehension of it, and splitting it to smaller black boxes the shapes of which you keep refining is programming, and the part of it LLMs currently can't do
No, the argument is that it's less appealing to leadership even when it's the better outcome, but not vice versa - it might or might not be better for reasons unrelated to said appeal ("standardizing on something across the company vs having everyone roll their own variant is a hard decision to make.")
And of course you can also end up standardizing on something because it benefits someone good at politics even though it's a bad idea, I just didn't elaborate on this stuff because it is too far away from the subject. I didn't say you should always stanardize on something though, I said that it was a hard decision
Well, they are 2 different failure modes. You have people dumping their work on someone all too willing (I even know productive people who just like helping way more than doing their own work and then complain that they have no time for said work, not as easy to manage as it sounds), and you also have teams which mostly refuse to do anything from anyone. You can tell a "workplace shark" from a more vegetarian workplace animal by whether they credit people for their work.
What are you disagreeing with in TFA though? I agree with your points, I just think there are counterpoints and this needs to be decided on a case by case basis
Right, but that's more a lack of reward than outright punishment. If you work with these people on something that "crosses boundaries" and that something succeeds, you can credit them and in the hope to help their career. I agree that larger places are worse in this regard (though there can be a small part of a large place which is, well, small enough to work like a small one), and that you should generally make sure you're rewarded for your work, and if you're not, either work less or work elsewhere.
Uber reported that their Go code has quantitatively more concurrency bugs than code in other languages, and while to me it seems obvious from looking at Go's concurrency model, this is backed by actual data. Is there any quantitative data to back the claim that Go is better in an LLM based workflow than another popular language?
Bush knew what he was doing - Hamas has the influence it has because the US wants it to have it. When Trump decided he wants them to release Israeli hostages he forced them to do it rather quickly, all things considered, showing who really controls Hamas. Restraining American "allies" is key to how America understands its interests and Hamas is an excellent lever to pressure Israel, or Hamas-controlled Gaza wouldn't be flooded with American and European money.
Similarly, Obama supported the Muslim Brotherhood because he did; in Ukraine for instance the same admin supported a coup against the elected government (this is not to say that Russia's actions in Ukraine are "justified", it's just a fact.) Democracy has nothing to do with any of this
Currently these models have a limited context window, so the value of a session is not that high, at any rate at some point the model will have forgotten things. If in the future the model will truly learn / "change" as a result of the interaction, in any case this will be non portable to another model. So I think this is kinda moot
I'm able to see how it's safer than Rust but what I like is that it works with existing C++ code; I don't think the extra safety relative to Rust is worth the performance penalty (not to mention needing to recompile every dependency) and I doubt you think that, either
I think Fil-C is awesome and I very much like the style in which you present your work as well. (Hope I'm not being too emotional here!)
FWIW, I can see where TFA is coming from and I had the urge to write something "in defense of Rust" after listening to / reading some of your recent comments. I think your sister comment about the limits to Rust memory safety being real as much as the limits to Fil-C's performance and practicality is spot on, but the feeling (those emotions again) one gets from much of your commentary is that you downplay the latter quite a bit.
I think the real argument for Fil-C is that you aren't going to "rewrite in Rust" but you can often realistically recompile in Fil-C and pay the performance penalty; the fact that that Rust rewrite could also end up less safe is I think should be argued mainly from the AI angle where the only practical way is an LLM based rewrite but that would have a load of unsafe - way more than a "proper" rewrite - to be practical and the recent $100K Bun rewrite is a testament to that.
(I would love nothing more than for Fil-C to become as widely used as it practically can, since no other approach does nearly as much to secure C / C++ code and a lot of said code is out there; and security aside, it could prevent a lot of data corruption that most major C++ programs gift to their users.)
Flush denormals to zero. Even their inventor had trouble writing correct code in their presence - see the Appendix to that "what every programmer should know..." paper
Indeed you're supposed to, but that way if someone calls exit(0), it looks like the program worked fine, when in fact they committed some debug code and made the program no longer run to completion. "Yay, done" was put in for the scripts to flag this sort of thing, presumably based on experience.
While we're at it, when did central banks start to buy lots of gold and under which POTUS? Could it have something to do with the freezing of hundreds of billions of some sovereign assets?
What produces this Iranian "mercy" at a time when Iran is extensively bombed, if not a combination of defensive and offensive capabilities providing escalation dominance?
"Ironically, among the four stages, the compiler (translation to assembly) is the most approachable one for an AI to build. It is mostly about pattern matching and rule application: take C constructs and map them to assembly patterns.
The assembler is harder than it looks. It needs to know the exact binary encoding of every instruction for the target architecture. x86-64 alone has thousands of instruction variants with complex encoding rules (REX prefixes, ModR/M bytes, SIB bytes, displacement sizes). Getting even one bit wrong means the CPU will do something completely unexpected.
The linker is arguably the hardest. It has to handle relocations, symbol resolution across multiple object files, different section types, position-independent code, thread-local storage, dynamic linking and format-specific details of ELF binaries. The Linux kernel linker script alone is hundreds of lines of layout directives that the linker must get exactly right."
I worked on compilers, assemblers and linkers and this is almost exactly backwards
The list of the oil producers listed and omitted on a given forum in these contexts is always interesting. On HN it is often SA or Russia, and almost never Qatar or Iran.
std::move is definitely for there for optimizing application code and is often used there. another silly thing you often see is people allocating something with a big sizeof on the stack and then std::moving it to the heap, as if it saves the copying
You could say the same things about assemblers, compilers, garbage collection, higher level languages etc. In practice the effect has always been an increase in the height of a mountain of software that can be made before development grinds to a halt due to complexity. LLMs are no different