Mensajes

VanX se esta preparando para el próximo concurso de desarrollo ehndev  .

No he probado las tools todavía pero me gusta ver cuando la gente se entusiasma con algo y se pone a desarrollarlo. Sigue así!

[eso solo]

Salas de juego? eso solo en las grandes compañías. Si no se puede negar que la mayoría de las multinacionales de renombre tienen actividades para distraerte un poco del estrés diario, no todas, pero algunas si se preocupan por tu salud. Un empleado que esta por tener una parálisis facial de tanto estrés no le sirve a nadie, y cualquier empresa sabe eso aunque obviamente a algunas les da lo mismo y simplemente te reemplazan por otro. Por esto siempre digo que es fundamental informarse sobre la empresa a la cual están a punto de entrar.

El trabajo como programador en las mas bajas categorías (junior/trainee) suele ser muy tranquilo porque comienzas interiorizandote con los proyectos y capacitandote en las tecnologías que vas a utilizar (ya sea por tu cuenta o por cursos que se te asignen).
Luego de algunos meses cuando ya tengas los conocimientos para tirar código en los proyectos reales posiblemente pases momentos de estrés como por ejemplo que te pasen un caso de uso y no sepas ni como arrancar o que te den un incidente para resolver y no sepas ni por donde empezar a depurar porque el proyecto tiene 10.000 lineas.
Son cosas que pasan, pero en general depende del proyecto. Si tenes compañeros de trabajo agradables que te dan una mano cuando tenes dudas y tu team leader sabe como tratar a la gente, entonces seguramente no tengas ningún problema. Lo importante es encarar los desafíos con ganas sabiendo que estas aprendiendo cosas y con eso te basta y te sobra para aguantar la mala cara que pueda tener tu leader (que si, puede pasar que tu leader sea un ogro, como en cualquier trabajo).

Cuando ya sos programador/analyst/programador senior o la categoría que sea en la cual ya estas efectivizado y ya estas en el "fragor del desarrollo", el ritmo obviamente cambia y puede costar acostumbrarse, pero no es la muerte y lo peor que te puede pasar es que tengas que llamar a algún compañero para que te de una mano o en su defecto pedirle una mano a tu referente técnico, que si es un tipo amigable (no suelen serlo, pero los hay ) y van a terminar resolviendo todo.

Ahora bien, también esta el otro lado de la moneda. Cuando ya cometes muchos errores en forma reiterada(por ejemplo reproducir errores y olvidarte de guardar el stacktrace, lo haces una vez, ok, lo haces dos y ya te van a mirar mal), desarrollas de muy mala manera y demás, el sermón lo vas a tener que aguantar y si la actitud no cambia obviamente no van a dudar mucho en despedirte. Muchos programadores piensan que es un trabajo en el cual nunca te echan y que si lo hacen conseguís otro muy fácil, y no siempre es así.
Te puede pasar que no te echen de entrada, si no que te empiecen a dar cosas que vos sabes que solo no podes resolver, y te dan y te dan hasta que te terminas yendo solo.

Lo de las horas depende, si trabajas en relación de dependencia suelen ser 8. Trabajos part-time debe haber pero no suelen ser la mayoría. Luego están los que trabajan freelance pero en este ultimo caso las horas dependen del ritmo de cada uno.

Tus ultimas preguntas no tienen respuesta fija puesto que puede variar dependiendo de muchos factores. Cuando sos leader, y te ponen un proyecto sobre la mesa, puede ser que el tiempo en el que tiene que estar finalizado se encuentre entre los requerimientos o puede que te pregunten en cuanto tiempo podes terminarlo. Vos como leader analizas cuantos recursos (desarrolladores) disponibles tenes, cuanto tiempo te llevara pasar por todas las fases de la metodología de desarrollo que utilices, etc. Luego del análisis estarías capacitado para estimar un tiempo y ponerlo sobre la mesa, luego de eso se vera si les parece bien, si lo podes negociar y/o si deberás analizar nuevamente o en el peor de los casos rechazar el proyecto.

Sin miedo a la programación que es un trabajo lindo y te puede abrir muchas puertas.

Saludos!

[We normally hate to use goto, but in our opinion this is one situation (well, the only situation) where it is useful]

El programador puede ser, pero tus compañeros de trabajo? usualmente no trabajas solo, y no siempre vas a ser vos el que depure el código. Incluso luego de 6 meses, vos no vas a ser el mismo que codifico esos gotos, y ni los comentarios van a ayudarte lo suficiente.

Obviamente no vas a tener problemas con goto en proyectos chicos, pero en aplicaciones reales los tenes, por esa misma razón es una característica de lenguaje obsoleta. No porque a alguien se le ocurrió demonizarla, no por cuestiones religiosas si no por simples conceptos de diseño de software que ya están muy bien explicados.

Habría que analizar la evidencia porque en lo que a mi respecta que se utilice en X lugar para mi no significa nada y eso es lo único que se ha dicho hasta ahora. Que en un link Linus diga que Dijkstra no tenia idea de lo que hablaba y que goto en algunos casos sirve para mi tampoco significa nada.

Habra algunos casos en donde usar goto es valido? seguro! de ahí a que haya varios casos en donde sea la mejor opción hay un abismo puesto que porque alguien considere que para algún caso en particular, goto es la mejor opción, no lo hace verdad, solo lo hace una opinión.

De hecho, de "Linux Device Drivers, 2nd Edition" -se encuentra dentro de unos de los links que pusieron- claramente se puede leer esto:

Error recovery is sometimes best handled with the goto statement. We normally hate to use goto, but in our opinion this is one situation (well, the only situation) where it is useful. In the kernel, goto is often used as shown here to deal with errors.

The following sample code (using fictitious registration and unregistration functions) behaves correctly if initialization fails at any point.

 

Código (c) [Seleccionar] Expandir

   int init_module(void)
     {
     int err;

      /* registration takes a pointer and a name */
      err = register_this(ptr1, "skull");
      if (err) goto fail_this;
      err = register_that(ptr2, "skull");
      if (err) goto fail_that;
      err = register_those(ptr3, "skull");
      if (err) goto fail_those;

      return 0; /* success */

      fail_those: unregister_that(ptr2, "skull");
      fail_that: unregister_this(ptr1, "skull");
      fail_this: return err; /* propagate the error */
     }

Los problemas que Dijkstra menciono respecto de usar goto siguen siendo validos, no seria ni el primero ni el ultimo en exponer posibles problemas que permanecen vigentes en el tiempo incluso luego de décadas. Se le suele llamar "estar adelantado a la época" y Dijkstra era claramente uno de esos afortunados.

Lo único que puedo decir es repetir lo que ya dije en un pm; si quieren usarlo porque para determinado caso les parece correcto, haganlo, como profesional y moderador es mi deber avisarles que en el 99% de sus actuales/futuros trabajos a sus referentes técnicos no va a gustarles.

Saludos!

Lo de programadores muy brillantes es relativo, por supuesto algunas personalidades conocidas lo son, algunos desconocidos también lo serán, eso no significa que todos lo sean. Pero igualmente eso no importa mucho, a lo largo de la vida en sistemas puedes encontrarte con muchas personas brillantes y con muchas eminencias en determinadas áreas, así y todo no se puede dar por sentado todo lo que digan y/o hagan por mas geniales que sean como profesionales.

Muchas personalidades conocidas que son brillantes en lo que hacen opinan que C++ es una basura mientras que otros opinan que C++ es una maravilla; ese es uno de los tantos debates interminables.

Una frase muy cierta del libro "Spring in Action" que leí hace un tiempo que ejemplifica un poco todo esto:

There are certain things that most people can agree upon: The fact that the sky
is blue, that Michael Jordan is the greatest player to touch a basketball, and
that Star Trek V should have never happened. And then there are those things that
stir up controversy, such as politics, religion, and the eternal "tastes great/less
filling" debates.

Como profesional tienes que analizar las visiones existentes y ver cual te convence mas y luego de eso verificar que tan cierta es esa visión que tanto te convence. De lo contrario terminarías usando un framework solo porque tal persona brillante lo usa, terminaras comprando un auto porque tal persona lo usa, y así puedo seguir con interminables ejemplos que lograrían que tomes muy malas decisiones en la vida así sea en lo profesional como en lo personal.

Saludos

No siempre menos lineas de código significa que este bien hecho y el goto para lo único que sirve en el 99% de los casos es para ahorrar lineas de código, esa por lo menos es mi opinión.

Que se use en Perl o en el Kernel que gusten no es una muestra de nada puesto que son programadores como todos; no puede tomarse eso como una referencia de que algo es correcto. Con el mismo criterio podemos decir que Dijkstra comento que no debería usarse y explico muy bien por que, y ¿Quien de ustedes se atreveria a decir que Dijkstra no tenia idea de lo que hablaba?.
Como verán ninguna de estas referencias pueden tomarse para probar que "esto es así sin ninguna duda" porque cada uno tiene una visión distinta; se puede estar de acuerdo o no.

Personalmente no creo que goto sea adecuado para nada, genera confusión en el código y torna al flujo del algoritmo difícil de seguir para los que deban continuar lo que uno hizo (nada mas propenso a errores que un programador que no puede entender el código base con el cual debe trabajar).

Lo del goto exit; puede aparentar valido cuando se muestra en 5 lineas pero cuando comienzan los errores, las excepciones, cuando comienza las unidades de testeo y la depuración, la historia es otra.

Estoy de acuerdo con lo que dijo Zero, es cuestión de gustos.

Saludos!

PD: Sin comentarios como gtfo ni demás porque todos tienen derecho a opinar en la forma que gusten mientras no se falte el respeto a nadie.

Esta usando un puntero a función.

Código (c) [Seleccionar] Expandir

#include <stdio.h>
double inversos(int k);
double cuadrados(int k);
double funcsuma(int n,double (*f)(int k)); //f es un puntero a funcion

int main(){
printf("Suma de cinco inversos: %.3f \n",funcsuma(5,inversos)); //Pasa la direccion de inversos
printf("Suma de tres cuadrados: %.3f \n",funcsuma(3,cuadrados)); //Pasa la direccion de cuadrados
}
double funcsuma(int n,double(*f)(int k)){ //f recibe la dirección de la función
double s= 0;
int i;
for (i=1;i<=n;i++)
s+=f(i); //Llamada a la función correspondiente pasandole el valor de i
return s;
}
double inversos(int k){
return 1.0/k;}
double cuadrados(int k){
return (double) k* k;
}


En este caso el valor de retorno y los parámetros son exactamente los mismos por lo que es sencillo hacer una especie de puntero a función "genérico".
Busca sobre punteros a función.

Saludos!

Bueno antes que nada bienvenido/a al foro.

Te tendría que borrar la respuesta por revivir un tema tan antiguo (dale una leída a las reglas cuando puedas) pero no lo haré para que no creas alguna cosa rara como que te borro la respuesta porque no estoy de acuerdo con lo que has dicho o algo similar (doy fe que a otros moderadores les ha pasado).

no quiero ser antipatico pero siempre me ha molestado quienes piensan que sabiendo C saben mas...cada lenguaje te da algo, si sabes c++ sabrás de apuntadores, si sabes de ruby sabras de metaprogramación (algo que no es moco de pavo tampoco) y si sabes de lenguajes de lenguajes funcionales como alguno de la familia lisp o haskell sabrás muchisimas cosas que ni te imaginas. Para ser sincero, yo programé en c++ y es poco lo que me deja el lenguaje a la hora de aprender otros lenguajes que no me hubiese dejado ruby, python, etc , si bien te enseña programación a mas bajo nivel, es algo que al menos hoy en día en el 99% de las aplicaciones que escribas es inutil (a menos que escribas un software de muy bajo nivel donde el rendimiento sea necesario)...en cambio cuando aprendí common lisp y clojure me sirvió de mucho, es otra optica de programar, muy diferente a C y es algo que sabiendo C no se aprende, es como empezar de cero...la gran diferencia es que aprendiendo common lisp te hace mejor programador en cualquier otro lenguaje, no lo digo yo, lo dicen todos los programadores de la familia lisp...ahora que lisp no es popular......ya es otra cosa, al menos con clojure ahora se puede escribir sobre la maquina virtual de java, codigo casi tan rapido, mas "inteligente" que el codigo java y en menos lineas...

Primero que nada no creo que nadie piense que sabiendo C sabe mas que otro o tal vez haya gente que si, pero no es mi caso. Se sabe mas de otras cosas por supuesto por las características inherentes al lenguaje, pero esto obviamente aplica para cualquier área de la vida y por supuesto para cualquier lenguaje de programación.

En mi opinión, aprender C favorece mucho la ejercitación para lograr que gente que nunca programo en su vida comience a pensar como un programador. Esto se puede hacer con cualquier lenguaje? seguramente que si, a mi me parece que C es el mas simple para hacerlo y te da una buena base para aprender luego lo que gustes. No te deja malos hábitos, te fuerza a conocer lo que estas haciendo, y la sintaxis es similar a lenguajes de mas alto nivel como Java o C# por lo que la transición es mas sencilla.

Se puede aprender programación con Python? seguro que si, nadie dijo que no. En mi opinión no es lo mejor concatenar una cadena haciendo string + string y pensar que eso funciona así mágicamente.
Al aprender un lenguaje por primera vez estas "nimiedades" son importantes. Seguro que Python, Ruby, y demás, pueden enseñarte muchisimas cosas a nivel diseño y/o lógica de programación, pero luego de cuanto tiempo? hay que ponerse en el contexto de alguien que toca un lenguaje por primera vez en la vida.

Sinceramente si dices que comenzaste aprendiendo C++ y lo único con lo que te has quedado es con el manejo a bajo nivel, entonces lamento decirte que no has aprendido C++ como se debe, pero eso es un tema aparte.

en cuanto a la popularidad, para mi no tiene sentido, java es popular porque en muchas universidades es lo que enseñan y muchos "profesionales" salen aprendiendo solo a programar java y pensando que java es sencillo y divertido...solo cuando aprenden un lenguaje script abren los ojos...python esta creciendo al igual que ruby, javascript, lua...son lenguajes del futuro

Hablar de Java en reglas generales es un poco difícil puesto que es muy amplio y abarcas desde sistemas web, aplicaciones de escritorio, y tantos etc que es muy difícil comparar "Java" como tal contra otras tecnologías.

Si te puedo decir que su "popularidad" no se debe a que se haya enseñado en las universidades si no a las facilidades de uso, a su licencia, a la multitud de tecnologías (frameworks, servers, y mil cosas mas) para trabajar con Java y muchas cosas mas que lo hacen un buen lenguaje y uno de los mas usados en el mercado laboral.

En las universidades se enseñan lenguajes por sus ventajas en el aprendizaje y/o para amoldar a los futuros profesionales a las necesidades actuales del mercado. Por eso se enseña Java, por eso se enseña C#, no porque se les haya salido de la galera.
Sea cual sea el motivo por el cual se enseña un lenguaje; si es por lo primero es porque el lenguaje puede aportarte algo en el aprendizaje, y si es por lo segundo es porque el lenguaje supo ganarse su cuota de mercado. Si supo ganarse su cuota de mercado es porque algo tuvo para que las compañías y/o los profesionales lo acepten como una herramienta valida. Esto es una regla de oro y funciona así siempre aunque nosotros personalmente consideremos otros lenguajes como "mejores".

en si me parece que tu argumento es de alguien que no le gusta aprender y que se conforma con saber solo un lenguaje, cada lenguaje deja algo, en cada lenguaje se aprende algo y sobretodo cada lenguaje es mejor para hacer alguna cosa determinada, es mejor aprender poco a poco varios, conociendo sus beneficios y sus desaciertos y luego aplicarlo, que enfrascarse en uno, se pierde menos tiempo aprendiendo y utilizando el adecuado que solo sabiendo uno y matandose en escribir todo tipo de codigos con él.......

Me parece que estas prejuzgando sin saber desconociendo todo lo que he estudiado y todo lo que estudio. No voy a mencionar los lenguajes que conozco y/o uso en mi trabajo porque me parece innecesario exponer mi "curriculum" y sinceramente me molesta cuando la gente usa eso como base para argumentar, pero me parece valido aclarar que estas opinando sin saber y sin conocerme.

No estoy de acuerdo con lo que has dicho. Me parece que es mejor aprender un lenguaje BIEN sea cual sea y luego aprender las tecnologías que necesites o que te parezcan atractivas. Pero al hacerlo lo harás con una buena base en programación y no solo sabiendo hacer un hola mundo; esa base de programación no se logra tocando de oído varios lenguajes.

Ir vagando de lenguaje en lenguaje aprendiendo un 5% de cada uno no te hace llegar nunca a a ser un buen programador. Todo lo contrario, solo hace que seas un buen aficionado familiarizado con 3 o 4 lenguajes y poco mas, y así uno no puede trabajar de esto. Para trabajar de esto uno tiene que estar especializado en determinadas tecnologías relacionadas al área que mas te guste o a la que hayas tenido la suerte de entrar.

si no me crees te pongo el reto que aprendas haskell, un lenguaje funcional donde todo es inmutable, a ver que tan dificil o sencillo se te hace viniendo de C, te aseguro que aprenderas muchas cosas nuevas y tu codigo en cualquier lenguaje mejorará, por cierto, en el code jam siempre haskell gana por una gran ventaja, lo que demuestra que sus programadores tienen mejor logica (programar es cuestion de logica no de estar declarando tipos y manejando apuntadores)...he aqui un articulo

Lamentablemente no me queda mas alternativa que pasar del reto de aprender Haskell. No tengo el tiempo y sinceramente no lo necesito ni creo que pueda aportarme nada a mi manera de programar y/o diseñar software. O tal vez si, pero nunca lo sabre hasta que alguien me convenza con argumentos mas sólidos de porque debería aprender Haskell y que me enseñaría que otros lenguajes en menor medida no me han enseñado ya. Cuando uno trabaja de esto, el tiempo que se gasta en aprender un lenguaje es dinero, las capacitaciones son dinero, y se hacen en base a requerimientos claros.

Si crees que puedes aportar algo para los que recién comienzan con la programación, o si quieres exponer lo que vos consideras que son ventajas a la hora de aprender determinadas tecnologías para los que ya somos profesionales, sos libre de hacer un nuevo hilo!

Saludos!

Cierro el post porque es claramente una tarea. Si quieres postear lo que llevas hecho y requieres ayuda sobre tu codigo me avisas y te reabro el post.

Dale una leída a las reglas.

Saludos!

La idea de aprender C antes que C++ es poder empezar en el mundo de la programación con un lenguaje estructurado (procedural) el cual te permite aprender de manera mas clara los conceptos básicos e incorporar la lógica de programación mas fácilmente sin tener que asimilar al mismo tiempo todos los conceptos de la programación orientada a objetos ya que esto ultimo puede ser pesado si es la primera vez que se programa.

No obstante, no necesitas aprender C antes que C++ porque este ultimo es multiparadigma; por lo que técnicamente, podes usarlo de manera estructurada y pasar a utilizarlo orientado a objetos cuando gustes.

Depende del ritmo de cada uno, he visto chicos que no podían comprender que era un objeto luego de días de estudiar y he visto otros que a la semana ya están comprendiendo la POO y aplicando distintos patrones de diseño para resolver determinados problemas. Depende de cada uno y del empeño que se ponga pero en reglas generales es pesado comenzar a programar orientado a objetos si es el primer contacto con la programación por lo que así sea con C o con C++ es preferible empezar de manera estructurada e ir avanzando al ritmo que creas correcto.

Saludos!

Usa el buscador del foro y encontraras muchos hilos hablando de esto. Empieza por ahí como punto de inicio y luego si quedan dudas puedes volver a preguntarlas aquí, pero lee primero algunos hilos relacionados a tu pregunta que los hay varios.

Saludos!