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

Andre Schnoor wrote:
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.

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
.

Relevant Pages

  • Re: Definition of outdated...
    ... There are often a reference to a programming language to be 'outdated', ... Looking strictly at the wording, then Java is more outdated than Delphi, ... What imo should be outdated is how money controls hype that controls ...
    (borland.public.delphi.non-technical)
  • La.i Tsunami nu+~a Tro+`i (071706)
    ... Tsunami kills 80 people in Indonesia ... The tsunami was triggered by a strong undersea earthquake off the Java ... Local official Rudi Supriatna Bahro says waves up to 1.5 metres high ...
    (soc.culture.vietnamese)
  • Re: Windows forms application without Managed Code?
    ... But of all the current options, Java is the currently most portable. ... The myth that open source implies portability is right up there with Java as a silver ... applications with relatively lightweight GUI front ends and complex GUI ... The biggest problem was that none of the underlying operating system primitive controls ...
    (microsoft.public.vc.mfc)
  • Re: VB.NET 2008 not backward compatable?
    ... Most VB6 applications made use of ActiveX ... controls such as the Windows Common Controls ActiveX controls. ... Yet Java has been around ...
    (microsoft.public.dotnet.languages.vb)
  • Re: where do us long time VBers move on to?
    ... > application over to Java. ... > to add when using M$' incomplete controls. ... > While they bragged that converting User Defined or 3rd party controls was ... They had VBers ...
    (microsoft.public.vb.general.discussion)