For example...
1. I think wrapping the database records as objects in Magik provides for realistic real-world
modelling.
2. Long transaction support is still an industry leader.
3. External access to VMDS has a performance bottle neck in Magik.
I would love to read your comments pro/con in the comments of this blog. Or you can send me an e-mail directly. If there is a lot of response, I can set up a wiki page at http://www.gesmallworld.org that lists the advantages/disadvantages.
Posts
3 comments:
I have a limited experience with ESRI products, but the network modelling is a lot nicer.
I also like the real-world object idea where one models an object with one or more geometry. Last I used ArcInfo (9?), it still thinks in one geometry = one object.
Version management is way and above anything else I have used, especially compared to ESRI's implementation in SDE.
Negatives:
Same-server performance between swmfs and Oracle is no comparison. Smallworld's database ain't so fast.
Development environments are far more expensive than other environments.
Real pain to inter-operate with other systems or code written in other languages.
Magik is still slow. I kind of wish they'd invest in just-in-time compiling using something like http://www.llvm.org/ or http://www.gnu.org/software/lightning/
Nice map styling/rendering would be nice.
Interfacing with the underlying OS is a pain.
You mention the swmfs server is slower than Oracle. I'm going to object to that. The spatial scanning of the database i believe is the best in the industry.
As for development costs, I think the runtime compiling is the most beneficial part of of magik. Development costs are probably half of anything else I've used.
As for OS interoperability. You must not use python or java. They are just as a pain in the rear. Anything non native will always be difficult to get to core OS functionality.
Hi Mark: We used emperical data. Using the exact same AIX server in Development (so there was no other users to skew results), we did an extract via SmallWorld/swmfs which took 2+ hours. We then exported the table in its entirety to Oracle 10g and did the same query/extract. Took less than a minute.
For spatial, we set up time trials of various things, and I don't know your situation, but a properly set-up Oracle spatial table is at least as fast as swmfs, and in some cases (point data), faster. We even tried exporting all our poles into an Oracle table then used SmallWorld's Oracle spatial connector to add it as a dataset. Rendering time for several thousand poles were indistinguishable.
For development environments, I am referring to the actual $$ costs. For the base cost, all we get is emacs. For 1499€, one could buy MDT. For $1100, I can get Visual Studio Professional with even more features.
Smallworld bought the Magik Debugger a few years ago, but then sold it for such an exhorbitant price that most people didn't touch it and stuck with write statements. That's the cost I am talking about. Personally, I think SW should have shipped it free, but I digress...
The immediate mode development environment is, of course, excellent. It was one of the best features of the original SmallTalk and definitely shows its value in Magik. I've written code at the Magik prompt then copied and pasted it into my method. :-)
Other languages: I have a lot of experience with other languages and inter-operability. 20+ years: 10 years in Magik alone.
I spend most of my time these days working in Java, .Net. I use Python a lot interacting with the OS. Python has a lot of libraries to make it nearly painless. Magik still has no native ability to declare an interface to a DLL or even a UNIX library. That single feature alone would make a lot of my problems go away. The Automation interface we currently use is too heavy-weight (read: slooow), and an ACP is overkill for a single method call.
Although attending the session on GSS at the conference, I was impressed with the SOAP calling client. Sort of surprised it's a module in GSS instead of core. Just an odd decision, imo.
Post a Comment