Alternativa a Visual Fox

[syscontri EC]

Saludos grupo. 

Estaba revisando esta página, se ve que están trabajando en que xsharp sea compatible con Visual Fox.

Este link lo dejó David Acuña

https://www.xsharp.info/forum/public-vfp

Que opinan estimados?

Saludos!!!

[James Suárez]

Mucha gente habla de alternativas a VisualFoxPro, pero en realidad quieren alternativas? EN realidad están dispuestos a apoyar proyectos como estos? 

Soy el creador de Kodnet, sinceramente pensé que iba a tener más acogida al liberar el código pero de hecho no fue mucha.

En lo personal quiero empezar un "Parser" que funcione 100% con el Léxico de VFP y luego quiero empezar a añadir las funciones internas de VFP, al menos un proyecto por diversión. Si el proyecto va a más y tengo apoyo financiero trataré de convertirlo en un reemplazo 100% de VisualFoxPro. Eso sí yo no quiero usar nada específico de Windows para el core, quiero que sea lo más crossplatform posible. 

--
Has recibido este mensaje porque estás suscrito al grupo "Comunidad de Visual Foxpro en Español" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a publicesvfoxp...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/CAD--dOYomBLSqEXyoPwEKj3Awq1R2pqFauptepG41QgmFTB15A%40mail.gmail.com.

[Irwin Rodriguez]

Celebro tu iniciativa pero honestamente pienso que te estás apuntando un proyecto hercúleo en tus hombros y más si lo tomas por hobbie, eso si acaso logras conseguir patrocinantes. Me recuerda a Rick Hodgin con Visual FreePro (ni siquiera sé si lo sigue trabajando), hablas de un parser pero quién estaría detrás del parser? piensas usar las bondades de un compilador ya existente y crear una capa adicional?, y de ser así, no sería demasiado lento al someterlo a pruebas de estrés?

Por otro lado, yo en particular estuve viendo tu clase KodNet y si me parece una herramientas interesante, por lo menos está por encima de la DotNetBridge en ciertos aspectos, pero como sugerencia para futuros sponsors o colegas que te apoyen en el core, tienes que dejar algo más que soltar el código a secas, así como lo soltaste apenas se puede masticar. Tal vez con una buena documentación, quizá otros se sumen a tu iniciativa y quieran colaborar.

Bueno en todo caso, enhorabuena por tus aportes e ideas.

saludos!

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/CAFiS3qVDwgJz%2BK%3DaGmdBLH-WxDKcWmjK1bkD45uUf7nzsRqaQw%40mail.gmail.com.

--

Irwin Rodríguez

Programmer Analyst

"A team is only pieces that you exchange until you finish the work, it is efficient, it works."

[James Suárez]

Irwin en parte concuerdo con lo que dices.

kodnet en particular fue un proyecto que hice hace unos 6 años (cuando tenía 19). Si lo hubiera hecho ahora que he madurado un poco en mi visión y mi oficio como programador, seguro habría mejorado varios aspectos técnicos del código y documentación. Lo liberé hace poco porque estoy queriendo sacar todas las herramientas que había hecho en el pasado para VFP 

Lo de la lentitud es lo de menos, estoy seguro que puedo lograr que el parser sea más rápido que el motor actual de VisualFoxPro. Y estoy seguro de eso porque VisualFoxPro como intérprete es "muy lento" en comparación a otras plataformas (basta con crearte un ejemplo sencillo: una funcion que sume dos números, haz la prueba contando cuanto tarda en ejecutarla 1 millón de veces, para darte una idea, en una máquina que tengo, en VFP tarda 1,554 segundos en el motor V8 de javascript tarda en un código equivalente a eso 0,006 segundos ), y  yo mismo hace unos 6 años igualmente (poco después de lo que ahora se llama kodnet), ya me había hecho un parser del lenguaje, con las funciones internas, escribiendo el parser, el intérprete y las funciones base (exceptuando las de DBF aún no llegaba a esa parte, aunque había puesto en cambio SQLite embebido) completamente en C#. Y bien recuerdo que logré hacer que corriera muy por encima de lo que corre VisualFoxPro. En ese tiempo no era tan ordenado con mi código terminé PERDIENDO casi todo ese código, pero recuerdo que me sirvió mucho para afianzar mis conocimientos en programación y algo de eso lo iba a aplicar en kodnet pero nunca terminé haciendolo (eso le hubiera dado aún más velocidad al proyecto de kodnet, ya que se aplicaba compilación JUST-IN-TIME con el manejo de System.Reflection.Emit de .NET)

Y volviendo a kodnet, entiendo lo que me dices, pero siento que en sí kodnet no necesita mucha documentación, tal vez ejemplos. Traté de incluir varios ejemplos en el proyecto que sirvan de base. De todas maneras para usar kodnet se necesita más que todo saber de .NET Framework   

También ahora de manera específica digo que si alguien quiere aplicar kodnet para algo en específico pero no entiende mucho del .NET Framework o no encuentra como puede hacerlo, yo puedo trabajar en ello, y eso me serviría para seguir encontrando cosas por mejorar en la librería.

SIn embargo tú como usuario Irwin, que más esperarías que haya en la documentación? Has visto los ejemplos? QUé otros ejemplos serían útiles? 

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/CABooBB%3DxZzofi_%3DTPDhVnkbF1bfVT1qiJQPS3C85aEr5h-VaGg%40mail.gmail.com.

[James Suárez]

Y por cierto a todos los que también están buscando lenguajes alternativos a VisualFoxPro, quiero decirles que no solo tienen que pensar en lenguajes para Windows. MIcrosoft siempre ha sido muy monopolizador. Recién ahorita está haciendo opensource el .NET core cuando vio que perdió mucho terreno en el ámbito "Servidores" con GNU/Linux y la verdad aplaudo ese espíritu, pero aún me deja dudas si está por el camino correcto (sobre todo viendo que en .NET core 3 ya implementaron WPF y Windows Forms , pero aún no implementan ninguna GUI para GNU/Linux o Mac)

En lo personal yo ahora programo en Node.js creo que puede ser una buena opción para algunos, ya que al igual que VFP es una lenguaje dinámico, single thread, pero añade todo el poder de clusters, y operaciones asíncronas (async/await)

Y les muestro mi proyecto: https://github.com/kodhework/kawix   que no es más que nodejs + superpoderes (typescript + todas las características nuevas del standard EcmaScript). En proyectos de escritorio lo uso junto a Electron ,  que de hecho lo incluyo dentro de mi proyecto kawix  como una librería que se instala y carga on demand. Para CLI es una delicia trabajar con lenguajes de tanta sencillez como javascript/typescript y para WEB igualmente, y también está incluida en mi proyecto la librería DHS que es un server web bastante configurable, y que permite cambios en vivo sin reiniciar la aplicación. 

Recién está en la versión 0.7.1, pero de hecho, ya lo he usado con algunos usuarios de este grupo, ya que cuento también con un proyecto de comunicación VFP-Kawix que permite expandir las capacidades de VFP a cosas que naturalmente no tiene: requests, sockets, etc. (podría decirse de cierta manera que algo como kodnet   con el .NET framework)

BIen, me iré a dormir es tarde acá, xD 

El jue., 3 oct. 2019 a las 0:24, syscontri EC (<syscon...@gmail.com>) escribió:

[Irwin Rodriguez]

Entonces tu idea sería crear un parser de VFP para Node.js? de ser así me parece genial, y coniciendo la estadística que me acabas de dar entonces no llegaría ni a las 0,010 milésimas de segundos, eso suena bastante interesante. Para empezar el parser debería comenzar por cubrir el 90+ % del core de VFP, luego trabajar el parser de formularios y clases visuales pero recogiendo estos últimos como código en lugar de binarios, por ejemplo usando el classbrowser para casos concretos o bien usarlo en masa con FoxBin2Prg. Se ve muy cuesta arriba y harán falta muchas manos hábiles y tiempo. Ambos recursos son tan valiosos como finitos así que bienvenido sea quien se quiera sumar a la iniciativa.

Saludos!

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/CAFiS3qXdBCgxpiLY_Bt8%3DkABBCr%3DY4EJa_aoqi5Z6kGwCQjysA%40mail.gmail.com.

[James Suárez]

Irwin sí, exactamente jaja, no lo dije oficialmente pero sí, lo había pensado para nodejs (aprovechando la gran velocidad del motor V8). La curva de tiempo sería menor que programarlo en c# por ejemplo, ya que con node.js se puede aplicar transpilación  y seguramente correría más rápido que si crearamos un interprete propio en C++ o C# (ya que v8 es un motor bastante rápido) . Escribir el parser, luego escribir las funciones base, esto es relativamente fácil, DBF y OBDC tal vez nivel medio, y la parte complicada viene con los Forms - Reports pero tampoco es imposible y de inicio igual se tendrían opciones como electron que ya están creadas. 

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/CABooBB%3DYO4YS2M7gSOqaU-oj8O5HrWJi-SUg8r7h0ZA4h7kh_A%40mail.gmail.com.

[Luis suescún]

Irwin Rodríguez y James Suarez, a mi personalmente no me queda sino felicitarlos por como hablan de todos estos temas, parece que es un juego, se nota el conocimiento que tienen, desafortunadamente no se ve reflejado en herramientas que sean de uso general(sin dejar de reconocer sus inmensos aportes) y que sean proyectos tales como se encuentra uno por ahí(angular, Django, laravel), entiendo que para eso deberían poner todo a costo de ustedes y en ese sentido no es nada fácil, les toca tomar una decisión, o dejan sus conocimientos para aplicarlos en proyectos personales o se lanzan al mundo de la programación por reconocimiento y meritocracia porque al parecer hasta Microsoft está reculando de su objetivo original que era sacar dinero de todo(ya lo hizo), pues en herramientas de programación se está quedando atrás y le está tocando remar a cuatro manos para intentar recuperar terreno perdido, pues ya vemos que en lenguajes, frameworks y cualquier clase de herramienta que se necesite para desarrollar están tiradas por ahí, y bien buenas, solo nos toca a nosotros saber elegir cual y gastarnos el tiempo que dadas nuestra habilidad y capacidad nos demande tal objetivo...

Por éso, solo les puedo expresar mi admiración y respeto en este asunto y que buen debate.

Que cosas se llegarían a hacer?  si un equipo de unas 6 u 8 personas(identificadas) de este foro se unieran para jalar hacia un mismo lado de la cuerda..

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/CAFiS3qWxvKbYgCF-wixuG1%3D%2BpFo2gqJvRoHv4XMhM3Uu1QYsYQ%40mail.gmail.com.

[Carlos Miguel FARIAS]

Pregunto: Las opciones como dBase, xBase (Alaska), Lianja, etc. no funcionan? 

Porque lo que he visto, podrían reemplazar a VFP. En mi caso ya estoy con Python y ya no desarrollo aplicaciones en la parte privada pero veo que abarcan S.O. y aplicaciones Web.

Saludos: Miguel

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/CALB_FW70Lio1DyKdLmfo2bYc35%3DsDG8uqZqfOywPQBQHXnk8RQ%40mail.gmail.com.

[Carlos Vargas]

O las alternativas xharbour ó harbour que solamente son compiladores y con ayuda del prepeocesador ya tendrian muchas funciones de vfp, seria crear una lib vfp.lib por poner u ejemplo y toda la parte gui