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

91–100 of 150 posts

Re: Write More Classes

#91

Post by timruffles »

the_mitsuhiko wrote: post #70
viraptor wrote: post #54

I really don't like the way this was presented, even if I may agree with the idea underneath. It's not about classes at all. It's about better design, but even the examples are strange. Just from the JSON example: - Why do I need a class for streaming JSON - Python's got a perfectly good `yield` for returning tokens in such situations. - Why would I ever design the JSON library to be extendable at the tokenizer level…

> - 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 constants, class names feel very much like a global variable that's a pain to change. In Ruby, as of 1.9.3, lookup is lexical so you can't simply define a class-local value for the JSONParser constant.

I don't know the story in other languages - I assume Java has it as you see a great emphasis on dependency injection. If dynamic lookup of constants was present I think classes would be more unintentionally extensible however they were written - as it is, you have to be as careful writing classes for extension as for functional code where you have to manually provide extension points.

Re: Write More Classes

#92

Post by _glass »

Mutjake wrote: post #65
Uchikoma wrote: post #39

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?

From http://www.infoq.com/interviews/johnson-armstrong-oop " Is Erlang object oriented? Joe Armstrong: Smalltalk got a lot of the things right. So if your question is about what I think about object oriented programming, I sort of changed my mind over that. I wrote a an article, a blog thing, years ago - Why object oriented programming is silly. I mainly wanted to provoke people with it. They had a quite interesting…

I always asked myself why Alan Kay didn't name it "message oriented" then.

Re: Write More Classes

#93

Post by vaughan0 »

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?

Personally I find myself avoiding writing in a functional style in Python because of it's lack of good anonymous function literals and poor handling of closures in nested functions.

Edit: when I say "poor handling of closures in nested functions" I'm referring to having to use nonlocal in order to modify variables in the parent function's scope.

Re: Write More Classes

#94

Post by nnq »

vaughan0 wrote: post #93
nnq wrote: post #76

Earlier quoted context omitted.

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

Personally I find myself avoiding writing in a functional style in Python because of it's lack of good anonymous function literals and poor handling of closures in nested functions. Edit: when I say "poor handling of closures in nested functions" I'm referring to having to use nonlocal in order to modify variables in the parent function's scope.

yeah, I think lack of real anonymous functions is a small annoyance that can get quite "big" from the yucky feeling you get when defining functions just to pass them on. But... what do you mean by "poor handling of closures in nested functions"?

Edit: ok, I get what you mean now :) ...though I consider this "poor handling" a feature of Python - mutating outer scope variables is a side-effect and what it encourages is what I like to call "callback hell functions with data Javascript-style nightmare" :) (true, some people know to keep their sanity and write readable code even in this style, and if you enjoy it you're probably one of them few, but most don't...). By "functional style", I and some people refer to "functional as in mathematical functions", so only using side-effects when actually needed (yeah, some "extremist" languages like Haskell try to never do them, but...) and you get this by having immutable values and passing around anonymous functions (that don't modify their outer scope).

...and this is another part of the paradox: this "feature" of Python should encourage what I call functional style, but why oh why it doesn't? ...maybe Rich Hickey is on to something with Clojure and it's actually more about the data-structures than the language syntax or semantics?

Re: Write More Classes

#95

Post by willvarfar »

viraptor wrote: post #54

I really don't like the way this was presented, even if I may agree with the idea underneath. It's not about classes at all. It's about better design, but even the examples are strange. Just from the JSON example: - Why do I need a class for streaming JSON - Python's got a perfectly good `yield` for returning tokens in such situations. - Why would I ever design the JSON library to be extendable at the tokenizer level…

> - Why do I need a class for streaming JSON - Python's got a perfectly good `yield` for returning tokens in such situations.

I use msgpack in Python (twisted, tornado) precisely because it can consume byte buffers which are not token-aligned.

Re: Write More Classes

#96

Post by jerf »

In Python, the distinction is less strong than it is in some other languages. Since a class can implement __call__, allowing instances to be directly called like a function, even if an API specifies a function, you can pass a class instance in with a suitable __call__. So using functions doesn't have to tie to to it being a function forever and ever in the future (or breaking reverse compatibility, the way it does in most other languages. This isn't a perfect answer to the objections, but the objection is at its most weak in Python.

Re: Write More Classes

#97

Post by the_mitsuhiko »

rlpb wrote: post #73
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?

> So, I guess the question I ask as someone who doesn't write a ton of python code is: Is that true? I don't think it is. His objections to the json library API can be addressed without introducing a single class. He seems to want access to the internal implementation of converting bytes into a single Python object. That is probably just an internal function that can just be exposed. If he wants to override it from t…

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

Re: Write More Classes

#98

Post by loup-vaillant »

the_mitsuhiko wrote: post #97
rlpb wrote: post #73

Earlier quoted context omitted.

> So, I guess the question I ask as someone who doesn't write a ton of python code is: Is that true? I don't think it is. His objections to the json library API can be addressed without introducing a single class. He seems to want access to the internal implementation of converting bytes into a single Python object. That is probably just an internal function that can just be exposed. If he wants to override it from t…

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

The question is, what classes do that module systems don't? The answer is generally inheritance, and through it, class polymorphism.

With first class function, you hardly need class polymorphism. Just pass the function as argument already, don't bother with writing a whole new class just to override one method.

The other use for inheritance is plain code reuse. This is bad most of the time because it promotes thick interfaces, and function calls are great at code reuse anyway.

Re: Write More Classes

#99

Post by rlpb »

the_mitsuhiko wrote: post #97
rlpb wrote: post #73

Earlier quoted context omitted.

> So, I guess the question I ask as someone who doesn't write a ton of python code is: Is that true? I don't think it is. His objections to the json library API can be addressed without introducing a single class. He seems to want access to the internal implementation of converting bytes into a single Python object. That is probably just an internal function that can just be exposed. If he wants to override it from t…

> 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 of functions will usually suffice. In Python, you can use modules for this.

By all means use classes if they are the best way to solve a problem. But for those who know nothing else, how do they even know this?

My problem with this article is that it says "I have a problem; I can solve it with classes; therefore everyone should use classes more". It fails to even consider anything else.

Re: Write More Classes

#100

Post by CodeMage »

loup-vaillant wrote: post #98
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…

The question is, what classes do that module systems don't? The answer is generally inheritance, and through it, class polymorphism. With first class function, you hardly need class polymorphism. Just pass the function as argument already, don't bother with writing a whole new class just to override one method. The other use for inheritance is plain code reuse. This is bad most of the time because it promotes thick i…

The question is, what classes do that module systems don't?

Modules (at least in Python) are singletons.

Post reply on HN