rtpg

The "top layer" of maths being this is one thing. Now imagine another layer of this. Then another. Then another. Then another.

At one point intuition helps to build out usage of the math itself. See stuff like "oh I can do rotations through matrix multiplication"-style ideas.

It is helpful for us to be able to reach for those tools quickly. The more tools that require advanced prep to use, the less we'll be able to use the results in easier contexts. Everything will be hard

Of course nothing really prevents people from looking for the simpler tools and proofs. Lots of math stuff starts off complicated and gets simpler.

Just important that this is still a goal in mind

Can people please make something with the tools they are pitching before putting it out in the wild?

Not the stupid useless field tests that no one uses. Make a real thing that gets used by more than 5 people. Then consider whether your thing is actually useful. Then maybe put it out to the world

Perhaps you don't want to waste your time or tokens or whatever REing a thing and instead can use something someone else has distributed to solve the problem in a general way

Any time you see “Adjective Noun. Adjective Noun. Preposition Noun” as a section you know you’re in for a bad time.

It's unfortunate because like... in theory if you apply the right kind of debugging philosophy you can use this tooling to help you move through the work a bit more easily.

But just kinda randomly trying at various reasoning efforts reminds me a lot of hearing people just randomly replacing various libraries or code snippets with stuff found on stack overflow. No real theory of the system.

There's not even much of an excuse, cuz you can "just" sit there and type "why?" or "why not?" over and over into an agentic chat session and probably get things working quite quickly. Principled debugging is state space elimination for the most part!

You interpret that wiki list of 154 items as proof that we know nothing. I interpret that as "oh wow, only 154!" That list feels pretty short, but of course it's just a wiki list.

I do get what you're getting at. I just feel like for every bit of drug that is just dumb luck we have a good amount of iterative processes.

I agree that you often find effects before understanding causes (I think that math also exhibits this! Many endeavors are about finding existing structure that we sense to be there but are unsure of).

Just... well... if you go down the "we don't understand anything anyways" path too much what makes your work different from alternative medicine?

I think the important idea here in Terrence's hypothetical is that in the hypothetical there is no hill-climbing. The AI shows up with a thing and says "we don't need to hill-climb for years and waste time, here's a thing that I know will work".

And maybe it does a single finalized clinical trial.

You end up with this miracle drug (supposedly!), but no understanding of why it works or access to the iteration that would lead to that understanding (and increase in confidence that it doesn't cause people to drop dead anyways).

I think the medical example is a bit obtuse overall because "proof nobody understands for an open problem" isn't "miracle drug we are too scared to use". But understanding things feels useful and good.

So is the demo real or is it smoke and mirrors? Could you have pointed at other words and have it work?

(I think I overestimated how much of an angled shot it was the first time I saw it, on top of how easy or hard turning your finger into “actually capture this text”… but you’re totally right that in principle a camera at a non agressive angle can capture that text)

(I like this overall concept a lot! Cooking is the right example, voice interfacing’s 96% use case is basically “my hands are dirty but I must use computing”)

Is a basic webcam really able to read text at that angle for the “what is this word” example?

I wasn’t sure if any of this was real and that example looked extremely fake to me because I had a hard time believing the device being able to read text from that distance.

This is pretty funny to see, because every financial firm interview process I've seen involves some variant of solving a bunch of stuff with min heaps.

Never before has a set of engineers been more primed to solve a problem

> many have voiced other structures such as altering prices based on time/place/road driven, which would require more data than simple odometer readings.

There are people who won't care about this but I think that legibility would be a huge concern here. It's one thing to do $X per megameter, but it's another to start breaking it down into various zones etc

At that point might as well just do congestion pricing in cities.

By living off grid they are stress testing things so that when things are tougher (perhaps temporarily!) things have a higher chance of chugging along

And obviously, like, they go to places and talk to people and buy equipment etc.

There’s a whole gamut of failure modes for tech from “total civilizational collapse” down to “cell tower is down”, and time periods from “forever” down to “a couple of days”

People doing this sort of lifestyle but sharing findings and ideas and ultimately maybe pointing out how more can be done with less is part of us building up knowledge together isn’t it?

These people aren’t completely offline even! They blog and post online!

The problem is that one a person writes a 60 page proof in theory that person has spent an inordinate amount of time on the proof and can answer questions, describe some insight, etc etc.

If a random person is given a 60 page proof to digest and not the author, those hidden insights that _aren't_ in the paper might be completely inaccessible. Maybe the AI will "just" be able to provide the insights. Maybe. But pedagogy is tricky work, and despite these AIs being able to do all this fancy math we can't get them to write good cover letters yet, so....

Ultimately we might be left with just a bunch of intellectually unsatisfying proofs. This means way less drive to simplify the proofs or rework them.

End result: we generate a layer of "less efficient" mathematics, that won't get built upon. We will not actually have any shoulders upon which to stand.

IIRC I think it overclocked your PSP or something?

I agree there's a bunch of buggy software, my contention is that a lot of that exists is because people are bad at the hard part and the easy part!

I am also dissatisfied at the current state of software so feel your pain. I think it's just that like .... I think if you can't get the code right you're probably not getting the requirements etc right either.

I've had discussions around this with theorem prover types (OPLSS, highly recommend for people who can take the two weeks off)

The sort of head canon for any of the automated proof systems is that lean saying a proof is correct is "if lean is correct then the proof is correct".

One can get the temptation to try and prove lean correctness with lean but I believe _that_ is impossible due to the incompleteness theory.

_But_ the discussions I had, everyone was kind of in agreement with the idea that you could continue to shrink down the "kernel" of lean with lean (or whatever proof system really) so that in the end the thing you have to trust is pretty small.

I don't know if we can really be clear about the order of things, but I think even without AI maths is filled with "someone provides a proof of X, and the proof itself is wrong/incomplete but X itself is true".

"Incomplete" proofs might be a way of viewing this. You have a NL argument to prove X. It turns out the NL proof has holes you can drive a truck through. So... you go around and patch the holes.

The resulting proof is different! You can start off with a bad proof and find a correct proof. Sometimes.

EDIT: for French speakers (maybe autodub gets you there) I saw a very nice simple case of this recently. A commonly stated proof for a relatively simple theory. The proof has a giant hole in it, and completing it requires some work [0])

[0] https://www.youtube.com/watch?v=kQBu6NH1u3I

I've always believed the opposite: get conditionals deep in your code so that the higher level control flow is regular.

But I suppose my greater philosophy for making code that avoids bugs is that you have a couple things that are done when dealing with data:

- distribution

- deciding

And you want to avoid distribution and deciding being mixed together in the same spot.

"Distribution" can be for loops but also breaking up some data based on some key into N bistinct buckets

"Deciding" is where you're looking at the data more closely to make some decision (like "is this a big customer or a small customer")

Distribution often involves decision making, but if you mix them all in one spot you can obfuscate your decision points. Splitting it up just makes things "obviously" right or "obviously" wrong. Perf stuff is another discussion of course, but in practice most things are not at a scale where it matters.

    by_category = defaultdict(list)
    for d in data:
      by_category[category(d)].append(d)

    for category, per_category_data in by_category.items():
       do_thing(category, per_category_data)

I really value code patterns that make mistakes obvious, or at least makes it harder to stuff a mistake in somewhere. Some patterns are harder to describe in this model though.

(I do like the advice of having a consistent vocabulary for working on collections as a principle though, I just find that top-level conditional use tends to quickly get you into "... why is this method not called" territory, which is a more annoying problem than "why is this slow")

For a server using a DB, all of your methods are calling out to data stores. So you're like "OK I receive a &connection" but all the mutability is hidden inside.

There's a bunch of type direction you can do to get around this (`ReadConnection` vs `ReadWriteConnection` and some other magic), far from an immediate win but it's not impossible.

People talk about mutability a lot but the vast majority of Python code I see in the wild is SSA and has _very_ little mutability to begin with.

Of course ownership still has its costs. Lots of "I guess I'm copying this dict because I don't know if the owner will modify it or not" issues.

I think people overestimate how much they'll get from `&mut` annotations on business logic, and undersestimate how much line noise they'd get from a lot of the other stuff that happens in a lot of business logic.

Granted, I'm coming from a web-dev/Django perspective, where duck typing and overriding methods in subclasses is used heavily. And a lot of that doesn't have a nice 1:1 equivalent in the Rust model.

(I enjoy Rust BTW, just don't feel particular excitement about shuffling around strings in it)

I feel like everyone already knew the code was the easy part, even pre-AI.

> Coding being so easy now has just pulled back the curtain and shown the world that software developers really don't have much left to contribute. It's been done, a thousandfold.

Maybe, but I feel like there's a reason that the "useful" AI-generated work all seems to come from people who could get to the same result given "infinite" time anyways.

AI tool usage reflects and amplifies your own skill sets IMO, and I think it's pretty hard to be amazing at software architecture design but be bad at coding.

For people who don't want to splurge on the Noguchi lamps, Aliexpress has a decent number of knockoffs.

Probably way less stable than the real deal.

We have a couple of the marset lamps that we enjoy as well. The sort of low-poly design is really fun.

The lack of polish is usually in the actual usability of the feature set (see yesterday's "polished photoshop clone" where the keyboard shortcuts just don't work)

I think you can use these tools to get something very polished. I have found that a lot of people get "tricked" into thinking that their result is good, but the people making these things and the people with expertise in the domain are often not that close to each other.

It is valuable for a thing to get used to figure out if it's actually any good.

Though the obvious glib thing is a lot of people build these tools and then don't use it.

(No not you, person who decides to reply to this saying 'but _I_ use it')

Sorry if you think 280 household of water is not a lot and if the facts don't help your cause.

For a small locality it is a real amount of water. And if there's a draining reservoir, then that's _even more_ water being pulled out of a reservoir.

The almond discussion is tiring as well. We're not growing almonds in most of the world. The water in Montana isn't the water in Cali as well.

If the facts aren't on your side on a specific issue, at least have the courage to accept it.

> I'm sure we'll be staging the protests and forgoing our emerald nuts 100 cal snack packs any day now.

People protest golf course water usage. Water usage problems in Cali are not as big of a concern to people in Montana than water usage in Montana.

And of course there are people who think that the added buildout of data centers _for AI usage_ (people acting like "oh these data centers are just from everything", let's not kid ourselves what the source of the demand is) is a net negative. People don't think that about food.

Personally I think we shouldn't be setting up massive farms in a desert (and perhaps just figure out how to make society work in a way where during winter we accept having less fresh veggies available) either.

Data center defenders need to get better talking points, cuz they sound very silly (perhaps as silly as the arguments heard on the other side!)

I guess it has to be said: it is not guaranteed that the water rains in the "right" spots for it to be useful freshwater again anymore. Dumb example: maybe the wind currents mean that the water simply comes back down downstream.

One shouldn't assume that evaporated water comes back into the system in the place you want it to. Water management orgs try to reduce loss from evaporation for a reason!

Median US household water usage is 130 gallons per day according to Wiki.[0]

So ~280 households worth of water? Though the US seems to be on the high end, using 3x more than Japan and 4x more than France (according to a random website)[1]

To state the obvious most people are not running big faucets all the time, and in fact are using way less.

It seems like a bit of a self-own to not just use household or per-capita usage here to prove a point though.

[0]: https://en.wikipedia.org/wiki/Residential_water_use_in_the_U... [1]: https://www.worldometers.info/water/

I don't think React pretended like they've invented FP, and I've always heard them be pretty open about FRP work existing in the past and them leaning on it.

This issue remains true even with the JS "wrapper" elements.

The number of times I have senen frontend people pull in some frontend component from a library (say, for fancy select widgets) and then have to spend a bunch of time trying to fight the existing bugs in that... and then struggle to swap it out later on for another library with a distinct set of bugs...

UI is hard, so it's hard to have a general thing fit _your_ specific purposes nicely. This is why I think it's super valuable to wrap things you can't control easily. That way you both document what you _do_ use, can fix issues at a bit of a higher level, and can swap out the internals way more easily.

People fight back on me on this on so many projects (the most recent thing: "the LLM won't know about our special UI component" IT WILL! IT CAN READ THE CODE!), but then hit those moments of regrets and end up wrapping stuff anyways.

Especially annoying coming from people who talk about design systems. A base vocabulary is a real good way of enforcing a design system!

I mean this relatively lightly, I understand the qualms at a high level, and coming up with the right abstraction is a skill. I've just felt the burn too many times and have very little issue coming up with very limited abstractractions and relying on tech debt to get my wrapper components out into the world.

OP's comment:

> it's basically a highway with no sidewalk would not matter.

"Basically a highway" and "a highway" is different!

In my experience all highways have markings explicitly banning walking (among other things). So it sounds like OP was making a judgement call based on the fact that there's no sidewalk.

I have the unfortunate experience of walking alongside certain roads without sidewalks. It's not fun by any means but I wouldn't want OSM to outright say that it's not walkable.

Of course it maybe "actually" was a highway.

All three of those companies were convicted in a price fixing scandal.

I feel like it's "obvious" that it's not particularly in the interests of these companies to increase production in the current environment. Except perhaps in the long term "we don't want to get nationalized" or something, I suppose.

Personally I do not think think that they are dragging their feet extremely intentionally, but I do think they are structurally incentivised to do so.

> 2 years is not remotely enough time to spin up a competitor. It's not even enough time for a current leading competitor to spin up another fab.

A thing I heard from a friend who works in at one of the largest providers of production machines in this space: they have the machines and for some slices of the market they could basically ship them to a new fab next week. The problem is more in the installation (since the installs themselves are complicated), where they're basically limited by not having enough people to go around and _do the installs_.

It's really funny to think about how the bottleneck is so deep in the chain.