7 ms·
I've never found static typing to aid in my understanding of a program. For example: def add_item_to_cart(item) vs void add_item_to_cart(IItem item)
by jacobsenscott 4y ago
I've never found static typing to aid in my understanding of a program. For example:
def add_item_to_cart(item)
vs
void add_item_to_cart(IItem item)
They are equally easy to understand. The first is easier to read.
- joeldo 4y agoWhat is an item in the first declaration? Is it an id? Is it an object (if so, what type of object? Id and qty or some other data)? I guess you now need to read through the implementation or docs. The first is much easier to read incorrectly.
- bjourne 4y agoWhat is an item in the second declaration? That it has type "Item" doesn't help you unless you have contextual information. And if you have contextual information you can probably figure out what an item is in the first declaration too.
- joeldo 4y agoI would argue that it isn't a zero-sum game. Extra context (that is enforced) is better than none at all.
- kdtsh 4y agoAn item is an IItem, as it says in the definition. You can always ‘figure out what an item is’ in a dynamic typing system, that’s not the problem. There’s an incredible amount of mental overhead in any non-trivial project which employs dynamic typing. Engineers who can work around this have my respect, but I find static typing to be the easiest solution to this problem by far.
- bjourne 4y agoThat fact is useless without any context. An "item" could have been an "Ifdkjsj" and you'd be none the wiser. "incredible amount of mental overhead" needs a citation and, as shown in TFA, no citation exists.
- kdtsh 4y agoMaybe I’m not understanding where you’re coming from because as far as I can tell a ‘lfdkjsj’ and a ‘skfjwb’ which are both an IItem, or both a IWhcjwp, is easier to work with than the dynamic alternative. Regardless of how poorly named a variable is, in a static ruling system what you see is what you get, where as in a dynamic typing system what you see could be anything at runtime. The only citation I have is the tenuous grip I have on my own sanity - I could have more correctly talked about the incredible amount of mental overhead this has _for me_, but read the rest of the thread and you’ll see that this isn’t an uncommon experience. As I said, if you can work around this then you have my respect.
- bjourne 4y ago> in a static ruling system what you see is what you get, where as in a dynamic typing system what you see could be anything at runtime. What you see in a statically typed language: IBlaha blah. What could blah be? An IBlaha. What could IBlaha be? Anything! The type has not gained you anything. > The only citation I have is the tenuous grip I have on my own sanity That's an argument from authority where you are the authority. It doesn't work on HN since we are all skilled developers. I've also been a software developer for decades and I can count on one hand the times static types has provided a tangible benefits.
- kdtsh 4y agoNow we are just talking about using a sane naming convention for your types. Depending on the paradigm you are working in your instance of IBlaha has a consistent definition - in a trait or a class or whatever else you like. It also likely makes simple work for your IDE during refactoring as others have observed. You don’t get this from dynamic typing. Of course you could say the same thing about sane naming dynamic naming conventions for your declarations in a dynamically typed language - and you wouldn’t be wrong, but a compiler won’t help you in the case of human error. All I’m interested in is offloading as much complexity onto the tools at my disposal, so I can focus on what’s important. On my citation … that was tongue in cheek and I thought it was obvious. I don’t have a citation, this is all my own experience. For the third time, if you can work your way around this you have my respect.
- jacobsenscott 4y agoIf it were an item id the argument would be item_id. It is an object. What type of object? The type that can be added to a cart. You don't just drop a programmer into the code and have them call a function in a vacuum. Nobody just throws random objects at a function. They are familiar with the code in general and they know what to do.
- joeldo 4y ago- If it were an item id the argument would be item_id. It is an object. You've never worked with vaguely named variables? What you are suggesting is guessing the data type based off the name. - What type of object? The type that can be added to a cart. Okay sure, but what precisely is that? - Nobody just throws random objects at a function. I couldn't agree more - so the follow up question is what is the fastest way to get familiar with what type of input or output this function returns? - They are familiar with the code in general and they know what to do. For very small projects with very small teams after some onboarding time perhaps, but outside of this I would disagree. Code changes over time, parts that you use to know intimately get changed subtley and erode knowledge away. Having types in place highlights these changes if your assumptions are incorrect.
- jacobsenscott 4y agoIf you're working with badly named variables you have more problems than a type system can help with. It doesn't matter "what precisely" is the the thing that you are adding to the chart, and a static type system won't tell you that either. There could be be any of 1000 things that implement IItem. And probably half those things just throw exceptions for methods they aren't actually able to implement.
- peteradio 4y agoWhat about return types? Do you generally deal with voids in your line of work? Having code that could return different types depending on branching is pretty self-evidently worth preventing.
- randtrain34 4y agoBut suppose you were unfamiliar with the code, the 2nd tells you what fields/methods are available for "item", and furthermore most IDEs will use that info to populate autocomplete suggestions and such.
- falcolas 4y agoLanguage engines exist for Python and Ruby (and Lisp, etc.)as well, and they handle autocomplete and refactoring quite handily.
- semiquaver 4y agoNo they don’t.
- maleldil 4y agoHow would a "language engine" know what you can do with `item` if it has no type information? You can do that with Python (sometimes) because many libraries have type hints today, so even if you don't use types yourself, the type checker can infer them in your code and help you out.
- falcolas 4y agoIs this a serious question? Code analysis (both static and dynamic). The same way Rust checks for object lifespans with the borrow checker, which is distinct from the compiler and type system. The same way valgrind for C can check for use after free. The same way errorprone can look for null checks in Java. This is a well tested and proven technique. Static code analysis is a staple of the industry, when it comes to automated code analysis.
- lijogdfljk 4y agoDepends on the specifics, but i'm betting if `IITem` is close by i know how to interact with it. I have no clue what the hell fields or methods may or may not be on `item`. Nor will i, ever. At best i have to enforce method/fields myself, at worst i subscribe entirely to duck typing and let the gods sort it out.
- jacobsenscott 4y agos/gods/tests/ - which you need even in a statically typed system.
- lijogdfljk 4y agoI don't need tests to check what methods or fields are on my types though. You need the same tests from a typed system in a non-typed. You _don't_ need all the tests from a non-typed system in a typed system. Writing tests to enforce types just hand-rolls a type system, in my experience.
- jacobsenscott 4y ago> I don't need tests to check what methods or fields are on my types though. You do though, because invariably people violate the LSP and just "throw Unimplemented" in the methods required by the interface they can't figure out how to implement. In other words all system are duck typed in reality.
- lijogdfljk 4y agoI don't, though. If it compiles, it exists. Saying that a method might actually be a nuke is a bit besides the point. It could also contain a virus. Not sure what typing system you're referring to, but it sounds very half-baked at best. I'm using Rust fwiw. I cannot access any field or method that does not exist. Even dynamic traits are compile time enforced, but i think we can largely have this discussion around static dispatch.
- esperent 4y agoWhat about addItemsToCart(items) Vs Type ItemCode: string; Type ItemDetails = {...}; addItemsToCart(items:ItemCode[]) or, for a slightly different implementation: addItemsToCart(items:Record<ItemCode, ItemDetails>) If you only use trivial examples, types seem silly. But in real examples they become more useful. In this case looking at the function signature give you immediate information about the implementation that is missing from the untyped version. EDIT: please excuse formatting, I'm on mobile and cannot get it to add spaces before the last code block
- gpderetta 4y agoStatic typing does not imply type annotation. For example in C++: void add_item_to_cart(auto item) will still statically verify that item has the required syntax; C++ is very poor on this aspect on only doing the verification at instantiation time, languages with more sophisticate typing systems can infer the correct type from tome add_time_to_cart definition alone.