Tag Info

Hot answers tagged

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 ...


50

("Java", as used here, is defined as standard Java SE 7; "Haskell", as used here, is defined as standard Haskell 2010.) Things that Java's type system has but that Haskell's doesn't: nominal subtype polymorphism partial runtime type information Things that Haskell's type system has but that Java's doesn't: bounded ad-hoc polymorphism gives rise to ...


41

That quote points to a problem that occurs if the declaration and assignment of identifiers (here: instance members) are separate from each other. As a quick pseudocode sketch: class Broken { val foo: Foo // where Foo and Bar are non-nullable reference types val bar: Bar Broken() { foo = new Foo() throw new Exception() ...


35

I believe that understanding Haskell's type system is an amplifier to understanding functional programming. The thing about purely functional programming is that in the absence of side-effects, which allow you to do all sorts of things implicitly, purely functional programming makes the structure of your programs much more explicit. Haskell prevents you ...


35

Let's take a look at Java. Java can't have variables with inferred types. This means I frequently have to spell out the type, even if it is perfectly obvious to a human reader what the type is: int x = 42; // yes I see it's an int, because it's a bloody integer literal! // Why the hell do I have to spell the name twice? ...


33

Yes, I believe that they do. There are a few reasons that need to be considered in the selection of a language for a new project: Run-time speed. Compared to C/C++/Fortran, Perl and Python are so slow it's funny. Initialization speed. Compared to the above fast languages, Java falls over and cries as the JVM keeps loading and loading and...while(1).... ...


33

"Never" is the canonical answer to "when is type testing okay?" There's no way to prove or disprove this; it is part of a system of beliefs about what makes "good design" or "good object-oriented design." It's also hokum. To be sure, if you have an integrated set of classes and also more than one or two functions that need that kind of direct type testing, ...


32

The most dynamically typed functional language is arguably Scheme. That said, Haskell's type system is an indicator of its purity. It's a question of "how does one measure purity?". Haskell's type system lets you easily cordon off impure actions in IO. To do that, you need a static type system. But let's say Haskell's type system has nothing to do with ...


32

Almost every word you might think of adding as a keyword to a language has almost certainly been used as a variable name or some other part of working code. This code would be broken if you made that word a keyword. The incredibly lucky thing about auto is that it already was a keyword, so people didn't have variables with that name, but nobody used it, ...


32

Technically speaking, Java does have type inferencing when using generics. With a generic method like public <T> T foo(T t) { return t; } The compiler will analyze and understand that when you write // String foo("bar"); // Integer foo(new Integer(42)); A String is going to be returned for the first call and an Integer for the second call based ...


32

The use of subtypes creates a lot of complications when doing generic programming. If you insist on using a language with subtypes, you have to accept there's a certain inherent complexity in generic programming that comes along with it. Some languages do it better than others, but you can only take it so far. Contrast that with Haskell's generics, for ...


27

Some suggested reading: Developers Shift to Dynamic Languages (PDF) On the Revival of Dynamic Languages (PDF) Static typing where possible, dynamic typing when needed: The end of the cold war between programming languages (PDF) The Security of Static Typing with Dynamic Linking (PDF) Combining Static and Dynamic Reasoning for Bug Detection (PDF) Dynamic ...


26

There's a fair bit of incorrect information in ratchet freak's answer and in its comment thread. I'll respond here in an answer, since a comment is too small. Also, since this an answer after all, I'll attempt to answer the original question too. (Note however that I am not an expert on type systems.) First, the short answers to the original question are ...


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 ...


25

Java's type system lacks higher kinded polymorphism; Haskell's type system has it. In other words: in Java, type constructors can abstract over types, but not over type constructors, whereas in Haskell, type constructors can abstract over type constructors as well as types. In English: in Java a generic can't take in another generic type and parameterize ...


25

A strong type system is a type system that has a compile-time restriction or run-time feature that you find attractive. A weak type system is a type system which lacks that restriction or feature. Seriously, that's it. You read the Wikipedia page, so you know that there are at least eleven different mutually incompatible meanings of "strongly typed". The ...


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

The main situation I've ever needed it was when comparing two objects, such as in an equals(other) method, which might require different algorithms depending on the exact type of other. Even then, it's fairly rare. The other situation I've had it come up, again very rarely, is after deserialization or parsing, where you sometimes need it to safely cast to ...


21

I mostly agree with you, but for fun I'll play Devil's Advocate. Explicit interfaces give a single place to look for an explicitly, formally specified contract, telling you what a type is supposed to do. This can be important when you're not the only developer on a project. Furthermore, these explicit interfaces can be implemented more efficiently than ...


20

You're giving way too much technical credit to Enterprise decision makers. There is an old saying, "Nobody got fired for buying IBM." If you go a different route and things get rocky (they always do), nobody wants to risk being blamed. Stick to the standards and blame someone else. There are a lot of younger companies that will eventually become the ...


20

Inheritance and polymorphism are widely used because they work, for certain kinds of programming problems. It's not that they're widely taught in schools, that's backwards: they're widely taught in schools because people (aka the market) found that they worked better than the old tools, and so schools began teaching them. [Anecdote: when I was first ...


19

While Generics have been mainstream in the functional programming community for decades, adding generics to object oriented programming languages offers some unique challenges, specifically the interaction of subtyping and generics. However, even if we focus on object oriented programming languages, and Java in particular, a far better generics system could ...


18

I would say "Yes". As you say, the purpose of Hungarian Notation is to encode information in the name that cannot be encoded in the type. However, there are basically two cases: That information is important. That information is not important. Let's start with case 2 first: if that information is not important, then Hungarian Notation is simply ...


17

In a weakly-typed language, type-casting exists to remove ambiguity in typed operations, when otherwise the compiler/interpreter would use order or other rules to make an assumption of which operation to use. Normally I would say PHP follows this pattern, but of the cases I've checked, PHP has behaved counter-intuitively in each. Here are those cases, ...


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 ...


17

In a dynamically typed system, values have types at runtime but variables and functions do not. In a statically typed system, variables and functions have types known and checked at compile-time. E.g. in Python x can be anything; at runtime, if it is 1 it's a number and if it is "foo", it's a string. You would only know which type x was at runtime, and it ...


17

It's true that code is read far more often than it is written. However, reading also takes time, and two screens of code are harder to navigate and read than one screen of code, so we need to prioritize to pack the best useful-information/reading-effort ratio. This is a general UX principle: Too much information at once overwhelms and actually degrades the ...


16

I'm curious what would be the most purely functional language that is dynamically typed. Erlang probably. In Erlang all variables are immutable and there are no mutable data structures other than the process dictionary. You can still do IO whenever you want and message passing isn't referentially transparent either, so it's not entirely pure. But it's ...


16

I vote for C. It's vastly simpler than C++, and it clearly shows what's happening under the hood, because it doesn't have any hood! :-)


16

Use C++, do not use any embedded/layered anything. I am going to answer the question in the negative, and tell you to use C++, hire appropriate resources, and do not layer something else on top. Most of your criteria already fit C++ anyways: strong typing, minimal runtime, etc. (Typing not as strong as Haskell, but better than most scripting languages) ...



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