Errors during development are better than errors in the wild. I know most of you out there love your dynamic languages but static analysis is the best way we have to minimize runtime errors. To use a common phrase, "You can pay me now or you can pay me later." You can have fewer errors during development or you can have fewer errors in production. Pick your poison.
Yes! Languages that try to guess my intent are not pleasant since the usually fail. I've come to appreciate compiler warnings, errors, strong typing and static_assert as a form of job security.
I remember studying a hardbound book about structured programming which made a bold claim that any program (before OOP was invented) could always be rewritten in structured form. No matter how much spaghetti code was in the program, it could be rewritten into structured form. The book turned out to be correct; that hooked me on structured programming and analysis of code design. I soon appreciated compiler optimizations that convert structured source code into optimized object code.
Not all forms of program logic lend themselves to pure structured programming forms. You end up having to replicate pieces of the logic or use runtime flags which can actually be worse than the problems they replace. I'm not saying I use gotos. It's rare. But I often write naked while(true) type loops and put one or more breaks inside the loops because it leads to less contorted logic than the standard while or do-while loops. (I almost never use the latter). A structured purist would balk at such things but 40 years of experience says it's often the right thing to do. I don't strive to write code to some "ideal" just for the sake of that ideal. I write code that best fits the logic. Clarity and fewer bugs are the goals.
The book is correct. Any provably correct program can be written as a structured program. The reverse is not true, however: a programs containing a goto is no longer provably correct. This, for me, is the biggest reason to never use one. And to be honest, I've never actually needed one ever since I graduated in 1994 (although I must admit I no longer do a lot of programming nowadays)
It's true, but that GOTO-less code can be horribly disgusting. For example, GOTO-less COBOL-74 was *painful,* but using paragraphs and GO TO to emulate "while", "for" and "do" made for quite readable code. Prefixing paragraphs with numbers was also very useful.
This claim was mentioned - and prooved - on my first ever university programming lecture. You know, the kind where they start from the very basics (in this case, C), as they don't know who has any prior experience in programming. The proof is super-simple: convert the non-structured program into a state-machine (maybe line-by-line), implement the state-machine in a structured way, and boom, you have the exact same program implemented in a structured way.
It also has been my experience unstructured code can be rewritten into a structured one: I started with unstructured programming, because I tend to default to a zoomed in view point like on the microscopic scale. So I look at coding as trying to work out how the computer does it (eg I want to know/understand what the current state of the machine is while "drawing" to the screen). So languages like Atari BASIC hooked me in because of their control flow is similar to the control float on the hardware level, but writing in an emulator had it's problems and I wasn't able to find a similar BASIC interpreter for modern Linux. Which lead me to writing more in C and all my previous projects I wrote unstructured code ported nicely to structured. While I still like to dink around with problems in unstructured, I found I really like writing my own Libraries in C building up from my own primitives. Honestly still non of these have an end goal other then filling up free time and most of these are just re-inventing the wheel, but it's just nice to know how that wheel works because you wrote it.
19:31 *Ancient compiler bugs.* I learned an important lesson when some of us younger programmers (back in the 1980s) were talking with an Old Guy about why he did _X_ on the *IBM* VS COBOL II compiler, and he said it was because of a specific compiler bug. Old Guy 2 walked up, laughed, and said that was a *Burroughs* compiler bug which had been fixed *20 years earlier.* Turns out Old Guy 2 was right...
I'm a dinosaur who started programming in FORTRAN IV on an IBM 360. I am a believer is structure that makes the code extremely readable and that means using variable names that may be 20 characters long so that is very clear what they are, and lines speed out with every curley bracket tabbed on a new line. This way you can read the code like a book and barely need any documentation. That is my inheritance of structured programming. It is certainly an improvement on the old "spaghetti programming" with go to all over the place!
@@AdrieKooijman A couple of years ago I had to recreate a very complex investment model with a dozen tabs. I had no choice but to document it in a variety of ways.
@Dušan Xmetov i am actually refering to overcommiting. Even if there is no RAM left malloc doesnt fail, only when you try to write to that memory then the system kills (almost randomly some applications).with the oom killer. Sounds crazy
I still have to use continue occasionally. We do have a lot of data-structures were you just got a container and have to do some checks on all of them before you know which of them end up getting processed. The alternatives that i mostly see is either deeply nested If-statments (> 10 levels sometimes), or copying the data around "if (check(data)) furtherProcessingContrainer.pushback(data);" As with these scenarios we often have more than 10 different conditions to check - yeah break/continue is great for that.
It is a real interesting talk. I met many code reviewers that would not like my code, like this `int f(x) { if (something) { return g(x); } else { return h(x); } }`, and ask to remove the else, and write: `int f(x) { if (something) { return g(x); } return h(x); }`, which makes it 1) unstructured, 2) non-symmetric. At least in most cases it is a bad choice, as it requires you to analyse the code fully before being able to reason about it, which is bad. However, early exit, with no else for subsequent code, is still handy, if you have a large number of checks to test, and do not want to indent your code horribly. In some situations if it is known pattern (i.e. for error handling and input validation), it is a good thing and good structure, but not for other nontrivial cases.
A bit cheeky, perhaps (and not specifically addressing your argument), but in this case I'd use the following: int f(x) { return something ? g(x) : h(x); } I think this fits both the structured and symmetric criteria, and it's less verbose as well with a single return statement. (I know it's a basic, contrived example, but.)
Any of these solutions are fine. Subjective preference is going to dominate any actual objective benefit so it's not worth wasting time on it. Especially in a simple 3-5 line function.
I would include the unnecessary else for clarity. No 'else' says "I'm exiting early depending on some condition" (e.g. a trivial case), whereas including the 'else' says "the value returned depends on some condition." There's a remote possibility someone might unintentionally add code after the first return statement that should have been placed before it. But I agree that the ternary operator would be better
@@johngimble4260 thats why i personally dont use the else when theres a single if, for me it says "if this condition is true, then do some logic and return a value, return a default value at the end if the condition wasnt true. But if the default logic is longer or there are some else ifs i would always put the else just for clarity
@@delulu6969 The only thing using dollar sign in jQuery is the jq object itself, which is not being used in this code, so it's definitely not jquery (also jquery would make zero sense in the context here as it's not reading or modifying a DOM structure but instead operating on a class). It could be JavaScript, although variables starting with $ are very rare in JS (usually reserved for framework internals). Maybe some weird framework. Agree it doesn't look like php as that one would use strtoupper() most likely. Edit: After a bit of research I think it's probably a templating language for JavaScript in which someone made an error (like forgetting to put curly braces). That's most likely where the $ comes from.
Yes. Not PHP. Not entirely sure what. Powershell uses both dollar sigils for variable names and dot notation for method calls, but has an "ToUpper()" method. (Not even sure if this is a true method in Powershell as it's not my language).
Actually on second thought, I think the dollar sigils are a red herring and the language is just Java. Due to the dot method calls, camel case names, prefixing "get" and "set" for getters and setters, and that the method "toUpperCase()"
He's quite strangely mentioning those whose mother tongue is not English in the context of "arboricide" whereas even though that word might not occur in other language, it's still made of commonly-used latin roots. Whereas an example of something entirely foreign to almost anyone of a different mother tongue, is the "Fizz Buzz" thing that he treats as if everybody knew it.
Love the subtype/supertype discussion. The definition holds in data modelling as well. If it has the same key and more attributes, it's a subtype. But still, replacing the supertype with the subtype doesn't change the behaviour of any program manipulating the supertype.
I would have to mention COBOL (dirty word). When I started programming it was all over the place. When Structured Programming came in, it was so much easier to follow. Get rid of the GOTO, use procedures and functions. It was allowed to get out of a procedure, but not to switch to another one. Can someone tell me what is wrong with this?
Nothing wrong with it. When introducing/teaching structured programing the core concept is "don't use goto". That restriction is the key to starting to think in terms of structured (non-spagetti) code. As with learning or mastering many things, there are levels of awareness. Kevlin's video is going a couple of levels up in that awareness, and depending on the program, may not always be required. The problem with goto is not that it should never be used. It's just how/when/why it is used that needs to be chosen with care. Breaking out of loops/blocks/routines of code with a goto (which is what a break/continue/return statement is... ie a controlled goto, not just arbitrarily jumping to wherever the heck I feel like) can be ok (as you mentioned). It is breaking INTO the middle of loops/blocks/routines that is not ok. (I think I got this revelation about this essence of structured programming from an Uncle Bob video). If I am writing a thousand line program that only myself and 1 other may ever see, I am not going to worry about all the higher level structured programming stuff. If it makes the program easier to code, or more readable to use a break/continue/return, then I'll do it and move on. But if I am programming a larger system, millions of lines of code, or working in a team of programmers, then the level of care I will apply will be greater. I will craft my code with higher levels of structured programming in mind. For me this is all about a desire for code readability. I am relating Kevlin's comment about code that can be reasoned with/about to code that can be read/understood (as you said "easier to follow"). So to me the answer to your question is that there is nothing wrong with what you said. Perhaps someone could argue that you might be at the brown belt level of structured programming, and this video is at the black belt level. But it is not a case of you are at the wrong level and they are at the right level.
@@PauloConstantino167 He didn't say that it made it impossible to lex or parse, but I'm guessing that it did make syntax error location attribution horrific also.
@@PauloConstantino167 Could be worse, it could let you put ASCII control codes into variable names! Technically your compiler could compile them, but good luck getting the code to display correctly onscreen... 🤣
🙏 🙏 😊 fantastic talk! one of the very few people who mentioned Michael Jackson and his JSD/JSP/Frames in a talk. he is one of my favorites of all time.
Interestingly, a very good "modern" ebook on program design (as the process of organizing development work and design elements) explicitly attributes its inspiration to Jackson's work. htdp.org/
Yeees! I agree! Why dealing with code when you are constructing a program? In JSP you can model datastreams of a program to form an architecture! When this is done and the whole construction is finished, you let the code (operations) run the program. Like a technical product, which is done on the drawing board, then you build it.
For me it's much easier to read code that has many early exits at the beginning and then stuff what it should do than reading "properly" structured function with four levels of indentation (if (thisWontFail) { if (thisWontFailNeither) { if (bufferAllocationSucceeded) { do_some_stuff_hopefully() } someCleanupCode }} return result}
But it's not the point of example. That poorly designed function is actually three different functions under one name and it's much easier to see that this is indeed true with the structure he shows.
Structured Programming is not forgotten, it is the basis of everything we do (except assembler). 1. If I am here I came from above. 2. When I am done here I will continue below. 3. I can call out, but it will return here and continue. 4. NO GOTO's Isn't that what we do today? It is for me...
I suspect that one of the reasons that PowerPoint has (or had) dependencies on Internet Explorer is that Bill or Steve made it a requirement for anti-antitrust measures.
@@cheaterman49 They have a technology for that, OLE, that avoids hard dependencies like that. For full compatibility, you would need the corresponding OLE component, but otherwise, a low-resolution fallback would be embedded in the document.
@@cheaterman49 OP is right. It's likely enough that they avoided the use of OLE for the web component at least in part order to be able to claim that they can't remove Internet Explorer, because it's a stock component of Windows that everything depends on, and there would be hard breakage. They tried to pepper embedded Internet Explorer all over the place, in the desktop, in the file manager, in the help system (replacing RTF), etc. Webkit? Well Webkit's predecessor KHTML is pretty old, and Mozilla was open sourced in 1998, but of course MS wouldn't have picked those back in the day. There was a concentrated strategic effort to make sure Internet Explorer is on every PC one way or another and try to make it the default and predominant web browser. They knew Mozilla would try to push them out by any means possible. Making people adopt their proprietary solution as a standard and make it such that any third party software would be at least somewhat incompatible was Microsoft's predominant strategy, and any actual open standards backed by open-source code would have been a threat.
@@SianaGearz Oh wow, alright, I didn't get that! So they developed a compatibility component for the appearance, but still very much forced IE as a hard dependency? That's twisted... But certainly not out of character for 90's and 00's MS.
if-else leapyear example: Sadly we are using part of the LLVM-guidelines there - no else-if after return. As you said that just makes it harder to reason about.
Makes you realize what a brilliant language COBOL II was. (The original COBOL was a bit more difficult to structure). But all the self proclaimed "experts" were very sniffy about COBOL.
Any idea how to spell the programming language at 49:35 from Conrad Susa? I hear something like "pancalcul" but google returns nothing. I wish to find some more information about it. EDIT: I found it, but that was some work. It is spelled Plankalkül (German) and it was a work from Konrad Zuse, very recommended to read its wiki and personal history (perhaps he built the first computer and higher-level language).
philosophy rich talk; im not c++ fan, but this is much wider than c++/c. i especially liked thoughts explained about top-down approach (starts at ~58:50). it is very-very true that when one invents something it generally happens from "inside" and result looks messy and ugly like Frankenstein's monster. only after refactoring (probably more than one) it obtains logical hierarchy. (i think that there's something wrong with fizz buzz here, i see two checks even in lambda c++ version)
Making things structured seems fine in these simple examples, but in reality taking this too far leads to huge nesting, "arrow shaped" code that is very ugly. Early returns, break, continue, and even the occasional goto fail become the better alternative.
Right. Value of early return is it also encourages people to refactor early, makes breaking the single responsibility rule more difficult. With elses in place there is no limit in how convoluted you can make a function while it still (rumor has) works.
Agreed. IHMO the assumption that block structure is the only thing that immediately pops out and it’s the only thing comprehensible about a function without reading it in detail, is wrong. Return statements pop out at least as much.
It was throwing me off that the text on Kevlin's 2001 slide didn't look like Gill Sans, so I checked and confirmed 2001 did use Gill Sans. It's just the slide is using maybe Century Gothic.
this is kinda bullshit though - goto really IS the best way to do error handling in C, in a lot of cases anyway - althought, not in the way he showed on the slide
Linger, Mills, and Witt How to write correct programs and know it? Structured programming is a disciplined means to achieve correctness in software programs. A program is composed of an intended function followed by steps that faithfully and correctly carry out that function. This is done through the use of zero and one predicate prime programs organized into proper programs with single entry and single exit. Reasoning about intended functions, prime programs, and proper programs form the basis for arguing proof of correctness. [Linger 79] Linger, R.C., H.D. Mills, B.I. Witt, "Structured Programming: Theory and Practice", Addison-Wesley Publishing Company, Inc., 1979, 402 pages
Minute 16:00 Electrical Engineers deserve it; Minute 18:00 Physicists cannot write Fortran. Comment: FWIW the EE's and physicists I've met write novice messy hard-to-follow code. I write this in the best possible intent, some education, training, and experience would go a long way.
My very first code for pay was to make C code written by Astronomers work. The 300 lines looked a lot like somebody tried to translate Fortran concepts into C concepts. When finished the code was just 30 lines. :-)
@@devinjones1337 Some of the first code I saw from industry was while I was in high school, code my dad brought home written by mechanical engineers. He wanted to change parameters and this code had no documentation and no comments. After looking at it for a few minutes I guessed at the parameter he was interested in, he thought so too, but he was not a programmer, I was budding at that time. ... I think the example shown in the video of a big comment block with white space is the extreme of useless noise commenting. I try to write overviews, summaries, explain why certain things are in the code, and write a short flowing description of the code. I also write separate requirements and design documents. I've worked with other programmers who have a hard time reading others's code regardless, I think it is a lack of motivation, effort, and practice. Cheers as my associates in the UK say.
Early return, break and continue are good tools when you don't want your functions to resemble a christmas tree, else is a redundant statement. also at 45:14, the realloc version with early returns and if's is clearly more readable and matches the "block-model" of the speaker even better than nested branching on his "correct" example. In the early returning one, you can read the functions designated task from the end of the function, the beginning is just handling errors and the two peculiar cases with nullptr and 0 size that he mentions. On every step it is crystal clear what is returned in which case.
Each to his own. I haven't used a continue or break statement to mess with a loop's natural termination logic for decades, and my code is so much the better for it. You missed the entire point, I think. The way you code, you have to look at the entire tree to know what will executed, because you've got those break/continue/return bombs embedded in there. Those of us who refrain from embedding control flow bombs in our xmas trees only have to look at the main skeleton, and we can ignore the rest for many purposes. _Any_ style is easy to read if it has an underlying logic, and is employed routinely enough to become idiomatic. When one chooses to eschew break/continue/return, one really don't have much choice remaining but to develop a highly consistent, idiomatic style. My xmas tress have few degrees of expressive freedom. Your trees have more degrees of expressive freedom. When you look at my trees (large footprint) with your eyes (dense with options) you get the worst of both worlds.
It is forgotten because there is a lot of shitty advice floating around about 'succinctness' or 'elegance' or 'beauty' in code that is at odds with structured programming. Trading ease of reading, refactoring, and debuggability for ease of writing and cleverness. Because people want to be code poets, rather than software engineers. What some chapter in a textbook glossed over doesn't really control the state of current thinking (and more importantly, practice) of software engineering.
I'm glad he gave a talk on Structured Programming, but his idea, in many respects, of Structured Programming is his own interpretation of Structured Programming. I'm not sure he made it past the first two chapters of Dijkstra's book, and he definitely didn't get passed the title of Dijkstra's article. Purists are always wrong. He mentions the ACM article, but didn't mention the debate that followed, nor the follow up from Dijkstra. He supports his own narrative with carefully selected examples. This is disappointing. Leave it to the English, masters of the English Language to write books that not even the English can understand. Kevlin Henney fits in this category.
So today I learned you can write a C program with GOTOs and that I kind of want to learn Fortran now because it's code kind of looks like BASIC. Was that the take away I was supposed to take from this talk?
I learned about structured programming during one Computer Science lecture in college. I didn't use until 5 years later and kept with ever since. I use a liberal version which allows for breaks in small loops, although I try to avoid these too, exception handlers because the language practically demand these, but never multiple returns, and never an unstructured use of goto, and long jumps are right out. ... I prefer to call this structured execution flow. I continued this line of reasoning to programming to state machines instead of arbitrary flags, and structured data flow.
@@theb1rd I know this is a year late, so you might not respond, but how can you tell who knows what they're talking about and who doesn't? I'm not very good at differentiating this kind of thing, so I'd be interested to hear what way you can recognize the difference
I can't help thinking that common lisp doesn't suffer any of these problems because you always have to declare the structure you're using explicitly and only certain keywords are available for that structure and they can't occur in further nested structures.
5:40 That's a day before start of the unix epoch, no? my quess is the message was generated as you posted the feedback, but was supposed to be delayed (few minutes, to maybe even few days), and scheduled to "arrive" to you then (for the UX to give subconscious impression that someone might have read it, or at least looked at it), but someone added the wrong number, so it overflown and wrapped around to a weird state which is technically an invalid value, because the platforms date system starts on unix epoch, but the value is there in the internals because it makes it more convenient to do some boundary checks like "is a valid date"... Knowing today's tech stacks, I would say that's the most possible cause.
My thought was that the message had a zero timestamp for whatever reason. Basically a modern-day uninitialized value: we’re now made to always give variables a determinate value, even if it’s still bogus. That’s zero relative to the Unix epoch in UTC. If you adjust that for a more westward (e.g. American) time zone, you end up on the previous day.
@@mtbinkdotcom oo, baby found a new toy in his browser's menu! congratulations! now go play with it so you don't disturb adults with your offtopic blabber =D
I was following just fine until the punch card program at 50 minute mark temporarily blinded my brain. I credit modern programming languages first and foremost for allowing more people to understand how to read and write computational instructions without necessarily needing an advanced math degree. Punch card era computations must have seemed like occult gibberish to most reasonably intelligent people in their time.
As a Go programmer, this is a little frustrating. I'd write this code as: ``` func IsLeapYear(year int) bool { switch { case year % 400 == 0: return true case year % 100 == 0: return false case year % 4 == 0: return true } return false } ``` Note that in Go, the `switch` statement doesn't have implicit fallthrough. I also have a problem with how he explains how binding a value as the result of the function and changing control flow are two different concepts yet Go is foolish in some way for separating the binding of values to the result of a function (e.g. named return values) and changing control flow (e.g. "naked" return).
You know the reason that everything depends on each other in Microsoft programs, right? It's blatantly obvious that they WANT those dependencies so you can't uninstall their software without it breaking the OS. It didn't USED to require iexplore.exe to run a lot of software. It USED to be more modular in some older OS's. I mean, how many times can a company willfully make a "mistake", get complaints, and then not fix it for next update before you realize it's that way on purpose.
A testing book by Shel Siegel -OO Testing etc., will explain some of that internal analysis failure stuff. Also a good old compilation is publ. Strawberry Software. Similar to your ref to writings of the rev'ln
yeah, but then you cannot have branches, or trunks, stems, etc. Gotta make up a bunch of weird subterranean language for these things. Maybe we should just call them graphs.
@@khhnator I can get peoples issues with Lisp's syntax, but the parens part of it has always seemed a bit odd to me. I mean all languages use parens to a fairly significant extent. As a hackneyed example, the max of two floors in Java is max(floor(a), floor(b)). In Lisp it's more or less (max (floor a) (floor b)). Slightly different order, but it's not really that significantly different altogether. I suppose there's the whole issue of everything is in parens, (setf x "hi") versus let/var/String x = "hi" but I personally like the consistency. The bigger issue people I've met at least seem to have is that Lisp tends to stack the closing parens at the end, which eh. The IDEs tells you when you forgot one anyway so just kinda ignore them and pay attention to tabbing convention like you do with C++, Java, Typescript, etc. Also, if you're ending up with that many parens, you probably want to decompose your function some more, same as you would for a C-family function that's got a bunch of nested ifs. To each their own. I hate some well-loved languages. The parens part always seemed like a weird sticking point when the bigger issue seems to me like it's more how different the overall syntax is to the C family.
Unlike a calling procedure a goto caused program execution to jump to another part or line of the code without returning - the issue with that is that if over-used it tended to cause what became know as spaghetti code because of the tendency to skip around in almost a seemingly haphazard way whereas better use of structured procedures and naming conventions allowed other people especially who had to maintain or troubleshoot the code to make better sense of the program logic.
@@lenfirewood4089 doesn't always though. if you can give structure to the code in other was then that helps a bit. i've written chatbots in batchfiles that used goto for basically everything. but that was in batch not c++. basically though i sectioned of chunks of function. i had a 'preprocessor' chunk that handled analyzing the users input from the 'input' chunk and deciding whether or not to even send it to the 'processor' chunk which then decide what the output would be using a bunch of if statements before sending it to the 'voice' chunk which would write a voice.vbs file and execute it and then delete voice.vbs before returning back to the 'input' chunk.
@@logangraham2956 Yes it doesn't have to result in badly structured code especially if the programming language used allows you to alias the program line to a more user friendly label that helps explain the branching reason.
@@logangraham2956 Thinking back to the days of writing DOS batch files I too remember it's use there. I even used it myself but then the batch processing language was very limited. I don't think itwas much of an issue there anyway because most batch programs were relatively short and thus would be easier to maintain.
Too much code snobbery here for me. It's possible to write tidy, *idiomatic* code in any language. Every language has its way of doing things. Some of the early languages were primitive. Get over it.
Same. Would you rather write code with perfect structure with four levels of indentation or code with many early exit points? Which one is more readable? Is it worth 45 minutes of talk? (i skipped through the video, cause it does not seem to contain anything useful)
There are too many use cases where short circuiting and goto make the code clearer and simpler than without them, that dismissing them without a strong justification is just wrong.
From what I've understood you cannot extract a block from a piece of block with the goto in there without the risk of breaking the overall program behaviour. Instead, throw it’s a mechanism where the block ”explode” and alarms the caller, which will ”explode” (throw) if it doesn’t catch. So extracting and refactoring as a new block a piece of the original block where the throw occurs, doesn’t change the overall program behaviour. If it was to throw then it will still throws, if it wasn’t, it won’t. Think about the goto as a return (just the control flow part of it, not the carried value) where you can specify where to go instead of just ”go” to the caller. Then, think about refactoring a piece of your block with a return in it in another little block called by the original one. Obviously the overall behaviour changes, because the return is now local to the new little block and ”return” ”to” the original block instead of returning ”from” the original one.
@@xybersurfer Nope, he's a bot. That exact same comment was left by two other "commenters" above (although four months ago). This is why we can't have nice things on the internet.
@@ericbwertz oh dang. thanks for informing me. i don't understand what someone would get out of this. maybe using they are using this as a training ground. i've reported it as spam
For the leapyear C code I would write : int isleap(year) int year; { int ret_val=0; if ( year % 400) ret_val = 1; else if ( year % 100) ret_val = 0; else if (year % 4 == 0) ret_val = 1; return ret_val; } I'm a true believer in the one exit point rule as it aids debugging. I don't have to guess where the program exited. I prefer to compute up and assign a return value variable and return that. or I might write : ymod4 = year % 4 == 0; ymod100 = year % 100 == 0; ymod400 = year % 400 == 0;
Seems his idea for "structured programming" is simply reworking the function to always reach the end brace. This level of thinking divides functions up into understandable parts, but it also creates something like YandereDev.....which is horrible.....so don't do this. Functions should have only a very select set of jobs and fit on a single sheet, then you would know what the function is doing and can refactor it with ease. . Also, I can program fortran, not sure what he means that there are no fortran programmers, unless he's talking about "for profit," but that's obvious. There's no punchcard programmers, if that's the case.....yet I can do those too.
I'm not sure I can follow the huge leap of logic from "function always reach the end brace" to "YandereDev-levels of spaghetti code". The reason YandereDev has such bad code etiquette is because he does not think in terms of composition of code, and ends up having to write everything by hand, in one big function on the main game loop. The structured style he's talking about still favors extracting and naming blocks of code with semantic meaning and/or with multiple usage, it still works best with an understanding of the layers of abstraction and hierarchy of the code.
@@SolarLiner ....what I mean by "reach the end brace" is to "not return early"....but that's poor programming practice. If you can leave the function, then do it as soon as possible, don't wait until the end to decide if a return is necessary or an error needs to be thrown just to separate error checks from valid value returns. Instead of writing a function like this: bool load_file(string filename) { if(file f = file_open(filename, "b+")) { //load everything, 100 lines of code f.close(); return true; } else { return false; } I would do it like this: bool load_file(string filename) { if(!file f = file_open(filename, "b+")) return false; load_file_secure(f); f.close(); return true; } void load_file_secure(file f) { //specific lines of code } This is just a crude example and many facets are not highlighted, but the basic gist is to exit as soon as possible, so that you are not indented "like yandere" does with if/elseif structuring. It also gives you the ability to refactor specific subcode without endangering the project.....for example, the "load_file_secure" pseudocode above can take any previously allocated file stream and use it as access to load, so if your file is RAM-drived or accessed in another way entirely, you can refactor the "load_file" code to handle the allocation of the stream and just pass the "file" to the secure part. Simple in, simple out....the compiler will do most of the work in compressing down use-once code and function calls anyway, so you are not losing run speed at all, and you gain readability and refactor ability. Though I only vaguely remember ever commenting on this video, so this is all just a guess on what the hell was even going through my mind at the time....been busy doing a dozen other things, sorry.
@@sabriath Right expect this does not change code generation, and so boils down to personal preference. I write a lot of Rust code where keeping the if/else is idiomatic, so by simple muscle memory I also do it in other languages.
If you want to see REALLY bad code, find a data scientist. Worse still, a data science tutorial. Embarrassing lack of good software development practices.
I can imagine them often generating 'wild' code to only run a few times, like searching a pattern or do a conversion. I have recently done this to tear apart a undocumented data stream.
@@manuell3505 You're only scratching the surface there. Data scientists love Jupyter notebooks, which enable the sort of workflow where cells run in indeterminate order and as a result cells often hold the results of an inscrutable set of transformations. Whoever thought python was a good fit for the notebook model has no idea how to use Mathematica properly.
@@isodoubIet You have no idea what you're talking about. Get out of your own small world... I don't think anybody who intensively uses computers 'loves' certain notebooks. Those things kill your typing rate. And what's with the cells? Like all data science involves distributed grid computing or such....
@@manuell3505 I think it's pretty much an objective fact that data scientists intensively use Jupyter notebooks, and I think it's as close to an objective fact as possible that they promote absolutely terrible development practices. I have no idea what it is you're disagreeing with.
43:04 I don't like how C++ makes it so easy to find the longest way to do the simplest thing. If you don't want to do the same check twice, first create your string object. If your number is divisible by 3, append "Fizz", then if it's divisible by 5, append "Buzz", then return the string. This method doesn't require rechecking any conditions. Short, simple, to the point, and not unnecessarily convoluted or confusing to read.
No, he is wrong. And the reason is that the examples are too simple. Sticking to pure structured programming as he defines it has the critical problem of being unable to filter inputs and only access the body of a function if the inputs are valid. Input validation and/or normalization should always come at the top of a function and use return statements to exit before the body of the function actually starts if anything is wrong about the inputs. The result is always less, more correct code in real-world usage. Less code is generally more readable and correct code is functionally stable. And, as everyone knows, readable code is maintainable code. His approach, strictly applied, results in less-readable, less-maintainable code where real-world code can easily wind up in a situation where everything is nested and the main body of the code is way off the edge of the screen due to indentation OR explodes into a zillion little functions that each need their own input validation. In either case, the code is far less readable. Also, structured programming is generally wrong because it ignores better solutions to software engineering problems. For example, state engines regularly violate structured programming concepts even though state engines are the most correct way to write software. If you aren't writing state engines, then you are, with the exception of extremely trivial programs, doing it wrong. Yup, everyone's been writing software incorrectly for the last 50 years.
Thank you. All attempts I’ve seen to avoid the oh-so-evil guard clauses end up resulting in horrendous, unreadable code once you go beyond trivial examples. I just cannot imagine what religious believers in the one-return rule are thinking. Since when is: - more mutable state - more code to verify - more indentation OR - more jumping around code to see trivial 2-line functions “better” for code style? Never, as far as I’ve seen, unless you are writing something extremely simple. Use guard clauses and move on
people are just slapping code in big ball of mud, back in the days they called it structural programming, then OOP, now functional, but the ultimate result is still the same: a big ball of mud
Back in the days there was no big balls of mud. Code had to fit on floppy drive and program had to fit into few memory segments. But from what I've seen, code from 90s usually sucks more than modern code. Variables named a,b,c,i,j,k,m,n,p,q, no comments, serialization done by write(&data, sizeof(data)) etc.
![Debug C++ Without Running - Anastasiia Kazakova [C++ on Sea 2019]](http://i.ytimg.com/vi/ByG6nIm6U24/mqdefault.jpg)
![Debug C++ Without Running - Anastasiia Kazakova [C++ on Sea 2019]](/img/tr.png)
![KEYNOTE: What Everyone Should Know About How Amazing Compilers Are - Matt Godbolt [C++ on Sea 2019]](/img/n.gif)
"In failure, software reveals its structure" This is fucking brilliant. I'm stealing that quote.
Errors during development are better than errors in the wild. I know most of you out there love your dynamic languages but static analysis is the best way we have to minimize runtime errors. To use a common phrase, "You can pay me now or you can pay me later." You can have fewer errors during development or you can have fewer errors in production. Pick your poison.
Yes! Languages that try to guess my intent are not pleasant since the usually fail. I've come to appreciate compiler warnings, errors, strong typing and static_assert as a form of job security.
That’s why Typescript > JavaScript
There is no poison - it is static types all the way
typescript lies
I remember studying a hardbound book about structured programming which made a bold claim that any program (before OOP was invented) could always be rewritten in structured form.
No matter how much spaghetti code was in the program, it could be rewritten into structured form.
The book turned out to be correct; that hooked me on structured programming and analysis of code design.
I soon appreciated compiler optimizations that convert structured source code into optimized object code.
Not all forms of program logic lend themselves to pure structured programming forms. You end up having to replicate pieces of the logic or use runtime flags which can actually be worse than the problems they replace. I'm not saying I use gotos. It's rare. But I often write naked while(true) type loops and put one or more breaks inside the loops because it leads to less contorted logic than the standard while or do-while loops. (I almost never use the latter). A structured purist would balk at such things but 40 years of experience says it's often the right thing to do. I don't strive to write code to some "ideal" just for the sake of that ideal. I write code that best fits the logic. Clarity and fewer bugs are the goals.
The book is correct. Any provably correct program can be written as a structured program. The reverse is not true, however: a programs containing a goto is no longer provably correct. This, for me, is the biggest reason to never use one. And to be honest, I've never actually needed one ever since I graduated in 1994 (although I must admit I no longer do a lot of programming nowadays)
It's true, but that GOTO-less code can be horribly disgusting. For example, GOTO-less COBOL-74 was *painful,* but using paragraphs and GO TO to emulate "while", "for" and "do" made for quite readable code.
Prefixing paragraphs with numbers was also very useful.
This claim was mentioned - and prooved - on my first ever university programming lecture. You know, the kind where they start from the very basics (in this case, C), as they don't know who has any prior experience in programming.
The proof is super-simple: convert the non-structured program into a state-machine (maybe line-by-line), implement the state-machine in a structured way, and boom, you have the exact same program implemented in a structured way.
It also has been my experience unstructured code can be rewritten into a structured one:
I started with unstructured programming, because I tend to default to a zoomed in view point like on the microscopic scale. So I look at coding as trying to work out how the computer does it (eg I want to know/understand what the current state of the machine is while "drawing" to the screen). So languages like Atari BASIC hooked me in because of their control flow is similar to the control float on the hardware level, but writing in an emulator had it's problems and I wasn't able to find a similar BASIC interpreter for modern Linux. Which lead me to writing more in C and all my previous projects I wrote unstructured code ported nicely to structured. While I still like to dink around with problems in unstructured, I found I really like writing my own Libraries in C building up from my own primitives. Honestly still non of these have an end goal other then filling up free time and most of these are just re-inventing the wheel, but it's just nice to know how that wheel works because you wrote it.
The end of this talk started to become the most interesting, i'd love to see more talks about concepts of coordination + computation.
19:31 *Ancient compiler bugs.* I learned an important lesson when some of us younger programmers (back in the 1980s) were talking with an Old Guy about why he did _X_ on the *IBM* VS COBOL II compiler, and he said it was because of a specific compiler bug. Old Guy 2 walked up, laughed, and said that was a *Burroughs* compiler bug which had been fixed *20 years earlier.* Turns out Old Guy 2 was right...
I'm a dinosaur who started programming in FORTRAN IV on an IBM 360. I am a believer is structure that makes the code extremely readable and that means using variable names that may be 20 characters long so that is very clear what they are, and lines speed out with every curley bracket tabbed on a new line. This way you can read the code like a book and barely need any documentation. That is my inheritance of structured programming. It is certainly an improvement on the old "spaghetti programming" with go to all over the place!
Most companies are running on undocumented, uncommented spaghetti code.
to be fair to them they are not running as they are crawling
oh there are plenty of comments, mostly by chef boyardee
Documenting excel sheets doesn't really help.
@@AdrieKooijman A couple of years ago I had to recreate a very complex investment model with a dozen tabs. I had no choice but to document it in a variety of ways.
They don’t pay enough to document the code :p
I didn't know somebody shared my hobby! I have been fotographing those screens for 15 years :)
He uses a laser pointed to point at parts of code, but we can't see what he's pointing at.
@45:54 there is a bug in realloc(). It should return null if the call to malloc failed.
It does since it returns whatever malloc returns. :)
in the right system (linux), malloc never fails.
@@andik70 malloc() will fail if new_size is too large. Even in linux.
@Dušan Xmetov i am actually refering to overcommiting. Even if there is no RAM left malloc doesnt fail, only when you try to write to that memory then the system kills (almost randomly some applications).with the oom killer. Sounds crazy
I still have to use continue occasionally. We do have a lot of data-structures were you just got a container and have to do some checks on all of them before you know which of them end up getting processed. The alternatives that i mostly see is either deeply nested If-statments (> 10 levels sometimes),
or copying the data around "if (check(data)) furtherProcessingContrainer.pushback(data);"
As with these scenarios we often have more than 10 different conditions to check - yeah break/continue is great for that.
It is a real interesting talk. I met many code reviewers that would not like my code, like this `int f(x) { if (something) { return g(x); } else { return h(x); } }`, and ask to remove the else, and write: `int f(x) { if (something) { return g(x); } return h(x); }`, which makes it 1) unstructured, 2) non-symmetric. At least in most cases it is a bad choice, as it requires you to analyse the code fully before being able to reason about it, which is bad. However, early exit, with no else for subsequent code, is still handy, if you have a large number of checks to test, and do not want to indent your code horribly. In some situations if it is known pattern (i.e. for error handling and input validation), it is a good thing and good structure, but not for other nontrivial cases.
A bit cheeky, perhaps (and not specifically addressing your argument), but in this case I'd use the following:
int f(x) {
return something
? g(x)
: h(x);
}
I think this fits both the structured and symmetric criteria, and it's less verbose as well with a single return statement. (I know it's a basic, contrived example, but.)
for me its just a bit shorter and looks cleaner, so i dont see why i would want the else in that case
Any of these solutions are fine. Subjective preference is going to dominate any actual objective benefit so it's not worth wasting time on it. Especially in a simple 3-5 line function.
I would include the unnecessary else for clarity. No 'else' says "I'm exiting early depending on some condition" (e.g. a trivial case), whereas including the 'else' says "the value returned depends on some condition." There's a remote possibility someone might unintentionally add code after the first return statement that should have been placed before it. But I agree that the ternary operator would be better
@@johngimble4260 thats why i personally dont use the else when theres a single if, for me it says "if this condition is true, then do some logic and return a value, return a default value at the end if the condition wasnt true.
But if the default logic is longer or there are some else ifs i would always put the else just for clarity
"reasons why viewers quit watching YT presentation videos: presenters trying to be 'entertainers' instead of presenting the subject matter"
Another awesome talk by Kevlin!
4:30 Pretty sure that's not PHP. Would be valid JavaScript which also has String.toUpperCase(), so that's my guess.
You're right. In PHP it would be `$retAdd->getFirstName()`
I think that's jQuery to be exact. Dollar sign, camel case, & dot notation.
@@delulu6969 The only thing using dollar sign in jQuery is the jq object itself, which is not being used in this code, so it's definitely not jquery (also jquery would make zero sense in the context here as it's not reading or modifying a DOM structure but instead operating on a class). It could be JavaScript, although variables starting with $ are very rare in JS (usually reserved for framework internals). Maybe some weird framework. Agree it doesn't look like php as that one would use strtoupper() most likely.
Edit: After a bit of research I think it's probably a templating language for JavaScript in which someone made an error (like forgetting to put curly braces). That's most likely where the $ comes from.
Yes. Not PHP. Not entirely sure what. Powershell uses both dollar sigils for variable names and dot notation for method calls, but has an "ToUpper()" method. (Not even sure if this is a true method in Powershell as it's not my language).
Actually on second thought, I think the dollar sigils are a red herring and the language is just Java. Due to the dot method calls, camel case names, prefixing "get" and "set" for getters and setters, and that the method "toUpperCase()"
07:32 Robert Floyd, 1971, paradigm 08:27 goto 08:49 Dijkstra 11:00 niklaus wirth, pascal 11:40 goto fail 15:18
4:45 That screen in Bologna isn't a blue screen, but the regular information set out for passengers.
He's quite strangely mentioning those whose mother tongue is not English in the context of "arboricide" whereas even though that word might not occur in other language, it's still made of commonly-used latin roots. Whereas an example of something entirely foreign to almost anyone of a different mother tongue, is the "Fizz Buzz" thing that he treats as if everybody knew it.
Imagine watching niche programming talks and not knowing what fizz buzz is. You’d have to imagine because it’s never happened.
I'm 13 minutes in and I can already tell this is an amazing talk, exceptionally well delivered.
Why the clickbait (and untrue) title then?
Love the subtype/supertype discussion. The definition holds in data modelling as well. If it has the same key and more attributes, it's a subtype. But still, replacing the supertype with the subtype doesn't change the behaviour of any program manipulating the supertype.
I would have to mention COBOL (dirty word). When I started programming it was all over the place. When Structured Programming came in, it was so much easier to follow. Get rid of the GOTO, use procedures and functions. It was allowed to get out of a procedure, but not to switch to another one. Can someone tell me what is wrong with this?
Nothing wrong with it. When introducing/teaching structured programing the core concept is "don't use goto". That restriction is the key to starting to think in terms of structured (non-spagetti) code. As with learning or mastering many things, there are levels of awareness. Kevlin's video is going a couple of levels up in that awareness, and depending on the program, may not always be required. The problem with goto is not that it should never be used. It's just how/when/why it is used that needs to be chosen with care. Breaking out of loops/blocks/routines of code with a goto (which is what a break/continue/return statement is... ie a controlled goto, not just arbitrarily jumping to wherever the heck I feel like) can be ok (as you mentioned). It is breaking INTO the middle of loops/blocks/routines that is not ok. (I think I got this revelation about this essence of structured programming from an Uncle Bob video). If I am writing a thousand line program that only myself and 1 other may ever see, I am not going to worry about all the higher level structured programming stuff. If it makes the program easier to code, or more readable to use a break/continue/return, then I'll do it and move on. But if I am programming a larger system, millions of lines of code, or working in a team of programmers, then the level of care I will apply will be greater. I will craft my code with higher levels of structured programming in mind. For me this is all about a desire for code readability. I am relating Kevlin's comment about code that can be reasoned with/about to code that can be read/understood (as you said "easier to follow"). So to me the answer to your question is that there is nothing wrong with what you said. Perhaps someone could argue that you might be at the brown belt level of structured programming, and this video is at the black belt level. But it is not a case of you are at the wrong level and they are at the right level.
Names containing spaces in Algol68 is possibly the most horrific thing I've ever seen.
Space is ASCII code 20h bruh
@@PauloConstantino167 He didn't say that it made it impossible to lex or parse, but I'm guessing that it did make syntax error location attribution horrific also.
I can beat that. In PL/I IF IF = THEN THEN THEN = ELSE ELSE THEN = IF ;
@@ChasRMartin WTF!?! You mean PL/I lets you use command words as variables? (I was gonna say reserved words, but in that case they obviously aren't!)
@@PauloConstantino167 Could be worse, it could let you put ASCII control codes into variable names! Technically your compiler could compile them, but good luck getting the code to display correctly onscreen... 🤣
🙏 🙏 😊
fantastic talk! one of the very few people who mentioned Michael Jackson and his JSD/JSP/Frames in a talk. he is one of my favorites of all time.
Interestingly, a very good "modern" ebook on program design (as the process of organizing development work and design elements) explicitly attributes its inspiration to Jackson's work. htdp.org/
Yeees! I agree! Why dealing with code when you are constructing a program? In JSP you can model datastreams of a program to form an architecture! When this is done and the whole construction is finished, you let the code (operations) run the program.
Like a technical product, which is done on the drawing board, then you build it.
For me it's much easier to read code that has many early exits at the beginning and then stuff what it should do than reading "properly" structured function with four levels of indentation (if (thisWontFail) { if (thisWontFailNeither) { if (bufferAllocationSucceeded) { do_some_stuff_hopefully() } someCleanupCode }} return result}
It's spelled "poorly", not "properly".
Completely agree. Also, isolating trivial code paths this way often reveals more opportunities for simplification.
Another point, the early return/continue "flat" style is much more robust to merging.
But it's not the point of example. That poorly designed function is actually three different functions under one name and it's much easier to see that this is indeed true with the structure he shows.
When I notice the need for validation in a function body, this is a clear indicator to me that validation belongs one level above in the call stack.
Structured Programming is not forgotten, it is the basis of everything we do (except assembler).
1. If I am here I came from above.
2. When I am done here I will continue below.
3. I can call out, but it will return here and continue.
4. NO GOTO's
Isn't that what we do today? It is for me...
I suspect that one of the reasons that PowerPoint has (or had) dependencies on Internet Explorer is that Bill or Steve made it a requirement for anti-antitrust measures.
What about, y'know, displaying web contents in your slides? It's not like they had WebKit back in the day, haha.
@@cheaterman49 They have a technology for that, OLE, that avoids hard dependencies like that. For full compatibility, you would need the corresponding OLE component, but otherwise, a low-resolution fallback would be embedded in the document.
@@SianaGearz The mere existence of this technology also seems to go against OP, hehe :-) good info!
@@cheaterman49 OP is right. It's likely enough that they avoided the use of OLE for the web component at least in part order to be able to claim that they can't remove Internet Explorer, because it's a stock component of Windows that everything depends on, and there would be hard breakage. They tried to pepper embedded Internet Explorer all over the place, in the desktop, in the file manager, in the help system (replacing RTF), etc.
Webkit? Well Webkit's predecessor KHTML is pretty old, and Mozilla was open sourced in 1998, but of course MS wouldn't have picked those back in the day. There was a concentrated strategic effort to make sure Internet Explorer is on every PC one way or another and try to make it the default and predominant web browser. They knew Mozilla would try to push them out by any means possible. Making people adopt their proprietary solution as a standard and make it such that any third party software would be at least somewhat incompatible was Microsoft's predominant strategy, and any actual open standards backed by open-source code would have been a threat.
@@SianaGearz Oh wow, alright, I didn't get that! So they developed a compatibility component for the appearance, but still very much forced IE as a hard dependency? That's twisted... But certainly not out of character for 90's and 00's MS.
"You've got long builds at work" - I'm watching these while stuff builds.
if-else leapyear example:
Sadly we are using part of the LLVM-guidelines there - no else-if after return. As you said that just makes it harder to reason about.
Makes you realize what a brilliant language COBOL II was. (The original COBOL was a bit more difficult to structure). But all the self proclaimed "experts" were very sniffy about COBOL.
Any idea how to spell the programming language at 49:35 from Conrad Susa? I hear something like "pancalcul" but google returns nothing. I wish to find some more information about it.
EDIT: I found it, but that was some work. It is spelled Plankalkül (German) and it was a work from Konrad Zuse, very recommended to read its wiki and personal history (perhaps he built the first computer and higher-level language).
This talk has no structure
@Sebaka & Co. *Structure is in the eye of beer holder
Elementary my dear flotsam. :)
philosophy rich talk; im not c++ fan, but this is much wider than c++/c.
i especially liked thoughts explained about top-down approach (starts at ~58:50). it is very-very true that when one invents something it generally happens from "inside" and result looks messy and ugly like Frankenstein's monster. only after refactoring (probably more than one) it obtains logical hierarchy.
(i think that there's something wrong with fizz buzz here, i see two checks even in lambda c++ version)
Making things structured seems fine in these simple examples, but in reality taking this too far leads to huge nesting, "arrow shaped" code that is very ugly. Early returns, break, continue, and even the occasional goto fail become the better alternative.
Refactor into methods...you may also find objects hidden in there.
Right. Value of early return is it also encourages people to refactor early, makes breaking the single responsibility rule more difficult. With elses in place there is no limit in how convoluted you can make a function while it still (rumor has) works.
Agreed. IHMO the assumption that block structure is the only thing that immediately pops out and it’s the only thing comprehensible about a function without reading it in detail, is wrong. Return statements pop out at least as much.
great presentation
😄 The slide at 10:26 aged well: "X is the new Y", or "These aren't the Xs you're looking for".
It was throwing me off that the text on Kevlin's 2001 slide didn't look like Gill Sans, so I checked and confirmed 2001 did use Gill Sans. It's just the slide is using maybe Century Gothic.
5:22 is now my background picture
this is kinda bullshit though - goto really IS the best way to do error handling in C, in a lot of cases anyway - althought, not in the way he showed on the slide
100% , don’t say that tool is bad if you can’t use it properly.
Linger, Mills, and Witt
How to write correct programs and know it? Structured programming is a disciplined means to achieve correctness in software programs. A program is composed of an intended function followed by steps that faithfully and correctly carry out that function. This is done through the use of zero and one predicate prime programs organized into proper programs with single entry and single exit. Reasoning about intended functions, prime programs, and proper programs form the basis for arguing proof of correctness.
[Linger 79] Linger, R.C., H.D. Mills, B.I. Witt, "Structured Programming: Theory and Practice", Addison-Wesley Publishing Company, Inc., 1979, 402 pages
Minute 16:00 Electrical Engineers deserve it; Minute 18:00 Physicists cannot write Fortran.
Comment: FWIW the EE's and physicists I've met write novice messy hard-to-follow code. I write this in the best possible intent, some education, training, and experience would go a long way.
My very first code for pay was to make C code written by Astronomers work. The 300 lines looked a lot like somebody tried to translate Fortran concepts into C concepts. When finished the code was just 30 lines. :-)
@@devinjones1337 Some of the first code I saw from industry was while I was in high school, code my dad brought home written by mechanical engineers. He wanted to change parameters and this code had no documentation and no comments. After looking at it for a few minutes I guessed at the parameter he was interested in, he thought so too, but he was not a programmer, I was budding at that time. ... I think the example shown in the video of a big comment block with white space is the extreme of useless noise commenting. I try to write overviews, summaries, explain why certain things are in the code, and write a short flowing description of the code. I also write separate requirements and design documents. I've worked with other programmers who have a hard time reading others's code regardless, I think it is a lack of motivation, effort, and practice.
Cheers as my associates in the UK say.
Learned Structured Programming with Pascal in the 1990 before OOP took off!
Early return, break and continue are good tools when you don't want your functions to resemble a christmas tree, else is a redundant statement.
also at 45:14, the realloc version with early returns and if's is clearly more readable and matches the "block-model" of the speaker even better than nested branching on his "correct" example. In the early returning one, you can read the functions designated task from the end of the function, the beginning is just handling errors and the two peculiar cases with nullptr and 0 size that he mentions. On every step it is crystal clear what is returned in which case.
Each to his own. I haven't used a continue or break statement to mess with a loop's natural termination logic for decades, and my code is so much the better for it. You missed the entire point, I think. The way you code, you have to look at the entire tree to know what will executed, because you've got those break/continue/return bombs embedded in there. Those of us who refrain from embedding control flow bombs in our xmas trees only have to look at the main skeleton, and we can ignore the rest for many purposes. _Any_ style is easy to read if it has an underlying logic, and is employed routinely enough to become idiomatic. When one chooses to eschew break/continue/return, one really don't have much choice remaining but to develop a highly consistent, idiomatic style. My xmas tress have few degrees of expressive freedom. Your trees have more degrees of expressive freedom. When you look at my trees (large footprint) with your eyes (dense with options) you get the worst of both worlds.
Fun stuff! Horrible thought that people actually had to mess with some of this chaos before languages advanced.
I don't understand: what Kevlin is describing seems like exactly what I was taught in school. What about this philosophy has been "forgotten", then?
It is forgotten because there is a lot of shitty advice floating around about 'succinctness' or 'elegance' or 'beauty' in code that is at odds with structured programming. Trading ease of reading, refactoring, and debuggability for ease of writing and cleverness. Because people want to be code poets, rather than software engineers. What some chapter in a textbook glossed over doesn't really control the state of current thinking (and more importantly, practice) of software engineering.
44:32 this code would not compile:
"void *ptr_ptr = malloc(new_size);" should presumably be "void *ptr_new = ...".
I'm glad he gave a talk on Structured Programming, but his idea, in many respects, of Structured Programming is his own interpretation of Structured Programming. I'm not sure he made it past the first two chapters of Dijkstra's book, and he definitely didn't get passed the title of Dijkstra's article. Purists are always wrong. He mentions the ACM article, but didn't mention the debate that followed, nor the follow up from Dijkstra.
He supports his own narrative with carefully selected examples. This is disappointing. Leave it to the English, masters of the English Language to write books that not even the English can understand. Kevlin Henney fits in this category.
By pascal's pipe! This was enlightening.
So today I learned you can write a C program with GOTOs and that I kind of want to learn Fortran now because it's code kind of looks like BASIC. Was that the take away I was supposed to take from this talk?
I didn't know that Zuse was in the Fregeian tradition of inventing interesting ideas that played hell with typesetters!
Ok...lets call him Zeus for simplicity :D
1:00:40 I always imagine an onion with layers, the core is where the hardware is, the abstractions are layers around it.
I learned about structured programming during one Computer Science lecture in college. I didn't use until 5 years later and kept with ever since. I use a liberal version which allows for breaks in small loops, although I try to avoid these too, exception handlers because the language practically demand these, but never multiple returns, and never an unstructured use of goto, and long jumps are right out. ... I prefer to call this structured execution flow. I continued this line of reasoning to programming to state machines instead of arbitrary flags, and structured data flow.
This reminds me of Casey's compression-oriented programming/design.
thanks for the ref
Except Casey actually knows what he's talking about.
@@theb1rd I know this is a year late, so you might not respond, but how can you tell who knows what they're talking about and who doesn't? I'm not very good at differentiating this kind of thing, so I'd be interested to hear what way you can recognize the difference
12:00 yep, that 2nd-to-last one really did make that whole page a "fail" video :P
I've seen quite a bit of Martin Fowler inspired refactored code that makes liberal use of continue.
I can't help thinking that common lisp doesn't suffer any of these problems because you always have to declare the structure you're using explicitly and only certain keywords are available for that structure and they can't occur in further nested structures.
5:45 : 12/31/1970 is one day before the Unix Epoch. So Facebook is _really_ fast with their response...
It might be -1 interpreted as a date, or it might be 0 as a date viewed from a negative timezone (e.g. the USA)
Very, very interesting talk.
Hold on, I need google what is Structured Programming first
It's a new thing, may be a couple years old. Some say it was created by google.
5:40 That's a day before start of the unix epoch, no? my quess is the message was generated as you posted the feedback, but was supposed to be delayed (few minutes, to maybe even few days), and scheduled to "arrive" to you then (for the UX to give subconscious impression that someone might have read it, or at least looked at it), but someone added the wrong number, so it overflown and wrapped around to a weird state which is technically an invalid value, because the platforms date system starts on unix epoch, but the value is there in the internals because it makes it more convenient to do some boundary checks like "is a valid date"...
Knowing today's tech stacks, I would say that's the most possible cause.
My thought was that the message had a zero timestamp for whatever reason. Basically a modern-day uninitialized value: we’re now made to always give variables a determinate value, even if it’s still bogus. That’s zero relative to the Unix epoch in UTC. If you adjust that for a more westward (e.g. American) time zone, you end up on the previous day.
Inspect HTML
@@EllipticGeometry oh, yeah, that makes much more sense
@@mtbinkdotcom oo, baby found a new toy in his browser's menu! congratulations! now go play with it so you don't disturb adults with your offtopic blabber =D
@@MidnightStI think he was kidding
I was following just fine until the punch card program at 50 minute mark temporarily blinded my brain. I credit modern programming languages first and foremost for allowing more people to understand how to read and write computational instructions without necessarily needing an advanced math degree. Punch card era computations must have seemed like occult gibberish to most reasonably intelligent people in their time.
Zuse’s Plankalkül was before punch card programming.
A Visual Studio license for 5883516 years? I don't think it will be usable in 50 years, wow. Maybe for writing retro code in an emulator...
With how long it takes to open an average project today, and it's not exactly been getting faster, i doubt it will be usable in 5.
I solved FizzBuzz using the "accumulator" approach, and thought I was being rather clever... I'm not sure what this reveals about me as a programmer?
what about gosub
As a Go programmer, this is a little frustrating. I'd write this code as:
```
func IsLeapYear(year int) bool {
switch {
case year % 400 == 0:
return true
case year % 100 == 0:
return false
case year % 4 == 0:
return true
}
return false
}
```
Note that in Go, the `switch` statement doesn't have implicit fallthrough.
I also have a problem with how he explains how binding a value as the result of the function and changing control flow are two different concepts yet Go is foolish in some way for separating the binding of values to the result of a function (e.g. named return values) and changing control flow (e.g. "naked" return).
I have no idea what this man is talking about but I enjoyed the talk.
You know the reason that everything depends on each other in Microsoft programs, right? It's blatantly obvious that they WANT those dependencies so you can't uninstall their software without it breaking the OS. It didn't USED to require iexplore.exe to run a lot of software. It USED to be more modular in some older OS's. I mean, how many times can a company willfully make a "mistake", get complaints, and then not fix it for next update before you realize it's that way on purpose.
A testing book by Shel Siegel -OO Testing etc., will explain some of that internal analysis failure stuff. Also a good old compilation is publ. Strawberry Software. Similar to your ref to writings of the rev'ln
Turtles all the way down? I'm for it.
Buy your new Untel Zombie Arisen cpu here! Does over fifty megaturtles! Sounds cool enough.
For accuracy, it might be more correct to talk about root systems than about trees, but trees are nicer.
Or you could just draw the damn trees with the leaves up. It's just an analogy anyway, it doesn't matter which way they go.
yeah, but then you cannot have branches, or trunks, stems, etc. Gotta make up a bunch of weird subterranean language for these things.
Maybe we should just call them graphs.
Lisp s-expression syntax solves this problem
but at what cost?!?!
@@nullvoidpointer the cost is fricking using LISP!!
@@khhnator I believe you've mixed up the terms cost and payoff :P
@@andrewrobie620 parenthesis people!! shoo shoo!
@@khhnator I can get peoples issues with Lisp's syntax, but the parens part of it has always seemed a bit odd to me. I mean all languages use parens to a fairly significant extent. As a hackneyed example, the max of two floors in Java is max(floor(a), floor(b)). In Lisp it's more or less (max (floor a) (floor b)). Slightly different order, but it's not really that significantly different altogether. I suppose there's the whole issue of everything is in parens, (setf x "hi") versus let/var/String x = "hi" but I personally like the consistency. The bigger issue people I've met at least seem to have is that Lisp tends to stack the closing parens at the end, which eh. The IDEs tells you when you forgot one anyway so just kinda ignore them and pay attention to tabbing convention like you do with C++, Java, Typescript, etc. Also, if you're ending up with that many parens, you probably want to decompose your function some more, same as you would for a C-family function that's got a bunch of nested ifs.
To each their own. I hate some well-loved languages. The parens part always seemed like a weird sticking point when the bigger issue seems to me like it's more how different the overall syntax is to the C family.
In my experience electrical engineers understand demorgan transformations better than software engineers.
What was censored at 6:56???
It was an image that was thought to have been in the public domain, but turned out to be copyrighted
@@philnash1121 The Eiffel intellectual property dependency hell?
Hard crowd! Not even a single chuckle for the "[electrical engjneers] deserve it" joke. I laughed out loud.
Was the term structured programming ever defined?
Not sure if I missed it or he just dove right into rambling.
i wasn't even aware of this goto keyword XD
Unlike a calling procedure a goto caused program execution to jump to another part or line of the code without returning - the issue with that is that if over-used it tended to cause what became know as spaghetti code because of the tendency to skip around in almost a seemingly haphazard way whereas better use of structured procedures and naming conventions allowed other people especially who had to maintain or troubleshoot the code to make better sense of the program logic.
@@lenfirewood4089 doesn't always though.
if you can give structure to the code in other was then that helps a bit.
i've written chatbots in batchfiles that used goto for basically everything.
but that was in batch not c++.
basically though i sectioned of chunks of function.
i had a
'preprocessor' chunk that handled analyzing the users input from the 'input' chunk and deciding whether or not to even send it to the 'processor' chunk
which then decide what the output would be using a bunch of if statements before sending it to the 'voice' chunk which would write a voice.vbs file and execute it and then delete voice.vbs before returning back to the 'input' chunk.
@@logangraham2956 Yes it doesn't have to result in badly structured code especially if the programming language used allows you to alias the program line to a more user friendly label that helps explain the branching reason.
Its also in VB6, not sure if .net allows it, had no need for a goto personally lol
@@logangraham2956 Thinking back to the days of writing DOS batch files I too remember it's use there. I even used it myself but then the batch processing language was very limited. I don't think itwas much of an issue there anyway because most batch programs were relatively short and thus would be easier to maintain.
Too much code snobbery here for me. It's possible to write tidy, *idiomatic* code in any language. Every language has its way of doing things. Some of the early languages were primitive. Get over it.
Exactly. One can write well-designed and easily maintained code in assembler. You just have to know what you're doing.
Same. Would you rather write code with perfect structure with four levels of indentation or code with many early exit points? Which one is more readable? Is it worth 45 minutes of talk? (i skipped through the video, cause it does not seem to contain anything useful)
There are too many use cases where short circuiting and goto make the code clearer and simpler than without them, that dismissing them without a strong justification is just wrong.
Everyone has learned most consumers are not demanding.
i wish he had spent more time on explaining how, "throw" is not "goto"
From what I've understood you cannot extract a block from a piece of block with the goto in there without the risk of breaking the overall program behaviour. Instead, throw it’s a mechanism where the block ”explode” and alarms the caller, which will ”explode” (throw) if it doesn’t catch. So extracting and refactoring as a new block a piece of the original block where the throw occurs, doesn’t change the overall program behaviour. If it was to throw then it will still throws, if it wasn’t, it won’t. Think about the goto as a return (just the control flow part of it, not the carried value) where you can specify where to go instead of just ”go” to the caller. Then, think about refactoring a piece of your block with a return in it in another little block called by the original one. Obviously the overall behaviour changes, because the return is now local to the new little block and ”return” ”to” the original block instead of returning ”from” the original one.
@@nickolasnielson4727 cool. you're grandma is in programming? were you really responding to my comment?
@@xybersurfer Nope, he's a bot. That exact same comment was left by two other "commenters" above (although four months ago).
This is why we can't have nice things on the internet.
@@ericbwertz oh dang. thanks for informing me. i don't understand what someone would get out of this. maybe using they are using this as a training ground. i've reported it as spam
For the leapyear C code I would write :
int isleap(year)
int year;
{
int ret_val=0;
if ( year % 400)
ret_val = 1;
else if ( year % 100)
ret_val = 0;
else if (year % 4 == 0)
ret_val = 1;
return ret_val;
}
I'm a true believer in the one exit point rule as it aids debugging. I don't have to guess where the program exited. I prefer to compute up and assign a return value variable and return that.
or I might write :
ymod4 = year % 4 == 0;
ymod100 = year % 100 == 0;
ymod400 = year % 400 == 0;
Seems his idea for "structured programming" is simply reworking the function to always reach the end brace. This level of thinking divides functions up into understandable parts, but it also creates something like YandereDev.....which is horrible.....so don't do this. Functions should have only a very select set of jobs and fit on a single sheet, then you would know what the function is doing and can refactor it with ease.
.
Also, I can program fortran, not sure what he means that there are no fortran programmers, unless he's talking about "for profit," but that's obvious. There's no punchcard programmers, if that's the case.....yet I can do those too.
wut?
@@khhnator which part are you having troubles with?
I'm not sure I can follow the huge leap of logic from "function always reach the end brace" to "YandereDev-levels of spaghetti code". The reason YandereDev has such bad code etiquette is because he does not think in terms of composition of code, and ends up having to write everything by hand, in one big function on the main game loop. The structured style he's talking about still favors extracting and naming blocks of code with semantic meaning and/or with multiple usage, it still works best with an understanding of the layers of abstraction and hierarchy of the code.
@@SolarLiner ....what I mean by "reach the end brace" is to "not return early"....but that's poor programming practice. If you can leave the function, then do it as soon as possible, don't wait until the end to decide if a return is necessary or an error needs to be thrown just to separate error checks from valid value returns.
Instead of writing a function like this:
bool load_file(string filename)
{
if(file f = file_open(filename, "b+"))
{
//load everything, 100 lines of code
f.close();
return true;
} else {
return false;
}
I would do it like this:
bool load_file(string filename)
{
if(!file f = file_open(filename, "b+"))
return false;
load_file_secure(f);
f.close();
return true;
}
void load_file_secure(file f)
{
//specific lines of code
}
This is just a crude example and many facets are not highlighted, but the basic gist is to exit as soon as possible, so that you are not indented "like yandere" does with if/elseif structuring. It also gives you the ability to refactor specific subcode without endangering the project.....for example, the "load_file_secure" pseudocode above can take any previously allocated file stream and use it as access to load, so if your file is RAM-drived or accessed in another way entirely, you can refactor the "load_file" code to handle the allocation of the stream and just pass the "file" to the secure part. Simple in, simple out....the compiler will do most of the work in compressing down use-once code and function calls anyway, so you are not losing run speed at all, and you gain readability and refactor ability.
Though I only vaguely remember ever commenting on this video, so this is all just a guess on what the hell was even going through my mind at the time....been busy doing a dozen other things, sorry.
@@sabriath Right expect this does not change code generation, and so boils down to personal preference. I write a lot of Rust code where keeping the if/else is idiomatic, so by simple muscle memory I also do it in other languages.
Scala is rooted in this paragraph 1:06:58
Promise future pipelines are very very similar to Monads in Haskell...
18:08 "Really GOTO Town on it*"
Physicist here, can confirm that I can't write fortran to save my life.
Yes. It should be Fortran or FORTRAN and you wrote fortran.
1:00:50 Hah! I had this exact exchange with my grandma.
Why is this 1.5 hrs long if it's been forgotten? It should be "Whoops, it's been forgotten. Nothing to say." 10 seconds at most
Ok, just a few seconds in and he makes a very dubious claim. I highly doubt that painting is fractal.
He doesn't make a dubious claim. He just cited a scientific article. You can find it yourself very easily on Google as well.
@@Luxalpa He didn't cite a paper he just made a claim, looking it up in google I still find it very difficult to belive.
"You reach for the banana 🍌, you get the gorilla 🦍." (about DLL dependencies)
TLDR; Last years anecdotes, considered click bait
If you want to see REALLY bad code, find a data scientist. Worse still, a data science tutorial. Embarrassing lack of good software development practices.
I can imagine them often generating 'wild' code to only run a few times, like searching a pattern or do a conversion. I have recently done this to tear apart a undocumented data stream.
@@manuell3505 You're only scratching the surface there. Data scientists love Jupyter notebooks, which enable the sort of workflow where cells run in indeterminate order and as a result cells often hold the results of an inscrutable set of transformations. Whoever thought python was a good fit for the notebook model has no idea how to use Mathematica properly.
@@isodoubIet You have no idea what you're talking about. Get out of your own small world...
I don't think anybody who intensively uses computers 'loves' certain notebooks. Those things kill your typing rate.
And what's with the cells? Like all data science involves distributed grid computing or such....
@@manuell3505 I think it's pretty much an objective fact that data scientists intensively use Jupyter notebooks, and I think it's as close to an objective fact as possible that they promote absolutely terrible development practices. I have no idea what it is you're disagreeing with.
11:08 ALL YOUR BASE ARE BELONG TO US.
You can have my X!
This is way I use D
17:57
43:04 I don't like how C++ makes it so easy to find the longest way to do the simplest thing. If you don't want to do the same check twice, first create your string object. If your number is divisible by 3, append "Fizz", then if it's divisible by 5, append "Buzz", then return the string. This method doesn't require rechecking any conditions. Short, simple, to the point, and not unnecessarily convoluted or confusing to read.
You’re supposed to return a string containing the number if it’s neither divisible by 3 nor 5. How do you detect that case without rechecking?
No, he is wrong. And the reason is that the examples are too simple. Sticking to pure structured programming as he defines it has the critical problem of being unable to filter inputs and only access the body of a function if the inputs are valid. Input validation and/or normalization should always come at the top of a function and use return statements to exit before the body of the function actually starts if anything is wrong about the inputs. The result is always less, more correct code in real-world usage. Less code is generally more readable and correct code is functionally stable. And, as everyone knows, readable code is maintainable code. His approach, strictly applied, results in less-readable, less-maintainable code where real-world code can easily wind up in a situation where everything is nested and the main body of the code is way off the edge of the screen due to indentation OR explodes into a zillion little functions that each need their own input validation. In either case, the code is far less readable. Also, structured programming is generally wrong because it ignores better solutions to software engineering problems. For example, state engines regularly violate structured programming concepts even though state engines are the most correct way to write software. If you aren't writing state engines, then you are, with the exception of extremely trivial programs, doing it wrong. Yup, everyone's been writing software incorrectly for the last 50 years.
Thank you. All attempts I’ve seen to avoid the oh-so-evil guard clauses end up resulting in horrendous, unreadable code once you go beyond trivial examples.
I just cannot imagine what religious believers in the one-return rule are thinking. Since when is:
- more mutable state
- more code to verify
- more indentation
OR
- more jumping around code to see trivial 2-line functions
“better” for code style? Never, as far as I’ve seen, unless you are writing something extremely simple. Use guard clauses and move on
“Everyone but me has been wrong for 50 years” 😂 ok bud
people are just slapping code in big ball of mud, back in the days they called it structural programming, then OOP, now functional, but the ultimate result is still the same: a big ball of mud
Back in the days there was no big balls of mud. Code had to fit on floppy drive and program had to fit into few memory segments. But from what I've seen, code from 90s usually sucks more than modern code. Variables named a,b,c,i,j,k,m,n,p,q, no comments, serialization done by write(&data, sizeof(data)) etc.
rerun.
I blame Martin Fowler for the crap code that gets written these days.
Harlan Mills would be quite proud.