21–30 of 71 posts
>> And here is that insidious problem; all your unit tests have frozen the interaction of your components. They have copied the API of your components and distributed it all over your test code base. This is what I hate about the unit-test everything approach. There seems to be a class of developers recently that believe robustness is more important than anything else. Often speed bumps in changing API contracts is a…
Earlier quoted context omitted.
Could you elaborate. Which claims are incorrect?
One example would be this: > If you misspell a variable [...], you discover this at run time. Ouch. CL-USER> (defun square (n) (* nn n)) ;; Ouch! nn isn't defined! ; in: DEFUN SQUARE ; (* NN N) ; ; caught WARNING: ; undefined variable: NN ; ; compilation unit finished ; Undefined variable: ; NN ; caught 1 WARNING condition SQUARE
I use a strongly, statically typed functional language. Because my code has no mutable state, the type system of the program proves the program correct. So I don't have to write any tests at all and maintenance is easy.
Not sure if you're trolling or just don't understand what tests are actually supposed to test.
The argument between dynamic and static languages has gone one for years and there's been no conclusive answer that one is better than the other. People have written 500kloc C++ systems and they've written 500kloc of TCL.
Submitter here: Yes, and some of the claims are simply factually incorrect: the original work on refactoring OO programs was done in the context of Smalltalk, the code navigation we now have in IDEs was taken from Smalltalk (in fact, Eclipse started out as Visual Age Smalltalk) etc. So I find the post "debatable"...
Earlier quoted context omitted.
One example would be this: > If you misspell a variable [...], you discover this at run time. Ouch. CL-USER> (defun square (n) (* nn n)) ;; Ouch! nn isn't defined! ; in: DEFUN SQUARE ; (* NN N) ; ; caught WARNING: ; undefined variable: NN ; ; compilation unit finished ; Undefined variable: ; NN ; caught 1 WARNING condition SQUARE
It is true of other dynamic languages and there isn't any way to fix that.
$ perl -Mstrict -E 'say $foo'
Global symbol "$foo" requires explicit package name at -e line 1.
If you're going to write a physics simulation, you're really going to benefit from some language features over others. I would argue that you especially benefit from static types because you control a lot of your stack and type checking can make your code very robust. On the other hand, if you're going to write a webapp, think about what you're doing: essentially slinging text around and taking random inpust from users, casting all of it to actual types, and shoving it into a data store (casting it again sometimes). What is the type system providing you in that scenario? Everything is cast at runtime somewhere.
Static typing is right for some problems, but the idea that dynamic languages are inherently unmaintainable in some way that most static languages aren't is one that I find incorrect.
I use dynamically typed languages maybe 90% of the time, and completely agree. But here's the thing: for most projects - including ones in production - it doesn't matter because the app won't be large enough to not completely fit in a mental model. If the app starts getting too large, then by all means rewrite it in a statically typed language. If you're getting to that point, a rewrite is probably warranted anyways;…
All you need is a sophisticated type-system and smart type-inference that works everywhere (not just locally) and you'll be able to be just as productive as with today's popular dynamic languages but get all the benefits of static verification.
I use a strongly, statically typed functional language. Because my code has no mutable state, the type system of the program proves the program correct. So I don't have to write any tests at all and maintenance is easy.
> the type system of the program proves the program correct.
Is not a valid statement, unless you're actually writing proofs in Coq. I bet you aren't.
"The type system of the program proves many simple properties of the program correct" is much more correct.
Also:
> Because my code has no mutable state
No, that's not why. The type system you use may be incapable of reasoning about mutable state, which coincidentally serves to indicate that it most likely can't reason about such things as "this list is sorted", further supporting my initial counterpoint.
Check out ATS or Why for examples of languages that permit reasoning about mutable state.
Earlier quoted context omitted.
One example would be this: > If you misspell a variable [...], you discover this at run time. Ouch. CL-USER> (defun square (n) (* nn n)) ;; Ouch! nn isn't defined! ; in: DEFUN SQUARE ; (* NN N) ; ; caught WARNING: ; undefined variable: NN ; ; compilation unit finished ; Undefined variable: ; NN ; caught 1 WARNING condition SQUARE
It is true of other dynamic languages and there isn't any way to fix that.
$ cat err.py
def a():
print b
$ pylint -E err.py
************* Module err
E: 2,8:a: Undefined variable 'b'