No. Don't write classes. Write useful abstractions. It doesn't matter what the abstraction is (a class, a function, or something else you programming language supports)as long as it fits your current architecture and can be easily modified for possible future extensions.(I will agree with the author that one giant monolithic function is probably a bad abstraction).
Write More Classes
31–40 of 150 posts
Re: Write More Classes
#32if 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…
I would argue that this repetition is not essential. It happens when you assign a constructor argument to an attribute directly without any modification. But there are case where it doesn't appear:
- the attribute has a different name
- an attribute is set whose value is a function of more than one argument
- an attribute is set to a constant value independent of constructor arguments
How often such circumstances occur is another issue. The form of initialization that you mentioned is probably the most common so languages can provide shortcuts in this case.
Re: Write More Classes
#33I must be way out of touch because I had no idea there was an anti-class movement for which the OP has to argue for more classes?
He mentions stop writing classes talk in the very beginning.
Re: Write More Classes
#34As Java was mentioned. The Java API is very nice, but there is a layer missing on top. The Java API was written with a early 90s mindset and got most users after 2000. This goes for most Java APIs. IO, Swing, ... The idea is to have LEGO building blocks (BufferedReader) you can plug together. But you need to plug them together all the time. The missing layer e.g. is IO.readIntoString(file). Apache IOUtils, StringUtil…
To be fair, they have mostly fixed the IO API with Java 7 (NIO2). This covers various Files# helpers as well as a proper Path abstraction.
Re: Write More Classes
#35The programming industry walks around in circles and there is no beacon in this darkness of ignorance.
There is no professional culture and new generations of developers successfully forget all the experience previous generations have accumulated.
Also, some piece of advice from a seasoned programmer to the web-programming-children: if you are not really a serious developer, if you write your freaking websitee on Django, or whatever a framework there is, you don't really need a methodology, because you are doing an easy task, you can write in whatever language/style/paradigm you like, even on Brainfuck. But please don't extrapolate your humble experience to the entire industry and don't tell people working on large complicated (real) projects how they must write code, because they have some experience you don't have.
Re: Write More Classes
#36Write 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…
classes are exactly the pattern that tends to evolve into monolithic piece of code. Worse, they are harder to read and debug
Re: Write More Classes
#37Write 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.
Are you saying Joe Armstrong doesn't know what he's talking about? He's a very googleable guy.
Re: Write More Classes
#38As Java was mentioned. The Java API is very nice, but there is a layer missing on top. The Java API was written with a early 90s mindset and got most users after 2000. This goes for most Java APIs. IO, Swing, ... The idea is to have LEGO building blocks (BufferedReader) you can plug together. But you need to plug them together all the time. The missing layer e.g. is IO.readIntoString(file). Apache IOUtils, StringUtil…
To be fair, they have mostly fixed the IO API with Java 7 (NIO2). This covers various Files# helpers as well as a proper Path abstraction.
15 (?) years late ;-)
Re: Write More Classes
#39Earlier quoted context omitted.
Love it when people write about OO without OO experience.
Are you saying Joe Armstrong doesn't know what he's talking about? He's a very googleable guy.
I'm not aware of Joe Armstrong having extensive OO experience - either as a programmer or a language designer. Could you fill me in? Perhaps the picture I have is completely wrong. Erlang is from 1986. Did he gather extensive OO experience before? In Smalltalk? Or on the side while developing Erlang?
Re: Write More Classes
#40I 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 alw…
Quoting from the end of the article: "And our solution to monolithic code in Python are classes."
So, I guess the question I ask as someone who doesn't write a ton of python code is: Is that true? And if so, why? Is it not possible to compose a layered API that doesn't rely on inheritance / classes in Python?