Just today, after been fascinated by this talk, I encountered my own raw loop type of problem where I had at least two for loops nested, possibly even if test inside, and I couldn't for the life of me figure out how to flatten it out. It came from my frustration with not coming up with words from the letters left in wordle. I would iterate all the letters left over two empty places in the word and form all the combinations. I just couldn't figure out an algorithm that would've done it. I wish I could've just said "ha, that's a rotate!" And even more so I couldn't figure out how to do it without first checking where the spaces were and saving their positions. I tried coming up with finds and lambdas but I just couldn't make them work for the purpose. Sure, it's a pretty straight iteration, easy to reason about, but not very satisfying. Definitely n^2 with my abilities, but is there a way?
No raw loops? I still write code after 40 years (as a professional developer of at least 1 million lines of code) and I think this statement is just plain stupid! It sounds like a religious statement spouted by a rank beginner and you certainly should know better. The only rule without exception in writing code is that all rules have valid exceptions.
Did you actually understand Sean's definition of 'raw loop'? Cause it certainly sounds like you did not. He does not say 'no loops', but that each loop should be replaced with an algorithm IF POSSIBLE. If it's NOT possible, it should be extracted to a dedicated function. It's not religion, it's progress - much like moving away from goto statements to structured programming was progress ~40 years ago.
It would be interesting to see if someone could rewrite his loop example as a 'raw loop' that is easy to understand, update, and reason about. As, his example is actually of refactoring code, it is hard to understand if his great result is from using STL algorithms to rewrite it or if it could be done just as well with a raw loop.
Just because you've been writing code for 40 years, doesnt necessarily means you've been doing it in the most optimal way. I know cooks that have been cooking for much longer than Gordon Ramsay, that doesn't make them better than Gordon Ramsay. Years is not a way to determine specialty nor experience any more. Not in this age and time. There are 25 year old programmers out there who write better code than 50 year old men, just because 50 year old men are usually used to legacy old-school code unless they practice much and refine their skills. (like the presentor seems to be doing) As Lukasz mentioned, you're arguing about progress. Progress not necessarily always but most of the time it also means change for the better. Try being more open minded. You also most likely seem to have misunderstood what "raw loop" means as well.
@@exapsy The C++ STL was created in 1992; so that makes it about 30 years old. This methodology that is being presented may not be 'new', it may be quite old. 'Progress' should not be attributed to whatever someone determines is 'new', it needs to be valued according to the needs of a particular use.
If your top bragging right about writing code is how many millions of lines of code you generate, you might be a bad programmer. But seriously, the argument is reasoned and moderate. They are saying that replacing non-trivial raw loops with refactored code tends to generate better, easier to understand code, in almost all cases. This can require some extra work. I find writing "write only code" is far easier than writing code that others have understood. And refactoring and simplification takes time, produces easier to understand code, and often results in better code. Sometimes code isn't worth being good code. Usually that is code that is actually throw away code -- like stuff I am spewing out when prototyping a problem. But the thing is if my spewed prototype code is crap, I don't practice writing better code. So I try (and don't always succeed) to write better prototype code so when I write good code, I have the "muscle memory" of writing good code, and my important code is better. And, sometimes, your problem is actually a painful pile of garbage, and you have to write ridiculously complex code to solve it. OTOH, that usually means you don't understand the problem, _or_ you need to iterate and find out that your problem isn't actually what you think it is, _or_ you found a new branch of problems in computer science that nobody has good solutions for.
not all code is readily covertible to stl algorithms. this authors presents happy go lucky cases he happened to stumble upon. more often than not real life code is highly unstructured which requires much refactoring before it can be transformed to simple algorithms.
Excellent explanation and examples. I liked how he walked through the reasoning behind his assertions.
that's a rotate!
Just today, after been fascinated by this talk, I encountered my own raw loop type of problem where I had at least two for loops nested, possibly even if test inside, and I couldn't for the life of me figure out how to flatten it out. It came from my frustration with not coming up with words from the letters left in wordle. I would iterate all the letters left over two empty places in the word and form all the combinations.
I just couldn't figure out an algorithm that would've done it. I wish I could've just said "ha, that's a rotate!" And even more so I couldn't figure out how to do it without first checking where the spaces were and saving their positions. I tried coming up with finds and lambdas but I just couldn't make them work for the purpose.
Sure, it's a pretty straight iteration, easy to reason about, but not very satisfying. Definitely n^2 with my abilities, but is there a way?
ahem what’s that again?
A rotate!
No raw loops? I still write code after 40 years (as a professional developer of at least 1 million lines of code) and I think this statement is just plain stupid! It sounds like a religious statement spouted by a rank beginner and you certainly should know better.
The only rule without exception in writing code is that all rules have valid exceptions.
Did you actually understand Sean's definition of 'raw loop'? Cause it certainly sounds like you did not. He does not say 'no loops', but that each loop should be replaced with an algorithm IF POSSIBLE. If it's NOT possible, it should be extracted to a dedicated function. It's not religion, it's progress - much like moving away from goto statements to structured programming was progress ~40 years ago.
It would be interesting to see if someone could rewrite his loop example as a 'raw loop' that is easy to understand, update, and reason about.
As, his example is actually of refactoring code, it is hard to understand if his great result is from using STL algorithms to rewrite it or if it could be done just as well with a raw loop.
Just because you've been writing code for 40 years, doesnt necessarily means you've been doing it in the most optimal way. I know cooks that have been cooking for much longer than Gordon Ramsay, that doesn't make them better than Gordon Ramsay. Years is not a way to determine specialty nor experience any more. Not in this age and time. There are 25 year old programmers out there who write better code than 50 year old men, just because 50 year old men are usually used to legacy old-school code unless they practice much and refine their skills. (like the presentor seems to be doing)
As Lukasz mentioned, you're arguing about progress. Progress not necessarily always but most of the time it also means change for the better. Try being more open minded. You also most likely seem to have misunderstood what "raw loop" means as well.
@@exapsy The C++ STL was created in 1992; so that makes it about 30 years old. This methodology that is being presented may not be 'new', it may be quite old. 'Progress' should not be attributed to whatever someone determines is 'new', it needs to be valued according to the needs of a particular use.
If your top bragging right about writing code is how many millions of lines of code you generate, you might be a bad programmer.
But seriously, the argument is reasoned and moderate. They are saying that replacing non-trivial raw loops with refactored code tends to generate better, easier to understand code, in almost all cases.
This can require some extra work. I find writing "write only code" is far easier than writing code that others have understood. And refactoring and simplification takes time, produces easier to understand code, and often results in better code.
Sometimes code isn't worth being good code. Usually that is code that is actually throw away code -- like stuff I am spewing out when prototyping a problem. But the thing is if my spewed prototype code is crap, I don't practice writing better code. So I try (and don't always succeed) to write better prototype code so when I write good code, I have the "muscle memory" of writing good code, and my important code is better.
And, sometimes, your problem is actually a painful pile of garbage, and you have to write ridiculously complex code to solve it. OTOH, that usually means you don't understand the problem, _or_ you need to iterate and find out that your problem isn't actually what you think it is, _or_ you found a new branch of problems in computer science that nobody has good solutions for.
At this point ... th-cam.com/video/W2tWOdzgXHA/w-d-xo.html ...
lock(mutex) .. .. is written .
Is lock (mutex_) .. .. intended?
wonderful content 25msr. I crushed the thumbs up on your video. Keep on up the outstanding work.
Ok?
Normally "Ok's" annoy me but Sean's talks are so good i don't even notice it.
mkay.
This talk is so old but still so damn modern! Love it!
This presentation basically show in what ways Functional Programming is superior to C-based ways of programming.
Okay.
not all code is readily covertible to stl algorithms. this authors presents happy go lucky cases he happened to stumble upon. more often than not real life code is highly unstructured which requires much refactoring before it can be transformed to simple algorithms.
So you have to refactor it
Haskell would like to know your location.