Why OO Sucks by Joe Armstrong (2000)

Post by tombert » Tue, Apr 23, 2019, 6:55 AM UTC

jhomedall wrote: post #360

hota_mazi wrote: post #345

Earlier quoted context omitted.

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…

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…

Post by sideshowb » Tue, Apr 23, 2019, 8:05 AM UTC

LifeLiverTransp wrote: post #286

bad_user wrote: post #248

Earlier quoted context omitted.

C++'s vtable is also late binding, since you don't know which implementation you're calling until runtime. And there's no such thing as "extremely late binding". > In C++, for example, the only kind of late binding that you have is abstract classes and vtables. That's not true, you can always have a "send_message(string id)". Few people do it because you lose static type safety. And some languages, like C# and Scala,…

The only good thing about OO as a architecture is, that there is nearly no education required to introduce it to the most novice in the field. Its basically the default thinking approach rebranded. It comes with all the benefits of a mental model - quick orientation, and all the negative of a mental model. (Badly adapted to fit to machine execution, after acertain complexity level is reached - god like actorobjects -…

Post by carlmr » Tue, Apr 23, 2019, 11:14 AM UTC

vidarh wrote: post #374

lame88 wrote: 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…

Post by Const-me » Tue, Apr 23, 2019, 11:45 AM UTC

jstimpfle wrote: post #376

Const-me wrote: post #283

Earlier quoted context omitted.

> Streams are one of the few successful abstractions out there. I don’t think they’re few. I think all modern software uses OOP-based abstractions heavily. For example, for GUIs, it’s visual trees everywhere. HTML DOM is the most widely used one now, but pretty much every GUI framework have something conceptually similar, even 30 years old WinAPI is built on very OOP-like concepts, you have HWND handles but the state…

The last Electron app I've used (one of these new chat apps, forgot the name) was dog slow (on my $700 computer from 2018), and gave my computer a hang up (probably triggered a graphics driver issue, or sth related with too much memory consumption).

Post by jstimpfle » Tue, Apr 23, 2019, 1:23 PM UTC

Const-me wrote: post #378

jstimpfle wrote: post #343

Earlier quoted context omitted.

Absolutely should you wrap malloc in any moderately sized project! But clearly that's not OOP. We need to differentiate between abstract data types (method dispatch, which I would normally count as OOP) and just making functions to "reuse" code. In the latter case, there is only one possible implementation, and the implementation can expose as much or as little implementation details as is appropriate -- and in gener…

> and in general, there won't be any abstraction leaks. For malloc, address space fragmentation is a common issue for 32-bit processes. Multithreading issues are common, when 2 threads access same cache line, it’s even slower than accessing main RAM. Randomized nature of the allocator causes performance problems. Every time people bother writing custom allocators, they do that because malloc/free abstraction was not…