vouwfietsman

> Do we want software to be more complex?

No but the complexity of software should follow from the complexity of end user features. Essential vs accidental complexity. Some problems are complex, they require complex software. Some problems are simple, so the software should be simple. In an ideal world, at least.

> However, it might make it easier? Isn't easy really important in some domains?

Indeed, this is maybe a better wording of the problem: it is easier but not simpler. Easy is never important in a domain, except perhaps adversarial domains like marketing or sales. Easy is shortsighted. Easy is not economical because easy choices are not the right choice.

> If Word startup speed was important then more engineering resources would be expended to solve that problem

No this is a common misconception about economics: things do not at all behave rationally in supply/demand situations. People want the wrong things all the time, people act irrationally all the time, business don't know what value is all the time, large problems are ignored all the time.

> Unfortunately I think Blow, et. al, only give this question a shallow examination

I am not sure about this, maybe so. Either way, so do you: it is not at all about performance, but performance is the canary in the coalmine: it is a direct translation of the essential vs accidental complexity problem.

If I can serve you a webpage in 10ms, and you serve me that same webpage in 3000ms (excluding network latency), you are obviously solving that problem in a way that is an order of magnitude more complex than what I have proven is necessary to solve the problem. Either by involving more software, more hardware instructions, more infrastructure network hops, etc. In other words: performance is an easy objective metric for the complexity that lies behind (an otherwise opaque) piece of software.

This is a bit of a simplification of the ideas of Blow, Muratori et al, a much better source for the ideas can be found in "Preventing the collapse of civilization" [0].

The argument made there is that "software quality" in the uncle bob sense, or in your domain version, is not necessarily wrong but at the very least subjective, and should not be used to guide software development.

Instead, we can state that the software we build today does the same job it did decades ago while requiring much vaster resources, which is objectively problematic. This is a factual statement about the current state of software engineering.

The theory that follows from this is that there is a decadence in how we approach software engineering, a laziness or carelessness. This is absolutely judgemental, but its also clearly defended and not based on gut feel but rather on these observations around team sizes/hardware usage vs actual product features.

Their background in videogames makes them an obvious advocate for the opposite, as the gaming industry has always taken performance very seriously as it is core to the user experience and marketability of games.

In short, it is not about "oh it takes 2 seconds to startup word ergo most programmers suck and should pray to stand in the shadow of john carmack", it is about a perceived explosion in complexity both in terms of number of developers & in terms of allocated hardware, without an accompanying explosion in actual end user software complexity.

The more I think about this, the more I have come to agree with this sentiment. Even though the bravado around the arguments can sometimes feel judgemental, at its core we all understand that nobody needs 600mb of npm packages to build a webapp.

[0]: https://www.youtube.com/watch?v=ZSRHeXYDLko

> That's not how automated tests work > today's LLMs are able to recreate all your unit tests from scratch. > That's the responsibility of the developer > LLMs are quite capable of delivering fully working apps with a single, detailed prompt

You seem to be very resolute in positing generalizations, I think those are rarely true. I don't see a lot of benefit coming out of a discussion like this. Try reading my replies as if you agree with them, it will help you better understand my point of view, which will make your criticism more targeted, so you can avoid generalizations.

Aha! Like that. Yes that's interesting, the only other alternative would be manual classification of novel data, so extremely labour intensive. If an LLM is able to do the same classification automatically it opens up use cases that are otherwise indeed impossible.

> No. It makes sense to use LLMs to generate tests. Even if their output matches the worst output the average human can write by hand, having any coverage whatsoever already raises the bar from where the average human output is.

Although this is true, it disregards the fact that prompting for tests takes time which may also be spent writing tests, and its not clear if poor quality tests are free, in the sense that further development may cause these tests to fail for the wrong reasons, causing time spent debugging. This is why I used the word "augment": these tests are clearly not the same quality as manual tests, and should be considered separately from manual tests. In other words, they may serve to elevate below average code or augment manual tests, but not more than that. Again, I'm not saying it makes no sense to do this.

> That's not the LLM's responsibility. Humans specify what they want and LLMs fill in the blanks. If today's LLMs output bad results, that's a reflection of the prompts. Garbage in, garbage out.

This is unlikely to be true, for a couple reasons: 1. Ambiguity makes it impossible to define "garbage", see prompt engineering. In fact, all human natural language output is garbage in the context of programming. 2. As the LLM fills in blanks, it must do so respecting the intention of the code, otherwise the intention of the code erodes, and its design is lost. 3. This would imply that LLMs have reached their peak and only improve by requiring less prompting by a user, this is simply not true as it is trivial to currently find problems an LLM cannot solve, regardless of the amount of prompting.

Indeed the idea of a meta LLM, or some sort of clear distinction between manual and automated-but-questionable tests makes sense. So what bothers me is that does not seem to be the approach most people take: code produced by the LLM is treated the same as code produces by human authors.

Right but by your reasoning it would make sense to use LLMs only to augment an incomplete but rigorous testing process, or to otherwise elevate below average code.

My issue is not necessarily with the quality of the code, but rather with the intention of the code, which is much more important: a good design without tests is more durable than a bad design with tests.

Are you referring to the process of requirement engineering? Because although I agree its a fuzzy natural language interface, behind the interface should be (heavy should) a rigorously defined & designed system, where fuzzyness is eliminated. The LLMs need to work primarily with the rigorous definition, not the fuzzyness.

Maybe someone can help me out here:

I always get the feeling that fundamentally our software should be built on a foundation of sound logic and reasoning. That doesn't mean that we cannot use LLMs to build that software, but it does mean that in the end every line of code must be validated to make sure there's no issues injected by the LLM tools that inherently lack logic and reasoning, or at least such validation must be on par with human authored code + review. Because of this, the validation cannot be done by an LLM, as it would just compound the problem.

Unless we get a drastic change in the level of error detection and self-validation that can be done by an LLM, this remains a problem for the foreseeable future.

How is it then that people build tooling where the LLM validates the code they write? Or claim 2x speedups for code written by LLMs? Is there some kind of false positive/negative tradeoff I'm missing that allows people to extract robust software from an inherently not-robust generation process?

I'm not talking about search and documentation, where I'm already seeing a lot of benefit from LLMs today, because between the LLM output and the code is me, sanity checking and filtering everything. What I'm asking about is the: "LLM take the wheel!" type engineering.

> free market competition always was and is the main source of human progress

Not really though, most progress is driven by scientific or government institutions, offloaded only to private enterprise for execution, usually still heavily subsidized to cover risk.

True free market competition creates monopolies and stagnation, this is not a controversial opinion.

I'm not sure what you mean here, since in different replies to this same thread you've already encountered someone who is, by virtue of Rusts borrow checker design, forced to change his code in a way that is, to that person, net negative.

Again this person has no trouble understanding the BC, it has trouble with the outcome of satisfying the BC. Also this person is writing Vulkan code, so intelligence is not a problem.

> is quite common and widely understood

This is an opinion expressed in a bubble, which does not in any-way disprove that the reverse is also expressed in another bubble.

A lot has been written about this already, but again I think you're simplifying here by saying "once you get it". There's a bunch of options here for what's happening:

1. The borrow checker is indeed a free lunch 2. Your domain lends itself well to Rust, other domains don't 3. Your code is more complicated than it would be in other languages to please the borrow checker, but you are unaware because its just the natural process of writing code in Rust.

There's probably more things that could be going on, but I think this is clear.

I certainly doubt its #1, given the high volume of very intelligent people that have negative experiences with the borrow checker.

> The borrow checker is automatic and works across all variables.

Not that I'm such a Rust hater, but this is also a simplification of the reality. The term "fighting the borrow checker" is these days a pretty normal saying, and it implies that the borrow checker may be automatic, but 90% of its work is telling you: no, try again. That is hardly "without needing to do much extra at all".

That's what you're missing.

Aha, ok. I'm not 100% sure I understand but I imagine you mean that bureaucracy, viewed negatively as simply the execution of some process, is expedited by form validation. I have to agree then indeed that this is true. I thought of bureaucracy more as the whole of the functioning, so efficiency would include successful resolution, not just successful process.

I love me some FOSS but I don't think that helps here, does it? In the end the person having domain knowledge is no longer in control of the process, because its been transferred to an automated system. Therein lies the issue, even if the software can be modified it cannot be done by the domain expert, or on the fly, or at low effort.

Yes and no, form validation is a double edged sword: without it whoever receives the data may have to deal with inconsistencies, so removing that will increase efficiency.

However, the flexibility and adaptability of human interaction is lost when an intermediate digital system enforces rules without exception, and that loss can absolutely result in inefficiencies because the world is always changing and your digital models rarely reflect reality.

Let's say you work for a government agency processing stolen bikes. To fill in your form you must select a category of bike, but "fatbike" is not an option as the software was built in 2012. As a human using paper, you could easily talk to your colleagues and agree that you can now check the "e-bike" checkmark and write "fat" beside it to indicate a fatbike. In the software world, some company (hopefully the one that built the original software) will quote you 50k to do it, it won't work correctly, and you'll thank them for the pleasure of dealing with them.

In another example, let's say you have to get a building permit to build an extension to your house, and based on your postal code the system tells you that you are too close to a nature reserve and are not allowed to do any construction, and the system rejects your application. The government has recently ruled that this does not apply anymore to residential housing development, to improve the housing crisis situation, but the software is not up to date with this change. In a paper world the human could simply approve the permit based on their knowledge of the real world, in the software world the computer program will never approve your permit.

This whole thing may sound anti-automation. Its not meant to be, rather its a reminder that the processes we automate should leave enough flexibility and adaptability to deal with the real world. This does not come for free though: the bike system would need to allow you to add categories, or a free-form details field. The permit system should work in an advisory manner, but allow overrides by a professional specifying a reason, or it should allow you to disable/modify/create rules on the fly.

However, no matter what you do, form validation will always leave somebody out in the cold, some edge case uncovered, that a human could always resolve, but a system cannot.

Interesting! There seem to be a lot of limitations though:

> Boost.PFR library works with types that satisfy the requirements of SimpleAggregate: aggregate types without base classes, const fields, references, or C arrays:

And in general seems to be dependent on C++20 for getting field names.

Do you know how this works? Initializer lists seem somehow involved.

Takes a bunch of manual work per POD, that's the gist of it.

Fundamentally, if I have struct { int x = 3; std::string y = "bla"; }

I want the json to look like { x: 3, y: "bla" } without writing any code specific to the struct, and have it work bidirectionally. This is currently not possible because of a lot of reasons, but most trivially because the names "x" and "y" do not even exist anymore in your compiled code.

> by pretending it's no different than some cut and dried computational system

This is not really what is going on, what is going on is a mix-up in interpreting the meaning of words, because the meaning of words is not transitive between subject matter unless we arrive at a scientific definition which is leading, and we have not (yet).

When approaching the word consciousness from a spiritual POV, it is clear that LLMs may not possess it. When approaching consciousness from a technical point of view, it is clear that LLMs may possess it in the future. This is because the spiritual POV is anthropologically reductive (consciousness is human), and the technical POV is technically reductive (consciousness is when we can't tell it apart).

Neither statements help us clarify opposing positions because neither definitions are falsifiable, and so not scientific.

They absolutely are in the context of a technical, scientific or mathematical subject.

Like in the subject of LLMs everyone knows what a "token" or "context" means, even if they might mean different things in a different subject. Yet, nobody knows what "consciousness" means in almost any context, so it is impossible to make falsifiable statements about consciousness and LLMs.

Making falsifiable statements is the only way to have an argument, otherwise its just feelings and hunches with window dressing.

Hilariously, I was once trying to install MacOS to a HP university laptop, hackintosh style, and got into a situation where after hours of kernel panics and boot configurations I finally got far enough to see the MacOS install screen on the display!

I did not have working trackpad or usb, but undeterred I continued with keyboard navigation through the install menu, going further and further, partitioning and formatting drives and whatnot, until finally I hit the language selection dropdown, one of the last steps in the install process. This screen, although simple, did not have keyboard accessibility. I tried everything I could but never got the mouse to work, and was stuck at the language select. Frustratingly the screen also played some weird pop music full blast which I never was able to lower the volume of.

I still think somehow they knew, that they were mocking me, knowing that the trackpad would always work on a real mac, and only kids with too much free time would be stuck on the final step of the install process...

> But it is clear humans are capable of ...

Its not though, nobody really knows what most of the words in that sentence mean in the technical or algorithmical sense, and hence you can't really say whether llms do or don't possess these skills.

I am not sure what your point is, as you have not yet described it fully. Do you mean to suggest that you just drop the C of ACID? What is there to gain exactly besides the freedom that is like the freedom of a blind man crossing the freeway.

How do you regain the C from the application layer? Do you reject scaling horizontally? Or does the C just interfere with achieving the mellow developer nirvana.

> with discounting the observability challenges > handwaving away these architectural differences

I am doing neither of these things. I am only saying you will have observability problems whether you do LP or WS, because you are stepping away from the request/response model that most tools work with. As such, its weird to argue that "observability remains unchanged".

The points mentioned against websockets are mostly fud, I've used websockets in production for a very heavy global data streaming application, and I would respond the following to the "upsides" of not using websockets:

> Observability Remains Unchanged

Actually it doesn't, many standard interesting metrics will break because long-polling is not a standard request either.

> Authentication Simplicity

Sure, auth is different than with http, but not more difficult. You can easily pass a token.

> Infrastructure Compatibility

I'm sure you can find firewalls out there where websockets are blocked, however for my use case I have never seen this reported. I think this is outdated, for sure you don't need "special proxy configurations or complex infrastructure setups".

> Operational Simplicity

Restarts will drop any persistent connection, state can be both or neither in WS or in LP, it doesn't matter what you use.

> Client implementation

It mentions "no special WebSocket libraries needed" and also "It works with any HTTP client". Guess what, websockets will work with any websocket client! Who knew!

Finally, in the conclusion:

> For us, staying close to the metal with a simple HTTP long polling implementation was the right choice

Calling simple HTTP long polling "close to the metal" in comparison to websockets is weird. I wouldn't be surprised if websockets scale much better and give much more control depending on the type of data, but that's besides the point. If you want to use long polling because you prefer it, go ahead. Its a great way to stick to request/response style semantics that web devs are familiar with. Its not necessary to regurgitate a bunch of random hearsay arguments that may influence people in the wrong way.

Try to actually leave the reader with some notion of when to use long polling vs when to use websockets, not a post-hoc justification of your decision based on generalized arguments that do not apply.

Let me be the void.

> ... an illustration on how everybody doing A doesn’t mean shit.

I don't think you understand either the parent or me. The point is that the majority of people do something wrong that the author is trying to help prevent, so just by virtue of that being true it stops being "stupid and obvious".

> We can all agree that something huge is missing if you don’t learn algebra or addition.

We can indeed all agree on a separate topic, but that does nothing for the topic we are actually discussing. The core of your entire argument is that somehow FP is fundamental to solving complexity, you seem to think that everybody already agrees with this. We don't.

> Even the atheist is a zealot

No, he is not. Being an atheist or not is a completely internal world view, being a zealot implies being vocal and aiming to convert or convince others.

> The only way to not be a zealot is to be a zealot about being unsure of everything

No this is also not true, see above. Things are not as black and white as you think.

> People insinutated a lot of things because I used religion as an analogy.

The point of an analogy is to improve the discussion through clarity, you made a bad analogy and in doing so made the discussion worse and less clear.

> The ONLY point I was trying to make is that a majority or large group of people believing in or doing plan A doesn't mean shit for plan A.

Which, again, is missing the point. The majority is already judged by the parent, namely: they are doing something wrong. Hence it does not matter that the majority is not always right, the point of the parent is already that the majority is wrong. You are trying to argue for something that nobody brought up, you are arguing against the statement: "the book is good because everybody is doing what it describes". Nobody is saying that, and so you're arguing into the void.

No, its not similar at all.

Parent is telling you: "if A is so simple and obvious, why does nobody do A", your counter argument: "if many people believe A it does not mean it is true". This is entirely unrelated, the point is that these things are NOT obvious to the average programmer, he/she would benefit from learning this, and claiming that these things are broadly "stupid and obvious" is petty and false.

Also, the things you're saying just don't add up with your criticism that the author is missing some fundamental part of software philosophy. If the author is only missing something, then it still makes sense for the majority to learn the things he is saying, at least, as explained by your parent.

Finally, if anything can be compared to religion, it surely is the evangelism of functional programming zealots.

I thought that was a very strange thing to do from the patriarch, until I googled non-allopathic and found out you're setting fire to 4-5k a month.

Its homeopathy, NOT healthcare.

Compression is only ever as good as the information it is given, if given text, it can do an OK job using general entropy encoding. However, most data is not text, even log data is not text. Log data is timestamps, numbers, enums, indices, guids, text, etc. Each of those categories, combined with how they are layed out, can be compressed in different optimal ways, resulting in different optimal compression ratios based on your specific log format. As a simple example, compressing 3D meshes as meshes is an order of magnitude better than compressing 3D meshes as text.

Sure, zipping your logs gives you a LOT, and you should do it, but if the result disappoints it is not the end of the road, at all.