I am a Java developer. There, I said it :-).

When I am writing code, I can rely on the compiler to confirm that
any methods I write will be called with parameters of the “right”
type. I do not need to test that parameter #1 really is a String
before I call some method on it that only works on Strings.

If I am writing in Python, since it is dynamically, but strongly
typed, I really should check that each parameter is of the expected
type, or at least can respond to the method I plan on calling (“duck”
typing). Every call should be wrapped in a try/except statement to
prevent the method (and program) from crashing when my method is
called with an integer instead of the expected string.

Is this the experience that Python programmer (of large projects) see?
Do you also write unit tests to confirm that the methods actually
check for and catch “bad” parameter types? If I am writing small one-
off scripts, I wouldn’t worry about it, but if I am writing a large
system that must have 99+% uptime without constant monitoring, this
really should be verified.

Up for discussion…

Please, could we now stop this. Could you stop twisting my words, could you stop insulting me, could you stop attacking me personally?

For reference to make sense out of my last comment:

Yes. At least here in Germany there are limits on free speech. Concerning libel and insults for example.

Don’t comment and I won’t quote you out of context.

“You seem to want to make this a nationalist thing. Well I’m not biting.”

You’re so twisted, it’s beyond words. How you could construct a “national” thing out of my comment is beyond me. I added “Germany” because otherwise you would again call me “vague”.

“Please remove your last comment as it quotes me without containing the full text of what I actually said.”

With your comments we have left “please” behind us. I asked you not to comment, but to no avail. No, I won’t remove my comments. Just yours. Stop commenting. I told you.

Thanks
Stephan

You seem to want to make this a nationalist thing. Well I’m not biting.

Please remove your last comment as it quotes me without containing the full text of what I actually said.

Thanks,

Paul.

I’ve made several times my intentions with the quotes clear.

You have been warned not to repeat this. You have the fame for being the first to be banned from further comments and your recent comment after my last warning is deleted.

Proposition A: “Okay, pretty darn good units tests cover all type errors and more. Then, dynamic typing with good unit tests won’t probably have a typing error (then again, if we consider Null pointers exceptions to be some kind of typing errors, then they’re pretty common even in static typed languages like Java). Therefore dynamic typed languages are as safe a static typed languages”.
Stephan says this is a bit of a lie, because most dynamic typed projects don’t have pretty darn good unit tests.
I’m guessing this is truth, besides, this dude, Josh, says he has seen this.
But Stephan never argued that if you DO write pretty darn good unit tests you are within the “lie”. And this is what Paul is trying to argue against.

Myself? I think Stephan is right, has said no false statements AFAIK, but he isn’t saying too much. “Yes if you do write good unit tests your ass is saved but if you don’t then you don’t” doesn’t say anything to me, it is an obvious statement. The fact that most developers don’t test still doesn’t say anything to me, THEY SHOULD do pretty darn good unit testing, and maybe with time it will become a more and more common practice.

http://pab-data.blogspot.com/2009/01/i-dont-know.html

Peace.

Paul.

“2.) Developers in dynamic languages do (more) unit testing”

Who is saying this? Have they done a survey? Do you have a link?

It amazes me just how difficult some programmers find it to say “I don’t know”.

The psychology of it fascinates me. Otherwise intelligent people end up boxing themselves into stupid positions just because they can’t admit that they don’t understand, or perhaps someone else has a insight that perhaps they’ve missed or maybe they have a bind spot.

Thanks for the discussion. I’ve been meaning to blog about this phenomena for a while, and you’ve kindly provided me with plenty of material :)

Kieth Braithwaite makes a similar point in an interview on InfoQ:

http://www.infoq.com/interviews/Agile-Skeptic-Keith-Braithwaite;jsessionid=FCE66C551EE2C3046F6952A81EC59E5F

He speaks about people who attempt to do Agile “by the book” without ever questioning whether they know what they are doing and whether things are actually working for them, leading to Agile as a “one size fits all” commodity.

I think it has to do with an organisational culture where you are penalised for admitting that you don’t know. But if you can’t admit you don’t know, how can you ever learn? As a consequence whole organisations eschew learning and become stuck in a rut.

PS. Sorry if I caused offence. This was not my intention. If you read back what I have said once the emotion has subsided then you will see that I was genuinely trying to shed light on an often misunderstood topic.

Paul.

I looks a little bit too – self confident doesn’t give the right impression …. – hmm, to place oneself between Eckel and Martin.

“I won’t waste anymore of your time.”

It seemed too good as a promise as to be true. How do you call your statement as a native speaker?

Just not Paul Beckford, Bruce Eckel, Bob Martin and… anyone else who so happens to hold a different point of view.

“But you’re partially right, perhaps not from someone who doesn’t want to help, but who wants to be on top – even when he needs to resort to ad hominem attacks and twist other peoples arguments to achieve his goal.”

Now who is implying motive? I was truly trying to help you sieve through what seem to me to be muddled thoughts.

I guess my help wasn’t appreciated :)

Paul.

But you’re partially right, perhaps not from someone who doesn’t want to help, but who wants to be on top – even when he needs to resort to ad hominem attacks and twist other peoples arguments to achieve his goal.

Looks like I’ve hit a nerve :)

And you are right. There is nothing you can learn from me or anyone else, because you know it already :)

I won’t waste anymore of your time.

Paul.

You’re right, but I haven’t said this, have I?

Funny how you try to educate me on TDD/BDD, unit testing, dynamic languages and agile. Or Smalltalk.

I have been a agile proponent and Scrum master for some years, have been writing software for around 26 years, have mentored developers, have done dozens of projects in dynamic languages during the 90s (Perl, Python, Tcl/Tk, Ruby, PHP), love a Lisp book from the 60s, wrote frameworks for dynamic languages, have been doing unit testing since Kent published his first XP book in the 90s and gave some speeches about unit testing and how to achieve 100% test coverage in nasty places like DAOs, databases, Swing, Emails and Exceptions.

You’re assuming lots of things about me, my knowledge and my attitude in your posts. You might be wrong. As far as I can see none of your comments talk about the things I’ve written in my blog post.

“Sorry, not all of us can be native speakers, we wish we could,…”

So you are willing to accept that perhaps you misunderstood what Bruce and Bob were saying.

If you start with the understanding that “dynamic languages in themselves lead to bug free code” then I agree this is a lie which is self evident from the fact that dynamic language projects have bugs too.

But no one is saying this. What people are saying is that the real issue is producing defect free software and that there is more than one way to achieve this.

One approach stems from the REPL (Read-Evaluate-Print-Loop) idea from Lisp. Were you gain quick feedback about the correctness of your code by running it often (I like to call this approach suck-it-and-see).

Suck-it-and-see is only effective if the time it takes to get feedback is short. So languages that require a long compile cycle aren’t well suited to a REPL approach. Dynamic languages on the other hand provide the opportunity for fast feedback as Bruce Eckel rightly points out.

Fast feedback in itself isn’t sufficient however, the feedback needs to point you to the defect. So with regards to type safety, a language which provides strong dynamic type safety will provide you with fast and accurate feedback about type errors at runtime.

TDD/BDD build on these ideas. In fact Kent Beck invented TDD in the context of a dynamic language: Smalltalk. With TDD you only write code once you have specified a failing test. You then run your code as part of your test suite to gaining instant feedback.

Now if you are good at TDD and are only writing code in response to a failing test then it is very difficult for your code to pass all your tests whilst containing type errors. Any type errors will be readily detected by the runtime.

This is what both Bob and Bruce mean when they say that static type error detection is redundant for them. Of course if you aren’t skilled in this programming style and you don’t write tests first, then you won’t get the same results.

It comes down to the programmer and how adapt he or she is in using their chosen tool.

So talk of “lies”, is irrelevant. The real issue is understanding the skills needed to use dynamic languages effectively.

The same can be said for static languages too. Hence why most teams spend 60% of project time finding and removing bugs that could have been avoided if they had used TDD.

Paul.

“[...] Linux (Linus Torvald) [...]”

From my understanding Linus mostly wrote the Linux kernel not the system. Perhaps it would be best on your blog to be more precise.

I’ve also liked the comment

“Paul, your ad-hominem remark is both unwelcome (as you no doubt intended) and incorrect, [...]”

After more thinking your comment about my English made me cry.

Haven’t we non native speakers listened to BBC podcasts all day? Haven’t we watched Red Dwarf? Haven’t we watched Fawlty Towers and laughed about the Germans? Haven’t we watched every Flying Circus episode? Didn’t we try as children to understand the bizarre nature of The Trap Door? Didn’t we laugh at the First World War episodes of Black Adder?

And still, how wrong our understanding of the English language is. What tragedy!

Yes, and as I commented this is the base for the argument for dynamic languages. See my comment.

“If you stopped and thinked about what I’m saying for a moment, you would realise that perhaps I am your friend.”

Hard to imagine as you deliberately twist most of the things I write and imply I’ve written things which I haven’t.

“If you choose to see my words as a personal attack then I think that points to your own insecurity.”

Insecurity? After some self reflection – no, probably not.

Again:
“Mud as an unfortunate habit of sticking, and when you decide to call fellow programmers liars you really need to build an iron clad case first.”

You twist my words. I haven’t called them liars. You deliberately suggest that I have.

To quote myself:
“1.) Unit testing prevents type bugs (see quotes)
2.) Developers in dynamic languages do (more) unit testing
3.) Therefor there are no type problems at runtime with dynamic languages”

And you better stop telling people I called Bruce Eckel and Robert Martin liars, otherwise I will need to defend myself.

“The issue is understanding plain English.”

Sorry, not all of us can be native speakers, we wish we could, but some of us are born to start with inferior languages – call yourself lucky to be born into the elite of native English speakers and keep helping us poor ones.

Update: “The issue isn’t research.” If you’ve read my comment, and not assumed things, you would have seen that my comment was not about research but the style of peer reviewed research papers.

The issue isn’t research. The issue is understanding plain English. Both Bruce and Bob were speaking about their programming styles.

“I’m sure we’re not friends”

If you stopped and thinked about what I’m saying for a moment, you would realise that perhaps I am your friend. Only a friend would take the time to point out your blind spots:)

If you choose to see my words as a personal attack then I think that points to your own insecurity.

Hopefully your readers will view me as a friend for pointing out the flawed logic in your post.

Mud as an unfortunate habit of sticking, and when you decide to call fellow programmers liars you really need to build an iron clad case first.

You haven’t.

Paul.

“We just do more unit testing to prevent type errors” meme is quite prevalent in the blogosphere.”

and form the basis of the type testing and dynamic language arguments.

I did not imply that they have lied. The lie is that there is no problem with dynamic typing because developers do unit tests:

1.) Unit testing prevents type bugs (see quotes)

2.) Developers in dynamic languages do (more) unit testing

3.) Therefor there are no type problems at runtime with dynamic languages

As quoted in the post, the argument breaks down because 2 is a lie (as in “not the truth”), developers don’t do more tests in dynamic languages according to the cited post.

Your quite notorious at twisting what I’ve said.

“Muddled thinking my friend :)”

I’m sure we’re not friends.

Update:As you accuse me of muddled and vague ideas, I would love to see more research papers on this topic. As I’m no longer in research I don’t have the time to write those kind of peer reviewed papers anymore. This blog posts are not scientific, peer reviewed research papers. Thanks for understanding the difference.

You lack precision in your argument.

You said:

” The myth/lie I’ve meant is that there is no difference between dynamic languages and static languages concerning type bugs because developers write unit tests – even considered better than static typing – to cover type checks. ”

None of your quotes say that “there is no difference between dynamic languages and static languages concerning type bugs”

What Bruce Eckel and Bob Martin are saying are that they (as programmers) get feedback on the correctness of their code by running the code through tests.

This feedback means that they no longer rely on the feedback that they get from a static type checking compiler. Making the type checks performed by the compiler, redundant for them.

This is a statement about their programming style.

Calling them liars and using the programming practices of “others” as proof makes no sense.

Muddled thinking my friend :)

“but I’m tired of a discussion about points I didn’t make.”

I can tell. You seem to have a difficulty listening to the voices of others. Hence your total misrepresentation of what both Bruce Eckel and Bob Martin actually said.

I’ll leave you to your soap box.

Paul.

sorry I didn’t know that you don’t know the topic. The “We just do more unit testing to prevent type errors” meme is quite prevalent in the blogosphere.

Bruce Eckel
” In a dynamic language you have the flexibility to do rapid experimentation which is highly productive, but to ensure that your code is airtight you must be both proficient and diligent at unit testing. ”

Robert Martin
“About two years ago I noticed something. I was depending less and less on the type system for safety. My unit tests were preventing me from making type errors. The more I depended upon the unit tests, the less I depended upon the type safety of Java or C++ (my languages of choice).”

etc.

“I am not aware of anyone propagating this lie.”

http://letmegooglethatforyou.com/

“The problem I think you are facing is that you have started with the premise that “you are right” (about something), and then you fish around for supporting evidence.”

No, quite to the contrary. I’ve read a blog post from someone who has fixed lots of Rails code and from there deduced that developers don’t do more unit tests in dynamic languages than static languages (which they needed to do to find bugs which the compiler usually finds). Have you read my post?

I don’t know why you resort to straw man attacks again

“Even the most ardent advocates of static type checking would agree that a static compiler will not write clean code for you, [...]”

but I’m tired of a discussion about points I didn’t make.

Its kind of difficult to pin you down. Now lets start with the title: “The unit testing lie aka dynamic typing testing lie”. Which lie? whose lying? Can you provide a link?

The you go on to say:

” The myth/lie I’ve meant is that there is no difference between dynamic languages and static languages concerning type bugs because developers write unit tests – even considered better than static typing – to cover type checks. ”

I am not aware of anyone propagating this lie. I agree, a compiler can help to detect type errors without the need to run your code. So you can detect type errors with a static type check without tests. This says nothing though about whether your code is bug free and will actually ‘work’ as expected at runtime.

You then go one to quote poor programming practice with rails as some how supporting your argument. What ever your argument is!

Given the vagaries of your post, I decided to rewind the clock and get back to first principles, hence my references to Fred Brooks. Even the most ardent advocates of static type checking would agree that a static compiler will not write clean code for you, rendering your references to poor rails practice as irrelevant. A ball of mud is still a ball of mud in any language.

The problem I think you are facing is that you have started with the premise that “you are right” (about something), and then you fish around for supporting evidence.

I would understand if you said that I write poorer quality code with a dynamic language as compared to a static one. This is common for a lot of people, since dynamic languages require a different programming style and a different skill set.

Your blanket statement about “lies”, doesn’t allow for the fact that some programmers are both more productive and produce higher quality code using dynamic languages as compared to a static language.

Instead you choose to label these programmers as liars :)

Hence my second reference to Fred Brooks. We tend to get overly attached to our favorite tools and forget that good people are far more important. I have been programming with languages with varying degrees of static type checking for over twenty years now, and for most of that time the programs I worked on were riddled with runtime bugs. So static analysis is “No Silver Bullet”.

(Incidentally the static language programs I have worked on that were largely bug free all had an extensive unit test suite, and were written test first by competent programmers).

Paul.

Especially

“Some observatons. All the points you raise are equally applicable to static languages too. I’ve yet to come across a project that lacked tests yet the code quality was some how preserved by the presence of static type checks.”

looks like false logic in context of my post. I don’t see my post talking about code quality in general.

“No silver bullet (Fred Brooks again).”

I’m not sure why everyone cites Fred Brooks on my blog, I have never sold silver bullets here. On the contrary.
It goes against the silver bullet of dynamic typing: unit testing.

“When discussing dynamic vs. static languages, the arguments for not needing static type checks are based on more unit tests.”

Could you explain how my post is advocating silver bullets?

Otherwise I consider your whole post a strawman attack.

Thanks for your observations though.

Some observatons. All the points you raise are equally applicable to static languages too. I’ve yet to come across a project that lacked tests yet the code quality was some how preserved by the presence of static type checks.

Writing tests after the code is difficult and time consuming and like you say often gets dropped or is incomplete due to time pressures.

Writing tests before writing the code is a different thing entirely. Here testing is an intrinsic programming step. Tests are interface specifications, or better still “behaviour specifications”. Making the testing language redundant, and allowing the programmer to know when his code works (when the design spec is met), and allowing him to clean up his code knowing that he hasn’t broken anything.

If you do not specify what your code is meant to do in an executable specification, then you don’t know whether the code works and meets your intent. You don’t know when you’re done.

If you do not specify what your code is meant to do in an executable specification, then you don’t know whether a refactor will break your code or not. You cannot clean up your code with safety.

Without refactoring and cleaning up your code, and without a way to verify your design, a team can quickly end up with a code base that resembles a big ball of mud (Fred Brooks).

Facing a ball of mud, I would rather it was written in a static language then a dynamic one. At least then my compiler provides me with a minimal executable specification, based on types.

Having said this, I would rather not work with a ball of mud. So the real issue is how do you keep your code clean in the first place. Compilers don’t generate clean code, so In my eperience static types don’t help to keep code clean. They just make unclean code more tolerable.

Clean maintanble code comes down to programmers. No silver bullet (Fred Brooks again).

Paul.

“[...] coverage is not a good measure of test quality.”

No it’s not, it’s a measure about test density. I didn’t want to imply that it’s a metric for test quality. And after reading the post again, I don’t think I have.

ps: thx for the “rails worst practice” link, very useful post.