El índice Tiobe, que mide la popularidad de los lenguajes de programación entre los desarrolladores, muestra como C ha logrado alzarse con el primer puesto que ocupaba Java. En castellano
www.theinquirer.es/2012/04/09/el-lenguaje-c-desbanca-a-java-del-primer 
Calibre (Python + Qt)
Eclipse (Java + GTK)
Todos los programas de Android (Java)
Javascript en todos los sitios web.
PHP, Python, Java, Ruby, Perl, Scala... en servidores web (incluido Google).
C# en los programas modernos de Microsoft.
> mejor hacerlo directamente con un lenguaje compilado y pensando en la escabilidad desde el minuto 0
Ya, porque tú lo dices, y ni idea del sobrecoste humano que eso significa (como si fuese lento, o los ordenadores costasen menos que los programadores), y técnicamente el problema de los fork() en programar en código nátivo.
Es fácil hablar, y asegurar que todo el mundo está equivocado. Vaya con el nivel informático, sois unos gurús. Todos los demás están equivocados, desde Zuckerberg hasta Guido van Rossum.
>A menos que desarrolles sistemas operativos, o librarías de manipulación de datos o cálculo, no tiene demasiado sentido desarrollar en un lenguaje compilado
>Por otro lado, el C++ es uno de los peores lenguajes inventados
Y yo te he demostrado que prácticamente el 100% de los programas que usas están hechos en C/C++, por lo que algo de sentido sí tiene.
Yo a un chaval que empiece ahora, le recomendaría que lo primero que aprendiese fuera C, luego el tema de objetos con C++ y luego una librería multiusos como Qt.
Pero bueno, a lo mejor es que soy un brontosaurio y merezco la extinción.
Por mi parte, debo ser un bicho raro, soy arquitecto de software, 16 años de experiencia en programación, he sido profesor de Java, he programado en C, en C++, en Ruby, en C#, en Delphi... y lo que he sacado en claro en todo este tiempo es que el lenguaje de programación ayuda en parte, pero es el programador, y más en concreto el equipo de desarrollo, el que tiene que funcionar. Por poner un ejemplo, se le puede dar el lienzo más caro con los mejores óleos a una persona con arte mediocre, y conseguirás un resultado mediocre. En cambio, Goya era capaz de hacer arte con un carboncillo.
Java es un gran lenguaje, como también lo es C# (después de todo, son bastante parecidos), como también lo es C. Tienen primas feas, como Cobol o Visual Basic, que aun así hay gente que las saca a bailar. No me gustaría estar en su pellejo, pero les entiendo, a un lenguaje también se le puede coger cariño, y seguramente sean capaces de hacer maravillas. Lo mismo para los IDE, hay gente que le encanta eclipse, otros como yo que prefieren el Visual Studio, pero que uno te parezca mejor que el otro no implica que el otro sea malo.
Y sigo diciendo, el desarrollo de software es un arte, exige creatividad, exige compenetración en el equipo, unos engranajes bien engrasados, y entonces se hará algo grandioso, sea en lo que sea. Lo malo es que esto es complicado de conseguir, en especial en España, dónde las empresas no saben entender cómo funciona realmente un equipo de software, ni les entra en la cabeza que un técnico experto puede tranquilamente ganar más dinero que un gestor, sencillamente pertenecen a ramas diferentes del trabajo.
Y a los que hablaron de Hibernate, Spring o Struts para expresas lo bueno que puede llegar a ser java, les recuerdo que ese trío de ases también existe en .NET, no hay que cerrarse en banda a nada nuevo y hay que evaluar todo lo que existe sin descartar absolutamente nada simplemente por ser un fanboy.
PD: esto por lo menos si lo hace bien C++.
Por otro lado, el mercado del software está muy mal si los máximos exponentes son C y Java. Por un lado un lenguaje inseguro, responsable del 90% de los problemas de seguridad que nos asaltan en el software de hoy en día. Y por otro, un lenguaje que no sirve para hacer programas nativos y heredero de una sintaxis (la de C) poco legible y mantenible.
Cada lenguaje tiene su propio campo de aplicación. Tienes el C para librerias de alto rendimiento y luego puedes enlazar esas librerias con Phyton e incluso con JAVA, que son lenguajes de más alto nivel y permiten una mayor abstracción.
Pero la gente se equivoca cuando considera lenguajes diferentes y que programar en C++ implica trabajar con objetos, templates y toda la parafernalia. El C++ es lenguaje que particularmente no me gusta demasidao, pero lo utilizao a diario. Hay alternativas como D, pero que apenas se utilizan.
Si aún te piensas que la velocidad es lo único importante es que estás pensando en términos absolutos de utilidad, lo que es el programa en sí vamos. Lo que no estás teniendo en cuenta es la enorme diferencia económica que representa hacer un programa en un lenguaje compilado, con todo lo que ello acarrea (ausencia de multiplataforma, más propenso a errores por el tema punteros y similares, poco o ausencia de soporte para ampliaciones/instalaciones en caliente, etc), y otro dinámico, que a parte de solucionar todos los problemas que tienen los compilados, sólo te implica un mínimo decremento en el rendimiento, que en la gran mayoría de aplicaciones es totalmente despreciable, y por eso, ahí, se utiliza Java.
Y es que hay aplicaciones que necesitan ser programadas en C, y otras que no y que en Java se harían muchísimo antes (más rápido, más barato). Si en algún momento he defendido una supuesta "superioridad" de Java, me habéis malinterpretado. Al César lo que es del César.
Luego no acabo de entender lo que sueltas sobre los procesadores. Aunque sea bastante ridículo pensar que las CPU's tienen un límite conocido, si lo tuviesen, los programas estarían adaptados a ese rendimiento. De momento los servidores son cada vez más potentes y el software avanza a la par (más o menos, ya sabéis).
#214 Dato totalmente relevante, vamos. Y el Windows que utilizo tiene componentes en .Net, y el Linux que uso está en parte en IA32. Alucinante.
wiki.python.org/moin/PythonGames
www.youtube.com/watch?v=c7RRaEvWqJc&html5=True Hecho en Python (Blender)
Hace un porrón de años vi que los juegos del Source de Valve (mi querido Vampire Bloodlines) usan Python para el scripting de escenas (así se mejoraron cosas y arreglaron cositas por parte de los usuarios, que como buen juego de Troika esta petao).
PD: favor de que nadie tenga este comentario en Cuenca y me depuren los fallos con respuestas o perfilen a negativos.
Yo hablo de hacer un programa bien, compilado siempre sera más rapido. Otra cosa es que bueno para determinadas aplicaciones no es muy viable.
"Aunque sea bastante ridículo pensar que las CPU's tienen un límite conocido"
Yo reconozco que soy un poco abuelo cebolleta, pero tio, si no sabes que los procesadores tienen un limite fisico conocido, no sabes como estan hechos. Aunque quiza te has explicado mal.
Te recomiendo que leas cosas como esta:
www.neoteo.com/los-ordenadores-tienen-un-limite-absoluto
Otra cosa es que se rompa esa barrera cambian el material/modelo. Todo fisicamente tiene un limite, yo viví cuando tener 1Mb de RAM era la leche, y un procesador a 2,4MHz era potente. En poco mas de diez anos se ha superado en mas de 1000 veces, pero todo tiene un limite.
Desconocía ese "limite conocido" que comenta ese artículo. Gracias por la referencia.
Como te comenté, en caso de llegar a ese límite, los lenguajes y plataformas se diseñarían con eso en mente, porque tiene implicaciones bastante serias, pero de momento no es así.
De todas maneras, yo soy de los que piensa que "la vida se abre camino" (como dicen en la peli), y tal y como comenta el artículo al final "Puede que en el futuro algunas mentes privilegiadas puedan encontrar una fisura allí donde no podemos verla ahora, y abrir la puerta a toda una generación futurista de ordenadores.".
Y qué me quieres decir con eso? Es que en Java no tienes prácticamente librerías para cualquier cosa?
Terminos como, modularidad, o poca propensión a errores los presupongo por supuesto, no creo que sean excluyentes.
Además, ese argumento tampoco aguanta mucho si tenemos en cuenta que la forma correcta de acabar un programa en C es mediante exit (int)
Si quieres un sistema un 20% más rápido, pon un procesador un 20% más rápido, o pon 2 procesadores en paralelo, o 50. Es mucho más fácil y barato escalar de esta manera.
Si la única forma de que ese sistema funcione es con un procesador ya overclockeado al máximo y no permite paralelización, es que el sistema está mal parido.
En cualquier caso, para cálculos científicos, para negocios muy concretos, para aplicaciones que surgieron de una filosofía muy particular, sí, para eso está C, PHP y demás pero, para todo lo demás, mastercard no, Java.
No nos vayamos a los extremos. Para un kernel o para computación matemática, tienes C o incluso pseudolenguajes matemáticos que al final precompilan a C.
Estoy hablando de la inmensa inmensísima mayoría de empresas del mundo, que haces webs, desarrollos a medida (incluso ERPs a medida), modificaciones-integraciones-adaptaciones de sistemas propietarios, etc. y para todo eso, lo lógico es usar Java por las ventajas que ofrece para una empresa.
También te digo que para eCommerce rápido y barato, hay soluciones PHP muy buenas, pero cuando las grandes compañías, por lo general, usan soluciones que les den más confianza y ahí Java gana por goleada.
Amazon o ebay son pioneros y su negocio está 100% dedicado a la web. Es lógico que tengan un framework específico y, por su filosofía, empezaron en un lenguaje concreto y se han montado todo el stack a medida para el desarrollo de sus aplicaciones. Les da una libertad tremenda y se la suda el TCO porque todo su negocio y toda su plantilla está enfocada a ese modelo de trabajo. Pero hay pocas empresas que puedan permitirse todo esto. Para todas las demás, ahí está Java.
Si eres cautivo de Navision y tienes un integrador que te "obliga" a trabajar con soluciones .net, pues a joderse tocan, pero Java no hace cautivo a nadie y eso es una libertad tremenda para las empresas, porque limitan mucho el número de barreras de salida de su solución de IT.
C - Hay 100 versiones distintas, no hay acuerdos para las librerías, te dejas un puntero y la lías parda. No existen metodologías de desarrollo comúnmente aceptadas lo que hace complejo el mantenimiento. Eso sí, es el más rápido.
.NET - No es ni siquiera un lenguaje, sino un grupo de lenguajes y liberías que puedes incluso mezclar. Está bastante estandarizado (si por estandarizar queremos decir imponer por ser un sistema propietario). Es muy poco robusto y te obliga a casarte con windows y con microsoft (y casi diría que con Office).
PHP - Hay que ser un maestro para ser capaz de hacer aplicaciones decentes. No tiene capas de abstracción suficientes ni metodología de desarrollo. De estándares ni hablamos. Es muy fácil de programar y, el time to market, si encaja con algo que ya hay por ahí, es corto porque se puede reutilizar. Ahora bien, como vayas a hcer algo distinto, prepárate porque la llevas guapa. Además, es muy difícil de mantener debido a la ausencia de metodologías aceptadas. Te casas con el equipo de desarrollo que ha hecho tu aplicación. Del despliegue y producción ni hablamos.
Java - aceptado y defendido por IBM, Oracle, Google (en parte) y otros de los mayores fabricantes del mundo.
¿Se han equivocado? Cuando los grandes tiran por un lado, ¿de verdad pensáis que lo hacen porque sí? No ganan nada usando Java que no lo harían usando otro lenguaje.
Java desperdicia memoria y cpu pero son bienes muy baratos en comparación al coste de desarrollo, mantenimiento y daños por falta de fiabilidad.
De todas formas, es mi opinión; cada cual verá sus pros y contras.
exit solo debería usarse en casos donde esta contemplada una salida del abrupta de la secuencia o que necesiten control del cierre, para todo lo demás return.
¿por que narices en C99 obligan devolver un valor int en main? en.wikipedia.org/wiki/C_(programming_language)#cite_note-20
*te aconsejo que leas esto. faq.cprogramming.com/cgi-bin/smartfaq.cgi?id=1043284376&answer=104 • www.eskimo.com/~scs/readings/voidmain.960823.html (mas tocho por si quieres mas)
PD: No quiero meterme contigo no es mi intención. Pero por favor, no defiendas pullas con medias verdades manipuladas que estaba hablando de que puso 'VOID'.
Como digo, no estoy 100% seguro, y posiblemente también haya código en C en subsistemas menos críticos o en algún driver de muy bajo nivel.
En el mundo aeroespacial-defensa, Ada tiene un nicho de mercado importante (algunos ejemplos los puedes ver en la web de AdaCore). El motivo es que certificar código "real time safty critical" en C es realmente mucho más complicado y costoso que en Ada. No es de extrañar pues, como se dice por ahí arriba, los lenguajes de programación son herramientas, y Ada se diseñó expresamente para esta clase de sistemas y C no.
Hay muchos argumentos para defender el prototipo de main, pero yo creo que ese no es uno.
Yo escapo de los returns siempre que puedo porque introduce cierto problema de abstracción que además acaba en problemas de portabilidad. Si bien el prototipo es int main (int, char **, char **) -el cual da a entender que puedes devolver un entero con signo a la salida-, sólo puedes usar los 8 bits (en algunos sistemas incluso 7) menos significativos de ese entero para meter un código de error. El cual, por cierto, se convierte a un entero sin signo. ¿Por qué entonces un int y no un uint8_t?
A mi entender, utilizar exit aquí es preferible, y ya no porque me dé más bits para meter un código de error, si no porque exit me aporta dos constantes que debería usar (EXIT_SUCCESS y EXIT_FAILURE) y me alejan de introducir códigos raros. Y podemos acabar el main con un return 0 para mentener la coherencia con el prototipo.
Respecto a esto "PHP - Hay que ser un maestro para ser capaz de hacer aplicaciones decentes." ....uhmmm.. se lo dire a los creadores de algunos de los portales mas grandes de internet con millones de usuarios diarios y que utilizan PHP para casi todo (con esto no digo que sea la unica opción, solo que tu argumento no me parece minimamente válido).
Respecto a esto "Java - aceptado y defendido por IBM, Oracle, Google (en parte) y otros de los mayores fabricantes del mundo.
¿Se han equivocado? Cuando los grandes tiran por un lado, ¿de verdad pensáis que lo hacen porque sí?"
Ah, claro... las motivaciones de las empresas son siempre tecnicas. Y voy yo y me lo creo. Te podria decir que he conocido a dos empresarios de empresas de software que cuando les preguntabas porque usaban Java, te respondían que era para facturar mas, porque el mismo trabajo les llevaba mas tiempo hacerlo. No digo que tuvieran razón, ya que su argumento era muy simplista y creo que puede haber situaciones en las que Java sea mejor, pero esto a años luz de decir que esta por muy por encima de otras opciones. ¿te parece entonces que, a nivel técnico, mi argumento de los empresarios aceptando Java por esas razones es tan valido como el tuyo de que IBM defiende Java?
"Java desperdicia memoria y cpu pero son bienes ..." y tiempo corrigiendo lo que otros han hecho mal porque muchos programadores parece que no acaban de aclararse de como usar este lenguaje (que conste que hablo por mi experiencia en este campo hasta hace unos años....ahora ya no empleo nunca este lenguaje ...), lo que me ha hecho encontrarme "casi" siempre con programas en Java que no funcionaban bien.
Me refiero a que la aplicación no pete constantemente y no sepas ni qué ha pasado (en java es raro ver un APPCRASH UnknownState Error 0x38383838383, que ni aparece cuando lo buscas en Google). Cuando haces bien una aplicación Java, siguiendo todas las buenas prácticas (que están publicadas aunque hay muchos que las desconocen), la aplicación es muy muy robusta e, incluso cuando falla, sabes por qué ha fallado, ha avisado de su error y, seguramente, si lo has hecho todo bien, se habrá levantado otra instancia con 0% de downtime (ó 0.000001%)
Me puedes decir qué ganaba Sun con Java (qué vendía Sun que no pudiera vender sin Java). Y IBM, competidor de Sun en su época, por qué se volcó también en Java. Hablamos de los grandes entre los grandes de la industria IT.
Quien te dijera que vende Java porque podía facturar más al hacer aplicaciones más caras, con todos mis respetos, era un jodido ignorante que no sabe por qué se hacen las cosas.
Que se factura más con un desarrollo Java, estoy de acuerdo; gracias a lo cual el cliente de ese desarrollo obtiene un sistema robusto, fácilmente mantenible por cualquiera, sin tecnología propietaria y, por tanto, sin cautivos. Por todo ello, sí, se paga un poco más... para luego pagar bastante menos, porque el ciclo de vida de un sistema de información no se reduce al desarrollo sino que su mantenimiento es igual o más caro que el desarrollo inicial. Y si tu proveedor no te gusta o se pasa con los precios, te pasas a otro fácilmente.
Lo que sí es cierto, es que hubo (y hay) muchos "expertos Java" que no saben ni lo que es Spring, lo que es una conversación y se hacen mil líos cuando le llegan dos peticiones a la vez a un servlet (por poner un ejemplo tonto). Si te formas en Java siguiendo las recomendaciones y poniéndolas en práctica, te das cuenta de que el conocimiento de tu aplicación no reside en el programador y eso te da una libertad inmensa en su mantenimiento.
Y por eso, los lenguajes de alto nivel, se crearon precisamente para ese propósito, para no tener que lidiar con librerías, que por muchas que sean, no deja de tenerse que programar a bajo nivel.
No es lo mismo la legibilidad de un código Ruby/Python/Java que la de una aplicación en C.
Como comento con anterioridad, C por supuesto que es muy potente, con 200.000 librerías para todo tipo de situaciones, y nadie lo niega, pero añade una capa de complejidad innecesaria para ciertos tipos de proyectos. Querer defender a capa y espada el uso de C, para todo tipo de desarrollos, es ser fanboy.
Programar un ERP completo en C, es tirar el tiempo, ya que tienes que preocuparte de ciertos detalles que en un ERP no son primordiales, mientras que no me plantearía programar una aplicación de bajo nivel en otra cosa que no fuera C.
Just my 2 cents.
Por el contrario suelo usar inkscape, gimp, matlab, texmaker, ... de aplicaciones no hechas en Java, que nunca me han dado problemas.
Repito, no es que no se puedan hacer buenos productos con Java, pero algo debe tener para que haya tantos productos "no tan buenos".
¿Netbeans te falla? Algo raro tendrás, nunca me han reportado nada parecido. De eclipse sí, pero por los plugins basura que hacen cuatro aficionados.
En cuanto a editores gráficos... como he dicho antes, Java no está pensado para eso; en cuanto a los applets, joder, eso sí que es la mayor basura que se ha inventado en mucho tiempo.
Vale, quizás debería reducir el ámbito a lo que yo entiendo por robusto: JEE
Y... si Gimp no te ha dado nunca problemas... joder, afortunado tú. Mira que la uso (como particular, no profesional) y me falla más que una escopeta de feria. Además de hacerse un lío con el gestor de ventanas inmenso, a veces, subo el zoom y hace un crash que ni la bolsa en 2008.
Matlab, al menos en Windows (supongo que habrá versión para Linux) tres cuartos de lo mismo. Se queda tieso con un cálculo sencillo y dices ¿qué coño estará haciendo por dentro?
PD: Ubuntu (11) y Java no es que se lleven muy bien. Con la 10, va como un tiro.
"Prototipos" de main en C: en.wikipedia.org/wiki/Main_function_(programming)#C_and_C.2B.2B
#define EXIT_SUCCESS 0 #define EXIT_FAILURE 1. Y no hace falta stdlib (que es el que las aporta y no exit) y mucho menos recurrir a exit.
En main devuelves un int por narices (el valor que devuelvas mas alla de 0 eso ya es cosa de cada uno). Si usas exit, ¿que le mandas de parametro? ¿un uint8_t o un int?
PD: Acepto negativos por respuesta.
Si uso exit debo usar una de las constantes (cuyo contenido no deberías ni conocer) que se usan con exit. Eso es como decir, "si kill me pide un int de segundo argumento, ¿por qué no meterle un número negativo?". No. Hay unas constantes para usar con esa función y punto. El funcionamiento interno te la sopla.
Ahora, si confundes niveles de abstracción, pues hombre, es un problema.
Si crees estar tan seguro prueba a poner una pregunta con código usando "void main()" de ejemplo en groups.google.com/group/comp.lang.c/ te van a sobrar correcciones y correctores.