31–40 of 71 posts
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.
Now and then I get to deal with development groups who have built their software systems using a language like Ruby or PHP. Many of them are proud of their extensive automated tests. They'll brag about how they have 45,000 or more unit tests, for instance. Yet when we actually look at these tests, many of them just end up implementing a half-baked type system. Even if they don't realize it, or don't want to acknowled…
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.
(define square ((a number)) :out number (+ a 2)) This program is arguably incorrect, even though the types match up and there is no mutable state.
fun square {m:int} (a: int m): int (m*m) = a + 2
The difference between writing proofs and writing tests is subtle though and serve similar purposes. Tests can make you feel confident that things are right but proofs should make you certain of it.
[1] http://bluishcoder.co.nz/2010/09/01/dependent-types-in-ats.h... [2] http://bluishcoder.co.nz/2013/07/01/constructing-proofs-with... [3] http://bluishcoder.co.nz/2012/10/04/implementing-a-stack-wit...
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
Technically speaking, the more reflection a language provides, the less correct this becomes. Python code can dynamically inject local variables into stack frames, attributes into objects and so on in more or less silly and probably non-portable ways. So in the end, you end up with pragmatic correctness for mostly sane code. If that's enough for you and your project, go with it.
One thing I've only come to appreciate during my professional development is that there are huge differences in the kinds of software people write and what's good in one scenario isn't necessarily good in another. A lot of people around here fall into the trap (myself included) of thinking that web programming is the entire universe of programming. That's not so, and the difference matters greatly. If you're going to…
Though the data flowing in and out of a web application is usually in string form, that doesn't mean that it needs to be treated as such in your application. You'll convert the string to a richer, more specific datatype and the static type system will help you correctly manipulate the data.
A nice blog post on the subject is [1] where the author explains how you can represent different kinds of strings (raw strings, SQL strings, etc.) using the type system.
[1] http://blog.moertel.com/posts/2006-10-18-a-type-based-soluti...
Earlier quoted context omitted.
Given that the second paragraph makes factually incorrect claims about what you can detect at compile time in dynamic languages, I think "debatable" is rather kind :) Of course, sweeping generalizations about static versus dynamic languages tend to fall flat.
> I think "debatable" is rather kind :) Well, I think he has an interesting data-point, and makes some interesting points despite maybe making a somewhat incorrect generalization. But even that generalization points to something I find interesting, which is that Python and JavaScript (maybe Ruby as well) possibly form a separate group with the characteristics he describes. I also found the observation that Mock objec…
rspec-fire for example validates that the object you're mocking responds to the method name you've used, and takes the same number of arguments. It also does it conditionally based on whether the class in question has been loaded, so your unit tests can run in isolation, but when you run your full test suite it will catch any mocking errors.
Pretty handy!
Earlier quoted context omitted.
Isn't "some language xyz worked out very well..." and "I found writing large projects in Python..." basically the same (anecdotal) argument?
Yes, but its a subjective post. If someone wants to say or blog "I use xyz and I can successfully maintain and extend large projects and it hasn't collapsed under a cognitive burden and too-specific unit testing" that'd be a cool counter data point.
The lack of static analysis is extremely irritating when you've been running a long old calculation for 20 minutes and it chokes on a misspelled variable name. You can often catch these with PyDev/eclipse, but not always.
I try to rewrite any code which isn't fast enough in C (or C++, using a few of its "features" as possible) and wrap it up as a Python module; this gives me the best of both worlds: the speed and type checking of C/C++, with the convenience of calling the code from a quick script or an IPython shell.
This approach is much easier for scientific code than for web apps, though, which do actually need dicts and string parsing.
[[One web app option might be to cython as much of your pure python code as possible (including cdef'ing many of your local variables) as this will dramatically help typo checking - I don't know if this is particularly scalable though.]]
>> 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…
It's better to do the wrong thing quickly.
It all depends on your problem domain--the cost of failure for certain things (pacemakers, telco software, car engine ECU code, and so on) may be much, much greater than the cost of being super retentive in your development.
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.
>> don't have to write any tests at all
>> maintenance is easy.
You're zero for two, my friend. :(