mission critical apps

[David Vaughan]

On  and before 10/02/2004, at 7:19, several people wrote many things on 
this topic:

>

Fundamentally, Alex is right but it does not matter a lot. So is Rob 
but in a different sphere. Meanwhile, I think Frank is wrong.

Without going back to the original, I recall Alex's basic points as 
being:
- Rev lacks the inherent or external tools to support large team 
development.
- A Smalltalk-like message passing structure makes assurance of formal 
correctness difficult.

I am not certain that the second point (as I have interpreted him) is 
true in the sense that it can not be dealt with in tool design or code 
management but the first alone is sufficient to wipe Rev out of large 
scale application development anyway. So, does this matter?

While some of the commentary drifted between xTalk as a viable language 
and the actual topic of message model and team development, the nub 
appears to be: in what market is Rev playing, and is the tool you are 
using viable? In fact, I think this thread originally grew from Alex or 
someone's difficulty in getting Rev accepted as a development tool by a 
client.

There was an article a year or so ago (there will be a ref in the 
archives somewhere) on xTalks. Essentially, it placed them as very high 
level RAD tools ideally adapted to glue functions. Recall that Alex 
never gainsaid Rev's productivity advantages, only its fitness for 
large scale development. I think his reference to "mission critical" is 
a little off topic in that mission critical is quite often a discovery 
after the software has been in use for a while. I would simply stick 
with a measure of size, which of course is highly correlated with 
mission-critical.

Rob's defence of Rev's productivity and reliability is fair but again 
is off the core point. Rev is perfectly suited to those millions of 
small-scale niche (in the best sense) applications for business, on 
which the computing world actually thrives. It is also excellently 
suited to systems integration tasks of glueing unlike apps together, or 
post-processing standardised output to give interactive and enhanced 
access or multimedia presentation. In either of those roles, it can and 
will be used in "the enterprise" and is a powerful platform for a small 
firm marketing to those enterprises. It is just that it will not be 
used to re-write SAP or Sabre or ComputerShare or the like. It may help 
glue, say, the accounting system with a proprietary case management 
system and provide joint reporting from them or to enable common web 
access to a (Rev) engine reprocessing corporate data. These are things 
MIS generally does not want to do and present golden opportunities for 
small integration firms.

Then, there are endless apps already made by people on this list. Core 
tools like Rob's SDB, Sarah's POP library and Shao Sean's LibSMTP. Apps 
like Oenolog and Tom's instructive CD or Alex' ARC (excuse me for not 
going on). They are providing reliable and effective service because 
they are based on a solid platform.

Hence, I think Alex's positioning of Rev is fair but in my view not in 
any respect damaging. Let me put this another way. You could be a 
programmer in a huge enterprise or in a small business, possibly your 
own. Where have you chosen to work? Then choose the right tool for what 
you are doing and don't fret over what you are not doing.


While I'm here, I may as well add my free trade comment on Frank's 
request for C-like syntax:
- It will remove zero bugs from Rev
- It is more likely to add programmer coding and reading bugs than to 
reduce them
- It will make some people more comfortable with the language and 
others less.
- Transcript is a perfectly good (in the vernacular sense) formal 
language as it stands.

Those interested in it can always write the requisite pre-processor 
themselves and insert it into the editor, then release and maintain it 
for a price. The market will answer for their opinion.

regards
David