Is being a good cross-platform tool good enough?

[Dan Shafer]

Frank.....

Good conversation.
On Aug 8, 2004, at 10:28 PM, Frank Leahy wrote:

>> Frank.....
>>
>> Pardon me, but this comment seemed a little strange to me. "Just
>> another cross-platform tool"? What others are there? RealBasic has 
>> been
>> mentioned. Maybe Director (though it's not for general-purpose apps).
>>
>
> Dan,
>
> Let's say you've been hired to develop a cross-platform accounting 
> system, and you present the spec to your client.  After reading it 
> over they ask why features A, B and C are missing, and you respond 
> with "well, no other cross-platform accounting system can do that".  
> Do you suppose you're going to get the project?  I doubt it, not when 
> your client is competing against single-platform packages that do A, B 
> and C.
>
Intriguing scenario. I've never encountered this issue. If I did, I'd 
probably try to explain up front the trade-offs involved in getting 
those nifty platform-specific features in a product he wants to be sure 
is cross-platform. I'd explain the costs of maintaining two separate 
(even partial) code bases. I'd try to find out why he wants this 
product to be cross-platform. If, e.g., he has clients where mixed 
platforms will be used, introducing platform-specific features might 
create some zany support and training issues.

At the end of the day, if he really wants platform-specific features in 
this cross-platform tool, then I have to decide if I want to learn 
those features and how to implement them, pass on the project, or hire 
someone who's expert on his other platform.

But you are right that RunRev won't in its current incarnation be the 
right tool for all such applications. I'm not even sure it's a good 
choice for an accounting package. But the fact that a huge percentage 
of xplat projects don't require that platform-specific feature set 
makes it usable for a lot of things. Enough to keep me happy anyway.

> Same goes for RunRev.  When a programmer evaluates RunRev they're 
> looking not just at cross-platform packages, but at single-platform 
> packages as well,

Not sure I agree or follow here, Frank. If I had a client who wanted a 
Windows-only product, I'd choose a Windows-only tool, not a tool 
designed specifically to create cross-platform apps because I know the 
trade-offs that are inevitably made to create such tools.

For example, if I were asked to write an OS X-only product, I might 
well choose not to use Revolution simply because Revolution might not 
be as easy to do system-specific features in.

> and they're weighing the ease of going cross-platform with a limited 
> set of technologies, versus the cost of not having access to native 
> technologies that RunRev doesn't support.  And when there's a 
> single-platform must-have that RunRev doesn't support then RunRev 
> doesn't get the sale.
>
>> I think the shoe belongs on the other foot. If Rev attempts to be 
>> "just
>> another Windows tool" (or for that matter "just another Mac tool") it
>> will miss its opportunity to be the best damn cross-platform tool
>> around.
>
> Kevin doesn't have enough $$$ in the bank to keep up with the latest 
> technologies on all the platforms he's trying to support, and so he's 
> always going to have to shoot for the lowest common denominator.  He 
> can get rid of that problem by providing native API support once.  
> Because once he does that the problem goes away -- forever.
>
Decent point. But in the process, will he have to give up on the 
simplicity and approachability of Transcript and Revolution? It seems 
to me inevitable. And when that happens, the utility of the program  
for its largest potential user base -- inventive users rather than 
professional programmers --  declines.

My ultimate point remains if not valid at least logical. There's no way 
for Rev to compete as a single-platform development tool for 
professionals on any platform. Its real power is in cross-platform. To 
keep the language accessible, we need to resist gratuitous additions.

I can't say that the ability to access system APIs will of necessity 
make the language and/or IDE more complex than necessary or accessible, 
but it seems to me that it's likely to do so.

> -- Frank
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>