3 ms·

Bold. :-) I do hope you're correct. (Given a modest test suite and checking parameters at external API interfaces, scripting languages didn't have much problem

by berntb 10y ago

Bold. :-) I do hope you're correct. (Given a modest test suite and checking parameters at external API interfaces, scripting languages didn't have much problems with bugs that could be found at compile time, imho.)

tatterdemalion 10y ago
> (Given a modest test suite and checking parameters at external API interfaces, scripting languages didn't have much problems with bugs that could be found at compile time, imho.) Not my experience at all.
- hinkley 10y ago
  I've given JavaScript about six years to prove that tests make up for static analysis and all I've learned is that we need MORE static analysis. I've met about four people in a dozen years that write better tests than me, and pretty much everyone else is writing garbage. And when I look back at my own I'm never satisfied. Essentially the only thing worse than no tests is thinking you have test safety when you don't. Particularly, negative tests in a dynamic language are easy to write but are virtually guaranteed to break at a later date without anyone noticing, because you are now looking in the wrong spot for a piece of data.
  - berntb 10y ago
    Good point about tests and dynamic data structures. Thanks.
  - Can_Not 10y ago
    Coming from dynamic land, including JavaScript, one thing I noticed about rust's types and compile time safety was how it would probably eliminate 90% of the unit tests needed for an equivalent JavaScript program, essentially allowing the programmer to focus on less pendantic and more useful-looking unit tests.
kazagistar 10y ago
"Bugs that can be founderstood at compile time" is a complicated category, since it depends on how much you lean on your compiler to help. For example, wrapping primitive types in semantic wrapper types can be an easy way to catch errors where you mix up parameters. And with a sufficiently powerful type system like Idris you can theoretically catch literally any possible bug at compile time.

by berntb 10y ago

tatterdemalion 10y ago

> (Given a modest test suite and checking parameters at external API interfaces, scripting languages didn't have much problems with bugs that could be found at compile time, imho.) Not my experience at all.

hinkley 10y ago
I've given JavaScript about six years to prove that tests make up for static analysis and all I've learned is that we need MORE static analysis. I've met about four people in a dozen years that write better tests than me, and pretty much everyone else is writing garbage. And when I look back at my own I'm never satisfied. Essentially the only thing worse than no tests is thinking you have test safety when you don't. Particularly, negative tests in a dynamic language are easy to write but are virtually guaranteed to break at a later date without anyone noticing, because you are now looking in the wrong spot for a piece of data.
- berntb 10y ago
  Good point about tests and dynamic data structures. Thanks.
- Can_Not 10y ago
  Coming from dynamic land, including JavaScript, one thing I noticed about rust's types and compile time safety was how it would probably eliminate 90% of the unit tests needed for an equivalent JavaScript program, essentially allowing the programmer to focus on less pendantic and more useful-looking unit tests.

kazagistar 10y ago

"Bugs that can be founderstood at compile time" is a complicated category, since it depends on how much you lean on your compiler to help. For example, wrapping primitive types in semantic wrapper types can be an easy way to catch errors where you mix up parameters. And with a sufficiently powerful type system like Idris you can theoretically catch literally any possible bug at compile time.