Portada
mis comunidades
otras secciones
#13:
#2 Es ahí donde he dejado de leer el artículo.
Hoy en dia ser hater de C (y practicamente de cualquier lenguaje compilado) es lo que está de moda. Gente que no ha programado nunca seriamente en estos lenguajes. En el caso de C yo creo que el mayor problema de esta gente es creer que todo se acaba en la librería estandard, la supuesta falta de orientación a objetos de C y la visión simplona del lenguaje que enseñan en los primeros cursos de las universidades, donde lo que prima es martirizar a los alumnos con la gestión de memoria. (#4)
C es un languaje bien provisto, flexible, portable, eficiente y actualizado, solo que no todo el mundo puede asumir la, supuesta, complejidad que esto conlleva. No estoy diciendo que esto justifique su uso en todos los casos, pero tacharlo de coñazo, complicado o "incomodo" es un razonamiento simplista.
Hoy en dia ser hater de C (y practicamente de cualquier lenguaje compilado) es lo que está de moda. Gente que no ha programado nunca seriamente en estos lenguajes. En el caso de C yo creo que el mayor problema de esta gente es creer que todo se acaba en la librería estandard, la supuesta falta de orientación a objetos de C y la visión simplona del lenguaje que enseñan en los primeros cursos de las universidades, donde lo que prima es martirizar a los alumnos con la gestión de memoria. (#4)
C es un languaje bien provisto, flexible, portable, eficiente y actualizado, solo que no todo el mundo puede asumir la, supuesta, complejidad que esto conlleva. No estoy diciendo que esto justifique su uso en todos los casos, pero tacharlo de coñazo, complicado o "incomodo" es un razonamiento simplista.
#126:
#49 #49 Realmente, es un bulo que C++ sea mas lento que C.
No es un bulo. De hecho, es irremediable. Cualquier nivel de abstracción superior siempre va a suponer una pérdida de rendimiento respecto al anterior. Es el precio a pagar por la abstracción: generalizar siempre supone una pérdida de posibilidades en los ámbitos concretos.
Lo que sí sucede es que todo depende de las capacidades del programador. Un programador bueno puede hacer código en C++ que rinda mucho mejor que un código en C mediocre. Sin embargo, optimizando una misma solución al máximo, las características de C++ suponen un coste que puede no ser asumible. Por ponerte un ejemplo, hay muchos sistemas de trading de alta frecuencia que están implementados íntegramente en C a día de hoy, o en C++ sin usar muchas características propias del lenguaje. También he visto sistemas de balanceo de carga en servidores con partes escritas en ensamblador.
Los costes del alto nivel son despreciables en la mayoría de aplicaciones, o son asumibles comparados con otros costes (tiempo de desarrollo y/o portabilidad). Pero existen, están ahí y, dependiendo del contexto, se vuelven inasumibles.
No es un bulo. De hecho, es irremediable. Cualquier nivel de abstracción superior siempre va a suponer una pérdida de rendimiento respecto al anterior. Es el precio a pagar por la abstracción: generalizar siempre supone una pérdida de posibilidades en los ámbitos concretos.
Lo que sí sucede es que todo depende de las capacidades del programador. Un programador bueno puede hacer código en C++ que rinda mucho mejor que un código en C mediocre. Sin embargo, optimizando una misma solución al máximo, las características de C++ suponen un coste que puede no ser asumible. Por ponerte un ejemplo, hay muchos sistemas de trading de alta frecuencia que están implementados íntegramente en C a día de hoy, o en C++ sin usar muchas características propias del lenguaje. También he visto sistemas de balanceo de carga en servidores con partes escritas en ensamblador.
Los costes del alto nivel son despreciables en la mayoría de aplicaciones, o son asumibles comparados con otros costes (tiempo de desarrollo y/o portabilidad). Pero existen, están ahí y, dependiendo del contexto, se vuelven inasumibles.
#33:
#30 ¿cómo que foro de política?
Lo normal si algo no te interesa es que pases de ello... y llegará o no a portada.
No entiendo por qué si no te interesa la programación vas a negativizar (sin saber de programación y por tanto si es un buen artículo o no) un envío.
Si votamos irrelevante todo lo que no nos interesa personalmente nada llegará a portada.
Lo normal si algo no te interesa es que pases de ello... y llegará o no a portada.
No entiendo por qué si no te interesa la programación vas a negativizar (sin saber de programación y por tanto si es un buen artículo o no) un envío.
Si votamos irrelevante todo lo que no nos interesa personalmente nada llegará a portada.
#76:
#49 +1
es un mito muy extendido por algunos ignorantes, que C++ es más lento que C. Luego lo justifican con ideas peregrinas como las llamadas mediante puntero (virtual), los destructores, etc.
C++ es "you pay for what you get". Si tu diseño necesita funciones virtual, también se necesitará algo equivalente en C. Resultado: Tu implementación nunca va a ser más rápida y correcta que la de C++, como mucho igualarás.
Si tu diseño necesita destructores, en C también deberás hacer algo parecido (liberar un recurso). Resultado: Tu implementación nunca será más segura que la de C++, porque tú te puedes olvidar de liberar el recurso, C++ no se olvida nunca.
En general lo que hace lento a C++ es el diseño sobrecargado e innecesario que te enseñan en la universidad, con clases, herencia y polimorfismo para todo.
es un mito muy extendido por algunos ignorantes, que C++ es más lento que C. Luego lo justifican con ideas peregrinas como las llamadas mediante puntero (virtual), los destructores, etc.
C++ es "you pay for what you get". Si tu diseño necesita funciones virtual, también se necesitará algo equivalente en C. Resultado: Tu implementación nunca va a ser más rápida y correcta que la de C++, como mucho igualarás.
Si tu diseño necesita destructores, en C también deberás hacer algo parecido (liberar un recurso). Resultado: Tu implementación nunca será más segura que la de C++, porque tú te puedes olvidar de liberar el recurso, C++ no se olvida nunca.
En general lo que hace lento a C++ es el diseño sobrecargado e innecesario que te enseñan en la universidad, con clases, herencia y polimorfismo para todo.
#72:
#58 Es que solo la primera recomendación ya es para tirarse de los pelos, lo más ridículo que he leido nunca.
"No usar char, int, short, long..." y sí usar uint8_t, uint32_t .. etc.
La del #pragma once, cuando no es estándar.
La de no utilizar memset, y luego reconocer que su alternativa no sirve debido al padding
La de utilizar arrays dinámicos en lugar de alojar memoria (como si el stack fuese infinito).
La de usar bool en lugar de devolver un valor especial (ptr == NULL), como si fuera una novedad gracias a stdbool
La de no usar malloc...
Pero bueno qué te puedes esperar del idiota que programó redis
"No usar char, int, short, long..." y sí usar uint8_t, uint32_t .. etc.
La del #pragma once, cuando no es estándar.
La de no utilizar memset, y luego reconocer que su alternativa no sirve debido al padding
La de utilizar arrays dinámicos en lugar de alojar memoria (como si el stack fuese infinito).
La de usar bool en lugar de devolver un valor especial (ptr == NULL), como si fuera una novedad gracias a stdbool
La de no usar malloc...
Pero bueno qué te puedes esperar del idiota que programó redis
#2:
La primera regla de C es no escribir en C si puedes evitarlo
y esto por qué?
y esto por qué?
#16:
Voto errónea porque el artículo y sus recomendaciones no hay por donde cogerlas. Ridículo
#12:
#c-9" class="content-link" style="color: rgb(, , )" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment//order/9">#9 Sí, C estándar. Con él puedo programar en cualquier plataforma por limitada que sea con un rendimiento decente. C++ y C# no los he probado lo suficiente, pero es que C es un lenguaje más... funcional. 
#1:
¡Qué moderneces! Donde esté el Cobol de toda la vida
Comentarios
#30 ¿cómo que foro de política?
Lo normal si algo no te interesa es que pases de ello... y llegará o no a portada.
No entiendo por qué si no te interesa la programación vas a negativizar (sin saber de programación y por tanto si es un buen artículo o no) un envío.
Si votamos irrelevante todo lo que no nos interesa personalmente nada llegará a portada.
#33 Eso de que "lo normal es pasar" es bastante discutible. Piensa que hay muchas familias con hijos que dependen del karma.
No entiendo cómo la gente puede votar irrelevante a noticias que no le interesan, como dice #33. Eso es no permitir a los que sí nos interesan que salgan a portada. Creo que el voto irrelevante es para otra cosa.
Por otra parte, las críticas de #13 y #2 donde “dejaron de leer” en cuanto se recomienda no programar en C me llevan a pensar que no han programado mucho en C. C no es un lenguaje de alto nivel. C es un lenguaje de bajo nivel muy cercano al ensamblador donde es el programador el que tiene que hacer todo, sobre todo la gestión de memoria, de donde salen el 95% de todos los errores y fallos de seguridad del software.
Por lo tanto, C tiene un dominio de programación muy específico, como es un kernel (y yo, personalmente, creo que tampoco). Para aplicaciones de alto nivel, es decir, aplicaciones no estén cerca del hardware ni sean de sistemas embebidos, cualquier otro lenguaje es mejor. Porque, ¿podéis argumentarme por qué C es mejor que otros lenguajes? ¿Podéis decir qué características de C son mejores para hacer aplicaciones de alto nivel?
#4 No es ningún coñazo. Ayuda a comprender cómo funciona un ordenador. Otra cosa es que te lo hayan metido a machete en primero de carrera. Ahí sí que es un coñazo. /cc #5
#16 ¿Algún argumento aparte del magnífico “no hay por dónde cogerlo”?
#43 Hoy en día no es cierto porque quien se ocupa de generar ejecutables más rápidos es el compilador, no el programador. Con lo evolucionados que están hoy los compiladores, el rendimiento es prácticamente idéntico entre C y C++ (al menos con gcc y con llvm). /cc #21
La primera regla de C es no escribir en C si puedes evitarlo
y esto por qué?
#2 Porque es un coñazo.
#4 A mí no me lo parece. Es más, me gusta más que Java.
#c-5" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2542865/order/5">#5 seguro? el C estándar? no se habla ni de C++, ni de C#, ni nada parecido...
#c-9" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2542865/order/9">#9 Sí, C estándar. Con él puedo programar en cualquier plataforma por limitada que sea con un rendimiento decente. C++ y C# no los he probado lo suficiente, pero es que C es un lenguaje más... funcional.
#c-12" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2542865/order/12">#12,#9 C++, sí está “emparentado” directamente con C.C# es una especie de java y compararlo con C/C++ es casi insultante…
#c-32" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2542865/order/32">#32 insultante tampoco... pero no es comparable, es un lenguaje distinto... a mí, desde luego C# me gusta p.e. más que Java (con él sí que se puede comparar), aunque considero que está lejos de lenguajes más modernos como Ruby y Python.
#12 coño, funcional tener que rematar los strings a mano para que no se vayan de madre...
#77 No va por ahí el chiste.
#5 Básicamente es porque a medida que el programa crece la posibilidad de que se te cuele un error de manejo de punteros o de memory leak y no lo localices nunca es muy alta. Java no tiene punteros pero además los beneficios de java no están tanto en el lenguaje si no en la máquina virtual.
#51 En eso te doy toda la razón. Para programar en C hay que ser muy metódico o tienes leaks por todas partes.
No obstante, yo diría que lo peor de Java es precisamente su ineficiente máquina virtual. La gran mayoría de los programas hechos en Java tienen la estabilidad de un palillo de pie porque los programadores confían pletamente en su JVM.
#84 La ineficiencia de la VM es una leyenda de las primeras versiones. La estabilidad de un palillo no la conozco. Tengo servidores que no se han reiniciado en años. Yo te puedo decir que a día de hoy "La gran mayoría" son muy estables. Muchas aplicaciones de escritorio multiplataforma (mac/windows/linux) están hechas en java y poca gente lo aprecia en cuanto a velicidad y estabilidad.
#51 Java no tiene punteros...
Esto es un error clásico de concepto. En realidad no es así: en Java todo son punteros. Los "beneficios" de Java en realidad están en el hecho de que muchas cosas están implementadas a más alto nivel y el programador no tiene que controlarlas. De hecho, eso es lo que produce que la mayoría de gente piense que java no tiene punteros.
Desde mi punto de vista siempre digo lo mismo: usar lenguajes de alto nivel es genial, y ahorra muchísimo. Sin embargo, es necesario primero dominar los conceptos de bajo nivel, si se quiere llegar a ser un buen programador. De lo contrario, muchas cosas se construyen como castillos en el aire.
Por otra parte, que nadie piense que los lenguajes de más bajo nivel como ensamblador o C van a desaparecer o están en desuso. Siempre es necesario que alguien implemente las capas de bajo nivel del hardware para que otros puedan programarlas a alto nivel desde cualquier lenguaje moderno. Y hay muchas más capas de bajo nivel de las que uno se imagina hasta que trabaja con ellas. Por algo C y ensamblador siguen siendo lenguajes muy usados.
#5 A nadie le gusta Java.
#13 Todo lo que dices no es incompatible con que escribirlo sea un coñazo, lo cual es una visión subjetiva sobre la verbosidad o sobre cómo hay que escribir el código. Un lenguaje puede ser bueno, versátil, moderno y tener muchas librerías y, aún así, ser un coñazo para escribir.
#2 Es ahí donde he dejado de leer el artículo.
Hoy en dia ser hater de C (y practicamente de cualquier lenguaje compilado) es lo que está de moda. Gente que no ha programado nunca seriamente en estos lenguajes. En el caso de C yo creo que el mayor problema de esta gente es creer que todo se acaba en la librería estandard, la supuesta falta de orientación a objetos de C y la visión simplona del lenguaje que enseñan en los primeros cursos de las universidades, donde lo que prima es martirizar a los alumnos con la gestión de memoria. (#4)
C es un languaje bien provisto, flexible, portable, eficiente y actualizado, solo que no todo el mundo puede asumir la, supuesta, complejidad que esto conlleva. No estoy diciendo que esto justifique su uso en todos los casos, pero tacharlo de coñazo, complicado o "incomodo" es un razonamiento simplista.
#13 Y cual es la ventaja de C con respect a C++? A mi no se me ocurre ninguna situación donde sea major usar C que C++ salvo en casos de software empotrado muy especifico.
#21 Personalmente para mi eso ya es una preferencia personal. De todos modos depende del conjunto de caracteristicas que uses de C++ las tienes disponibles en C (nativamente o usando librerías) como por ejemplo orientación a objetos, herencia, interfaces, señales…
Pero lo dicho: para mi, según gustos.
#27 No se, para mi hoy en día prescindir de la orientación a objetos, la metaprogramación y todo lo que proporciona la STL no tiene mucho sentido. No ganas nada a cambio.
Hacer piruetas en C para conseguir funcionalidades que son nativas en C++ o están en la STL es una tontería, en mi opinión.
#31 "No ganas nada a cambio". -> Rendimiento.
Lo de las piruetas sí te doy la razón.
#40 Realmente, es un bulo que C++ sea mas lento que C. Depende mucho de como uses el lenguaje que del lenguaje en si, opr ejemplo cuando abusas de streams, y hay alternativas para no hacerlo.
En mi opinión, a no ser que no tengas un compilador de C++ en la plataforma donde vas a programar, o haya reestricciones de otro tipo (C/ADA para software critic), no tiene mucho sentido.
#49 +1
es un mito muy extendido por algunos ignorantes, que C++ es más lento que C. Luego lo justifican con ideas peregrinas como las llamadas mediante puntero (virtual), los destructores, etc.
C++ es "you pay for what you get". Si tu diseño necesita funciones virtual, también se necesitará algo equivalente en C. Resultado: Tu implementación nunca va a ser más rápida y correcta que la de C++, como mucho igualarás.
Si tu diseño necesita destructores, en C también deberás hacer algo parecido (liberar un recurso). Resultado: Tu implementación nunca será más segura que la de C++, porque tú te puedes olvidar de liberar el recurso, C++ no se olvida nunca.
En general lo que hace lento a C++ es el diseño sobrecargado e innecesario que te enseñan en la universidad, con clases, herencia y polimorfismo para todo.
#76 Bueno, x264 (el encoder más optimizado para h264 y diría que el más optimizado en general) utiliza C porque tiene una traducción más optimizada a ASM. Las partes críticas son en ASM. Y la gente que lo programó sabe muchísimo más que todos nosotros juntos, algo de razón habrá.
#82 Eso es un argumento muy pasado. Igual que h264, o el kernel de linux, utilizan C, hay otros proyectos muy críticos que utilizan C++ sin problema.
Repito, en C++ puedes hacer código igual de prestacional que en C. Lo que sí te reconozco es que C++ te va a obligar a "pensar demasiado" en algunos casos para asegurarte de que no añades overhead.
#98 Bueno, reconozco que la herramienta funciona mejor o peor dependiendo de en qué manos esté. Pero no me negarás que cuanto más alto nivel más descuidada es la gente.
#76 Y si a eso le sumas que muchisima gente sigue usando C++ como si fuera C con clases, apaga y vamonos. Cada vez que veo un malloc o un memcpy en C++ me llevan los siete males.
#49 #49 Realmente, es un bulo que C++ sea mas lento que C.
No es un bulo. De hecho, es irremediable. Cualquier nivel de abstracción superior siempre va a suponer una pérdida de rendimiento respecto al anterior. Es el precio a pagar por la abstracción: generalizar siempre supone una pérdida de posibilidades en los ámbitos concretos.
Lo que sí sucede es que todo depende de las capacidades del programador. Un programador bueno puede hacer código en C++ que rinda mucho mejor que un código en C mediocre. Sin embargo, optimizando una misma solución al máximo, las características de C++ suponen un coste que puede no ser asumible. Por ponerte un ejemplo, hay muchos sistemas de trading de alta frecuencia que están implementados íntegramente en C a día de hoy, o en C++ sin usar muchas características propias del lenguaje. También he visto sistemas de balanceo de carga en servidores con partes escritas en ensamblador.
Los costes del alto nivel son despreciables en la mayoría de aplicaciones, o son asumibles comparados con otros costes (tiempo de desarrollo y/o portabilidad). Pero existen, están ahí y, dependiendo del contexto, se vuelven inasumibles.
#31 Te voto positivo sólo porque estoy harto de los haters de C++ que están por doquier (no me refiero al usuario con el que hablas, sino en general). Veo que tú le profesas el respeto que se merece.
#21 Dependiendo del uso, C puede producir ejecutables mucho más chicos y mucho más rápidos que C++. Claro que hoy en día la solución para la lentitud de los programas es comprar un ordenador nuevo más potente.
#43 Realmente en el único caso donde necesitas ejecutables realmente pequeños en el caso de los sistemas empotrados, donde tiene sentido usar C (que no deja de ser un esamblador portable). Ahí si que te doy la razón, si es que realmente existe una limitación sería a nivel de ROM.
#59 El problema con eso (aclaro que soy programador con 30 años de experiencia) es que uno se acostumbra a "la vida fácil" y deja de preocuparse por optimizar, por el tamaño de los programas, etc.
Entonces resulta que ahora tenemos en el bolsillo ordenadores 100 veces más potentes que un PC de hace unas décadas y aún así nos parecen lentos. Yo me acuerdo cómo ejecutábamos el viejo Doom (gráficos 3D) de manera completamente fluida con un procesador de 66Mhz, 4Mb de RAM y 100Mb de disco (sin placa 3D obviamente). Claro que no eran los mejores gráficos del mundo pero con un procesador así se podía realizar todo el trabajo que hoy en día nadie se plantea hacer sin una placa 3D.
Si se hubiera mantenido la costumbre de optimizar al máximo el software, tal vez hoy en día la batería de los teléfonos nos duraría semanas en lugar de días.
#75 Bueno, es un trade off como siempre. Facilidad (velocidad y sencillez) vs Performance. Abstracción vs Performance. Etc.
Si las IT han llegado donde han llegado ha sido en gran parte porque la barrera de entrada se ha ido bajando cada vez mas gracias a todas las capas de abstracción y herramientas que se han creado. Desde luego que todo requeriria menos hardware si siguieramos escribiendo directamente en la memoria de video pero no habríamos llegado tan lejos (Realidad virtual, por ejemplo).
Con respect a los moviles, no creo que sea una comparación justa. La mayor parte del consumo se la lleva la pantalla. De todas formas estoy de acuerdo en que hay mucha mierda y mucho proceso en Segundo plano que se queda consumiendo ciclos. Pero esto es ma un problema de QA que de optimización, en mi opinión.
#81 Y no sólo eso. Estan vendiendo teléfonos con procesadores de 8 núcleos de 2Ghz y 3Gb de RAM. Si al menos el kernel y la máquina virtual de Android estuvieran bien optimizados (la optimización es una asignatura pendiente de GCC) o mejor aún escritos en assembler, probablemente nos alcanzaría con un sólo núcleo de por ejemplo 200Mhz, y 128Mb de RAM. La RAM no consume demasiado pero el procesador sí.
Lo que no se podría solucionar es el consumo de la pantalla. Pero recuerda que la mayor parte del tiempo el teléfono está con la pantalla apagada, y en ese estado y con las tremendas baterías que tenemos hoy en día, deberían durar semanas o incluso meses y no es así.
#94 Pero volvemos a lo mismo. Es mas eficiente (no hay que perder de vista que esto es un negocio) invertir en hw mas potente que en optimización. Cuando producir chips te sale por dos duros pero la hora de trabajo de un buen programador es mucho mas cara, la opción está clara.
No solo la pantalla, la radio 3G/4G es pozo de bacteria tambien. Solo podemos esperar un cambio de paradigma en cuanto a baterías
#75 El DOOM no era en 3D. Era un modo 7 de toda la vida con sprites 2D. Muy bien logrado, eso si.
#86 Claro, era lo que llamaban 2D y medio. O sea escenarios en 3D con sprites en 2D con varias vistas (frente, costado, atrás). Pero el hecho es que lograban mostrar un escenario en 3D sin una placa 3D y con un procesador que con el softare de hoy en día tardaría minutos o hasta horas horas en dibujar lo que hace años hacía en milisegundos.
#100 En ese aspecto habria que mencionar el Duke Nukem 3d como la joya de la corona. Eso si que exprimia los recursos .
#21 C esta implementado en todas las plataformas. hasta el chip mas mierdoso del mundo tiene un compilador de C, porque C es un lenguaje muy pequenyo. En cambio C++ es un lenguaje muy complicado (creeme, lo uso a diario). De hecho es bastante sencillo hacerte tu propio compilador de C, conforme a la especificacion completa del lenguaje... pero hacer un compilador del lenguaje C++ conforme a la especificacion completa de C++ es basicamente una locura.
#85 Si tienes razón, pero es obvio que si no tienes un compilador de C++ no vas a poder usarlo y tendrás que tirar de C, ahí no hay opción, no se trata de cual es major o peor
#21 Muchísimos gurús de la programación dicen que las abstracciones que ofrece C++ para lo único que valen es (no todos los dicen con estas palabras, pero el mensaje es básicamente ése) para que los malos programadores parezcan menos malos. Pointer chasing, mayor dificultad para optimizar el uso de caché, árboles de jerarquía (el famoso diamante de la muerte)... C es como tener el capó del coche abierto y todas las piezas desmontadas hasta el último tornillo. Yo era muy de C++ y aunque es lo que uso para programar con el tiempo me he dado cuenta de que tienen toda la razón.
#21 Tu mismo lo has insinuado, es la eficiencia.
#13: Yo es que incluso he usado C como si fuera un guión (script).
Se que no será eficiente, pero me funcionó bien.
Es decir, para hacer una figura paramétrica basada en matemáticas, usé un código fuente que tomaba los valores de entrada del propio código (en la inicialización), y el resultado lo escribía en un fichero.
Para probar diferentes formas en esa figura probé a cambiar los valores de la inicilización y los parámetros, compilando el código cada vez.
#35 Pero hombre, lee los parámetros de la línea de comandos.
#42: Demasiada complicación si quieres hacer algo rápido y sencillo y no andar escribiendo los comandos cada vez.
Me refiero a que tenía esto en el código:
float ancho = 30;
float largo = 50;
float alto = 40;
Para hacer algo sencillo, que no vas a distribuir por ahí, te sirve. Vas tocando los parámetros hasta que te gusta el resultado. Por eso me refiero a que C puede incluso usarse como lenguaje de guión y no como lenguaje compilado.
#68 Pero hombre, para cosas así creo que era más sencillo usar ShellScript (Bash).
#13 Madre mía lo que hay que oir. c es un lenguaje con un problema terrible e INSALVABLE que no tienen otros lenguajes modernos, y es la gestión de la memoria. A nadie en su sano juicio se le ocurre hoy en día poner en manos del programador la alocación y dealocación de memoria, gestionar explícitamente estructuras de datos basadas en punteros, gestionar buffers, tener que prevenir y detectar explícitamente desbordamientos de memoria,... es una fuente constante de problemas de seguridad y disponibilidad de recursos, de depuración, de manteninibilidad... uff es que me dan escalofríos.
A cada día que pasa c es cada vez de más bajo nivel, y sus aplicaciones son cada vez más específicas y limitadas. Cuando necesitas usar c sabes muy bien que tienes que usar c. Si tienes la más mínima duda al respecto, no lo uses. Y mi trasfondo es de microcomputadores y para mi c es mi lenguaje nativo.
#13 Razonamiento simplista es el tuyo, que tachas toda crítica de "hater", y al que la hace de inexperto o de "tonto" que no puede asumir la complejidad. Quizás los que critican C son, precisamente, más expertos y capaces que tú, y por eso lo desaconsejan: porque lo entienden de verdad.
La razón número 1 por la que se desaconsejan lenguajes como C es por el ratio de errores. El 99% de los agujeros de seguridad son por buffer overflows, printf overflows, ROPs, etc. Eso con un lenguaje con gestión decente de memoria (o gestión, a secas, ya que C no tiene nada) no te puede pasar.
#13 la supuesta falta de orientación a objetos de C
En el clavo. El día que se enteren de lo que es un puntero a función, les da un apechusque.
solo que no todo el mundo puede asumir la, supuesta, complejidad que esto conlleva
Aquí ya no estoy tan de acuerdo. Esa complejidad no es supuesta, sino real.
#c-2" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2542865/order/2">#2 #13 A mí me encanta C, es el lenguaje con el que empecé a programar y todavía lo uso habitualmente (y lo prefiero personalmente a ese Frankenstein que es C++, que también me toca usar a menudo). Pero creo que el autor del post tiene toda la razón.
Por muchas librerías que le metas a C, sigue teniendo el problema de que es mucho más difícil de depurar que otros lenguajes de más alto nivel (Java, C#, Python, etc.) y además es inseguro, debido a la ausencia de chequeos automáticos que hacen que en cualquier programa un poco grande en C aparezcan posibles vulnerabilidades de buffer overflow y similares (esto lo corrigen alternativas como Rust, que combinan acceso al metal con seguridad opcional).
¿Cuándo hay que usar C entonces? Pues básicamente cuando necesitamos estar muy cerca de la máquina, como cuando programamos un driver, o desarrollamos para un sistema embebido. Vamos, lo mismito que dice el post: cuando no podemos evitarlo
#144 Por otra parte, las críticas de #13 y #2 donde “dejaron de leer” en cuanto se recomienda no programar en C
1°- he meneado esta noticia
2°- no he dejado de leer la noticia
3°- pregunto por qué afirma semejante cosa, cosa que no es de extranyar, no?
#c-4" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2542865/order/4">#4 Concuerdo contigo, yo lo odié con todas mis fuerzas.
El C y el C++ son los lenguajes que menos me han gustado. La nomenclatura era complicada y menos estructurada que otros lenguajes (delphi, java, C#), y el rollo de los punteros y la gestión manual de la memoria es algo del siglo pasado.Me acuerdo de la mierda de los archivos .h que se me hacían redundantes y estúpidos, la gestión de los imports,... arg! Recuerdo tirarme horas depurando problemas de memoria.
Es cuestión de gustos, pero a mí no me convenció.
Prefiero los lenguajes protegidos como java y C#, no hay tanto rollo con la memoria ni los imports, y es difícil cargarla gracias al garbage collector.
C y C++ sólo lo encuentro útil para desarrollos a bajo nivel o que requieren una gran potencia de proceso. Si hay que hacer un driver, cosas del kernel, aplicaciones intensivas y ese tipo de cuestiones pues sí, C/C++. Pero para todo lo demás lo considero innecesario. En el 95% de las aplicaciones es difícil justificar que necesitas exprimir tanto el CPU como para necesitar usar C.
Por portabilidad es mejor java (y en breve espero que C# al haberse liberado el .Net), para entornos web hay mil opciones mejores que C
#2: Porque hay gente que así se siente más guay.
Que cada uno escriba en el lenguaje que prefiera. A mi por ejemplo Python no me gusta por esto:
http://www.freecadweb.org/wiki/index.php?title=Dialog_creation/en#The_complete_script
Ahí tenéis un ejemplo de porqué Python no me gusta. En C (o en JavaScript) todo está estructurado con llaves , en Python no las hay. ¿Por qué? No lo se, pero yo ahí veo un código muy desligado, suelto...
Ojo, que JavaScript tiene sus pegas, como usar el + para "sumar" frases, es decir, juntar cadenas de texto. Si, parece bonito y cómodo al principio... hasta que tienes que convencer al motor de JavaScript que no quieres escribir "34", sino que sume lo que valen dos variables, siendo en ese caso la primera un 3 y la segunda un 4, y intentando conseguir un 7, no que te ponga un número detrás de otro.
#29 Python/Javascript y C son lenguajes incomparables. Pertenecen a dos paradigmas diferentes. Yo por ejemplo no me siento comodo trabajando en un lenguaje que no sea fuertemente tipado. Ya me cuesta prescindir de la gestión de memoria en Java, pero si me quitas los tipos no soy nadie.
Las diferencias que comentas me parecen trivialidades. El identado de Python esta bien por que fuerza a los novatos a identar bien su código. La segúnda queja es un problema derivado de la falta de tipado y de la ambigüedad general de los operadores.
#36: Lo de los tipos es algo bastante odioso en JavaScript, porque se producen muchas ambigüedades que luego cuesta un montón resolver.
Es mejor tener que poner siempre un "convertir_texto(var)" que andar rebuscando la fuente de un error y que salga de ahí.
En cuanto al indentado de Python no me gusta, porque en general me gusta decidir yo la estructura de mi código, y no que la decida el autor del lenguaje de programación.
#36 Aunque imagino que con lo de "la segunda queja" te refieres a lo que dice #29 sobre Javascript, conste que Python sí es un lenguaje fuertemente tipado, otra cosa es que tenga tipado dinámico y eso pueda gustar más o menos.
Entre otras cosas en Python no puedes concatenar un string y un integer sin realizar una conversión, y otras características de los lenguajes débilmente tipados o no tipados.
#60 Tenia entendido que Python era debilmente tipado. La verdad es que no he trabajado prácticamente nada con el (Alguna tontería jugando con el Euler Project, poco mas). Tienes razón.
#29 Pues yo lo veo perfectamente. El código no necesita llaves porque está bien indentado, que es una de las características de Python.
#48: ¿Y si a mi me da la gana indentarlo de otra forma porque lo veo más ordenado?
Porque en C y JavaScript lo hago bastante, poner varias instrucciones en una misma línea, sobretodo cuando comparten una estructura común.
A mi en general no me gusta que me lleven con correa como a los perros, me gusta poder decidir cómo hago mis programas.
#55 Porque en C y JavaScript lo hago bastante, poner varias instrucciones en una misma línea, sobretodo cuando comparten una estructura común.
Mereces la muerte a pellizcos, desde el respeto
#67: No si lo documentas bien con un comentario.
Cuando hago eso lo que intento es tener un código más compacto al ojo, yo personalmente lo veo mejor así.
#70 No se me ocurre ninguna situación donde se pueda justificar poner varias instrucciones en una misma linea.
Es mas, el código debería ser autoexplicativo (Salvo en excepciones), si necesitas un comentario es que algo no estás hacienda bien.
#70 No necesitas hacer cosas raras con las indentaciones. Cada bloque de código es un "nivel más de ejecución".
Ese script de Python lo estoy leyendo perfectamente, sé qué hace y ni sé de qué trata. Anda que no he visto desarrolladores en otros lenguajes liarla parda con las indentaciones.
Si te asusta es porque no sabes programar en Python, igual que a mí a priori me puede asustar Perl o Ruby.
#48 La manía por las llaves se te quita la primera vez que pierdes una mañana porque alguien puso espacios en vez de tabs para indentar.
#66 ESA gente.
Por otro lado debate ya muy antiguo, pero del que siempre defenderé los tabs. Programar con espacios es el mal, pero en Python ya es para mandar a pastar al que lo ha hecho.
#97 No será tan maligno programar con espacios cuando la misma Style Guide oficial de Python los recomienda :
https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces
#29 Supuestamente las llaves dan la libertad de escribir como te de la gana. Si quieres puedes hacer un programa de una sola línea. Pero resulta que si no sigues algún standard después ni tu entiendes lo que has escrito, así que al final terminas utilizando la indentación para hacer más claro el programa con lo que las llaves dejan de tener utilidad. En python directamente usas la indentación y no necesitas las llaves.
#54: Pero el problema está en la falta de libertad.
Si en un programa tengo una estructura con subestructuras y quiero dar valores de inicialización, me gusta agruparlos dentro de una misma línea. También suelo meter en una misma línea los "case - break" de C cuando sólo tienen una instrucción.
#61 Sí, te entiendo. Pero lo que te decía es que si te tomas demasiadas "libertades", el programa puede volverse muy difícil de leer. Al final uno con el tiempo termina llegando a al conclusión de que más vale indentar bien y las llaves terminan siendo un estorbo. Ojo, que yo no programo en Python. A pesar de que hace mucho que no lo uso, mi lenguaje preferido es el Pascal y actualmente lo que más uso es PHP, Javascript y a veces C++. Pero reconozco que la sintaxis más estricta de Python es una ventaja.
#79: A ver, que no escribo todo el código en una línea. Cuando meto varias instrucciones por línea es en casos como este, en el que hay una relación entre lo primero y lo segundo (es evidente que esto sólo puede hacerse en zonas muy concretas y aisladas, no hacerlo de repente con una línea en medio del código sin más, porque entonces no la ves):
function variable_validar(min, max, variable)
El objetivo es tener a la izquierda todos los casos que provocan que haya que devolver un 0 (falso) y a la derecha lo que se hace. Yo personalmente lo veo mejor porque tengo todo junto, sin "return" entre medias que me obstaculicen la vista.
#Nota: si, se que en JS hay "trues y falses", pero es un código heredado de C y no quiero arriesgarme a mezclar.
#29 En C (o en JavaScript) todo está estructurado con llaves , en Python no las hay. ¿Por qué? No lo se, pero yo ahí veo un código muy desligado, suelto...
Esa es precisamente una ventaja de Python, no una desventaja. Dividir bloques de código permite a la gente tener malos hábitos de identación, que luego conllevan errores de programación muy graves.
Ejemplo https://www.imperialviolet.org/2014/02/22/applebug.html
#29 Me asombra la gente que dice que Python no le gusta "porque no tiene llaves".
Python es precioso de leer precisamente por este hecho. Nada hay más horrible que estar programando y tener entre medias una escalerita de 7, 10 ó 15 llaves o paréntesis cerrándose, o los "end" esos to feos de Ruby.
Un código bien indentado es más sencillo de leer que uno donde la gente escribe las funciones y las clases y los bucles como le sale de las gónadas. Si algo me gusta de los proyectos en Python es que todos los programadores se ven obligados por el lenguaje a gastar la misma indentación, piensen lo que piensen y vengan de la escuela que vengan. Qué asco esos proyectos donde cada uno se cree el más listo de la oficina e indenta las cosas como le da la gana, haciendo que lo que ya es complicado de entender (leer código no es como leerse El País) encima sea difícil de leer.
#2 Un motivo que veo claro es por la depuración. La gestión manual de punteros y de memoria puede hacer que los programas erroneos no cancelen a veces cuando llegan a una la línea erronea. Un buffer overflow pude hacer que escribas en otra variable a la que accede el programa dentro de media hora. También te puedes cargar el puntero que indica donde esta el area una memória, cuando haces un free de esa area el espacio no se libera y la memoria se va consumiendo. Un día sin más el programa falla y no tienes ni idea que es lo que está pasando. Puedes reducir esto con buenas practicas de programación, pero si programas en equipo nunca vas ha estar completamente seguro de lo que ha echo otra personas. He visto programas que han estado fallando durante meses por que nadie tenia cojones de encontrar el error.
Lenguajes como Java tienen comprobación edinámica de limítes, gestión automática de memoria, etc. Por diseño estos errores son directamente imposibles.
Voto errónea porque el artículo y sus recomendaciones no hay por donde cogerlas. Ridículo
#16 Yo estoy tentado.
At no point should you be typing the word unsigned into your code. We can now write code without the ugly C convention of multi-word types that impair readability as well as usage. Who wants to type unsigned long long int when you can type uint64_t?
Y luego abajo dice:
Instead of:
long diff = (long)ptrOld - (long)ptrNew;
Use:
ptrdiff_t diff = (uintptr_t)ptrOld - (uintptr_t)ptrNew;
Desde luego dice que ha hecho un borrador, y es que no lo ha revisado.
#58 Es que solo la primera recomendación ya es para tirarse de los pelos, lo más ridículo que he leido nunca.
"No usar char, int, short, long..." y sí usar uint8_t, uint32_t .. etc.
La del #pragma once, cuando no es estándar.
La de no utilizar memset, y luego reconocer que su alternativa no sirve debido al padding
La de utilizar arrays dinámicos en lugar de alojar memoria (como si el stack fuese infinito).
La de usar bool en lugar de devolver un valor especial (ptr == NULL), como si fuera una novedad gracias a stdbool
La de no usar malloc...
Pero bueno qué te puedes esperar del idiota que programó redis
#144 En mi comentario #72 tienes un pequeño resumen de mi "no hay por donde cogerlo". Se puede ampliar, estoy abierto a debate.
#72 Añado de regalo un pequeño ejercicio para el lector, haciendo uso de una de sus malvadas recomendaciones:
int my_array[10000000]; // variable global
...
int main() ; // crash si compilas con clang , optimizado a memset en gcc.
// es posible que crashee en gcc también si compilas sin optimizaciones.
Por qué hay un crash siguiendo el consejo tan útil de este señor ?
#72 char, int, short y long son dependientes de la arquitectura. Por poner un ejemplo, en un sparc los int eran de 4 bytes, mientras que en un ia64 eran 8. char solían "intercambiarlo" alegremente con short, pero es que short no tenía por qué ser 1 byte, en ciertas máquinas eran 2. ¿Código portable y seguro? y una mierda. Los que se salvaban eran los float y double y porque se definieron de manera estándar por cierto comité.
¿Entiendes por qué usar tipos uint8_t, etc. que están fijados a un tamaño independientemente de la arquitectura subyacente al tamaño que representan es mucho mejor y más seguro si quieres hacerlo portable? así que para nada es tontería.
El pragma once está soportado por todos los compiladores modernos. Si vas a usar código C99 o c11 que es de lo que va el artícuylo lo soportarán, así que tampoco es una estupidez.
Lo de no usar memset es porque no todo el mundo necesita exprimir el rendimiento del procesador hasta el último suspiro (alineando datos para hacer más efectiva la caché y demás). Si símplemente quieres inicializar una struct por ser más legible en código, tienes una alternativa mejor y más simple. Lo cual tampoco es una tontería.
Lo de los arrays si me parece una buena cagada.
Aunque a mi siempre me gustó devolver enteros (podía interpretar qué tipo de error o acierto devolvía según el valor), reconozco que era una potencial fuente de errores y que en general usar booleanos true y false es mucho más seguro (que por ejemplo el segundo ejemplo, donde no se sabe qué pasa si llega un valor diferente a 0, 1 ó 2), si lo han incorporado al lenguaje por mi estupendo.
Lo del malloc se explica sólo, no hace comprobaciones de ningún tipo a la hora de dar esa memoria. Pero eso es así desde siempre y nunca está de más recordárselo a los que quieran retomar el lenguaje o aprenderlo de nuevas.
#72: Una pregunta: ¿Dónde puedo encontrar más información sobre memoria dinámica sin malloc en C?
Tampoco te compliques en responderme, si no sabes alguna página donde comenten un poco eso del stack (cuando haces pop() ya no hay stack... perdón) para ver un poco los detalles, porque me temo que no debe ser tan simple como lo pintan en el artículo.
Hola #72
Estuve un tiempo viendo el código de redis (para ver código ajeno en C y eso, aprender ya sabes). Mi confusión ha sido cuando te he leído, ¿No está bien programado redis? ¿Tiene fallos? ¿Cuales serían los más importantes?
Para que me orientes y pueda buscar información.
#144 Gracias por tu comentario. Lo de irrelevante muchas veces me saca de las casillas por gente que tumba noticias porque son de otra ciudad, o no saben del tema. Menéame es más que política.
Sobre la calidad del contenido del artículo, he de decir que coincido un poco con #16, he visto varias contradicciones en la misma sección del texto. El tema a mí me interesa mucho, pero si el autor hubiera pulido más su contenido no hubiera cometido imprecisiones.
Ni mucho menos pretendemos desmerecer tu intención.
Glorioso artículo, gracias #0
Alucino con los que votan irrelevante al mejor envío de programación de lo que va de año.
#19 A mucha gente que no le interesa la informática ni la programación es normal que les resulte irrelevante. También es normal tratándose de un foro de política, donde a veces se envían cosas ajenas a la política que no siempre acaban cuajando.
#19 no entiendo qué le ves de glorioso a un artículo escueto, limitado, y plagado de errores y desinformación. Explícate.
Espero que si programas en C como tu nick indica no hagas las burradas que recomiendan aquí.
¡Qué moderneces! Donde esté el Cobol de toda la vida
#14 No entiendo que utilidad tiene no aprender a usar un IDE aparte de sentirte mas macho.
#17 las clases en papel, las prácticas en PC, los exámenes en papel, los exámenes de prácticas en PC. 70% en papel 30% en IDE.
#26 tú estarás en la ETSInf no en la ETSII de la UPV . Java en industriales solo se toca en 4 en una asignatura para aplicaciones en dispositivos móviles .
#34 Me has dado una guía no una razón para hacer un examen a papel eso sólo sirve para tener que aprenderte de memoria muchas cosas que tienes en la documentación del lenguaje.
#39 es que no quería darte una razón quería decirte que si que nos enseñan a usar el IDE, al menos una parte.
#41 Si te he entendido. Lo que quiero es saber por qué dices que hay que aprender en papel.
Me hace gracia que todo el mundo sabe un montón y dicen que C no vale para nada, y resulta que que es el segundo lenguaje más usado del mundo, por detrás de Java.
Que atrevida es la ignorancia.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Yo ya sé C--
#10 Malo malo...
Como nadie lo ha puesto aún, ahí va:
Se puede programar una web en C: https://github.com/acanas/swad-core // autobombo
#45 Uff, vaya locura. He echado un ojo muy muy por encima, y realmente es el último lenguaje de los que "sé" que elegiría para un proyecto así. Veo que es para la Universidad de Granada.
De lo poco que he podido contrastar fuera del C es el JS, y lo veo a bastante distancia de como yo lo hacía/hago, supongo que porque te has centrado en C. Pero vamos, toda esa gestión de fechas cuando tienes librerías como moment, no le veo mucho sentido (y puedes caparlas todo lo que quieras para que no pesen tanto).
Por cierto, he visto SOAP para ws, ¿pero tienes la parte cliente hecha también en C? En teoría debería estar en el mismo lenguaje para dotarle de ese sentido SOAP (y las estructuras de intercambio XML), ¿no? Y claro, Java Applets, JS,... sí, ¿pero como tiras de C en navegador si no es emscripten?
Lo que más me interesa es saber cual es la razón de diseño por la que decides hacer eso en C, si lo has hecho solo y que cuentes alguna experiencia del proceso.
Un saludo y ánimo.
#88 Gracias por tu interés. Aquí tienes más información de cómo está montado y quienes hemos trabajado en el proyecto: http://es.slideshare.net/acanas/inside-swad
Respondo tus dudas (tocho):
Como bien dices, fue un proyecto para la Universidad de Granada. En 2010 lo liberamos Liberada la plataforma SWAD bajo licencia AGPL v3
Liberada la plataforma SWAD bajo licencia AGPL v3
softlibre.barrapunto.comProbablemente hoy no empezaría a hacer un proyecto de este tipo en C. El principal motivo es que comencé en 1999, y entonces yo no conocía la existencia de PHP u otros lenguajes. Bueno, realmente sabía que existía Perl, pero que me perdone mi compañero experto en Perl, no tuve la curiosidad suficiente para aprenderlo. También hay que decir que todo empezó como una prueba de concepto o un divertimento y fue con el tiempo que se convirtió en algo más serio. Un par de años después ya tenía bastante código hecho y huí hacia delante
C se usa en el servidor para ofrecer las páginas web mediante el protocolo CGI. En el cliente sólo hay HTML5, CSS y JavaScript. Usamos un poquito de AJAX, a pelo. No usamos ningún framework de JavaScript.
La desventaja de usar C es no disponer de la potencia de funciones pensadas para la web que tienen otros lenguajes. La ventaja es que es muy ligero en el servidor. Ofrecemos hasta unas 400K páginas vistas al día (picos de 1000 por minuto) en un único servidor (no es un cluster), y con un uso bajo de CPU. El cuello de botella es mucho más MySQL/MariaDB que el CGI escrito en C. Me consta que con PHP el propio PHP consume muchos recursos.
En general soy reacio a usar bibliotecas/librerías por un motivo: cambian sus especificaciones cada pocos años o incluso meses. Si el proyecto se mantiene entre varios es posible que cada miembro pueda centrarse en un aspecto y adaptar las llamadas cuando cambie la especificación, pero cuando estás solo en un proyecto de más de 15 años, no puedes multiplicarte. Sólo las uso cuando no queda más remedio. En este proyecto uso algunas bibliotecas y programas de terceros de JavaScript (jstz, DropzoneJS, MathJax), C/C++ (gsoap, sha) y otros (pandoc, iconv). Barajé moment pero era demasiado grande para lo poco que quería hacer y preferí programarlo yo. Lo mismo con XML, programé un parser sencillo de XML porque las bibliotecas que encontraba eran demasiado complejas.
Usamos gsoap como servidor para ofrecer un servicio web SOAP https://openswad.org/ws/ y también como cliente para acceder a servicios web SOAP de terceros. Respondiendo a tu pregunta, los clientes de nuestro servicio web no están programados en C, sino que son principalmente apps móviles como SWADroid https://swadroid.wordpress.com/ Lo de usar SOAP en vez de otra tecnología para comunicarnos entre aplicaciones es por la misma razón que usar C: cuando empezamos era lo que conocíamos, y cambiar cuesta mucho.
Espero haber aclarado tus dudas
El problema del c son los programas de c. Puedes usar el cfree para empezar, pero como quieras usar netbeans o eclipse para c querras morirte. Llevo toda la p mañana intentando meter el mingw. Desde netbeans te mandan a sourceforge, y el exe tiene virus segun virustotal. Sourceforge no es confiable en todo caso. Si lo intentas con eclipse tampoco hay manera. Tener que tocar las paths para que tire es ganas de tocar los huevos. No tengo idea de como hacerlo... ni entiendo para que lo complican todo tanto.
#73 Uso Eclipse con el plugin de C desde hace más de tres años y estoy contento con él. Me costó un poco al principio, eso sí. Y va muy fluido con disco SSD, antes no.
#c-78" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2542865/order/78">#78 Pero como has instalado el mingcc o el otro?? Sabes alguna pagina con un buen tuto o alguna recomendación? Uso androidstudio para java/android y rodado. El visualstudio para c# y ningun problema. Pero no puedo ni iniciar proyectos sin esa cosa en netbeans o eclipse para c. Es desesperante.
Y gracias
#73 http://codelite.org/
#73 http://www.codeblocks.org/
Yo soy más de FORTRAN, pero amo al C puro. Siempre seré más de unsigned char que de uint8, y demás enums...
Instead of:
long diff = (long)ptrOld - (long)ptrNew;
Use:
ptrdiff_t diff = (uintptr_t)ptrOld - (uintptr_t)ptrNew;
Hace lustros que hago nada en C (desde mi proyecto de final de carrera). Me alegro profundamente que hayan trabajado en liberar a C de tener que hacer pirulas para todo.
Ahora solo falta que hagan lo mismo para Javascript.
#23 Recuerda: http://babeljs.io/docs/learn-es2015/
#23 lo mismo, hace montón que no lo uso, pero no lo descarto volver a hacer, según el proyecto. Al contrario que mucha gente en este post, el sobrecomplicar las cosas produce código mucho más largo, complejo y difícil de mantener. Cuanto más viejo el perro, más sencilla quiere su vida, y en mi caso ocurre algo parecido..
¡Sólo puedes aprender C si ya lo sabes!
Hasta hace 4 años en la ETSII de Valencia nos enseñaban C. Ignoro si se sigue enseñando pero apuesto a que sí.
#8 En Sevilla enseñan Java en papel y boli.
Edito, en la ETSI si no recuerdo mal siguen enseñando C.
#11 en Valencia también es así y desde mi punto de vista así debe de seguir siendo.
#8 En Industriales de Valladolid aprendí C (2006), y hasta donde sé es el lenguaje que se sigue enseñando.
Y si, como dice #11, el 80% del examen era a papel y boli
#15: Y se sigue aprendiendo C, y yo creo que hacen bien, porque de C es fácil saltar al resto. En cambio, saltar de algún otro lenguaje a otro (incluído C) no suele ser tan fácil. Incluso de ensamblador a C es difícil porque C es un lenguaje estructurado y en compilador se adquieren "malas prácticas" en C.
#11 En Teleco en Sevilla se da C, ASM, Java y (en Telemática) un poco de C++ y Objective-C.
#11 En la politécnica de Huelva, hace 15 años se empezaba con Pascal y luego C.
#8 Estoy en segundo, y en la mayoría de asignaturas trabajamos en Java. En LTP además hemos tocado Prolog y Haskell. Sólo hemos programado en C en FSO.
#8 El C sigue siendo un lenguaje útil, no para aplicaciones de tamaño grande, pero sí para rutinas de bajo nivel. Muchos dispositivos llevan rutinas en C
Aprendí a programar en C (que no es lo mismo que saber C, que creo que realmente muy poca gente SABE) y doy gracias.
Gestión de memoria, programación a bajo nivel... hoy en día lo uso mucho en mi trabajo.
Y aunque las aplicaciones de escritorio las desarrollo en C# por rapidez, lo que aprendí en C lo uso cada día más en autómatas.
Pues yo hasta ahora me he ganado la vida programando en C, C++, Java y C# y si pudiera programaría exclusivamente en C, creo que después de 18 años programando (es decir, sufriendo, programar en España es sufrir) es lo único que me devolvería la ilusión por la profesión.
#63 Pues yo prefiero Rust, pero entiendo que todavia no es la opcion mas evidente por su falta de madurez.
#89 Prefiero Rust por las ideas y renovación que trae, además de que siempre me ha gustado aprender lenguajes nuevos. Pero a día de hoy si tuviera que seguir haciendo embebidos (según cual) probablemente seguiría con C. He visto algunos proyectos de Rust pero les falta algo de soporte y continúan desarrollando toolchains para soporte a dispositivos embebidos. De todas formas les sigo con interés, aunque no he vuelto a probarlo desde antes de la 1.0rc. Ahora los embebidos no es más que hobby, pero muy de vez en cuando, y supongo que cuando saque más tiempo volveré a intentar usar Rust.
Java y C++ me aburren sobremanera desde hace años. El primero sobre todo, es muy simple y tosco. Ya son varios los proyectos a las espaldas y más de 50k líneas de Java que habré lanzado, y siempre que puedo lo evito. Tengo suerte de poder elegir.
#63 algo asi como que te dieran tiempo suficiente como para hacer codigo rapido y elegante?
Hace relativamente poco, tuve que hacer un plugin npapi en C. Acostumbrado a funciones y tipado de alto nivel, volver a programar en C fue un puto infierno. Y meterle otras dlls o código fuente al proyecto daba para hacerse el harakiri.
Yo llevo como 20 años usando C, luego C++ y ahora C#, y hoy es el día que para hacer un "for", tengo que pararme un segundo a pensar cómo se hace.
#c-3" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2542865/order/3">#3 ¿Sabes que dicen que lo del # del C# es porque es cuatro veces +?
Yo digo que al C# lo que es del C#.
#c-7" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2542865/order/7">#7 ¿y le pusieron la # para no entrar en disputa con Citroen?
#25 Claro, si no sería C^^
#25: Citroën, con diéresis.
#c-7" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2542865/order/7">#7 c# es c++ para niños
Yo programo en C: y luego guardo el software en cederrones.
Hello world
C# powah!
Yo con lo poco que he trabajado con C++ y Java he visto que son tremendamente parecidos, vamos que si aprendes a programar en C luego lo tienes realmente facil para saltar a Java.
#24 aquí se está hablando de c no de C++.
Pregunta seria de uno que abandonó la programación para escritorio por motivos laborales pero quiere retomar, ¿que lenguaje e IDE se utiliza ahora habitualmente para programar para Windows?
#65 Hola, yo diría que Visual Studio para Windows sigue siendo la opción más usada. También Eclipse, Netbeans, etc.
#65 Para Java, Intellij Idea. No es gratis, pero tiene versión Community
También te recomiendo para empezar pasar de IDEs y usar un editor de texto como notepad++ que te colorea la sintaxis de cualquier lenguaje
A veces aprender a usar un IDE lleva un sobre esfuerzo, y bastante tienes con aprender un lenguaje
#c-65" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2542865/order/65">#65 Acabo de releer tu comentario y me he dado cuenta que te refieres a programar únicamente aplicaciones de escritorio. En tal caso tienes que elegir librería, a parte de lenguaje e IDE. Mis opciones son:
Java + Swing
C++ + Qt
Python + PyQtPySide
Las tres opciones son multiplataforma. Si te da igual que tu aplicación no funcione en Mac Os y Linux, puede que el camino más fácil sea usar C# + WinForms (O la librería que corresponda, no estoy muy puesto)
Hoy en día existen lenguajes como Rust o Go que pueden sustituir a C en casi cualquier escenario y están mucho mejor preparados para la programación multihilo. Salvo para sistemas legacy donde no quede más remedio que seguir usando C es difícil pensar un escenario donde iniciar un nuevo proyecto con C tenga sentido la verdad.
La elección de un lenguaje de programación en un proyecto (o parte) raramente depende del gusto de quien lo use. Supongo que no hace falta listar la cantidad de factores que deciden qué lenguaje hay que usar para implementar la solución.
Cada uno se sentirá más cómodo en un lenguaje u otro dependiendo de su conocimiento, experiencia, rendibilidad, etc. Personalmente, no veo motivo para evitar C cuando sea posible usarlo si se cumplen las condiciones necesarias.
#57 Intuyo muchos más escenarios en los que iniciar un proyecto en C tenga mucha más ventaja que hacerlo en Rust o Go. Cuenta sólo la probabilidad de que un programador sepa C o Rust/Go, o la probabilidad que tengas librerias ya desarrolladas en C (aprovechables) y quieras tener un entorno homgeneizado.