Stop Writing Classes

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.

[@nyosgomboc2392]

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. - Antoine de Saint-Exupery

[@touchestoomuch]

my amputee friend disagrees

[@LightLord1870]

Great Quote.

[@Muck-qy2oo]

@@touchestoomuch Me, and other poor people disagree!

[@TheMarti1978]

Same thing said Michelangelo: that sculpture is finished when there is nothing more to remove.

[@R0MUl0]

I must add that to be true to this ideal you must not target solving everybody's problem.

[@kirathekillernote2173]

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

[@ChrisAthanas]

Functional style with sprinkles of classes to hide functionality

[@edwardminnix7438]

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.

[@soberhippie]

Zen also says "Readability counts". That Game of Life implementation, short though it is, is not readable.

[@ZapOKill]

@@soberhippie i think it was readable... code is like poetry -> some like, some don't

[@der6409]

@@ZapOKill most coders aren't making art, they're making systems. Consistency is always going to win out.

[@oysteinsoreide4323]

@@soberhippie Exactly. Readability is the most important measure of a good program. Not how long or short it is.

[@edgeeffect]

@@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.

[@brecoldyls]

Even though this talk is older, I find it so relevant and interesting still today

[@BingtheLizard]

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.

[@t0maz.m]

self, nice one

[@ChrisAthanas]

This is the correct mindset and curiously very rare

[@furiousmat]

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.

[@MyAmazingUsername]

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.

[@ChrisAthanas]

Pair programming is one way to reduce this problem

[@ChrisAthanas]

Pair programming is one way to reduce this problem

[@advance512]

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.

[@johnouellette1098]

One of my favorite Python videos. Every example is so on point.

[@Ubben1999]

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.

[@Norsilca]

And much more, to catch them specifically and not some unrelated one.

[@minchulkim87]

Judging by the comments that are "more recent" a lot of people still don't get it.

[@tpflowspecialist]

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!

[@mbrian870]

Great talk. I like the simplicity.

[@molewizard]

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.

[@djeendo]

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.

[@molewizard]

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.

[@absurdworlds]

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.

[@molewizard]

Minimal abstraction is not easier to maintain for any significantly sized system.

[@dlwatib]

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.

[@c21jwest]

"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.

[@jeroenvermunt3372]

And, do classes make code more or less readable?

[@edgeeffect]

@@jeroenvermunt3372 Both

[@edwardminnix7438]

To get the curried arguments from a partially applied function, use the partial.args, and partial.keywords properties

[@aoeu256]

You can also use lambda for partially applied functions, or changing the order of arguments, or to add more arguments to something

[@markemerson98]

love it - so relevant even today in 2020

[@MistaSmith]

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.

[@eduardin5214]

But when you Throw an exception you can pass the error message.

[@jonathandaniel7321]

You are right and the developers of Python agree with you

[@redetrigan]

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

[@jessstuart7495]

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.

[@QckSGaming]

@It’s me again Nooooo we never hear that word anywhere!!! It cant be½!!!1§

[@KilgoreTroutAsf]

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.

[@marcosbarranquero8289]

@@KilgoreTroutAsf I subscribe this

[@_caracalla_]

public static constant main void covid let get set x = 5;

[@ChrisAthanas]

@@_caracalla_ @override

[@conatcha]

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".....

[@nicop175]

Watching this in 2020 and all the rules still apply. Great talk.

[@BladeOfLight16]

They apply even more because we have more standard tools to deal with the problems people tried to use classes to solve.

[@BladeOfLight16]

@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.

[@williamkmanire]

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?

[@BladeOfLight16]

@@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.)

[@beefbroccoli5489]

making a mental note to pronounce 'dict' as 'dictionary' in real life.

[@beefbroccoli5489]

@@alexanderzerka8477 that was a joke but i'm glad you pinged me a year later to make a snotty comment!

[@beefbroccoli5489]

@@alexanderzerka8477 uh, okay. sounds good!

[@marcofumagalli8147]

Great talk and effective examples. Congrats

[@NaumRusomarov]

I kinda like his implementation of conway's game of life, very neat and concise.

[@brixomatic]

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.

[@artemzhuravlev543]

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.

[@saurabht3540]

Artem Zhuravlev he realizes waste of time and effort, his engineering was over engineering.... It's really a heart breaker

[@harrypadarri6349]

@Joe Boxter Uhm, especially in languages like Python everything actually is an object.

[@whossname4399]

@@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.

[@harrypadarri6349]

@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“.

[@theshermantanker7043]

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

[@edgeeffect]

"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

[@YeshuaAgapao]

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.

[@randmorf]

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).

[@bryanbisimotopinas345]

@@randmorf same issue. probably not the code. hope they included some source.

[@BruceDuncan]

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.

[@johanlarsson9805]

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]

except that the code you have to read is often crap like your comment

[@johanlarsson9805]

@@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?

[@drasticfred]

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.

[@barnabasnanna6845]

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.

[@quickdudley]

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.

[@ChrisAthanas]

University CS education is stuck around 1988

[@Mr8lacklp]

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]

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...

[@Mr8lacklp]

porffiry I had no problem with what he said i just don't think it is worth talking so long about it.

[@saltyman7888]

Mr8blacklp: Vidcon 2017: "Stop writing sentences!"

[@throawwai]

"Write good code!" There, now you don't have to watch any more software talks ever. I just summarized it all for you ;-)

[@kosbarable]

what is the good code?

[@RufusVidS]

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...

[@DustinRodriguez1_0]

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.

[@NOPerative]

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!

[@ChristianBrugger]

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.

[@powderdescent]

Say "Iterate on a random dict" five times fast. Thanks commentary guy!

[@snowpunk116]

Great talk. I recommend it. Q&A is skipable though.

[@edgeeffect]

That is true for almost every Q&A ever.

[@polarpanda2337]

11:38 but the PEP 8 says I should add an Error suffix to exceptions that are errors

[@lucasa8710]

10 year later and we still have these problems lol

[@ChrisAthanas]

The Agile(TM) consultants said that architecture and design could be done later Lol Whoops

[@movax20h]

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.

[@aoeu256]

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...

[@Dacusx]

Sometimes you need wrappers and interfaces for your code to become testable.

[@movax20h]

@@Dacusx Standalone functions are probably easiest to test. :)

[@Dacusx]

@@movax20h Only if they are pure. :)

[@DarkTrunksGeorgeSim]

He hasn't used "Separation of concerns", "decoupling", "encapsulation" or "implementation hiding" in 15 years of programming? Ok bud.

[@smallbluemachine]

As a C++ person all those terms are the core principles, to me at least. I’m completely baffled watching this presentation.

[@smallbluemachine]

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.

[@gogl0l386]

@@smallbluemachine [deleted it because I confused c++ with c# lol]

[@floriansalihovic3697]

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.

[@marco_gorelli]

What does he say at 20:20? "refactor every line you see"? I can't really tell

[@rodi-soonshin-kwon]

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.

[@trampflips101]

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?

[@r.t.5767]

For any language or just Python?

[@trampflips101]

@@r.t.5767 Any language

[@r.t.5767]

@@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

[@vicatucd]

It can be as simple as Find & Replace

[@trampflips101]

@@vicatucd It would still largely be a manual process though. But yeah, it probably wouldn't take that long.

[@carlos.arenas]

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..

[@moussabnmohdahman5318]

Great.... usefull time saving...thank you 4 ur pitch.

[@cladmi]

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.

[@Milamberinx]

Then you get an IndexError and you either deal with it or you crash.

[@TsungWeiHu]

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.

[@rdoetjes]

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.

[@MyAce8]

in none of the examples mentioned OO achieved that task.

[@edvansousa1270]

A great talk.. Thanks a lot for sharing .

[@jordanmungo917]

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

[@francescocariaggi1145]

0:05 R.I.P. Jack, you're going to be missed

[@cplusplussizeddick1430]

Lol dude. I said the same thing. Probably gonna email him to wish him my condolences. Truly heartbreaking...

[@AlbertoRivas13]

Lool

[@anar-k-jafarov]

maybe he is cheating with death telling that he already dead?

[@keneo.7627]

It's freakin' Gavin Belson!

[@cranespud]

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.

[@Underpantz]

Good talk. A very simple yet very useful message.

[@borkair6581]

+Christian Tidmarsh he wouldn't be let near any project I was involved in

[@zn9707]

What did Raymond say??

[@SuperVt100]

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.

[@GathGealaich]

"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.)

[@Shockszzbyyous]

is to keep it closer to the zen ?

[@lordtejas9659]

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]

Exactly. Why make a class just to call it's methods.

[@lordtejas9659]

@@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.

[@cwill6491]

@@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.

[@lordtejas9659]

@@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.

[@BryanChance]

Well, you know what they say "the headlines tell the story" in this case the title "stop writing classes". LOL

[@zbeast]

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.

[@janprzepiorkowski5815]

+Kobe Wild What kind of contests?

[@BladeOfLight16]

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.

[@edgeeffect]

Yeah but, y'know, working for a bad employer is a hell of a lot more lucrative than working for no employer at all.

[@TwstedTV]

@@edgeeffect Hahahaa. VERY TRUE LOL

[@jamieg2427]

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.

[@ameeradel4846]

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?

[@EvilWonka]

Great talk!!!

[@ssw4m]

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.

[@Mauricione07]

You Tube recommended me this because i watched Monty Python's sketch... let us turn off recommendations.

[@MidnightSt]

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.

[@haphazard1342]

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.

[@mr_karamazov246]

incredibly enlightening.

[@kashey2000]

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.

[@9SMTM6]

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.

[@ChrisAthanas]

@@9SMTM6 there is a ton of cargo cult practices in the industry

[@rosssharma542]

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.

[@jeroenvermunt3372]

Agreed, this makes the talk a bit weak to be honest.

[@valentintudormocanu8483]

if for a problem similar with Conway Game , the requirements will change often, the presented optimization will not be an optimization and the objects will become useful. So, there are not universal best practices, but some good practices in context.

[@roadent217]

I feel this whole talk was mostly about drawing loads of attention to that very important "if" at the very start of your first sentence.

[@edgeeffect]

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: kzbin.info/www/bejne/o5qqoJ-dpZ6rp5o

[@dionbridger5944]

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

[@eecarres]

You're returning the point itself whereas his implementation does not (although yes, the neighbours function could be simpler)

[@dionbridger5944]

@@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.

[@BladeOfLight16]

@@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.

[@dionbridger5944]

@@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.

[@dionbridger5944]

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 ;)

[@dmi_go]

The game of life implementation is simplistic, but barely readable like that.

[@NaumRusomarov]

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.

[@vincecas3557]

it look like code I was making when I first started programming... tbh its a fugly mess.

[@nitroyetevn]

I'm new to python and I had no problem reading it

[@advance512]

The OO code is much easier to read, reason about and modify. Hence, in my opinion, much more maintainable in the long run.

[@zapy422]

I was thinking the same thing

[@georganatoly6646]

surprisingly inspired presentation

[@AJ-et3vf]

Awesome video! Thank you!

[@eduardin5214]

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

[@clumsyjester459]

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.

[@syntaxed2]

Its quite amusing - We all love to code...but still we love if there is LESS to code :D

[@romainvincent7346]

That's because we love "our own" code. The others's code, not so much. ^^

[@minastaros]

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."

[@YeshuaAgapao]

I have nothing against emulating function libraries by using global scoped all-static classes in .Net. For functions that need to interact with the ASP page context stuff (session variables, etc..) and need page scope instead of global scope - make class variables in the virtual class that inherits the ASP page and have its constructor pre-instantiate them. Accessible throughout the page, instantiate once, use many times. This is especially true with database connections as your should extremely rarely need MARS (Multiple Active Result Sets). Instantiate one connection at start, assign it to the command objects as needed, close and dispose on the bottom, always standard connection string. Less lines of code usually means faster execution too.. Exceptions are very slow

[@GhastlytheTinkerer]

Who is the Raymond he mentions at the start?

[@llothar68]

I also see this in my C++ testing code after i moved away from an OO framework to one home grown inspired by "Catch"

[@kim15742]

12:40 lol. C++ defines like 5 exceptions...

[@electric26]

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.

[@electric26]

Michael David that’s completely unrelated to the comment, but I agree

[@vytasmatas]

great presentation and presenter

[@jeffwads6158]

These guys are always so draconian. Good thing.

[@ImaginaryNumb3r]

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...

[@carlosgarza31]

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.

[@BladeOfLight16]

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.

[@BladeOfLight16]

​@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).

[@BladeOfLight16]

@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.

[@artychartybyjackmerlinbruc7134]

This was the whole point of the talk... Not to use classes when you don't need the

[@zhilongji]

After 10 years, with the introduction of type hintings and pattern match in newer python versions, the idea of less classes seems more true

[@raianmr2843]

protocols, data classes, single dispatch are also pretty useful

[@user-lk1fw1lp8b]

Want to write spagetti code?

[@user-lk1fw1lp8b]

​@@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.

[@youtubeenjoyer1743]

​@@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.

[@user-lk1fw1lp8b]

@@youtubeenjoyer1743 if you don't know how to write OO code, yeah, it turns into procedural garbage.

[@Kniffel101]

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.

[@ryonagana]

why? i tried to use non OO i cant use it, remeber i'm not said its bad but i just cant think how to solve my problems.. using OO i can think more details how to solve my problem

[@HeyItzMeDawg]

"It does the exact same thing with fewer lines" But 'fewer lines' is not a metric or goal that matters at all. Is it more readable or easier to maintain? Not necessarily. Does it execute quicker or with less resources? Not necessarily. Is it faster to write? Not necessarily.

[@absurdengineering]

Less lines of boilerplate is the point: boilerplate dilutes the code and when you look at it, it’s harder to comprehend. It’s the same thing with excessive vertical white space and silly “function start” comments that harken from COBOL days. There’s a big open source project, with proprietary roots, where the coding rule proudly states that all functions and methods must be preceded by a 4-line comment (at minimum), where said comment has two horizontal lines built out of “=“ characters, one line that repeats the name of the function, and the final line that states the purpose, and 95% of those lines regurgitate either the action implied by the name of the function, or describe the purpose such that it doesn’t add anything to what you read in the body of the function itself. Those 95% are out of a sample of a 1000, and I did do it carefully. Said project also has thousands of source files that declare or define short classes that are 5-10 lines long. It’s a C++ project and this is nonsense: entire subdirectories of “modules”, each with a multitude of files, could be often boiled down to a single header file, since the methods are either getters/setters or defaults. It’s nuts. And people claim that this is “discipline” - yeah, in self-flagellation. I have a general rule that source files shorter than 250-500 lines should be viewed with suspicion, as are sources over 2000 lines. Exceptions to those rules of thumb arise, but infrequently. Short files with nothing that boilerplate should be burninated with gusto, and the heads of the projects such files comprise viewed with suitable suspicion. Good comments should describe the purpose and must not regurgitate the obvious. Good classes introduce abstractions that are helpful, that improve the understanding. Having a base class just so that at some point in the future we may change the underlying container is silly. Never mind that the container may need to be changed only on a few derived classes - as might reasonably be expected with the mentioned descendants of the Flow class.

[@aoeu256]

Its not just fewer lines of code all of the code to do the tasks aren't spread out.

[@khadimhusen]

Its happen when you use your keyboard more than your brain.

[@cosinenine]

I would be curious to hear his response to when programs evolve and inevitably become more complex. It seems like Jack leans more towards regular functions manipulating primitive data types, rather than making classes. What if in the future the program has to handle different types of boards, including triangular or hexagonal grids, instead of squares? Different data structures would (and should) be used for these scenarios. A programmer would be forced to enter a higher level of abstraction, something that classes do really well.

[@jonaskoelker]

> different types of boards To me that sounds like you want multiple implementations of the same interface, using "interface" and "implementation" in the most generic sense possible. For example, the `advance` function might take as an argument a function which tells you the neighbors of any given location. You can then write one such function for square grids and another for hexagonal grids. Those functions implement the "neighborhood-producing callable" interface: they both do what is needed of them by the calling code. You don't (always) need classes just to implement an interface twice. Sometimes classes are the best way of doing that.

[@____uncompetative]

That is not Conway's Game of Life. That is an entirely different program. It isn't even guaranteed you could create a different starvation and reproduction ruleset for this other cellular automata and elicit similar LIFE like behaviours from various starting patterns. It could be the phenomena that makes LIFE interesting only works on grids. If you made one with a hexagonal or Penrose tiling and got to elicit similar behaviour I think it would be fair to call it Gabe's Game of Life. It would have to be reconceived from first principles and the likelihood of there being code reuse between implementations is so low you would just be adding superfluous complexity to the standard Conway grid case for the unknown benefit of future unrelated systems.

[@lawrencedoliveiro9104]

What’s all this “class «Foo»(object)” stuff? Are you still thinking in Python 2?

[@scalesconfrey5739]

When this talk was given, python3 was only around for just over 3 years. Comparing that to python2, released in 2000 (ie almost 12 years) at that time I think some people in industry preffered py2, partially because it had more library support. Also, for a long time python2 has been THE version included by default on the 'unices,' so to guarantee that people could run your code, even to this day, people tended to write for py2. Now that py3 has matured a bit and become the official version, that will obviously change, but that only happened just this year (not 8 years ago during this talk).

[@daixtr]

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++...

[@ericmacleod8605]

+Eigenfield Aparicio save me, tell me where to go from here.

[@Kniffel101]

I hope you're following Jonathan Blow and _his_ language, he's gonna use as C++ replacement. ^^ kzbin.info/www/bejne/epaTcqCVhsiNn7M

[@ChrisAthanas]

@@ericmacleod8605 we are all looking for the promised land

[@ElenaDotNET]

The majority of this errors, of the code is shown, is not about Classes, is not about OOP. Is about bad refactoring or not refactoring AT ALL. Dont stop writing Classes, just think, write and refactor!

[@edgeeffect]

You're taking the title far too literally and not really listening to the talk.

[@ElenaDotNET]

Do you think so?

[@loslosbaby]

Sometimes writing OOP-as-a-lifestyle leads to infinifactoring. Then there's FOMO-refactoring. Then there's ... %

[@jackiepuppet_5324]

...and practice TDD

[@kicknotes]

@@ElenaDotNET I do not think so; I agree with you.

[@alexign]

Great talk!

[@t43562]

I see the idea as not optimizing your design beyond what is currently needed. You can make it a class later if you want to and you may often find that you never want to. So the problem is when you're trying to guess the future for some reason - trying to make an API that will account for all future needs.

[@ChrisAthanas]

Instead of making it for all needs, set it up in a way that it can change This message was lost along the way Or never discussed in the first place (ie university) or told its not important (agile and scrum consultants)

[@behnamrasooli8801]

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.

[@crystalray4231]

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.

[@wouldbabyhitlerkillyou4217]

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.

[@DonAlcohol]

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

[@joekerr5418]

you see, "you're not writing code for computers to understand, but for human" is just another philosophy, not a general truth.

[@DaniloSouzaMoraes]

"they didn't even try to hide it"

[@dailylegend]

Conclusion/summary at 20:00

[@jgschneider2009]

@p34cekeeper Just because abstract classes and formal interfaces aren't native to Python doesn't mean Python programers can't implement the good design principles they help enforce. We're talking about good design here. Replacing crappy classes with crappy functions doesn't really improve the design/code at all.