Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
RailsConf 09: Robert Martin, "What Killed Smalltalk Could Kill Ruby, Too" (blip.tv)
19 points by RiderOfGiraffes on May 23, 2009 | hide | past | favorite | 16 comments



i like the parts where he equates estrogen with insipidness. nice ranty take on that at:

http://gilesbowkett.blogspot.com/2009/05/what-killed-smallta...

and a response that isn't so ranty ( and addresses other parts ) at:

http://www.cincomsmalltalk.com/blog/blogView?showComments=tr...


I'm really glad they posted this. I saw a lot of twitters at RailsConf about how great this keynote was. Now that I've seen it, I personally don't see that much to like about it, but at least I'm no longer left wondering


Me too. It is delivered with great fun, but there is no truth.


... there is no truth.

Interesting claim.

Question: Have you actually tried programming the way he sugegsts? Have you used it "in anger"? Have you worked in a team that has ubiquitous, all-encompassing, tests?

I ask because I'm interested. I've started recently, as an experiment, to run in that very, very small circle, and after an initial experience of paralysing culture shock I'm starting to run really, really fast.

I'm finding it liberating.


There is no doubt many programmers find it beneficial to use TDD. My claim is still that there is no truth, but not in the sense that you think. It is very easy to say that TDD helps, or that X killed Smalltalk, because it is almost impossible to falsify. It is the same weak argumentation that made OO prevail back in the 80'es/90'es. Usually you back up this by a "study" containing a) 1-2 "Cases" and b) no statistics with a significance test.

As to your questions:

"Have you tried it?": It depends. Test driven design states that you need to develop code and tests in tandem. I rarely do that. But note I also rarely program in dynamically typed languages. I develop the type in tandem with the program, and that constitutes a verifiable test as well, albeit a different one. Correctness is usually backed up by either a) machine-verifiable proof or b) Black-box test suites.

"Have you used it an anger?" I can't answer this. I rarely program when I am angered. I don't become desperate when I write code.

"Have you worked on a team with ubiquitous, all-encompassing, tests?" Yes. The team did not do TDD though. All tests were black-box.

Here is another experiment: Read Benjamin C. Pierce: TAPL and ATTAPL. Understand them. Learn Haskell. Learn QuickCheck. You will probably find that TDD is something which is much more needed in the dynamic language setting.


Found from http://news.ycombinator.com/item?id=604808 but worthy of its own item.

Also referenced from http://news.ycombinator.com/item?id=597314

For some reason I can't make it play beyond about the 41 minute mark. Can anyone else?



Could you give a brief summary of the points for those of us who are video impaired? Thanks.


That's tough. It's a 60 minute video, and he makes a lot of great points. The style is fun, too.

From memory,

It was insular - people created and staying in their bubble and didn't interact with messy other code.

It was too easy to make a mess, and continue to work with it until suddenly the code become too fragile to change.

Proponents thought their world was somehow better, and didn't play nice. So others didn't play nice in return.

One big one that really needs the video to support it - it will come to be believed that professional programming will be based entirely and exclusively around "proper" TDD.

There are more. I'll see what I can do. Do you have any video capability? It's also on YouTube.


To whomever down-modded this ...

I'm sure you have your reasons, but I'd love to know them. I've just provided a service in response to someone, why down-mod me?

Talk about shooting the messenger.

This isn't a complaint, I'm simply confused. I don't much care about the karma, but I worry that sometimes people down-mod something because they don't agree with it, rather than because it's of negative value.


It was pure laziness, not any lack of facilities. :-) I find it hard to devote an hour to a video when there is a good science fiction book around. Thanks again for the summary.


Oh, it's seriously incomplete. There's a lot more stuff.

I would recommend downloading it and playing it at double speed.


To summarise:

Skip straight to 05:30. It starts with something completely unrelated and, to me, uninteresting.

This link works beyond the 41 minute mark:

http://blip.tv/file/2089545?filename=RailsConf-RailsConf09Ro...


So, is TDD really the key? Should you really always (or nearly so) write your tests first before writing any code?

It would seem to me that doing so would seriously interfere with workflow.


I'm sure I should be very afraid, but I had to skip the details after he bored me to death with that unfunny rambling metaphor for who the fuck knows what in the beginning.


Yah, skip straight to 05:30.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

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

Search: