#7:
#c-4" class="content-link" style="color: rgb(, , )" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment//order/4">#4 Poco has programado tú. Normalmente un programa con metodologías modernas y tecnologías actuales tiene que coexistir con programas anteriores de la misma empresa o del antiguo proveedor de servicios del cliente. Esto provoca que haya que hacer mil pirulas para comunicar unas aplicaciones/funcionalidades con otras.
Lo ideal sería abandonar el programa "viejo" y usar el "nuevo" del tirón, pero la realidad es que las empresas no tienen tantos recursos como para dedicar media plantilla a seguir dando soporte a la aplicación vieja mientras otra media plantilla desarrolla la nueva. Las cosas se van haciendo poco a poco, cuando el cliente aprieta, e integrando lo nuevo con lo que ya hay.
Te voy a poner un ejemplo de la multinacional en la que trabajo. Tenían una aplicación de escritorio, que migró a internet (html 2), que luego fue reconvertida a otra tecnología web que quedó obsoleta, y luego pasó a html5. Eso convive con otros servicios que automatizan tareas, fuera de la aplicación manejada por el cliente. En total, coexisten aplicaciones en javascript, html, asp, c#, c++, c++ builder, visual c, oracle, sqlite, office y alguna más que se me escapa. Todo en un delicado equilibrio.
#5:
#3 Es tan sencillo como decir "no tengo ni idea, cuando en la empresa tengo un problema, llamo a sistemas". Con esa respuesta, llevo más de 10 años sin arreglar un ordenador que no sea mio.
#10:
#8 Yo no he dicho que sea un caos. Lo que digo es que la aserción 1 tiene razón:
"Under the hood, most critical software you use every day (like Mac OS X, or Facebook) contains a terrifying number of hacks and shortcuts that happen to barely fit together into a working whole. It would be like taking apart a brand-new 747 and discovering that the fuel line is held in place by a coat-hanger and the landing gear is attached with duct tape."
Que hay un todo que funciona gracias a un montón de ñapas que conectan unas partes con otras. Que es como viajar en un 747 y darte cuenta de que el tubo de la gasolina está sujeto con una percha y que la rueda de aterrizaje está pegada con cinta americana.
#39:
#3, 3 buenos trucos para evitar esas reparaciones:
1) Decir "Traemelo a casa y lo miro": El 90% de las personas no querrá hacerlo por pura vagancia. Si piden un favor y no son capaces de llevarte el bicho, no son merecedores de ninguna ayuda.
2) Decir que eres usuario de linux desde hay 10 años y que no conoces windows lo suficiente.
3) Hacerlo con la condición de que se vista de gallina y te haga una paella.
#68:
#7Lo ideal sería abandonar el programa "viejo" y usar el "nuevo" del tirón,
En mi experiencia los que dicen eso son nuevos programadores con muy poca experiencia.
Dile tú a un banco que estaría bien quitar código COBOL que lleva funcionando 40 años, que será muy feo y lo que quieras pero que funciona como un reloj y que lo vas a cambiar por otra cosa que te vas a picar de cero usando la novedad de la semana.
Por cierto, otra verdad que los programadores con experiencia saben: Nuestro propio código revisado 10 años después nos suele parecer una puta mierda.
#109:
#3#5#6#39 Yo fui técnico de sistemas cuando empece a trabajar a los 17 y, si, sabia arreglar ordenadores. La frase que mejor me iba era "Ah, vale, cuando te vaya bien me paso por tu casa. Te haré buen precio".
Manita de santo, nunca me volvían a llamar.
#13:
#11#10 ¡Pelea de gatas!. Cuando veo flames de estos siempre pienso que antes de discutir con alguien (en un campo en que ambos somos entendido en la materia) debemos conocer muy a fondo el bagaje del adversario, porque es muy importante no caer en la trampa de subestimar los conocimientos del oponente. Siempre digo que hay tres tipos de profesionales, los que saben, los que no, y los que "creen" que saben. Considerándome de los segundos, claro.
Dicho esto, soy de la opinión de que el punto 1 tiene más razón que un santo.
#96:
#22#24#28#32#42#45 Supongo que ya lo sabéis, pero el que los arreglos comiencen por 0 no es ningún capricho de algún programador que lo decidió así porque le salió de los cojones. Viene de los lenguajes que tratan al arreglo como posiciones contiguas en memoria. El caso más común es el de C: cuando creas un arreglo en C, lo que obtienes es la posición en memoria del primer elemento, es decir, puntero+0 (puntero es la posición del arreglo en memoria). Para recorrer el resto del arreglo, debes ir incrementando esa posición: puntero+1, puntero+2, puntero+n. Luego se inventaron el acceso tipo puntero[n], pero para que conservar la compatibilidad con la notación de suma de punteros, tenía que comenzar por 0. Así, puntero[0] es lo mismo que decir arreglo+0. Si los arreglos comenzaran en 1, tendrías que saber cuándo usar 1 y cuándo 0: puntero[1] == puntero+0.
Luego vinieron los descendientes de C que, aún sin necesitarlo (porque ya no almacenan los arreglos de esta forma y no se puede acceder multiplicando el puntero por el índice), conservaron la notación por compatibilidad. Excepciones: lenguajes que nada tienen que ver con C como Pascal, en el que el estándar es acceder con [indice]. Por esto el índice puede comenzar en 1 o cualquier otro número, ya que el lenguaje se encarga del resto internamente.
#37:
#28 VB no es que empiece en el 1, es peor aún.
Tu declaras un array tal que así: Dim foo(5) As Integer
Y resulta que el array tiene 6 posiciones, que son: foo(0), foo(1), foo(2), foo(3), foo(4), foo(5)
Es lo tercero más estupido que he visto en mi vida. Lo segundo es la paja mental de Null vs Nothing, y lo primero es Javascript en general.
Una lanza en favor de todos los programadores que tenemos amigos que nos llaman "informáticos". HASTA LA P... de que me pidan arreglar ordenadores
#11:
#10 Como exageración es graciosa pero le falta la otra mitad, también humorística.
Porque te darías cuenta de que esa percha a superado numerosos test que demuestran que cumple a la perfección su cometido, y que la rueda pegada con cinta americana aguantará perfectamente incluso ante casos extremos y coincidencias que se dan una vez en un millón como que el avión aterrice sobre un centavo en vertical.
#24:
#22Poco ha programado éste para decir semejante estupidez.
.
#6:
#5#3 ¿No podríais pasaros por casa un rato a sintonizarme la TDT?
#20:
#14 En realidad, esa mirada que comentas va acompañada de un "¿Entonces qué clase de informático eres? ¿Esque no os enseñan nada en la universidad?"
#84:
#70 Si, es la que usaba Nokia y otros tantos, si quieres ser totalmente fulminado por la competencia en un par de años es la mejor tactica.
#23:
El punto 3 lo he tenido que argumentar muy a menudo. Un programador no tiene porque saber arreglarte el ordenador.
A menudo uso el símil entre un conductor y un mecánico.
El programador sería como el conductor que sabe como sacar el máximo provecho del coche. Exprimir sus capacidades para lograr llegar al objetivo. Incluso tiene nociones de como funciona internamente el motor. Pero nada mas.
El "técnico en hardware" es el verdadero mecánico. A lo mejor el no sabe sumar dos mas dos, ni como ordenar una array(ni siquiera sabe que es una array), pero sabe como funciona el ordenador físicamente. Que es cada pieza y como arreglarla.
#c-4" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2372568/order/4">#4 Poco has programado tú. Normalmente un programa con metodologías modernas y tecnologías actuales tiene que coexistir con programas anteriores de la misma empresa o del antiguo proveedor de servicios del cliente. Esto provoca que haya que hacer mil pirulas para comunicar unas aplicaciones/funcionalidades con otras.
Lo ideal sería abandonar el programa "viejo" y usar el "nuevo" del tirón, pero la realidad es que las empresas no tienen tantos recursos como para dedicar media plantilla a seguir dando soporte a la aplicación vieja mientras otra media plantilla desarrolla la nueva. Las cosas se van haciendo poco a poco, cuando el cliente aprieta, e integrando lo nuevo con lo que ya hay.
Te voy a poner un ejemplo de la multinacional en la que trabajo. Tenían una aplicación de escritorio, que migró a internet (html 2), que luego fue reconvertida a otra tecnología web que quedó obsoleta, y luego pasó a html5. Eso convive con otros servicios que automatizan tareas, fuera de la aplicación manejada por el cliente. En total, coexisten aplicaciones en javascript, html, asp, c#, c++, c++ builder, visual c, oracle, sqlite, office y alguna más que se me escapa. Todo en un delicado equilibrio.
#3 Es tan sencillo como decir "no tengo ni idea, cuando en la empresa tengo un problema, llamo a sistemas". Con esa respuesta, llevo más de 10 años sin arreglar un ordenador que no sea mio.
#8 Yo no he dicho que sea un caos. Lo que digo es que la aserción 1 tiene razón:
"Under the hood, most critical software you use every day (like Mac OS X, or Facebook) contains a terrifying number of hacks and shortcuts that happen to barely fit together into a working whole. It would be like taking apart a brand-new 747 and discovering that the fuel line is held in place by a coat-hanger and the landing gear is attached with duct tape."
Que hay un todo que funciona gracias a un montón de ñapas que conectan unas partes con otras. Que es como viajar en un 747 y darte cuenta de que el tubo de la gasolina está sujeto con una percha y que la rueda de aterrizaje está pegada con cinta americana.
#3, 3 buenos trucos para evitar esas reparaciones:
1) Decir "Traemelo a casa y lo miro": El 90% de las personas no querrá hacerlo por pura vagancia. Si piden un favor y no son capaces de llevarte el bicho, no son merecedores de ninguna ayuda.
2) Decir que eres usuario de linux desde hay 10 años y que no conoces windows lo suficiente.
3) Hacerlo con la condición de que se vista de gallina y te haga una paella.
#10 Como exageración es graciosa pero le falta la otra mitad, también humorística.
Porque te darías cuenta de que esa percha a superado numerosos test que demuestran que cumple a la perfección su cometido, y que la rueda pegada con cinta americana aguantará perfectamente incluso ante casos extremos y coincidencias que se dan una vez en un millón como que el avión aterrice sobre un centavo en vertical.
#11#10 ¡Pelea de gatas!. Cuando veo flames de estos siempre pienso que antes de discutir con alguien (en un campo en que ambos somos entendido en la materia) debemos conocer muy a fondo el bagaje del adversario, porque es muy importante no caer en la trampa de subestimar los conocimientos del oponente. Siempre digo que hay tres tipos de profesionales, los que saben, los que no, y los que "creen" que saben. Considerándome de los segundos, claro.
Dicho esto, soy de la opinión de que el punto 1 tiene más razón que un santo.
#7Lo ideal sería abandonar el programa "viejo" y usar el "nuevo" del tirón,
En mi experiencia los que dicen eso son nuevos programadores con muy poca experiencia.
Dile tú a un banco que estaría bien quitar código COBOL que lleva funcionando 40 años, que será muy feo y lo que quieras pero que funciona como un reloj y que lo vas a cambiar por otra cosa que te vas a picar de cero usando la novedad de la semana.
Por cierto, otra verdad que los programadores con experiencia saben: Nuestro propio código revisado 10 años después nos suele parecer una puta mierda.
El punto 3 lo he tenido que argumentar muy a menudo. Un programador no tiene porque saber arreglarte el ordenador.
A menudo uso el símil entre un conductor y un mecánico.
El programador sería como el conductor que sabe como sacar el máximo provecho del coche. Exprimir sus capacidades para lograr llegar al objetivo. Incluso tiene nociones de como funciona internamente el motor. Pero nada mas.
El "técnico en hardware" es el verdadero mecánico. A lo mejor el no sabe sumar dos mas dos, ni como ordenar una array(ni siquiera sabe que es una array), pero sabe como funciona el ordenador físicamente. Que es cada pieza y como arreglarla.
#3#5#6#39 Yo fui técnico de sistemas cuando empece a trabajar a los 17 y, si, sabia arreglar ordenadores. La frase que mejor me iba era "Ah, vale, cuando te vaya bien me paso por tu casa. Te haré buen precio".
#5 Al principio cuesta un poco porque te miran con una mezcla de que les estés engañando y como pensando qué será lo que haces en el trabajo si no sabes hacer nada.
Si mañana heredo una torre de pisos en la Castellana, si quiero saber cuántas plantas tiene, empezaré a recorrerlas desde la planta baja contando desde 1. Si quiero ponerles un letrero, empezaré a recorrerlas desde la planta baja numerando desde 0.
#22#24#28#32#42#45 Supongo que ya lo sabéis, pero el que los arreglos comiencen por 0 no es ningún capricho de algún programador que lo decidió así porque le salió de los cojones. Viene de los lenguajes que tratan al arreglo como posiciones contiguas en memoria. El caso más común es el de C: cuando creas un arreglo en C, lo que obtienes es la posición en memoria del primer elemento, es decir, puntero+0 (puntero es la posición del arreglo en memoria). Para recorrer el resto del arreglo, debes ir incrementando esa posición: puntero+1, puntero+2, puntero+n. Luego se inventaron el acceso tipo puntero[n], pero para que conservar la compatibilidad con la notación de suma de punteros, tenía que comenzar por 0. Así, puntero[0] es lo mismo que decir arreglo+0. Si los arreglos comenzaran en 1, tendrías que saber cuándo usar 1 y cuándo 0: puntero[1] == puntero+0.
Luego vinieron los descendientes de C que, aún sin necesitarlo (porque ya no almacenan los arreglos de esta forma y no se puede acceder multiplicando el puntero por el índice), conservaron la notación por compatibilidad. Excepciones: lenguajes que nada tienen que ver con C como Pascal, en el que el estándar es acceder con [indice]. Por esto el índice puede comenzar en 1 o cualquier otro número, ya que el lenguaje se encarga del resto internamente.
Como estudiante de programación, mi verdad en programación y la vida es esta: No lo puedes tener todo a la vez.
Un algoritmo puede ser bueno para una cosa, pero es malo para otra. Si es buenísimo para una cosa, probablemente es pésima para otras. Y si resulta ser bueno en todo lo que se le pide, entonces es extremadamente complejo, y por tanto, lleno de posibles errores.
#24 En la inmensa mayoría de los casos en el cero. Creo que en alguna versión de Basic empezaban por 1 y quizá haya algún otro por ahí, pero desde luego la minoría. No sé yo quién será el que ha programado poco.
El último es cierto y no solo en la informática, cuanta gente farda de no leer un libro, de pasar de la cultura, de vivir rodeado de tecnología y no entender ni papa... en fin... que lo diga mi padre, pues todavía, aunque para él es una mierda no saber de informática, pero que lo diga alguien de mi generación y con una sonrisa en la cara es para echarse a llorar.
#c-36" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2372568/order/36">#36 Buenas de nuevo. Efectivamente, y eso nos lleva al Fact #.10: muchos programadores se creen que son superiores al resto de profesionales. Por esto se pasan el día llorando cuando les pasan las mismas cosas que al resto de profesionales...
#2 Puede ser cierto para el legacy code, pero un software moderno desarrollado con metodologías modernas es una pieza muy precisa y testeada.
La limpieza del código, su legibilidad, su mantenibilidad son de los factores más importantes en todo proyecto de software.
Excepto en los sprints y o en el prototipado rápido de un producto mínimo viable, el tiempo invertido en tests y refactorizaciones es tanto como el invertido en añadir nuevas funcionalidades.
#38#37 A mi eso me demuestra que Javascript sigue siendo el lenguaje más incomprendido del mundo. Llevo un año con este lenguaje y cada vez me gusta más. Ya no echo de menos Java para nada.
#30 Y solo el cocinero, si es un restaurante, sabe si te han escupido en la comida.
#41 Muy cierto, yo pensaba que mi casa era más "solida" hasta que vivi mi primera reforma. Al terminar esa reforma, durante unas semanas tenía la impresión de que que cualquier cosa que tocara se podía caer.
#113 se me olvidó: la gente que no es médico conoce perfectamente las excusas y las obligaciones de un médico jajjajaja
Todas las personas tienen amigos que piden ayuda al amigo que consideran experto de vez en cuando. Y ese amigo tiene el mismo derecho a sentirse utilizado y a decir que no que un informático Eso no es patrimonio exclusivo de los informáticos.
Prestar auxilio en una emergencia en la medida de los conocimientos de cada uno es obligación de todos.
Bienvenidos al mundo real. Eso pasa en casi todos los campos. Por poner un ejemplo, cuando vas al super y compras una bolsa de patatas tú ves un producto acabado en el que todo está correcto, si viéseis la fábrica...
#11 Eso mismo podría aplicar a cualquier otra ingeniería, lo que pasa es que el software en varios aspectos es mucho más flexible, tienes menos restricciones impuestas que sean totalmente inviolables, etc, y al final se hacen más ñapas.
Sin embargo, viendo algunos programas como el de megaestructuras, en la construcción del LHC se hicieron varias ñapas por cosas que no se habían tenido en cuenta. Y sí en un avión en vez de con un perchero utilizan la pieza D05-JSA pues yo no sé si es la más adecuada, pero es que igual quizás es una ñapa.
Quizás si yo supiera todo lo que se hace para construir un avión, ni volaría en uno...
Interesante ... y ¿los admins/aquitectos de sistemas que somos?
Por que yo me meto entre pecho y espalda cada script en bash, ksh, Perl, Python/Jython (Weblogic) y en ocasiones hasta Php y C que flipo, sin contar con SQL (incluyendo PL).
Para buscar cagadas de los programadores (nadie es perfecto) y revisión del diseño de las BBDD para cortar deditos.
Y soy un admin. No, no soy un hombre orquesta ni trabajo en una Pyme.
El conductor de coches sería el usuario de informática. El conductor de un coche maneja unos mandos, botones y salpicadero (volante, pedales, botón de luces, claxon, marchas... así como velocímetro, cuentakilómetros...) y el usuario de informática maneja una interfaz de usuario: botones, ratón, teclas, lista desplegable... El conductor "normal" no sabe cómo está construido por dentro el coche, igual que un usuario de Chrome o de Wikipedia.org no tiene que saber si está hecho en C++ o en Java o en PHP.
El conductor experto o avanzado del que hablas, que lleve al límite la máquina y pueda conocer ciertas interioridades sería un piloto de rallies o de Formula 1, o un técnico de calidad de fabricación de coches... y en informática el equivalente podría ser o bien un usuario experto o un analista de pruebas o técnico de calidad de software (labores que quizá la hacen muchos programadores pero que no sería el centro de su actividad) .
El programador sería el fabricante de coches / operario de fábrica, mezclado quizá con diseñador industrial técnico. En realidad la labor de diseño técnico de un programa o sistema debería hacerla un analista técnico pero ya sabemos que el programador suele encargarse de muchas decisiones de ese estilo, y de otras. Pero su labor principal es "unir piezas" para dar como producto otras piezas que cumplan unas especificaciones. Y eso sería lo que hace una fábrica de coches o de piezas de coche... parte de unas piezas existentes y las monta para hacer otra pieza o un producto final.
Cuando alguien pide a un programador que le arregle el ordenador sería como pedir a un operario de una fábrica de SEAT que arregle o aconseje sobre un camión Volvo que no fabrica él, sólo por el hecho de que ambos tienen ruedas. O, al revés, uno que fabrica camiones o grúas le piden que arregle un coche SEAT. Si a un programador un usuario de la aplicación que él ha programado le pregunta por esa aplicación seguramente sabrá más que el usuario y le podrá ayudar pero si es otra fabricada por otros pues no tiene por qué. Bueno, a veces el programador hace aplicaciones para Windows conociendo a fondo el sistema pero no tiene por qué ser el caso general, y puede delegar cierto mantenimiento e instalaciones en otro experto.
#40 pues sí, el médico no puede poner la excusa de que usa Linux ... los cuerpos son básicamente todos el mismo sistema.
Ahora bien, el médico tiene otros "recursos":
* Decir: "para saber con más detalle tendría que hacerse unos análisis" ... Es algo que todo el mundo entiende, que puede haber 200 enfermedades diferentes que causen un dolor en el brazo (fractura, problemas de articulaciones, problema circulatorio, problemas musculares, tumor, etc) ... y saben que normalmente los médicos no llevan un laboratorio a cuestas. Aparte, todo el mundo sabe que el estado paga gratis médicos y análisis. Así que la alternativa es obvia, gratuita y sencilla: urgencias o pedir cita.
* Decir que no es su especialidad. Todo el mundo sabe que no es lo mismo un médico de medicina general que un cirujano o un cardiólogo o un neurocirujano o un traumatólogo o un psiquiatra o un anestesista, etc. Sin embargo, al informático parecen exigirle todo, como si no existieran especialidades...
* Aún así, el médico puede dar una información: "para el dolor puedes tomar un analgésico y te lo calmará... en tu caso este o este". Es diferente a lo que se pide al informático: no que le de información sino que le "cure" el ordenador (o el móvil, o el microondas...)
* Y, por supuesto, si es una cuestión de vida o muerte en una urgencia el médico se supone que debe ayudar, unos primeros auxilios al menos mientras llegan los servicios de urgencias, aunque no conozca al paciente de nada. En el caso del informático no "se supone" que tenga obligación de arreglar algo, no suele haber una vida en juego... pero se lo piden igualmente. Aquí el informático tiene ventaja: si se niega no va a morir nadie.
#155Hablemos sólo de favores: cuando a un médico le piden el favor puede dar un argumento razonable para no hacerlo (hay que analizarlo a fondo y él no tiene el instrumental ni siquiera en casa para hacerlo bien... aparte, hay un servicio gratuito que lo hace, así que no deja abandonada a la persona que pide ayuda) pero para el informático puede ser más complicado porque si no ayuda deja tirada a la persona que le pidió el favor siendo la alternativa gastar dinero (aunque a veces el usuario puede llamar al servicio técnico, que puede estar incluido en el precio que ya pagó... y le saldría "gratis" pero no lo hace).
Cuando a un informático le piden un favor también puede dar un argumento razonable para no hacerlo. Se han expuesto muchos que a mí me parecen razonables en este hilo.
Todos, independientemente de los estudios o la profesión, tenemos la opción de hacer un favor o no hacerlo. Y también de sentir que "por ser lo que somos" la gente abusa al solicitar nuestros servicios en el tiempo libre.
Y eso es lo que he intentado argumentar desde el principio. Que a tí te parezca más fácil en unas o en otras es una opinión subjetiva, problamente debida a un conocimiento desigual de una u otra actividad.
#3 extrapolable con muy pocos cambios a otras profesiones (por ejemplo, la medicina (exagerando ):
¿tú sabes porqué cuando levanto el brazo derecho y me toco la ceja izquierda me duele justo en la parte ésta que me estoy tocando? pero solo me pasa cuando hago ese movimiento los días pares y si, además, he comido judías... )
#80 Leñe, ahora que lo mencionas, a mí lo que me parece retorcido es usar "arreglo". He visto que lo usaban alguna vez, pero a mí siempre me recuerda a un "arreglo" que te puede hacer una costurera en la ropa. No me acaba de convencer. Yo uso el término matemático (vector o matriz, según sea el caso).
Respecto a lo de la numeración, entiendo que se hizo de esa manera para que fuese más fácil para sumar el desplazamiento de cada elemento a la posición inicial en memoria. Tampoco sé qué lenguaje inició esto; pero tiene su lógica. Claro que también habrían podido abstraerlo para el programador y hacer la conversión por debajo. Manías de los "inventores de lenguajes".
#5 Pero... ¿podrías pasarte por mi casa a echarle un vistazo al microondas, que lo del grill no va bien del todo? Total, si a ti no te va a costar nada...
Y si me lo arreglas te invito a una cerveza.
#7 Sí, esa es la dura realidad, pero no significa que deba ser así. Ahí hay algo de cabezonería y tacañería de las grandes empresas. Todo programa es susceptible de ser reescrito de una mejor forma, mejor documentado, optimizado, más preparado para manejar errores ya conocidos durante su uso en producción. Sólo que actualizarlos cuesta dinero y las empresas siguen eso de "si funciona no lo toques y menos si nos cuesta dinero". Si sólo se dieran cuenta de los problemas (y dinero) que se ahorrarían actualizando el código obsoleto, se convertiría en una prioridad hacerlo.
#82 Sí, siempre está la posibilidad de usar VanillaJS ( http://vanilla-js.com ), pero todos los que he visto intentarlo, tarde o temprano vuelven a JQuery, por alguna razón inexplicable. Es como una droga.
#68 muy cierto. Yo desarrollo software industrial y ahí ves cosas de hace eones (he visto máquinas rulando msdos, windows xp sigue dominando, en la programación ahora empieza a verse OO...) y si le dices a algunas empresas que es hora de cambiar, se despollan en tu cara.
Por qué van a cambiar una maquinaria que funciona, que costó muchísimo dinero porque su software sea obsoleto?
¡Ya te apañarás tú como programador para que coexista con lo nuevo!
Algunos tienden a pensar que es fácil cambiar un software a uno más moderno, pero hay muchísimos ejemplos en los que no es así, como el de los bancos que bien has dicho.
Pues yo tengo en mi empresa un administrador de sistemas cojonudo que lo primero que hago es preguntarle -cómo buscar esto o aquello en google- (porque no siempre se donde o cómo) él me da una guía, lo miro por mi cuenta uno o dos días (o una semana) y si no lo consigo le pido ayuda y él siempre está encantado.
Después siempre le compro cerveza alemana en agradecimiento, me ayude o me diga cómo buscar en google.
Eso si, si después él me pide cualquier cosa, en 5 minutos le estoy ayudando también, como si me pide que le ayude a pintar su casa.
#11 lo unico que demuestran los tests es que el funcionamiento basico es correcto y que los bugs detectados no ocurrirán. No dicen nada de los bugs no detectados, y sobre todo, hablan de que la finalidad se cumple, no de cómo se cumple. Un software bien testeado es mucho mejor que uno sin testear, pero pueden tener la misma cantidad de chapuzas dentro.
"Under the hood, most critical software you use every day (like Mac OS X, or Facebook) contains a terrifying number of hacks and shortcuts that happen to barely fit together into a working whole. It would be like taking apart a brand-new 747 and discovering that the fuel line is held in place by a coat-hanger and the landing gear is attached with duct tape."
Todas estas ñapas funcionan hasta que dejan de funcionar, o hasta que las tienen que mantener o reparar otras personas.
Por eso a los que piensan, diseñan y programan así, nunca hay que dejarles que programen sistemas para centrales nucleares, software para dispositivos medicos, software para dispositivos que vayan a ser instalados en aviones u otros sistemas criticos, como por ejemplo sistemas que controlan los sistemas electricos de ciudades, o sistemas críticos para la seguridad nacional (como por ejemplo si la privacidad de determinados datos son criticos para la seguridad).
De hecho si os leeis los acuerdos de licencia de windows, mac os x, ... habrá una parte en que dice que ese software vale para sistemas de usuarios, pero no para centrales nucleares, aparatos medicos u otros sistémas críticos.
#1 Para hacer una función de Fibbonacci, estoy de acuerdo que es pelín exagerado, pero cuando se trata de computación distribuida en tiempo real... muchas, muchas cosas están cogidas con alfileres. Lo que pasa es que esos alfileres han demostrado que funcionan razonablemente bien (para eso están las pruebas) en circunstancias normales o no demasiado extraordinarias.
Por ejemplo, una misión espacial se fue al garete, con un presupuesto de miles de millones, porque "alguien" no cayó en la cuenta que 1 milla no es igual que 1kilómetro (WTF?).
Necesito recien titulado ingeniero con 10 años de experiencia, con francés, alemán, ruso e ingles bilingue.
Experiencia en entorno Mainframe ZOS, ZOZ.
Bases de datos DL1, DB2.
Experiencia en ObjetStar (Huron), LAMP (PHP, MySQL), Vision Builder (Mark, Mark 4 y Mark 5), COBOL, COBOL II, JAVA, HTML y JavaScript.
Ajax, Less
Valoramos experiencia en frameworks (Sencha, Jquery, Dojo, etc.) y Bootstrap
Se ofrece prácticas en empresa líder internacional arreglando portátiles y PC's.
No se ofrece sueldo, pero es un entorno joven, dinámico de programadores élite donde puedes enriquecerte mucho.
#7 tu lo has dicho en software nuevo y ni eso, todo depende de las urgencias que tengas y la autodisciplina que te aseguro es muy difícil de mantener, más cuando nadie va a revisar lo que haces solo su resultado, es decir miles de horas de test no detectarán esa ñapa si funciona #68 siempre con el ejemplo del Cobol, no es que no lo quieran cambiar por amor a la mitologia informàtica, és que són sistemas y procesos profesionales con soporte de grandes empresas que funcionan y además han sabido adaptarse para intercambiar información con nuevas tecnologías, para que vas a gastar pasta en cambiar lo que funciona? Gastan pasta en montar capas amigables pero el core lo mantienen sentido común. #26 en cualquier lenguaje no, solo si este no está compilado, en ese caso es más fácil detectar errores catastróficos y más si son de formato. Y todas estas respuestas sin leer artículo, me encanta...
#78 Cierto. Cuando empecé a programar (Pascal), para mí era natural empezar siempre en uno. Cuando pasé a otros lenguajes no entendía qué pasaba por la mente de quienes los hicieron. ¿Qué clase de mente retorcida comienza un arreglo en cero?
#127 Disculpa, lo que hice fue reunir todos los comentarios que hablaban sobre el cero, incluyendo el tuyo . Tienes razón, yo tampoco numero todo como 0, 1, 2..., tampoco conozco otro programador que lo haga. Supongo que sólo los más frikis.
Y respecto a empezar char[0]: Delphi recientemente (En sus nuevas versiones XE) lo ha cambiado para adaptarse a ARM y lo considero mucho mejor que antes.
Respecto a retornar tipos: Bueno, PHP no nació como lo que es ahora y aún así todo está bastante bien solucionado. A mi me gusta, no obstante tienes que saber sobre qué estás programando. Nada más.
#136 estábamos hablando de disculpas a personas que piden favores. Y, que yo sepa, atender una emergencia no es un favor. Si no sabes diferenciar cosas tan básicas como ésta, no tengo nada más que discutir contigo. No hablamos el mismo idioma.
#176 Los de la Real Academia se equivocan: contar y numerar no son lo mismo. Para empezar, una numeración ni siquiera tiene que ser consecutiva. Por ejemplo, en un hotel las habitaciones están numeradas de forma que el primer dígito indique la planta y así en la segunda planta habrá habitaciones numeradas como 201, 202... sin que haya cien habitaciones anteriores a esas.
#179 Sí, los programadores somos como las putas, que estamos para hacer realidad las fantasías de nuestros clientes. Además el cliente quiere saber por adelantado cuánto le va a costar y qué le vamos a hacer por ese dinero.
#61 Yo doy gracias por el advenimiento de jquery. Hasta entonces, las batallas de las distintas librerías de Js para hacer cualquier cosa eran épicas (y aleatorias).
#110 Todos los lenguajes con tipado dinámico ofrecen un operador similar, por lógica.
Si algún día te has pasado tirándote de los pelos por ese motivo (el programa está interpretando un 0 como false y tú no lo compruebas) la culpa es abslutamente tuya, primero por gañán, segundo por creerte la hostia cuando en realidad eres un mal profesional y tercero y más importante, por no haberte leído la puta documentación en donde detalla precisamente lo que debes y no debes hacer y por qué.
No entiendo qué clase de programadores del ojete son aquellos a los que les ofende que les pongan un operador nuevo que precisamente ayuda a utilizar las particularidades del lenguaje. Si no sabes usarlo, sea en el lenguaje que sea, no culpes al lenguaje.
Claro que cuando sólo se conoce una forma de funcionar, crees que tipado dinámico es lo mismo que tipado débil, o incluso que tiene algo que ver con ser un lenguaje compilado.
Lueog encuentras cosas super coherentes como meterse con PHP y sus conversiones automáticas en expresiones, pero luego defienden lenguajes como C++, que hace exactamente lo mismo (puedes meter caracteres en enteros o booleanos en caracteres, p.ej.) y además no te da herramientas para lidiar con ello de forma directa.
Es lo de siempre, noobs que se creen la hostia por que aprenden C los primeros años y creen que un lenguaje les hace ser grandes pofesionales. Los grandes profesionales saben que no saben nada, y tienen que intentar saber una variedad de lenguajes que funcionen de diferentes formas, para conocer ventajas e inconvenientes de cada cosa.
Comentarios
#c-4" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2372568/order/4">#4 Poco has programado tú. Normalmente un programa con metodologías modernas y tecnologías actuales tiene que coexistir con programas anteriores de la misma empresa o del antiguo proveedor de servicios del cliente. Esto provoca que haya que hacer mil pirulas para comunicar unas aplicaciones/funcionalidades con otras.
Lo ideal sería abandonar el programa "viejo" y usar el "nuevo" del tirón, pero la realidad es que las empresas no tienen tantos recursos como para dedicar media plantilla a seguir dando soporte a la aplicación vieja mientras otra media plantilla desarrolla la nueva. Las cosas se van haciendo poco a poco, cuando el cliente aprieta, e integrando lo nuevo con lo que ya hay.
Te voy a poner un ejemplo de la multinacional en la que trabajo. Tenían una aplicación de escritorio, que migró a internet (html 2), que luego fue reconvertida a otra tecnología web que quedó obsoleta, y luego pasó a html5. Eso convive con otros servicios que automatizan tareas, fuera de la aplicación manejada por el cliente. En total, coexisten aplicaciones en javascript, html, asp, c#, c++, c++ builder, visual c, oracle, sqlite, office y alguna más que se me escapa. Todo en un delicado equilibrio.
#3 Es tan sencillo como decir "no tengo ni idea, cuando en la empresa tengo un problema, llamo a sistemas". Con esa respuesta, llevo más de 10 años sin arreglar un ordenador que no sea mio.
#8 Yo no he dicho que sea un caos. Lo que digo es que la aserción 1 tiene razón:
"Under the hood, most critical software you use every day (like Mac OS X, or Facebook) contains a terrifying number of hacks and shortcuts that happen to barely fit together into a working whole. It would be like taking apart a brand-new 747 and discovering that the fuel line is held in place by a coat-hanger and the landing gear is attached with duct tape."
Que hay un todo que funciona gracias a un montón de ñapas que conectan unas partes con otras. Que es como viajar en un 747 y darte cuenta de que el tubo de la gasolina está sujeto con una percha y que la rueda de aterrizaje está pegada con cinta americana.
#22 Poco ha programado éste para decir semejante estupidez.
.
La 3 debería ser enseñada en los colegios.
Una lanza en favor de todos los programadores que tenemos amigos que nos llaman "informáticos". HASTA LA P... de que me pidan arreglar ordenadores
#5 #3 ¿No podríais pasaros por casa un rato a sintonizarme la TDT?
#3, 3 buenos trucos para evitar esas reparaciones:
1) Decir "Traemelo a casa y lo miro": El 90% de las personas no querrá hacerlo por pura vagancia. Si piden un favor y no son capaces de llevarte el bicho, no son merecedores de ninguna ayuda.
2) Decir que eres usuario de linux desde hay 10 años y que no conoces windows lo suficiente.
3) Hacerlo con la condición de que se vista de gallina y te haga una paella.
#10 Como exageración es graciosa pero le falta la otra mitad, también humorística.
Porque te darías cuenta de que esa percha a superado numerosos test que demuestran que cumple a la perfección su cometido, y que la rueda pegada con cinta americana aguantará perfectamente incluso ante casos extremos y coincidencias que se dan una vez en un millón como que el avión aterrice sobre un centavo en vertical.
#11 #10 ¡Pelea de gatas!. Cuando veo flames de estos siempre pienso que antes de discutir con alguien (en un campo en que ambos somos entendido en la materia) debemos conocer muy a fondo el bagaje del adversario, porque es muy importante no caer en la trampa de subestimar los conocimientos del oponente. Siempre digo que hay tres tipos de profesionales, los que saben, los que no, y los que "creen" que saben. Considerándome de los segundos, claro.
Dicho esto, soy de la opinión de que el punto 1 tiene más razón que un santo.
#7 Lo ideal sería abandonar el programa "viejo" y usar el "nuevo" del tirón,
En mi experiencia los que dicen eso son nuevos programadores con muy poca experiencia.
Dile tú a un banco que estaría bien quitar código COBOL que lleva funcionando 40 años, que será muy feo y lo que quieras pero que funciona como un reloj y que lo vas a cambiar por otra cosa que te vas a picar de cero usando la novedad de la semana.
Por cierto, otra verdad que los programadores con experiencia saben: Nuestro propio código revisado 10 años después nos suele parecer una puta mierda.
#14 En realidad, esa mirada que comentas va acompañada de un "¿Entonces qué clase de informático eres? ¿Esque no os enseñan nada en la universidad?"
#28 VB no es que empiece en el 1, es peor aún.
Tu declaras un array tal que así:
Dim foo(5) As Integer
Y resulta que el array tiene 6 posiciones, que son: foo(0), foo(1), foo(2), foo(3), foo(4), foo(5)
Es lo tercero más estupido que he visto en mi vida. Lo segundo es la paja mental de Null vs Nothing, y lo primero es Javascript en general.
#11 Me gustaría trabajar en tu empresa, porque en la mía cuando la percha comienza a fallar la pegan con un chicle ¿Estáis buscando A/P?
La profesión del programador es como la del camarero. Solo el camarero sabe lo que hay al otro lado de la barra. Y es inquietante.
El punto 3 lo he tenido que argumentar muy a menudo. Un programador no tiene porque saber arreglarte el ordenador.
A menudo uso el símil entre un conductor y un mecánico.
El programador sería como el conductor que sabe como sacar el máximo provecho del coche. Exprimir sus capacidades para lograr llegar al objetivo. Incluso tiene nociones de como funciona internamente el motor. Pero nada mas.
El "técnico en hardware" es el verdadero mecánico. A lo mejor el no sabe sumar dos mas dos, ni como ordenar una array(ni siquiera sabe que es una array), pero sabe como funciona el ordenador físicamente. Que es cada pieza y como arreglarla.
#3 #5 #6 #39 Yo fui técnico de sistemas cuando empece a trabajar a los 17 y, si, sabia arreglar ordenadores. La frase que mejor me iba era "Ah, vale, cuando te vaya bien me paso por tu casa. Te haré buen precio".
Manita de santo, nunca me volvían a llamar.
#15 Uff, de todas esas la única que se me da bien es hacer el mongo.
#46 Al menos admitirás que Javascript se parece a Java lo que una pepsi a una lavadora.
Ñapas...
Es aquí donde los programadores os chupais las pollas unos a otros?
#5 Al principio cuesta un poco porque te miran con una mezcla de que les estés engañando y como pensando qué será lo que haces en el trabajo si no sabes hacer nada.
#22 Contar empieza por 1.
Numerar empieza por 0.
No es lo mismo.
Si mañana heredo una torre de pisos en la Castellana, si quiero saber cuántas plantas tiene, empezaré a recorrerlas desde la planta baja contando desde 1. Si quiero ponerles un letrero, empezaré a recorrerlas desde la planta baja numerando desde 0.
#70 Si, es la que usaba Nokia y otros tantos, si quieres ser totalmente fulminado por la competencia en un par de años es la mejor tactica.
#3 Te inventas una avería física. Le dices que hay que cambiarle la junta de la trócola y que cuesta X. Así tiene dos opciones, pagarte, o llevárselo.
#7 yo creo que #4 está empezando en el mundo laboral y desarrolla páginas webs o temas Android o cosas así, porque si no no me explico su comentario.
#25 Hombre, poder puedes. No sólo con PHP, sino con cualquier lenguaje (que yo sepa todos tienen sintaxis por definición).
Ahora bien, para eso tienes un servidor de desarrollo y otro de producción (y dependiendo de lo grande que sea la empresa, de pruebas, etc.).
Subir código a producción sin probarlo antes (aunque sea a pinrel) es una temeridad. Si no lo aprendes por las buenas, lo aprendes por las malas.
#22 #24 #28 #32 #42 #45 Supongo que ya lo sabéis, pero el que los arreglos comiencen por 0 no es ningún capricho de algún programador que lo decidió así porque le salió de los cojones. Viene de los lenguajes que tratan al arreglo como posiciones contiguas en memoria. El caso más común es el de C: cuando creas un arreglo en C, lo que obtienes es la posición en memoria del primer elemento, es decir, puntero+0 (puntero es la posición del arreglo en memoria). Para recorrer el resto del arreglo, debes ir incrementando esa posición: puntero+1, puntero+2, puntero+n. Luego se inventaron el acceso tipo puntero[n], pero para que conservar la compatibilidad con la notación de suma de punteros, tenía que comenzar por 0. Así, puntero[0] es lo mismo que decir arreglo+0. Si los arreglos comenzaran en 1, tendrías que saber cuándo usar 1 y cuándo 0: puntero[1] == puntero+0.
Luego vinieron los descendientes de C que, aún sin necesitarlo (porque ya no almacenan los arreglos de esta forma y no se puede acceder multiplicando el puntero por el índice), conservaron la notación por compatibilidad. Excepciones: lenguajes que nada tienen que ver con C como Pascal, en el que el estándar es acceder con [indice]. Por esto el índice puede comenzar en 1 o cualquier otro número, ya que el lenguaje se encarga del resto internamente.
Programador = /= Técnico
Igual que conductor de automóvil =/= Mecanico
#59 Javascript is to Java as hamburguer is to ham
Para mí lo peor de Js es el nombre, que crea falsas expectativas.
#1 Explanation needed.
"That about 25% of the hours spent writing an application are spent figuring out ways the end user will do something wrong."
Esto es algo común en el campo de la ingenierá en general.
#8 la máxima es «si funciona, no lo toques!»
Como estudiante de programación, mi verdad en programación y la vida es esta: No lo puedes tener todo a la vez.
Un algoritmo puede ser bueno para una cosa, pero es malo para otra. Si es buenísimo para una cosa, probablemente es pésima para otras. Y si resulta ser bueno en todo lo que se le pide, entonces es extremadamente complejo, y por tanto, lleno de posibles errores.
Rapidez, memoria y complejidad. Escoge dos.
#30 Y el mecanico, albañil, cirujano...la entradilla es un poco chorra.
#4 ¿En qué departamento de Márketing dices que trabajas?
#4 PHP.
Déjate un punto y coma en el sitio equivocado y puedes descojonar una web entera.
#7 Si sigues la máxima de dejar el código mejor de como lo encontraste no termina todo siendo un caos.
#24 En la inmensa mayoría de los casos en el cero. Creo que en alguna versión de Basic empezaban por 1 y quizá haya algún otro por ahí, pero desde luego la minoría. No sé yo quién será el que ha programado poco.
El último es cierto y no solo en la informática, cuanta gente farda de no leer un libro, de pasar de la cultura, de vivir rodeado de tecnología y no entender ni papa... en fin... que lo diga mi padre, pues todavía, aunque para él es una mierda no saber de informática, pero que lo diga alguien de mi generación y con una sonrisa en la cara es para echarse a llorar.
#c-36" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2372568/order/36">#36 Buenas de nuevo. Efectivamente, y eso nos lleva al Fact #.10: muchos programadores se creen que son superiores al resto de profesionales. Por esto se pasan el día llorando cuando les pasan las mismas cosas que al resto de profesionales...
#2 Puede ser cierto para el legacy code, pero un software moderno desarrollado con metodologías modernas es una pieza muy precisa y testeada.
La limpieza del código, su legibilidad, su mantenibilidad son de los factores más importantes en todo proyecto de software.
Excepto en los sprints y o en el prototipado rápido de un producto mínimo viable, el tiempo invertido en tests y refactorizaciones es tanto como el invertido en añadir nuevas funcionalidades.
#38 #37 A mi eso me demuestra que Javascript sigue siendo el lenguaje más incomprendido del mundo. Llevo un año con este lenguaje y cada vez me gusta más. Ya no echo de menos Java para nada.
#15 Veo todas esas tecnologías y subo otras cinco más.
¿Alguien quiere trabajar en mi startup?
#30 Y solo el cocinero, si es un restaurante, sabe si te han escupido en la comida.
#41 Muy cierto, yo pensaba que mi casa era más "solida" hasta que vivi mi primera reforma. Al terminar esa reforma, durante unas semanas tenía la impresión de que que cualquier cosa que tocara se podía caer.
#3 "pringaohowto.txt" te solucionará la vida... (googlealo)
#113 se me olvidó: la gente que no es médico conoce perfectamente las excusas y las obligaciones de un médico jajjajaja
Todas las personas tienen amigos que piden ayuda al amigo que consideran experto de vez en cuando. Y ese amigo tiene el mismo derecho a sentirse utilizado y a decir que no que un informático Eso no es patrimonio exclusivo de los informáticos.
Prestar auxilio en una emergencia en la medida de los conocimientos de cada uno es obligación de todos.
Bienvenidos al mundo real. Eso pasa en casi todos los campos. Por poner un ejemplo, cuando vas al super y compras una bolsa de patatas tú ves un producto acabado en el que todo está correcto, si viéseis la fábrica...
#90 Si PHP al colegayonseca le parece chungo, mejor que no vea esto:
http://en.wikipedia.org/wiki/International_Obfuscated_C_Code_Contest
#11 Eso mismo podría aplicar a cualquier otra ingeniería, lo que pasa es que el software en varios aspectos es mucho más flexible, tienes menos restricciones impuestas que sean totalmente inviolables, etc, y al final se hacen más ñapas.
Sin embargo, viendo algunos programas como el de megaestructuras, en la construcción del LHC se hicieron varias ñapas por cosas que no se habían tenido en cuenta. Y sí en un avión en vez de con un perchero utilizan la pieza D05-JSA pues yo no sé si es la más adecuada, pero es que igual quizás es una ñapa.
Quizás si yo supiera todo lo que se hace para construir un avión, ni volaría en uno...
Interesante ... y ¿los admins/aquitectos de sistemas que somos?
Por que yo me meto entre pecho y espalda cada script en bash, ksh, Perl, Python/Jython (Weblogic) y en ocasiones hasta Php y C que flipo, sin contar con SQL (incluyendo PL).
Para buscar cagadas de los programadores (nadie es perfecto) y revisión del diseño de las BBDD para cortar deditos.
Y soy un admin. No, no soy un hombre orquesta ni trabajo en una Pyme.
Saluditos vecinitos
#35 A mi me lo han pedido, literalmente, true story.
#1 Esto es que has visto pocas aplicaciones que lleven unos cuantos annos en producción.
#23
El conductor de coches sería el usuario de informática. El conductor de un coche maneja unos mandos, botones y salpicadero (volante, pedales, botón de luces, claxon, marchas... así como velocímetro, cuentakilómetros...) y el usuario de informática maneja una interfaz de usuario: botones, ratón, teclas, lista desplegable... El conductor "normal" no sabe cómo está construido por dentro el coche, igual que un usuario de Chrome o de Wikipedia.org no tiene que saber si está hecho en C++ o en Java o en PHP.
El conductor experto o avanzado del que hablas, que lleve al límite la máquina y pueda conocer ciertas interioridades sería un piloto de rallies o de Formula 1, o un técnico de calidad de fabricación de coches... y en informática el equivalente podría ser o bien un usuario experto o un analista de pruebas o técnico de calidad de software (labores que quizá la hacen muchos programadores pero que no sería el centro de su actividad) .
El programador sería el fabricante de coches / operario de fábrica, mezclado quizá con diseñador industrial técnico. En realidad la labor de diseño técnico de un programa o sistema debería hacerla un analista técnico pero ya sabemos que el programador suele encargarse de muchas decisiones de ese estilo, y de otras. Pero su labor principal es "unir piezas" para dar como producto otras piezas que cumplan unas especificaciones. Y eso sería lo que hace una fábrica de coches o de piezas de coche... parte de unas piezas existentes y las monta para hacer otra pieza o un producto final.
Cuando alguien pide a un programador que le arregle el ordenador sería como pedir a un operario de una fábrica de SEAT que arregle o aconseje sobre un camión Volvo que no fabrica él, sólo por el hecho de que ambos tienen ruedas. O, al revés, uno que fabrica camiones o grúas le piden que arregle un coche SEAT. Si a un programador un usuario de la aplicación que él ha programado le pregunta por esa aplicación seguramente sabrá más que el usuario y le podrá ayudar pero si es otra fabricada por otros pues no tiene por qué. Bueno, a veces el programador hace aplicaciones para Windows conociendo a fondo el sistema pero no tiene por qué ser el caso general, y puede delegar cierto mantenimiento e instalaciones en otro experto.
No estoy de acuerdo con el punto 1.
#4 que tierno....
Dile al cliente q vas a hacerlo todo súper bien y q solo le ca a salir el doble de caro y le va a costar el doble de tiempo, veras q bien....
#40 pues sí, el médico no puede poner la excusa de que usa Linux ... los cuerpos son básicamente todos el mismo sistema.
Ahora bien, el médico tiene otros "recursos":
* Decir: "para saber con más detalle tendría que hacerse unos análisis" ... Es algo que todo el mundo entiende, que puede haber 200 enfermedades diferentes que causen un dolor en el brazo (fractura, problemas de articulaciones, problema circulatorio, problemas musculares, tumor, etc) ... y saben que normalmente los médicos no llevan un laboratorio a cuestas. Aparte, todo el mundo sabe que el estado paga gratis médicos y análisis. Así que la alternativa es obvia, gratuita y sencilla: urgencias o pedir cita.
* Decir que no es su especialidad. Todo el mundo sabe que no es lo mismo un médico de medicina general que un cirujano o un cardiólogo o un neurocirujano o un traumatólogo o un psiquiatra o un anestesista, etc. Sin embargo, al informático parecen exigirle todo, como si no existieran especialidades...
* Aún así, el médico puede dar una información: "para el dolor puedes tomar un analgésico y te lo calmará... en tu caso este o este". Es diferente a lo que se pide al informático: no que le de información sino que le "cure" el ordenador (o el móvil, o el microondas...)
* Y, por supuesto, si es una cuestión de vida o muerte en una urgencia el médico se supone que debe ayudar, unos primeros auxilios al menos mientras llegan los servicios de urgencias, aunque no conozca al paciente de nada. En el caso del informático no "se supone" que tenga obligación de arreglar algo, no suele haber una vida en juego... pero se lo piden igualmente. Aquí el informático tiene ventaja: si se niega no va a morir nadie.
#155 Hablemos sólo de favores: cuando a un médico le piden el favor puede dar un argumento razonable para no hacerlo (hay que analizarlo a fondo y él no tiene el instrumental ni siquiera en casa para hacerlo bien... aparte, hay un servicio gratuito que lo hace, así que no deja abandonada a la persona que pide ayuda) pero para el informático puede ser más complicado porque si no ayuda deja tirada a la persona que le pidió el favor siendo la alternativa gastar dinero (aunque a veces el usuario puede llamar al servicio técnico, que puede estar incluido en el precio que ya pagó... y le saldría "gratis" pero no lo hace).
Cuando a un informático le piden un favor también puede dar un argumento razonable para no hacerlo. Se han expuesto muchos que a mí me parecen razonables en este hilo.
Todos, independientemente de los estudios o la profesión, tenemos la opción de hacer un favor o no hacerlo. Y también de sentir que "por ser lo que somos" la gente abusa al solicitar nuestros servicios en el tiempo libre.
Y eso es lo que he intentado argumentar desde el principio. Que a tí te parezca más fácil en unas o en otras es una opinión subjetiva, problamente debida a un conocimiento desigual de una u otra actividad.
El punto nueve me recuerda la frase: Es que yo soy de letras
#3 extrapolable con muy pocos cambios a otras profesiones (por ejemplo, la medicina (exagerando ):
¿tú sabes porqué cuando levanto el brazo derecho y me toco la ceja izquierda me duele justo en la parte ésta que me estoy tocando? pero solo me pasa cuando hago ese movimiento los días pares y si, además, he comido judías... )
#80 Leñe, ahora que lo mencionas, a mí lo que me parece retorcido es usar "arreglo". He visto que lo usaban alguna vez, pero a mí siempre me recuerda a un "arreglo" que te puede hacer una costurera en la ropa. No me acaba de convencer. Yo uso el término matemático (vector o matriz, según sea el caso).
Respecto a lo de la numeración, entiendo que se hizo de esa manera para que fuese más fácil para sumar el desplazamiento de cada elemento a la posición inicial en memoria. Tampoco sé qué lenguaje inició esto; pero tiene su lógica. Claro que también habrían podido abstraerlo para el programador y hacer la conversión por debajo. Manías de los "inventores de lenguajes".
#26 "Si no lo aprendes por las buenas, lo aprendes por las malas."
Santa verdad.
#1 ni yo en el 0
#5 Pero... ¿podrías pasarte por mi casa a echarle un vistazo al microondas, que lo del grill no va bien del todo? Total, si a ti no te va a costar nada...
Y si me lo arreglas te invito a una cerveza.
La #3 la voy a grabar en una placa de mármol.
#7 Sí, esa es la dura realidad, pero no significa que deba ser así. Ahí hay algo de cabezonería y tacañería de las grandes empresas. Todo programa es susceptible de ser reescrito de una mejor forma, mejor documentado, optimizado, más preparado para manejar errores ya conocidos durante su uso en producción. Sólo que actualizarlos cuesta dinero y las empresas siguen eso de "si funciona no lo toques y menos si nos cuesta dinero". Si sólo se dieran cuenta de los problemas (y dinero) que se ahorrarían actualizando el código obsoleto, se convertiría en una prioridad hacerlo.
#82 Sí, siempre está la posibilidad de usar VanillaJS ( http://vanilla-js.com ), pero todos los que he visto intentarlo, tarde o temprano vuelven a JQuery, por alguna razón inexplicable. Es como una droga.
#21 creeme, tambien son ñapas
#68 muy cierto. Yo desarrollo software industrial y ahí ves cosas de hace eones (he visto máquinas rulando msdos, windows xp sigue dominando, en la programación ahora empieza a verse OO...) y si le dices a algunas empresas que es hora de cambiar, se despollan en tu cara.
Por qué van a cambiar una maquinaria que funciona, que costó muchísimo dinero porque su software sea obsoleto?
¡Ya te apañarás tú como programador para que coexista con lo nuevo!
Algunos tienden a pensar que es fácil cambiar un software a uno más moderno, pero hay muchísimos ejemplos en los que no es así, como el de los bancos que bien has dicho.
#9 Relacionada con tu comentario: Alternativas a la junta de la trócola: 7 piezas de tu coche de las que jamás habías oído hablar
Alternativas a la junta de la trócola: 7 piezas de...
motorpasion.com#18 no.
Programador != técnico
Igual que diseñador de automoviles != mecanico
Igual que dios != medico
O algo así
Pues yo tengo en mi empresa un administrador de sistemas cojonudo que lo primero que hago es preguntarle -cómo buscar esto o aquello en google- (porque no siempre se donde o cómo) él me da una guía, lo miro por mi cuenta uno o dos días (o una semana) y si no lo consigo le pido ayuda y él siempre está encantado.
Después siempre le compro cerveza alemana en agradecimiento, me ayude o me diga cómo buscar en google.
Eso si, si después él me pide cualquier cosa, en 5 minutos le estoy ayudando también, como si me pide que le ayude a pintar su casa.
#11 lo unico que demuestran los tests es que el funcionamiento basico es correcto y que los bugs detectados no ocurrirán. No dicen nada de los bugs no detectados, y sobre todo, hablan de que la finalidad se cumple, no de cómo se cumple. Un software bien testeado es mucho mejor que uno sin testear, pero pueden tener la misma cantidad de chapuzas dentro.
#29 fácil elección... Si algo esta bien hecho y funciona rápido usando poca memoria no tengo pq saber como funciona caja negra powa
"Under the hood, most critical software you use every day (like Mac OS X, or Facebook) contains a terrifying number of hacks and shortcuts that happen to barely fit together into a working whole. It would be like taking apart a brand-new 747 and discovering that the fuel line is held in place by a coat-hanger and the landing gear is attached with duct tape."
Todas estas ñapas funcionan hasta que dejan de funcionar, o hasta que las tienen que mantener o reparar otras personas.
Por eso a los que piensan, diseñan y programan así, nunca hay que dejarles que programen sistemas para centrales nucleares, software para dispositivos medicos, software para dispositivos que vayan a ser instalados en aviones u otros sistemas criticos, como por ejemplo sistemas que controlan los sistemas electricos de ciudades, o sistemas críticos para la seguridad nacional (como por ejemplo si la privacidad de determinados datos son criticos para la seguridad).
De hecho si os leeis los acuerdos de licencia de windows, mac os x, ... habrá una parte en que dice que ese software vale para sistemas de usuarios, pero no para centrales nucleares, aparatos medicos u otros sistémas críticos.
Relacionado
Una línea de código fue capaz de congelar el tráfico aéreo de UK durante una hora
Una línea de código fue capaz de congelar el tráfico aéreo de UK durante una hora
Una línea de código fue capaz de congelar el tráfi...
xataka.comLa última actualización de Panda Antivirus deja el ordenador inútil
La última actualización de Panda Antivirus deja el ordenador inútil
La última actualización de Panda Antivirus deja el...
elgrupoinformatico.comGoogle filtra por error los datos privados de 280000 dominios (en)
Google filtra por error los datos privados de 280000 dominios (en)
Google filtra por error los datos privados de 2800...
arstechnica.comFacebook soluciona grave vulnerabilidad que permitia a un atacante borrar cualquier fotografía de un album
Facebook soluciona grave vulnerabilidad que permitia a un atacante borrar cualquier fotografía de un album
Facebook soluciona grave vulnerabilidad que permit...
blog.elhacker.net«Hackers» de todo el mundo compensan al pirata informático al que Facebook no quiso pagar
«Hackers» de todo el mundo compensan al pirata informático al que Facebook no quiso pagar
«Hackers» de todo el mundo compensan al pirata inf...
lavozdegalicia.esUna actualización de Windows 7 provoca reinicios
Una actualización de Windows 7 provoca reinicios
Una actualización de Windows 7 provoca reinicios
elgrupoinformatico.comUn ingeniero de Google denuncia una cantidad "vergonzosamente grave" de errores en Flash Player
Un ingeniero de Google denuncia una cantidad "vergonzosamente grave" de errores en Flash Player
Un ingeniero de Google denuncia una cantidad "...
genbeta.comPor ejemplo
http://es.slideshare.net/jorarome/anlisis-de-modelos-de-evaluacin-de-calidad-de-software-libre
https://www.google.es/search?q=estandares+de+calidad+de+software
#95 Menuda joya de comentario.
En el punto 2 creo que se han quedado corto.
#c-7" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2372568/order/7">#7 " javascript, html, asp, c#, c++, c++ builder, visual c, oracle, sqlite, office y"
Vade retro.
#1 Para hacer una función de Fibbonacci, estoy de acuerdo que es pelín exagerado, pero cuando se trata de computación distribuida en tiempo real... muchas, muchas cosas están cogidas con alfileres. Lo que pasa es que esos alfileres han demostrado que funcionan razonablemente bien (para eso están las pruebas) en circunstancias normales o no demasiado extraordinarias.
Por ejemplo, una misión espacial se fue al garete, con un presupuesto de miles de millones, porque "alguien" no cayó en la cuenta que 1 milla no es igual que 1kilómetro (WTF?).
Necesito recien titulado ingeniero con 10 años de experiencia, con francés, alemán, ruso e ingles bilingue.
Experiencia en entorno Mainframe ZOS, ZOZ.
Bases de datos DL1, DB2.
Experiencia en ObjetStar (Huron), LAMP (PHP, MySQL), Vision Builder (Mark, Mark 4 y Mark 5), COBOL, COBOL II, JAVA, HTML y JavaScript.
Ajax, Less
Valoramos experiencia en frameworks (Sencha, Jquery, Dojo, etc.) y Bootstrap
Se ofrece prácticas en empresa líder internacional arreglando portátiles y PC's.
No se ofrece sueldo, pero es un entorno joven, dinámico de programadores élite donde puedes enriquecerte mucho.
#32 Pues hay un montón de programadores de ascensores que te vuelven loco para saber cual es el botón de la planta baja.
#66 javascript
#144 Yo soy Pythonista, al lado de su flexibilidad, elegancia y librerias incluidas por defecto, JS parece diseñado por un mono.
Cada vez que alguien me dice que NodeJS es el futuro del servidor me rio en su puta cara.
#83 Y en R
#7 tu lo has dicho en software nuevo y ni eso, todo depende de las urgencias que tengas y la autodisciplina que te aseguro es muy difícil de mantener, más cuando nadie va a revisar lo que haces solo su resultado, es decir miles de horas de test no detectarán esa ñapa si funciona #68 siempre con el ejemplo del Cobol, no es que no lo quieran cambiar por amor a la mitologia informàtica, és que són sistemas y procesos profesionales con soporte de grandes empresas que funcionan y además han sabido adaptarse para intercambiar información con nuevas tecnologías, para que vas a gastar pasta en cambiar lo que funciona? Gastan pasta en montar capas amigables pero el core lo mantienen sentido común. #26 en cualquier lenguaje no, solo si este no está compilado, en ese caso es más fácil detectar errores catastróficos y más si son de formato. Y todas estas respuestas sin leer artículo, me encanta...
#78 Cierto. Cuando empecé a programar (Pascal), para mí era natural empezar siempre en uno. Cuando pasé a otros lenguajes no entendía qué pasaba por la mente de quienes los hicieron. ¿Qué clase de mente retorcida comienza un arreglo en cero?
#101 Si, es lo que explico en #96
#127 Disculpa, lo que hice fue reunir todos los comentarios que hablaban sobre el cero, incluyendo el tuyo . Tienes razón, yo tampoco numero todo como 0, 1, 2..., tampoco conozco otro programador que lo haga. Supongo que sólo los más frikis.
#5 os dejo el simil que uso yo:
"A ver, yo soy como Alonso, sé pilotar pero no tengo ni idea de como reparar el F1"
Funsiona de maravilla, hasta el mas gañan lo entiende
#24 Otro que empieza desde 1
#110 Eso es exactamente lo que he explicado.
Y respecto a empezar char[0]: Delphi recientemente (En sus nuevas versiones XE) lo ha cambiado para adaptarse a ARM y lo considero mucho mejor que antes.
Respecto a retornar tipos: Bueno, PHP no nació como lo que es ahora y aún así todo está bastante bien solucionado. A mi me gusta, no obstante tienes que saber sobre qué estás programando. Nada más.
Debería haberlas enumerado del 0 al 8
#24 también en Matlab el primer índice es el 1.
#136 estábamos hablando de disculpas a personas que piden favores. Y, que yo sepa, atender una emergencia no es un favor. Si no sabes diferenciar cosas tan básicas como ésta, no tengo nada más que discutir contigo. No hablamos el mismo idioma.
#176 Los de la Real Academia se equivocan: contar y numerar no son lo mismo. Para empezar, una numeración ni siquiera tiene que ser consecutiva. Por ejemplo, en un hotel las habitaciones están numeradas de forma que el primer dígito indique la planta y así en la segunda planta habrá habitaciones numeradas como 201, 202... sin que haya cien habitaciones anteriores a esas.
por lo que más queráis: no os metáis en esta mierda...
no podéis decir que no os han avisado.
Nada como una competición de egos para pasar una tarde de sabado
#179 Sí, los programadores somos como las putas, que estamos para hacer realidad las fantasías de nuestros clientes. Además el cliente quiere saber por adelantado cuánto le va a costar y qué le vamos a hacer por ese dinero.
#25 C. Cómete un asterisco de dos y observa como ese puntero va a tomar por culo cuando menos te lo esperas.
#61 Yo doy gracias por el advenimiento de jquery. Hasta entonces, las batallas de las distintas librerías de Js para hacer cualquier cosa eran épicas (y aleatorias).
#110 Todos los lenguajes con tipado dinámico ofrecen un operador similar, por lógica.
Si algún día te has pasado tirándote de los pelos por ese motivo (el programa está interpretando un 0 como false y tú no lo compruebas) la culpa es abslutamente tuya, primero por gañán, segundo por creerte la hostia cuando en realidad eres un mal profesional y tercero y más importante, por no haberte leído la puta documentación en donde detalla precisamente lo que debes y no debes hacer y por qué.
No entiendo qué clase de programadores del ojete son aquellos a los que les ofende que les pongan un operador nuevo que precisamente ayuda a utilizar las particularidades del lenguaje. Si no sabes usarlo, sea en el lenguaje que sea, no culpes al lenguaje.
Claro que cuando sólo se conoce una forma de funcionar, crees que tipado dinámico es lo mismo que tipado débil, o incluso que tiene algo que ver con ser un lenguaje compilado.
Lueog encuentras cosas super coherentes como meterse con PHP y sus conversiones automáticas en expresiones, pero luego defienden lenguajes como C++, que hace exactamente lo mismo (puedes meter caracteres en enteros o booleanos en caracteres, p.ej.) y además no te da herramientas para lidiar con ello de forma directa.
Es lo de siempre, noobs que se creen la hostia por que aprenden C los primeros años y creen que un lenguaje les hace ser grandes pofesionales. Los grandes profesionales saben que no saben nada, y tienen que intentar saber una variedad de lenguajes que funcionen de diferentes formas, para conocer ventajas e inconvenientes de cada cosa.