rtpg
"I can one-shot a new thing" is interesting but definitionally a thing is new only once. Maybe if I worked in a space where we had way more throwaway things to work on.
At the end of the day I want to understand the output anyways, so it one shotting a thing vs me going back and forth with it in smaller increments is a mixed bag anyways.
You can go very far in life with a thing that isn't futzy
I wonder if Anthropic will "see the light" and stop trying to burn a bunch of money and sell a thing they already have (which is decently useful). Very ready to be proven wrong in any direction
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
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
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!
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?
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.
(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”)
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.
Never before has a set of engineers been more primed to solve a problem
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.
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!
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.
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.
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.
"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])
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")
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)
> 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.
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.
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')
Don't you have a company to found or run or whatever? What are you doing in here?
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!)
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!
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/