Live data from Hacker News

Why OO Sucks by Joe Armstrong (2000)

cs.otago.ac.nz

381–390 of 396 posts

Re: Why OO Sucks by Joe Armstrong (2000)

#381

Earlier quoted context omitted.

Its not the length of the array. Its using things like array[20]. Yes that exists pre-OO and outside of OO, but its the foundational aspect of OO and one of the strongest use cases. Sorry for the way I communicated- I was tired and should have reconsidered.

> Sorry for the way I communicated- I was tired and should have reconsidered. No worries, it happens. :) > Its not the length of the array. Its using things like array[20]. Yes that exists pre-OO and outside of OO, but its the foundational aspect of OO and one of the strongest use cases. I'm not sure what you're getting at then. Indexing into an array? Are you making a more general point than arrays? I'm not followin…

I think my argument is basically that arrays are effectively object oriented abstractions in most languages.

You aren't responsible for maintaining any of the internal details, it just works like you want it to. My example was with the getter for the item at index 21 (since you had specifically called out useless getters), but equally well applies to inserting, deleting, capacity changes, etc.

Re: Why OO Sucks by Joe Armstrong (2000)

#382
post #359

Earlier quoted context omitted.

You misunderstood my post. I said I haven’t seen a useful getter abstraction. Not all data access is via a method nor is it always abstract. I specifically object to the useless abstraction, not the boilerplate (boilerplate is cheap).

I think we're coming at it from different angles. My point is that there shouldn't be any abstraction to write, and it should just be the way the language works. Primitive slot access in Java is not just a get/set interface, it's a get/set interface that also specifies implementation characteristics and what the code will be capable of in the future. It should be in the language so that you can have primitive slots,…

> My point is that there shouldn't be any abstraction to write, and it should just be the way the language works.

I understand your point, but I think you misunderstand what "abstraction" means. "abstraction" doesn't mean "function" (although functions are frequently used to build abstractions), and if you have "dynamic properties" (or whatever you'd like to call them) a la Python, then you're still abstracting. My point is that abstracting over property access (regardless of property-vs-function syntax) is not useful, or rather, I'm skeptical that it's useful.

> I think a better question is when that abstraction gets in your way. When does it bother you that nullary functions aren't reading memory locations? Why do you feel that's an essential thing to specify in your public interface, as a default? There's nothing stopping you from writing code in Python and mentally modelling o.x as slot access, because it follows the interface you want from it.

I think this is a good question, because it illustrates a philosophical difference--if I understand your position correctly, you'd prefer to be as abstract as possible until it's problematic; I prefer to be as concrete as possible until abstraction is necessary. There's a lot of mathematical elegance in your position, and when I'm programming for fun I sometimes try to be maximally abstract; however, when I'm building something and _working with people_, experience and conventional wisdom tells me that I should be as concrete and flat-footed as possible (needless abstraction only makes it harder to understand).

To answer your question, that abstraction gets in your way all the time. The performance difference between a memory access (especially a cache-hit) and an HTTP request is several orders of magnitude. If you're doing that property access in a tight loop, you're wasting time on human-perceivable timescales. While you can "just be aware that any given property access could incur a network call", that really sucks for developers, and I see them miss this all the time (I work in a Python shop). We moved away from this kind of "smart object" pattern in our latest product, and I think everyone would agree that our code is much cleaner as a result (obviously this is subjective).

TL;DR: It's useful to have semantics for "this is a memory access", but that's unrelated to my original point :)

Re: Why OO Sucks by Joe Armstrong (2000)

#383
post #359

Earlier quoted context omitted.

I think we're coming at it from different angles. My point is that there shouldn't be any abstraction to write, and it should just be the way the language works. Primitive slot access in Java is not just a get/set interface, it's a get/set interface that also specifies implementation characteristics and what the code will be capable of in the future. It should be in the language so that you can have primitive slots,…

> My point is that there shouldn't be any abstraction to write, and it should just be the way the language works. I understand your point, but I think you misunderstand what "abstraction" means. "abstraction" doesn't mean "function" (although functions are frequently used to build abstractions), and if you have "dynamic properties" (or whatever you'd like to call them) a la Python, then you're still abstracting. My p…

[deleted]

Re: Why OO Sucks by Joe Armstrong (2000)

#384
post #359

Earlier quoted context omitted.

I think we're coming at it from different angles. My point is that there shouldn't be any abstraction to write, and it should just be the way the language works. Primitive slot access in Java is not just a get/set interface, it's a get/set interface that also specifies implementation characteristics and what the code will be capable of in the future. It should be in the language so that you can have primitive slots,…

> My point is that there shouldn't be any abstraction to write, and it should just be the way the language works. I understand your point, but I think you misunderstand what "abstraction" means. "abstraction" doesn't mean "function" (although functions are frequently used to build abstractions), and if you have "dynamic properties" (or whatever you'd like to call them) a la Python, then you're still abstracting. My p…

[deleted]

Re: Why OO Sucks by Joe Armstrong (2000)

#385

Earlier quoted context omitted.

> Sorry for the way I communicated- I was tired and should have reconsidered. No worries, it happens. :) > Its not the length of the array. Its using things like array[20]. Yes that exists pre-OO and outside of OO, but its the foundational aspect of OO and one of the strongest use cases. I'm not sure what you're getting at then. Indexing into an array? Are you making a more general point than arrays? I'm not followin…

I think my argument is basically that arrays are effectively object oriented abstractions in most languages. You aren't responsible for maintaining any of the internal details, it just works like you want it to. My example was with the getter for the item at index 21 (since you had specifically called out useless getters), but equally well applies to inserting, deleting, capacity changes, etc.

> I think my argument is basically that arrays are effectively object oriented abstractions in most languages.

I think I see what you mean, although I think it's worth being precise here--arrays can be operated on via functions/methods. This isn't special to OO; you can do the same in C (the reason it's tedious in C is that it lacks generics, not because it lacks some OO feature) or Go or Rust or lisp.

These functions aren't even abstractions, but rather they're concrete implementations; however, they can implement abstractions as evidenced by Java's `ArrayList implements List`.

And to the extent that an abstract container item access is a "getter", you're right that it's a useful abstraction; however, I don't think that's what most people think of when they think of "getter" and it falls outside the intended scope of my original claim.

Re: Why OO Sucks by Joe Armstrong (2000)

#386
post #350

Earlier quoted context omitted.

TLA+, SPARK, Frama-C, PROMELA, Astree, even plain C or C++ and a heavily safety-oriented process are used when correctness is important more than any of the FP languages you've mentioned. In fact, by mentioning Erlang and Ericsson, you exhausted the only case supporting your point. Maybe if you tried hard, you could come up with a couple more. Now let's do the same exercise for the languages and tools I enumerated an…

I don’t know anything about SPARK or FramaC, but TLA+ isn’t a programming language, and you can use it to model distributed functional apps just fine (I still do). Even if the Erlang/Ericsson stuff is the “only case” (It’s not) I do not see how that makes my point less valid; Erlang was specifically design for systems that cannot fail. Telephones are just a good example of that.

And doesn't your TLA+ model make your functional code significantly more reliable? Guess what, it does the same thing for OO languages => no need to use FP to increase reliability.

Same goes for the other tools or languages I mentioned.

Re: Why OO Sucks by Joe Armstrong (2000)

#387

Earlier quoted context omitted.

In what way is Scala not pragmatic?

It's a language that's aimed more at research, producing papers for conferences, and financing the EPFL and its PhD students than at users in the real world. There's absolutely nothing wrong with that, by the way, I love studying all the advanced concepts that Scala has pioneered over the years. But it's also the reason why it's largely in decline and why Kotlin has taken the industrial world by storm: because it is…

Kotlin is just Scala with a few most advanced features taken out with no good replacement. It is not even really much faster in compilation speed when you account for its verbosity [1] and it has worse IDE support limited to just one IDE. Jetbrains is not interested in supporting other IDEs than its own. So what is so much more pragmatic about it?

Also there is no decline in Scala usage, and Kotlin doesn't exist outside its Android niche really. So "taking by storm" is a wishful thinking.

[1] https://stackoverflow.com/questions/34615947/why-does-kotlin...

Re: Why OO Sucks by Joe Armstrong (2000)

#388

Earlier quoted context omitted.

I've used Scala in production environments, and we never had any problems with it being too academic. SBT sucks, but that's another issue. Kotlin doesn't have typeclasses (something you get as a side effect of Scala implicits), ADTs, or true pattern matching (along with exhaustivity checks). In combination, all of those allow for expressive, easy-to-read code that, in my experience, tends to have few bugs. Kotlin is…

A step backward to you is a step forward in pragmatism for the rest of the world. I understand the value of higher kinds and I'm comfortable with Haskell, but it's pretty obvious to me why Kotlin is succeeding where Scala failed. Sometimes, improvements in programming languages are reached by having fewer features, but Scala is a kitchen sink that was always unable to turn down features, just because their implementa…

AFAIK Scala is much more popular than Kotlin in terms of job postings and projects in big enterprises. My data limited to some Fortune 100 companies tell me it is on par with Python in popularity. Spark, Kafka, Flink, Finangle are written mostly in Scala. Pretty impressive for an academic, non-pragmatic language that has failed, isn't it?

So can you elaborate what do you mean by "failed"? Because it seems you are using a different definition of it.

"Sometimes, improvements in programming languages are reached by having fewer features, but Scala is a kitchen sink that was always unable to turn down features, just because their implementation would lead to more research papers to submit to conferences."

That's some different language you're talking about. Scala is built on a small set of very powerful, general, orthogonal features which cooperate nicely and allow to build most of the stuff as libraries. Its design is much more principled than Kotlin's. Kotlin has special features built into the language, that Scala needs just a library for.

Re: Why OO Sucks by Joe Armstrong (2000)

#389
post #374
post #338

Earlier quoted context omitted.

“I mainly wanted to provoke people...” I hate this. I see it way too often. It’s either a cop-out to avoid having to own up to your arguments or its just poisonous rhetoric in the first place that contributes to partisan opinions, especially when the speaker has an air of authority that causes people to accept what they say at face value. It is directly antithetical to critical thinking.

> It is directly antithetical to critical thinking. I don't think it is. Yes, it can get some people to just lash out in response. But it also often forces people to think critically about how to convincingly justify their own standpoint to counter the provocation. This can be particularly useful when a viewpoint has "won" to the extent that people just blindly adopt it without understanding why. It does have it's pr…

True, I can see how in this case, at that time, it could be effective. But ironically, there seems to be a similar dogma surrounding FP these days - speaking even as a fan of the paradigm, with a perspective tempered by experience. I can’t help but think that polarized viewpoints like this contribute to replacing the subject of the idealization rather than the underlying problem of idealizing itself, if only indirectly due to the combination of the arguments themselves and the sense of authority behind them, rather than the merit of the arguments alone.

Re: Why OO Sucks by Joe Armstrong (2000)

#390

Earlier quoted context omitted.

Are you the Alan Kay. Is there any way we can verify this is you? The HN user account seems to have a very low "karma" rating, so one can't help but be more suspicious.

I'm the "computing Alan Kay" from the ARPA/Parc research community (there's a clarinettist, a judge, a wrestler, etc.) I did create a new account for these replies (I used my old ARPA login name).

It's really cool that you weigh in on discussions on HN. Or I suppose it feels like that to me primarily because I grew up reading your quotes in info text boxes in programming texts. And it's cool to have that person responding to comments.
Post reply on HN