I've been watching some stuff recently... Ginger Bill talking about "Clean Code Vs performance" leaps immediately to mind... and it's interesting to hear here something of a counter to those arguments with talk of not abandoning abstractions all together but finding the RIGHT abstractions. I gotta have a look at the full episode when I've got the time.

Yes, thank you! DDD is about making business semantics clear. OOP is just a programming paradigm. They are completely separate, and DDD can and should be utilized much more across all sorts of languages, code styles and architectures.

@JasonSmith-dy5hj

4 ай бұрын

Exactly , its that simple

The right 'meta-abstraction' here could be Type Theory. Where Eric asks about which containers belong in the selected set, he's saying there is a Type of container. I sometimes abandon high-level-languages to gain speed if I measure the actual bandwidths of certain algorithms to be smallish, but the abstractions build code for the most general cases thus wasting bandwidth, cache, or whatever the tight resource may be. Usually the language is failing to compile for the most economical choice of data types or else the library coders have no good means to inspect the data types on which the algorithms are being deployed. Abstraction says "hide details." But performance demands that we exploit domain-specific details. Type theoretic languages let you express details so that they can be statically analyzed. It then becomes safe and effective for abstractions to benefit from inspecting the black boxes on which they work.

@D4no00

4 ай бұрын

nice story bro. Unless you are working in a industry/product where performance is absolutely critical, what you say makes absolutely no viable sense from the business perspective. Writing in rust, because you can gain 10% more performance but at the same time have 5x penalty on development speed is not a choice you will be praised for in the industry.

@JaxVideos

4 ай бұрын

@@D4no00 I was a working computer scientist since 1978, implemented optimizing compilers, interpreters, and runtime libraries for vector & parallel languages on many hardware designs for Burroughs, SGI, Intel, and the Center for Supercomputing R&D. I've written a parallel prelinker for C++ template instantiations, a commercial SystemVerilog compiler used by Intel to design processors with 100s of millions of gates, everyone of which occupies a wad of virtual memory and figures into local and global optimizations of a circuit design. So I live and breathe the tension between abstraction costs, and the correctness burdens of abandonning abstraction to achieve performance goals. In the HDL compiler business, one bad tape-out costs $10M, and yet the expectation is for a 5-10% speed or capacity boost every release cycle. Believe me, if you take some moments to acquaint yourself with Homotopic Type Theory mathematics, you'll start to get insights into how to build better languages for provably correct code that can be correctly optimized at its compile time to whatever extent is economically feasible. Don't just learn programming languages, learn how to design them, and how to rewrite preserving correctness. Type Theory is the first system I've seen with fully flexible introspection that is devoted to data set definition. It is the language in which we reason about abstractions.

@MikeStock88

4 ай бұрын

​​​@@D4no00yeah that's solving a problem that doesn't exist 😅 I find this is a problem in our industry where we overcomplicate things for no reason. You can make something ultra performant if you have a reason to do so

@D4no00

4 ай бұрын

@@MikeStock88 tell me about it. I think a big reason why is the fact that the teachers/books we learned from, come from the age where hardware was extremely slow and expensive. Nowadays we have so much raw computing power, that development time is the biggest expense in all businesses. I like the quote by Joe Armstrong: Steps to creating good software: 1. Make it work; 2. Make it beautiful; 3. Make it performant if you need it.

@TonyWhitley

3 ай бұрын

"Get it working, *then* optimise it."

Is this not common sense? How have we got to a place where efficiency (as opposed to optimization) has taken a backseat?

@BertLaverman

4 ай бұрын

Hah! Look at CPPCon presentations…

@danp8321

4 ай бұрын

Yeah - assembly language hasn't been necessary for performance in most cases for a decade or more 🤦

@alexanderpodkopaev6691

3 ай бұрын

'...you'll make it fast later' had become a mindset

@jimhumelsine9187

3 ай бұрын

"Common sense is not so common." - Voltaire

@elecorn

3 ай бұрын

What seems "obvious" once discovered is not always easy to come by.