Tecnología, Internet y juegos
325 meneos
13267 clics

Unos consejos para los interesados en programar (bien)

Programar es fácil, programar bien es muy difícil. No hay que engañar, que luego abandonan decepcionados a la primera complicación. Problemas complejos + estructuras complejas requieren dominio de algoritmos básicos fundamentales, y conocer la complejidad de cada uno.

| etiquetas: programar , bien , consejos
147 178 4 K 502
147 178 4 K 502
  1. Los libros sobre algoritmos aue recomidnda gallir estan en ingles.

    Aqui va la heregia, ¿alguno reclmendable y mas o menos basico en español?

    No me importa tragarme documentacion o ejemplos en ingles pero ponerse con algo asi sin base alguna, si es en tu lengua materna mucho mejor.

    Yo es que soy un negado en matematicas, y aunque para muchos programas no me ha hecho falta para otroa si es muy necesario( ya de paso cualquier cosa relacionada con matematicas para tontos aplicables genial)


    Por cierto yo creo que se le tiene tirria a php porque cualquiera programa en php y ademas es un lenguaje muy extendido
  2. No sé qué pinta esto aquí. Aquí somos todos los mejores programadores de la galaxia y parte del extranjero. Y los rabos nos llegan por la rodilla.
  3. #100 Creo que confundes "productivo" con chapucero. En realidad puedes ser "productivo" mientras realizas buenas prácticas de programación (quienes mantengan tu código -y tú mismo en el futuro- te lo agradecerán), y eso lo puedes lograr en Pascal, Java y hasta PHP. O puedes ser chapucero y terminar antes, pero dejando un desastre sin posibilidades de mantenimiento a futuro, y eso también lo puedes lograr con PHP, Java y hasta Pascal.
  4. #9 Sir, deliver naww
  5. #103 Es cuestión de gustos y habilidades. Hay quienes son expertos copiando, pegando y ensamblando 1000 librerías, frameworks, scripts y fragmentos copiados de foros y Stackoverflow, para publicar algo rápido y que funcione. Eso sí, luego no trates de modificarlo o actualizar alguna librería. Creo que PHP se hizo para esa clase de "programadores".
  6. Umm, yo catalogaría a PHP como un lenguaje para iniciados. Su extensión lo hace complejo a la hora de mantenerlo, por lo que para trabajar con el hay que saber como hacer las cosas correctamente y tener una guía de estilos bien potente.

    Cualquier cosa relacionada con la programación web es un tema complejo, por la variedad de tecnologías, rendimiento, seguridad...
  7. #87 Yo he entrado indignado por lo que dice de javascript:

    JAVASCRIPT ES UNA MIERDA COMO UN TEMPLO. Con javascript se hacen cosas que quedan chulas en web, pero, en si, es una mierda como un templo. Todo lo que puedes hacer con javascript son castillos de naipes...
  8. #100 Perdon por el negativo, me se fue la mano
  9. #25 Los problemas de C/C++ son dos, primero no tiene estructuras de datos avanzadas estandarizadas (arrays, sets, hashs...), es cierto que con C++11 han mejorado muchísimo la librería estandar, pero antes era un coñazo estar utilizando librerías adicionales o programartelas tu mismo. Por otro lado el tener que preocuparse uno mismo de la gestión de memoria permite mejorar el rendimiento, pero es bastante coñazo a parte de ser muy propenso a que haya fallos o menory leaks.
  10. #38 PHP es malo, punto, está mal diseñado, está mal implementado, carece de muchísimas características básicas, permite hacer cosas horribles, es un lenguaje para diseñadores que pseudo-programan. Claro hay genios que pueden hacer programas decentes, pero un hay músicos que podrían hacer canciones decentes usando trastes de cocinan, pero eso no convierte a los trastes de cocina en instrumentos músicales.
  11. ¿En serio ha llegado esto a portada? Vaya tela María Manuela.
  12. No sé la manía a C++, si decimos Objective C, pero C++... con su STL y no tener que preocuparse de los malloc ni los delete cada vez que defines un string o una lista.
  13. #111 PHP es malo, punto, está mal diseñado, está mal implementado,</i
    aquí estaría bien que indicases ejemplos/referencias

    carece de muchísimas características básicas,
    ¿qué le echas en falta que sea "básico"?

    permite hacer cosas horribles,
    como cualquier lenguaje de programación...

    es un lenguaje para diseñadores que pseudo-programan.
    Es cierto que puedes, y de hecho inicialmente se pensó así, embeber PHP dentro del HTML. Pero la mayoría del código que se realiza actualmente, al menos en mi experiencia, el PHP embebido en HTML se deja justo en la parte de la producción de la salida. La única diferencia frente a otros lenguajes que no se puedan embeber es que el resto de lenguajes lo tendrías que hacer con un motor de plantillas. Cosa que con PHP también se puede y de hecho se hace...

    Respecto a los trastos de cocina y los lenguajes de programación, me remito a lo que he dicho en el anterior comentario. La mayoría de lenguajes de programación (todos los que yo conozco al menos...) permiten hacer cosas que harían llorar al niño Jesús. Ahora, si las haces no es problema del lenguaje de pogramación...

  14. Se ha salvado por poner enlace a dos libros, porque el resto son sobradas de barra de bar la mayoría.
  15. Me gustó esta charla, está bien para empezar.

    www.youtube.com/watch?v=0SARbwvhupQ

    Eso y leer Code Complete. Siempre leer Code Complete.
  16. #49 para hace gráficas PHP es una pasada. Yo hice hace ya casi una década una web de monitorización de consultas de usuarios para la dgt con carreteras y provincias marcadas por colores en función del uso. Y con PHP. El lenguaje no suele ser importante... Yo uso en el dia a dia 4 o 5 y en mi poco tiempo libre otros 3. Todos tienen esa base común que no hay que reaprender, luego cada uno con particularidades que le dan mucha potencia. Por ejemplo esto de ruby es una pasada:

    `6.upto(10) {|x| puts x}`

    Incluso objective c tiene perlitas, una vez superado el periodo de pánico.

    Para ser buen programador, por otro lado, leerse Clean Code. Lo demás son tonterías www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350
  17. Voy a burlarme un poco cambiando la profesión de informático por la de constructor en sus consejos:

    Construir una casa es fácil. Construir una casa bien es muy difícil. No hay que engañar, que luego abandonan decepcionados a la primera complicación.

    Cuanto más grandes es una casa, más debes pensar en su mantenimiento futuro. Hacerlo bien lleva aún más práctica.

    A medida que crece la casa, se necesitan materiales y estructuras más complejas.

    Casa compleja con estructuras complejas, requieren el dominio de lo básico.

    Y aquí la mayoría peta de forma estrepitosa ¿Pongo un cable de 1.5 ó de 6? ¿Meto un tubo de 80x40 o necesitaré uno de 80x60?

    Lo digo fudamentalmente por "enseñar a los niños" y que "todos deben saber un poco de electricidad y fontanería". Bien, pero cuidado en crear falsas espectativas.

    Así como todo el mundo no puede ser buen músico, no todo el mundo tiene la capacidad o la voluntad de esforzarse en ser un manitas.

    Saber cambiar un enchufe no requiere la experiencia para diseñar, construir y mantener una casa compleja.

    Nunca empecéis a diseñar la cocina con el programa de IKEA. Agrega una capa de abstracción muy elevada.

    Una excavadora no está mal, pero exige GASOIL, lo que os hace demasiado dependiente de él, y no sabéis ni usar un pico y una pala.
  18. Hola mi nombre es Find y programo en C#
  19. #2 discrepo, el problema de PHP es que se popularizó demasiado y la cantidad de código basura que puedes encontrar en Internet es abrumadora.

    Eso sí, hasta PHP 5.3 ni siquiera lo puedes considerar como lenguaje de programación.
  20. Yo resumiría todos los consejos en uno: "cada vez que toques algo, no solo tiene que funcionar, sino que lo tienes que entender y no aumentar la complejidad más de lo necesario". Cuando llegas al punto que implementar algo en tu programa es más complicado que el problema que quieres resolver, lo estás haciendo mal :-P
  21. Al final esto de comparar lenguajes en sí tiene su gracia, pero es bastante mas importante todo el "contexto" que rodea una plataforma. El IDE/Debugger, Frameworks y librerías. Vamos ya puede ser la ostia el lenguaje que como no tenga un IDE que vaya bien no lo pienso usar en el mundo real, y si luego tienes que picarte una librería para generar pdfs ya ni te cuento..

    Yo puedo comparar trabajar profesionalmente con Java y Php con Eclipse y cada uno tienes sus ventajas y desventajas. Prefiero Java como lenguaje, debo ser cuadriculado, me gustan los lenguajes tipados, si tengo un array con peras no quiero meter manzanas, luego el open call hierarchy funciona de lujo y se donde se usa esa función. Pero el no tener que re-arrancar el maldito servidor cada vez que hago un cambio en una clase me hace querer a PHP..
  22. Es aquí donde ponen a parir a PHP?
  23. #106 Eso es cierto, desde que programo en PHP pienso menos, busco en google y acabo en stackoverflow.
  24. #110 Planeta tierra llamando a Jupiter: developer.gnome.org/glib/2.40/glib-data-types.html
    (Cuidado, no confundir glib -The GNU Lib- con glibc -la implementatción de libc de GNU-)

    C-- tiene STL desde hace siglos, pero aun así, C-- sigue siendo una mierda pinchada en un palo.

    Más info: developer.gnome.org/glib/2.40/
  25. #34 Yo al reves, aprendi POO en C++ y luego empece a programar en java. El paso de c++ a Java es muy facil, al reves, jodido. Echo de menos cosas de c++ que no tengo en Java, como la sobrecarga de operadores.
  26. Me sorprende que gallir no mencione los patrones de diseño. Sobre todo el libro de Gamma y compañía.
  27. #125 126 comentarios y sólo uno rajando de Javascript? Donde iremos a parar.. :palm:
  28. #110 smart pointers de c++11
  29. #127 Ya que existe GLib, Boost.... me refiero a tener todas esas estructuras en el propio STL. Y claro que hay un STL, pero comparado con lo que te ofrecen los lenguajes "modernos" (Ruby, Python...) no tiene color. Con C+11 han intentado solucionar esto, pero no no se usa en muchos sitios aun.
  30. '...Nunca comencéis a aprender con programación orientada a objetos (ni con lenguajes que lo exijan), agrega una capa de abstracción muy elevada...'

    Error. En los paises nórdicos desde primero de carrera Java con objetos. El error es empezar a programar sin pensar en objetos. No lo digo yo (que también), lo practica hoy la propia universidad que inventó en los 70 la programación orientada a objetos.

    '...Java no está mal, y mejoró mucho en los últimos años, pero exige un IDE, lo que os hace demasiado dependientes de él y no sabéis ni sangrar...'


    Falso. Java puede programarse desde cualquier editor de texto, desde cualquiera, VIM incluido. El IDE es completamente opcional, aunque pueda ayudar mucho a gente que empieza más que nada por los autocompletados opcionales.

    No es una critica, en la mayor parte de consejos lleva razón, pero no todos conocen como se tratajan en otros paises estos temas de primera mano.
  31. Edit #133. '...Y si uno quiere empezar a ser bueno programando, ni diría que hay que saber ensamblador, pero dominar C es un requisito básico...'

    Y si uno quiere entender bien C saber ensamblador (o al menos tener buenas nociones) es un requisito básico.

    '...C es fundamental porque es un lenguaje muy simple pero cercano a la arquitectura, aprendes cómo se implementan todas las abstracciones...'

    Y en Java, y en lenguajes funcionales tipo HASKELL, LISP o SCHEME (en realidad con cualquier lenguaje de programación serio puede hacerse). Las abstracciones son propias del la orientación a objetos y la orientación a objetos la facilitan mucho, razón de más para empezar a programar con objetos desde el principio.
  32. #47 Hice un curso de programación básica en Coursera porque lo hacían en Racket y me pareció muy cómodo para aprender programación funcional.

    El lenguaje tiene niveles y puedes empezar por lo más básico y luego ir subiendo de complejidad. Además puedes usar primitivas de dibujo directamente como tipos de datos lo que hace que sea más entretenido. Me dió la sensación de ser un "Logo" pero en funcional.

    Lo malo es que fuera del ámbito del apredizaje no parece que haya proyectos complejos hechos en Racket y se queda como un mero entretenimiento para pasar luego a lenguajes aparentemente menos de juguete.
  33. Para #3. Goto #133 && #134.
  34. Mi recomendación para aquellos que quiera a prender a programar como dios manda desde cero.

    Empezad por leer esto:
    download-mirror.savannah.gnu.org/releases/pgubook/ProgrammingGroundUp-
  35. #50 Completamente de acuerdo. Manejar punteros directamente es cada vez más arcaico. Entre la STL, o incluso mejor, usando BOOST, lo que es necesidad de utilizarlos no tienes, la gran mayoría de las veces. A ver, tienes una clase string, la clase vector que almacena lo que quieras, la clase map, que es un diccionario.... Para que quiero un char*?

    Y si lo quiero, pues uso punteros inteligentes (que se liberan solos si no les referencian), y tan contento--> unique_ptr<char> en vez de char*
  36. Para #101. '...¿alguno reclmendable y mas o menos basico en español?...'

    Olvídalo, las traducciones suelen y tienden a ser terribles. Para temas avanzados los autores españoles más 'conocidos' van siempre 20 pasos por detrás que la mayoría de autores en lengua inglesa que tienen todos estos temas ya superados desde hace décadas.

    El inglés es claro y conciso en estos temas, te sale más a cuenta meterte de cabeza en el inglés que permitir que te lien las ciencias en computación con retorcida prosa española.
  37. Poner nombres de variables indentificables, como algunas grandes consultoras obligan a sus picateclas:
    XJP005AH116, por ejemplo, que se ve claramente que es para almacenar el apellido. :troll:
  38. Y quizá no hubiese sido mejor hacer un articulo que tropecientos twitts? quisir cada cosa sirve pa lo que sirve, twitter pa una cosa y los artículos pa otra.
  39. Para #50. '...Saber qué hace la máquina por debajo es lo de menos. Y te lo dice alguien que aprendió con C y fue fan de ASM en su día...'

    Me pongo bastante triste cada vez que se ataca de forma totalmente injusta al ensamblador.

    Sin ensamblador ni se podrían programar lenguajes de alto nivel ni se podrian compilar (ni ejecutar). En fin, que sin ensamblador digamos que no tendriamos ni los chips del PC ni PC.

    Sin ensamblador no podriamos literalmente hablar directamente con el 'hardware', algo que los sistemas operativos a ciertos niveles agradecen profundamente.

    Programar es un campo de muchos ámbitos.

    Para resolver problemas de la vida cotidiana la orientación a objetos es perfecta porque el mundo está lleno de objetos reales (e imaginarios) que pueden representarse facilmente.

    Para resolver problemas relacionados directamente con los propios ordenadores, tan necesarios ellos, para comunicarse directamente con su hardware, para diseñar cierto tipo de hardware, para facilitar la vida de los humanos via compilarores, para comprender y desarrollar areas básicas de las ciencias de la computación saber que hace la máquina es imprescindible.
  40. #142 todo eso está muy bien, pero programar en ensamblador es innecesario porque tienes unos compiladores muy majos que lo escriben más rápido, mejor, más optimizado y con más comprobaciones de los que cualquiero humano sería capaz.

    Los compiladores son mucho mejores que tú programando. Los lenguajes de alto nivel no son más que instrucciones a los compiladores para que programen por ti. Qué mejor que aprovecharlo ;)

    Es que ni en empotrado se usa ya ASM, ni mucho menos en CISC donde tienes extensiones que añaden instrucciones que están pensadas para los compiladores y no para un humano.

    Si usas ASM para optimizar, you are doing it wrong.

    > Para resolver problemas de la vida cotidiana la orientación a objetos es perfecta porque el mundo está lleno de objetos reales (e imaginarios) que pueden representarse facilmente.

    Soy fan de la FP así que ahí discrepamos :-P

    Seamos sinceros. El 99% de las veces este es el trabajo. Una simple capa CRUD con algo de UI específica para el caso de uso por encima y tirando.

    > Para resolver problemas relacionados directamente con los propios ordenadores, [...], para comunicarse directamente con su hardware, para diseñar cierto tipo de hardware

    Ese trabajo la mayoría de veces es de lo que en EEUU llaman Electrical Engineering, no de un Software Engineer (que es de lo que implícitamente habla Gallir y hablamos en general todos los comentarios del hilo).

    > para comprender y desarrollar areas básicas de las ciencias de la computación saber que hace la máquina es imprescindible.

    Sí, tal y como digo en otros comentarios.
  41. #142 Así pasa luego, que los picateclas creen que la memoría y el disco es infinito, lo mismo que los recursos de procesador.
  42. #142 ah, y por cierto, ¿"se ataca de forma totalmente injusta al ensamblador"?

    No es un ataque. Es una realidad. Saber ASM es lo de menos porque es completamente innecesario para ese 99% de desarrollos reales. Ojalá todo el mundo aprendiera ASM porque es muy divertido, pero... ¿útil?

    Obviamente si vas a escribir compiladores no es lo de menos, pero citar como me suelen citar cuestiones de rendimiento... en 2014 no tiene sentido, porque a mano vas a hacer un ASM menos eficiente que cualquier compilador seguro.

    ¿Qué sin ASM no podría existir el compilador? Sí. ¿Que compiladores son un 0,1% de los desarrollos? También. ¿Que los compiladores que se escriben compilan a backends en plan LLVM o son transpilers así que no tienes ni que aprender ASM? También.
  43. #142 para aclarar algo más mi posición (maldito tiempo de edición xD) cuando digo "saber un lenguaje" distingo entre "saber" y "conocer".

    Saber ASM es saber TODAS las instrucciones (o la mayoría) de tu arquitectura de pe a pa, no conocer un poco cómo funciona. Por ejemplo, ¿qué hace PAVGW en SSE de x86? Yo ni puta idea e imagino que tú tampoco, así que ninguno de los dos realmente sabemos ASM 686.

    Del mismo modo que saber C y aprender a crear clases NO es saber C++.
  44. #38 No puedo estar más de acuerdo contigo.

    La condena que se hace a PHP en este articulo por el Doctor, es como tirarse de cabeza a una piscina vacía. Creo que lo más importante es, antes de ponerse manos a la obra, buscar, comparar y tomar la mejor decisión de usar las librerías/lenguajes apropiado para el problema que tenemos, ahorrando lo máximo en costes y esfuerzo. Para ello suelo buscar por la red y hacer caso omiso a este tipo de condenas personales que se hacen sin aportar ningún dato objetivo. Lo mismo con XML/JSON, me encanta JSON, pero no ofrece la misma robustez que un XML validado con un DTD. no? es un ejemplo.
    Tengo experiencia y multitud de proyectos desarrollados en PHP, MySql, javascript que dejarían a menéame en la lógica de un hello world B) :P. Por el lado de procesado/servidor me encanta Perl, la potencia de las bases de datos orientadas a columnas, estudio y selección de algoritmos, procedimientos almacenados, programación del cron de linux, la escalabilidad de las máquinas virtuales, y, sobre todo, la multitud de soluciones libres que disponemos.
    Hoy en día no nocesitamos ser Oracle, Microsoft o SAP para hacer algo muy muy grande. Con conocimiento de lo que hay disponible y perdiendo el miedo, eres capaz de hacer casi cualquier cosa.
    PD: Me esperaba un articulo que algo sobre buenas practicas, código limpio, control de versiones, entornos colaborativos, etc. En fín, decepción
  45. #142 y sin adn tendriamos humanos, pero aqui estamos chingando sin tener ni puta idea de que estamos programando adn
  46. #147 eso es algo que pienso a veces, a dia de hoy solo mi imaginacion es el limite lo demas solo es una cuestion de tiempo ver manuales y aprender
  47. Para programar en C++ no es obligatorio usar todas las features del lenguaje.
  48. #151 Si el motor de plantillas en cuestión, implementa sistemas de caché, implementan funciones que facilitan el desarrollo de las mismas y que permiten que se el diseño de plantillas se aleje de la programación pura y dura y se centre más en el desarrollo de las plantillas propiamente, puede que no lo sea tanto.
  49. #38 Python se recomienda sobre todo para empezar, y creo que eso mismo dicen en el artículo, mejor empezar con Python que con PHP, a mi me parece que tiene bastante sentido.
  50. #156 Podrás empezar a programar con lo que quieras. Y si, puedo estar de acuerdo que Python es bueno para empezar. Pero cuando has aprendido a programar, luego lo que toca es programar. Y cuando hablamos de programación web, como ya he dicho antes, no he encontrado ningún argumento que me haga decantarme hacia otro lenguaje. Hablando del caso general, obviamente.

    En ciertos contexto, puedo preferir NodeJS, donde el requisito del tiempo real sea más crítico. Pero es es más la excepción que la norma para el común de los mortales.
  51. #155 No te obceques. Puede que PHP naciese como un motor de plantillas, pero es más que evidente que su objetivo ya no es ni por asomo ese.

    Respecto a que implemente su propio lenguaje para las plantillas: tampoco lo veo problema. Si la sintaxis luego le resulta más cómoda a un diseñador que la de PHP ¿por qué no? Además, los motores de plantillas lo que suelen hacer es coger dicha plantilla y compilarla a PHP.

    Además, los motores de plantillas implementan ciertas funcionalidades que PHP no lo hace y tiene sentido que no lo haga, pues son demasiado específicas del mundillo de los motores de plantillas que, como te he dicho, PHP hace tiempo que trata de alejarse. Por ejemplo, la herencia de plantillas: www.smarty.net/docs/en/advanced.features.template.inheritance.tpl twig.sensiolabs.org/doc/templates.html#template-inheritance

    Personalmente soy de los que piensa que PHP no debería ir embebido en el HTML en la medida de lo posible, y en mis desarrollos así trato de hacerlo. Pero entiendo que haya gente que se sienta cómoda con ello y tampoco me sangran los ojos si está hecho con cierto criterio.

    No hay que ser más papista que el papa.
  52. #136 #133 #134

    Es un error enseñar Java desde el principio, lo experimento desde hace años (ojo, doy clases y veo la diferencia), y expliqué porqué:

    - Porque se usa IDE (es casi obligatorio si no eres gurú de Java, y no lo eres cuando comienzas a programar) por lo que ni entienden muy bien qué están haciendo (cosas del autocompletar, por ejemplo) y ni siquiera aprenden a estructurar y sangrar el código (porque ya lo hace el IDE).

    - Por obliga a aprenderse "reglas" sin saber muy bien por qué, por ejemplo:

    public class HelloWorld {

    public static void main(String[] args) {
    System.out.println("Hello, World");
    }

    }

    ¿Qué es una clase? ¿qué es una función pública estática de una clase? Para que lo entiendan deben aprender antes conceptos de POO, pero resulta que todavía ni saben lo que es "programar algoritmos en lenguajes imperativos secuenciales" (Java y todos los lenguajes orientados a objetos son eso, fundamentalmente).

    Lo mismo en Python:

    print("Hello world")

    ¿Cuál es más claro y cuál exige menos conocimientos? (y lo puedes hacer en cualquier editor de texto y ejecutar directamente (python hello.py, sin necesidad de IDE o llamadas a builders previas).

    Por otro lado, justificar que es bueno "porque lo usan en universidades nórdicas" es una falacia de autoridad de copón. No creo que sus profesores sean mejor que yo, ni que no puedan cometer fallos.

    hay opiniones de otra gente muy experta que piensa lo mismo que yo, por ejemplo: www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html


    Y sobre ensamblador, no dije que no haya que aprenderlo, sólo que no lo pondría como un requisito fuerte:

    1. Estoy hablando de "gente que quiere aprender a programar", no de estudios universitarios de informática (donde sí se lo estudia).

    2. Afirmo que se necesita como mínimo saber C para relacionar lo que se programa a como se ejecuta en la arquitectura.

    3. Saber más lenguajes de programación siempre es bueno, y nunca diría que no se haga.

    4. Yo programo o programé en: Fortran, Basic, Cobol, Prolog, Pascal, Ada, C, C++, Smalltalk, Shell/Bash, awk, Perl, Ruby, Python, Java, Lisp, PHP, Javascript... Es decir, sé un poco de lenguajes, y de todos, Python me parece el más simple y potente para empezar a aprender, y el C un requisito mínimo.
  53. Para #159. Cuando vivía en España pensaba igual que tu, que empezar con la programación a objetos antes que la estructurada era un error, pero hoy lo veo completamente al revés.

    Java no es un lenguaje complicado, es infinitamente más sencillo que el imprescindible ansi C en muchos aspectos, y no se necesita entender todo desde el principio para empezar a escribir código que haga algo.

    Si quieres ver las prácticas que realicé desde el primer curso puedo pasarte un enlace en un privado, lo tienen todo online y las prácticas suelen colgarlas también en inglés. Es un problema de metodología en la enseñanza y clases de apoyo con estudiantes de cursos superiores, no es más complicado aprender Java que Ada, en absoluto. La orientación a objetos, los conceptos básicos de las internalidades de Java y ejemplos sencillos de implementación de código están al alcance de cualquiera si se sabe como impartirlos, y de ahí hacia adelante.
  54. #160 Varias preguntas:

    1. ¿Sabes C? Si es así, ¿para qué, si no hace falta?

    2. Java y su entorno de programación está diseñado para evitar los errores estúpidos de programadores, que me pases una práctica (que son programas pequeños) en Java no demuestra nada, mis alumnos también las tienen desde primero y no tienen idea de programar con punteros, ni hacer debug si no tienen el IDE que los haga.

    3. Pásame una práctica más o menos compleja en C (por ejemplo mis alumnos de SO2 hace un sistema de ficheros completo, pero pequeño, sólo 2200-2500 líneas de código, y les cuesta mucho) y podré evaluar mejor tus conocimientos y buena programación. ¿Lo espero? gallir en gmail.com.
  55. #160 Yo empecé de cero con Java. Incluso, mi sobrino con 12 años está aprendiendo a programar en Java gracias a un juego. Y le ha ido muy bien.
  56. #161 Por que no colgáis la practica y la evaluación de la misma en algún sitio donde todos podamos verla y así aprendemos algo?
  57. Para #161.

    1) No lo tengo fresco pero conozco/sé ansi C y como debug utilizaba GDB en terminal y ocasionalmente alguna versión de GDB gráfica, pero vamos, que era lo mismo.

    2) Java no tiene entorno IDE por defecto, si te descargar el SDK de java puedes picarlo todo sin problemas en editores de texto plano. El problema es la cantidad de funcionalidades que disponen sus librerias sumadas a las que ofrezca tu propio código, el autocompletado en los IDE ayuda mucho paran perderse entre mil anotaciones.

    3) Tengo que buscarlas. Fueron dos prácticas con valor parcial en la nota final, en la primera implementamos una agenda para telefono movil a muy bajo nivel en una porción reducida de memoria con mucho tema de punteros y optimización (de espacio). En la segunda implementamos un servidor/cliente (ambas partes). El servidor debía soportar conexiones al mismo tiempo para varios clientes y el objetivo era visualizar directorios, visualizar el contenido de archivos, y cosas así desde un menu definido, remotamente entre dos máquina via TCP/IP. Puedo enviártelas en otro momento sin problemas.
  58. Ya que estamos y creo que viene al caso:

    En inglés: www.coursera.org/course/algo

    En spanglish: www.coursera.org/course/pealgoritmico
  59. #50 Yo creo que tendemos a ser chovinistas los que venimos de la universidad y nos hemos pegado con Pascal, C y posteriormente C++.

    No creo que debamos(en terminos laborales) pensar que alguien que aprende Java y sólo Java tenga que ser un mal programador. Probablemente es curioso en su trabajo y respeta las buenas prácticas en la forma de hacer las cosas.

    Ahora bien...

    Yo estoy corrigiendo exámenes de candidatos para entrar en una empresa importante dedicada a este mundo y he de decir que los que sólo conocen Java, suelen hacer un examen muy bueno en la parte Java que es elemental, pero no captan los detalles del problema, que es donde se dan los puntos, es decir, donde vamos a pillar al examinado. Además, de que cuando se van al resto del examen donde no hay palabra de java, sino de otro lenguaje o directamente pseudocódigo, meten la pata estrepitosamente.

    Por otro lado, los que hacen el examen y son de carrera, sin experiencia, suelen fallar en el conocimiento del lenguaje pero demuestran un espabilo mayor allí donde hay problemas lógicos que comprender.

    No sé si me explico, pero creo que las tablas en programación (conocer los cimientos de que va todo esto) son necesarias al fin y al cabo.
  60. Hay un problema recurrente. Los malos programadores dan trabajo a más malos programadores. Y así hasta el infinito.
  61. #163 No puedo publicar código que no es mío, y mucho menos si es de alumnos. Pero aquí tienes la guía de desarrollo por semanas para el sistema de ficheros (es un copy&paste del campus virtual, el formato queda una mierda):

    dl.dropboxusercontent.com/u/13267747/so2-guia.odt
  62. Para #161. '...pero pequeño, sólo 2200-2500 líneas de código...'

    Y es que cuesta. Al inicio y durante el proceso de aprendizaje Ansi C es duro, pero fue fantástico sentirse tan cerca del metal, de la máquina.
  63. #111 "Claro hay genios que pueden hacer programas decentes"

    Falso. Yo hago programas decentes en PHP y no soy un genio.
  64. #162 Claro, el tema es cuando tengas que realizar un algoritmo avanzado y eficiente, si no conoces las estructuras y funcionamiento bruto de las abstracciones que utilizas acabas haciendo chapuzas. Luego resulta que ¿Por qué tarda tanto en arrancar este programa tan simplón?

    Si te quieres dedicar a ello a nivel profesional, es una mala elección empezar por ahí, porque puedes sentir que controlas más de lo que realmente controlas y porque no vas a entender los argumentos que te den para elegir dos opciones que funcionan.

    Por ejemplo, he visto utilizar un HashMap (pares clave-valor, en cada lenguaje se llamarán X) con claves tal que 1, 2, 3... 18751548, sin ningún valor intermedio ausente. Claro, eso funciona, Java te deja, ahora, si sabes algo de estructuras de datos y lo que implica esa acción sabrás que lo correcto habría sido usar un ArrayList.

    Cosas que te obligan a saber si aprendes con un lenguaje que no ofrezca tanta abstracción (C, Pascal, Fortran...) sobre lo que implica ese uso de HashMap:
    *Estás obligando a calcular un hash de cada índice numérico, eso conlleva ciclos de reloj, y al ser índices enteros consecutivos es absurdo.
    *Una vez calculado el hash, la búsqueda de la coincidencia para obtener la entrada es otra vez pesada, aún metiendo un árbol binario (si sabes lo que es)
    *Una vez obtenida la entrada hay que comprobar la colisión del hash.
    *Estás desperdiciando memoria en conservar un hash y el entero que sirve de índice.

    ¿Cómo se resuelve con un array a partir del índice?
    1 - Se multiplica el índice por el tamaño de cada entrada.
    2 - Yastá.

    Los primeros pasos son los que más te marcan el aprendizaje, si tienes alguna mala manía programando muy difícil te vas a librar de ella. Si programas en C las malas manías se quitan a golpe de "Violación del segmento" y corrupción de memoria (del proceso).

    Y luego, si dejas Java y te quieres adentrar en... digamos... programar para dispositivos embebidos, drivers, sistemas operativos o herramientas de bajo nivel, vas a flipar en colores de todas las asunciones erróneas que tenías, doble de quebraderos de cabeza. En cambio, aprender Java o C# controlando C es un juego de niños, no paras de pensar "oh, que guay, ya tiene una herramienta para hacer esto solo", pero sabiendo y conociendo qué es lo que está haciendo realmente.

    Luego vayamos a la exageración ¿Ensamblador? Bien, ensamblador tiene una serie de problemas,
    * el primero y evidente es que hay un ensamblador por cada procesador ya que programas directamente para ese hardware, no puedes aprenderlos todos y no es práctico.
    * el segundo que el control de la estructura de datos entre asm y c tiene un salto brutal en dificultad pero un mínimo impacto en rendimiento (incluso un compilador podría hacerlo mejor que tu si no eres un genio bestial y controlas un huevo de procesadores "¿Hola? ¿Estoy empezando recuerdas?").
    * luego está el detalle de que no vas a poder ejecutar tus programas de iniciado en hardware real hoy día (o muy difícilmente), vas a tener que pelearte pues con emuladores de ensamblador que a saber qué hacen y que tal lo implementan y si equivale realmente a un procesador real. "¿Estoy aprendiendo algo o es solo un juguete difícil con lucecitas?"
    * también que es bastante ilegible y para entenderlo hace falta conocer la arquitectura interna de una CPU (no, de LA CPU para la que es ese ensamblador), que tampoco está mal, pero ahí ya nos vamos a saber ingeniería informática y no solo a programar...
  65. #143 Discrepo parcialmente: en mi trabajo una de las cosas a las que me dedico, que por suerte no es la única :), es a optimizar trozos de código. Y no lo hago en ensamblador, pero si que me miro el que genera el compilador para comprobar que todo es correcto: que la vectorización está bien hecha, que hay prefetchers donde toca, que los bucles están desplegados, que se usa precisión simple en vez de doble y un montón de cosas más. Y no, no siempre el compilador lo hace bien, hay que mimarlo un poquito y darle las cosas bien masticadas.

    En general aquí todo el mundo barre para casa pensando que lo que él hace es lo correcto, cuando en realidad hay un montón de campos distintos y lo que es necesario y funciona en una especialidad no tiene porque hacerlo en otra.
  66. Respecto al tema de si PHP es un mal lenguaje no estoy de acuerdo. Los lenguajes de programación son simplemente un medio de comunicación simplificada entre el hombre y la máquina. Al igual que sucede en los distintos idiomas cada uno tiene sus propias particularidades y características. Por ejemplo en francés el número 90 se escribe "quatre-vingt-dix", que representa cuatro por veinte más diez. Ésto no es nada óptimo ni ventajoso frente a como se escribe en español o en inglés (ninety). Algunos podrían decir algo similar a los que critican ciertos lenguajes de programación: "¡el francés es una m***da! Pero lo cierto es que a pesar de esa supuesta desventaja Francia ha conseguido estar muy por delante de nosotros en ciencia y tecnología. Para ellos no ha supuesto ninguna problema porque lo importante es el uso que se hace. Lo mismo se puede decir acerca de las grandes obras de la literatura o de la música realizada por distintos intrumentos o incluso de las distintas formas de codificación de las notas musicales.

    En realidad un buen programador lo es independientemente del lenguaje que use. Se pueden encontrar verdaderas maravillas en PHP y verdaderos bodrios en Python y viceversa. Un lenguaje no evita usar malas prácticas y otro sí pero eso no quiere decir que el programa final vaya a estar mal hecho. Cada lenguaje tiene sus puntos fuertes y sus puntos débiles y lo bueno es saber elegir el adecuado para cada proyecto y programar de forma óptima, sencilla, clara y ordenada.
  67. #169 Cógete un emulador de Spectrum y crea código ASM para Z80.

    Ahí vas a optimizar por cojones tu código.

    Hay gente que se ha hecho hasta un Doom en 3D.

    Y bueno, si ves programas como Elite en 48k... es para pensárselo.
  68. #139 "
    El inglés es claro y conciso en estos temas, te sale más a cuenta meterte de cabeza en el inglés que permitir que te lien las ciencias en computación con retorcida prosa española. "

    He ahí mi problema con las mates en secundaria. En inglés, pillaba todo a velocidad supersónica.

    En castellano (y euskera igual), dan 50 vueltas para explicar una simple ecuación.

    Por eso, en Code Academy, cuenta en inglés. No quiero leer cuarenta frases subordinadas como si fuera una obra de Cicerón para saber como se asigna usa simple variable.
  69. #175 En serio, ponme una frase en inglés que no puedas decir con la misma sencillez en español. Una sola. Te reto.

    Otra cosa es que la gente se complique más o menos, pero el idioma no es responsable de como lo use la gente.
  70. Para #176. '...pero el idioma no es responsable de como lo use la gente...'

    No tengo pruebas que lo demuestren, pero estoy convencido de que te equivocas. CC #175

    Dale la vuelta y experimenta como mentalmente se cambia el chip cuando uno se expresa en otro idioma que empieza a dominar.
  71. #176 Por lo general, las expresiones matemáticas en los idiomas son mucho más cortas que en idiomas latinos/germánicos.

    Eso ayuda a expresar y entender las mismas operaciones mucho más rápido.

    Parecido a decir "añadiendo dos unidades a dos unidades, obtenemos como resultado cuatro " a "dos,añadir,dos,cuatro" en chino/japonés .

    Pues en el castellano, en los manuales de programación, realizan los mismos fallos. Las explicaciones son largas e innecesarias.
  72. #178 Perdón, quise decir "las expresiones matemáticas en los idiomas asiáticos son mucho más cortas que en idiomas latinos/germánicos."
  73. #178 "Parecido a decir "añadiendo dos unidades a dos unidades, obtenemos como resultado cuatro " a "dos,añadir,dos,cuatro" en chino/japonés ."

    dos y dos son cuatro :-P

    En serio, estoy estudiando japonés y chino, y lo que dices no es cierto. De hecho la forma que enseñan de hablar es relativamente enrevesada. Lo que ocurre es que en el habla real se simplifica, se utiliza el contexto. Pero tanto en idiomas asiáticos como en latinos.

    #177 "Dale la vuelta y experimenta como mentalmente se cambia el chip cuando uno se expresa en otro idioma que empieza a dominar."

    Hablo inglés, y estoy estudiando japonés, y algo de chino. Y nada de esto me obliga a cambiar el chip. Igual a ti si, pero se trata de una experiencia particular tuya, que no a todos nos ocurre.
  74. Para #180. Pues yo he cambiado el chip en un montón de aspectos de mi vida residiendo en el extranjero y creo que en buena medida el nuevo idioma ha tenido bastante que ver. El idioma dice mucho de nosotros y de sus respectivas culturas.
  75. #91 ¿Que Composer es mejor que los "gestores de paquetes" de Python?

    :-O
  76. #182 si trabajas en linux y con lo típico de Python va bien, pero ponte a desarrollar para Windows y verás.

    Por cierto ¿cuánto tiempo hace que no usas composer? Con los nuevos estándares PSR-4 y PSR-5 la función de autoload es la polla y el duo git / composer va como la seda.
  77. #86 vamos, que han hecho un

    gcc python.c -O php
  78. #183 Si tampoco digo lo contrario, simplemente que yo no suelo tener problemas con pip, aunque no lo he probado mucho bajo Windows. Y sin embargo Composer tiene más pinta de "inacabado" cuando lo he usado.
  79. #181 "Pues yo he cambiado el chip en un montón de aspectos de mi vida residiendo en el extranjero y creo que en buena medida el nuevo idioma ha tenido bastante que ver"

    A poco que lo pienses te darás cuenta que si te vas a Argentina, a Méjico, a Guinea, a Cuba,... vas a cambiar el chip en muchos aspectos, a pesar de ser el mismo idioma.

    Tu puedes creer que en parte es el idioma, pero realmente no lo sabes por que ha habido otras variables. Yo por contra he aprendido sin moverme del país, y se que eso no me ha cambiado el chip.

    "El idioma dice mucho de nosotros y de sus respectivas culturas"

    Dira algo, no lo niego, aunque la realidad es que distintas culturas compartimos el mismo idioma. Pero por si no recuerdas de donde partió esto, yo dije "el idioma no es responsable de como lo use la gente", lo que no es incompatible con que el como lo use la gente hable de su cultura.
  80. #180 " De hecho la forma que enseñan de hablar es relativamente enrevesada"

    Cierto, pero observa cualquier clase de mates en chino.

    O mejor aún, cambia en Code Academy tu leccion al castellano.
  81. #187 "Cierto, pero observa cualquier clase de mates en chino."

    ¿En serio has visto muchas clases de mates en chino? Yo ninguna

    "O mejor aún, cambia en Code Academy tu leccion al castellano."

    Te repito, ponme una frase que no se pueda poner igualmente simple en castellano. El que la traducción la hayan hecho más compleja no significa que no se pueda hacer mejor.
  82. #188 En el inglés la gramática es más sencilla y directa comparada con el castellano.

    Menos rodeos = interpretación más rapida de conceptos que requieren una explicación larga.
  83. #189 "En el inglés la gramática es más sencilla y directa comparada con el castellano."

    No estoy de acuerdo, pero por favor, pon ejemplos si lo crees así.

    De hecho la gramática española e inglesa son bastantes similares comparada con la de otros lenguajes
  84. #189 Te voy a poner un ejemplo de lo similares que son las gramáticas, usando la entrada de programación orientada a objetos de la wikipedia:

    "Object-oriented programming (OOP) is a programming paradigm that represents the concept of "objects" that have data fields (attributes that describe the object) and associated procedures known as methods. Objects, which are usually instances of classes, are used to interact with one another to design applications and computer programs.[1][2] C++, Objective-C, Smalltalk, Java, C#, Perl, Python, Ruby and PHP are examples of object-oriented programming languages."

    "Programación orientada a objetos (POO) es un paradigma de programación que representa el concepto de "objetos" que tiene campos de datos (atributos que describen el objeto) y procedimientos asociados conocidos como métodos. Los objetos, que usualmente son instancias de clases, son usados para interactuar unos con otros para diseñar aplicaciones y programas de ordenador.[1][2] C++, Objective-C, Smalltalk, Java, C#, Perl, Python, Ruby y PHP son ejemplos de lenguajes de programación orientada a objetos."

    No me parece que el español complique en absoluto la explicación.
  85. LA "Programación orientada a objetos (POO) es un paradigma de programación que representa el concepto de "objetos"" Es una traducción literal pésima.
  86. #192 "Es una traducción literal pésima."

    Que si, que como traductor doy asco :-P . Pero el caso es que es español correcto y que es tan sencillo como la versión inglesa.

    Yo aporto ejemplos y argumentos, mientras que tu te limitas a indicar que yo soy mal traductor, lo que por si no te habías dado cuenta, nada aporta al debate :-P
  87. Es curioso, casi todos los comentarios de esta noticia han sido escritos por programadores, y en general están mejor redactados y tienen menos falta de ortografía que los de noticias generales o de política :-)
  88. #195 Ese artículo en la mayoría de los casos lo que viene a decir es que si no lees la documentación, te puedes encontrar con "sorpresas". Pero dichas "sorpresas" lo que vienen a decir es que la lógica de uno no tiene porque ser la válida.

    Por ejemplo:
    array_search, strpos, and similar functions return 0 if they find the needle at position zero, but false if they don’t find it at all.
    ...
    In C, functions like strpos return -1 if the item isn’t found. If you don’t check for that case and try to use that as an index, you’ll hit junk memory and your program will blow up. (Probably. It’s C. Who the fuck knows. I’m sure there are tools for this, at least.)


    Si, es un fastidio que no pueda venir directamente de C y ponerme a programar con PHP. Pero personalmente, si no se encuentra algo, prefiero que se me devuelva una excepción, o de no ser así, un tipo que sea completamente distinto al resultado que espero cuando la función opera correctamente.
    Si no fuera porque en C las funciones tienen que devolver siempre el mismo tipo si no quieres trabajar con void *, seguramente utilizarían un formato similar a PHP, o eso creo.
    En fin, que comparar estrictamente (===) con false en lugar de con -1 me parece más elegante.

    [] cannot slice; it only retrieves individual elements.
    Si, es una pena. Pero eso el único lenguaje que lo soporta tal cual es Python, de los que yo conozca. ¿Son los demás lenguajes una basura por no tenerlo?
    Para los que no tenemos la piel tan fina: es1.php.net/array_slice

    En otro casos, podemos ver que hablar es gratis, y no hace falta investigar lo más mínimo:
    include() and friends are basically C’s #include: they dump another source file into yours. There is no module system, even for PHP code.

    Supongamos que tenemos un fichero entero.php con el siguiente contenido "<?php return 1;"
    Y luego tenemos otro fichero con este contenido: "<?php echo include('entero.php');"
    Esto con PHP funciona. Con C, la adaptación tal cual, no.

    En fin, podría seguir, pero no me vale la pena con un artículo tan poco sólido como ese, movido más por las preferencias personales en general. Como ya he dicho, la mayoría de ataques contra PHP los hacen gente que esperan saltar de C directamente a PHP sin leer una línea del manual. Lo siento, no funciona así. Si quieres hacer webs sabiendo C, para eso existe el CGI.

    Puedo estar de acuerdo con que, por ejemplo, la cantidad de funciones relativas a los arrays debería haber hecho pensar a alguien que un Array debería ser un objeto, con sus correspondientes métodos. Pero bueno, es a mi particularmente no me nubla la vista de que PHP me proporciona ventajas frente a otros lenguajes para la programación web, que es para lo que lo uso, frente a otros comparando la distribución básica.
    Y si nos ponemos con el tema de las librerías, pues que le vamos a hacer, PHP lleva muchos años de rodaje y por eso tiene librerías para casi todo lo que pueda necesitar. De hecho, nunca ha habido nada para lo cual no dispusiese de una librería, puede que haya tenido suere...
  89. #194 Eso es porque los programadores sabemos activar el corrector ortográfico :-)
  90. #171 Agradezco mucho que te tomaras el tiempo en explicarme esto tan detalladamente. Nunca lo había visto de eso modo, pero ya de esta forma creo tienes mucha razón. Entonces qué recomiendas para empezar, ¿Python? No sé por qué se me hace tan pesada la sintaxis de ese lenguaje.
  91. #198 Anda, no esperaba una respuesta así, y como ves me conecto muy de vez en cuando.

    Lo que es aprender a programar puede hacerse con cualquier lenguaje, ahora, para hacerlo bien como dice el título, es mejor conocer las bases, la barrabasada que mencioné antes fue en un programa "profesional", así que para simplemente trabajar se ve que llega.

    Con Python tengo poco contacto, pero he visto de todo, gente a la que le ha ayudado por su rigidez estructural y gente que lo detesta y aborrece por la falta de identidad y flexibilidad. Es un lenguaje interesante pero supongo que se aprende lo mismo que con Java.

    Yo recomendaría empezar por los que son la base de todo lo que hay ahora en cuanto a lenguajes de programación, los tradicionales, tipados, declarativos, incluso sin orientación a objetos... Fortran es un poco suyo y tiene peculiaridades propias, COBOL era de enfoque muy específico y está en proceso de extinción (Alguien me comería por decir eso :-S ), así que me quedaría con C o Pascal, Pascal no deja de ser un C azucarado, sustituyendo las llaves por "END" y "BEGIN", añadiendo una palabra para identificar las funciones... en el fondo, la mayoría de lenguajes que han ido surgiendo copian sintaxis e ideas de C (C también copió en su día, pero sus precursores están caput), añadiendo luego sus dulzores propios.

    Ahora, entiendo que es mucho más frustrante que Java o C# (o PHP o JavaScript...) que llenas una pantalla y ya puedes ver resultados rápidamente. También es más gratificante cuando ves resultados por eso mismo, claro que eso ya es personal y tiene que gustarte esto de controlar al ordenador.

    Yo diría que cosas que hay que hacer, ya en cualquier lenguaje, pero es que hacerlas en Java es un poco "tontería" y no se aprecia tan bien el resultado son:
    - Implementa por tu cuenta (y ayuda de tutoriales para saber cómo son) tipos de dato avanzados: listas enlazadas, arrays con memoria dinámica (de varias dimensiones a poder ser), diccionarios. Si te gusta hasta puedes implementar objetos por tu cuenta ;) Esto ayuda luego a pelearse con lenguajes no tipados o de tipado no explícito, saber cómo lo hacen es muy útil cuando no hacen lo que tu esperabas.
    - Hacer aritmética de punteros y casting, por eso mi lenguaje predilecto para empezar es C, te deja ver todo esto claramente, y que no casque. Algunos te dirán que eso no lo vas a volver a tocar en la vida (ya lo han dicho), es cierto si acabas en la…   » ver todo el comentario
  92. #199 Muchas gracias de nuevo. Sobre esta parte: "recomendaría tocar programas ya hechos, hacerles pequeños cambios, yo que se, te descargas el código fuente de gedit (o notepad++ si usas Windows) y cada vez que escriban tu nombre que lo subraye o remarque".

    Quiero decirte que así di mis primeros pasos con PHP y me resultó bastante bien. Te aseguro me servirán de mucho varios de tus consejos. Los pondré en práctica. ;)
comentarios cerrados

menéame