avador

There’s a very real dichotomy at play here. Position 0: humans depend upon AI. Position 1: AIs depend upon humans.

At first blush, it seems achingly obvious that position 1 is true, whilst position 0 is a false play by con artists.

Well, at first blush I agree! But first blushes are notorious for being famous last words (blushes).

You see, we always knew that the tool shapes the hand. That is, as we use computational (discrete) devices, we ourselves become more computational, discrete.

But what we did not anticipate is that the tool would fool others as the ACTUAL HAND. I am so fooled. Daily.

My friends. Does technique encompass being? Answer me this!

Once I began the “start from zero” routine at work, I could not stop. It meant I had to know what to do to get back to my ideal dev env every morning. It meant I had the choice to automate that, or to leave some bits (or all bits) manual. It surprised me how much I preferred manual, and taught me to recognize when things were actually tedious vs premature shortcuts. Clarity trumps convenience, but, you know, not always.

I have always cringed at the senior-junior distinction, especially because it is mostly espoused by those calling themselves senior, and that felt unnecessarily imperious.

Any senior in any workplace is senior because of their specific and narrow experience in their particular role, over a sufficient amount of dedicated time. So it felt wrong to me to allow such a bifurcation of human ability with a senior-junior framing.

The thing is, when some people employ the senior-junior language, they are implicitly referring to that very particular, unique, and narrow situation of the role-space they have found themselves in, and justifiably so.

We are all juniors in a much larger space than we are seniors. Does it irk that someone is a senior in the nest they have made? It did, for me, but not anymore. “I tilled this field 17 times; I know it”, is a statement not only of knowing a single field (as opposed to any other fields), but also about some way of tilling.

Without a universal standardization over behaviour, we’re all mostly junior mostly all of the time. Any claim of “senior”ness is therefore a claim of finding something cool in some narrow space. It’s worth listening to and extracting the value from such claims, if the practices therein are producing evidently worthy outcomes.

That said, “senior” is a very small boat in a very large sea. Better to be aware and humble, no matter the efficacy of your current practices in your current environment.

Not normally, no. Can you point to a divergence of the bitterness in the subsequent text?

What I find to be the normal pattern (by intuition) is that the condensed leading text belies the expansive following text. This is likely lazy (a shortcut) and I am open to correction at your effort. If a call to your effort (I apologize) is unpalatable then I concede.

Isn’t “Writing is a Technology that Restructures Human Thought” another way of saying that “feedback has an effect”?

If so, this seems to be a trivial (still worthy) assertion.

For example, I intend to, say, construct a shed. I make mistakes that I only see because I actually constructed. I revise future endeavours involving sheds.

I admit to not having read this piece, and am merely reacting to the title.

—-

Okay, I got through the first paragraph of Walter’s writings. While I nod to the bitterness (I assent to the existence of it), I do not bow.

The inability to tell if a model is improving is, I think, a tell that the model has improved up to your level of programmatic (analytic, computational) capacity.

A lot of the information (blogs, tweelches, plosts) that I consume seems to be converging on the idea that we all depend on the models. However. It seems to me that the exact opposite is true. The models depend on us, and _desperately_ so.

There must have been stories, books, movies, made about this intellectual (and propositional, legal, factual) inversion.

The majority need the minority. Has always been the case, I now think. But what has newly developed is that the majority can take a dependency not on the minority, but on a select few companies who are abstracting and compressing the minority into latent spaces.

Well, if it works on step one, then why not step two? Where would different folks draw the line? My grandparents might continue on a while, whereas I would not. But if it also “works” on step two for me, should I take a third?

What counts as “works” is the important bit, I think.

Yes.

Useful - thank you. I will contact them.

epicfurious.com is blocked by my service provider. It’s a small, local, fiber company called mornington.

They do not say why in the returned html.

I do not approve of such blockage.

Nevertheless. Knowledge is knowledge. So I post for everyone’s sake.

I _think_ what you’ve said is “go shallow, not deep”. That is, don’t let the walk you make inside the latent space a long one. Twenty-five short and peppered steps, from de novo, is better than one long, protracted stew.

Is that accurate?

Order of operations: Make it work. Make it right. Make it fast.[0]

[0] https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

I think you and 7e are both right. Being able to iterate some N orders of magnitude quicker is a big deal. This doesn’t eliminate design and UX. Rather, it merges it with high iteration speed to produce a form of “play”.

“Play” is what produced at least two (likely more) generations of attentive (and therefore competent) programmers. The hype around LLMs is painful, yes, but attentive human minds will ultimately bust through it.

Compusion.

Just finished a reading. (Ordered after seeing this post.)

It’s not my normal cup of tea. I will never forget it.

Hey Yohan,

That is an absolutely lovely resource. Thanks for sharing! Concise, useful, references like this are great “core drills”[0] into the ever-expanding deluge of human knowledge.

[0] https://en.m.wikipedia.org/wiki/Core_drill

To go from scratch to calculus, there is Mathematics for the Million by Lancelot Hogben. I did not see it on gutenberg. But it is on archive.org.

https://archive.org/details/HogbenMathematicsForTheMillion/p...

NKosmatos pointed out in another reply that this post was about software rot, and not data rot.

From the Wikipedia article he linked for software rot:

“[software rot] is not a physical phenomenon: the software does not actually decay, but rather suffers from a lack of being responsive and updated with respect to the changing environment in which it resides.”

The software doesn’t physically rot. Its relationship to something (the world) does.

I attempted to draw a parallel of this to a database because, for many folks, the immediate environment of their app is a database of some kind. The world is kind of like a database, too, because it is read from and written to. But unlike an in-house data store, it changes without regard for dependant applications.

In the second paragraph I attempted to distinguish two kinds of programming endeavours. One is like chopping wood for fire, the other like retrieving and then cutting a hard substance. Whatever the purpose of the latter, it takes planning, experience, and the result is both intended to last a long time, and to be versatile. But the former is cheap and short and for the moment. You’ll have to do it again, many times, and in slightly different ways, depending on where you are, who you’re with, what the weather is like, and so on. Dijkstra’s seeming dismissal of rot may be directed against the latter, but not the former.

I guess my third commentary is that many, many software systems are not designed at the time of their construction, because they are sudden and their manifestation is opportunistic. This lack of design at the point of construction is an implicit assertion against the expected lifetime of any such system. It admits rot as a matter of course.

Imagine your database is a sensor network instead of some schema-ful/typed data store. Field operators unbeholden to you keep adding, removing, or updating sensors. Your data format evolves underneath you, and you behave more like a magic carpet pilot than a builder of things unbreakable. You’re attempting to store the flight path as best as you can, update configurable sensors for the most profitable reads, but what you record is a direct reflection of the current sensors and their current settings.

I am wary of hastily agreeing that Dijkstra missed something. He may have been talking about specific, general purpose algorithms, which do not change much once conjured. There is another type of software, though, a software that sits atop the immutable spellcraft, a software that attempts to shake the boughs of profit trees at specific points and places in time and space.

Dijkstra says “Famous is the story of the oil company that believed that its PASCAL programs did not last as long as its FORTRAN programs "because PASCAL was not maintained".”

The oil company folk are the kind who prefer tree-trembling to the deep and unchanging sea.

I, too, when cold and hugging uncertainty for warmth, prefer to cut down trees for fire than to spelunk for hard diamonds.

“…we aren’t yet good at thinking about the intended lifetime of a software system when we’re designing it.”

And sometimes the life expectancy is so short that any old (or new) design will do.

It looks like https://news.ycombinator.com/user?id=staltz

Or https://staltz.com/

Offers will vary, but, if impromptu answers carry any weight, then off the top of my Sunday afternoon head, this is the first reference that percolates to the surface.

Conclusion:

“ To create the future we must first dream the future. Private foundations that are interested in pro-density politics should give a bunch of money to people like Christopher Hawthorne, who should then scour the country for a hundred different Imperial Boy type artists to draw pictures of the futures of American cities.”

Yes!

I feel the same. The two levels of “variableness”, and the prohibition of mixing them, must have something to do with lazy vs eager evaluation, right?

Look, here we have the humble “Just”, sitting low in the wordy shrubs, almost hidden from view, pecking at its surroundings with confidence. Its natural habitat rife with nutrition, the Just pecks in any direction it likes, and, with ease reminiscent of more rare species, like the Merely, or the Simply, fills itself up for blind and rampant reproduction across all the fields of human thought.

Oh. I see the title was changed. :(

“I discovered computers”, the title of this submission, is uttered very early on in this video. I feel the phrase to be terribly universal in that, at some age, at least, computers provide an antidote to the terrible. Confronted with an obvious and stark lack of power, we are suddenly granted power: the machine does exactly what I say, if I have the patience to learn how to say it. What an incisive and timely tool. What serendipity!

A stick on the ground remains a stick - no staff, no wand, no artifact of thunder - unless urgency presses the insignificant into significance.

This talk by David Beazley (Lambda Calculus from the Ground Up) might be useful: https://youtu.be/pkCLMl0e_0k

Zero and one come in around the 35 minute mark (after booleans).

This is interesting. Is aeroplane flight akin to bird or insect flight? Rolling down the tarmac, peering out the window, the planes look more like elongated fish bodies than soft bird bodies, or compact insect bodies. Our planes rather swim in the air than fly in it, I think.

Our flight is some other kind of thing (whatever we uncovered the model-able, salient properties of flight to be). Computer consciousness might similarly be some other kind of thing. And that’d be ok.

But can they be equated? Only at some abstraction level. A plane is obviously not a bird or an insect or a fish. Aeroplane flight is not bird or insect flight either, nor is it swimming. But it is safe travel through the air, from one earth-bound destination to another.