The difference between inheritance and composition

Article title: "Mastering React component composition using children"

<image of a couple holding a baby>

Image caption: "Parents with child."

**Reads the title again**

Wait what?

Storing and comparing genomic data on cancer tumors to create custom treatments targeted to the exact genomic composition of the patient's tumor.

It's about a guy that knows better.

I was working as a subcontractor on a bigger system. We (subs) were not allowed to deploy code, we had to wait for contractor to deploy.

One day I got an email that my code is bugged and that my feature is not working on production. I checked it on test env, everything was fine. Then I checked if the code I wrote was deployed. It was not.

I send an email explaining that if they deployed my code it would be working. Then I got a response. There was a bug in my code.

Another email. I asked how would they know? Do they have a test on their environment that failed?

No. There is one guy that READ my code and he said it should not work, so he will not deploy it. He was not a programmer, he was a business consultant responsible for the documentation.

His issue was that I used a function that was not in a class. So if the function is not declared it's obvious it will not work. I had to explain to him in another email, that you can use object of another class inside your class and then call a function, that is not in your class. It was the last time this guy blocked my deploy.

TL;DR, I had to explain a non-dev how object composition works in order to have my code deployed. Took four emails.

Here in Saint Petersburg, Russia, our local governmental utility company that is responsible for providing tap water for the entire city, uses crayfish to monitor the water composition.

There are some crayfishes living at the plant and there are some scientists that constantly monitor the crayfish via optical fiber to measure how they feel. If crayfish feels bad, the water is cut out and the inspection begins. There are operators that are paid to watch for crayfish mood throughout the day.

This system works flawlessly since 2005 and helped prevent several accidents when toxic stuff that can’t be monitored on a large scale ended up in our local river.

I mean coal miners was using canaries and rats for years to detect what detectors just can’t detect good enough.

Our entire tap water system depends on some crayfish and it’s amazing.

I wrote a prototype for a program to do some basic data cleaning tasks in Go. The idea is to just distribute the files with the executable on our shared network to our team (since it is small enough, no github bullshit needed for this) and they can go from there.

Felt experimental, so I decided to try out F# since I have always been interested with it and for some reason Microsoft adopted it into their core net framework.

I shit you not, from 185 lines of Go code, separated into proper modules etc not to mention the additional packages I downloaded (simple things for CSV reading bla bla)

To fucking 30 lines of F# that could probably be condensed more if I knew how to do PROPER functional programming. The actual code is very much procedural with very basic functional composition, so it could probably be even less, just more "dense"

I am amazed really. I do not like that namespace pollution happens all over F# since importing System.IO gives you a bunch of shit that you wouldn't know where it is coming from unless you fuck enough with Ionide and the docs. But man.....

No need for dotnet run to test this bitch, just highlight it on the IDE, alt enter and WHAM you have the repl in front of you, incremental quasi like Lisp changes on the code can be REPL changed this way, plethora of .NET BCL wonders in it, and a single point of documentation as long as you stay in standard .net

I am amazed and in love, plus finding what I wanted to do was a fucking cakewalk.

Downside: I work in a place in which Python is seen as magic and PHP, VB.NEt and C# is the end all be all of languages. If me goes away or dies there will be no one else in this side of the state to fuck with F#

This language needs to be studied more. Shit can be so compact, but I do feel that one needs to really know enough of functional programming to be good at it. It is really not a pure language like Haskell (then again, haskell is the only "mainstream" pure functional language ain't it not?) but still, shit is really nice and I really dig what Microhard is doing in terms of the .net framework.

Will provide later findings. My entire team is on the Microsoft space, we do have Linux servers, but porting the code to generate the necessary executables for those servers if needed should be a walk in the park. I am just really intrigued by how many lines of code I was able to cut down from the Go application.

Please note that this could also mean that I am a shit Golang dev, but the cut down of nil err checkings do come somewhere.

!dev
I hate it when the inspiration finally comes... and you can't use the PC to compose. Because you're currently at school, or for whatever reason.
Now I'm scared that I will forget my ideas, before I get back home...
Damn, happens everytime.
( ◕∧◕)

Me in school: Math? When do I need know those details? I can look them up and just code it.

Me in high school: Computer science is way too math-y. I want to code!

Me coding php: Just make it work.

Me coding typescript: Just make it work.

Me coding scala: Just make it ... what ... how do I make it work!?!

Me asking stackoverflow: How do I do X in scala some functional programming stuff in mind in order to keep immutability.

Somebody way smarter than I: "In scalaz, a function A => A is called an endomorphism and is a Monoid whose associative binary operation is function composition and whose identity is the identity function"

Me now: Fuck my old arrogant self.

While reviewing a PR from one of our newer FE devs, I ended up spending more time than I would like mulling over its composition. The work was acceptable for the most part; the code worked. The part that got me was the heavy usage of options objects.

When encountering the options object pattern (or anti-pattern, at times) in complex scenarios, I have to resist the urge to stop whatever I'm doing and convert it to the builder pattern/smack them in the head with a software design manual. As much as I would like to, code janitor is one of the least valuable activities I engage in daily, and consistently telling someone to go back to the drawing board for work that is functional, but not excellent is a great way to kill morale. Usually, I'll add a note on the PR, approve it, add a brown bag or two on that sort of thing, and make attendance mandatory for repeat slackers. Skills building and catharsis all rolled up in a tiny ball of investing in your people.

Builders make things so much cleaner; they inform users what actions are available in a context; they tend to be immutable, and when done well, provide an intuitive fluent interface for configuration that removes the guesswork. As a bonus, they're naturally compositional, so you can pass it around and accumulate data and only execute the heavy lifting bits when you need to. As a bonus, with typescript, the boilerplate is generally reduced as well, even without any code generation. And they're not just a dumping ground for whatever shit someone was too lazy to figure out how to integrate into the API neatly.

They're more work in js-land, sure; you can't annotate @builder like with Lombok, but they're generally not all that much work and friendlier to use.

Designer ranting about designer.
Most graphic designer in switzerland have no clue on how to build a proper InDesign document. The design looks astonishing but when they want their design printed, they get roasted everytime.
No I can't print this ultra vibrant rgb color. This image has only 72ppi I need 300ppi in order to print this! WTF? What is this color setting? Japanese ICC color profiles? Are you retarded? No this layer composition is horrendous and unusable. WTF? a 60 page business report and no paragraph format presets? How I'm supposed to typeset this shit next year? No I can't print this fucktard, how long have been a graphic designer? 15 years? And you've still produce this crap? .... Every single time.

Thank goodness I don't work in print anymore.

Discovering Julia:

"Wow! It is awesome! It's like a Python but fast, function composition is so useful..."

Then you realize that arrays start at 1:

"WHAT THE F! WHY?!"

I'm quite tired if all the hate that PHP gets. Whilst the language composition is terrible it runs well with almost minimal setup on a Linux box, it is very powerful when it is used correctly and can even be OK to work in if you take time to setup nicely.

Neither Python nor node seem to me like a good enough replacement as they serve different purposes.

I prefer Python as a language but php serves a purpose

!rant
So, Rust again.
When I learned that Rust doesn’t support inheritance, only traits (interfaces), I was shocked at first.

Then I tried to remember when the last time was that I have used inheritance in the code that I write (not the code that I use).

And I could remember an instance some months ago. But I also remember that I was very unsatisfied with that design and refactored it to use composition instead. And it was much better.

One of Rust’s properties is that many good practices in other programming languages are enforced rules in Rust.
And in case of inheritance, it seems like Rust decided that composition over inheritance is such a good practice that it should be a rule.

I’m not 100% convinced that there never will be cases where inheritance is better. But I still like this radical idea of forcing the devs to do it "the right way" in the majority of (if not all) cases.

I think many devs will disagree.
What do you think?

dev, ~boring

This is either a shower thought or a sober weed thought, not really sure which, but I've given some serious consideration to "team composition" and "working condition" as a facet of employment, particularly in regard to how they translate into hiring decisions and team composition.

I've put together a number of teams over the years, and in almost every case I've had to abide by an assemblage of pre-defined contexts that dictated the terms of the team working arrangement:

1. a team structure dictated to me
2. a working temporality scheme dictated to me
3. a geographic region in which I was allowed to hire
4. a headcount, position tuple I was required to abide by

I've come to regard these structures as weaknesses. It's a bit like the project management triangle in which you choose 1-2 from a list of inadequate options. Sometimes this is grounded in business reality, but more often than not it's because the people surrounding the decisions thrive on risk mitigation frameworks that become trickle down failure as they impose themselves on all aspects of the business regardless of compatibility.

At the moment, I'm in another startup that I have significantly more control over and again have found my partners discussing the imposition of structure and framework around how, where, why, who and what work people do before contact with any action. My mind is screaming at me to pull the cord, as much as I hate the expression. This stems from a single thought:

"Hierarchy and structure should arise from an understanding of a problem domain"

As engineers we develop processes based on logic; it's our job, it's what we do. Logic operates on data derived from from experiments, so in the absence of the real we perform thought experiments that attempt to reveal some fundamental fact we can use to make a determination.

In this instance we can ask ourselves the question, "what works?" The question can have a number contexts: people, effort required, time, pay, need, skills, regulation, schedule. These things in isolation all have a relative importance ( a weight ), and they can relatively expose limits of mutual exclusivity (pay > budget, skills < need, schedule < (people * time/effort)). The pre-imposed frameworks in that light are just generic attempts to abstract away those concerns based on pre-existing knowledge. There's a chance they're fine, and just generally misunderstood or misapplied; there's also a chance they're insufficient in the face of change.

Fictional entities like the "A Team," comprise a group of humans whose skills are mutually compatible, and achieve synergy by random chance. Since real life doesn't work on movie/comic book logic, it's easy to dismiss the seed of possibility there, that an organic structure can naturally evolve to function beyond its basic parts due to a natural compatibility that wasn't necessarily statistically quantifiable (par-entropic).

I'm definitely not proposing that, nor do I subscribe to the 10x ninja founders are ideal theory. Moreso, this line of reasoning leads me to the thought that team composition can be grown organically based on an acceptance of a few observed truths about shipping products:

1. demand is constant
2. skills can either be bought or developed
3. the requirement for skills grows linearly
4. hierarchy limits the potential for flexibility
5. a team's technically proficiency over time should lead to a non-linear relationship relationship between headcount and growth

Given that, I can devise a heuristic, organic framework for growing a team:

- Don't impose reporting structure before it has value (you don't have to flatten a hierarchy that doesn't exist)
- crush silos before they arise
- Identify needed skills based on objectives
- base salary projections on need, not available capital
- Hire to fill skills gap, be open to training since you have to pay for it either way
- Timelines should always account for skills gap and training efforts
- Assume churn will happen based on team dynamics
- Where someone is doesn't matter so long as it's legal. Time zones are only a problem if you make them one.
- Understand that the needs of a team are relative to a given project, so cookie cutter team composition and project management won't work in software
- Accept that failure is always a risk
- operate with the assumption that teams that are skilled, empowered and motivated are more likely to succeed.
- Culture fit is a per team thing, if the team hates each other they won't work well no matter how much time and money you throw at it

Last thing isn't derived from the train of thought, just things I feel are true:

- Training and headcount is an investment that grows linearly over time, but can have exponential value. Retain people, not services.
- "you build it, you run it" will result in happier customers, faster pivoting. Don't adopt an application maintenance strategy

/rant

"What are the four pillars of OOP?"

Me:(I'm not an OOP guy, but focused on design patterns)

1. Encapsulation
2. Abstraction
3. Polymorphism
4. ??(was it inheritance or composition).

Fuck, Because of the phrase "composition over inheritance". I've been mixing both composition and inheritance at the same time.

Music composition and writing my book

In competitive games in which team composition matters and you have different playable classes and/or roles (tank, area damage, point damage, various kinds of healing, buffs/debuffs, etc) what kind of character do you like to play?

I guess this would apply to stuff like MMOs, Overwatch, TF2, DOTA, Diablo/PoE, and so on.

FUCK

I really wanna love Rust. I really, really do. But no inheritance is just such a stupid decision. But inheritence bad REEEE. No. Just no. Composition only works fine for some things because it just isn't powerful enough to properly (without performance penalty or boilerplate, that is) emulate inheritance. Some things are just better with inheritance: Games, UI, html or xml libs, etc. Now I have to use stupid fucking workarounds because oh no we cannot implement inheritance because that's scary and might give the programmers to much power. I can decide when I want to use inheritance or composition for myself, dickheads

That moment when you're very happy you just completed a hard Haskell kata in CodeWars, with 8 lines, three functions, a lot of functional concepts (which would take at least 30 lines in Java or C#) and they show you the top voted solution by another user with JUST TWO LINES and a lot of function composition.

I just wrote ”o fuk u vue” as a commit message. That’s how I feel about the composition api fucking me in the arse at every turn.

Lead: alright people what are your ideas and updates for this page refactor we've been talking about.

dipshit: Alright guys, I've done a quick awesome prototype that I really like...

dipshit: *starts to speak super fast* (I catch words about function composition, clean, no side effects, speed, efficiency. Basically a string of brogrammer buzzwords.)

me: what did you mean by that? How does it work?

dipshit: *basically repeats the same drivel*

me: uh..ok I don't quite understand

everyone else looks confused.

me: ok since you've done a prototype, we take a look at it later

*** After meeting, looks at code ***

It was COMPLETE GARBAGE. He used 1,500+ lines of js in 17 files to make what was essentially a simple 2 item list.

We were looking at a way to overhaul the entire page, he "refactored" maybe perhaps 5% of the page.

There was absolutely nothing clean / functional / composable about this monstrosity. It was as if he read chapter 1 of a book on functional programming and decided he understood enough to call himself an expert.

WHY THE FUCK ARE YOU STILL HIRED?

HOW DO YOU CALL YOURSELF A DEVELOPER?

YOU ARE SELF TAUGHT, DISS PEOPLE WITH FORMAL CS/CE DEGREES AND YOU PRODUCE TRASH CODE?!

ARE YOU SO RETARDED THAT YOU DO NOT RECOGNIZE HOW STUPID YOU ARE?

Please die in a fire, along with your jock attitude and unprofessionalism. Take this worthless junk unfit to be called code with you.

I don't know what to think of Vue 3 Composition API anymore. At first I hated it because it's nothing but one big ole rip off of React, and I hate React so much; its hook system is the most disgusting anti-pattern I've ever seen in the entire JS ecosystem. This gave me the incentive to try out Svelte instead, but after doing so, I look back at Vue 3 and noticed that they're kinda similar... why are so many JS devs allergic to classes? You can have much better written code that way. Idk, I'm waiting for vue-class-component and vue-property-decorator to fully migrate. In the mean time, if I'm gonna be forced to write composition based code, I might as well use Svelte.

For some reason I keep over engineering stuff to the point I spend 2 hours thinking the best way to do something. I'm making the backend for a project of mine and I wanted somewhat decent error handling and useful error responses. I won't go into detail here but let's say that in any other (oo) language it would be a no-brainer to do this with OOP inheritance, but Rust does OOP by composition (and there's no way to upcast traits and downcasting is hard). I ended up wasting so much time thinking of how to do something generic enough, easily extendable and that doesn't involve any boilerplate or repeated code with no success. What I didn't realize is that my API will not be public (in the sense that the API is not the service I offer), I'm the only one who needs to figure out why I got a 400 or a 403. There's no need to return a response stating exactly which field had a wrong value or exactly what resource had it's access denied to the user. I can just look at the error code, my documentation and the request I made to infer what caused the error. If that does not work I can always take a quick look at the source code of the server to see what went wrong. So In short I ended up thrashing all the refactoring I had done and stayed with my current solution for error-handling. I have found a few places that could use some improvement, but it's nothing compared to the whole revamp I was doing of the whole thing.

This is not the first time I over engineer stuff (and probably won't be the last). I think I do it in order to be future-proof. I make my code generic enough so in case any requirements change in the future I don't have to rewrite everything, but that adds no real value to my stuff since I'm always working solo, the projects aren't super big and a rewrite wouldn't take too long. In the end I just end up wasting time, sanity and keystrokes on stuff that will just slow down my development speed further down the road without generating any benefits.

Why am I like this? Oh well, I'm just glad I figured out this wasn't necessary before putting many hours of work into it.

Ah, so the great war I my head has begun. When you're a CS major in college, you can't help but realize that knowing everything about computers and how to develop everything on thrm is next to impossible. So you start to question "what will be my specialty?". "Web dev or Low-level? "swirl through my head. I work on projects when I should be writing that 5-page essay for that College Composition course I care nothing about. Then on my own time I need to openly practice and refine my craft, and studying. Sheesh, I hate time (or the lack thereof). How do you do anything major on your own these days?

I want a simple solide orange color for my text.In preview mode it works perfectly .when I render my composition I get this messy color any ideas ?

How I knew programming was for me?

In high school, the special education teacher who was assigned to teach the 'Computer' class. He taught us (maybe 5 of us in the class) Basic on Apple IIe and using various apps (word processing, database, spreadsheet). One day he brought in his personal Macintosh and showed how one could write code 'underneath' clicks to perform operations. Using Pascal, I popped up messages, made beeping sounds, etc. Blew my mind.

Seeing my and other's interest, he got the board to approve a 'Advanced Comp' class for the next semester.

First day, the room was packed.

Teacher: "Raise of hands, who thinks this class is 'Advanced Composition'?"
<most of the room raises their hands>
Teacher: "That's Mr. Early's class. This is Advanced Computers. You're welcome to stay, but we're going to be writing programs and learning other computer related topics"

Next day, the class was just me. I knew then I wanted to do this the rest of my life.

Thank you Mr. Hitt.

Very Long, random and pretentiously philosphical, beware:

Imagine you have an all-powerful computer, a lot of spare time and infinite curiosity.
You decide to develop an evolutionary simulation, out of pure interest and to see where things will go. You start writing your foundation, basic rules for your own "universe" which each and every thing of this simulation has to obey. You implement all kinds of object, with different attributes and behaviour, but without any clear goal. To make things more interesting you give this newly created world a spoonful of coincidence, which can randomely alter objects at any given time, at least to some degree. To speed things up you tell some of these objects to form bonds and define an end goal for these bonds:
Make as many copies of yourself as possible.
Unlike the normal objects, these bonds now have purpose and can actively use and alter their enviroment. Since these bonds can change randomely, their variety is kept high enough to not end in a single type multiplying endlessly. After setting up all these rules, you hit run, sit back in your comfy chair and watch.
You see your creation struggle, a lot of the formed bonds die and desintegrate into their individual parts. Others seem to do fine. They adapt to the rules imposed on them by your universe, they consume the inanimate objects around them, as well as the leftovers of bonds which didn't make it. They grow, split and create dublicates of themselves. Content, you watch your simulation develop. Everything seems stable for now, your newly created life won't collapse anytime soon, so you speed up the time and get yourself a cup of coffee.
A few minutes later you check back in and are happy with the results. The bonds are thriving, much more active than before and some of them even joined together, creating even larger bonds. These new bonds, let's just call them animals (because that's obviously where we're going), consist of multiple different types of bonds, sometimes even dozens, which work together, help each other and seem to grow as a whole. Intrigued what will happen in the future, you speed the simulation up again and binge-watch the entire Lord of the Rings trilogy.
Nine hours passed and your world became a truly mesmerizing place. The animals grew to an insane size, consisting of millions and billions of bonds, their original makeup became opaque and confusing. Apparently the rules you set up for this universe encourage working together more than fighting each other, although fights between animals do happen.
The initial tools you created to observe this world are no longer sufficiant to study the inner workings of these animals. They have become a blackbox to you, but that's not a problem; One of the species has caught your attention. They behave unlike any other animal. While most of the species adapt their behaviour to fit their enviroment, or travel to another enviroment which fits their behaviour, these special animals started to alter the existing enviroment to help their survival. They even began to use other animals in such a way that benefits themselves, which was different from the usual bonds, since this newly created symbiosis was not permanent. You watch these strange, yet fascinating animals develop, without even changing the general composition of their bonds, and are amazed at the complexity of the changes they made to their enviroment and their behaviour towards each other.
As you observe them build unique structures to protect them from their enviroment and listen to their complex way of communication (at least compared to other animals in your simulation), you start to wonder:
This might be a pretty basic simulation, these "animals" are nothing more than a few blobs on a screen, obeying to their programming and sometimes getting lucky. All this complexity you created is actually nothing compared to a single insect in the real world, but at what point do you draw the line? At what point does a program become an organism?
At what point is it morally wrong to pull the plug?

Turns out composition over inheritance won't save you from downcast hell, it just becomes `_ => abort()` hell.

In most businesses, self-proclaimed full-stack teams are usually more back-end leaning as historically the need to use JS more extensively has imposed itself on back-end-only teams (that used to handle some basic HTML/CSS/JS/bootstrap on the side). This is something I witnessed over the years in 4 projects.

Back-end developers looking for a good JS framework will inevitably land on the triad of Vue, React and Angular, elegant solutions for SPA's. These frameworks are way more permissive than traditional back-end MVC frameworks (Dotnet core, Symfony, Spring boot), meaning it is easy to get something that looks like it's working even when it is not "right" (=idiomatic, unit-testable, maintainable).

They then use components as if they were simple HTML elements injecting the initial state via attributes (props), skip event handling and immediately add state store libraries (Vuex, Redux). They aren't aware that updating a single prop in an object with 1000 keys passed as prop will be nefarious for rendering performance. They also read something about SSR and immediately add Next.js or Nuxt.js, a custom Node express.js proxy and npm install a ton of "ecosystem" modules like webpack loaders that will become abandonware in a year.

After 6 months you get: 3 basic forms with a few fields, regressions, 2MB of JS, missing basic a11y, unmaintainable translation files & business logic scattered across components, an "outdated" stack that logs 20 deprecation notices on npm install, a component library that is hard to unit-test, validate and update, completely vendor-& version locked in and hundreds of thousands of wasted dollars.

I empathize with the back-end devs: JS frameworks should not brand themselves as "simple" or "one-size-fits-all" solutions. They should not treat their audience as if it were fully aware and able to use concepts of composition, immutability, and custom "hooks" paired with the quirks of JS, and especially WHEN they are a good fit.

I have an 8gb i5 7200u nvidia 920mx laptop.I want to optimize aftereffects because preview mode is so slow and not showing realtime fps.My composition is 1080p

Sydochen has posted a rant where he is nt really sure why people hate Java, and I decided to publicly post my explanation of this phenomenon, please, from my point of view.
So there is this quite large domain, on which one or two academical studies are built, such as business informatics and applied system engineering which I find extremely interesting and fun, that is called, ironically, SAD. And then there are videos on youtube, by programmers who just can't settle the fuck down. Those videos I am talking about are rants about OOP in general, which, as we all know, is a huge part of studies in the aforementioned domain. What these people are even talking about?
Absolutely obvious, there is no sense in making a software in a linear pattern. Since Bikelsoft has conveniently patched consumers up with GUI based software, the core concept of which is EDP (event driven programming or alternatively, at least OS events queue-ing), the completely functional, linear approach in such environment does not make much sense in terms of the maintainability of the software. Uhm, raise your hand if you ever tried to linearly build a complex GUI system in a single function call on GTK, which does allow you to disregard any responsibility separation pattern of SAD, such as long loved MVC...
Additionally, OOP is mandatory in business because it does allow us to mount abstraction levels and encapsulate actual dataflow behind them, which, of course, lowers the costs of the development.
What happy programmers are talking about usually is the complexity of the task of doing the OOP right in the sense of an overflow of straight composition classes (that do nothing but forward data from lower to upper abstraction levels and vice versa) and the situation of responsibility chain break (this is when a class from lower level directly!! notifies a class of a higher level about something ignoring the fact that there is a chain of other classes between them). And that's it. These guys also do vouch for functional programming, and it's a completely different argument, and there is no reason not to do it in algorithmical, implementational part of the project, of course, but yeah...
So where does Java kick in you think?
Well, guess what language popularized programming in general and OOP in particular. Java is doing a lot of things in a modern way. Of course, if it's 1995 outside *lenny face*. Yeah, fuck AOT, fuck memory management responsibility, all to the maximum towards solving the real applicative tasks.
Have you ever tried to learn to apply Text Watchers in Android with Java? Then you know about inline overloading and inline abstract class implementation. This is not right. This reduces readability and reusability.
Have you ever used Volley on Android? Newbies to Android programming surely should have. Quite verbose boilerplate in google docs, huh?
Have you seen intents? The Android API is, little said, messy with all the support libs and Context class ancestors. Remember how many times the language has helped you to properly orient in all of this hierarchy, when overloading method declaration requires you to use 2 lines instead of 1. Too verbose, too hesitant, distracting - that's what the lang and the api is. Fucking toString() is hilarious. Reference comparison is unintuitive. Obviously poor practices are not banned. Ancient tools. Import hell. Slow evolution.
C# has ripped Java off like an utter cunt, yet it's a piece of cake to maintain a solid patternization and structure, and keep your code clean and readable. Yet, Cs6 already was okay featuring optionally nullable fields and safe optional dereferencing, while we get finally get lambda expressions in J8, in 20-fucking-14.
Java did good back then, but when we joke about dumb indian developers, they are coding it in Java. So yeah.
To sum up, it's easy to make code unreadable with Java, and Java is a tool with which developers usually disregard the patterns of SAD.

Dear composition API, I'm going to compose you as you've never been "setup".

Help me out a bit, functional programming fans!

I'm experimenting with functional programming through JavaScript.

I created some dummy data to experiment with and created a simple function to query the data. I would like to get all elements, whose type attribute is not 'x'. A simple solution can be seen under the 'original code' part.

Under the 'fully functional code' part I gathered some frequently used general purpose functions, which I assembled into the function composition at line 45.

I'm having a bad taste in my mouth and feel that I've gone too far. I basically replaced every language element for a function. Is this the goal of functional programming? Is this how a perfectly functional code should look like?

So is the difference between inheritance and composition is that of a fridge and iceman?

class Man {
fun greet(){return "hi"}
}

class IceMan extends Man{
override fun greet(){return "hi i am iceman"}
fun getIce(){return "ice"*Random.nextInt()}
}

class Fridge{
private Man manAi;
private String s = "ice";
fun greet(){return manAi.greet()}
fun getIce(){return s*Random.nextInt()}
}

}

=========
Basically , in first case, a class is getting features by inheriting from parent while in another case, a class is getting features by internally having objects of other classes that could provide those features?

I know using Composition is a good way of reusing components. Works like a charm and sends data down the tree like a waterfall.

But in our codebase it's applied to bugs. Fix one, get two more, fix two get four more.

I want to cry :'((

I'm probably doing something wrong because I cannot think of a good implementation (or alternative) for this pattern in Rust.

trait Terminal {
fn color_manager(&mut self) -> &mut dyn ColorManager;
}

All I want is having things in their own tidy little class with a specific job. In this case handling color conversion, having a registry for indexed colors, stuff like that...

It's composition which Rust should be good at so I assume there's a better way

How can I do something like this properly?