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