3 posts tagged “gnu smalltalk”
As I was reading the latest entry in Brett Hallett's blog, titled "Rewriting a script into a callable method", I saw the code:
i := 20.
d := '0123456789abcdefghijklmnopqrstuvwxyz'.
l := d size.
s := String new: i.
1 to: i do: [ :x |
s at: x put: (d at: (Random between: 1 and: l))
].
s printNl.
This code didn't look very smalltalk-like to me. So I thought a bit about what was striking me odd, and it was all those explicit #at: and #at:put: calls. Not to mention confusing uses of "i" and "l" in a bad font. :)
The first two lines aren't bad. I'd keep them, although I'd probably name the values a bit more intention-revealing:
desiredLength := 20.
sourceCharacterSet := '0123456789abcdefghijklmnopqrstuvwxyz'.
sourceCharacterSet := '0123456789abcdefghijklmnopqrstuvwxyz'.
But the rest of the code starts going a bit odd. Consider the expression:
d at: (Random between: 1 and: (d size))
(factoring out the temp variable). This is equivalent to simply:
d atRandom
And the loop there is collecting together "desiredLength" number of these random selections. So let's say that using a Collection-style method instead:
(1 to: desiredLength) collect: [:each | sourceCharacterSet atRandom]
We're now much closer to the result. The problem is that we now have an OrderedCollection of Characters, not a string. But a simple class-mapping will fix that, because Strings know how to create themselves from Collections of Characters:
((1 to: desiredLength) collect: [:each | sourceCharacterSet atRandom]) as: String
And there we have it. If #collect: didn't barf on a 0-arg block, we wouldn't need the misleading ":each" in there either. (Developed with Squeak... not sure how unstandard this stuff is, or if it's just missing in GNU Smalltalk.)
Last night, I gave the second presentation of my "Intro to Seaside" talk: this time to the patient people of the "Advanced PLUG" group. I had incorporated comments from the previous presentation by including less information about Smalltalk history, and more live demos to illustrate by doing instead of talking.
However, even after these adjustments, my should-be-50-minutes talk ended up taking almost 90 minutes. The consensus of the group seemed to be that I could eliminate even more of the "intro to Smalltalk" part, and concentrate on the meat of the talk: how Seaside workflow helps me get my webdev done faster, better, and cheaper, by abstracting and reusing in the two directions (web components, and workflow steps). Apparently, the simplicity of the Smalltalk code that I end up demoing is nearly self evident, and what's more important is that I show Seaside working, and my enthusiasm makes up for the lack of technical details. And with my next presentation to be at the largest open source conference in the world (FISL in Brazil in April), that's really what matters.
One of the things I discovered is that I can neither cut-n-paste from Keynote, nor type very fast. So I think the next time I do this talk, I'll pull a "Julia Child" and have "the cake already finished in the oven". I'll start to enter the code, and then switch to one already finished to skip the rest of the boring typing, unless there's a point to it. I have to work out the details of that, but I'm confident that there's some way to do it nicely.
Some of the attendees stayed around afterwards for a bit more detailed feedback, and I appreciated that. During this conversation, I observed and shared that my dozen years of experience as a leading Perl lecturer and writer are proving useful in determining how to present Smalltalk and Squeak and Seaside. My dedication to finding the sweet spot between free/open source and commercial viability has worked well for Perl, and I am sure I can bring that same skill set to the Smalltalk world as well.
If there is any year for Smalltalk to regain a commercial visibility, this will be it. I mean, look at all the things coming together:
- the OLPC XO is putting Smalltalk into the hands of thousands of young kids
- Cincom and Gemstone are stepping up to support Seaside in a big way
- Gemstone is offering the single-instance free commercial license and GLASS quickstart appliance
- Squeak's license is finally getting cleaned up
- Seaside is reaching a nice level of maturity
- Seaside running on GNU Smalltalk for those that want a command-line environment
- Croquet is maturing, even being adopted as a commercial "virtual meeting" space
- Ruby on Rails has reestablished dynamic languages as useful for the web
Looks like we really have an opportunity here. Carpe Diem!
With GNU Smalltalk 3.0 having just been released, there's a bit of buzz about it. But, I'd caution anyone who is contributing within the Squeak community on an ongoing basis to stay away from GNU Smalltalk.
The problem: GNU Smalltalk appears to be released under the GPL (which seems natural). The GPL taintedness of the code in the GNU Smalltalk distribution therefore would apply to any derived products. If you take something you create as a result of looking at GNU Smalltalk code, and put it into a Squeak distro, some would argue that this is in fact a derived work. It's no longer compatible with the current Squeak license, and taints the entire distro.
For example, let's say you like the Generators of GNU Smalltalk, so you look at how it's implemented in the GNU Smalltalk distro. Now you write the same methods (or close enough) and contribute it to Squeak 3.10. Oops. Now Squeak 3.10 is GPL-tainted.
So, while it's probably OK to look at the protocol and documentation of GNU Smalltalk, we must be very careful not to taint the contributed code by looking at the implementations. Keep a clean-room distance from it.
Ouch.
Damn GPL.
Update: My declaration resulted in quite a stir on the Squeak-dev mailing list. I think the best post that puts actual facts and findings to my warning is one from Joshua Gargus:
LGPL code is completely unacceptable for inclusion in the main Squeak
distribution, and doubly so if it is code that the FSF holds the
copyright to. RMS was unwilling to elaborate on the interpretation of the LGPL for image-based systems such as Squeak. In his view, including a single LGPL class makes the entire image into a "derived work" that can only be redistributed subject to the restrictions of the LGPL.
