Elige tu lenguaje de programación


  • 0



  • 1

    De toda la vida ha sido C++ el que más me ha gustado. :nusenuse:



  • 2

    @Joel dijo:

    De toda la vida ha sido C++ el que más me ha gustado. :nusenuse:

    ¿También sabes programar? :roto2nuse:



  • 3

    @dehm dijo:

    ¿También sabes programar? :roto2nuse:

    Sí, muy orientado a resolver algoritmos (más o menos tipo lo que se ve en las dos primeras asignaturas de programación de ing. informática), pero bueno... :nusenuse:

    Le hice un par de trabajos de programación a mi hermana (no le gusta para nada, pero tenía que dar las asignaturas obligatoriamente) y su profesora le dio la enhorabuena. :gaydude:



  • 4

    @Joel dijo:

    Sí, muy orientado a resolver algoritmos (más o menos tipo lo que se ve en las dos primeras asignaturas de programación de ing. informática), pero bueno... :nusenuse:
    Le hice un par de trabajos de programación a mi hermana (no le gusta para nada, pero tenía que dar las asignaturas obligatoriamente) y su profesora le dio la enhorabuena. :gaydude:

    Qué crack! :mola:



  • 5

    @bean dijo:

    Me ha salido Python,
    Llegué a tenerlo, hace años. No tengo ni idea de programar pero me dio por intentar una cosa y lo bajé. Evidentemente fracasé.

    A mi siempre me ha interesado, pero soy demasiado burro. Con el auge de internet, la oferta de cursos y manuales es infinita, pero es muy duro aprender solo, y más si no somos muy dotados.

    Hace unos 3 años empecé a seguir un curso de C++ en la página de c.conclase.net y cuando iba a abandonar una vez más, tuve la inmensa suerte de que uno de los que están allí se apiadase de mi, y me ayudó muchísimo.

    Desde entonces lo tengo como hobby y he de decir que dentro de mis limitaciones disfruto muchísimo. Supongo que trabajar de forma profesional es otra historia.



  • 6

    @dehm dijo:

    A mi siempre me ha interesado, pero soy demasiado burro. Con el auge de internet, la oferta de cursos y manuales es infinita, pero es muy duro aprender solo, y más si no somos muy dotados.
    Hace unos 3 años empecé a seguir un curso de C++ en la página de c.conclase.net y cuando iba a abandonar una vez más, tuve la inmensa suerte de que uno de los que están allí se apiadase de mi, y me ayudó muchísimo.
    Desde entonces lo tengo como hobby y he de decir que dentro de mis limitaciones disfruto muchísimo. Supongo que trabajar de forma profesional es otra historia.

    Yo empecé también mirando C con clase, luego ya fui mirando un poco de todo de lo que iba encontrando. Solía preguntar alguna que otra duda en elhacker.net, que además allí hay muchos hilos con consejos sobre lo que no es recomendable hacer y tal. Y también, al menos por la época en la que me pasaba por allí, los que respondían a la gente solían decir "no hagas esto, no hagas lo otro" y a base de leer las dudas de los demás terminabas adoptando una buena forma de programar. :qmeparto:



  • 7

    yo no se cual será el mio...... :mrgreen:
    ahora en serio, me quedé en BASIC.



  • 8

    @Joel dijo:

    Yo empecé también mirando C con clase, luego ya fui mirando un poco de todo de lo que iba encontrando. Solía preguntar alguna que otra duda en elhacker.net, que además allí hay muchos hilos con consejos sobre lo que no es recomendable hacer y tal. Y también, al menos por la época en la que me pasaba por allí, los que respondían a la gente solían decir "no hagas esto, no hagas lo otro" y a base de leer las dudas de los demás terminabas adoptando una buena forma de programar. :qmeparto:

    Yo con el tiempo conseguí hacer que las cosas funcionasen. Es decir, me veo capaz de resolver (casi) cualquier problema.

    Sin embargo, también se da uno cuenta de que tarde o temprano cualquiera puede hacer que una cosa funcione. Pero es más difícil hacer las cosas bien, para hacer un código legible, ordenado y mantenible. Y para eso hace falta una buena base, una buena metodología y no buscar atajos. Y en esa parte estoy :qmeparto:

    Por cierto, yo cuando tengo problemas suelo ir a forosdelweb a lloriquear. Y allí hay un usuario que debe ser el mismo que aquí, que es @Madh



  • 9

    Pues yo pensaba que el lenguaje mejor pagado era Ruby y no Java



  • 10

    @dehm la foto es buenisima



  • 11

    @Stalker dijo:

    Pues yo pensaba que el lenguaje mejor pagado era Ruby y no Java

    :facepalm:



  • 12

    @bean ¡Qué raro que en una gráfica "tan neutral" hecha por algún folla-serpientes (Python fanboy) te salga Python! :roto2rie:



  • 13

    @pepehierbas dijo:

    :facepalm:

    Pues yo siempre he pensado que de java hay mas trabajo, pero de ruby siempre mejor pagado. Tampoco estoy muy metido en el mundo profesional pues estoy terminando la carrera, pero eso pensaba yo



  • 14

    JavaScript dificultad 2/5 no se lo cree ni su madre xD al de la gráfica le metía yo a gestionar callbacks :dale2:

    @Stalker efectivamente, Ruby está mejor pagado que Java. Eso está en dólares y vete a saber de dónde han sacado los datos. En España ya te lo digo yo, Ruby está mejor pagado que Java. Ten en cuenta que casi en todas las consultoras hay javeros, pagados como el culo, Ruby se usa más en sitios guays y modernos que tratan al programador dignamente.

    @dehm +1 a que la dificultad está en la calidad del código que haces, no en si funciona. Una buena metodología para hacer código mantenible es el TDD (Test Driven Development). Consiste en hacer primero un test y a continuación implementar el código de producción.
    Es decir, si quisiéramos crear una nueva funcionalidad para nuestro programa, por ejemplo un sistema de "me gusta" para el foro, empezaríamos haciendo un test. Test de que cuando llamo a la función post.like() se añade mi usuario a la lista de "usuarios a los que les gusta este post". El test fallaría, porque la función like() no está implementada, y entonces con un test en rojo pasarías a "resolver el test". En este caso podría ser algo así:

    function like(userId) {
        post.likes.push(userId);
    }
    

    Es un codigo rápido, que añade el userId al array de "likes" del post.
    Pues a continuación volverías al test, y estaria "en verde", es decir, pasaría. Entonces haces otro test, por ejemplo, imaginemos que los likes, cuando se hacen en el primer post de un hilo, además de meterte en el array de likes, te mete en el array de suscriptores.
    Pues ale, otro test, y a ponerlo en verde.

    Y así es como irías avanzando. De esta forma te creas una base de tests, que serán útiles para mantener el código y al mismo tiempo vas descubriendo el problema, implementándolo paso a paso. En cada paso aplicarías también pequeños refactors o modificaciones. Por ejemplo, si la función se ha ido complicando, y tiene ya 20 líneas, un if, un for, etc. pues antes de meter más tests limpiaríamos el código. Sacaríamos funciones más unitarias, quitaríamos código duplicado y todas esas cosas. Y todo con la garantía de que si rompemos algo con esas modificaciones, los tests nos cubren el culo.

    Es la mejor forma de hacer un código de calidad. Aunque sin voluntad ni experiencia por muchos tests que hagas puedes terminar haciendo un mojón de código y un mojón de tests.



  • 15

    Me ha salido Python, cosa que ya me imaginaba :sisi1:

    @TheBronx dijo:

    JavaScript dificultad 2/5 no se lo cree ni su madre xD al de la gráfica le metía yo a gestionar callbacks :dale2:
    @Stalker efectivamente, Ruby está mejor pagado que Java. Eso está en dólares y vete a saber de dónde han sacado los datos. En España ya te lo digo yo, Ruby está mejor pagado que Java. Ten en cuenta que casi en todas las consultoras hay javeros, pagados como el culo, Ruby se usa más en sitios guays y modernos que tratan al programador dignamente.
    @dehm +1 a que la dificultad está en la calidad del código que haces, no en si funciona. Una buena metodología para hacer código mantenible es el TDD (Test Driven Development). Consiste en hacer primero un test y a continuación implementar el código de producción.
    Es decir, si quisiéramos crear una nueva funcionalidad para nuestro programa, por ejemplo un sistema de "me gusta" para el foro, empezaríamos haciendo un test. Test de que cuando llamo a la función post.like() se añade mi usuario a la lista de "usuarios a los que les gusta este post". El test fallaría, porque la función like() no está implementada, y entonces con un test en rojo pasarías a "resolver el test". En este caso podría ser algo así:
    function like(userId) {
    post.likes.push(userId);
    }
    Es un codigo rápido, que añade el userId al array de "likes" del post.
    Pues a continuación volverías al test, y estaria "en verde", es decir, pasaría. Entonces haces otro test, por ejemplo, imaginemos que los likes, cuando se hacen en el primer post de un hilo, además de meterte en el array de likes, te mete en el array de suscriptores.
    Pues ale, otro test, y a ponerlo en verde.
    Y así es como irías avanzando. De esta forma te creas una base de tests, que serán útiles para mantener el código y al mismo tiempo vas descubriendo el problema, implementándolo paso a paso. En cada paso aplicarías también pequeños refactors o modificaciones. Por ejemplo, si la función se ha ido complicando, y tiene ya 20 líneas, un if, un for, etc. pues antes de meter más tests limpiaríamos el código. Sacaríamos funciones más unitarias, quitaríamos código duplicado y todas esas cosas. Y todo con la garantía de que si rompemos algo con esas modificaciones, los tests nos cubren el culo.
    Es la mejor forma de hacer un código de calidad. Aunque sin voluntad ni experiencia por muchos tests que hagas puedes terminar haciendo un mojón de código y un mojón de tests.

    Todo eso lo hacemos en el foro, a que si? :sisi2:
    Yo esta ha sido la primera vez que he hecho algo con JavaScript (NodeJS), y al principio fue desesperante, no sabía como cojones iban los callbacks :facepalm:
    El plugin de tagstitle fue el primero que hice y da vergüenza ver el código :toloco:
    Los últimos plugins han mejorado.



  • 16

    @TheBronx dijo:

    JavaScript dificultad 2/5 no se lo cree ni su madre xD al de la gráfica le metía yo a gestionar callbacks :dale2:
    @Stalker efectivamente, Ruby está mejor pagado que Java. Eso está en dólares y vete a saber de dónde han sacado los datos. En España ya te lo digo yo, Ruby está mejor pagado que Java. Ten en cuenta que casi en todas las consultoras hay javeros, pagados como el culo, Ruby se usa más en sitios guays y modernos que tratan al programador dignamente.
    @dehm +1 a que la dificultad está en la calidad del código que haces, no en si funciona. Una buena metodología para hacer código mantenible es el TDD (Test Driven Development). Consiste en hacer primero un test y a continuación implementar el código de producción.
    Es decir, si quisiéramos crear una nueva funcionalidad para nuestro programa, por ejemplo un sistema de "me gusta" para el foro, empezaríamos haciendo un test. Test de que cuando llamo a la función post.like() se añade mi usuario a la lista de "usuarios a los que les gusta este post". El test fallaría, porque la función like() no está implementada, y entonces con un test en rojo pasarías a "resolver el test". En este caso podría ser algo así:
    function like(userId) {
    post.likes.push(userId);
    }
    Es un codigo rápido, que añade el userId al array de "likes" del post.
    Pues a continuación volverías al test, y estaria "en verde", es decir, pasaría. Entonces haces otro test, por ejemplo, imaginemos que los likes, cuando se hacen en el primer post de un hilo, además de meterte en el array de likes, te mete en el array de suscriptores.
    Pues ale, otro test, y a ponerlo en verde.
    Y así es como irías avanzando. De esta forma te creas una base de tests, que serán útiles para mantener el código y al mismo tiempo vas descubriendo el problema, implementándolo paso a paso. En cada paso aplicarías también pequeños refactors o modificaciones. Por ejemplo, si la función se ha ido complicando, y tiene ya 20 líneas, un if, un for, etc. pues antes de meter más tests limpiaríamos el código. Sacaríamos funciones más unitarias, quitaríamos código duplicado y todas esas cosas. Y todo con la garantía de que si rompemos algo con esas modificaciones, los tests nos cubren el culo.
    Es la mejor forma de hacer un código de calidad. Aunque sin voluntad ni experiencia por muchos tests que hagas puedes terminar haciendo un mojón de código y un mojón de tests.

    esto es git no?

    amí me encanta php la verdad xD, c++ me esta costando y java me encuentro comodo la verdad, ruby por lo que he visto se parece un poco a .NET no? la verdad es que .NET me gusto bastante en su día.



  • 17

    @erpatata No, Git es un control de versiones, lo que dice @TheBronx es un método para desarrollar software.



  • 18

    @Stalker dijo:

    @erpatata No, Git es un control de versiones, lo que dice @TheBronx es un método para desarrollar software.

    Bueno pero esto del tdd sería como tener un proyecto aparte en el que ir haciendo pruebas llamamosle "test1", y finalmente cuando se ha conseguido el objetivo, se pasa a otro proyecto llamado "test2" el cual sirviría para optimizar codigo y final mente llevarlo al proyecto final.



  • 19

    @erpatata dijo:

    Bueno pero esto del tdd sería como tener un proyecto aparte en el que ir haciendo pruebas llamamosle "test1", y finalmente cuando se ha conseguido el objetivo, se pasa a otro proyecto llamado "test2" el cual sirviría para optimizar codigo y final mente llevarlo al proyecto final.

    Pues no lo estaba pensando de esa manera, pero como dices supongo que se podría utilizar Git para crear los tests en una rama distinta y luego llevar el código a la versión final.





Has perdido la conexión. Reconectando a Éxodo.