Recomendaciones para iniciarme en programación

#33: Tío, que estoy dentro, ya sé como va. Y te digo que eso es solo una buena base, pero necesitas muchísimas piezas por encima.

#35: Ya, ya. Pero quiero matizar que lo suyo es hacer los tres cursos, sacar una puntuación perfecta, saber muchas más cosas y, solo después, contactar con ellos para trabajar allí.

PD: Lo de la puntuación perfecta no sé si es posible porque no hice ningún examen aún, pero supongo que no será solo apto/no apto.

Si quieres aprender a hacer cosas rápido: empieza por Java.

Si quieres aprender a programar de verdad: empieza por C, luego sigue por C++ y luego si tal Java, que sabiendo los otros 2 es una tontería aprenderlo.

Java te vale para hacer cosas rápido, pero es una máquina de generar malos hábitos de programación acojonante, traga con todo lo que le metas.

#39 Programar de verdad y malos hábitos de programación van unidos de la mano. Si quieres algo que funcione rápido y eficientemente, no entra en ninguna cabeza hacerlo en Java, básicamente porque su punto fuerte de cara a desarrollar, que es el simplificar la tarea del programador para poder acortar tiempos de desarrollo gracias a evitar la gestión manual de la memoria, es su punto débil en cuanto a rendimiento, y es básicamente el recolector de basura. A eso me refiero con programar de verdad, hacer algo que exprima una máquina al límite o un sistema en tiempo real, no lo vas a hacer con Java por razones obvias. Que sí, que es la ostia de cómodo y para muchas cosas es lo mejor porque puedes hacer por ejemplo webs con servlets y demás en 4 patadas, pero dista mucho de ser el mejor lenguaje, al menos a mi modo de ver.

Y luego malos hábitos, pues en primer lugar no tocas nada de la memoria, con lo cual esa parte no te molestas en pensar acerca de su optimización, lo cual va a derivar en un menor rendimiento de lo que hagas. Después, si estás acostumbrado a Java y su recolector de basura, muy probablemente sufras como un cerdo en caso de querer o tener que cambiarte a un lenguaje con gestión de memoria manual y vas a tener petes por todos los lados. A mayores de esto, está el tema de que tiene cosas muy poco ortodoxas como los casteos mágicos a lo loco. En mi experiencia personal, la gente que se quiere pasar de C/C++ a Java no tiene problema ninguno, porque es una simplificación enorme, pero la gente que quiere hacer al contrario las pasa canutas.

#41 nunca has tenido que hacer ningún sistema en tiempo real no? o para un sistema pequeño?

#43 eres consciente de que hay miles de aplicaciones donde el procesamiento en tiempo real es indispensable?
No sabía yo que no había consolas portátiles con míseros megas de ram sin llegar ni al medio giga, no sabía que las consolas hasta ahora tenían gigas y gigas de ram, o que todos los móviles tengan gigas de ram también, por citar 3 cosas que no van tan sobradas de memoria.

Pero por eso lo digo, es decir, Java es tan cómodo como ineficiente, y es muy cómodo, para determinadas cosas está muy bien y es lo más práctico comparando rendimiento y tiempo de desarrollo, pero vamos, que alguien que está acostumbrado a picar C++ (por comparar con orientación a objetos) está a un nivel superior de programación que alguien que únicamente pica Java, para mí es indiscutible, directamente por lo que te da un lenguaje y otro.

#45 "Tengo abiertas un montón de aplicaciones que son posibles gracias a Java y el framework Android. Eso en C es impensable."
Pues me entero ahora de que C gasta más memoria que Java xDDDD

"What's your point?"

Mi punto es que hay para cosas para las cuales Java no es una alternativa, pero por tema eficiencia C siempre va a ser una alternativa por encima de prácticamente cualquier otro lenguaje.

"Y como digo, ahora con cosas como la RasPI/móviles los casos de uso del RT son cada vez menores... como mucho dispositivos de control y ese tipo de cosas."

Sistemas de visión por ordenador, juegos, sistemas de control de robótica, sistemas de procesado paralelo de alto rendimiento, por citar 4 campos en los que RT es necesario y en los cuales no hay alternativa real a C/C++ salvo contadas excepciones.

Pero vamos, esto era un hilo de por dónde era mejor empezar a aprender programación y estamos bastante desviados del tema xDDDD.

Relativamente a eso (a aprender), para mí el trío a aprender es C/C++/Java, con eso cubres la grandiosísima mayoría de cosas que vayas a necesitar y te va a simplificar muchísimo la vida de cara a aprender nuevos lenguajes.

A eso me refiero con programar de verdad,
hacer algo que exprima una máquina al límite o un sistema en tiempo real

Y luego malos hábitos, pues en primer lugar no tocas nada de la memoria,
con lo cual esa parte no te molestas en pensar acerca de su optimización,
lo cual va a derivar en un menor rendimiento de lo que hagas.

#40 suponía que ibas a responder algo así. Te doy mi opinión:

Ah, pues muy bien. Esa es tu definición. Según a quien preguntes te va a decir una cosa distinta.
Si le preguntas a mi director general, te dirá que un programador de verdad soy yo y mi equipo, que
utilizamos XP como metodología de trabajo y antes del deadline tenemos todo a punto. Y te dirá que el equipo de weberos de mi empresa son lo peor porque se pasan el deadline por el arco del triunfo.

Si le preguntas a un usuario sobre dos webs distintas quién es el programador de verdad, te dirá que la más bonita, aunque por debajo tenga código espagueti del bueno.

Si le preguntas a un profesor de universidad, un engendro como este:

sobre qué es programar de verdad, la respuesta puede ser que programar de verdad es ASM. Y que todo lo que no sea ASM es de pobres. Son personas que dudo que hayan escrito programas de más de 1000 líneas (y estoy siendo generoso).

A mí si me preguntas qué es programar de verdad, te preguntaré a su vez que me des información sobre Qué, Cuándo, Dónde y Cuánto. Y entonces elegiré la herramienta, la metodología y te diré que para ese objetivo en concreto, programar de verdad es hacerlo con esto, de esta forma y en este tiempo. Y todo lo que no sea saber elegir bien la herramienta y la metodología, lo considero un mal hábito.

Cierto es que a mi opinión le he dado un sesgo desde el punto de vista de la ing. del software a nivel empresarial. Pero, por mi parte, basta ya de denostar paradigmas, lenguajes y metodologías. Cada una de ellas tiene su razón de ser y es como comprar churras con merinas. Hace tiempo que no soy ni de apple ni de android, ni de c ni de java, etc. Creo que en estos temas se tiende a caer en absolutismos con puntos de vista obtusos creyendo, por ejemplo, que programar en C es de pr0s y programar en Java es de inútiles.

Es como decir que un Concorde es mejor que una avioneta. Pues si es para ir de Londres a Nueva York con prisa ok. Pero si lo que quiero es ir de mi finca al aeródromo que está a 50Km va a ser que no.

Y los malos hábitos los puedes tener programando en ASM, ActionScript, C, Java, Haskell, Ruby, etc. He aquí un listado de malos hábitos: http://es.wikipedia.org/wiki/Antipatr%C3%B3n_de_dise%C3%B1o. Y aun así, hay situaciones en las que se permite caer en alguno de ellos si tiene en cuenta el compromiso eficiencia/rentabilidad.

Por otro lado, suscribo todo lo referente a tus comentarios sobre C, Java y la eficiencia en términos de velocidad de uno sobre otro. Te veo muy puesto en el asunto. No puedo estar más de acuerdo.

#49 sí, no te creas que me tomé a mal lo de "programar de verdad". Sólo intento decir que hay muchas formas de programar "de verdad" y ninguna es exclusiva, todo depende de qué quieras.

En una empresa les vienes con lo del rendimiento y se te ríen en la cara xD La empresa quiere resultados, no rendimiento. ¿Necesito rendimiento? Pues meto más memoria al servidor o me compro una máquina y que trabaje en paralelo. Los servidores son, como dicen los ingleses, "dirt cheap". Es una cuestión de costes: gasto más tiempo (es decir, dinero) optimizando cuando puedo gastarlo en arreglar bugs y comprar una máquina extra que vale dos pesetas.

En la uni desgraciadamente no lo enseñan, pero en IT prima la mantenibilidad, no el rendimiento. Sigo diciendo que son dos "niveles". Tú lo ves desde el punto de vista teleco/industrial (¿me equivoco?) y yo como ingeniero del software.

Por eso no creo que sea un buen consejo decir que aprendan C porque van a manejar memoria, porque es un... ¿1%? del trabajo que se realiza programando (robótica y poco más, que es donde se necesita RT de verdad), mientras que Java vale para el 99% de las tareas haciendo el tiempo de desarrollo ridículamente bajo comparado con C.

No sólo eso, diría que todo el FUD que hay contra Java en cuanto a rendimiento, es eso, FUD. Créeme que en la JVM 1.7 se ha implementado lo que quiera que tú vayas a implementar en C++ mucho más eficiente, mucho más bonito, con mucho más conocimiento del dominio y, sobre todo, su "codebase" está repleto de conocimiento tácito (corner cases, peleas contra bugs, etc.) Java es mucho más rápido de lo que el 99% de la gente piensa.

Pero bueno paro aquí porque esto es un bucle y como dices hemos deraileado el thread

manejar memoria a mano y luego decir "programo en java" y "ayudo al garbage collector" es cuanto menos curioso (amén de una gilipollez)

#55 va, venga, si citas, cita bien:

Volviendo al tema de la educación, para mí si que es importante aprender a manejar la memoria a mano, puede que sea un 1% de los casos, pero al menos a mi modo de ver, el código resultante si estás acostumbrado a hacerlo manualmente siempre va a simplificarle la vida al garbage collector

Para ayudar al recolector de basura, saber manejar la memoria a mano es completamente irrelevante, lo único que tienes que hacer es evitar usar new en partes temporales del programa donde se reserva memoria en la pila que es liberada al terminarse esa parte (ej: dentro de un bucle o en las variables locales de un método) y poco más...

Es más relevante conocer las particularidades de la plataforma para evitar utilizar cosas que usan "new" por debajo creando objetos que luego hay que limpiar (ej: en Java usar el operador + para concatenar 2 Strings crea por debajo un StringBuffer temporal que es lo que realmente concatena, y que luego tiene ser limpiado por el recolector, por lo que es mejor usar un StringBuffer directamente si vas a concatenar mucho).