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

111–120 of 150 posts

Re: Write More Classes

#111

Post by dougk16 »

grn wrote: post #30
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…

I don't think that nullary constructors are so good. If you have dependencies then after constructing your object it'll be in an invalid state because the dependencies aren't set up correctly.

http://news.ycombinator.com/item?id=5207262

Is there a preferred way on HN to address a "duplicate" reply?

Re: Write More Classes

#112

Post by revscat »

Uchikoma wrote: post #19
contingencies wrote: post #13

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

Lets stick to the argument made rather than the person making it.

Re: Write More Classes

#113

Post by loup-vaillant »

CodeMage wrote: post #100
loup-vaillant wrote: post #98

Earlier quoted context omitted.

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.

Doesn't count. When you define a single data structure in a module, (along with functions to manipulate it) you can instantiate it just like you would a class.

Re: Write More Classes

#114

Post by icebraining »

RyanZAG wrote: post #79
icebraining wrote: post #64

Earlier quoted context omitted.

In some ways, yes. Plenty of people moved to other languages because of those handicaps, and they have no good reason to come back.

You make it sound like it's some kind of popularity contest, where people not choosing the language means it 'loses'. I disagree pretty heavily there - your hammer doesn't lose if you use your saw. The language's user loses if he is such a fanboy of hammers he refuses to use the saw. If Java improves to become the best tool (not saying it has/will), then choosing not use use Java because you 'moved on', is a failure…

The thing with analogies is that you have to know when they break down.

Sure the language loses. An hammer is self-sufficient; a language needs libraries, community support, job/project candidates that can replace an absent developer, etc. Do you think having NumPy isn't a win for Python?

Of course, if the language is sufficiently better than the others, maybe you're willing to write your own e.g. Websockets library to use it. But there's still a large handicap there.

For example, Plan9 is in many ways a better OS than GNU/Linux. But I still use the latter, because I rather have the support and thousands of binary packages that a larger community brings.

Re: Write More Classes

#115

Post by Uchikoma »

dbecker wrote: post #104
Uchikoma wrote: post #50

Earlier quoted context omitted.

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.

(as a side note, your argument does not make logical sense. Designing A does not make me an expert in B.)

I do not "insist" that he is a "dilettante", I question people on this thread quoting him as an expert on OO as there without showing that he is an expert on OO. Beside I give circumstantial evidence why he isn't ("Tried Java ...", "Threw C++ book at the wall ..."). I think it's important to differentiate strong opinion from expert.

And there are more indications: His understanding of "isolation" in the quoted text above is very influenced by him being the Erlang creator and the way Erlang thinks of isolation (processes). None of the (C++/Java/Ruby) OO programmers I know would use "isolation" in an OO context that sense (one error crashing other programs in the same VM).

Re: Write More Classes

#116

Post by calpaterson »

betterunix wrote: post #105
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?

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

Meh, you'd use fold, map or filter 99% of the time in a functional language like scala or haskell. TCO is great, but you can still write a lot of idiomatic functional stuff even without it.

Re: Write More Classes

#118

Post by rlpb »

the_mitsuhiko wrote: post #102
rlpb wrote: post #99

Earlier quoted context omitted.

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

> What I see instead is that people can't get rid of state and put it as global variables into Python modules.

What I see is people writing classes that hold state in instances for far longer than is needed. Other code written around these classes then need to take this into account. This tends to the same place where global variables are. A tangled mess.

> If one function in a module calls into another function in the module I can only do two things...

3) Adjust the function to include the behaviour that you need. In Python, default parameters often mean that you can do this without breaking backwards compatibility. If a function is deficient in some way, why not fix the function rather than working around it?

Re: Write More Classes

#119

Post by Uchikoma »

hythloday wrote: post #109
Uchikoma wrote: post #22

Earlier quoted context omitted.

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

You're right!

Re: Write More Classes

#120

Post by pekk »

ehutch79 wrote: post #89

I think the original video this is a response to, was really just saying 'A class should not be one method, that's a function'

That was only one of the things the video said. Overall, it was pointing out how overuse of classes was resulting in lots of extra complexity and additional lines of code, making programs harder to understand and maintain
Post reply on HN