Live data from Hacker News

Object Oriented Programming is an expensive disaster which must end

smashcompany.com

71–80 of 123 posts

Re: Object Oriented Programming is an expensive disaster which must end

#71
post #62

Earlier quoted context omitted.

Oh, so what happens if all the arguments against him are actually fallacious? You realise that you would have ignored him based on the fallacy of the Fallacy fallacy?

No, I wouldn't have. I ignore his claim that all arguments against him are True Scotsman Fallacies. I don't ignore the actual arguments against him, nor the one he makes. Any of those arguments may or may not be fallacious themselves, but that has no bearing on me ignoring his claim that they all are.

What I'm saying is that if all the arguments against him were True Scotsman Fallacies, then it would be fallacious to ignore him based on a mistaken understanding that he is arguing based on a Fallacy fallacy. And as we all know, no true logician would make such a mistake.

Re: Object Oriented Programming is an expensive disaster which must end

#72
post #63
post #58

Earlier quoted context omitted.

I know, it can also be written in many other ways. What decides which one is more correct if they are all semantically equivalent? Is it less characters? Is it using exactly as many 'e's as 'a's? Is it the unnecessary braces?

There is probably no "correct" way of writing this, but there are ways of making your next code maintainer's life easier (which might be you in a few months from now). One line is easier to read and understand than 10, especially if that one line is just "return p".

Personally most of the time id rather have 10: main(int c,charv){return!m(v[1],v[2]);}m(chars,chart){returnt-42?s?63==t|s==t&&m(s+1,t+1):!t:m(s,t+1)||*s&&m(s+1,t);}

Re: Object Oriented Programming is an expensive disaster which must end

#73
post #72
post #63

Earlier quoted context omitted.

There is probably no "correct" way of writing this, but there are ways of making your next code maintainer's life easier (which might be you in a few months from now). One line is easier to read and understand than 10, especially if that one line is just "return p".

Personally most of the time id rather have 10: main(int c,char v){return!m(v[1],v[2]);}m(char s,char t){return t-42? s?63== t| s== t&&m(s+1,t+1):! t:m(s,t+1)||*s&&m(s+1,t);}

But I meant return p, not some gibberish that obviously should be formatted better. It's just that for some developers "formatting better" doesn't translate to "make it shorter and sweeter".

Re: Object Oriented Programming is an expensive disaster which must end

#75
Say I want to migrate from OOP to Functional and avoid doing things the wrong way the first time, like we supposedly did with OOP and it's too late to fix. What book/code/etc is a good reference for high-quality, practical proven Functional programming best practices?

Re: Object Oriented Programming is an expensive disaster which must end

#76

Say I want to migrate from OOP to Functional and avoid doing things the wrong way the first time, like we supposedly did with OOP and it's too late to fix. What book/code/etc is a good reference for high-quality, practical proven Functional programming best practices?

It might be easier for those in the know to make a recommendation if they have an example of the kind of book/code/etc you're looking for on the OO side. What do you recommend for high-quality, practical proven OO programming best practices?

Re: Object Oriented Programming is an expensive disaster which must end

#77
post #76

Say I want to migrate from OOP to Functional and avoid doing things the wrong way the first time, like we supposedly did with OOP and it's too late to fix. What book/code/etc is a good reference for high-quality, practical proven Functional programming best practices?

It might be easier for those in the know to make a recommendation if they have an example of the kind of book/code/etc you're looking for on the OO side. What do you recommend for high-quality, practical proven OO programming best practices?

I have no idea. Programming is not my main area and thus I look for advice from other people to avoid doing stupid mistakes by following best practices. That being said, OO people will often point me to the design patterns book, etc. Is something similar needed for FP?

I've got the Haskell Craft book but haven't practiced enough. It seems good enough for me but, as people are learning more and more about using OO and FP in the real world (thus such criticism), I would like to keep current.

Re: Object Oriented Programming is an expensive disaster which must end

#79
post #74

I've written my rebuttal here: http://axilmar.blogspot.gr/2014/10/object-oriented-programmi... .

You don't come across well in this at all. 200 classes in a OO project is pretty small really. And you've never used DI ever? Really?

Re: Object Oriented Programming is an expensive disaster which must end

#80

As someone who is more familiar with OOP, I would love to see examples/hear more alternative approaches to organising code. Let's say that you want to design a CRUD app, but you're not going to use OOP. What are some of the ways you could choose to structure your code? Would you still use a pattern like MVC?

My main issue with OOP is that classes/objects conflate a whole bunch of notions, and end up not being very good at any of them.

Modularity and design-by-contract are better implemented by module systems ( http://en.wikipedia.org/wiki/Standard_ML#Module_system )

Encapsulation is better served by lexical scope ( http://en.wikipedia.org/wiki/Scope_(computer_science)#Lexica... )

Data is better modelled by algebraic datatypes ( http://en.wikipedia.org/wiki/Algebraic_data_type )

Type-checking is better performed structurally ( http://en.wikipedia.org/wiki/Structural_type_system )

Polymorphism is better handled by first-class functions ( http://en.wikipedia.org/wiki/First-class_function ) and parametricity ( http://en.wikipedia.org/wiki/Parametric_polymorphism )

As for an alternative to "CRUD app using MVC", I'd probably recommend Functional Reactive Programming ( http://en.wikipedia.org/wiki/Functional_reactive_programming ). MVC is a way to architect interactive simulations and games, developed in the live environment provided by SmallTalk.

However, I imagine your intention was for something closer to the server-side code of a form wizard on a Web page, rather than a game. In which case, I'd avoid MVC-style approaches completely, since they're inappropriate. It's much more straightforward to model servers as UNIX pipelines turning HTTP requests into HTTP responses ( http://en.wikipedia.org/wiki/Pipeline_(Unix) )

Pipelines turn out to be a great fit for functional programming: lots of small, single-purpose pieces, composed together into a server which requests flow into and responses flow out.

Post reply on HN