mission critical apps; was Re: cross platform ide

[Alex Rice]

"Well *I* can write reliable code in transcript". Of course! If we all 
didn't believe that we would not be using Runrev as our favorite 
development tool right?

I don't mean to be pedantic about this. I want anyone trying to write 
business apps with runrev to succeed. Before you can succeed you have 
to get in the door. Before you can get in the door you have to justify 
and get funding for your dev. tools, or get a client to sign off on a 
technical spec of the project. I am just raising issues that I think 
runrev users should be aware of if they are bringing runrev into 
corporate IT environments, where correctness and reliability is 
important. By "important" I don't mean important because some suit 
likes the buzzword "mission-critical". I mean where $, property, or 
safety is actually at stake.

Rob C wrote:
> If the intended objet does not receive the message, the programmer 
> screwed up.

The question I am raising is not whether it is possible for programmers 
to screw up using xtalk code, rather: how are you going to sell xtalks 
in a corporate environment where reliability and correctness is more 
important than programmer productivity? Imagine a manager or programmer 
is in your face asking for a justification of the xtalk/smalltalk 
messaging model where the message traipses up the message path, landing 
on whatever object it may land (in their subjective view, that is). 
It's a legitimate question, issue, and (perhaps) there are places where 
xtalks are not a good solution. A very few places.

Ken N wrote:
>  The
> message --> the object. The message is now on a rail, can't go anywhere
> else.

Your "rails" concept is appealing, but in reality you don't know until 
*at runtime* if the message lands where you intended. Furthermore, 
getting the message to the object is only part of the problem. Ensuring 
the object can accept the message is the other part: the message having 
the right number and type of parameters.

What's worse is in complex apps you are probably going to be 
manipulating the message path with "send", "start using", or evaluating 
dynamic code with "do" or "value". I deduce from the existence of such 
language features: the message is not on a rail. In other words, the 
message path can change at runtime.

Even if the message path is not changing at runtime, it's still tricky. 
Something that has bitten me many times in transcript is sending a 
message to "this card" or "this stack" only to discover this card or 
this stack was not the one *I thought I was sending to*.

Ken N wrote:
> I admit, the models I use are much more simplistic than you fellers 
> seem to
> be describing, but I never had one miss or get lost if I did it like I
> described.

Again: formalize it and be able to explain it to managers and other 
programmers. Make a case study for runrev to post on their website. Or 
write a HOW-To and post it to RevNet. Seriously. I'm not singling you 
out Ken; anyone who's thinking the same thing, I challenge you.

Myself, I admit to having lots of message path problems. There is a 
learning curve about the message path. I guess it depends what kind of 
apps you are writing and whether you use "send" , "do" , "value", 
"start using"; the features of the language that involve different 
parts of the message path.

Also, consider the possibility that maybe you don't even know if 
messages not reaching their destination. Did you know there is a bug 
with errorDialog in standalones, and with try/catch exception handling 
in the IDE? Dar once filed a bug that messages start getting unreliable 
after many million messages or weeks of runtime (I forget the details 
or even if it was a legitimate bug). Issues like these will thwart even 
the most well intentioned and diligent xtalk programmer.

The questions I intended to bring up were:

1) In a technical interview, or when trying to sell an xtalk solution 
to corporate IT dept, you may run into someone who challenges the 
xtalk/smalltalk messaging model. I described in a previous post that 
interview where the Java engineer was challenging me about Objective-C. 
It's possible the issue will come up for other 
xtalk/smalltalk/objective-C programmers too.

2) Is a tool that's really good for games and multimedia also a good 
tool for making ultra-reliable business applications? There is an 
saying something like: When all you have is a hammer, everything looks 
like a nail. Can the 'All talking All singing All dancing' Runrev 
really be the 1 true tool that we want it to be?

Another anecdote:

I wrote some Perl CGI programs at an insurance company, for auto and 
homeowners policies. There were definitely mission critical aspects 
because large amounts of money were involved in the transactions. But 
the Perl CGI programs were just taking initial information for new 
policy applications, and providing quotes, before a policy was even 
active. So it's OK that the Perl code was rushed and hastily done and 
that it was _Perl_ which is even more weird and flexible and dynamic as 
xtalk. It's OK: because the mission critical stuff like billing, claims 
and actuarials were done in some other language, probably in Oracle 
PL/SQL. In hindsight Runrev could have been fine for the former purpose 
(the Perl part), but not the latter (the Oracle PL/SQL part).

--
Alex Rice | Mindlube Software | http://mindlube.com