Heavily typed
-
From Stephan Grieger ...
I had a conversation with my manager here who fancies himself a bit of a programmer.
Me: What you have to remember is that C# is heavily typed.
Him: Does that mean you need to hit the keys harder?
Me: ...
-
Heavily typed? Is that a synonym for strongly typed? If not, links to definition, please!
-
@Alex Papadimoulis said:
From Stephan Grieger ...
I had a conversation with my manager here who fancies himself a bit of a programmer.
Me: What you have to remember is that C# is heavily typed.
Him: Does that mean you need to hit the keys harder?
Me: ...I must say that I never ever heard about "heavy typing".
I know about static/dynamic, explicit/implicit, strong/weak (and these 3 fields are orthogonal) but not about heavy typing (as far as I know C# is statically explicitly [somewhat] strongly typed, but C# 3.0 adds inferred implicit typing in some situations, the advantages of such a thing being debatable).
Could you explain what it would be exactly?
-
I assume that it means C# is more laden with type messages than other strongly typed languages. For example, converting foo to bar, where bar needs type a:
b bar = (b) foo
compared to the pure functional language of your choice:
bar = b foo
These redundant type messages carry weight, and the longer a program is, the more needless mass there is, so C# is 'heavily' typed, compared to 'lightly' typed languages (Haskell, OCaml, etc), or 'featherweight' typed languages (scripting languages - no type declarations at all!).
-
@masklinn said:
C# 3.0 adds inferred implicit typing in some situations, the advantages of such a thing being debatable).
Debatable? Can you give an example of a situation where it's anything but an advantage to be able to write
var myObjectContainer = new MyContainer<MyObject>;
instead of the redundant and less readable status quo,
MyContainer<MyObject> myObjectContainer = new MyContainer<MyObject>;
I honestly don't see any scope for "debate"... it's good, period. It makes code easier to read and easier to write, without affecting semantics or performance in any way whatsoever. And it doesn't even decrease the LOC count, so your PHB won't realise you're having to do less typing!
-
@Iago
I see that 'side-effect' as a subjective advantage. Personally, I find the "status quo",
MyContainer<MyObject> myObjectContainer = new MyContainer<MyObject>;
To be just as readable, if not more so. A possible disadvantage would be someone coming in behind the original programmer, unfamiliar with C# 3.0 and it's 'var' and making the assumption that it is an object or variant. I actually did the same thing until I gave the C# designers the benefit of the doubt and did a search for it. In any case, its real purpose appears to be allowing for anonymous typing "Does that mean you have random people on the Internet hit the keys for you??" :)
-
@Iago said:
@masklinn said:
C# 3.0 adds inferred implicit typing in some situations, the advantages of such a thing being debatable).
Debatable? Can you give an example of a situation where it's anything but an advantage to be able to write
var myObjectContainer = new MyContainer<myobject>;</myobject>
instead of the redundant and less readable status quo,
MyContainer<myobject> myObjectContainer = new MyContainer<myobject>;</myobject></myobject>
I honestly don't see any scope for "debate"... it's good, period. It makes code easier to read and easier to write, without affecting semantics or performance in any way whatsoever. And it doesn't even decrease the LOC count, so your PHB won't realise you're having to do less typing!
The debatable part isn't the fact that they introduce type inference (i like type inference), it's that it yields an hybrid of explicit and implicit typing that makes me quite afraid.
And var is a stupid declaration keyword, too, it has strong weak typing connotations, let would have been a much better keyword in my opinion.
-
Type inference makes it annoying to track down the source of a type error. If you do
A x = func_returning_B(); a explicitly typed language can see the error
right there, but an implicitly typed language will assume that x was
supposed to be a B and the error will appear to be later in the code
when x is used in the manner befitting an A, so to fix it you first
have to go up and find x's initialization.
-
@bonfyre said:
@El Foo said:
These redundant type messages carry weight, and the longer a program is, the more needless mass there is, so C# is 'heavily' typed, compared to 'lightly' typed languages (Haskell, OCaml, etc), or 'featherweight' typed languages (scripting languages - no type declarations at all!).
errr.... OCaml is strongly typed.
I think his point was that languages like *ML and Haskell have less need for explicit typing because they use type inference heavily. Java and C#, on the other hand, need lots of information which should be obvious from context.
So while Haskell and OCaml are strongly typed they are not heavily typed (for this new definition of 'heavy typing').
This is my first post on TDWTF, so I shall now perform a small prayer and hope not to look like an idiot when I hit post :-)
-
@Goplat said:
Type inference makes it annoying to track down the source of a type error. If you do
A x = func_returning_B(); a explicitly typed language can see the error
right there, but an implicitly typed language will assume that x was
supposed to be a B and the error will appear to be later in the code
when x is used in the manner befitting an A, so to fix it you first
have to go up and find x's initialization.
I don't see how type inference is inferior here. If I have two functions f and g whose types don't agree, like the following
f x = x + 5
g x = x ++ "!"
then it's fairly apparent that g . f will choke, since f returns an integer and g expects a string. Any type inference system should identify the disparity between what f implies about g, and what g implies about f.
-
I have seen the term "heavy typing" used in Python circles to indicate strong and statically typed languages like C# and Java. This is to differentiate them from, say, Python, which is "nimbly typed", in that it is strongly, but dynamically, typed.
This is not a very widespread way of referring to typing, however, so I'd have to say that the real WTF is Stephan Grieger used "heavily typed". His boss was probably being sarcastic with his reply. Some people think they're so l33t. [|-)]
-
@El Foo said:
I assume that it means C# is more laden with type
messages than other strongly typed languages. For example, converting
foo to bar, where bar needs type a:
b bar = (b) foo
compared to the pure functional language of your choice:
bar = b foo
These
redundant type messages carry weight, and the longer a program is, the
more needless mass there is, so C# is 'heavily' typed, compared to
'lightly' typed languages (Haskell, OCaml, etc), or 'featherweight'
typed languages (scripting languages - no type declarations at all!).
No, that isn't it. That requirement for explicit conversion is a sign
of "strong" typing. Pay close attention: C++ is weakly typed. It's
just also very statically typed. Python offers strong, dynamic typing,
for comparison. Many people falsely associate weak typing with dynamic
and strong with static, but they are actually pretty much orthogonal.
I do think "heavy typing" makes sense as a term; I think of it as
referring to the complexity of the type system and the kinds of options
you have for expressing types. So for example C++ has very "heavy"
typing, because there are both user-defined types and parametric
polymorphism (templates) on both integer values and other types;
whereas Perl 4 (pre-OO stuff and references) is about as "light" as
typing can get, since there are really only three types - scalar, array
and hash. (Whether you consider it static or dynamic, or weak or
strong, is actually not very clear. If you're strict about the
interpretation of those as the only types, then it's static for
example; but it's dynamic if you consider automatic interpretation of a
string that "happens" to represent a number, as a number, to be a "type
conversion".)
