Fed-up with strongly typing
-
The C# compiler, and any other compiler for a strongly- and statically-typed language, certainly will check the data type of variables through every possible code path. It may not know the value of a variable at a particular point or evaluate all possible paths through the code (that is impossible for anything which takes external input, after all), but it can check the type, and if you make a type related mistake anywhere in your code, it will be caught.
BobJanova wrote:
The C# compiler, and any other compiler for a strongly- and statically-typed language, certainly will check the data type of variables through every possible code path
Neither C# or any other compiler in that category will check dynamically loaded code paths. Where as unit testing would check that.
-
Guirec Le Bars wrote:
you have to type
I often hear complaints about how much typing someone has to do. If you don't like typing, you shouldn't be a programmer. As to dynamic typing, while it's cool and fun, in the long run, the number of problems that I've had to fix that simply wouldn't be there in a strongly typed language all but eliminates for me the benefits. Not to mention that I wouldn't write anything that requires performance in a dynamic language, as these usually cannot be compiled into native assembly code but are either interpreted or are run in a VM. So I'll say it again, but this time metaphorically: If you don't like typing, you shouldn't be a programmer. Marc
Testers Wanted!
Latest Article: User Authentication on Ruby on Rails - the definitive how to
My Blog -
Chris Maunder wrote:
it means an awful lot of referring to external documentation or external code
1. it looks like an interesting feature to have devs reading some documentation 2. they will read it once or twice and then they will remember. At that point in time you will end-up with "the code simple, elegant and fast to write as well as robust to changes". Isn't it the point?
Seulement, dans certains cas, n'est-ce pas, on n'entend guère que ce qu'on désire entendre et ce qui vous arrange le mieux... [^] Joe never complained of anything but ever did his duty in his way of life, with a strong hand, a quiet tongue, and a gentle heart [^]
Guirec Le Bars wrote:
At that point in time you will end-up with "the code simple, elegant and fast to write as well as robust to changes".
You must either program by yourself or work with a very extraordinary group of programmers and an extraordinary company. The rest of us must work in the real world where the average programmer, by definition, is average. And some are below average. Thus over time larger systems are neither "robust" nor "elegant". And that even presumes that the business requirements and delivery times allowed for that in the first place.
Guirec Le Bars wrote:
Isn't it the point?
Might be the intent but that isn't what happens. What happens over time is that there is little to no documentation. One must look to the code to find out what is going on and one must often delve through multiple layers to understand it. Which becomes even more true when someone, previously, decided that some generic, meta data, multi-layered solution was appropriate to solve what would have been a trivially simple bit of code.
-
Great. The compiler help me in making sure I don't mix-up class Person with class Country or int with Toto. Awesome... Do you really need a compiler for this? I mean, can't you just concentrate when writing code? Or adopt Hungarian Apps style which is definitely every programmer's friend? Anyway you are not answering the vey valid point of Freak30
Freak30 wrote:
And what if the proficient programmer misses one of the code paths during his tests
Answer: I don't know! But I am sure that csc does not help in any way for that! The .net platform gives too many facilities which make the posiible code paths just too numerous (infinite? at least overflowing...)
Seulement, dans certains cas, n'est-ce pas, on n'entend guère que ce qu'on désire entendre et ce qui vous arrange le mieux... [^] Joe never complained of anything but ever did his duty in his way of life, with a strong hand, a quiet tongue, and a gentle heart [^]
-
Marc Clifton wrote:
If you don't like typing, you shouldn't be a programmer.
Or write code that writes code for you.
jschell wrote:
Or write code that writes code for you.
Quite so. I haven't needed to write a line of SQL in a while now. :) Marc
Testers Wanted!
Latest Article: User Authentication on Ruby on Rails - the definitive how to
My Blog -
Freak30 wrote:
The compiler will surely check them all.
I want one of these! Please let me know which compiler as you are using. A compiler which checks all code path is priceless!
Seulement, dans certains cas, n'est-ce pas, on n'entend guère que ce qu'on désire entendre et ce qui vous arrange le mieux... [^] Joe never complained of anything but ever did his duty in his way of life, with a strong hand, a quiet tongue, and a gentle heart [^]
Compilers already check all paths because they have to. The 'art' of writing good code or being a proficient programmer is to write code such that the compiler can perform the checks itself. You essentially move what can be checked at runtime into something that is checked at compile time. This is what a strongly typed language will allow you to do. This requires more thought and effort from the programmer, which discourages them, as well as the fact that the majority of programmers don't understand this.
-
Strongly typing has one big advantage: it will force you to grow from a jerk to a proficient programmer. Yes, many programmers never get proficient but then strongly typing is not the cause :-) But here we are: when you are proficient in your domain of expertise (eg: embedded, gaming, LOB apps, multi-million users websites or whatever is your mod) then strongly typing is just a pain... It only multiplies by X (I am curious here... anyone? ) the number of reserved keywords you have to type to get to an equivalent result that you would get with a dynamic language. What do you guys think?
Seulement, dans certains cas, n'est-ce pas, on n'entend guère que ce qu'on désire entendre et ce qui vous arrange le mieux... [^] Joe never complained of anything but ever did his duty in his way of life, with a strong hand, a quiet tongue, and a gentle heart [^]
[quote]But here we are: when you are proficient in your domain of expertise (eg: embedded, gaming, LOB apps, multi-million users websites or whatever is your mod) then strongly typing is just a pain... [/quote] Are you talking about yourself only? I don't always program multi-million users websites, but when I do, I use strongly typed languages.
-
Strongly typing has one big advantage: it will force you to grow from a jerk to a proficient programmer. Yes, many programmers never get proficient but then strongly typing is not the cause :-) But here we are: when you are proficient in your domain of expertise (eg: embedded, gaming, LOB apps, multi-million users websites or whatever is your mod) then strongly typing is just a pain... It only multiplies by X (I am curious here... anyone? ) the number of reserved keywords you have to type to get to an equivalent result that you would get with a dynamic language. What do you guys think?
Seulement, dans certains cas, n'est-ce pas, on n'entend guère que ce qu'on désire entendre et ce qui vous arrange le mieux... [^] Joe never complained of anything but ever did his duty in his way of life, with a strong hand, a quiet tongue, and a gentle heart [^]
IMO, if you can't handle strong typing, then you weren't completely sure what you were doing in the first place. Disabling strong typing, or using languages that don't feature it, are for the lazy in spirit and mind. Strong typing catches many simple, dumb little problems that can really bite you at runtime, when you may have already shipped the product. You can afford the compiler yelling at you for 5 seconds much more than you can afford a support call + an emergency patch.
-
that is definitely not the case. but a proficient programmer is anyway testing is code and just don't rely on compilation, right?
Seulement, dans certains cas, n'est-ce pas, on n'entend guère que ce qu'on désire entendre et ce qui vous arrange le mieux... [^] Joe never complained of anything but ever did his duty in his way of life, with a strong hand, a quiet tongue, and a gentle heart [^]
In a strongly typed language, I don't have to write tests that check type safety. In a weakly typed language I do. Strongly typed languages let me focus on the domain and mostly ignore the types because I know the compiler (and more recently the IDE and plug-ins) will flag any issues. Weakly typed languages force me to pay attention to the plumbing more, leaving less energy for the more important things.
-
Strongly typing has one big advantage: it will force you to grow from a jerk to a proficient programmer. Yes, many programmers never get proficient but then strongly typing is not the cause :-) But here we are: when you are proficient in your domain of expertise (eg: embedded, gaming, LOB apps, multi-million users websites or whatever is your mod) then strongly typing is just a pain... It only multiplies by X (I am curious here... anyone? ) the number of reserved keywords you have to type to get to an equivalent result that you would get with a dynamic language. What do you guys think?
Seulement, dans certains cas, n'est-ce pas, on n'entend guère que ce qu'on désire entendre et ce qui vous arrange le mieux... [^] Joe never complained of anything but ever did his duty in his way of life, with a strong hand, a quiet tongue, and a gentle heart [^]
Strong typing is better down the road, with it the compiler catches many "dumb" errors that will pass unmarked otherwise (for example undeclared variables, type mismatch, redeclared of variables, etc.). If you want to put it like this it gives me peace of mind that my solution will not blow up at runtime with some obscure and untraceable bug caused by a redefined variable somewhere in a function.
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
Strongly typing has one big advantage: it will force you to grow from a jerk to a proficient programmer. Yes, many programmers never get proficient but then strongly typing is not the cause :-) But here we are: when you are proficient in your domain of expertise (eg: embedded, gaming, LOB apps, multi-million users websites or whatever is your mod) then strongly typing is just a pain... It only multiplies by X (I am curious here... anyone? ) the number of reserved keywords you have to type to get to an equivalent result that you would get with a dynamic language. What do you guys think?
Seulement, dans certains cas, n'est-ce pas, on n'entend guère que ce qu'on désire entendre et ce qui vous arrange le mieux... [^] Joe never complained of anything but ever did his duty in his way of life, with a strong hand, a quiet tongue, and a gentle heart [^]
I use them both. When it matters, I use a typed language, when it doesn't I use untyped. It would drive me crazy if shell/batch scripting was strongly typed. It would also drive me crazy if highly complex programs were untyped. I developed programs in BCPL for body scanners two years. BCPL has only one type: a word. There were times when I really wished it was typeless.
-
Compilers already check all paths because they have to. The 'art' of writing good code or being a proficient programmer is to write code such that the compiler can perform the checks itself. You essentially move what can be checked at runtime into something that is checked at compile time. This is what a strongly typed language will allow you to do. This requires more thought and effort from the programmer, which discourages them, as well as the fact that the majority of programmers don't understand this.
Actually, not even that. Templated code is not compiled unless instantiated. Conditionally compiled code is not looked at by the compiler unless the argument to #ifdef is true. I've been looking at some of my regression tests using the gcov tool. The number of lines marked ### is bad enough, but all of those lines marked --- (not reachable) is even worse (if you're writing a library, that is). Incidently, a question for the dynamic typing guys, particularly Javascript - is there an equivalent code coverage tool for testing the coverage of a jsunit suite of tests?
-
Strongly typing has one big advantage: it will force you to grow from a jerk to a proficient programmer. Yes, many programmers never get proficient but then strongly typing is not the cause :-) But here we are: when you are proficient in your domain of expertise (eg: embedded, gaming, LOB apps, multi-million users websites or whatever is your mod) then strongly typing is just a pain... It only multiplies by X (I am curious here... anyone? ) the number of reserved keywords you have to type to get to an equivalent result that you would get with a dynamic language. What do you guys think?
Seulement, dans certains cas, n'est-ce pas, on n'entend guère que ce qu'on désire entendre et ce qui vous arrange le mieux... [^] Joe never complained of anything but ever did his duty in his way of life, with a strong hand, a quiet tongue, and a gentle heart [^]
I actually find myself in 2 minds about this. But it's not that I think strong vs weak is bad/good, or even that statick vs dynamic is good/bad. It's a case of most programmers misunderstanding the concepts. Usually I hear stuff like strong-static and weak-dynamic, in fact the opposite is mostly true in nearly all languages, i.e. you tend to find strong-dynamic languages and weak-static languages much more than the other ways round. Actually, most languages are not perfectly strong, perfectly weak, perfectly static nor even perfectly dynamic ... note "most". More usually you'd find something like a language which is mostly statically typed, but allows for automatic coercion when such is needed (e.g. adding a double and a long does not require an explicit type cast in nearly any language). Then also some strong-dynamic languages might assert interaction between different variable types, e.g. raising an exception / compile error when adding a string to an int. To define what's actually happening:
- Weak (the extreme case): Any variable just contains data. There's no type inherent in the language and/or compiler which defines what that data is or how it's structured. Think of this as a pointer to a position in RAM without any further data about what is contained in RAM. Sample of this is C, where all variables are in fact simply containing byte arrays. There's no structure to the variable which defines what that variable's type is.
- Strong (the extreme case): All variables are created as a record (or more usually an object) with some form of type descriptor. Followed by the data, which might then simply be a byte array or even just a pointer. See this as an Object with constructors and methods which check to see that only the correct types of data interact with it. A sample of this is Lisp, where each symbol (variable) contains a description of the type of data contained inside it.
- Static (the extreme case): All variables will only hold the type which they are defined to hold. They may not be assigned another type. This is usually enforced at compile-time, though some languages also insert runtime assertions for this. A sample of this is C, where each variable (or rather most) are defined as containing some type. Then the compiler does type checking whenever that variable is used as input or being assigned to.
- Dynamic (the extreme case): Any variable can be assigned any type at any time. A sample of this is Lisp, whenever you assign a value to
-
BobJanova wrote:
The C# compiler, and any other compiler for a strongly- and statically-typed language, certainly will check the data type of variables through every possible code path
Neither C# or any other compiler in that category will check dynamically loaded code paths. Where as unit testing would check that.
Unit testing will check the set of code paths that you write the tests to exercise. Fine if you're testing small methods, with only a few possible code paths or edge cases. Then you need to test interactions between your classes, each of which has a dozen methods with 2-5 paths each. Suddenly you have tens of thousands of tests, most of which differ in very small ways. A strong type system enables invariants to be proven efficiently, regardless of the number of possible paths through the code, because it does not need to rely on executing every possible path. A type system is not a replacement for unit tests, and unit tests are not a replacement for a type system.