Hacker News new | past | comments | ask | show | jobs | submit login

The concept of clarity is why I don’t like the consequence of SOLID, where you have lots of tiny classes.

tl;dr - Context!

The problem with a lot of the principles developed from the Smalltalk days, is that different environments have differing cost/benefit results for different tasks. This means that many practices which are awesome in a dynamic, programmer-is-god-of-runtime environment like Smalltalk are doing to bog down in other environments. (see below)

It’s easier to understand complex functions and a simple class structure than the other way around. Because jumping between multiple files/classes incurs a high understandability cost, whereas complex functions fit on your screen typically.

What this reveals about the above observation, is that reading and conceptualizing large chunks of operation of the code has a higher cost/benefit in the accustomed environment. My day job is in C++, and because of the compile times, that's certainly the case in that environment. However, in an environment like VisualWorks Smalltalk, where the debugger is 10X nimbler and has literally made students in my Smalltalk classes cry out, "This debugger is GOD!" the cost/benefit trade-offs are very different. Most of the time, code is read and edited in the debugger, and flipping between multiple classes in that context happens automatically by navigating. Also, the work for navigating relationships in the object model in a clean code base is an entirely different order of magnitude. Instead of O(2^n) on n == distance by references, it's O(n), because there's no fan-out for different kinds of references. It's all done by "message sends" or calls of a method.

A lot of damage over the past 3 decades has been done by very smart OO people who tried to transplant methodologies from Smalltalk to C++ and Java. If one wants to be a step above, then look at the largest 7 or so cost/benefit trade-offs that affect the methodology. Then adjust accordingly.

Context!




Similarly, probably the main reason I really like JS... I can apply different paradigms to different areas of code where a given approach makes more sense in terms of understanding or cognitive overhead. JS debugging is relatively nice as well, though in some cases the tooling leaves a bit to be desired.

When I'm in C# by contrast, I often get irritated that I can't just have a couple functions that I can reuse, no, I have to create as static class, ideally in a namespace and do a bit more. I do try to minimize the complexity of my classes and separate operational classes that work on data, and data classes that hold values.


separate operational classes that work on data, and data classes that hold values

This is how I view Entity Component System. It's kind of re-mapped Object Oriented, with strict Areas of Concern.


I wish we named all kinds of ECS-es. It's a total confusion of terms now. Your view is one kind of ECS. Another view is "structuring data to be cache-friendly". Another is "data feels better when modeled and accessed in relational fashion". Yet another is "composition over inheritance taken up to 11". People mix and match these views, which is why every single article on ECS seems to be talking about something different from every other article.


Your view is one kind of ECS. Another view is "structuring data to be cache-friendly". Another is "data feels better when modeled and accessed in relational fashion". Yet another is "composition over inheritance taken up to 11".

You can do all 4 of those at the same time!


I believe you can, though I've not been there myself. But all the articles I've read and all the ECS implementations I've studied so far usually focus on one, maybe two of those aspects at a time, so every one looks different from another.

(In my current side project, I have relaxed performance requirements, so I'm experimenting with taking the relational aspect up to 11.)


Maybe I'm not so sure what you mean by "taking the relational aspect up to 11." My side project is in golang, so composition over inheritance isn't really an issue. I guess that leaves me with just 2 of the aspects.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: