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

Re: OOP Isn't a Fundamental Particle of Computing

#131

Post by chousuke » Wed, Nov 14, 2012, 6:03 PM UTC

mercurial wrote: post #117

ajuc wrote: post #113

Earlier quoted context omitted.

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

The nice thing about Haskell is that you can have a million data types with different names, and as long as they're capable of implementing the type classes you are using, you can pretty much freely switch between the different underlying types. And if a library author doesn't provide an instance of a type class for the data type, you are still able to write one.

In most OOP languages, you'd be forced to either monkey-patch the classes, or writing cumbersome wrappers.

Re: OOP Isn't a Fundamental Particle of Computing

#132

Post by barrkel » Wed, Nov 14, 2012, 6:08 PM UTC

SethMurphy wrote: post #10

OOP has never been just about computing. It's strength is that it allows the business rules to be most directly mapped to the code that needs to be written. When both parts of this process are performed by the same person it loses much of it's value (until the problem gets larger and you need more than one person). As we have better computing tools in modern languages it is more often the same person. It has never be…

Many of the business rules I've seen would be (and often are) better handled by rule engines; and these tend to be functional or functional reactive in nature.

There's usually lots of complicated conditions; if the customer is grandfathered in, then apply rules R1, if they got discount X, apply R2X, otherwise apply R2. Then a new set of rules come in and you need to grandfather the old ones in, and so on; the conditions grow like weeds. When you have rule engines designed around decomposing these conditions, they make them easier to develop, test, they can do things like warn you when certain cases are impossible to reach, etc.

Re: OOP Isn't a Fundamental Particle of Computing

#133

Post by jeffdavis » Wed, Nov 14, 2012, 6:22 PM UTC

gdwatson wrote: post #59

jeffdavis wrote: post #53

Earlier quoted context omitted.

You and the author appear to be using different definitions. I find it troubling that, after all this time, there is still no definition that doesn't use words like "thing".

I like the Rees OO ontology[1]. The set notation doesn't lend itself to easy reading, but it lets you break out the features of an object system in a more precise way. [1] http://mumble.net/~jar/articles/oo.html

I have seen that before and I don't consider it particularly useful. #5 is self-referential and useless. Only one or two (#9 and maybe #7) of those help distinguish OOP style from anything else, and #9 is not very compelling.

When I see OO code, I mostly think about the bundling of code with the data it operates on, but that is basically a module. So maybe it should be called module-oriented programming?

Re: OOP Isn't a Fundamental Particle of Computing

#134

Post by seanmcdirmid » Wed, Nov 14, 2012, 6:22 PM UTC

papsosouid wrote: post #124

seanmcdirmid wrote: post #118

Earlier quoted context omitted.

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…

>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. No? How would you get to that interpretation when I didn't even say anything about this theoretical person, but rather about you? >For what I do, I cannot afford to work with a PhD student who does not know more than one programming paradigm! Unless you are doing programming languag…

> Unless you are doing programming language research, yes you can.

Yes, I do, but no, its still a problem. With my colleagues, they are even more strict about OOP experience. I'm sort of unusual in that I appreciate FP experience, or I actually demand it, as part of finding well rounded candidates (very difficult in China, to be sure).

You don't "transform" the egg chemically from an unbeaten to a beaten state. Instead, you beat it, and that well-known transformation happens as a side effect. Also, after you've beaten the egg, you don't have an unbeaten egg to reuse elsewhere in another operation. Finally, someone has to beat the egg, either yourself or your assistant, or a machine designed specifically for beating eggs. In this way, FP does not map to the way normal people think.

Re: OOP Isn't a Fundamental Particle of Computing

#135

Post by atas » Wed, Nov 14, 2012, 6:24 PM UTC

> Corporate programmers in OOP-land often never get the architectural experience of writing systems (starting with small ones) from scratch. Instead, they spend their 40 hours maintaining and tweaking large monoliths other people wrote, and this is a big part of why they never improve.

You just described my 'career', sir.

Re: OOP Isn't a Fundamental Particle of Computing

#136

Post by seanmcdirmid » Wed, Nov 14, 2012, 6:27 PM UTC

chousuke wrote: post #126

seanmcdirmid wrote: post #122

Earlier quoted context omitted.

The problem with monads is that they DO leak into the type system. What effect the object has must be exposed for type checking reasons, and it can't be encapsulated, hidden, changed transparently, and so on. Try iterative algorithms, UI programming with views and models, an interactive code editor, etc...you get trapped quickly by the type system. The point is, you often want to be oblivious about what that object i…

I'm sorry, I don't see the problem. You can encapsulate away the state behind an opaque type so that it can be only accessed by functions that you have defined. Whether this is a good choice is up to the programmer, but it's common practice in haskell to use domain-specific types wherever it makes sense. For UIs and such, in addition to monads there are more powerful abstractions, but at no point is it necessary to l…

Ah, they just didn't design their UI libraries right? I hate this argument, because its easily proven true (someone just has to design a "right" library) and impossible to prove false (the "right" library could exist, it just hasn't been built yet).

The problem with Haskell, which isn't a problem in an impure FP like Clojure, is that you can't define objects at all (in the sense that objects completely encapsulate state). Yes, you can do a lot of nice combinator tricks, but these only work well for well understood problems, and so FP practitioners spend most of their time trying to understand problems very well so that they are amenable to their elegant abstractions. Whereas if I just use an OOP language (or a pragmatic FP language), I just solve the problem in a hacky way without needing to completely understand its essence (which, for me at least, only comes after I've solved the problem N times in N different ways!).

Closed classes suck, but not all OOP languages restrict you to closed classes. Scala does very well here, and traits are wonderfully expressive.

Re: OOP Isn't a Fundamental Particle of Computing

#137

Post by seanmcdirmid » Wed, Nov 14, 2012, 6:29 PM UTC

se85 wrote: post #109

seanmcdirmid wrote: post #93

Earlier quoted context omitted.

When you have state...I mean real state, it sure is nice to encapsulate that state in an object rather than in what is basically an unencapsulated monad. OO supports state encapsulation, pure FP basically does not, that is a big deal. Immutable programming sort of side steps the issue, that state is needed at all, that an interactive program can somehow be stateless is ridiculous, even many batch programs require som…

Oh really? A pipedream you say? Oh ok then...

Let me reply your one liner with my own: nice elegant composable abstractions are great when they work, and very horrible when they don't.

Re: OOP Isn't a Fundamental Particle of Computing

#138

Post by swift » Wed, Nov 14, 2012, 6:59 PM UTC

hackinthebochs wrote: post #94

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…

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.

If anything it's quite the opposite; most OOP languages are extremely limiting for DSL creation as compared to most FP languages.

Re: OOP Isn't a Fundamental Particle of Computing

#139

Post by swift » Wed, Nov 14, 2012, 7:03 PM UTC

debacle wrote: post #127

tikhonj wrote: post #119

Earlier quoted context omitted.

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.

It's a matter of maintainability. For the startup scene, the latter provides faster development, more flexibility, and a more intuitive codebase. When you reach corporate scales, convention needs to aid in the grokking of the codebase. I greatly prefer JavaScript in a functional style when I'm coding for myself, because I know the code in and out, but I prefer something more like C# when working on a team because the…

While conventions are useful, different conventions are appropriate for writing different kinds of code, and one should use the right tool for the job. Understanding code written in a functional style is something a good developer should be able to do for the same reason that recognizing design patterns in use is something a good developer should be able to do.

Re: OOP Isn't a Fundamental Particle of Computing

#140

Post by tikhonj » Wed, Nov 14, 2012, 7:09 PM UTC

debacle wrote: post #127

tikhonj wrote: post #119

Earlier quoted context omitted.

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.

It's a matter of maintainability. For the startup scene, the latter provides faster development, more flexibility, and a more intuitive codebase. When you reach corporate scales, convention needs to aid in the grokking of the codebase. I greatly prefer JavaScript in a functional style when I'm coding for myself, because I know the code in and out, but I prefer something more like C# when working on a team because the…

I think which one is more maintainable also depends on the makeup of your team. If it's primarily a bunch of Java/C# programmers, than the former style is best.

On the other hand, if you have a set of string programmers and a bunch of domain experts, the DSL style is not only faster but wait to maintain. Your core programmers should be good enough to deal with both the host language and the DSL with no difficulty, and your domain experts need only to understand the DSL, which could be easy since it's already optimized for their domains. I've certainly read about this approach being very successful with Haskell at a bank.

More generally, core logic should be easier to understand and maintain with a DSL. Perhaps this makes it harder to extend or repurpose the DSL without a good understanding of the host language and the codebase, but it makes working within the domain much easier, and makes it simpler to verify that the code is correct in regards to the specific domain.

Also, Javascript is not the best language for embedding DSLs; while it's not horrible, the syntax is inflexible and the semantics are somewhat limiting.