jonathaneunice

That's the best "what is ANE, really?" investigation / explanation I've seen. Directly lays out why LLMs aren't an ideal fit, its "convolution engine" architecture, the need for feeding ANE deep operation sequence plans / graphs (and the right data sizes) to get full performance, the fanciful nature of Apple's performance claims (~2x actually achievable, natch), and the (superior!) hard power gating... just _oodles_ of insight.

Are the Apple neural engines even a practical target of LLMs?

Maybe not strictly impossible, but ANE was designed with an earlier, pre-LLM style of ML. Running LLMs on ANE (e.g. via Core ML) possible in theory, but the substantial model conversion and custom hardware tuning required makes for a high hurdle IRL. The LLM ecosystem standardized around CPU/GPU execution, and to date at least seems unwilling to devote resources to ANE. Even Apple's MLX framework has no ANE support. There are models ANE runs well, but LLMs do not seem to be among them.

Ecosystem was a huge driver. But even before that, so so easy to get going. 5 minute guided install, if you're doing it yourself. Many web hosting providers auto-installed for you. No one could touch that ease to just get going.

I once did a review of CMSs to see "is there anything better out there?" Literally scores of options. At one point seemed like everyone had tried their hand at building a CMS. Installed maybe a dozen of the most promising. It was all very meh. Some had this nice feature or that (e.g. WYSIWYG editing, back when that wasn't table stacks). But overall, none seemed substantially better that WP, Drupal and Joomla among them. Most of them seemed blighted by comparison. Drupal and Joomla included. Nothing else out there seemed worthy of investing time and energy into.

First impression is love that! Need to study it more.

We need—or at least I need—a better UI/tool to manage the sequence of edits and collaboration, drafting, rubber-ducking, and evaluation that AI tools provide. Including the prompts and edits is a nice feature, though I would also like more comparison "where we started" vs "where we are now."

Agree with the underlying point: "don't let an LLM do your thinking, or interfere with processes essential to you thinking things clearly through."

My own experience, however, is that the best models are quite good and helping you with those writing and thinking processes. Finding gaps, exposing contradictions or weaknesses in your hypotheses or specifications, and suggesting related or supporting content that you might have included if you'd thought of it, but you didn't.

While I'm a developer and engineer now, I was a professional author, editor, and publisher in a former life. Would have _killed_ for the fast, often excellent feedback and acceleration that LLMs now provide. And while sure, I often have to "no, no, no!" or delete-delete, "redraft this and do it this way," the overall process is faster and the outcomes better with AI assistance.

The most important thing is to keep overall control of the tone, flow, and arguments. Every word need not be your own, at least in most forms of commercial and practical writing. True whether your collaborators are human, mecha, or some mix.

Love this!

I've heard that desert sand is fundamentally smoother than beach or river sand. Would love to see some examples of non-beach sand side-by-side with these glorious samples.

Love this!

Have wanted to work on a "better situational awareness while traveling" app, but haven't yet had the chance. Reachability of a POI is a great place to start, and I _feel_ that "it's a lot harder than it at first looks" aspect.

It would also be cool to:

* Become aware of local attractions. Esp. good restaurants, shops, views, hotels, hiking trails, etc. A lot of rating systems seem to give every fast food venue 3 or 4+ stars. Impossible to sift out the truly good and local / unique from the chaff.

* Become aware of time-limited events. Fairs, art shows, VFD chicken BBQs or fish fries, ... all the little "I wish I knew that was happening, I would have stopped by!" I constantly search for the local, the offbeat, the not-yet-another-corporate-outpost. But again, the chaff!

* Be able to navigate on backroads and scenic roads. Mapping apps are so hyper-focused on getting you there fast. They're not good at "get me there happy"—at least not for those of us that value the path less traveled far more than the highest-speed highway.

> while avoiding AI taint

Don't be shy. Tell us what you really think.

This times a thousand!

In the years before VMs, containers, and locked dependency manifests, it was essentially impossible to get repeatable builds. There are still a lot of hurdles and gotchas, but we can at least get a rough approximation. The idea that some other pre-2010 dev team was going to be able reliably build your thing from just raw source code, and have it closely resemble the thing you built—it was a delightful fantasy. Escrow was a sales and legal "don't worry we have that eventuality covered!" CYA and emotional de-risking move, not a practical expectation of ability to build from scratch.

See the embedded video Failed Vocal Attempt (Music Video). However when it is played (at 0:02 or 0:03), it shows a title card for "Neon Dreams." That's the song that seems one part ELO, one part Daft Punk.

_Neon Dreams_ is ELO × Daft Punk.

Sometimes posts like this are just value-signaling. I hear a lot of cynicism and "just you wait, the other shoe will drop" comments along those lines.

But combined with the other projects Anthropic has pursued (e.g. around understanding bias and explaining "how the model is thinking as it is") and decisions it has made, I'm happy with the course they're plotting. They seem consistently upstanding, thoughtful, and respectful. I want to commend them and earnestly say: Keep up the good work!

You might think you can, for a while. Been there, done that. But you probably can not do so sustainably in most cases. Even if you could, would you really be better off building vs. buying? Outsourcing development, operations, and maintenance is almost always the better choice, letting you focus on the things you do uniquely, differentiably, or meaningfully better.

"We have this awesome internal version of Docs that we're responsible for fixing, upgrading, and doing support for" is not the flex "AI can code anything!" aficionados think it is. Especially when you also have similar internal versions of Sheets, Jira, Slack, GitHub, Linux, Postgres, and 100 other tools.

> If you believe the AI researchers–who have been spot-on accurate for literally four decades

LOLWUT?

Counter-factual much?

Switching to sovereignty-protecting, locally-hosted collaboration, compute, and storage is by no means impossible. FOSS advocates have been eagerly beating this drum and providing options for 25+ years.

The missing ingredient has always been the will to absorb the inevitable cost of change, and the friction of choosing something other than the standard, go-to, often at least apparently free (or at least bundled) tools.

The current U.S. threats against NATO and allies creates a rift in the previously-accepted international order that may finally motivate material change. Often such change is chaotic and discontinuous—it feels well nigh impossible, right up to the moment it feels necessary and inevitable.

That's Dan Frye's article, and it is um, a little Dan Frye-centric. He was a legitimately important contributor to IBM's technology management team around Linux and open source, especially as and after IBM made the turn.

But it reads as if he called the shot and piloted the turn. That is not my recollection or understanding. Other folks contributed as much or more to driving the Linux/open source pivot. Irving Wladawsky-Berger, the late Scott Handy, _et al_. It's IBM, so there were a ton of folks involved and contributing.

My source: I was an industry analyst and consultant in the server / system software space at the time, and I was in at least a few of the rooms where it happened.

Love a good rant or an artfully scathing review!

This seems very consistent with the refactoring techniques taught by Sandi Metz (https://sandimetz.com/99bottles). After taking her course, I successfully applied those techniques to good ends and outcomes.

Not sure "refactor in context" is the tool for every single last refactoring job in the universe. Some plumbing changes may be large or systematic enough that they need to be separately planned and applied, especially as explaining "oh I changed the fundamental way we do things, just in passing" can be a hard PR to present. OTOH, since adopting the "in context" approach I have had many fewer refactoring attempts abandoned, and refactoring seems much more logical and purposeful. So it works IME.

The complexity and frustration are in no way accidental. A carefully designed, obfuscated, and Byzantined process designed for exactly this effect.

> You're supposed to be so beaten down, so utterly depleted of will, that you just cave. [...] You disable a bunch of parental controls you don't really understand. You let your kid play his damn game. You become the ideal customer.

Exactly so. Parental controls, privacy settings, permission to show ads and collect infinite tracking data… The machine is working exactly as intended. Maybe there are sentiments that "the parents should have some control" and maybe there are some laws about protecting children or protecting consumer privacy. But hey, what if actually using any of those mechanisms was mind-bendingly difficult and annoying? What if your control were only available downstairs, in the unlighted cellar, at the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "Beware of the Leopard." We'd still be in compliance, right? Heh heh. Yeah. That's the ticket!

It paved the way for a lot more than that. At a time open source in general, and Linux in particular, did not have much corporate buy-in, IBM signaled "we back this" and "we're investing in this" in substantial ways that corporate IT executives could hear and act upon. That was a pre-cloud, pre-hyperscaler era when "enterprise IT" was the generally understood "high end" of the market, and IBM ruled that arena. IBM backing Linux and open source paved the way for a large swath of the industry—customers, software vendors, channel/distribution partners, yadda yadda—to do likewise.

Cosigned!

Em dash forever! Along with en dash for numerical ranges, true ellipsis not that three-period crap, true typographic quotes, and all the trimmings! Good typography whenever and wherever possible!

VAX hardware did eventually run out of steam by the early 1990s. But VMS had already failed to capture the next generation of growth. Even while DEC was still the number 2 computer company, 5–10x the size of its competitors, and growing $1B/yr in revenues.

Unix (workstations first, then servers), PCs (DOS and NetWare, later Windows), packaged enterprise apps (e.g. IBM AS/400), "data warehousing," fault tolerant apps—a lot of those were not things happening on VAX or VMS or any other DEC product. The fight was already structurally lost and VMS aficionados were already bemoaning DEC's failure to pick up new workloads and user communities even when VAX was still going strong.

VMS declined like almost all proprietary minicomputer environments. AOS, ClearPath, GCOS, MPE, NonStop, PRIMOS, VOS, and VMS...all fine products just ones no longer serving the high-growth opportunities.

Declining investment streams hamstrung proprietary CPU/system development efforts compared to higher-volume alternatives (PC or Unix), so they got successively slower and relatively more expensive each generation. Proprietary environments weren't designed to ever escape their home fields, nor were their companies set up to profit from opening up / spreading out. A few tried, very belatedly, but... by that point, dead man walking.

So from this vantage, same pattern, not a different thing. Perl and VMS were awesome in their original home fields, but were not quick to, or even able to, capitalize on the new directions and workloads customers grew to want.

Ordering, like stability in sorting, is an incredibly useful property. If it costs a little, then so be it.

This is optimizing for the common case, where memory is generally plentiful and dicts grow more than they shrink. Python has so many memory inefficiencies that occasional tombstones in the dict internal structure is unlikely to be a major effect. If you're really concerned, do `d = dict(d)` after aggressive deletion.

Debugging is a completely different and better animal when collections have a predictable ordering. Else, every dict needs ordering before printing, studying, or comparing. Needlessly onerous, even if philosophically justifiable.

That's a great link and recommended reading.

It explains a lot about the design of Python container classes, and the boundaries of polymorphism / duck typing with them, and mutation between them.

I don't always agree with the choices made in Python's container APIs...but I always want to understand them as well as possible.

Also worth noting that understanding changes over time. Remember when GvR and the rest of the core developers argued adamantly against ordered dictionaries? Haha! Good times! Thank goodness their first wave of understanding wasn't their last. Concurrency and parallelism in Python was a TINY issue in 2006, but at the forefront of Python evolution these days. And immutability has come a long way as a design theme, even for languages that fully embrace stateful change.

Perl's decline was cultural in the same way VMS's decline was. A fantastic approach and ecosystem—just one overtaken by a world that was moving on to a different set of desires and values.

PHP emerged as a separate language and community and "ate Perl's lunch" when it came to the dominant growing app style of the Aughties... web pages and apps. Had PHP instead been a Rails-like extension of Perl for the web, sigils would have reigned for many years more. But there was never a WordPress, Drupal, or similar in Perl, and no reason for anyone who wasn't already highly connected to the Unix / sysadmin community to really give Perl another look.

By 2005 if you weren't already deep into Perl, you were likely being pulled away to other communities. If you were into Perl, you were constantly lamenting why newbies and web devs weren't using your language, just like the DECUS and VMS crowd did a decade earlier as Unix and Windows consumed all the oxygen and growth opportunities in the room.

Asking about Y (or Z, or some other problem a few layers down) is common when yak shaving. Aka doing the thing that's needed to do the thing that's needed to do X. Not to be confused with the also-present problem of ADHD sequential distraction by some other unrelated problem (possibly one sighted along the way to eventually get X done).

It's a gross idealization that every problem can be directly solved, or is "shovel ready." In my world there are often oodles of blockers, dependencies, and preparations that have to be put in place to even start to solve X. Asking about Y and Z along the way? Par for the course.

Sure you could just use in-program comments and/or external annotation files. There were a handful of standards for doing exactly that... NumPy, Google, RST/Sphinx, Epydoc, Zope, ...probably a few others I'm forgetting. And there were external "stub" definition files like `.pyi`. Not exactly code, but closely-linked metadata. Ruby seems to be trying something like that with its `.rbs` files.

IME not until there was a sufficiently clean, direct, and common way to add typing (PEP 484 and its follow-ons) did the community actually coalesce, standardize, and practically start to use type information on a broad basis. We needed there to be one default way of sufficient attractiveness, not 14 competing, often incompatible, and rather inconvenient options.

You may look at built-in typing as a way to communicate with interpreters, compilers, type-checking and linting tools, and/or editor language support engines. Certainly the old purely static typing languages looked at them this way, out of necessity. The compiler, linker, loader, ABI chain has to know the bit-width of your objects, and pronto, because they're going right on the stack!

But in a highly dynamic language that doesn't strictly need types to run the code, typing works as much a signal to future me and my colleagues and collaborators as it is to any mechanism or tool. It signals structure and intent that we'd otherwise have to intuit or decipher. That some tools can use it too, just as they do in fully static languages, is great and useful but not the whole enchilada.

I had exactly this reaction when gradual typing came to Python. "Do we really need this??"

But over time, I've grown to love it. Programming is communication—not just with the machine, but with other developers and/or future me. Communicating what types are expected, what types are delivered, and doing so in a natural, inline, graceful way? Feels a big win.

Wayland is the IPv6 of the windowed display world.

The bright, complete, unfettered future always just a few more versions and a few more years over the horizon.