Voy por partes.



En lo referente al esquema "bastante saladito y muy elitista el esquema de
suscripción cerrada", me refería al esquema de suscripción de Vulcan, algo
que para mí no es muy competitivo respecto de las herramientas .Net. Pero
bueno, sus razones comerciales tendrán, a mí lo que me importa es que si
utilizo un lenguaje y este tiene errores no tengo porque suscribirme a nada, o
lo que pagué no alcanza?? Es un tema largo...



Cito por ejemplo el problema de la 2.7 (o 2.6 no recuerdo), que tenía un error
trabajando con Excel y resultó ser un bug del lenguaje... la solución sólo
estaba disponible para suscriptores Platinum. Si yo tenía un Upgrade o si la
solución resulta salir luego de vencer la suscripción ... fuiste, te quedaste
con un pisapapeles.



Si, ya sé, todos tienen clientes preferenciales a los que se les dá info de
1era, pero un error básico como poder interactuar con uno de los programas más
utilizados ... no es muy "user friendly" no?



Respecto a el paso lógico, es lógico ;)



A mi entender, como decía, Vulcan llega demasiado tarde. Pensemos que el
desarrollo de esta herramienta arranca junto a VO 2.6 (2.5 casi) y recién hoy
podemos decir que se halla estable como para poder desarrollar seriamente.



Ahora, material formativo, ejemplos, soporte de VB.Net y C# hay como para fundar
una Internet paralela. Ojo, al referirme a VB.Net no estoy hablando de VB de
Microsoft. Este es un error muy común, no olviden que .Net es un estándar y
Microsoft sólo desarrolla lo que le conviene, pero hay un mundo de lenguajes
pululando sobre la plataforma, F#, J#, PHP, etc.. (Vulcan incluído).



Por ejemplo, yo utilizo VS 2008 para programar aplicaciones en VB.Net; pero
podría utilizar SharpDevelop sin problemas, claro, sacrificando algunas
posibilidades, pero con iguales resultados y costos sensiblemente diferentes.



Respecto de las DBFs. Lo que nos comenta Juan a cerca del cliente de Advantage,
es cierto. Otro punto a mi favor y en contra de trabajar con Vulcan.



Hasta ahora, las charlas que mantengo con desarrolladores tienden a desprenderse
de las DBFs y lamentablemente no hay muchas alternativas o desarrollamos para
DBFs o con motores.



Para quienes tienen hoy aplicaciones Clipper, los (x)Harbour pueden ser una
alternativa potable, ahora están muy estables. Pero para los que pretenden
desarrollar aplicaciones Cliente/Servidor... al menos hasta hoy ... la única
que conozco es trabajar con (x)Harbour y SQLRDD (comercial) que brinda un RDD
para migrar las DBFs a SQL.



Insisto, es mi punto de vista. Quizás mañana o la semana que viene, vea Vulcan
y piense distinto (no creo) pero bien podría haber otra herramienta que no
conozco.


Claudio G. Torrillo

ClipSupport Argentina





De: tonet@... [mailto:tonet@...] En nombre de
Piazza Sistemas
Enviado el: jueves, 04 de diciembre de 2008 09:49 a.m.
Para: tonet@...
Asunto: Re: [tonet] Vulcan y Dxperience



Buenos días Claudio, como estás?

Podrías explayarte acerca de la expresión: " yo creo que el paso lógico de un
programador VO es el que tu has dado" ? Te referís a pasar a VB.NET?

Y acerca de que DevExpress es "bastante saladito y muy elitista el esquema de
suscripción cerrada" ¿Como es esto?

Saludos!

----------------------------------------------------------
Fernando Piazza
Coronel Suárez



[Se han eliminado los trozos de este mensaje que no contenían texto]