5 ms·
My main objection is always readability. Sure, it is nice when I am writing code and on top of my head I know the type of each variable, but when I am reading c
by riyadparvez 10y ago
My main objection is always readability. Sure, it is nice when I am writing code and on top of my head I know the type of each variable, but when I am reading code, this becomes nightmare for lack of type information.
- B1FF_PSUVM 10y ago> My main objection is always readability. Strange, that's my objection to type declarations.
- ufo 10y agoI'm nor sure I would use the word "readability" there. I'd prefer saying that types aid in documentation.
- tigershark 10y agoFactory<MarketDataService<Stock>> marketDataService = new Factory<MarketDataService<Stock>>() Is objectively less readable than def marketDataService = new Factory<MarketDataService<Stock>>() And even the latter is not the best. def MyClass(marketDataService){ this.marketDataService = marketDataService } It's imho the most readable. If the name is self describing and there are unit tests that prove that I'm receiving the correct type I cannot care less about the type itself.
- ubertaco 10y agoAlternatively, in MLs (this sample specifically is OCaml) : type expression = | Number of float | Add of expression * expression | Subtract of expression * expression | Multiply of expression * expression | Divide of expression * expression let rec eval expr = match expr with | Number n -> n | Add (expr1, expr2) -> (eval expr1) +. (eval expr2) | Subtract (expr1, expr2) -> (eval expr1) -. (eval expr2) | Multiply (expr1, expr2) -> (eval expr1) *. (eval expr2) | Divide (expr1, expr2) -> (eval expr1) /. (eval expr2) Hey look, I just built a calculator DSL. And everything is statically typed and typechecked (and if I left off the "Divide" case in my "eval" method, it would warn me).