Thoughts on software development

You will never win a fight with such a sophisticated machine as even the weakest laptop is.

Take is as a cooperation with occassional disputes. Your life will be much more easier.

Happy weekend my fellow Programmers!

Just have finished the https://www.udemy.com/certificate/UC-b05767c0-bbf0-4abd-9d0a-631a583ce589/

Was not much difficult with prior knowledge of Typescript.
Seems like Much of the Typescript concepts are comming from C #.
More on that in my blog soon.

Udemy Course Completion Certificate My course completion certificate for "C # 10 | Ultimate Guide - Beginner to Advanced | Master class"

Ways to adhere to the OCP principle.

The OCP tells us to keep the class closed to modification and opened to extensions.

The first thing, that came up to my mind was to extend an abstract class.

However there are more ways to achieve the OCP compliant code.

Not to mention, that according to Gang of Four, "You should prefer decoration before extension" for classes.

To follow this we have several basic ways to work with classes:
- visitor
- delegation
- composition
- strategy
- state

The OCP in nutshell tells us that every new piece of functionality, should be achievable through extension of the affected holder of the logic and information.

The patterns mentioned above are special case of reification. You name a piece of functionality, give it life in the form of code and fling it together with class prepared to be extended in one way or another.

Should every function be, at worst, unary?

You have basically three ways to convey the intended reason behind functions existence.
- Name
- Body
- Parameters

The parameters name, if you look at it from the point of view of the arguments of the functions invocation, can convey only a little information, which is not even visible at the first sight and thus not very intuitive.

As for me, the function should not have more than two arguments. Every time, you need more, you can always turn that into a single Object-based argument. This have one side-benefit: Objects' properties add more information about the reason for the existence of the given parameter - you have there always the name of the property, which you can use to convey this additional information.

Studying REACT CONTEXT in the source code, I have not found any substantional use case, which couldn't be achieved by custom defined hook.

Guys, do you have some scenarion, in which CUSTOM React HOOK cannot replace React CONTEXT?

What is, as for you, the core pattern for functional programming paradigm?
Imho, it is clearly a decorator pattern.

What is the pattern, the whole React ecosystem is build upon?
Again, the decorator pattern.

Altogether, this can taken as a prof by trasitivity that React is obviously a functional library.

Just have finished Refactoring For Software Design Smells.
Sometimes a book is sparking with ideas so much, that almost every line incurs some deep thought. This book is definitelly one of them. I was reading this book for 4 weeks in total. Not because it would be so boring, but because I was so immersed, that almost every chapter needed to be read at least twice, repeating the concepts over and over again.
Highly recommending.

After reading Clean Code and Interpretation fo Computer Languages, I am becomming more and more persuased, that significant part to SW engineering is the ability to speak in coherent and logically profound way.

By far my most favorite definition of SW language is:

"Medium to convey the record about the flow of the program from human to machine".

Tight coupling
Is supposed to be an opposite of the cohesion.

Even if methods inside a class are supposed to be cohesive, once we spread members of the abstraction to different places, the result is supposed to be called tight coupling.

The reasoning behind this is, that abstraction follows some principles that are given to us by the technology we use. Thus, what is supposed to be cohesive abstraction, will probably be technically implemented as one file containing that abstraction. No matter whether class of functional component.

Once we have the possibility to move the abstractions content inside our IDE, what is supposed to be cohesive should be a purpose of one such atomic operation. If we need to focus on repeating this operation to keep the covered use case of the abstraction valid, we are experiencing tight coupling.

Just WOW

GitHub - giltayar/proposal-types-as-comments: ECMAScript proposal for type syntax that is erased - Stage 0 ECMAScript proposal for type syntax that is erased - Stage 0 - GitHub - giltayar/proposal-types-as-comments: ECMAScript proposal for type syntax that is erased - Stage 0

Sometimes, after going through the React source code, which I mostly do with every breaking version, I re-watch the introductory video by Petr Hunt about the principles behing React.

Interesting, how each time I see that, it helps to harden the news flashes into an broader mental model.

Pete Hunt: React: Rethinking best practices -- JSConf EU Slides: http://www.slideshare.net/floydophone/react-preso-v2React, the new open-source JS library from Facebook and Instagram, is a different way to write Ja...

Are SOLID principles a valid concept in the functional realm of the REACT development?

Thinking about that and after going through many resources on functional programming I beg to postulate they are.

A lot of clarity to that for me have brought first three intial chapters of the Robert C. Martin's "Clean architecture".

The acronym becomes even more valid after reading a "Composing Software" serie by Eric Elliot.

Other concepts like:
- Cohesion
- Separation of concerns
- Modularity
- Abstraction
- Hierarchies
- Encapsulation

and many more make sense too after reading these two kind of scriptures of modern Javascript programming.

What a class means in OOP, the module as kind of singleton means in the realm of Javascript functional frameworks.

The idea of cohesion of a class can be extended to the idea of a cohesion of a module.

Not to mention, that there is no violation of functional paradigm to use and operates on objects, as far as the function keeps it's referential integrity.