3 ms·
This is an excellent point. I just finished reading the book “Domain Modeling mad Functional” [0] and it absolutely opened my eyes in terms of the power of stro
by garren 5y ago
This is an excellent point. I just finished reading the book “Domain Modeling mad Functional” [0] and it absolutely opened my eyes in terms of the power of strong types and functional design.
I believe that strong types can absolutely help to improve a code base, but they can’t do it alone. And they certainly won’t do much if one only associates strong type systems with intellisense.
I agree that a strong type system might make some things harder, but I think that’s because you’re design probably requires a bit more thought up front. I don’t know that I agree with your “real functional programming” statement though. JS lends itself to functional design really well. I don’t use TS, but as a superset of JS, I’d be surprised if it didn’t work as well in an FP design.
[0] https://pragprog.com/titles/swdddf/domain-modeling-made-functional/ https://pragprog.com/titles/swdddf/domain-modeling-made-func...
- valenterry 5y ago> I agree that a strong type system might make some things harder, but I think that’s because you’re design probably requires a bit more thought up front. Unfortunately it is rather because, as of now, all but the most advanced & academic type-systems are incapable of solving even basic tasks without getting into the way. Easy examples: Pick a statically typed language of your choice and implement a function, that takes any function A that returns a boolean and returns a new function that is just like A but returns the opposite result. E.g.: fun even(input: Number): Boolean = ... even(2) // true fun opposite(function: ?): ? = ... fun odd = opposite(even) odd(2) // false What are the types of the two question-marks? Or: Try to write a function that executes SQL and, based on the SQL, returns a proper return type that contains type-information about what will be returned. Then write a function that can model joins of two of these SQLs. I.e. the compiler must be able to calculate a new type structure, based on two other type structures. Or: Implement a function that "slides" over a list and the sliding size window can be configured. E.g.: fun sliding(size: Number, list: List[String], function: ? => ...) = ... list = List("a", "b", "c", "d", "e") sliding(2, list, (window: ?) => print(window)) // prints (a, b) then (b, c) then (c, d) ... sliding(3, list, (window: ?) => print(window)) // prints (a, b, c) then (b, c, d) then (c, d, e) ... What is the type of the value that will be passed to function: ? => ... The type must depend on the given window-size. But almost all type-system fail to make this possible. Only so called value-dependent type-systems can do that, and some other's that have built-in special features for specific use-cases, but fail to generalize them (e.g. looking at you typescript).
- tacotacotaco 5y agoI have read this book and recommend it other devs. It is a great example of using types effectively and writing good functional code. I have worked on several TS projects and none even had a glimpse of the patterns explored in that book. That is my point. TS doesn't make you write better code. If anything, it encourages the dev to document the types which is still no guarantee of quality documentation. I have worked on several JS projects that are written functionally. They have been some of the high points of my web development experience. None of the TS projects I have worked have been functional. Maybe it's a coincidence.