| ▲ | blibble 5 days ago |
| I can count the amount of times in my 20 year career that I've had to look at compiler generated assembly on one finger and I've never looked at the machine code produced by an assembler (other than when I wrote my own as a toy project) is the same true of LLM usage? absolutely not and it never will be, because it's not an abstraction |
|
| ▲ | KoolKat23 5 days ago | parent | next [-] |
| It's still early stages, that is why. It is not yet good enough or there is not yet sufficient trust. Also there are still resources allocated to checking the code. I saw a post yesterday showing Brave browser's new tab using 70mb of RAM in the background. I'm very sure there's code there that can be optimized, but who gives a shit. It's splitting hairs and our computers are powerful enough now that it doesn't matter. Immateriality has abstracted that particular few line codes away. |
| |
| ▲ | LandR 5 days ago | parent | next [-] | | >> I saw a post yesterday showing Brave browser's new tab using 70mb of RAM in the background. I'm very sure there's code there that can be optimized, but who gives a shit. I do. This sort of attitude is how we have machines more powerful than ever yet everything still seems to run like shit. | | |
| ▲ | const_cast 5 days ago | parent [-] | | This is barely related but I bet that the extra 70 mb of ram isn't even waste - it's probably an optimization. Its possible they're spinning up a JS VM preemptively so when you do navigate you have a hot interpreter for the inevitable script. Maybe they allocate memory for the DOM too. | | |
| ▲ | KoolKat23 5 days ago | parent [-] | | Probably the case, I felt bad using this as an example as I don't know the specifics, but thought it is an easy way to convey my point (sorry if so Brave developers). |
|
| |
| ▲ | ncruces 5 days ago | parent | prev | next [-] | | > It's still early stages, that is why. Were we advised to check compiler output every single time "in the early days"? No, that's not the difference. A compiler from whatever high/low level language is expected to translate a formal specification of an algorithm faithfully. If it fails to do so, the compiler is buggy, period. A LLM is expected to understand fuzzy language and spit out something that makes sense. It's a fundamentally different task, and I trust a human more with this. Certainly, humans are judged by their capability to do this, apply common sense, ask for necessary clarification, also question what they're being asked to do. | |
| ▲ | rafterydj 5 days ago | parent | prev | next [-] | | I feel like I'm taking crazy pills or misunderstanding you. Shouldn't it matter that they are using 70mb of RAM more or less totally wastefully? Maybe not a deal breaker for Brave, sure, but waste is waste. I understand the world is about compromises, but all the gains of essentially every computer program ever could be summed up by accumulation of small optimizations. Likewise, the accumulation of small wastes kills legacy projects more than anything else. | | |
| ▲ | Mtinie 5 days ago | parent | next [-] | | It could matter but what isn't clear to me is if 70MB is wasteful in this specific context. Maybe? Maybe not? Flagging something as potentially problematic is useful but without additional information related to the tradeoffs being made this may be an optimized way to do whatever Brave is doing which requires the 70MB of RAM. Perhaps the non-optimal way it was previously doing it required 250MB of RAM and this is a significant improvement. | | | |
| ▲ | KoolKat23 5 days ago | parent | prev [-] | | Yes it can be construed as wasteful. But it's exactly that, a compromise. Could the programmer spend their time better elsewhere generating better value, not doing so is also wasteful. Supply and demand will decide what compromise is acceptable and what that compromise looks like. |
| |
| ▲ | ToucanLoucan 5 days ago | parent | prev | next [-] | | > It's still early stages, that is why. I have been hearing (reading?) this for a solid two years now, and LLMs were not invented two years ago: they are ostensibly the same tech as they were back in 2017, with larger training pools and some optimizations along the way. How many more hundreds of billions of dollars is reasonable to throw at a technology that has never once exceeded the lofty heights of "fine"? At this point this genuinely feels like silicon valley's fever dream. Just lighting dumptrucks full of money on fire in the hope that it does something better than it did the previous like 7 or 8 times you did it. And normally I wouldn't give a shit, money is made up and even then it ain't MY money, burn it on whatever you want. But we're also offsetting any gains towards green energy standing up these stupid datacenters everywhere to power this shit, not to mention the water requirements. | | |
| ▲ | SamPatt 5 days ago | parent | next [-] | | The difference between using Cursor when it launched and using Cursor today is dramatically different. It was basically a novelty before. "Wow, AI can sort of write code!" Now I find it very capable. | | | |
| ▲ | KoolKat23 5 days ago | parent | prev [-] | | I know from my own use case, it went from Gemini 1.5 being unusable to Gemini 2.0 being useable. So 2 years makes a big difference. It's out there right now being used in business making money. This is tangible. I suspect there's a lot more use out there generating money than you realize, there's no moat in using it, so I'm pretty sure it's kept on the downlow for fear of competitors catching up (which is quick and cheap to do). How far can one extrapolate? I defer to the experts actually making these things and to those putting money on the line. |
| |
| ▲ | vrighter 4 days ago | parent | prev | next [-] | | I hate this "early stages" argument. It either works, or it doesn't. If it works sometimes that's called "alpha software" and should not be released and hyped as a finished product. The early stages of the GUI paradigm at release started with a fully working GUI. Windows didn't sometimes refuse to open. The OS didn't sometimes open the wrong program. The system didn't sometimes hallucinate a 2nd cursor. The system worked and then it was shipped. The "early stages" argument means "not fit for production purposes" in any other case. It should also mean the same here. It's early stages because the product isn't finished (and can't be, at least with current knowledge) | |
| ▲ | throwaway1777 5 days ago | parent | prev | next [-] | | [dead] | |
| ▲ | 5 days ago | parent | prev [-] | | [deleted] |
|
|
| ▲ | elAhmo 5 days ago | parent | prev | next [-] |
| It is an abstraction. Just because you end up looking at what the prompt looks like “under the hood” in whichever language it produced the output, doesn’t mean every user does. Similar as with assembly, you might have not taken a look at it, but there are people that do and could argue the same thing as you. The lines will be very blurry in the near future. |
| |
| ▲ | card_zero 5 days ago | parent | next [-] | | I can fart in the general direction of the code and that's a kind of abstraction too. It distills my intent down to a simple raspberry noise which could then be interpreted by sufficiently intelligent software. | | |
| ▲ | joenot443 5 days ago | parent | next [-] | | Sort of like when people argue about "what is art?", some folks find it clever to come up with the most bizarre of examples to point to, as if the entire concept rests on the existence of its members at the fringe. Personally, I think if your farts are an abstraction that you can derive useful meaning from the mapping, who are we to tell you no? | | |
| ▲ | card_zero 5 days ago | parent [-] | | So, can derive useful meaning from is the point of contention. (Also: bizarre examples = informative edge cases. Sometimes.) |
| |
| ▲ | Phemist 5 days ago | parent | prev | next [-] | | The final result of course depending on how many r's there are in the raspberry. | |
| ▲ | chaps 5 days ago | parent | prev [-] | | Could you please expand on this thought? I'm curious where this abstraction's inflection points are. |
| |
| ▲ | rsynnott 5 days ago | parent | prev [-] | | > Just because you end up looking at what the prompt looks like “under the hood” in whichever language it produced the output, doesn’t mean every user does. > Similar as with assembly, you might have not taken a look at it, but there are people that do and could argue the same thing as you. ... No. The assembler is deterministic. Barring bugs, you can basically trust that it does exactly what it was told to. You absolutely cannot say the same of our beloved robot overlords. |
|
|
| ▲ | CuriouslyC 5 days ago | parent | prev | next [-] |
| I like to think of it as a duck-typed abstraction. I have formal specs which guarantee certain things about my software, and the agent has to satisfy those (including performance, etc). Given that, the code the agent generates is essentially fungible in the manner of machine code. |
| |
| ▲ | sarchertech 5 days ago | parent [-] | | Only if you can write specs precisely enough. For those of us who remember the way software used to be built, we learned that this is basically impossible and that English is a terrible language to even attempt it in. If you do make your specs precise enough, such that 2 different dev shops will produce functionally equivalent software, your specs are equivalent to code. | | |
| ▲ | CuriouslyC 5 days ago | parent [-] | | This is doable, I have a multi-stage process that makes it pretty reliable. Stage 1 is ideation, this can be with a LLM or humans, w/e, you just need a log. Stage 2 is conversion of that ideation log to a simple spec format that LLMs can write easily called SRF, which is fenced inside a nice markdown document humans can read and understand. You can edit that SRF if desired, have a conversation with the agent about it to get them to massage it, or just have your agent feed it into a tool I wrote which takes a SRF and converts it to a CUE with full formal validation and lots of other nice features. The value of this is that FOR FREE you can get comprehensive test defintions (unit+e2e), kube/terraform infra setup, documentation stubs, openai specs, etc. It's seriously magical. | | |
| ▲ | sarchertech 5 days ago | parent [-] | | Imagine that when you deploy you have an LLM that regenerates code based on your specs, since code is fungible as long as it fits the spec. Keeping in mind that I have seen hundreds to thousands of production errors in applications with very high coverage test suites? How many production errors would you expect to see over 5 years of LLM deployments. | | |
| ▲ | CuriouslyC 5 days ago | parent [-] | | Maybe more, but agents can also respond to errors much more quickly, and agents have the ability to manage small staged rollouts with monitoring to catch an issue before it goes global, so your actual downtime will be much better at the same time that you're producing code way faster. | | |
| ▲ | sarchertech 4 days ago | parent [-] | | My magic potion will make you much faster. It will also make you crap your pants all the time. But don’t worry I have a magic charm that I can sell that will change colors to alert you that you’ve shat yourself, and since you’re faster you can probably change your pants before anyone important notices. |
|
|
|
|
|
|
| ▲ | joenot443 5 days ago | parent | prev | next [-] |
| "SwiftUI red circle with a white outline 100px" ```
Circle()
.fill(Color.red)
.overlay(
Circle().stroke(Color.white, lineWidth: 4)
).frame(width: 100, height: 100)
``` Is the mapping 1:1 and completely lossless? Of course not, I'd say the former is most definitely a sort of abstraction of the latter, and one would be being disingenuous to pretend it's not. |
|
| ▲ | theptip 5 days ago | parent | prev [-] |
| > and it never will be The only thing I’m certain of is that you’re highly overconfident. I’m sure plenty of assembly gurus said the same of the first compilers. > because it's not an abstraction This just seems like a category error. A human is not an abstraction, yet they write code and produce value. An IDE is a tool not an abstraction, yet they make humans more productive. When I talk about moving up the levels of abstraction I mean: taking on more abstract/less-concrete tasks. Instead of “please wire up login for our new prototype” it might be “please make the prototype fully production-ready, figure out what is needed” or even “please ship a new product to meet customer X’s need”. |
| |
| ▲ | sarchertech 5 days ago | parent [-] | | >“please ship a new product to meet customer X’s need” The customer would just ask the AI directly to meet their needs. They wouldn’t purchase the product from you. |
|