OOP Isn't a Fundamental Particle of Computing • Hacker News Board

Re: OOP Isn't a Fundamental Particle of Computing

#111

Post by papsosouid » Wed, Nov 14, 2012, 4:22 PM UTC

seanmcdirmid wrote: post #108

papsosouid wrote: post #103

Earlier quoted context omitted.

>The nice thing about a language like Haskell, then, is that you have to be really smart to use it I'm living proof that you are mistaken. >Actually, many companies put Haskell (or even Scala) down as a requirement just to filter out the low end programmers If by "many" you mean "a couple", then it depends what you mean by "low end programmers". Asking for haskell is decent at weeding out people who have no interest…

Asking for Haskell is actually good for weeding out most American programmers, but whatever. The point is that you'll get a better programmer if they know lots of programming language paradigms. But I wouldn't for the life of me take on as an employee someone who knows Haskell but not an OOPL (like C#, Java, or at least C++), that would indicate severe ideological bias on their part. I'm using naturalistic here as a…

>But I wouldn't for the life of me take on as an employee someone who knows Haskell but not an OOPL (like C#, Java, or at least C++), that would indicate severe ideological bias on their part.

Ironically, it actually indicates a severe ideological bias on your part, not theirs.

The rest of your post seems like it is entirely platitudes intended to say nothing. No, people don't think in terms of objects, that is why the leaky metaphor used to teach OOP traditionally causes so much confusion, and makes OOP harder to learn than FP. Thinking in terms of FP is not thinking in terms of "formulas", and it appears you are basing all the rest of your assumptions on top of that one faulty assumption. People intuitively understand "I make a thing that transforms other things" much easier than they understand "I make my things know how to transform themselves, or maybe other things, or maybe both, but sometimes neither and I make different things to do the transforming instead, but those things are wrapped inside an "object" that doesn't represent anything for no discernable reason".

Re: OOP Isn't a Fundamental Particle of Computing

#112

Post by se85 » Wed, Nov 14, 2012, 4:30 PM UTC

papsosouid wrote: post #105

hackinthebochs wrote: post #94

Earlier quoted context omitted.

Of course, anything you can create abstractions with you can create a DSL of sorts. But I think most would agree that OOP is the more natural paradigm for this.

Most would agree because most have never used anything other than OOP. That isn't saying anything interesting. I find OOP to be most often awkward and difficult to express the rules of my application in. Functional programming does it quite naturally, as it is all about creating small simple components and combining them to produce larger components. My rules are simply the combination of smaller rules applied in ord…

This is exactly how I feel also.

This simple logic of fitting smaller things together to make bigger things has always delivered superior results for me regardless of the language in use.

OOP seems ass backwards to me but everyone I talk to generally doesn't have a clue how FP is different to OOP!

Re: OOP Isn't a Fundamental Particle of Computing

#113

Post by ajuc » Wed, Nov 14, 2012, 4:37 PM UTC

mercurial wrote: post #89

Jare wrote: post #83

Earlier quoted context omitted.

OOP philosophy is to turn concepts from your problem space into custom data types. The article suggests that this is not always the simplest and most practical way to architect every piece of your solution. That's all. The underlying reason is that data types must address (in some way) a number of requirements: copyability, management of owned resources, conversions, limits, etc. You need to take care of all that for…

> OOP philosophy is to turn concepts from your problem space into custom data types. I don't agree with this statement. Surely the use of structs in C, or records in Haskell, are not enough to turn them into object-oriented languages. And whatever language you end up using, you are going to end up with custom datatypes when attempting to solve non-trivial problems. Sure, simple data types are useful enough on their o…

Do we really need to reinvent these complex datatypes each time, thought? How many classes there exists in Java or C++ just to keep x,y and z coordinates of a point in 3d space? With custom types we gain the ability to distinguish color (r, g, b) from position (x, y, z), but is it worth the cost? How often do you catch errors like assigning point coordinates to a color?

If you want to use library A that has Vector3d type defined with library B that uses library C that has Point3f class, and with graphic library that use its own Vertex class - isn't it stupid that we need to convert the data all the time?

I've seen application in C++ that uses 4 types of string: QString, std::string, char* and custom type to pass data to database. 3 of them just because of used libraries.

I think OOP mindest makes people whip their own datatypes too easily, and it hurts when you need to integrate libraries developed independently. Most of the time tuples, lists and hashmaps suffice, and in better languages you get many operations on you composite datatypes for free - for example serialization, deep copying and deep equality checking.

Re: OOP Isn't a Fundamental Particle of Computing

#114

Post by Uchikoma » Wed, Nov 14, 2012, 4:37 PM UTC

This thread symbolizes everything that is wrong with our industry.

70% pop culture, 30% strong opinions, 0% facts. There is no science in computer science outside of algorithms, there is especially no science or engineering or anything substantial in the love child of this industry: programming languages.

I have still some hope this changes someday, with

https://leanpub.com/leprechauns and the older

http://www.codinghorror.com/blog/2008/03/revisiting-the-fact...

e.g. when to use FP (the tool to solve a problem, not the religion), or OOP (the tool to solve a problem, not the religion) and what is the probability that this works in that environment etc. Like when to use steel or wood. But man, we're decades away from that.

Re: OOP Isn't a Fundamental Particle of Computing

#115

Post by stcredzero » Wed, Nov 14, 2012, 4:38 PM UTC

> OOP can be verbose and contrived, yet there's often an aesthetic insistence on objects for everything all the way down.

It depends on the language you're using. In languages like Smalltalk, it's quite natural to have a Color object and not be passing around a tulle of RGB values. Then adding something like a "beta" value to Color (in addition to RGBA) involves no change to most of the code base.

Re: OOP Isn't a Fundamental Particle of Computing

#116

Post by tikhonj » Wed, Nov 14, 2012, 4:49 PM UTC

colanderman wrote: post #88

I thought he was going to talk about how OOP can be broken down into several simpler orthogonal concepts, namely: 1) Code reuse (e.g. inheritance) 2) Implementation hiding (e.g. methods) 3) Subtyping (e.g. interfaces) 4) Code composition / programming in the large (e.g. classes) 5) Run-time dynamic dispatch (e.g. instances) Functional languages such as Haskell, Mercury, OCaml, and Scheme do a good job of teasing thes…

Just to be pedantic, what Haskell type-classes provide is not usually known as sub-typing. Sub-typing usually implies some relation between types such that every element of a sub-type is also an element of the super-type.

Haskell does not have any sort of sub-typing in this sense. Every single value only belongs to a single type. What you get with type-classes is polymorphism: your function works for all types in the type-class, but each type is disjoint.

Now, I should add that your observations about how type-classes are used are correct--they really do serve many of the same roles as sub-typing does in other languages. However, the distinction between polymorphism and type-classes is still important both in practical and in theoretical terms. Not having sub-typing significantly simplifies the Haskell type system--you never have to worry about covariance or contravariance, for example--but also makes some things, like heterogenous lists, slightly more tricky.

I think you could safely replace your "sub-typing" header with "polymorphism"; sub-typing with interfaces is just one kind of polymorphism, and other kinds also serve a similar rule of making your code more generic by letting it work on multiple types.

Anyhow, I think that covers my daily dose of pedantry :).

Edit: also, to clarify: I like and agree with your post, I just think the distinction between sub-typing and polymorphism more generally is important.

Re: OOP Isn't a Fundamental Particle of Computing

#117

Post by mercurial » Wed, Nov 14, 2012, 4:58 PM UTC

ajuc wrote: post #113

mercurial wrote: post #89

Earlier quoted context omitted.

> OOP philosophy is to turn concepts from your problem space into custom data types. I don't agree with this statement. Surely the use of structs in C, or records in Haskell, are not enough to turn them into object-oriented languages. And whatever language you end up using, you are going to end up with custom datatypes when attempting to solve non-trivial problems. Sure, simple data types are useful enough on their o…

Do we really need to reinvent these complex datatypes each time, thought? How many classes there exists in Java or C++ just to keep x,y and z coordinates of a point in 3d space? With custom types we gain the ability to distinguish color (r, g, b) from position (x, y, z), but is it worth the cost? How often do you catch errors like assigning point coordinates to a color? If you want to use library A that has Vector3d…

Haskell has String, ByteString and Text :) Data type proliferation is not confined to object-oriented languages (actually, since datatypes are much easier and cheaper to build in functional languages, they're even more likely to occur within FP).

Re: OOP Isn't a Fundamental Particle of Computing

#118

Post by seanmcdirmid » Wed, Nov 14, 2012, 4:59 PM UTC

papsosouid wrote: post #111

seanmcdirmid wrote: post #108

Earlier quoted context omitted.

Asking for Haskell is actually good for weeding out most American programmers, but whatever. The point is that you'll get a better programmer if they know lots of programming language paradigms. But I wouldn't for the life of me take on as an employee someone who knows Haskell but not an OOPL (like C#, Java, or at least C++), that would indicate severe ideological bias on their part. I'm using naturalistic here as a…

>But I wouldn't for the life of me take on as an employee someone who knows Haskell but not an OOPL (like C#, Java, or at least C++), that would indicate severe ideological bias on their part. Ironically, it actually indicates a severe ideological bias on your part, not theirs. The rest of your post seems like it is entirely platitudes intended to say nothing. No, people don't think in terms of objects, that is why t…

I'm not sure I understand, do you mean, that someone only knows an FPL and not an OOPL means they are more well rounded than someone who has experience with both. And I didn't even mean they have to do most of their programming in an OOPL. For what I do, I cannot afford to work with a PhD student who does not know more than one programming paradigm!

I definitely meant to say something, I think the platitude remark is uncalled for. People don't talk in terms of transformations, they talk in terms of instructions, recipes, responsibilities, parts and pieces, and lots of encapsulated processes. Again, check out chapter 3 of the SCIP, which you already probably know about if you are teaching programming from an FP perspective.

Re: OOP Isn't a Fundamental Particle of Computing

#119

Post by tikhonj » Wed, Nov 14, 2012, 5:02 PM UTC

debacle wrote: post #98

crntaylor wrote: post #68

Earlier quoted context omitted.

> Being able to create something of a DSL and map your business rules onto basic operations on this DSL is a huge win. Hold on - how is this a concept specific to object-oriented programming? Creating a DSL for your problem domain and solving the problem in the new language is exactly what functional programmers have been doing for decades! E.g. here's a mini-DSL in Haskell for parsing CSVs, built on top of the Parse…

The difference, at least in my eyes, is that OO languages have a convention for the grammar of the DSL.

At some point--well before Java--sufficiently constrained syntax turns your DSLs into libraries, which tend to be less close in design to the given domain than actual DSLs.

Put another way: with Java or Python, you coerce your problem domain to fit the language. With Lisp and Haskell, you coerce the language to fit the problem. I personally like the latter approach, but I suspect it's also a matter of preference.

Re: OOP Isn't a Fundamental Particle of Computing

#120

Post by stcredzero » Wed, Nov 14, 2012, 5:02 PM UTC

programminggeek wrote: post #9

Well, most OOP isn't object oriented at all, it's class oriented or maybe another way to look at it is that most of the time OOP is used as containers for data and function, not for things. For example, say you have an object that holds some strings and numbers and it has getters and setters on it. How is that different than a Hash? Is that object oriented? If you add a couple helper methods to said object is it more…

> Treated the way it often is, OOP is not that useful for anything other than namespacing and creating ridiculous hierarchy structures just because "it's oop" and inheritance lets humans do what they love to do - name and categorize things.

Leave out inheritance, but keep interfaces, and you get better OOP.