4 ms·

Change my view - Half the design patterns are due to Static Typing &...

2 points by techsin101 6y ago

WARNING PERSONAL OPINION COMING THROUGH!!!! ... Single inheritance 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'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's what design patterns are, at least lot of them. They are simply strategies to mitigate the limitations of Static typing. For example Factory Pattern, Facade, Decorator, Adapter, ... Now definitely not the case for ALL design patterns but I do think many are. It's kinda sad when you entire program is simply a fight against types. Coming from Ruby and Javascript land this seems very stupid. I don't need to make 10 abstract classes, 10 interfaces and overload, underload, sideload (lol) same functions. The main pain point seem to be you have only one chain of inheritance. 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. It'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. I used typescript. I didn'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.

thecupisblue 6y ago
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 6y ago
  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 6y ago
    >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.
AnimalMuppet 6y ago
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 6y ago
  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.
rogerkirkness 6y ago
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 6y ago
  yes because logic part is huge

2 points by techsin101 6y ago

thecupisblue 6y ago

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 6y ago
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 6y ago
  >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.

AnimalMuppet 6y ago

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 6y ago
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.

rogerkirkness 6y ago

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 6y ago
yes because logic part is huge