Live data from Hacker News

Write More Classes

lucumr.pocoo.org

41–50 of 150 posts

Re: Write More Classes

#41
post #35

The 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 Dja…

Don't you think writing about it is a good to minimize the amount forgotten generation to generation? Even if they write something that is flat out wrong, someone will probably tell them and everyone might learn. Also I wouldn't be so quick to dismiss building websites on Django (or any other framework) as easy. I imagine many things are easier, but I bet many things are harder as well, I'd think you'd be surprised at how quickly "good" designs go to shit when business requirements change every two weeks and how this effects development.

Re: Write More Classes

#42

Earlier quoted context omitted.

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?

According to a message he posted[0] on the erlang-questions mailing list, since 1967 he has written in Fortran, Lisp, Prolog, Smalltalk, Erlang, C, C++, Java, Python, Ruby, Lua, Javascript, Haskell, ML and OCaml.

I italicised all the object-oriented ones. Saying that Joe Armstrong doesn't have "extensive OO experience" is pretty comical!

[0] http://erlang.org/pipermail/erlang-questions/2013-January/07...

Re: Write More Classes

#43
post #27

This is a bad article. First, write nothing. If you can solve your problem without writing code (or even better, by deleting code), that is the best solution. Next, write code which fits your architecture. Sometimes functional composition is the best system for representing your computational structure. Tree operations, for example, are especially amenable to recursive function-based computation. Sometimes, when you…

From what you wrote, I'm not sure you read the article. It's not about objects vs functions; it's about hiding a lot of functionality behind an overly-simple interface, with particular attention paid to an example of a parser that takes a whole string rather than a streaming interface. What annoyed me most was his constant apparent conflation between bytes and characters. But I didn't really see much evidence of trea…

I know what he was trying to say, but I don't think that's actually what he said.

What he should have said is that you should pick an interface that suits your computation. The problem was not that the interface was too simple, but that it didn't fit the computation. One can easily imagine an object-oriented interface for the same wrapper computation that also hides the true nature of the computation.

Re: Write More Classes

#44

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

being googleable and knowing what he is talking about doesnt mean that his this quote is relavant in this context. What he said is a good piece of advice, but only when looked through larger window of programming. When we are talking about only python and choices of coding style in python, his quote looks like santa on valentines day!

Re: Write More Classes

#45

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

Which he doesn't really address, nor do the two opinions necessarily clash (at least not totally). Diederich's talk is mostly about avoiding to write superfluous classes. Quite often a simple module with one or two function suffices. His examples look quite different from those in the blog post.

(Although I have to admit that I skimmed most of them, as I'm in serious eyeroll territory whenever I see the old Java IO API used as a bad example again.)

Re: Write More Classes

#46
There's a fairly effective rule of thumb: classes--or more accurately objects--are a way to cleanly encapsulate state. If you rely on a mutating state, you probably want an object/class. If not, a function is often better.

Now you can bundle related functions together in a structure, but this structure is morally a module, not an object, let alone a class. Some languages will force you to encode those modules as classes / prototypes / singletons, but that's just a design pattern to circumvent a limitation of the language.

Re: Write More Classes

#47
post #31

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

+1, one of the best points in the discussion so far. :)

Re: Write More Classes

#48
post #40

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

One can write Python in a procedural manner, and even in a functional way, so one can use the same techniques as are used in those paradigms (OO is probably more natural for Python though).

Re: Write More Classes

#49
post #40

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

It is perfectly acceptable to design a library with a simplified, restricted interface that covers the majority of use cases, but not all. e.g. requests vs urllib2 For me, that's a win for common sense. I have never even considered streaming JSON. The lack of streaming support should be a clue that the OP needs to look at whether what he's attempting is even sensible or could be better served by a different transport protocol with built in streaming support.

Re: Write More Classes

#50

Earlier quoted context omitted.

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?

According to a message he posted[0] on the erlang-questions mailing list, since 1967 he has written in Fortran, Lisp, Prolog, Smalltalk , Erlang, C, C++ , Java , Python , Ruby , Lua , Javascript , Haskell, ML and OCaml. I italicised all the object-oriented ones. Saying that Joe Armstrong doesn't have "extensive OO experience" is pretty comical! [0] http://erlang.org/pipermail/erlang-questions/2013-January/07...

Extensive experience?

About Java: "I tried Java"

About C++: "I saw C++ coming and read the book - or at least tried to read the book - there's a dent in the wall behind my piano, where the book hit the wall"

About Smalltalk: "I learnt (with various degrees of proficiency) [...] smalltalk [...] and became proficient in Prolog (aggghhh - the beauty ....)"

About the others: " I also (later) tried Python (ok), Ruby (ok)".

We might vary in our perception, but I would not call this extensive experience, "trying" some languages and "trying" to read a book.

I would call "I've written some systems in Java for 10 years" extensive Java experience.

Post reply on HN