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

Goodbye, Object Oriented Programming

medium.com

Post reply on HN
Print view View original

331–340 of 355 posts

Re: Goodbye, Object Oriented Programming

#331

Post by l_dopa »

seanmcdirmid wrote: post #298
l_dopa wrote: post #293

Earlier quoted context omitted.

It sounds like we agree that lexically scoped immutable values are easier to understand, either precisely or with fuzzy metaphors. I'm not sure what "ideal" FP is or how it might have a certain "mathematical view of the world". The features I mentioned are just a subset of semantics that every high-level language programmer already knows, but are pointlessly hobbled in popular languages. Why should expressing somethi…

You mean CLOS? This is exactly the context RPG coined "worse is better". Languages are not so much a collection of features but mindsets. So polymorphism, dynamic dispatch, subtyping, etc...do not define OOP so much as they are leveraged by those languages to enable reasoning with names and metaphors. Calling them just domain specific features misses the point like talking about some dish only as the sum of its ingre…

  Languages are not so much a collection of features ...
If you want to define objects precisely, even just to have a language spec, they are absolutely made up of sums, products, recursive types, etc. Whatever useful metaphors one might have to work with objects doesn't change what they actually are. If you give the programmer access to these building blocks, you get ML.

  Calling them just domain specific ...
I meant that the particular way they're combined to get OOP is domain-specific.

Again, I'm just asking: why mess with the basics? Why require encoding simple, universal concepts in terms of an ad-hoc object system? You can still have an object system on top, if you find that helps with the really complicated cases, but why encode the parts of your code that are simple in terms of much more complicated, derived concepts?

Re: Goodbye, Object Oriented Programming

#332

Post by dmbarbour »

seanmcdirmid wrote: post #311
dmbarbour wrote: post #302

Earlier quoted context omitted.

> And how often does that occur in practice for most of the programs people write? Very frequently. The simple theorems that equational reasoning supports are very convenient for refactoring and optimizing code. Understanding components in isolation is useful for testing, isolating bugs, and refactoring of subprograms independently from their contexts. Since I do testing and refactoring frequently, I make good use of…

> Very frequently. The simple theorems that equational reasoning supports are very convenient for refactoring and optimizing code. I was generalizing across all programmers. Of course individual cases may vary, and it really depends on the code that you write! > Not really. Statically typed OO doesn't prove nearly as much about the behavior. This is mostly due to potential for aliasing of stateful sub-components. Has…

> generalizing across all programmers

I think the relevant question is whether functional programmers, not all programmers, regularly leverage the lightweight equational reasoning, refactoring, and context-independent behavior that is available with purely functional programming. I believe most do.

> avoids aliasing with value semantics, and even then you can add it back and get the same problems (...) you have to bury the state in something else, which is then exposed via a signature

In a programming model without side-effects, it is necessarily the case that all 'effects' are modeled in the call-return behavior. The type signature, too, for a strongly typed language. And I agree that, upon modeling state or aliasing, we get to deal with not just the feature but all of its associated problems.

OTOH, the problems of state and aliasing don't implicitly leak into every subprogram. The precise control over effects can be very convenient.

You couch that control in pessimistic terms like "pollute all function signatures it buried through". But in practice I've never had difficulty anticipating where I'll need to model effectful behavior, nor with extending the set of effects as needed. Oleg's recent development of freer monads with more extensible effects [1] is compelling in its potential to remove remaining drudge-work.

[1] http://okmij.org/ftp/Haskell/extensible/more.pdf

> We could debate a lot on what pure FP is, what pure OO is (...) paradigms developed around the same time

Pure FP (programming with mathematical functions, no side-effects) and impure FP (i.e. first-class procedural programming) are essentially different paradigms. They require different patterns of thinking, reasoning about, and constructing programs. Despite the ongoing battle over the "functional programming" branding, it isn't wise to conflate the two paradigms. It was impure FP that developed around the same time as OOP. Pure FP is about twenty years younger, more or less.

(The mention of 'pure OO' seems an irrelevant distraction. Do you believe pure OO vs. impure OO, however you distinguish them, require significantly different design and development patterns and are thus distinct paradigms?)

Re: Goodbye, Object Oriented Programming

#333

Post by lispm »

justin_vanw wrote: post #316
GFK_of_xmaspast wrote: post #209

Earlier quoted context omitted.

> Neither Schema nor Lisp nor any but a very few quite obscure languages satisfy this. That doesn't seem like it would be a very useful definition then.

Haskell, Ocaml, etc. There's nothing at all functional about Common Lisp, not even a little bit, far from it, if anything the opposite.

Which is nonsense.

Common Lisp and its implementations supports some parts of Functional Programming:

* First Class Functions

* Higher Order Functions

* Anonymous Functions

* Lexical Binding

* Closures

* TCO is supported by a variety of implementations

Re: Goodbye, Object Oriented Programming

#334

Post by pdimitar »

eru wrote: post #233
pdimitar wrote: post #146

Earlier quoted context omitted.

I would argue this is inertia and a hype train that never slowed down -- up until the last 2 or so years that is. I do agree with you that thinking in FP takes a bit more experience however.

Actually, from what I've seen, pure FP forces people with less experience into design and structures of their code that they'd only do in imperative settings with considerably more experience. Eg when I asks students to do some simple exercise like "write a function that finds the shortest path through a given graph", in impure languages their solutions tend to return a path if they find one, but just give up with eg…

I'm sure you're right. Apologies for me misleading. It appears I'm twisted by years of OOP during the start of my career.

Re: Goodbye, Object Oriented Programming

#335

Post by sctb »

aibottle wrote: post #31

God damn it I begin to hate Medium. Just another Bullshit article. When I read those dips ts description: "Software Engineer and Architect, Teacher, Writer, Filmmaker, Photographer, Artist…" Great. And you want to tell me that OO is dead and functional the only future? Fuck off.

Aside from the quality of the submitted article, this comment does not contribute to the discussion and invites a trail of predictably off-topic replies. Please comment civilly and substantively on HN, or just not at all.

Re: Goodbye, Object Oriented Programming

#336

Post by justin_vanw »

qwertyuiop924 wrote: post #329
justin_vanw wrote: post #317

Earlier quoted context omitted.

How is 'the same year as smalltalk' predating it? Simula was working in like '67, which is like 5 years before smalltalk. My point is that functional languages do not predate OO languages, and if anything come later, and you never really addressed that.

>How is 'the same year as smalltalk' predating it? That's just the first one that was implemented. The IDEAS reach far further back. ISWIM was '66, it it's not the oldest. >My point is that functional languages do not predate OO languages, and if anything come later, and you never really addressed that. Between my points on Lisp, ISWIM, Lambda Calculus, and others, I think I did that quite adequately.

Not really? The claim that functional programming predates OO would require that functional programming languages existed before OO languages, which is clearly false. If anything they were both developed at approximately the exact same time, which has more to do with hardware coming into existence and wider use that could support higher level languages.

Re: Goodbye, Object Oriented Programming

#337

Post by qwertyuiop924 »

justin_vanw wrote: post #336
qwertyuiop924 wrote: post #329

Earlier quoted context omitted.

>How is 'the same year as smalltalk' predating it? That's just the first one that was implemented. The IDEAS reach far further back. ISWIM was '66, it it's not the oldest. >My point is that functional languages do not predate OO languages, and if anything come later, and you never really addressed that. Between my points on Lisp, ISWIM, Lambda Calculus, and others, I think I did that quite adequately.

Not really? The claim that functional programming predates OO would require that functional programming languages existed before OO languages, which is clearly false. If anything they were both developed at approximately the exact same time, which has more to do with hardware coming into existence and wider use that could support higher level languages.

ISWIM did exist, even if the compiler wasn't there. The lisp community did a lot of work with FP-style code, even if the language as a whole wasn't functional: the idea was still there.

But your main point was that FP was useless, deriding it, and claiming that, "only people that talk about it are academics and people who want to seem smart," which is demonstrably not true.

Even Smalltalk had map, filter, etc, and HOFs.

Re: Goodbye, Object Oriented Programming

#338

Post by seanmcdirmid »

dmbarbour wrote: post #332
seanmcdirmid wrote: post #311

Earlier quoted context omitted.

> Very frequently. The simple theorems that equational reasoning supports are very convenient for refactoring and optimizing code. I was generalizing across all programmers. Of course individual cases may vary, and it really depends on the code that you write! > Not really. Statically typed OO doesn't prove nearly as much about the behavior. This is mostly due to potential for aliasing of stateful sub-components. Has…

> generalizing across all programmers I think the relevant question is whether functional programmers, not all programmers, regularly leverage the lightweight equational reasoning, refactoring, and context-independent behavior that is available with purely functional programming. I believe most do. > avoids aliasing with value semantics, and even then you can add it back and get the same problems (...) you have to bu…

> I think the relevant question is whether functional programmers, not all programmers, regularly leverage the lightweight equational reasoning, refactoring, and context-independent behavior that is available with purely functional programming. I believe most do.

This begs the question of who is a functional programmer, and how typical are they? I know a few FP programmers who are able to stay in the abstract world for a long time, thinking symbolically, equationally, and don't need petty things like concrete examples (most of the members of WGFP, for example). Then there is the rest of us!

> In a programming model without side-effects, it is necessarily the case that all 'effects' are modeled in the call-return behavior. The type signature, too, for a strongly typed language.

You can always default to World -> World in a pure language, and ya...technically you don't have side effects anymore, but for all practical purposes you do! For this to be useful at all, you have to keep your effects fine grained, and for functions that call other functions (like a general ForEach), effects have to be parametric as well, or you wind up polluting everything (or worse, being unable to express something).

Pure FP culminates from a bunch of experience in the 70s (I'm not talking about Lisp), which happens to be where OO came from as well. Pure OO doesn't really make sense...OO can't be pure but rather organic.

Re: Goodbye, Object Oriented Programming

#339

Post by dmbarbour »

seanmcdirmid wrote: post #338
dmbarbour wrote: post #332

Earlier quoted context omitted.

> generalizing across all programmers I think the relevant question is whether functional programmers, not all programmers, regularly leverage the lightweight equational reasoning, refactoring, and context-independent behavior that is available with purely functional programming. I believe most do. > avoids aliasing with value semantics, and even then you can add it back and get the same problems (...) you have to bu…

> I think the relevant question is whether functional programmers, not all programmers, regularly leverage the lightweight equational reasoning, refactoring, and context-independent behavior that is available with purely functional programming. I believe most do. This begs the question of who is a functional programmer, and how typical are they? I know a few FP programmers who are able to stay in the abstract world f…

Methinks you misunderstand the programming experience of FP. A nice property of 'equational reasoning' is that, as a universal property of code, I don't have to think about it. It just becomes a law of code - conservation of meaning. Abstraction, splicing, refactoring, and reuse happens easily and fluidly because I don't need to think about whether those actions are safe or correct. It isn't about hand-wavy abstract worlds at all, but rather concrete manipulation of source code. Concrete examples are also very common and useful with pure FP, e.g. use of REPLs is common.

A pure `World→World` effects model is NOT a practical equivalent to introducing side-effects. Unlike with side-effects, it's trivial to constrain a subprogram from access to the whole World, e.g. use divide and conquer tactics to hide parts of the world, or limit a subprogram to a constrained subset of monadic commands that an interpreter uses to access and update the world in limited ways.

No experience from the 70s left academics or industry prepared to support purely functional IO models. It should go without saying that you can't have a complete programming paradigm without an effective story for IO. Miranda, an attempt at a purely functional language of the mid 80s, made a valiant attempt at pure IO, and failed. Even early Haskell, up through the early 90s lacked an effective, coherent story for IO. I find your repeated assertions that pure FP was somehow a child of the 70s to be very dubious.

Re: Goodbye, Object Oriented Programming

#340

Post by seanmcdirmid »

dmbarbour wrote: post #339
seanmcdirmid wrote: post #338

Earlier quoted context omitted.

> I think the relevant question is whether functional programmers, not all programmers, regularly leverage the lightweight equational reasoning, refactoring, and context-independent behavior that is available with purely functional programming. I believe most do. This begs the question of who is a functional programmer, and how typical are they? I know a few FP programmers who are able to stay in the abstract world f…

Methinks you misunderstand the programming experience of FP. A nice property of 'equational reasoning' is that, as a universal property of code, I don't have to think about it. It just becomes a law of code - conservation of meaning. Abstraction, splicing, refactoring, and reuse happens easily and fluidly because I don't need to think about whether those actions are safe or correct. It isn't about hand-wavy abstract…

REPLs don't help out with refactoring, splicing, or even abstraction, at least with the current tool chain we have.

IF you add a World->World effect to your function, it is the equivalent to saying it has unconstrained side effects, is it not? It is the practical equivalent, even if its implementation can pair off the world as needed.

Hindley Milner, Landin, ISWIM, APL, list comprehensions, etc...are all children of the 70s. The IO problem wasn't solved until Wadler in early 90s, but then again we didn't get type parameters in OO languages before then either.

Post reply on HN