Qt vs GTK
Xavier Montero
no puede existir un conjunto de librerías que reúnan lo bueno de los
dos para evitar tener múltiples vertientes... No me creo que sea
mejor "tener los dos para poder elegir". Lo que debería suceder
es tender a unificar, no? O estoy diciendo cosas que no tocan.
Razona tu respuesta (como en EGB, je, je)
Xavi.
samsagaz
La principal diferencia es que Gtk tiene licencia GPL y Qt norl. Solo
por esto ya deberias plantearte seriamente elegir uno. Por otro lado, la
mayoria de gente elige Gtk o Qt dependiendo de su escritorio preferido.
Ademas y tambien muy importante es que Gtk esta escrito en C y Qt en
C++, y el C++ apesta.
--
Los elementos mas comunes del universo : el hidrogeno y la estupidez.
folgui
GTK-Gnome como QT.
Saludos.
Xavier Montero <xmon...@dsitelecom.com> escribió en el mensaje de noticias
392B29F4...@dsitelecom.com...
Xavier Montero
>
> La última versión de gIDE, creo que la 0.3.0, permite desarrollar tanto para
> GTK-Gnome como QT.
>
--------------------------------------------------------------
Chao!
Xavi
http://www.dsitelecom.com/ (Digital Sound Items)
--------------------------------------------------------------
Xavier Montero
>
> La principal diferencia es que Gtk tiene licencia GPL y Qt norl. Solo
> por esto ya deberias plantearte seriamente elegir uno. Por otro lado, la
> mayoria de gente elige Gtk o Qt dependiendo de su escritorio preferido.
> Ademas y tambien muy importante es que Gtk esta escrito en C y Qt en
> C++, y el C++ apesta.
>
me gusta 1000 (o 1024) veces más el C++ que el C.
samsagaz
>
> samsagaz escribió:
> >
> > La principal diferencia es que Gtk tiene licencia GPL y Qt norl. Solo
> > por esto ya deberias plantearte seriamente elegir uno. Por otro lado, la
> > mayoria de gente elige Gtk o Qt dependiendo de su escritorio preferido.
> > Ademas y tambien muy importante es que Gtk esta escrito en C y Qt en
> > C++, y el C++ apesta.
> >
> Estoy de acuerdo en todo excepto la machacada que le pegas al C++. A mí
> me gusta 1000 (o 1024) veces más el C++ que el C.
>
> Gracias.
>
portable que C++.
--
Ramera: Mujer que comercia con la RAM.
Eduardo Perez
>
> La última versión de gIDE, creo que la 0.3.0, permite desarrollar tanto para
> GTK-Gnome como QT.
>
>
> Xavier Montero <xmon...@dsitelecom.com> escribió en el mensaje de noticias
> 392B29F4...@dsitelecom.com...
> > Po eso... Una o dos líneas de qué tiene uno versus el otro y porqué
> > no puede existir un conjunto de librerías que reúnan lo bueno de los
> > dos para evitar tener múltiples vertientes... No me creo que sea
> > mejor "tener los dos para poder elegir". Lo que debería suceder
> > es tender a unificar, no? O estoy diciendo cosas que no tocan.
> >
> > Razona tu respuesta (como en EGB, je, je)
> > Xavi.
Que el gIDE soporte o no GTK-Gnome / QT me parece que es poco relevante.
¿Qué significa que lo soportan? Ambos entornos sólo aportan a los
programas algunas librerías específicas, así que cualquier programa de
desarrollo se puede utilizar. Lo que generes con gIDE va a seguir siendo
un programa en C o C++ con llamadas a las funciones de GTK-Gnome o a las
de QT. Otra cosa son las aplicaciones como GLADE, que permiten crear
aplicaciones para GTK, pero creo que no es el caso.
Espero haber ayudado.
Jose Luis
Alla cada uno con sus ideas ... programemos en COBOL, volvamos al DOS (uy,
que digo), mejor dicho, programemos en pascal.
¿Que problemas de portabilidad ves en C++ que no tienes en C?
Saludos,
glez
PD.- No es por fastidiar, solo que me ha llamado la atencion ....
samsagaz <sams...@menta.net> escribió en el mensaje de noticias
39315D3D...@menta.net...
Drizzt
>Po eso... Una o dos líneas de qué tiene uno versus el otro y porqué
>no puede existir un conjunto de librerías que reúnan lo bueno de los
>dos para evitar tener múltiples vertientes... No me creo que sea
>mejor "tener los dos para poder elegir". Lo que debería suceder
>es tender a unificar, no? O estoy diciendo cosas que no tocan.
>
QT es C++ ( aunque se puede usar, en otros lenguajes). Es desde su versión 2.x
open source. Para mi son mucho más completas y fáciles de usar que GTK. De
hecho, cuando ni GTK existia la libreria era una maravilla.
Un saludo
Drizzt
--
____________________________________________________________________________
Drizzt Do'Urden Three rings for the Elves Kings under the Sky
drizzt....@iname.com Seven for the Dwarf_lords in their
hall of stone
Nine for the Mortal Men doomed to die
Drizzt
>
>La principal diferencia es que Gtk tiene licencia GPL y Qt norl. Solo
>por esto ya deberias plantearte seriamente elegir uno. Por otro lado, la
>mayoria de gente elige Gtk o Qt dependiendo de su escritorio preferido.
>Ademas y tambien muy importante es que Gtk esta escrito en C y Qt en
>C++, y el C++ apesta.
Entonces no usaras las XWindow. Ni el OpenSSH, ni postgress. POrque ninguno de
ese soft es GPL. Ademas, GTK se dedica a imitar programación orientada a
objetos en C, IMHO es una chorrada, existiendo lenguajes orientados a objetos.
Drizzt
>samsagaz escribió:
>>
>> La principal diferencia es que Gtk tiene licencia GPL y Qt norl. Solo
>> por esto ya deberias plantearte seriamente elegir uno. Por otro lado, la
>> mayoria de gente elige Gtk o Qt dependiendo de su escritorio preferido.
>> Ademas y tambien muy importante es que Gtk esta escrito en C y Qt en
>> C++, y el C++ apesta.
>>
>me gusta 1000 (o 1024) veces más el C++ que el C.
Prueba las QT antes de dejarte llevar por tonteroas de licencias. Luego leete
la licencia de la 2.x. Verás como es Soft opensource. Y si tanto te procupa
que sea GPL y usar soft no-GPL no sé porqué usas las X, que no son GPL.
Drizzt
>Xavier Montero escribió:
>Todo es cuestion de gustos, pero lo indiscutible es que C es mucho mas
>portable que C++.
JAJA. Eso es más que discutible. Hay que ver cuanto soft utiliza las
extensiones GNU del gcc y que no compilan ni a tiros con otro compilador.
Drizzt
>folgui escribió:
>>
>> La última versión de gIDE, creo que la 0.3.0, permite desarrollar tanto para
>> GTK-Gnome como QT.
>>
El kdevelop permite QT, KDE, Gnome, etc
Joaquín Cuenca Abela
samsagaz <sams...@menta.net> wrote:
> Xavier Montero escribió:
> >
> > samsagaz escribió:
> > >
> > > La principal diferencia es que Gtk tiene licencia GPL y Qt norl.
Solo
> > > por esto ya deberias plantearte seriamente elegir uno. Por otro
lado, la
> > > mayoria de gente elige Gtk o Qt dependiendo de su escritorio
preferido.
> > > Ademas y tambien muy importante es que Gtk esta escrito en C y Qt
en
> > > C++, y el C++ apesta.
Por que apesta?
> Todo es cuestion de gustos, pero lo indiscutible es que C es mucho mas
> portable que C++.
Que sistema conoces que no tenga disponible un compilador de C++?
Incluso los mas exoticos como QNX/Photon tienen uno...
Un saludo!
--
Joaquín Cuenca Abela
e-mail: cue...@ie2.u-psud.fr
Sent via Deja.com http://www.deja.com/
Before you buy.
Luca Olivetti - Please remove the tv-show!
Hash: SHA1
On Mon, 29 May 2000 09:51:10 +0200,
Jose Luis <joseluisgonz...@yahoo.es> wrote:
>La programación orientada a objetos te da igual, por lo que veo.
>
>Alla cada uno con sus ideas ... programemos en COBOL, volvamos al DOS (uy,
>que digo), mejor dicho, programemos en pascal.
¿Acaso crees que no se puede hacer programación orientada a objetos con el
Pascal?
El object pascal de Borland (y su clónico libre, el free pascal compiler,
disponible para dos y Linux) no tiene nada que envidiar al C++, a cambio
mientras un compilador C++ está todavía tragándose las cabeceras de un
fichero el object pascal ya se ha compilado todo el proyecto.
Y si programásemos en pascal no tuviéramos tantos problemas de buffer
overflow....
Saludos.
- --
Luca Olivetti http://olivetti.cjb.net Linux registered user #55968
- --------- Asociación de Internautas http://www.internautas.org ---------
Telefonica, PP y CiU son un freno para el desarrollo del país
Telefonica, PP and CiU are a restrain on the development of the country
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE5MutfCQPXTRx9NmQRAk7nAJ4+YO+MVaPUmPQRvO/gs/QVzFnQJACgunxg
yf7FcTQJYNEEB1DHcf62Db8=
=0mif
-----END PGP SIGNATURE-----
Jose Luis
> >
> >Alla cada uno con sus ideas ... programemos en COBOL, volvamos al DOS
(uy,
> >que digo), mejor dicho, programemos en pascal.
>
> ¿Acaso crees que no se puede hacer programación orientada a objetos con el
> Pascal?
Efectivamente, lo creo. En la especificación del lenguaje PASCAL no esta
contemplado lo que tu comentas.
Me parece muy bien que te guste Pascal e incluso que utilices una version
orientada a objetos ... habria que ver hasta que punto es orientado a
objetos ... un lenguaje de programación se define por la forma de manejar
una serie de caracteristicas del lenguaje, y no creo que esto que comentas
defina un lenguaje orientado a objetos puro y duro ... allla cada uno con
sus elecciones.
No me voy a poner ahora en plan defensor de C++. Primero, me parecio una
locura que alguien diga que C es mejor que C++. Segundo, me parece
impresionante que ante una frase del estilo de " ... programemos en COBOL y
PASCAL" me conteste alguien diciendo que hay una variante de Pascal
orientada a objetos, pues perfecto, la utilizaras tu y cuatro mas .... ya me
contaras si tambien tiene cuestiones orientadas a programacion distribuida,
llamada a metodos remotos, comparticion de objetos, ....
Pascal es un lenguaje de programacion que fue creado para enseñar
programacion. Hay multiples variantes o variaciones de este lenguaje como
Delphi o la que tu comentas.
Pero, ¿de verdad crees que ese object Pascal es mejor que C++? Y por favor,
no califiques solo la velocidad de compilacion, un lenguaje tiene muchas
otras caracteristicas, y un lenguaje te ofrece muchas mas funcionalidades
que debes evaluar.
glez
J.A. Gutierrez
:> Todo es cuestion de gustos, pero lo indiscutible es que C es mucho mas
:> portable que C++.
: Que sistema conoces que no tenga disponible un compilador de C++?
: Incluso los mas exoticos como QNX/Photon tienen uno...
no es problema de que lo tenga disponible o no.
Es indiscutiblemente menos portable:
- los ficheros objetos no son portables, por definicion, diferentes
compilardores utilizan diferentes "mangleados"
- C++ se ha estandarizado muy recientemente, y aun hoy entre
diferentes compiladores existen diferencias significativas que
hacen que el mismo codigo compile en unos y falle en otros.
A modo de ejemplo, recientemente he tenido que trabajar con
el codigo de otra gente, que trabaja con una version no demasiado
reciente de g++.
Intente compilar todo con el compilador nativo de mi sistema
y no hubo manera; como las librerias son incompatibles, ademas
tube que recompilarlas con el g++; y como encima en lugar de
las STL utilizaban la libg++ (ya obsoleta), pues a compilarla
tambien...
(me diras: bueno, es que ese codigo no estaba hecho siguiendo
el standard; pero lo cierto es que cogiendo cualquier codigo
al azar hecho en C, por guarro que sea, es mas facil que se
compile en cualquier compilador de C que lo mismo para C++)
--
PGP and other useless info at \ Oh, show us the way
http://www.cps.unizar.es/~spd/ \ to the next whisky bar
finger://daphne.cps.unizar.es/spd \ Weill/Bretch
es doloroso ser sabio y descubrir la sopa de ajo (Pla)
MiP
>
> La última versión de gIDE, creo que la 0.3.0, permite desarrollar tanto para
> GTK-Gnome como QT.
No entiendo esta polémica.
Segun creia, GTK permite programar en varios lenguajes, no?
en
http://gtkmm.sourceforge.net/
hay una interface para C++ con GTK.
Si no me equivoco, ya se puede programar en C++ con GTK,
además de C etc.
Un saludo.
samsagaz
gustos y ese dia iba un poco cabreadillo.
Lo que es cierto es que cada lenguaje esta pensado para trabajar en un
campo concreto o en varios campos (los lenguajes que intentan abarcarlo
todo acaban apestando, vease Visual Basic)
Asi que el C esta pensado para desarrollar aplicaciones para el SO, el
C++ para lo mismo pero con a un nivel un poco mas alto y asi cientos de
lenguajes diferentes.
Esta claro que si quieres hacer una aplicacion para una empresa que
consista en una base de datos no vas a hacerlo en C, escogeras un
lenguaje de mayor nivel y asi conseguiras ahorrarte mucho dolores de
cabeza.
--
Nuestro orden defiende la Iglesia católica, apostólica y romana, es
decir,
el conjunto de los sentimientos que mantienen al pueblo en la
obediencia.
(H. de Balzac)
Joaquín Cuenca Abela
"J.A. Gutierrez" <s...@daphne.cps.unizar.es> wrote:
>
> :> Todo es cuestion de gustos, pero lo indiscutible es que C es mucho
mas
> :> portable que C++.
Y aun asi lo estamos discutiendo... :)
> : Que sistema conoces que no tenga disponible un compilador de C++?
> : Incluso los mas exoticos como QNX/Photon tienen uno...
>
> no es problema de que lo tenga disponible o no.
>
> Es indiscutiblemente menos portable:
>
> - los ficheros objetos no son portables, por definicion, diferentes
> compilardores utilizan diferentes "mangleados"
>
> - C++ se ha estandarizado muy recientemente, y aun hoy entre
> diferentes compiladores existen diferencias significativas que
> hacen que el mismo codigo compile en unos y falle en otros.
Francamente, esto es algo muy raro.
> A modo de ejemplo, recientemente he tenido que trabajar con
> el codigo de otra gente, que trabaja con una version no demasiado
> reciente de g++.
> Intente compilar todo con el compilador nativo de mi sistema
> y no hubo manera; como las librerias son incompatibles, ademas
> tube que recompilarlas con el g++; y como encima en lugar de
> las STL utilizaban la libg++ (ya obsoleta), pues a compilarla
> tambien...
Lo que comentas no es problema de C++ sino de las bibliotecas
utilizadas, y exactamente el mismo problema te lo encuentras con
C. Por ejemplo, el siguiente programa:
#include <stdio.h>
#include <strings.h>
#include <stdlib.h>
int main (int argc, char *argv[])
{
char *tmp = strdup (argc > 1 ? (const char *) argv[1] : "");
printf ("%s\n", tmp);
free (tmp);
}
que compila (o deberia, no lo he probado :) en linux, pero que no lo
hace (o puede no hacerlo, tampoco lo he probado) en windows. Hay
cientos de peque~nas funciones que tienes disponibles con las
bibliotecas que acompa~nan a un compilador y que no te vienen con
otro compilador (otro peque~no ejemplo que me viene a la mente,
stricmp de VC y strcasecmp de GNU que hacen exactamente lo mismo, pero
claro, si usas stricmp con gcc o strcasecmp con VC estas jodido).
Este problema fue el que origino la creacion de glib, pero no esta tan
extendido fuera de linux como para poder utilizarlo y dormir tranquilo.
> (me diras: bueno, es que ese codigo no estaba hecho siguiendo
> el standard; pero lo cierto es que cogiendo cualquier codigo
> al azar hecho en C, por guarro que sea, es mas facil que se
> compile en cualquier compilador de C que lo mismo para C++)
No, te dire: bueno, pero al menos en C++ tienes una biblioteca
*estandar* lo suficientemente completa. Si alguien no la usa es su
problema. El problema aqui es que en C no tienes ninguna biblioteca
comparable a STL que todos los compiladores soporten.
La segunda parte de tu parrafo ("cualquier codigo al azar hecho en
C...") simplemente no es cierto. C++ "correcto" es igual de portable
que C "correcto". El problema es que con C "correcto" (entiendase por
correcto que no utilice una biblioteca que sea un estandar para todos
los compiladores) te faltan montones de peque~nas funciones muy utiles,
y C++ "correcto" es perfectamente utilizable (STL contiene todo lo que
se le puede pedir a una biblioteca de ese tipo).
Joaquín Cuenca Abela
e_mail_en_signature@menzoberrazan wrote:
>
> Prueba las QT antes de dejarte llevar por tonteroas de licencias.
No son tonterias para todo el mundo...
Luego leete
> la licencia de la 2.x. Verás como es Soft opensource. Y si tanto te
procupa
> que sea GPL y usar soft no-GPL no sé porqué usas las X, que no son
GPL.
La licencia de X no tiene nada que ver con la QPL. Y la QPL tiene
un problema practico muy importante: no puedes mezclar codigo QPL
con codigo GPL, sin embargo si que puedes mezclar codigo con licencia
X con codigo con licencia GPL.
Para muchas personas, este problema es tan importante que hace que
no puedan utilizar Qt (simplemente, hay *mucho* codigo GPL para "copiar
y pegar" hay fuera :)
J.A. Gutierrez
:>
:> - los ficheros objetos no son portables, por definicion, diferentes
:> compilardores utilizan diferentes "mangleados"
:>
:> - C++ se ha estandarizado muy recientemente, y aun hoy entre
:> diferentes compiladores existen diferencias significativas que
:> hacen que el mismo codigo compile en unos y falle en otros.
: Francamente, esto es algo muy raro.
no por mi experiencia, ni por la de la gente que conozco...
Especialmente en cuanto se meten con templates.
: #include <stdio.h>
: #include <strings.h>
: #include <stdlib.h>
: int main (int argc, char *argv[])
: {
: char *tmp = strdup (argc > 1 ? (const char *) argv[1] : "");
: printf ("%s\n", tmp);
: free (tmp);
: }
: que compila (o deberia, no lo he probado :) en linux, pero que no lo
: hace (o puede no hacerlo, tampoco lo he probado) en windows. Hay
que no lo hace? me suena muy raro.
(en todo caso, yo estaba pensando sobre todo en compatibilidad
entre diferentes unix)
: cientos de peque~nas funciones que tienes disponibles con las
: bibliotecas que acompa~nan a un compilador y que no te vienen con
pero si que hay un minimo disponible en todas partes.
: otro compilador (otro peque~no ejemplo que me viene a la mente,
: stricmp de VC y strcasecmp de GNU que hacen exactamente lo mismo, pero
: claro, si usas stricmp con gcc o strcasecmp con VC estas jodido).
es que no hay que viciarse usando esas funciones "extra" (o
al menos, incluir una implementacion alternativa)
: La segunda parte de tu parrafo ("cualquier codigo al azar hecho en
: C...") simplemente no es cierto. C++ "correcto" es igual de portable
: que C "correcto".
Bueno, sustituyendo codigo C++ al azar por "aplicaciones
de dominio publico escritas en C++". Por lo general, siempre
me dan muchos mas problemas para compilarlas que las escritas
en C
Raúl (Ridiculum)
>QT es C++ ( aunque se puede usar, en otros lenguajes). Es desde su versión 2.x
>open source. Para mi son mucho más completas y fáciles de usar que GTK. De
>hecho, cuando ni GTK existia la libreria era una maravilla.
>
>Un saludo
>Drizzt
de GTK??? Esta entre esos enlaces el C??
Es que a mi el tema de C++ me sobrepasa, pero tengo en mente un
programa (simulador de enlaces de fibra optica) que necesita de un
GUI y me interesa saber como está el tema ese, porque me habia
decidido por GTK
--
Miembro del grupo LILO: htpp://www.airtel.net/hosting/a_hoz
Linux User 157744
Red Hat 6.0 (2.2.14)
rorQU...@retemail.es
r...@QUITALOingenierosmix.com
Drizzt
> El 29 May 2000 01:21:15 GMT, Drizzt escribió:
> >QT es C++ ( aunque se puede usar, en otros lenguajes). Es desde su versión 2.x
> >open source. Para mi son mucho más completas y fáciles de usar que GTK. De
> >hecho, cuando ni GTK existia la libreria era una maravilla.
> >
> >Un saludo
> >Drizzt
> Tienen las QT enlaces a otros lenguajes que no sea C++, al estilo
> de GTK??? Esta entre esos enlaces el C??
> Es que a mi el tema de C++ me sobrepasa, pero tengo en mente un
> programa (simulador de enlaces de fibra optica) que necesita de un
> GUI y me interesa saber como está el tema ese, porque me habia
> decidido por GTK
AL menos que conozca yo, a perl y python seguro. C tambien hay algo
Roberto Alsina se escribio unos binding para el tema, la libreria
en cuestion se llama QtC
Un saludo
Drizzt
Drizzt
> La licencia de X no tiene nada que ver con la QPL. Y la QPL tiene
> un problema practico muy importante: no puedes mezclar codigo QPL
> con codigo GPL, sin embargo si que puedes mezclar codigo con licencia
> X con codigo con licencia GPL.
Tampoco puedes mezclar codigo BSD con codigo GPL y nadie pone el grito
en el cielo. Aunque claro, se hace, pero no se reconoce (licencia del
fips por ejemplo, GPL, y linkado al runtime de Borland, propietario),
o cuando el DDD se compilaba con Motif.
La QPL es una licencia opensource, al menos en los terminos de ESR.
> Para muchas personas, este problema es tan importante que hace que
> no puedan utilizar Qt (simplemente, hay *mucho* codigo GPL para "copiar
> y pegar" hay fuera :)
Ya, por eso el KDE usa las Qt. Aunque empiezo a sospechar, que claro,
siempres es "mas facil copiar" y no pagar un duro, que desarrollar algo,
que a fin de cuenta, es lo que significa tu ultima frase.
Saludos
Drizzt
Drizzt
>http://gtkmm.sourceforge.net/
>
>hay una interface para C++ con GTK.
>
>Si no me equivoco, ya se puede programar en C++ con GTK,
>además de C etc.
Si, pero espero que esté más evolucionada que la última vez que la vi. De
hecho, una de las cosas que a mi me ha hecho siempre descartar GTK ha sido
esa: la falta de una interfaz C++ en condiciones.
Juanjo Álvarez
en fecha: 29 May 2000 01:22:23 GMT
|Entonces no usaras las XWindow. Ni el OpenSSH, ni postgress. POrque ninguno de
|ese soft es GPL. Ademas, GTK se dedica a imitar programación orientada a
|objetos en C, IMHO es una chorrada, existiendo lenguajes orientados a objetos.
No es tan chorrada: Permite que puedas usarlo desde C, Pascal, Fortran,
, etc, además de en lenguajes orientados a objetos. Reconozco que el API
Gtk_desde_C_apesta(), pero tampoco pueden hacer mucho más (sin complicar
mucho la cosa), sin embargo desde Python, por ejemplo, tiene una
orientación a objetos de lo más elegante.
(Por cierto, aprovecho para anunciar que hace poco han salido los
módulos Qt para Python, si bien aún no los he probado).
--
Página personal: http://www.clickeas.com/linux
Debian GNU/Linux 2.2 + ReiserFS
Juanjo Álvarez
en fecha: 31 May 2000 16:04:43 GMT
|El 29 May 2000 01:21:15 GMT, Drizzt escribió:
|>QT es C++ ( aunque se puede usar, en otros lenguajes). Es desde su versión 2.x
|>open source. Para mi son mucho más completas y fáciles de usar que GTK. De
|>hecho, cuando ni GTK existia la libreria era una maravilla.
|>
|>Un saludo
|>Drizzt
| Tienen las QT enlaces a otros lenguajes que no sea C++, al estilo
| de GTK??? Esta entre esos enlaces el C??
Al menos a Python sí que tiene, y creo que a Perl también (y
probablemente a algún que otro lenguaje OO).
| Es que a mi el tema de C++ me sobrepasa,
Le sobrepasa a cualquiera. Demasiado espeso. Prefiero el Java (el Gcj
compila a código nativo), o Python si no se necesita velocidad extrema.
|pero tengo en mente un
| programa (simulador de enlaces de fibra optica) que necesita de un
| GUI y me interesa saber como está el tema ese, porque me habia
| decidido por GTK
Hay un tutorial de Qt 2.0 en la página de Larrosa (¿era así?), busca en
www.ldp.org y lo deberías encontrar.
Jesús M. NAVARRO
Jose Luis wrote:
>
[...]
>
> No me voy a poner ahora en plan defensor de C++. Primero, me parecio una
> locura que alguien diga que C es mejor que C++. Segundo, me parece
> impresionante que ante una frase del estilo de " ... programemos en COBOL y
> PASCAL" me conteste alguien diciendo que hay una variante de Pascal
> orientada a objetos, pues perfecto, la utilizaras tu y cuatro mas .... ya me
> contaras si tambien tiene cuestiones orientadas a programacion distribuida,
> llamada a metodos remotos, comparticion de objetos, ....
>
Bueno, quizá hablo por hablar, pero ¿C++ tiene "cuestiones orientadas a
programación distribuida, invocación remota, objetos compartidos"? Si
me hablas de CORBA, sí, pero C++?
> Pascal es un lenguaje de programacion que fue creado para enseñar
> programacion. Hay multiples variantes o variaciones de este lenguaje como
> Delphi o la que tu comentas.
>
> Pero, ¿de verdad crees que ese object Pascal es mejor que C++? Y por favor,
> no califiques solo la velocidad de compilacion, un lenguaje tiene muchas
> otras caracteristicas, y un lenguaje te ofrece muchas mas funcionalidades
> que debes evaluar.
>
...bueno, primero, aceptar que *nunca* he trabajado con objectPascal,
pero...
1/ El compilador que usa Borland para C++ *es el mismo* que usa para
objectPascal: no habrá tantas diferencias, pues.
2/ Básicamente, objectPascal es un subconjunto de C++ (con algunas
adiciones menores), con soporte menguado para sobrecarga de métodos y
operadores, y sin soporte para herencia múltiple (más de cuatro teóricos
te dirán, con buenas razones, que hay que mirar muy despacito que la
herencia múltiple sea una "ventaja"...)
3/ objectPascal compila en general más rápido que C++ porque
a)objectPascal es más fácil de parsear
b) el tipo de fichero binario de objectPascal (DCU) es más simple y
flexible que el de C++ (obj) y es más fácil de hacerle el 'make'.
4/ Positivamente, objectPascal no lo usan cuatro gatos: Delphi es un
entorno sobre objectPascal y lo usa *bastante* gente.
Las referencias las he obtenido de Charlie Calvert's "Borland C++Builder
Unleashed", de SAMS publishing.
--
SALUD,
Jesús
***
jesus_...@geocities.com
***
DaVinci
> >Si no me equivoco, ya se puede programar en C++ con GTK,
> >además de C etc.
>
> Si, pero espero que esté más evolucionada que la última vez que la vi. De
> hecho, una de las cosas que a mi me ha hecho siempre descartar GTK ha sido
> esa: la falta de una interfaz C++ en condiciones.
Prueba la última versión de Gtk--. He leído que, por fin, resulta
poderosa y estable.
--
DaVinci
Salvador Petit Martí
> Hola Jose Luis:
> Jose Luis wrote:
>>
> [...]
>>
>> No me voy a poner ahora en plan defensor de C++. Primero, me parecio una
>> locura que alguien diga que C es mejor que C++. Segundo, me parece
>> impresionante que ante una frase del estilo de " ... programemos en COBOL y
>> PASCAL" me conteste alguien diciendo que hay una variante de Pascal
>> orientada a objetos, pues perfecto, la utilizaras tu y cuatro mas .... ya me
>> contaras si tambien tiene cuestiones orientadas a programacion distribuida,
>> llamada a metodos remotos, comparticion de objetos, ....
>>
> Bueno, quizá hablo por hablar, pero ¿C++ tiene "cuestiones orientadas a
> programación distribuida, invocación remota, objetos compartidos"? Si
> me hablas de CORBA, sí, pero C++?
Para ese tipo de cosas esta el Objective-C, que nadie usa, por cierto.
-- spetit at disca dot upv dot es --
David Martínez
"Salvador Petit Martí" wrote:
> > Bueno, quizá hablo por hablar, pero ¿C++ tiene "cuestiones orientadas a
> > programación distribuida, invocación remota, objetos compartidos"? Si
> > me hablas de CORBA, sí, pero C++?
>
> Para ese tipo de cosas esta el Objective-C, que nadie usa, por cierto.
>
Supongo que estaré equivocado, pero creo que Objective-C no ofrece
facilidades de programación distribuída de por si.
Cuando se utiliza dentro del framework NeXT/Open/GNUStep se ofrecen
ciertos servicios adicionales, pero la última vez que le eché un vistazo
a la especificación de OpenStep no recuerdo haber visto nada sobre
objetos remotos.
SI estoy equivocado agradecería cualquier referencia, me interesa mucho
el tema
Estoy contigo en que nadie lo usa y que es una verdadera pena, es
realmente potente.
Saludos
David Martínez
Jose Antonio wrote:
> - Los botones, marcos, etc. no tienen la apariencia "tosca" de
> los GTK
GTK ofrece un temas para personalizar totalmente la apariencia de los
controles.
> - Hay una versión de QT para Windows (Gtk para Windows??)
Si, la hay.... yo he utilizado GIMP sobre windows sin servidor X :)
Saludos
Ignacio Arenaza
Hash: SHA1
>>>>> "Jose" == Jose Luis <joseluisgonz...@yahoo.es> writes:
Jose> Me parece muy bien que te guste Pascal e incluso que
Jose> utilices una version orientada a objetos ... habria que ver
Jose> hasta que punto es orientado a objetos ...
Tan orientado a objetos como pueda ser C++ o SmallTalk. Tienes clases,
herencia, polimorfismo, clases virtuales, en fin, todo lo que se
considera imprescindible en un lenguaje orientado a objeto. Por lo que
veo no conoces demasiado de el ;-)
Jose> No me voy a poner ahora en plan defensor de C++. Primero, me
Jose> parecio una locura que alguien diga que C es mejor que
Jose> C++.
Te voy a decir que C _SI_ es mejor que C++ ... en ciertos casos. Y C++
es mejor... en cierto casos. Y Delphy o Java o RPG o COBOL son mejores
que C++/C... si, lo has adivinado, en ciertos casos. No hay _ningun_
lenguaje que sea *el mejor*. Es el mas adecuado en mas o menos
situaciones, pero nunca en todas ellas. De esto estoy bien seguro. Si
el tipo de aplicaciones al que te dedicas habitualmente dicta que C++
es la eleccion mas logica, estupendo. Pero no todo el mundo tiene la
misma problematica y por tanto no todo el mundo tiene porque
considerar el mismo lenguaje el "mas superior".
Jose> .... ya me contaras si tambien tiene cuestiones orientadas a
Jose> programacion distribuida, llamada a metodos remotos,
Jose> comparticion de objetos, ....
Esto, que yo sepa, no es parte del lenguaje C++. Esta (como mucho) en
las bibliotecas de funciones adicionales. Y si hablamos de CORB A (por
poner un ejemplo que se ajuste a tus "requisitos") recuerdo que hay
interfaces para usarlo desde lenguajes como Delphi Pascal.
Saludos. Iñaki.
- --
Get PGP/GPG Keys at http://personales.jet.es/inaki.arenaza/pgpkey.html
A proud member of GULA - http://gula.hispalinux.es/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.4 and Gnu Privacy Guard
iD8DBQE5NWwIZXLnGT1HLgcRAmc7AJ9Fk/HANYiKKcaL7vRgO3K/dtQniACfV8Cc
c/vvDydGnI9wm0d8AspNGOU=
=nv1D
-----END PGP SIGNATURE-----
Mario Teijeiro Otero
Hash: SHA1
ter...@menzoberrazan.dhis.org (Drizzt) writes:
> El día Sun, 28 May 2000 14:19:48 +0200, Xavier Montero decía:
> >folgui escribió:
> >>
> >> La última versión de gIDE, creo que la 0.3.0, permite desarrollar tanto para
> >> GTK-Gnome como QT.
> >>
> >Ok. Gracias.
>
>
> El kdevelop permite QT, KDE, Gnome, etc
versión 1.2 o mayores.
- --
vi vs emacs: Es como el papel del water: o lo pones con el papel colgando por
delante o por detrás, pero siempre lo pondrás por el mismo lado.
(Xavier González Onrubia)
====================================================================
Mario Teijeiro Otero mailto:asimovi at teleline dot es
Powered by Hispafuentes 6.1 clave: correo con Asunto: "[PGPKEY]"
Usr. Reg. 122438 o en http://www.terra.es/personal2/asimovi
====================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard <http://www.gnupg.org/>
iD8DBQE5Nk9dMKsc+XeZcdwRAi6cAJ4qVc7sGsC2z3wH3KlzwAj268QNvgCfQnLR
DtZLSChraTQXRfRIbRMr8xs=
=/JnK
-----END PGP SIGNATURE-----
samsagaz
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Version: GnuPG v1.0.1 (GNU/Linux)
>
> iD8DBQE5NWwIZXLnGT1HLgcRAmc7AJ9Fk/HANYiKKcaL7vRgO3K/dtQniACfV8Cc
> c/vvDydGnI9wm0d8AspNGOU=
> =nv1D
> -----END PGP SIGNATURE-----
basic es una peazo de chapuza. El basic nacio con la intencion de
enseñar a programar y no para ser un lengauje en el que hacer
aplicaciones.
--
AX, BX, CX ... Assembler o Citroen?
Javier Lasheras
samsagaz escribió:
> Una cosa sobre los lenguajes que yo veo muy clara, es que el visual
> basic es una peazo de chapuza. El basic nacio con la intencion de
> enseñar a programar y no para ser un lengauje en el que hacer
> aplicaciones.
> --
> AX, BX, CX ... Assembler o Citroen?
si te digo la verdad a mi el visual basic me da asco, pero he visto currar
aqui a mi compañero de curro y me he quedado flipado. Es una puta mierda, para
que engañarnos pero se debugea que es una maravilla.
El visual basic es para lo que es, que cualquiera pueda hacer un programilla,
y si no es muy habil y tiene que usar el metodo de ensayo y errror no pierde
mucho tiempo.
Asi de lenguajes programo en java porque es facilillo y multiplataforma.
Cuando necesito codigo nativo en c++ si me conviene y en c si es simple o
quiero que me entiendan (el que sabe c++ entiende c pero al contrario no es
tan seguro)
En definitiva, todos los lenguajes tienen sus cosas utiles y sus cagadas, pero
una casa si que tengo clara: que un lenguaje que solo sirve para enseñar no
vale para nada y tiende a desaparecer. (aunque no opinen lo mismo en algunas
universidades que siguen empeñadas en enseñar chorradas)
Saludos
Javi
Salvador Petit Martí
> Hola a Todos!
> "Salvador Petit Martí" wrote:
>> > Bueno, quizá hablo por hablar, pero ¿C++ tiene "cuestiones orientadas a
>> > programación distribuida, invocación remota, objetos compartidos"? Si
>> > me hablas de CORBA, sí, pero C++?
>>
>> Para ese tipo de cosas esta el Objective-C, que nadie usa, por cierto.
>>
> Supongo que estaré equivocado, pero creo que Objective-C no ofrece
> facilidades de programación distribuída de por si.
Cierto. Tienes razón con eso. La sintaxis del lenguaje no ofrece eso
especificamente (la sintaxis es extremadamente simple, por cierto).
Pero esto es como el java, no hay nada en la sintaxis del lenguaje, pero
esta todo en librerias (rmi, p.ej). El framework *Step viene a ser como
la libreria estándard de Objective-C. Yo me he fijado más en el
lenguaje, pero debe ser muy simple importar un interfaz remoto en un
proxy local pq. todo eso se puede hacer dinámicamente con el lenguaje.
> Cuando se utiliza dentro del framework NeXT/Open/GNUStep se ofrecen
> ciertos servicios adicionales, pero la última vez que le eché un vistazo
> a la especificación de OpenStep no recuerdo haber visto nada sobre
> objetos remotos.
> SI estoy equivocado agradecería cualquier referencia, me interesa mucho
> el tema
> Estoy contigo en que nadie lo usa y que es una verdadera pena, es
> realmente potente.
> Saludos
Joaquín Cuenca Abela
Drizzt <ter...@trajano.us.es> wrote:
> Joaquín Cuenca Abela <e98c...@my-deja.com> writes:
> > La licencia de X no tiene nada que ver con la QPL. Y la QPL tiene
> > un problema practico muy importante: no puedes mezclar codigo QPL
> > con codigo GPL, sin embargo si que puedes mezclar codigo con
licencia
> > X con codigo con licencia GPL.
>
> Tampoco puedes mezclar codigo BSD con codigo GPL y nadie pone el grito
> en el cielo. Aunque claro, se hace, pero no se reconoce (licencia del
GNU tiene una pagina donde explica la importancia de no incluir la
clausula de la licencia BSD sobre citar a los autores originales.
Aunque no se si es esto lo que entiendes por "poner el grito en el
cielo"...
> fips por ejemplo, GPL, y linkado al runtime de Borland, propietario),
> o cuando el DDD se compilaba con Motif.
O xemacs, no hace falta ir mas lejos. Pero que se haga no quiere decir
que sea legal o que no sea un problema.
Ademas no es tan comun como quieres dar a entender (sobre todo gracias
a lesstif). Y cosas como X (que mencionabas en tu anterior email) se
pueden enlazar sin problemas con (L)GPL.
> La QPL es una licencia opensource, al menos en los terminos de ESR.
Yo nunca he dicho lo contrario. Yo solo he dicho que no puede mezclarse
con codigo GPL y que esto presenta un problema para muchas personas.
> > Para muchas personas, este problema es tan importante que hace que
> > no puedan utilizar Qt (simplemente, hay *mucho* codigo GPL para
"copiar
> > y pegar" hay fuera :)
>
> Ya, por eso el KDE usa las Qt. Aunque empiezo a sospechar, que claro,
> siempres es "mas facil copiar" y no pagar un duro, que desarrollar
algo,
> que a fin de cuenta, es lo que significa tu ultima frase.
De que estas hablando? No he entendido ni una palabra.
Joaquín Cuenca Abela
"J.A. Gutierrez" <s...@daphne.cps.unizar.es> wrote:
> Joaquín Cuenca Abela <e98c...@my-deja.com> wrote:
> :>
> :> - los ficheros objetos no son portables, por definicion,
diferentes
> :> compilardores utilizan diferentes "mangleados"
> :>
> :> - C++ se ha estandarizado muy recientemente, y aun hoy entre
> :> diferentes compiladores existen diferencias significativas que
> :> hacen que el mismo codigo compile en unos y falle en otros.
>
> : Francamente, esto es algo muy raro.
>
> no por mi experiencia, ni por la de la gente que conozco...
> Especialmente en cuanto se meten con templates.
El problema que mencionabas es relativo a las bibliotecas y no tiene
nada que ver con el lenguaje utilizado.
Y las templates no dan problemas (excepto las imbricadas, ahi estoy de
acuerdo).
>
> : #include <stdio.h>
> : #include <strings.h>
> : #include <stdlib.h>
>
> : int main (int argc, char *argv[])
> : {
> : char *tmp = strdup (argc > 1 ? (const char *) argv[1] : "");
> : printf ("%s\n", tmp);
> : free (tmp);
> : }
>
> : que compila (o deberia, no lo he probado :) en linux, pero que no lo
> : hace (o puede no hacerlo, tampoco lo he probado) en windows. Hay
>
> que no lo hace? me suena muy raro.
>
> (en todo caso, yo estaba pensando sobre todo en compatibilidad
> entre diferentes unix)
Mi argumento sigue siendo igual de valido. Cambia de un System V a
un BSD, intenta compilar y veras como empieza la fiesta...
>
> : cientos de peque~nas funciones que tienes disponibles con las
> : bibliotecas que acompa~nan a un compilador y que no te vienen con
>
> pero si que hay un minimo disponible en todas partes.
minimo completamente insuficiente. De hay que existan tantas
extensiones para diferentes compiladores/plataformas.
>
> : otro compilador (otro peque~no ejemplo que me viene a la mente,
> : stricmp de VC y strcasecmp de GNU que hacen exactamente lo mismo,
pero
> : claro, si usas stricmp con gcc o strcasecmp con VC estas jodido).
>
> es que no hay que viciarse usando esas funciones "extra" (o
> al menos, incluir una implementacion alternativa)
Cual es la gracia entonces de utilizar las extensiones? Y si no las
usas estas jodido porque con las funciones de biblioteca del ANSI C
te faltan montones de cosas de uso cotidiano. Mira glib para ver un
ejemplo.
>
> : La segunda parte de tu parrafo ("cualquier codigo al azar hecho en
> : C...") simplemente no es cierto. C++ "correcto" es igual de
portable
> : que C "correcto".
>
> Bueno, sustituyendo codigo C++ al azar por "aplicaciones
> de dominio publico escritas en C++". Por lo general, siempre
> me dan muchos mas problemas para compilarlas que las escritas
> en C
Lo dicho, el problema que citabas es el de problemas con bibliotecas.
Intenta compilar una biblioteca programada para ncurses5.x... si tienes
la desgracia de tener en tu sistema ncurses4.x estas jodido. Lo mismo
con gtk+, gnome, etc...
Jesús M. NAVARRO
"Salvador Petit Martí" wrote:
>
> Jesús M. NAVARRO <jesus_...@geocities.com> wrote:
>
> > Bueno, quizá hablo por hablar, pero ¿C++ tiene "cuestiones orientadas a
> > programación distribuida, invocación remota, objetos compartidos"? Si
> > me hablas de CORBA, sí, pero C++?
>
> Para ese tipo de cosas esta el Objective-C, que nadie usa, por cierto.
>
¿Nadie? Nadie no, una pequeña aldea todavía resiste...
Aún quedan por ahí pizzaboxes (la viejas NeXt) con gente usando su
compilador ObjectiveC, que lo se.
J.A. Gutierrez
:> (en todo caso, yo estaba pensando sobre todo en compatibilidad
:> entre diferentes unix)
: Mi argumento sigue siendo igual de valido. Cambia de un System V a
: un BSD, intenta compilar y veras como empieza la fiesta...
dejando aparte de que casi todos los unix incluyen capas
de compatibilidad con ambos sistemas, me parece que nos
estamos alejando del tema.
Lo unico que queria destacar yo al respecto es lo de que las
librerias de C++ se han estabilizado hace relativamente poco,
y es muy facil encontrar codigo hecho para usar alguna que no
tienes. No es el caso en C
Vale, no tiene nada que ver con el lenguaje en si, sino con
la realidad practica de su utilizacion.
:> : otro compilador (otro peque~no ejemplo que me viene a la mente,
:> : stricmp de VC y strcasecmp de GNU que hacen exactamente lo mismo,
: pero
:> : claro, si usas stricmp con gcc o strcasecmp con VC estas jodido).
:>
:> es que no hay que viciarse usando esas funciones "extra" (o
:> al menos, incluir una implementacion alternativa)
: Cual es la gracia entonces de utilizar las extensiones? Y si no las
pues o bien ninguna, o bien el confiar que en caso de tenerlas
van a estar mas optimizadas que las que incluyas.
: usas estas jodido porque con las funciones de biblioteca del ANSI C
: te faltan montones de cosas de uso cotidiano. Mira glib para ver un
: ejemplo.
no, si ya te entiendo.
Pero aun con eso, puedes encontrar miles de programas hechos
en C que no dependen de tener ninguna libreria instalada en
concreto.
Drizzt
>
>No es tan chorrada: Permite que puedas usarlo desde C, Pascal, Fortran,
>, etc, además de en lenguajes orientados a objetos. Reconozco que el API
>Gtk_desde_C_apesta(), pero tampoco pueden hacer mucho más (sin complicar
>mucho la cosa), sin embargo desde Python, por ejemplo, tiene una
>orientación a objetos de lo más elegante.
QT al menos desde Python, Perl y C :) ( aunque claro, esto último, pues no se,
Roberto Alsina, contertulio en otros grupos fue el que hizo el port).
Un saludo
Drizzt
PD: A GTK la faltaba (ahora ya no lo se, pero hace un año que fue cuando
estuve evaluando toolkits, un buena libreria de clases en C++)
Drizzt
>> Si, pero espero que esté más evolucionada que la última vez que la vi. De
>> hecho, una de las cosas que a mi me ha hecho siempre descartar GTK ha sido
>> esa: la falta de una interfaz C++ en condiciones.
>
> Prueba la última versión de Gtk--. He leído que, por fin, resulta
> poderosa y estable.
Me da miedo mirarlo, sobre todo visto, lo que vi en su época. De todas
mameras, cuando pueda las miraré. De momento, sigo con QT por ser lo que más
me ha convencido.
Un saludo
Drizzt
Drizzt
>> Bueno, quizá hablo por hablar, pero ¿C++ tiene "cuestiones orientadas a
>> programación distribuida, invocación remota, objetos compartidos"? Si
>> me hablas de CORBA, sí, pero C++?
>
>Para ese tipo de cosas esta el Objective-C, que nadie usa, por cierto.
Otra de las grandes idea de NeXT y su gente ( ahora en Apple). Habia que ver
NeXTStep cuando salio, barria todo lo barrible :).
Xavier Montero
> Una cosa sobre los lenguajes que yo veo muy clara, es que el visual
> basic es una peazo de chapuza. El basic nacio con la intencion de
> enseñar a programar y no para ser un lengauje en el que hacer
> aplicaciones.
Sí, pero si el Linux hubiera algo tan "inmediato de usar" (y aunque se
que vais a responder "Glade!", no es lo mismo), por cutre que sea
(y no es orientado a objetos de los buenos puesto que ni herencias
ni virtuales ni nada) permite hacer "proyectillos cutres" en dos
(a veces tres) segundos.
Para hacerme un "crono visual" o un "editor de cubos de rubick"
o un "[póngase cualquier chorrada]" está claro que un entorno
RAD, por cutre que sea, si cumple con lo de RAD (Rapid App Devel)
ya sirve (me remito a lo que decía Iñaki, que cada lenguaje, a
su situación).
Aunque dije que C++ me gustaba 1024 veces más que C (y vaya lo que
se ha desencadenado), continúo manteniéndolo porque encuentro
"necesario" programar en clases siempre (por pequeño que sea mi
programa; bueno si es un Hello world me lo pensaría). Otra
persona puede no necesitarlo.
Y en ese sentido, VB me ofrece programar en clases y de forma
inmediata (muchos de los proyectos de mie mpresa se programan
en VB y si a un cliente le das un programa terminado en un mes
en vez de dos, para él mucho mejor). Un ejemplo: Para Friskies
España llevamos haciendo un programa desde el Mayo del 1999
(más de un año), que van "moldeando" a su gusto. Está hecho
en VB y nos va perfectamente, por el tema de la velocidad
(suelen pedir modificaciones del tipo: "Esta mañana, en la
plataforma de distribución de no-se-donde ha habido unos
problemas, quiero un gráfico 3D en pantalla que muestre los
datos de tal y tal y tal ficheros interrelacionados para
esta tarde puesto que debo analizar los resultados para mañana
informar a los directivos"
Dirás lo que quieras pero en VB incrusto un ActiveX de gráfico
3D y por programa le lleno las propiedades de los datos. Me centro
en programar lo que debo y no reutilizo código que otros (en este
caso M$) ya han programado para que se pueda usar.
Así que precisamente pienso que (aunque cutre, que no lo niego)
pienso que parte del éxito de windows está en el Visual Basic.
Es más, pienso que aplicaciones como el calcultaor y el Notepad
seguro que son VB y pienso que hasta quizás ellos mismos
crearon el VB inicialmente no para venderlo sino para crear
las interfaces de los wizards y cosas de esas.
Si Linux tuviera un Glade con un IDE (donde programes de forma
integrada) y se pudiera debugar y tracear (hacer paso a paso
modificar en run-time las variables del programa, etc)
(vamos, a lo action replay), sería una PASADA porque mucha gente
que NO es programador (porque no conocen ni librerias ni nada)
pero algo saben de Basic harían miles de utilidades que
enriquecerían la popularidad de Linux/Unix.
> --
> AX, BX, CX ... Assembler o Citroen?
Citroen. Un buen assembler, si no es A0-A7/D0-D7 no es lo mismo.
Chao!
Xavi
PD: Me podéis machacar, si queréis.
PD2: Pero a menos que me deis una razón convincente, no voy
a cambiar fácilmente de opinión.
--
--------------------------------------------------------------
Chao!
Xavi
http://www.dsitelecom.com/ (Digital Sound Items)
--------------------------------------------------------------
Joaquín Cuenca Abela
Xavier Montero <xmon...@dsitelecom.com> wrote:
> samsagaz escribió:
> > Una cosa sobre los lenguajes que yo veo muy clara, es que el visual
> > basic es una peazo de chapuza. El basic nacio con la intencion de
> > enseñar a programar y no para ser un lengauje en el que hacer
> > aplicaciones.
>
> Sí, pero si el Linux hubiera algo tan "inmediato de usar" (y aunque se
> que vais a responder "Glade!", no es lo mismo), por cutre que sea
> (y no es orientado a objetos de los buenos puesto que ni herencias
> ni virtuales ni nada) permite hacer "proyectillos cutres" en dos
Esto es mentira. El modelo de objetos de gtk+ permite herencia y
funciones virtuales.
> (a veces tres) segundos.
>
> Para hacerme un "crono visual" o un "editor de cubos de rubick"
> o un "[póngase cualquier chorrada]" está claro que un entorno
> RAD, por cutre que sea, si cumple con lo de RAD (Rapid App Devel)
> ya sirve (me remito a lo que decía Iñaki, que cada lenguaje, a
> su situación).
>
> Aunque dije que C++ me gustaba 1024 veces más que C (y vaya lo que
> se ha desencadenado), continúo manteniéndolo porque encuentro
> "necesario" programar en clases siempre (por pequeño que sea mi
> programa; bueno si es un Hello world me lo pensaría). Otra
> persona puede no necesitarlo.
Ni gtk+ ni glade te impiden programar con clases. Gnumeric, Dia,
Abiword y todos los programas grandes de gnome se han programado
con "clases".
> Dirás lo que quieras pero en VB incrusto un ActiveX de gráfico
> 3D y por programa le lleno las propiedades de los datos. Me centro
> en programar lo que debo y no reutilizo código que otros (en este
> caso M$) ya han programado para que se pueda usar.
Y esto es algo que le falta a gnome/kde. Esperemos que la version
2.0 de cada uno de estos entornos arregle este problema.
> Así que precisamente pienso que (aunque cutre, que no lo niego)
> pienso que parte del éxito de windows está en el Visual Basic.
Windows triunfo mucho antes de que Visual Basic existiese
> Si Linux tuviera un Glade con un IDE (donde programes de forma
> integrada) y se pudiera debugar y tracear (hacer paso a paso
> modificar en run-time las variables del programa, etc)
> (vamos, a lo action replay), sería una PASADA porque mucha gente
> que NO es programador (porque no conocen ni librerias ni nada)
> pero algo saben de Basic harían miles de utilidades que
> enriquecerían la popularidad de Linux/Unix.
Tambien de acuerdo. Es uno de los problemas mas acuciantes de el
entorno de desarrollo de GNOME.
KDE esta mucho mejor en este campo. Mira kdeveloper
> PD2: Pero a menos que me deis una razón convincente, no voy
> a cambiar fácilmente de opinión.
Como todos, me parece a mi :)
Xavier Montero
en el párrafo:
Xavier Montero escribió:
>
> Dirás lo que quieras pero en VB incrusto un ActiveX de gráfico
> 3D y por programa le lleno las propiedades de los datos. Me centro
> en programar lo que debo y no reutilizo código que otros (en este
> caso M$) ya han programado para que se pueda usar.
Donde dije: "no reutilizo" debí decir "reutilizo".
Xavier Montero
> > que vais a responder "Glade!", no es lo mismo), por cutre que sea
> > (y no es orientado a objetos de los buenos puesto que ni herencias
> > ni virtuales ni nada) permite hacer "proyectillos cutres" en dos
>
> Esto es mentira. El modelo de objetos de gtk+ permite herencia y
> funciones virtuales.
Me refiero a que VB NO ES OO porque VB no soporta herencia ni
virtuales. Me refiero a que VB es cutre y GTK no lo es, pero que
en VB pueden programar muchas más personas que en GTK, y más
rápidamente.
(que no se me entienda mal, que no quiero machacar GTK ni nada,
sólo quiero decir que VB, aunque de M$, permite hacer muchas
cosas muy rápidamente y con muy bajas probabilidades de cuelgue
puesto que, por poner un ejemplo, no hay punteros y no puedes
escribir en zonas de memoria no-tuyas, entre otros).
> > Aunque dije que C++ me gustaba 1024 veces más que C (y vaya lo que
> > se ha desencadenado), continúo manteniéndolo porque encuentro
> > "necesario" programar en clases siempre (por pequeño que sea mi
> > programa; bueno si es un Hello world me lo pensaría). Otra
> > persona puede no necesitarlo.
>
> Ni gtk+ ni glade te impiden programar con clases. Gnumeric, Dia,
> Abiword y todos los programas grandes de gnome se han programado
> con "clases".
Si no digo que no, jolín. Que GTK puede programar en clases y MUCHO
MEJORES que las de VB, pero que en VB tardas menos en hacer cosas
simples, y sobre todo, tardas menos en debugarlas por poder hacer
traces, watches y steps muy, pero que muy cómodamente (vamos, sólo
con picar F8-F8-F8-F8... y vas viendo run-time cómo tu programa
va cambiadno de estado.
Además tienes facilidades que pueden parecer chorras, pero que cuando
las pruebas te facilitan mucho la vida, como que cuando has escrito
el proto de una función, en el momento que estás escribiendo
más códig y vas a llamar a esa función, un analizador sintáctico en
tiempo real detecta que vas a hacerlo y te saca un tip con el proto
para que no tengas que andar scrolleando arriba y abajo, o como que
cuando tienes un enumerado (por ejemplo, imagina en una clase tuya
que encapsula un servidor y puedes tener un estado del tipo
"CONNECTED", "CONNECTING", "NOT CONNECTED", un enum mejor que un DEFINE
y el analizador sintáctico cuando escribes
miestado =
al escribir el símbolo = te saca un desplegable con los estados posibles
puesto que sólo uno de ésos vas a poder asignar (salvo que asignes
un cast u otra variable), pero puedes ignorar el desplegable y
continuar tecleando.
No sé, son muchas ayuditas chorras, si quieres, pero que habiendome
peleado muchos años con asembler 8x86, assembler 68K, C, C++, VB
y algún que otro, creo que de todos los lenguajes y de todos los
entornos de programación que he probado es el permite mayor
rapidez y sencillez para hacer cosas (repito que simples).
> > Dirás lo que quieras pero en VB incrusto un ActiveX de gráfico
> > 3D y por programa le lleno las propiedades de los datos. Me centro
> > en programar lo que debo y no reutilizo código que otros (en este
> > caso M$) ya han programado para que se pueda usar.
>
> Y esto es algo que le falta a gnome/kde. Esperemos que la version
> 2.0 de cada uno de estos entornos arregle este problema.
Una cosa ideal sería un entorno en el que tengas Wizards (con los
que mucha gente suele contrariar). Pero sería ideal iniciar el
Glade o culaquiera de éstos y que te diga:
"¿Qué deseas? Un ejecutable estándard, una librería inámica, o un
applet de Gnome"
Selecciones un applet y te pongas un par de labels y llames a time()
y te hagas tu relojito chulo en cinco minutos. Éso es lo que falta.
Drizzt
>
>Esto es mentira. El modelo de objetos de gtk+ permite herencia y
>funciones virtuales.
Y una leche. Gtk+ es C puro y duro. Por mucho que se quiera "ocultar" a base
de punteros, las GTK son C.
>Ni gtk+ ni glade te impiden programar con clases. Gnumeric, Dia,
>Abiword y todos los programas grandes de gnome se han programado
>con "clases".
No, se han programado IMITANDO clases con C. No se puede comprar un lenguaje
orientado a objetos de verdad ( C++, Smalltalk, Effiel, ADA), con C. C NO
TIENE CLASES. Por mucho que intentes imitarlos con structs y punteros a
funciones. Siempre pierdes un parámetro haciendo referencia al objeto.
Drizzt
>> AX, BX, CX ... Assembler o Citroen?
>Citroen. Un buen assembler, si no es A0-A7/D0-D7 no es lo mismo.
Vaya, código 680x0 :).
Bueno, con respecto a lo que comentas si, un RAD "de verdad" no un simple
diseñador de entornos hace falta en Linux. Que incluya conexiones ODBC para
bases de datos, y controles que permitan esa conexión con la bases de datos (
que no sé como la gente que ha hecho Glade y demás no se ha dado cuenta de eso
pero bueno).
De todas maneras es lo que hay. Mucho del soft que hay en Linux se hace por
esfuerzo voluntario, y si los programadores que lo hacen consideran que no son
necesario pues ya se sabe.
Otro detalle que me viene a la cabeza. Es probable que Borland porte su Delphi
a linux. eso sería desde mi punto de vista algo más que interesante :).
Jose Antonio
<xmon...@dsitelecom.com> escribió:
> Fe de erratas:
>
> en el párrafo:
>
> Xavier Montero escribió:
>>
>> 3D y por programa le lleno las propiedades de los datos. Me centro
>> en programar lo que debo y no reutilizo código que otros (en este caso
>> M$) ya han programado para que se pueda usar.
>
Supongo que el grupo está al corriente de Gnome-Basic
la dirección creo que es ww.gnome.org/gb o /gnome-basic ??
La idea es desarrollar un lenguaje BASIC 100% compatible con Visual-Basic.
Se está aplicando para gnumeric (el campo de pruebas de las tecnologías de
GNOME).
Actualmente está en estado pre-alpha, si se puede llamar así.
jose_antonio
(A)
Salvador Petit Martí
deberia llebar el Python con Qt (PyQt) que directamente C++/Qt. Me
parece más comparable, aunque no lo he usado.
Joaquín Cuenca Abela
Xavier Montero <xmon...@dsitelecom.com> wrote:
> > > Sí, pero si el Linux hubiera algo tan "inmediato de usar" (y
aunque se
> > > que vais a responder "Glade!", no es lo mismo), por cutre que sea
> > > (y no es orientado a objetos de los buenos puesto que ni herencias
> > > ni virtuales ni nada) permite hacer "proyectillos cutres" en dos
> >
> > funciones virtuales.
>
> virtuales. Me refiero a que VB es cutre y GTK no lo es, pero que
> en VB pueden programar muchas más personas que en GTK, y más
> rápidamente.
Ops, perdona, lo habia entendido al contrario. Ahora ya esta todo
claro.
> Si no digo que no, jolín. Que GTK puede programar en clases y MUCHO
> MEJORES que las de VB, pero que en VB tardas menos en hacer cosas
> simples, y sobre todo, tardas menos en debugarlas por poder hacer
[cortado]
> rapidez y sencillez para hacer cosas (repito que simples).
Totalmente de acuerdo. Un entorno de esa calidad para Linux es mas
que deseable.
> Una cosa ideal sería un entorno en el que tengas Wizards (con los
> que mucha gente suele contrariar). Pero sería ideal iniciar el
> Glade o culaquiera de éstos y que te diga:
> "¿Qué deseas? Un ejecutable estándard, una librería inámica, o un
> applet de Gnome"
Creo que kdeveloper lo tiene. Hechale un vistazo. (desgraciadamente
en GNOME no hay ningun entorno que este a su altura...).
samsagaz
Y porque no nos curramos uno?
--
Si no puedes hacerlo bueno, hazlo bonito (Bill Gates)
Joaquín Cuenca Abela
samsagaz <sams...@menta.net> wrote:
> "Joaquín Cuenca Abela" escribió:
> >
> > Creo que kdeveloper lo tiene. Hechale un vistazo.
(desgraciadamente
> > en GNOME no hay ningun entorno que este a su altura...).
>
En mi caso, por dos razones:
1) No tengo tiempo.
2) No tengo tiempo.
Drizzt
> La idea es desarrollar un lenguaje BASIC 100% compatible con Visual-Basic.
> Se está aplicando para gnumeric (el campo de pruebas de las tecnologías de
> GNOME).
>
?Un lenguaje COMPATIBLE con VB. Que bien, ahora los virus de VB tb corren
en Linux. Compatibilidad total ....
Juanjo Álvarez
en fecha: 05 Jun 2000 19:04:22 +0200
Me pareje una gilipollez que haga un el lenguaje BASIC de Visual Basic
para Linux.
En primer lugar porque es una mierda de lenguaje.
En segundo lugar: tendría sentido si pudieras coger los .bas de un
programa visual basic de windows y te funcionaran en Linux,
pero es que no van a funcionar, porque no están los ActiveX
(que es el verdadero potencial de Visual Basic).
Para mi Visual Basic son tres partes bien diferenciadas:
1) El lenguaje.
2) El entorno.
3) Los ActiveX.
Han ido a copiar la peor y la más inútil.
Juanjo Álvarez
en fecha: 5 Jun 2000 08:26:14 GMT
|A mi modo de ver, quizás la competencia con VB en el caso de KDE, la
|deberia llebar el Python con Qt (PyQt) que directamente C++/Qt. Me
|parece más comparable, aunque no lo he usado.
Hay algunas diferencias notables:
1) No hay un entorno para Python-Qt como el de Visual Basic
2) Python, como lenguaje, es infinitamente mejor que el Basic de VB, y
probablemente igual de fácil de aprender.
3) Python es más lento que VB compilado, si bien para muchas
aplicaciones (del estilo de las que se suelen hacer en VB) no ibas a
notar la diferencia.
4) No hay una colección de ActiveX (o equivalente) para Python QT como
la que puede haber para VB. Esto puede cambiar con lo de los componentes
por Bonobo, aunque en este caso hablamos de Python-Gnome.
Pero sí se arreglaran los puntos 1 y 4 (el 3 no es en realidad tan
crítico para la mayoría de aplicaciones), podrían cambiar muchas cosas.
--
http://www.clickeas.com/linux
Antonio Larrosa
>
> Raúl (Ridiculum) dijo sobre Re: Qt vs GTK,
> en fecha: 31 May 2000 16:04:43 GMT
>
> |El 29 May 2000 01:21:15 GMT, Drizzt escribió:
> |>QT es C++ ( aunque se puede usar, en otros lenguajes). Es desde su versión 2.x
> |>open source. Para mi son mucho más completas y fáciles de usar que GTK. De
> |>hecho, cuando ni GTK existia la libreria era una maravilla.
> |>
> |>Un saludo
> |>Drizzt
> | Tienen las QT enlaces a otros lenguajes que no sea C++, al estilo
> | de GTK??? Esta entre esos enlaces el C??
>
> Al menos a Python sí que tiene, y creo que a Perl también (y
> probablemente a algún que otro lenguaje OO).
>
> | Es que a mi el tema de C++ me sobrepasa,
>
> Le sobrepasa a cualquiera. Demasiado espeso. Prefiero el Java (el Gcj
> compila a código nativo), o Python si no se necesita velocidad extrema.
>
> |pero tengo en mente un
> | programa (simulador de enlaces de fibra optica) que necesita de un
> | GUI y me interesa saber como está el tema ese, porque me habia
> | decidido por GTK
>
> Hay un tutorial de Qt 2.0 en la página de Larrosa (¿era así?), busca en
> www.ldp.org y lo deberías encontrar.
Muchas gracias por la publicidad :-)
El enlace es :
http://www.arrakis.es/~rlarrosa/tutorial.html
Aunque es mas un tutorial de KDE que de Qt, en general, si quereis
ver otros tutoriales de KDE, echadle un vistazo a :
http://developer.kde.org/documentation/tutorials/index.html
especialmente (y ya que se ha hablado del tema del ActiveX), creo
que os puede resultar interesante el tutorial de KParts
(con nombre "Embedded Components")
Si quereis un tutorial de Qt, viene en la documentación del Qt
dentro del mismo paquete.
Realmente, Qt es _muy_ facil de usar, sólo teneis que echarle un
vistazo. El sistema de slots/signals desarrollado por los Trolls
es _intuitivo_, que es una de las cosas mas importantes a la hora
de desarrollar.
Si os fijais en cualquier interfaz de usuario, ¿qué es lo que
veis? Botones, menús, barras de estado, lineas de entrada,
etc. Cada elemento (widget) con sus propiedades, posición,
acciones, etc. Son precisamente OBJETOS ! Por lo cual (y siempre
en mi opinión) lo lógico es usar un lenguaje orientado a objetos.
Un saludo,
--
Antonio Larrosa Jimenez
Student of Mathematics
lar...@kde.org ant...@arrakis.es
http://www.arrakis.es/~rlarrosa/index.html
Klein bottles for rent -- inquire within
Jose Luis
>
> Jose> Me parece muy bien que te guste Pascal e incluso que
> Jose> utilices una version orientada a objetos ... habria que ver
> Jose> hasta que punto es orientado a objetos ...
>
> Tan orientado a objetos como pueda ser C++ o SmallTalk. Tienes clases,
> herencia, polimorfismo, clases virtuales, en fin, todo lo que se
> considera imprescindible en un lenguaje orientado a objeto. Por lo que
> veo no conoces demasiado de el ;-)
".. habria que ver hasta que punto .." esta claro que esto quiere decir que
yo no lo conozco, y que mi opinion va a ir encaminada en ese sentido ...
evidentemente no conozco demasiado de el ... lo cual no quiere decir que ya
por eso desconozco todo lo relevante a Orientacion a Objetos ... si algo he
aprendido en mis años de sufrimiento academico es que no quiere que me
enseñen a utilizar un herramienta, lenguaje o instrumento, sino que quiere
conocer la metodologia.
>
> Jose> No me voy a poner ahora en plan defensor de C++. Primero, me
> Jose> parecio una locura que alguien diga que C es mejor que
> Jose> C++.
>
> Te voy a decir que C _SI_ es mejor que C++ ... en ciertos casos. Y C++
> es mejor... en cierto casos. Y Delphy o Java o RPG o COBOL son mejores
> que C++/C... si, lo has adivinado, en ciertos casos. No hay _ningun_
> lenguaje que sea *el mejor*. Es el mas adecuado en mas o menos
> situaciones, pero nunca en todas ellas. De esto estoy bien seguro. Si
> el tipo de aplicaciones al que te dedicas habitualmente dicta que C++
> es la eleccion mas logica, estupendo. Pero no todo el mundo tiene la
> misma problematica y por tanto no todo el mundo tiene porque
> considerar el mismo lenguaje el "mas superior".
>
>
Mira, ademas me estas dando la razon ... yo no voy a ponerme a defender un
lenguaje ni una metodologia ni nada .. simplemente conteste a alguien que
dijo rotundamente que C era mas portable y rapido y le expuse que hay otras
cuestiones que pueden ser mas importantes a la hora de elegir un lenguaje
... por favor ... por supuesto que no hay nada mejor que lo que es apropiado
o esta pensado para ello, no te preoupes, hasta eso llego. Tranquilo, que no
he empezado en la informatica desarrollando ERP's para particulares.
> Jose> .... ya me contaras si tambien tiene cuestiones orientadas a
> Jose> programacion distribuida, llamada a metodos remotos,
> Jose> comparticion de objetos, ....
>
> Esto, que yo sepa, no es parte del lenguaje C++. Esta (como mucho) en
> las bibliotecas de funciones adicionales. Y si hablamos de CORB A (por
> poner un ejemplo que se ajuste a tus "requisitos") recuerdo que hay
> interfaces para usarlo desde lenguajes como Delphi Pascal.
>
> Saludos. Iñaki.
>
Perdona que te diga, pero no se llaman interfaces CORBA, se llaman ORB's
CORBA (Object Request Browser) ... pero ya veo que no conoces mucho del tema
... ;-). De todas formas no voy a hacer a salirme por la tangente ... este
no era la cuestion ... ¿a que no por este error debido a desconocimiento
particular de CORBA dejas de tener razon en el resto de cuestiones?
Saludos, y de todas formas, tampoco estoy pretendiendo demostrar que tengo
razon ... mi experiencia me dice que la portabilidad no la voy a conseguir
con C ni C++ sino con otro lenguaje que es en el que estoy desarrollando
actualmente, por ejemplo. Es decir, lo de C o C++ pretende ser un opinion,
comprendo que no estes de acuerdo, e incluso puedo comprender que no tengo
razon... se han dado justificaciones y apoyos tanto a uno como a otro por
parte de todo el mundo.
Alla cada cual ....
Salvador Petit Martí
> Salvador Petit Martí dijo sobre Re: [OFF-TOPIC] El mejor lenguaje (Era-->Re: Qt vs GTK),
> en fecha: 5 Jun 2000 08:26:14 GMT
> |A mi modo de ver, quizás la competencia con VB en el caso de KDE, la
> |deberia llebar el Python con Qt (PyQt) que directamente C++/Qt. Me
> |parece más comparable, aunque no lo he usado.
> Hay algunas diferencias notables:
> 1) No hay un entorno para Python-Qt como el de Visual Basic
Hmmm No tengo claro si con el KDevelop se puede usar Python. Yo pensaba
que si. Cierto que no es el entorno del VB pero se asemeja mas que
editar a pelo.
> 2) Python, como lenguaje, es infinitamente mejor que el Basic de VB, y
> probablemente igual de fácil de aprender.
Eso no es malo :P. Aunque eso de los objetos es un poco complicado ¿no? }-)
> 3) Python es más lento que VB compilado, si bien para muchas
> aplicaciones (del estilo de las que se suelen hacer en VB) no ibas a
> notar la diferencia.
¿VB no se precompila e interpreta? ¿Es posible compilarlo a nivel
máquina? ¿Perl y python no se precompilan e interpretan tb.? ¿Se puede
compilar python a nivel máquina o traducirlo a C/C++? ¿Estoy haciendo
demasiadas preguntas? ¿Parece que me quiero enterar de cosas sin
investigar por mi cuenta por el puñetero interes? ¿?¿¿??¿¿¿???
> 4) No hay una colección de ActiveX (o equivalente) para Python QT como
> la que puede haber para VB. Esto puede cambiar con lo de los componentes
> por Bonobo, aunque en este caso hablamos de Python-Gnome.
http://www.river-bank.demon.co.uk/software/
Quiere soportar los componentes de KDE2, dale más tiempo. Por cierto he
comentado que KDE2 tiene componentes y es un flipe?. Estoy realmente
emocionado con el...
> Pero sí se arreglaran los puntos 1 y 4 (el 3 no es en realidad tan
> crítico para la mayoría de aplicaciones), podrían cambiar muchas cosas.
> --
> http://www.clickeas.com/linux
Santiago Romero
>A mi modo de ver, quizás la competencia con VB en el caso de KDE, la
>deberia llebar el Python con Qt (PyQt) que directamente C++/Qt. Me
>parece más comparable, aunque no lo he usado.
Yo creo que la pregunta es...
¿Cuando salía C++ Builder para Linux? ¿No salia este verano?
Sera la salvacion de Linux, y yo me fio de los señores de borland,
porque si saliera el VisualBasic ay que miedo, pero el Builder...
en fin.
salu2.
--
El Principio de la Memoria de Hurewitz: La probabilidad de que
recuerdes algo es inversamente proporcional a... uh... esto...
_-----------------------------------------------------_
| NoP / Compiler -- s.ro...@unix-shells.com |
|-------------------------------------------------------|
| POWERED BY - Linux RedHat 6.0 - Reg. User #74.821 |
| http://web.jet.es/s.romero |
~-----------------------------------------------------~
Raúl (Ridiculum)
>?Un lenguaje COMPATIBLE con VB. Que bien, ahora los virus de VB tb corren
>en Linux. Compatibilidad total ....
o de macros o como gaitas se llame eso, pero para Gnumeric y
Evolution. La cuestion era que se iba a ejecutar encapsulado en una
caja, de la misma forma que lo hace Java en un navegador.
Ojo, esto no exime para que no se puedan hacer perrerias, puesto
que las JVM han tenido errores, pero esperemos que esto funcione
mejor y piensen en la posibilidad de la rapida propagacion de los
"virus" esos.
--
Miembro del grupo LILO: htpp://www.airtel.net/hosting/a_hoz
Linux User 157744
Red Hat 6.0 (2.2.14)
rorQU...@retemail.es
r...@QUITALOingenierosmix.com
Juanjo Álvarez
|
|> |A mi modo de ver, quizás la competencia con VB en el caso de KDE, la
|> |deberia llebar el Python con Qt (PyQt) que directamente C++/Qt. Me
|> |parece más comparable, aunque no lo he usado.
|
|> Hay algunas diferencias notables:
|
|> 1) No hay un entorno para Python-Qt como el de Visual Basic
|
|Hmmm No tengo claro si con el KDevelop se puede usar Python. Yo pensaba
|que si. Cierto que no es el entorno del VB pero se asemeja mas que
|editar a pelo.
No se, pero sería una buena noticia ¿alguien puede confirmarlo?
|> 2) Python, como lenguaje, es infinitamente mejor que el Basic de VB, y
|> probablemente igual de fácil de aprender.
|
|Eso no es malo :P. Aunque eso de los objetos es un poco complicado ¿no? }-)
No he dicho que fuera algo negativo, solo una "diferencia notable".
|> 3) Python es más lento que VB compilado, si bien para muchas
|> aplicaciones (del estilo de las que se suelen hacer en VB) no ibas a
|> notar la diferencia.
|
|¿VB no se precompila e interpreta? ¿Es posible compilarlo a nivel
|máquina?
Creo que a partir de la 5.0 sí.
|¿Perl y python no se precompilan e interpretan tb.?
No. Se pasan a un bytecode, que en el caso de Python (de momento) no
acelera la ejecución, sólo la carga del programa. El caso de Perl no lo conozco,
pero supongo que será similar.
|¿Se puede
|compilar python a nivel máquina o traducirlo a C/C++?
Hay un traductor de Python a C y un "empaquetador" de aplicaciones.
El traductor no funciona siempre, y sólo vale para módulos pequeños y
sencillos (por ejemplo, módulos de cálculo numérico), te genera una
librería dinámica (.so), que después siempre tendrás que cargar en un
programa Python.
El empaquetador lo único que te hace es crearte un ejecutable gigantesco
que incluye el intérprete y el bytecode python. No ganas en velocidad,
pero si en facilidad de distribución, dado que el usuario no necesitará
tener python instalado, aunque para el que lo tenga es una p*utada, por
lo que no suelen distribuirse los programas.
|> 4) No hay una colección de ActiveX (o equivalente) para Python QT como
|> la que puede haber para VB. Esto puede cambiar con lo de los componentes
|> por Bonobo, aunque en este caso hablamos de Python-Gnome.
|
|http://www.river-bank.demon.co.uk/software/
|
|Quiere soportar los componentes de KDE2, dale más tiempo. Por cierto he
|comentado que KDE2 tiene componentes y es un flipe?. Estoy realmente
|emocionado con el...
A ver si le doy un vistazo al tutorial de A. Larrosa, pero primero tengo
que acabar los exámenes, luego aprender (bien) C++, luego acabar el
tutorial de las Qt...
Suena bien eso de los componentes.
--
Los programadores de verdad hacen 'copy con program.exe'
-- PC Users. La mejor revista de computación del mundo.
http://www.clickeas.com/linux
DaVinci
> Bueno, con respecto a lo que comentas si, un RAD "de verdad" no un
> simple diseñador de entornos hace falta en Linux. Que incluya
> conexiones ODBC para bases de datos, y controles que permitan esa
> conexión con la bases de datos ( que no sé como la gente que ha
> hecho Glade y demás no se ha dado cuenta de eso pero bueno).
Mira el fichero TODO de Glade y te llevarás una sorpresa.
¿Hay que recordar quizá que está en su versión 0.5.9?...
Saludos.
--
DaVinci
Juanjo Álvarez
en fecha: 3 Jun 2000 23:17:35 GMT
|El día Sat, 03 Jun 2000 17:25:40 +0200, Xavier Montero decía:
|>> AX, BX, CX ... Assembler o Citroen?
|>Citroen. Un buen assembler, si no es A0-A7/D0-D7 no es lo mismo.
|
|Vaya, código 680x0 :).
|
|Bueno, con respecto a lo que comentas si, un RAD "de verdad" no un simple
|diseñador de entornos hace falta en Linux. Que incluya conexiones ODBC para
|bases de datos, y controles que permitan esa conexión con la bases de datos (
|que no sé como la gente que ha hecho Glade y demás no se ha dado cuenta de eso
|pero bueno).
Probablemente sí se han dado cuenta. Mira la versión actúal: 0.5. Es
decir, tienen el 50% de lo que querían (y es bastante), pero ni ellos
consideran que se acerque a una versión final. Tieeeempo.
|De todas maneras es lo que hay. Mucho del soft que hay en Linux se hace por
|esfuerzo voluntario, y si los programadores que lo hacen consideran que no son
|necesario pues ya se sabe.
Bueno, pero también hay listas de correo y demás donde se pueden sugerir
todas estas cosas.
|Otro detalle que me viene a la cabeza. Es probable que Borland porte su Delphi
|a linux. eso sería desde mi punto de vista algo más que interesante :).
"probable" no es la palabra, porque ya hay una versión alpha (proyecto
kylix o algo así). Hoy en Barrapunto hay una noticia de que ya hay
capturas.
--
El tiempo fabuloso que ha durado toda la semana se convierte en un tiempo fatal cuando ésta se acaba.
-- Ley del Clima.
http://www.clickeas.com/linux
Xavier Montero
>
> Salvador Petit Martí dijo
>
> |¿VB no se precompila e interpreta? ¿Es posible compilarlo a nivel
> |máquina?
>
> Creo que a partir de la 5.0 sí.
Sí seguro, en la 5, pero no 100% optimizado. En la 6 el mismo código
tira un promedio de un 20% más rápido porque hay estructuras
que sí las compilan directamente en assembler (esas mismas
estructuras en la 5 pasan por una especie de lenguaje
intermedio que acaba siendo assembler pero no tan optimizado).
Xavier Montero
>
> Yo creo que la pregunta es...
> ¿Cuando salía C++ Builder para Linux? ¿No salia este verano?
> Sera la salvacion de Linux, y yo me fio de los señores de borland,
> porque si saliera el VisualBasic ay que miedo, pero el Builder...
> en fin.
Pero el Builder ¿no será comercial si es de Borland? Al menos
los de M$ ponen la versión Profesional (la de 100.000 cucas) al
precio de 10.000 para quien presente una matrícula oficial
en cualquier escuela. Esa cantidad es muy razonable para quien
desee no fomentar la piratería. Se sabe el precio de Borland?
Si es de pago, pero es barato es un buen momento para fomentar
la compra de software legal para que los grandes softwareros
confíen cada vez más en Linux. Si por el contrario tal como
las empresas intenten entrar el el mercado la gente piratea
pará como en el Amiga. Entre todos (yo también me considero
culpable) matamos a los fabricantes de soft. Hace 10 años, más
de 1.400 disketes pirateados era una buena pasta que las
empresas perdían, multiplicado por todos los usuarios (que
levante la mano el que fuere amiguero y nunca copió nada
pirateao), era una ruina.
--
Xavier Montero
>
> Y porque no nos curramos uno?
de cada uno. Pero si integramos todos los tiempos de cada uno *
todos los interesados en aportar su granito de arena, quizás pueda
nacer algo respetable.
Yo ofrezco espacio para albergar el proyecto, en el host de mi
empresa (es que el hosting me da 350MB y no llego ni al 1%).
La base (creo) sería en primero hacer un muy buen brainstorming
antes de empezar ni una sola línea de código. Tras unas semanas
comantando qué y cómo podemos enumerar tareas "independientes"
como "un editor chulo", "un analizador sintáctico", un "compilador",
la enumeración de "wizards interesantes", creación de "controles",
estudios sobre "optimización de código", etc.
Eso es muchíííííííííí [x1000] íííísimo trabajo. Pero si no
lo empezamos no lo acabamos. Estoy de acuerdo en la iniciativa
que propones (quizás estamos demasiado "acostumbrados" a que
como en Linux todo aparece tarde o temprano, alguien lo
hará y yo lo usaré, y quizás también este sea el momento para
reunir los talentos que hay sueltos por ahí). No digo que
que necesariamente debamos "dedicar" x horas semanales. Es como
las news: A veces cada día, a veces una vez a la semana, a veces
incluso semanas o meses sin probar nada... Eran las news, o
era otra actividad también interesante (je, je)...
ÁNIMO A TODOS!
Quien quiera que levante el dedo (vamos, que conteste).
Sugiero que hagamos una "lista" oficial de gente interesada
"EN QUE SE DESARROLLE EL PROYECTO" distinta a otra lista oficial
de gente interesada "EN DESARROLLAR EL PROYECTO".
Sugiero también el nombre de "Linux-Basic" o de "Visual-Linux",
teniendo en cuenta que este último nos independiza del lenguaje
(mejor, no?)
Lo de Visual puede "sugerir" a windoze, pero si nos olvidemos
de prejudicios, nos estamos precisamente inspirando en sus
entornos integrados, no?
A MACHACAR A WINDOWS!!!
PD: Si haceis follo-ups, podría ser interesante que indicarais
claramente lo siguiente:
REAL_NAME:
NICK_NAME:
E_MAIL: youN...@lo.que.seaNOSPAM
INTERESADO EN: Que se desarrolle | Desarrollar | Testear | LoQueSea
Cuando esté terminado (allá por el 2010 o así, je, je) que tiemble
Windows. Ahora es lo único que le queda a windows que no tenga Linux.
Juanjo Álvarez
en fecha: Wed, 07 Jun 2000 03:38:28 +0200
|samsagaz escribió:
|>
|> Y porque no nos curramos uno?
|Bueno, yo creo que el problema puede estar en el timepo disponible
|de cada uno. Pero si integramos todos los tiempos de cada uno *
|todos los interesados en aportar su granito de arena, quizás pueda
|nacer algo respetable.
|
|Yo ofrezco espacio para albergar el proyecto, en el host de mi
|empresa (es que el hosting me da 350MB y no llego ni al 1%).
|
|La base (creo) sería en primero hacer un muy buen brainstorming
|antes de empezar ni una sola línea de código. Tras unas semanas
|comantando qué y cómo podemos enumerar tareas "independientes"
|como "un editor chulo", "un analizador sintáctico", un "compilador",
|la enumeración de "wizards interesantes", creación de "controles",
|estudios sobre "optimización de código", etc.
|
|Eso es muchíííííííííí [x1000] íííísimo trabajo. Pero si no
Exacto, por ello propongo, antes de que reinventemos la rueda, hacer un
análisis profundo de las herramientas de las que ya disponemos
(Kdeveloper, Glade y VDKBuilder), ver si podríamos mejorarlas para
incluir fácilmente componentes, tanto Bonobo como Kde2 (si no lo hacen
ya, ojo), y ver si podríamos hacer que además de C/C++ puedan utilizar
otros lenguajes fácilmente.
En el caso extremo de empezar de cero, hay muchísimas cosas que
podríamos aprovechar (el Kwrite, por ejemplo). No se, analicemos.
Propongo empezar por el Kdeveloper, ya que es (parece ser) el más
evolucionado.
Durante un tiempo cada uno podría poner sus impresiones sobre el mismo,
y como podría mejorarse. Al final podríamos hacer una votación informal
para ver si nos ponemos a mejorarlo o hacermos otra cosa.
Así que... todo el mundo a destripar (con sentido crítico) el
Kdeveloper 1.2.
--
La duración de un minuto depende de que lado del baño estés.
-- Ley de la Relatividad (Burke).
http://www.clickeas.com/linux
Salvador Petit Martí
> No, se han programado IMITANDO clases con C. No se puede comprar un lenguaje
> orientado a objetos de verdad ( C++, Smalltalk, Effiel, ADA), con C. C NO
> TIENE CLASES. Por mucho que intentes imitarlos con structs y punteros a
> funciones. Siempre pierdes un parámetro haciendo referencia al objeto.
Bueno. Al fin y al cabo asi se implementan los objetos en C++ ¿no?. El
primer parametro es siempre implicito y "this".
samsagaz
>
> samsagaz escribió:
> >
> > Y porque no nos curramos uno?
> Bueno, yo creo que el problema puede estar en el timepo disponible
> de cada uno. Pero si integramos todos los tiempos de cada uno *
> todos los interesados en aportar su granito de arena, quizás pueda
> nacer algo respetable.
>
> Yo ofrezco espacio para albergar el proyecto, en el host de mi
> empresa (es que el hosting me da 350MB y no llego ni al 1%).
>
> La base (creo) sería en primero hacer un muy buen brainstorming
> antes de empezar ni una sola línea de código. Tras unas semanas
> comantando qué y cómo podemos enumerar tareas "independientes"
> como "un editor chulo", "un analizador sintáctico", un "compilador",
> la enumeración de "wizards interesantes", creación de "controles",
> estudios sobre "optimización de código", etc.
>
> Eso es muchíííííííííí [x1000] íííísimo trabajo. Pero si no
Gtk y Gnome.
--
Fórmula del condón: No-metil-lacolina-oxi-metil-metila-con-gomina.
Drizzt
>Realmente, Qt es _muy_ facil de usar, sólo teneis que echarle un
>vistazo. El sistema de slots/signals desarrollado por los Trolls
>de desarrollar.
He comprado un libro de O'Really sobre QT y está _más_ que bien. Se lo
aconsejo a cualquiera que quiera aprender QT.
>en mi opinión) lo lógico es usar un lenguaje orientado a objetos.
Si es lo lógico, por lo menos para mi. Después de haber programado en Windows
a golpe de API en C, C++ y una libreria de clases en condiciones da mucha
mayor comodidad y rapidez al hacer las cosas.
Drizzt
>
>Bueno. Al fin y al cabo asi se implementan los objetos en C++ ¿no?. El
>primer parametro es siempre implicito y "this".
¿Y qué mas da como se implemente?. También los saltos se implementan con un
jmp y la gente que enseña lenguajes estructurados se lleva las manos a la
cabeza con los gotos.
En C, tengo que pasar por meter forzosamente un parámetro que haga referencia
al objeto en cuestión. Sin contar que en C++ el chequeo de tipos es mucho más
estricto, puedo sobrecargar operadores y muchas otras posibilidades.
Drizzt
> Mira el fichero TODO de Glade y te llevarás una sorpresa.
Ya, pero es TODO, es algo presente en otros paquestes desde el año .. uhm ...
92-93 mínimo. Cuando se diseña un RAD hay que tener en cuenta eso desde el
principio.
Drizzt
>
>Me pareje una gilipollez que haga un el lenguaje BASIC de Visual Basic
>para Linux.
Ya por eso hice el comentario. Tanto criticar a M$ , y aquí nos dedicamos a
copiarlo en todo.
Drizzt
> Creo recordar que el objetivo era desarrollar un lenguaje de script
> o de macros o como gaitas se llame eso, pero para Gnumeric y
> Evolution. La cuestion era que se iba a ejecutar encapsulado en una
> caja, de la misma forma que lo hace Java en un navegador.
> Ojo, esto no exime para que no se puedan hacer perrerias, puesto
> que las JVM han tenido errores, pero esperemos que esto funcione
> mejor y piensen en la posibilidad de la rapida propagacion de los
> "virus" esos.
Si, yo he pensado, pero para otra cosa muchas veces en ese tema. Pero estamos
en lo de siempre. ¿Qué lenguaje?. Pero si en Windows se usa VB, porqué no lo
hacemos nosotros, etc. Al final habrá un Basic en vez de otros lenguajes que
desde mi punto de vista tienen más potencial, y que de por sí, ya alguno puede
meterse en libreria, como Python. O acabará, conociendo a la gente de gnome
metiendo Scheme o algún lisp que hará que no nos den las manos para meter
paréntesis.
Drizzt
>en cualquier escuela. Esa cantidad es muy razonable para quien
>desee no fomentar la piratería. Se sabe el precio de Borland?
La versión estandar del C++ Builder 5 , vale unas 30K. Si tuviese dinero lo
y sale al mismo precio de Linux, lo compro.
Juanjo Álvarez
en fecha: 7 Jun 2000 18:45:08 GMT
|El día Tue, 6 Jun 2000 02:38:54 +0200, Juanjo Álvarez decía:
|>
|>Me pareje una gilipollez que haga un el lenguaje BASIC de Visual Basic
|>para Linux.
|
|Ya por eso hice el comentario. Tanto criticar a M$ , y aquí nos dedicamos a
|copiarlo en todo.
|
Hombre, normalmente se copia lo mejor que se vea de otros SSOO, eso se
hace en Linux, en Solaris y en Windows NT, y no creo que se copie sólo
de M$ (especialmente M$ son los reyes a la hora de copiar).
Sólo que en este caso no han ido a copiar "la joya de la corona"
precisamente...
(en mi muy subjetiva opinión).
--
Demasiada capacidad es peor que la incapacidad.
-- Observación de Peter.
http://www.clickeas.com/linux
Juanjo Álvarez
|Si, yo he pensado, pero para otra cosa muchas veces en ese tema. Pero estamos
|en lo de siempre. ¿Qué lenguaje?. Pero si en Windows se usa VB, porqué no lo
|hacemos nosotros, etc. Al final habrá un Basic en vez de otros lenguajes que
|desde mi punto de vista tienen más potencial, y que de por sí, ya alguno puede
|meterse en libreria, como Python.
Es lo que yo digo, de todo lo que podían copiar del VB han cogido lo
peor.
El intérprete de Python es muy fácil empotrarlo dentro de una aplicación
C o C++, por lo que siempre es muy tentador hacerlo (además hay muy
buena documentación al respecto). Si no me equivoco, Gnumeric ya puede
programarse tanto en Python como en Perl, y creo que Gimp (con
determinados plugins) también.
Es más, hay rumores de que ActiveState (los que portaron el Perl a NT)
haya sido contratada para meter un intérprete Python dentro del Mozilla
(aunque para lo sencillo que es me podían haber contratado a mi), y
dar la posibilidad de crear un PythonScript que puede acceder a las
clases del JavaScript.
|O acabará, conociendo a la gente de gnome
|metiendo Scheme o algún lisp que hará que no nos den las manos para meter
|paréntesis.
Que pena que no conozcan el Haskell. (Pista con regla de tres: Haskell
es a Lisp lo que C++ es a Fortran).
Juanjo Álvarez
en fecha: 7 Jun 2000 18:15:29 GMT
|El día Tue, 06 Jun 2000 14:49:29 +0200, Antonio Larrosa decía:
|>Realmente, Qt es _muy_ facil de usar, sólo teneis que echarle un
|>vistazo. El sistema de slots/signals desarrollado por los Trolls
|>es _intuitivo_, que es una de las cosas mas importantes a la hora
|>de desarrollar.
|
|He comprado un libro de O'Really sobre QT y está _más_ que bien. Se lo
|aconsejo a cualquiera que quiera aprender QT.
Ese libro ¿Habla de las Qt 1.x o 2.x? Si pudieras dar los datos exactos,
me harías muy feliz.
|>en mi opinión) lo lógico es usar un lenguaje orientado a objetos.
|
|Si es lo lógico, por lo menos para mi. Después de haber programado en Windows
|a golpe de API en C, C++ y una libreria de clases en condiciones da mucha
|mayor comodidad y rapidez al hacer las cosas.
Es que los "botoncitos" se prestar mucho a ser vistos como objetos.
Salvador Petit Martí
> El día 7 Jun 2000 10:34:36 GMT, Salvador Petit Martí decía:
>>
>>Bueno. Al fin y al cabo asi se implementan los objetos en C++ ¿no?. El
>>primer parametro es siempre implicito y "this".
> ¿Y qué mas da como se implemente?. También los saltos se implementan con un
> jmp y la gente que enseña lenguajes estructurados se lleva las manos a la
> cabeza con los gotos.
No se tu pero para mi la diferencia entre:
objeto->llamada(parametros) y
llamada(objeto, parametros)
No es importante, y por eso su nombre es "azucar sintáctico".
Lo bueno de C++ sobre C no está ahí. Está en otras cosas que comentas
más abajo. A las que yo añadiria dos: Herencia y las STL (el
polimorfismo es perfectamente emulable con C y punteros). Otra cosa es
que C++ pueda parecer más limpio haciendo lo mismo, que tb.
> En C, tengo que pasar por meter forzosamente un parámetro que haga referencia
> al objeto en cuestión. Sin contar que en C++ el chequeo de tipos es mucho más
> estricto, puedo sobrecargar operadores y muchas otras posibilidades.
> Un saludo
> Drizzt
> --
> ____________________________________________________________________________
> Drizzt Do'Urden Three rings for the Elves Kings under the Sky
> drizzt....@iname.com Seven for the Dwarf_lords in their
> hall of stone
> Nine for the Mortal Men doomed to die
samsagaz
si se quiere hablar sobre esto lo mejor seria montar una lista de
correo. No pensais lo mismo?
--
Dios nos envia los alimentos y el demonio los cocineros.
Drizzt
QT 1.44 aunque cubre tambien alguna cosa de la 2.0 . El libro es de
este año. O'Relly QT libs o algo asi. En su web vendra la referencia.
Un saludo
Drizzt
Manuel López Moreno
Drizzt <ter...@menzoberrazan.dhis.org> nos relató:
> El día Tue, 6 Jun 2000 02:38:54 +0200, Juanjo Álvarez decía:
> >
> >Me pareje una gilipollez que haga un el lenguaje BASIC de Visual Basic
> >para Linux.
>
> Ya por eso hice el comentario. Tanto criticar a M$ , y aquí nos dedicamos a
> copiarlo en todo.
Es que M$ es el punto de referencia.
Todos nos hemos criado con M$, y lo peor, las empresas tienen a
M$ como el paradigma de _todo_.
¿Por qué tanto interés por los RADs sino porque es lo que vende?
Así que, si hay que dar buena impresión a las empresas tendrá que
ser con lo que ellas conocen: entornos de desarrollo "estilo
windows".
Cuestión de marketing ;-)
--
Manuel López Moreno
O---m <http://www.linuxfan.com/~luname/pgp-key.asc>
Visita: Web de ecol.* <http://www.linux-es.com/es.comp.os.linux.*/>
Jesús M. NAVARRO
Drizzt wrote:
>
> El día Tue, 6 Jun 2000 02:38:54 +0200, Juanjo Álvarez decía:
> >
> >Me pareje una gilipollez que haga un el lenguaje BASIC de Visual Basic
> >para Linux.
>
> Ya por eso hice el comentario. Tanto criticar a M$ , y aquí nos dedicamos a
> copiarlo en todo.
>
TODO, no. No, por ejemplo, las BSOD (a menos que incluyas en la
comparativa el salvapantallas ése que hay por ahí, que la saca... muy
gracioso).
¿Qué tiene de malo imitar lo bueno? M$ se gasta un porrón de dinero en
estudiar la ergonomía de sus programas, y a mí me parece que lo hacen
muy bien (supongo que, puesto que M$ se rige principalmente por el
criterio comercial, los de marketing les habrán dicho que puesto que
*algún* dinero han de gastar en el programa en sí, lo mejor que pueden
hacer es dedicarlo a eso, que es lo que da mayor 'revenue'... mayor que
hacer que el código que hay por debajo funcione).
--
SALUD,
Jesús
***
jesus_...@geocities.com
***
Santiago Romero
>Santiago Romero escribió:
>>
>> Yo creo que la pregunta es...
>> ¿Cuando salía C++ Builder para Linux? ¿No salia este verano?
>> Sera la salvacion de Linux, y yo me fio de los señores de borland,
>> porque si saliera el VisualBasic ay que miedo, pero el Builder...
>> en fin.
>
>Pero el Builder ¿no será comercial si es de Borland? Al menos
La version 1.0 profesional (que yo uso para hacer cosas de la uni
por ejemplo) es gratuita, de hecho hasta la regalaban en la PCWorld,
y puedes hasta distribuir los ejecutables que hagas con ella... claro,
la 1.0 porque van por mas adelantadas, pero de verdad, lo que lleva
la 1.0 es para mi bastante para hacer aplicaciones buenas como
churros, y cuando este, igual aparecen aplicaciones que ahora no hay
y que hacen falta...
en fin.
salu2
--
¿Multitarea en Windows?
Significa que dos programas pueden fallar simultaneamente.
_-----------------------------------------------------_
| NoP / Compiler -- sro...@unix-shells.com |
Drizzt
>>en Linux.
>
>VisualBasic + Gnumeric tiene su razón de ser. Los usuarios más
>potentes utilizan todos Excel y programan en VisualBasic. Si Gnumeric
>intenta ser un contendiente del Excel, debe de ofrecer un lenguaje de
>programación asequible para usuarios Excel.
Para eso te quedas con Excel. En serio, si a mi la unica ventaja técnica que
tengo es que tengo fuentes, pues seguiría con Excel ( que no es el caso).
Quiero un software potente y si el lenguaje de programacion y script que mete
no es uno potente, sino uno por "simple compatibilidad", para clonar un
producto comercial de poco me vale.
Lo mismo me vale para el Evolution, que los snaphots que he visto está calcado
del Outlook Express ( que en este caso es gratuito). No me gusta "clonar"
Windows y sus aplicaciones porque si, y simple y llanamente, porque seguir
ese camino es estar siempre por detrás. ¿Qué pasaria si M$ en un momento dado
porta parte de su soft a Linux?. Y si encima, le da por dar las fuentes. Pues
un monton de horas de programacion tiradas a la basura, por "clonar" algo
hasta sus últimos detalles.
Una de las razones por las que uso Linux y recomiendo linux es su potencia y
la flexibilidad que da. Si por "clonar" lo único que voy a hacer es perder la
flexibilidad o llegar a programas "bloatware", imposibles de mantener, apaga y
vamonos.
Ya ha pasado con Motif, que aunque no tiene una licencia libre _total_ para el
el uso que tiene, (port de soft de otras plataformas,etc), no creo que nadie,
a menos que tenga una necesidad muy grande de algo "estandar" y del opengroup
se ponga hoy en dia con Motif, y mucho menos cuando hay toolkits de varios
colores por ahí, con lo cual se tienen cierta ventaja. Así que todo el
esfuerzo de lesstif en estos momentos es replanteable. ( a fin de cuentas no
tienen compatibilidad 2.1 ) y sinceramente, si lo único que quieres el .so
para poder rular 4 programas y medio, ....
En cuanto a lo del Basic, está bien para lo que estaba en los años 80 y para
hacer macros. El problema es que me veo que si Gnumeric incorpora una
implementacipon de VB, lo unico que va a heredar la gente son las malas
costumbres que hay Windows.
Ya se ha demostrado, que por muchas fuentes que haya, en el mundo unix y soft
libre los bugs de seguridad también siguen campando por sus anchas ( los
ultimos q me vienen, el del kernel 2.2.16, qpopper, etc), y mucha gente ha
mirado las fuentes, y el último del kernel lo ha levantado otro programa. Esto
lo digo a cuento del comentario de la implementación. Habas cuecen en todos
lados, y para el que lea poe ejemplo linux-kernel sabe los problemas que tiene
el propio kernel. Y esto solo se evita con una auditoria muy cuidadosa de
las fuentes que se hacen, cosa que de momento , solo han conseguido ( y no con
éxito total), la gente de OpenBSD, pero que en contra hacen que tengan que
manterner cierta simpleza en programas y no poder acoplar lo último de lo
último.
Xose Manoel Ramos
>¡Larga vida a C, C++ y Python!
Lenguajes geniales, que en manos de un programador indisciplinado dan
un resultado aterrador.
--
\/ _ _ _ (Vigo/Galicia/España)
/\(_)_\(/_ xma...@i.am
http://i.am/xmanoel/
Jose Antonio
> La "portabilidad descendente" como tu la llamas dudo muchísimo que se
> consiga con cualquier programa que no sea el HOLA MUNDO. ¿Cómo traduces
> los controles? Y casi cualquier programa VB tiene controles.
> ***
> Hay Python para Win, quizás lo interesante sería hacer un entorno tipo
> VB con Python como lenguaje y para Windows y Linux (y otros Unix), junto
> a una colección de controles muy interesantes (no sólo gráficos, también
> de conectividad con BBDD y demás). Eso SI arrasaría y sería más fácil
> que lo que están haciendo (al fin y al cabo, el intérprete/compilador,
> que es lo más dificil, ya lo tienen hecho).
> *********
> Un programador debe saber más lenguajes y desde luego, otras formas de
> trabajar además de las que pueda enseñar VB, sino lo que es es un molinillo
> de código no un programador, o al menos no debería tener mucha dificultad
> en aprender Python si sabe VB.
>
> --
> Desarrolle un sistema que hasta un tonto pueda utilizar, y solamente un tonto lo querrá utilizar.
> -- Principio de Shaw.
> http://www.clickeas.com/linux
Hola:
Permítime que me salga un poco por la tangente y replantee el problema. Creo que el problema
es de
masa crítica:
Una de los elementos __fundamentales__ para el desarrollo de un proyecto de software
libre
es el número determinado de usuarios y programadores que participan en el proyecto, por encima del
un
número determinado el proyecto puede crecer y por debajo del cual desaparecerá como tantos otros
(ideas tomadas de La Catedral y el Bazar).
Pues bien en un proyecto tan GIGANTESCO (así en mayúsculas) como es GNOME es necesaria
la participación del mayor número de usuarios y, sobre todo, programadores para echar a andar la
"bola de nieve" (en palabras de los desarrolladores de GNOME).
Esta es una de las razones, no la más importante, pero SI, la decisiva para obtar por
gnome-basic.
¿Técnicamente es mejor python ?, puede ser, tambien lo era el Amiga, el NextStep y tantos y
tantos,
¿por qué fracasaron?: no estuvieron a la altura de las circunstancias,... Espero que a GNOME-BASIC
no le pase lo mismo.
¿Cuanta gente programa en Visual Basic? cientos, miles ... (ya no digo programadores) ...
imaginemos que un 5% prueba Gnome-Basic, y un 1% decide hacer algún programa sencillo
bajo GPL... ¿de cuanta gente estamos hablando?
¿Puede Gnome-Basic ser una bola de nieve?
Pruéba sus primeras versiones "alpha" en http://www.gnome.org/gb
Gracias por leer este "post" tan largo :-)
jose_antonio
--
__________________________________________________________________
jose...@wanadoo.es | Pagina Personal:
LIF | http://personal4.iddeo.es/joseantsa
DaVinci
>imaginemos que un 5% prueba Gnome-Basic, y un 1% decide hacer algún
>programa sencillo bajo GPL... ¿de cuanta gente estamos hablando?
Pues no le veo la gracia a tantísima gente haciendo programas
sencillos... Me parece que es mucho más interesante que las cosas
marchen como hasta la fecha: cada uno aportando su granito de arena
(código, manuales, howtos, búsqueda de bugs...) a proyectos de
verdadera necesidad.
Sólo falta que se potencie aún más esa extraña tendencia de
"vamos a hacer otro cliente de correo gráfico con las librerías de
la señorita Pepis"...
De cualquier forma, espero que, tal y como apuntas, haya una
avalancha de gente con ganas de ayudar y, de entre todos ellos,
surjan nuevas promesas con buenas ideas.
Un saludo.
--
DaVinci
Juanjo Álvarez
en fecha: Mon, 12 Jun 2000 09:51:53 GMT
|El Sun, 11 Jun 2000 08:24:08 +0200, Juanjo Álvarez decía:
|
|>¡Larga vida a C, C++ y Python!
|
|Lenguajes geniales, que en manos de un programador indisciplinado dan
|un resultado aterrador.
Cierto. Pero yo creo que es así (a base de ostiones) y no con lenguajes
que te aten, como debes de aprender porqué determinadas cosas se han de
hacer de determinadas formas. Otros lenguajes te dicen "tienes que hacer
esto así porque no tienes otra opción". En lenguajes como estos puedes
hacer las cosas como quieras, y tienes libertad para saltarte las normas
si es necesario, pero sueles aprender, como tu dices, a "disciplinarte".
--
¿Usted tiene un micro? El mío es enorme...
-- Www.frases.com.
http://www.clickeas.com/linux
Juanjo Álvarez
en fecha: Mon, 12 Jun 2000 22:32:53 +0200
|Juanjo Álvarez wrote:
|
| Pues bien en un proyecto tan GIGANTESCO (así en mayúsculas)
|como es GNOME es necesaria la participación del mayor número de
|usuarios y, sobre todo, programadores para echar a andar la "bola de
|nieve" (en palabras de los desarrolladores de GNOME). Esta es una de
|las razones, no la más importante, pero SI, la decisiva para obtar por
|gnome-basic.
Lo que me asusta es la preparación media del programador de Visual
Basic...
| ¿Técnicamente es mejor python ?, puede ser, tambien lo era
|el Amiga, el NextStep y tantos y tantos, ¿por qué fracasaron?:
|no estuvieron a la altura de las circunstancias,... Espero que a
|GNOME-BASIC no le pase lo mismo.
Pones Python como si fuera un perdedor, cuando lo que hace ultimamente
es subir, subir, y subir de popularidad, uso y admiración entre
profesionales.
Me reiría mucho (amargamente) si dentro de un par de años M$ decide
elegir Python como lenguage de Script de determinadas aplicaciones, y
los señores de Gnome van todos corriendo a implementar Python.
Pero no me extrañaría mucho que pasará algo asi. En primer lugar porque
sería una excelente decisión de diseño (y los buenos programas se basan
en decisiones de diseño, no en intentar parecerse a otros). En segundo
lugar porque el WSH (Windows Scripting Host) ya soporta Python. Si lo
tienes instalado en Win98, puedes hacer desde el explorer:
<script language="python">
print "hola, mundo"
</script>
y en tercer lugar porque ya hay librerías muy buenas que pueden
manipular aplicaciones M$ (entre ellas Excel) desde Python, desde un
programa externo, pero de ahí a integrarlo hay un paso.
| ¿Cuanta gente programa en Visual Basic? cientos, miles ... (ya no
|digo programadores) ... imaginemos que un 5% prueba Gnome-Basic, y un
|1% decide hacer algún programa sencillo bajo GPL... ¿de cuanta gente
|estamos hablando?
Prefiero tener menos aplicaciones, creadas por programadores competentes
que muchas creadas por VisualBasiqueros. No digo que todos los
programadores de Visual Basic sean malos, pero si hay más mantas que en
cualquier otro lenguaje que te encuentres.
|¿Puede Gnome-Basic ser una bola de nieve? Pruéba sus primeras versiones
|"alpha" en http://www.gnome.org/gb
Definitivamente creo que es una pérdida de tiempo. Pero bueno, "Linux is
about choice".
--
En el año 2005 los chips serán tan baratos que los encontraremos en todas partes: la nevera, la lavadora y cualquier otro electrodoméstico.
-- Vinton Cerf. (1934) Padre de Internet. (Fundador de Internet Society).
http://www.clickeas.com/linux
Juanjo Álvarez
en fecha: 11 Jun 2000 22:19:03 GMT
|El día Sat, 10 Jun 2000 21:46:42 GMT, Xose Manoel Ramos decía:
|>>en Linux.
|>
|>VisualBasic + Gnumeric tiene su razón de ser. Los usuarios más
|>potentes utilizan todos Excel y programan en VisualBasic. Si Gnumeric
|>intenta ser un contendiente del Excel, debe de ofrecer un lenguaje de
|>programación asequible para usuarios Excel.
|
|Para eso te quedas con Excel. En serio, si a mi la unica ventaja técnica que
|tengo es que tengo fuentes, pues seguiría con Excel ( que no es el caso).
|Quiero un software potente y si el lenguaje de programacion y script que mete
|no es uno potente, sino uno por "simple compatibilidad", para clonar un
|producto comercial de poco me vale.
Cierto.
|Lo mismo me vale para el Evolution, que los snaphots que he visto está calcado
|del Outlook Express ( que en este caso es gratuito). No me gusta "clonar"
|Windows y sus aplicaciones porque si, y simple y llanamente, porque seguir
|ese camino es estar siempre por detrás. ¿Qué pasaria si M$ en un momento dado
|porta parte de su soft a Linux?. Y si encima, le da por dar las fuentes. Pues
|un monton de horas de programacion tiradas a la basura, por "clonar" algo
|hasta sus últimos detalles.
Bueno, cada uno es libre de hacer lo que quiera, y desde luego un
programa de correo tipo Outlook puede ayudar a mucha gente a dar el
salto. De todos modos tal como lo tienen planeado promete bastante más
que Outlook, sobre todo en temas de trabajo en grupo y demás.
Hay que tener de todo "linux y about choice", y si falta un programa de
correo muy gráfico, pues se hace y ya se tiene. No veo el problema por
ningún lado.
|Una de las razones por las que uso Linux y recomiendo linux es su potencia y
|la flexibilidad que da. Si por "clonar" lo único que voy a hacer es perder la
|flexibilidad o llegar a programas "bloatware", imposibles de mantener, apaga y
|vamonos.
"Lo unico que voy a hacer es perder la flexibilidad". Que pasa ¿Cuando
instalas Evolution se te borra el Mutt? Porque sino no entiendo como es
que pierdes la flexibilidad.
|En cuanto a lo del Basic, está bien para lo que estaba en los años 80 y para
|hacer macros. El problema es que me veo que si Gnumeric incorpora una
|implementacipon de VB, lo unico que va a heredar la gente son las malas
|costumbres que hay Windows.
De nuevo, de acuerdo, pero recuerda que también se puede programar en
Python, Perl y Scheme... ¿puede hacer eso Excel? Gnumeric ya aventaja a
Excel en algunos campos.
|Ya se ha demostrado, que por muchas fuentes que haya, en el mundo unix y soft
|libre los bugs de seguridad también siguen campando por sus anchas ( los
|ultimos q me vienen, el del kernel 2.2.16, qpopper, etc)
¿Cuanto han tardado en arreglarse? ¿Cuanto tardan M$ o Sun en arreglar
los suyos? Ya tienes el kernel 2.2.17-pre1, que sólo tiene arreglos de
fallos, y el Qpopper 3.0.
En la práctica los mas hackeados son los NTs. Si no te lo crees pásate
por www.attrition.org y dale un vistazo, hace poco pusieron unas
gráficas muy monas.
|, y mucha gente ha
|mirado las fuentes, y el último del kernel lo ha levantado otro programa.
Esta frase no la entiendo.
|Esto
|lo digo a cuento del comentario de la implementación. Habas cuecen en todos
|lados, y para el que lea poe ejemplo linux-kernel sabe los problemas que tiene
|el propio kernel.
Pero se arreglan muy rápido, si necesitas seguridad a tope y actualizas
regularmente poca gente se te va a colar (suponiendo que seas cuidadoso
en otros aspectos).
|Y esto solo se evita con una auditoria muy cuidadosa de
|las fuentes que se hacen, cosa que de momento , solo han conseguido ( y no con
|éxito total), la gente de OpenBSD, pero que en contra hacen que tengan que
|manterner cierta simpleza en programas y no poder acoplar lo último de lo
|último.
No se puede tener todo. Pero si quieres un linux muy seguro lo puedes
tener.
Juanjo Álvarez
en fecha: Tue, 13 Jun 2000 03:34:52 +0200
|Esto
|lo digo a cuento del comentario de la implementación. Habas cuecen en todos
|lados, y para el que lea poe ejemplo linux-kernel sabe los problemas que tiene
|el propio kernel
^
|
`- El kernel INESTABLE.
Se me olvido decir: Leo linux-kernel y si comparas los problemas que
tienen ahora (oops esporádicos principalmente, cosa fácil), con los que
tenías hace un mes o dos te das cuenta de que esto se ha acelerado una
barbaridad, los problemas de memoria virtual ya se han solucionado
practicamente con el parche de Van Riel, y el del kswapd igual con el
del tal Quintana (o algo así se llamaba el hombre), la gente que está
probando el 2.0-test1-ac13/14 está notando una mejora de rendimiento
tremenda (sobre todo los que más se quejaban antes de eso), ya parece
que se ha relajado la modificación de interfaces, etc.
Hace dos meses no lo hubiera dicho, pero ahora estoy convencido de que
es muy posible que tengamos un 2.4.0 antes de que acabe el verano, o al
poco de acabar (si Linus no se pira otra vez de vacaciones, of course
:-)
Por otro lado, leyendo la lista del kernel a uno le puede entrar la
sensación de que los kernel 2.3 son una patata más inestable que el
Windows 3.11 (que ya es decir), pero date cuenta de que los mensajes que
ves con problemas son los de la gente que informa de bugs, normalmente
nadie escribe para decir "pues me va de maravilla y es muy estable" a la
lista del kernel.
Pero si pruebas el 2.3 verás que es bastante estable,
yo llevo dos meses con el en el otro ordenador y ni un sólo oops, ni un
cuelgue, ni un problema, y las versiones que se supone que tenían el
rendimiento de VM jodido, sinceramente, yo no notaba diferencia (creo
que para notarla debías de tener más de 512 Mb de RAM).
Así que no seamos tan catastrofistas que no es para tanto.
Por cierto, yo veo posible que Linus meta el ReiserFS en algún 2.4.x (al
fin y al cabo funciona de maravilla). Hagan sus apuestas.
Xose Manoel Ramos
>Para eso te quedas con Excel. En serio, si a mi la unica ventaja técnica que
>tengo es que tengo fuentes, pues seguiría con Excel ( que no es el caso).
>Quiero un software potente y si el lenguaje de programacion y script que mete
>no es uno potente, sino uno por "simple compatibilidad", para clonar un
>producto comercial de poco me vale.
¿Compatibilidad? VisualBasic sin ActiveX no es compatibilidad. Nunca
va a ser compatible, ni nadie va a esperar que se utilicen los macros
de Excel en el Gnumeric. He comentado que un usuario de Excel puede
encontrar cómodo y familiar usar un lenguaje similar en otra hoja de
cálculo. ¿Que no te gusta? Gnumeric & Gnome usa Guile, que permite
que programes en bastantes lenguajes diferentes. Haz lo que tu
quieras.
Al respecto del futuro de Gnumeric... yo espero que sea tan potente o
más que el Excel. Y de hecho esta esperanza me interesa. ¿Sabes lo
que cuesta una licencita de Excel? ¿Sabes lo que cuesta un modulo de
ampliación de Excel en VisualBAsic al que no puedes meter mano porque
es código cerrado?
Excel + VisualBasic = Ningún interés
Gnumeric + cualquier lenguaje script = Potencia
Drizzt
>comentado aquí):
> - Absoluta portabilidad "descendente" (desde Visual Basic hacia Gnome-Basic).
> - Portabilidad "ascendente" (desde Gnome-Basic hacia Visual-Basic) (esto es muy
>importante
> pues si se hiciese en un lenguaje tan poderoso como python sería muy difícil el
>paso).
Eso equivale a clonar todos los ActiveX , y por supuesto, dejar acceso a los
ficheros, y posibilidades del sistema desde Basic ( y tb clonar el registro de
Windows por el camino).
Drizzt
>Bueno, cada uno es libre de hacer lo que quiera, y desde luego un
>programa de correo tipo Outlook puede ayudar a mucha gente a dar el
>salto. De todos modos tal como lo tienen planeado promete bastante más
>que Outlook, sobre todo en temas de trabajo en grupo y demás.
>
>Hay que tener de todo "linux y about choice", y si falta un programa de
>correo muy gráfico, pues se hace y ya se tiene. No veo el problema por
>ningún lado.
A mi me da igual lo que elija la gento. Tambien tengo bastante libertad de
elección en Windows ( y además mucho software gratis). Lo que pasa es que me
veo que va a pasar lo mismo que Windows, que como vendrá en toda las
distribuciones y te forzaran a "usar esas herramientas". Un ejemplo claro de
esto son algunas de las herramientas de administración de Redhat, que fuerzan
a Gnome.
Si veo un problema, que al final, tendremos fotocopiado diferentes
aplicaciones que forzaran a usarlas.
>
>"Lo unico que voy a hacer es perder la flexibilidad". Que pasa ¿Cuando
>instalas Evolution se te borra el Mutt? Porque sino no entiendo como es
>que pierdes la flexibilidad.
A mi no, pero a la gente que "fuerzas" a usar los programas gráficos si. De
hecho, mucha gente en Windows no usa otros programas por pura comodidad...
como viene con el sistema.
>De nuevo, de acuerdo, pero recuerda que también se puede programar en
>Python, Perl y Scheme... ¿puede hacer eso Excel? Gnumeric ya aventaja a
>Excel en algunos campos.
No se lo que puede hacer Excel (ni Gnumeric ...), pero si se que mercado lleva
cada uno. A fin de cuenta, ese es el VERDADERO negocio de M$, el Office y su
integración. Sólo hay que pasarse por algunas Webs oficiales para ver en que
formato te piden las cosas, o en que formato te obligan a entregar
documentación, o en que formato están los documentos.
>
>¿Cuanto han tardado en arreglarse? ¿Cuanto tardan M$ o Sun en arreglar
>los suyos? Ya tienes el kernel 2.2.17-pre1, que sólo tiene arreglos de
>fallos, y el Qpopper 3.0.
Un día en algunos casos. Aquí nadie conoce los hotfixes de NT, parece ser.
Por que de todas maneras, el fallo de Linux se conocia desde hace tiempo en el
mundillo underground, como se deduce los post de Bugtraq, así como el qpopper,
que se sabia que tenía exploits no publicados en los medios habituales.
>En la práctica los mas hackeados son los NTs. Si no te lo crees pásate
>por www.attrition.org y dale un vistazo, hace poco pusieron unas
>gráficas muy monas.
Habría que recordar la época de los Linux , *BSD, con imapd, ipop y el resto
de la pesca ..... Ha habido mucho mucho hack de Unix. Y a todo esto, muchos NT
"caen" por incompetencia de los administradores ( ej , los _vti_pvt del
FrontPage con permisos erróneos).
>|mirado las fuentes, y el último del kernel lo ha levantado otro programa.
>Esta frase no la entiendo.
Que por mucha gente que haya visto las fuentes del kernel nadie ha visto el
fallo de las capabilites, y ha sido la gente de Sendmail quien ha levantado el
fallo.
>
>Pero se arreglan muy rápido, si necesitas seguridad a tope y actualizas
>regularmente poca gente se te va a colar (suponiendo que seas cuidadoso
>en otros aspectos).
¿Y tu puedes estar parando una máquina cada día para cambiar el kernel?.
A lo mejor, no te has dado cuenta que por ahí , parar una máquima significa
perder una considerable cantidad de dinero.
>No se puede tener todo. Pero si quieres un linux muy seguro lo puedes
>tener.
Ya lo sé que no se puede ni se tendrá nunca todo. Lo único que digo, es que
en todos lados cuecen habas, no solo en M$.
J.A. Gutierrez
: Por cierto, yo veo posible que Linus meta el ReiserFS en algún 2.4.x (al
: fin y al cabo funciona de maravilla). Hagan sus apuestas.
apuesto por XFS, que al fin y al cabo ya esta funcionando
en las maquinas que vende SGI con Linux.
--
PGP and other useless info at \ Oh, show us the way
http://www.cps.unizar.es/~spd/ \ to the next whisky bar
finger://daphne.cps.unizar.es/spd \ Weill/Bretch
es doloroso ser sabio y descubrir la sopa de ajo (Pla)