mission critical apps; was Re: cross platform ide

[Alex Rice]

Don't interpret any of the following as a complaint against xtalks, in 
fact I desire to move away from business support apps and into more 
games and multimedia. So I do like the "ad-hoc" flexibility of 
transcript.

Topics have been coming up about how Runrev should gain footholds in 
corporate IT departments, and lure in disaffected VB and .NET 
programmers, and some issues are inevitably going to be raised about 
the programming model used by transcript.

recall this post
On Jan 26, 2004, at 10:50 PM, Alex Rice wrote:
> Instead of ad-hoc message passing and script evaluation found in 
> xtalks, Eiffel code is meticulously crafted with strictly typed 
> objects that can only connect with other particular objects and call 
> certain functions; "design by contract" they call it.

I keep on thinking about this post I made a couple of weeks ago, and I 
am wondering more and more: is Runrev really suitable for mission 
critical business or industrial apps where the design is strictly top 
down with a rigid and well defined plan about how the objects are 
required to interact with the rest of the system?

Look at Eiffel as the total opposite extreme from xtalks: the eiffel 
compiler won't even build your code unless it can say with certainty if 
a particular message is passed, it will have x,y,z pre conditions and 
post conditions- you can count on a particular state of the system.

At a job interview once the guy was asking me about Objective-C, which 
I had on my resume. As a Java programmer of a large financial app, he 
was skeptical about the messaging model employed by Objective-C: "just 
send a message 'out there' for some other object to catch... 
hopefully", as he described it. Now he doesn't understand how the 
Objective-C runtime works exactly, but I can understand the issue he's 
worried about: How do you know whether a message will arrive at it's 
intended destination (object).

In short- you don't know, unless the compiler and the language work 
together to give that kind of assurance. Java goes a long way towards 
this goal because it won't compile if any method call or any parameter 
does not match the signature of the objects used.

Objective-C is compiled so if you are using typed objects, the compiler 
gives you a degree of safety that object x will accept message y at 
runtime. But with Objective-C it's still a smalltalk like "throw a 
message out there".

xtalk (transcript) however is a total free-for-all. As messages are 
fired off, any handler could dynamically change the message path via 
front scripts, back scripts, insert scripts, etc. Think about it: it 
literally is what that interviewer was talking about: "just send a 
message 'out there' for some object to catch... hopefully". If the 
intended object does not receive the message, how will you know? Is 
exception handling working? Is errorDialog working? Did another object 
handle the message? How did that other object get in the message path?

So the continuum of languages maybe looks something like this:

xtalks <-> smalltalk <-> objective-c <-> C++ <-> Java <-> Eiffel

Dan Schafer, if you are reading this far, How did smalltalk deal with 
this issue, if it was a issue, in the eyes of customers getting large 
business apps in written in smalltalk? I'm sure they had to deal with 
it at some point as they tried to convince customers to use them 
instead of some C++ programmers or Fortran or Ada or something. It 
would be interesting to learn from the history of both smalltalk and 
xalks. So when we walk into the board room we can defend the reputation 
of 4GL scripting languages with acumen.

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