Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Write More Classes

lucumr.pocoo.org

Post reply on HN
Print view View original

101–110 of 150 posts

Re: Write More Classes

#101

Post by bunderbunder »

rlpb wrote: post #99
the_mitsuhiko wrote: post #97

Earlier quoted context omitted.

> It seems to me that the writer has little experience of not using classes, so wants to solve every problem he has with a class. That's a bold statement. Where is the trend to forcefully avoid classes here coming from? Classes are a perfectly valid tool in Python to solve problems. Someone sent me a mail this morning proposing a dictionary with callback functions in addition to a function as if that would solve anyt…

> Where is the trend to forcefully avoid classes here coming from? See the "Stop Writing Classes" video. Classes hold state. More state adds more complexity, and typical OO design add lots of layers of indirection which also add complexity. Most of the time, you don't need the flexibility that the extra indirection gives you. So you get complexity for little benefit. If you don't need to hold state, then a collection…

I'd be so bold as to make a categorical statement: If your classes are invariably stateful, or if they can reasonably be described with the phrase "lots of layers", then you're doing it wrong. You're not doing object-oriented programming so much as the mongrel "class-oriented programming" style that rose to prominence among C++ programmers in the 1990s.

Good well-modularized object-oriented code should not be an alternative to a collection of functions. It should be a technique for making your collections of functions more effective. It allows you to write a smaller, more concise collection of functions that can operate in a consistent manner on a whole plethora of datatypes. It accomplishes this because you can write your functions against a common set of mixins that your datatypes inherit rather than having to worry about specializing them for every datatype.

Re: Write More Classes

#102

Post by the_mitsuhiko »

rlpb wrote: post #99
the_mitsuhiko wrote: post #97

Earlier quoted context omitted.

> It seems to me that the writer has little experience of not using classes, so wants to solve every problem he has with a class. That's a bold statement. Where is the trend to forcefully avoid classes here coming from? Classes are a perfectly valid tool in Python to solve problems. Someone sent me a mail this morning proposing a dictionary with callback functions in addition to a function as if that would solve anyt…

> Where is the trend to forcefully avoid classes here coming from? See the "Stop Writing Classes" video. Classes hold state. More state adds more complexity, and typical OO design add lots of layers of indirection which also add complexity. Most of the time, you don't need the flexibility that the extra indirection gives you. So you get complexity for little benefit. If you don't need to hold state, then a collection…

> Classes hold state. More state adds more complexity, and typical OO design add lots of layers of indirection which also add complexity. Most of the time, you don't need the flexibility that the extra indirection gives you. So you get complexity for little benefit.

Functions hold state as well, they just encapsulate it. You can still break up your algorithm into a class with multiple template methods and then encapsulate it in a function if you're afraid of leaking state elsewhere.

What I see instead is that people can't get rid of state and put it as global variables into Python modules. Case in point: pickle. It uses sys.modules and pickle.dispatch_table to store some of its state.

> If you don't need to hold state, then a collection of functions will usually suffice. In Python, you can use modules for this.

Classes have another advantage: virtual method calls. If one function in a module calls into another function in the module I can only do two things: a) copy/paste the library and change one of the functions or b) a monkeypatch which modifies a shared resource someone else might want to use with the old semantics.

A class I can subclass and change the behavior for each method separately.

Re: Write More Classes

#103

Post by hythloday »

timruffles wrote: post #91
the_mitsuhiko wrote: post #70

Earlier quoted context omitted.

> - Why do I need a class for streaming JSON - Python's got a perfectly good `yield` for returning tokens in such situations. See the msgpack-cli example at the bottom. Say you have a function that returns a generator for tokens in Python. You would need another function that builds objects out of them. How do you customize how objects are being built? A class makes that simpler because each of the methods are extens…

I think > A class makes that simpler because each of the methods are extension points you can override. is a strong argument in favour of classes. They're more extensible even if the author doesn't consider it. However - as soon as your class has an implementation like def to_json(str) JSONParser.parse(str) # JSONParser is not streamed end then you're in trouble. Unless your language supports dynamic lookup of consta…

In Java, you often see a class JsonClass with a toJson method like you presented and then a StreamingJsonClass with an overriden toJson that streams - this can cause problems with types (because the most obvious return type for toJson when it's written is JsonObject, but you really want an Iterator), but Ruby/Python have the same problem (only hidden).

It's quite idiomatic Java, though, to remove all static calls from methods, even if you have to use anonymous classes (i.e. extensible method dependencies) to do so, for exactly the reasons you outline.

Re: Write More Classes

#104

Post by dbecker »

Uchikoma wrote: post #50
crntaylor wrote: post #42

Earlier quoted context omitted.

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

Designing Erlang is an impressive accomplishment as computing goes. I don't know why you insist Armstrong is a dilettante without any basis.

Re: Write More Classes

#105

Post by betterunix »

nnq wrote: post #76
bhntr3 wrote: post #40

Earlier quoted context omitted.

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?

...indeed, the one thing I "hate" about Python is that somehow it pushes your mind away from functional solutions. You end up writing either OO or procedural code, although in a language with first class functions and immutable strings you's expect to slip more to the functional side. Anyone else had the feeling that although Python allows functional style, it somehow pushes your mind away from it?

Well it does not really help that Python lacks tail call elimination (last I checked), which is fairly important to (practical) functional programming.

Re: Write More Classes

#106

Post by dbecker »

coldtea wrote: post #90
loxs wrote: post #56

Earlier quoted context omitted.

So you are saying that you are a better language expert, and know better than him?

Why can't he say that? Several people in HN should know more about OO than Armstrong. There are academics that have taught and worked for decades on OO systems and concepts among the crowd, unlike Joe. In general, popular language creators are hardly the more knowledgable of the various PL concepts and issues. Simon Peyton Jones probably knows hundred times more about such stuff than Matz or Guido do, for example.

It's worth pointing out that the original comment claimed Armstrong had no OO experience... not simply that Armstrong wasn't the most knowledgable OO programmer on HN.

Re: Write More Classes

#107

Post by dbecker »

ankitml wrote: post #44
willvarfar wrote: post #37

Earlier quoted context omitted.

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!

That's fine. Armstrong may be wrong in this case, but he doesn't deserve the ad hominem attack.

Re: Write More Classes

#108

Post by seanmcdirmid »

willvarfar wrote: post #37
Uchikoma wrote: post #19

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.

Joe Armstrong is very opinionated. I would want to hear what he has to say but I wouldn't take him as an unbiased authority.

Re: Write More Classes

#109

Post by hythloday »

Uchikoma wrote: post #22
benrhughes wrote: post #7

Earlier quoted context omitted.

FWIW, with C#'s object initialisation syntax you can cut that down to once too. eg public class Foo { public string Bar { get; set;} } var foo = new Foo { Bar = "Hey there" };

I've come to love Scala case classes: case class Foo(bar: String, foo: String = "hello") new Foo(bar = "Hey there") new Foo(foo = "Hey there", bar = "Hello") new Foo("Hey there")

Case classes, I believe, have a companion object with an apply method build for them, so you can get it down to:

  case class Foo(bar: String, foo: String = "hello")
  val f1 = Foo(bar = "Hey there")
  val f2 = Foo(foo = "Hey there", bar = "Hello")
  val f3 = Foo("Hey there")

Re: Write More Classes

#110

Post by dougk16 »

epidemian wrote: post #28
dougk16 wrote: post #23

Earlier quoted context omitted.

I get what you're saying, but good OO for me usually suggests nullary constructors, letting a class know when something happens as opposed to setting internal state directly, and the class saying let me do something for you using my state instead of giving you my state directly. Providing a getter at least is sometimes practically unavoidable, so there's 1 repetition, but with a good IDE that's just a quick key combi…

> good OO for me usually suggests nullary constructors I'm curious, could you please elaborate on this point? If a class has any dependency, i usually find it better to require that dependency to be passed in the constructor, so the constructed instance can always be in a valid initialized state. Why do you find nullary constructors to be good OO?

I came off too heavy-handed there. My intention was more to just say that variables shouldn't be put in constructors if they don't have to be. So, just railing more against the pattern that Java seems to have popularized where every private variable automatically has a getter/setter and can be set through the constructor. Certainly if an object requires some initial state that can never change, passing the value in through the constructor is usually most appropriate. Even then, I sometimes like to have a nullary constructor with an init() method. Just makes certain design patterns utilizing e.g. reflection or pooling a bit easier to manage in some languages.
Post reply on HN