Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OOP Isn't a Fundamental Particle of Computing

prog21.dadgum.com

Post reply on HN
Print view View original

121–130 of 163 posts

Re: OOP Isn't a Fundamental Particle of Computing

#121

Post by pjmlp »

klibertp wrote: post #107
pjmlp wrote: post #102

Earlier quoted context omitted.

My argument is still the same. By having the data types exposed as objects, it doesn't matter what you do, because from the CS point of view you are still manipulating objects. Even lambdas and functions are objects with some kind of invoke method. So it is not possible to use those languages without OO, because OO is part of the language's type system. Using CS language speak, you cannot do language semantic analysi…

I think I don't understand what you mean. Why does it matter how lambda is implemented on the language level if it retains lambda semantics? Also, it seems that only languages you think worthy of being called "funtional" are various (typed or not) lambda calculi implementations? What is Scala, then? Not functional at all, too? Could you maybe provide a few examples of languages you'd call "functional" or "supporting…

Standard ML, Haskell, Miranda, Lisp, Scheme, OCaml, F#

Re: OOP Isn't a Fundamental Particle of Computing

#122

Post by seanmcdirmid »

chousuke wrote: post #110
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…

Could you explain why a monad is unencapsulated? As far as I can tell, using monads is a far superior way to encapsulate state, since it's impossible to use the state without also operating within the type universe that you've defined for your stateful calculations. Therefore, you can trivially tell if a piece of code is relevant to the state of your program, and it's enforced at compile-time. Further, since the actu…

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 is doing and when it is doing it.

Re: OOP Isn't a Fundamental Particle of Computing

#123

Post by dschiptsov »

That was solved long ago and already forgotten, or never noticed by ignorant.

When, for some specialized task, smart people need an object system they just write one in their high-level language. They called it CLOS.) Why? Because what we call OOP is just a set of conventions.

Almost every decent Scheme implementation has OO system.

btw, having message passing and delegation along with a supervision hierarchy of closures is what OO is meant to be by Alan Kay. He modeled hierarchies of people. So did Joe Armstrong.)

Programming is modeling. Smart people model real world phenomena. Idiots model AbstractFactoryInstantiatorBuilderSingletons.

Re: OOP Isn't a Fundamental Particle of Computing

#124

Post by papsosouid »

seanmcdirmid wrote: post #118
papsosouid wrote: post #111

Earlier quoted context omitted.

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

>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 language research, yes you can. Almost everyone already does, it is just that the only paradigm in question is imperative, rather than functional. That's not a significant barrier for the vast majority of roles, especially not PhD students.

>People don't talk in terms of transformations, they talk in terms of instructions,

That's the same thing. People think "beat the egg". Beating is a transformation, egg is a thing. People do not think "send the egg a message requesting it to change itself to the beaten state", which is why the OOP metaphor fails so badly. Functional programming directly maps to the normal way people think, as does traditional imperative programming. OOP does not.

Re: OOP Isn't a Fundamental Particle of Computing

#125

Post by se85 »

pjmlp wrote: post #86
klibertp wrote: post #67

Earlier quoted context omitted.

Python: "Paradigm(s): multi-paradigm: object-oriented, imperative, functional, procedural, reflective" JavaScript: "Paradigm(s): Multi-paradigm: scripting, object-oriented (prototype-based), imperative, functional" Ruby: "Paradigm(s): multi-paradigm: object-oriented, imperative, reflective, functional" From Wikipedia. So, where the faux pas is?

All data types in those languages are objects.

I agree (generally speaking).

I'm not sure at what point MVC based design patterns became the definition for OOP but stranger things have happened.

People calling JavaScript the new HTML5 gets me everytime!

To be fair though the topic of discussion was semantics so if we are only talking about semantics it is correct as per the dictionary terminology to call JavaScript an FP or an OOP because it is both.

Re: OOP Isn't a Fundamental Particle of Computing

#126

Post by chousuke »

seanmcdirmid wrote: post #122
chousuke wrote: post #110

Earlier quoted context omitted.

Could you explain why a monad is unencapsulated? As far as I can tell, using monads is a far superior way to encapsulate state, since it's impossible to use the state without also operating within the type universe that you've defined for your stateful calculations. Therefore, you can trivially tell if a piece of code is relevant to the state of your program, and it's enforced at compile-time. Further, since the actu…

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 leak information to the client. The common UI toolkits tend to have some impedance mismatch with FP because they've been designed with OOP in mind, but this is not the fault of FP.

Of course, in FP it often doesn't even make sense to encapsulate everything. Why hide useful data when it's guaranteed that any user will not be able to misuse it?

Haskell provides tools for abstraction that are IMO vastly superior to anything I've seen in an OOP language. If anything, you're more likely to have leaky abstractions and failed encapsulation in Java or C++ compared to Haskell, simply because of mutable state, closed classes, and limited expressiveness of the type system.

Re: OOP Isn't a Fundamental Particle of Computing

#127

Post by debacle »

tikhonj wrote: post #119
debacle wrote: post #98

Earlier quoted context omitted.

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.

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 then at least there is a set of more strict conventions we have to adhere to.

Re: OOP Isn't a Fundamental Particle of Computing

#128

Post by cwbrandsma »

stcredzero wrote: post #120
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.

Yes, then you get VB6. Not sure that is the paragon of language design you are looking for.

Inheritance is a very useful tool, but like many other things, overuse of inheritance is worse than not using it at all.

Re: OOP Isn't a Fundamental Particle of Computing

#129

Post by zwieback »

mercurial wrote: post #75

Given the amount of comments on this article, I feel like I'm the only one who missed the point the author is trying to make. TFA goes from praising the existence and ease of use of data types, particularly collections, in high-level languages such as Python (an object-oriented language) and constrasts it to C and Pascal (neither of which are object-oriented) and then seems to extoll the virtues of relying on basic d…

I had the exact same impression. Your Libya analogy is perfect.
Post reply on HN