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

261–270 of 355 posts

Re: Goodbye, Object Oriented Programming

#261

Post by cousin_it »

eru wrote: post #242
dkarapetyan wrote: post #66

Earlier quoted context omitted.

You mean lambda calculus? That model has plenty of shortcomings. Someone recently pinpointed the problem for me. Complexity analysis is impossible in a system that is inherently unaware of time and computational cost of transition rules. Lambda calculus is inherently timeless (both in the theoretical sense because of turing equivalence and the practical sense of being unable to provide a proper framework for complexi…

You can count your reduction steps in lambda calculus just fine. Can't you?

If you want a foundation for computing, may I humbly suggest imperative algorithms in the integer RAM model. That gives correct answers to questions like "what's the time and space complexity of quicksort in the average and worst case?" Good luck answering that with lambda calculus, or Turing machines for that matter.

Re: Goodbye, Object Oriented Programming

#262

Post by davedx »

whateveracct wrote: post #127
lispm wrote: post #117

Earlier quoted context omitted.

The real disadvantage of pure functional programming is that it is notoriously difficult to use and thus only very few programs outside specialized domains are written in them. For example I would guess that in a typical enterprise (say, a manufacturing company), 0.0001% of the software is written in a pure functional language. Things OO languages 'force' us seem to be relatively easy to use: sending a message to a c…

I work in a group of teams that is mostly new college grads and nobody has trouble writing pure FP business logic in Scala. We don't go as far as doing pure FP for all effects though (although we are starting to do that more as well) If we can do it, so can everyone else ;)

In my experience, business logic is often relatively easy to express in pure FP. Where things start to get trickier is the boilerplate and boundaries, e.g. I'm writing a Rails app at the moment where the business logic is in pure functions, but the boundaries with other systems like ActiveRecord and external webservices tends to end up being more object-oriented.

For example, the ruby library I use to connect to webservices is very OO, and requires you to derive from its base class to build each webservice client.

This is of course very natural in Ruby, but I do see lots of OO in Scala libraries too (e.g. Spray).

Re: Goodbye, Object Oriented Programming

#263

Post by lmm »

seanmcdirmid wrote: post #155
eutectic wrote: post #108

Earlier quoted context omitted.

Except that there is a real advantage to using pure functional programming; being able to easily prove theorems about your code and understand different components in isolation. There is a reason why the majority of proof assistants are implemented as functional languages. Most functional languages even give you ways of modelling imperative code (e.g. monads) in a way which hardly sacrifices expressiveness. The real…

> Except that there is a real advantage to using pure functional programming; being able to easily prove theorems about your code and understand different components in isolation. And how often does that occur in practice for most of the programs people write? Even the most hardcore Haskell programmer isn't going around proving theorems about their modules beyond what the type system can provide for free (and that is…

> And how often does that occur in practice for most of the programs people write? Even the most hardcore Haskell programmer isn't going around proving theorems about their modules beyond what the type system can provide for free (and that is true of statically typed OO also).

"What the type system can provide for free" isn't static. Part of working in that kind of language is structuring your code such that important properties end up being proved by the type system.

It rarely rises to the level of a "theorem", but "is this piece of code equivalent to this other piece of code?" is what I'd venture to suggest programmers spend most of their day asking, and Haskell-like languages make that easier to answer.

Re: Goodbye, Object Oriented Programming

#265

Post by davedx »

astrobe_ wrote: post #253
eru wrote: post #235

Earlier quoted context omitted.

As a weaker form of going around and proving stuff: people do care a lot about properties. We just check them via QuickCheck, instead of formally proving them. And we organize our programs such as to get nice properties.

If you ask me what's the opposite of "proving", I'd say it's "testing". You call that "weaker"? It's the weakest form of validation I know of.

It may be weak, but by hell it's practical. Tons of tooling, tons of engineers who understand it, and with a pragmatic approach, eliminates many bugs and regressions.

Re: Goodbye, Object Oriented Programming

#266

Post by pjmlp »

EdJiang wrote: post #3

Interesting. I almost though this was going to be an advertisement for Swift, since I saw this exact argument in a WWDC talk. Apple calls Swift a "protocol-oriented" programming language, and with the addition of first class value types, tries to solve these problems in their own way. I'd definitely suggest people frustrated by the problems outlined in this post to check out the Apple talk on protocol-oriented progra…

Protocols are as old as Objective-C, and were the inspiration for interfaces.

They are also widely explored in languages that support some kind of polymorphism.

The problem is getting the common developer interested in making good use of them.

Re: Goodbye, Object Oriented Programming

#267

Post by pjmlp »

vegabook wrote: post #115
ryanmarsh wrote: post #97

How about we just say this: OO solves a set of problems albeit with tradeoffs Functional solves a set of problems albeit with tradeoffs There. We can all go back to our tea.

yep... I was just dunking a hobnob while writing some good old imperative C. Did anybody notice that Vulkan, "the future" of graphics APIs, doesn't f*ck around with OO or Functional?

However Metal, DirectX and the console APIs do.

Khronos are the ones that still leave in pure C world.

Hence why most researchers went to CUDA in terms of language support and now they are trying to catch up with SYSCL and SPIR.

Re: Goodbye, Object Oriented Programming

#268

Post by Chattered »

jghn wrote: post #60
vinceguidry wrote: post #28

Inheritance is overused in OOP. There are many ways to share object behaviors, inheritance only works well when you expect all objects of both classes to share all behavior except one or two things. Even then, you should investigate dependency injection before reaching for inheritance. For the example given for the Triangle Problem, the author isn't clear about exactly what behavior is being shared among the classes.…

From a purist view one could argue that inheritance doesn't belong in OO in the first place. Alan Kay's first descriptions of Smalltalk & OOP did not include inheritance concepts.

Kay has also suggested that late binding or dynamic dispatch is a massive deal, and in most statically typed oop languages, dynamic dispatch is typed according to the inheritance hierarchy.

The upshot is that to teach OOP in Java, say, you need to talk about significant parts of the inheritance machinery just to get dynamic dispatch, perhaps later cautioning against implementation inheritance and even interface inheritance.

In Smalltalk, you can talk dynamic dispatch without messing around with inheritance at all.

For a statically typed language where dynamic dispatch is free from inheritance graphs (sometimes described by saying that subtyping is not inheritance) see Ocaml's structural subtyping via row polymorphic records (bit of a mouthful --- but I need to differentiate from Ocaml's module system which is structurally subtyped and supports inheritance!)

Re: Goodbye, Object Oriented Programming

#269

Post by rejschaap »

eru wrote: post #241
mk89 wrote: post #81

When I read such titles I feel sad. In 2016 we are still talking about Cobol, which is spread in a relatively niche market and considered as a pillar in fields like banking, how can the object oriented paradigm be considered " past or even bad? It is the present and will be the future for at least the next 20 years, considering the number of billions lines of code. From a management perspective, such statements are n…

Cobol is certainly considered bad.

But good enough to be widely used for some of the worlds most important business processes such as payrolling and banking.

Re: Goodbye, Object Oriented Programming

#270

Post by Ntrails »

discreteevent wrote: post #250
eru wrote: post #231

Earlier quoted context omitted.

The majority of software written ever has been written in the world's most popular functional programming language: Excel.

Yes but the majority of excel sheets consist of calculations. The source code of many OO programs will also consist of pure functions if that program is focused on calculation. So calculations are easy to express as pure functions, everybody knows that. On the other hand, if you want to make an interactive application in excel you use VBA which exposes a large and rich set of objects.

>On the other hand, if you want to make an interactive application in excel you use VBA which exposes a large and rich set of objects.

Please don't encourage this. Because honestly debugging VBA written by consultants has definitely shortened by lifespan by a couple years

Post reply on HN