Their product is ads slots and data, which they seem to be brilliant at. Everything else is a funnel to feed the ads, and the funnels change like wvery other marketing funnel.
AI probably should be. The bulk of its efficacy comes from the work of “everyone else” (in loose terms). AI also aims/hope/threatens to replace such a large number and range of jobs that it probabky should be a commons.
It’s a reasonable course for helping yiu identify a single line of notes across the two staves. Or maybe just the “right hand” upper/trebble clef stave (the bormal one for most instruments).
It does teach a little anout scales. It wont teach chords. It doesn’t go very far into time signatures. It only has you play a virtual keyboard so it’s useless for learning how to feel your instrument.
It’s quite fun. My kid plays it every day and it’s helped get them feeling more confident to sit at our piano and noodle around. As a noodler myself, this seems valid.
It wont get you good enough to play pieces with other musicians, or to compose with weatern harmony. You’ll need extea tutorials for those.
I agree that we had much better patterns back then. The software industry in general worked towards sharing visual paradigms, making use of system designs of their host playforms, facilitated discovery etc etc. All that was good and the recent trends moving us away from that consistency and discoverability are a detrement being steamrolled over by agents…
But I don’t agree that it “looked nice”. I hated Windows 95 and 2000’s “style”. They looked like engineers had made them. They looked stiff and unfriendly, eith too much border and outline. Real life has no outlines. I was in my late teens when 2000 came out. My friends and I jumped on it and felt it was the Os we had been waiting for.
But even then I thought it looked like shit.
The affordances were great. I agree that details like button depress and consistent scrollbars are valuable.
But I genuinely prefer things a bit rounder, a bit flatter, less grey, or late Aqua-style flat-with-shiny-affordances.
I agree that backgrounds should be flat (or very subtly textured so they recede but arn’t “boring; again, late-00s Mac OS nailed this for me).
What I’d really like to see is something new that takes the consistency of NT/2000 and Mac OSX prior to Lion, mixed with the novel affordances of BeOS/Haiku (docking windows, small title handles), and puts it through Apple’s “zing” (but not too far - transparency is highly overrated).
Context: I vibe code most of my production code, but I come from a long FED career so I'm vibe-coding small things, constantly tweaking, refining prompts, picking work to do that fits with the existing work, etc. So I'm either "doing it wrong" or "being careful". Anyway, that's the perspective I have ATM...
So, it seems to me that there's quite a lot of skill to using these "god boxes": which models, connecting to your systems, hosting the code, running the model, running the code, not breaking your production pipelines, having a production pipeline in the first place.
Sure, the god boxes help with a lot of that. But they don't help setting up the accounts, connecting your code hosting to your production servers. You can't currently just give random people in your org access to an LLM account and have them safely make production changes w/out some engineering knowledge and oversight. In NGOs, especially the small ones, they already outsource all that to 3rd parties so they don't have to worry about it. But with "just the right amount" of in-house knowledge, gear, config (maybe one office computer hooked up with Claude, or a small GHCP account, with GH + hosting configured), it's possible that anyone in the company might be able to add to the company's suite of useful small tools, or add features.
(I also think there's more to "hey claude, make feature X" than we're capturing here, but as I said at the top, I might be doing it wrong.)
I think I missed the significance of your narrowed definition of recursion, and didn't apply it the way you intended when I read the article. I admit to my bad reading.
I went on to discuss your article with an LLM and used the experiences I've had _using_ some functional approaches in JS to help it give me a tutorial on the combinators, to try to better understand your article and the underlying principles. I "mostly get it" now, but I will have to go over it a couple more times.
You shared a thought-provoking article, even if I didn't immediately get your intended lesson out of it.
I’ll re-read it, because clearly I don’t get it. And I’d like to.
My first two attempts made it seem like it was building on a function calling itself, with itself as an argument (so that it can call itself). I’m not sure how that isn’t recursion, and I didn’t read it as throwing away those approaches. But, as I say, I’ll re-read it…
It sets a challenge as a rhetorical tool, but then completely fails to honour the challenge through the bulk of the explanation.
- don’t use recursion: spends multiple paragraphs implying that a function calling itself isn’t recursion
- don’t use declaration: ignoring that defining arguments to a function is declaration
I’m not saying the article is “wrong”. But I thunk I’d have preferred a plain intro to lambda calculus.
(Writing this as someone who has struggled to learn “real” functional programming the few times I’ve tried over the past 20+ years, but who very much likes using RxJS and the functional flavour of lodash and wishes I could see deeper into that black hole.)
> Poor quality comes from the fact we have outsourced manufacturing.
My experience with software development suggests this is not the main driver. The main driver seems to be management not caring about quality, UX, long term maintainance costs, externalities, and by viewing customer service as a cost rather than as branding.
The "right" abstraction seems like quite an art. Sometimes it's not obvious, or it takes multiple rounds of exploration and testing (I'm thinking here of the mental shift moving from HTML + JS, via jQuery, Backbone, Knockout and up to React/Vue or Angular). At all points, we thought we had reasonable abstractions for a while. Vue and Svelt, or NextJS, now are so far from the mental model of early 00s "DHTML".
And I'm not sure how this relates to TFA's point. Are you saying we collectively need to get better at abstraction so that LLMs get better at abstraction (either by training, or our prompting), so that their code is easier to read?
My inherent pedantry drives me to say "this sounds like compression, not gating". Do lots of people use "gating" to mean "automated volume control"? In 30ish years of hobbyist music production I have only encountered it to mean "automated in/out control". It's "compression" that automates dynamics.
Thinking out load a bit here:
- maybe the existence of West-coast style "low pass gates" proves me wrong...
- gates sometimes have release controls, which would make them "automated volume control", but I still contend that aiming for zero gain when the gate closes makes them in/out controls not "dynamics" controls).
> Another way in which it's not cheap to lose sight, I guess.
True.
We can frame it even more strongly: "default societal practices actively discriminate against people with disabilities; they intentionally, consciously choose to make life harder for people who're disadvantaged".
TypeScript interfaces just merge. You can aet any property name you like on a plain JS object, at any time.
The CSS version is a risk, for sure. The dev tools in all the main browsers will tell you where the extension happens and show yiu the order the complecting rules are applied, so it’s fairly easy to debug. Bugs/misbehaving code is usually a problem of structure. In other languages, we take on the need to apply structure; just do the same with CSS.
The mechanism that allows this merging behavior is the means by which intentional reuse is composed. It allows yiu to set general and specific rules sets. This seems conceptually similar to OO classes and subclasses, to me.
In your "programmatic" code (your JS/TS, python, C++, whatever..) your classes are global. Even if the language supports flexible namespaces, or module scoping, you still have to take great care naming because reusing a name will cause you confusion. Giving two things the same name makes them harder to import, and risks clashes and bugs.
No-one complains about this. This is just how you code in all those other languages.
Mix this 3d graphics, with data science notebooks, with local LLMs, and perhaps an integrated coding harness, with visibility over your personal data and you’d have something absurdly good.
This might overtake “a haiku+macOS mashup” as my idealised computing future.
My banks provide different colour options for their cards. All my digital cards differ, even from the same bank. The alternate colours helps within the banks/ apps as well as within Wallet, so it's not just an iOS "workaround".
I agree, it would be nice if Apple added stickers, but the problem isn't, IMO, as bad as you make out.
Exceptions include transport and concert tickets. Most of the time this doesn't cause problems because I'm standing with the other people I'm travelling/gigging with, and the agent scanning the tickets doesn't care about any names on them.