"compile" vs. "tokenize" (was Re: Password Problem)

[Bill Akers]

Fairlight wrote:
> With neither thought nor caution, Kenneth Brody blurted:
> 
>>Well, to be "buzzword compliant", I would say that "filePro compiles to
>>a bytecode for the filePro Virtual Machine".
>>
>>Basically, it gets compiled to machine code.  It's just that the machine
>>that it compiles for is not the physical machine that you're running.
> 
> 
> I'd say you're splitting hairs, Ken.  :)
> 
> Let me put it this way--if that's your criterion, then perl is to be
> categorised as a compiled language without perlcc, perl2exe, PAR/pp, or any
> other of the self-contained-executable generating software available.
> 
> And in the real world, that just isn't how it's viewed.
> 
> I mean, it's your prerogative to view it that way.  I can even understand
> why you're saying it.  I'd just say that I have a quibble with the
> technicalities under which you invoke the definition of 'compiled'.
> 
> No offense, but I'll agree to disagree on this one.
> 
> And as a sidenote--it doesn't really matter; both example platforms do
> their respective jobs, and it's pretty irrelevant how it's viewed so long
> as it works.  At least in a technical sense.  In a -conceptual- sense, it
> matters, as compiled languages are preferable to interpreted (even
> bytecode-interpreted), and licensing and distribution of applications is a
> lot simpler in the compiled sense.  The logistical viewpoint where someone
> looks at a product and says, "Okay, great...looks sharp, we'll take it,"
> but then is told, "Well, there's just one tiny thing...you also need to buy
> this to actually run it," has been a bit of a thorn in the side for some.
> It's frankly harder to sell something like that than something
> self-contained--especially when what it depends on isn't something you can
> just pick up off the shelf or readily obtain support for from just about
> anywhere (Oracle, MSSQL, (God save me) even Jet/Access).

I disagree with your assertion that it is harder to sell a product with 
a runtime module than otherwise. How many cobol programs do you know of? 
  I sold quite a few Realworld accounting programs and nobody complained 
about paying for the runtime module. The prospective customer just 
expects a product, so if you need a runtime it is just part of the 
product and the savvy salesman includes it as such. I never tried to 
sell a complete development system when all the customer wanted was a 
functional program, runtimes can be included easily with minor 
conversation since the cost is small compared to the development system. 
The truth is that unless the customer had filePro already, I simply 
included the runtime as part of the program.

> 
> I'm not -personally- complaining.  I just know it's made it harder over the
> years in some situations.  People want one unified "something".  Doesn't
> matter what.  They start seeing more and more necesssary pieces and they
> start wanting to walk, as it gets more complex, and people that make the
> decisions on buy/don't-buy don't tend to like 'complex'.

Have you looked at the number of modules in any program that performs a 
complicated procedure, lately? I will agree that the windows installer 
covers up the complexity of programs on that platform, but most are 
complicated anyway.

> 
> It also depends how the developer handles it.  If they transparently bundle
> it so that the customer is barely even (or NOT even) aware they're running
> fP, then it's easier to sell.  The problem then is that if their developer
> goes away or there's a falling out, the customer in question doesn't even
> know what they're dealing with because it was never presented up-front.

I always told my customers what the programming platform was and never 
lost a sale because of that. I lost sales for other reasons(hair parted 
on the wrong side,etc.) but not because it was filePro.

> 
> Overall, I think the current runtime model has made it harder on
> developers, which in turn makes it harder on fP-Tech.  But that's just my
> opinion.  YMMV.

I don't know what the current model is harder than, so can't
  comment on that issue.

> 
> mark->


-- 
William Akers
MGM Industries, Inc.
Hendersonville TN USA