this is worth so much, pity we as a industry do so little with it. seriously.. this is the stuff that will make us real engineers, instead of code ejaculators.
@@droneborg19 This is late, but my assumption is that time limitations, low perceived value by managing entities, and lack of software engineers that actually are familiar with formal methods all contribute to it.
@@droneborg19 I think it is also because we have traditionally not needed to scale solutions up to truly global scale So we have things that for now are 'good enough', good because over time we have hashed out patterns that we now know have issues, enough to avoid them As we move to the next scale up, issues are going to creep out of the woodwork. TLA+ with it's rigor on proofs, would eliminate the trial by error (and improve) methodologies we are currently using
I'm only as far as 17:15 but this is very interesting. Really valuable. It's interesting how Leslie's experience with formal specification really shines through as most of this talk is a series of very precise statements.
Ive always wondered about the boundaries between programming and mathematical thinking, this gives me a satisfying answer, thank you. And nice costumes! :)
imagine if this man filmed all this video in one day this means that he had to change clothes in every slide, if so (deterministic 😉) it means he is a psychopath. I just wanted to watch the introduction but he go me hooked.
This is all extremely interesting, but I'm afraid it might cause a new team to overengineer a pre-product architecture. This seems to be applicable at large waterfall corporations that are ready to rearchitect an existing system using all the lessons they learnt from the first one.
People over-engineer all the time, with every existing programming language or modeling tool. So it's not a problem in the tools, it's a problem in the engineers, likely due to lack of experience (luckily, that's something that can be earned eventually). If you think a system is likely to be over-engineered *because of* the use of TLA+, that system might probably fall into the "TLA+ is not useful" category mentioned by the professor. This tool is designed mainly to model complex distributed systems, where few people can turn their heads around just by thinking. At least I'm having this problem - my brain is just too primitive to intuitively conclude that my distributed system will work as expected in every possible concurrent execution, especially on failures. I'm hoping TLA+ would help me on that.
It depends there's over engineering and there's improving. The falacy of coding is coding. There alot of thought but people don't see it. It doesn't show up on GitHub. They should have used it on cyberpunk 2077. Anything that reduces code is a good thing.
If I understand correctly the purpose of this tool, I think it does not force you to overengineer anything. You have a model how your (future) concurrent system should behave, and you use TLA+ to check what the points of failure are, if any. You may decide to fix or not to fix those. How you fix them, it's up to you, TLA+ will not dictate that. I think "overengineering" the system is something that people do (models may already be overengineered or fixes to issues TLA+ finds can be overengineered), TLA+ merely explores the paths of execution and tells us what may go wrong where.
dont want to flex but i made the most popular distributed consensus algorithm and won a turing award for it ... ok DOC we get it you are the GOAT
THE. GOAT.
this is worth so much, pity we as a industry do so little with it. seriously.. this is the stuff that will make us real engineers, instead of code ejaculators.
'code ejaculators' is the funniest, best phrase i've heard to describe MYSELF in a long time
Why is it not used? Because of time/schedule pressure?
"Code ejaculators"
Im saving that one for later use
@@droneborg19 This is late, but my assumption is that time limitations, low perceived value by managing entities, and lack of software engineers that actually are familiar with formal methods all contribute to it.
@@droneborg19
I think it is also because we have traditionally not needed to scale solutions up to truly global scale
So we have things that for now are 'good enough', good because over time we have hashed out patterns that we now know have issues, enough to avoid them
As we move to the next scale up, issues are going to creep out of the woodwork. TLA+ with it's rigor on proofs, would eliminate the trial by error (and improve) methodologies we are currently using
very special sense of humor :)
I'm only as far as 17:15 but this is very interesting. Really valuable. It's interesting how Leslie's experience with formal specification really shines through as most of this talk is a series of very precise statements.
Discovered this via a 2014 Microsoft talk :-)
Ive always wondered about the boundaries between programming and mathematical thinking, this gives me a satisfying answer, thank you. And nice costumes! :)
At least you have the right reasoning, some ppl thinks code writing its programming, and programming it’s an art form, omg lol.
I like that he kept changing clothes to kept the viewer engaged
More defi protocols need to start using this, perhaps even should hire dedicated formal verification engineers for sc development
Thank you!! Can't wait to start using TLA+. I definitely need this.
I need a state machine representing the possible next values of hat
imagine if this man filmed all this video in one day this means that he had to change clothes in every slide, if so (deterministic 😉) it means he is a psychopath. I just wanted to watch the introduction but he go me hooked.
congratulations for making to Linux foundation.
Tip on reading the AWS paper: skip the first 1.5 pages.
They should have shortened the intro to 1 sentence.
Very interesting !!! Re-thinking engineering.
This dude is, like, really smart.
He won a turing award and invented... way too many things for just a comment on youtube
thank you sir
Well atleast I don’t have to do this too, now I can focus on my emacs config!
Prof Lamport
Vrh ✊
i belong here
This is all extremely interesting, but I'm afraid it might cause a new team to overengineer a pre-product architecture. This seems to be applicable at large waterfall corporations that are ready to rearchitect an existing system using all the lessons they learnt from the first one.
People over-engineer all the time, with every existing programming language or modeling tool. So it's not a problem in the tools, it's a problem in the engineers, likely due to lack of experience (luckily, that's something that can be earned eventually). If you think a system is likely to be over-engineered *because of* the use of TLA+, that system might probably fall into the "TLA+ is not useful" category mentioned by the professor. This tool is designed mainly to model complex distributed systems, where few people can turn their heads around just by thinking. At least I'm having this problem - my brain is just too primitive to intuitively conclude that my distributed system will work as expected in every possible concurrent execution, especially on failures. I'm hoping TLA+ would help me on that.
@@baganatube : what industry are you in?
Software is riddled with bugs and wider use of TLA+ would be a huge improvement.
It depends there's over engineering and there's improving. The falacy of coding is coding. There alot of thought but people don't see it. It doesn't show up on GitHub. They should have used it on cyberpunk 2077. Anything that reduces code is a good thing.
If I understand correctly the purpose of this tool, I think it does not force you to overengineer anything. You have a model how your (future) concurrent system should behave, and you use TLA+ to check what the points of failure are, if any. You may decide to fix or not to fix those. How you fix them, it's up to you, TLA+ will not dictate that.
I think "overengineering" the system is something that people do (models may already be overengineered or fixes to issues TLA+ finds can be overengineered), TLA+ merely explores the paths of execution and tells us what may go wrong where.