4 ms·

> Sure. And if you think the the difference in developer efficiency between a dynamic language and a static one is less than 10%, but when the gains are small,

> Sure. And if you think the the difference in developer efficiency between a dynamic language and a static one is less than 10%, but when the gains are small, as has been shown in the linked article, then why pay the cost of possible program failure for a less than 10% gain in string concatenation speed when you probably won't event see it? I actually think that dynamic languages have negative efficiency impact over long periods of time and large numbers of developers. (If that doesn't make it clear where I stand on static vs dynamic typing...) > Exceptions which can be caught are not comparable to memory corruption... I never compared exceptions to memory corruption, I compared them to crashes. I could also "catch" crashes with techniques such as watch-dog processes with very similar effects. Now if you really mean "crashes" as "program faults due to memory corruption", as opposed to "unexpectedly halting execution", then you're both using a niche definition and gave a bit of deceiving definition of "unsafe": > To be clear, what I mean here by unsafe, and everywhere I've used the word, is "can cause a crash or memory corruption"...

kbenson 10y ago
> I actually think that dynamic languages have negative efficiency impact over long periods of time and large numbers of developers. I agree, but that does leave open the possibility of them being more efficient in some circumstances. > I could also "catch" crashes with techniques such as watch-dog processes with very similar effects. Without a system for handling the crash information in such a way that you can feed it back into the restarted program to retrieve prior that and recover from it, I don't really see how they are equivalent. > Now if you really mean "crashes" as "program faults due to memory corruption", as opposed to "unexpectedly halting execution", then you're both using a niche definition and gave a bit of deceiving definition of "unsafe" I mean either, for the entire program, not some executing branch. I think "crash" is fairly unambiguously accepted as "an unrecoverable problem within the current running context causing it to halt." An exception is not a crash, it's a problem, which if unhandled can lead to a crash. Perhaps I'm in the minority in my opinion on this, but I don't think so.
- jdmichal 10y ago
  OK, now this is turning into a real tangent on exceptions vs crashes. I see little difference between an exception with no actionable programmatic resolution and a program crash. You can always retry, but the bottom line is that there's never going to be a good answer to flooring a banana. You can try to floor something else, or you can try to do an operation that's not flooring, but that particular combination isn't going to ever have a good solution. > I mean either, for the entire program, not some executing branch. That's a pretty arbitrary line to draw. The difference between one thread acting as a watch-dog for another thread, or the same situation with processes could probably be made indistinguishable with the proper setup.
  - kbenson 10y ago
    > I see little difference between an exception with no actionable programmatic resolution and a program crash. What you consider actionable and what is possibly actionable may not be the same thing. For example... > You can always retry, but the bottom line is that there's never going to be a good answer to flooring a banana. Except potentially asking the user to supply another number, if it happened to be user input. There's an example of an actionable exception to something you seem to consider having no programmatic resolution. > That's a pretty arbitrary line to draw. Not according to wikipedia. The following is under the Application Crashes subsection of Crash (Computing)[1] An application typically crashes when it performs an operation which is not allowed by the operating system. The operating system then triggers an exception or signal in the application. Unix applications traditionally responded to the signal by dumping core. Most Windows and Unix GUI applications respond by displaying a dialogue box (such as the one shown to the right) with the option to attach a debugger if one is installed. This behavior is called "crashing". Some applications attempt to recover from the error and continue running instead of crashing. Note the last sentence, which implies recovery is not crashing. But you can call bullshit on Wikipedia as source (because that's sometimes valid), I don't really care. This whole discussion has devolved to the point it's not useful to continue. You stated your preference to crash elsewhere, which I have a difference in opinion on, so I don't think any headway will be made there. We can just agree to disagree on what we think is a best default behavior for a language. 1: https://en.wikipedia.org/wiki/Crash_(computing) https://en.wikipedia.org/wiki/Crash_(computing)

kbenson 10y ago

> I actually think that dynamic languages have negative efficiency impact over long periods of time and large numbers of developers. I agree, but that does leave open the possibility of them being more efficient in some circumstances. > I could also "catch" crashes with techniques such as watch-dog processes with very similar effects. Without a system for handling the crash information in such a way that you can feed it back into the restarted program to retrieve prior that and recover from it, I don't really see how they are equivalent. > Now if you really mean "crashes" as "program faults due to memory corruption", as opposed to "unexpectedly halting execution", then you're both using a niche definition and gave a bit of deceiving definition of "unsafe" I mean either, for the entire program, not some executing branch. I think "crash" is fairly unambiguously accepted as "an unrecoverable problem within the current running context causing it to halt." An exception is not a crash, it's a problem, which if unhandled can lead to a crash. Perhaps I'm in the minority in my opinion on this, but I don't think so.

jdmichal 10y ago
OK, now this is turning into a real tangent on exceptions vs crashes. I see little difference between an exception with no actionable programmatic resolution and a program crash. You can always retry, but the bottom line is that there's never going to be a good answer to flooring a banana. You can try to floor something else, or you can try to do an operation that's not flooring, but that particular combination isn't going to ever have a good solution. > I mean either, for the entire program, not some executing branch. That's a pretty arbitrary line to draw. The difference between one thread acting as a watch-dog for another thread, or the same situation with processes could probably be made indistinguishable with the proper setup.
- kbenson 10y ago
  > I see little difference between an exception with no actionable programmatic resolution and a program crash. What you consider actionable and what is possibly actionable may not be the same thing. For example... > You can always retry, but the bottom line is that there's never going to be a good answer to flooring a banana. Except potentially asking the user to supply another number, if it happened to be user input. There's an example of an actionable exception to something you seem to consider having no programmatic resolution. > That's a pretty arbitrary line to draw. Not according to wikipedia. The following is under the Application Crashes subsection of Crash (Computing)[1] An application typically crashes when it performs an operation which is not allowed by the operating system. The operating system then triggers an exception or signal in the application. Unix applications traditionally responded to the signal by dumping core. Most Windows and Unix GUI applications respond by displaying a dialogue box (such as the one shown to the right) with the option to attach a debugger if one is installed. This behavior is called "crashing". Some applications attempt to recover from the error and continue running instead of crashing. Note the last sentence, which implies recovery is not crashing. But you can call bullshit on Wikipedia as source (because that's sometimes valid), I don't really care. This whole discussion has devolved to the point it's not useful to continue. You stated your preference to crash elsewhere, which I have a difference in opinion on, so I don't think any headway will be made there. We can just agree to disagree on what we think is a best default behavior for a language. 1: https://en.wikipedia.org/wiki/Crash_(computing) https://en.wikipedia.org/wiki/Crash_(computing)