HomeНаука и техникаRelated VideosMore From: Coding Tech

Procedural Programming: It's Back? It Never Went Away

1229 ratings | 56877 views
When programmers describe code as 'procedural', it's generally not meant as a compliment. There is the belief that we have collectively moved pass such thinking and onto better paradigms. But a paradigm is no more than a pattern language, a family of solutions fit for a context. Change the kind of problem you are solving and you may find a different solution makes sense — even, in these days where pure functions battle it out with classy objects, procedural programming. This talk takes a look at some of the past, present and future of procedural programming, looking at how there's more to it than many first assume, how it still informs language design and how it relates to other paradigms, such as functional and OO. EVENT: Build Stuff 2017 PERMISSIONS: Build Stuff Conference Organizer provided Coding Tech with the permission to republish this video.
Html code for embedding videos on your blog
Text Comments (216)
lama beans (18 hours ago)
Our search for the one right answer continues
Solve Everything (15 days ago)
Procedural stuff are too difficult and complex. They take to much time to make pretty and sweet. Theres always some unpermitted case getting generated by my grammars. I give up on this impossibly messy subject.
Graham Telfer (26 days ago)
I just kept thinking Forth and Factor.
Brian Barefoot Burns (29 days ago)
Great talk from a great speaker. Thanks very much. I will be sharing with my colleagues.
drstrangelove09 (1 month ago)
What is the problem with return early? Say it clearly. Give examples. Otherwise I'm not buying. Whis is the problem with not specifying the else because we return? You claim that it is hard to follow... not buying it.
Dan Cook (1 month ago)
The idea is to replace a series of sequential statements that might or might not happen, with a single expression. The claim is that is easier to reason about because there is no branching, just a single linear statement. I don't know if it's worth arguing whether that's correct or not (or whether one can claim that across the board in all situations); but Kevlin is not saying that's the right way to do it. He's just clarifying that that is what "structured programming" really means, or at least what it originally meant. That's all.
Shadowstray (1 month ago)
The first floor is the first floor above the first floor you're on when you enter the building. How hard is that to learn?
david rawk (1 month ago)
I loved this talk. Old is new. Your love of history and code is palpable. Respect.
Kavukamari (1 month ago)
I love this guy's sense of humor
movax20h (1 month ago)
Most OO and functional languages are procedural languages. C++, Java, Python are all procedural languages.
Will Perrin (1 month ago)
Great lecture
Sharp Bends (1 month ago)
It's turkeys all the way down ! Is there any other industry or endeavour where the protagonists bitch and moan endlessly with each other about what tools should be used and how they should be wielded ? ;-)
GRAFT (1 month ago)
Great presentation.
Sergio Díaz Nila (1 month ago)
what you described as "idea of orthogonality, that things can be composed" comes from functional programming, that started with LISP 1958, closures were invented in Mathematics, then they were part of LISP and then ALGOL68 All of the things you claim were invented by ALGOL they were really invented in LISP John McCarthy was member of the original design team of ALGOL68 and he introduced all of those features from his work with LISP. Get your history straight!!!
Cale McCollough (1 month ago)
Ideally, the best software SHOULD be created in a waterfall pattern using domain-specific knowledge. You really should do design thinking up front, iterate through mockups rather than legacy code, then UML-to-TDD-to-Waterfall #4TheWin!!!
Cale McCollough (1 month ago)
Good TDD video: Jim Coplien and Bob Martin Debate TDD. It doesn't have Design Thinking in it though. I advocate the school of thought where you create a verbatim unit test script from your Use Case Scenario with a mocked-up server at the end of the Engineered Software Analysis stage right when you're starting the Software Architecture, and you get your Use Case Scenario Test to pass and iterate through some mocked up architectures before you even set your architecture. This allows you to get in-person customer feedback so you can develop domain-specific knowledge without writing code. Most companies can't do this though because they have legacy code. +sacredgeometry
Cale McCollough (1 month ago)
+sacredgeometry Okay, I agree that my initial comment wasn't well written. I have updated it to read Ideally and SHOULD be, rather than this is how you should code today.
sacredgeometry (1 month ago)
+Cale McCollough I am not interested in the shortest path to market. I am interested in making the best software possible.
Cale McCollough (1 month ago)
I probably agree with what you're saying but we're misunderstanding each other. I'm talking about the IDEAL situation, and you are probably correct. You must learn Design Thinking, it is the way. You should really learn about it. Google did studies 3-4 years ago that show it takes on average 400% more revenue than Lean Startup methods. Of course, this doesn't work when you're trying to figure things out, but what I'm trying to say is that domain-specific knowledge (DSN) is more important than Agile practices. The shortest path to market is a waterfall Agile is not needed with DSN. +sacredgeometry
sacredgeometry (1 month ago)
+Cale McCollough The main improvement and difference between waterfall and agile is agile is collaborative and concurrent where waterfall tends to be sequential and not. I know which I would always choose.
doublestarsystem (1 month ago)
What is a method in oop if not a procedure?
Jack Dingler (1 month ago)
It's semantics.
FeelingShred (1 month ago)
'68 first Deep Purple LP
Zachary Pfefferkorn (1 month ago)
Jesus...tough crowd. He landed some really clever jokes and never got so much as an audible giggle.
Ryan N (1 month ago)
I doubt they mic'ed the audience.
Stephen Lynx (1 month ago)
It's what I've been talking for years.
Bogdan Ionitza (1 month ago)
this guy looks like Bruce Willis
WRQ Nine (1 month ago)
Right back to the same protectionist language. Control is almost never voluntarily given up, regardless of consequence. The exceptions all being in the broadly public and well understood instances. External criticism has never existed for the vanguard of coding, and it's legacy has been fundamentally corrupted by it's process. My contempt for the abuses of position and intellect is purely supported by all the aspects of this production. As we casually create a comfortable home for psychopathy in modern endeavor, who will carry the torch of reality into that cave of potential and imperative? Mark my words, group think on this level is of unknowable toxicity. One of the most dangerous and insidious facets of "AI' is written in our history of this process and it's relationship to the private affairs of individuals. The once humane notion of credence takes a decidedly decadent turn in every proximity to "AI" in general. On a personal level it's ramifications run from inconsequential to absurd. The only defenses for the general public are either the unlikely possibility of direct confrontation with all of the offending parties, or to take up and (in effect) become the thing itself. The intellectual crimes of the coding cartel are already multitudinal, and this is as close as I've ever seen to a discussion of it! The environment of potential impact on this subject is so infused with the paste of human imperfection that, barring a miracle against Newton's first law (and the second law of thermodynamics), we've already seen the best of it. You, as "professionals", are still incapable of accepting the reaches of your creation, least of all in the realm of the human spirit. I consider this piece dangerously optimistic and self congratulatory for a system that plainly has ignored the impact of it's operators and deferred any hint of impropriety to the ambiguous concatenations of a "logical" device.
Paddy McCarthy (1 month ago)
38:04 "What I find interesting; what validates or strengthens a paradigm is when you can arrive at its conclusions from multiple paths"
Darwin Santos (1 month ago)
Gold!
Paddy McCarthy (1 month ago)
25:00 "GOTO considered hamful" was much debated in the 89's w.r.t. the BASIC programming language.
Paddy McCarthy (1 month ago)
The first three minutes unjustly denigrates the proceedural method for effect. Does the guy have so little to say that he needs to spout such rubbish?
TheRainHarvester (1 month ago)
OO gets in the way for architectural changes. When you want to change the architecture to see if something else would be faster, OO becomes baggage to lug around and maintain.
Brian Crink (1 month ago)
This should be obvious given OO uses encapsulation while freely flowing code cares nothing at all about isolation and largely leaves the data intact in the public domain
Matt (1 month ago)
HOLY SHIT PROCEDURES ARE FIRST CLASS CITIZENS IN 1968
John Undefined (1 month ago)
Procedural programming will never go away. The assembler is procedural, imperative, and non-recursive. And it can not go away. All higher level programming languages depend on it. They may hide it from the user. But they still need that assembler.
sacredgeometry (1 month ago)
+John Undefined weren't punch cards declarative?
John Undefined (1 month ago)
+sacredgeometry Ok, if programming as a whole goes away, procedural programming will go with it.
sacredgeometry (1 month ago)
+John Undefined Surely binary/ machine code is the common progenitor and binary may going away with quantum computing. So ... never say never. Also in a future where problems become more complex and computers become better at understanding requirements and instructions in spoken languages humans may not be writing code for that much longer. In short. We will see about that.
John Undefined (1 month ago)
+foo bar Oh, you can _implement_ recursion in assembly. It just isn't an inherent feature of the language. You only need one little stack misalignment to be reminded that assembly language isn't really recursive. When they create a new programming paradigm, its distinguishing feature is always how it is _different_ from assembly language. My point is that the scary attributes of the assembler are not going to go away because the assembler itself cannot go away. All of programming falls apart without it.
foo bar (1 month ago)
Eh. Recursion isn't so hard in assembly. Just save your registers in a stack frame a jump back to the beginning of the function. Even "common" OO (more like what we see in mainstream languages like C++, as opposed to Smalltalk) doesn't map that badly onto the machine. I kind of think that accident made OO more popular.
spaceLem (1 month ago)
13:19 Nope, Fortran, Lua, R, Julia, Matlab, Octave, Maple, Mathematica... plenty of languages (mostly those used by mathematicians) still using 1-based indexing.
Milan Stevic (1 month ago)
+temporary_name the key part is in the parentheses "(mostly those used by mathematicians)" not a single true engineer's language is based on 1 (even QBasic had the OPTION BASE instruction since the 90's). almost all of these languages are used exclusively for numerical/mathematical/computational analysis, high-level design/specification, or in other research capacity, where the base-1 comes off as natural, and correlates well with the corresponding scientific disciplines. only Lua got lucky to some extent to be used in a commercially operative environment as an interpreted language for high level behavior.
temporary_name (1 month ago)
What a list! 🙄
Mohamed Fouad (1 month ago)
Love this guy
overclucker (1 month ago)
An empty lot has zero floors. Everything between ground level and the ceiling is 1 floor. If you demolish a building to ground level it has zero floors.
Dorf Nolen (1 month ago)
Yeah, if a house has zero floors then it is non-existent, if it has one floor then it has a ceiling and walls that are attached to that floor.
rafaelveggi (1 month ago)
Wow, what an awesome talk! the only thing I missed was a big fat thick round of applause at the end. Thanks for sharing
Ch Pe (1 month ago)
Are there any procedural programming languages where i can actually do useful things without needing OOP or Date Structures? And get a job.
moefag (21 days ago)
Go ?
_me-ta-_ (1 month ago)
+Ch Pe C++ has support for most OOP concepts (objects, classes, inheritance, etc...), but you do not need to use them although in reality it is used. That being said, you can sort of use OOP in C also even though the language itself doesn't help you out with that. Assembly too. OOP is really just a way of organizing things after all.
Xiefux (1 month ago)
to get a job, yes. but otherwise you can just not use oop+Ch Pe
Ch Pe (1 month ago)
+Xiefux I'm under the impression OOP is used in C++. My school teaches OOP and Data Structures in C++ which means you likely need C++ OOP to get a job.
Xiefux (1 month ago)
c++
Wen0110 (4 months ago)
Good lecture! OOP has become a kind of religion for many, and this is actually a bit puzzling. Most of the pioneers of Object Oriented Programming were actually pretty clear that OOP was to be an additional tool in tool design toolbox. They never intended to create a world in which people would say that something is wrong because you din't use OOP.
sacredgeometry (1 month ago)
+Milan Stevic "We all tend to take things like data access for granted -- there is a cache, it's all abstracted yadda yadda, well I like to be in control, and I like having a mental image of the inner processes at all times. I like my code reasonably well organized between the pragmatism, readability, and performance. It's not as simple as a memory leak, it's this misconstrued transformation that's wasting cycles invisibly, that gets only multiplied whenever you lose your mental grip. This is the essence of coding as a craftsmanship. That's hardly the case with other coders who typically organize their work between their wage, their kids, and skiing. Yeah I sound a bit salty, but I really think there's room for improvement, and a better language design could only help with this -- it needs to be reasonably mnemonic, uniform, and (cognitively) lightweight, with as little special cases as possible, and as few clever twists as possible -- the neatest trick should be the most default one that anyone could think of etc. " I couldnt agree more.
sacredgeometry (1 month ago)
+Milan Stevic Obviously a really contrived poorly optimised example but...
sacredgeometry (1 month ago)
​+Milan Stevic "LINQ provides many a shortcut to getting things done, some of which are, in fact, more horrible than when the code is obviously horrible, for a trained eye. If you nest several LINQ queries with lambdas, it certainly looks & feels clever, but not even the authors could tell you how well that's performing, especially in context, and how the underlying types might affect the data access performance if changed or expanded in the future (the invisible eater of cycles). But you cannot train yourself to see this -- because there are legit uses of LINQ that look suspicious, in fact, most of them do, imho." Nested LINQ statements can get hairy but then so can nested iterative code. I would still say that there is a balance where LINQ is more readable in certain use cases where imperative code is more readable in others. Ideally for complicated things I would suggest using both or break it up a little. Passing methods into LINQ like. MyCollection .Where(MeetsConditions) .Select(DoMyThing) Then in say your method you could do more LINQ: MyNewObject DoMyThing(MyOldObject oldObject) { return oldObject.Children .Where(x => x.FirstName == "Ben") .Select(x => new MyNewObject(x)) .FirstOrDefault(); } That said the method could just as easily have been something like: MyNewObject DoMyThing(MyOldObject oldObject) { foreach(var child in oldObject.Children) { if(child.FirstName == "Ben") { return new MyNewObject(child); } } }
sacredgeometry (1 month ago)
​+Milan Stevic "I used to be able to do fantastic mental gymnastics in coming up with various algos, and I tend to design coherent data-oriented workflows, but Linq is so convoluted and unintuitive you simply cannot work without a reference." Are you using the method chaining lambda syntax or the statment/ query syntax? Most LINQ methods are pretty self explanatory and are pretty comparable to SQL. That said 90% of the time you are using a really small set of Methods Select/ SelectMany (basically map/ flatmap), Where (basically filter), Aggregate(reduce). Other than that you have simple methods for common operations: First: Get first in collection (if empty throw exception) FirstOrDefault: Get first in collection or default value (if struct then default(Type) if class then null) Last: Get last in collection (if empty throw exception) LastOrDefault: Get last in collection or default value (if struct then default(Type) if class then null) ElementAt: Get Item at index (if out of range throw exception_ ElementAtOrDefault: Get Item at index or default value (if struct then default(Type) if class then null) Any: returns true if any in the collection match predicate All: returns true of all in the collection match predicate Count: Return Int size of collection Sum: Add up a each of the numbers returned by your lambda OrderBy: return a new collection ordered ascending by value returned in expression OrderBy: return a new collection ordered descending by value returned in expression Skip: Return new collection but skip n items. SkipWhile: Return new collection but skip until condition in predicate not met Take: Returns a new collection taking the first n items in collection Take: Returns a new collection taking items until condition in predicate not met. Distinct: Get all unique items in the collection The others I use so rarely but thats most of them that I remembered of the top of my head. If you use them every day for almost a decade then it really becomes trivial. I would say there is definitely a point at which they become indecipherable but they are wonderful when used sensibly...
Milan Stevic (1 month ago)
+sacredgeometry "Can you give some examples of where there are problems?" Well, unfortunately, no, I can't recall anything particular at this moment, but will do if something pops up. I use it seldomly, and ONLY if that would 1) improve readability, OR 2) drastically reduce the implementation (or potential errors). However, each time I need something intermediate-to-advanced, I find myself browsing SO for the best solution and it's been like this for 6 years. Even though I'm not a genius per se, I have high doubts that my mental capacity is at fault. I used to be able to do fantastic mental gymnastics in coming up with various algos, and I tend to design coherent data-oriented workflows, but Linq is so convoluted and unintuitive you simply cannot work without a reference. "They are deliberately extensions because all the collection/ iterable/ queryable types are interfaces and thats the only way to add behaviour to an interface in C# (well an Interface interface, you could implement the interface as an abstract class but thats a digression). " Of course, it _is_ an extension of the base functionality, and I think this decision of having routinely required operations attached as tumor-like extensions is what lends to this general feel -- I don't know, maybe it's simply too much apples and oranges right off the bat, attached to any iterable collections and my brain dislikes it badly for not being able to discern the categorization and feeling lost in the possibilities. "I wont show you the immense horrid clusterfuck that I am having to decipher now if you think LINQ is bad." I trust you, but then I'm a solo coder most of the time, and couldn't get along with others like AT ALL. I find it boring, regardless of the language, because the point of coding should be translating transformative work against the constraints of the machine, not the constraints of people. And people always talk about the coding style as if that's the true demarcation line between any two programmers -- no, it's not the style, I can tolerate that, it's about other people's motives. If my colleague is like "let's finish this so I can go to lunch" in his head, his style will only reflect that. He just does whatever he thinks is the least offensive way to get things "done". That's not a coding style, he'll obviously stick to any kind of style protocol to hide the fact that he didn't think about it. He's just getting things done, he doesn't care for the overall performance or maintainability, that's someone else's problem, or a tomorrow's problem. He lies the entire organization basically, and what exactly prevents him from doing this? And while there are many ways to get things "done", very few are correct (that's the whole point, right?), and LINQ provides many a shortcut to getting things done, some of which are, in fact, more horrible than when the code is obviously horrible, for a trained eye. If you nest several LINQ queries with lambdas, it certainly looks & feels clever, but not even the authors could tell you how well that's performing, especially in context, and how the underlying types might affect the data access performance if changed or expanded in the future (the invisible eater of cycles). But you cannot train yourself to see this -- because there are legit uses of LINQ that look suspicious, in fact, most of them do, imho. We all tend to take things like data access for granted -- there is a cache, it's all abstracted yadda yadda, well I like to be in control, and I like having a mental image of the inner processes at all times. I like my code reasonably well organized between the pragmatism, readability, and performance. It's not as simple as a memory leak, it's this misconstrued transformation that's wasting cycles invisibly, that gets only multiplied whenever you lose your mental grip. This is the essence of coding as a craftsmanship. That's hardly the case with other coders who typically organize their work between their wage, their kids, and skiing. Yeah I sound a bit salty, but I really think there's room for improvement, and a better language design could only help with this -- it needs to be reasonably mnemonic, uniform, and (cognitively) lightweight, with as little special cases as possible, and as few clever twists as possible -- the neatest trick should be the most default one that anyone could think of etc. The next paradigm should be very far away from the OO. I don't know, perhaps it is ECS, but we'll see.
Cezary Dudek (5 months ago)
Off-topic... I don't like the way that Daft Punk's Rinzler song was sped up so much at the closing of the talk.
Rory O Connor (6 months ago)
Excellent talk, truly insightful! 1=D
Virtus Brædder Opstrup (7 months ago)
Holy shit his wig is nearly falling off his back
Procedural programming + FPGAs = Match Made in Heaven?
Zantorc (7 months ago)
Algol 68R was 50 years ahead of it's time.
Patrick Isbendjian (7 months ago)
Goodness, makes me feel old. It reminded me of Algol68, which was taught in my computer science classes in the mid-70's. And also of Professor Paul Branquart who was teaching us compiler construction and was one of the authors of the Philips Laboratories Algol68 compiler... Thanks Kevlin for stressing that almost all the ideas we are seeing pop up now are old ideas in new guise
Ted Mosby (7 months ago)
hahah how did he know i never new my grandfather && i thought al gore was of TV he looks 68
Dan Cook (8 months ago)
Magnificent! In many ways, OOP had taken these old ideas and made them worse or locked down (and this was a refreshing review of history that many are ignorant about). Most devs nowadays think opposite, and to them I provide the following articles which compliment this video very well: https://csis.pace.edu/~bergin/patterns/ppoop.html http://www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end (The first one is an excellent example of how procedural programming is thought of in the limited way that this video describes). My observation is that a lot of modern OO is a long shot process of realizing the good of other paradigms, and then providing them (in a more locked-down or limited form) as breakthrough OO advancements. OO as a culture is more about what is popular and makes you look professional, than about understanding first principles (and historical context) and using them judiciously. This video is a refreshing revisit of history and first principles from which OO (and others) eventually derived.
aylictal (9 months ago)
Nice presentation. I wanted to expand more upon his ideas and say that while pure functional programming is the opposite of the imperative procedural model, they each have their pro's and their cons, which is why procedural is still very valid today, but shouldn't be used everywhere. I think the rule of thumb I try to follow (as a javascript developer that has access to both models at any given time) when figuring out the best implementation or utilization of a paradigm is two things A) Managing State B) Performance. I feel functional programming designs cater to A however procedural in essence caters more to B. Managing state is always goign to be a bitch, but that is the primary concern that functional programming addresses because it attempts to effectively eliminate it. Procedural doesn't necessarily address performance as it's concern, but it turns out that it really is the most explicit way to perform the best because there is (usually) no additional overhead ... niceties if you will. As a couple of examples of the above: Recursion specifically is very much welcomed and promoted in the functional programming paradigm, but the overhead is actually significantly worse than explicitly detailing exactly what you want the program to do imperatively. In javascript specfically, the forEach native method to iterate over an array as a functional method, doesn't even allow you to exit the loop unless you throw a hard exception or error. This definitely highlights the key difference between the two paradigms: a pure function such as forEach vs a native iterative procedural for loop with a nested break condition. This may also be the reason why C took off in the 70s over lisp. Performance was valued moreso than managing state back then because of hardware limitations. Vice versa, in today's era, hardware isn't the bottleneck, it's creation of apps that are doing absolutely insane things that were only dreamed about back in the 70s, which makes managing state the more primary concern. This is why functional programming is the current buzz over procedural.
aylictal (7 months ago)
To additionally add here, my response is that while functional can be utilized to easier convey to other developers their implementation and understanding, it is not often the best approach to do so. Me personally I struggle very hard understanding that ES5 functional implementation, yet the ES6 implementation (functional) is quite easy for me to understand. Likewise, the ES5 procedural implementation is easy for me to understand as well to solve a fairly daunting problem when looked at initially at face value. Perhaps you'd like to try to solve this without even looking at the solution. Heres the problem: Given a 2 dimensional array of positive integer values which form a trianglular grid, where the first row has a length of one, and each sequential row has an additional array length of lastrow+1 length, find the path from the bottom of the grid to the top which will add up to the maximum possible value if traversed, where you can only travel along a segmented line which has to be adjacent to the row below it (example, if you start on the fifth element of the last row, your next traversal point upwards has to be the 4th or 5th element of the next array only which you can traverse).
aylictal (7 months ago)
There is a very good example of a triangle counting problem posted online on how to solve for the path with the largest sum. I will post it at the end of this message. For the javascript solution, there are two answers posted. One is written in a procedural style, and the other is written in a pure functional style (as pure as possibly can be done). I don't think things written in a functional style are necessarily easier to read. as per this example. What do you think? And sorry I am estimating here that you understand Javascript. If you don't I apologize. Also I am referring to the ES5 implementation. After working with specifically JS for the past 5 years exclusively, I feel that the ES6 functional approach is the easiest, however the ES5 functional (haskell translation) is the hardest for me to actually comprehend, and this is all because in ES5 there were no native functional array methods available: https://rosettacode.org/wiki/Maximum_triangle_path_sum#JavaScript
Okuno Zankoku (7 months ago)
Your point is not lost on me, but I just wanted to clear up some functional programming stuff. I don't think forEach is a good example for your argument. It isn't that functional, since its point is to perform side-effects. Also, the idea behind not having early exit in forEach (or its functional cousin map) is that those operations could in principle be vectorized. I don't know of any compilers that currently do this vectorization automatically, but in Haskell, you can manually switch map for parMap to instantly get vectorized code and thereby a performance gain. Second, manually writing recursion in modern functional languages is actually discouraged. Instead, programmers should use a standard library of basic recursion patterns (map, fold, &c), and in doing so , they open up a ton of compiler optimizations. The Glasgow Haskell compiler, even though it's fighting both recursion and laziness, is able to translate large but idiomatic uses of recursion into tight loops. Often, these loops will be tighter than the corresponding hand-optimized loops because compilers are much more comfortable with cross-module optimization than humans. Of course, in Javascript, especially in the browser, your JIT will vary. And because js is a dynamically typed, impure language, optimizations like stream fusion are going to be essentially impossible without incurring too much latency from the optimizer. The underlying reason to pop into procedural is to avoid reliance on the mythical "sufficiently intelligent compiler", and procedural is the only option given today's hardware. I don't think functional is really a buzz for two reasons. Empirically, it's already demonstrated over fifty years of staying power despite implementation difficulties. Theoretically, the lambda calculus and its descendants are the easiest formal theories of computation that can be manipulated by humans at the source-code level, which makes it immensely readable. On the other hand, I do think that functional programming is now a misnomer, and as it becomes a buzzword, that will dilute the important idea: restrict the power of the programmer in order to increase their ability to communicate both with the compiler as well as with other humans. Of course, that's also the idea behind structured programming, so I have hope that we'll keep seeing the idea come up until we get it right.
Filip Majetić (10 months ago)
"X is the dark souls of Y" well who would've thought this had a name
Jared Maddox (10 months ago)
For those who are confused, this entire talk is essentially "Everything that you think is new and exciting is actually really old ideas, so there's a lot of old books and papers that you can look at for help with it. Here's an hours worth of working through this concept." Technically he's right and wrong at the same time, because type arithmetic is not math, and yet it is.
realcygnus (11 months ago)
The evolution of technology is almost as interesting as the technology itself.
moofymoo (11 months ago)
About 15min in video and my inner hipster senses are tingling.
Bryon Lape (11 months ago)
My god....I understand that C code.....I am old...
Milan Stevic (1 month ago)
but... c'mon... in today's world almost every language looks like C, everybody understands it, even my grandma. if it was at least a little bit esoteric, I dunno Lisp-like, it might've been considered a trait of being oldschool, but a C-like syntax is insta-readable, even with pointers.
TheHyperplayer (1 month ago)
I understand that C Code, I am 20 years old and self taught.
Dimitar Getsov (1 month ago)
Sir!!!??! Understanding C code means that You are YOUNG and You will remain EVERGREEN forever!!!!
Gytis Dobrovolskis (1 month ago)
+Ko- Jap Did 75% of students at your college/uni looked like retards in terms of programming as well ?
Ko- Jap (6 months ago)
noxabellus Or someone who went to almost any college... For IT , CS, SE ...etc
Ian Schimnoski (11 months ago)
11:29 😑 WOULD YOU PLEASE: NOT BE A HUMAN WHO SOMETIMES SUFFERS FROM THE URGE TO COUGH!!😬 (Joking😄😄 you're cool, yo, anonymous person who coughed. We all been there; I was once choking to death on water in a movie theater, and then to add insult to injury: I accidently farted whilst trying to choke as quietly as possible... ...it was embarassing, but people politely pretended they weren't aware of it )
Carl Franz (11 months ago)
"Next gen. Object Oriented programming"? Did I miss something?
ck sin (1 year ago)
I spent an hour to listen to this non-sense and I cannot find a single example he talked about which cannot be recreated in C#. Experienced programmer has no doubt that things he talked about are foundation of modern OO languages, those fundamental ideas are actually already embedded in modern OO languages in an improved way. What modern languages are doing are improving on those foundation, because those foundations are not nearly enough for complex programs or are not easy to be used. There is no point to mocking at what "All these crazy 'new' solutions" are doing, it like mocking at electric vehicles(EV) and saying "Haha. What's "crazy new" about EVs? it also has 4 wheels as same as my chariot! See? Chariot is already the solution to transportation, why struggle with EV? They're both the same!". This argument may fool people who know nothing about EV, but we all know this could not be further from the truth. **Laughing at EV** Chariot:It's Back? It Never Went Away ! .... What a clickbait!
Brian Crink (1 month ago)
+ck sin while this thread is rather dated, it should be noted that programming paradigms and design patterns should be considered as tools and used given the appropriate context.
Dan Cook (1 month ago)
+sacredgeometry Yeah, I think I did misinterpret your statement about C# as a claim about OO. It's ironic that as a result, I was making the very mistake that I incorrectly attributed to you. Anywho, I think this exchange has gone as far as is meaningful. Hopefully it leaves interesting food for thought for whomever else reads it.
sacredgeometry (1 month ago)
​+Dan Cook I think you are getting really confused. "I can do it in c#" Is not the same as "I can do it in OO" C# like any modern language and like any modern codebase is a multi "paradigmed" language. This cultist devotion to one paradigm is exactly what languages like this are trying to move away from and instead cohesively integrating and exposing methods of using many of them. LINQ in c# is completely functional and it benefits from it but thinking something like MVVM or MVC patterns work better functionally is just wrong and ideological. No professional programmer I have ever met has had a "I can do that in OO" attitude. They have a "that would be better in OO" or "That would be better as declarative functional" and their tastes may vary but only someone with limited experience and who is exceptionally myopic would say there is only one pattern/ paradigm that is appropriate for all problems because no-one with any real world experience writes code like that. So if thats the predicate for this video then its nonsense and pointless from the outset.
Dan Cook (1 month ago)
+sacredgeometry I'll come back to mixins in C# further down; but back to the point of the video: it's not about what can or cannot be done where, or which paradigm is better; it's that the paradigms themselves have been mislabelled, relabelled, redefined, etc., and often weakened or watered down in the process. The mindset that "I can can do already do that in OO!" is EXACTLY a symptom of the problem Kevlin addresses in this video: helping to illustrate how things have been shifted around and misunderstood and reinvented in weaker ways, and providing some real historical context to show for it. So for example, With mixins, the premise is specifically to be able to inject ("mix") shared code into a class as if it had been written there to begin with. No inheritance, no fragmentation across classes, just a compiler trick so you literally only write the code once, and introduce zero mechanism to do so. (Some languages break these rules, and don't adhere to the formal / original definition and miss the idea). That might sound like I'm being very picky, because for most intents and purposes, that trick (extension methods on an interface) is essentially accomplishing the same thing (and that's an AWESOME technique that I will definitely use -- great share!) ... But the point I'm making is to consider that there may be a bigger picture to something than what your (not you specifically) favorite language or paradigm (e.g. OO, functional, etc.) may present something as. And even if the MECHANISM can (more or less) be implemented, that's not always what a paradigm is about or what actually makes it powerful or useful (or at least it's not the whole story).
sacredgeometry (1 month ago)
https://www.zorched.net/2008/01/03/implementing-mixins-with-c-extension-methods/
hytlerson (1 year ago)
O, čia Lietuvukėj :D
moofymoo (11 months ago)
čau braļuga! :D
Justin Smith (1 year ago)
Nuclear proliferation is Bill Clinton and Obama's fault. They made deals with North Korea and Iran making their nuclear programs possible.
Bacons Strip (1 month ago)
The last nuclear test the US conducted was 1992. NK broke and immediately signed a new non-proliferation agreement with the US in 1994. It collapsed in 2002. NK again agreed to stop producing weapons in 2005, then broke the deal again in 2009. Saying any of those agreements or breakdowns that happened across all presidents in the last 20 years had anything to do with something other than NKs perpetual efforts to stall and hide their production of nukes is hilariously stupid and really goes to show what a laughable partisan shill you are. Intelligence agencies are saying once again NK started producing nukes after telling Trump’s administration they would stop. Surprise surprise... this is why you never say mission accomplished like Trump did after dealing with Kim. NK is an authoritarian regime and just like all authoritarian regimes is led by a compulsive liar.
Pedro Montoto García (1 year ago)
The talk that spawned ten thousand startups based around Algol 68
Timothy Johnson (1 month ago)
I'm building an Algol to JS transpiler right now. It'll be the next Heroku
keedt (1 month ago)
​+John Karavitis Not in the slightest. Reread Elite7555's comment and reread mine. Think. He clumps together Algol and Fortran and says two nice things about them, but if you check carefully the first only applies to Algol (although beauty is in the eye of the beholder, but few people would call Fortran beautiful) and the second only applies to Fortran. It was a riff off the old quip: "your book is both deep and original. Unfortunately, the parts that are deep are not original, and the parts that original are not deep." Get it now? try to think before you post next time, you might learn something.
John Karavitis (1 month ago)
+keedt English comprehension problems much?
keedt (7 months ago)
I see what you did there. Algol is beautiful and fortran is in use ;-)
Elite7555 (8 months ago)
In fact, Algol and Fortran were beautiful languages and are still in use for scientific programming, and not only for legacy's sake, but because they are much easier to teach than C++ and they are better suited for certain numerical operations.
ronP __ (1 year ago)
amazing!
Alexey Lyahov (1 year ago)
This is highly educational! Thank you
Sergio Díaz Nila (1 month ago)
actually no, it is misleading & misinformed because all the things he claim were invented in ALGOL68 really come from LISP (1958), John McCarthy creator of LISP was member of the original ALGOL68 team and he included all the features he and his own team designed with LISP.
John Appleseed (1 year ago)
I believe this guy takes advantage of a subset of programmers (or aspiring programmers) who are desperate to escape complexity and are also vulnerable to vague promises of "a better way". He is right about one thing, though. Procedural programming never "died". It's used all the time and is entirely appropriate sometimes, just like the other paradigms. I'm all for pushing the boundaries of what it means to program, but this guy often revisits things which have been thoroughly tested over the decades; the strengths and limitations of which are well known, but he's presenting it like it just might be the magical solution to your complexity ills! He's a decent story-teller, but he doesn't have any concrete solutions.
Phil Adams (9 months ago)
Yeah, this talk starts out great but kinda goes nowhere. Well, it does go SOMEWHERE, just off course a bit. He's a great speaker though and has some other good talks on YouTube.
John Appleseed (1 year ago)
+noxabellus I can see that and it's a good point, but I also hear loads of talking without much content. He dances around one common sense idea for an hour essentially restating his case over and over, alluding that when he finally gets to the point he's going to reveal that 'one simple trick'. Of course we know there's no simple trick, but that hook is powerful and I think he knows it. Anyway, you took away a good message, so maybe it's not as slimy as I think.
noxabellus (1 year ago)
Quite a different take than I had. It seemed to me he was doing just the opposite, and saying "All these crazy 'new' solutions youre struggling with for complexity arent actually new and if you knew the foundation of the ideas you might be better able to achieve your goals"
Min Luchs (1 year ago)
the hardware architecture with registers fits to stateful procedural programming. Neumann messed it up I guess. oop + procedural programming crap. each object having his own api. so you learn each time everything from start. dynamic language makes it even worse. Why is python and golang so popular?
Milan Stevic (1 month ago)
+moofymoo "OOP alows to write more robust-idiot proof code. You don't want idiots to mess with registers/global variables/goto in procerural code and then blame you for errors. In ideal world, where all programmers know what they are doing, there would be no need for antipatterns and extra safety nets." You're striking the core of why we need OOP in the first place. It was never about the paradigms, or about the philosophy of data management, it's all about the conservation of maintainability and forced "black box" encapsulation due to only TWO BUSINESS CONSTRAINTS. 1) Code tends to be proprietary (i.e. secret), but its authors still want it consumed (i.e. sold). 2) Programmers should be cheaper -- so what if we had a system that allowed idiots, but they couldn't mess with registers/global variables/goto too much? Enter OOP as an organizational paradigm. Hence the patterns as well. It's a system for massively employed idiots with only a couple of software engineers (that can get fired as soon as they establish the flywheel*), and an uptight upper management who get to tinker with the specification. The axiom is that the best programs in the world tend to be produced by extremely small teams or even solo on the humblest of hardware. Corporations can churn out only shit that wastes electricity, and then drag that shit through vast QAs until it stops smelling. It's a game of high-level predictability in iterative management, not engineering efficiency, or god forbid, competence. For that reason, OOP is still strong, because business management has zero incentives to push the envelope in using more productive paradigms, because then they depend on having fewer highly proficient people. Not going to happen any time soon. * This is basically what kickstarted the startup culture. Capable people work for corporations less and less, because individuals can have access to their own market and demography. And the only natural counteroffensive is not to improve coding standards, but to build monolithic technologies that employ production lines of hundreds, even thousands of people, until a bar is raised so much that anyone solo or small cannot do anything comparable in a lifetime. Of course, there is a strong synergy with the hardware manufacturers as well. Then you have an underdog corporation that pokes the dominant one in the eye by letting the startup culture use its yesteryear's tools, or its market platform, and this is what's been going on for at least 20 years now. Open source my ass. Everything would collapse if we didn't have access to open source or automated marketplace -- it's an external public RnD and baseline comparison for the rest of the proprietary industry. A 3rd party proxy for business moves and countermoves, so to say. This is exactly what picked up Linux in the 90's. And this is exactly why .NET has been made open source as of lately. Not to mention UDK, Unity and similar game engines which are practically free to use, to counteroppose the big entertainment industry (or, in actuality, feed the scene with breaths of competence and baseline comparison).
TheRainHarvester (1 month ago)
moofymoo it's not a tax at Intel or nvidia or ATI. We use automated testing per check-in. Speed is king. No excuses!
Gytis Dobrovolskis (1 month ago)
+moofymoo I was replying to this part "where all programmers know what they are doing, "
moofymoo (1 month ago)
+Gytis Dobrovolskis noone write code without bugs. What I was trying to say is that encapsulation (safety nets) is tax all programs have to pay to somewhat limit what bugs appear where.
Gytis Dobrovolskis (1 month ago)
+moofymoo Barely anyone writes code with no bugs. You might have meant very smart perfectionists, and average very very slow programmers or smth.
toferj (1 year ago)
What's with the crack about Americans counting floors in a hotel "wrong"? Why do so many people try to make me feel bad about where I was accidentally born? I can't help that we use imperial instead of metric, or spell some words differently, or any other stuff. Why do they think it's funny to take the piss out of us because of stuff that we can't really control? Well, I apologize, sir. I'm dreadfully sorry that I was born in America. I'm not particularly proud of it. But thanks for poking me in the ribs (you and others like you). I'm just tired of hearing this kind of thing. I consume a lot of British media online, and I this kind of thing happens a lot. I'm just tired of being made to feel bad for where I was born.
storerestore (1 month ago)
This is probably the funniest, most inconsequential thing I've ever seen someone be upset about.
Ko- Jap (6 months ago)
Chris Jordan 2018 sensitive American is a must to find on YouTube .... Stop bitching nobody cares
Sean Ramey (7 months ago)
+Chris Jordan While I can see were you are coming from, you can't just expect others to keep opinions and certain thoughts to themselves because they might offend somebody. You know, there is something great about being born in the U.S., and that is that we have so many rights that we take for granted sometimes, such as Freedom of Speech. And I think others have left some good advice, so I'll end my comment here.
noxabellus (9 months ago)
This is only hilarious because you'r probably one of those people who goes around calling other folks snowflakes.
Ryan Fleury (11 months ago)
troll?
tOmzz4video (1 year ago)
Very good talk!
Cees Timmerman (1 year ago)
Nice talk. I love how you leave out the semicolon clutter, but suggest you oneline the "goto fail" style at 28:52.

Would you like to comment?

Join YouTube for a free account, or sign in if you are already a member.