It's a shame you've been downvoted, this is better satire than anything A24 has put out in years. Must be a large number of people who saw that post as a slightly exaggerated mirror held up to themselves and didn't like it.
To me it often if feels like South American countries themselves are stuck in an eternal pendulum of electing corrupt left-wing populists after corrupt right-wing populists and swinging back again.
That's representative democracy. There's not really any practical ways to delegate power without enabling corruption, so corruption is more or less inevitable without radical levels of transparency and public oversight.
The main idea is that in legal contracts, the written signed paper is just evidence for what the agreed-upon contract was. The actual contract is the agreement itself - which the paper may not reflect exactly. If the two parties disagree on what is the actual contract, the paper is of course strong evidence for one side or the other, but it's not the final word, other evidence may be brought that contradicts the written contract and that can be held to be more convincing.
In contrast, the smart contract crowd wants the contract code to represent the final word, and if any party didn't notice that the contract code didn't match the understanding they had of the agreement, too bad.
A statute is an act of legislation, and a "statute of limitations" typically prevents courts from dealing with claims arising from matters that happened years ago (subject to some exceptions). The public policy arguments are usually that witness memories decay to the point of obvious unreliability, and that the maxim "equity aids the vigilant not those who sleep on their rights" was already the root of the common law doctrine of laches, but scattered over so much case law that putting the concept on a statutory footing is useful for the courts and all litigants (and especially defendants).
(In criminal law, "justice delayed is justice denied" and clarifications of constitutional or treaty requirements for speedy trials also can be tidied up by the legislature in a statute of limitations).
Statute (legislation) is a superior source of law to contract law, and so there is generally no way to contract to avoid being statute barred if a claim for breach of contract (or specific performance, etc.) is made beyond the statutory deadline.
Typically there are carve outs enacted in a statute of limitations that allow a claim to be brought out-of-time if the defendant has acted in a dishonest way that prevented a claim from being filed in time, for certain classes of litigant, or for certain types of claim. (And in criminal law, for certain offences - serious crimes will tend to have a longer, or no, limit on how long after the crime the prosecution is begun).
A statute of limitations typically does not extinguish defences based on the lapse of too much time; but such defences in some jurisdictions may be contracted away, leaving the statutory limit as the hard deadline.
There's nothing to prevent people from having a blockchain subject to court jurisdiction. In fact probably all blockchains are anyway, modulo the problem of enforcement.
There's this thing that people often do, even within the law itself, that's just like "well, you can fix everything by just writing it correctly the first time."
And this will always feel retroactively correct and never workable in practice.
Smart contracts ARE NOT CONTRACTS. Count them in the worst named things in computing.
A contract is a legal agreement that is mostly about stipulations on what to do if things go wrong.
A so-called "smart contract" is doubly bad named -- because it's just a stupid, irrevocable, unchangeable, piece of code. Imagine an ATM with the controls welded shut.
> if I am not even quite sure what exactly I want to build myself
Sounded to me like you need a plan.
My approach is to take the statement of work or problem definition and iterate on that myself until I'm really clear on what is the goal. I therefore have a good some good ideas about what the plan should be.
If extending an existing application, which is usually the case, then make use of the plan documents that I had written before AI arrived on the scene. These sre documents in markdown form that say step-by-step how to, for example, add a new report to the system.
You tell it, "let's brainstorm, don't implement anything yet". Then you talk about what you want to build and hammer out all the corner cases. Then you tell it "now do that".
My experience with that is not very good. It gets so hung up in its initial decision. Like, it won't make changes because they're "breaking", for something never even committed. Or it will litter the code base with defensive code and comments about the path not chosen.
> My experience with that is not very good. It gets so hung up in its initial decision. Like, it won't make changes because they're "breaking", for something never even committed.
This hasn't been my experience.
> Or it will litter the code base with defensive code and comments about the path not chosen.
I think their point was more: is an ESP32 more like a arduino (or any other MCU) running bare metal or some thine RTOS or more like a raspberry pi which is more like a mini computer running a full fledged Linux. And I guess the answer it kind of always sat in between a little bit and now the family kind of spreads out across this whole spectrum.
To date ESP32s have been best thought of as arduino-like things, albeit with some fancy hardware available like WiFi and Bluetooth stacks. But very much microcontroller boards where you compile firmware and push it to the board over USB.
You can actually do an awful lot of stuff with an ESP32, which often comes as a surprise to people who think you need a full Linux system just to turn a light on and off. For example Goodwe solar inverters/controllers are controlled by ESP32s and do a great job while Enphase controllers use Linux SBCs and are flaky, bug-riddled garbage.
Arduino have muddied this water now, too, as some newer ones come with a full fledged Qualcomm SOC, multiple GB of RAM, and power consumption which requires quite a beefy heatsink.
> is an ESP32 more like a arduino (or any other MCU) running bare metal or some thine RTOS or more like a raspberry pi which is more like a mini computer running a full fledged Linux
I have used fable to aid me with PCB design. It is pretty good. But it can also sometimes make very human mistakes. It mixed up RX and TX on a uart line. If you don't catch stuff like that and get assembled boards this can obviously be pretty annoying. On the other hand I have also mixed up RX and TX before, lol.
I feel like just leaving PCB routing and schematics for it is just waste of tokens.
Once you have initial design (what chips to use, what each of them needs in terms of other components etc.) the schematic/PCB isn't the hard part but it is the hard part for the AI.
It's great at stuff that humans take a lot of time like say "get me buck converters in that range of voltage in power, and put price of chip and supporting components in the table", and at least in not heavily analog designs, finding chips that fit the purpose, are available and in price range is good part of the work
Humans are incredibly good at adapting. A few days ago AI solved Navier-Stokes and I was blown away. Now I'm already thinking: "Well, it was only a counterexample and it brute-forced its way to it." lol
Sure. More precisely: they resolved the Navier-Stokes Millennium problem as posed by the Clay Institute. Not sure what else "solving Navier-Stokes" could reasonably mean. A general closed-form solution probably doesn't exist. And numerical solutions have existed for decades. But of course there are still open questions like unforced solutions etc.
I suspect EdwardDiego is referring to the brouhaha about whether OpenAI's training for the model that produced the alleged solution to the Millennium Problem about the Navier-Stokes equations was trained on material that included conversations Tristan Buckmaster and Levent Alpöge had had with earlier OpenAI systems.
I think there's a bit less to that than meets the eye. Yes, OpenAI's result builds on human work. It's possible that it builds on more human work than OpenAI admitted. But even if we suppose that everything Buckmaster and Alpöge did (which, btw, was itself very heavily LLM-assisted/generated work) was a necessary precursor to what OpenAI released, it's still the case that OpenAI's clankers completed the solution and Buckmaster and Alpöge didn't.
My understanding from what Buckmaster has written about this is that the deep mathematical ideas behind their work (and presumably OpenAI's) are due to Córdoba and Martínez-Zoroa. Those ideas are in the published literature, and human mathematicians and AI systems alike are allowed to use them, and doing so doesn't mean they didn't actually do something impressive. Mathematicians build on one another's work; that's how mathematics progresses and always has been.
It may very well be that OpenAI's announcement has a serious problem of professional ethics, especially as their first version of it didn't even list Córdoba and Martínez-Zoroa in its references. (On the specific question of what if anything they learned from B&A's work before that was published: OpenAI are now claiming that after investigating carefully they are confident that the model was not trained on anything Buckmaster and Alpöge did after early July. B&A had been working on this thing for much longer than that. However, on Buckmaster's account of things it wasn't until mid-August that they got beyond what he calls "preliminary results".)
But! The results of B&A were themselves largely AI-generated. (From Buckmaster's statement: "on August 15th, we obtained the blow up results, with smooth forcing, for both Boussinesq and Euler. I can say the first LLM generated proof Levent sent me was the most horrendous I have ever read; we verified it on Lean on August 22nd. Since this point, we have been working around the clock to understand this proof and turn it into something readable." That is: the LLMs found the proof, and B&A had to work to understand what the LLMs had done. It's not that humans did the thinking and AIs just did the gruntwork. (Except in so far as one might want to give all the credit for Real Deep Cleverness to C&MZ.)
And! What OpenAI say their model has proved goes well beyond what B&A did.
I don't see any way of slicing this that makes it unreasonable to say (unless it turns out that there's an error in the proof -- unlikely, given that it comes with Lean verification, but there have been misformalizations and Lean bugs in the past and there surely will be in the future) that AIs solved the N-S problem. No, they couldn't have done it without the work of C&MZ, but again: important mathematical work almost always builds on earlier important mathematical work, that's just how it is. Yes, if OpenAI are lying through their teeth their model might have had early access to B&A's ideas -- but it seems like most of the B&A work was actually done by AI systems anyway.
It is (I think -- I am not an expert and in particular I have not so much as looked at OpenAI's publication) reasonable to say that the deepest ideas here came from humans, and that it was already widely expected that the N-S problem would be solved in the not-impossibly-distant future in something like the way it has been. So, sure, what the AIs have done here is much less impressive than if they'd settled the Riemann Hypothesis or (probably even harder) PvNP. But it's still a resolution of a famous mathematical problem that any human mathematician would have been very proud to have achieved.
Can someone explain if i understand this correctly: Are they saying that they started training this new model on August 28th and then started using it on September 1st? Does training a new model only take 3 days?
OpenAI finished another pre-train in late August, and they are now building models off that base. He's saying the specific model OpenAI used to solve this problem is currently in post-training, which started on August 28.
Not entirely, it's just a late stage of the overall training process. It's an early checkpoint in post training (you can use the model at different stages of training), so it will probably become even stronger with more post training.
> I've heard it said that true understanding is demonstrated when someone can explain difficult concepts well.
I think this not generally. I worked together with this amazing engineer, but he really struggled to sometimes explain what he was trying to do. He came up with great solutions, but often took us some time to figure out what he was trying to get at.
Being good at a thing and explaining it well are different skills. Part of the problem is that you have to empathize with your audience when explaining. It's not sufficient to break a problem down into its essence; its "essence" varies depending on who you're talking to.
An example from something I've had to iterate on: When explaining an event loop multiprocessing runtime sort of thing, I eventually found I had to hand-wave "and your CPU hates that" to establish an appropriate premise to the problem and solution (referring to item-by-item dynamic dispatch with a large number of task types as the specific demon which needed to be slain while discussing that subset of the design). People in the know didn't need more understanding. People not in the know were happy to brush their lack of microarchitectural understanding under the rug. With that premise, both crowds were able to understand what followed.
That wasn't my first attempt. I have a bad habit of trying to explain those missing details as well, especially when it's clear the listener doesn't know them yet -- trying to get them into a position where they could've built the thing themselves -- but that only lands well with like 1-5% of people I've met.
Critically, agreeing with you, that's a communication failure, not an engineering failure. I understood the problem just as well in both cases; I just didn't understand the full extent of the people problem.
I've experienced something similar, I still think the quote works -
If you can explain difficult concepts well, it's a demonstration of true understanding. Not that poor communication demonstrates lack of it.
Oh but I think it can demonstrate the lack of it. There's a distinct difference between learning by memory and learning by understanding, and the only indicator is being able to explain it in a novel way. After all you can also memorize someone else's explanation. In practice, being able to explain it is the only actual difference, if you can't then it's the same as not understanding it and the burden of proof is on the one claiming otherwise. That's the approach upon which the world's education is generally built.
You can do things extremely well without having the foggiest about the actual underlying principles, just from observations and intuition. Doubly so if the process can be machine automated, which by this point encompasses nearly everything to some extent. Sufficiently advanced overfitting is indistinguishable from generalization.
For some tasks, this is absolutely true. We can identify e.g. a dog in picture in 100ms or so, and nobody is capable of explaining how. We can understand and speak languages, without the slightest idea of how it works. Maths is of course not comparable to these cognitive functions, but people with high levels of expertise do have a lot of their knowledge "automated", and not open to introspection.
You can also understand the very simple basic essence of something, but get lost in the complexity when scaling up.
Binary is very simple, but scaled up: look what we've created with software.
When it comes to explanation: pulling from rote memory, requires someone to attempt to hold all the short-term details in mind.
There are biological limitations to how well we can do this, but we can also exercise our brains to improve this ability.
But when something is deeply learned, in long-term memory, the effort of recall is much less than rote memory of short-term details. Our context window is limited, fills up, and we must recover. When you're remembering long-term details, context seems easier to swap in and out (sorry to sound like an LLM, but they do simulate thinking).
Whether or not someone is a master of any given domain of knowledge comes from demonstration. Maybe that is teaching the essence of a subject in a way that demonstrates you can visualize and move around the subject with ease. Or maybe you can create something very useful, or tasteful.
We accept that you have spent time in this area and probably can revral truth to us. You are credible.
If you can't demonstrate mastery through teaching, exchanging ideas to bring me closer to your level: them other forms of credentials are sought: like how well they code, or how useful their products become.
But life isn't about usefulness and will just lead to unhappiness. Just be the best version of yourself you can be. Life is too much to understand all at once.
Expert mathematicians may not be able to explain how they find a proof of a difficult mathematical statement, but once a correct proof is found, it can be, with sufficient work, be formalized (most mathematicians don't do this part). This formal proof can be mechanicaly checked, without any creativity, step-by-step according to the axioms and inference rules of a mathematical logic.
Up to the limits of the Goedels incompletness theorem.
Dependenting on the used notation the formal proof can be very long. For example, Principia Mathematica took about 300 pages to prove that 1 + 1 = 2.
It doesn't matter if you can explain it in a novel way if your novel way doesn't correspond to your listener's ability. So it is possible they can explain it in a different way but still don't know how to explain it in a way that their listener can gain understanding from it.
My sense (I could be wrong) is that once that amazing engineer really understood the class of problems (i.e. he handled it multiple times) and was really comfortable that they would in fact be able to communicate plainly about the decisions and architecture.
Being a good communicator is a skill in itself and requires understanding not only of the problem, not only of yourself, not only of the language but also of other people. And not everyone is capable in all of those at the same time.
Yeah, there's this thing called the curse of knowledge. If an engineer has a deep understanding of something, it's not a given that they can explain it well. For them, the topic feels so simple, and they've done it so many times that they may have forgotten other people aren't as knowledgeable. They will throw terms around without explaining them, etc.
