Barrapunto

1) Ahora mismo se puede interoperar entre distintos lenguajes. Basta que se pacte de antemano una forma de comunicación neutral (CORBA, adaptador C de SWIG o lo que sea). Por ejemplo, en python puede programar un componente activo usando las mfc y después llamarlo desde un proyecto c++ en Visual Studio o desde vbscript en una página web.

Con las jfc puedes usar componentes activex en java y beans en c++, etc.

2) La productividad es la de siempre (o peor, hasta que la gente se acostumbre la biblioteca de clases y a sus truquillos). Ni más ni menos que la de java.

3) Las bibliotecas son potentes pero no son ni más ni menos completas que las de java o python Además muchas partes del .NET framework son windows-céntricas y no es fácil reeimplementarlas en Linux (en lo relacionado con los interfaces y demas, ahí están los handles de windows!).

En fin, que yo tampoco entiendo muy bien el revuelo que montan con .NET. C# es un lenguaje majo, muy divertido, pero sólo es un lenguaje más y las bibliotecas de clases son buenas pero no son infinitamente superiores que lo que tenemos ahora mismo. No veo qué puede hacer .NET que no se pueda hacer *ahora* igual de bien e igual de rápido con tecnologías de hace casi un lustro.

Es más, me resulta sorprendente que dentro de Gnome le estén dando tanto impulso. Muchas personas que estan detrás de la plataforma de desarrollo Gnome estan muy sensibilizadas con el tema del rendimiento (con consignas como "programos en C porque el código es más rápido, consume menos recursos, etc"). No sé como racionalizan meter una capa de abstracción tan gorda para las aplicaciones (.NET) con un overhead brutal.

De: Miguel de Icaza
A: gnome-desarrollo@es.gnome.org
Asunto: [Gnome-desarrollo] Mono y Gnome.
Fecha: 03 Sep 2002 02:40:35 -0400

Hola,

Me he enterado que hay una discusión en este foro sobre Mono y
Gnome. Y quería hacer algunos comentarios al respecto. Creo que ya se
han mencionado los temas principales aquí.

* Sobre los lenguajes de programación.

Gnome siempre usó C para diseñar sus APIs con una serie de
restricciones (gnome-libs/devel-docs/gnome-language-bindings.tex ) para
poder lograr que se usaran múltiples lenguajes de programación. Fué
algo que siempre promovimos. De hecho, las primeras aplicaciones de
Gnome fueron escritas en Scheme/Gtk.

Soportar múltiples lenguajes de programación es algo que *siempre*
hemos empujado.

Desgraciadamente, los "bindings" tenían un problema: pasaban varios
meses antes de que todos los lenguajes soportaran la funcionalidad que
introducíamos y el soporte variaba mucho dependiendo del encargado del
port.

Una nueva tendencia apareció en 1998 y empezamos a empujar esta
tendencia: definir APIs en términos de interfaces CORBA. La gran
diferencia es que era posible definir el API una sola vez, y re-usarlo
desde cualquier lugar (a esto se le llama "Automation" en el mundo de
Windows). Owen Taylor tenía un pequeño demo que mostraba el control de
Gnumeric remoto.

Desgraciadamente, nunca pudimos lograr suficiente masa crítica en el
escritorio para que todo el sistema lo soportara, y si no se logra esto,
entonces la tecnología tiene poco impacto. CORBA era difícil de
aprender y los bindings no eran triviales en C.

Ximian contrató a Paolo Molaro para que le diera mantenimiento a los
bindings de Perl de tiempo completo y para que incorporara CORBA como un
producto soportado en los bindings, lo cual hizo.

Asi que hacia finales del año 2000 teníamos Nautilus que estaba por
venir, Bonobo congelado, un Gnome 2.0 que es un desastre y muchas
opiniones divergentes sobre el futuro de Gnome y el particionamiento del
mismo. Por un lado queremos lograr la visión de "automation", pero por
otro lado, require hacer el software más complicado. Incluso evaluamos
la tecnología UNO de OpenOffice, y Michael estuvo a punto de abandonar
Bonobo y CORBA en Gnome 2.0 a favor de UNO, pero hubiera retrasado
Gnome2 más de lo que ya lo estaba.

El "Ximian Labs" a finales del año 2000 trabajaba en varios
proyectos:

Soap y Wsdl en C para Gtk/Gnome (Soup: Alex y Dick)
CORBA, Gtk y Perl (Paolo).
Configuración, Bonobo y bonobo-conf (Dietmar)
Bonobo, Orbit y OAF (Michael)

Cuando Microsoft.NET fue anunciado y los documentos técnicos
surgieron, fue inmediatamente claro que Microsoft había resuelto el
problema que teníamos: como soportar un API en varios lenguajes al mismo
tiempo sin tener el problema de los múltiples meses de retraso [1].

Esto fué un golpe muy fuerte para mi, por que estábamos tratando de
crear una plataforma atractiva para los desarrolladores: queríamos que
el usuario silvestre pudiera usar todo lo que Gnome podía ofrecer, pero
para esto era necesario exponer estos APIs a lenguajes de alto nivel.

Era claro que Microsoft tenía una mejor tecnología y que podíamos
invertir muchísimo tiempo con nuestra plataforma, pero no estábamos
logrando nuestro objetivo de darle poder a los usuarios más simples de

Para mí la pricipal ventaja para Microsoft, es una nueva API, mucho más potente que la clásica, mejor pensada, unifica criterios (ahora todo son objetos, los mismos objetos), que elimina y camufla muchos de los lastres arrastrados durante más de quince años por problemas de compatibilidad (desde el Windows 1.0 y antes incluso). .NET es una simplificación enorme para la programación en Windows sin convertirla en la parodia de lenguaje de programación que era Visual Basic. Puedes hacerlo todo y con el lenguaje que quieras.

Por otro lado .NET son muchas ideas con un sólo nombre, un sistema operativo, un lenguaje, una API, un sistema de autenticación, una serie de servicios por internet... .NET es una solución que pretende englobarlo todo, absorverlo todo. El que muchos de los avances que introduce .NET ya estuvieran en Java es algo que Microsoft quiere que pasemos por alto, pero de cara al usuario final eso da igual, porque el usuario final normalmente sólo ve que su vida es más fácil y bonita y eso en el fondo ha sido siempre la estrategia de Microsoft: abrazar y extender. Dicho de otro modo el que .NET sea mejor o peor no es algo importante porque ellos siempre venden muy bien su producto, y si parece que el .NET está en todas partes (ese revuelo que comentas) es porque Microsoft con su publicidad se encarga de que sea así.

Tu du me parece que está estropeadillo:

teo@periquito:~/mono/pruebas$ cat hola.cs
using System;

class HolaMundo
{
                public static void Main()
                {
                                Console.WriteLine("Hola Mundo!!!");
                }
}
teo@periquito:~/mono/pruebas$ mcs hola.cs
Compilation succeeded
teo@periquito:~/mono/pruebas$ mono hola.exe
Hola Mundo!!!
teo@periquito:~/mono/pruebas$ du -h *
4.0k hola.cs
4.0k hola.exe
teo@periquito:~/mono/pruebas$

A ver! si no lo has probado de que te quejas?

Fácil: Me quejo de que no puedo probarlo.

Los tipos de micro$oft me dieron una vez un pack de 4 CDs con el visual studio .net, y leo textualmente: "
PC con un procesador Pentium II, a 450 Mhz, Pentium III a 600 Mhz recomendado
S.O.: W2K, pro o server; WXP pro; o WNT server
"

O alguien me regala un ordenador nuevo, o seguiré programando en PHP en mi portátil P-166.

¿Desde cuando hace falta tánta máquina para programar, digo yo?

No soy ningún experto ni lo seré, pero todo este revuelo sobre .NET hizo que me entrara curiosidad, de manera que me informé un poco. Ahora sé al menos lo que es .NET un poquito (antes pensaba que era una "oscura" estrategia empresarial :-) ).

Aún no soy capaz de entender las repercusiones de .NET ni sus pros y contras, pero al leer alguna documentación, entendí que lo más novedoso era que .NET era de carácter estándar, de manera que Microsoft tendrá su implemetación, pero Icaza tendrá la suya, cosa que no pasa con Java, y creo que Java en este sentido a perdido el tren.

La manera en que se concibe la multiplataforma también me ha sorprendido.

Como he dicho, todo esto, bajo riesgo de equivocarme, no soy más que alguien que se informó un poquito sobre .NET y no sé gran cosa.

Funciona sobre un contenedor J2EE y no necesitas saber para nada si lo que lleva por debajo para implementar el servicio transaccional es MTS, Tuxedo o CICS.
 

Esta pregunta se hará muchas veces mientras no sea convincentemente respondida (personalmente dudo que pueda hacerse).

La única ventaja que le veo actualmente a .NET es el IDE de desarrollo y ese solo funciona bajo windows.

Lo que me parece sorprendete es por qué no se ha realizado con Java el esfuerzo que se esta realizando con .NET si era tecnologicamente viable y actualmente mucho más maduro ?

Si es de Microsoft es mejor ? La plataforma multilenguaje que quiere Miguel solo requiere una maquina virtual y Java ya la proporciona.
Además su especificación es totalmente abierta, así como la del resto de tecnologías (JDBC, JNDI, etc.)

Por qué entonces no se desarrollaron frontends para los diferentes lenguajes (Python, Perl, C++) que generaran como código intermedio bytecode para la JVM ?

Si se quiere adoptar la CLR como soporte multilenguaje, porque se ha empezado a implementar primero C# y no otro lenguaje ?

En definitiva, por que tanto revuelo con .NET si no aporta tecnológicamente nada nuevo ?

   

...para diseñar un sistema de escritorio. No se puede decir lo mismo de MS.

Ya que te veo muy convencido, me puedes decir cuales de las bondades que le atribuyes a .NET no existen en la plataforma J2EE ?

Es la pregunta del millón, si la respondes se acabará el debate y todos nos pondremos a desarrollar MONO :)

 

Por otro lado, el rendimiento de .NET parece que es realmente lamentable. Recuerdo un congreso sobre integración de aplicaciones (la utilidad real de los servicios web) en la que compañías de telefonía hablaban de soluciones con j2ee que estaban soportando cargas de hasta 250 transacciones por segundo, algo totalmente impensable sobre una plataforma Microsoft (palabras literales del delegado de la compañía)

No te digo que no, yo no probado .NET para compararlo con Java, pero me sorprende. Por lo que tengo entendido, el código C#, pongamos, acaba "compilado" en el lenguaje ensamblador de la máquina sobre la que se ejecuta el programa. Así, a priori una aplicación .NET será más rápida que su "equivalente" en Java, ¿no?

¿O no he entendido nada de cómo funciona .NET? Que alguien me lo diga, por favor.

Pues mono + compilador (mcs) + clases que hay hechas hasta el momento, no ocupa mucho mas que 8MB, si tenemos en cuenta que entre esas clases se ingluyen los bindings para gtk, glade, gda, ... pues no se si sera demasiado..., a mi me parece que no.

Librerias no estandar...
glib2.0 (todo el mundo la tiene)
libgc6 (recolector de basura bohem) [se puede omitir tb]

Mono se arrastra rápido en un viejo Pentium 90 que tengo por aquí. Vim, emacs y demás tienen coloreado de sintaxis. Si usas linux no veo el problema. Yo no puedo "disfrutar" del Visual Studio .NET porque solo tengo Debian en mis máquinas (el p90 y un PII300) pero estoy aprendiendo C# con mono y en feeling to es bueno tras acostumbrarme desde c pelao. Con Java no me pasó lo mismo cuando lo intenté al poco de salir Java2. Me pareció incomodo. Gustos personales.

No entiendo este follón que se monta cada vez que se habla de .NET o Mono o C# y Java. En el futuro se podrá programar en Java para .NET (es un ToDo en la página oficial de Mono). Solo hace falta que alguien implemente un compilador, si esque Sun no hecha a sus abogados encima del que lo intente. (Desventaja de Java por ser propiedad de una empresa y no ser libre).

La idea original de microsoft ? no me hagas reir :)) Como aquel que decía que Microsoft invento SOAP... Microsoft está entre los autores, pero es una verdad a medias (o a quintas ;):

http://www.w3.org/TR/SOAP/

Copyright© 2000 DevelopMentor, International Business Machines Corporation, Lotus Development Corporation, Microsoft, UserLand Software

SOAP a su vez se desarrolló a partir de XML-RPC que realizó Userland en solitario:

http://www.xmlrpc.com/spec
     

El _nombre_ Java es de una empresa. Como puedes ver Microsoft no tiene nigun problema en llamarle J, J# o lo que le viene en gana :)

Te contesto con lo que contó Miguel de Icaza un día en una charla (que si alguien quiere se la puedo pasar en .mp3 o en .ogg)

La máquina virtual de Java fue diseñada JUNTO con el lenguaje de programación, de forma que el propio diseño de los ByteCodes era en cierta medida dependiente del lenjuage.

Además, llegado el momento, Sun se negó a hacer algunos cambios y ampliaciones propuestas por la Comunidad (aunque no tengo muy claro qué comunidad), que habrían hecho mucho más flexible la plataforma, diciendo algo así como "Es nuestro juguete y es como nosotros decimos, y ahora no vas a venir tú a decirnos cómo hacer las cosas".

Parte de ese diseño hacía imposible o al menos muy complicado/poco elegante programar con otros lenguajes para luego compilar a los ByteCodes de Java.

Así que los "ingenieros" de M$ cogieron la idea, hicieron un par de mejoras, añadieron un par de intrucciones al "ensamblador" de la Máquina Virtual, crearon un API que englobara otras cosas de forma unificada, se montaron una estrategia de negocio alrededor, y voilá.

Por eso dice Miguel que cuando lo vieron les gustó.

Me aburre profundamente la gente, cada vez más abundante en barrapunto por desgracia, que se dedica a despreciar y desprestigiar el enorme trabajo de los demás.

Pasa con GNOME, pasa con KDE (menos, pero pasa), pasa con Debian, pasa con Linux (los BSDeros) y ahora pasa con Mono.

Os recuerdo, queridos amiguitos, que Mono es un proyecto 100% SOFTWARE LIBRE. Y una de las libertades básicas que nos ofrece el software libre es la libertad de ejecución. Libertad para usar un software, pero también libertad para no usarlo. Lo que me parece muy mal es tratar de desprestigiar el trabajo de tanta gente, con acusaciones ridículas y sin fundamento (.net/mono no aporta nada, .net/mono es lento, .net/mono es una conjura judeo-masónica para arrastrar a los usuarios de software libre al mundo windows, etc, etc).

A quien no le guste Mono, que no lo use, así de simple. El día que alguien me diga que ha hecho en pocos meses un compilador, una biblioteca de clases como la de Mono y unos bindings de GTK, le escucharé todo lo que tenga que decir.

Y aquí os dejo dos comparativas JVM-JIT para los que decís que .NET va más lento que Java:

Una (PDF)
Otra

Cuando me refiero a interoperar, me refiero no solo a que puedes hacer una llamada de una función desde VB echa en VC, sino a que puedes heredar todo el código de un lenguaja a otro sin problemas

Python te permite heredar objetos C++ (con una librería) y viceversa (con Boost::Python). Con otras librerías puedes incluso meter directamente código C entre el código Python. De todas formas el C++, Lisp, Python etc para el .NET son sólo versiones recortadas de 'los originales' que pierden algunas de sus características más importantes (sobre todo los lenguajes más dinámicos) y que no son _para nada_ compatibles con los estándares.

La productividad es la de siempre (o peor, hasta que la gente se acostumbre la biblioteca de clases y a sus truquillos). Ni más ni menos que la de java.

Eso será porque o bien no conoces bien las librerías Java/C++/Python de las que dispones o puedes disponer con buscar un poco o porque no has encontrado un buen entorno para ellos (o combinación de las anteriores).

En pyton o en c, se pueden hacer webservices?, webforms?

Tu no conoces Zope ¿verdad? Se nota (mucho).

acceso a BD?, XML?.

En Python por supuesto, desde la librería estándar, y con dos parsers distintos para elegir (en el caso de XML).

En fin, que no es la panacea, pero es una tecnologia moderna...

...que no aporta nada nuevo...

tiene mucho futuro por delante, algo que los lenguajes de hace un lustro no tienen.

En lo de que tenga futuro estamos de acuerdo, pero no por sus virtudes sino por la publicidad que le va a hacer el Imperio. Que Python(Java y otros no tengan futuro... bastante más que tu como visionario, seguro.

  La relevancia de C++ es muy poca en toda esta discusión. Es un C
mejorado, pero tiene los mismos problemas de C: es un lenguaje de bajo
nivel, sin protecciones, sin recolección de basura y con APIs que no
necesariamente funcionan en ambientes multi-hilo. Eso si, tiene
objetos.


Basura basura basura. Hoy en día, salvo Java, C++ es el mejor lenguaje para hacer aplicaciones multihilo, como demuestran tantas y tantas aplicaciones (entorno KDE, Star Office, etc). C++ es más estricto con los tipos y el compilador capta muchísimos más errores que C. Como me imagino que cuando dice 'sin protecciones' se refiere al pequeño infierno de las cadenas y los punteros en C, nadie en su sano juicio hoy en día desarrolla aplicaciones grandes en C++ sin utilizar algún objeto de tipo String (sea de la STL, sea de las Qt, etc). Idem para el resto de tipos de datos. C++ te da la libertad de tener recolector de basura _si quieres_ (al igual que C, aunque al parecer Miguel no lo sepa), y además new/delete y demás hacen mucho más sencilla la gestión de memoria que free()/malloc() en C.

Y sí, tiene objetos, y plantillas, y tipos de datos complejos y abstractos, y...

C++ es desgraciadamente un lenguaje complicado y crea código que es
difícil de mantener si no se usan reglas estrictas de programación.

Traducción: C++ expone a los malos programadores más fácilmente que C. ¿Es eso malo? ¿Es C más fácil de mantener que C++? ¿Más fácil de entender? Vamos hombre...

Un buen proyecto en C++ con un buen diseño (como casi todos los programas del entorno KDE) es increíblemente fácil de entender, de hecho yo, que en algunas ocasiones he mandado parches a algunos proyectos, el que mejor he entendido hasta ahora, por su excelento diseño ha sido KVIrc3, un tochón de varios cientos de miles de líneas, pero tan bien organizadas que entender la arquitectura del mismo es casi como leer un libro. Un buen código C++, de buenos programadores, es casi tan facil de entender como Python, pues rápidamente se reduce a sucesiones de llamadas a métodos de objetos muy definidos (dentro de las condicionales/repetitivas etc, por supuesto), y a la definición de esos objetos a partir de otros.

. Creo que nadie duda aquí que se desarrolla mucho más rápido en Java que en C++, verdad? (que solo respondan aquellos que han hecho aplicaciones de más de 1000 líneas en ambos)

Buenos días, soy el discutidor, y sí, he escrito más de 1000 líneas en ambos lenguajes (aunque reconozco que bastante más en C++, pero tuve mi vena Java...) :)

Con una buena librería de tipos de datos (STL, y usándola claro), y otra de red/bases de datos/widgets/más tipos de datos (como Qt) te aseguro que la diferencia no es tanta. Todo depende de lo que hagas, por supuesto, para algunas (muchas) cosas Java tiene mucha mejor librería que C++, aún con las Qt, y en aplicaciones que necesiten de ello (a pesar de que no suele ser dificil encontrar el equivalente C++ buscando un poco) el desarrollo va a ser más rápido, pero por ejemplo yo te aseguro que me encuentro mucho (¡muchísimo!) más cómodo desarrollando una interfaz gráfica internacionalizada con Qt[designer/translator/etc] que con sus alternativas (Swing) en Java. Así que todo es relativo, pero sí, concedo que _en general_ suele ser más rápido Java, pero no siempre ;)

Totalmente de acuerdo (soy informático, aunque aún no me considero un semidiós ;) La programación debería considerarse una herramienta, como las matemáticas, intentar limitar su uso a informáticos sería como limitar las matemáticas a los matemáticos; desde el equipo de informáticos/físicos/industriales/etc que realiza un proyecto complejo para informatizar una central nuclear hasta el ama de casa que se hace un script para bajarse recetas cada cierto tiempo la programación es para todos. El problema viene cuando proyectos que por su tamaño o importancia requerirían de varias personas y un ciclo de análisis/diseño/implementación/prueba se contrata a un chapucillas con un curso de INEM que se salta las fases uno, dos y cuatro (vamos que como suele decirse utiliza la infame metodología de 'programo y miro a ver que pasa'), porque 'Visual Basic es muy fácil', algo cada vez más común.

El bytecode de .NET está tan orientado a C# como el de java a java y sino mira las características que pierden otros lenguajes como C++, Python o Lisp cuando tienes que compilarlos a .NET. Por cierto, que también hay compiladores de C y de muchos otros lenguajes que generan bytecode Java, además de existir una versión de Python (Jython) 100% compatible con Java, así que no veo donde está la ventaja (salvo en la publicidad). Miguel debería enterarse mejor, y no sólo leerse la publicidad de M$.

La idea básica que está detrás de .NET es la de servicios web, es decir, yo pongo una máquina en inet y "abro" una serie de puertos para que tanto los usuarios con su navegador web como los programas puedan interactuar con mis aplicaciones. Hasta ahora las "aplicaciones" que estan funcionando en inet no son más que un conjunto de páginas html y algunos scripts, con este sistema tenemos aplicaciones reales que son capaces de transmitir datos via tcp/ip. Todo lo demás son adornos y marketing para vender el producto.

Perdona.

Un ""servicio web"", tal y como me lo explicaron en una conferencia de asp.net a la que acudí (y de la cual no obtuve muy buena imagen, como os imaginaréis), me explicaron claramente qué es un servicio web (más que nada, porque lo pregunté):

Un servicio web es una página XML, transmitida por el puerto 80, que encapsula, mediante soap, un nombre de variable y su valor (o varios nombres de variable, y varios valores).

Vamos, que significa poner *otra* capa encima de una aplicación que ahora mismo envie/reciba datos por el puerto 80.

A ver, por un gallifante, ¿quién me dice una ventaja de esto?

me puedes decir cuales de las bondades que le atribuyes a .NET no existen en la plataforma J2EE

En realidad una sola, en .NET han introducido un "lenguaje" intermedio entre el fuente y los bytes codes de forma que tú puedes escribir una biblioteca de clases en un lenguaje y utilizarla desde otro. Incluso escribir media biblioteca de clases en un lenguaje y media en otro. En realidad ni siquiera es una idea original, es la implementación de la solución lo que merece la pena.

Para el que dude que esto tenga alguna utilidad, pensad en las miles de clases (funciones) que hay hechas en uno y otro lenguaje, en una y otra biblioteca y que hacen lo mismo. En .NET esto sería inecesario, se hace una vez y la utilizas en tu proyecto sea cual sea el lenguaje.

¿Cuál es la diferencia entre mono y dot gnu?

No te confundas, aquí no se menosprecia el trabajo de nadie (al menos por mi parte) pero sí se cuestiona, que me parece muy sano :)

Tampoco creo haberme referido a Mono en ningún momento sino a la plataforma .NET que es muy distinto.

Icaza, Ximian y muchos otros voluntarios han aportado grandes cosas al Software Libre por lo que les estoy muy agradecido, pero que respete su trabajo no quiere decir que tenga que estar de acuerdo con el.

Saludos.

Tal vez nuestro amigo Joel pueda añadir alguna luz sobre el asunto. Os recomiendo encarecidamente su artículo Disparar y Avanzar que además ha traducido un buen conocido mío. :-P

Así sin pensarlo mucho las ventajas que se me ocurre es la simplificación y estandarización de la comununicación entre aplicaciones, que no es poco. Lo genial de estas cosas está en lo sencillo que es. De todos modos esto no es nada exclusivo de .NET. También lo implementan en el J2EE de Java y seguro que otras muchas aplicaciones hacen cosas por el estilo. La verdad es que no sé tanto de programación distribuida como para saber como se comunican las aplicaciones CORBA y COM... quizás alguién más ilustrado nos ilumine :)

No dependes de microsoft en ningun caso, solo si usas la plataforma de MS, dependes de MS, es como decir que si usas C++ dependes de AT&T

Y lo que no se realizaran extensiones o mejoras a .NET.... ¿donde lo has leido? por que la actitud no es esa. Solo se mantendra la compatibilidad mientras se pueda, pero eso no significa que no se extienda la plataforma. Gtk# (y Glade, gda ...) Mono.* y otros conjuntos de clases y proyectos son ejemplos de ello.

Me refiero a lo de conseguir pasar como callback un miembro de una clase, hace algun tiempo estuve haciendo pruebas y no lo consegui. Resulto problematico porque intente amoldarme a la POO todo lo que pude y en mi aplicacion todo era clases salvo el obligatorio main que "simplemente" creaba el objeto correspondiente a la aplicacion e iniciaba su ejecucion. He intentado todo tipo de conversiones, pero al final me toco sacar el metodo de la clase para pasarlo como callback (o retrollamada).Te estaria muy agradecido si me dijeses cuales son esos truquillos. :)

tcp/ip es un protocolo de transmision de datos, que realiza funciones semejantes a las de netbios. Pero com+ y rpc no tienen nada que ver con ellos, y por lo tanto no pueden ser sustituidos por tcp/ip.

.NET esta soportada desde un monton de lenguajes, incluidos C++, VB y C#, no te obligan a aprender ningun otro lenguaje.

En lo que coincido totalmente contigo es que las charlas que da MS son propias de comerciales charlatanes, no tecnicos. Usan ese tipo de discurso que me hace tanta gracia: te dicen que su producto/tecnologia es mas X (donde x es eficiente, compatible, estable, escalable, etc..) que los demas, pero no te dicen porque. Es como llamar a una ley de la enseñanza "ley de calidad", ¿que pasa?¿que el resto de las leyes de enseñanza no tenian como objetivo la calidad de la misma?.

Todos los lenguajes que pueden trabajar sobre .NET se ejecutan sobre una Runtime Library, que es independiente de las caracteristicas del lenguaje desde el que se haya compilado. Por lo tanto no pierden nada, sino no habria dios que portara una aplicacion a el, y esto ultimo es un objetivo primordial de dicha plataforma.

Evidentemente puedes generar bytecodes de java desde cualquier lenguaje, pero es como si generas codigo java desde otro lenguaje, y eso ademas de muy poco eficiente es bastante poco elegante.

Miguel esta realizando una "implementacion" alternativa de .NET a la de MS, asi que yo creo que si sabe cuales son sus virtudes y defectos. No creo que la comunidad Gnome de un salto de esa categoria asi como asi.

No se tu, pero yo prefiero evitar las complicaciones cuando son innecesarias. No se trata de que alguien cree una aplicacion que programe por notrosos, se trata de que nos ayude. Parece que por usar Glade para crear interfaces graficos en vez de trabajar a piñon, o Rational Rose para generar el esqueleto de una aplicacion en c++ ya no se es programador.

¿Te esta evitando .NET usar el lenguaje que tu quieras?. No. Puedes elegir el lenguaje, y esa es una de las grandes diferencias entre j2ee y .net. Ligar a una plataforma un lenguaje de programacion es una aberracion. En .net eliges el lenguaje que mas se adapte a tus gustos y necesidades. Sin embargo j2ee es una tecnologia creada alrededor de java, con las consecuencias que conlleva.

Por otro lado los webservices poco tienen que ver con CORBA. Quizas para ti conocer CORBA es saber hacer una llamada. Nada mas lejos de la realidad.

Por cierto, usar XML para encapsular binarios no tiene porque ser tan ineficiente como tu comentas. De hecho nada te quita de que a cierto nivel ese XML se codifique a binario para reducir su tamaño.

No digo que .NET me parezca superior a j2ee, solo digo que cada uno tiene sus virtudes y no conviene menospreciarlos solo por la mano de quien vienen. Lo que si creo es que el mayor defecto (en mi opinion) de j2ee es tener a java como tecnologia unificadora, sobre todo dado lo "limitado" del uso de ese lenguaje. Limitado en el sentido que hay muchas plataformas que apenas hacen uso de el, win32 o unixes por ejemplo, y en nuestro caso GNU/Linux.

Excelente tandem el que forman Qt/Kde3, muy buena plataforma de desarrollo.

Para los que busquen librerías C++ potentes para multihilo, además de para infinidad de muchas otras cosas: Boost. Encima es libre (en realidad de dominio público). Fastuosa. Boost+STL+Qt ¿Quién necesita más? :)

Yo sigo sin ver por qué tanto revuelo por .NET (será por mi perfil de acerrimo programador de C++ y Python :-)) , pero te animo a que al menos le eches un vistazo a C#. No es que sea la bomba de neutrones de la programación pero tiene sus cosas buenas.

Tu perfil es igual que el mío. No me he lanzado sobre C# principalmente porque no he tenido la combinación adecuada de tiempo/interés, lo segundo motivado principalmente porque como lenguaje de tipo C (en la síntaxis y filosofía) con muchas mejoras ya tengo C++ que es mucho más rápido que C# y en realidad casi igualmente portable (con las librerías adecuadas y teniendo la portabilidad en mente desde el principio) y como lenguaje dinámico interpretado e increiblemente productivo ya tengo Python. De todas formas me lo miraré más a fondo, como lenguaje (que es lo que me interesa), más que como plataforma.


Por cierto, ¿qué tal va el animail?, aquello de los archivos de configuración ¿cuajó? :-)


Bueno, va por la 2.0-pre5, para la 2.0 sólo me queda hacer que funcione con los malditos M$ Exchange en modo IMAP (ya sabes, siempre van contra corriente :) y a ser posible que no haya bugs nuevos, de momento no se me ha notificado ninguno sobre esta versión (y arreglé todos los que conocía anteriores). Como firmas como anónimo no se exactamente quien eres, ni puedo identificarte por lo de los archivos de configuración (porque he tenido varias sugerencias con respecto a ellos de bastantes personas) pero, sin usar XML, han cambiado mucho de los de las series 1.0, es más flexible, y bastante más complicado que usuarios torpones cometan zarpazos al crearlos y luego me lo manden como bug ;) (en realidad si el usuario se equivocaba mucho con el fichero de configuración realmente era un bug de diseño de los mismos, así que los hice más fáciles y el parser bastante más 'listo').

Saludoxxxxxxx.

Me ha gustado el artículo, más la primera parte que la segunda ("Sí, jefe. Puede que parezca que leyendo Barrapunto estoy perdiendo el tiempo, pero, en realidad, estoy siguiendo la gestión de tiempo de uno de los máximos guruses del sofgüer.").
La traducción también parece bastante hábil. No he comparado mucho, pero se maneja bien con los coloquialismos de Joel. Felícitale.

...todas las condiciones de error se manejan de forma uniforme por excepciones

Desde luego, ahí tienes toda la razón, una vez que has aprendido a controlar tu código mediante excepciones en un lenguaje que las soporte bien como Python o Java volver a programar sin ellas es un algo doloroso.

  Aunque, dicho sea de paso, me parece aberrante que las señales en Qt sean punteros constantes a char (¿dónde queda el tipado estricto ahí?).

Bueno, que la biblioteca por debajo las implemente utilizando const char* al programador no le debe importar mucho mientras las declare como métodos dentro del objeto que tiene que lanzarlas, cuando necesite una nueva, utilice las funciones que lanzan las estándar, cuando necesite una de este tipo, y use ambas en los emit() y en los conectores. No se como va la cosa en C#, de todas formas.

Sobre las excepciones, y ya que viene al caso con el tema de los hilos en C++: ¿has probado a arrojar una excepción desde un método que corra en un hilo en C++?

No, con la librería adecuada, por ejemplo Boost::thread:

Boost::thread

En concreto mírate esto: http://www.boost.org/libs/thread/doc/exceptions.ht ml.

Muchas veces pienso que nadie debería saber programar C++ sin conocer esta librería. Además, todos los elementos de ella son 'proposed standarts'. Ahora mismo no se decirte si el módulo thread de las Qt permite excepciones pero vamos, no sólo está Boost, hay más librerías.


  Para que me situes, soy Jorge, el colgado de la primera y cutre implementación multihilo de animail (hallá por la versión 1.52, creo :-). El que te mando el parser XML en SAX y lo de los ficheros de configuración en python.


Muy buenas Alcalaino :)
De momento, como te dije, no estoy usando XML para los ficheros de configuración porque son algo más engorrosos de editar, y la mayoría de la gente sigue configurando el Animail editándolos directamente, así que de momento sigo con lo que tengo ahora (como te digo, bastante evolucionado con respecto a lo de la 1.0). El multihilo de la 2.0 funciona de vicio :) aunque he hecho algunos cambios menores, principalmente utilizar los hilos del módulo threading, de más alto nivel y más cómodos y alguna que otra cosilla más.

El ¿problema? con las señales en Qt está en el QObject::connect()/disconnect(). Cuando conectas unb slot a una señal simplemente le pasas a connect() el nombre de la señal en una cadena (porque eso hace la macro SIGNAL()), entonces ¿qué pasa si lo tecleamos mal ("clcked()", en vez de "clicked()", por ejemplo)?, la señal sigue siendo "válida" (esperamos una cadena de car. y una cadena es), el compilador se lo traga y el error tipográfico no se detecta hasta tiempo de ejecución. Pasa lo mismo en GTK+.

Pues es verdad, acabo de probarlo y así es, hasta que no lo ejecutas no peta. Tienes razón en lo de que es imperdonable en este caso (aunque la verdad es que yo nunca he tenido un error por ese motivo). De todas formas, por lo que ahora veo las Qt me 'chivan':

QObject::connect: No such signal QLineEdit::returnPPressed()
QObject::connect: (sender name: 'unnamed')
QObject::connect: (receiver name: 'channelsjoin')

Con lo que debería quedar bastante clara la cosa, pero claro, hace falta que alguien vea el error.

Vamos, que no cuela: sigues teniendo el mismo problema: una excepción salta y el hilo termina (de forma limpia), pero no puedes manejar el error con un catch porque no te llega la excepción que acabó con el hilo

Bueno, pero lo correcto (creo yo) al programar hilos con excepciones sería intentar capturar las posibles excepciones lanzadas desde dentro del propio hilo, y nunca dejar que se propaguen fuera (de hecho la librería Boost:threads te advierte muy seriamente de que captures todas las excepciones desde dentro), sino un bonito programa multihilo se puede convertir en una bonita chapuza multi-espaguetti. Por supuesto puede haber casos en los que interese que se propague.


Por otro lado, la biblioteca es espectacular, y no la conocía. Me acabo de convertir a Boost ;-)

Pues si quieres disfrutar como un enano mírate (si no lo has hecho ya) Boost.Python o 'como usar clases escritas en C++ desde Python como si fueran nativas' (heredándolas, modificándolas, etc). Yo voy a escribir la opción de 'scriptar' el kvirc (3.argo o 4, que la 3.0 va a salir ya) con Python usándola. También para mejorar el rendimiento de los programas Python, aquí tienes un JIT para Python en ciernes: http://psyco.sf.net, aunque no he hecho pruebas serias de rendimiento con el mismo (aún), otros hablan bastante bien de él (http://groups.google.com/groups?th=d85d63a710c536 07)


(Pasaté alguna vez por Alcalá y te enseñamos el chiringuito :-))

Dame tu telefono al email y un día te doy un toque.

Vamos a ver, el que un lenguaje como c# no soporte herencia multiple no quiere decir nada, dado que todos los lenguajes se compilan a los "bytecodes" de la CLI, la cual a diferencia de la JVM es generica para cualquier lenguaje. La cual es independiente del lenguaje.

De hecho con c puedes emular todas las caracteristicas de c++, y evidentemente c no tiene herencia multiple. Idem del manejo de estructuras de datos complejas como los struct de c cuando compilas a maquina, y eso que el procesador solo conoce tipos basicos.

Una empresa del calibre de MS no cometeria un error como capar una plataforma impidiendo que se puedan importar otras aplicaciones en otro lenguajes. Ademas, si ya hay compilador de c++ para .net, no hay que darle mas vueltas.