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
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
