
Change my view - Half the design patterns are due to Static Typing &... - techsin101
WARNING PERSONAL OPINION COMING THROUGH!!!!<p>... Single inheritance<p>Imagine you are hired in a company but they have this rule that nobody can walk more than 3 steps in one direction so you have to rotate 90 degrees, also you can&#x27;t cross the path you have travelled already. Now everyone comes up with contrived and ridiculous strategies to get to the restroom, cafetaria, and kitchen. That&#x27;s what design patterns are, at least lot of them.<p>They are simply strategies to mitigate the limitations of Static typing. For example Factory Pattern, Facade, Decorator, Adapter, ...<p>Now definitely not the case for ALL design patterns but I do think many are. It&#x27;s kinda sad when you entire program is simply a fight against types.<p>Coming from Ruby and Javascript land this seems very stupid.<p>I don&#x27;t need to make 10 abstract classes, 10 interfaces and overload, underload, sideload (lol) same functions.<p>The main pain point seem to be you have only one chain of inheritance.<p>What we do these days for JS seems to be the simplest solution. Import whatever functionality you need, run the function, and be done with it. No point in defining entire world in terms of single inheritance. Simply compose what you need.<p>It&#x27;s my opinion OOP with Static typing results in very contrived code that is half solving the technical problem and half fighting its limitations. Oh but that autocomplete.<p>I used typescript. I didn&#x27;t care much for abstract blabalba. But I really liked being able to define input and output in strict terms. Which is like JS docs but more enforced. VScode works great with it.
======
AnimalMuppet
I think the same about FP and some of the monad hoops they jump through. Half
of the uses of monads are not because they're so optimal for the problem at
hand. Rather, it's because they're the only way of escape from the straight-
jacket of functional purity, no side effects, and no state.

And, to parallel thecupisblue's comment, there really are reasons that the FP
people don't want side effects. There are reasons they don't want state -
real, valid reasons. In going as far as they can away from state and side
effects, though, they've painted themselves into a corner where monad
gymnastics are the only way of escape. I am not convinced that _in all cases_
the rigorous FP cure is better than the disease.

~~~
techsin101
FP zealots do go overboard and never want to modify a variable, they'd rather
use x^10 space for N variables and loop 10 times to get to the final result
but that's not what I'm condoning.

------
thecupisblue
Have you ever worked on a large-scale project with a large team? Do you know
how much mental context is represented in an information such as a type? Or
that some patterns are there for easier reading and writing, or preventing
people using your API to do stuff they shouldn't? Or that it's just an
abstract name for something that's not strictly defined but is easier to
explain with one word than with a paragraph?

It's not neither inheritance nor static typing's problem that you are
obviously working on a Typescript codebase with a lot of design patterns and
code. Have you tried other languages that are more expressive than Typescript
but deal with types? Grow over your arrogance and realise that you are not the
only person in the world writing the code, reading the code and working with
it. I'd rather have types and inheritance than have a bunch of random objects
strung together with hacked glue or abstract naming the author thought
represented an idea that would've been obvious under a different name and then
waste time trying to figure out all possible inputs and outputs. I've seen
this attitude before and it's just a phase on your journey and usually occurs
when people are frustrated with blindly following form. Instead of attacking
all those things, read into them, think about them, figure out why they exist
and when and where to use them. Everything is there for a reason.

~~~
techsin101
It's never been a problem for me to look where the code is being used and what
it does. I see there are 2 types of functions, functions that do one
particular thing and functions that are like main in C++ they simply compose
all functions and handle errors on higher level. So if you know the function
name and where it's being used you pretty much know what it will do more or
less. Problem with OOP + Types is that it requires you predict future and come
with convoluted interdependent structure that forever binds your code. If you
were wrong in anyway or if you misunderstood the problem not only you spent
10x time building out this megacity for no reason now you have to break it
too. Had you been using modular functions in dynamically typed language you'd
have to simply update one single function and be on your way.

Every time you create a type, you create dependency into the entire code,
everywhere that type is used.

Every time you inherit something you create technical debt.

World can't be modeled in single inheritance and future can't be predicted
with 100% certainty.

~~~
thecupisblue
>Problem with OOP + Types is that it requires you predict future

No, they don't? They let you scope things safely, in context and with meaning
attached. If you try to "predict the future", that's your problem.

> and come with convoluted interdependent structure that forever binds your
> code

What are you even talking about? Nobody is forcing you to write it like that.
You are writing it like that. You can write functional monad hell in a bad way
just as you can create super convoluted structures that seep through your
codebase. It isn't the fault of a programming paradigm, it's your fault.

> Had you been using modular functions in dynamically typed language you'd
> have to simply update one single function and be on your way

Really? Because you never had to update something throughout multiple
functions? Because if you write "modular functions" the requirements never
change and you can predict the future with 100% certainty?

>Every time you create a type, you create dependency into the entire code,
everywhere that type is used.

And every time you create a function, you create a dependency everywhere that
function is used.

>World can't be modeled in single inheritance and future can't be predicted
with 100% certainty.

Did anyone say that? Ever?

What you are saying is "oil paint is better than acrylics in any way, the
world doesn't dry after a minute! The world is changing!". Or "Screwdrivers
are better than wrenches! Wrenches are evil!".

Yes, if you don't know how to use a wrench, you might hit yourself on the
fingers with it. It's not the wrenches fault.

Instead of being so frustrated at a paradigm, grow up and accept that
programming is not a single-track single-minded single-person single-paradigm
job. You keep acting like the only way to use types is to shoehorn everything
into a type and an object that inherits something. Or that everyone builds out
huge complicated FactoryAdapterMapperBuilderCreatorBeans that do who-knows-
what. It's not types, it's just bad code.

Instead of wasting your time on trying to wage a holy war of paradigms, go
outside and take a breathe of fresh air. It's better for you.

------
rogerkirkness
If the database is typed on one side, and the documentation is typed on the
other side, you really want dynamic typing in the middle?

~~~
techsin101
yes because logic part is huge

