Recomendadme un libro de C

Pues el kernighan y ritchie es todo un clásico y además lo encuentras en castellano sin problemas.
http://cm.bell-labs.com/cm/cs/cbook/

Saludos

La colección de "Aprenda ... como si estuviera en primero" está bastante bien, pero eso sí, tendrías que imprimir y encuadernar (creo que no se venden):

http://www.tayuda.com/ayudainf/aprendainf/programacion.htm

Curso de programación de C/C++ de Fco. Javier Ceballos
Editorial Ra-Ma
ISBN:8478972005
Precio de 1997: 4995 ptas.

Te lleva de menos a más. Sirve tanto para iniciarse como para asentar conocimientos (para esto último me lo compré yo, que lo tenía oxidado).Tiene muchos ejemplos y muy explicados. De C++ sólo hace referencias porque este libro tiene dos continuaciones, una para C++ y otra para VC++. Se centra en el C estándar y hace referencias a las librerías para DOS o Unix, y me pareció que estructuraba mucho las cosas, algo que necesitaba.

El de Ritchie que dice Raharu es un "must read".

Saludos.

bpeople escribió:Curso de programación de C/C++ de Fco. Javier Ceballos

Fué mi primer libro de C++. Tengo la primera edición... brutal, el más didáctico en castellano. Lo explica muy muy bien.

[tadoramo][tadoramo][tadoramo]Ceballos[tadoramo][tadoramo][tadoramo][tadoramo]

bpeople escribió:El de Ritchie que dice Raharu es un "must read".

if if... pero sinceramente, Ceballos... es mucho Ceballos.

Por cieto, tiene dos libros sobre C/C++: el que ha citado bpeople, que curiosamente SÓLO enseña C, pero al ser la misma base para C++... y el segundo que es exclusivamente de C++.

Hiper-recomendados los dos. Que decir que forman parte desde hace tiempo de mi biblioteca particular.

Saludos!

POR FAVOR señores, ha dicho uno basico, no uno para avanzados, el del sr ceballos es una MIERDA,xD, asi de claro, anda que el tio tiene arte, te lia mucho, hasta mi cuñado que es programador profesional me dijo que era malisimo el libro, tuve que comprarme otro para aprender.

Yo te recomiendo a ti como he recomendado a muchos y todos han comprado ese libro y estan contentisimos y aprendieron mucho sobre todo, es el del sr Herbert Schildt(de los mejorcitos del mundo

C, guia de la autoenseñanza, editorial MC-GRAW Hill

Te lo explica todo paso a paso, y de una forma PERFECTA, ejemplos y ejercicios por cada seccion, y al final de cada tema te pone mas ejercicios, esta MUY bien, te lo recomiendo.

Un saludo

Fox escribió:POR FAVOR señores, ha dicho uno basico, no uno para avanzados, el del sr ceballos es una MIERDA,xD, asi de claro, anda que el tio tiene arte, te lia mucho, hasta mi cuñado que es programador profesional me dijo que era malisimo el libro, tuve que comprarme otro para aprender.

PERO SERÁ SACRÍLEGO!

Que ni tu ni tu cuñado llegueis, no significa que sea malo.

Tenía 15 años cuando me lo compré, y aprendí muy rápido con él.

Lo que hay que oir.

Saludos

P.D. no os fieis de nadie al que le guste .NET de M$

El nivel de ese libro lo sobrepaso y mi cuñado con creces ya que es profesional y gana pasta programando para empresas, solo quiero decir que es un nivel alto para principiante aparte de que se explica con la parte con la cual se sienta.

Quizas te resulto facil, pero si lees el que te dije flipas de lo sencillo que es.

Y .NET es hoy por hoy lo mejorcito

Y .NET es hoy por hoy lo mejorcito

Supongo que podrás argumentar eso.

Saludos.Ferdy

Cuidadito con los flames que aquí los ánimos se calientan en nada

De todos modos a mi no me ha convencido nada ningún libro de los que he leido. La mayor parte se centran en el lenguaje y no en los conceptos. Yo creo que paralelamente a aprender a usar la herramienta que es el lenguaje de programación hay que aprender a usar otras herramientas como unos conceptillos mínimos de ingeniería del software y unos de algoritmia (complejidades... )

Aunque es menos vistoso ya que te metes mucho en terreno abstracto creo que es mucho más productivo y se cojen hábitos buenos.

Muchas gracias a todos por contestar, he visto el de Ra-Ma pero me parecia mas bien indicado para alguien con algun que otro conocimiento de programación. Finalmente me he decidido por uno de Anaya que tiene muy buena pinta y todo muy bien detallado, una vez lo termine, me pillaré otro un poco mas extenso para reforzar.

Gracias

.NET tiene un potencial que te cagas, y facilita el desarrollo de aplicaciones que no te lo puedes ni creer. No sabes lo fácil que resulta hacer un acceso a una BD y hacer un binding de esos datos a controles.
Por no hablar de otras lindezas como Web Services o tener un framework común para desarrollar aplicaciones de escritorio y dispositivos móviles (PDAs, SsmartPhones)


Si tanto preocupa que sea de MS apoyad el proyecto MONO y todos felices, pero recordad que C# y el CRL son estándares (no son de MS, vamos)

Un colega mío linuxero que te cagas le encanta C# y a mi me está empezando a alegrar la vida, ahora está intentando rular WinForms en Mono xD

Ahora a ver los argumentos de por que no es de lo mejorcito

Del Fco leí un sólo libro, y lo dejé de leer cuando vi lo enrevesado que era en algunas -bastantes- cosas. Pero sobre todo lo dejé de leer cuando vi la sentencia:
flush(stdin);

Si eso es C estandar que baje diox y lo vea.


¿Libro para aprender?
Didácticamente está bastante bien el de "Como programar C y C++" Deitel&Deitel, el problema es que enseña primero C y luego C++, pero de forma muy prática. El otro problema es que no se cómo de jorobado será pillar esa edición, ya que la que editan ahora es "Como programar C++" que empieza con C++ y POO directamente.
Otro problema de ese libro es que la traducción es en español neutro (te encontrarás con cosas como arreglos y apuntadores, en vez de vectores/arrays y punteros)

¿Libro para saber? El de K&R que ya te han dicho.[

*sigh*

The fflush() function conforms to ISO/IEC 9899:1990 (``ISO C89'')

Sobre lo de .NET decir que es distinto de Mono. Mono no me importa... no es muy portable; pero extremadamente más portable que .NET claro. Por ahora ninguno de los dos gana en portabilidad a C.

Saludos.Ferdy

Yo de C tengo un libro (bastante viejo, es de mi padre) pero que lo explica todo mu bin (incluye dibujitos graciosos ke facilitan las cosas y tal) se llama "Programación en C. Introducción y conceptos avanzados." de m.Waite/S.Prata/D.Martin.
La editorial es Anaya multimedia.

Yo ahora mismo estoy en primero de carrera y excepto por lo que dicen por ahí arriba de cálculo de complejidades lo cubre todo perfectamente (bueno, por lo menos lo que yo uso).

Yo creo que es un libro muy bueno para empezar.

Rurouni escribió:Fué mi primer libro de C++. Tengo la primera edición... brutal, el más didáctico en castellano. Lo explica muy muy bien.

Yo tengo también la 1ª edición, del año 97. He visto por ahí la última edición, creo de 2004, y trae un CD, supongo con los ejemplos.

Rurouni escribió:Por cieto, tiene dos libros sobre C/C++: el que ha citado bpeople, que curiosamente SÓLO enseña C, pero al ser la misma base para C++... y el segundo que es exclusivamente de C++.

Hiper-recomendados los dos. Que decir que forman parte desde hace tiempo de mi biblioteca particular.

Yo tengo esos dos, porque el tercero de Visual C++ no me ha interesado nunca.

Respecto a lo de si es enrevesado o no, yo no lo vi así cuando me puse con él (hace 8 años), aunque yo ya me había leído otros libros y había hecho algunos programas.

Esto de recomendar un libro para iniciarse en C no es tan fácil como recomendar una distro para empezar xDDD.

Saludos.

Todos esos libros que te han dicho estan muy bien, aunque deberias de echar un vistazo al que te dije.


Sobre mono es muuuuuuuy portable, yo he pasado codigo de un sistma a otro y funciona perfecto, he pasado codigo compilado y tambien, lo unico que falla es windows forms pero eso aun lo estan implementando.

Si quieres mas detalles, /query _Neji en gentoo-es ferdy PP

Yo tengo algunos libros por aqui de programacion pero jamas me ha dado por echarles un vistazo, me gusta mas tirar de la documentacion que hay por la red.

Una de las paginas que me sirvieron bastante para empezar con C y comprenderlo un poco mejor es "Elrincondelc.com" en la cual hay un curso que puedes leer online o bajartelo al ordenador creado por Gorka Urrutia y esta bastante bien desde mi punto de vista.
Te dejo el enlace por si te intereza.

http://www.elrincondelc.com/cursoc/cursoc1.html

PD.: Igual hay portales con documentacion mas sencilla y completa que la del enlace que acabo de poner, si es asi, por favor posteadlas, seria de gran ayuda a mas de uno(me incluyo en ese grupo).

Saludos y suerte.
Demonix.

La verdad que yo quería algún librillo así tb... creo que iré a alguna librería en la que puedan tener varios de los nombrados, les echaré un vistazillo y elegiré.

Sobre todo quiero que lo que ponga sea ESTÁNDAR. Sí, con mayúsculas.

Sobre .NET... en fin, no me termina de convencer. Muchos me llamarán de todo, pero eso de que tenga una parte patentada... pues mira, no me mola un pelo!
Y encima por lo que he visto, ya empieza a haber esas excepciones que comentaba antes y esa teoría de "un mismo programa para cualquier sistema" comienza a no funcionar al 100%. Así que entre unas cosas y otras... no sé, no sé...

Un saludo!

P.D: Pero amos, que a Ferdy tampoco le gusta C++, . Por cierto, ya de paso ¿por qué sí ObjC y no C++? Es que de ObjC la verdad que no tengo ni idea... ni de qué va ni nada.

Porque ObjC es una forma limpia de añadir OO a C y C++ es 'un lenguaje nuevo'.

Saludos.Ferdy

¡Oig! Calla calla que Obj-C es mi nuevo amor. Una sitaxis limpita y que facilita hacer las cosas de una manera legible.

Solo le fataría que GNUStep estuviera más avanzado.

.NET tiene un potencial que te cagas, y facilita el desarrollo de aplicaciones que no te lo puedes ni creer. No sabes lo fácil que resulta hacer un acceso a una BD y hacer un binding de esos datos a controles.

Aaaarghhh... los enlaces a BD de .NET son de lo más cerdo que he visto. ADO.NET tiene buenas funcionalidades pero sigo diciendo que se podía hacer de una manera infinitamente más sencilla.

¿O te estás refiriendo al que con un par de clicks enlazas algo? Separemos porque eso no tiene nada que ver con .NET. Eso lo hace la IDE que es un producto completamente distinto

Por no hablar de otras lindezas como Web Services o tener un framework común para desarrollar aplicaciones de escritorio y dispositivos móviles (PDAs, SsmartPhones)

Hombre, eso existe desde toda la vida porque las PDAs antes se programaban en C también. Vamos, nada nuevo bajo el sol. En todo caso que las funciones se llaman igual y ni así porque si pretendes hacer algo que funcione en productos de varios fabricantes puedes echarte a temblar. Te lo digo yo que he estado haciendo unos programillas (poco más que demos técnicas) para Palm y PocketPC y hacer que funcionaran en ambas es practicamente imposible sin hacer una capa dependiente de la plataforma.

Cosas por lo que no es lo mejorcito:

- Una gigantesca mentira: No es portable. A mi no me vale que saquen una cosa y digan que es portable todo menos la interfaz y si quieres ahi tienes la API para currartela que nosotros ya llevamos unos años currando sobre ella y además tenemos el control de facto sobre ella porque eso significa unos cuantos años de ventaja competitiva lo cual es una brecha insuperable. Aún así se están haciendo progresos pero nada de nada. Mientras no pueda cojer CUALQUIER aplicacion que se ejecute sobre .NET y la tire sobre un BSD no es portable....

- Por no hablar de que los web services no son portables.

- No ha ofrecido nada que Java no ofrezca salvando una IDE nueva.

- Una ventaja era que podias usar el mismo lenguaje para todo pero eso ya se podía hacer. Con java o con C mismo.

- El sevidor web es únicamente para windows y los mod que hay de apache funcionan como el culo.

- De facto solo hay una IDE. SharpDevelop y MonoDevelop tienen muuuuucho tiempo de retraso (y mira que sharpdevelop esta avanzado). Es como si yo voy con una pistola y tu con una red de gladiador y te digo que es un duelo con armas.

Gníiiiirg no tenía que contestar porque es un oftopicazo como un templo pero es que me pierdooooooo.

Me ha picado la curiosidad con lo de Obj-C y he estado mirando cosillas (si es que con tal de no estudiar...). La verdad que parece interesante por lo que decís, y por lo que he leído, junto con GNUStep y Cocoa se desarrollan aplicaciones bastante rápido... Pero, ¿tiene el mismo potencial que C/C++? Lo digo porque tanto C como C++ ya están muy trillados en todos los sistemas, son muy portables, y no sé si hay algo que se les resista y que en cambio sí ofrezca Obj-C. En otras palabras... tiene sentido programar en Obj-C si no vamos a programar para Mac?
Por lo que he visto, por ejemplo, no puede mezclarse con las librerías SDL (escritas en C, creo)... y están teniendo que desarrollar unas aparte para Obj-C lo cual retrasa bastante el tema... supongo que ese tipo de cosas serán el punto débil de Obj-C.

Y de C++... vale, lo puedes considerar un lenguaje distinto, pero... ¿es malo? ¿qué le falla? Lo digo porque últimamente oigo multitud de comentarios en que parece que C++ es una auténtica basura y que no sirve para nada ó siempre hay mejores opciones... ¿tan malo es?

Siento el offtopic... Por cierto ¿alguien puede recordarme qué parte estaba patentada de .NET?
Y coincido en todo con lo dicho por SickBoy. Mire por donde lo mire... veo .NEt más una trampa que una ventaja.

Un saludo!

FuckingFreaky escribió:Y de C++... vale, lo puedes considerar un lenguaje distinto, pero... ¿es malo? ¿qué le falla? Lo digo porque últimamente oigo multitud de comentarios en que parece que C++ es una auténtica basura y que no sirve para nada ó siempre hay mejores opciones... ¿tan malo es?

A KDE no le está yendo nada nada mal con C++ y QT, otra cosa es que a algunos no les guste el enfoque de escritorio gigantesco que están construyendo.

FuckingFreaky escribió:Siento el offtopic... Por cierto ¿alguien puede recordarme qué parte estaba patentada de .NET?

Lo tienes en la página de Mono:

http://www.mono-project.com/FAQ:_Licensing#Could_patents_be_used_to_completely_disable_Mono.3F

Lo que pasa es que hay quien ni siquiera está convencido de que las partes cubiertas por el ECMA estén completamente libres de riesgos. Claro, que hoy día tal y como está la cosa no hay nada libre de riesgo.

*sigh*

Efectivamente fflush() es estandar... lo que no es estandar, o mejor dicho, no está definido en el estándar, es aplicarlo a flujos de entrada.

Con el DataBind me estoy refiriendo a que con hacer una asignación enlazas algo a un DataGrid (por poner un ejemplo) una vez que lo has sacado de la BD con ADO.NET que es bastante fácil.

No se en que parte de mi mensaje dije que WindowsForms fuera portable, y menos en qué parte dije que era una ventaja. Es más, no recuerdo haber dicho que .NET fuera totalmente portable.

Al hablar de desarrollo en dispositivos móviles me refiero a que programas usando una interfaz similar, lo que es una ventaja. Claro que en PDAs y demás existían entornos de desarrollo y APIS aparte
Por cierto, estoy hablando de PDAs con el compacFramework, si quieres hacer aplicaciones para PPC y PALM normal que tengas que hacer una capa intermedia ya que estos últimos no implementan el CF.

Una ventaja era que podias usar el mismo lenguaje para todo pero eso ya se podía hacer. Con java o con C mismo.

No no, la ventaja es que aquí puedes mezclar lenguajes, que no es lo mismo. Eso no lo puedes hacer a no ser que te metas en otros berenjenales (COM y cosas así)

De facto solo hay una IDE. SharpDevelop y MonoDevelop tienen muuuuucho tiempo de retraso (y mira que sharpdevelop esta avanzado)

Hombre, es que estaría cojonudo que los mismos que proporcionan la plataforma no te dieran un entorno de desarrollo como dios manda. Es como si te hecho en cara que no hay versión de Windows de Anjuta... :S


.NET es lo que es y para lo que es: una plataforma de MS (léase orientada a Windows) para desarrollar aplicaciones de forma más fácil.


C++ es un lenguaje que hay que saber utilizar bastante bien, simplemente eso. Guarradas varias y código spaghetti lo puedes hacer con todos los lenguajes.

Guarradas varias y código spaghetti lo puedes hacer con todos los lenguajes.

Oh si, hasta en *#

Saludos.Ferdy

zheo escribió:Con el DataBind me estoy refiriendo a que con hacer una asignación enlazas algo a un DataGrid (por poner un ejemplo) una vez que lo has sacado de la BD con ADO.NET que es bastante fácil.

Ah vale. Pues si, eso está bastante bien. Demasiado ligado al entorno de ventanas que uses pero la idea subyacente está bien pensada.

Al hablar de desarrollo en dispositivos móviles me refiero a que programas usando una interfaz similar, lo que es una ventaja. Claro que en PDAs y demás existían entornos de desarrollo y APIS aparte
Por cierto, estoy hablando de PDAs con el compacFramework, si quieres hacer aplicaciones para PPC y PALM normal que tengas que hacer una capa intermedia ya que estos últimos no implementan el CF.

Entonces ¿en que quedamos? Si proporcionas una API común proporcionas una API común. Lo que no puedes es coger y decir que proporcionas una API común para tus productos porque entonces no es una API común. Es que TU API es coherente. Es algo que debería darse por supuesto. No veo la innovación por ninguna parte.

No no, la ventaja es que aquí puedes mezclar lenguajes, que no es lo mismo. Eso no lo puedes hacer a no ser que te metas en otros berenjenales (COM y cosas así)

Esta es una de las partes que menos me convence de .NET. Principalmente porque sigue la misma filosofía de desarrollo que muchas de sus aplicaciones: "Tu tira pa'lante que otro se va a comer la mierda". Mezclamos leguajes, mezclamos presentación con datos, mezclamos lo que haga falta con tal de que salga algo que se vea rápidamente. Luego el monstruo que salga lo va a depurar el tato.

Ya es un jaleo meterse con código que ha pasado por 4 manos previamente no me quiero imaginar lo que pasaría si encima usaran el lenguaje que les salga de los huevos.

No pido que la tecnología te haga organizado pero si que no te lo ponga a huevo para ser un desastre.

Hombre, es que estaría cojonudo que los mismos que proporcionan la plataforma no te dieran un entorno de desarrollo como dios manda. Es como si te hecho en cara que no hay versión de Windows de Anjuta... :S

Repito. Es una trampa y como tal la veo. ¿Salio Anjuta junto a C y a la vez que C? ¿Cuantas IDE hay para C? ¿Está C ligado a alguna IDE, toolkit, etc...?

.NET es lo que es y para lo que es: una plataforma de MS (léase orientada a Windows) para desarrollar aplicaciones de forma más fácil.

Pues lo dicho. Sigo sin coger las ventajas que tiene y porque es tan maravilloso.

- Mezclar lenguajes es una marranada desde el punto de vista de estilo. Porque ahora me vas a decir que es más legible un programa escrito en Python, Perl, C, C# y Java que uno en C++

- Lo de la facilidad de uso también lo veo un poco relativo. Tiene lo de los controles de presentación que dices y tal pero vamos... tampoco me parece la panacea. Que son funciones que, en cualquier plataforma con una sencillez de uso media te programas en un plisplas. Vamos que si esa es toda la facilidad que me dan...

- Solo tengo una plataforma para desarrollar. Eso me parece una enorme desventaja.

- Es un "cásate con nosotros de por vida" y no quiero casarme con nadie que no sea mi novia. . Todo son facilidades para entrar y todo son barreras de salida. Cuando se evalua un producto la facilidad para dejar de usarlo también es importante.


Y con todo esto sigo sin ver las enormes ventajas. No se, me parece uno más en la vorágine. En lugar de mejorar lo ya existente que tenemos que competir de verdad nos creamos un juego nuevo para así ir ganando. Solo veo eso.

SickBoy escribió:Entonces ¿en que quedamos? Si proporcionas una API común proporcionas una API común. Lo que no puedes es coger y decir que proporcionas una API común para tus productos porque entonces no es una API común. Es que TU API es coherente. Es algo que debería darse por supuesto. No veo la innovación por ninguna parte.

No estoy hablando de una API, sino de un mismo modelo de programación y un mismo entorno para todo. Tampoco digo que sea una gran innovación, simplemente es un paso en la dirección correcta.

SickBoy escribió:Esta es una de las partes que menos me convence de .NET. Principalmente porque sigue la misma filosofía de desarrollo que muchas de sus aplicaciones: "Tu tira pa'lante que otro se va a comer la mierda". Mezclamos leguajes, mezclamos presentación con datos, mezclamos lo que haga falta con tal de que salga algo que se vea rápidamente. Luego el monstruo que salga lo va a depurar el tato.

SickBoy escribió:- Mezclar lenguajes es una marranada desde el punto de vista de estilo. Porque ahora me vas a decir que es más legible un programa escrito en Python, Perl, C, C# y Java que uno en C++

Estas pensando en singular. En un grupo de desarrollo sería bastante factible tener diferentes modulos en diferentes lenguajes según la utilidad de ellos. No digo que debería ser una premisa de cara al diseño, pero es una opción más, nadie te obliga.
Y por ejemplo usar las extensiones administradas de C++ para aplicar un Facade a un módulo en C/C++ y así poder utilizarlo en un proyecto bajo .NET es bastante útil (aunque hay punteros por todas partes )

SickBoy escribió:Repito. Es una trampa y como tal la veo. ¿Salio Anjuta junto a C y a la vez que C? ¿Cuantas IDE hay para C? ¿Está C ligado a alguna IDE, toolkit, etc...?

Yo edito código en C# con el bloq de notas si hace falta y no hay problema, el caso es tener un editor que ayude. No hay tantos IDEs buenos para C aunque si hay muchos editores.
Con el tiempo existiran mejores IDEs.

SickBoy escribió: - Lo de la facilidad de uso también lo veo un poco relativo. Tiene lo de los controles de presentación que dices y tal pero vamos... tampoco me parece la panacea. Que son funciones que, en cualquier plataforma con una sencillez de uso media te programas en un plisplas. Vamos que si esa es toda la facilidad que me dan...

Yo lo veo más como un diseño mucho mejor y más cómodo. MFC también tenía asistentes, Intellisense y un editor, pero sólamente el paso de mensajes era un coñazo. Ahora es simplemente haciendo una asignación de una función a un evento.

SickBoy escribió: - Solo tengo una plataforma para desarrollar. Eso me parece una enorme desventaja.

De acuerdo, pero no fue pensado para ser multiplataforma, al menos lo que es windows Forms y similares.

SickBoy escribió:- Es un "cásate con nosotros de por vida" y no quiero casarme con nadie que no sea mi novia. . Todo son facilidades para entrar y todo son barreras de salida. Cuando se evalua un producto la facilidad para dejar de usarlo también es importante.

¿Y qué API no lo es?

SickBoy escribió:Y con todo esto sigo sin ver las enormes ventajas. No se, me parece uno más en la vorágine. En lugar de mejorar lo ya existente que tenemos que competir de verdad nos creamos un juego nuevo para así ir ganando. Solo veo eso.

Pues yo precisamente veo lo contrario: eso es una mejora sobre todo lo que había antes en Windows. Es mucho más cómodo y rápido de programar.

zheo escribió:No estoy hablando de una API, sino de un mismo modelo de programación y un mismo entorno para todo. Tampoco digo que sea una gran innovación, simplemente es un paso en la dirección correcta.

Que es la tendencia cierto pero de ahi a que sea correcto... No estoy yo tan convencido. Cada cosa tiene sus distintas necesidades y no se si será lo más indicado unificar plataformas distintas. Siempre decimos eso de "un operativo para cada necesidad" o un "lenguaje para cada necesidad" ¿no? Sencillamente creo que no existe ese idílico entorno que sirva para todo y que funcione bien. Siempre hay unas restricciones por las que no estoy dispuesto a pasar como por ejemplo el "todo es mio". Si seguimos así solo habría un fabricante.

Estas pensando en singular. En un grupo de desarrollo sería bastante factible tener diferentes modulos en diferentes lenguajes según la utilidad de ellos. No digo que debería ser una premisa de cara al diseño, pero es una opción más, nadie te obliga.
Y por ejemplo usar las extensiones administradas de C++ para aplicar un Facade a un módulo en C/C++ y así poder utilizarlo en un proyecto bajo .NET es bastante útil (aunque hay punteros por todas partes )

Al contrario. Estoy pensando en un grupo amplio con una relativa libertad y sigo viendo una locura. No consigo ver un proyecto en el que cada módulo sea de su padre y de su madre y luego, por ejemplo, el encargado de un modulo se ponga de baja.

Lo dicho nadie te obliga pero es un arma de reducción de costes de doble filo. Si, al principio puedes meter toda la mierda que quieras y tardas poco (por eso se usará) pero cuando lleves un tiempo la cosa se pondrá fea. Es lo de siempre. En lugar de ayudar a que se hagan las cosas como deben de hacerse se permite hacer lo que le salga a uno de los pies. Además es la típica cosa que se va volviendo una gran bola de nieve. Según vas metiendo más lenguajes volver atrás va siendo imposible.

Yo lo veo más como un diseño mucho mejor y más cómodo. MFC también tenía asistentes, Intellisense y un editor, pero sólamente el paso de mensajes era un coñazo. Ahora es simplemente haciendo una asignación de una función a un evento.

Joer. Es que vaya ejemplo. Si programabas MFC a pelo sinceramente eres un machote . Jamás pude con ello ni asistentes ni leches. Aquello era un infierno.

¿Y qué API no lo es?

Mira en ese sentido veo a QT o a GTK por ejemplo mucho más preparados para una huida a gran escala. Aunque es un potencial que nadie ha utilizado de momento. Por ejemplo porque los archivos generados con su constructor de interfaces son unos XML legibles a pelo que parseados correctamente podrían ser transformados para hacer una interfaz de cualquier cosa (ahora mismo no recuerdo los de VS ni si proporcionan alguna herramienta para la migración pero me suena que no y ahora mismo no tengo tiempo para comprobarlo). Digo potencialmente porque que yo sepa nadie ha tenido necesidad de hacerlo. Además si cambias de plataforma de servidor aunque no de toolkit la migración es muuuucho más fácil desde el punto de vista de las ventanas.

Evidentemente nada sustituye a un buen diseño para facilitar estas cosas pero se puede ayudar a hacer las cosas como se debe o se puede "dar más posibilidades".

Pues yo precisamente veo lo contrario: eso es una mejora sobre todo lo que había antes en Windows. Es mucho más cómodo y rápido de programar.

Supongo que si todo el espectro es Windows evidentemente mejora lo que había pero mirando más ampliamente sigo diciendo que no había necesidad de cambiar todo el bloque. Se necesitaba una mejora de interfaces de programación pero junto con ella nos meten muchas más cosas que hay que tragar.

P.D. : Joer, el que busque un libro de programación en C se va a cagar

SickBoy escribió:Que es la tendencia cierto pero de ahi a que sea correcto... No estoy yo tan convencido. Cada cosa tiene sus distintas necesidades y no se si será lo más indicado unificar plataformas distintas. Siempre decimos eso de "un operativo para cada necesidad" o un "lenguaje para cada necesidad" ¿no? Sencillamente creo que no existe ese idílico entorno que sirva para todo y que funcione bien. Siempre hay unas restricciones por las que no estoy dispuesto a pasar como por ejemplo el "todo es mio". Si seguimos así solo habría un fabricante.

Hombre, todo tiene que tomarse con límites. Por ejemplo esa idea está muy bien si tienes que desarrollar, por ejemplo, una aplicación cliente servidor que consulte una BD de un almacen para hacer el inventario con un PDA y wireless. El hecho de programar ambos sistemas de la misma manera es una facilidad de cara al aprendizaje.

SickBoy escribió:Al contrario. Estoy pensando en un grupo amplio con una relativa libertad y sigo viendo una locura. No consigo ver un proyecto en el que cada módulo sea de su padre y de su madre y luego, por ejemplo, el encargado de un modulo se ponga de baja.

Eso puede pasar en cualquier proyecto. Y dependiendo del programador de baja entender eso puede ser un percal o no.

SickBoy escribió:Lo dicho nadie te obliga pero es un arma de reducción de costes de doble filo. Si, al principio puedes meter toda la mierda que quieras y tardas poco (por eso se usará) pero cuando lleves un tiempo la cosa se pondrá fea. Es lo de siempre. En lugar de ayudar a que se hagan las cosas como deben de hacerse se permite hacer lo que le salga a uno de los pies. Además es la típica cosa que se va volviendo una gran bola de nieve. Según vas metiendo más lenguajes volver atrás va siendo imposible.

Como bien dices más adelante es cosa del diseño, y tiene que ser muy meditado. Los punteros también son peligrosos pero bien usados son necesarios.

SickBoy escribió:Joer. Es que vaya ejemplo. Si programabas MFC a pelo sinceramente eres un machote . Jamás pude con ello ni asistentes ni leches. Aquello era un infierno.

Juas, pues hay un libro en mi facultad que lo explica, a pelo, ni asistentes ni nada. :S
Sólo con asistentes hacer cualquier chorrada ya era un coñazo hasta que te habituabas... y después de habituarte también, ahora que lo pienso. xD

SickBoy escribió:Mira en ese sentido veo a QT o a GTK por ejemplo mucho más preparados para una huida a gran escala. Aunque es un potencial que nadie ha utilizado de momento. Por ejemplo porque los archivos generados con su constructor de interfaces son unos XML legibles a pelo que parseados correctamente podrían ser transformados para hacer una interfaz de cualquier cosa (ahora mismo no recuerdo los de VS ni si proporcionan alguna herramienta para la migración pero me suena que no y ahora mismo no tengo tiempo para comprobarlo). Digo potencialmente porque que yo sepa nadie ha tenido necesidad de hacerlo. Además si cambias de plataforma de servidor aunque no de toolkit la migración es muuuucho más fácil desde el punto de vista de las ventanas.

No conozco QT, no tengo experiencia en entornos multiplataforma y/o linux, básicamente porque no tengo tiempo. (SDL es lo único y no es entorno de ventanas )

SickBoy escribió:Supongo que si todo el espectro es Windows evidentemente mejora lo que había pero mirando más ampliamente sigo diciendo que no había necesidad de cambiar todo el bloque. Se necesitaba una mejora de interfaces de programación pero junto con ella nos meten muchas más cosas que hay que tragar.

Casi mejor que lo hagan de cero todo y dejarse de parches. Ojalá hicieran algo así en LongHorn (que no)

SickBoy escribió:P.D. : Joer, el que busque un libro de programación en C se va a cagar

Ya te digo :D

Viva Python.

Rurouni escribió:Viva Python.

xDDDDD

¡Festival del humor!

Bueno había escrito una respuesta más pero se me fue al carajo y ya estamos dando bastante la chapa

Además mañana tengo dos divertidos exámenes y estoy perdiendo pila de tiempo de estudio

Jejeje! SickBoy... eso nos pasa a muchos... cuánto más hay que estudiar, más te conectas ó pierdes el tiempo. Es una curiosa relación...

Por otra parte a mí me encantan estos hilos (que se discute pero no se calienta la cosa), aunque al final no sepa muy bien con qué quedarme, .

Supongo que por una parte .NET se utilizará mucho para desarrollar aplicaciones rápidamente, que al fin y al cabo es lo que interesa a las empresas... como pasaba ya con VB. Pero igual que tú... tampoco me convence demasiado a la larga eso de que se mezclen muchos lenguajes. Es un arma de doble filo. Por preguntar... .NET no puede pasar de su lenguaje intermedio generado primeramente a través de VB.NET, por ejemplo, a C#, no?

Esto me recuerda un poco a lo que decía RaUleX sobre la política de MS con este tema: yo programo multiplataforma, para mi plataforma. Jejeje! Al final aparecen incompatibilidades, cosillas que en un sitio sí, pero en otro no, embudos, limitaciones de cualquier tipo... En este sentido veo mejor a Mono ya que aunque tenga eso mismo, al ser soft libre, estará disponible perfectamente para todas las plataformas; cosa que .NET dudo que haga...

Además... es una cosa que no me cuadra. Esto se basa sobre una máquina virtual, pero se supone que es para dispositivos móviles. Y digo yo... con estos dispositivos de recursos limitados... no se ganaría más con lenguajes compilados? Ya que son limitados en potencia, ¿por qué hacerles cargar con una máquina que siempre será más lenta que un compilado? Pregunto, porque creo que tb se lleva haciendo con Java, y no entiendo mucho por qué, por ese motivo. Tirar de recursos en un HW en el que no sobran...

Por cierto, C# es sólo para .NET, verdad? Es decir... no se puede programar compilado con él... no?

Hale, a seguir el hilo!!! aunque quizá sería mejor abrir uno nuevo... no sé. Al menos la pregunta del libro quedó contestada .

Un saludo!

FuckingFreaky escribió:Jejeje! SickBoy... eso nos pasa a muchos... cuánto más hay que estudiar, más te conectas ó pierdes el tiempo. Es una curiosa relación...

Pensé que era el único al que le pasaba. A mi me da por leer libros como un loco en época de exámenes

FuckingFreaky escribió:Supongo que por una parte .NET se utilizará mucho para desarrollar aplicaciones rápidamente, que al fin y al cabo es lo que interesa a las empresas... como pasaba ya con VB.

Hombre, la verdad es que es un poco mejor que con VB

FuckingFreaky escribió:Pero igual que tú... tampoco me convence demasiado a la larga eso de que se mezclen muchos lenguajes. Es un arma de doble filo.

Os ha dao fuerte con eso. Es una ventaja. Claro que es un arma de doble filo. Y los punteros. Y los punteros a función. Y la herencia.

FuckingFreaky escribió:Por preguntar... .NET no puede pasar de su lenguaje intermedio generado primeramente a través de VB.NET, por ejemplo, a C#, no?

Que yo sepa no, pero sería algo interesante como proyecto.
Así de paso se vería que, da igual el lenguaje en el que programes el código final es el mismo, y aunque sea en diferentes lenguajes siempre te vas a tener que plegar a las especificaciones de .NET (ejemplo, programando en C++ con extensiones administradas no puedes tener herencia múltiple)

FuckingFreaky escribió:Además... es una cosa que no me cuadra. Esto se basa sobre una máquina virtual, pero se supone que es para dispositivos móviles. Y digo yo... con estos dispositivos de recursos limitados... no se ganaría más con lenguajes compilados? Ya que son limitados en potencia, ¿por qué hacerles cargar con una máquina que siempre será más lenta que un compilado? Pregunto, porque creo que tb se lleva haciendo con Java, y no entiendo mucho por qué, por ese motivo. Tirar de recursos en un HW en el que no sobran...

La MV de los dispositivos móviles siempre es una versión con mucha menos carga que su versión "grande", y por supuesto con menos funcionalidad, claro.
El porqué se hace así te lo explico con un ejemplo: imagina crear un mismo programa para varias series de móviles sin tener J2ME detrás, cada uno de los móviles con un hardware diferente...
Las ventajas son mayores que las desventajas.

En cualquier caso en PPC no tienes porqué usar el CF (compact framework de .NET), y de hecho hay cosas que éste no soporta. La ventaja es que puedes crear módulos que sirvan en versiones CF.NET y .NET, además de seguir como dije el mismo método de programación (misma forma de acceder a BD, de tratar la IU, etc)

Una de las ventajas de .NET es que puede precompilarse al menos parte del programa en la instalación según tengo entendido, sin embargo eso no puede hacerse en CF.NET según MS por limitaciones de espacio (maldita la gracia)

FuckingFreaky escribió:Por cierto, C# es sólo para .NET, verdad? Es decir... no se puede programar compilado con él... no?

Nop, aunque otro proyecto puede ser perfectamente un compilador para C#, ya que el lenguaje está estandarizado.

Un saludo

zheo escribió:Hombre, la verdad es que es un poco mejor que con VB

Hombre ya. Me refería a que es la misma manera de pensar en las empresas. La cosa es sacar el trabajo en el menor tiempo posible. La calidad de programación y demás, son secundarios. Por eso utiliza mucho VB, y por eso (que por supuesto es mejor que VB) se utilizará .NET.

zheo escribió:Os ha dao fuerte con eso. Es una ventaja. Claro que es un arma de doble filo. Y los punteros. Y los punteros a función. Y la herencia.

Ya, pero el caso es que alguien que sepa C++ debe saber esas cosas, por ejemplo. En cambio con .NET un tío que programe en VB.NET no tiene por qué saber C#. Al final, con proyectos grandes, se puede armar mucho pifostio, creo yo. Si estuviera lo que he dicho de poder pasar del código intermedio de .NET a cualquiera de los soportados, ya lo vería de otra forma. Así, cada uno programaría cómo más le gustara, y si dado un momento alguien quiere ese código generado por otro lenguaje, en el que él está acostumbrado, lo tendría. Desde luego, creo que eso sí sería un salto de calidad importante.

Sobre los móviles... sí, ya había pensado en eso; que con distinto hardware, mejor desarrollar para una MV. La pregunta que me digo (piensa que yo acabo de empezar con esto de la programación) es... esa MV se tendrá que compilar para ese hardware específico, no? Entonces... si ya se tiene un compilador, no se puede aprovechar para aplicaciones compiladas y programar eso en C/C++ por ejemplo?
Gracias por todas las explicaciones, desconocía eso del compact framework y demás .

zheo escribió:cita de FuckingFreaky:

Por cierto, C# es sólo para .NET, verdad? Es decir... no se puede programar compilado con él... no?

Nop, aunque otro proyecto puede ser perfectamente un compilador para C#, ya que el lenguaje está estandarizado.

Jeje, la verdad que si supiera y tuviera tiempo, me molaría lo de crear un módulo para pasar de un lenguaje a otro en Mono/.NET y un compilador para C#. He visto casi nada de ejemplos de C#, pero si no recuerdo mal era orientado a eventos tb, no? Es mejor, no tiene nada que ver, ó... cómo lo definirías respecto a C y C++?

Muchas gracias por todo. Sé que soy un poco coñazo... pero es que todos estos temas me encaaaaaaaaantan.

Un saludo!

P.D: Espero que no leas libros mientras posteas y estudias, porque eso ya sería una mezcla muy .NET .

FF que te liassssssss,xD

Lo bueno del codigo intermedio es por ejemplo, tu si programas VB.NET y yo C# y tu ahora haces un modulo de mmmmm facturas por ejemplo y yo lo queiro para mi y creo una clase derivada de la tuya en VB.NET pues se puede hacer perfectamente.

Conversores de codigo si que hay, al menos SharpDevelop trae uno, pero no se decirte como lo hace con proyectos grandes.

Y sobre que no hay codigo para C#....si dices eso mejor no entres a http://www.codeproject.com y vayas a las secciones de General C# y C# Windows forms(esto para win).

En esa web tienes muuuuuuuuuuchos articulos para hacer casi de todo y no solo C#, C++ y VB.NET, pero predomina C# para uqe mentir, se actualiza a diario tambien, a mi me gusta y ayuda mucho .

Un saludo.

PD: A mi tambien me encantan estos temas.

¿cómo puede gustaros tanto un lenguaje tan poco portable actualmente?

La cosa es hablar por hablar...

Si algo reciente y con tan buen sabor no se le da el apoyo que necesita nunca sera ni portable, ni usado y NUNCA sera nada, pero si a ese lenguaje se le da apoyo desde su nacimiento algun dia gracias a la gente puede llegar a ser GRANDE.

Contamos con la ayudas de personas como Miguel de Icaza que hace todo lo posible junto a sus compañeros de que .NET crezca bajo Linux y M$ por parte de windows.

Aunque sea originario de MS no puedo negar que es algo muy bueno.

Asi que Ferdy, si algun dia le dedicas una oportunidad y haces algunos programas en linux bajo mono leere tus criticas.

Un saludo.

En más de la mitad de mis máquinas no funciona ni un hola mundo en C#. El día que seas capaz de que funcione, hablaremos de un lenguaje serio

Saludos.Ferdy

No todo se basa en SO's y Arquitecturas, yo estoy cobrando pasta por programar, hago programas a empresas en C#, ellos usan windows y x86, asi que mientras eso siga asi lo demas me da igual.

C tiene varias decadas, C# tiene un par o dos pares de años, la cosa va evolucionando, antes C# solo estaba bajo windows, ahora gracias a que ciertos desarrolladores de linux se dieran cuenta de las ventajas de C# respecto a otros lenguajes decidieron crear la plataforma MONO y con ello aprovecharse de dicho lenguaje. Mono aun es primitivo en muchos aspectos, tiene que crecer en librerias, y adaptar windows forms y quizas portarlo a mas arquitecturas(soporta x86 y PPC mono).

Dentro de unos meses o quizas años .NET estara en muchas arquitecturas y sera un lenguaje mas grande. En estos temas los años no importan, porque C tiene decadas y es GRANDE, pero seguro que cuando tenia 2 o 3 años no era mucho.

Eso es todo .

Todo eso que cuentas ademas de ser una suposición tuya no me hace ver por qué debería que tener que usar un lenguaje que de primeras solo está soportado en dos arquitecturas de nada y además no supone ningún avance frente a otros lenguajes.

Saludos.Ferdy

Yo no digo que uses nada hombre, cada uno que programe donde mas comodo este, solo defiendo lo mio, tu defenderas lo tuyo, y si que son suposiciones, ya que esto pinta muy bien

Un saludo ferdy ¬¬.

Hombre... yo sus ventajas sí se las veo. Lo que no me acaba de convencer nada es la velocidad. Sé que es lógico dado que depende de una máquina virtual, pero es que nunca me gustó la ejecución de programas Java siquiera, y mono tapoco parece que sea un avance respecto a la velocidad.

Me interesaría más poder tener las ventajas de Mono/.NET en lenguaje compilado.

Fox, con lo del código... tú puedes crear una clase derivada y tal, pero a lo que me refiero es... alguien programa algo en VB.NET; ¿tú puedes ver ese código en C#? Se hace bien la conversión? Todo esto viene por lo que comentamos de que sería un lío que cada uno programara en un lenguaje, y que si luego se te marcha el tío que programaba en tal lenguaje... tuvieras que seguir igual. Total, si vas a poder tener el proyecto en el lenguaje que tú quieras, pasarlo de uno a otro, etc etc... sería la hostia.

Aparte, aunque las ideas sean buenas lo que nunca me va a convencer es la política de MS. Lo hacen multiplataforma para windows, no dan especificaciones de Windows Forms y cosas así... es un juego sucio, como siempre. Esto, aparte de otras cosas como las partes que tienen patentadas y que no me huelen nada bien.

Fox. aparte de lo que es .NET en sí... ¿qué ventajas le ves a C# frente a C ó C++? Me refiero como lenguaje, nada más. ¿Siguen existiendo punteros en C#?

Y por último la preguntilla que sigo sin ver, auqnue no es exclusiva de .NET:

FuckingFreaky escribió:Sobre los móviles... sí, ya había pensado en eso; que con distinto hardware, mejor desarrollar para una MV. La pregunta que me digo (piensa que yo acabo de empezar con esto de la programación) es... esa MV se tendrá que compilar para ese hardware específico, no? Entonces... si ya se tiene un compilador, no se puede aprovechar para aplicaciones compiladas y programar eso en C/C++ por ejemplo?

Por cierto... yo veo lógico que como todo, se empieza desde abajo y poco a poco se va evolucionando. Con el tiempo, Mono será más portable, más rápido, en definitiva, mejor. Eso es lo normal, si no pasa nada extraño. Claro que ahora C está mucho más extendido, pero es que es totalmente lógico. Pero es que si sólo nos dejamos guiar por la portabilidad y cosas así dedse un principio, no existiría nada más que C y algún que otro lenguaje antiguo. Lleva poco tiempo, y de momento no creo que sea tiempo de darle un valor prioritario a eso. Dentro de unos años, pues sí.

Muchas cenkius!

Un saludo.

Claro que C se extendió, pero en gran parte sería por su eficacia y x su superioridad frente a los demás.
Claramente C# y la plataforma .NET no aporta nada nuevo ni revolucionario, nada que no se pueda realizar ya con las mismas ventajas, por ello no tendría sentido utilizarlo en tantos ámbitos como C/C++ y por eso nunca llegará a ser tan portable como C, creo yo...

Si en algún momento hicieran un lenguaje superior a los demás, es decir, superior de verdad (no como C#) obviamente sustituirá en gran parte a C/C++ y ganará mucha portabilidad en poco tiempo.

Además, si llega a salir este lenguaje o plataforma dudo mucho que sea en manos de microsoft....

PD: Mi opinión está basada en las ventajas/inconvenientes que hay en el hilo.

hola pues yo estoy estudiando informatica estoy en cero porque me toco un mal maestro, etc y me preocupa que no se NADA me gustaria bajar libros electronicos pero no se con que es lo que tengo que tener en la pc para ya hacer las actividades que hay por el internet (me refiero a los editores o esas cosas)

Lo que quieres son IDE (entornos de desarollo)? Es que no sé si es eso lo que quieres...
¿Para windows ó para Linux? Bueno, pues para Win tienes Dev-Cpp, y para Linux, aparte del ya citado hay otros como Eclipse.

Sobre libros ó tutoriales... tb de C? La verdad que no puedo recomendarte ninguno de C porque no he leído ninguno de internet.
De C++ me pasaron uno en inglés hace poco, que lo poco que leí tenía muy buena pinta. Si quieres te lo miro.

Un saludo!

Eclipse también lo puedes encontrar para Windows.

Saludos.

C# como lenguaje nuevo tiene bastantes ventajas aunque en ciertos ámbitos no interesen. El recolector de basura es una ayuda de programación de la ostia y en ciertos entornos simplifica de una manera brutal el tiempo de desarrollo. En C++ tendrías que currártelo tú con smart pointers, que ya tendrías que currártelo tú y además no sería lo mismo.

C# soporta delegados de forma nativa, que son punteros a métodos pero con chequeo de tipos.

C# tiene cierto grado de reflexividad, cosa que ni C ni C++ tienen, y hasta donde llega mi poco conocimiento de Java, éste tampoco.

Por no hablar de la comprobación de tipo en tiempo de ejecución.

Pero claro, C# no aporta nada nuevo...

Si en algún momento hicieran un lenguaje superior a los demás, es decir, superior de verdad (no como C#) obviamente sustituirá en gran parte a C/C++ y ganará mucha portabilidad en poco tiempo.

El C++ tardo varios años en tener la aceptación que tiene ahora, y eso que de mano se definió como un estándar basado en C.

Por otro lado el C# es estándar (que a muchos no se os mete en la cabeza pensando que es de MS) Es decir, que por poder puedes hacer un compilador de C# que compile a nativo

Fox, con lo del código... tú puedes crear una clase derivada y tal, pero a lo que me refiero es... alguien programa algo en VB.NET; ¿tú puedes ver ese código en C#? Se hace bien la conversión? Todo esto viene por lo que comentamos de que sería un lío que cada uno programara en un lenguaje, y que si luego se te marcha el tío que programaba en tal lenguaje... tuvieras que seguir igual. Total, si vas a poder tener el proyecto en el lenguaje que tú quieras, pasarlo de uno a otro, etc etc... sería la hostia.

No no puedes verlo en C# al menos de forma directa. Lo puedes ver en IL, si Fox dice que hay traductores yo no los conozco, pero en teoría se podría hacer, otra cosa es cómo quede el código.
Y seguís con la pijada del lenguaje. Si un tío se programa un módulo en un lenguaje y se va, la empresa o bien contrata a otro que sepa programar en ese lenguaje para que continue el módulo, o bien rehace el módulo en otro lenguaje según le interese y punto. Que pasa, ¿que si a una empresa que hace un programa en VB se le van los programadores quiebra? Pues esto igual y en cualquier ámbito, no sólo en el empresarial.

Aparte, aunque las ideas sean buenas lo que nunca me va a convencer es la política de MS. Lo hacen multiplataforma para windows

Es que un lenguaje no es multiplataforma. Un lenguaje define unas reglas y punto. Es luego responsabilidad del que quiera implementar un compilador a una cierta máquina. Lo mismo en el caso de Windows. MS centra sus esfuerzos en su sistema, lo que es lógico. O vosotros os pondríais a mejorar el Windows Forms por que si.

no dan especificaciones de Windows Forms y cosas así... es un juego sucio, como siempre.

Coño, entonces la documentación que miro yo todos los días varias veces no se de dónde la saqué
Lo que no esperes es que te den el código para que lo mires.

¿cómo puede gustaros tanto un lenguaje tan poco portable actualmente?

Porque también hay mundo después del pingüino, y si has tenido que programar en win32, en MFC, lo comparas con Windows Forms y aún así no eres capaz de ver la mejora brutal que hay en el desarrollo, entonces no merece la pena discutir.

No no puedes verlo en C# al menos de forma directa. Lo puedes ver en IL, si Fox dice que hay traductores yo no los conozco, pero en teoría se podría hacer, otra cosa es cómo quede el código

Por lo que me ha comentado Fox existen traductores de C#a VB.NET y viceversa. Supongo que al pasar todo por CIL, pues con más o menos esfuerzo se pueden hacer ese tipo de cosas.

Si un tío se programa un módulo en un lenguaje y se va, la empresa o bien contrata a otro que sepa programar en ese lenguaje para que continue el módulo, o bien rehace el módulo en otro lenguaje según le interese y punto. Que pasa, ¿que si a una empresa que hace un programa en VB se le van los programadores quiebra? Pues esto igual y en cualquier ámbito, no sólo en el empresarial.

Ya, pero la cosa es no perder el tiempo en rehacer de nuevo el módulo, ó igual no tener que seguir por la misma linea, con el mismo lenguaje, que anteriormente. Por eso me parecerái interesante la idea de poder cambiar de un lenguaje a otro. Pero vamos, que esto es como una mejora, porque es otra cosa que creo que ni C ni C++ pueden hacer.

Es que un lenguaje no es multiplataforma. Un lenguaje define unas reglas y punto. Es luego responsabilidad del que quiera implementar un compilador a una cierta máquina. Lo mismo en el caso de Windows. MS centra sus esfuerzos en su sistema, lo que es lógico. O vosotros os pondríais a mejorar el Windows Forms por que si.

Por eso me parece mucho mejor mono que realmente sí se esfuerza en ser multiplataforma. Si MS vende algo como el "boom" de la multiplataformidad y luego resulta que hay incompatibilidades... dónde está la mejora?

Lo que no esperes es que te den el código para que lo mires.

Pues eso... De todas formas, de las cosas que más les estaba costando al equipo de Mono era implementar Windows Forms. Podrás opinar lo que qiueras, pero yo no lo veo como nada más que una triquiñuela más de MS para imponerse "de facto", como lo hace con sus formatos.

Pues eso... yo cada vez veo con menos malos ojos a Mono, que no .NET. Sobretodo porque creo que puede evolucionar bastante más allá de lo que es ahora, y porque Mono sí puede llegar a ser multiplataforma, cosa que MS ni siquiera pretende. Y si algún día Mono consigue implementar todo lo "MS like" de .NET, como Windows Forms, etc... se va a cagá!XD.
En fin, voy a ir investigando un poquito más sobre todo esto.

Un saludo!

Como te has pasado un poco de listo... pues te la llevas:

El recolector de basura es una ayuda de programación de la ostia y en ciertos entornos simplifica de una manera brutal el tiempo de desarrollo. En C++ tendrías que currártelo tú con smart pointers, que ya tendrías que currártelo tú y además no sería lo mismo.

Vamos a ver los recolectores de basura están bien para:

1) Gente que no sabe programar y programa 'a la puzzle' es decir, poniendo unas lineas por aquí y a ver si funciona. Sin siquiera saber lo que ocupan los tipos y preocupandose solo de que sus amigachos vean la porquería que ha hecho.

2) Gente que no sabe programar y está aprendiendo. Aún así siguen sin saber programar.

3) Gente que no sabe programar porque le parece muy dificil trabajar con direcciones de memoria, late binding y todas esas cosas que hacen la programación más divertida, bonita, eficiente y para gente que realmente PROGRAMA.

4) ¿He dicho ya que un GC sirve para ayudar a gente que no sabe programar?

Los GC realmente interesantes son los que están implementados en forma de Autorelease Pool's (i.e. como en ObjC); que además lo puedes activar para las porciones de código que tu quieras.

Porque también hay mundo después del pingüino, y si has tenido que programar en win32, en MFC, lo comparas con Windows Forms y aún así no eres capaz de ver la mejora brutal que hay en el desarrollo, entonces no merece la pena discutir.

¿ Quién ha hablado de Linux ? Porque creo que yo dije que no es portable... y que las empresas de verdad no tienen ganas ni interés en portar la porquería esta a otras arquitecturas y sistemas porque no vale nada.

Es simple, yo abro vim y codeo algo en C y me está compilando en mis máquinas alpha, en las de casa, en el portatil, .... cada una con una arquitectura y sistema operativo distinto. Si lo intento hacer en C# ni el Hola mundo funciona. ¿por qué? Pues por lo que he dicho antes, nadie tiene interés en portar toda la parafernalia que requiere que .NET/Mono esté disponible en algo que no sea Windows/Linux{x86,ppc}.

Todo para que cuatro mojigatos hagan de programadores con un lenguaje de juguete.

PD: Creo que la discusión no es si las empresas pagan por una cosa u otra... a mi ahora mismo me da igual si las empresas pagan pseudo-programadores por hacer aplicaciones en .NET. La discusión es más cercana a la aportación tecnológica.

Creo que más o menos ha quedado claro... ¿verdad?

HTH, HAND

La ostia! ahora me entero que java no tiene reflectividad :D:D

Para muestra un boton, la api de la clase class