¿Seria factible un fork de Harbour para VFP?

[Carton Jeston]

Como muchos sabéis, hay un lenguaje Xbase de código abierto compatible clipper 5.2 que lleva muchos años entre nosotros y esta muy maduro. Es multiplataforma, permitiendo desde xbase generar C y compilar con ming u otros compiladores. Su objetivo es estrictamente tener la máxima compatibilidad con clipper y a la vez añadirle nuevas posibilidades para expandirlo a otras bases de datos y otras características.

Llamativo es el caso de xHarbour un fork que nació con la idea de no buscar la compatibilidad sino que prima su ampliación y adaptar a los nuevos tiempos aunque perdiese la compatibilidad. Parece menos activo y no soporta tantas plataformas, aunque hay un editor ide-rad comercial llamado Visual xHarbour que tiene una pinta estupenda muy profesional.

Hablando en el otro tema con compañeros sobre el rad y su sustitución con otras herramientas como qtdesigner, veo que harbour ya tiene implementadas muchas de estas librerías. Yo hace años me pregunto si seria viable hacer un fork de harbour para foxpro, aunque no fuese 100% compatible pero que tuviese aquellas cosas que nos gustan de fox y sobre todo la sintaxis y la forma de programar idéntica. Teniendo en cuenta que muchos comandos de clipper y fox tienen muchas cosas en común, seria el paso mas lógico para tener un fox open source.

Si, hay que tener los pies en el suelo y es un trabajo enorme, solo quiero saber si alguien ha intentado alguna vez estudiar esa vía aunque solo sea por curiosear. Ojo, aqui estoy hablando de un caso hipotético, porque detraes de ellos hay una tarea inmensa. Esto solo es un ejercicio de ideas y un debate abierto para mentes constructivas ;-)

[Carton Jeston]

Se me olvidaba para los mas curiosos...

Harbour web: https://harbour.github.io/

Exe: https://sourceforge.net/projects/harbour-project/files/latest/download

Codigo fuente en C: https://netix.dl.sourceforge.net/project/harbour-project/source/3.0.0/harbour-3.0.0-src.zip

[Irwin Rodriguez]

Una vez lo intenté y llegue a crearme una aplicación pequeña, la forma de trabajar es muy similar a VFP, usé un IDE libre y más o menos me pude defender. Creo que se puede lograr algo bueno pero como dices, es un trabajo arduo y se necesita de la ayuda de todos los que se sientan capaces. Si se deciden por algo nomás me avisan...

Saludos...!!!

--

Irwin Rodríguez

Analista Programador

+593 0994903424
Latacunga - Ecuador

"Un equipo solo son piezas que intercambias hasta que terminas el trabajo, es eficiente, funciona."

[Salo K]

Me hiciste caer una lágrima... recordar tiempos de Harbour/Fivewin....

Cuenten conmigo

--

Salo

[Hernan Serrano]

Y por que en vez de empezar con algo nuevo. No se pone el esfuerzo en algo. Que esta pensando para Nuestro querido Zorro. Y ya lleva años desarrollandose. Pero ha sido un esfuerzo de solo una persona.

https://www.facebook.com/profile.php?id=404179816309642&ref=br_rs

Visual Free Pro (VFP)

Rick C. Hodgin

En algun momento pidio ayuda a la comunidad pero no obtuvo respuesta.

--

Tico Support S. A.
Tel. (506)8819-4369

[Diego Fazio]

Yo me pase de V.Fox a Harbour hace años y la verdad no estoy para nada arrepentido. Creo que hoy Harbour esta mucho mas avanzado a VFP con respecto a lo nuevito(cURL/OpenSSL) y en lo visual existe QT que esta buenisimo y es muy simple de implementar en Harbour. Es compatible con casi todos los tipos de bases de datos, la sintaxis de programacion es muyyyy parecia da la de VFP. Por esto es que la migracion no les resultaria tan complicada. Y lo mas importante!!! Corre en windows y en linux.

Se los recomiendo...

Diego.

[Carlos Miguel FARIAS]

Lo de Hodgin está por enésima vez detenido (en realidad, salvo expresiones de deseo no ha avanzado mucho). Desde 2015 que no se ve que lo esté desarrollando.

Es mucho más serio lo de Chen que al menos periódicamente da señales de avance (más allá de la discusión de la legalidad).

Lo que estaba bueno era lo de etecnologies, que era VFP sobre .NET más una serie de mejoras notorias, con la ventaja de que el RAD ya está.

Saludos: Miguel

[almonts ( www.ontarioxb.es )]

Totalmente de acuerdo con los comentarios. La verdad es que no entiendo cómo no se ha intentado antes. Yo he hecho mis pinitos con Habour Minigui + MariaDB. la curva de aprendizaje es mínima. Eso sí, siguen siendo aplicaciones de escritorio

[Jorge Galván Pérez]

Y que paso con este proyecto murio en el intento????

http://www.alaska-software.com/products/fox-compatibility.cxp?gclid=CjwKCAjwq57cBRBYEiwAdpx0vWwjzC3usZlL0KWOIyJ6iQqs8BY_kNZ5OkfzVmbTB86q5pn2R3Bv1hoCacAQAvD_BwE

The Visual FoxPro Successor Alaska Polar

[almonts ( www.ontarioxb.es )]

Adjunto un vídeo que publiqué en su día en Youtube de un ejemplo de harbour Minigui + MariaDB. Es una contabilidad prácticamente acabada, pero la tengo aparcada ya que el Fox de momento me da mucho trabajo.
Mencionar que el harbour Minigui es totalmente free. Los formularios los genero con un prg muy básico que desarrolle en Fox

https://youtu.be/Mm6-X3Q_gHI

[Jorge Galván Pérez]

https://www.alaska-software.com/landing/foxpro/start.cxp

PolarFox: ¡la próxima generación de Visual FoxPro!

[Edgar Acevedo]

Algunos compañeros han hablado pestes de DBASE.  Sus buenas y muy fundamentadas razones tendrán.
Yo probé la más reciente versión del (DBASE PLUS 12) y la verdad, no me dio los errores que muchos han publicado.  Creo que es porque soy tan mal programador, que mis programas no exprimen a fondo el hardware y por ello no tengo problemas con este producto (DBASE PLUS 12).

Incluso lo sentí muuuuucho más amigable de aprender (y adaptarse) que los proyectos basados en HARBOUR. Y tienen planes de orientar sus próximas versiones a mayor inter operabilidad con dispositivos móviles y desarrollo web.  

DBASE:  http://www.dbase.com/
DBASE PLUS 12:  http://www.dbase.com/dbasesql/features/

Pero no me creas, de repente y soy muy baboso como para llevarlo al límite.  Pruébalo y saca tus propias conclusiones.

Saludos,  Edgar Acevedo.

[Carlos Miguel FARIAS]

No es factible hacer un fork de nada para VFP. No al menos por esta comunidad.

Para hacer un fork de un desarrollo en C/C++ (con eso está hecho casi cualquier entorno tipo xBase) hay que tener un grupo de programadores C/C++ lo suficientemente avanzado. Por los comentarios en el foro, no debe haber más de 10 con conocimientos y menos con tiempo para destinar.

Hay buena cantidad de productos xbase ya disponibles. 

dBase / Visual dBASE de dBASE Inc. : muy interesante, hasta sacaron una versión actualizada para emular DOS en windows. Soporta móviles y Web

(dBXL/Arago) QuickSilver descontinuado desde 1995

Clipper de GrafxSoft descontinuado en 1997 pasa ser CA/Visual Objects y ahora Vulcan.NET

Flagship y Visual Flagship -> un fork para Clipper para varios S.O. no windows, pero creo compila windows también

FoxPro y Visual FoxPro de Microsoft oh mira vos!!!

xBase++ de Alaska Software

Recital de Recital Corp. -> Lianja

Proyecto Harbour y su fork xHarbour

Fivetech...y muchos más

Y ustedes quieren hacer otro más. Cual de estos figura como muy usado, el otro día comentaban que VFP está como 50 en la lista de populares... Además varias proyectos anteriores, bastante avanzados se dejaron de lado por falta de apoyo, o dispersión de apoyo.

Hay muchas opciones ya en curso y más de 250 lenguajes disponibles,

Bueno, nada es imposible, sobre todo hoy que es viernes

Saludos: Migue

[mapner]

Creo que tenemos dos próceres a los que les debemos respeto y homenaje

Wayne Ratliff, el creador del dBase (dBase II y luego dBase III)

https://en.wikipedia.org/wiki/Wayne_Ratliff

y 

David L. Fulton, creador del FoxPro

https://en.wikipedia.org/wiki/David_L._Fulton

Saludos!

[Ivan Aguirre]

Yo siempre los leo porque siempre hay algo interesante.  No entiendo porque no les gusta C#, para mi, en mi humilde opinión, es el verdadero sucesor de Fox, pero bueno, es mi opinión. Dbase, lo intenté una vez,  pero tienen una web muy agresiva, tras registrarme, me volvían locos con los mails, -todavía deben estar llegando como spam-  y me pareció complicadísimo, además admitieron mentirme cuando les pregunté si tenia posibilidad de sacar una aplicación web....  uno sueña, que agarran tu proyecto fox y lo pasan a la web con dos clicks, y no, nada de eso...

Lo de Alaska polar, me parece un capturador de mails solamente.

Pero yo, desde que tuve mi primer contacto con Visual Fox, nunca usé las bases dbf más que para cosas puntuales pero no como base de datos, a lo mejor por eso, yo siempre use MSSqlserver desde la versión 6.0 que lo único lindo que tenía era el semáforo. La versión web la tenemos hecha en C#, y la de escritorio todavía está en fox. Chen, me envía info, me gusta lo que hace,  pero todavía no lo he visto en detalle.

[mapner]

Ivan, que bueno tu experiencia de C# en reemplazo a VFP. La relidad es que C# tiene un nivel de complejidad bastante mayor que el lenguaje xBase en el que se basa VFP y tiene una curva de aprendisaje mucho más pronunciada. Un programador VFP tarda un tiempo considerable en convertirse a C#, y ahí está las ganas de invertir tiempo y esfuerzo de cada uno. Yo hice desarrollos en C# pero de temas particulares como el uso de web services. Lo bueno sin duda es el IDE de Visual Studio que automátiza un montón de tareas al desarrollar.  

El tema de MS es que pareciera que siempre te va a mentener cautivo en sus entornos, o sea, .Net fue pensado para correr en ambientes Windows, no hace mucho sacaron la versión .Net Core que supuestamente es multi-plataforma, pero conociendo a los muchachos de MS no se sabe cuanta continuidad va a tener. Yo viré hacia Java que me parece un entorno más que potente y por ahora la evolución de producto pareciera más estable que los vaivenes de MS, pero es cuestión de gustos. Coincido que todos los otros intentos de xBase no han prosperado (ej. dBase XII es un rejunte de cosas que no funcionan del todo bien...)

Saludos

[Antonio Meza]

Mapner!!!

En el caso de muchas paginas del gobierno Mexicano están desarrolladas en Java y otros programas, pero es un verdadero dolor de cabeza para el usuario final hacer que funcionen las paginas con los navegadores, no se si te pasa lo mismo, por esa razón descarte a java, esta la pagina del sat para realizar todo tramite, la pagina del IMSS esta te podrán contar varias historias de terror jajajajaj en fin a cada rato que debes actualizar java en la pc, que esa versión de java no es compatible, instala X versión, ahh pero como usas otro programa ese programa solo funciona con X versión, entonces mejor compra otra maquina!!! una para el sat, otra para el IMSS, otra para los coves, porque cada una requiere X versión de java jajajajajaja ahh se me olvidaba olvídate de windows 10, debes usar windows 7!!!! en fin un pesadilla.

saludos

Antonio Meza

[mapner]

Antonio,

Java lo utilizo solo para el back end (reglas de negocio y acceso a datos), y en forma de interfaz RESTful, en el front end tengo una librería Javascript que recibe JSON, sin saber en que tecnología se lo están mandando. Esto hace que Java no se meta con la UI. Fin del problema. 
Lo que me contás es un estilo de desarrollo un poco arcaico donde se desarrollaba todo en JSP (Java Server Pages) similar a como trabaja el viejo estilo de PHP, mezclando cosas de la UI con código de servidor. A la vez, desconozco la calidad de la aplicación que comentas donde la plataforma puede ser sólida pero el desarrollo malo. Sobre las versiones de Java en general tienen buena retro-compatibilidad, el tema son las librerías add-ons como en otros entornos que funcionan con tal versión del lenguaje madre (pasa en PHP, Python y etc.).

Saludos

[Antonio Meza]

Es que comentas que Java te resuelve la vida y no dices la historia completa!! que solo usas una parte en Java jajajajajajajajaj si un programador ve tu comentario diría pues voy con Java y luego se da cuenta que no usas java para todo y se pone a llorar jajajajaja

De hecho en mi caso estoy separando todo para el ambiente web, acceso a datos por medio de API Rest y UI por separado, he probado Flask (phyton) me facino, pero el problema es montar en un servidor en la web, tambien probo Adonis.js otra maravilla pero el mismo problema para montar en la web, y Slim de Php, simple y facil para montar en la web. Al final si me canso con Slim puedo usar Lumen, todo para API Rest.

En la parte UI definitivamente por Vue.js 

Lo mismo hice en VFP, tengo los datos en MariaDb con FoxyDb y la parte visual con formularios.

saludos

Antonio Meza

[mapner]

Antonio, te pido que me transcribas donde puse que Java me resuelve la vida. Creo que lees mal en el mejor de los casos. El back end es la parte más importante de un sistema porque es donde está el modelo y el acceso a datos. Y hoy de hecho, la tendencia es separar en forma muy diferenciada Backend end de FrontEnd. Los sistemas monolíticos hace rato que están perimidos. A su vez, solo cuento mis experiencias, no le digo a nadie que camino tomar ni que le conviene. Eso quizá lo hagan los desbordados de arrogancia... conoces a alguien así? Saludos.

[mapner]

Respondiendo la parte técnica de tu mensaje, en Java hay una especificación para RESTful y una implementación llamada Jersey, que resuelve muy fácilmente el tema de ruteo de URL y de serializacion y des-serializacion de objetos Java a JSON o viceversa (o XML o lo que sea).
Ese API RESTful es el que llama al real Backend que son los objetos Java Entities y los DAO que son donde residen los mapeos de modelos y su manipulación en servicios (CRUD y etc).
En varias plataformas/lenguajes hay framework RESTful, pero la implementación de objetos de negocios me parece (a mi) mejor logrado en Java, C# o en Python. Saludos.

[Antonio Meza]

jajajajajaj que dramatismo !!!! jajajajaja

Es un decir!!! mencionas:

 Yo viré hacia Java que me parece un entorno más que potente y por ahora la evolución de producto pareciera más estable que los vaivenes de MS, 

En ningún momento dices que solo lo usas para API jajajajaj en fin!!! viernes de dramatismo!!!!

saludos

Antonio Meza

[GeoSys Diseño de Software]

Ahora con lo de la facturación electrónica desde  VFP genero los XML y  para el envío del XML a la API de plataforma web utilizo  C# y me resulta muy familiar, cuando uno se acostumbra al uso de las llaves  { }  que no es para nada difícil de comprender, al ser un producto de MS me es bastante familiar, los ejecutables  se crean allí mismo sin ningún esfuerzo extra, la verdad que le estoy tomando el sabor. 

Anthony Contreras

[Carlos Miguel FARIAS]

Bueno, el hilo corresponde acerca de un fork para harbour se fue al ca... Viernes

C# lo veo como un fork de Java, desde la óptica de M$. No veo a C# como reemplazo de VFP, si no una forma de M$ de capturar todos los Ing, en sistemas que conocian Java, el cual alcanzó mucha difusión por sus características pero entiendo que principalmente por la políticas de SUN microsistemas que vendía hardware y promocionaba Unix.

Sun distribuyó en forma gratuita en las universidades todo lo relacionado a Java.

Entonces por lógica, si te acostumbras a tomar sopa en casa (más allá de las bondades de la sopa), cuando salís a ganarte el pan, quieres sopa.

Ahora se está difundiendo python, pero no hay una empresa comercial impulsandolo, simplemente python es más fácil para enseñar y hay mucha demanda de profesionales dando soluciones rápidas. Se necesita terminar programas más rápido.

Si un lenguaje es de código más corto, se escribe y depura más rápido.

Python es lento, si, pero se puede detectar las partes que son cuello de botella, y esa parte la escribis en C. O en Julia o Nim.

No hay un lenguaje que te sirva para todo o si sirve, sea lo más eficiente en todo.

Hoy leía un articulo donde se hablaba acerca de Java y que no había logrado desplazar a COBOL, ni C# desplazar a Java.

Y PHP no va a ser desplazado por Python (y no creo que se caiga Ruby).

Hay gente programando en RPG. RPG el viejo RPG II ya permitía emparejar por 9 columnas de datos (campos) (equivalente a un JOIN), tener 9 niveles de corte de control, con conteos y sumas, sin tener que codificar un renglón de lógica.

Entonces, un lenguaje tiene sus pro y contra.

Y cada cual le podrá encajar mejor en su estructura de pensamiento (racional, emocional, inculcada, comercial, económica o por la pistola en la cabeza).

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la fuerza los acompañe, la suerte está echada (creo que empollando suertudos)

Los xBase tienen 

[mapner]

Antonio, dos temas,
1) si a tus mensajes le sacaras los permanentes "jajaja..." los comprimirías más que el WinRAR :))
2) no entiendo cuando dices que yo al Java lo utilizo solo para API, de hecho Java hace años con JEE es un plataforma del lado del servidor, no un lenguaje de FrontEnd, o sea yo utilizo el Java para lo que está diseñado, soluciones del lado del servidor y no del lado del cliente, del lado del cliente hace rato que hay otras tecnologías como HTML, Javascript, JQuery, ahora Vue entre otras..
El problema de venir desde VFP es que es un único entorno cuasi monolítico en el que toda la aplicación corre en el cliente y solo la parte de datos corre en el servidor. Obviamente al pasar a web o sistemas distribuidos la cosa cambia.
Pero, anticipo tu repuesta como algo así: "jajajaja..." lo cual nos resulta a todos muy simpático. :))
Saludos

[Antonio Meza]

jajajajaja le atinaste!!! es viernes no te estrenes!!! 

Para que no te sientas mal, mi comentario fue un decir que tu con Java lo tienes todo, si te lastimo mi comentario tengo Vitacilina a que buena medicina!!! jajajajaj

En fin que quieres que diga? que me equivoque!! perfecto !! me retracto me equivoque, leí mal, me exprese mal, dije mal, pensé mal, estoy erróneo, falso, negativo, así o mas??? 

P.D. Le pido perdón a Marped en nombre de todos los compañeros programadores del mundo mundial!!!

Listo!!!! algo mas??? jajajajajaja

saludos

Antonio Meza

[Carton Jeston]

Bueno, he dejado que pase el Viernes y es una lastima, porque iba a decir que tenia terminado el fork a ver si alguno se lo creia pero al ser Sabado ya seria mentir jajajaja (c)AntonioMeza  ;-) Vuelvo a defender a Antonio y su humor acido, es un jodedor patologico pero sin malas intenciones, excepto cuando toca temas "sensibles" que hay que flagelarlo un poco para que vuelva al redil ;-)

Sobre Java y C#, nunca me gusto el primero (C transnochado) y C# (C para flojitos) viendo si con C# Native evitan la descompilacion o puedo evitar depender de MS, me lo pensaria para ciertas cosas. No se tomen a mal lo de C trasnochado y C para flojitos, que el humor no debe limitarse a los Viernes :-D

Curiosamente Anthony comenta el uso de las llaves { } en C#, justamente eso fue uno de los motivos de que en los 90 lo prefiriese antes que el begin-end de pascal (con lazarus me ocurre algo parecido) o que xBase no lo necesite y sea mas "humano" que otros "basic" es un detalle. Otro fue que podia expandir con C y ASM a clipper y en aquella epoca con eso ya eras todopoderoso ;-) Con esto quiero poner el foco en lo que hemos hablado en otros hilos sobre manejar mas de un lenguaje o usar diferentes herramientas en vez del todo-en-uno a lo que estamos acostumbrados, nunca hay que descartar nada simplemente porque es diferente.

Aparte que escuchar lo que tiene que decir los demas, hacer una pausa antes de responder, te das cuenta de lo mucho que se aprende ;-)

Miguel, como siempre pareces la voz que dice lo que nadie quiere oir, pero no hay nada que decir cuando tienes la razon. Es casi imposible que salga un fork desde esta comunidad porque es algo demasiado ambicioso pero he querido implantar esa idea en todos vosotros para empezar a debatir sobre ese tema dividiendo lo imposible en partes mas pequeñas, ver las diferencias, que se echa de menos que tenemos en fox y en harbour no (algunas evidentes), etc.

Hernan, Holding estuvo por aqui pero no consiguio convencer ni siquiera a algun peso pesado de fox, porque no vieron claro el rumbo del proyecto y las relaciones personales no eran del todo fluidas. En mi caso, a sus ojos debia ser tan malo como la niña del exorcista, le propuse que mirase harbour para ahorrarse muchisimas funciones en comun con fox, pero obtuve la misma respuesta que el de esta comunidad. Espero que tenga suerte en su proyecto y lo termine algun dia.

Chen acaba de enviarme hoy la ultima version con el fix40 de VFPA sobre un problema con objetos grandes en los informes y tambien afectaba al compilador. Ahi veo unos de los pilares del "futuro" de fox, sobre todo evitar que si un dia una actualizacion de windows nos tumba fox, el esta capacitado para resolverlo. Lo malo que veo es la dependencia del ide, funciona pero no se adapta a los nuevos tiempos. Tambien entiendo que hay otras cosas mas importantes como adaptar el entorno, librerias y compilador a 64 bits. Personalmente tiene todo mi apoyo y aunque tengo fe en su persona y su trabajo, no tiene que impedir que vea otras alternativas incluso combinando ambas cosas.

Salo, Irwing, Almonts y especialmente Diego Fazio que paso definitivamente de vfp a harbour, creo que pueden aportar mucho con su conocimiento en estas diferencias. Y a eso vamos...

Te encuentras variables tipo x :=0 u objetos form1:title que te dejan ojiplatico pero veo que acepta x=0 o form1.title.

Hay comandos como scatter que no existen pero hay una libreria hbvfoxpro que lo incorpora junto con otros.

Tiene caracteristicas de clipper5 para expandir el lenguaje mas alla de funciones usando comandos tipo @ 0,0 GSAY PICTURE .... lo que resulta un modo mas natural de incluir esos comandos que usabas en fox.

Llama la atencion el desarrollo de gui, hay ide's que lo hacen pero veo freeware o de pago, en la jungla de harbour uno se pierde con facilidad con tantas opciones. Es envidiable el uso de interface QT desde harbour, ignoro si existe alguno que aproveche bien esta caracteristica para la crear formularios visuales y genere ficheros en codigo que a su vez pueda ser leido por el ide para su modificacion sin tocar programacion como he visto en Purebasic. Otros usan QTdesigner convirtiendo el formato ui en xml, tambien se puede interpretar el SCX/DBF pero pienso en el control de codigo fuente para todo esto (gracias fernando). Y con los formularios tenemos las clases visuales que son primos hermanos pero con un plus de complejidad...

Para informes se usa mucho el easyreports, dice tener cosas interesantes de cara a la creacion de informes por parte del usuario, aunque no dejo de pensar en nuestro querido foxypreviewer  cuando hablo de informes...

Como no, las bases de datos son ampliamente soportadas, desde DBF/CDX hasta las mas potentes. Desconozco si tiene esa facilidad de foxydb en su manejo, pero ya se vera.

Al final ves un proyecto de fox o cualquier lenguaje con ide y te encuentras basicamente, tablas/db, formularios, informes, librerias, codigo y poco mas. La realidad es que hay cantidad de posibilidades que te ofrece a la hora de trabajar y eso es lo mas complejo junto con el lenguaje y funciones.

Sintetizando un poco:

¿existe algun informe donde se vean las diferencias en la sintaxis en el lenguaje fox/hb? los comandos identicos, los que hacen los mismo pero con otro nombre, los que no existen, etc.

Un diseñador visual de formularios que lea/guarde en QT, asi no estar atado solo a windows, sino tener una solucion multiplaforma en el gui.

¿el sistema de reportes es igual o mejor que el de foxpro?

No quiero hacer mas preguntas, solo abrir un debate sobre la problematica de un programador fox encarando harbour, que necesita tener para resultar no igual a foxpro, sino "atractivo", no buscar un fork si es demasiado pretencioso, sino un conjunto de herramientas o un framework que te haga la vida mas facil.

Tambien puedes pensar para que moverse de fox, de hecho yo no lo voy a dejar, pero veo posibilidades "extra" dentro del xbase que tiene harbour como ios, android e incluso hay un modulo de apache para harbour y creo que un servidor nativo que mereceria estudiar. Todo esto puede ser un complemento para llegar con xbase a plataformas que estan actualmente fuera de nuestro alcance. Y todo eso no es para desanimar a que estudies java, C#, Julia, Nim o lo que sea, ya que no es incompatible.

Y todo esto lo digo desde un enfoque teorico casi un juego o cacharreo, luego sabemos que casi todo acaba mal, pero antes de seguir quejandome por estar abocado a la extincion prefiero fantasear con algo plausible, que siempre ha estado ahi desde hace 18 años pero desde fox pocos lo han tenido en cuenta :-)

Buen fin de semana

[Carlos Miguel FARIAS]

👏👏👏

[Miguel A.]

Buenas tardes,

Primeramente, os voy a contar mi vida, en un párrafo para no aburriros, y porque, por lo que he visto, no es muy distinta de la del resto de la gente de este foro. Dentro de unos días cumpliré (s.D.q.) 63 años; en los años 80’-90’ he programado en Cliper y dBaseIII y IV, luego me pasé a VFP y aún sigo utilizándolo en la versión última 9.2. En lo que a base de datos se refiere, sigo siendo un fósil: continúo utilizando dbfs (y no me sonrojo por ello), algunos de ellos con varios millones de registros. Reconozco que no he sabido cómo resolver las opciones de búsqueda, actualización, etc. con otras bases de datos.

A lo largo de este tiempo siempre he creído que necesitaría actualizarme, para no quedarme colgado de una liana como Tarzán. Y para ello necesitaría:

• Una base de datos de referencia, preferentemente libre de royalties, etc., que incluya conocer de una forma fácil (al menos para mí y los que aún no hemos sabido cómo pasar de un dbf a otra BD) para crearla, conectarme con ella y actualizarla, sobre todo a través de VFP.
• Un entorno de escritorio, para lo cual dudo mucho que exista algo mejor que VFP, por lo que en este punto, creo que tenemos nuestro trabajo hecho y podríamos seguir utilizándolo largo tiempo.
• Un entorno web, para hacer accesible nuestra BD a través de Internet, o de una APP; para lo cual estimo que existen muchas alternativas, relativamente fáciles de analizar y de implementar en función de nuestros intereses.

Así pues, la gente que esté como yo, con una pata en el siglo XX y otra en el XXI, a punto de jubilarse pero que quiere dejar algo funcionando a las próximas generaciones, creo que, si lo que he planteado es lógico, deberíamos de:

• Discutir cuál es la BD, o las BDs, que más nos puede interesar. Y, una vez definida, trabajar sobre ella/s en las opciones comentadas de acceso, actualización, etc.
• Cuál es el lenguaje web que mejor se adapta a esa BD, para que cada uno confeccione el entorno cliente que más le convenga.

Personalmente agradecería que los mensajes relacionados no utilicen toda esta parafernalia anglosajona y de siglas que los puristas informáticos utilizáis y que obligan al resto a realizar una navegación alternativa para intentar saber qué nos están contado.

Es posible que esto no sea más que una propuesta absurda, propia de un abuelo sesentón, en caso contrario, los que habéis aportado opinión e información en los múltiples hilos sobre la migración, por favor, darnos vuestra opinión sobre este asunto.

Un saludo,

Miguel A. 

[arti...@gmail.com]

Totalmente de acuerdo contigo, yo sigo usando VFP y estoy por ver a qué lenguaje emigro, pero mientras tanto, sigo con VFP porque es lo que más rápidamente me permite desarrollar, además con la última versión, se abren posibilidades de desarrollar cosas en otros lenguajes, para complementar aquellas tareas en las que VFP no pueda

[Patricio Muñoz]

Miguel

Yo tengo 42 años, me queda mucho tiempo para jubilar, y es por esa razón que al visual fox pro lo he dejado bastante de lado y me he inclinado al mundo web y próximamente al desarrollo de dispositivos móviles.

Ahora, si yo tuviese tu edad, pues ni siquiera me molestaría en pensar en migrar mis sistemas en fox pro. Es casi imposible que en tan solo tres años el fox pro deje de funcionar en los computadores por lo tanto seguiría trabajando tranquilamente en este lenguaje esperando que pasen estos años y después jubilarme tranquilamente o antes de jubilar ver la posibilidad de vender mis sistemas con clientes incluidos a alguna empresa para que le sigan dando soporte.

Me parece que tu eres español, si ese es el caso, me impresiona que en España aún hayan empresas que usen sistemas en fox.

Bendiciones Miguel

--

Saludos

Patricio Muñoz

Pro&Tech

Analista en Sistemas

[Carlos Miguel FARIAS]

Muy bueno el análisis de Patricio. Sin mencionar herramientas, indica ámbitos de trabajo.

Ahora, para tener en cuenta es que los móviles están teniendo una capacidad de procesamiento y almacenamiento similares a notebooks de 10 años atrás.

Y las velocidades de conexión por sin cables son superiores en un orden de magnitud a las disponibles hace 10 años atrás.

Y las interfaces de programación pueden cambiar mucho a futuro.

Por ejemplo Velneo tiene una interfaz de desarrollo muy interesante. Es como que todo es componente y cuadros de diálogo de completar. (Precio y licencia ni idea).

Appinventor: En este momento para aplicaciones de móviles, pero con desarrollo sobre el navegador. La programación consiste en encastrar bloques (tipo lego pero adaptables) y los tiras sobre la mesa de trabajo. En realidad no escribís código, solo pones bloques con un significado semántico determinado (y con la forma que te permite visualizar bien la lógica) y completas nombres, constantes y parámetros.

Miguel A. Vos que decís que andas colgado como Tarzan, hace me acordar que el viernes te cuento de donde sale el grito de Tarzan.

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la Fuerza los acompañe.

[almonts ( www.ontarioxb.es )]

Buenas noches.
Si,
en España hay aún muchas empresas que tienen sus sistemas en Fox. Y además aún alguna vez aparece una oferta de trabajo.
Yo más que un fork, intentaría crear un conversor de formularios e informes a xharbour.
En cierta manera es lo que quiere hacer Alaska xbase++, cojer un proyecto PJX y convertirlo a su lenguaje.
O foxincloud hace más o menos lo mismo.

[arti...@gmail.com]

Yo tengo bastantes aplicaciones realizadas con VFP, gestión de recibos, contabilidad, presupuestos y mediciones, facturación de agencias de aduanas, etc. y todas funcionan a la perfección. En la medida que pueda, me iré metiendo con el tema de WEB, por ahora estoy simplemente asimilando conocimientos, ya conozco algo de HTML5, CC3, Javascript, C# y algo de python y precisamente el problema es este, cada lenguaje tiene sus ventajas y sus inconvenientes o carencias, pero bueno,la cosa es no pararse, avanzar, como sea, sin prisas, pero sin pausa...

[Miguel A.]

Agradezco vuestros comentarios sobre mi próxima jubilación, está claro que esto de "pasar a mejor vida" le gusta a casi todo el mundo, pero deduzco que lo que planteaba en mi mensaje es una tontería, ya que nadie ha respondido a si la forma que veo de buscar una salida al bloqueo en el que estamos es válida o no.

Personalmente creo que el asunto no está tanto en cambiar de lenguaje, como de adaptar la plataforma y la forma de pensar que teníamos con VFP, complementarla para ir evolucionando hacia otros entornos. Por ejemplo, en mi caso, si consigo transformar los DBFs a un entorno de un SGBD y sé como hacer búsquedas y actualizaciones de forma rápida, esto sería un paso de gigante porque a partir de ahí fácilmente podría hacer un acceso web con cualquier lenguaje de los muchos disponibles para ello, al tiempo que continuar utilizando nuestra típica aplicación de escritorio con el zorro. Con esta propuesta, tendría resuelto, prácticamente de por vida, los pasos 1 y 3 que proponía. El paso 2, para sustituir el VFP por otro entorno de escritorio, o bien podría hacerlo utilizando la propia aplicación web en la intranet, o bien empleando el lenguaje que mejor sepa, aunque en este sentido creo que el VFP tiene cuerda para largo.

Patricio, agradezco tu comentario, pero soy empresario y por tanto la empresa para que desarrollo es como mi hija, no pretendo irme a mejor vida y dejarla sin bienes y sin herencia. Aunque me jubile seguiré apoyándola mientras tenga intereses y fuerzas en ello.

Saludos,

Miguel A.

[mapner]

Disculpen que insista, pero el secreto para salir del VFP es dejar de pensar en desarrollo estilo VFP.

En vez de un producto monolítico All In One, se puede apuntar a un conjunto de herramientas que que compongan el mejor entorno de desarrollo:

IDE + SGDB + OOP + UI + Diseñadores

En cuanto a la BD, otro gran "secreto" es el siguiente: traten de pasar al SGDB todo lo que sea resoluble en el SGDB, o sea, si tienen que hacer un query complejo, no hagan tres consultas desde el cliente para luego combinarlas en el cliente, hagan una sola vista o un solo Store Procedure lo bastante potente en el motor y listo. Lo mismo para actualizaciones de datos. De esta manera irán almacenando cada parte de conocimiento del sistema en el lugar correcto. Otro "secreto" del SGDB es elegir el motor adecuado, si es Open Source a mi criterio el más completo en prestaciones es PostreSQL (a su vez, MariaDB es muy completo y Firebird es muy práctico), pero esto como siempre es opinión criterial a gusto de cada uno. Pero si o si, elegir un SGDB lo suficientemente potente para derivar la mayor cantidad de trabajo resoluble de ese lado y así descargar peso en la capa media y en la UI, y no reinventar la rueda cuando la BD ya lo puede resolver. Por eso es importante quienes todavía no hayan salido de los DBF lo hagan con urgencia.

Y también muy importante, separar (muy bien separado) manejo de datos/manejo de modelo, del manejo de UI, casi como si fueran dos aplicaciones independientes, conectadas por una única interfaz o API para quienes gozan con este término :))

 

Como se ve, lo antedicho es muy diferente a lo que ofrecen productos monolíticos de desarrollo, que funcionaron bien en determinado momento pero ahora la necesidad es otra.  Hace rato que estamos en la era de Sistemas Distribuidos (como la web) y hacer rato que estamos saliendo de sistemas manejados casi en su totalidad en el cliente.

Es un cambio de paradigma, no un cambio de producto.

Saludos!

(I M H O)

[Irwin Rodriguez]

Mejor consejo que ese no se puede pedir, gracias Mapner. (y)

--

Irwin Rodríguez

Analista Programador

+593 0994903424
Latacunga - Ecuador

"Un equipo solo son piezas que intercambias hasta que terminas el trabajo, es eficiente, funciona."

[FoxInCloud]

On Monday, September 3, 2018 at 12:29:23 AM UTC+2, almonts ( www.ontarioxb.es ) wrote:

En cierta manera es lo que quiere hacer Alaska xbase++, cojer un proyecto PJX y convertirlo a su lenguaje.
O foxincloud hace más o menos lo mismo.

 

Buenos días a todos,

Solo una aclaración,

FoxInCloud no convierte pantallas e informes, sino que los adapta para trabajar en modo escritorio y / o en modo Web dentro de FoxInCloud Application Server.

El mismo código funciona en modo escritorio o en modo web con VFP9 o VFPA (excepto activeX para VFPA)

Thierry Nivelet, FoxInCloud

(traducido con Google Translate)

[Carton Jeston]

Miguel A. El tema de la base de datos usaria foxydb, pero depende de como tengas estructurada tu aplicacion, puede ser facil o una tarea casi imposible.

Mapner, sabios consejos y totalmente de acuerdo. Añadire algo usando tu frase, el secreto para CONTINUAR en VFP es dejar de pensar en desarrollo estilo VFP. De ahi viene el tema de hablar de harbour (fork, framework o lo que sea) como apoyo, expansion o sustitucion de VFP pero adaptando el lenguaje o su forma de trabajar a los nuevos tiempos.

Tambien hay que destacar el trabajo de chen y foxincloud por llevarlo a otros niveles, aunque no dejan de ser parches muy trabajados sobre un producto que no se esta desarrollando actualmente y al no ser open source estamos un poco vendidos. Y eso se nota en la comunidad harbour o con lazarus, con la aparicion de nuevas funcionalidades y su total disponibilidad me da la impresion de ser un entorno vivo.

Si quieres seguir con VFP un tiempo mas, aparte de usar lo anterior, hay que seguir tus recomendaciones de uso de bases de datos, separacion de capas, control de codigo, etc. Vamos, lo que lleva Fernando intentando evangelizarnos desde hace años y con razon.

Ahora reformulare la pregunta del millon: ¿hay en algun lado alguna informacion de las diferencias de lenguaje entre harbour y vfp9? Ya sabeis, comando similares, diferentes, nuevos, etc.

[Hugo C.]

En mi opinión si VFP aún nos da de comer, por que dejarlo ? , pero creo que tenemos que dedicar tiempo para aprender las nuevas tecnologías, por mi parte ya me siento algo cómodo con Angular (front end) y el Web Api  (back end) de MicroSoft  (c#, entity framework ...) pero no le quito el ojo a React y Node

Saludos

[FoxInCloud]

Hola,

Chen y FoxInCloud son parte de la comunidad de VFP y no hay ninguna razón por la cual el trabajo de esta comunidad sea menos válido que el de otras comunidades como xHarbor.

El hecho de que Microsoft haya dejado de desarrollar VFP no es un problema, siempre y cuando la comunidad continúe con el trabajo. No tener el código fuente de VFP es más una ventaja que un problema, ya que garantiza que VFP es perfectamente estable y una base sólida para el trabajo comunitario adicional.

En otras palabras, en cualquier situación, puede ver el vaso medio lleno o medio vacío. La única razón por la que debería ver uno u otro es su propio interés.

(traduit por Google Translate del inglés)

Hello,

Chen and FoxInCloud are part of the VFP community and there is no reason why the work from this community should be less valid than that from other communities like xHarbor.

The fact that Microsoft has stopped developing VFP is a non issue as long as the community continues the work. Not having the VFP source code is more an advantage than an issue as it guarantees VFP is perfectly stable and a rock solid base for additional community work.

In other words, in any situation you can see the glass half full or half empty. The only reason why you should see one or the other is your own interest.

[Gaetano Quattrocchi]

gracias chicos, usted es desde el premio Nobel con el fin de mantener viva nuestros Amado Fox

[Carton Jeston]

Por suerte, soy capaz de ver el vaso lleno y tambien medio vacio.

No estoy diciendo que los esfuerzos que se estan haciendo para prolongar la vida de fox no sea tan valido como la comunidad harbour, ya hace tiempo que apoyo a chen y otros compañeros que siguen creando herramientas como foxydb, foxypreviewer, foxbin2prg+plasticscm, foxincloud, etc.

Hay que tener en cuenta que todos son open source excepto VFPA y Foxincloud, que dependen de unas pocas personas para que siga funcionando.

El problema es que a pesar de ello seguimos perdiendo programadores de fox y siempre estamos esperando el dia del fin del mundo (casi aciertan los mayas con el fin de fox), buscando el sustituto que no llega, etc. Sigue la desconfianza porque una empresa privada gestione una herramienta  llegue el dia en que decida descontinuar su producto y nos deje tirados de nuevo.

En otras palabras, se trata de tener opciones y no vivir como si estuvieramos encerrados en un ascensor, tener control sobre el lenguaje base y a partir de ahi que crezcan librerias tanto open source como  privativas.

Y si me preguntas, aun sigo con foxpro y aplaudo la creacion de herramientas para el. Solo recomiendo explorar otras vias por si aun se puede tener un futuro para la programacion xbase con la maxima compatibilidad con foxpro.

[GETIANG]

Carton, muy buena la exposición, quedo como el café fuerte... cortico y claro, mas claro, imposible...! 

[Edgar Acevedo]

"Aventurarse a predecir el futuro es como manejar a alta velocidad por una autopista mirando a través de una pajilla" (Nassim Nicholas Taleb, genio matemático y economista actual, a quienes muchos proponen para premios de la talla del Nobel, pero se lo niegan por ser "políticamente incorrecto" y demostrar con números y estudios "verdades incómodas").

La gente que sigue con el modelo XBASE quieren vender su producto para muchos años más. NADIE en su sano juicio haría herramientas de programación XBASE sabiendo que solo podrá venderla por 3 o 4 años más.  Por ello TODOS ellos se están orientando en:

• Conexión nativa con bases de datos (MySQL, PostgreSQL, Firebird, etc).
  
• Facilidad para uso de ADO
  
• Acceso nativo a FTP, FTPS y HTTP.
  
• Herramientas para facilitar conexión, servicios y "cosas" Web (claro, dentro de lo humanamente posible).
  
• Mejora en sus IDE para creación de formularios, reportes y demás yerbas
  
• Compilar en 32 y 64 bits (a lo VFP Advanced)
• Poder correr en portables: tablets, celulares.

La gente que desarrolla nuevos productos XBASE: DBase, FiveTech Software, XAILER, Visual Flagship, Alaska Software, dudo que solo vendan un producto al mes. ¡ Ya habrían cerrado !  Van lento, es cierto, pero es porque quieren integrar lo arriba indicado y quieren parecerse a VFP pues entre líneas, se nota que lo reconocen como el modelo a imitar.  De hecho, en lo que a "extensiones" respecta, ya rebasaron a VFP pues tienen prestaciones que VFP no tiene.  Les falta madurar sus IDE, y su "amigabilidad" de interface, pero trabajan en ello.  Lento, pero lo siguen trabajando.

Por mas que programadores de otros lenguajes, insulten a XBASE, esas descalificaciones no le quitan las grandes facilidades que este tipo de programación otorga para manejo de datos, y más aún, datos desde motores ajenos. 

No se cual sea el futuro ni me quiero aventurar a predecirlo (como indica la cita inicial).  Pero hay gente desarrollando y vendiendo XBASE todavía.  Y lo hacen con miras al futuro:  64 bits, prestaciones Web, celulares, tablets y demás cosas que se vienen.

Quizás los foros de VFP se están adelgazando, pero los foros de XBASE me da la impresión que están aumentando.

¡ Saludos !

[Diego]

Completamente de acuerdo.

Diego

[Carlos Miguel FARIAS]

Si es así como dices, porque ningún producto xBase figura entre los lenguajes más mentados.

En el índice TIOBE no aparece ningún lenguaje xBase entre los 50 primeros (bueno, tampoco vi a Windev, Lianja o Velneo).

En el ranking de spectrum.ieee.org (un poco más serio, y que categoriza además según uso) en 36 lenguajes para la empresa, tampoco figura ninguno.

Eso está dando una pauta de que, sin discutir las virtudes de los xbase, no son tenidos en cuenta a nivel mundial.

Saludos: Miguel

[Carton Jeston]

Si yo fuese capaz de adivinar el futuro, apostaria todo a la loteria y no haria cabalas sobre xbase :-)

Yo hago calculos estimados, como quien tira una piedra y calculando su trayectoria, mas o menos puede ver donde va a caer. Y siempre que no ocurra algun evento totalmente inesperado pero eso no es videncia... :-)

La gente que menciona, no creo que gane por ventas sino por el soporte/pago anual de licencias, que cuanto mas adelgace la poblacion de desarrolladores de xbase, mas insostenible sera economicamente hablando. 

Empezando porque siempre me ha parecido xbase lo mas comodo para programacion de bases de datos desde los 80, mi critica constructiva parte de que se puede hacer para que VFP siga vivo, si tendiendo un puente hacia harbour puede existir una via de ampliacion o migracion llevandonos modos de trabajos de fox, usarlo para ampliar al propio fox o viceversa, etc.

Analizar esa posibilidad como beneficio del fox como un ejercicio de curiosidad es lo que se pretende, no añadir mayor confusion o adelgazar aun mas la comunidad fox :-)

[mapner]

Si pueden explicar que les gusta de VFP quizá puedan explicar que necesitan de cualquier alternativa de reemplazo de VFP 

Les gusta que :

es un lenguaje cómodo, de sintaxis clara y sencilla?  Python, Ruby (algo de PHP,...)

es un lenguaje que manipula datos? PL/SQL

tiene ventana interactiva de comandos para testeo y desarrollo? (???)

Lenguaje OOP ? Python, Ruby, PHP, Java, C#, ...

UI Componentes visuales ? (varias librerías de UI para escriotrio o web)

Generador de Reportes (Jasper o iReport o ...)

etc

etc

etc

[Carlos Miguel FARIAS]

Tienes razón mapner. El tema que los lenguajes que tienen el RAD (que algunos dicen que no va mas) interesante (C# con VS, Lazarus) tienen lenguajes duros, Por lo que vi, Windev tiene un RAD mejor que VFP pero no se que tal lenguaje. Velneo es una cosa distinta, es otro enfoque.

VFP además de un lenguaje interesante, tiene el RAD simple, y muchas herramientas de utilidad. Y está posiblemente en el límite de la practicidad. Hace años, intente trabajar con delphi (5). conocía bastante pascal, pero ya la interfaz y la forma de adicionar componentes era bastante compleja.

Es lo que llamo el límite del Word Perfect 6 (o 5), tenían tantos atajos de teclado que más que atajar, metía goles en contra, y de hecho, el Word, más simple y más visual lo desbancó del mercado.

VFP tiene esa particularidad, un RAD bastante completo, sin ser engorroso de manejar. VFP creo alcanzó en gran medida el límite de lo que un programador puede aprovechar bien.

Saludos: Miguel

[mapner]

Miguel, el IDE de VFP tiene varias cosas perfectibles, el project manager con sus curiosas solapas en vez de un solo árbol integrado, su editor de PRGs o fuentes de a uno por vez sin sistema de solapas múltiples, su almacenamiento de formularios, reportes y menús en pseudo-dbfs en vez de archivos de texto editables... en fin, el zorro es muy querido por los años que lo venimos usando pero convengamos que el entorno tiene múltiples puntos mejorables...

[arti...@gmail.com]

He estado realizando algunas cosillas con Visual Studio 2017 y el RAD es genial, en algunos aspectos incluso es mejor a la hora de trabajar con controles, ahora bien, otra cosa es el propio lenguaje, como VFP hasta ahora no he encontrado algo tan potente y simple a la vez para trabajar

[Carlos Miguel FARIAS]

Si mapner, es perfectible, fue diseñado hace más de 20 años, trayendo de arrastre el de Fox * DOS. El árbol es interesante, pero fíjate que no es un widget natural de fox. Los prgs separados, no es un problema, es una manera de no tener muchas hojas de código que tienes que paginar que muchas veces llevan a confusión (si manejas archivos de código fuentes muy grandes es imperioso tener posibilidad de ocultar segmentos.

A lo mejor sería interesante de que cuando te posicionas en una función, puedas abrir el fuente correspondiente. Que pueda decirte de que estas asignando a una variable algo que no es del tipo esperado (como cuando pones LOCAL variable AS INTEGER).

Todo es perfectible. Pero como comente, el IDE de Delphi para mi, con tantos elementos "te pierde".

Saludos: Miguel

[mapner]

Miguel, si te "pierde" el IDE de Delphi el día que tengas que trabajar con Eclipse te parecerá demasiado, pero a todo uno se acostumbra. En Java por ejemplo el paquete o "package" (una especie de work space)  ayuda a organizar los código fuentes en proyectos grandes, cosa que en VFP ese concepto no existe, con lo cual si el proyecto empieza a crecer para un mismo módulo EXE hay que nombrar los archivos (PRG, FORMS, etx...) con nombres con prefijos para diferenciar módulos.

El concepto de paquete o workspace ya está difundido en casi todas las plataformas/lenguajes modernos (o actualizados) o sea, las complejidades de desarrollo ya han sido encaradas en casi todos esos lenguajes y los que no se han actualizados quedan arcaicos (vale la obviedad). 

Hasta PHP que al principio era un pastiche de código spagetti hoy en día tiene todas las características de lenguaje "serio".

Y ese es uno de los grandes problemas de VFP y los xBase, al detenerse su desarrollo han quedado congelados en el tiempo.

A su vez, y leyendo los comentarios, queda claro que lo que más extrañamos de VFP cuando vamos a hacia otras plataformas es la potencia, expresividad y simplicidad del lenguaje xBase. La verdad es muy raro que esas características sean de segundo orden a la hora de promover nuevos lenguajes de desarrollo, en esto ha imperado estilos de lenguajes de nivel medio (ej. C# o Java) a los de alto nivel. Llaves de bloques, punto y coma de fin de instrucción y otros elementos sin utilidad aparente que dificultan en vez de facilitar.

Python y Ruby serían de las pocas excepciones que han tenido en cuenta facilitar el código y a la vez, no son los lenguajes más usados (están por debajo de Java).

Quién diseño el lenguaje dBase fue Wayne Rattlif quien intentó una forma de escribir comandos para manipulación de datos similares al lenguaje natural (inglés). Es extraño que ese precepto no se haya impuesto como condición prioritaria a la hora de elegir herramientas de desarrollo. Pero lamentablemente es así.

[Antonio Meza]

Mapner: Python y Ruby serían de las pocas excepciones que han tenido en cuenta facilitar el código y a la vez, no son los lenguajes más usados (están por debajo de Java).

Ruby y Python estan arriba de Java jajajajajajajaja

https://www.unocero.com/software/python-es-cada-vez-mas-popular-y-esta-incontenible/

saludos

Antonio Meza

[Carlos Miguel FARIAS]

Trabaje con Eclipse, con netbeans sobre PHP, y trabaje con Pascal con el editor del turbo pascal. Y el entorno de Delphi me resulta sobrecargado (ventanas y ventanas para cargar configuraciones) y es una opinión personal.

Trabajo ahora con Pycharm, y con python fenómeno (también use otros editores de python y todos me resultaron agradables).

En cuanto a lo que comentas del lenguaje xBase, sigue el concepto de COBOL, el lenguaje es verborrágico pero va documentando al vuelo. Y esa es una gran ventaja.

Los comandos son potentes, y lo que aprendiste a codificar de una manera, sigue operativo aún a pesar del tiempo, por más que sea un mamarracho ante las nuevas cosas agregadas.

Justamente cuando sugiero python (ruby es similar, el nuevo Julia o el nim, van por el mismo camino), es porque son lenguajes simples de escribir, poco código, los bloques se definen fácilmente, cuando un bloque cierra sabes donde empezó, o que cuernos está cerrando (imagínate un código en cualquier lenguaje que marca bloques con llaves, y en un punto te cierran varios bucles, varias condiciones, etc. a la vez) te encuentras con más llaves que en llavero de sereno. Hacerle mantenimiento es caótico.

Y para tener en cuenta, Python sigue subiendo en todos los rankings de lenguajes (en varios ya lo ponen a la cabeza), porque algo es evidente, cada vez es más notoria la necesidad de más programadores, y en un entorno de sistemas, lo más lento es el programador. Entonces si necesitas soluciones. tienes que entrenar más gente, y que esta te escriba soluciones más rápidamente.

Con el aumento de velocidad de las computadoras la diferencia entre interpretado y compilado va a dejar de ser perceptible.

Recuerdo que en los 80, dbase en PC IBM 8088 de 8 mhz necesitaba 1 minuto para ordenar mil registros, en Pascal había escrito un algoritmo de sort que ordenaba 2000 registros en 4".

Pero desde ese momento a ahora, las computadoras son un millón de veces más rápidas.

En 1992 en una PC 286, un proyecto me tardaba 20 minutos en compilar. hace 10 años atrás un proyecto 10 veces más grande compilaba en segundos.

Las cosas cambian.

Saludos: Miguel

[Carlos Miguel FARIAS]

Exacto Antonio. El otro día pase el link en que basa parte de ese gráfico.

Java script se usa mucho porque en los navegadores web casi no hay opciones.

Hay algunas herramientas que permiten escribir python y luego interpretar con javascript o compilar python a javascript pero al final estas usando js.

Saludos: Miguel

P.D. Vi el gráfico y  me dio ganas de comer pizza, ja ja no estoy gordito al pedo

[mapner]

Antonio, esos rankings son de dudoso origen y la prueba más fácil es ir a ComouTrabajo o página similar y ver los requerimientos de trabajo para uno y otro, otra alternativa es ir a GitHub y ver cantidad de proyectos en cada lenguaje. Dudo mucho pero mucho que Ruby sea más popular que Java en el mercado laboral.

[Carlos Miguel FARIAS]

El ranking que pase es el de spectrum.ieee.org, que ranquea según 4 tipo de aplicaciones (web, móvil, empresarial y hardware), En ese ranking está en varias categorías, primero python (en trabajo está primero java), Ruby no esta muy arriba (menos que php). En la sumatoria de clasificaciones que hace esa organización, python queda primero.

Pero. Entiendo que seleccionar uno de los que está en los 10 primero lugares no es mala elección. Sobretodo si te aplicas a un nicho específico.

Por ejemplo, PHP para quien trabaja en ámbito Web es uno de los mejores candidatos. Quien tiene que trabajar con aplicaciones a bajo nivel, o de tiempo de respuesta crítico seleccionará C o C++ (hasta free pascal).

Fundamentalmente, uno debe seleccionar el lenguaje que mejor se adapte al ámbito donde va a realizar el trabajo.

Si entras en un banco (a trabajar en sistemas, se entiende) posiblemente tengas que elegir COBOL.

Vi una migración de COBOL a Java (con SERVOY!!), la cantidad de líneas de código era la misma, oh no!!!

Programé con COBOL +15 años y dBase más de 20, y el código Fox es unas 3 a 4 veces más corto que el de Cobol. Y téngase en cuenta que en COBOL accedía a datos con SQL.

En fin si quieren hacer un fork, haganlo, cada cual atiende su juego.

Saludos: Miguel

[Carton Jeston]

He esperado unos días para ver vuestras ideas y sobre todo esperar que sea Viernes. Me he dado cuenta que todos estáis equivocados y solo tengo razón yo... lo que no tengo aun decidido en que tengo razón :-)

Viernes aparte, como siempre de todo lo que dicen se sacan ideas interesantes. Vamos allá...

Sobre los rad o con los entornos todo en uno no hay que menospreciarlos, diré que en el desarrollo de videojuegos indie, tenemos dos muy conocidos como game maker studio y unity y aunque puedes usar herramientas externas, la mayor parte de cosas lo haces en el mismo entorno. Su éxito es la comodidad y la productividad que se traduce en proyectos terminados mucho mas rápido.

Como lenguajes cómodos python, purebasic y algún que otro dialecto de basic y poco mas. Y habrá que ver lo que que dura el Visual Basic cuando a MS se le crucen los cables... Ruby tiene su punto divertido pero no se cual sera su techo. La libreria QT es muy atractiva y el tema de los reportes no lo he estudiado aun, tampoco es que el foxpro me apasione mucho como lo hace. Lo que si veo es que en muchos sentidos fox se ha quedado estancado aunque sigue siendo bueno en muchas otros.

Respecto a Java, su éxito fue su aceptación en las universidades y la ascensión de phyton creo que va por el mismo camino. No importa que java sea mejor en muchas cosas, con los movimientos de Oracle, casi tiraría por C# (pasando de MS) o phyton como apuesta de futuro.

La pagina de spectrum tiene algo muy interesante, indica para que puedes desarrollar web. movil, desktop, etc. y nunca hay uno que haga todo lo que quieres. Si elijes web, seria recomendado un lenguaje que funcione en el lado del cliente y en el lado del servidor, como javascript, phyton, etc. Fuera de eso ves otros lenguajes como purebasic (rapido como C pero no esta orientado a objetos como c++) y spìderbasic, su version que genera para javascript. Xojo tambien trabaja en desktop y genera javascript.

Por otro lado harbour o lazarus dispone de todo el codigo fuente, creo que es algo vital para seguir adaptandose a los nuevos tiempos, aunque son multiplataformas, cojean un poco con internet.

Y cuando hablamos de internet, hablamos de tendencias y cambio de paradigma pero hay que estar atentos a los avances tecnologicos. Yo intento ir un poco mas lejos, cuando sacaron la tecnologia WAP para los telefonos y vi que en Japon sacaron lo que hoy estamos usando todos, me di cuenta que podia saltarme aquello. Ya comente hace tiempo que en el mundo de los videojuegos se esta buscando el juego en demanda y si se aplica a programas de escritorio, no deja de ser que tu cliente trabaja como en remoto con tu programa en tu servidor. Lo que quiero decir es que si los avances tecnologicos hacen que los lenguajes interpretados sean mas rapidos, se pueden abrir otras posibilidades que cambien las reglas del juego y se requiera velocidad de programas nativos.

Ahora vuelvo al zorro, para aplicaciones de escritorio con uso de bases de datos modernas, el soporte de chen, y algunas librerias de apoyo le queda mucha guerra que dar. En el tema web foxincloud puede ser una solucion, aunque no tengo claro como seria tener tu propio servidor con todos los clientes que desees.

El tema de fork, framework o como querais llamarlo a Harbour, es por ver cuando de ese trabajo se puede aprovechar para fox, si se puede modificar para adaptar la sintaxis, etc. Hay otra posibilidad que es usar fox como herramienta de programacion y de ahi generar o traducir a otros lenguajes como harbour, phyton, javascript, etc. y eso requiere de una libreria de funciones en el otro lado.... y una lista de requerimientos que asustan... hay que ser realista.

Por ejemplo, se puede programar en fox para escritorio y generar phyton para la web. Que facil es decirlo... Aqui vemos que podemos seguir usando el ide por un buen tiempo, se pueden usar aplicaciones externas para ese fin incluso hechas en fox, como Fernando con su foxbin2prg que genera archivos de texto para el control de codigo. El gran problema es que ide y lenguaje puede ser mejorado pero no evolucionado sino se crea algo nuevo.

Todo esto parece mas cosa de Viernes, solo estoy sintentizando lo que comentan y aportando algo mas.

En mi caso, seguire con fox para desktop con su compilador de C++ x64 pero abriendome a otras utilidades mas alla del entorno como hice con plastic, quizas un editor tipo visual code, editor de bases de datos como sqlstudio, etc. y alguna cosa mas que se me ocurra o incluso pueda desarrollar.

Harbour lo sigo de cerca, aunque me da la sensacion de saltar de una rama a otra y no de un arbol a otro, django+phyton es atractivo para tener ese plus de la web. Quizas mantenerme en fox y viendo como derivar hacia phyton con comandos de fox puede ser una solucion a largo plazo.

Con este ladrillo, creo que al final alguien me lo tirara a la cabeza ;-)

[Gaetano Quattrocchi]

Hace algún tiempo alguien estaba trabajando en Guineuide,
http://guineu.foxpert.com
Creo que es un gran proyecto, lástima que se haya detenido. con el código Fox generó el código c # directamente de fox ide, y también generó ejecutables para dispositivos móviles, y muchas extensiones de comandos. uno podría usar dicho sistema y mejorarlo entre otras cosas y de código abierto

[Gaetano Quattrocchi]

puede usar vfpa y agregar funciones para compilar en otros lenguajes como android, linux, usando el método guineuide. sería un buen partido ganador

[Carton Jeston]

Guineu es un gran proyecto que se descontinuo pero no tengo claro el motivo.

Por especular, quizas era demasiado grande para una sola persona y por mucha constancia que tenga su programador, es una tarea titanica que quema poco a poco.

Que genere en C# necesitas un programador muy bueno en fox y en C# con tiempo libre para continuarlo. Depender del runtime .net te hace tener que adaptar tu codigo a cada cambio que a MS le incorpore asi que el mantenimiento no tiene que ser sencillo.

La ventaja de un interprete desde C# u otro lenguaje frente a un codigo generado, es que es mas facil que no se cometan errores o que tengas que adaptar el codigo generado cada vez si hay alguna incidencia. Por contra, crear un runtime con todas las funciones y comandos de fox ya es una tarea inmensa de por si.

Y es por esto ultimo que propuse la "idea" del fork de Harbour, porque hay mucho trabajo hecho y por la similitud de ambos lenguajes. En la practica un proyecyo asi al 99.99% no se hara pero hay casos atipicos como el programador de harbour o purebasic, etc. que hay llevado el proyecto adelante, mas por el esfuerzo personal y constancia de una persona que por el apoyo de una comunidad.

Luego esta el factor tiempo, no solo de ese programador, sino lo que se alarga en el tiempo. Si un proyecto como el compilador VFP C++ ha estado desarrollando a lo largo de 10 años y teniendo en cuenta que no ha escrito la libreria del runtime sino generado en C con las llamadas a la libreria, te puedes imaginar el resto.

Incluso con un proyecto de generador orientado a harbour, hay que preguntarse los beneficios finales... android? web? que diferencias hay entre comandos y funciones del lenguaje y la forma de trabajar?

Por eso hay que hablar tanto y ser "pesimista", porque es mas triste empezar algo y abandonarlo al cabo de los años.

[Gaetano Quattrocchi]

Eres genial, siempre te sigo con interés. cumplidos como este.

[HernanCano]

Carton:

También quisiera hacer algo que dé continuidad a nuestros desarrollos.

Sabes que he apoyado un proyecto y lo he promovido por acá. 

Hace varios años también miré Harbour, pero lo descarté por que (1) el lenguaje es más Clipper que VFP, (2) se debe recompilar cada que se hace un cambio en el "core"(¿podemos llamarlo así?), y de hecho (3) que sólo sea programación "DOS". En su momento quise aportar "ampliando" una librería llamada quizá hbfoxpro.h, pero me desconsolé pues cuando la bajé ví que sólo tenía cuatro o cinco comandos (aunque en el foro se mencionan entre agregados y otros comentados alrededor de veinte).

Si bien no me gusta tener que compilar el core, si alguien me guía quisiera participar. Con el interés que tienes en este Harbour y los alicientes primarios (familia xbase), te cuento que participaré ---si alquien me guía.

>>> Por eso hay que hablar tanto y ser "pesimista", porque es mas triste empezar algo y abandonarlo al cabo de los años.

Si quieres iniciar, hagámoslo.

[Elettronica Sistem Pos S.r.l.]

Hola, ¿hay alguna manera de crear los tiempos de ejecución vfpa64 y vfpa32 actualizados?
la posibilidad con una herramienta que genera el tiempo de ejecución de VFPA32 y VFPA64 del entorno instalado en mi PC?
muchas gracias

Il giorno giovedì 30 agosto 2018 08:33:18 UTC+2, Carton Jeston ha scritto:

Como muchos sabéis, hay un lenguaje Xbase de código abierto compatible clipper 5.2 que lleva muchos años entre nosotros y esta muy maduro. Es multiplataforma, permitiendo desde xbase generar C y compilar con ming u otros compiladores. Su objetivo es estrictamente tener la máxima compatibilidad con clipper y a la vez añadirle nuevas posibilidades para expandirlo a otras bases de datos y otras características.

Llamativo es el caso de xHarbour un fork que nació con la idea de no buscar la compatibilidad sino que prima su ampliación y adaptar a los nuevos tiempos aunque perdiese la compatibilidad. Parece menos activo y no soporta tantas plataformas, aunque hay un editor ide-rad comercial llamado Visual xHarbour que tiene una pinta estupenda muy profesional.

Hablando en el otro tema con compañeros sobre el rad y su sustitución con otras herramientas como qtdesigner, veo que harbour ya tiene implementadas muchas de estas librerías. Yo hace años me pregunto si seria viable hacer un fork de harbour para foxpro, aunque no fuese 100% compatible pero que tuviese aquellas cosas que nos gustan de fox y sobre todo la sintaxis y la forma de programar idéntica. Teniendo en cuenta que muchos comandos de clipper y fox tienen muchas cosas en común, seria el paso mas lógico para tener un fox open source.

Si, hay que tener los pies en el suelo y es un trabajo enorme, solo quiero saber si alguien ha intentado alguna vez estudiar esa vía aunque solo sea por curiosear. Ojo, aqui estoy hablando de un caso hipotético, porque detraes de ellos hay una tarea inmensa. Esto solo es un ejercicio de ideas y un debate abierto para mentes constructivas ;-)

[Carlos Miguel FARIAS]

Amerita se habra un fork aparte

[Carton Jeston]

El lunes, 17 de septiembre de 2018, 1:02:30 (UTC+2), HernanCano escribió:

También quisiera hacer algo que dé continuidad a nuestros desarrollos.Sabes que he apoyado un proyecto y lo he promovido por acá.Hace varios años también miré Harbour, pero lo descarté por que (1) el lenguaje es más Clipper que VFP, (2) se debe recompilar cada que se hace un cambio en el "core"(¿podemos llamarlo así?), y de hecho (3) que sólo sea programación "DOS". En su momento quise aportar "ampliando" una librería llamada quizá hbfoxpro.h, pero me desconsolé pues cuando la bajé ví que sólo tenía cuatro o cinco comandos (aunque en el foro se mencionan entre agregados y otros comentados alrededor de veinte).Si bien no me gusta tener que compilar el core, si alguien me guía quisiera participar. Con el interés que tienes en este Harbour y los alicientes primarios (familia xbase), te cuento que participaré ---si alquien me guía.Si quieres iniciar, hagámoslo.

Hernan, una de las cosas que he aprendido en esta vida es no implicar a nadie en un proyecto que no tengo la certeza absoluta de que algun dia se terminara. Tu disposicion es encomiable y como bien dices ya has apoyado un proyecto que no esta claro su final y creo que ocurre lo mismo que con la libreria hbfoxpro, cuando se meten se ve una cosa y cuando no ves la luz al final del tunel, te das cuenta que es mas largo de lo que aparentaba. Y la vida es muy corta para perderla con cosas que posiblemente no llevan a ningun sitio.

Asi es, harbour es una evolucion natural de clipper 5, pero para quien conocio VFP aun con un nivel basico, o incluso clipper summer87 es un tanto extraño. Eso no quita mi curiosidad y al mismo tiempo me llena de dudas.

La ventaja es que es xbase, multiplataforma y open source, compila nativo 64 bits, es un lenguaje vivo, etc. pero no veo nada claro que solucione el tema de internet, aunque he visto utilidades y librerias en este sentido.En vfp excepto multiplataforma (que aparte de android tampoco me interesa demasiado, tal vez linux en servidor) y ser opensource, lo demas esta "cubierto".

Por lo que se deduce de lo que hemos discutido por aqui, la espada de damocles no sera tanto que un dia deje de funcionar VFP, sino la tendencia hacia la web. Ya tengo experiencia cuando llego windows 95, un dia a medio proyecto un cliente dijo que no lo queria en msdos y por suerte me meti en foxpro 2.6 aunque de un modo un tanto precipitado. Y ya hacia tiempo que me peleaba con visual objects, clipper 5 para windows, etc... y ahora veo un dejavu en todo esto.

Seguramente me he repetido un monton de veces diciendo lo mismo y llegado a este punto digo como lo veo. Ahi tengo un monton de enlaces a phyton+django+pypy, xojo, lazarus, C# ademas de harbour y otros como nim, julia, scriptcase y todo lo estoy valorando de pasada.

Ahora mismo mi prioridad esta en migrar mis aplicaciones a VFPA 64 y VFPA COMPILER 64, lo que implica cambiar algunas FLL de 32 bits que seran incompatibles, aprovechar para refactorizar y aplicar mejores practicas y pasarme a una base de datos como postgresql que sirva para tanto para entorno de escritorio como alojamiento en web. Con esto creo que tendria asegurado el desarrollo para escritorio windows durante unos largos años. Y luego esta el tema de seguir creando extensiones que alargan la vida y aumentan las fronteras, como foxbin2prg, foxydb, foxypreviewer, .etc. por mencionar algunos.

Harbour me parece interesante si cubre ademas de entorno escritorio, android pero si no hay una solucion de futuro para la web, quizas no sea lo suficiente interesante. Quizas aprender a usarlo como camino paralelo pero no para hacer un fork.

Ahi es donde entra typescript-angular o phyton-django, este ultimo con la sintaxis casi tan sencilla como xbase . Y tiene el aliciente de ser el lenguaje mas popular y puede ser una salida profesional para quien quiera trabajar en una compañia.

Y como curiosidad, en todos estos lenguajes que estoy mirando, siempre hay alguien que quiere crear un libreria de funciones o hacer una migracion de foxpro pero dudo que si MS no libera el codigo o los de visual devapp no le ponen pilas al reloj, nunca habra nada 100% fox. Y por mi experiencia, ni siquiera en versiones de un mismo producto no me he librado de tener que cambiar una parte o incluso crear una version desde cero aprovechando lo que podia.

No hay que pecar de exceso de ambicion, creo que hay que mirar de solucionar pequeños problemas, no esperar a tener lo mismo pero "foxerizar" parcialmente el lenguaje objetivo al modo de trabajo de fox o que las mejoras vayan en ambas direcciones. Lo primero siempre es ver equivalencias y despues diferencias para hacernos una idea y esa informacion siempre sera util porque te puede servir si decides aprenderlo aunque no hagas ninguna adaptacion.

¿Lo de compilar el core te refieres a compilar el propio harbour cuando haces cambios? Si te refieres al crear aplicaciones  ademas de compilar el exe tambien hay un runtime si no he leido mal. Lo cierto es que a estas alturas, la primera impresion resulta un tanto arida, es como volver a los 90, pero hoy en dia casi todos los lenguajes han perdido un poco lo "visual" a lo que nos habiamos acostumbrado.

El lunes, 17 de septiembre de 2018, 16:07:19 (UTC+2), Elettronica Sistem Pos S.r.l. escribió:
Hola, ¿hay alguna manera de crear los tiempos de ejecución vfpa64 y vfpa32 actualizados? la posibilidad con una herramienta que genera el tiempo de ejecución de VFPA32 y VFPA64 del entorno instalado en mi PC?

No entiendo bien la pregunta... cuando instalas VFPA tienes que tener instalado la ultima version VFP9 SP2 con sus parches y VFPA aplica las correcciones y se regenera runtime y librerias.

[Hernan Cano]

Hola, Carton:

>>> Quizás aprender a usarlo como camino paralelo pero no para hacer un fork.

Lo de "fork" en el sentido estricto de fork, estoy de acuerdo contigo: no sería bueno crear otro fork de Harbour, pero la idea es mirar qué se le puede hacer para que le sea útil a los foxeros; tal vez primero iniciemos como fork y a medida que se hagan desarrollos, pedir que hagan los pull al core....o esperar al final.. pero se debe iniciar para lo que dices más adelante: "...lo primero siempre es ver equivalencias y después diferencias para hacernos una idea...."

>>> dudo que si MS no libera el código o los de visual devapp no le ponen pilas al reloj, nunca habrá nada 100% fox...

Considero entender que hablas de algo comercial, pues los del cronómetro sacarán algo comercial, y doña M$ ... liberar código... falacia... no comento...

De hecho los que hacen llamar su producto "Visual FoxPro 10" ya tienen el desarrollo hecho. ¿Qué has notado en él?

>>> Y por mi experiencia, ni siquiera en versiones de un mismo producto no me he librado de tener que cambiar una parte o incluso crear una versión desde cero aprovechando lo que podía.

Correcto. Por eso quienes han querido hacer algo lo han expuesto aquí.... pero hacerlo a solas es extremadamente complicado.... y pedir ayuda no ha sido bien recibido... nos hemos excusado de no conocer el otro lenguaje en que esté basado....

>>> No hay que pecar de exceso de ambición, ...Lo primero siempre es ver equivalencias y después diferencias para hacernos una idea y esa información siempre sera útil porque te puede servir si decides aprenderlo aunque no hagas ninguna adaptación.

Precisamente. ¿Quién hace éso en lo que respecta a este hilo? ¿Acaso no deberías ser tú... que eres el que está interesado? ¿y pedir que otros nos "conectemos"?

>>> ¿Lo de compilar el core te refieres a compilar el propio Harbour cuando haces cambios?...

Sí, compilar el core de Harbour...

>>>  La ventaja es que es xbase, multiplataforma y open source, compila nativo 64 bits, es un lenguaje vivo, etc. pero no veo nada claro que solucione el tema de internet, aunque he visto utilidades y librerias en este sentido

Si consideras alcance web como primordial y te parece que Harbour no llega a web entonces no debiste proponer el tema. Si has visto librerías en ese sentido, debes analizarlas antes y si te parece que sí se ajustan a tu pensamiento, empezar con el susodicho fork al que yo me apunto.

¿Consideras Harbour "vivo"? La última versión estable data de julio del 2011 (dos mil once).

[Carton Jeston]

Vamos por partes, cuando he iniciado el hilo ¿Seria factible un fork de Harbour para VFP? ademas de ser una pregunta "sencilla", se puede ver a lo largo de los mensajes que indico que es una pregunta o en el mensaje inicial "Esto solo es un ejercicio de ideas y un debate abierto para mentes constructivas". No estoy pidiendo que nadie haga nada, simplemente si alguien ha contemplado esa posibilidad en algun momento y creo que el debate se ha ampliado en muchos aspectos, con usuarios que han tenido contacto con harbour u otros lenguajes y nada de lo que aqui se ha dicho tiene desperdicio, tanto de los que estan a favor como de los que piensan diferente.

Este hilo bien podria ser "el futuro de fox" solo que he querido apuntar en una direccion determinada y tener un debate mas pragmatico que no sea llorar aquello que perdimos y no supimos defender, como Boabdil con la Alhambra. No es mi intencion promover falsas esperanzas ni ofender a nadie con esto.

Y si, he mirado librerias de harbour y he instalado ultimamente casi una docena de utilidades de programacion y lenguajes para evaluar diferentes opciones. Harbour al igual que phyton, tiene una sintaxis sencilla y un enorme catalogo de herramientas y librerias que dificultan elegir lo mejor. Incluso cuando alguien ha mencionado algo interesante como miguel con el pycharm, pues lo he instalado para ver de que va.

Sobre Harbour, es cierto que la version 3.0 es de 2011, pero la version en desarrollo se le han añadido varias funciones hace apenas una semana. Un lenguaje vivo en el mundo real es cuando se siguen incorporando nuevos vocablos o terminos al lenguaje, del mismo modo un lenguaje informatico vivo es cuando se añaden nuevas funciones al core. Nada tiene que ver en esta definicion las personas que lo hablen o en nuestro caso, los programadores que lo sigan usando ;-)

En este sentido, cuando alguien se escuda diciendo que no domina un lenguaje como C para no ayudar no es ninguna excusa, no solo hay que conocerlo sino ser muy bueno por no hablar de "entender" como lo ha escrito el programador original. Luego esta la disyuntiva, si haces un fork por ejemplo de la version de 2011, todo lo que se haga despues ya no sera compatible con la original y saldras del ecosistema harbour. Pretender hacer algo compatible con vfp e incorporarlo al proyecto harbour original choca con la filosofia del propio proyecto, que es su compatibilidad total con clipper. De hecho en los ultimos años se han abierto un poco pero si te fijas los comandos nuevos empiezan con HB_ para no interferir con clipper original.

La otra opcion es como la libreria hbfoxlib, crear funciones fox con el lenguaje xbase de harbour, que aunque no se domine por lo menos ya es mas familiar que C para la mayoria. Por ejemplo:

* SEEK <eExpression> [<soft: SOFTSEEK>] [<last: LAST>] TAG <cTagName> IN <cTableAlias>
*function fox_Seek(_eExpr,_soft,_last,_cTableAlias,_cTagName)

Claro, uno no se ve escribiendo funciones tipo fox_seek() en vez de SEEK porque pierde la naturalidad de xbase pero se valen del #COMMAND para definir el SEEK y como lo convertira en fox_seek() al compilar. No se si existe un comando equivalente al #COMMAND en foxpro, pero era una de las caracteristicas que me encantaban de clipper, la expansion de comandos en formato "natural".

Bien, olvidamos #command de momento, porque eso esta muy bien para añadir comandos de fox que no existen en harbour pero en cuanto tocas un USE (por decir algo) que comparten el comando pero los parametros o el modo de trabajo es diferente en ambos lenguajes, es cuando se complica la cosa. Por tener una cierta coherencia, casi estas obligado a hacer funciones FOX_ por cada comando de harbour sean identicas o no, por simplificar la escritura directa o reescribir el contenido de una funcion si en algun momento cambian algo en harbour que lo afecte.

USE X   -> ambiente harbour

foxUSE X-> fox_use(xxx,xxxx,xxxx,xxxx,xxxx) esto ya estaria definido con #command y se puede usar dentro de harbour, que no dejaria de ser el USE de harbour con parametros extra o lo que difiera de fox.

Esto es a la hora de escribir directamente en harbour, si generas o exportas desde fox, simplemente añadiendo el prefijo fox a la  linea de cofigo foxpro ya funcionaria. Por contra, la ejecucion del programa seria mas lenta usando el lenguaje de harbour, pero si la diferencia es entre un latido o un parpadeo, al ritmo de aumento de velocidad de los pc no deberia ser un problema. La otra ventaja, es que no tocas el nucleo de harbour y sigues siendo compatible 100%.Todo esto es teoria, una exposicion de observaciones muy por encima, luego la realidad suele ser mas dura.

Pasando a otro asunto, el alcance web, es algo que me preocupa junto el paso a los 64 bits por ser los dos grandes problemas que nos encontraremos en el futuro los programadores de fox. Empiezo con los x64...

Llegara el dia en que las aplicaciones de 32bits no funcionaran en windows, posiblemente mas pronto de lo que imaginan. Eso es imposible diran algunos, hay demasiados programas en x32 en el mercado... bueno, asi murio el subsistema de 16 bits con la llegada de los x64, asimismo pienso que habran versiones WINDOWS 2030 ULTIMATE con retrocompatibilidad pero las versiones de windows home/estandar de muchos usuarios y clientes solo seran a x64, de hecho hoy muchas aplicaciones ya no tienen version x32. No importa que tu desarrolles a x32, pero tendra que funcionar a x64 en tu cliente o tu aplicacion morira como lo hizo de un dia para otro los programas de msdos.

Harbour ya trabaja en x64 y VFPA se esta adaptado a x64 junto con algunas librerias mas conocidas. Creo que mas inmediato que tiene que hacer cualquier programador de fox es adaptar su aplicacion a x64, ver si usa fll que no tiene codigo fuente y cambiarlas por otras. Yo lo veo asi y es lo que estoy haciendo actualmente.

Luego esta la cuestion web, algo que harbour y VFP estan en paños menores salvo algunas soluciones que todos conocemos. Si se hace lo de harbour,no se da solucion la web. Ahi el camino se hace cuesta arriba y no hay una solucion "sencilla" (aunque ninguna lo es).Aqui ya habria que meterse en un sistema de generacion puro y duro, por ejemplo, reescribir todas las funciones del runtime en phyton. Al final llegariamos a la conclusion como otros han hecho ya, directamente irse a aprender phyton con mucho menos tiempo.

Esto es lo que me hace dudar con harbour, como dije es como saltar a una linea paralela con esa ventaja que supone ser open source pero que no resuelve el cambio de paradigma. Eso me hace pensar, de seguir en VFP con x64 como base de escritorio de windows y si hay que generar a partir de fox como comentan los compañeros de foxgen, orientarnos hacia apache cordova o una plataforma similar para aplicaciones concretas. Eso da para mas lineas, pero ya me duelen los dedos :-)

Hernan, cuando mencionabas VisualFoxPro10 me imagino que te refieres al VFPA, porque hay muchos que se cuelgan esa medalla y ninguno se acerca. Lo que han conseguido hasta ahora es hacer 40 fix al vfp original y estan adaptando a x64 que no me parece poco. No han añadido ningun elemento nuevo al lenguaje pero creo que el objetivo inmediato es hacerlo estable y migrar a los 64 bits. El compilador VFP C++ se considera completo a dia de hoy, aplicando algun fix si se le detecta, asi que me imagino que los esfuerzos actuales van por VFPA.

El problema no es seguir con fox como desarrollador, en tu pc puedes poner el windows que quieras o virtualizar, sino que tu aplicacion corra en la plataforma del cliente, ya sea escritorio, movil o web. Es un problema de futuro y el mas preocupante hasta cierto punto. Depende del tipo de cliente y la actividad del mismo, las aplicaciones web no tienen cabida. Si eres desarrollador por cuenta propia es una cosa, si trabajas para una compañia tienes que abrirte a otras cosas.

Otra cosa que me gustaria ver con Chen es hasta que punto se puede modificar el ide internamente, a la hora de crear ciertas funciones sin tener que añadirlas estilo thor.

Bueno amigos, despues de este ladrillo del que espero no usen para lapidarme, no es mas que una humilde reflexion a modo de tormenta de ideas y que cada cual aproveche lo que pueda y aun mejor, que aporte sus propias ideas. Y vuelvo a decirlo, todo esto es teoria a base de unas observaciones, nunca me pongo a programar "en caliente" sin tenerlo todo bien pensando... y al final nunca es tan facil como lo imaginabas.

un saludo

[mapner]

Cartón, sin duda tienes virtudes pero el poder de síntesis no parece ser una de ellas... :))
Te comento, hace muchos (pero muchos) años en los que empezaba a reinar el Clipper como compilador de aplicaciones dBase (en MS-DOS) buscando resolver problemas de memoria y de perfomance me topé con una librería que manejaba comandos dBase en lenguaje C, esa librería era CodeBase y se distribuía comercialmente. En el cliente que atendía lo compraron y lo estuve estudiando un buen tiempo. De hecho fue la primera librería con un enfoque de pseudo OOP que ví y me abrió la mente para futuros desarrollos míos. Probablemente todavía se ofrezca en la web. Cómo ves, el tema de abordar comandos dBase en otros entornos viene del principio de los tiempos.
Saludos!

[Carlos Miguel FARIAS]

Me gustó el análisis de Carton. Pareció largo pero muy interesante para tener en cuenta, porque no se queda en podríamos, si no que plantea el probemos.

En cuanto el hacer un fork de Harbour mi planteo es:

a) Hay en el grupo suficiente cantidad de desarrolladores que sepan trabajar en C (o C++) como para encarar la tarea? Ojo, hay que manejar muy bien el tema de parseo de cadenas, que en C creo no es tan fácil como en Fox.

b) Si los hay, tienen tiempo disponible para encarar el trabajo? Ya se anunció que se corta el soporte a Windows 7. Esta por salir una nueva versión de Windows (10 fase dos u 11). Significa que el salto a 64 bits sin retorno es incipiente.

c) La tarea es ardua, tal como indica el amigo Carton (que ha tenido un buen Jeston para elaborar su análisis). Se debe discernir si lo que se haga es un ad on sobre Harbour (para mantener compatibilidad y aprovechar los avances que tenga ese desarrollo) o es un fork contundente y la bifurcación se adapta bien a VFP sin hacer modo Fox (como era el modo SQL en el Dbase IV). Y cada cual por su lado

d) Debe tenerse en cuenta además que se considera realmente deprecated de VFP. VFP siempre se caracterizó por mantener compatibilidad a versiones viejas, pero justamente veo que esa compatibilidad provoca que se usen cosas obsoletas que funcionan, pero implican mayor complejidad de programación, fuente de errores, etc. (tales como el APPEND BLANK y REPLACE, en lugar de INSERT de SQL; los comandos SEEK y FOUND, reemplazables con una función SEEK(), etc.).

e) Las tablas nativas en VFP y Harbour no son 100% compatibles, difieren en indices y tipos de campos (los tipos agregados por VFP 9 creo que no están disponibles, tampoco los datetime y difieren los memo). Es más habría que ver si vale la pena mantener compatibilidad con tablas dbf.

f) También hay que ver como se soluciona el tema de los componentes de la interfaz gráfica (desconozco si Harbour cuenta con todos los controles que VFP). VFP por otra parte ya está "viejito" en relación a lo que permiten otras interfaces como wxwidgets o qt.

g) Y es imprescindible que se dispongan de capacidades web.

h) Y como la hache, quedamos mudo ya que el esfuerzo debe concluir en menos de 3 años? 5? y no van a ver un peso (ni sol, ni dolar, ni nada, GRATAROLA).

Saludos: Miguel

Larga Vida y Prosperidad

Que la Fuerza los acompañe, larga vida, larga vida pero hasta Spock se murió

[Hernan Cano]

Colega Carton:

>>> ... cuando he iniciado el hilo ¿Seria factible un fork de Harbour para VFP? ademas de ser una pregunta "sencilla", 

>>> se puede ver a lo largo de los mensajes que indico que es una pregunta o en el mensaje inicial "Esto solo es un 

>>> ejercicio de ideas y un debate abierto para mentes constructivas"...

Varios colegas (si no muchos) han propuesto /consultado sobre diversas alternativas y tipos de alternativas a nuestro querido VFP.

Considero que --para los conocimientos que tenemos tú y yo-- no debemos preguntar, sino proponer (e iniciar) lo que pensemos; de hecho me doy cuenta que has hecho un análisis lo suficientemente completo para iniciar.

>>> Luego esta la disyuntiva, si haces un fork por ejemplo de la version de 2011, todo lo que se haga despues ya no 

>>> sera compatible con la original y saldras del ecosistema harbour. Pretender hacer algo compatible con vfp e 

>>> incorporarlo al proyecto harbour original choca con la filosofia del propio proyecto, que es su compatibilidad 

>>> total con clipper. De hecho en los ultimos años se han abierto un poco pero si te fijas los comandos nuevos 

>>> empiezan con HB_ para no interferir con clipper original.

>>> La otra ventaja, es que no tocas el nucleo de harbour y sigues siendo compatible 100%. Todo esto es teoria, una 

>>> exposicion de observaciones muy por encima, luego la realidad suele ser mas dura.

Espero aportar un granito de arena: considero que sí se puede "iniciar" un fork, a manera de "laboratorio", sólo con la intención de saber si podemos llegar a algo. Si concluimos que sí es posible, entonces iniciamos un proyecto real con la info del primero..... (no me bandereen con ".. ¡hacerlo dos veces????).. sólo propongo un simple estudio, un análisis, una prueba...

El proyecto de que se base el fork puede ser del 2011 de uno actual..... El admor (que es alquien que está interesado en el proyecto) será quien lo decida...

 

>> Harbour ya trabaja en x64...

Si el subsistema base sobre el que se desarrolla nuestra alternativa lo soporta, entonces nuestro proyecto será x64.

>>> Luego esta la cuestion web, algo que harbour y VFP estan en paños menores salvo algunas soluciones... 

>>> Si se hace lo de harbour, no se da solucion la web. Ahi el camino se hace cuesta arriba y no hay una 

>>> solucion "sencilla" (aunque ninguna lo es).

>>> Esto es lo que me hace dudar con harbour, como dije es como saltar a una linea paralela con esa ventaja que  

>>> supone ser open source pero que no resuelve el cambio de paradigma.

http://www.dbfree.org

He notado que en la mayoría de las soluciones web, el lenguaje base es HTML y tal vez PHP. Así que el "chip" es diferente, nuestra mente debe cambiar un poco, y tal vez con dbFree --o alguna otra solución-- ya hay algún camino logrado.

>>> #COMMAND 

>>> SEEK 

>>> fox_seek() 

>>> foxUSE

Entonces ésto es algo clave para saber si se "inicia" un proyecto de este tipo: encontraste la manera de compatibilizar las dos variantes (la de VFP y la de Harbour). En lo personal considero que ---con esta información--- sí se puede iniciar el proyecto.

>>> ...VisualFoxPro10...

Me refiero a Lianja.

[Carlos Miguel FARIAS]

Es incoherente el nombre dbFree, porque si db no es free ;-DDD

Propongo dbBeFree (debe ser libre!!!)

Yo estaba pensando en un convertidor fox a python.

La parte de datos es fácil, hay una interfaz muy práctica para bases de datos, que todas los conectores básicos de python a cualquier bd respetan, por lo que para migrar de una bd a otra solo hay que cambiar la cadena de conexión.

Desde python se puede leer sin problemas dbf (no así interacturar con índices), en todo caso usaría leer dbf para luego solo migrar

Lo más complejo de fox es equiparar la interfaz gráfica (métodos y propiedades) a las librerías gráficas que se usan en python.

Pregunta harbour como maneja la interfaz gráfica?

Saludos: Miguel

[Hernan Cano]

Carlos:

Que quede claro que yo no propuse (ni he visto que alguien más lo haya hecho) que el nombre de un desarrollo derivado de este hilo sea dbFree.

[Carlos Miguel FARIAS]

El nombre ya está en uso. Argentina está entre dbfree y mariadb, db todo. ;-D

[Antonio Meza]

Definitivamente se deben olvidar de los DBFs, creo que ese es el problema central, arrastrar algo que no vale la pena a estas alturas y desde otras alturas ya pasadas jajajaj.

Muchos intentos fallidos y todo por querer conectar con DBF, cuando hay infinidad de herramientas para migrar de DBF a un servidor de base de datos.

El común denominador en la programación es la base de datos, es decir si usas un servidor de base de datos puedes migrar a cualquier lenguaje con toda la tranquilidad del mundo o combinar, pero si la idea (que es de muchos) es seguir usando DBF pues ahí se van a quedar.

saludos

Antonio Meza

[Dsan]

Muy cierto Antonio.

Y fue uno de los principales problemas al momento de hacer el vfp8 y vfp9, se enfrascaron en hacer mejoras otras áreas de VFP9, la verdad que los que estuvieron dando seguimiento al desarrollo de vfp9, no eran personas capaces tal como Ken Levy, creo que fueron personas que deseaban el fracaso de vfp, y me enmarco en:

1. Olvidar los dbf, en pleno sigilo 21 manejar grandes cantidades de datos, no era viable seguir usándolos.

2. No creo que no se les haya pasado por la mente que vfp escalaria a otros motores,  que se conectaria a Oracle (recibe grandes bloques de registros, no enviar uno a uno) o Sql Server (Creceria). pensar en vender captar otros desarrolladores que menejan grandes cantidades de datos.

3. Que se conectaría de Forma Nativa a un Hosting, para manejo de datos desde una Applicación de escritorio tipo Java, he visto varias, tenemos soap, y luego 2 años despues desconinuado...plop...

Solo esas tres cosas, deja mucho que pensar, sin meter web form ya que eso le quitaria punto a .net.

En sintaxis, usar dbf es como tener una maldición.

Saludes

DSánchez

[Carton Jeston]

Buf, he estado liado revisando todo el material que tengo entre manos, pero antes voy a contestar... en lo que sospecho sera otro mega-ladrillo.... como dice mapner, para otra cosa no valdré, pero para sintetizar una idea tampoco valgo :-D

Mapner, Codebase lo descarte en su dia porque ya tenia clipper87 para todo y solo usaba el C para funciones extra que no tenia clipper. Por lo menos asi lo hacia en programacion empresarial.

Miguel, otra vez no se puede discutir contigo cuando expones todos los puntos tanto positivos como negativos y son realistas.

Hernan, si todos tuvieramos la mitad de tu energia, fox estaria #1. Solo que mi experiencia siempre me dice que antes de hacer algo lo mire bien porque siempre hay otro mas listo que lo ha hecho antes... como he podido comprobar  y comento despues.

Antonio/Dsanchez, aunque esta claro que una de las mejoras que tiene que hacer cualquier programador de fox para tener cierto futuro es dejar atras los dbf, para ciertas cosas son una bendicion, no una maldicion. Con buenas practicas se puede conseguir que funcionen decentemente y para cualquiera que se inicie o haga una aplicacion monopuesto, lo tiene bien integrado en fox. Antonio, creo que en foxydb tenias que haber creado una parte para dbf, en que la carpeta actuase como una base de datos y las tablas contenidas... como tablas, aplicando esas buenas practicas desde tu motor. El paso a otra base de datos "de verdad" solo seria cambiar que motor seleccionar. Creo que eso facilitaria las cosas para los que empiezan o como yo, que mas que tener separacion de capas las tengo de capa caida. Ahi queda el reto por inutil que te parezca. :-D

A lo que vamos, he estado viendo otras posibilidades, proyectos y herramientas, probando y pensando mucho.... pero mucho y siempre con el riesgo de equivocarme. Para empezar, me ha llamado la atencion algunos proyectos en curso:

https://github.com/mwisslead/foxpro2python   ejecutar codigo python desde fox

https://github.com/mwisslead/vfp2py  convierte codigo fox a phyton

https://github.com/DougHennig/ProjectExplorer  sustituye al project manager (puede ser la base de todo)

y en menor medida:

https://github.com/mattslay/DynamicForms  Formularios sin diseñador con un lenguaje simple con engine propio.

http://www.sweetpotatosoftware.com/blog/index.php/2005/07/25/visual-basic-to-visual-foxpro-conversion-utility/ transforma codigo VB6 a fox

Empezar este hilo ha sido para resolver algunas dudas y sobre todo para escuchar lo que tenian que decir (fuese agradable o no). Ahora mismo sin descartarlo del todo, me cuestiono mucho la conveniencia de saltar a Harbour, no digo aprenderlo pero si generar de fox a harbour.

Las ventajas, open source, similitud con fox y otras que hemos hablado no oculta mis dudas sobre el futuro web. Comparando fox con harbour, no dejan de ser dos trenes que corren por vias paralelas y no sabes cual de los dos ira mas lejos, pero sabes que si nada lo remedio, al final hay un rio y el puente esta roto. Para entendernos, es la misma sensacion cuando estamos en la cola de la caja del supermercado y dudas entre estar quieto en tu cola o cambiar a la otra caja sin saber cual terminara mas rapido. A mi me funciona casi siempre no moverme de la que estoy... :-D

Y si se trata de tender un puente, creo que phyton puede ser un destino mas inteligente, porque es un lenguaje asequible para los que venimos de fox y lo que aprendas no caera en saco roto, ya que es uno de los lenguajes mas usados y demandados y profesionalmente habras ampliado tus posibilidades profesionales.

Para llegar a esa conclusion, he tenido que pensar donde estamos con fox y sobre su final apocaliptico. Es dificil apostar como sera un evento futuro pero creo que se ha exagerado mucho, no en su final sino en que hemos estado demasiado tiempo pensando sobre esa idea como algo inevitable. Hasta que Microsoft no haga su windows online, quizas no tengamos que tirarnos por el susodicho puente, existiran las aplicaciones de escritorio y aqui fox es bastante fuerte pero necesita arreglos. Cambiar a otra plataforma de aplicaciones de escritorio (no se si mañana saldra una solucion) no evita que dentro de unos años el modelo web nos haga empezar de nuevo otra vez. Tengo esa terrible sensacion de que estamos subestimando el fox y todos los esfuerzos por seguir manteniendo a flote, chen con vfpa, foxincloud, el proyecto vfpx,e tc. y sin entrar en la negacion que no es buena nos hemos instalado en la negatividad mas depresiva.

Otro detalle que me esta obsesionado es el ide, en ciertos modos se ha vuelto viejuno pero los proyectos que estan sacando adelante para mejorar fox me hacen preguntarme que me he perdido para que estas personas "pierdan" su tiempo en un lenguaje muerto... porque quizas no esta tan muerto como creemos. Estoy en contacto con chen y otros "locos" del fox porque creo que combinando diferentes proyectos se puede hacer algo bueno con el ide original sin requerir hacer algo totalmente nuevo y posiblemente inviable por el tiempo. Por otro lado, el ide solo lo usamos los desarrolladores en nuestro trabajo, no importara si dentro de 20 años usemos maquinas virtuales para programar, siempre que el cliente tenga la aplicacion final en una plataforma actual, ya sea local, web o en un chip en la nuca.

(llegados a este punto, el poder de la sintesis brilla por su ausencia)

Mi opinion personal, hay un largo camino por delante y que cada uno decida que le conviene, algunos directamente se iran a otro lenguaje o plataforma, yo voy a optar por fox y empezar a aprende phyton a mi ritmo y ver como unir ambos, del mismo modo que en el pasado usaba clipper+C para hacer cualquier programa que me pidieran.

Mi hoja de ruta pasa por usar VFPA64 y hacer funcionar mis aplicaciones a 64bits, sustituyendo las FLL o cambiando las que pueda. Cambiar a Postgresql, pensando en compatibilizar con phyton y hosting, aunque no es definitivo.  Por cierto, faltaria algun experto que añada la informacion necesaria para que foxydb la maneje. (antonio para que digas que no hago publicidad)

Al mismo tiempo y siempre sobre x64, me interesa ver como expandir el ide. Lo mas llamativo para mi ha sido el Project Explorer, una mejora sustancial con muchas opciones que he demandaban por aqui. Detras de ella esta el incombustible Doug Hennig y despues de probarla le he enviado algunos cambios para mejorar su usabilidad sobre todo cuando quieres que ocupe menos espacio y el orden de los botones...

La ventaja que tiene esto asi de entrada, es que puedes tener el control de codigo con foxbin2prg y generarlo automaticamente despues de editar un formulario por decir algo. Desde el proyecto se controla todo y le he enviado a Doug algunas sugerencias, de modo que puedas elegir en tu proyecto el editor interno o uno externo como una app o un exe. Por ejemplo, si uso un editor de tablas, el interno usaria el de fox por defecto, pero el externo podria ser una version mejorada o un editor de otra base de datos. Lo mismo con el editor de reportes, formularios, codigo, etc. Bueno las sugerencias estan para decirlas y el otro hacer lo que considere oportuno.

Respecto al conversor a phyton, no hay mucho que decir, es con mucho el camino mas largo y aun no he tenido respuesta del autor del proyecto. La idea no seria de un conversor de fox a phyton, sino un generador desde fox. De no ser asi, es mas rentable aprender phyton+django directamente y reescribir nuestra aplicacion en tiempo y esfuerzo.

El conversor funcional de visualbasic6 a vfp es antiguo, pero es curioso de ver como lo hace. Su autor lo usaba para hacer una conversion "sucia", quizas sirva para hacer lo mismo de fox a phyton, especialmente util para pasar la capa de negocios a la web. Hernan, si puedes echale un ojo a ver que opinas.

Y finalmente Dynamic Forms, una suerte de generador de formularios por codigo muy sencillo, parecido a generar un formulario tipo html y lo mejor, un render engine que lo muestra y te permite trabajar con el. Esto permitiria sustituir el DO FORM y el editor de formularios y facilitaria la generacion a phyton o incluso usar otras librerias graficas como QT. No por ello deja de ser conveniente un editor adaptado a esta libreria para facilitar el diseño siguiendo su filosofia.

Bueno amigos, aqui acaba el ladrillo de esta semana.... ahora dejare que lo digieran y que cada uno exprese su opinion. Mientras espero a ver si se algo mas de los autores de estos proyectos.

Nos vemos

[Carton Jeston]

Dynamic Forms no sustituye a do forms como puse, es mas bien un sistema de posicionamiento y creacion de forms por codigos como un compañero que decia tener algo parecido y no usaba el diseñador para nada. En este caso, le veo ciertas ventajas al hacerlo por codigo, pero creo que un "asistente" mas adelante le daria ventaja. Empiezo a entender las ventajas que puede llegar a tener.

Mapner, y sobre project explorer, echale un ojo ya que tiene algunas caracteristicas que decias echar de menos en el foxpro original.

un saludo

[Antonio Meza]

"Antonio, creo que en foxydb tenias que haber creado una parte para dbf,"

Si lo hubiera hecho muchos seguirán con los DBF, y es el peor error!!! tener los datos en un servidor de base de datos, te permite fácilmente investigar y probar hacia que nuevo lenguaje quieres ir, pero si usas DBF te limitas.

saludos

Antonio Meza

[Carlos Miguel FARIAS]

Pero Antonio, porque ese rechazo a las DBF?, si es sabido que son Datos Bien Frágiles ;-D

[Jorge L. Florez C.]

Hola, pero si todos o casi todos los lenguajes se conectan a las BB/DD via ODBC, si foxydb tiene soporte ODBC pues también debería conectarse a un DBF, si quieres ir a un nuevo lenguaje el DBF no es la limitante.

Saludos

Jorge Florez

Lima - Perú

[Newbie]

Hola Jorge en este caso yo creo que si DBF tiende a ser limitante, por que si migras a otro lenguaje, pues al no usar lo nativo de ese lenguaje pierdes mucho valor, y deja de tener un poco de sentido el migrar, el mejor consejo creo que es siempre mirar hacia motores de especialidad., pero  repito es un consejo.!!

[Carton Jeston]

Antes de nada, daros la razon, seguir con DBF de cara al futuro es un error.... pero un error a medias. Hay proyectos mas sencillos que no necesitan una base de datos "de verdad" o incluso las tablas libres DBF se mueven con mas soltura a la hora de instalacion y del mantenimiento.Si se programa bien, suelen funcionar y cumplir con el objetivo.

Otra cosa es que quieras hacer algo mas serio, una base de datos potente, escalable e incluso programarla para que ciertas cosas las haga ella y no la aplicacion, eso es el futuro y lo recomendable cuando tienes claro que BD es la que vas a usar.

Guste o no, DBF esta en el adn de xbase... Al final decir que dbf o fox es una KK, es mas postureo que otra cosa :-D

El lunes, 1 de octubre de 2018, 16:33:41 (UTC+2), Antonio Meza escribió:

"Antonio, creo que en foxydb tenias que haber creado una parte para dbf,"

Si lo hubiera hecho muchos seguirán con los DBF, y es el peor error!!! tener los datos en un servidor de base de datos, te permite fácilmente investigar y probar hacia que nuevo lenguaje quieres ir, pero si usas DBF te limitas.

Amigo Antonio, de hecho muchos siguen con DBF y sin usar foxydb ¿porque? En muchos casos, nada que ver con zona de confort.

Primero tienen que adaptar su aplicacion para que trabaje con foxy y depende como este hecha... o contrahecha... ya puede tener su complicacion. Suma la instalacion y aprender el manejo de un BD no nativa y tienes un DBF FOREVER.

Esa idea original era por sacar partido a las "buenas practicas" con dbf desde tu libreria, ya evita el append+replace, bloqueos optimizados en red y todas las mejoras que se te ocurran. Es un reto, lo se, pero facilitaria el despliegue durante el desarrollo y facilitaria el acercamiento a los mas noveles.

Una vez que sepan usar dbf con foxydb, ya pueden elegir que BD elegir (y estudiar) y optimizar de cara al despliegue en produccion. Si ya se conforman con eso, pues es problema y riesgo de cada uno ;-)

No deja de ser la filosofia de separar un problema en partes mas pequeñas. Ojo, es mi opinion personal, del mismo modo que hago esa "critica" constructiva, no puedo dejar de agradecer tu esfuerzo por hacernos las cosas tan faciles.

PD: un JAJAJAJA al año no hace daño.

[Carton Jeston]

Michael Wisslead, el creador de fox2python (proyecto en curso) me ha respondido y me dice que empezo con un simple conversor y en los ultimos dos años ha incluido muchos comandos de fox en phyton (y le faltan otros tantos), que se ha convertido en un runtime mas funcional aunque con un analisis sintactico un tanto lento. Lo han estado usando para migrar aplicaciones poco a poco mientran mantienen las actuales en fox.

Mi idea es otra, no es tanto migrar aplicaciones enteras sino trabajar en fox y tender puentes hacia phyton del mismo modo que en clipper usabas C para ampliarlo.

Yo aqui soy uno mas, veo a harbour como un camino para seguir en xbase pero con el handicap de la web. Por otro lado tenemos phyton, es sencillo pero es otra historia y quizas unir fox a un lenguaje de los mas usados actualmente sea lo mas inteligente... pero tampoco se puede poner la mano en el fuego por nada con tanta tendencia cambiante, asi que vuestras opiniones son valiosas, discrepantes o no.

[FoxInCloud]

On Saturday, September 29, 2018 at 9:43:22 PM UTC+2, Carton Jeston wrote:

 

Tengo esa terrible sensacion de que estamos subestimando el fox y todos los esfuerzos por seguir manteniendo a flote, chen con vfpa, foxincloud, el proyecto vfpx,e tc. y sin entrar en la negacion que no es buena nos hemos instalado en la negatividad mas depresiva.

He estado defendiendo esto desde 2007 ... Estratégicamente, la guerra entre lenguajes de programación, sistemas operativos y bases de datos ha terminado desde finales de los 90.

Cualquier lenguaje, siempre que sea gráfico y esté orientado a objetos, hace aproximadamente las mismas cosas y proporciona un resultado final muy similar para el usuario. No hay nada que pueda hacer con JavaScript que no pueda hacer aproximadamente lo mismo con VFP; La principal diferencia es que escribo las funciones una tras otra ('string' .trim (). Substr (...)) en lugar de anidarlas (substr (trim ('string'))). Por supuesto, es más legible, pero el resultado final es exactamente el mismo, incluido el rendimiento.

En lo que respecta a la Web, VFP tiene las mismas habilidades que los otros idiomas; la única limitación es que necesita un conector dll externo para el servidor web, mientras que otros idiomas lo proporcionan fuera de la caja (por ejemplo, php.dll). Además, puede hacer exactamente lo que necesita, muy eficiente y estable, y puede considerarlo aún más poderoso con la simplicidad de los DBF que, detrás de una aplicación web, son perfectamente estables y seguros.

Así que la verdadera pregunta es "¿vale la pena migrar?" La migración significa reescribir 20 años de código, sin ninguna posibilidad de escribirlo más rápido que el primer disparo en VFP. Solo reescriba para reescribir, mientras realiza el trabajo de mantenimiento actual, y al final no tiene nada más que vender a nuestros usuarios y clientes.

Siempre y cuando estemos seguros (como Microsoft ha anunciado) que Windows ya no cambiará tan profundamente que rompería las aplicaciones basadas en el tiempo de ejecución de C ++ (y hay muchas, incluidas las aplicaciones de Microsoft como Visual Studio e IIS), ¿por qué debería poner ¿Su negocio en riesgo sin ningún beneficio?

"VFP ya no es compatible" significa de hecho "Microsoft ya no desarrolla VFP". En realidad, VFP solo se basa en el tiempo de ejecución de C ++ y en la API de Win 32 que aún son compatibles, si no oficialmente, al menos en la práctica. Y la verdad es que VFP AÚN ESTÁ DESARROLLADO POR TERCEROS COMO VFPx, Baiyujia, West Wind, FoxInCloud, etc.

Es solo una cuestión de ver la realidad de manera diferente de lo que Microsoft y otras grandes compañías nos dicen que veamos. Ver el vaso medio lleno en lugar de medio vacío. 

[GeoSys Diseño de Software]

Yo no me confiaría mucho, yo a VFP lo utilizo solo para dar mantenimiento a aplicaciones en producción la idea es ir migrando ordenadamente, 

[Carton Jeston]

Si es un vaso de whisky, se puede ver medio lleno o medio vacio depende de lo borracho que vayas... incluso se puede ver doble!!! :-D

Mi esperanza para el futuro en programacion para escritorio son los avances con tecnologia en stream, segun como se plantee, puede cambiar las cosas...

https://www.polygon.com/2018/10/1/17924554/google-game-streaming-test-assassins-creed-odyssey

Sobre el Api32, ahi tengo toda mi desconfianza. Se que es muy dificil descontinuar aplicaciones 32bits, pero cuando ves que todas tus herramientas son x64 y muchas de ellas no existe x32, lo mismo con los juegos, cuando la mayoria de sistemas operativos instalados son x64. Yo preveo que windows seguira sacando versiones x32 y x64, esta ultima ejecuta x32 actualmente, pero temo que en algun momento en determinadas versiones solo sera compatible con x64 y apuesto que sera lo que acabaran teniendo la mayoria de clientes. Quizas pase 1 mes o 10 años, eso es algo que no sabemos pero que hay muchas posibilidades de que pase.

No es nuevo que cuando dejamos windows98se, muchos programas y juegos dejaron de funcionar y se ha repetido hasta nuestros dias, viendo como desaparecian los subsistemas de msdos, soporte 16bits, etc. No hay nada que indique que vaya a ocurrir, pero tampoco hay nada que me asegure de que no va a pasar... el vaso medio lleno o medio vacio... o como se suele decir, pillarte con los pantalones bajados.

Y esa es mi mayor preocupacion actual, mas que funcione o no en web, porque la tecnologia sigue avanzando y los escenarios pueden cambiar... ¿un servidor de aplicaciones por stream en vez de aplicaciones web?... realmente no se esta inventando nada, lo que hoy es la nube, no deja de ser un servidor ftp tuneado.

Este hilo ya empieza a parecerse al otro de "el futuro de foxpro"...

Sobre reescribir 20 años de codigo, te doy la razon que actualizar todo eso al mismo tiempo que haces tu trabajo de mantenimiento normal es muy complicado... Yo llevo mas de 10 años asi!!!. Pero tambien me preocupan los 20 años que tienen que venir.

Y yo no hablo de migrar y abandonar fox, sino extender el horizonte hacia una direccion concreta. Cuando hablaba de fork de Harbour, era para ver si existe la posibilidad de tener un fox libre. Al tener la limitacion web, he seguido mirando y oyendo lo que comentan otros compañeros y veo el proyecto de fox2phyton, asi que es casi seguro que empezare a aprender phyton como "complemento" a fox pero no como "sustituto". Es como si hablo español pero veo que cada vez hay mas turistas en mi zona y decido hablar ingles. Seguro que usando ambos tendre mas oportunidades...

Y si es cierto que con todos los lenguajes hacen lo mismo, te invito a que subas a un Tesla Fox o un Fiat Panda, ambos te llevan al sitio pero la comodidad y la rapidez no es la misma :-D

Lo que elijamos, fork de harbour, exportacion/extensor a phyton, etc. son proyectos para muy muy largo plazo, asi que recomiendo usar lo que tenemos y actualizarnos todo lo que podamos. El que piense quedarse con fox y no migrar, que se mire como pasar su aplicacion y todas sus librerias a x64... pero que no se quede ahi!!!... es solo mi opinion personal. No animo a que dejen fox y migren a otra cosa, somos pocos para encima espantarlos... hay que usar lo que tenemos actualmente, aprovechar las herramientas y proyectos que se estan haciendo y ver como llegar a web, moviles, etc.

En definitiva, crecer desde fox y no matar al zorro en el proceso. ;-)

PD Mi poder de sintesis sigue en paradero desconocido y el de la oratoria no es tal, mas bien es verborrea :-D

[Carlos Miguel FARIAS]

Coincido con GeoSys, de hecho estoy en el mismo camino. El tema pasa porque hay dos elementos a tener en cuenta, el entorno de desarrollo y el runtime. Además todos aquellos componentes que usa vfp para conectarse principalmente a bases de datos, y en segundo lugar a dispositivos que tenga que acceder mediantes drivers.

Posiblemente se pueda seguir usando el entorno por un tiempo, pero recuerdo que el IDE de Fox no funciona en un windows que no sea de la familia NT (no en Millenium ni W98 o anteriores), son S.O. de solo 18 años atrás. Gracias a que Microsoft la embarró con Windows Vista, el XP funciono mucho más allá de lo esperado. M$ para evitar el zafarrancho del Vista, saco W7 muy compatible con lo anterior (XP).

Pero para no perder la línea, la embarro con W8, enderezó con W9 (si W8.1; 8 + 1 = 9).

Manteniendo una máquina que aguante W10 se podrá seguir compilando VFP.

Mientras, los dispositivos fueron evolucionando y los drivers se fueron pasando de 32 bits a 64 bits y cada vez menos dispositivos fuera del alcance de VFP. Pero que pasará cuando no saque S.O. para 32 bits. Estimo que para 2025 posiblemente no haya más S.O. microsoft para 32 bits (compatibilidad descendente) (Bah, pienso ya estar jubilado, porque los aportes me van a alcanzar).

Que pasa con el runtime? Si lo que hace Chen no lo reemplaza íntegramente, no se le puede decir al cliente, comprese una maquina que aguante W10 32 bits porque si no mi soft no anda. Y el cliente te manda con Rodrigo de Triana.

Que pasa si tienes que conectarte a algo esencial para lo que no hay driver de 32 bits?

Y sumale lo de Carton

Saludos: Miguel

[Carton Jeston]

Disculpar las "vacaciones", he estado documentando sobre harbour-vfp (y no he terminado) y el tiempo vuela y no te da cuenta. Por suerte, mi disco duro donde trabajo y programa ha muerto a los pocos meses de vida (tengo copias generales de hace un mes y casi diaria de lo mas importante)... ahora estoy pasando a otro y tengo tiempo de contestar. Hay que ser positivo.... :-)

Independientemente de que se haga fork, framework, libreria o lo que sea de VFP-HARBOUR o incluso nada, por lo menos estudiare a fondo el tema. Porque la otra opcion y mas probable es seguir con VFPA y aprender harbour para extender las posibilidades de fox, crear servicios, etc. Estoy pensando por ejemplo en ese plugin para apache que permite escribir en xbase-harbour como si se tratase de PHP.

Miguel, creo que lo has preguntado varias veces y no has leido mis respuestas ... :-)

VFPA64 funciona a 64bits, ide y runtime ha sido "adaptado" para funcionar en x64, asi como algunas librerias como foxtools y las mas populares. Necesita del fox original para instalarse, aunque si guardas una copia de la carpeta del fox9 y la pones en archivo de programas, lo hara igual. Esto lo digo por si un dia tu fox original no dejara instalarse.

Y eso si hablamos del entorno ide que solo lo usamos los programadores, como bien dices siempre con un vfo9 y con un win10 o incluso virtualizando puedes usarlo "para siempre". El problema es el runtime funcionando en el cliente, ahi es donde entra el compilador (de pago creo que ahora esta en 500$ y yo pago 50$ de soporte/actualizacion anual ) que convierte a Visual Studio C++, no solo proteje sino que actualmente es compatible con VS2017.

Seguiremos informando....

[Carton Jeston]

Se me olvido aunque ya lo he dicho en repetidas ocasiones...

El problema no es solo que vfp9 funciona en 32 y te pases a VFPA64, eso es facil. Lo que hay que vigilar son la dependencias de tu aplicacion en librerias externas FLL, OCX y similares de los que no tengas el codigo fuente ni version 64 bits. Si ademas quieres usar el VFP C++ Compiler, hay algunas restricciones como el uso de store que yo hace tiempo ya adelante en su version 32.

En en eso donde estoy echando el tiempo libre, sustituyendo esas librerias que en algunos casos solo uso una funcion determinada. Esa creo que deberia ser la prioridad, convertir tus aplicaciones para que soporten x64, porque lleva su tiempo pero no tanto como para migrar a otro lenguaje o desarrollar una alternativa que no sabes si llegara.

Eso solo es mi opinion, la de mas vale pajaro en mano que ciento volando :-)

[Ramon-México]

Finalmente, no hay consenso ni acuerdo. Según se ve, cada quién deberá rascarse con sus uñas, nada de trabajo colaborativo o en conjunto, ni hablar, aun así como profesionales estoy seguro que cada quien encontrará el lenguaje que cumpla sus expectativas para lo que desarrolla y de acuerdo a sus capacidades. 

La mezquindad de muchos comentarios en este grupo veo que restan en lugar de sumar.

Buena suerte.

[Carton Jeston]

Cuando se abre un debate no es para llegar a un consenso ni acuerdo, es simplemente para que cada uno opine o aporte lo que pueda.

Hay que tener en cuenta que un proyecto suele salir adelante por la constancia de una sola persona y a veces, es secundada por otros, aunque casi siempre acaba solo sujetando la bandera.

Pero cuando es un proyecto faraonico, ni siquiera un grupo pequeño de personas puede llevarlo a cabo. Las personas tienen vida mas alla de la programacion, tienen trabajo y poco tiempo. Tampoco se les puede echar nada en cara. Al final siempre se sacan ideas u orientacion de todas las respuestas.

un saludo

[HernanCano]

[Victor Espina]

Asi mismo es. Ademas, como alguien comento mas arriba, aca estamos hablando de programacion C/C++... cuantos de los que estan aqui tienen un dominio suficiente de esos lenguajes como para poder participar productivamente en un proyecto asi??   Hay que ser realistas tambien.  Mi opinion es que en lugar de estar gastando tiempo y esfuerzo en resistirse al cambio, es mas productivo aceptar la realidad y empezar a aprender otras tecnologias mas actuales y demandadas.

Saludos

Victor Espina

[mapner]

Concuerdo con Victor,

Meter mano en un compilador escrito en C/C++ no es un cuestión para nada fácil. Requiere mucho conocimiento en la materia.

y si, realmente es una pena que un lenguaje tan versatil como XBase se desestime, pero hace rato que existen tecnologías que permiten desarrollan en otras plataformas, y simplemente hay que dar el paso para el cambio.

Y de hecho lo que hoy es casi obligatorio estudiar es JavaScript y su entorno como lenguaje de frontend, y varias de las alternativas de backend (incluido el mismo JS), con lo cual por ahí va la cosa a la hora de invertir energía de estudio.

[Victor Espina]

Concuerdo completamente.  La mejor inversion en este momento es aprender tecnologias web, bien sea con Javascript o con Java normal.

Victor Espina