[nnq]

Definitely a matter of taste then. The other think I like about Python and why I find it more readable is the usage of snake_case instead of camelCase. I'd take

    Door.open(1, times=3, close_after_ms=30)

over

    Door open: 1 times: 3 andCloseAfterMilliseconds: 30

anytime :)

[kilon]

doable with smalltalk too

Door open: 1 times: 3 and_close_after_ms: 30

also please note here, that python does not usually use keyword arguments. Unless for cases of optional arguments.

So the python you wrote is completely doable of course, BUT not that used as often. So it will be Door.open(1,3,30) a lot more than Door.open(1, times=3, close_after_ms=30).

This is where smalltalk shines, its culture. Those code habits that make a difference. Especially when you have to read tons of code.

When you read message send, you can understand easily what that message sent is doing. While a Door.open(1,3,30) will not reveal exactly what the method is doing. Or what that arguments mean and you will have to look into the documentation to figure things out.

This emphasis on workflow is what set for me smalltalk apart from other programming languages and enviroments. Its not a preference thing, its actually 100% practical and easily measured as workflow enhancement. And keyword arguments based coding is just one of the enhancements that smalltalk offers.

[philippeback]

aBlock := [:times :delay | times timesRepeat: [ door open. (Delay milliseconds:delay) wait. door close ]].

aBlock value: 3 value: 30.

[bromagosa]

This is valid Smalltalk code, but not the way you'd program a door in Smalltalk.

You'd probably prototype this in a Workspace, then create the method suggested above, which would force you to specify keys for the arguments, thus forcing you to make your code cleaner and more readable.

[kilon]

completely agree with you. I am no big fan of blocks myself and I try to use them as sparse as possible. Keeping things simple is the way to go unless you have a good reason to do otherwise.