Barrapunto

python por ejemplo.

En algunos casos, no hay más remedio que alternotivas complatibles, pero en este creo que no.

...puede estar bien para añadir soporte de ASP en Apache, lo cual ayudaria mucho de cara a migrar desde IIS.
Dado que no tiene nada que ver con el toolkit gráfico utilizado, tambien estaria bien que se pueda utilizar desde KDE.

Aunque, como ya ha dicho Drizzt, Python es mejor para extender las aplicaciones de GNOME

Si, python es mejor en teoria. Pero si hay que lograr compatibilidad con M$ en las dos direcciones es mas practico desarrollar un Gbasic, aunque inicialmente parezca una aberracion. Si no ya me contareis como vas a exportar una hoja de Gnumeric con codigo phyton en formato Excel. Desgraciadamente, para atraer a gente del mundo de M$ hacia linux - punto importante para hacer triunfar a la comunidad opensource- hay que hacer concesiones de este tipo.

...que es cierto que Basic no es ni de lejos un buen lenguaje, pero que si queríamos que la mayoría de programadores Windows portaran sus aplicaciones a Linux, ésta era la única forma de conseguirlo.

No se trata de una extensión de Gnome ortodoxa, sino más bien de ponérselo fácil a los más reacios, que no son pocos, a juzgar por el montón de gente que programa en Visual Basic. Es poner un azucarillo al lado de Linux.

Si quieres los programadores portar aplicaciones, que se porten bien hechas y con cosas coherentes.

Siempre se puede crear un RAD adecuado y con un lenguaje correcto. No creo que convenga en absoluto las tan criticadas aplicaciones realizadas completamente un Visual Basic. Si se queire portar aplicaciones, se presupone un minimo interés por la plataforma a la que se porta y un mínimo interés por aprender sus ventajas.

Por esa regla de tres, arreglamos Wine definitivamente y tenemos todo el problema de porting resuelto. Se programa para Win32 y luego con Win32, se corren / recompilan aplicaciones y asunto concluido.

Si no ya me contareis como vas a exportar una hoja de Gnumeric con codigo phyton en formato Excel.

En principio, las versiones modernas de Windows pueden aceptar cualquier lenguaje de script que esté integrado en Windows Scripting Host. Me parece.

Sería cuestión de llevar el Python a este sistema de Windows (¿Se ha hecho ya con Perl?)

El tema de este artículo es Microsoft. Pero el Basic existió antes de Microsoft.

No lo he probado, pero puede que apache::perl::asp sea una buena solución, a priori tiene buena pinta pero se tendría que comprobar el redimiento.

Ya se ha hecho. Hace poco he terminado de leerme el libro de Mark Hammond (el responsable del port de python a windows) y en el se describe como utilizarlo. Aunque dudo que se pueda usar WSH desde Excel...
Lo que si se puede hacer es controlar Excel (y el resto de aplicaciones de Office) desde python mediante COM
Lo que seria interesante es simplemente exportar, en lugar de todo el código, los métodos y los parámetros que utilizas, y que cada lenguaje lo adaptase a su sintaxis. Como eso no existe por el momento (tal vez con .NET), de momento, al exportar, una sencilla función puede traducirlo a VBscript. Claro que no todas las features de la sintaxis de python ("rebanado de secuencias", etc.) son fácilmente traducibles a VBscript

Yo tampoco lo he probado, pero ¿soporta VBscript, o solo Perl? porque yo me referia a usar el soporte de Gnome Basic desde este módulo

También se extinguió fuera de Microsoft.
De hecho, que yo recuerde, Basic utilizaba numeros de línea, y no funciones (subrutinas) con nombre...
Microsoft ha trasteado tanto con este lenguaje (embrace and extend) que ya no puede decirse que sea el mismo...

Precisamente para casos como este es importante tener una arquitectura de componentes con APIs bien claras y usuables desde varios lenguajes. Y por ejemplo en GNOME a través de CORBA se van a poder atacar a los contenedores, controles y empotrables desde cualquier lenguaje soportado por CORBA, además de Perl y Python que ya disponen de enlaces con ORBit.

...de una empresa que desarrolla para Windows y tenga todo su software importante en Visual Basic (mala idea, a mi parecer). Si un buen día se les ocurriese dar el salto a linux, necesitarían esto para llevarlo a cabo, ya que seguramente el coste de reescribir todo de nuevo sería inabordable.

Para ellos, esta iniciativa es la diferencia entre poder o no poder entrar en Linux. Si el objetivo es que se use software libre de forma generalizada, habrá que tender puentes a los que todavía están fuera. No nos cerremos a cal y canto.

Desde sus comienzos, Linux es la mejor plataforma de desarrollo, con una inmensa cantidad de lenguajes disponibles. ¿Por qué íbamos a decir que no al más usado de todos, (mal que nos pese)?

Bueno pues... cada vez me acojona mas ver a Icaza acercarse a Windows en todos los aspectos y sin razón aparente... lo de la compatiblidad, como dice Drizzt, me parece una pobre excusa. Volvemos a la misma polémica que cuando a Icaza le dió por realzar las virtudes de OLE y decantarse por un sistema similar a este frente a otras alternativas.

Sigo pensando que la dirección que se han marcado los chicos de KDE es mejor en casi todos los aspectos.

Y si, yo tb. opino que phyton hubiera sido una mejor alternativa que BASIC.

La idea era darle un lenguaje de scripting a gnumeric, para poder importar tb las macros de los ficheros excel, y toda esa morralla. Al principio, se había sugerido hacer un conversor de basic a python, pero entonces seguimos teniendo el problema de la exportación...

que problema hay que gnumeric acepte basic y aconsecuencia de esto todo ese monton de hojas excel que andan por ahi?
el soporte total al endiablado office es obligatorio si queremos mas maquinas trabajando con linux.
tambien podria a su vez aceptar gnumeric python como lenguaje de programacion.
creo que se tendra que tragar con el basic. desde luego estoy de acuerdo con no ceder ante modelos de objeto tan molestos como el OLE.

Porque en ese caso, lo mejor sería centrarse en terminar Wine y olvidarse de todo.

Y aquí no se dice nada.

No creo que haga falta dar tanto soporte para captar usuarios de Office, al fin y al cabo cuantos usuarios hacen uso siquiera de las macros de un procesador de texto? aparte de los que se dedican a desarrollar virusillos... a ver si al final en vez de tener mas máquinas trabajando con LiNUX vamos a tener mas LiNUX petando como Windows... ;-)

En cualquier caso había alternativas mejores y, dado que no debería sobreponerse la excusa de la compatiblidad a otras razones como la eficiencia mismamente, creo que la implementación de BASIC debería haber sido un objetivo secundario y los esfuerzos iniciales tal vez hubieran estado mejor dirigidos hacia otros lenguajes, como el citado python; quiero decir, que el motor primario fuera algo decente y, si acaso, establecer a otro nivel una compatiblidad con el BASIC de Office.

Todo ello sin desmerecer tu interesantísimo punto de vista ;-)

como un sabio hablas...
todo es cuestion de parametros y prioridades...

El GNOME Midnight Commander (gmc) efectivamente es un programa que, desde que nació, estaba llamado a morir, pues era una extensión, para GNOME, del famoso Midnight Commander, que ese si que no me negarás que, como aplicación de consola, es una maravilla.

Estos problemas del gmc son los que decidieron a la comunidad GNOME a hacer el Nautilus. Pero no te quejes mucho, que ya queda muy poquito para la defunción definitiva del gmc.

Podríamos escribir el Access y enchufarle el Visual Basic este. Luego lo llenamos de componentes y le metemos un navegador. Así podremos escribir un documento de texto con el equivalente al Word y meterle una película para luego imprimirla.

En fin, que al final vamos a conseguir ser el espejo de Microsoft.

Luego llenaremos de asistentes todos los programas.

Acabo de terminar un proyecto para una administración pública que acaba de aunar todas sus aplicaciones a un mismo lenguaje de programación. A tardado seis años desde la decisión corporativa para realizar tal migración hasta que el usuario final a podido utilizar las nuevas herramientas en dicho lenguaje.

Esa decisión tuvo que ver con el hecho que el mantenimiento de las distintas aplicaciones, realizadas en Cobol, Pascal, Basic, Clipper, etc, etc, no podía mantenerse. Muy bien pensado por los responsables.

No obstante, como he mencionado, han tardado !!!!seis años!!!! en migrar a otro sistema que utiliza un solo lenguaje de programación. Esta empresa no se volverá a meter en otra migración hasta dentro de 15 años por lo menos, según lo acordado por esta.

¿Crees que por muy bueno que sea GNU/Linux, con todas sus ventajas (y sus pocas desventajas), se meterán antes de 15 años en otra migración a otro sistema totalmente distinto al suyo?

Lo ideal para el responsable de informática de dicha empresa (en este caso administración pública) le será mucho más aceptable portar a un entorno con el mínimo coste posible, es decir, recompilar los fuentes y resolver las pequeños problemas inherentes a toda migración. Es decir, pasar de un sistema a otro en unos 6 meses como mucho, como ha ocurrido en dicha administración (migración de versión del mismo paquete).

Lo que quiero decir, es que, aunque lo ideal sea reescribir todo el código, e incluso realizar un analisis funcional y técnico (en algunos sitios se hace), las empresas, después del bluf que fue el evento 2000, no se atreverán a cambiar drásticamente sus aplicaciones para pasar de un SO a otro.

Bye

No me parece que el Basic sea el lenguaje del milenio y no creo que se este imponiendo a nadie utilizarlo. Pero pongamonos en un escenario posible. Una organización ha invertido 10.000 horas/hombre en macros de Excel y programas en Visual Basic. Deciden migrar a GNU/Linux porque estan convencidos de que es mucho mejor técnicamente y la solución es invertir otras 10.000 horas en pasarlo a C, Python o cualquier otro lenguaje.Creo que es una aberración del tamaño de un sioux y completamente inviable desde el punto de vista financiero. Ahora cambiemos la solución por: existe un traductor/inteprete de Basic que te convierte las hojas de Excel a Gnumeric (y el lenguaje de script es el que te de la gana C, Python o perl) y las aplicaciones tambien con "pequeños" retoques. Yo no tengo ninguna duda prefiero la segunda. GNU/Linux no es para la "elite" de gurus, es para todo el mundo y cuanta más gente lo use mejor.

Por mucha compatibilidad que haya con macros y demás, me parece que la mera migración del sistema, supera al tema del Visual Basic, por muy realmente bueno que sea Linux

Pero realmente, si consideras mantenible y coherente el Visual Basic pues q quieres que te diga.

Pero tu hablas de traductor, algo totalmente distinto a soporte del propio lenguaje. Si la incoporaciónde VB va a traer un lastre de compatibilidad tipo memoria segmentada, o MSDOS o algo de eso, mejor apaga y vámonos. ( por no hablar que habrá q tener un equipo viendo por donde va cambiando M$ el lenguaje).

Un fusile del nc, pero probablemente sea una de las cosas que mas suelo usar =).

...De no ser por Microsoft, BASIC ya estaría durmiendo y gozando la paz de los justos.

BASIC no fue malo, de hecho, es un lenguaje valioso para enseñar los fundamentos... Pero responde a paradigmas de programacion que ya no son validos, y es MARAVILLOSO para crear programadores malos :(

GnomeBasic fue pensado inicialmente para que Gnumeric pudiera correr las macros de excel, actualmente en gnumeric puedes escrivir formulas en python, guile y perl y cuando se pueda controlar via CORBA (ya hay algo implementado, pero creo que de momento no funciona), se podra hacer scripting desde cualquier lenguaje que tenga bindings, osea que GB es simplemente una alternativa mas para facilitar la migracion.

El ejemplo que he dado de migración se basa en la migración de la versión 3.x a 4.x de SAP y se ha conseguido en ese periodo de tiempo. No es sencillo, sino que es mucho más simple que el paso de un sistema (ejemplo Cobol, por no decir VB) a o otro (Linux bajo Phyton, C, C++, etc).

Mi opinión sobre el VB es que es una mierda con todas las palabras (he trabajado con él desde la versión beta de la 1.0 hasta la útilma, simpre bajo coacción y amenazas). Prefiero el C y el C++, y si me apuras, los nuevos interpretes y lenguajes que han se utilizan bajo Linux.

Lo que defiendo es que las empresas no se plantearán a corto plazo el cambio a otro sistema si ha desarrollado bajo VB (incluyendo las macros de Excel, Word y de lo que quieras) hasta por lo menos 5 años, debido a que la mayoria de estas han aprovechado el efecto 2000 para realizar sus migraciones a otros sistemas.

Por lo cual, si Linux dispone de una herramienta compatible con VB, o conversores de código fiables a otros lenguajes, será más factible que las empresas empiecen a pensar a pasarse a Linux.

Otra cosa será que empresas como Oracle, SAP, meta4, etc desarrollen sus herramientas (ya sea como servidores o como clientes) para Linux, tal como estan haciendo las dos primeras (SAP en modo cliente bajo Linux va un 50% más rápido que bajo Windows, ya sea 98 o NT y eso con la versión beta de su cliente). Pero muchas empresas tienen otras herramientas para funciones que no soportan las herramientas que he mencionado. Ese es el hueco a llenar por la comunidad.

Un saludo ;-))))

En cualquier caso había alternativas mejores y, dado que no debería sobreponerse la excusa de la compatiblidad a otras razones como la eficiencia mismamente, creo que la implementación de BASIC debería haber sido un objetivo secundario y los esfuerzos iniciales tal vez hubieran estado mejor dirigidos hacia otros lenguajes, como el citado pythonquiero decir, que el motor primario fuera algo decente y, si acaso, establecer a otro nivel una compatiblidad con el BASIC de Office

Gnumeric soporta extenciones en python, guile y perl, pero por el momento solo para escrivir formulas. El motor primario del que hablas es CORBA, por la cual se podra hacer scripting desde muchos lenguajes. Otra cosa, gnumeric soporta extenciones por medio de plugins, y esto es lo que es el soporte para gb, si no te gusta lo borras y no te causa problemas, igual que los plugins de python, guile y perl.

Efectivamente. Solo q espero que no pase como en Windows, que se exteindas ese tipo de aplicaciones mal hechas como virus. (ojo que no dudo que haya algunas bien hechas, pero mucho de lo que he visto :()

La solución más interesante, es que los lenguajes de macros para aplicaciones se pudieran instalar y desinstalar como si fueran plugins.

      Deberían estar desarrollados en forma de librerías de enlace dinámico y exportando una serie de funciones identicas independientemente del lenguaje del que se trate. VBA, GUILE, python, Perl, Java Script, Tcl, c-script, sh script, etc.

      Estas dll deberían estar hechas de tal forma que sean fácilmente utilizables desde cualquier aplicación, esté hecha en consola, ncurses, KDE, gnome, XLib o motif.

      Cuando se desarrolle una aplicación, se centra uno en la aplicación sin complicarse la vida con el lenguaje de script. Y así disponer desde el primer momento de una aplicación nueva de todos los lenguajes que ya estén desarrollados, siendo el usuario el encargado de instalar el lenguaje o lenguajes que mas le conviene o necesita.

      Cuando se ejecuta un script extraño, la primera línea de este script, tendría un significado similar a los script que se ejecutan desde el shell de Unix/Linux, indicar qué lenguaje de script se debe usar.

      De esta forma no haría conflictos, si un equipo de desarrollo quiere desarrollar un Visual Basic for Aplications, haya el con su body.

Por mucho q me esfuerce no tengo si no que dar la
razón a Drizzt...
ya puestos a hacer burradas mejor se arregla el wine ;).

Por lo que yo se no muchas empresas desarollan sus programas en visual Trashic pero lo hacen en lenguajes mas malos como visual fox. Mientras que otras se ariesgan a Visual c/c++ . Ademas quien quiere un programa malo programado en vb para que sirva en linux ... no me parece.

Si, una alternativa que puede fomentar ciertos vicios de programación que todo el mundo conoce. En fin, para gustos colores.

No hay "motor" primario en CORBA. Corba no deja de ser un RPC donde podemos pasar parmetros,llamar a métodos o tocar propiedades. En absoluto tiene que ver el método de tu meter plugins, o lo que quieras, o como manejar los componetes reales de Gnumeric ( que para eso está Bonobo o en el caso de Excel COM). No lleves a corba para lo que no es.

EL lenguaje en el que realmente se escriben es el que sea, y no peudes esperar que si están hechos en VB "magicamente" se conviertan el perl, python o guille.

Si la presencia de VB va a llevar a una plaga de aplicaciones, desarrolladas como muchas aplicaciones que se han visto en Windows, pues apaga y vámonos,ya he visto demasiada shareware / freeware / pagoware basura en ese plan, como para seguir viendolo en el mundo Linux.

>No creo que haga falta dar tanto soporte para captar usuarios de Office, al fin y al cabo cuantos usuarios hacen uso siquiera de las macros de un procesador de texto?

Te sorprenderia ver las impresionantes hojas de cálculo que se hacen algunos contables ellos solitos sin tener ni idea de programacion. Y no solo fórmulas, tambien alguna que otra macro o función en VB.

He visto tener que ampliar la memoria a un equipo para que el Excel andase con estos cálculos nada triviales.

Por supuesto que un buen programador podria hacer esto mucho mejor y más rápido ( en tiempos de desarrollo y de ejecución ) pero la informática debe servir para que cualquiera resuelva sus problemas fácilemente y NO dependa de una élite de "elegidos" y gurús.

Si a uno de estos usuarios "avanzados" de Excel (hay muchos mas de los que piensas) le presento Linux puedo:

a) Hacerle aplicaciones que le hagan los cálculos que quiere con mis maravillosos conocimientos de C, Perl, o lo que sea. Un trabajo gordo porque yo no se ni la milesima parte de lo que el sabe de contabilidad. Ademas, si quiere otro cálculo tiene que volver a llamarme.

b) Enseñarle Perl o el maravilloso lenguaje de script de moda del momento soportado por Gnumeric para que pierda el tiempo en rehacer lo que ya tiene hecho.

c) Intentar que Gnumeric importe sin problemas de Excel soportando sin problemas VB. Ademas puedo guiarlo a que los siguientes cálculos los haga con tal o cual lenguaje de script tambien soportado por Gnumeric. O sea, le facilito las cosas y ademas le doy alternativas.

Creeme que con solo las opciones a) y b) nadie querra pasar a Linux. ¿ para que ? Si ya les funciona y les va bien con Excel.

Creemos un GNU/Linux para todos y no solo para los informaticos.

...a un usuario "de oficina" no le puedes hablar de que si la eficiencia del modelo de noseque o que si usa un código no optimizado y blah, blah, blah. Normalmente la informática le importa tres pepinos y lo que quiere el buen señor es pegar con el ratón su media docena de controles, meterle a cada uno veinte líneas de churrocódigo que no cumple los inmutables esquemas de excelencia de la ingeniería del software y ala, a rular el programita que acaba de hacer que le calcula las amortizaciones del inmovilizado según el método de Periko Of the Palotes ;) nos guste o no M$ acertó de lleno con el tema del VB y de su uso en scripts y hay que dar lo que quiere la gente.

Los plugins de gnumeric son basados en bibliotecas compartidas, actualmente tiene plugins para escrivir funciones para usarlas en la hoja de calculo en python, guile y perl (esto lo dije por aquello que decian que mejor deberian usar python), el plugin de gb tambien es una libreria compartida que la borras y no te da conflicto.
Ahora si quieres hacer scripting en otros lenjuages como en gb, puedes usar CORBA, o bonobo, desde cualquier lenjuage que tenga bindings y voila. Yo en ningun momento dije que se hiban a convertir a ningun lenguaje, solo afirme que gb solo es una opcion, como lo son perl, python, guile, etc, etc.