Yes. it’s a bit of a polemic but there are nuggets of the truth along the way.
I agree really, both can get the job done and organising your code into modules / namespaces containing related structures and functions isn’t that much different to coding classes.
I was actually just teasing Thorsten because he does love to pontificate 
No, I do not love that. The entire point is: Namespaces and modules making it more complex than it should be especially in really complex projects. But: you think you have the right solution with it. Stay with it. There is no problem as long as I don’t have to change the way I am developing with my Team. That’s it. It is a question of experience and also of the jobs you have to get done. No question. A Web App with many parallel tasks like it is mostly: GO is wunderful. A Webapp with many complex operations can be a real pain. There Java would make the Job let me say less complex to get it done. That’s why banking runs in the most cases on Java as a Server Site. That’s why so many companies running their Web-Applications on Java. But there are applications that can be done fast and smart with GOlang for example. You can use what you want to. And testing me: trust me, it is a DIFFERENT LEAGUE.
I wish there were less information available as video-only
I don’t understand the recommendation.
I’m not looking for videos(?). I just think that the composition video going all in against inheritance is … silly(?).
You can have elements of both in software you write. You can organize inheritance so it doesn’t create the roadblocks mentioned in that video. And you don’t have to resign yourself to the cons of duplicating code to have the desired results.
OOP structure as shown in the original video could be an issue when working for a company, inheriting bad code, or having a boss demand you structure it specifically as they want. But even then, code duplication is going to be eventually be a maintenance nightmare no matter how that’s cut.
I don’t see a big difference using namespaces or modules instead of classes.
Even 8th can use namespaces and UDT objects and it’s not overly complex:
Sample code for a simple game tile UDT:
\
\ Game tile UDT
\
ns: tile
: __init__
"passable" rot m:!
"img" rot m:!
"xy" rot m:!
"m" m:new m:!
"step-on-callback" ' drop m:!
drop ;
: __deinit__
drop ;
: m@ \ tile s -- tile x
swap "m" m:@ rot m:_@ ;
: m!
2 pick "m" m:_@ -rot m:! drop ;
: xy@ \ tile -- tile [x,y]
"xy" m:@ ;
: rect@ \ tile -- tile rect
xy@ a:open 1 tuck nk:grid ;
: img@ \ tile -- tile image
"img" m:@ ;
: img! \ tile image -- tile
"img" swap m:! ;
: passable@ \ tile -- tile passableT
"passable" m:@ ;
: step-on! \ tile word -- tile
"step-on-callback" swap m:! ;
: step-on \ tile -- tile
"step-on-callback" m:@ w:exec ;
: new \ [x,y] image passableT -- tile
ns:tile G:new ;
: draw \ tile --
rect@ swap img@ nip "white" nk:draw-image ;
Sample GUI program using the tile UDT to draw a game grid of floor tiles:
\
\ Simple tile drawing test
\
needs nk/gui
needs games/tile
600 constant WIDTH
600 constant HEIGHT
9 constant NUM-TILES
NUM-TILES n:sqr constant TOTAL-TILES
"gfx/t1.png" app:asset img:new constant floor-img
nullvar tiles
: tile:floor \ [x,y] -- tile
floor-img true tile:new ;
: draw-tiles
tiles @ ' tile:draw a:each! drop ;
: init
( NUM-TILES n:/mod swap 2 a:close tile:floor ) 0 TOTAL-TILES n:1- a:generate tiles ! ;
: new-win
{
name: "main",
wide: @WIDTH,
high: @HEIGHT,
resizable: false,
title: "Test"
} nk:win ;
: main-render
{
bg: "gray",
padding: [0,0],
flags: [ @nk:WINDOW_NO_SCROLLBAR ]
}
nk:begin
null { rows: @NUM-TILES, cols: @NUM-TILES, margin: 8 } nk:layout-grid-begin
draw-tiles
nk:layout-grid-end
nk:end ;
: app:main
' init w:is nk:rendering
new-win ' main-render -1 nk:render-loop ;
I don’t know why I love irony so much but I do… 
Sinde 8th is used all over the world…NOT. If you don’t realize that you should look onto bigger projects with complex structures. Makes things simple with OOP definitely.
Fair enough… if you design for that intentionally (or refactor for it, or whatever). It’s hard to do in a large ecosystem where you want to encourage broad reuse over time. Julia achieves this with multiple dispatch. In particular, in this video (sorry for another video… just easier for this example), there is a discussion starting at 14:45 that offers a really clear example of this. I’d be curious how this could be engineered using inheritance in a way that would still achieve the reuse-over-time objective without duplicating code, which the speaker suggests at 26:02. Is this wrong?
I wouldn’t few it as wrong at all. Just different.
I had thought the context here was within a project or company, done by a person or team. In which case, the problems are largely known ahead of time, there’s planning and design, and it’s executed with intention.
Global code sharing / reuse has it’s own share of problems. Trying to solve many problems with one solution generally ends up leaving things out, and solutions for those tend to encourage using a hammer and seeing everything as a nail. The problems solved with programming languages are not just the syntax, models, and patterns used.
The problems just shift to different areas. Those areas may be easier mitigated for some, but they are still there and can affect others. Julia has them, along with every other language.
It’s a bit like tuning a race car in a video game. You can adjust the spoilers for traction, but lose speed. You can adjust the wheels but that changes how often they need to be changed. You end up adjusting the car for the track you are on, and your driving style. You shift the pain points to things that matter less, or can be more easily managed your situation.
I think the same applies here. Rust is about as old as Julia, and they seem to be in mostly separate markets. Different assembly languages still gets used today, and someone still needs to make the processors.
well my 2cents… Procedureal is dead. Long live OOP! 
My current project is written in Swift, and contains 100’s of classes, and subclassed objects, There would have been NO WAY this could have been done otherwise, Especially since the one code base works for macOS (desktop) , iOS (iPhone/iPad) and tvOS (AppleTV). Those 3 platforms each with their own OS share 90% of the code, the other 10% encompasses things that are mostly related to the specific GUI requirements of each.
Oh, and there is ZERO “duplicated” code, as should be the case with a properly designed project
And Go doesn’t have inheritance and classes at all. And yet I’ve converted many classes to Go. Go interfaces and composition make it seem very OO at times. They definitely decided on simplicity for most of the language.
Sure. All the world’s most powerful supercomputers are running an OS coded in a procedural language but there’s simply NO WAY your fiendishly complicated app could have been realised except with OOP.
.
“Object oriented programs are offered as alternatives to correct ones”
You do you, and I’ll do me
