> "Take note of the emphasis I added: the very notion that something else could be "as good as I am" is, first of all, hard to believe and secondly necessarily means that it's "superhuman".
Unironically, I recommend psychedelics. The right experience will make you aware of just how tiny a part of a vast universe you are -- and obliterate any sense of hubris.
Let me play Devil's Advocate, without having dug into his personal life at all:
Is it possible that the person accused of being a Chinese spy, was a businessperson located in China who was coerced by authorities?
IF the above is true -- do others genuinely believe they would stare down the face of a world power and dare to defy them, if they were not the only living member of your family tree within the geographic area?
What is the functional difference between someone who reports to China because they love China and someone who reports to China because the Chinese government pressured them to?
Every task that would be a multi-week engineering effort, I defer for a few months, until inevitably a model that trivializes it appears, repeat ad-nauseum.
Languages have not yet evolved to multi-core properly IMO
I've sketched what I think an ideal "language of today" would look like, and one of the core tenets is making concurrent code explicit and part of the design surface.
You might imagine a webserver with main code like:
spawn(on_core: 0) {
await receive_packet(input)
}
Or iterating over "num_cpus" and doing the same thing, with hashing based on CPU number for shared-memory resources.
The problem is that when you build at this layer, you end up writing far more scheduling code than business logic. Eventually you've built the abstractions we already use today.
The vast, vast majority of software, and software developers, simply do not care about core affinity, NUMA, noisy neighbors, etc.
Even on systems or situations where this matters (massive number of cores and memory, multiple sockets, thousands of threads, etc.) the juice is rarely worth the squeeze.
Doubly so when you end up being I/O bound anyways.
Nearly every software developers wants their software to work across multiple deployment targets. Maybe you just target x86-64, and you don't care about the number of CPUs because you'll be upgrading your servers every couple of years.
No one wants to deal with difficult-to-reproduce issues related to scheduling in niche configurations. It's much more efficient for runtime or compiler engineers to solve these problems for us, leveraging the vast amount of resources of corporations to develop and test these features. Then you have a place your code can live happily ignorant of its runtime constraints.
And that, my friend, is the beauty of our industry.
I disagree. In a world of different architectures, out-of-order execution, asymmetric cores, branch prediction, per-core caching and information leakage between threads and the branch not taken, my opinion is firmly that most people shouldn't be writing multithreaded code because it is almost impossible to get it correct and safe.
The effects can be subtle and lurk for years until a seemingly unrelated change exposes them. It starts with optimizations like instead of spawning a thread, you use a thread pool, possibly abstracted as some kind of executor service. Other code might use different thread pools to isolate them because each pool has its own limits on the number of threads. Some might grow but usually they won't.
Until one day you end up with thread starvation and a deadlock through a series of benign seeming optimizations. There are threads around but not in the right pools and the entire thing grinds to a halt.
Cooperative async/await on a single thread is the ideal solution for most use cases, particularly with complete environment teardown between requests. Yes, this is basically the PHP model.
The receive functions are async so they can only be used inside an async context, like the one created by race. Race is a keyword from Verse that returns the result of the first finished task and cancels the other.
It’s funny that you write this, as when I was at Salesforce, I picked up a nested list drag-and-drop task solo except-testing (as the “go to” UI person on the team), and it took me almost the entire release cycle (1/3rd year release schedule (but picked it up later into it)) to complete it. While it turned out good (and I remember the feature’s implementation getting praise by a senior manager at a sub-org demo meeting), that I was called into a team meeting for a “Root Cause Analysis” (paraphrasing) to discuss why the feature took so long to implement.
I think the Dragology stuff actually gets to the nub of what makes interactive drag-and-drop challenging: it's speculative live editing of a view into your model data.
While it's a wrong assumption, I don't really think it's dumb for a non-technical person to assume this is fast to implement, and I don't think it's some epic own that he offered pushback on this even though he was wrong.
If said this way he was a jerk. So good on em for making a joke.
"Why would this take so long?" would be better.
My guess like most things "you wanna retrofit audio and data cabling to your house. Find an electrician who can do that in an hour. Yes it is just wires".
Could mean "I didn't know you had so much stuff on your plate that takes precedence". You're giving 0 benefit of doubt to a PM who in my opinion was right to push back because for a non-technical person it's not easy to grasp why drag and drop should be so much harder than other similar impact features.
You could be right. Depends on their tone and previous interactions. This is why it is good to have rituals and processes where e.g. you estimate a bunch of stuff at once and it is clear what kind of estimate it is. Effort, elapsed time or Tony's elapsed time given he is going to a conference Tue to Thu.
> to a PM who in my opinion was right to push back because for a non-technical person...
Ah and there's the rub. Why should a PM of a software project even be a 'non-technical person' (because tbh what's even the point, how would a 'non-technical' person even be able to evaluate technical decisions and their implementation?). And even for multi-disciplinary projects like videogames it's not too much to expect that the project manager has at least a basic understanding of all crafts that work on a game.
E.g.. there's nothing more useless than a PM that's just pushing task bars around in JIRA to make them fit into the next sprint.
...and also: would you fly in a plane, or drive over a bridge that was built under supervision of a 'non-technical' PM? (I know I know... since the Boeing disasters that question is rhetorical, most people don't seem to care)
The head of a space program doesn't need to be an astronaut. An admiral doesn't have to know how to swim. A PM doesn't have to know all the various engineering disciplines the project may touch.
The comment was derisive, and therefore poor leadership. Period.
Dumb question: why? It’s been a long time since I touched GUI code, but I thought it gave you a message with the URI to the file. How is this significantly different than file-open?
This was circa 2010 or so, and it was a web app. So pre-ES6 JavaScript, before React.
Nowadays you would just "npm install drag-and-drop" but back then you often had to hand-roll solutions.
If anyone can dig up an ancient library on GitHub for drag-and-drop back in those days, I'd imagine it would be several thousand lines long, not to mention the absolute nightmare that testing something like this with a proper framework and accompanying testing library.
Desktop app drag and drop is also a nightmare. Various frameworks can make it easier or harder, but regardless of what you choose, you have about 5 different states your draggable is in, and all of these states have at least 2 transitions to other states, and all your drop targets have to handle mouse-in/mouse-out/drop-end events, and those events need to expose enough data about the dragged object so that every drop target can not only execute the drop, but also tell you whether dropping is allowed without consuming the data.
It's not insurmountable by any means, but it does have enormous inherent complexity compared to almost every other UI action there is.
Graphical interfaces can only paper over misdesigns and kludges in the underlying operating system; they can’t eliminate them.
The “drag-and-drop” metaphor tries to cover up the Unix file system, but so little of Unix is designed for the desktop metaphor that it’s just one kludge on top of another with little holes and sharp edges popping up everywhere. Maybe the “sag-and-drop” metaphor is more appropriate for such ineffective and unreliable performance.
A shining example is Sun’s Open Windows File Manager, which goes out of its way to display core dump files as cute little red bomb icons. When you double-click on the bomb, it runs a text editor on the core dump. Harmless, but not very useful. But if you intuitively drag and drop the bomb on the DBX Debugger Tool, it does exactly what you’d expect if you were a terrorist: it ties the entire system up, as the core dump (including a huge unmapped gap of zeros) is pumped through the server and into the debugger text window, which inflates to the maximum capacity of swap space, then violently explodes, dumping an even bigger core file in place of your original one, filling up the entire file system, overwhelming the file server, and taking out the File Manager with shrapnel. (This bug has since been fixed.)
But that’s not all: the File Manager puts even more power at your fingertips if you run it as root! When you drag and drop a directory onto itself, it beeps and prints “rename: invalid argument” at the bottom of the window, then instantly deletes the entire directory tree without bothering to update the graphical directory browser.
2010 I'm pretty sure you had jQuery plugins to simplify drag&drop for a lot of use cases. But of course, if your use case was outside of the basic ones easily handled by a jQuery plugin, good luck!
Hit-test where the mouse-down event is fired, hit-test where the mouse-up event is fired. What the hell do you need a library for?
> If anyone can dig up an ancient library on GitHub for drag-and-drop back in those days, I'd imagine it would be several thousand lines long,
I bet, the JS devs who do write code overcompensate for the ones who can only stitch together libraries. I suppose because the expectation is that the library consumer is incapable of writing their own code extending it, so the library itself must support every possible combination of use cases for a million different users, even though the code any individual consumer actually needs is more like 100 loc.
On the frontend, you have to re-calculate the display state for all the possible drop positions, in-between transitions, and drop-end-snap-back.
Think of a grid of cards, and all the possible drag, hover, and drop state transitions it can be in with any other card, and the animations required to make it look nice
Now also consider that you need to persist the final state on the backend, and handle things like rejection, cancellation, failed updates/errors.
It becomes a massive state chart and web of complexity
I mean, maybe we're missing context here. Is that what your boss was actually asking for? 99% of web applications (or, hell, desktop applications) don't have ultra-interactive, fully-responsive-animation drag-and-drop. If he was asking for functional drag-and-drop and the team was implementing top 1% cosmetic drag-and-drop, that's certainly one avenue for a mismatch in expectations.
I think people are talking about two different kinds of drag-and-drop. There is dragging external items (files from the OS, for example) onto the app surface from outside. And there is a list of items, each with its own UI component, being dragged within an app to either change sort order or otherwise change data state. Both complex, and have a lot in common, but many comments here seem to be talking about one or the other without specifying.
If you are dragging within the page, then the draggable “ghost” is your problem too (it’s not automatic). As is deciding whether the ghost should affirmatively snap out of and into the source and target containers (that is, whether the destination container should appear to “make room” for the ghost at some transitional point), whether there’s a transition on that, etc.
Drag and drop in desktop non-web GUIs have all sorts of visual affordances that users expect for consistency that are your job in HTML.
I was once quite up-to-date with raw frontend work and I tried to implement this; it’s actually not trivial.
Okay, you've added a requirement. Poll the current cursor position after the first hit-test sets the dragging state and call a function to render your object with X% opacity at a higher Z level than anything else. Your 30 minute job has become a 60 minute job.
> As is deciding whether the ghost should affirmatively snap out of and into the source and target containers (that is, whether the destination container should appear to “make room” for the ghost at some point), whether there’s a transition on that,
Most applications don't go this far, including your operating system like Windows that sets baseline UX expectations, so you're well beyond the default expectation for drag-and-drop. If someone asks you to implement drag-and-drop without specifying they want all the bells and whistles, and you respond it's going to take you a week because you're planning to go all-out beyond necessary business requirements, they'd have a valid reason to be like "WTF mate?". Also this is still pretty paltry and not a week's worth of work.
z-index is a CSS property, but doesn't work reliably on the web to always put something on top (IIRC, it positions it within its stacking context - there may be many nested stacking contexts). You need to somewhat carefully make a copy of the dragged DOM node (assuming the thing being moved is all in one DOM node), put it into a separate div which can be in front everything you want it to be in front of; and hide the ghost when you want to do hit testing for the drop. Also, you need to actually think about what you want the drop interaction to do wherever it might land (this last step could scale in complexity indefinitely depending on the webpage).
I've done it a dozen times in gamedev, where interfaces and interactivity are routinely built from scratch without any help of a framework. I didn't work on web applications in 2010, but even with the clusterfuck that the web is I find it difficult to believe it was that hard to do.
It could be absolutely exasperating, even in 2010 (especially then since browser support for touch events was still shaking out).
The problem is that even without a framework, you didn’t have a blank slate (which would have been better). You had a moving target of blank slates, you had platform differences, you had drag vs touch-drag, entrenched older browsers and the simple frustration of testing on an array of real devices, all sorts.
Now, if you were talking about 2015, then it starts to get a bit flatter.
so in short, you haven't done "this" work, you have done work in another field with different technical limitations that also has the concept of "drag and drop".
serious question, why, when people from a field you are unfamiliar with tell you that something has particular constraints in that field, do you confidently assert that you know better?
I built a drag and drop content CMS/website builder in native Javascript years ago. The browser APIs are really cumbersome. The other issue is more UX than technical, there are lots of questions to answer. What are you dragging, what is it hovering over actually, what is the intention once it's dropped etc.
Drag-and-dropping a file directly on the HTML `<input type="file">` file picker works with no code/JS.
If you want to splash up the "drop here" thing it's a frickin nightmare. The events don't fire when they should (e.g. mouse leave doesn't fire so it gets stuck, or you get duplicate events or missing events) so you get a bunch of flicker unless you do a bunch of debouncing and fail safes to cover all the browser quirkiness. And this is the easy drop-a-file scenario.
Is that some sort of legacy pricing? because on https://chatgpt.com/pricing/?type=team I see an option of either £15/ month or £75/ month, per seat, 2 seats required. So it's more expensive than a single £89/ month pro subscription.
The 2x15 is not ChatGPT Pro you're getting, it's the equivalent of the "Plus" plan. So yes, you can get 2 "Plus" subscriptions for more money than it would cost to get them as a personal ones.
I've been working on a decomp + translation of another RPG that was never released in English:
Uncharted Waters IV: Porto Estado (Daikoukai Jidai IV)
The second game, Uncharted Waters 2: New Horizons is one of the greatest and most unique games I've ever played.
Unfortunately, despite being wildly popular in Japan, the series never caught on here and so later games don't have an English release.
I've heard the 4th game is excellent and so have been using LLM's to reverse and translate it, with intent to publish the patch once complete so others can enjoy it
So there's a ~30 pt difference between them. Let's add 5% more for quantization damage.
My perspective is, yes - that's a huge difference. No - it doesn't matter. Flash-next is above the threshold of useful intelligence. I can ask it to do something and it does it. Sure, it burns some tokens on bad ideas on the way, and sure it can't turn a single paragraph prompt into million dollar business. I don't need or want that - I want something I can ask to refactor a module, and it does it and it doesn't stop until the module compiles and all the tests pass. flash-next does that.
Local models at that scale just aren’t comparable to the frontier. I’m a big DeepSeek glazer but even the gap between full DS 1017 and Opus 5.5 is vast. Local models will never be able to reach that level, there’s real limitations at play. SOTA models are getting bigger and bigger.
I might humbly suggest that the tasks you need to be competitive as an engineer in 2026 are different than they were in 2024. And they’ll be even more different in 2028.
If you’re using open weight models to code basically the same as you always have been but just a little faster, while your competitors are using frontier models to go 10x faster, you haven’t saved anything.
Now, granted, the real question comes down to whether they’re going 10x faster, and whether that’ll hold up in the long term. But that’s the gamble as I see it. And to me, open weight models aren’t worth the risk. $200 is 0.5% of my little company’s revenue. It would be foolish of me to try and save that money.
Local models are useable and practical today. There is very clear diminishing returns from just increasing model size. You say you are a 'deepseek glazer' but the anthropic/openai glazers were saying the local models we have now were literally impossible just a year ago... and it seems the propaganda is still flowing
It’s a $20-100 a month outlay for an otherwise low expense discipline to access the best models available, without any local dev ops requirement or expense. If access ever becomes a problem, the open models are there. That’s a fairly straightforward calculation for a lot of people.
I just want to own the tools I use to earn my living.
You can rent your very shiny version of the tools you use for a very reasonable price, but to me the bent and rust-stained tools I own myself are worth much more.
That's fine, it's great they exist and are there as an option if needed/wanted. But you said you couldn't understand how people justify a Claude subscription.
This is a great example of why benchmark racing is useless for LLMs.
I use both models extensively and there is no way I would ever agree that Astra and Qwen3.8-FN are that close in the real world.
I agree with the other comments: These comparisons are silly.
You keep saying that you don’t understand why anyone would have a Claude subscription and reciting ideological reasons not to. I’m assuming this means you don’t use their new models much? That’s the only explanation I can think of for how someone could think that Opus 5.5 or even Sonnet 5.5 and Qwen3.8-FN are close.
I use them both (often Qwen3.8-FN as a subagent) and any claims that they’re actually pretty close read as downright delusional to me.
I run my own local models, and I can tell that yes, one ask and they do... with many more errors, and much much slower, compared to the lowest levels of frontier models.
Sure, if one has no standards at all, local LLMs definitely are "above the threshold of useful intelligence".
Putting aside the absurd straw man, you’re touching on an important point: these small open weight models are sufficient for how you like to work, but it’s not remotely good enough for how I like to work. Opus 5.5 is barely sufficient for how I like to work (many parallel work streams, as little of me in the loop as possible, etc).
I work like the parent poster does. I am working harder than before the AI tools came around. I am just working at a higher level. Not too dissimilar from someone moving from programming in assembly language to significantly higher level language.
> as little of me in the loop as possible
You may be confused about this. If I am running just one loop at a time, you'd be right. What modern tools allow me to do is think more like a supervisor that has dozens of engineering teams available to him. I always have a long list of problems I need to solve. I used to sit with one and bang on it until it would pass acceptance criteria. Sometimes that took months. Now I just farm out each task to an agent orchestrator, provide it details on what I want done, a bit of design and architecture and acceptance criteria. I then step away from it and move to the next agent orchestrator and repeat the process for the next task. I usually have 6 or 7 large tasks being worked on at the same time. This is currently my personal limit. I can't babysit more than that. But as the models and harnesses get better I suspect I will have to do less babysitting and this process will get more autonomous.
It may sound like this process would remove the need for engineers. In my organization it is doing quite the opposite. As the organization figures out that we can do a lot more, we change our plans to build more. A lot more. Building still requires engineers, more than before, for us. But only those who can think like architects and can manage large teams of AI agents and orchestrators that work 24x7.
Haha, yes, it’s not work, just like any EM, tech lead, principal engineer, etc, isn’t doing work either. Everyone knows if you’re not scrutinizing each line of code, it’s not really work.
And I work for myself, so no, not automating myself out of a job.
Although I suppose I’m automating the people I won’t hire now out of a future potential job.
For programming, sure. There are oodles of tasks that you can defer to AI for that aren't nearly as picky though.
For example, suppose you have a list of questions in a CSV, and you just want to categorize them by the "type" of question (e.g. technical, bureaucratic, procedural, a mixture, etc). You could have Fable do it, and it will work, but it probably won't work significantly better than Haiku, or even one of the cheaper Qwen or Deepseek models.
A lot of my AI usage does boil down to that. I use Opus for most of the actual tasks involving writing code, but for more mechanical and less complicated stuff I prefer the speed and the lower usage of my tokens and defer to Sonnet or Haiku.
Ok, but as parent said, not every use case is programming. If I want a model to extract or guess column's units from CSV header names plus the column's first 5 values, I don't need Opus 5.5, do I?
You have the harness pick the appropriate model for the appropriate task. Most high level software development projects can be broken down into tasks, many which do not need the smartest model.
This is one of the most useful web tools I've ever seen.
I work on connectors for datasources (mostly DB's. Being able to quickly test things like sorting behavior and how the same function can be emulated across DB's would have made my life so much easier.
reply