Quote: Original post by Pxtl
I'd like to see a modern, static-typed language
Haskell?
🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Why weakly typed?
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.
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.
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.
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.
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
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.
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.
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.
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
