I'm with Dan Gillmor on this steroids topic. Can anyone be surprised at the recent news? "Athletes use performance-enhancing drugs! Read all about it!"
The Oregonian today devoted half of its front page to the topic. Unbelievable priorities in journalism. Is there nothing else more important for us to be aware of? (Interestingly this topic apparently is not important enough to go on their web site.)
Over in the comments on this item pleading for better closures in Java, a reader suggests Groovy will satisfy some of those needs when it becomes stable. My comment in return is, why wait?
Why wait for Groovy? Scheme is in production already in the JVM.
SISC is a complete and efficient Scheme.
JScheme is less complete and efficient, but simpler and useful for its integration with Java.
Patrick K. O'Brien, Orbtech, writes in a comment...
Keep your eye out for two Python projects that will have major releases in the next couple of weeks: Pypersyst is a prevayler-style persistence mechanism for Python. Schevo is a full-blown ODBMS and Application Framework written in Python that can store Python objects in Pypersyst, ZODB, or Durus (including the ability to switch between storage backends, and the ability to use different backends for replicas). And it has many other goodies (like incredible support for schema evolution and object migration) that you'll simply have to wait to hear about.
Edd Dumbill reports on unmet expectations that Binary XML would cause more of a raucous response.
My off the cuff theory is that by now every developer on the planet has implemented at least one kind of kludge for sending their own encoding of XML over the wire more efficiently the default bulky representation format that is XML. Because the problem has been solved just good enough by their own quick hack, developers might easily assume a standard binary format for XML would be trivial.
My favorite approach was, is, and probably ever shall be Lisp. Convert from XML to Lisp format. Convert to binary if necessary. And use an efficient, incrementatal protocol if needed beyond that. (One reasonable example is found in that wonderful journal, Software Practice and Experience, in a paper called "Efficient Binary Transfer of Pointer Structures". (PDF)
In any case, my response is to just kind of chuckle. There are a number of variables in choosing a binary representation of semi-structured data intended for various uses. This is not a one-size fits all problem, XML is a simple idea complicated by a wide range of intentions.
Ian Bicking writes in a comment to an earlier post about "issues" with certain anachronistic databases (e.g. ZODB and Berkeley DB)...
RDBMSs and flat files are the two true ways, because they are somewhat less broken than other things!A Smalltalk image works well as a simple object database because it is fairly simple: in-memory, simple process model (e.g. no complicated conflict resolution). Prevayler could become a simple extension of this, and the capability/complexity trade-off grows from there.
I agree with Ian's sentiment. The relational model is better than credit is given from the object-oriented programming community. The main problem is not the relational model per se, but the language implementation (i.e. SQL) is not so compatible with the more modern languages we use (even Smalltalk and Lisp, which pre-date SQL by a fair number of years. I agree with other voices that the Object-Relational Mapping problem is not worth spending too much time worrying about.
Even with SQL's shortcomings, the range of reliable implementations is nothing to shake a stick at. And flat files in basic file systems are tried and true, not a lot of moving parts to worry about for a good many scenarios.
Newer implementations of relational databases do address some of the language issues. (e.g. Derby nee Cloudscape and the even simpler Hypersonic SQL on the language issue, Postgres on the some of the O-R mapping issues). But some down to the roots rethinking of the implementation of relational databases could fuel them up for the years ahead.
(By the way Ian, I am interested in this comment and intend to respond. I just haven't taken the time yet to get into the detail required.)
Ian Bicking writes in a comment on my blog...
I really don't see how Smalltalk is better. It has blocks, and that's cool, and you can use them in several interesting ways. But in many ways its model is more rigid. Well, maybe it's more appropriate to say that its representation of source is more rigid, specifically the IDE. I can imagine Smalltalk objects that are completely general and not particularly related to classes. But I can imagine block objects in Python; in both cases, there's no good way to represent them (traditionally) in source.Python has some flexibility that Smalltalk tends not to because of its imperative style. Since each Python module is a script, you can program how the objects that are constructed. Decorators are one obvious example of this -- and something where syntax was added for aesthetic effect, but the semantics were already well worked out, and fit into Python's model just fine.
Because Smalltalk has declarative source, there's not as much room for building objects on the fly. Again, you can do it, but it's not nearly as comfortable.
In the end, it doesn't seem like Smalltalk is an evolving language, and there's no one to even go to to ask for new features (who would realistically respond in a positive way). So it's hard to compare; in all of these languages, you can cope somehow. You can always do code generation, after all. In evolving languages there are options besides coping; that people respond to that and ask for changes doesn't indicate a more flawed language.
Update:
Socinian writes in a comment...
[An image is] just not a multi-user database. Make every image multi-user and every running image a server and Smalltalk will soar. Think in terms of the Chandler project. Everyone's a producer, consumer, and database.Essentially Gemstone/S is a highly scalable, distributed multi-user "image". (And a good bit more.) No doubt there is a lot of value in this concept. But the concurrency complications go way up as well. Maybe the simplest form of this idea is a Smalltalk implementation of Prevayler.
Original:
Ian Bicking writes in a comment on Avi Bryant's blog...
To me, the image seems very challenging from a usability point of view. Images are monolithic, while most version control systems work on filesystems which are rather distributed. You can have two branches or checkouts sitting along side each other, and tools can access either just fine, compare, contrast, etc. In Smalltalk that's two discrete systems. Maybe if you could run select code in a specific branch, while the rest of the system remained in a different branch. But that seems infeasible, and even if it wasn't, since it's utterly inconcrete it's also rather opaque.Smalltalk-80 was designed to put the tools and the objects they evolve into one image. ANSI Smalltalk was designed to support a "firewall" if desired between the tools and the objects they evolve.
Either way, I think it is not helpful to combine discussions of "the image" too closely with discussions about "version control". Smalltalk version control is typically done independent of the image. The image is where specific versions of things are installed to provide specific executable capabilties (e.g. an application). Various images can have various versions of various things installed in them.
That said, an image *can* contain things which "do version control" and often the things they version are things in that same image. But "the image" and "version control" are really independent things.
Since there can be many images, let's not talk about "the image". Better to think about images as simple, yet powerful object-oriented databases.
Things in an image can be made from specific versions of things that originate in some version control system, just as things in a Zope Object Database can be made from specific versions of things that originate in some version control system.
What if a Zope Object Database were even easier to use than it already is? What if you just had one ready by default and your application was automatically a part of the database, and all your favorite tools were automatically able to inspect and update that database?
That's kind of what should come to mind when thinking about "the image".
Mark Baker writes...
[If] we want to enable a world of indiscriminate consumption of remote third party services, we need to do so in a manner similar to other systems which have done just that, like the Web, email, instant messaging, etc... Namely, by using a constrained interface, and embracing (application) protocol dependence.
