4 ms·

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 so

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.

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.