4 ms·

By that logic, most object oriented languages like Java, C# and C++ are fundamentally flawed as calling a method only works most of the time. Besides, code in

by Skinney 11y ago

By that logic, most object oriented languages like Java, C# and C++ are fundamentally flawed as calling a method only works most of the time. Besides, code in general only work most of the time. Static typing does not protect you from bugs.

the_af 11y ago
> Static typing does not protect you from bugs. But it does. It doesn't protect you from all bugs, but nobody claimed it did.
- Skinney 11y ago
  True, should have specified what I meant. The thing is, static typing doesn't necessarily protect you from more bugs than a dynamic language. For instance, Clojure is less prone to NPEs because you don't call methods on objects, and because a lot of your program manipulates datastructures, and nil is treated as an empty datastructure. Of course, a language like Rust, which doesn't have null, does protect against NPEs. It's all relative.
  - Skinney 11y ago
    Reading this again make me realize that I'm wrong. Static typing will safeguard you against certain types of bugs that a dynamic language don't. The point I was trying to make was that a static language doesn't necessarily protect you against a certain type of bug, which you may rarely experience in a dynamic language.
JadeNB 11y ago
I didn't call anything flawed, fundamentally or otherwise; but I take your point. I think that there is an important distinction between 'almost-there' solutions. Suppose that you have a piece of code that is specified to work in a certain way. Because code, and the hardware on which it runs, is made (at least indirectly) by humans, it will fail under some conditions; it only satisfies its specification. I think that we are all comfortable with this kind of "works most of the time". By contrast, consider 'smart' products—for example, the auto-complete on your phone. This also, after a bit of training, works most of the time, and can make some brilliant inferences. However, I think that most people can agree that the "most of the time" for auto-completion is qualitatively different from the "most of the time" for specified software: it is reasonable to rely on the latter, but not, or at least not nearly as much, on the former (http://www.damnyouautocorrect.com http://www.damnyouautocorrect.com).
- Skinney 11y ago
  I know you didn't, but if you have a language have a core semantic that only works "most of time," and "most of the time" is worse than "never," then you have a language that is worse than not having a language at all, which means that it is fundamentally flawed. Yes, I probably did enjoy my logic courses at the university too much.
- JadeNB 11y ago
  Oops, I an important word out: > Because code, and the hardware on which it runs, is made (at least indirectly) by humans, it will fail under some conditions; it only satisfies its specification. This sentence was supposed to end "it only satisfies its specification some of the time." I was not going for Knuth-ian irony about proving vs testing (https://en.wikiquote.org/wiki/Donald_Knuth#Sourced https://en.wikiquote.org/wiki/Donald_Knuth#Sourced).
outworlder 11y ago
But they are. As in, they fail to handle the null case properly.

by Skinney 11y ago

the_af 11y ago

> Static typing does not protect you from bugs. But it does. It doesn't protect you from all bugs, but nobody claimed it did.

Skinney 11y ago
True, should have specified what I meant. The thing is, static typing doesn't necessarily protect you from more bugs than a dynamic language. For instance, Clojure is less prone to NPEs because you don't call methods on objects, and because a lot of your program manipulates datastructures, and nil is treated as an empty datastructure. Of course, a language like Rust, which doesn't have null, does protect against NPEs. It's all relative.
- Skinney 11y ago
  Reading this again make me realize that I'm wrong. Static typing will safeguard you against certain types of bugs that a dynamic language don't. The point I was trying to make was that a static language doesn't necessarily protect you against a certain type of bug, which you may rarely experience in a dynamic language.

JadeNB 11y ago

I didn't call anything flawed, fundamentally or otherwise; but I take your point. I think that there is an important distinction between 'almost-there' solutions. Suppose that you have a piece of code that is specified to work in a certain way. Because code, and the hardware on which it runs, is made (at least indirectly) by humans, it will fail under some conditions; it only satisfies its specification. I think that we are all comfortable with this kind of "works most of the time". By contrast, consider 'smart' products—for example, the auto-complete on your phone. This also, after a bit of training, works most of the time, and can make some brilliant inferences. However, I think that most people can agree that the "most of the time" for auto-completion is qualitatively different from the "most of the time" for specified software: it is reasonable to rely on the latter, but not, or at least not nearly as much, on the former (http://www.damnyouautocorrect.com http://www.damnyouautocorrect.com).

Skinney 11y ago
I know you didn't, but if you have a language have a core semantic that only works "most of time," and "most of the time" is worse than "never," then you have a language that is worse than not having a language at all, which means that it is fundamentally flawed. Yes, I probably did enjoy my logic courses at the university too much.
JadeNB 11y ago
Oops, I an important word out: > Because code, and the hardware on which it runs, is made (at least indirectly) by humans, it will fail under some conditions; it only satisfies its specification. This sentence was supposed to end "it only satisfies its specification some of the time." I was not going for Knuth-ian irony about proving vs testing (https://en.wikiquote.org/wiki/Donald_Knuth#Sourced https://en.wikiquote.org/wiki/Donald_Knuth#Sourced).

outworlder 11y ago

But they are. As in, they fail to handle the null case properly.