Just A Summary : The "Yes is No" Problem

Comment on The "Yes is No" Problem by Vince P.

Wed, 04 Apr 2007 13:39:28 -0500

Then, a few weeks ago, I watched a couple of screencasts of experienced Smalltalk developers doing their thing and… wow.

Do you have a link to those screencasts you can email me? I’m curious what all the fuss has been about as well. Even having done some SmallTalk, I never did see the magic. Thanks!

-Vince

Comment on The "Yes is No" Problem by Jan

Wed, 04 Apr 2007 15:33:57 -0500

Can I ask which smalltalk screencasts you found impressive?

Comment on The "Yes is No" Problem by Dave

Wed, 04 Apr 2007 17:46:44 -0500

Welcome to SmallTalk :)

Once you enter…

Comment on The "Yes is No" Problem by Jonathan Allen

Wed, 04 Apr 2007 20:39:53 -0500

Why do you need this ability? Is it impossible to pick the real algorythm to be used at design time?

Comment on The "Yes is No" Problem by Piers Cawley

Thu, 05 Apr 2007 01:47:08 -0500

Johnathan: It’s not impossible to tell. ActiveRecord needs them all, but the various different behaviours can be thought of as layers on top of some basic functionality. If your language supports them, you could use Traits (Smalltalk) or Roles (Perl 6) to layer the behaviour, but Ruby doesn’t have that, so Mixins it is.

Layering the behaviour in this way also enables reuse in a way that having one big hunk o’ code doesn’t; I can (and do) write classes in such a way that I can layer ActiveRecord::Validations on top (it’s often useful to do this for objects that are going to end up serialized inside an ActiveRecord based object, especially if you’re generating them from form data and want to give feedback on entered data).

Everyone else: If I could remember which ones and their URLs I’d’ve added them to the body of the post. I shall hunt through my browser history at some point.

Comment on The "Yes is No" Problem by Bill de hÓra

Thu, 05 Apr 2007 11:54:04 -0500

“Having taken the time to explain why dynamic modification of classes can be a problem, I should point out that I don’t think it’s really a problem in practice. Sure, you can do Very Bad Things with it, but so what?”

You really, really need to look at a big codebase that does this and has done so over many years. One example is Zope2.

Zope2 also has a shell/codebrowse environment, but try running dir() on a Plone page object inside it. Watch the screen scroll through many hundreds of methods, over a thousand in some cases. It’s food and drink to the “scripting languages don’t scale” crowd.

I’ve always said that the worst case scenario for Rails is that it evolves in something like Zope, because at Zope’s core is an object web publisher, which did 8 years ago what Rails does today.

Given enough time, dynamic modification and class monkey patching are entropic, or rather, beg serious questions about sustainability. All languages present tradeoffs.

Comment on The "Yes is No" Problem by Phil Toland

Thu, 05 Apr 2007 11:49:16 -0500

I don’t know if these are the screencasts you mentioned, but here are a few that I have recently watched:

Comment on The "Yes is No" Problem by Piers Cawley

Thu, 05 Apr 2007 12:43:52 -0500

Bill: About the only thing I’d disagree with in your discussion of Zope as a system whose codebase got bad is your implication that it was ever anything but bad. It’s a framework I’ve disliked since I first saw it.

And bear in mind that I’m praising Smalltalk – when I check in my local Squeak image, I see that ‘Object’ has around 500 methods sorted into something like 60 message protocols. And that’s not counting class methods or anything inherited from the ProtoObject class. It could probably stand to be slimmed down some (there’s quite a bit of cruft kicking around in Squeak), but it’s still manageable.

It’s not about method counts, it’s about care and clarity. I have issues with Rails in some areas, but profusion of methods isn’t one of them. I’d like to see the way mixins are layered to build the core classes documented more clearly, but within any module it’s usually clear what’s going on – methods tend to be named well and each mixin concentrates on doing one thing, so it tends to be understandable on its own terms.

Phil: Ah… thanks for those links. I’d not seen Avi’s last one, but the rest are all familiar.

Comment on The "Yes is No" Problem by Daniel Berger

Thu, 05 Apr 2007 15:12:00 -0500

Would something like the ‘use’ module solve your issue? I based it somewhat on Curtis Poe’s traits module:

http://rubyforge.org/frs/download.php/8825/use-1.2.0.tar.gz

Comment on The "Yes is No" Problem by Piers Cawley

Fri, 06 Apr 2007 04:16:18 -0500

Frankly, I don’t think it is an issue; it’s a capability. I was trying to explain why some people think it’s a problem.

Comment on The "Yes is No" Problem by Mauro Cicio

Wed, 09 Apr 2008 07:53:15 -0500

I have two more points to support your position on the 80 columns issue.

respecting this old rule has an interesting side effect: it makes the figures spitted out by rake stats much more reliable and meaningful.
the old 80 columns terminal DO exists, often in production environments on “ruggedized” machines (typical situation of banks, telecommunication companies, etc.).

Comment on The "Yes is No" Problem by James Robertson

Wed, 02 Jul 2008 08:54:29 -0500

You can also see screencasts and videos on Smalltalk at the Cincom Smalltalk site: