I find that I like it when classes store configuration that's known at load time, rather than state. That way it's a lot like a Common Lisp program, except multiple programs can run in the same process, have different configurations, and communicate with each other.
Write More Classes
11–20 of 150 posts
Re: Write More Classes
#12I think the real point the author is trying to make is: use modular, layered designs of composable components, instead of monolithic APIs that only have a single entry point. The single-entry-point model imposes costs and decisions onto the application that are hard to work around.
I think this is a good point. I think that it's hard to get from there to "more classes are always better" though. More classes don't always make a design more flexible. You have to consciously design for flexibility and reusability, and even then it takes a lot of deep thought and hard work to get your interfaces right, such that they are truly reusable in practice.
Re: Write More Classes
#13Write no classes!
Joe Armstrong: "I think the lack of reusability comes in object-oriented languages, not in functional languages. Because the problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. If you have referentially transparent code, if you have pure functions-all the data comes in its input arguments and everything goes out and leaves no state behind-it's incredibly reusable. You can just reuse it here, there, and everywhere. When you want to use it in a different project, you just cut and paste this code into your new project. Programmers have been conned into using all these different programming languages and they've been conned into not using easy ways to connect programs together. The Unix pipe mechanism-A pipe B pipe C-is trivially easy to connect things together. Is that how programmers connect things together? No. They use APIs and they link them into the same memory space, which is appallingly difficult and isn't cross-language. If the language is in the same family it's OK-if they're imperative languages, that's fine. But suppose one is Prolog and the other is C. They have a completely different view of the world, how you handle memory. So you can't just link them together like that. You can't reuse things. There must be big commercial interests for whom it is very desirable that stuff won't work together."
- Peter Seibel, Coders at Work: Reflections on the Craft of Programming
Re: Write More Classes
#14Write no classes! Joe Armstrong: "I think the lack of reusability comes in object-oriented languages, not in functional languages. Because the problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle . If you have referentially transparent code, if you have pure func…
Nice quote, but did you read the article at all?
Something else I want to mention: what's written above will most likely result in some sort of warmed up discussion in regards to object oriented programming versus something else. Or inheritance versus strategies. Or virtual methods versus method passing. Or whatever else hackernews finds worthy of a discussion this time around.
All of that is entirely irrelevant to the point I'm making which is that monolithic pieces of code are a bad idea. And our solution to monolithic code in Python are classes. If your hammer of choice is Haskell then use whatever the equivalent in Haskell looks like. Just don't force me to fork your library because you decided a layered API is not something you want to expose to your user.
Re: Write More Classes
#15if classes didn't have such a terribly verbose syntax in basically every language that has them, i'd be less opposed to using them. in java, c++, or c#, to add a variable to a class, you have to repeat its name 4 times. once to declare, once in the constructor parameters, and once on each side of the assignment. why am i writing the same thing 4 times for what should be a core part of the language? in haskell, you wr…
Scala and TypeScript do it right, though.
Re: Write More Classes
#16I could not understand how classes can help with JSON-example.
It looks the same as XML SAX vs DOM: you feed NN-Mb to DOM-parser (SQLServer xml-datatype for example) and you have problems. No matter: classes or functions.
Re: Write More Classes
#17Can anyone explain the statement about simplejson for me please? Some libraries manage to skip the token part. (I'm looking at you simplejson, a library that even with the best intentions in mind is impossible to teach stream processing)
When you are trying to parse extremely large documents or you only care about a small subset of a document, needing to load the entire parsed file into memory is problematic. Simplejson doesn't provide an API that allows for any other option.
This is in contrast to something like an XML sax parser, that allows you to register for events like "a foobar element was loaded". You get the foobar element while all the other tokens are thrown out the window as soon as they are parsed.
The complaint is that, somewhere, under the hood, simplejson is doing that token parsing, but because of their API, a user can't plug into it.
Re: Write More Classes
#18Write no classes! Joe Armstrong: "I think the lack of reusability comes in object-oriented languages, not in functional languages. Because the problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle . If you have referentially transparent code, if you have pure func…
Nice quote, but did you read the article at all? Something else I want to mention: what's written above will most likely result in some sort of warmed up discussion in regards to object oriented programming versus something else. Or inheritance versus strategies. Or virtual methods versus method passing. Or whatever else hackernews finds worthy of a discussion this time around. All of that is entirely irrelevant to t…
Aha! Good point. TL;DR! Only skimmed, as others have commented, it was far too long. Perhaps the title should have been Python rant: Write More Classes!. The point is, the themes touched upon in the article are greater. The author's wish not to raise them is .. hereby noted, but not understood, really, when appealing to a larger audience. You can't have it both ways.
Re: Write More Classes
#19Write no classes! Joe Armstrong: "I think the lack of reusability comes in object-oriented languages, not in functional languages. Because the problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle . If you have referentially transparent code, if you have pure func…
Love it when people write about OO without OO experience.
Re: Write More Classes
#20By default, I go with the inclination to put code in functions when I tackle a project, because most of my projects are just products and applications without a public API and testing or debugging the flow in a functional paradigm is much simpler. I can take a function and plug it in the interactive interpreter (in Python) and run it without needing to instantiate other state that's needed for the test.
However, in certain cases, like where I need to write a public API, I have found that having classes as wrappers to the functionality helps it a bit. So really, the "stop-writing-classes-unless-you- absolutely-need-to" guideline still holds true for me.