> Are you also claiming you can't be sure someone had to create and raise you to get to the point of asking such questions? We are downstream from parents and society.
Yes exactly. You are sure of nothing except the fact this now exists. The simulation could collapse in the next second. I could awake from this dream.
Don't you see the problem? Now engineers literally do not have any leverage. Did the model make it work? Yes? Then ship it, what are we waiting around for?
That sounds pretty much the same as it’s always been? It used to be: “Does the happy path work? Then ship it! There’s no time to make it robust or clean up tech debt.”
Now there actually is time to make things robust if you learn how to do it.
> Now there actually is time to make things robust if you learn how to do it.
What makes you think you are going to be given time to polish it? You would be pushed to another project. You have more responsibilities with none of the growth.
You’re assuming that building something robustly is significantly more time consuming than the “quick and dirty” version. But that’s not really true anymore. You might need to spend another hour or two thinking through the task up front, but the implementation takes roughly the same amount of time either way.
One cannot build something robust just by thinking about it _a priori_, and while this was somewhat at the periphery of the author's argument, it is important.
You can’t get every detail right up front, but you can build a robust foundation from the beginning.
The argument seems to be that AI is causing managers to demand faster results, and so everything has to be a one-shotted mess of slop that just barely works. My point is that it doesn’t take much longer to build something solid instead. Implementation time and quality/robustness are not tightly coupled in the way they used to be.
I am sorry but this is an insane take. The probability of GCC going haywire with your special snowflake correct C code? Please. Have this EVER happen to you? I am not talking about the performance of the generated assembly because that IS flaky, but functionality wise I do not think so.
If people are so confident about the determinism of LLMs, or at least consider it on par with compilers, please ask it to compile your source code instead. Better yet, replace all your GNU utils with LLM instead. Replace your `ls` with `codex "prompt"`.
I have done this, alias codex --yolo -p . It's very helpful not having to remember every odd command and its parameters. It's a bit more typing but I type faster than invoke and scan through man pages.
There's a lot of "girl games" in the industry. Have you heard of LADS [1]? The studio makes plenty of girl games with the Nikki franchise. There's also Stardew Valley and Disney Dreamlight Valley. It feels like a lot of people just overlook these games.
I know what I'm trying to say, so I can sanity check the output. You can't, unless you listen to the monologue.
That's why I disagree with people that say "just give me whatever you gave the LLM." That's only useful if you, the writer of the prompt, have no intention of looking at the LLM output before sending it.
I haven't thought about it this way but I have been feeling that something is off. I think you got it right. There is a HUGE difference between "I understand the concept" and "I can write down the concept on paper".
Everyone fools themselves into thinking that they understand but the illusion immediately falls apart when they try to write it down. The problem with LLM is that it is actually able to produce something that "works". But more often that not, what it produces is usually beyond what the author actually understand.
Arguably, one could ask "Why does it matter?" If there are enough tests and monitoring to capture the behavior of the program, who cares how it is implemented? To me this is extremely disappointing. I have always wanted to write software that lasts for a century but if software becomes a commodity, I see software quality mattering less and less.
If something is broken, just ask the LLM to patch it. Unlike a human, there is no limit to this. The LLM will happily fix that 50 years old Fortran code that no one understand. There is a lot less pressure to rethink at the fundamental principles.
Clearly India history has a lot to say about mathematics but I don't think they get enough attention. Or am I just ignorant and living in my own bubble? Indian philosophy is also very intriguing.
Regarding attention, anything that does not draw directly from the Greek mainline, does not get much attention in the mainstream.
Lot of interesting mathematics was done by Indians, Persians, Arabs, Mayans.
Indian mathematics has an additional layer of obscurity. Very little was written down and when it was it was written down in picturesque and poetic verses (as a mnemonic device) that used a lot of symbolism and imagery. For the number one they will mention the Sun, for two the moon and so on, these mappings would also change from work to work, chapter to chapter. So one needs a lot of context to understand what a document is saying.
For example the source of the approximation above is described as follows (literal translation) [1]
The degree of the arc, subtracted from the total degrees of half a circle, multiplied by the remainder from that [subtraction], are put down twice. [In one place] they are subtracted from sky-cloud-arrow-sky-ocean [40500]; [in] the second place,
[divided] by one-fourth of [that] remainder [and] multiplied by the final result
[i.e., the trigonometric radius].
There's more to open source than just the code or output, it is also the community. There's apparenticeship, sharing of knowledge, sense of comradery, supporting each other, etc.
My day job uses a lot of open source libraries and projects, and do you know what we do when we fix things? We fork internally and don't upstream any patches.
Do you not see a loss here?
With LLMs, there's even LESS reason to keep up with upstream. We would probably just ask LLM to keep up with the changes commit by commit.
> There's more to open source than just the code or output, it is also the community. There's apparenticeship, sharing of knowledge, sense of comradery, supporting each other, etc.
No there is not. That’s what you impose on it. My code is open, free, and unencumbered. If I don’t want you using it you don’t see it at all. The licenses are there to make people happy.
I think your idealized list of attributes of “open source” is admirable. However, the apprenticeship, comradery, and support are a specific and often sought out feature of some development ‘communities’ for specific software. I’d also say that the ‘loss’ when fixes, updates, optimizations of open source software is not up-streamed is real, but this has very little to do with adopting or promoting the externalities (no matter how laudable) you want to see in certain software’s development.
I personally don’t care about the community, its composition, or its internal structure for a lot of software I use. Even when I’m compiling from source and customizing smaller applications for personal efficiency, I’m not usually interested in being a part of some distributed community centered on that software. Some times I am engaged in the community and appreciate it and the work required to maintain that community. But in either case, the software is “open source”.
That's all great, but to me the primary point is rms' original grievance with that printer driver. If the source is open, anyone can improve it. Multiple anyones can improve it! They can even collaborate on message boards and make a nice community, but this is certainly not a requirement.
The biggest takeaway for me from LLMs is that the implementation details no longer. If you have a sufficiently detailed tests and requirements, there is going to be a robot that will roll the dice until it fits the tests and requirements.
Yes exactly. You are sure of nothing except the fact this now exists. The simulation could collapse in the next second. I could awake from this dream.
reply