Critical Program Reading (1975) - 16mm Film
HTML-код
- Опубликовано: 26 сен 2024
- This is a 16mm film titled "Critical Program Reading"
I applied some color correction as this is very faded. Mostly this worked well but there are some magenta backgrounds that are... intense!
Little information is known about this film. Credits are very incomplete, and there was no information left in the film can. Credits open with "Edutronics Presents /
Structured Programming Techniques/
Part 1 Critical Program Reading: Structuring and Unstructured Program /
Produced in Cooperation with ETHNOTECH
Gerald Weinberg
Dennis Geller
Tom Plum
Copyright MCMLXXV Edutronics Systems International, Inc.
![State of Play | September 24, 2024 [ENGLISH]](http://i.ytimg.com/vi/fVs0suPHAX8/mqdefault.jpg)
This aged very well. 48 years later and people are still writing indecipherable code
I guess it makes sense, as it says from the start: "errors are made by people." The errors that happen when programming come from the person writing them, and people tend to make the same mistakes.
Nobody writes excellent code from scratch. You work through the problem until you have a working solution, then you refactor the solution to make it readable. Trying to do both simultaneously, or just outright ignoring the second step is where all the trouble comes from.
Obfuscation is also important in some areas.
Sadly some people pride themselves in the most compact or “efficient” (as they define it) code possible.
Of course this is in the sense of high level programming and the business logic doesn’t have to be the absolute fastest possible. In other circumstances coders have “unrolled” loops such that the code is longer and repetitive but flows through the cache/pipeline more quickly. Forget what video I was watching on RUclips where this was revealed in some program that seemed to defy reality but yeah I guess it’s works and is good IN CERTAIN CIRCUMSTANCES. Otherwise the spirit of this video is the where it’s at.
Btw, anyone ever see the C program that looks like hi but when run prints the 12 Days of Christmas? (today is 12/26 so very timely)
@@nickpalance3622
Efficiency, and compactness in some instances, is very important, but
it doesn't at all detract from the message here. A balance between factors must be made as appropriate for a project, and sometimes compromise is needed.
A phrase that seems somewhat appropriate here _"Complexity is not the Hallmark of good design, but simplicity"_
Film: "It's a shame that our language can't read our indentation"
Me: "Wait till you get some Python"
Yeah, I caught that too! LOL
Makefiles were dependent on tabs long before Python was a thing. They are even worse there.
Whitespace delimitation wasn't invented by Python. Plenty of languages had it before Python. COBOL is probably the worst for it because it depends on certain control characters being in specific columns, and if you don't have the correct whitespace, then the entire program will refuse to compile.
100 C @@benanderson89/videos Fortran is probably a close second contende
* r. Thanks punchcards! We really appreciate the cla
* rity it provides today when you misplace something
^-- AND SUDDENLY YOUR COMMENT HAS SYNTAX ERRORS
@@jwhite5008 oh, wow. That's pretty bad xD
And in those days you wouldn't realise it had errors until it was sent off to the computer department to be ran by the operators and you received your print outs back.
Wow this is gold! I loved the part when it said "criticize the program, not the people". That's a great lesson that improves teamwork and problem solving
Except Andy, Andy keeps screwing it all up!
Just look at the Poon code, the error will likely be in there (that's Mr Poon).
Wtf this video is actually SO good and relevant. Every programmer should watch this 😂
Why do you hate devs that much?
Many are too sensitive for COBOL and would probably drown themselves as soon as they see it.
I could see this being shown as part of a first or second semester university course even today. Would definitely capture the student's attention with the retro charm and the knowledge that it's literally nearing 50 years old. None of the concepts shown here changed from then to now.
@@jwhite5008 Every programmer should have a set of big projects early in his career to translate something from an obscure or ancient language into whatever is being used for the new code, if the company training the newbie doesn't have old code he should get lots of pseudocode from architects to translate into real code for the real project. This will allow that dev to read programs and algorithms rather than reading code. COBOL is no worse than anything else after being properly trained.
@@jwhite5008 I think it’s pseudo-code though, obviously inspired by cobol though
@@coomservative They even say in the film that it's a mash-up of COBOL and PL-1.
COBOL gave me nightmares ... it was the one language I didn't intuitively understand.
Weinberg, listed in the credits, may be best known as the author of the popular book "The Psychology of Computer Programming." He was also the co-author of the "Ethnotechnical Review Handbook" and the "Handbook of Walkthroughs, Inspections, and Technical Reviews," which promote ideas related to those discussed in this film.
Seconded. If you haven't read 'The Psychology of Computer Programming' I'd recommend it. It's one of the few textbooks from my college days still worth a read.
It turns out he has a wiki page, he passed away in 2018 at the age 84.
When you showed a few seconds of this on your Sound on Film video, I immediately was curious and wanted to see the whole thing, but sadly had no way of finding the whole thing. Seeing you uploading the entire thing in my RUclips recommendations a few hours later was just a beautiful Christmas gift. Thank you, Alec!
I immediately thought hey whats that I want to see more lol.
Same!
Thirded. Just the little snippet in the main video "code unto others.." had me itching to watch the whole thing and I was not disappointed. I'm already sending this to my coworkers and pulling snippets out that are especially valuable
Same for me, this was gold
I had the exact same experience!
nearly half a century later and all of this advice still applies maybe more than ever.
We have learned nothing. This is even from before C
Well, why wouldnt it?
Except the being tactful with personal criticism. Past me was a douchnozzle and needs to pick up his game or I'll fire his ass!
If you look at Python at least the indentation is necessary. But you still need to do it right.
@@jeroen5838 we certainly learned a lot. Most people learn this stuff in programming 101. Also, turns out, that you can totally avoid GOTOs.
Modern languages and style guides are clearly better in terms of readability. The way that periods and commas work in that language is batsh*t insane. And stuff like "less than or equal to" instead of
"It's a shame, isn't it, that our language won't let the computer read our indentation" This dude straight up prophesied Python.
I think any programmer at the time would have liked to see something like that, it was just a matter of time before it finally did
I bet Guido saw that :)
And now we know to be careful what we wish for ;)
Holy crap, this video was surprisingly good. Not just in presentation, most work based videos like this these days are so bland, cringe and boring; but in actually teaching you something. I like how it's a back and forth, that the guy teaching them isn't just telling them what to do but guiding them along as they work it out. And I like how they're not always right but the others catch that and they all help each other figure out the why.
We need *more* stuff like this!
At first it felt offputting, like the instructor was being too forceful. But the more I watched the more I realized that's just decades of that bland, cringey, boring learning material talking. This was refreshing in a good way, and was engaging.
Film 🎥 😉
Let’s hear it for the disembodied know-it-all/guru voice 🎉
That's how classroom teaching & learning generally works, at least in the Socratic model prevalent in the US (in good schools/teachers' classrooms anyway). The goal is generally to get the students to think about the problem, come up with potential solutions/hypotheses, test & critique them, and then come to the correct answer, collectively and/or through guidance from the teacher. Retention & understanding are provably better than in the lecture-and-memorize approach.
"bland and boring" 🤡
14:16
"If you don't want to be bored, learn a style and improve your working conditions."
This was a great video with so much timeless advice.
I learned Visual Basic in high school. Our teacher was originally not a programmer and had to teach himself to teach the class. He impressed upon us to use descriptive names for variables and functions. I took it to heart, and that little extra bit of effort made the code so much more understandable.
In college, they taught us Java in CS101. These dedicated programming profs and TAs always seemed to want to use the shortest, barely understandable names for things. Combine that ambiguity with their garbage teaching ability (college professors rarely know how to actually teach), and I was constantly lost. I eventually passed on my second attempt at the class, mostly teaching myself from a Java book I bought myself. For unrelated reasons, I dropped EE and switched to ChemE. I never had to take another CS class, and I certainly didn't miss that crap.
My high school teacher was much more on the ball and much closer to the tenets of this video despite being a programming neophyte himself. Maybe because he had to teach himself how to make things understandable instead of just being handed a ton of bad habits from previous generations. I owe him a lot of thanks, and everyone who "taught" me programming in college can suck it.
Yah, short variable names like those only make sense if space to store them -- or time to type them -- is at a premium. ...Which it generally isn't. I think I'll take the extra typing time and effort over the extra _mental_ time and effort.
(Not much of a programmer myself, but I've followed people who are. And done a little bit now and then in a few games' internal scripting languages.)
@@AaronOfMpls There's one other consideration - long variable names can also be a pain if you have to type them many many times. RSI _is_ a thing, and many programmers would *really* rather type a little less if they can, so long as it doesn't sacc readability (some fail at that last catch, though).
"These dedicated programming profs and TAs always seemed to want to use the shortest, barely understandable names for things."
To be completely fair, depending on when you went to college, it is entirely possible that those professors themselves learned to program in languages that flat-out didn't allow you to use long names. Either that, or they learned from people who themselves had to code that way.
Habits like this are very hard to break.
@@AaronOfMpls Yeah, I found it interesting that this video is from 1975, a time when I still would have expected space for characters to be at a premium. I was expecting some talk about that in this video, but it never came, and instead they just went all in on long, fully-descriptive names. Pleasantly surprising to see it so prioritized.
It sounds like your college had a poor computer science teaching staff. In my situation, I took a FORTRAN class taught by a ChE professor, and learned nothing. Only after taking a similar class in the CS department did I start to understand programming, and later changed my major to computer science.
That's gold, Jerry! Gold! If there are more films in this series, please post them! WOW.
Jerry squints "ban-ya"
is the technology man called jerry? What the hell
@@ちにたてとな I thought his name was Alec
@@SidewaysCytlan Doesn't he also go by Captain Disillusion? This man must be a multitalent.
@@ちにたてとな his name is Alex iirc. The comment was making a Seinfeld reference
I've been programming PLCs since 1985 for stand alone equipment and I write the ladder code and subroutines in order of machine operation. I even had one customer compliment my coding as "elegant." This film is great!
ladder logic I wasnt so good at. I can program and I can read a schematic but ladder logic acting as both would get hard to manage for say the bottle line project I did. I was pissed I could easily code the logic in basic but never get it tuned to not break bottles.
That is high praise indeed. Congratulations!
5:38 "Why are we restructuring that code?"
"Cus it's bad, that's why!"
This has to be a meme
In a couple more years this film would be 50 years old and yet almost all of the things they say are still perfectly acceptable.
pmuch all of it except using dashes in variable names :D
I think this is the case because it is foundational knowledge. Just as modern codes were genuinely inspired by the order ones, the fundamental principals are still the same for any "words to computer" system.
Furthermore: if you can "divide and conquer" a large function, then in modern languages, moving the resultant sections into their own functions almost never has a performance cost, and often increase readability, reusability, and testability (but not always; stay critical and keep discussing it with your colleagues).
Unpopular opinion: this coding style can be applied in mindless ways too easily and often leads to premature abstractions that make code a lot harder to reason about.
If your language supports it, try using scope blocks instead. This gives you the same encapsulation semantics but doesn’t create an incidental abstraction. One less thing to name, too! (But comments are still your friend)
Splitting too much can lead to lasagna code: layers and layers
@@float32 AWS Step Functions are a great example of both lasange and spaghetti code when used improperly. At last check, Amazon let's you string upto 200 services together in step functions! That's just obscene.
There's a good balance between nesting vs. breaking out into functions.
Also, leave plenty of clear and concise comments -- it makes life easier for you when you revisit code that hasn't been touched in years, and it's good for anyone who comes after you.
@@louroboros My old boss told one of our programmers that they need to write two lines of comments for every line of code. And he did.
"Write your code as if the next developer to maintain it is a psychopath who knows where you live."
-- the old dev on the mountain
And often that psychopath is yourself.
"Take the time to be precise" is quite the life lesson
almost 50 years after this was made, everything covered in this film still applies to us "modern software engineers"
Except no--one puts hyphens in variable names as shown, we use underscore or CamelCase.
@@thegeek3295 Yup. But like, come on. The detail doesn't matter, but the principle does. (I wish I could read this like the narrator guy. "Don't get HUNG UP on the details of the LANGUAGE you're using!")
@@thegeek3295 Lisp programmers do!
@@markg735 you are correct, I totally missed that one.
"Is that really a precise statement?"
"Sure, it is, look at the program."
"YOU look at it."
I love this unexpected argumentative approach to problem solving.
He scolded him over that less or equals just to remove that equals in the next two minutes. What a butt.
thats how us programmers are.
"I don't know what this program does. Let's refactor it, because style guide is life."
"Programming with Joe Pesci"
@@jhoughjr1 "we programmers".
You programmed your response incorrectly
When I first started programming (two years before this film!) there were plenty of languages that had hard limits on variable name length. Nearly 50 years later and there are still programmers who write cryptic variable names, but with absolutely no reason to.
RIFE in SQL and C, Java coders must have got paid by the character at some point!
@@SarahC2 They're outright proud of all their design patterns that are working around language flaws. Can't have default arguments? Builder pattern! Can't have globals? Singleton pattern! Obviously org.thoughtcrime.securesms.components.FixedRoundedCornerBottomSheetDialogFragment is a perfect name!
@@0LoneTech You may have a point about some workaround-patterns, but the verbosity of Java devs is more a result of Java programs generally having longer lifespans in-production. Multi-generational legacy code, or needing to port or document server-side business logic, is more the norm than in say, web front-end, or even HPC for academic research.
Yet this example is an abstract class in frontend code whose very name is impossible to parse unless you already have both the shape and structure of the resulting layout, and whose existence is supposedly a generalisation its name is countermanding. And it's not atypical; just the longest filename in one of hundreds of directories of one app.
Heck, even this longer lifespan claim I don't see support for. I know the marketing (Java is the strongest example of a marketing pushed language) said so from the get-go, when Java programs were inevitably younger than anything else. But it's just pointing out a niche where programs are culturally hard to replace (so the marketers wanted a foot hold). It's certainly no stronger for that task than e.g. Erlang, which never had this culture of ExtremelyLongTackedOnListsOfWordsFrequentlyRepeated.
Mind you, that marketing has been a huge success. It's why we have Java in places it's a perfectly awful fit for, like so called smart cards. They turned the "write once, run anywhere" slogan into "let's only support that thing".
@@0LoneTech 1- Your class name example, "FixedRoundedCornerBottomSheetDialogFragment", is easy to understand - it's an Android dialog base-class. My only complaint is that the styling is baked-in to the name/class, when it should be handled elsewhere (XML theme or layout in Android, or some Swing/framework UI config).
Naming conventions tend to reflect the policy & usage at a shop - if the names are very verbose, that usually means it's code that will need to be read/understood by a lot of people, either concurrently or over time. Obviously there's a tipping point into absurdity, but in an era of autocomplete IDEs and consumer-grade gigaflop CPUs, a few extra characters is a miniscule price to pay for clarity.
I haven't seen this one in eons. Our old goat collected lots of Edutronics and other old IT training matterial.
I think i watched these in 1996~1998. It made me appreciate and understand what actual programmers think about when writing programs. Because at the time we had a lot of GOTO programmers and all new hires had to pass goat's test. I wasn't a programmer but i still loved to pass time with the old hands and programmers and learned a lot.
Just wish this attitude of company thinking in all aspects of corporate work was kept. Think, Educate, Improve and add Value.. I miss the old trainings. No spreadsheet and unit cases..
If you have access to the old Edutronics stuff still I'm sure someone would love to digitize it and get it uploaded
If there's any chance those tapes are still around it'd be great to see them digitized.
Why did your goat have videos?
What was the goat's test?
Amazing how this is still entirely exactly relevant.
Why should be the new generation of coders be smarter than the last one (at the beginning)?
well you’d think that 50 years of hindsight would help but it’s funny how we’re still making the same mistakes as our parents
Even more relevant now since a long variable name won't eat up half a punch card.
@@Broken_Yugo Especially because we can also _comment on our code._ Like seriously, if you want to used abbreviated variable names to make it faster to type out or something, please throw in a comment somewhere explaining what that variable means! Documentation people! It matters!
@@flametitan100 that did come to mind, did these early languages not allow comments?
Lol, nothing have changed in 50 years. Still bad devs, still "someone retired", still refactoring required.
As I plan for my retirement, I like adding comments like: //Good Luck, future Jim.
I like keeping people on their toes.
back then, the world simply didnt have experienced developers. Now, companies all over the world employ the biggest, most unqualified idiots who passed exams / tests / whatever. Because they're cheap at first and get the fastest results thereafter - not a single manager selects applicants based on experience and skill (even though all of them believe to do so). Try applying for a job at a major tech firm with dev-experience and you'll quickly see what i am talking about. The words "coding test" or "tech interview" are clues on how utterly misled and unqualified most HR people / applicant-evaluating-people are.
No comments, no understandability, when I'm gone, they'll be sure to miss me.
@@IgorOzarowski in actuality, un-maintainable, unreadable code like this is deleted pretty fast - and noone "misses" anyone who commited a code-crime like that. In fact, a few will be glad that you're gone. So, basically, all you achieved is wasting memory, drive-space and cpu-cycles for "some" time. Great job. Thats like spreading graffiti.
@@ololh4xx Merely a joke, of course I plan to document my code. I know how often I've been angered by undocumented code myself.
Honestly, this should still be screened in CS classes. Nothing has changed.
Yes!
what has changed is that everyone uses comments, and the Programming Overlords dictated that gotos are evil (they're not, just easy to misuse, just like manual memory management), so programs are a bit different now...
but yes, overall same points definitely apply...but we're in the age of rushing out a QUANTITY of programmers, rather than QUALITY of programmers, nowdays...
there's a LOT more than *JUST* programming, you should know, to be a good programmer, such as when is a problem *ACTUALLY* solvable, or not...and other stuff...when is it alright to reinvent the wheel...etc...
@@jan_harald Down in assembly, there's goto's everywhere. Higher level code just hides the concept. ;-) Also..... comments... I HATE reading "This IF checks that R is over 30".. . yes, the code says that (for now), what's it FOR?
@@SarahC2 that's the kind of comments you get with policies of "must comment every line of code", when you just have to fill the quota, lol
and yes, awful, though usually not *THAT* useless
@@jan_harald Gotos are evil but try... catch is good. Which is actually pretty much the same thing with more elegance.
As a programmer I understand making my code unreadable means job retention.
As a programmer who has maintained a whole lot of code written by other people that strategy will not be anywhere near as successful as you think based on the garbage I've had to maintain.
@@brendonwood7595 true. Honestly I rather my code be readable / well documented. I'm too much of a perfectionist
I'm already sharing this video with my fellow software engineers at my work, merry Xmas everyone!
There’s another potential bug that the authors appear to miss: suppose you have 7 fulfilled orders, 3 backorders, and 6 returns. This code assumes you have 4 net orders, and thus a 150% return rate. It’s unlikely that’s what they wanted to measure!
Maybe that's why they were trying to understand the code in the first place... to fix that bug! :P
It might have been included intentionally to give extra work to the students. (Find the other errors of the code in the video.)
This issue is subtracting returns from the numerator, that isn't actually necessary.
this video is apparently part 1 in a series so maybe that was addressed in later videos?
Well, it did open by saying that the code hadn't worked right since the original programmer left. The film (and lesson) ended before they fully deciphered the business logic and found a bug.
It's only part 1, wish we had the other parts.
"I wish I could do that color trick..." It's like he foresaw the future!
This was actually really good! I don't do much programming anymore, beyond an Arduino/proton pack hobby, but I always try and make my code clear and understandable. If for no other reason, when I come back to it every 3 months I'm as confused as these guys were!
not really.
They completely missed that the remainig 'goto' statement is now redundant.
Also, as soon as you have functions/subroutines (which this pseudo-language seems to have with the 'perform' statement), early returns a.k.a. guard clauses are actually a good idea and preferable to the deeper nesting that it is introduced here.
This style leads to ever deeper if-then-else trees, which are even harder to read than code containing goto.
The only really usable tip is to use meaningful names.
Don't get me wrong, those techniques were all the rage in the 70s, but we have moved on since then and found better ways.
(I’m in the last year of a 4-year electronics technician apprenticeship.) My programming teacher was very happy when I raised my hand to answer the question “why should we write lots of comments” with “so that future me can understand it”!
@@tookitogo Even better would be to write the code itself so that future you can understand it. Comments have the nasty tendency of diverging from the code over time, as they are often not updated properly when the code is changed. Even right at the moment you write them they often do not match 100% with what the code does. Also comments are not "syntax-checked" by the compiler (because they are - by definition - ignored). So all you are doing with comments is adding redundant information that is never checked for correctness. And even worse: it's in a completely different language, usually natural language which is by default not as precise as a programming language, so you're almost guaranteed to lose information in translation.
So the better approach is to have _few_ comments that convey the overall _intention_ of a piece of code (because the intention usually doesn't change as much over time), and try to write the code as self-explanatory as possible. The most important part of this is using good names for variables and methods (attention: by 'good' I don't mean 'long' but rather 'to the point'). Also: don't be afraid to change those names when required.
To quote Rob Pike's 'Notes on Programming in C': "Comments
A delicate matter, requiring taste and judgement. I tend to err on the side of eliminating comments, for several reasons. First, if the code is clear, and uses good type names and variable names, it should explain itself. Second, comments aren't checked by the compiler, so there is no guarantee they're right, especially after the code is modified. A misleading comment can be very confusing. Third, the issue of typography: comments clutter code."
Kevlin Henney put it this way: "A common fallacy is to assume authors of incomprehensible code will somehow be able to express themselves lucidly and clearly in comments."
My way of commenting is to let the code itself express WHAT to do and the comment explain WHY the code block that follows is to be executed.
This film isn’t just a good way to teach programming but also how to be a critical thinker and to have common sense. This is a perfect example that common sense isn’t common if knowledge is taken for granted and never taught. Amazing video. More please !!!!!
Careful, you might be accused of "Critical Code Theory"
I’m not even a professional programmer, but “do it right the first time” is always relevant in whatever you do!
Yeah but they didn't do it right. You can't put hyphens "-" in a variables name. The compiler will interoperate that as a math operation between two variable. Use underscores.
@@thegeek3295This depends on the language you are using. COBOL uses hyphens to delimit words within names.
"Because it's bad, that's why!" was amazing - I've coded professionally for five years and that sentiment is so relevant. And the situation - bad code written by a developer who left - is so common a teaching point now!
I appreciated that there was a woman amongst the three coders, and that one of the logos was of a woman (in heels!) programming at a computer. This film captures a period in history where men were increasingly intruding into programming. By the 80s, it was a male world, sadly, and even now female programmers are exceptionally rare.
Yeah, it’s quite sad how we’re actually went completely backwards in computing (and some other areas of STEM) with regards to women in the workplace.
P.S. For anyone who hasn’t seen it yet, watch the movie “Hidden Figures”. It’s fantastic.
We're not "exceptionally rare", but can be hard to find depending where you look. Places with good work-life balance and fair-pay, like gov't/public sector and enterprises, tend to have better gender parity. I agree that diversity has plummeted in both business & academic computing.
Always strikes me as Orwellian when I hear some junior dev [or ignorant senior] opine that "women have never been into coding," when here I am, a 3rd-gen-woman dev. (I'm mobile & web, enterprise-by-day and games-by-night, Mom was COBOL & Palm Pilots, and Great-Aunt was a mainframe team-lead decades before "fintech" was a household word.)
@@andrewblake8797 It's mainly that Black programmers are used to being overlooked. It's actually gotten worse IMExp, as there were more of us in both CS classes and IT workplaces in prior generations than now. But that's certainly not something to champion, or make sarcastic remarks about.
As a software dev born well after this was made, I tend to think that a lot of the kind of work done back before the 80s was unstructured or not very well refined. It's weirdly impressive and comforting to see and hear something like this from that era. Most of the books I learned these very ideas from came out in the 90s and 00s. Thanks for uploading this, I love it. ♥
"Why are we restructuring this code? Because its *bad* that's why!" 🤣Simple and straight to the point, and also a thing every good coder has said at some point.
It also means we have not improved in the past decades.
Worst codes I saw?
The stuff I wrote half a year ago... (only a slight hyperbole)
Another thing (should watch the whole video before commenting...): they make a difference between program design (programming) and implementation (coding) at the end. This is so useful. A bunch of my younger colleagues don't do that at all, which leads to unreadable and unmaintainable code. Told them, got ignored, not my project, they will learn. We all did. Eventually.
The young CS graduate I just hired (for my group) is even stricter than I am. I guess she'll tell me to get my act together sooner or later. I hope sooner, have high hopes. Then I'll just let my lads and lasses work ;)
@@johanneswerner1140 If I get what you are saying, then I agree, the designing vs implementing bit is challenging. It really is funny this video hit on "good names for stuff" because I half-jokingly think that is one of the hardest parts of coding. Its super easy to just toss in a random letter or to abbrv. and continue on your way. So much of my refactor work (on my own code usually haha) is me going "dam this name sucks" and renaming it, and that's _after_ having spent a minute or two the first time when I wrote the code, thinking about it.
There is a reason why a lot of software devs say coding is more art than science and its because of all these small details that are so subjective (till they aren't 😆).
@@vix86 "random letter to abbev."
😂
What kind of madman wrote that?
Oh. Past me. Thank you oh so bloody much. Right, it was an elegant solution, just not very obvious...
@@johanneswerner1140 So true! I can never tell in the moment if the way I have structured my code/solution is really that "obvious" until weeks later when I have to revisit it. One of these days I hope I'll get enough experience to know these things in the moment, but right now I rely on "future me" having to be the judge for so much of this. At least I'm smart enough to add enough comments so that future me has _some_ idea whats going on. But man, software development can be hard in the weirdest ways.
This video made me both giggle and smile because of how relevant it still is today.
I first learned programming (PASCAL) when this film was new. I was taught to use structured programming.
Now, I'm a web coder, writing HTML & CSS by hand.
I still use structured programming principles, and it drives me nutty when my fellow coders don't.
The film concepts are as relevant today as they were in 1975.
When I started working with WPF in windows, one of the things I realized after a few hours that it would really be nice to have something like CSS for this, and sure enough, a little research showed that you can make something like style sheets for XAML. It really cleaned up the code a lot and made tweaking the visuals a lot easier.
@@stonent WPF was pretty sweet once you got to know it.
It's great that you posted this. I was in high school in the 70s and I pegged the time period by the hair and clothes styles!
I have one point to make. In the 60s and 70s, computers were slow and data storage was limited due to it being crazy expensive. There was common practice to beat that code down into the smallest number of bytes possible. Notice how long the more readable code is compared to the original. It probably takes 4 times the storage! That would have been a very big no-no in the 60s. Now, as storage increased and the price came down, it would have been good to break that habit and I think that's where this film falls. It's message is space is less of an issue now, so you have the room to make code more understandable.
Which is why I'm so glad for comments in programming languages. A quick one time description of what each variable is can make a program easier to understand and save space.
Now ask me about how triggered I am at their removing OR EQUALS and not putting in OR EQUALS when changing to greater than... (edit spelling)
@@rvaughan74 Yes, a short block of comments at the top to list variables and their purpose helps solve the problem, or maybe a separate text file documentation with even more detail if the program really needed to be as small as possible.
That's a good point. At my job there is legacy code and concepts from the late 60s-70s-80s and whenever I ask why something is done in a strange way "because storage was expensive back then" is often the answer I get. They did some weird stuff (by today's standards) to save a byte or two per record. Now our main database is around a petabyte of SSDs, so saving a few bytes is never worth the effort.
@@Daggett1122 why there was a Y2K frenzy (not knocking it)
As an 18-year-old programmer, this is actually really interesting and useful.
as a 20 year old programming student, I'm worried as to why I wasn't taught this sooner
Waited at the end of this video for that "teacher turns the lights back on moment" for far longer than I care to admit.
I'm glad to see this in full. I was wondering what they were working on
I graduated in 1976 and by 1978 was involved in the use of structured programming methods and structured walk-throughs in an industrial process control and monitoring environment. All of us embraced it, and found it very useful.
It’s just like what one would learn in any good modern day computer science course, but the programming languages have improved dramatically since this was filmed…
The languages have improved, the programmers, sadly, have not...
LOL. Yeah, sadly education hasn’t progressed much. Here we are still using the outdated Prussian model of education. What should be a rigorous field of psychology is carried out using crude, ham fisted techniques better suited to indoctrination than true education.
This is honestly incredible considering the year, it keeps your interest and is highly educational. Very well-made, I wish I learned programming from this narrator when I first started. Now I just need to harness the power of AI to generate educational films from the 70s.
Yet no warnings about using only two bytes to represent a year.... They could have saved so much time and money if only they'd warned people about that.
@@h..h chef's kiss. technically correct, the best kind of correct.
@@h..h I present: binary coded decimal.
7:20 "is that really precise?" "Well sure it is just look at the program" "*YOU* look at it!"
That was great, thanks! Takes me back to my early efforts in FORTRAN and Algol which I realise were before this film was made. I am quite astonished that their invented language didn't seem to have any comments though.
It may have comments, but don't forget that the whole point was that code was written badly by a lazy programmer. And also the point maybe that your code should be self-explanatory and not to heavily depend on comments.
Bad programmers tend to think their code is self-explanatory, and therefore they don't need to write any comments.
@@dalstein3708 On the other hand, bad programmers often don't know what or how to explain with comments about their programs to make the meaning clearer
@@dalstein3708 At least if they make the code clear, it has a single meaning. Having comments explain to the reader and code direct the computer very easily leads to different understandings. Good comments tend to operate at a different abstraction level than the code itself, e.g. explain why a method was chosen.
I can remember watching those types of films when I first got into programming.
5:40 What everyone says in their head but can't say out loud. Also this is a really great informational film I'm glad it was preserved. These concepts still apply decades later and probably will forever.
My high-school programming teacher would have some words for anyone who wanted to use "GOTO".
That was absolutely amazing! There’s some strange comfort to watching old film videos that makes me feel like a kid again, and its even better that I’m just starting to learn programming!
Speaking as a programmer of over 30 years, this has dated very well, and I was saying much the same in code reviews recently.
Once you've been working long enough to have to deal with your own or a colleague's impenetrable code when we're under the weather and in a rush, the clarity of code shoots right up the priority list!
"Reading programs is so much easier than writing them"
Oh my sweet summer child...
This film opens with the Handel Gothic typeface and a clarinet, so I knew I’d enjoy it.
"If you need a flow diagram for a simple piece of code like this, your program isn't well structured."
These words were said nearly 50 years ago, and many programmers still don't get this.
Ok.. That's crazy... This film is 47 years old and I still need to repeat this basic things too much when I do code review at work... At least we are using python so the computer is reading our indentations when compiling it into bytecode.
Still I wish I didn't need to tell everybody to use better naming conventions.
Thanks for the class mister drunk professor!
One of the contributors (1:02) to this video is Gerald Weinberg, who wrote many good books about programming.
Haha - during that part where they fantasized about the computer reading their indentation, I thought to myself, “nah, you don’t want that - you’ll just end up with python.”
Love,
- a C / perl hacker.
@@nickwallette6201 Agreed, I hate Python and one of the things I hate about it is the forced indentation and lack of curly brackets. How am I supposed to run code through the C pre-processor with forced indentation? I've worked with systems that took top level values and C pre-processed them into Perl, C, ARM and a 16 bit DSP assembler, makefiles, and the linker scatter files. All of those played perfectly well with this, but Python can't do it because of the mandatory indentation.
@@owensmith7530 The first time I tried Python, I grimaced at the whitespace-as-syntax part, but tried giving it a shot anyway.
The straw the broke The Camel Book's back was that, with about half the libraries I tried to use, what passed for "documentation" went something like this:
_This library is super easy to use. You'll be amazed at how easy it is. With only a few lines of elegant, beautiful code, you can easily do things, easily. For example:_
< _some random Python code snippet_ >
_Isn't that beautiful? And super easy? And that's all it takes! * fart * * snnniiffffffff * AAaAaahhhhhh... omg it's so wonderful...._
... meanwhile, I'm like... sooooo... what does that actually _do?_ What do the parameters mean? What's the return value? How do you handle errors?
... to that, most of the Python community answers:
".... errors? What .. 'errors'? That's not a thing in python."
FYI "In my day" our compilers did not read indentation, but we had programs (not used enough) that would do automatic indentation and other operations on the source code, thereby pointing out structure errors. In my 'latter years" I would ALWAYS run this before final testing and placing into production, leaving a much more readable program for whomever would read it next (in many cases that was me)
Back in the 1980s, disk space was at such a premium that the sysadmins wanted us to use tabs instead of spaces to indent our code in order to save on the byte count of the source code files.
50 years later the unhandled division by zero is still looming. boggles my mind that they did not consider a fraction in time where you get returns while not having shipped products.
*EDIT:* I just went back to look at it again.
> NET ORDERS = FILLED-ORDERS + BACK-ORDERS - RETURNS.
> FRACTION-OF-RETURNS = RETURNS / NET ORDERS.
So even if they shipped products, they could end up with a 0 divisor if enough returns came in at once, but there isn't a lick of error handling. And it wasn't even mentioned. Brilliant. 🤦
I can only assume it was unthinkable at the time that product quality could ever be so consistently, almost universally low as it has become today.
Personally, I was 3 years old in 1975, but as a kid in general it seemed like things (especially items that were already "old" to me, that my parents had from the 60s or earlier) were made with more care and lasted longer than the disposable quantity-over-quality, cheapest-components-win paradigm that rules now.
I was wondering while watching the main video "Man I want to see this film"
Thank you so much
Seriously, I wish you luck in publishing old film transfers on RUclips and NOT getting DMCA'ed for copyright, a large majority of films I remember watching on RUclips in the past that were very useful to me have since been claimed for copyright and either been taken down completely or have large sections of audio silenced destroying any usefulness, even those that are public domain with little or no music, copyright trolls will still claim they own them.
Just make sure to download it if you want to preserve it
thats why you download stuff, they (for now atleast) cant remove it off your hard drive
I work every day with source code from 20+ years ago.
When THAT code was written, this video was 20+ years old.
And nearly EVERY principle still applies.
1:55 "Reading programs is so much easier than writing them" Timeless wisdom that seemingly needs to be relearned by every damn generation of programmers. It's incredible how little has changed in 50 years.
"A computer program is intended to be read by humans, and only occasionally by a computer."
@@dalstein3708 Well, except that the computer typically reads it at least 100 or 1000 times more frequently than humans do...
At the beginning of (programming) time the M.O. was to hire someone who knew the subject (engineering, statistics, finance, etc…) and teach them to ‘use the computer’. When I entered the profession, early’90’s, they were looking for more language training. WOW! What a throwback! Thank you.
I feel like I actually learned a fair amount about good programming practice from this.
Just don't put Hyphens "-" in your variable names. Use an underscore otherwise the compiler will think youre trying two subtract two values.
@@thegeek3295 CamelCase is even better.
This brings me back to when I did production CAD/CAM. Nobody else saw the things before I got shitcanned, but I baked a lot of verbosity into everything - sketches, feature names, the CAM post-processor, the subroutines saved to the machine tool… no one was there to help me but myself, so I tried to be a good resource.
Did you use AutoLISP or G code?
@@PixelOutlaw Fanuc g-code.
“Use tact with personal criticisms” I feel like he should have shouted that part.
Unambiguously the best present under my Christmas tree - and I say that as a functional programmer who just bought a "family" 3D printer. This is pure gold.
This is really good. The content is great and any novice programmer should watch it. But the scripting and production are great too. The back and forth between the "teacher" and "students" and the "students" checking each other's mistakes.
Damn that flutey muzak on the intro is so 70/80's education film flutey muzak Really does take me back.
What a delight! Sound programming advice in charming '70s aesthetics!
this angry old timey instructional video narrator is my spirit animal
It is crazy to me how these lessons are still so important 47 years later!
Having worked on critical financial systems, I can confirm that "less than .33" is NOT the same as "less than or equal to .33" and they can't change it just because they don't know why the original programmer wrote it like that. He wrote it like that because that's what fit the business rules in play.
Recall the context is this snippet of code is already doing something wrong. We don't know if that's one bug more or less, but understanding the code is likely a step towards solving the problem. Personally I'd prefer operators that aren't five words long, but lining up the values might be a start.
i want to shove this video into the face of basically every dev i've ever encountered over the decades, especially the young ones. this is pure gold.
Make them suffer the horror that is COBOL.
Let no one go unscathed and live a simple life in their little happy world.
They have to know what it is like to face the depth of despair!
Being young isn't the issue, it's being lazy and having no discipline that makes one's code horrendous.
“The computer doesn’t need the indent, it only sees the period!”
*sweats nervously in Python*
One of my better Christmas presents today. Thanks!
Keep up the good work fella and, as always, stay safe!
Thank you for putting this online! It's great to see people working to archive stuff like this, and as others have pointed out, this is something that's still very applicable to the modern day. I'd be fascinated to know more about the background of this film, and i hope that more of its background can be found. Saved to goog
This should be understood by everyone, not just coders
1975 programmers: "It's a pity we can't get the computer to understand our indentation."
Guido van Rossum: "Hold my Heineken..."
And so, as Tiny Tim observed, "Code unto others, as you would have others code unto you."
Edutronics appear to have written a variety of training programmes and at least one other video series: Top Down Design parts 1 and 2 are listed in the 1976 Catalog of Copyright Entries (it's on Google Books), both produced in cooperation with Ethnotech. Let the internet hunt commence!
I absolutely love this as someone who wants to learn to code this is definitely my speed for learning , please please please post the whole series if there is one !!!!!!
"Code like the next developer maintaining your program is a violent psychopath who knows where you live."
A lot of principles I wish were revisited today, like meaningful variable names, indenting, and debloating functions to something more concise. I really appreciated the way the H pops when the narrator says hwhile and hwhy.
Ok, Ok, I get it, I was the original programmer. What happened was that a competitor was acquired by "MegaCoprEntity" but due to legal requirements we had to rewrite a huge section of the system to link both companies inventory and make sure we could meet our statutory reporting requirements.
The problem was, despite people in the business knowing this acquisition was going to happen for days previously, they chose not to tell the developers until 16:30 the day before a bank holiday.
Anyway we wrote the code so we could get it through change management for each step, test and deployed on to production in under five hours, revising huge sections of the system. We were assured that all our other project work would be then suspended so we could write a proper fix. We did some estimates and reckoned that we required around four weeks to review the rush job and develop user stories and test cases properly. The message was, you need to get the basics working and we'd have allocated time from Tuesday next week to do it properly.
We arrived back on the Tuesday to find that the code worked and that everyone was delighted with what was done.
Could the team therefore carry on with the other projects and they would set up protected time next quarter, or next year...
Ok: I'd like to think I've never delivered bad code, or unintelligible code, but then that's what code reviews are for! But I'm sure we come across code like it.
But, time-and-time-again, however, many "poor" decisions are the result of management or people outside the development field placing requirements and demands that have to be met.
The legal one I mentioned above actually happened, by law we had to report to the UK Government data and failure to do was a serious issue. The change was made and actually it was very simple and well received, but the point stands, many poor programming processes would be avoided if the people that request work took the advice of the people doing it. and understood that actually as much development time is taken with thinking about the wider business process as is writing the code. Regardless, every hour informed is an hour to make ready.
Attempting to spot the holes in your business is hard enough, but in acquisitions: impossible!
That said, personally a comment, or a work ticket reference can go a long way to helping those who follow on after you. I know in "Clean Code / Uncle Bob" really the code should be self explanatory, but when you're handling the combining of complex systems and requirements a bit more detail can really help.
The actual subject is still very interesting and as others have said, nearly fifty years on you can still feel that the general thrust of the argument in the video was correct.
I reverse engineer and debug 30-40 year old programs every day. This is SUCH a good guide. I wish we would have watched this film in my comp sci course!
Amazing! A 50 years old video and yet we still do the same mistakes (even on PhD-Level....) Thank you!
This is unironically good, and still applicable to modern programming
"Use meaningful names" is the only thing applicable to modern programming.
Introducing deeper nesting like they do it here is actually considered bad style nowadays.
If-then-else trees are notoriously hard to read (even harder than just having a jump to a label!). In this example the tree might be just two levels deep, but even here without the indentation (which can easily be messed up during editing) it's not clear on the first glance to which 'if' the 'else' belongs. (And in whitespace-aware languages like python, this will actually change the meaning of the code.)
Of course today, instead of using goto we would just put the code into a function and use early return to bail out (which basically results in the same machine code, but is easier to read because we dont have to find the label).
@@stephanweinberger I don't think anyone programming or learning to program in python or any other language is using this film as a guide to code.
@@Dresdentrumpet read some of the other comments... ;-)
this video was recorded live from the liminal space in my brain when I reviewed a PR on some convoluted trash code last week
That soundtrack is totally groovy man, and the information still jives today. Right on.
The fact they didn't remove the useless go to at the end offends me
This is so cool to see! Programming languages are very different today, and it's really interesting to see where that structure came from.
A lot of comments have already covered the film’s timeless relevance and lesson structure, but it’s also marvellous how well crafted the art/visuals are. Its style is well executed and looks coherent. It must’ve been a ton of work just to do some of these animations in the 70s.
This is incredible in both how relevant it still is but also how our tools and languages have changed since. That guy would be so happy to see that we can indeed do the color trick, but even better. In python, the computer _does_ read the indentation. In most other languages, we have brackets that show exactly how everything is structured rather than using commas and points.
Also it's funny to see people were already saying gotos were bad
The main part of the "structured programming" movement was to eliminate GOTO statements.
Having "blocks" of code instead, with control-flow statements, eventually won out and influenced how computer languages are designed.
Fun detail: They left out a clear step. With the final structure using else, the remaining goto had no effect, so they would no longer need the label.
Gotos are bad when they obscure program flow.
If you look in e.g. Linux kernel source, goto remains heavily used to perform cleanups. There's structure to it; we have success and failure paths, with multiple possible transition points.
In e.g. Haskell, this might be represented using a Maybe monad (Rust inherited this as Option, but if let doesn't solve the nesting level issue). Python would usually do this using context managers or exceptions.
Other structured gotos are also popular, as in the continue and break C statements, extended with labels in Rust. The gotos used in this sample were of the break type, but they were only required because of reversed conditions. That sort of structure is often required in machine language but not source code.
"Reading programs is so much easier than writing them" oh, to have lived in the era before Perl
The snark is so real. Amazing.
This is genuinely very good. Thanks for uploading it.
All Devs should work in support for a time so they get to experience the horrors of unclear code that has to be fixed in 5 minutes flat.
How is this old sleep inducing video the BEST thing I’ve ever seen on how to program? I wish I’d seen it before my first programming class
Since the example is COBOL-like, RR and FRACTION-OF-RETURNS are presumably fixed-point decimal numbers, not floating point, and presumably have 2 significant digits after the decimal point, as specified by a PICTURE clause like PIC 9.99 or PIC 9V99, so they presumably have a range of 0.00 to 1.00 or 101 distinct values.
The revised code differs from the original code in that values of .20 and .33 both produce different results, with the excuse that .33 is only an approximation of 1/3.
If I were testing the revised code, I would run regression tests comparing the results from the new code with the results from the old code using actual data from previous runs.
If there's a sufficient amount of test data, it's pretty likely that values of .20 and .33 will be encountered, causing the regression tests to fail.
This is probably not what you want.
This is fabulous! Jerry Weinberg was a friend of mine and I've been trying to find a copy of this film collection.
Absolutely zero has changed in computing other than the current fashionable language of choice (obviously don't take that too literaly).
I have a masters in computer science and a lecturer, who was an old dinosaur, showed us old code written back in the 60s just out of sheet interest. My first job after post-grad was junior mainframe ops working with Adabas Natural on a codebase originating from around 1985. Flash forward 12 years and I now write C++ and various scripting languages for Amazon based services.
This film is still relevant. You could show it to someone graduating *tomorrow* and they'd find it useful.
No joke, I'll be sending this to everyone on MS Teams when we all finish with new year's break. We still end up with nonsense like "const r =" and "x => " littering the repo.
Or for loops with "i" as the loop variable. And don't get me started with nested for loops! STOP USING SINGLE LETTERS AS VARIABLE NAMES, DAMMIT!!! 🤬
@@Milnoc I'm 50/50 on "i" as a loop variable. If it's a very short loop in something like C then "i" is fine IMO. For anything larger, it really should be a fully qualified name like "iterator" or "index".
@@benanderson89 Since it's a "for" loop, I prefer to code them like "for (int loop = 0; ...". 😁
God no, I hate single letter variables, I'd love to see IDEs prohibit those, treat them as errors.
@@Milnoc depends on what it's for. array[loop] doesn't read well.