Live data from Hacker News

Joe Armstrong: Why OO Sucks

harmful.cat-v.org

181–190 of 267 posts

Re: Joe Armstrong: Why OO Sucks

#181
post #74

Earlier quoted context omitted.

Instead of giving you an example that anybody actually uses, I'm going to tell you about a cool idea I've been reading about that hasn't gotten much actual use. The basic idea is to use a generalization of pattern matching. Languages like ML and Haskell support pattern matching, but in rather limited ways. Crucially, patterns are not first-class citizens of the language. (For Haskell, at least, there are some librari…

Thanks for an excellent write up to the idea. That was very clear. I am very intrigued and was looking at purchasing that book to learn more - but then I saw the price. I'll have to scrounge a copy from a library somewhere. I thought on demand printing was going to reduce the costs of books on the long tail!

Oh hey, it seems that you can also read it online: http://www.springerlink.com/content/978-3-540-89184-0.

I'm not sure if there are any restrictions on this, and the format is annoying, but it might be worth looking into.

Re: Joe Armstrong: Why OO Sucks

#182
post #134

Earlier quoted context omitted.

I'm afraid that I'm not too familiar with either active patterns or GADTs at the moment. However, given the understanding that I do have, I think they are both unrelated to the basic dynamic pattern matching that I was talking about. As far as I can tell, active patterns only affect the constructor . They let a constructor like Even to run an arbitrary function when it's matched. This lets you customize what a constr…

Excellent! Thank you, yes I am clearer, the concept is even more awesome than I thought . >I think active patterns do not constitute first-class patterns. I agree, but like I said, they are the closest thing in active use, they extend the type of structures one can deconstruct to encapsulated ones while being more flexible in implementation. They fall in the class of techniques which extend and make matching more fle…

I think the main advantage is what I pointed out before--being able write functions that work on a wide variety of data types. I think my count example is something that could not be done with GADTS:

    count constructor (constructor) = 1
    count constructor (constructor x̂) = 1 + count x̂
    count _ (x̂ ŷ) = count ŷ
Keep in mind that this is pseudocode, so some of the semantics may not be perfect. The basic idea is this: the first argument count takes is a pattern, like a constructor. The second argument is matched against the dynamic pattern (constructor x̂). This pattern has one matchable variable x̂ and one free variable constructor. This free variable is bound in the previous argument to the function.

So this lets you use the count function to count any sort of sub-pattern in its argument. Let's imagine you have some hierarchy like (Book (Cons (Chapter stuff) (Cons (Chapter stuff) nil))). You could use the count function to count the number of chapters like this:

    count Chapter book
Basically, you're parametrizing your count function on the pattern you want to count. So count can work on any data type and any pattern. If you wanted to count sections, you could:

    count Section book
Now lets pretend that sections have numbers. Instead of (Section content) we have (Section number content). You can now count something like how many sections have the number 5:

    count (Section 5) book
I think you could generalize this even further, but it would be more complicated.

I'm not sure how this is typically implemented, largely because it typically isn't :P. I think there's essentially one implementation in a language called bondi[1] but I don't know how it is implemented.

[1]: http://bondi.it.uts.edu.au/

As for decidability, I'm not sure. The entire pattern calculus--that is, an extension of lambda calculus supporting this sort of pattern matching--is Turing-complete. I don't know if just the pattern matching part is undecidable though.

As I said in my original post, there is a nice book on this called Pattern Calculus. I think you can read it online[2], which is nice because it turns out to be fairly expensive on Amazon.

[2]: http://www.springerlink.com/content/978-3-540-89184-0

Re: Joe Armstrong: Why OO Sucks

#183
post #100

Earlier quoted context omitted.

Just because it is Functional Programming it does not mean to "throw away encapsulation". Most languages still allow you to limit the extent to which a piece of data is exposed. And that is needed for large systems - otherwise you will have to change many many functions as your data representation changes. This is also true of loose coupling. Seeking to modularize your code is always a good idea - but it is not impos…

> Just because it is Functional Programming it does not mean to "throw away encapsulation". Surely not, as even Clojure has support for OO programming. But Rich Hickey says that 90% of the time that encapsulation is used by OO programmers, it shouldn't have been. Instead, they should have just used a map or a list, etc. So, does something as complex as representing a book fall into the 90% case or the 10% case? Or ma…

Even more - encapsulation is not always mean OOP.

Erlang have encapsulation more strong than in any OOP language - all you have is server process and messages thrown to it.

Re: Joe Armstrong: Why OO Sucks

#184

The people who originally came up with OOP knew what they were doing. The inspiration was the cell, which hides immense mechanical complexity behind a simpler interface of electrical and chemical signals. When interfaces are simple, it limits the unexpected dependencies that can exist between software modules. Alan Kay wasn't saying, "Go off and write bloated objects" but, "When software must be complex, strive to pr…

"People should be required to learn the basics of programming first. They should start with immutable data objects" Immutable data objects and all the stuff are not the basics of programming. They never were. Unless you single-handedly redefine the meaning of "programming". The whole text you just wrote is full with dumb self-praise and deprecation of others; based on worship of principles that were never proven to p…

There's no need to redefine programming. There are essentially two fundamental ways to approach a program: what it does (coming from EE) and what it means (coming from math).

If you're coming from the first perspective, than mutation is fundamental. Registers are always changing in value and everybody likes self-modifying assembly.

However, if you're coming from the second direction--which is at least as fundamental as the first--the basis of computation does not involve mutation. This is where the lambda calculus comes in. It's the abstraction that underlies most of the mathematically well-behaved languages. And in the lambda calculus, as well as a bunch of its popular variations, there is no mutation.

From this second perspective, immutable data is a basic building block of programming. Essentially, all you have are functions that can bind names to arguments and be applied to each other. It's a surprisingly simple and elegant model.

There are some other popular models of a computer program like the SKI calculus. However, it's easy to translate between the lambda calculus and SKI calculus, so for the purpose of this discussion they are effectively the same.

So from a more mathematical standpoint, functional programming is more fundamental than imperative programming. Redefining the meaning of "programming" is not required!

Re: Joe Armstrong: Why OO Sucks

#185
post #36

Earlier quoted context omitted.

The key word there is gigantic not OO . All gigantic systems are crappy, no matter what their underlying language/paradigm is. Slightly less crappy is a win.

The problem is that OO thinking tends to inflate systems, spreading code all over the place even though it logically belongs in one place and adding object wrappers to things that don't need it. In my experience taking over Python code written by Java developers, I can usually shrink their OO code and make it more reliable by refactoring it into conceptually equivalent functional code wherever it makes sense and fall…

If you trying to write FP in Python - you're in trouble. (Python is my main language for several years)

It does not have "mandatory OOP" but it remains as mainly imperative OO-language with some FP-goodness. C# is the same, Java - not.

Re: Joe Armstrong: Why OO Sucks

#186
post #54

Wow, I am genuinely shocked by the comments in this thread. I didn't realise that so many people held the polar opposite view to me. It's a bit like suddenly finding out that all your friends are racist. I love object oriented programming. For me it aligns perfectly with the way I think - it allows me to produce a system of interrelated 'things' where each thing (or group of things) has a well-defined role and can hi…

"Trying to do that without object-oriented features would be like trying to write a letter by holding the pen with my teeth"

I think what you're imagining here is Java without the OO bits. And that would be horrible!

What you should imagine is Haskell. That's more like typing a letter instead of hand-writing it, to overstretch your metaphor.

I've found that it's much easier to write much more elegant code in Haskell than it is in any OO language. Instead of writing a program without OO features, you're writing a program with advanced functional features. Rather than just being removed, the OO features are replaced.

Re: Joe Armstrong: Why OO Sucks

#187

I'm all for proper rants against popular tools to keep people on their toes. This isn't one of those. "Objects bind functions and data structures together in indivisible units. I think this is a fundamental error since functions and data structures belong in totally different worlds." Sure—a class defines a type and operations on that type. What's fundamentally wrong about date.addDays(1) vs. date_add_days(date, 1)?…

I owe the author an apology on one point. "Minimise" is a correct spelling, though neither my system's dictionary or I realized this.

I think minimise vs minimize is just British vs American spelling respectively. So neither is strictly wrong.

Re: Joe Armstrong: Why OO Sucks

#188
post #178

Earlier quoted context omitted.

"People should be required to learn the basics of programming first. They should start with immutable data objects" Immutable data objects and all the stuff are not the basics of programming. They never were. Unless you single-handedly redefine the meaning of "programming". The whole text you just wrote is full with dumb self-praise and deprecation of others; based on worship of principles that were never proven to p…

Coming off conceited doesn't make him wrong regarding CS curriculum. He believes that people should have strong underpinnings in functional programming principles before learning oop. I think fp plays off required math classes pretty well. Consider function composition which is commonly taught in required pre-calc courses. f(x) = ...... f(g(x)) = ...... I will submit that first-class functions map more directly to fu…

Okay, but CS is not programming. After all, programming is not CS.

And by the way, I don't think anybody should first know anything before learning how to program. Programming is like breathing. Do you need to study anything before you breathe? No you don't!

So anybody who argues that you should learn all sorts of not useful things before having the privilege of trying useful things, is a strange person indeed to me.

Re: Joe Armstrong: Why OO Sucks

#189
post #98
post #68

Earlier quoted context omitted.

Reading the article, I don't think the author quite understands OOP. The original author is Joe Armstrong ( http://www.sics.se/~joe/ ), the creator of Erlang.

I don't think Joe ever claimed to be a great programmer. Erlang looks as odd as it does because it was hacked up in Prolog, which few compiler engineers would choose as a starting point. I think Erlang is interesting precisely because it was created by someone with a little distance.

Armstrong fan here :)

Jokes away - the "really great programmers" for me are people who can do extremely complex things very simple.

For me, Armstrong is somewhere near Peter Norvig. Both made me change my point of view, some complex things became simple (and some simple things became not so simple).

"Erlang was hacked up in Prolog" - it's the same as "Java was hacked in C". First implementation of Erlang was written in Prolog, first implementation of Java was written in C.

Re: Joe Armstrong: Why OO Sucks

#190
post #98
post #68

Earlier quoted context omitted.

Reading the article, I don't think the author quite understands OOP. The original author is Joe Armstrong ( http://www.sics.se/~joe/ ), the creator of Erlang.

I don't think Joe ever claimed to be a great programmer. Erlang looks as odd as it does because it was hacked up in Prolog, which few compiler engineers would choose as a starting point. I think Erlang is interesting precisely because it was created by someone with a little distance.

Armstrong fan here :)

Jokes away - the "really great programmers" for me are people who can do extremely complex things very simple.

For me, Armstrong is somewhere near Peter Norvig. Both made me change my point of view, some complex things became simple (and some simple things became not so simple).

"Erlang was hacked up in Prolog" - it's the same as "Java was hacked in C". First implementation of Erlang was written in Prolog, first implementation of Java was written in C.

Post reply on HN