Live data from Hacker News

Goodbye, Object Oriented Programming

medium.com

341–350 of 355 posts

Re: Goodbye, Object Oriented Programming

#341

Earlier quoted context omitted.

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…

Wat? It's equational reasoning that lets us manipulate concrete code easily. REPLs are just proof that functional programmers like working concrete examples, too.

A World->World function is unconstrained in its effects upon the given world, modulo substructural types. But it is not a "side effect". Among other important differences, your program can't describe an infinite loop with observable effects on that World.

I don't consider type safety, list comprehensions, etc. to be essential for pure FP. Immutable values, first class functions, and explicit effects models on the call-return path (instead of side effects) are the critical ingredients. Comparing the essential IO problem to "type parameters" (which aren't even a problem for a rich ecosystem of dynamically typed OO) seems disingenuous.

Re: Goodbye, Object Oriented Programming

#342
post #233

Earlier quoted context omitted.

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.

Haha. No worries. Mine is also just an observation I made with the few people I'm mentoring and teaching.

Also, they seem to grasp recursion much better via Haskell than in Python or Java. I believe that's mostly because Haskell makes structural recursion real easy (ie recursion along the structure of your data type, eg like along a tree)---and once they are comfortable with the basic idea from that, other patterns of recursion are easier to understand.

Algebraic datatypes and pattern matching on them are a great benefit for that structural recursion.

Re: Goodbye, Object Oriented Programming

#343

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…

Side effect free functional programming was taught using Lisp in the 60s.

See "Pure Lisp", a style and subset, where no side-effects has been used.

Re: Goodbye, Object Oriented Programming

#344

Earlier quoted context omitted.

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

map, filter, etc are not 'functional'. 'functional' doesn't mean 'functions'. It is all about side effects, and that the procedures in the language are like mathematical functions: without state or side effects.

Using your definition, virtually every language in use today is 'functional', all the way down to Fortran 77, since really any language you can get a pointer or other handle to a function or callable object would let you implement map, filter, etc.

Really the existence of map, filter, etc are not a clue to a language being 'functional'. Yes, you would need such things, but they are not sufficient. C is not a 'functional language', even though technically you can write C that is completely functional in style.

In fact, almost any modern language can be used in a 100% functional style, avoiding side effects and state completely. Nobody does this.

Even if it is one of your favorite things, virtually no one uses functional languages. This isn't because people are dumb, it's because functional languages are cumbersome and inefficient.

Re: Goodbye, Object Oriented Programming

#345

Earlier quoted context omitted.

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

"demonstrably not true"

Where are the software projects that are built using functional languages?

I'll call out XMonad. What can you come up with? Obscure companies doing obscure things, or else people using Common Lisp in a nonfunctional way.

What major project or product is built using Haskel or Ocaml? There aren't any! The only thing I have ever used that were written in those languages are XMonad and csvtool respectively.

Re: Goodbye, Object Oriented Programming

#346
post #343

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…

Side effect free functional programming was taught using Lisp in the 60s. See "Pure Lisp", a style and subset, where no side-effects has been used.

I wasn't able to find much on this via search. The papers I found date to 96. Do you know how 60s Pure Lisp handled IO?

Re: Goodbye, Object Oriented Programming

#347

Earlier quoted context omitted.

I did look at the source and it seemed that way (imperative code using flat arrays) but I don't know enough OCaml to say with certainty. I have worked with other functional languages (Clojure) and I have optimized GCed code and it mostly boils down to what I said - writing C/C++ like code in language X to get as close to hardware memory model (avoiding GC by pooling, increasing cache coherence, using value types or m…

No, that won't happen, but a lot of the code that you write in a functional language can be optimized far better than another language, because the compiler has more, stronger guarantees about your code.

There's some truth to this, but "can be optimized" is not the same as "there exists a compiler that optimizes". Your statement gets repeated a lot (and similarly about the JVM: it has run-time information that compilers don't have, so can optimize better), and yet C++ and Fortran continue to come out on top.

Re: Goodbye, Object Oriented Programming

#348

Earlier quoted context omitted.

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

map, filter, etc are not 'functional'. 'functional' doesn't mean 'functions'. It is all about side effects, and that the procedures in the language are like mathematical functions: without state or side effects. Using your definition, virtually every language in use today is 'functional', all the way down to Fortran 77, since really any language you can get a pointer or other handle to a function or callable object w…

I would not think passing procedure pointers in C makes it able to support functional programming. That's very shallow.

C lacks (last I looked) nested functions, closures, functions as first class data types, ...

> Really the existence of map, filter, etc are not a clue to a language being 'functional'.

'Functional Programming' isn't black and white. There are pure languages which ENFORCE functional programming like Haskell. It's their many paradigm, the language and its library make heavy use of FP and one has to actively manage side-effects.

Then there are language which SUPPORT some forms of functional programming, for example by providing a subset in the language and its libraries which can be used side-effect free, makes use of higher-order functions, etc.

At the bottom are languages which ENABLE some basic functional programming idioms. Though most of the language and its libraries are not using FP, the user can still use some FP constructs like nested functions, closures, etc.

Generally I agree, that pure FP is not that much used in the real world because of a lot actual problems (difficult to learn/use/maintain, efficiency might be achievable by experts, needs understanding of slightly advanced mathematical concepts, ...). There are some more or less used implementation languages of more or less pure FP (GHC, OCAML, F#, ..., Clojure) languages. I'd guess that the main applications are in domains where they have highly skilled people: finance, data analytics, verification/specification, ...

I sometimes see that companies advertise use of FP languages, but in reality that's marketing in recruiting to look cool and to attract clever people (who then have to work on Java jobs, mostly).

Re: Goodbye, Object Oriented Programming

#349

Earlier quoted context omitted.

No, that won't happen, but a lot of the code that you write in a functional language can be optimized far better than another language, because the compiler has more, stronger guarantees about your code.

There's some truth to this, but "can be optimized" is not the same as "there exists a compiler that optimizes". Your statement gets repeated a lot (and similarly about the JVM: it has run-time information that compilers don't have, so can optimize better), and yet C++ and Fortran continue to come out on top.

Indeed, because C++ and Fortran get the money and time, and they're closer to the metal to begin with. Also, C++'s "Nasal Demons on UB" problem helps a lot.

But yes, OCaml is quite fast, and probably could be faster. Does it really beat C++ in all contexts? Probably not, but it's still pretty fast.

Re: Goodbye, Object Oriented Programming

#350

Earlier quoted context omitted.

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

"demonstrably not true" Where are the software projects that are built using functional languages? I'll call out XMonad. What can you come up with? Obscure companies doing obscure things, or else people using Common Lisp in a nonfunctional way. What major project or product is built using Haskel or Ocaml? There aren't any! The only thing I have ever used that were written in those languages are XMonad and csvtool res…

I called out several in my original post. You want more? Elm, for one.
Post reply on HN