[nnq]

Side-topic question: is anything from the Smalltalk OO model that hadn't made its way into Ruby?

I know that Matz took lots of ideas from Smalltalk when he created Ruby, but I wonder if there are any good OO model related things he didn't adopt. I don't mean the whole image based and IDE in the program thing, I know this is something only Smalltalk has.

[spooneybarger]

Depends on what you mean by OO model. One of the most important things about Smalltalk is 'thisContext'.

The various links referenced from:

http://stackoverflow.com/questions/6347599/how-does-smalltal...

Should give you a good idea.

Basically, the current call stack is available. This makes it trivial to write a debugger, restart processing from a previous point in execution (debugger driven development as it is sometimes called makes the TDD process make so much sense when you do it in Smalltalk).

[gnaritas]

Lisp has images too. Ruby copies the Smalltalk OO model pretty closely but what Smalltalk has that Ruby doesn't is automated refactoring, that ability comes from being image based rather than file based. Ruby is a very practical modern Smalltalk frankly.

[kilon]

Does Ruby have traits ?

http://pharo.gemtalksystems.com/book/LanguageAndLibraries/Tr...

[nnq]

Well, isn't the use case for traits the same as for mixins? (http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_module...)

[kilon]

yeap definitely looks like it. I would not be surprised if Python has something similar too.

For me OO is not the big reason to use smalltalk. For me the biggest reason is the whole live coding environment which is a big plus for workflow and speed of development. But maybe other smalltalkers could chime in with features I am not aware of.

Also Pharo has Pooldictionaries , which are doing the same thing Traits are doing for methods , for instance variables. Probably Ruby has something similar too.

I really think highly of Ruby , its a really powerful language. The reason why I chose python instead is that I can't stand the "Pearl" syntax. All these weird symbols etc. Definitely not my thing and make code less readable to me.

But as a language Ruby looks great to me. So definitely would not recommend against learning it :)

[nnq]

Python has good multiple inheritance and as far as I've seen most sane people just use it to "emulate" mixins and even name their secondary parent classes like Feature1Mixin or DoesYTrait.

Traits seem like a great idea, but the only other language where I've seen it under the Smalltalk name of "trait" is... brace yourself :) ...PHP 5.4+.

[seanmcdirmid]

Scala has traits, to great effect.

[spooneybarger]

There are a few subtle, important differences...

Check out the original paper and they should become apparent:

http://web.cecs.pdx.edu/~black/publications/TR_CSE_02-013.pd...

[philippeback]

Less verbose syntax.

[nnq]

Indeed. But I would'n consider this a "feature" though: the easiest to read syntax I've seen is that of Python, with the "classic" (by classic I mean "C++/Java like") `.` and `(` clearly separating the message receiver, message name, and message parameters, plus indentation based syntax - nothing beats this combo for quickly scanning foreign code, even without syntax highlighting :)

[kilon]

I am python coder. Smalltalk is much more readable than Python and so is Lisp.

I dont know why you think dots and parentheses make things easier to read. Maybe its a matter of preferences , but even though I have grown up with this style , I dont find it more readable than smalltalk.

I dont see

Door.open(1,3,30)

as more readable to

Door open: 1 times: 3 andCloseAfterMilliseconds: 30

And this is exactly how python code works and how smalltalk works too. Also smalltalk culture is oriented towards clean code alot more than python world. You will rarely see methods in pharo more than a few lines long. And if you do , is most likely that code has not been cleaned up. And I find that a huge plus even more than the syntax itself.

Of course if I had to choose without smalltalk, then python would be my first choice for readability. But still nowhere near as to how easy I understand smalltalk , even though I am using it for less than a year.

[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.