5 ms·

This old canard. I am a professional Objective-C developer and have been for several years. Type safety is not an absurd length. Eliminating an entire class of

This old canard. I am a professional Objective-C developer and have been for several years. Type safety is not an absurd length. Eliminating an entire class of errors from your program by having the compiler infer and enforce types is not ridiculous. Using a type-safe language is a very good idea. We are human. We have stupid unchecked nil object errors come up in our code bases all the time. Swift will ensure that does not happen again. That's like the least part of what I am looking forward to. If you are having trouble writing a program that compiles with strong typing, I don't know what to tell you. Using types is nothing more than stating what you expect the shape of the data to be in and having the compiler make sure that is so.

vinceguidry 11y ago
Is it really worth that much though? I'm a Ruby developer and I've only very rarely actually wanted a type system. I've often found that I could work around its lack by implementing class checking and raising an error whenever the wrong type gets passed. It gave me everything I wanted without having to give up dynamicism. I think types probably work well in situations where you don't know what kind of code you're going to have to deal with in the future. It depends on the type of organization you're in, not the type of problem you're trying to solve. I think any respectable programmer should try to avoid having to have people hook into his code at any level other than the level he defines. To interface at the level of data, not client code. If you are needing typing to solve your own inadequacies as a programmer, you should become a better programmer rather than expect your language to do that for you. With a dynamic language, you can get all you could have wanted from a type system without having to infect your whole codebase with it. Most of the time, you just don't need it.
- actsasbuffoon 11y ago
  I agree that some type systems are infuriating. They demand highly verbose code, and offer almost no protection in exchange for your effort. However, not all type systems are equal. Haskell (for example) almost never requires explicit type annotations. It has a type inference system that is sometimes frighteningly good. You can express a huge amount of logic through the type system and enforce very non-trivial constraints. I've been writing Ruby for 7 years, and I've loved every moment of it. It's a wonderful language. That said, I usually have to spend quite a bit of time getting my code to work correctly. In Haskell, by the time I get to the point where the type checker approves of my code, it usually works as I intended the very first time I run it. It's a wonderful feeling.
  - vinceguidry 11y ago
    The problem isn't the type annotations. The problem is losing the meta-programming capabilities you gain when you can make everything an object with a class. These capabilities are really useful when you don't really know what you're doing yet, which, for me, is almost all the time. Knowing at any time I can take the class hierarchy I just built, turn each class into an instance of an object, and store those objects in a database, with a 10 minutes and a fancy bit of code, is much much more useful than having a babysitter.
- douche 11y ago
  I don't know much about Ruby, I will admit. But dynamic typing is terrible for large code bases. The only place I allow it is at the very edges of our system, where we are transforming the proper types of the internal system into POD-objects to be serialized and returned to the JS/HTML front-end. I'm not willing to give up the compile-time safety of breaking the build if someone inadvertently assigns a string to a number, or an object to a primitive in code that they check in, in place of unit testing that, odds are, will be incomplete or otherwise broken and won't catch the problems that static typing catches.
  - vinceguidry 11y ago
    > But dynamic typing is terrible for large code bases. Yes, you can get into a lot of trouble very quickly as your codebase grows if you don't have a heavy security blanket. But the more Ruby I write, the more typing looks like Linus from Charlie Brown's blanket. Because you don't need a monolithic code base any more. You can break it up into smaller pieces that interact with each other using POD objects. When I start to have type problems in Ruby, I start looking around for a domain concept that I need to extract into a gem. The codebase never grows to a point to where it becomes a serious problem.
- buttchrist 11y ago
  > If you are needing typing to solve your own inadequacies as a programmer, you should become a better programmer rather than expect your language to do that for you. That is one of the most ignorant things I have ever read. Perhaps if you are needing dynamicism to solve your own inadequacies as a programmer, you should become a better programmer rather than rely on your language like a crutch. Perhaps if you were an adequate programmer, you wouldn't have such a hard time understanding types and getting the compiler to accept your program. I cannot imagine a worse programmer than one who willfully rejects a tool which improves a codebase to great extent. Typed languages are strictly more powerful, and you cannot get the same code guarantees from a dynamic language.

vinceguidry 11y ago

Is it really worth that much though? I'm a Ruby developer and I've only very rarely actually wanted a type system. I've often found that I could work around its lack by implementing class checking and raising an error whenever the wrong type gets passed. It gave me everything I wanted without having to give up dynamicism. I think types probably work well in situations where you don't know what kind of code you're going to have to deal with in the future. It depends on the type of organization you're in, not the type of problem you're trying to solve. I think any respectable programmer should try to avoid having to have people hook into his code at any level other than the level he defines. To interface at the level of data, not client code. If you are needing typing to solve your own inadequacies as a programmer, you should become a better programmer rather than expect your language to do that for you. With a dynamic language, you can get all you could have wanted from a type system without having to infect your whole codebase with it. Most of the time, you just don't need it.

actsasbuffoon 11y ago
I agree that some type systems are infuriating. They demand highly verbose code, and offer almost no protection in exchange for your effort. However, not all type systems are equal. Haskell (for example) almost never requires explicit type annotations. It has a type inference system that is sometimes frighteningly good. You can express a huge amount of logic through the type system and enforce very non-trivial constraints. I've been writing Ruby for 7 years, and I've loved every moment of it. It's a wonderful language. That said, I usually have to spend quite a bit of time getting my code to work correctly. In Haskell, by the time I get to the point where the type checker approves of my code, it usually works as I intended the very first time I run it. It's a wonderful feeling.
- vinceguidry 11y ago
  The problem isn't the type annotations. The problem is losing the meta-programming capabilities you gain when you can make everything an object with a class. These capabilities are really useful when you don't really know what you're doing yet, which, for me, is almost all the time. Knowing at any time I can take the class hierarchy I just built, turn each class into an instance of an object, and store those objects in a database, with a 10 minutes and a fancy bit of code, is much much more useful than having a babysitter.
douche 11y ago
I don't know much about Ruby, I will admit. But dynamic typing is terrible for large code bases. The only place I allow it is at the very edges of our system, where we are transforming the proper types of the internal system into POD-objects to be serialized and returned to the JS/HTML front-end. I'm not willing to give up the compile-time safety of breaking the build if someone inadvertently assigns a string to a number, or an object to a primitive in code that they check in, in place of unit testing that, odds are, will be incomplete or otherwise broken and won't catch the problems that static typing catches.
- vinceguidry 11y ago
  > But dynamic typing is terrible for large code bases. Yes, you can get into a lot of trouble very quickly as your codebase grows if you don't have a heavy security blanket. But the more Ruby I write, the more typing looks like Linus from Charlie Brown's blanket. Because you don't need a monolithic code base any more. You can break it up into smaller pieces that interact with each other using POD objects. When I start to have type problems in Ruby, I start looking around for a domain concept that I need to extract into a gem. The codebase never grows to a point to where it becomes a serious problem.
buttchrist 11y ago
> If you are needing typing to solve your own inadequacies as a programmer, you should become a better programmer rather than expect your language to do that for you. That is one of the most ignorant things I have ever read. Perhaps if you are needing dynamicism to solve your own inadequacies as a programmer, you should become a better programmer rather than rely on your language like a crutch. Perhaps if you were an adequate programmer, you wouldn't have such a hard time understanding types and getting the compiler to accept your program. I cannot imagine a worse programmer than one who willfully rejects a tool which improves a codebase to great extent. Typed languages are strictly more powerful, and you cannot get the same code guarantees from a dynamic language.