Smalltalk - What Smalltalk product/implementation would you use, and why?

Author

What Smalltalk product/implementation would you use, and why?

enigmainorlando@aol.com

2006-04-01, 4:01 am

I am curious as to what version of Smalltalk would you use to implement
some generic application, and why would you choose it? I am mostly
interested in comparing Visual Age, Visual Works, ST/X, Gnu, and
Dolphin, but you can throw other versions into the discussion as well.

In particular, I'd like to know what you think about the "robustness"
of the version and "solidness" (and "advanced-ness") of the virtual
machine, performance, ease of use, "completeness," and functionality of
the implementation, but you can throw in whatever other metrics sway
you to a particular version as well.

This is not an attempt to start some war over which version is "better"
or "best," I'd just truly like to know what people think about the
various major (or other) versions out there, and which one they would
choose to develop with (if they could choose), and why. I also
understand that some versions may be better at some things, and others
at others, so it depends on what "generic application" you would be
implementing, but we'll just do the best we can with the discussion.

Thanks.

Hans-Martin Mosner

2006-04-01, 4:01 am

Dan Antion

2006-04-01, 7:04 pm

enigmainorlando@aol.com wrote:
> I am curious as to what version of Smalltalk would you use to implement
> some generic application, and why would you choose it? I am mostly
> interested in comparing Visual Age, Visual Works, ST/X, Gnu, and
> Dolphin, but you can throw other versions into the discussion as well.
>
>
We have chosen to use VisualAge and Dolphin. We use VisualAge for our
more complex business applications. Database connectivity is strong and
the native look and feel of VisualAge, coupled with the add-ons that
Instantiations provides enable us to deliver applications that look, and
act like the other applications on user desktops (Windows) - this is
very important to us. The class library is extensive and I am confident
that Instantiations will continue to improve this product, and quite
honestly, I don't find it lacking anything critical right now.

Their (Instantiations) previous work on the development environment
tools and libraries speaks to their capabilities and commitment to
quality. There is also a wide array of add-on libraries available from
TotallyObjects, which leaves you with an extremely powerful development
product. We haven't found anything we needed to do that we couldn't do
in VisualAge.

I am also hoping not to begin a flame war, but I will add that we would
rather pay a fixed cost for the application environment and avoid having
to pay runtime fees.

We use Dolphin for a number of smaller applications and utilities where
its speed on Windows is considerably better (like working with graphics
for example) than a cross platform product. Dolphin is inexpensive by
comparison to VA and VW, fun to work with, but it probably isn't as
robust out of the box. That said, the Dolphin community has filled the
void with a large array of add-ons and goodies, most of which are free,
well maintained and rock solid. Even the add-ons that you have to buy
are priced relative to Dolphin, so you are still looking at a very
reasonable price, albeit Windows only. The Dolphin community is also
very _very_ helpful when you need help or advice. The latest version of
Dolphin shows a commitment to the product and a distinct willingness by
the folks at Object Arts to listen to their users.

I hope that helps,
Dan

Marten Feldtmann

2006-04-02, 4:07 am

enigmainorlando@aol.com schrieb:
> I am curious as to what version of Smalltalk would you use to implement
> some generic application, and why would you choose it? I am mostly
> interested in comparing Visual Age, Visual Works, ST/X, Gnu, and
> Dolphin, but you can throw other versions into the discussion as well.

I've used VisualAge for the last seven years and I would stay at
that - whenever it is possible. Though it is portable. I would
say, that the best ports of this product are the ones for Windows
and OS/2. I also like the Solaris version, but the Linux version
is not quite good as it should be.

VisualAge was a tool for large customers - if there are lots of
developers it's not easy to find them. Some are in the newsgroups,
but most of these developers are not public ....

VisualAge is the last product using ENVY - and I love ENVY. But
the product needs more support and more features and I deeply
hope, that Instantiations has the power to make that product shine
again.

They cancelled support for OS/2 (staying at 6.01) and HP-UX (at
6.03 ?) with the 7.0 version, leaving it on Windows, Sparc Solaris,
AIX and Intel Linux. The OS/2 is still a nice system running under
all Warp versions and under eCS 1.x .

Some goodies are there - not supported (UML Designer, Multimedia
and the RDBMS mapper) - showing, that it is very difficult to
support all the stuff, IBM has done in the past for that system.

VisualWorks is a solid product, the biggest problems are the GUI,
but introducing Pollock will give here better results in the
future. VW has a large community and you find developers here and
there working with that tool.

Considering Pollock I would perhaps switch to VisualWorks - but
due to the runtime fees (or whatever you call it) I'm not
willing to do it.

Squeak is a tremendous project and I also looked several times
to switch to Squeak - but to be honest - the GUI is strange.

Dolphin is ok, without any question. Active user base - but of
course: no portability. But for Windows users it's a good
solution.

ST/X is another interesting project and is a very good solution
under Linux and Unix. Though it works under Windows, it still
has a few technical problems there.

Marten

--
Marten Feldtmann - Germany - Software Development
Information regarding VA Smalltalk and DMS-system
"MSK - Mien Schrievkrom" at: www.schrievkrom.de

Boris Popov

2006-04-03, 7:07 pm

Marten Feldtmann wrote:
>
> Considering Pollock I would perhaps switch to VisualWorks - but
> due to the runtime fees (or whatever you call it) I'm not
> willing to do it.
>

I still find it interesting how much resistance there is to such
licensing model. If you build a product that makes you money, why
wouldn't you want to pay a tiny, and I do mean tiny, share of proceeds
to the company that provides you a tool knowing that they will use that
money to improve the tool even more to enable you to make even more
money?

Its quite a common occurrence outside of IT too. If I were, say, a
custom part manufacturer and needed a laser cutter to produce the parts
for sale, I wouldn't mind having that cutter on site for $0 but pay
back 3% of my profit back to the manufacturer that provides the
hardware and support w/o charing a penny extra. The fear of royalties
is overhyped as far as I'm concerned, especially given how reasonable
Cincom sales department is when it comes to calculating them. If you
ship a product whose value is 90% in the backend and only uses VW
occasionally for the other 10% of the value and the product sells for
$1,000 you would only have to pay royalties on the 10% of $1,000 which
is $100. So 3% royalty would be $3 per $1,000 sale. Sounds good to me
:)

Cheers!

-Boris

Dan Antion

2006-04-03, 7:07 pm

Boris Popov wrote:
> Marten Feldtmann wrote:
>
>
>
> I still find it interesting how much resistance there is to such
> licensing model. If you build a product that makes you money, why
> wouldn't you want to pay a tiny, and I do mean tiny, share of proceeds
> to the company that provides you a tool knowing that they will use that
> money to improve the tool even more to enable you to make even more
> money?
>
> Its quite a common occurrence outside of IT too. If I were, say, a
> custom part manufacturer and needed a laser cutter to produce the parts
> for sale, I wouldn't mind having that cutter on site for $0 but pay
> back 3% of my profit back to the manufacturer that provides the
> hardware and support w/o charing a penny extra. The fear of royalties
> is overhyped as far as I'm concerned, especially given how reasonable
> Cincom sales department is when it comes to calculating them. If you
> ship a product whose value is 90% in the backend and only uses VW
> occasionally for the other 10% of the value and the product sells for
> $1,000 you would only have to pay royalties on the 10% of $1,000 which
> is $100. So 3% royalty would be $3 per $1,000 sale. Sounds good to me
> :)
>
> Cheers!
>
> -Boris
>
Obviously I can only speak for my own company's situation, but in our
case, we simply don't want to have to involve another party in our
decisions to distribute software. We mostly develop software for our own
internal use. But, sometimes we make this software available to others
and sometimes we might make this software available to others to use via
the web.

If there were no other alternative, we may find the Cincom model
acceptable, but there are alternatives, so...

To use your example, I would rather but the laser cutter, pay to have it
maintained, even if that required an annual maintenance contract, use it
as much as I want and not have to discuss my sales with anyone. That
way, my cost is fixed, predictable and, more importantly, I can
accurately budget for it every year. I know how much VisualAge is going
to cost me in 2006, I know how much Dolphin is going to cost in 2006. In
both cases, the number will exactly match my budget, regardless of what
I do with either product. Performance, relative to that budget, is one
of the ways I am evaluated.

Dan

jarober@gmail.com

2006-04-03, 7:07 pm

Dan,
I understand the objection. For apps used internally, Cincom
Smalltalk does come at a predictable annual cost - the royalty model
only applies to entities selling applications beyond their corporate
walls. In the case you outline, where you offer software free to
others, licensing would be their problem, not yours.

Dan Antion

2006-04-03, 10:03 pm

jarober@gmail.com wrote:
> Dan,
> I understand the objection. For apps used internally, Cincom
> Smalltalk does come at a predictable annual cost - the royalty model
> only applies to entities selling applications beyond their corporate
> walls. In the case you outline, where you offer software free to
> others, licensing would be their problem, not yours.
>

We've had this conversation before, and I <think> I understand the
model, but in our case, when we provide the software, we don't want the
ultimate user to have a licensing problem - they would be our business
partners and we would be doing them a favor.

Marten Feldtmann

2006-04-04, 4:11 am

Boris Popov schrieb:
> Marten Feldtmann wrote:
>
>
>
> I still find it interesting how much resistance there is to such
> licensing model. If you build a product that makes you money, why
> wouldn't you want to pay a tiny, and I do mean tiny, share of proceeds
> to the company that provides you a tool knowing that they will use that
> money to improve the tool even more to enable you to make even more
> money?

In the past my managers do not like to talk to other (unknown)
persons about the money we get from our customers. One has to
remember, that one NOT only has to pay for the software - but
for all other work around that (support contracts, learning
courses and all that stuff).

It is not clear if you have to give Cincom the rights to
look into your books, your list of your customers etc.

The comparision with manufacturing is (in my case) wrong. I'm
in the steel market and we nearly would never give work to
others for an unknown amount of money. We are looking for
subcontractors and we tell them, what we want and they tell us
a fixed price and then we decice who gets the job.

Actually we do not care, if our subcontractors improve their
company or their producting engines. They have a contract with
us, telling them what do, telling them to cover any ISO
standards etc - if they make it well, ok, perhaps they get the
next job also. The subcontractors decided for himself to improve
their machines and to lower their production prices - they
make it for themselves - not for us.

I admit, that there are other manufacturing jobs, where you
might have to pay fees for patents you are using ....

Another question is: what is a tiny share ? In our production
market we have (in average) a total win of 5% in every
contract - sometimes less. You might see the Cincom numbers as
tiny shares. My managers might have a total different view
about that.

Another side I also admit: Cincom made it possible to make
money again with Smalltalk and they are very customer oriented!

Perhaps better than any other VW owner before.

Marten

--
Marten Feldtmann - Germany - Software Development
Information regarding VA Smalltalk and DMS-system
"MSK - Mien Schrievkrom" at: www.schrievkrom.de

Boris Popov

2006-04-04, 7:05 pm

To be honest I'm not sure what you mean by having to involve another
party in your decision making process. You absolutely don't. Why would
Cincom care how you distribute your software? Internal apps can be
licensed w/o involving royalties AFAIK and others you can sell at your
discretion. All you have to do at the end of the year is cut a check
for the agreed royalty on the sales that you've made (be it your
partners at reduced rate or customers picking up a full price) to
Cincom and mail it off. No? If you don't sell any - you won't be
penalized by Cincom, thats why you pay per developer free up front
(which is applied towards the royalties amount, not added on). Did I
misunderstand what you're saying?

Boris Popov

2006-04-04, 7:05 pm

Right, which is fine, but why can't you just sell it to your partners
at reduced rate? If you sell it online for $1,000 and to your partners
for $100 then pay the royalties on $100, would that be a problem?

Dan Antion

2006-04-04, 7:05 pm

Boris Popov wrote:
> Right, which is fine, but why can't you just sell it to your partners
> at reduced rate? If you sell it online for $1,000 and to your partners
> for $100 then pay the royalties on $100, would that be a problem?
>

Again, if had to do something like this, I would.

I'm not saying Cincom's pricing model is bad or unfair. I'm simply
saying that I prefer what I see as the less complicated alternative, but
keep in mind, that isn't the only reason I choose VA over VW. I just
point it out because, if it matters to us, it might matter to someone else.

The original question was asking what environment we use and why? If
VisualAge didn't exist, I might work with VW. I try to stay relativelive
current with the NC versions so I am aware of how hard it would be to
port applications from VA to VW. I also look to see how hard it would be
to port VA apps to Dolphin. The first application I wanted to port, a
graphics application that was running too slow under VA, I ported to
Dolphin because it was a Windows app, and the native widgets are
identicle to those in the users' other applications. So, it's not just
the runtime fees, it's the whole picture.

The biggest issue of them all is the fact that I'm in VA now, I have
years of work and many applications already installed and being
maintainted - why would I want to change?

Dan

Dan Antion

2006-04-04, 7:05 pm

Boris Popov wrote:
> To be honest I'm not sure what you mean by having to involve another
> party in your decision making process. You absolutely don't. Why would
> Cincom care how you distribute your software? Internal apps can be
> licensed w/o involving royalties AFAIK and others you can sell at your
> discretion. All you have to do at the end of the year is cut a check
> for the agreed royalty on the sales that you've made (be it your
> partners at reduced rate or customers picking up a full price) to
> Cincom and mail it off. No? If you don't sell any - you won't be
> penalized by Cincom, thats why you pay per developer free up front
> (which is applied towards the royalties amount, not added on). Did I
> misunderstand what you're saying?
>

I just meant that I prefer working with products that I simply purchase
and use. If I want to maintain VisualAge, I sign up for maintenace, I
budget the cost and I'm done. There is nothing to settle up at the end
of the year, nothing to agree to.

I just see it as a simpler model, and, to be honest, it's the same model
as all the other software we use so it's easy to explain, easy to budget.

Dan

Marten Feldtmann

2006-04-05, 4:07 am

Boris Popov schrieb:
> To be honest I'm not sure what you mean by having to involve another
> party in your decision making process. You absolutely don't. Why would
> Cincom care how you distribute your software? Internal apps can be
> licensed w/o involving royalties AFAIK and others you can sell at your
> discretion. All you have to do at the end of the year is cut a check
> for the agreed royalty on the sales that you've made (be it your
> partners at reduced rate or customers picking up a full price) to

Internal applications are handled by a complete different model
and you have to pay for that - and its much more than the EUR 500,
which is pretty ok for the service you get from them. Perhaps most
people do not do this - but that's another story.

To make it clearer: If the development department is going to
make a decision for VW they go to the manager an tell them: well
we want VW and we are 10 developers and we have to pay EUR 5000
each year for these 10 licenses.

The manager might say: ok we go with them ...

Then you are happy and tell the manager - but if we have success
they would like to have 6% from the business revenues (including
software sells, support contracts and teaching lessons at the
customer site - from everything which is based on the VW based
product).

Now, the decision is no more within the development department -
it now located at the highest levels in the company. The
calculation of these financial numbers can become pretty
difficult.

I'm perhaps the smallest customer from Cincom ... and I like
their software and their team - but I have problems with these
license contracts and whenever I can I choose another Smalltalk
environment or another tool to create my programs.

But: VW is a bright tools and with Pollock it will look much
brighter in the future.

Marten

--
Marten Feldtmann - Germany - Software Development
Information regarding VA Smalltalk and DMS-system
"MSK - Mien Schrievkrom" at: www.schrievkrom.de

Alan Knight

2006-04-05, 8:03 am

Marten Feldtmann <marten@toppoint.de> wrote in news:e0t66s$gkr$00$1
@news.t-online.com:
> The comparision with manufacturing is (in my case) wrong. I'm
> in the steel market and we nearly would never give work to
> others for an unknown amount of money. We are looking for
> subcontractors and we tell them, what we want and they tell us
> a fixed price and then we decice who gets the job.

So I guess the analogy with software in that case is that every time you
want to distribute to a new customer you negotiate a new contract. I
certainly don't imagine that you negotiate fixed price contracts without
strictly specifying the number of units/amount of materials involved.

Normally, in anything that involves physical objects, paying based on the
number of things you ship is standard, because that's determining the
number of things you buy.

--
Alan Knight [|], Cincom Smalltalk Development
knight@acm.org
aknight@cincom.com
http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it
run." - Niall Ross

Eike Preuss

2006-04-05, 7:05 pm

Marten Feldtmann wrote:

<snip>
>
> I'm perhaps the smallest customer from Cincom ... and I like
</snip>

I find this a very interesting point, and want to come back to the
initial question (what st implementation to use), not quite leaving the
license-issue:
What ST implementation would you use if you want to produce small-scale
software on a shareware/donationware basis?

++Eike

Andre Schnoor

2006-04-05, 7:05 pm

Dan Antion wrote:
> I just see it as a simpler model, and, to be honest, it's the same model
> as all the other software we use so it's easy to explain, easy to budget.

Well, I also love this model, but it doesn't work for commercial
software vendors that have nothing else to make profit from than their IDE.

Even a big fish and very popular company like Borland is currently
cancelling its IDE product line (C++ Builder, Delphy, J++ Builder,
InterBase, etc). You can read that on their press release pages at
www.borland.com.

When a rather famous company announces it wants to "sell" something that
is well-known worldwide, while there is yet no particular buyer in
sight, it is absolutely clear that it doesn't make any profit. This
actually means: "Please, somebody may come at least pay *something* for
it, so our shareholders won't pull our heads off".

Unfortunately, I think that some kind of annual subscription,
pay-per-copy or similar model is necessary to keep the product alive. It
also motivates the vendor to keep his customers (us) happy in order to
get the revenue stream streaming.

Andre

Andre Schnoor

2006-04-05, 7:05 pm

jarober@gmail.com

2006-04-05, 7:05 pm

That's pretty much the point that we've been trying to make at Cincom
for awhile now. The "standard" developer license model simply does not
work. PPD went belly up on it; Borland is bailing out of the tools
business on it. The problem with that license model is that it only
works if the number of new license sales climbs every year, forever.
You're bound to hit a brick wall with that eventually, at which point
you have a problem.

Heck, the model clearly didn't work for IBM; that's why they sloughed
VAST off to a small vendor. The question you want to ask yourself is,
how can a large product that works on multiple platforms be maintained
and moved forward on that license model? You need more than 1 or 2
developers working on it to accomplish anything - a platform like VW or
VA is akin to the J2EE in terms of scope.

If you have enough developers to move such a product forward, then the
"standard" developer model simply can't fund it.

Andreas Wacknitz

2006-04-05, 7:05 pm

"Andre Schnoor" <andre_INSERT_DOT_schnoor@web.de> schrieb im Newsbeitrag
news:4433F97A.5020008@web.de...
> Dan Antion wrote:
>
>
> Well, I also love this model, but it doesn't work for commercial software
> vendors that have nothing else to make profit from than their IDE.
>
> Even a big fish and very popular company like Borland is currently
> cancelling its IDE product line (C++ Builder, Delphy, J++ Builder,
> InterBase, etc). You can read that on their press release pages at
> www.borland.com.
I disagree with you here. The situation is not so simple in my opinion.
First, I think the model worked for them quite a long time. But the actual
management
s

s for better margins and the SCM field promises it.

Second, you have to look at the different tools as they all have their
particular problems:
1) JBuilder: good tool but a too short release cycle with too high
update prices.
They deterred many customers. And now there are many competitve Java
IDEs.
2) C++Builder has been necleted for a long time. So MS Visual C++ became
dominant.
3) Delphi is a phantastic tool with many fans. But the underlying
language is neither an
ISO nor an ANSI standard.

>
> When a rather famous company announces it wants to "sell" something that
> is well-known worldwide, while there is yet no particular buyer in sight,
> it is absolutely clear that it doesn't make any profit. This actually
> means: "Please, somebody may come at least pay *something* for it, so our
> shareholders won't pull our heads off".
>
> Unfortunately, I think that some kind of annual subscription, pay-per-copy
> or similar model is necessary to keep the product alive. It also motivates
> the vendor to keep his customers (us) happy in order to get the revenue
> stream streaming.
An annual subscription is in my opinion quite more acceptable than a
participation on revenues.
The company I am working for pays lots of $ for support contracts for its
development
tool chain. The development department has a budget that is planned ahead.

Andreas

jarober@gmail.com

2006-04-05, 7:05 pm

One small comment:

>Delphi is a phantastic tool with many fans. But the underlying
>language is neither an
> ISO nor an ANSI standard.

So what? has being an ANSI standard helped Smalltalk versus, say,
Java? If not being an ISO or ANSI standard had any relevance at all,
Java would be dead.

Dan Antion

2006-04-05, 10:01 pm

Andre Schnoor wrote:
> Dan Antion wrote:
>
>
>
>
> Well, I also love this model, but it doesn't work for commercial
> software vendors that have nothing else to make profit from than their IDE.
>
> Even a big fish and very popular company like Borland is currently
> cancelling its IDE product line (C++ Builder, Delphy, J++ Builder,
> InterBase, etc). You can read that on their press release pages at
> www.borland.com.
>
> When a rather famous company announces it wants to "sell" something that
> is well-known worldwide, while there is yet no particular buyer in
> sight, it is absolutely clear that it doesn't make any profit. This
> actually means: "Please, somebody may come at least pay *something* for
> it, so our shareholders won't pull our heads off".
>
> Unfortunately, I think that some kind of annual subscription,
> pay-per-copy or similar model is necessary to keep the product alive. It
> also motivates the vendor to keep his customers (us) happy in order to
> get the revenue stream streaming.
>
> Andre

OK, I'll try and exit this thread (knowing I should have never raised
this issue) with two thoughts:

1)I wouldn't put too much value in the Borland annalogy. As a company, I
think they made more than a few mistakes along the way.

2) How does annual subscription differ from maintenance, and why doesn't
that model work? I paid annual fees to IBM and Instantiations for years,
I still do. I pay IBM for DB2, for Lotus Notes and I pay (now)
Instantiations for VAST and other tools.

I don't mind paying something every year, I know vendors have ongoing
costs, but subscription fees are fixed, easy to explain and easy to
budget. Hell, I pay Microsoft subscription fees (software assurance) and
they haven't even had a new release of Office! My point is, believe it
or not, I can explain that to my management. If I write an article,
using Word, is Microsoft entitled for a portion of the fee I receive for
the article? I don't think I could ever explain that.

Dan

jarober@gmail.com

2006-04-05, 10:01 pm

Back in the old PPD days, year on year, we would get maintenance
renewals at about a 50%. Which is why the standard license/maintenance
model falls apart - to make up for the maintenance shortfall, you have
to sell a bunch of new licenses every year. Eventually, you hit a
brick wall that way. When you hit the wall will vary, based on how
successful you've been with sales prior to that. The question you want
to ask yourself is simple - how much do I need this tool to survive?

Yanni Chiu

2006-04-05, 10:01 pm

(Oh no, drawn in...)

jarober@gmail.com wrote:
> Back in the old PPD days, year on year, we would get maintenance
> renewals at about a 50%. Which is why the standard license/maintenance
> model falls apart - to make up for the maintenance shortfall, you have
> to sell a bunch of new licenses every year. Eventually, you hit a
> brick wall that way. When you hit the wall will vary, based on how
> successful you've been with sales prior to that.

I thought the standard charts show a rapid rise, a peak,
then, in the mature product stage, a gradual tail off
(to a steady state, or to zero). And, you're supposed to
introduce a new product (or major upgrade), before the
severe tail-off, to maintain revenues.

I think you mistakenly attribute the precipitous fall
of 50% a year, to the model. Maybe the standard license/maint.
model is okay, but other factors were responsible for the "fall".
Maybe it's the nature of Smalltalk - it's so good that maintenance
seems an unnecessary expense. Or, maybe it was PPD marketing
and mgmt. Whatever it was, I'm skeptical that the pricing model
is inherently flawed.

Doug Swartz

2006-04-05, 10:01 pm

On 5-Apr-2006, Eike Preuss <mail@eikepreuss.de> wrote:

> What ST implementation would you use if you want to produce small-scale
> software on a shareware/donationware basis?

Dolphin

Chris Uppal

2006-04-06, 8:03 am

Doug Swartz wrote:

>
> Dolphin

Agreed.

Shareware apps are usually Windows desktop applications, and Dolphin excels at
such.

-- chris

Marten Feldtmann

2006-04-06, 8:03 am

Eike Preuss schrieb:
> Marten Feldtmann wrote:
>
> <snip>
>
>
> </snip>
>
> I find this a very interesting point, and want to come back to the
> initial question (what st implementation to use), not quite leaving the
> license-issue:
> What ST implementation would you use if you want to produce small-scale
> software on a shareware/donationware basis?
>
> ++Eike

Hmm, normally one would go with Dolphin and Windows only. I do not
do that, because I've used VA over years now and when I would be
forced to use a new system, I would not go with Smalltalk, but either
with Java or C# (just to become mainstream again - and in my latest
project I use C#).

Dolphin: Considering every two years an update of about EUR 200
VW: Considering the VAR contract
VA: Considering software maintance contract.
Squeak: May be an alternative for some apps. zero costs.
Smalltalk/X: May be an alternative for some apps. zero costs.
Smalltalk MT: Also an alternative for WIndows solutions.

VS Std. 2005: EUR 200 each year (assuming updates)
Eclipse: Zero costs

+------------ Costs -------+
copies(month) Revenues Dolphin VW VA

1 480 200 500 1600
5 2400 200 500 1600
20 9600 200 500 1600
30 14400 200 720 1600
50 24000 200 1200 1600
100 48000 200 2400 1600
200 96000 200 4800 1600

This short table also shows, that the VW model is not that bad
and compares pretty well.

And of course it does not make sense just to look only on costs
- but that is another story.

The question remains: how much money are you ready to spend for
your hobby (in case of donation software or in the early stage
of a shareware business).

Marten

--
Marten Feldtmann - Germany - Software Development
Information regarding VA Smalltalk and DMS-system
"MSK - Mien Schrievkrom" at: www.schrievkrom.de

ramon.leon@gmail.com

2006-04-06, 7:04 pm

> I still find it interesting how much resistance there is to such
> licensing model. If you build a product that makes you money, why
> wouldn't you want to pay a tiny, and I do mean tiny, share of proceeds
> to the company that provides you a tool knowing that they will use that
> money to improve the tool even more to enable you to make even more
> money?
>
> Its quite a common occurrence outside of IT too. If I were, say, a
> custom part manufacturer and needed a laser cutter to produce the parts
> for sale, I wouldn't mind having that cutter on site for $0 but pay
> back 3% of my profit back to the manufacturer that provides the
> hardware and support w/o charing a penny extra. The fear of royalties
> is overhyped as far as I'm concerned, especially given how reasonable
> Cincom sales department is when it comes to calculating them. If you
> ship a product whose value is 90% in the backend and only uses VW
> occasionally for the other 10% of the value and the product sells for
> $1,000 you would only have to pay royalties on the 10% of $1,000 which
> is $100. So 3% royalty would be $3 per $1,000 sale. Sounds good to me
> :)

I'll chime in, why... how about because I want development tools to be
products I buy once, not continually. Personally, I'll never use
Visual Works because of that licensing model. Forcing your customers
into a partnership rather than just selling them your product, is just
something a lot of people won't tolerate, myself included.

jarober@gmail.com

2006-04-06, 7:04 pm

Ramon,
I understand where you are coming from, but there's a simple
problem - the model you want does not lead to a supportable business.
Period. What it leads to is a vendor that goes under. There are two
general exceptions:

1) the vendor makes money elsewhere and is willing to support their
tool as a loss leader for other reasons.

Trouble is, the latter course is a dicey one, as it does not guarantee
long term stability either. At the first hint of trouble, the loss
leader gets intense scrutiny.

2) The vendor has a handful of developers, and sacrifices frequent new
versions due to a need to self fund via consulting

The bottom line is pretty simple: If you want your vendor to stay in
business and continue updating the product, your preferred license
model doesn't work.

ramon.leon@gmail.com

2006-04-06, 7:04 pm

Which is why I use Squeak.

Steve A

2006-04-07, 4:06 am

ramon.leon@gmail.com wrote:
> Which is why I use Squeak.
>

Then there is the other side of the equation where some people
(governments and large companies) will not by a product built on a tool
that has no commercial support.

Stefan Schmiedl

2006-04-07, 4:06 am

On Fri, 07 Apr 2006 16:16:14 +1000, Steve A wrote:

> ramon.leon@gmail.com wrote:
> Then there is the other side of the equation where some people
> (governments and large companies) will not by a product built on a tool
> that has no commercial support.

.... which is changing now, since more and more linux based systems
and services are getting deployed.

s.

Doug Swartz

2006-04-07, 10:02 pm

On 7-Apr-2006, Stefan Schmiedl <s@xss.de> wrote:

>
> ... which is changing now, since more and more linux based systems
> and services are getting deployed.

And quite a few of those LINIX based systems which are in corporations
are paying a commercial vendor for support.

James J. Gavan

2006-04-07, 10:02 pm

jarober@gmail.com wrote:
> Ramon,
> I understand where you are coming from, but there's a simple
> problem - the model you want does not lead to a supportable business.
> Period. What it leads to is a vendor that goes under. There are two
> general exceptions:
>
> 1) the vendor makes money elsewhere and is willing to support their
> tool as a loss leader for other reasons.
>
> Trouble is, the latter course is a dicey one, as it does not guarantee
> long term stability either. At the first hint of trouble, the loss
> leader gets intense scrutiny.
>
> 2) The vendor has a handful of developers, and sacrifices frequent new
> versions due to a need to self fund via consulting
>
> The bottom line is pretty simple: If you want your vendor to stay in
> business and continue updating the product, your preferred license
> model doesn't work.
>

I'll respond to this later under a fresh thread "Which LANGUAGE ?",
not which dialect of a language. My reason, I am sick and tired of being
hosed on COBOL's prohibitive costs - and I'm talking a fully integrated
IDE allowing for traditional COBOL (Procedural and COBOL file types),
SQL Preprocessors and OO COBOL with general/collection and GUI classes -
a superb tool - if you don't mind getting screwed by the compiler vendor
on fees.

I'm searching the Web looking at the multiplicity of options, Smalltalk
in its various flavours, Java, C# (why bother with C or C++) and of
course Visual Studio. I already know of COBOLers, (because of costs),
who have switched to C#, Java and PowerBasic. I'll get back when I've
read a little more and ask for your 'honest' and 'unbiased' advice.

As a closing observation - COBOL ANSI/ISO Standard is a 1,000 plus page
document - versus Smalltalk (Goldberg/Robson - Smalltalk-80), where the
complete syntax can be summarized on one page ! However I have seen
comments like, "I am maintaining (Procedural) COBOL programs which were
written before I was born". (And it is fast, VERY FAST, using EXEs and
DLLs). Can Smalltalk or any other OO language make that claim ?

Jimmy, Calgary AB

Bruno

2006-04-08, 4:01 am

> As a closing observation - COBOL ANSI/ISO Standard is a 1,000 plus page
> document - versus Smalltalk (Goldberg/Robson - Smalltalk-80), where the
> complete syntax can be summarized on one page ! However I have seen
> comments like, "I am maintaining (Procedural) COBOL programs which were
> written before I was born". (And it is fast, VERY FAST, using EXEs and
> DLLs). Can Smalltalk or any other OO language make that claim ?
>

I think the problem of software is complexity not performance.
(computers run faster at each moment)
Smalltalk is fast too.

In COBOL you need 1000 page to explain something, in Smalltalk only one.
Because is Smalltalk is simple.

Regards Bruno

Andre Schnoor

2006-04-08, 4:01 am

James J. Gavan wrote:

> I'm searching the Web looking at the multiplicity of options, Smalltalk
> in its various flavours, Java, C# (why bother with C or C++) and of
> course Visual Studio. I already know of COBOLers, (because of costs),
> who have switched to C#, Java and PowerBasic. I'll get back when I've
> read a little more and ask for your 'honest' and 'unbiased' advice.

Speed ist definately not an issue anymore. I've built rather complex
multimedia desktop apps in VisualWorks with tons of UI gadgets and
next-to-realtime performance (I still wonder why "Wrapper" is supposed
to be too slow). It runs fast and satisfying, even on a 800MHz machine.

However, you could get issues with bad GUI design, if you stack too many
wrappers or tab controls, or when displaying and editing huge structured
objects in scrollable views, i.e. when clever logical clipping/caching
on large trees or such is required.

I confess that I did a lot of UI tweaking and patched "Wrapper" for
performance, but that's not necessary for standard business apps.

Andre

Michael

2006-04-08, 4:01 am

I am pretty new to Smalltalk, but several years ago, I was again
attracted
to it. My only experience before hand was with DOS version which I
think
was called Smalltalk/V. Anyway upon encourntering Smalltalk again, I
somehow found Visualworks. I felt an almost immediate disdain for
their
licensing model. I can easily summarize my feelings in that as a
Developer
starting out, it would probably be hard enought just to sell a
potential
client a system, without trying to convince them to go into partnership
with the vendor of my development tools.

I have no quarrel with the fact that Cincom can choose any licensing
model they wiish. I can't really respond to their statements that this
is
the only licensing model they think would cause them to be able to
generate sufficient revenue to continue support and upgrading.

So we have established that fact that their licensing model is good
for them and I again I respect their right to choose any licensing
model
they wish. However where I would take issue is whether it is
good for anyone else and How many potential developers have been
turned off from even considering Smalltalk because of it.

As for me, Visualworks seems to be an excellant product, but
I refuse to use it.

Robin Barendregt

2006-04-08, 8:03 am

> As a closing observation - COBOL ANSI/ISO Standard is a 1,000 plus page
> document - versus Smalltalk (Goldberg/Robson - Smalltalk-80), where the
> complete syntax can be summarized on one page !

It all depends on what you like. Personally I like it that the syntax does
not get in my way, which results in programs that read much like natural
language (actually I found that Cobol had that a bit as well, but it's not
terse). But in order to find useful things to (re)use in either type of
language, you have to either dive into class libraries or hefty manuals.

> (And it is fast, VERY FAST, using EXEs and DLLs). Can Smalltalk or any
> other OO language make that claim ?

It all depends how you measure speed. Again personally, I think Smalltalk
shines when the algorithmic complexity is high (and i don't mean math but
business logic). Right there you gain speed by cutting development time
because of the terse syntax and of course the full reflective environment
(write some code, test it...oops debugger pops up..ah yes, rewrite some
stuff, save (and that's the kicker) and continue execution...wow!). In
execution time it will depend what environment you choose. VisualWorks is
/very/ fast.
As far as maintenance goes, I'd say that it falls into two extremes. A well
written program is a pleasure to maintain, but a badly written one is a true
nightmare because in such a case you'd actually wish you had static typing
information.

Regards, Robin.

jarober@gmail.com

2006-04-08, 8:03 am

Why does your customer have to "partner" with you under a royalty
model? You charge a fee of some sort, and at the end of the year you
pay Cincom a percentage. Your customer never sees Cincom, and neither
knows nor cares that you use Cincom Smalltalk.

None of our VARS share customer information with us; all they do is pay
a royalty.

As well, that license model is used only for customers selling a
product built in CST. Internally used apps are licensed differently.

Dan Antion

2006-04-08, 7:03 pm

jarober@gmail.com wrote:
> Back in the old PPD days, year on year, we would get maintenance
> renewals at about a 50%. Which is why the standard license/maintenance
> model falls apart - to make up for the maintenance shortfall, you have
> to sell a bunch of new licenses every year. Eventually, you hit a
> brick wall that way. When you hit the wall will vary, based on how
> successful you've been with sales prior to that. The question you want
> to ask yourself is simple - how much do I need this tool to survive?
>

"how much do I need this tool to survive?"

Unfortunately, for people on both sides of the equation, the answer to
your question is "not at all". Why do I say that? Easy, it's not my money.

I've been forced to change development environments three times in the
past 18 years, not counting the major upgrades within an existing
product that made it seem like a new paltform. In each case, we
survived, and my boss is well aware of that. I would never be able to
convince anyone, myself included, that I need a particular development
environment to do my job. Transitions to new platforms are painful, but
they are also a fact of life. Smalltalk is a wonderful development
environment, but I've just moved a major application out of Smalltalk
and into SharePoint because it's a less expensive solution long-term.

Before we knew that Instantiations was going to be taking over
VisualAge, we met to discuss "our" options. In the group making the
decsions. I was the only developer. Our decision was, if VAST was
declared to be at the end of marketing or end of life, we would probably
pay IBM for extended maintenance then migrate to either Java or C#. At
the time of that decision, I thought porting all of our applications to
Dolphin would be too costly, as it would require several frameworks to
be ported, including some we purchased. We didn't consider VW at all
because of the licensing.

I consider myself to be a loyal and supportive customer of most of my
vendors. I expect a quality product, I appreciate the fact that they
should be fairly compensated for their product but I am not committed to
helping them survive as business entities - that's their job, not mine.
We do buy maintenance, and we always have, because I like what I get for
the money I pay toward that maintenance product. When I see people
complaining that VAST 5.2 doesn't do <insert favorite complaint here> I
think "why should it? VAST 6.0 does and VAST 7.0 does. But the day
Instantiations tells me they can't afford to continue working on VAST,
I'll say "well, I've had a good run with VAST." At that point, I'll
take a hard look at Dolphin, and whetever the flavors of the day are,
and I'll recommend the best business decision for my company - because
it's their money.

Dan

James J. Gavan

2006-04-08, 7:03 pm

Andre Schnoor wrote:
> James J. Gavan wrote:
>
>
>
>
> Speed ist definately not an issue anymore. I've built rather complex
> multimedia desktop apps in VisualWorks with tons of UI gadgets and
> next-to-realtime performance (I still wonder why "Wrapper" is supposed
> to be too slow). It runs fast and satisfying, even on a 800MHz machine.

Andre,

I think speed can still be an issue. I haven't gotten into it, but I
have an icon for Squeak on my desktop. There is a very apparent delay
while it loads - my reaction, does that also occur with 'real apps' ?.
And again in a Java NG I see a couple of people arguing the toss about
the merits of Java versus C# (presumably it was either C or C++ ?) - the
claim being that C *was* faster.

On the speed issue - somebody looking for an alternative to COBOL; I've
added the '+++' for clarification :-

-----------------------------------------------------------------------
File Handler
=========
One thing about moving to anything else is the file handler. Tsunami is
the best so far. Its about 2/3 the speed of MF (+++ Micro Focus - Net
Express +++), under heavy loads. Under normal load (open, mostly reads,
close), they come in close enough that I'll use Tsunami for my
conversion tests.

- FJ (+++ Fujitsu - what they now call 'NetCOBOL', which can be used/not
used with dotNet +++). craps out at 3gig which was a downer for me. I
never bothered to do a benchmark because of that
- OpenCOBOL uses the Sleepycat routines which are very good but require
licenses if the package is not open source.
- PowerBasic comes with no indexed file handler (just sequential/random)
so I've had to go 3rd party.
- PowerTree from PowerBasic handles only the index portion. The data
records need to be managed elsewhere (ouch).
- Tsunami is a great record manager with no realistic size limits. It is
between 33% and 50% slower than MF Isam under load. The client-server
version of Tsunami is faster than FileShare so far.
- Dang MF file handler is just so fast. Its the modifications they made
to the c-isam engine that make it so dang fast. Even using aggressive
caching in Tsunami I can only get to 75% of MF in single-user mode.
-----------------------------------------------------------------------

I haven't got figures, but I believe his volumes are fairly significant.
Note that he wants to stick, as near as possible, with the COBOL file
approach. For me, I've already switched to SQL and my existing ESQL
Assistant does a neat job in COBOL letting me format a query, gives me
the complete code, (100% foolproof), that I can copy and paste into an
OO COBOL class.
>
> However, you could get issues with bad GUI design, if you stack too many
> wrappers or tab controls, or when displaying and editing huge structured
> objects in scrollable views, i.e. when clever logical clipping/caching
> on large trees or such is required.

I take your point about GUIs - one good reason *not* to ask the
academics in comp.lang.object about how you should do things :-)

I certainly didn't like the M/F OO examples - needed a tremendous amount
of copy/pasting to follow their style. A dialog is a dialog and contains
n or n + x controls. I went for a template class MyDialog; pass a fixed
set of parameters per control, store the info in an OrderedColllection,
together with the method-name of callbacks/iterators based on events -
where the Instance does something internally ( say like an integer of
12345 begin re-displayed as 12.345) or alternatively the result is
returned to a Business control class. Wouldn't claim it is perfection,
but if you like, the template class is a series of components - the
logic being that methods like 'show', 'hide', 'enable', 'disable' etc
are fairly common to many of the common controls; and while invoked from
the Business class the code for those methods only appears in one place
- my template instance.

Which GUI tool - will be one of my questions about 'Which Language ?'.

Jimmy
>
> I confess that I did a lot of UI tweaking and patched "Wrapper" for
> performance, but that's not necessary for standard business apps.
>
>
> Andre

Andre Schnoor

2006-04-08, 7:03 pm

> I think speed can still be an issue. I haven't gotten into it, but I
> have an icon for Squeak on my desktop. There is a very apparent delay
> while it loads - my reaction, does that also occur with 'real apps' ?.

Yes, it does. There are many examples I could think of: Adobe Acrobat,
Photoshop, OpenOffice.org, Dreamweaver, etc. I don't know if all of them
are written in C++. Even on a 3Ghz machine with 2GB memory, they perform
no better than my VisualWorks app, which is nearly about the same size.

Andre

Chris Uppal

2006-04-09, 4:03 am

James J. Gavan wrote:

> I think speed can still be an issue. I haven't gotten into it, but I
> have an icon for Squeak on my desktop. There is a very apparent delay
> while it loads - my reaction, does that also occur with 'real apps' ?.

There are several kinds of speed, and I think you may be confusing them.

Raw speed of computation. Given that you are talking about desktop apps, and
presumably not running on decade-old hardware, this is unlikely to be an issue
no matter what language or implementation you use. For instance I use Dolphin
in preference to, say, VW despite the fact that Dolphin is interpreted and VW
is not. I don't think the 2-3 x difference in speed is worth bothering about.
(it's less than the difference in speed between the two machines next to me,
anyway).

Perceived speed of rendering, updating, etc. This can be affected by the
complexity of the GUI, the complexity of the code which manages the GUI, and
the quality of implementation of the GUI widgets. Compare an app written in
Dolphin (such as its IDE) with one written in Java, and you'll see what I
mean...

Startup time. Basically a consequence of the size of the application, and the
complexity of its initialisation code. Some apps will always be slow, no
matter what they are written in since their startup is inherently complex.
However there are differences in the overhead required for the implementation
language itself. I don't know how much overhead other Smalltalk
implementations have (I've never knowingly used an application written in any
other Smalltalk except their own IDEs), but I do know that a deployed Dolphin
app will start up fast enough for startup time not to be noticeable. Note
however that there still is /some/ overhead. OTOH, since a deployed app is
(internally) just a saved image, it is sometimes possible to include complex
data structures in a pre-built state, and thus avoid what might be a
significant startup overhead in a different language where that structure had
to be created anew each time the app started.

Database access time. I only mention this because it seems to be what you are
concentrating on in the snipped part of your post. Basically it is
irrelevant -- data access is not part of the language in the way that (AFAIK)
it is in Cobol. You use whatever database package you want, with whatever kind
of interface you want. The choice of language/implementation does not
materially affect which packages are available for you to use.

-- chris

Boris Popov

2006-04-10, 7:04 pm

Umm, 'standard' and 'syntax' are two very different things. Last I
checked, Smalltalk ANSI standard was over 300 pages. Sure enough, its
not near the 1,000 pages for COBOL, but its not 1 page either.

Cheers!

Sponsored Links