Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Alaska
Message
De
14/11/2010 07:15:30
 
 
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Titre:
Re: Alaska
Versions des environnements
Visual FoxPro:
VFP 9 SP2
OS:
Windows 7
Divers
Thread ID:
01488800
Message ID:
01489067
Vues:
142
>Keep dreaming

What is your basis for that classification ?
There are transpilers / cross compilers currently running for languages much further apart,
like Cython moving nearly all Python to C, Pyjamas to move Python to Javascript,
lots of dynamic language to JVM compiler/interpreters,
not to mention YACC, Bison and so on - xBase or SQL to C to name a few.

I've seen their presentation and talked with them a bit in the last three conference days.
(Their offices are about 12 miles from me, but I am not affiliated in any way)
Three real flesh and blood person - and some of them the same as the year before,
so the company has more stability than etec on that front ;-)

They are definately working on it and parts are already working.
They are not going for the easy fruit first, which was one of Etecnologia mistakes -
Alaska already have much of the needed routines from their Clipper compiler
already debugged and deployed. Going after vfp as a compiler developer
broadening their user base gives me less stomach worries than the etec story
of having to write the compiler to use for their own products.

Their idea of moving the source to something delivering the same runtime
behaviour as the fox code in fox runtime is IMHO better than cluttering
existing controls or making their already overloaded language (similar to some
vfp constucts) more brittle. Working from a domain language approach makes sense,
especially as the works are already in use.

Their plans to implement their Cursor SQL by reusing proven OS
parts sounds reasonable.

That said - there are some heavy rocks on the road.
It ***is*** a smaller company and basing products on it will be a lot harder sell,
especially as they are neither into JVM or CLR. They also favor keeping compatible with
earlier versions - a good thing - but this makes opening up to similar dialects a no-no.
Their dev speed is slower, they openly say that they have missed deadlines before.
The window of opportunity is closing as some of the more "rigid" devs
unwilling to stomach more than 1 language settle into vb, java or c# are settling elsewhere.

For me, a 64-bit product having SPT / cursoradapter functionality, a data aware language
with OO capabilities for a scripting fwk will be an easy sell for my data exploration work -
even if the syntax will be unfamiliar for a couple of days, the RDD's have been in use,
so that is much less worry reason for me ;-)
- but there is doubt if it could be used as the backbone of enterprize
SALEABLE apps as easily as offerings from companies with a higher profile.

Actually I am more looking at/for an embeddable and portable Cursor engine,
and there is doubt that alaska dll's will allow such a pattern as easy as vfp COM
in activeX days for the currently en vogue JVM's.

not betting 20000 EUR but giving them chances before damnation ;-)

thomas
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform