For desktop and server, sure. MacBook is superior for everything that matters in a laptop. The touchpad alone is a dream. compare that to constant pain for the thousands of hours I will use the device over it's lifetime.
Apple makes nice hardware, but it's definitely not superior for everything, and the gap between other manufacturers isn't really there anymore on the upper end.
So sure - the Macbook is better than a cheap ~$500 laptop. But between my work issued Macbook and my nice Dell XPS? Not much difference. In either price or hardware...
Honestly, even between the macbook and my framework - not enough of a difference to really be that upset about (my biggest complaint is mostly just battery life).
---
Personally, I would argue that OS is a much bigger pain point to deal with, and you should probably factor that higher in the decision than the hardware. Just expect to spend roughly the same on the machine (Apple is still ~20% more)
And none of these are meaningfully different on high end laptops from other providers.
Apple had a window with M1 devices where I'd probably agree they were just better. Apple also has a history of making devices that are very expensive, and have a corresponding higher quality (ex - in the 2000s when most laptop manufacturers were racing to the bottom, and things like the Eee pc were considered hot - lots of garbage quality windows machines).
But many manufacturers today have entries in the "High quality, high price" category, and they're very similar.
The size is almost identical to an M5 laptop, the battery life is almost identical to an M5 laptop, the touchpad is almost identical to an M5 laptop (personally, I actually like the touchpad on the xps slightly more because the cutout on the front of macbooks is sharp, and I find it annoying and painful for long use, but I also have very large hands and I'm left handed).
And also - the price is functionally the same as the new M5 laptops.
All of those land in the +/- 10% range of each other. With just slight differences (ex - I can get a touchscreen on the XPS if I want, but it makes the battery life 15hrs instead of 18hrs on the macbook. The XPS is also fractionally lighter (3lbs vs 3.4lbs). The macbook is ~10% faster on single core benchmarks then the intel series 3, but identical to slightly worse on multicore. etc...)
Basically - unless you're actually using different machines here... stop it, you're talking out your ass (cough - fanboy - cough).
Even the framework... yes - it's clearly not as "good" as the $3600 macbook I have. I don't expect it to be given I paid ~$1500 for it. But it also excels in other areas that make it worth considering - I have 3 young kids, and I've had the screen pulled flat several times, the touchpad got a cup of milk dumped in it, and my oldest shoved a screwdriver into a usb-c port. Turns out new screen hinges were ~$19, the touchpad was ~$21, and the replacement port was $9. All done at home myself with simple tools.
Compared to several trips to a store and weeks without a laptop... that's a type of ergonomics that I prefer right now.
Eh, it depends on how you use it. I have a heavily used Linux laptop that's almost a decade old and I still love it.
I've had various work and personal MacBooks over the years and don't really miss them. It sounds like their quality has gotten somewhat better in recent cycles but the era of keyboards so fragile they break if you sneeze on them, and gimmicks like turning part of the keyboard into a touch screen were terrible. I would absolutely take a Linux machine from that era that costs half as much over any of those devices.
One caveat is that there are Apple-specific features like some of the trackpad gestures that I've never been a heavy user of. Partly because they aren't that interesting to me, and partly because I don't like having my workflows and muscle memory tied to a specific platform I don't control. Someone heavily into those features might have a harder time switching away.
How is that touchpad better than any other? My wife has Macbook Air, I don't see any difference between touchpad on my linux Dell 5680 compared to the Macbook.
It sounds similar to people that praise "haptic feedback" on phones, and describe feedback on some devices as extraordinary. (vibration device, seriously?)
Macbook has nice hardware, if I can ignore the strange keyboard layout, although I would prefer bigger keyboard and smaller touchpad.
Macbook software is something that is so bad compared to linux that I won't even comment.
Glad to see I am not the only one. Many years ago I had a laptop with a pointing stick, aka "the clit", and that was surprisingly easy to use. But touchpads? No matter how fancy and expensive you make them, they will always be a bad interface.
Haptic feedback touchpad is vastly superior to the button style. Less force required makes it easier to move your finger while the "button" is pressed. Most higher end laptops use it as the standard touchpad these days. MacOS is also well optimized for touchpads to the point that the traditional mouse experience is somewhat degraded. The smoothness and interactivity of the animations in response to touchpad gestures give a powerful placebo effect for how good the hardware is.
Multiple other competitive laptops have haptic trackpads with the list growing every year.
Lenovo and Framework have great ones, so does Microsoft and other brands I can’t think of right now.
I also find it that “macOS is well-optimized for touchpads” actually means “macOS is hostile to traditional mice and keyboards so that Apple can sell you external mice that cost 3x the price of alternatives even though you’re using your laptop at a stationary desk with external monitor 80% of the time”.
Plug in a traditional mouse to macOS and you’ll see how horrible the OS is with it for no reason. I needed third party mouse software just to play Minecraft without a horrendous scroll wheel experience for the item bar. There’s no built-in OS setting to have separate scroll directions for trackpad versus external mouse even though such a setup is highly logical. You need third party software for that. Meanwhile, on Linux that configuration option is built-in to Gnome and KDE.
Most trackpad gestures in macOS don’t need to be trackpad gestures at all and seem to be aimed at selling expensive peripherals and making Apple’s trackpad advantage larger than it would be if their system used a different OS. There’s no advantage to three finger swiping versus a traditional keyboard shortcut (to be fair, macOS also offers the keyboard shortcuts).
With the exception of flying on an airplane, grabbing a $30 mouse out of your backpack and plopping it on the table is perfectly acceptable and portable solution and often better than any trackpad imaginable for deep productive work.
Anyway, that last bit is a tangent and a rant of mine, but either way, the list of reasons to prefer a Mac is shrinking every day, if you ask me.
For example, MacBook Pros aren’t at the top of the battery life charts anymore, that honor goes to the Framework 13 Pro with the Panther Lake chips.
Unfortunately, not to my knowledge. I wouldn’t be surprised if they get a retail partner soon, though. Surely they must realize that Micro Center would be an ideal partner for their demographic.
I own the original chassis 13, AMD 7640U. My previous laptop was a MacBook Pro M2 14”.
There are some clear downgrades: battery life, screen, speakers. Processing power, yeah, though it’s not like I ever maxed out the one I had.
I love having ample storage though. 2TB/32GB in a MacBook Pro was wildly out of my price range. Back in the good old days of early 2025 buying those components yourself was something like a $200-300 cost while the Mac was closer to a thousand bucks. The keyboard is superior to a MacBook Pro in my eyes. I also started to really, really despise the notch and the way the menu bar software fights it.
My Framework 13 Pro arrives tomorrow. It appears like it should address every complaint I have on my original 13”. It’s just too bad about the RAM situation otherwise LPCAMM2 would be a benefit rather than something of a detractor like it is today. I’m one of the lucky people who snagged an old stock 32GB module for $250 during the announcement keynote. You’re almost better off with soldered memory in the current situation, but hopefully that’s temporary.
It’s a dream with Linux compatibility, as you’d expect. I enjoy the fact that I can play real games on Steam compared to the macOS situation where gaming was always a pain. There are also a lot of things I like about CachyOS and KDE a lot better than macOS. In a lot of ways it’s freeing, but some commercial software is obviously missing.
and yet, the collective industry has still continued to expand for decades because people overwhelmingly cannot consistently do these tasks without their code collapsing on itself.
imagine if people regularly had tires fall off on their way home from the mechanic. or regularly having to get bones rebroken to set them correctly.
I can agree that much of the work is not true "engineering" but most of what I've seen produced over the years is closer to fraud than anything else.
I echo the sentiment. Most work is described as basic and unimaginative, yet we still have every large company having outages despite employing "the best". Even worse, they game uptime and outages in a way that mirrors gerrymandering.
How this goes is the engineers start raising arguments in meetings full of nerdy technical terms such as “refactor”, “technical debt” and “accidental complexity”. As time progresses, more of them say more of this. At some point management learns that when engineers say engineery words like this you sometimes gotta say yes and let them do it even if it means urgent features are delayed, or the engineers will walk.
Let them walk. Good programmers can write code that doesn't degrade the customer experience.
In the last 15 years it's been all about the programmer's experience and user-facing software is objectively slower, buggier, and more resource intensive.
Good engineers would communicate effectively of something is impacting the product. Good product understands how to judge that impact and prioritize it. Frankly, if the engineers are making enough tech debt that they don't want to play in their own sandbox as part of regular practice, maybe they should walk.
It's a two ways street though, isn't it?
With lazy/unskilled/unmotivated developers you will have a shitty product, or maybe your SaaS would explode the day it's starting to get traction.
I very much miss the ability to never use my phone on a charging cable. Just swap the battery on an external charger and go. 5 seconds to charge to full. It was freeing and simple
I always wanted an internal battery of like 1 minute, so I could hot swap batteries. Then the battery capacity would be largely irrelevant. What would be cool is to have a large case that could charge the battery multiple times like with ear buds. The magnetic wireless charging blocks that just stick on the back of the phone are pretty fair compromise though.
as a local LLM novice, do you have any recommended reading to bootstrap me on selecting hardware? It has been quite confusing bring a latecomer to this game. Googling yields me a lot of outdated info.
First answer: If you haven't, give it a shot on whatever you already have. MoE models like Qwen3 and GPT-OSS are good on low-end hardware. My RTX 4060 can run qwen3:30b at a comfortable reading pace even though 2/3 of it spills over into system RAM. Even on an 8-year-old tiny PC with 32gb it's still usable.
Second answer: ask an AI, but prices have risen dramatically since their training cutoff, so be sure to get them to check current prices.
Third answer: I'm not an expert by a long shot, but I like building my own PCs. If I were to upgrade, I would buy one of these:
Framework desktop with 128gb for $3k or mainboard-only for $2700 (could just swap it into my gaming PC.) Or any other Strix Halo (ryzen AI 385 and above) mini PC with 64/96/128gb; more is better of course. Most integrated GPUs are constrained by memory bandwidth. Strix Halo has a wider memory bus and so it's a good way to get lots of high-bandwidth shared system/video RAM for relatively cheap. 380=40%; 385=80%; 395=100% GPU power.
I was also considering doing a much hackier build with 2x Tesla P100s (16gb HBM2 each for about $90 each) in a precision 5820 (cheap with lots of space and power for GPUs.) Total about $500 for 32gb HBM2+32gb system RAM but it's all 10-year-old used parts, need to DIY fan setup for the GPUs, and software support is very spotty. Definitely a tinker project; here there be dragons.
Agree on the framework, last week you could get a strix halo for $2700 shipped now it's over $3500, find a deal on a NVME and the framework with the noctua is probably going to be the quietest, some of them are pretty loud and hot.
I run qwen 122b with Claude code and nanoclaw, it's pretty decent but this stuff is nowhere prime time ready, but super fun to tinker with. I have to keep updating drivers and see speed increases and stability being worked on. I can even run much larger models with llama.cpp (--fit on) like qwen 397b and I suppose any larger model like GLM, it's slow but smart.
LLM code is higher quality than any codes I have seen in my 20 years in F500.
So yeah you need to "guide" it, and ensure that it will not bypass all the security guidance for ex...But at least you are in control, although the cognitive load is much higher as well than just "blind trust of what is delivered".
But I can see the carnage with offshoring+LLM, or "most employees", including so call software engineer + LLM.
Huh, that explains a lot about the F500, and their buzzword slogans like "culture of excellence".
LLM code is still mostly absurdly bad, unless you tell it in painstaking detail what to do and what to avoid, and never ask it to do a bigger job at a time than a single function or very small class.
Edit: I'll admit though that the detailed explanation is often still much less work than typing everything yourself. But it is a showstopper for autonomous "agentic coding".
> unless you tell it in painstaking detail what to do and what to avoid, and never ask it to do a bigger job at a time than a single function or very small class.
This is hyperbolic, but the general sentiment is accurate enough, at least for now. I've noticed a bimodal distribution of quality when using these tools. The people who approach the LLM from the lens of a combo architect & PM, do all the leg work, set up the guard rails, define the acceptance criteria, these are the people who get great results. The people who walk up and say "sudo make me a sandwich" do not.
Also the latter group complains that they don't see the point of the first group. Why would they put in all the work when they could just code? But what they don't see is that *someone* was always doing that work, it just wasn't them in the past. We're moving to a world where the mechanical part of grinding the code is not worth much, people who defined their existence as avoiding all the legwork will be left in the cold.
Maybe a bit, but unfortunately sometimes not so much. I recently had an LLM write a couple of transforms on a tree in Python. The node class just had "kind" and "children" defined, nothing else. The LLM added new attributes to use in the new node kinds (Python allows to just do "foo.bar=baz" to add one). Apparently it saw a lot of code doing that during training.
I corrected the code by hand and modified the Node class to raise an error when new attributes are added, with an emphatic source code comment to not add new attributes.
A couple of sessions later it did it again, even adding it's own comment about circumventing the restriction! X-|
Anyways, I think I mostly agree with your assessment. I might be dating myself here, but I'm not even sure what happened that made "coding" grunt work. It used to be every "coder" was an "architect" as well, and did their own legwork as needed. Maybe labor shortages changed that.
> It used to be every "coder" was an "architect" as well, and did their own legwork as needed.
I disagree. I remember in the days before "software engineer" became the rage that the standard job titles had a clear delineation between the people who thought the big thoughts with titles like "analyst" and the people who did the grunt work of coding who were "programmers". You'd also see roles in between like "programmer/analyst"
Might be a big company thing then, but I'm not wholly convinced. There's a big gap between designing the outline of a big system and coding instructions that can be followed without having to make your own decisions. The question of how much of that gap is filled by the "design" vs "coding" levels is a spectrum.
I think I see what you're saying and if so we're talking past each other a bit and I agree with what you're saying as well.
The point I was raising is by the time an IC developer sees something, there's already been a process of curation that happens that frames the possible solutions & constrains branch points. This is different from saying that an IC makes 0 implementation decisions. The C-suite has set a direction. A product manager has defined the shape of the solution. A tech lead, architect, or whatever may have further limited scope. And any of these could just already be in effect at a global scale or on the specific problem at hand. Then the IC picks up the work and proceeds to make the last mile decisions. And it's turtles all the way up. At almost all levels on the career ladder, there are people above and/or upstream of you who are pre-curating your potential decision tree.
As an analogy, I once had a fresh tech lead under me where they didn't understand this. Their team became a mess. They'd introduce raw tickets straight from the PM to their team without having thought about them at all and things ground to a halt due to decision paralysis. From their perspective that's how it was always done when they were an IC in that group. The team tackled the tickets together to work out how to accomplish their goals. It took a lot of effort to convince them that what they *didn't see* was their prior tech lead narrowing down the search space a bit, and then framing the problem in a way that that made it easier for the team to move forward.
I'm on board with that framing of the process, and I see how my original formulation was too rough.
I was reacting to "We're moving to a world where the mechanical part of grinding the code is not worth much". I have the impression that in the past just mechanically grinding the code was less of a thing than it apparently is today. Guidance, sure, but not as much as seems to be common (often necessarily so) today. But I'm sure that varies with a lot of factors, not just the calendar year.
Exactly. I was channeling the stereotypical dev that says they "just want to write code". To your point they're not literally *only* writing code, but this was the sort of person/mentality I was calling out.
What it says to me is they've actively avoided what appears to be becoming the most important skills in the new world. They're likely to find themselves on the short end of the stick.
I'm with you, it's constantly doing stupid shit and ignoring instructions, and I've always been responsible for determining architecture and doing the "legwork." Unless the task is so small and well defined that it's less typing to tell the LLM (and clean up its output) then i may as well just do it myself
Modern human programming has devolved to nothing more than modeling problems and systems using lines of code, procedures, sub-routines and modules, utilizing a “hack it till it works”(tm) methodology.
> utilizing a “hack it till it works”(tm) methodology.
Your post describes my coding perfectly. I don't have CS training of any type, never been formally involved in software development (recently started dabbling in OSS) and never used an LLM/agent for help (do use a local SLM for autocomplete and suggestions only).
Yet I can "code." I suspect a (pre-2023ish) software developer would likely tell me "go learn to code" if i asked for review. I don't know the formal syntax people expect to see and it has organization more typical of raging dumpster fires. Doesn't mean it's not code.
> The people who walk up and say "sudo make me a sandwich" do not.
My personal beef is the human devs get "make me a sandwich", and the LLM superfans now suddenly know how to specify requirements. That's fine but don't look down your nose at people for not getting the same info.
This is happening now at my company where leadership won't explain what they want, won't answer questions, but now type all day into Claude and ChatGPT. Like you could have Slacked me the same info last year knuckleheads...
Absolutely. Merely being a member of the business class does not magically mean one has the ability to specify business requirements much less product specifications. These are *not* the people I'm talking about now having superpowers.
I am picturing people who blend high level engineering and product skills, ideally with business sense.
> Merely being a member of the business class does not magically mean one has the ability to specify business requirements much less product specifications
Is this not why COBOL failed? Common Business-Oriented Language sure does look much more like natural language than a lot of other code, but it could never solve the abstraction needed to do the complex things.
I don't think LLMs will ever get rid of coders. Business people can no more tell an LLM what to build than they can a team of programmers. I've long argued that the contention between the "business monkeys" and "coding monkeys" is a good one. That the former focuses on making money and the latter focuses on making a better product. The contention is good because they need each other (though I do not think the dependence is symmetric).
Maybe one day AI will get there, but I don't see how it does without achieving AGI. To break down intent. To differentiate what was asked from what was intended. To understand the depth and all the context surrounding the many little parts. To understand the needs of the culture. The needs of the users. The needs of the business. This is all quite complex and it's why the number of employees typically grows quite rapidly.
How do we move forward without asking how we got here? Why we got here? How optimizing for decades (or much longer) led us to these patters. Under what conditions makes these patterns (near) optimal? I've yet to see a good answer to how LLMs actually address this. If typing was the bottleneck I think we would have optimized in very different ways.
My intuition tells me that llm’s combined with SWE’s with really amazing fundamentals will kill the code monkeys.
And frankly? That’s the best outcome. Code monkeys (in my view that’s an individual who writes out code just to complete a jira ticket) are a liability. Not only that but each additional person you have in an org means more noise creation.
If this forces the code monkeys to level up to compete… again a good thing.
The code base should not be elongated nor complicated. I’m not even a SWE by trade, rather a CEO, and this is my preferred outcome.
I agree with your first paragraph but not the second one. In many cases it's easier for me to directly write the code that satisfies the unwritten acceptance criteria I have in my head than to write those criteria down in English, have an LLM turn them into code, and then have to carefully review that code to see if I forgot some detail that changes everything.
> easier for me to directly write the code that satisfies the unwritten acceptance criteria I have in my head than to write those criteria down in English
Yes, and for team or company code, "there's the problem".
Those acceptance criteria are guardrails for the change that comes after, and getting those out of your head into English is more important over the long haul than your undocumented short-term solution to the criteria.
Virtually all teams — because virtually all PgMs, PjMs, TLs, and Devs — miscalculate this.
Easier for you, not better for team or firm.
• • •
FWIW, perpetuation of this problem isn't really a fault of culture or skill or education. It's largely thanks to "leadership" having no idea how to correctly incentivize what the outcome should holistically be, as they don't know enough to know what long-haul good looks like.
FWIW, you can make that easier for them by having the LLM derive your acceptance criteria into English (based not only on code but on your entire conversation+iteration history) and write that up, which you can read and correct, after the countless little iterations you made since your head-spec wasn't as concrete as you imagined before you started iterating.
Even if you refuse to do spec driven development, LLMs can do development-driven spec. You can review that, you must correct it, and then ... Change can come after more easily — thanks to that context.
> Those acceptance criteria are guardrails for the change that comes after, and getting those out of your head into English is more important over the long haul than your undocumented short-term solution to the criteria.
I have a lot of context about the system/codebase inside my head. 99.9% of it is not relevant to the specific task I need to do this week. The 0.1% that is relevant to this task is not relevant to other tasks that I or my teammates will need to do next week.
You're suggesting that I write down this particular 0.1% in some markdown file so that LLM can write the code for me, instead of writing the code myself (which would have been faster). Chances are, nobody is going to touch that particular piece of code again for a long time. By the time they do, whatever I have written down is likely out of date, so the long term benefit of writing everything down disappears.
> after the countless little iterations you made since your head-spec wasn't as concrete as you imagined before you started iterating.
That's exactly the point. If I need to iterate on the spec anyway, why would I use an intermediary (LLM) instead of just writing the code myself?
> getting those out of your head into English is more important over the long haul than your undocumented short-term solution to the criteria.
I think there may be miscommunication going on, or I may be misreading the conversation. What I do not know is what valicord means by "satisfies the unwritten acceptance criteria".
In one interpretation, I think they make a ton of sense. We invented formal languages to solve precisely this problem. The precision and pedantic nature of formal languages (like math and code[0]) is to solve ambiguity. If this is the meaning, then yes, code is far more concise and clear[1] than a natural language. That's why we invented formal languages after all. So they may be having trouble converting it to English because they are unsatisfied with the (lack of) precision and verbosity. That when they are more concise that people are interpreting it incorrectly, which is only natural. Natural languages' advantage is their flexibility, but that's their greatest disadvantage too. Everything is overloaded.
But on the other hand, if they are saying that they are unable to communicate the basics (it seems you have read in this way) then I agree with you. Being able to communicate your work is extremely important. I am unsure if it is more important than ever, but it is certainly a critical skill. But then we still have the ambiguous question of "to who?" The type of writing one does significantly differs depending on the audience.
Only valicord can tell us[edit], but I think we're just experiencing the ambiguity that makes natural languages so great and so terrible. I think maybe more important than getting the words out of ones head is to recognize the ambiguity in our language. As programmers this should be apparent, as we often communicate in extremely precise languages. But why I'd say it is more important than ever is because the audience is more diverse than ever. I'd wager a large number of arguments on the internet occur simply due to how we interpret one another's words. The obvious interpretation for one is different for another.
[0] Obviously there's a spectrum with code. C is certainly more formal than Python and thus less ambiguous.
[1] Clear != easy to understand. Or at least not easy to understand by everyone. This is a skill that needs training.
[edit] Reading their response, I think it is the first interpretation.
This is the point I'm raising. I agree with you, but what I'm saying is I think the skillset you describe is the next on the chopping block.
The acquaintances of mine who are absolutely *killing* it with these tools are very experienced, technically minded, product managers. They have an intimate knowledge of how to develop business requirements and how to convert them into high level technical specifications. They have enough technical knowledge to understand when someone is bullshitting them, and what the search space for the problem should be. Historically these people would lead teams of engineers to develop for them, and now they're sitting down and having LLMs crank out what they want in an afternoon. They no longer need engineers at all.
My contention is that people with that sort of skillset will have an advantage due to their experience with skills like finding product fit, identifying user needs, and defining business requirements.
Of course, the people I'm talking about were already killing it in the old paradigm too. I'll admit it's a bit of a unicorn skillset I'm describing.
It's almost as if architecture and code quality mattered just as before and that those who don't know proper engineering principles and problem decomposition will not succeed with these new tools.
If you're using words in English to "tell it in painstaking detail", you're doing it the hard way.
You can provide it with a tool to do that. Agents run tools in a loop, give it good tools. We have linters, code analysers, fuzzers and everything else.
Configure them correctly, tell the agent to use them (in painstaking detail) and it can't mess things up.
Uhuh. Let me present you Rudolph. For the next 15 minutes, he will paste pieces of top rated SO answers and top starred GH repos. Then he will suffer complete amnesia.
He might not understand your question or remember what he just did, but the code he pastes is higher quality than any codes you have seen in your 20 years in F500! For 20$ a month, he's all yours, he just needs a 4 hour break every 5 hours. But he runs on money, like gumball machine, so you can wake him with a donation.
Oh, you are responsible for giving him precise instructions, that he often ignores in favour of other instructions from uncle Sam. No, you can't see them.
As far as I've ever heard, "le code" used in a codebase is uncountable, like "le café" you'd put in a cup, so we would still say "meilleur que tout le code que j'ai vu en 20 ans" and not "meilleur que tous les codes que j'ai vus en 20 ans".
There is a countable "code" (just like "un café" is either a place, or a cup of coffee, or a type of coffee), and "un code" would be the one used as a password or secret, as in "j'ai utilisé tous les codes de récupération et perdu mon accès Gmail" (I used all the recovery codes and lost Gmail access).
I got curious and had to fire up the ol LLM to find out what the story is about the words that aren't pluralized - TIL about countable and uncountable nouns. I wonder if the guy giving you trouble about your English speaks French.
I speak Russian and some English, but the question was about universal quantification: author declares that LLMs generate code of better quality than "any codes" he seen in his career.
I'm native French and nobody would consider code countable. "codes" makes no sense. We'd talk about "lines of code" as a countable in French just like in English.
Codes is a proper grammatical word in English, but we don’t use it in reference to general computer programming.
You can for example have two different organizations with different codes of conduct.
There is though nothing technically wrong with seeing each line of code as an complete individual code and referring to then multiple of them as codes.
You'll find, at times, that those communicating in a language that's not their primary language will tend to deviate from what one whose it was their primary language might expect.
If that's obvious to you than you're just being rude. If it's not obvious to you, then you'll also find this is a common deviance (plural 'code') from those who come from a particular primary language's region.
Edit; This got me thinking - what is the grammar/rule around what gets pluralized and what doesn't? How does one know that "code" can refer to a single line of code, a whole file of code, a project, or even the entirety of all code your eyes have ever seen without having to have an s tacked on to the end of it?
"Codes" as a way to refer to programs/libraries is actually common usage in academia and scientific programming, even by native English speakers. I believe, but am not sure, that it may just be relatively old jargon, before the use of "programs" became more common in the industry.
As for the grammar rule, it's the question of whether a word is countable or uncountable. In common industry usage, "code" is an uncountable noun, just like "flour" in cooking (you say 2 lines of code, 1 pound of flour).
It's actually pretty common for the same word to have both countable and uncountable versions, with different, though related, meanings. Typically the uncountable version is used with a measure of quantity, while the countable version denotes different kinds (flours - different types of flour; peoples - different groups of people).
> Typically the uncountable version is used with a measure of quantity, while the countable version denotes different kinds (flours - different types of flour; peoples - different groups of people).
This was very helpful, thank you! (I had just gotten off the phone with Claude learning about countable and uncountable nouns but those additional details you provided should prove quite valuable)
> what is the grammar/rule around what gets pluralized and what doesn't? How does one know that "code" can refer to a single line of code, a whole file of code, a project, or even the entirety of all code your eyes have ever seen without having to have an s tacked on to the end of it?
Well, the grammar is that English has two different classes of noun, and any given noun belongs to one class or the other. Standard terminology calls them "mass nouns" and "count nouns".
The distinction is so deeply embedded in the language that it requires agreement from surrounding words; you might compare many [which can only apply to count nouns] vs much [only to mass nouns], or observe that there are separate generic nouns for each class [thing is the generic count noun; stuff is the generic mass noun].
For "how does one know", the general concept is that count nouns refer to things that occur discretely, and mass nouns refer to things that are indivisible or continuous, most prototypically materials like water, mud, paper, or steel.
Where the class of a noun is not fixed by common use (for example, if you're making it up, or if it's very rare), a speaker will assign it to one class or the other based on how they internally conceive of whatever they're referring to.
FWIW, I've noticed that scientists (native English speakers at least) will say "codes" rather "code". I don't know if this is universal or just specific domains (physics) nor if this is common or rare, but I've noticed it.
If you a) know what you are doing and b) know what an llm is capable of doing, c) can manage multiple llm agents at a time, you can be unbelievably productive. Those skills I think are less common than people assume.
You need to be technical, have good communication skills, have big picture vision, be organized, etc. If you are a staff level engineer, you basically feel like you don’t need anyone else.
OTOH i have been seeing even fairly technical engineering managers struggle because they can’t get the LLMs to execute because they don’t know how to ask it what to do.
How is that supposed to work? Humans are notoriously poor at multi-tasking. If you spend all day context switching between agents you’re going to have a bad time.
it's like that '11 rules for showrunning' doc where you need to operate at a level where you understand the product being made, and the people making it, and their capabilities, in order to make things come out well without touching them directly.
if you can do every job + parallelize + read fast, and you are only limited by the time it takes to type, claude is remarkable. I'm not superhuman in those ways but in the small domains where I am it has helped a lot; in other domains it has ramped me to 'working prototype' 10x faster than I could have alone, but the quality of output seems questionable and I'm not smart enough to improve it
For me, I'll do the engineering work of designing a system, then give it the specific designs and constraints. I'll let it plan out the implementation, then I give it notes if it varies in ways I didn't expect. Once we agree on a solution, that's when I set it free. The frontier models usually do a pretty good job with this work flow at this point.
Really? Because this perfectly explains why it will never replace them: it needs an exact language listing everything required to function as you expect it.
The real issue is the lack of support. Real users buy those support packages from vendors. They bring their PC in to be fixed at their local shop. They might Google a problem and find a solution occasionally of they are feeling spicy but how often do you get screenshots to get something to work in a Linux GUI? Web browser only laptops are great until your uncle gets a "killer deal" on some random printer on Facebook marketplace and they can't get it to work. Or a webcam. Or a Bluetooth headset. Or a game controller. Scanner. etc etc.
On top of all of this, they will just give up and buy a new machine and return it if that doesn't fix their issue.
Linux provides virtually nothing on any of those fronts unless you get a private level 8 tech support contact provided by your grandson. Who wants to be 24/7 on call for their extended family?
Regarding slow startups, I am not sure this applies to any use cases I can think of where it would not also be a concern in python, etc. JVM startup times have never meaningfully impacted my workflow in the last 15 years.
The why is quite simple, in my opinion. I see java devs reaching for other accepted tools for such things and opening a whole can of worms by introducing a new language that is only "required" by convention. I would love a rich java ecosystem of TUI/CLI libraries to reuse all of my existing business logic and company libraries. The lack of extremely streamlined wrappers is the only barrier. In my work environment, this would be a great addition.
Right, as I said I also think Python has similar issues with startup time.
I've used a limited amount of Java CLIs, the most obvious ones are things like Gradle which never felt snappy to use - it is annoying when even doing basic things takes 2+ seconds. I guess not the end of the world, but that seems suboptimal to me compared to a system that feels fast to use and hence well engineered.
reply