Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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 object testing doesn't seem to respond well to changes in the underlying code interesting.

It's that mix that makes it "debatable" ;-)


There are some interesting, semi-recent (last few years) attempts to fix the pitfalls of using mocks for testing - renaming methods, wrong arity, typos, etc.

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!


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


Practically speaking, this is helpful, indeed.

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.


It is true of other dynamic languages and there isn't any way to fix that.


Sorry, many dynamic languages prevent against this. For example:

    $ perl -Mstrict -E 'say $foo'
    Global symbol "$foo" requires explicit package name at -e line 1.
Also, his comment about properties on objects is very debatable, too. Ignoring that the term "property" is overloaded and not defined, since I use roles (see: http://www.slideshare.net/Ovid/inheritance-versus-roles-1799...), I find out at compile time if my classes are missing an attribute or method (actually it's composition time, but that's splitting a hair that most will never notice). In short, I don't get frantic 2AM phone calls about a batch process trying to call a non-existent method.


  $ cat err.py
  def a():
    print b
  $ pylint -E err.py
  ************* Module err
  E:  2,8:a: Undefined variable 'b'




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: