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.)
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…
author here. the idea is to see how the Y and Z combinators come out relatively naturally given an extremely constrained context with no loops, no recursion, no bindings. the article is intentionally structured as a sequence of failed attempts that progressively reveal which phenomenon is still responsible for the recursive behaviour.
in the article, i define recursion narrowly as "... call the function `fact` from inside the definition of the function `fact`".
you're right that `factgen` is also not recursive but it is also rejected, but for a different reason: self-reference. declarations are banned precisely because they give a function a "name" that can be referenced later.
please note that the solution which uses Z combinator (given at the end) grows from `(x => x(x))(x => x(x))`, which is NOT self-referential. it achieves self-replication by literally rewriting the content of the function twice, which is different from self-referential recursion of `factgen`.
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.
So it's as confusing as I thought to do it that way. I wasn't sure if I thought so because I'm already familiar with all these concepts or because this introduction is indeed convoluted. Thanks for taking the time to reply!
> 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?
>> I’m losing control over the code I write when I work with agentic code generation
> 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?
No - our current abstraction for coding agents is a loop where we express some freeform specification of a goal, then a sub loop kicks off where an llm takes a stab at what good looks like for the next step (make an edit, search for info, run a command to cause some side effect etc etc), it iterates in this loop and when it's finished its sub loop, it declares end of turn and the loop returns to the user for steering input.
That inner agent loop can make it quite hard to stay in control.
What if instead of only these low level free form prompts we additionally had some higher level primitives to work with?
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).
There's a world where all the big platforms automatically flag AI images thanks to SnythID and other techniques. The more ubiquitous it is the easier it will be for them to make that a reality.
> 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".
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.
In "programmatic" code, declaring two classes with the same name in the same namespace is generally either some sort of syntax error or one will "shadow" the other; it doesn't just silently merge the behavior of both classes.
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.
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.
Greenspun’s Tenth Rule of Programming states that any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
well, almost. if emacs offers a graphical file manager i'll consider using it. this seems to be a start: https://github.com/emacs-eaf/eaf-file-manager. the file manager needs to also integrate with a terminal though so i can run unix commands in the same directory. and it needs to support mouse-based operations too. finally, and that's the real kicker, i'd like a better integration of the terminal output and the graphical display by supporting the passing of structured data that the display knows how to handle without terminal escape codes. those need to go away. (which is why sixels are not a solution either)
you got a point with the notebook, except both it and vscode are for programmers. i want the same for non-programmers for the unix commandline. i looked at jupyter-qtnotebook. it can display graphics inline. now instead of a repl for programming code i want to enter unix commands and display their output with graphics.
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.
> but the problem isn't, IMO, as bad as you make out.
But it is exactly as bad as they describe it. My bank doesn't provide color options for my cards, and there is no way to distinguish my two cards aside from the displayed four digits.
I didn't know I could do that, so I just gave it a try.
First instinct, double tap the side button to open Wallet. Couldn't rearrange the cards there. So,I opened Settings app and couldn't rearrange the cards there. Finally, I opened the Wallet app and found I could rearrange cards there, though there's no visual indicators that I can. I accidentally changed my default card on the first attempt.
I find it very strange - I don’t really know what to make of it.
I have the wallet shortcut in my control centre. If I use it while on the Home Screen, I end up in the wallet app where I can rearrange and change settings for the cards. If I swipe down the Notification Centre, on my still unlocked phone, and then also swipe down the control centre, and then use exactly the same shortcut, I now end up in the “double-click to pay” version of the wallet, with no rearranging.
Sometimes there seem to be two different apps - the transition to the full app is a sideways transition, while the double-click version slides down from the top of the screen.
However, if I am in the full wallet app, with rearranging options available, and I double-click, it changes the wallet app to the double-click to pay version with no transition.
> My banks provide different colour options for their cards.
I'd like to take a moment to appreciate a tiny "UX feature" that punches above its weight: When multiple physical cards have different base-colors to their plastic, visible along the edge.
This reduces how often you even need to check the face of a card. With several in one sleeve/stack, you can slide out the one you want, knowing that (for example) blue is credit, green is debit, red is the shared family one etc.
With my kind of wallet, if I had to pick I'd rather customize the edge-color versus the faces.
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.)
reply