* The Business of Software

A former community discussing the business of software, from the smallest shareware operation to Microsoft. A part of Joel on Software.

We're closed, folks!

Links:

» Business of Software FAQ
» The Business of Software Conference (held every fall, usually in Boston)
» Forum guidelines (Please read before posting!)

Moderators:

Andy Brice
Successful Software

Doug Nebeker ("Doug")

Jonathan Matthews
Creator of DeepTrawl, CloudTrawl, and LeapDoc

Nicholas Hebb
BreezeTree Software

Bob Walsh
host, Startup Success Podcast author of The Web Startup Success Guide and Micro-ISV: From Vision To Reality

Patrick McKenzie
Bingo Card Creator

Smalltalk Anyone?

I recently asked a question about if anyone was still using VB6 for new development and got some great responses. Now, I have one last question on this type of subject...

Does anyone use Cincom Smalltalk for any uISV software development? I am attempting to learn Smalltalk this year as one of my goals.
Noble D. Bell Send private email
Thursday, February 14, 2008
 
 
It has been a few years (4) since I touched Smalltalk. My feeling at the time was the most commercial users were using VisualAge (which at the time was scheduled by IBM for end-of-life...) and most hobbiest seemed drawn to Squeak.

Smalltalk is a beautiful and easy to learn language. Semantically, java is its offspring even if not syntactically. When I first saw Ruby, all I could think was "oh you silly kids trying to re-invent smalltalk, how precious."

While it is a fun and productive language to learn, and I think everyone should be exposed to it, the reality is that for new commercial work I can't recommend it -- just not enough availability of people who know it or who are willing to learn.
Former Smalltalker...
Thursday, February 14, 2008
 
 
I don't have any experience in smalltalk, but I have wasted a lot of time trying to fit square pegs in round holes. (Writing complex windows GUI stuff in python, because I wanted to use python). So I would definitely encourage you to use whatever language give you the best stack of tools to solve your problem. That may be smalltalk, or it may not.
Starr Horne (ChatSpring) Send private email
Thursday, February 14, 2008
 
 
Perhaps give Squeak a look. Its an open source version of Smalltalk.
Squeak fan
Thursday, February 14, 2008
 
 
I have been playing with Squeak. I just don't see that it can be used for a commercial product like Cincom. Don't get me wrong, Squeak is very cool but I don't see how you can create a standalone app or OS-specific GUI's with it like you can in Cincom.
Noble D. Bell Send private email
Thursday, February 14, 2008
 
 
Smalltalk is fun, but the execution speed has been far to slow for things I have had to do professionally :-(

Similarly, I love Scheme.  Small simple language that can do/emulate all major programming models in.  Yet it is too slow for what I need to deliver :-(

I have played with the idea of creating a language based off of Scheme, but is targeted at commercial development.

You know.  If you like Smalltalk and want something better suited for commercial development you might want to look at Objective-C.  This is a much overlooked language (unless you do development on OSX) that, IMHO, never got the respect it was due.  It blends C and Smalltalk syntax and semantics.  Objective-C++ goes one step further blending C++ and Smalltalk syntax and semantics.

Objective-C/C++ is available for free too!
CodeWank
Thursday, February 14, 2008
 
 
I can't see myself tying a product to a commercial platform created by a relatively small vendor, specially in a language that has been dropped by other vendors, but if you see enough benefits over more popular choices and feel brave enough, then why not?
rubinelli
Thursday, February 14, 2008
 
 
I am a huge Smalltalk fan. I have met many others that also used to swear by the language. For all means, if you want to learn a new language for 'widening your horizons', Smalltalk is a great choice. But I would not consider it in a business environment. It had its time, but that is now gone.

Smalltalk could have been Java, but the fragmentation across vendors/platforms didn't allow it. People say it was the unusual syntax that prevented it from becoming more popular. I say it was the lack of portability.
Rafael Chaves Send private email
Thursday, February 14, 2008
 
 
Well, speaking for the vendor in question (Cincom):

-- We have many people writing software they then sell to others with Cincom Smalltalk

-- We are profitable, we are expanding our development staff (we are in the midst of hiring 3 new developers right now), and our sales are growing year on year.

-- Seaside is one of the two most interesting things going on in web development right now (RoR being the other).  It's no surprise that both are coming out of the dynamic language camp.  Oh, and Seaside is cross Smalltalk, open source, and is now supported by two different Smalltalk vendors (Cincom and Gemstone)

-- Overall, Cincom is a $100M + software company, with multiple non-Smalltalk business lines.  We aren't a small company.

Visit us here, and try the product yourself:

http://www.cincomsmalltalk.com


James Robertson
Smalltalk Product Evangelist
James Robertson Send private email
Thursday, February 14, 2008
 
 
I have Cincom NC version downloaded and installed. I have been toying with it off and on for about 2 years. I just now have finally made-up my mind to attempt learning it this year. I just wanted to make sure that by learning Cincom's version of Smalltalk that I would be able to market a product when I was able. It appears that I will be able to once I learn the language and purchase a license.
Noble D. Bell Send private email
Friday, February 15, 2008
 
 
Rereading what I wrote I see I sound more pessimistic than I intended. The royalty-based license looks a little unusual to me, but at least it minimizes the developer's risk.

Since you have already made up your mind, good luck with your new product, and please don't forget to tell us if Smalltalk works for you.
rubinelli
Friday, February 15, 2008
 
 
So far CodeWank has had the best REAL WORLD suggestion for a Smalltalk lover.  Switch to Objective-C/C++.  You get most everything you had in Smalltalk (including syntax!!!), but you can build full-on commercial quality executables.  You can also easily integrate with other C or C++ libs.

Smalltalk was great.  I loved it too.  But come on folks the era of pure Smalltalk is over with.  Dead even.
Larson Send private email
Friday, February 15, 2008
 
 
Larson,

For Windows, you can ship an exe.  For Mac, you can ship an app bundle.  For Windows, Linux, and Solaris, you can ship a DLL that is callable from C.

Smalltalk isn't dead, and you are spreading misinformation.

James Robertson
Cincom Smalltalk Product Evangelist
James Robertson Send private email
Friday, February 15, 2008
 
 
Hi all,

I work for a major shipping company. We have a massive OODB and Smalltalk Application (500 gig range) with 3 million lines of code. We have 2000 plus daily users. We can do 700 transactions a second before slowing down. We also have a Java + SQL +EMS system. On a good day they can do 70 transactions a second, with three times the hardware.

  --Timo
none
Saturday, February 16, 2008
 
 
Squeak is pretty off-putting as an environment to spend a lot of time working in. It seems like the only other realistic cross-platform Smalltalk choice is Cincom. 

Their pricing model is raising some red flags, as in, where is the information?  The only thing I could find looks like an old off-hand remark that does more to obscure the pricing than inform.  Is there a flat rate or are they still doing the "I want to be a part of your revenue stream"?  How is pricing handled for web applications?  I'd hate to download it, try it out and love it, then get hit with some scary fees.
Curious About Cincom
Saturday, February 16, 2008
 
 
I work for a smallish (7 developers) Smalltalk-only company. The vast majority of our products is built with Cincom's Visualworks Smalltalk dialect.

Since I wast trained on Smalltalk almost ten years ago I found that I lost interest in using other 'interesting' languages. There are a lot of interesting developments in algorithm specification in those language but they all operate in what Smalltalkers somewhat snearingly call 'dead code' mode: you edit a text file, perhaps have a compilation step and then run your application: it goes through initialization etc until it hits a breakpoint - the place you as developer should be concentrating on. Smalltalk (and some other environments like Lisp) operate on 'live' code, some IDE's nowadays inch towards live code mode calling it 'edit-and-continue' but the big difference is that Smalltalk has started out with live code as a requirement from day one, so it works in all circumstances whereas edit-and-continue only works in limited cases. So whereas large industries have sprouted around enhanced algorithm specification (DSLs, AOP, Model driven - you name them) Smalltalk optimizes a much more important aspect: developer interaction with evolving code. This extra power alone makes Smalltalk very interesting for small shops - it saves time and hence money.

VisualWorks Smalltalk has a spotted history in that its company (ParcPlace-Digitalk) decided to shoot itself through the head, fortunately Cincom -a much more robust company- picked it up making it very unlikely that VisualWorks will suddenly be sunset.

ViualWorks is open source (only the Smalltalk libraries for non-commercial users, also the VM for commercial users) wich we have found to be invaluable for blame assignment in the light of bugs. Often we find that if blame lies with the provided libraries it is faster to fix the bug ourselves than to write up a support request email! Again a very important point if you are a small shop.

One of our applications is an energy trading platform, parts of which have a stringent bug-fix time requirement: 15 minutes from bug report till fix or our customer gets hit with crippling fines. Those applications are deployed without sealing them, so when we get a bug report we connect to the machine and see an open debugger on the thread that failed while the rest of the application happily purs along; we modify the code and/or data in the debugger and hit the continue button, nearly always within this 15 min time frame. We then code up a permanent fix in our shop and hoist this permanent patch in the production server /while/ it is running. Again something that is mostly impossible in dead-code systems.

There is a whole slew of libraries that come with VisualWorks, like O/R mapping to several databases, support for a heavy-duty OODB (Gemstone), XML, COM-connect, SOAP, etc, etc.  It runs byte-identical an a lot of platforms (14 last time I looked), you can look up all the other product features on the Cincom web site.

Of course Smalltalk has weak points: number crunching and image manipulation are slow, but since VisualWorks easily connects to dlls you can use more suitable languages for such routines.

Another weakness is that VisualWorks runs in one OS process, so it does not automatically utilize multiple cores on modern machines, you will have to manually partition your application into multiple Smalltalk VM instances that communicate via sockets (IP or Unix domain) or files.

There is much more to say but I'll stop here with a boot note for all those Objective-C aficionados saying it incorporates Smalltalk syntax: it does not!
Fortunately a tool recently sprouted for Cocoa developers that  adds partial 'live code' support as well as full Smalltalk syntax support to Cocoa. See www.fscript.org for a valuable Cocoa developers tool.
Reinout Heeck Send private email
Saturday, February 16, 2008
 
 
A few years back me and an industrial engineer built a shop floor control system in Smalltalk/V 286.  I did all of the coding, but the system wouldn't have existed without Bill West (you out there Bill?).  This system scaled in a couple of ways which would surprise many.  First of all, it was running on top of a 486 processor with only 16MB of RAM.  This single machine drove a couple of dozen simultaneous terminals and printers.  It managed order quotations, engineering, shop workflow, reporting (it had its own mini SQL-like reporting language), email, reorders, and more 24/7.  Performance was very acceptable, and snappy, and I didn't even have a profiling tool.  :-p  This was not a modern Smalltalk VM, but an older byte code interpreter.  No dynamic translation or polymorphic inline cache.  VisualWorks would run circles around Smalltalk/V 286, and Squeak would probably beat it too.

The other special quality that scaled was as Reinout Heeck put it in his post, "live code".  My original implementation attempt was in C.  I only got to the toy application stage because deployment was hard.  With Smalltalk I was able to build the system as it ran.  Some people might think this would be a nightmare but in fact it was absolutely great.  While people used it, new features just appeared.  I didn't need to reboot the system or schedule downtime.  I could watch what was going on from my desktop and make changes.  If a runtime error happened, a debugger would appear right in front of me.  I would usually just fix the problem right there.

Smalltalk has many features of an operating system.  It has its own process model for example, and you can customize it.  This is amazingly useful for building multiuser systems.  Seaside takes advantage of this in great ways.  I wish I had Seaside when we were building the shop floor control application.
Carl Gundel Send private email
Sunday, February 17, 2008
 
 
On pricing: Cincom (as a company) does not publish pricing.  That's not my call, but it's the way it is.  Having said that, we run three models:

1) Per user (used for classic client/server apps)

2) Per CPU (for server/web server apps deployed in house)

3) Royalty model (for where you derive revenue from Cincom Smalltalk apps you sell or provide as a service)

People deploying web apps normally go with (2) or (3), depending on the situation.

James Robertson
Cincom Smalltalk Product Evangelist
James Robertson Send private email
Sunday, February 17, 2008
 
 
"Cincom (as a company) does not publish pricing"

Classic arrogance. Keep 'em guessing!

Fortunately the crown jewels (Seaside) doesn't require Cincom.

Monday, February 18, 2008
 
 
I don't see a problem with not posting the price. That way only serious people would inquire and yes, it does keep the competitors guessing. Nothing wrong with that in my book.
Noble D. Bell Send private email
Monday, February 18, 2008
 
 
Along side with the major shipping company, we are a major commodities exchange using GS and ST and while our operational DB is small (about 5 GB at the start of the trading day to less than 75 GB and the end) we are probably one of the fastest.  We easily handle transaction rates approaching 6000/sec with about 8000+ daily users.  Our average data center round trip times are in the 2-3 ms range.
GemStone Weenie
Monday, February 18, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz