As someone who falls into very easy trappings to be elegant and descriptive in my code, this video is a must revisit to remember what matters is keeping it simple, instead of using fancy coding paradigms. Classes are fun to play with, but I am increasingly convinced for most tasks, especially in regards to computation and data science, it is better to use them sparingly
Take aways from this talk and the comment section (note: I am including several quotes from the Zen of Python and PEP 8). 1. Classes are useful, but foolish consistency is the hobgoblin of simple minds. 2. Simple is better than complex, complex is better than complicated. 3. Practicality beats purity 4. When the tools you have already work: use and adapt them for your use-case. Don't reinvent the wheel with a class every time you happen upon a new problem. 5. People will miss the message because their beliefs and tools are attacked.
@@oysteinsoreide4323 Yes, but the unnecessary verbosity of (e.g.) The MuffinMail example in Jack's talk is far from readable. Whereas, his reduced version is both readable and quickly understandable.
Not an expert by any means (self-taught), but for most cases where I've been tempted to innovate something fancy, I just start by typing out what I want the user of my code to be able to type as instructions. Work my way backwards from there and figure out the "how" of the implementation as long as I already know the "what". I have used classes so far to help me conceal non-user methods (implementation hiding I guess; less options for users means easier learning curve and Python doesn't appear to have access modifiers as an alternative option). Has also helped with the purpose of some abstractions too.
I agree with a lot of this, but not at all the exceptions part. I like it when 3rd party libraries define their own exceptions. It makes it much easier for me to figure out the cause of the error.
"Code is read more times than it is written", and in production environments the programmer is not the one reading it. This quote, thanks to whoever said it first, is the first principle for whether to use classes or not. Whatever makes the code more readable and therefore maintainable should be used.
I think the take away here is simply that very often people tend to overdo some code steps systematically just because they learned that this was "the proper way" whereas it might actually just be making the code complicated and large uselessly. This guy isn't the first I see to make the point that this whole deal of making your code super complex for the pretended sake of future flexibility and time saving is a bunch of garbage and typically just ends up eating more time than it saves. I think there's truth to this. Also you gotta remember that everytime you complexify one of your APIs you're making the learning process longer for any new employee in your organization. I think over the years there's been a dogmatic approach that's built up in OOP and not always for the better.
The key takeaway for me is: Don't foolishly design everything as classes. Functional programming is way more efficient to read, write and test. Only use classes if you need complex objects.
Hmm, this guy has some good points. 1: Mostly no point in abstract base classes in duck-typed languages. 2: No point in making function objects (functors) when there is no interface concept. 3: Less code is mostly better, but only if it is simpler. 4: Preparing the code for the future is ok, if it requires minimal effort. Otherwise it is pointless. 5: Namespaces should not be abused. But they are helpful sometimes, for organization purposes. In auto-completion lists they are crucial.
I don't tend to enjoy tech conference talks, but I've watched this one several times. I'd guess most of us have encountered many different arguments for simplicity in software design, but I really enjoy this one in particular for some reason
"I hate code and I want as little of it as possible in our product" - Jack Diederich "We usually think of code as an ASSET, a valuable thing that we shouldn't delete. Code is a LIABILITY - all code is cost " - Dan North
A curious thing about this presentation (though it is an old one), is that what actually happens when some java/c# programmer accidentally starts writing in python/ruby scripting language.
@@harrypadarri6349 in Ruby everything is an object. In python you can get alot done with just imperative. It doesn't lean on the OO style anywhere near as much as C# and Java. Most Python dependencies are very OO though. I once tried to write functional Python code. It didn't go well.
@whossname You’re right with that. Python has so many built in datastructures and additional libaries that you can write pretty nice code that appears to be imperative. I once wrote a programm that did use only one single self-written class in over ten thousand lines of code. I am not talking about style but the inner workings of python. There everything is an object. Including functions used for functional programming. Unlike C where variables just point to a place in memory where a value is stored. In my CS lectures professors meant that distinction when saying „everything is an object“.
No? I've done Java and C# for forever and my first time with Python I just ran code directly without any classes. Just because I'm very used to it doesn't mean I can only code in classes
Keeping it simple is why Python is so appealing to me. Life is easier when you don't have to wade through 1000s of lines of boilerplate and code-bloat.
Yes, but you can also write code without boilerplate and bloat in C++. Python however makes writting, debugging and maintaining any reasonably complex project near impossible. It turns out types and identifiers make things easier, not harder, in the long run. The easier it is to write wrong code that still compiles and executes, the much harder it gets to write nontrivial programs.
Adding "Exception" to the name of an Exception does help. It helps if you're facing a library that has numerous exceptions and you just want to search for those. You could open the type hierarchy, but you could also just search for the type name, like "*Exception" and it will list you all of them. Programming is not just typing, it's also searching.
You, every time I turn around someone sais the contrary of I was told before. "Divide and conquer to solve your problems and make your program as easy to mantain as possible", then "Don't overuse classes, they reduce eficiency and stuff".....
The important lesson. Do not creat abstractions "just in case". It is easy to add them in the future if needed. Keep it as simple as possible. No wrappers. No custom base classes. Things like debugging and tracing can be solved other ways.
Maybe it comes from the C/C++/Java days where it was hard to patch things in when you needed them. No new means no need for factory methods, properties means no need for getters/setters, closures can be upgraded to objects with __call__, optional arguments, no difference between classes, objects, or modules, duck typing means no need to rewrite your code when you change your class hierarchy, classes/objects/modules can be swapped around, dynamic typing works sort of like duck typing and mypy's errors can be ignored..., iterators is the default, you can add data to classes, decorators, context managers changing globals, __getattr__... However, Common Lisp is even more hardcore than Python in that you could always use something like JQuery on your s-expressions to refactor it, optional return values and you could locally change progn, let, defun, etc... and turn functions into macros that alter the expression trees of their arguments...
Very useful message. Scala is probably one of the best languages to strive for the balance the author suggests between classes and functions. Python is moving that way, but it lacks the type safety. Very interesting and actually useful for every day work with python. Thanks!
@Michael David lol. You're an idiot. You're making a big deal out of nothing. Okay, "recalc" isn't a perfect name. So what? Any idiot can still see what it means and what data it holds: it's the set of all points that need checking to see if they're alive in the next state (or all the points that need to be "recalculated"). Also, I've seen professional code with much worse variable names, so your assertions about "any second year comp sci student" are full of crap anyway.
I've been using dataclasses quite a bit recently. I like them better than dictionaries when I need mutable named tuples or want to define data schemas. The typing library and typehints work nicely them as well. I wonder what Jack's opinion would be about using a dataclass when you could have used a dict or a tuple?
@@williamkmanire His talk is more about unnecessary use of classes as pure method holders. I doubt he'd object to a data class that defines a record or otherwise combines multiple related pieces of information. That said, I find I almost never need those classes to be mutable. Allowing them to be mutated usually makes the code more difficult to reason about (especially if you're stuffing intermediate values into its attributes), and avoiding that is usually a simple matter of doing any computation using local variables or another function before calling the constructor. (The dataclasses module has replace for if you actually need to change values for some reason.)
Classes have there place in programming as the questioner in 23-25 minute indicated but I do agree that many programmers do overkill. Helper functions can just be functions instead of a class with loads of static functions.
I think at least part of it is because so many people learn Java as their first programming language. Python has classes and objects as a feature but they're used to programming in a language which is built on classes and objects from top to bottom.
I don't know. I feel Exceptions are the exception (hehe). Having a Stacktrace where the first word already tells me what is the problem. Having an UpdateException(MyModuleException), DownloadFailedException(UpdateException), and InstallFailedException(UpdateException) giving me the alternative of what to try/except is quite important. Or let's say it otherwise. I simply don't know how I would do that exception handling stuff without all the subclassing.
I love what he's saying.. but when I go out for a programming interviews 99% of the time... they want me to write things as classes to solve the given coding test. No matter how inappropriate it would be to the test.
This is an indication that you are interviewing with a company that doesn't share your values (and lacks common sense). Filtering out bad employers is a great outcome for interviews.
That's how you know where not to work. Classes create bloat in terms of code complexity, execution time, and computer memory. Everytime a class is written, make sure you have a good reason for it.
Classes are great but they are also overused. This talk describes examples of class overuse taken from real world code and refactor the unnecessary classes, exceptions, and modules out of them.
I agree to a certain extend but we did not mention was the fact that Classes have a fundamental task of making Business Logic look readable and easy to implement for less technical people, often functional administrators.
@@raianmr2843data classes are a shame in the world of OOP. They break encapsulation, introduce mutable state and result in functionality being spread across the codebase. Burn it with fire.
@@user-lk1fw1lp8b Spaghetti code is when you see a simple function call, but actually it is a dynamic dispatch over an inheritance hierarchy. Spaghetti code is when numerous layers of indirection are pretending to be "simple" linear code. OOP is spaghetti code.
His point at 5:55 or so was great. If you know for a fact that you will need to use something later, then of course writing a class may be useful. But if you don't have any reason to need it later right now then don't try to plan for a 100k line project that will probably only ever be 1k lines max
How does print glider, where glider looks like a 5x2 staggered array of ints, magically turn into circles in a moving grid (the advance function changes the contents of the array, not draw anything)? Unless print has been overridden with a custom screen rendering routine.
I was wondering how they were going to graph their raw data, too. Any suggestions? Anyone? Guess maybe i'll have to look at some other people's GOL programs to see how they like to graph things in Python. Maybe Turtle Graphics (my speed).
His message was not to stop using classes but stop using classes for simple things. Lot of people misunderstood. Classes are useful when they are needed but too much of class objects with bigger code makes it slower. No Offense.
@@cwill6491 the things is lot of people are here fighting against each other one who likes classes and one who don't and some python haters! I don't know why this people just learn something new and appreciate it instead of fighting over each other. Why hating python in comments btw? What you think about this brother.
@@lordtejas9659 python breaks a lot of conventions. For example, declaring a variable globally doesn't necessarily make it global. You have to use the keyword global in every scope you want to use it in. Some people might not like stuff like that. If you can put that aside though, python is so useful. You can ignore many programming issues and get a prototype working quickly.
@@cwill6491 well I never got an issue with local and global in python. I have coded more than 100k lines in both python and C++ within this years. I use C/C++ as well as Python. What I was saying that to stop people for fighting over stupid things like they are tools and people misunderstood the message of the video. But this students from IT and freshers don't understand the basic concepts of Programming and starts fighting. If C++ was good for prototyping then why we even needed python in first place..thanks for your opinion friend. Have a nice day. Hope this message stops this new kids from fighting. It feels like civil war.
“If implementation is hard to explain then it may be good” Reminds me of pthread vs c++ thread. It is easy to implement in c++ but unless you program in pthread, various multithreading problems, you will not learn the conceptual ideas related to it. It’s about whether you are becoming code money for corporations or actually becoming a good programmer.
In python, i only use classes to define complex entities or objects and hold their respective attribute data. Doing this it helps maintaining the code and reduces code repetition. Example: function overriding is repetition.
22:33 I think this guy has a point with regards to implementation hiding. If you use a plain old dictionary everywhere in your code, but then later on realize you actually need some other data structure instead of a dict, you're going to have to change a hell of a lot of code. If you hid what data structure you were actually using behind some interface, then you can swap it out easily, only changing the code in 1 place. Is there a way to do that without interfaces/classes?
@@trampflips101 There is another way (and it is probably older than interfaces and classes). The translation units! In C you can easily hide data structure you use just by not defining it in header and defining it in source file. The same goes with functions that deal with that data structure. Make them small (their only purpose should be to deal with the data structure) and static (so they are hidden), and whenever you need a different data structure replace them with new functions working for the new data structure. Or make your project modular and that data structure and its "methods" as just another module - you can still replace that module any time you want, but it will not be hidden that way Just ask yourself if it needs to be hidden, if yes then you have the first solution, if no - probably the latter one is better The first solution is the best when the data structure is so small and easy to implement that creating another module is an overkill
Right, there is a nice quote (I think of the French Voltaire): "A book isn't finished when you can't _add_ any more words, but when you can't _remove_ any more."
damn... still or even more relevant these days after 10 years. No fancy words, straightforward. Great honor to have good people on python in the past although today many went to other lang and communities.
@@eecarres That's true but since "neighbors" is used exactly once, you can add a skip clause (if dx==dy==0: continue) in the body of the loop and the whole thing would still be simpler.
@@dionbridger5944 It's used twice: once in generating all the points to recalc and once in the live neighbor counting. I like the fact his solution avoids invoking an if condition on every loop.
@@BladeOfLight16 18 evaluations of a signed int equality test is computationally speaking, nothing, unless maybe you are running your program on a clockwork Babbage engine. Even for a million iterations, it comes to 18 million operations, which on a puny 18 mhz CPU is a total of 1 seconds worth of CPU time.
BTW you can get away with a succinct 2 line function without any equality test: for i in range(8): yield x+[-1,1,0][(i//3)], y+[-1,1,0][(i%3)] And the fact that the "function" is only 2 lines means you can probably get away with not having it be a function at all ( depending on where it's called from ) and just in-lining those 2 lines. So not only do you save on the if-clause, but you spare your Babbage engine the cost of doing a jump operation too ;)
This is more of a "Know Your Standard Libraries and Use Them" video. That is probably how he did the first "amazing" code side reductions. Also my heapq module does not have pushleft and popleft methods in his heapq, plus I think there's a bug in his popleft method if the user did not define a key function. (He passes the second element of a tuple which is only created if there is a defined function). I guess the main thing I agree with him on is I hate typing long identifiers...
If the user fails to define a key function, the key function defaults to 'lambda x: None'. It's right in the __init__ argument list. So there is no way to get into the guts of the class without having a key function of some sort defined.
Break everything down to their constituents and easily manage the larger problem; paraphrasing a Japanese proverb: you can ignore the big problem, it's the little problems you must address. Stub code a life hack! good vid!
I advocate for good design and structure, but also I strongly agree with not over design, one should plan for the future but not invest too much effort on it. for example I'll model this as a class because it has a good chance to be overload or subclassed, but I'm not creating the whole inheritance structure.
Edit: three years on, I don't think my comment here is correct at all. It might read convincingly but I didn't know what I was talking about. I wrote garbage code because of this mentality. Someone in the replies said I was conflating abstraction and good naming, and that's exactly right. --- This presentation is an attempt by someone who has a good point to overstretch that point way beyond reason. His game of life rework is very confusing (19:48). I have no idea what it's actually doing. I don't know how the game of life works, so I can't look at it with the luxury of already knowing what it does. I have to read it line by line and hold all kinds of information in my head at once to understand it. One of his lines has 4 steps' worth of nested function calls. Wtf? That's not simple code. If he abstracted those steps into individual logical leaps, each contained in a function with a _descriptive_ name, it would be so much easier to read. And, when you have a bunch of functions that depend on one another... You guessed it. You should put it in a class. He's using the complete wrong metric to judge whether classes are good or not. Classes allow you to compartmentalise a problem. If it assists you in compartmentalising the problem, *it's good*. If it makes the problem more complicated, *it's bad.* That's it. Obviously, the MuffinHash example is bad, but the reason has nothing to do with whether they used classes. The reason is that those classes make it _more difficult_ to conceptualise the solution.
I don't know why you find his Game Of Life code confusing. It took me 20 seconds to read and understand it. I assume you just aren't used to functional programming paradigm. But it is not his fault. With practice you can read it as easily as 100% imperative code. I find that I can read his code as a book: read it line by line, never look back. It is very easy and pleasant to read. And if he had 5-10 functions/classes it would take me longer to read and understand it, having to jump from one place to another. My only problem with his code is it's performance (obviously, I hope). But in exchange for this ineffectiveness you get GOOD readability and development speed. P.S.: If i wanted speed, I'd use C.
The _point_ of an abstraction is to allow you to understand the solution without understanding the lowest level of detail. You can still delve into it if you want to. Being able to paper over your ignorance is a _good_ thing. Programs that force you to understand the entire program just so you can understand a part of the program are bad programs.
I don't know python, but I was able to read and understand what that code does. The only part that was hard to understand was `board | set(itertools.chain(*map(neighbors, board)))`. But that's fixable, just add an extra local variable, and it'll become easy to read. And probably one more variable for `(neigh in board) for neigh in neighbors(point)`. > You want to code quickly and with minimal abstraction, I want to code in a way that's easier to maintain Eeh, I don't see a collision here. Minimal abstraction = easier to maintain.
Over-compartmentalization and over-abstraction is a sin to be avoided. I would not want to maintain your code. It's probably about 10 times more verbose than needed, inefficient, hard to read and therefore buggy. Smaller and simpler is better. The problem with OOP is that everybody thinks *their* problem is so *special* and needs special classes. Not so. Do us all a favor and use as few classes, methods, functions and lines of code as will get the job done.
Although in the game of life he has reduced the number of lines, I don't think it necessarily made the code easier to understand. It's easier to reason about cells in a board than reason about an "advance" function. Adding more possible cell types would already make this advance function too complicated. Anyways, I got the idea of the talk, always good to keep in mind that Python is not Java and that not everything must be a class
I have seen Game of Life's with different rulesets aka advance functions, but I have never seen one with different cell types. Don't generalize, if you don't know for sure, that you'll need it tomorrow.
most programmers don't use too many ideas from functional programming or aren't well acquainted with it. since he's using a few fp functions in the main function, so the code seems barely readable, but if you look closely it's actually quite okay. implementing it with classes would just slow down the code considerably while not adding anything useful.
Code in C. If you feel the urge to create an unnecessary class it will be a little more difficult and this will give you more time to come to your senses.
GogL0L C++ doesn’t force you to do anything, that’s half the problem collaborating with it. I don’t do OO. I do data oriented design, which C++ is great at.
But idiomatic Python code is different from idiomatic C++. When working in a "data oriented" fashion (in Java or Python), I tend to only use build-in types and write classes only when necessary. All those terms are pretty much related to C++, Java [,...], or C# styles of OOP, as you get pretty much no coupling at all when you use to build-in types and write classes only when necessary.
I find it amusing that my first impressions of what this guy had to say were completely off. I thought he was completely against classes in code, but what he was really speaking out against was a flagrant misuse of them that I hadn't even been aware existed.
Class Flow may be empty, but there's at least two reasons I can think of to keep it: 1) You want a way to test an object to see if it is a "Flow" (via isinsance, for example) 2) You want to allow the users of your code to subclass it and implement their own Flow class. Mr. Diederich doesn't seem to give the "benefit of the doubt", or even attempt to see why the code was written this way. The first audience question hinted at that, but the speaker never gave a real answer.
this guy has a point, even if at first he sounded like weird. In my time, I had to suffer tracing unnecessary class abstractions in C++ made by some kid (the management thought was a superstar) and now left for singapore. And when i looked and followed thru his abstractions, i began to realize that this OOP thing along with its power to create artificial abstractions is rearing a generation of ignorant developers later building on top of these abstractions. The BSD socket beauties and tcp/ip headers are hidden and instead exposing some get/set methods. It is true, that abstractions are powerful tools, but if you are not careful it can also lead to ignorance and decadence. To me, the first thing is the electrons and their properties of producing boolean logic. If you are aware at this level, then you will fear the days ahead when quantum computing comes. This is then followed on by protocols, and then the core libraries. It was from that experience that I started to move away from C++...
The person who asked the first question about functools proves why you should uses classes whenever possible. Having access to data is the best reason to use classes. Functions have local variables that you have no access to, but with a class you can access all the local variables. Data science!
That is one of the best seminars on programming I have heard in years: you should travel the United States and give seminars on programming: How To and How Not To.
Python had functions before it had classes. This is a Good Thing, because it means functions are powerful, first-class objects. Take advantage of this. Use them in conjunction with classes, by all means.
Actually, the fact that you have to create exceptions (most of the times) is because that would make it easier for documentation, when you have to create a document with all error cases with their respective error message, it is easier to create a package for exceptions only and have a custom exception for each error possible, also, OOP is on developer's option, Django framework (for example) is full of classes, and you actually follow MVC pattern which is an OOP pattern, and people still complain, I just don't see why, I mean, it's not everyone else's fault if your co-workers doesn't know when to write a class or not (or even how to do it properly), just saying..
You forgot one of the main goal of writing code, and that's readability. You're not writing code for computers to understand, but for human. People like you only make life harder for other developers like hell.
People who write 200 abstraction layers to do simple thing does not make things more readable. They claim the do but in reality they are just uncle Bob Worshippers who want every person on the planet to write code the same way.
All I know is things like typealiases are trash and classes are often overused as well. When debugging it makes things so much easier and quicker and intuitive when for ex an int is properly typed as an int and not some bs name you made up so that now I gotta go digging through the docs just to find out what basic/primitive type your alias is hiding. I find this bs in swift alot. But what do I know I'm just a noob.
imho , if your writing code for humans to read , write a book. if your writing code that also has to be read and understood by other people , you might do some adaptation for that purpose but especially if future you is one of those other people
You write code for people to read, not for computers to save space. I'd rather have 10 times as many lines of code that I understand instantly, then one tenth that I need to ponder for hours about until I get all the edge cases
@@Amine-gz7gq Seriosly? How is it crap? Objectivly or subjectivly? Is is the comment itself that you think is crap or is it the information it is trying to convey?
I'm not sure , but Python does NOT offer static classes, which are great way of ORGANIZING similar functions that do not require an instance. I look at the file where the residing function exist as static classes in Python. Classes are great for organize a common DATA STRUCTURE... To say to stop using classes is a bit extreme...
I goda disagree with what he was saying at 4:30, information hiding, encapsulation, seperation of concerns, etc are very important, and it is extremely difficult to make easy to understand, maintainable software without them.. However, what he says about speculative design is very true.
No, information hiding makes code unmaintainable. What makes code maintainable is readability and clarity, first and foremost. Obfuscating simple code behind layers of classes makes code a maintainability nightmare.
When including an external library that has a bad or illogical interface, encapsulating it (facade pattern) lets you hide the bad parts and ensure that your team only uses it right - it can also allow you to add correct logging, error handling, etc. to code you can’t refactor because it’s third party
Separation of concerns: actually usually creates simpler more readable and more reusable code with fewer side effects; I find that when this comes up in real life it’s usually not because someone is trying to pull a fast one, but rather because a more junior dev is doing something like putting API input validation logic into a DB stored procedure where it can’t be reused.
Of course you should always be wary of premature optimization and overengineering, but this guy sounds like a lazy/semi-skilled dev who never found that balance. He elevates simplicity before all else and throws out decoupling, encapsulation with the bathwater when there are very good reasons why those are best practices
Did I just watch 25 minutes of talking that can be compressed to the two sentences: "Think before you write" and "Look at the standard library to see how a language was intended to be written"?
That’s both because a lot of errors are at compile time and raising exceptions is slow when compared to error codes. If it wasn’t that raising exceptions is (comparatively) slow I’m sure there’d be a lot more.
That glider code and his admission that he hasn't had a single discussion about decoupled and cohesive system design with another engineer in >15 years pretty much tells me everything I need to know.
"1: Mostly no point in abstract base classes in duck-typed languages." Especially in those in which can have mixable traits. (Well, perhaps they could be used for documentation purposes, I don't know.)
@@edwin-jq4dp Google uses Python not just for machine learning, but for almost everything that isn't ultra performance-critical (in which case they'll use a bit of C++). www.quora.com/What-is-Python-used-for-at-Google The very site you're writing on (CZcams) is written in Python.
My understanding is that OO is chiefly about extensibility. Yeah, you could always make it extensible later but extension often happens in small increments, and for any given small change you are likely to make the extension in non extensible ways. By the time you wake up and realize your code should be in an extensible format all along, you'll have a lot to rewrite since all those small changes added up.
OOP Code which uses Classes and Inheritance is usually some of the least extensible code I've ever seen. The only thing you want to allow in OOP if you want extensibility is Interfaces. Sadly most Java Programmers I know seem to be unaware such a concept exists, using abstract base classes even where it's equivalent to an interface. OOP in general tends to overspecify and reinvent... All the things constantly. Even their own terms. Look at the famous "strategy pattern". It sure is great, I agree. Now look at how an interface is meant to be used. Oops. Thats the same fucking thing. Maybe just learn how to use a fucking interface before coming up with new design patterns.
For the "Game of life" I'd just fill a buffer with one background color at startup, loop through the color-values and if I find a color that is not equal to the background color, I'd apply the given rules.
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
- Antoine de Saint-Exupery
my amputee friend disagrees
Great Quote.
@@touchestoomuch Me, and other poor people disagree!
Same thing said Michelangelo: that sculpture is finished when there is nothing more to remove.
I must add that to be true to this ideal you must not target solving everybody's problem.
As someone who falls into very easy trappings to be elegant and descriptive in my code, this video is a must revisit to remember what matters is keeping it simple, instead of using fancy coding paradigms.
Classes are fun to play with, but I am increasingly convinced for most tasks, especially in regards to computation and data science, it is better to use them sparingly
Functional style with sprinkles of classes to hide functionality
Take aways from this talk and the comment section (note: I am including several quotes from the Zen of Python and PEP 8).
1. Classes are useful, but foolish consistency is the hobgoblin of simple minds.
2. Simple is better than complex, complex is better than complicated.
3. Practicality beats purity
4. When the tools you have already work: use and adapt them for your use-case. Don't reinvent the wheel with a class every time you happen upon a new problem.
5. People will miss the message because their beliefs and tools are attacked.
Zen also says "Readability counts". That Game of Life implementation, short though it is, is not readable.
@@soberhippie i think it was readable... code is like poetry -> some like, some don't
@@ZapOKill most coders aren't making art, they're making systems. Consistency is always going to win out.
@@soberhippie Exactly. Readability is the most important measure of a good program. Not how long or short it is.
@@oysteinsoreide4323 Yes, but the unnecessary verbosity of (e.g.) The MuffinMail example in Jack's talk is far from readable.
Whereas, his reduced version is both readable and quickly understandable.
Not an expert by any means (self-taught), but for most cases where I've been tempted to innovate something fancy, I just start by typing out what I want the user of my code to be able to type as instructions. Work my way backwards from there and figure out the "how" of the implementation as long as I already know the "what". I have used classes so far to help me conceal non-user methods (implementation hiding I guess; less options for users means easier learning curve and Python doesn't appear to have access modifiers as an alternative option). Has also helped with the purpose of some abstractions too.
self, nice one
This is the correct mindset and curiously very rare
I agree with a lot of this, but not at all the exceptions part. I like it when 3rd party libraries define their own exceptions. It makes it much easier for me to figure out the cause of the error.
And much more, to catch them specifically and not some unrelated one.
Even though this talk is older, I find it so relevant and interesting still today
"Code is read more times than it is written", and in production environments the programmer is not the one reading it. This quote, thanks to whoever said it first, is the first principle for whether to use classes or not. Whatever makes the code more readable and therefore maintainable should be used.
And, do classes make code more or less readable?
@@jeroenvermunt3372 Both
I think the take away here is simply that very often people tend to overdo some code steps systematically just because they learned that this was "the proper way" whereas it might actually just be making the code complicated and large uselessly.
This guy isn't the first I see to make the point that this whole deal of making your code super complex for the pretended sake of future flexibility and time saving is a bunch of garbage and typically just ends up eating more time than it saves. I think there's truth to this.
Also you gotta remember that everytime you complexify one of your APIs you're making the learning process longer for any new employee in your organization. I think over the years there's been a dogmatic approach that's built up in OOP and not always for the better.
The key takeaway for me is: Don't foolishly design everything as classes. Functional programming is way more efficient to read, write and test. Only use classes if you need complex objects.
Pair programming is one way to reduce this problem
Pair programming is one way to reduce this problem
Hmm, this guy has some good points.
1: Mostly no point in abstract base classes in duck-typed languages.
2: No point in making function objects (functors) when there is no interface concept.
3: Less code is mostly better, but only if it is simpler.
4: Preparing the code for the future is ok, if it requires minimal effort. Otherwise it is pointless.
5: Namespaces should not be abused. But they are helpful sometimes, for organization purposes. In auto-completion lists they are crucial.
I don't tend to enjoy tech conference talks, but I've watched this one several times. I'd guess most of us have encountered many different arguments for simplicity in software design, but I really enjoy this one in particular for some reason
"I hate code and I want as little of it as possible in our product" - Jack Diederich
"We usually think of code as an ASSET, a valuable thing that we shouldn't delete. Code is a LIABILITY - all code is cost " - Dan North
One of my favorite Python videos. Every example is so on point.
A curious thing about this presentation (though it is an old one), is that what actually happens when some java/c# programmer accidentally starts writing in python/ruby scripting language.
Artem Zhuravlev he realizes waste of time and effort, his engineering was over engineering.... It's really a heart breaker
@Joe Boxter
Uhm, especially in languages like Python everything actually is an object.
@@harrypadarri6349 in Ruby everything is an object. In python you can get alot done with just imperative. It doesn't lean on the OO style anywhere near as much as C# and Java. Most Python dependencies are very OO though. I once tried to write functional Python code. It didn't go well.
@whossname
You’re right with that. Python has so many built in datastructures and additional libaries that you can write pretty nice code that appears to be imperative.
I once wrote a programm that did use only one single self-written class in over ten thousand lines of code.
I am not talking about style but the inner workings of python. There everything is an object. Including functions used for functional programming.
Unlike C where variables just point to a place in memory where a value is stored.
In my CS lectures professors meant that distinction when saying „everything is an object“.
No? I've done Java and C# for forever and my first time with Python I just ran code directly without any classes. Just because I'm very used to it doesn't mean I can only code in classes
Keeping it simple is why Python is so appealing to me. Life is easier when you don't have to wade through 1000s of lines of boilerplate and code-bloat.
@It’s me again Nooooo we never hear that word anywhere!!! It cant be½!!!1§
Yes, but you can also write code without boilerplate and bloat in C++.
Python however makes writting, debugging and maintaining any reasonably complex project near impossible.
It turns out types and identifiers make things easier, not harder, in the long run. The easier it is to write wrong code that still compiles and executes, the much harder it gets to write nontrivial programs.
@@KilgoreTroutAsf I subscribe this
public static constant main void covid let get set x = 5;
@@_caracalla_ @override
I kinda like his implementation of conway's game of life, very neat and concise.
Adding "Exception" to the name of an Exception does help. It helps if you're facing a library that has numerous exceptions and you just want to search for those. You could open the type hierarchy, but you could also just search for the type name, like "*Exception" and it will list you all of them. Programming is not just typing, it's also searching.
You, every time I turn around someone sais the contrary of I was told before. "Divide and conquer to solve your problems and make your program as easy to mantain as possible", then "Don't overuse classes, they reduce eficiency and stuff".....
Great talk. I like the simplicity.
love it - so relevant even today in 2020
Judging by the comments that are "more recent" a lot of people still don't get it.
The important lesson. Do not creat abstractions "just in case". It is easy to add them in the future if needed. Keep it as simple as possible. No wrappers. No custom base classes.
Things like debugging and tracing can be solved other ways.
Maybe it comes from the C/C++/Java days where it was hard to patch things in when you needed them. No new means no need for factory methods, properties means no need for getters/setters, closures can be upgraded to objects with __call__, optional arguments, no difference between classes, objects, or modules, duck typing means no need to rewrite your code when you change your class hierarchy, classes/objects/modules can be swapped around, dynamic typing works sort of like duck typing and mypy's errors can be ignored..., iterators is the default, you can add data to classes, decorators, context managers changing globals, __getattr__... However, Common Lisp is even more hardcore than Python in that you could always use something like JQuery on your s-expressions to refactor it, optional return values and you could locally change progn, let, defun, etc... and turn functions into macros that alter the expression trees of their arguments...
Sometimes you need wrappers and interfaces for your code to become testable.
@@Dacusx Standalone functions are probably easiest to test. :)
@@movax20h Only if they are pure. :)
To get the curried arguments from a partially applied function, use the partial.args, and partial.keywords properties
You can also use lambda for partially applied functions, or changing the order of arguments, or to add more arguments to something
Very useful message. Scala is probably one of the best languages to strive for the balance the author suggests between classes and functions. Python is moving that way, but it lacks the type safety. Very interesting and actually useful for every day work with python. Thanks!
Great talk and effective examples. Congrats
Watching this in 2020 and all the rules still apply. Great talk.
They apply even more because we have more standard tools to deal with the problems people tried to use classes to solve.
@Michael David lol. You're an idiot. You're making a big deal out of nothing. Okay, "recalc" isn't a perfect name. So what? Any idiot can still see what it means and what data it holds: it's the set of all points that need checking to see if they're alive in the next state (or all the points that need to be "recalculated"). Also, I've seen professional code with much worse variable names, so your assertions about "any second year comp sci student" are full of crap anyway.
I've been using dataclasses quite a bit recently. I like them better than dictionaries when I need mutable named tuples or want to define data schemas. The typing library and typehints work nicely them as well. I wonder what Jack's opinion would be about using a dataclass when you could have used a dict or a tuple?
@@williamkmanire His talk is more about unnecessary use of classes as pure method holders. I doubt he'd object to a data class that defines a record or otherwise combines multiple related pieces of information. That said, I find I almost never need those classes to be mutable. Allowing them to be mutated usually makes the code more difficult to reason about (especially if you're stuffing intermediate values into its attributes), and avoiding that is usually a simple matter of doing any computation using local variables or another function before calling the constructor. (The dataclasses module has replace for if you actually need to change values for some reason.)
Classes have there place in programming as the questioner in 23-25 minute indicated but I do agree that many programmers do overkill. Helper functions can just be functions instead of a class with loads of static functions.
I think at least part of it is because so many people learn Java as their first programming language. Python has classes and objects as a feature but they're used to programming in a language which is built on classes and objects from top to bottom.
University CS education is stuck around 1988
I don't know. I feel Exceptions are the exception (hehe). Having a Stacktrace where the first word already tells me what is the problem. Having an UpdateException(MyModuleException), DownloadFailedException(UpdateException), and InstallFailedException(UpdateException) giving me the alternative of what to try/except is quite important. Or let's say it otherwise. I simply don't know how I would do that exception handling stuff without all the subclassing.
But when you Throw an exception you can pass the error message.
You are right and the developers of Python agree with you
making a mental note to pronounce 'dict' as 'dictionary' in real life.
@@alexanderzerka8477 that was a joke but i'm glad you pinged me a year later to make a snotty comment!
@@alexanderzerka8477 uh, okay. sounds good!
I love what he's saying.. but when I go out for a programming interviews
99% of the time... they want me to write things as classes to solve the given coding test. No matter how inappropriate it would be to the test.
+Kobe Wild What kind of contests?
This is an indication that you are interviewing with a company that doesn't share your values (and lacks common sense). Filtering out bad employers is a great outcome for interviews.
Yeah but, y'know, working for a bad employer is a hell of a lot more lucrative than working for no employer at all.
@@edgeeffect Hahahaa. VERY TRUE LOL
That's how you know where not to work. Classes create bloat in terms of code complexity, execution time, and computer memory. Everytime a class is written, make sure you have a good reason for it.
Classes are great but they are also overused. This talk describes examples of class overuse taken from real world code and refactor the unnecessary classes, exceptions, and modules out of them.
I agree to a certain extend but we did not mention was the fact that Classes have a fundamental task of making Business Logic look readable and easy to implement for less technical people, often functional administrators.
in none of the examples mentioned OO achieved that task.
A great talk.. Thanks a lot for sharing .
10 year later and we still have these problems lol
The Agile(TM) consultants said that architecture and design could be done later
Lol
Whoops
After 10 years, with the introduction of type hintings and pattern match in newer python versions, the idea of less classes seems more true
protocols, data classes, single dispatch are also pretty useful
Want to write spagetti code?
@@raianmr2843data classes are a shame in the world of OOP. They break encapsulation, introduce mutable state and result in functionality being spread across the codebase. Burn it with fire.
@@user-lk1fw1lp8b Spaghetti code is when you see a simple function call, but actually it is a dynamic dispatch over an inheritance hierarchy. Spaghetti code is when numerous layers of indirection are pretending to be "simple" linear code. OOP is spaghetti code.
@@youtubeenjoyer1743 if you don't know how to write OO code, yeah, it turns into procedural garbage.
His point at 5:55 or so was great. If you know for a fact that you will need to use something later, then of course writing a class may be useful. But if you don't have any reason to need it later right now then don't try to plan for a 100k line project that will probably only ever be 1k lines max
How does print glider, where glider looks like a 5x2 staggered array of ints, magically turn into circles in a moving grid (the advance function changes the contents of the array, not draw anything)? Unless print has been overridden with a custom screen rendering routine.
I was wondering how they were going to graph their raw data, too. Any suggestions? Anyone? Guess maybe i'll have to look at some other people's GOL programs to see how they like to graph things in Python. Maybe Turtle Graphics (my speed).
@@randmorf same issue. probably not the code. hope they included some source.
His message was not to stop using classes but stop using classes for simple things. Lot of people misunderstood. Classes are useful when they are needed but too much of class objects with bigger code makes it slower. No Offense.
Exactly. Why make a class just to call it's methods.
@@cwill6491 the things is lot of people are here fighting against each other one who likes classes and one who don't and some python haters! I don't know why this people just learn something new and appreciate it instead of fighting over each other. Why hating python in comments btw? What you think about this brother.
@@lordtejas9659 python breaks a lot of conventions. For example, declaring a variable globally doesn't necessarily make it global. You have to use the keyword global in every scope you want to use it in. Some people might not like stuff like that. If you can put that aside though, python is so useful. You can ignore many programming issues and get a prototype working quickly.
@@cwill6491 well I never got an issue with local and global in python. I have coded more than 100k lines in both python and C++ within this years. I use C/C++ as well as Python. What I was saying that to stop people for fighting over stupid things like they are tools and people misunderstood the message of the video. But this students from IT and freshers don't understand the basic concepts of Programming and starts fighting. If C++ was good for prototyping then why we even needed python in first place..thanks for your opinion friend. Have a nice day. Hope this message stops this new kids from fighting. It feels like civil war.
Well, you know what they say "the headlines tell the story" in this case the title "stop writing classes". LOL
0:05 R.I.P. Jack, you're going to be missed
Lol dude. I said the same thing. Probably gonna email him to wish him my condolences. Truly heartbreaking...
Lool
maybe he is cheating with death telling that he already dead?
“If implementation is hard to explain then it may be good”
Reminds me of pthread vs c++ thread. It is easy to implement in c++ but unless you program in pthread, various multithreading problems, you will not learn the conceptual ideas related to it. It’s about whether you are becoming code money for corporations or actually becoming a good programmer.
In python, i only use classes to define complex entities or objects and hold their respective attribute data. Doing this it helps maintaining the code and reduces code repetition. Example: function overriding is repetition.
22:33 I think this guy has a point with regards to implementation hiding. If you use a plain old dictionary everywhere in your code, but then later on realize you actually need some other data structure instead of a dict, you're going to have to change a hell of a lot of code. If you hid what data structure you were actually using behind some interface, then you can swap it out easily, only changing the code in 1 place.
Is there a way to do that without interfaces/classes?
For any language or just Python?
@@r.t.5767 Any language
@@trampflips101 There is another way (and it is probably older than interfaces and classes). The translation units!
In C you can easily hide data structure you use just by not defining it in header and defining it in source file. The same goes with functions that deal with that data structure. Make them small (their only purpose should be to deal with the data structure) and static (so they are hidden), and whenever you need a different data structure replace them with new functions working for the new data structure.
Or make your project modular and that data structure and its "methods" as just another module - you can still replace that module any time you want, but it will not be hidden that way
Just ask yourself if it needs to be hidden, if yes then you have the first solution, if no - probably the latter one is better
The first solution is the best when the data structure is so small and easy to implement that creating another module is an overkill
It can be as simple as Find & Replace
@@vicatucd It would still largely be a manual process though. But yeah, it probably wouldn't take that long.
Its quite amusing - We all love to code...but still we love if there is LESS to code :D
That's because we love "our own" code. The others's code, not so much. ^^
Right, there is a nice quote (I think of the French Voltaire):
"A book isn't finished when you can't _add_ any more words, but when you can't _remove_ any more."
damn... still or even more relevant these days after 10 years. No fancy words, straightforward. Great honor to have good people on python in the past although today many went to other lang and communities.
Great.... usefull time saving...thank you 4 ur pitch.
Great talk. I recommend it. Q&A is skipable though.
That is true for almost every Q&A ever.
That "very succinct" neighbours function is a bit silly
for dx in [-1,0,1]: for dy in [-1,0,1]: yield x+dx,y+dy
You're returning the point itself whereas his implementation does not (although yes, the neighbours function could be simpler)
@@eecarres
That's true but since "neighbors" is used exactly once, you can add a skip clause (if dx==dy==0: continue) in the body of the loop and the whole thing would still be simpler.
@@dionbridger5944 It's used twice: once in generating all the points to recalc and once in the live neighbor counting. I like the fact his solution avoids invoking an if condition on every loop.
@@BladeOfLight16
18 evaluations of a signed int equality test is computationally speaking, nothing, unless maybe you are running your program on a clockwork Babbage engine. Even for a million iterations, it comes to 18 million operations, which on a puny 18 mhz CPU is a total of 1 seconds worth of CPU time.
BTW you can get away with a succinct 2 line function without any equality test:
for i in range(8):
yield x+[-1,1,0][(i//3)], y+[-1,1,0][(i%3)]
And the fact that the "function" is only 2 lines means you can probably get away with not having it be a function at all ( depending on where it's called from ) and just in-lining those 2 lines. So not only do you save on the if-clause, but you spare your Babbage engine the cost of doing a jump operation too ;)
surprisingly inspired presentation
Awesome video! Thank you!
This is more of a "Know Your Standard Libraries and Use Them" video. That is probably how he did the first "amazing" code side reductions. Also my heapq module does not have pushleft and popleft methods in his heapq, plus I think there's a bug in his popleft method if the user did not define a key function. (He passes the second element of a tuple which is only created if there is a defined function). I guess the main thing I agree with him on is I hate typing long identifiers...
If the user fails to define a key function, the key function defaults to 'lambda x: None'. It's right in the __init__ argument list. So there is no way to get into the guts of the class without having a key function of some sort defined.
You Tube recommended me this because i watched Monty Python's sketch... let us turn off recommendations.
Break everything down to their constituents and easily manage the larger problem; paraphrasing a Japanese proverb: you can ignore the big problem, it's the little problems you must address. Stub code a life hack!
good vid!
I advocate for good design and structure, but also I strongly agree with not over design, one should plan for the future but not invest too much effort on it. for example I'll model this as a class because it has a good chance to be overload or subclassed, but I'm not creating the whole inheritance structure.
Edit: three years on, I don't think my comment here is correct at all. It might read convincingly but I didn't know what I was talking about. I wrote garbage code because of this mentality. Someone in the replies said I was conflating abstraction and good naming, and that's exactly right.
---
This presentation is an attempt by someone who has a good point to overstretch that point way beyond reason.
His game of life rework is very confusing (19:48). I have no idea what it's actually doing. I don't know how the game of life works, so I can't look at it with the luxury of already knowing what it does. I have to read it line by line and hold all kinds of information in my head at once to understand it.
One of his lines has 4 steps' worth of nested function calls. Wtf? That's not simple code.
If he abstracted those steps into individual logical leaps, each contained in a function with a _descriptive_ name, it would be so much easier to read. And, when you have a bunch of functions that depend on one another... You guessed it. You should put it in a class.
He's using the complete wrong metric to judge whether classes are good or not. Classes allow you to compartmentalise a problem. If it assists you in compartmentalising the problem, *it's good*. If it makes the problem more complicated, *it's bad.* That's it. Obviously, the MuffinHash example is bad, but the reason has nothing to do with whether they used classes. The reason is that those classes make it _more difficult_ to conceptualise the solution.
I don't know why you find his Game Of Life code confusing. It took me 20 seconds to read and understand it. I assume you just aren't used to functional programming paradigm. But it is not his fault. With practice you can read it as easily as 100% imperative code.
I find that I can read his code as a book: read it line by line, never look back. It is very easy and pleasant to read. And if he had 5-10 functions/classes it would take me longer to read and understand it, having to jump from one place to another.
My only problem with his code is it's performance (obviously, I hope). But in exchange for this ineffectiveness you get GOOD readability and development speed.
P.S.: If i wanted speed, I'd use C.
The _point_ of an abstraction is to allow you to understand the solution without understanding the lowest level of detail.
You can still delve into it if you want to. Being able to paper over your ignorance is a _good_ thing.
Programs that force you to understand the entire program just so you can understand a part of the program are bad programs.
I don't know python, but I was able to read and understand what that code does. The only part that was hard to understand was `board | set(itertools.chain(*map(neighbors, board)))`. But that's fixable, just add an extra local variable, and it'll become easy to read. And probably one more variable for `(neigh in board) for neigh in neighbors(point)`.
> You want to code quickly and with minimal abstraction, I want to code in a way that's easier to maintain
Eeh, I don't see a collision here. Minimal abstraction = easier to maintain.
Minimal abstraction is not easier to maintain for any significantly sized system.
Over-compartmentalization and over-abstraction is a sin to be avoided. I would not want to maintain your code. It's probably about 10 times more verbose than needed, inefficient, hard to read and therefore buggy. Smaller and simpler is better. The problem with OOP is that everybody thinks *their* problem is so *special* and needs special classes. Not so. Do us all a favor and use as few classes, methods, functions and lines of code as will get the job done.
Although in the game of life he has reduced the number of lines, I don't think it necessarily made the code easier to understand.
It's easier to reason about cells in a board than reason about an "advance" function. Adding more possible cell types would already make this advance function too complicated.
Anyways, I got the idea of the talk, always good to keep in mind that Python is not Java and that not everything must be a class
I have seen Game of Life's with different rulesets aka advance functions, but I have never seen one with different cell types. Don't generalize, if you don't know for sure, that you'll need it tomorrow.
The game of life implementation is simplistic, but barely readable like that.
most programmers don't use too many ideas from functional programming or aren't well acquainted with it. since he's using a few fp functions in the main function, so the code seems barely readable, but if you look closely it's actually quite okay. implementing it with classes would just slow down the code considerably while not adding anything useful.
it look like code I was making when I first started programming... tbh its a fugly mess.
I'm new to python and I had no problem reading it
The OO code is much easier to read, reason about and modify.
Hence, in my opinion, much more maintainable in the long run.
I was thinking the same thing
Good talk. A very simple yet very useful message.
+Christian Tidmarsh he wouldn't be let near any project I was involved in
Code in C. If you feel the urge to create an unnecessary class it will be a little more difficult and this will give you more time to come to your senses.
Re the question starting at 21:19 you can (now) introspect a partial object without using an undocumented dunder, it has args and keywords attributes.
incredibly enlightening.
14:19 Is it me or Heap is broken if no keys, like popleft will do a pop[1] but it won't be a tuple.
Then you get an IndexError and you either deal with it or you crash.
He hasn't used "Separation of concerns", "decoupling", "encapsulation" or "implementation hiding" in 15 years of programming? Ok bud.
As a C++ person all those terms are the core principles, to me at least. I’m completely baffled watching this presentation.
GogL0L C++ doesn’t force you to do anything, that’s half the problem collaborating with it. I don’t do OO. I do data oriented design, which C++ is great at.
@@smallbluemachine [deleted it because I confused c++ with c# lol]
But idiomatic Python code is different from idiomatic C++. When working in a "data oriented" fashion (in Java or Python), I tend to only use build-in types and write classes only when necessary. All those terms are pretty much related to C++, Java [,...], or C# styles of OOP, as you get pretty much no coupling at all when you use to build-in types and write classes only when necessary.
Say "Iterate on a random dict" five times fast. Thanks commentary guy!
I find it amusing that my first impressions of what this guy had to say were completely off. I thought he was completely against classes in code, but what he was really speaking out against was a flagrant misuse of them that I hadn't even been aware existed.
Class Flow may be empty, but there's at least two reasons I can think of to keep it:
1) You want a way to test an object to see if it is a "Flow" (via isinsance, for example)
2) You want to allow the users of your code to subclass it and implement their own Flow class.
Mr. Diederich doesn't seem to give the "benefit of the doubt", or even attempt to see why the code was written this way. The first audience question hinted at that, but the speaker never gave a real answer.
Agreed, this makes the talk a bit weak to be honest.
this guy has a point, even if at first he sounded like weird. In my time, I had to suffer tracing unnecessary class abstractions in C++ made by some kid (the management thought was a superstar) and now left for singapore. And when i looked and followed thru his abstractions, i began to realize that this OOP thing along with its power to create artificial abstractions is rearing a generation of ignorant developers later building on top of these abstractions. The BSD socket beauties and tcp/ip headers are hidden and instead exposing some get/set methods. It is true, that abstractions are powerful tools, but if you are not careful it can also lead to ignorance and decadence. To me, the first thing is the electrons and their properties of producing boolean logic. If you are aware at this level, then you will fear the days ahead when quantum computing comes. This is then followed on by protocols, and then the core libraries. It was from that experience that I started to move away from C++...
+Eigenfield Aparicio save me, tell me where to go from here.
I hope you're following Jonathan Blow and _his_ language, he's gonna use as C++ replacement. ^^
czcams.com/video/De0Am_QcZiQ/video.html
@@ericmacleod8605 we are all looking for the promised land
It's freakin' Gavin Belson!
What does he say at 20:20? "refactor every line you see"? I can't really tell
The person who asked the first question about functools proves why you should uses classes whenever possible. Having access to data is the best reason to use classes. Functions have local variables that you have no access to, but with a class you can access all the local variables. Data science!
What did Raymond say??
That is one of the best seminars on programming I have heard in years: you should travel the United States and give seminars on programming: How To and How Not To.
Version 3 of the Muffin API is not thread-save. Two threads using it with two different keys wont work, while it works with Version 2.
Glad someone said it: OOP in Python is a nightmare
typelessness was a terrible design choice in python
@@ipotrick6686 How come?
A more accurate statement would be "OOP is a nightmare".
Python had functions before it had classes. This is a Good Thing, because it means functions are powerful, first-class objects. Take advantage of this. Use them in conjunction with classes, by all means.
Actually, the fact that you have to create exceptions (most of the times) is because that would make it easier for documentation, when you have to create a document with all error cases with their respective error message, it is easier to create a package for exceptions only and have a custom exception for each error possible, also, OOP is on developer's option, Django framework (for example) is full of classes, and you actually follow MVC pattern which is an OOP pattern, and people still complain, I just don't see why, I mean, it's not everyone else's fault if your co-workers doesn't know when to write a class or not (or even how to do it properly), just saying..
is to keep it closer to the zen ?
Great talk!!!
You forgot one of the main goal of writing code, and that's readability. You're not writing code for computers to understand, but for human. People like you only make life harder for other developers like hell.
People who write 200 abstraction layers to do simple thing does not make things more readable. They claim the do but in reality they are just uncle Bob Worshippers who want every person on the planet to write code the same way.
All I know is things like typealiases are trash and classes are often overused as well. When debugging it makes things so much easier and quicker and intuitive when for ex an int is properly typed as an int and not some bs name you made up so that now I gotta go digging through the docs just to find out what basic/primitive type your alias is hiding. I find this bs in swift alot. But what do I know I'm just a noob.
imho , if your writing code for humans to read , write a book. if your writing code that also has to be read and understood by other people , you might do some adaptation for that purpose but especially if future you is one of those other people
you see, "you're not writing code for computers to understand, but for human" is just another philosophy, not a general truth.
You write code for people to read, not for computers to save space. I'd rather have 10 times as many lines of code that I understand instantly, then one tenth that I need to ponder for hours about until I get all the edge cases
except that the code you have to read is often crap like your comment
@@Amine-gz7gq Seriosly? How is it crap? Objectivly or subjectivly? Is is the comment itself that you think is crap or is it the information it is trying to convey?
11:38 but the PEP 8 says I should add an Error suffix to exceptions that are errors
Makes more sense. Good presentation
I'm not sure , but Python does NOT offer static classes, which are great way of ORGANIZING similar functions that do not require an instance.
I look at the file where the residing function exist as static classes in Python. Classes are great for organize a common DATA STRUCTURE... To say to stop using classes is a bit extreme...
+Zackery Fix just put those functions in their own module.
do NOT use static. static is a horrible way to store data and instances. Use parameters.
I goda disagree with what he was saying at 4:30, information hiding, encapsulation, seperation of concerns, etc are very important, and it is extremely difficult to make easy to understand, maintainable software without them..
However, what he says about speculative design is very true.
+Bejamin Rood Heh, after nearly 30 years of programming I might come up with a few, but it's a short list. Well said.
No, information hiding makes code unmaintainable.
What makes code maintainable is readability and clarity, first and foremost.
Obfuscating simple code behind layers of classes makes code a maintainability nightmare.
When including an external library that has a bad or illogical interface, encapsulating it (facade pattern) lets you hide the bad parts and ensure that your team only uses it right - it can also allow you to add correct logging, error handling, etc. to code you can’t refactor because it’s third party
Separation of concerns: actually usually creates simpler more readable and more reusable code with fewer side effects; I find that when this comes up in real life it’s usually not because someone is trying to pull a fast one, but rather because a more junior dev is doing something like putting API input validation logic into a DB stored procedure where it can’t be reused.
Of course you should always be wary of premature optimization and overengineering, but this guy sounds like a lazy/semi-skilled dev who never found that balance. He elevates simplicity before all else and throws out decoupling, encapsulation with the bathwater when there are very good reasons why those are best practices
These guys are always so draconian. Good thing.
Who is the Raymond he mentions at the start?
My god I wish the engineers at my work understood this
Me too. I'm currently working on a single file that has 860 classes, 99% of which say pass.
kek'd
@@SinCityGT3 wow
has it been any better now?
Did I just watch 25 minutes of talking that can be compressed to the two sentences:
"Think before you write" and
"Look at the standard library to see how a language was intended to be written"?
lol... sounds like you stopped listening because he said something you didn't like, and substitute what he said with what's in your own head...
porffiry
I had no problem with what he said i just don't think it is worth talking so long about it.
Mr8blacklp: Vidcon 2017: "Stop writing sentences!"
"Write good code!"
There, now you don't have to watch any more software talks ever. I just summarized it all for you ;-)
what is the good code?
great presentation and presenter
That make sens. Very nice.
12:40 lol. C++ defines like 5 exceptions...
That’s both because a lot of errors are at compile time and raising exceptions is slow when compared to error codes. If it wasn’t that raising exceptions is (comparatively) slow I’m sure there’d be a lot more.
Michael David that’s completely unrelated to the comment, but I agree
Its happen when you use your keyboard more than your brain.
Fast forward to 2022.... we still use Class for most cases... and its pain in the ass.
Great talk!
That glider code and his admission that he hasn't had a single discussion about decoupled and cohesive system design with another engineer in >15 years pretty much tells me everything I need to know.
what do you mean he hasn't had a discussion?
I'm glad I use C and asm...
My hypothesis is that Python believes it’s better to have unreadable code than the possibility of a dangling pointer.
"1: Mostly no point in abstract base classes in duck-typed languages."
Especially in those in which can have mixable traits. (Well, perhaps they could be used for documentation purposes, I don't know.)
lua would fit perfectly with this philosophy
OKAY IMMA STOP WRITING CLASSES IN JAVA THANK YOU
Better yet, stop writing Java.
@@edwin-jq4dp I guess Google isn't a serious company then.
@@WhateverYouLove
> No serious company writes anything serious in Python *apart from machine learning.*
@@edwin-jq4dp Google uses Python not just for machine learning, but for almost everything that isn't ultra performance-critical (in which case they'll use a bit of C++).
www.quora.com/What-is-Python-used-for-at-Google
The very site you're writing on (CZcams) is written in Python.
@@WhateverYouLove Djangooo
My understanding is that OO is chiefly about extensibility. Yeah, you could always make it extensible later but extension often happens in small increments, and for any given small change you are likely to make the extension in non extensible ways. By the time you wake up and realize your code should be in an extensible format all along, you'll have a lot to rewrite since all those small changes added up.
OOP Code which uses Classes and Inheritance is usually some of the least extensible code I've ever seen.
The only thing you want to allow in OOP if you want extensibility is Interfaces.
Sadly most Java Programmers I know seem to be unaware such a concept exists, using abstract base classes even where it's equivalent to an interface.
OOP in general tends to overspecify and reinvent... All the things constantly. Even their own terms. Look at the famous "strategy pattern". It sure is great, I agree.
Now look at how an interface is meant to be used.
Oops. Thats the same fucking thing. Maybe just learn how to use a fucking interface before coming up with new design patterns.
@@9SMTM6 there is a ton of cargo cult practices in the industry
I felt the greatest sense of disappointment, when you disclosed that the company from the 1st example was not actually called 'Muffin' :`(
Dreams crushed
For the "Game of life" I'd just fill a buffer with one background color at startup, loop through the color-values and if I find a color that is not equal to the background color, I'd apply the given rules.