OOP tells you to structure your software as objects exchanging messages, and DDD tells you what those objects (or their classes rather) should be.

Similarly, Procedural programming tells you to structure your software as procedures, and DOD tells you what those procedures should operate on.

The focus on the data is the really important part. What is the actual data I'm operating on (without any fluff on top) and what do I need to transform it into? What subsets of that data need to be operated on at any given point in the program? That's the core of DOD.

Then, as a second step, comes the hardware. Now that I know what data I need to operate on, how do I lay it out to best take advantage of the hardware I'm targeting? If you rename the paradigm to "Hardware Oriented Programming", it shifts the focus from data modeling to code (IMO), which is the wrong frame of mind.

For example, virtual calls are slow compared to direct calls, because they screw up branch prediction and often can't be inlined. In HOP, you'd probably ban virtual calls entirely because virtual calls bad.

But in DOD, they honestly probably don't matter at all! Because if you did the data modeling as instructed, and then you laid out the data to best take advantage of the hardware, your virtual function is going to be operating on a pile of data in bulk, making the virtual call cost pure noise.

There are also cases where the optimal data format isn't array oriented because the memory access patterns for the problem in question just require something else.

You also have to think of hot vs cold data, which has nothing to do with arrays.

Miri is meant as more of a sanitizer type tool that you use during development to catch bugs. Fil-C is a platform you compile your entire Linux distro with for use in production.

You could even use Rust alongside Fil-C to ensure the unsafe blocks are safe. It would even be interesting to turn off some of Fil-C's expensive protections in the safe parts of the Rust code, making an average-of-both-worlds sort of solution.

What I do care about are C and C++, these two absolute garbage languages (though I do have a lot of love for C, you can both love and hate something).

Tools like Fil-C, hardened mallocs like SlimGuard, and other "make C safe" solutions all sacrifice absurd amounts of performance because these two moronic languages refuse to have a proper slice/span type.

Use-after-free and double-free are serious problems but they're a spec of dust compared to missing bounds-checks. The low-hanging fruit is right there for the picking but everyone is worried about how to reach the fruits at the top.

C++ only now in C++26 is finally adding bounds checks to the [] operator on std::span and (hilariously) is also finally adding the now mostly redundant .at() method which should have been there from day one.

Clang added -fbounds-safety which is a feature that should have existed for a long time and serves as a decent stop-gap to a proper slice type. But of course, since it's not standardized, most people won't use it.

What these two languages have taught us is that if you want to produce utter garbage you should make it an ISO standard.

Me, personally, I find this whole discussion on memory safety amusing. Missing bounds checks are by far the biggest source of vulnerabilities and they're a problem in exactly 2 languages and those 2 languages have outright refused to do anything about it for decades.

But hey, even in memory safe languages you have frameworks like log4j that had remote code execution from a format string as a feature. Is the problem memory safety specifically, or this utter cavalier attitude towards security?

I'm not even suggesting something dumb like "you just gotta get good at C and then you won't have any vulnerabilities". Humans are fallible, which is why we delegate what we can to machines. I'm just pointing out the utter lack of care. People just don't care.

At least do the bare minimum of effort like, I don't know, not make remote code execution a feature tied to format strings. Or provide a slice type in your language and string manipulation functions in your standard library that make use of it, preferably 20 years ago.

Comments URL: https://news.ycombinator.com/item?id=48944106

Points: 1

# Comments: 0

Basically, they're all still concerned with the realities of current day GPU hardware, which in turn means they too, much like DirectX and Vulkan, will eventually become "bad" abstractions.

IMO, if there is any mention of a "vertex" or "fragment" shader, it's still not there yet. End goal should be massively parallel CPU, no graphics-specific functionality beyond compiler intrinsics for whatever can't be done efficiently in software. Something like CUDA is the target to aim for.

So for any sort of visual engine development (game engines being the most obvious, but also applications like blender or the JangaFx suite which is the main user of Odin), it is great. What you need is just there ready to go.

The language design itself is very much oriented around appealing to people who do this sort of work.

Other than there isn't much to the language really. It lacks a "big idea" feature like Rust's lifetimes or Zig's comptime. The closest thing to a "big idea" is the rejection of package managers but that's not really part of the language.

It's pleasant to use and compiles fast. Hard to complain.

Odin is a pretty neat language, I should play more with it. There's nothing outright wrong with it I can think of. Some things I would have done slightly different but they're all nitpicks (mainly having the context be a thread local so #contextless wouldn't be necessary).

Both should be much faster at compiling debug builds than they are though. There's an LLVM fork (TPDE-LLVM) that supports a limited set of backend targets but compiles way faster (order of magnitude) for O0, but for whatever reason they haven't managed to merge it with the mainline LLVM. Even with that there's still plenty of overhead from all the horrible C++ OOP-brained abstractions LLVM uses.

I'm fine with companies leasing software. I don't like it, and I much prefer buying, but that's fine. That is what software subscriptions are, the terms and conditions are clear.

"Buying" something where access can be revoked at any time, for any reason, needs to become illegal.

1) Allow objects to send messages to an implicit "parent" object, which supports "doesNotUnderstand" ala Smalltalk and that by default also forwards to the implicit parent. That means you can implement "log(...)" at the right point in the abstraction without manually passing a logger around.

2) Use algebraic effects, no need to handle this with OOP. A function requests the "log" effect and a handler defined in a higher level scope takes care of implementing log.

3) Have a language with an implicit context parameter that allows putting arbitrary things in it (closest would be Odin but Odin has a fixed set of operations in the context). Because it is implicit in the calling convention methods can be oblivious to it.

4) You separate the concerns: logging is the act of recording some information. Where that information is ultimately sent or stored is a separate concern. This is the more functional view of the problem. If you follow a "model-view-update" approach like the so called "Elm Architecture", logging is just another task produced by the view function, it doesn't need any special handling.

It's not that this is a "problem" of OOP, it is that OOP doesn't give you any tools for tackling this problem. That is why dependency injection frameworks exist. Some other paradigms and non-OOP architectures don't have any trouble with it. You can also replicate those architectures in an OOP language, but that's still "contorting the paradigm" rather than it helping or guiding you towards a clean solution.

Personally I think a global singleton logger is perfectly reasonable, it is other people (the ones using DI frameworks) that think otherwise ;)

OOP allows to create decoupled systems but it doesn't help in creating them. It is not an inherent property of the paradigm, but many people sold it as such.

"Use OOP and your application is now magically more modular! Buy my latest book to find out how!"

Since you mentioned you are a junior I guess this sort of nonsense is from before your time. No worries, that just means you won't have stupid dogma shoved down your throat. Use whatever paradigm if it helps you and avoid whatever gets in the way.

I can criticize a paradigm while also using it anywhere and everywhere it benefits me ;)

But it is true that there will always be parts of a software system that are highly coupled. I'm not even sure if that's even a problem, unless the coupling is also highly tangled (meaning the connections are coming from too many places).

But if you want to decrease coupling between parts of a system, OOP by itself is not particularly good at it. Even something like an Entity Component System is usually less coupled than most OOP codebases because while each System is heavily coupled to the components they do work on, the Systems are usually fully independent from one another and easily replaceable.

But you hit performance and/or outright computational limits (halting problem) rather quickly.

Interfaces (a feature of OOP) can be used to decrease coupling, but the paradigm itself doesn't really provide any assistance in regards to coupling.

The default is for objects to directly instantiate other concrete objects and to be able to directly communicate with any object they at any point come in contact with. That is strong coupling, by default.

You have to do extra work to get looser coupling. Smalltalk style OO is much better (regarding coupling) because you don't have explicit interfaces, you can always replace an object with another. You can also query all live objects of a certain type and replace all of them with a proxy if you so wish. Way better.

But you can go even further in regards to loosening coupling. You can have objects communicate through a tuplespace (Linda), you can have objects receive and send messages only through ports, you can have objects send a message to their implicit parent who is then responsible for redirecting it.

Mainstream OOP is a very poor paradigm full of issues that gets mogged by everything. Composition-over-inheritance is an admission of defeat for a paradigm that lacks native delegation support (good on Kotlin for realising this).

It even gets mogged by languages like Haskell that introduced the more loosely coupled idea of typeclasses, which were inherited by Rust (traits), Swift (protocols), Go (interfaces, not to be confused with declaration-time interfaces as in Java).

We dug a suboptimal hole and stuck our head in there for 50 years.