Stop Writing Classes
HTML-код
- Опубликовано: 1 авг 2024
- Jack Diederich
Classes are great but they are also overused. This talk will describe examples of class overuse taken from real world code and refactor the unnecessary classes, exceptions, and modules out of them.
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.
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
Even though this talk is older, I find it so relevant and interesting still today
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 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
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 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.
"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
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".....
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
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
One of my favorite Python videos. Every example is so on point.
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!
Great talk. I like the simplicity.
Judging by the comments that are "more recent" a lot of people still don't get it.
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
I kinda like his implementation of conway's game of life, very neat and concise.
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
love it - so relevant even today in 2020
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
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.
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
You Tube recommended me this because i watched Monty Python's sketch... let us turn off recommendations.
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.)
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
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.
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. :)
Say "Iterate on a random dict" five times fast. Thanks commentary guy!
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?
Great talk. I recommend it. Q&A is skipable though.
That is true for almost every Q&A ever.
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.
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 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.
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.
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.
“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.
It's freakin' Gavin Belson!
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 ;)
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.
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
Its happen when you use your keyboard more than your brain.
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.
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."
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?
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"?
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?
"Think before you write" is very vague...
11:38 but the PEP 8 says I should add an Error suffix to exceptions that are errors
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.
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.
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..
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.
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!
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
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 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.
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
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 also see this in my C++ testing code after i moved away from an OO framework to one home grown inspired by "Catch"
Good talk. A very simple yet very useful message.
+Christian Tidmarsh he wouldn't be let near any project I was involved in
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.
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
What did Raymond say??
in C# you make a class for everything, you refactor your classes until each method inside the class is responsible for one thing, e.g. Logger class can have 3 methods only, Check file, create file if does not exist, write message, so indifferent than python approach.
am i missing something here?
Great talk!!!
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?
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 is a great talk. Part of me died a little bit inside though when he says he wanted to use a URLShortener and in order to do so he had to go away and read 10K lines of code. He opens with the quote "don't do hard things in the first place" 🤷🏼♂ also, if he reads the 10K, does he have to read the code of whatever libs / dependency that is using et al?
A great talk.. Thanks a lot for sharing .
MuffinMail.MuffinHash.MuffinHash ! => Beetlejuice! Beetlejuice! Beetlejuice!
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.
What does he say at 20:20? "refactor every line you see"? I can't really tell
Great.... usefull time saving...thank you 4 ur pitch.
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.
aaaaaand... Yep, the title is most definitely a bait.
No?
@@ishdx9374
>"Stop Writing Classes"
>The speaker acknowledges that classes are very useful tools and that people should use them
@@Kolyasisan Did you even watch the video? He tells that you shouldn't use classes when unneeded, there was only one piece where he shown good use of classes.
@@ishdx9374 exactly, and the title says "Stop Writing Classes" when in reality the talk is about not creating classes when unnecessary, when an obscene amount of them will result in a clutter. Seems like a bait to me.
@@Kolyasisan You are being too literal with the title. Read between the lines..
incredibly enlightening.
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.
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.
11:40 the main problem with exception names is, I think, the fact that you can't do (in general in languages, afaik) "catch" on an exception property, only on a class (exception) (sub)type... if you could do:
catch (e.Type == "Whatever") or something of that kind, you would realize there's no need to make a new "class" for each type of error.
That only works if your types are flat, and having flat types means you cannot be more specific while still allowing other calling code to catch your exceptions generally.
The value of a sub-class of an exception is the ability to identify different kinds of failure and respond to them differently. You can try/except/except/except multiple kinds of exceptions, and do so at multiple layers.
Subclassing stdlib exceptions is tragically not that useful because so many of the stdlib's exceptions are flat and extremely specialized, but when authoring libraries for use by others you don't want to just subclass Exception directly in the majority of cases.
I felt the greatest sense of disappointment, when you disclosed that the company from the 1st example was not actually called 'Muffin' :`(
Dreams crushed
"they didn't even try to hide it"
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.
Fast forward to 2022.... we still use Class for most cases... and its pain in the ass.
These guys are always so draconian. Good thing.
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'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.
"Separation of concerns" existed even before the notion of OOP even "structured programming".
No, history started in 2005. (Don't mention the structured and recursive Algol with nested scopes from 1960, or the object oriented Simula from 1967. That's the Jura age, after all.)
@@herrbonk3635 Well, the only answer possible here is a quote from Santayana's The Life or Reason: "Progress, far from consisting in change, depends on retentiveness. When change is absolute there remains no being to improve and no direction is set for possible improvement: and when experience is not retained, as among savages, infancy is perpetual. Those who cannot remember the past are condemned to repeat it."
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!
Someone was thinking that way... And then Typescript rescued him.
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 like using classes, so I watched the video with an open mind, to see what could be wrong with that. I found the game of life example very enlightening because I just hate reading the example without the classes, I have to read line by line and be very focused, with the classes I could get a grasp of the situation very fast even without reading the details.
I wonder if people who like functions better actually understand the function example with more ease?
Maybe people prefer classes or function because of the way they think?
I think you probably find the game of life class-less version difficult to read because you aren't familiar with functional programming. If you learn a functional programming language like Haskell, that code will make more sense to you.
I think it has more to do with how confortable you are with certain concepts. His function used map, itertools.chain, set, and set union, sum, and generators. To understand the the class based version you have to understand tuples and dictionaries.
It is about what you are familiar with. If you had more time to unpack it, it would make more sense
@@johngibson4874 minimal python experience here. typed the code in IDLE, all I got is printed line of the glider. What am I missing?
@@bryanbisimotopinas345 The code in the example only prints out the glider once after 1000 iterations have passed. If you wanted to see it, you would need to have a way of printing out the grid, and print the glider after each step.
The key takeaway was using functions and appropriate data structures to express Conway's Game of Life as directly as possible.
The game of life example in OOP makes no sense because the rules of processing the game of life have to do with several objects (neighbors) interacting getting data from the board. Swapping out cell with other cell makes no sense because that cell would have to interact with other cells, and functions are objects in Python so instead needing to build lots of classes you could split the code into higher order functions.
great presentation and presenter
I want to work on this guys team. Can't believe that all the questions are from resistant people that just don't get it
Going against the classic CS training is very difficult
How software development is taught is totally ass backwards and should be considered harmful
It is ridiculous how far fetched this is. He gives examples of bad code and says why you shouldnt use classes for something they are not meant for.
Yeah, no shit...
Yea I don't think this guys as smart as he thinks he is. He advocates useing global variables to store URLS and API keys. Apparently we've been doing it wrong the whole time by writing a config file reader function and using that to populate the parameters of the __init__ constructure of a rest API client class. I don't know how much more of this I can stomach.
Except this is exactly how people use them in the wild. And people coming from languages like Java or C# are convinced that _everything_ should be a class because they don't even have a concept of things like functools.partial or having late binding for non-class methods. This is all really great advice.
@serpathius The fact that you think OOP is somehow more powerful than any of the techniques he discusses (comparing it to airplanes vs. cars) is exactly why he's talking about all this. OOP is not more powerful. It does not do more. It does not scale better. It's mostly only necessary as a kludge around the fact that OOP languages don't support late binding of methods that aren't bound to an instance (static methods).
@serpathius ..... I literally explained that in parentheses right in the sentence you're asking about. Did you bother to read the message? You claimed that OOP compares to other approaches in the same way airplanes compare to cars. That is clearly claiming that OOP is more powerful.
This was the whole point of the talk... Not to use classes when you don't need the
In this talk, Jack Diederich throws in a couple of references to "Raymond's talk" which is "The Art of Subclassing by Raymond Hettinger" which can be found here: ruclips.net/video/miGolgp9xq8/видео.html
surprisingly inspired presentation