Tag Info

Hot answers tagged

88

From a practical point of view I see these problems: A bloat of possible run type errors -- unless a lot of dynamic type checking which could be avoided with the Java included strong type checker. A lot of unnecessary casts Difficulty understanding what a method does by its signature From a theoretical point of view I see these problems: A lack of ...


86

The method violates the Liskov substitution principle. If a method accepts a parameter of type Object, I should expect that any object I pass to the method will work. What it sounds like is that only certain subclasses of Object are allowed. The only way to know which types are allowed is to know the details of the method. In other words, the method is ...


74

Type systems prevent errors Type systems eliminates illegal programs. Consider the following Python code. a = 'foo' b = True c = a / b In Python, this program fails; it throws an exception. In a language like Java, C#, Haskell, whatever, this isn't even a legal program. You entirely avoid these errors because they simply aren't possible in the set of ...


65

It's sort of a myth that programmers don't have to worry about types in dynamically typed languages. In dynamically typed languages: You still have to know if you're working with an array, an integer, a string, a hash table, a function reference, a dictionary, an object, or whatever. If it's an object, you have to know what class it belongs to. ...


62

As the types get stronger, they can help you more — if you use them correctly instead of fighting them. Design your types to reflect your problem space and logic errors are more likely to become compile-time type mismatches instead of runtime crashes or nonsense results.


48

I'd consider the following direct implications: Readability I guess working with him is not exactly the most pleasant experience in the world. You never know what the type is going to be in the end or what happens to the parameters. I doubt you appreciate wasting your time with that. Type Signature In Java everything is an Object. So what does that ...


44

Disclaimer: I am a type-lover ;) Your question is difficult to answer: What are those trade-offs ? I'll take an extreme example: Haskell, it is statically typed. Perhaps one of the most strongly typed languages that exist, in fact. However, Haskell supports Generic Programming, it the sense that you write methods that work with any type conforming to a ...


25

The problem with this kind of discussion is simply that the terms "weak typing" and "strong typing" are undefined, unlike for example the terms "static typing", "dynamic typing", "explicit typing", "implicit typing", "duck typing", "structural typing" or "nominal typing". Heck, even the terms "manifest typing" and "latent typing", which are still open areas ...


24

Yes, definitely. Functions/methods that take too many arguments is a code smell, and indicates at least one of the following: The function/method is doing too many things at once The function/method requires access to that many things because it's asking, not telling or violating some OO design law The arguments are actually closely related If the last ...


22

It takes away the type checking that the compiler does and can lead to more runtime exceptions when the object is cast to the concrete type. Thus, the end-user will see the unhandled exception, unless the invalid casts are all caught and properly handled.


22

No, you should not feel uncomfortable using auto. Just use it in situations where the type is obvious, or where no one is going to care about it A classic example (IMO) of where auto is handy: std::vector<sometype> vec ... ... //some code ... ... for(auto iter = vec.begin(); iter != vec.end(); ++iter) { //something here } Nobody really cares ...


19

Personally, I find that type safety helps me develop faster in my current job. The compiler does a lot of the sanity checking for me almost as I type, allowing me to focus more on the business logic that I'm implementing. Bottom line for me is that although I lose some flexibility, I gain some time that would otherwise be spent tracking down type issues.


17

Remember there are two major concepts that are commonly confused: Dynamic typing A programming language is said to be dynamically typed when the majority of its type checking is performed at run-time as opposed to at compile-time. In dynamic typing, values have types but variables do not; that is, a variable can refer to a value of any type. The ...


15

I like both statically-typed and dynamically-typed languages. The two biggest advantages of type safety to me are: 1) You can often pretty much deduce what a function does purely from its type signature (this is particularly true in functional languages like Haskell). 2) When you do significant refactor, the compiler automatically tells you everything you ...


15

I agree with the other responses that this is generally bad practice. There is one specific case where I find passing an Object may be superior: when you are eventually dealing with Strings, e.g. if you are creating XML or JSON. In that case, instead of something like: public void addAttribute(String s) { //... add s to the XML } I prefer: public ...


15

A type system helps you avoid simple coding errors, or rather allows the compiler catch those errors for you. For example, in JavaScript and Python, the following problem will often only be caught at runtime - and depending on testing quality/rarity of the condition may actually make it to production: if (someRareCondition) a = 1 else a = {1, 2, ...


15

These are phantom type parameters, that is, parameters of a parameterised type that are used not for their representation, but to separate different “spaces” of types with the same representation. And speaking of spaces, that’s a useful application of phantom types: template<typename Space> struct Point { double x, y; }; struct WorldSpace; struct ...


11

Reality itself is typed. You can't add lengths to weights. And while you can add feets to meters (both are units of lengths), you should scale at least one of the two. Failing to do so can crash your Mars mission, quite literally. In a typesafe system, adding two lengths expressed in different units would have been either an error or would have caused an ...


9

So first of all, what actually is safety? protection against data corruption, or > hackers, or system malfunctions, etc? Type safety is a property of a program brought by a sound type system and informed by a respective type checker (usually performed by a compiler). In very few words, a type safe program can be defined as one that, when executed, is ...


8

When you're maintaining code where every function takes an array blob of data written by someone who didn't believe in documentation, you'll know why.


7

Is type safety worth the hit to speed of development and flexibility? So really this comes down to what you are doing. If you are programming say, the backup systems for airplanes, type safety is probably the way to go. Dynamic language vs Static language programming are really two different animals. They both require a fundamentally different ...


6

Disclaimer: I prefer C to C++ Instead of classes, I would use structs. This point is pedantic at best, since structs and classes are nearly identical (see here for a simple chart, or this SO question), but I think there is merit in the differentiation. C programmers are familiar with structs as blocks of data that have some greater meaning when grouped, ...


6

Type safety is not a black-or-white type-safe or not. It's more of a spectrum and some languages can be more type safe than others (and vice versa). However, I think what you're thinking of with C# vs. Javascript is likely static typing (where type-checking happens at compile-time) vs. dynamic typing (where type-checking happens at run-time) -- certainly, ...


6

Being flexible and able to handle multiple types of data is exactly what method overloading and interfaces were created for. Java already has the features that make handling these situations simpler while guarenteeing compile time safety via type checking. Also, if it is impossible to narrowly define what data the method operates on, then that method may ...


5

Speed of development and flexibility is relative. Skilled developers can avoid the pitfalls either way. Working quickly can catch up with you if you're not careful. Many have mentioned project complexity. Sorry, can't specify the cut-off from simple to complex projects, but know it when they kick you in the pants. An uneducated child can learn their native ...


5

The main argument for weak typing is one of performance. (this is to answer the OPs question as stated). There's a lot of good discussion about dynamic vs. static, implicit vs. explicit. etc. C is the most famous weakly typed language, and it does not perform any run time checking or compile time checking of the variables type. In essence you can cast a ...


5

yes. java is supposed to be strictly typecasted . But having Object as parameter will virtually break this rule. Moreover, it will make your program more bug prone. And that's the one of the top reasons, why generics were introduced.


5

The earlier in the software development cycle you can catch an error, the less expensive it is to fix. Consider an error that causes your biggest client, or all your clients to lose data. Such an error could be the end of your company if it is only caught after real customers have lost data! It is clearly less expensive to find and fix this bug before ...


5

You are still getting strong types even if they aren't explicitly specified. You're going to eventually hit a static type mismatch in most circumstances. The main concern with type inference is accidentally inferring a type too concrete or abstract. In other words, inferring a derived type when you really needed the base type, or vice versa. If it ...



Only top voted, non community-wiki answers of a minimum length are eligible