Joe Armstrong: Why OO Sucks • Hacker News Board

Re: Joe Armstrong: Why OO Sucks

#231

Post by spacemanaki » Mon, Jul 16, 2012, 12:06 PM UTC

guard-of-terra wrote: post #227

spacemanaki wrote: post #211

Earlier quoted context omitted.

Your hard-line stance is a little bit too far IMHO. That inanimate matter programming is all about manipulating also has no notion of objects or object orientation... or (for the most part) methods, fields, functions, procedures, arrays, modules, encapsulation, interfaces, garbage collection, databases ... and so on and so on. All that abstraction exists to make programming easier for humans to grok, and for teams to…

I would argue that objects, methods, fields, modules, encapsulation, interfaces, garbage collection, databases are not the basics of programming either. Good things to have, but are not basics of programming. So, teach/learn them later in the cycle. Basics of programming are variables, branches, arrays, loops and simple I/O. You can go a long way with these. And you can explain those to 6 yr old child.

If we were talking about teaching programming to kids, I actually agree with you. It wasn't clear from the top-level comment that started this thread if that's what we were talking about though. I thought that we were talking about intro to CS for freshmen in college. That's where I think it might be valuable to start with functional programming. Note: might -- I really don't know.

Re: Joe Armstrong: Why OO Sucks

#232

Post by guard-of-terra » Mon, Jul 16, 2012, 12:54 PM UTC

spacemanaki wrote: post #231

guard-of-terra wrote: post #227

Earlier quoted context omitted.

I would argue that objects, methods, fields, modules, encapsulation, interfaces, garbage collection, databases are not the basics of programming either. Good things to have, but are not basics of programming. So, teach/learn them later in the cycle. Basics of programming are variables, branches, arrays, loops and simple I/O. You can go a long way with these. And you can explain those to 6 yr old child.

If we were talking about teaching programming to kids, I actually agree with you. It wasn't clear from the top-level comment that started this thread if that's what we were talking about though. I thought that we were talking about intro to CS for freshmen in college. That's where I think it might be valuable to start with functional programming. Note: might -- I really don't know.

"People should be required to learn the basics of programming first. They should start with immutable data objects"

We weren't talking about freshmen in college. And talking about freshmen in college is not so interesting because they agreed to listen to bullshit (information of questionable utility) by joining college.

It's much more interesting to talk about kids or adults because they have the choice.

Re: Joe Armstrong: Why OO Sucks

#233

Post by jroseattle » Mon, Jul 16, 2012, 2:18 PM UTC

Locke1689 wrote: post #225

jroseattle wrote: post #151

The conversation around programmatic semantics and languages and the like always come and go over time, and feelings about them ebb and flow. Over umpteen years as a developer, I can say that I've found there's something about every language that will cause one to say "why do I have to think about this like that?" Nothing is perfect, but certainly a lot of languages do a few things quite well. As such, I would be gra…

not the side effects part, which has nothing to do with state State is a side effect. In fact, that's basically the definition of side effect -- I think you need to revisit the basic principles of formal semantics. State, as the OP points out, exists in reality but should be eliminated from programming State is the entire point of programming. State shouldn't be eliminated, it should be corralled so effects are trace…

> State is a side effect. In fact, that's basically the definition of side effect -- I think you need to revisit the basic principles of formal semantics.

You're right, thanks for the correction. My line of thinking was that addressing the issue of side effects in programmatic functions was not the same thing as addressing state -- while not mutually exclusive, they're not the same thing.

> State is the entire point of programming. State shouldn't be eliminated, it should be corralled so effects are traceable and formalizable.

I won't go so far as state being the entire point, but it's simply another way to programmatically solve a problem. It absolutely should not be eliminated, but rather used responsibly -- just as with anything else in a programmatic environment.

Re: Joe Armstrong: Why OO Sucks

#234

Post by sodelate » Mon, Jul 16, 2012, 2:39 PM UTC

oo is not always the better choice

Re: Joe Armstrong: Why OO Sucks

#235

Post by nessus42 » Mon, Jul 16, 2012, 4:01 PM UTC

guard-of-terra wrote: post #226

spacemanaki wrote: post #209

Earlier quoted context omitted.

> It means the course wasn't about programming. Parent of your comment might have been talking the Structure and Interpretation of Computer Programs. Likely it needs no introduction, but it is absolutely about programming, and goes right down the rabbit-hole to implementing interpreters, virtual register machines, and a compiler for said machine. Yes, the first couple of chapters is mostly purely functional, but that…

I have experience suggesting that to learn programming, you write programs. The hard way, how Zed Shaw calls it. And when you have enough experience in writing programs with limited success, now you are ready for some theory. You know already to separate bullshit from useful things, for one. When you never wrote any programs, you would not be able to do that separation, which is bad for you.

Where do you get the crazy idea that you can't write functional programs? Or that SICP didn't have you write programs? SICP didn't start off with "theory"--it started off with PROGRAMMING. The programming that you did at first, however, just so happened to be recursion-heavy functional programming. The class then taught you how to build your own mutable object system out of the functional primitives, using closures and messages.

I clearly got a far better introduction to PROGRAMMING than you did. E.g., I learned how to add an OO subsystem to a functional programming language in my very first programming class.

SICP was a lab class. It nearly killed me with all the programming I had to do. It was billed as a 15-hour-a-week class, but 40 hours a week was more like it. I lived in the computer lab during that class. The intense programming assignments began on the first day, and continued all the way through to the end.

Is there any other way that you would like to continue to advertise your unsubstantiated bias and ignorance on the issue?

Re: Joe Armstrong: Why OO Sucks

#236

Post by Locke1689 » Mon, Jul 16, 2012, 5:07 PM UTC

jroseattle wrote: post #233

Locke1689 wrote: post #225

Earlier quoted context omitted.

not the side effects part, which has nothing to do with state State is a side effect. In fact, that's basically the definition of side effect -- I think you need to revisit the basic principles of formal semantics. State, as the OP points out, exists in reality but should be eliminated from programming State is the entire point of programming. State shouldn't be eliminated, it should be corralled so effects are trace…

> State is a side effect. In fact, that's basically the definition of side effect -- I think you need to revisit the basic principles of formal semantics. You're right, thanks for the correction. My line of thinking was that addressing the issue of side effects in programmatic functions was not the same thing as addressing state -- while not mutually exclusive, they're not the same thing. > State is the entire point…

I won't go so far as state being the entire point, but it's simply another way to programmatically solve a problem.

Writing to memory is stateful. Writing to a file is stateful. Printing something to the screen is stateful. Seeing the effect of your program is stateful. Would you say that the point of programming is to produce an effect?

Re: Joe Armstrong: Why OO Sucks

#237

Post by bborud » Mon, Jul 16, 2012, 6:16 PM UTC

It would be useful if Armstrong stated which languages and which programming styles he disagreed with.

"OO" is too vague. Not only does it include languages as different as JavaScript, Perl, C++ and Java, but there are wildly different ways of using each of these languages.

For instance it is entirely possible to write purely functional code in JavaScript if you want to.

Re: Joe Armstrong: Why OO Sucks

#238

Post by [deleted] » Mon, Jul 16, 2012, 6:20 PM UTC

fauigerzigerk wrote: post #224

radicalbyte wrote: post #192

Earlier quoted context omitted.

PropertySale is a thing. It should be modeled. You'll probably want to store some state with it (when the sale happened, to whom, the price, etc etc).

Yes property sale is a thing. It's a process. Why can that thing not be modelled as a function? Property sales are rather complicated processes so having a class for it could be justified. But OO forces us to do it that way for every tiny operation. It's pure bloat.

[deleted]

Re: Joe Armstrong: Why OO Sucks

#239

Post by guard-of-terra » Mon, Jul 16, 2012, 7:04 PM UTC

nessus42 wrote: post #235

guard-of-terra wrote: post #226

Earlier quoted context omitted.

I have experience suggesting that to learn programming, you write programs. The hard way, how Zed Shaw calls it. And when you have enough experience in writing programs with limited success, now you are ready for some theory. You know already to separate bullshit from useful things, for one. When you never wrote any programs, you would not be able to do that separation, which is bad for you.

Where do you get the crazy idea that you can't write functional programs? Or that SICP didn't have you write programs? SICP didn't start off with "theory"--it started off with PROGRAMMING. The programming that you did at first, however, just so happened to be recursion-heavy functional programming. The class then taught you how to build your own mutable object system out of the functional primitives, using closures a…

And there you go again, as the OP did. Self-praise, deprecation of others. What happened to humility?

You can write functional programs. You can also write concatenative programs and logical programs. Why not we suggest that people should be required to learn about beating around the stack and predicates first?

What makes functional programming so special? The hubris of its followers?

I can tell you now what makes imperative programming special. It allows all other kinds of programming to function. And it's the most used kind - by large. So, sorry. Basics are just so big that they won't fit any FP concepts. Loops, variables, procedures, branches, arrays. There you go. Be blessed and do not sin.

P. S. The whole concept of immutability linguistically depends on the default of mutability. Where did that default came from? Math does not have the concept of mutability. It came from imperative programming! So, we are told that people should learn basic things, whose definition depends on understanding non-basic things.

Re: Joe Armstrong: Why OO Sucks

#240

Post by bluesnowmonkey » Mon, Jul 16, 2012, 7:55 PM UTC

LnxPrgr3 wrote: post #55

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

> What's fundamentally wrong about date.addDays(1) vs. date_add_days(date, 1)?

One issue involves cross-cutting concerns. Say I'm creating a JSON API for my system. I use an API framework that lets me return objects that implement a JsonSerializable interface, and the framework calls to_json() to create the actual network response. The built in container classes (Hash, Array, etc.) implement this interface already, calling to_json() on their elements. I make all my core domain classes implement a JsonSerializable interface with to_json() methods. Now I can return an array of objects and it just works. Very straightforward.

Problem 1: I only need to_json for the API, but now that code is available everywhere. Every time I change my JSON API, it requires recompilation and testing of every component of the system, whether or not they are even related to the API.

Problem 2: Next I go on to add an XML API, HTML representations, database persistence, third party API integration. All those concerns go into my core domain classes, which become quite bloated. I could use decorator classes, but they require me to be aware of whether I'm using a decorated or non-decorated object. They also add a lot of boilerplate. Code becomes both bloated and ugly.

Problem 3: Next I need a new version of the JSON API, to be run concurrently with the old one. The new version is going to serialize things in a different style, so each class needs two versions of to_json(). I could make a to_json2(), but how would the API framework know to call it? I fork the framework. Now I have to merge my changes every time they release a new version of the framework. Code is bloated, ugly, and unmaintainable.

Problem 4: Next I need to return API responses with classes from third party libraries, for which I don't even have the source to fork. Fuck.

Ultimate solution is to wrap everything -- foo_as_json(foo), bar_as_json(bar), foo_as_xml(foo). It's ugly as hell but it's the only thing that basically works.