Quote: Original post by Pxtl
I'd like to see a modern, static-typed language
Haskell?
Why weakly typed?
133
July 06, 2004 10:37 AM
Haskell?
254
July 06, 2004 01:11 PM
Quote: Original post by Kylotan
Testing will tend to reveal that error, and how often does that sort of problem happen in real code? I find that the static typing issue is something that is mentioned a lot by many programmers as a possible problem but which never seems to be an actual problem.
I've been bitten by this issue recently in Prolog. I was using a function that returned the maximum value in a list, but it would return 'undefined' if the list was empty. This caused a very confusing fatal error later in development as the value returned from that function (which was used far away from the original call) was always used as a number.
Unit tests and user testing would of course uncover this kind of problem, but it is much better to catch these types of errors statically if you can. Testing all the control paths of your program is difficult and usually impossible, so I don't agree that these types of static checks are not useful.
259
July 06, 2004 01:18 PM
I favor soft typing and/or unit testing to static typing. Static typing is just too damn restricting, and I've seen a lot of programmers who try to work around the limitations of static typing.
July 06, 2004 01:43 PM
Quote: Original post by seanw
I've been bitten by this issue recently in Prolog. I was using a function that returned the maximum value in a list, but it would return 'undefined' if the list was empty. This caused a very confusing fatal error later in development as the value returned from that function (which was used far away from the original call) was always used as a number.
Sounds like a good time to throw an exception in Python. Or a lesson on checking your return codes in other languages. Static typing wouldn't have fixed the problem, only moved it. In such a language, you would have had to return -1 or some other special integer as an error value (assuming a list of integers), and since you weren't checking the return value for validity this too would have gone unnoticed.
Quote: Testing all the control paths of your program is difficult and usually impossible, so I don't agree that these types of static checks are not useful.
Testing all control paths in isolation shouldn't be impossible. If I remember correctly, Code Complete talks about some ways of making it easier, too.
354
July 06, 2004 01:46 PM
imho, the best lesson learned here is that of self-documentation. No matter what we have an exception - whether its described by returning a pair of values, one including success, or an alternate datatype, or throwing an exception - either way, it could slip by unnoticed. The exception is the best approach though, by far, no matter how much I find them to be a pain in the ass.
In dynamic-typed languages though, self-documentation is cruicial to understanding. Because anything could go in and anything could come out, you need to know what to expect. This is why I love how Python has its docstrings so you can query while you code.
In dynamic-typed languages though, self-documentation is cruicial to understanding. Because anything could go in and anything could come out, you need to know what to expect. This is why I love how Python has its docstrings so you can query while you code.
-- Single player is masturbation.
350
July 07, 2004 12:24 AM
The best argument for static typing, in my experience, is a very simple one: Intellisense. With dynamic typing, you often have to look up or remember every function call prototype in perfect detail most of the time. This also happens when you're using a sub-par development environment, but there is really no reason why you should be using such an environment.
Never underestimate tools for boosting productivity. They make all the difference when your brain refuses to start.
ld
Never underestimate tools for boosting productivity. They make all the difference when your brain refuses to start.
ld
No Excuses
606
July 07, 2004 12:31 AM
Quote: Original post by liquiddark
The best argument for static typing, in my experience, is a very simple one: Intellisense. With dynamic typing, you often have to look up or remember every function call prototype in perfect detail most of the time. This also happens when you're using a sub-par development environment, but there is really no reason why you should be using such an environment.
Never underestimate tools for boosting productivity. They make all the difference when your brain refuses to start.
ld
Why couldn't an IDE for a dynamically typed language hover the function signature (with parameter names, which you should make descriptive in any case) based on function name in a dynamically typed language? In fact, the IDLE editor for Python does just that.
122
July 07, 2004 12:37 AM
Fruny's example will compile. The string is compiled to a pointer to a compiler-generated char array. You can perform arithmetic on pointers, so what you will get is an extra character of gibberish before "hello" (unless the byte before the 'h' is the null character by coincidence).
This is why I like C++ more than C#-- it does what you expect even in odd circumstances.
This is why I like C++ more than C#-- it does what you expect even in odd circumstances.
Brian J
968
July 07, 2004 12:38 AM
Quote: Original post by Miserable
Why couldn't an IDE for a dynamically typed language hover the function signature (with parameter names, which you should make descriptive in any case) based on function name in a dynamically typed language?
It's rather hard to infer the exact type of a variable without actually running the code. IE; you are writing a method:
def Foo( bar ): bar. # What's the editor to do here?The method could be called with bar being any type. There just isn't a way to reliably deduce which methods to pop up at this point.
--AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.[Project site] [IRC channel] [Blog]
462
July 07, 2004 12:45 AM
Quote: Original post by MateiQuote: Original post by Fruny
Actually, you can!
*** Source Snippet Removed ***
That snippet won't compile I think, since string doesn't support the '-' operator. But anyway, everyone else seems to be comfortable with dynamic typing, so it probably doesn't lead to as many errors as it seems it might. I'll just go with it. Thanks for your explanations everybody.
Yeah it will, with T == char*. Ofcourse, the result of printing the cstring at x - 1 will be undefined.
Anyway, I feel typing needs to be extremely strong or extremely soft to work, there is no in between for me.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
