#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.
#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.
#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.
Estoy en otra startup donde estamos a la espera de que se firme un contrato con unos inversores (la firma es inminente desde febrero...)
En esa no sé que planes de contratación tienen.
#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.
#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...
#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.
#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.
#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.
#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...
#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.
#4#7 Es que pare eso están los programadores, para solventar marrones e intentar encajar una sucesión de ñapas con más o menos éxito. Bueno, para éso y para hacer realidad las flipadas de algunos jenios.
#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.
#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.
#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.
#5 A la tercera vez que me llamaban por tonterías les instalaba linux, mano santo, ya no me llamaban, no sé si era porque no lo podían romper o porque llamaban a otro que les instalase windows.
#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.
#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... )
#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.
#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.
#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).
#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.
#46 Puede que tengas razón, pero yo en algunos proyectos, de tanto callback he acabado con un código espagueti inmanejable. Admito que puede ser culpa mía, por falta de metodología adecuada o lo que sea. Pero ese mismo código en java, por decir uno, no me ocurre.
#94 Todo el que no lo entiende, se mete con el pobre JS.
En realidad es potente de cojones, siempre que no tengas la cabeza con forma de clase de tantos años haciendo lo mismo una y otra vez. si nos empeñamos en utilizar JS como si fuese Java o C++, normal que sea una mierda.
#46 No creo que esté reñido eso que comentas, algunos lenguajes interpretados son muy atractivos porque puedes hacer cosas muy fácilmente, el problema es que esa libertad de entender casi cualquier cosa que le eches luego genera muchas ambigüedades que son un problema.
En general mientras más cosas hace el interprete por ti sin que te des cuenta, menos vas a entender que pasa en casos complejos que no dan resultados intuitivos.
Alguien menciona PHP, también tiene ese problema, o peor aún, PHP nunca fue un lenguaje, se le fueron añadiendo cosas sobre la marcha.
#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.
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.
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.
A ver ... que no lo digo para ofender a nadie, pero que se perfectamente que es un algortimo y cantarle las 40 a quien programa con el culo y me deja la máquina frita
#60 Yo quiero un sub donde los admin de sistemas podamos llorar agusto.
1) En desarrollo funciona perfecto.
2) La aplicacion va fluida, el servidor necesita mad RAM
3) No sabemos nada de ese bloq en la BBDD las consultas tienen un timeout adecuado.
4) El servidor quadcore, es un poco escaso, el fabricante recimienda un opteron
Etc... mandarme la buambulancia me la he ganado.
#100 Y vuelves a intentar ir de listo sin ni leer mi comentario.
En PHP !== NO es sinónimo de diferente. Se utiliza para comparaciones de tipo. Si tu comparas (0 == true) te dará false y en mucho casos (como funciones que retornan una posición que puede ser cero) te conviene poder comparar también el tipo para que 0 se interprete como false. y para eso existen !== y ===
En el tutorial deJAVA que has enviado NI NOMBRA !==
#100 En Java no tiene sentido !== ni === ya que tiene una tipado fuerte, es decir, no puedes comparar tipos diferentes. En cambio en lenguajes de tipado débil como PHP y Javascript donde las variables puedes ser desde un carácter a un objeto que tu crees, se necesita un instrucción que supla la falta de tipado.
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.
#29 En general sí, cualquier buen profesional debe valorar siempre las alternativas, sin embargo, en muchos casos sí se puede tener todo. Aunque mientras más forma empieza a tomar tu sistema, siempre se tienen que tomar más compromisos.
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.
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...
#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...
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.
#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.
#65 Jajajajajaa lo mismo he pensado yo, suuuuper tiennnno.
Supongo que algunos lo miramos desde la cruda óptica de la consultoría egpañola, no desde el mundo de arcoiris y unicornios de las startups molonas (...que envidia...)
#4 Actualmente estoy trabajando en evolutivos de una de las empresas de
Banca mas fuerte de España (no diré más pero imagino que ya sabréis cual), y te dan ganas de dejar tu dinero
Bajo la colcha.
Violin.
Arca.
#1 Creo que se refiere a que cuando conoces bien algo también llegas a conocer sus debilidades y puntos críticos. Eso ocure cuando sabes "mirar bajo el capó" y entender lo que hay debajo y lo que puede haber. Ejemplo: cuando te conectas a una wifi abierta y desconocida y navegas a través de sistemas de terceros que examinan y almacenan tus datos. O como cuando whatsapp no encriptaba los mensajes y los trasmitía por canal inseguro...
#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?).
#1 Yo sí. Conozco programadores que pasan varios kilos de querer entender el hardware y el SO para el que desarrollan. O son completamente inútiles con el ordenador hasta el punto de necesitar ayuda para montarse el entorno de desarrollo desde cero. Los que realmente son buenos programadores, son bastante más espabilados y eficientes.
Otra cosa muy distinta es que usen esa estrategia del "no se" para escaquearse de hacer de pringao-howto para otros por amor al arte, cosa que me parece muy loable.
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.
"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.
A muchos nos da pereza leer en inglés o simplemente no lo dominamos. Pero que no se entere el resto, que somos gente de tecnología y nuestro dominio del inglés es incuestionable.
#45 Supongo que entiendo a qué te refieres, pero tu ejemplo está mal. Si cuenta del 0 al 9 te devolvería 10 billetes, como si cuenta del 10135 al 10144, o del 1 al 10.
#53 Siguen siendo 9, en todo caso la numeración estaría mal.
Sí, y también hay mucha gente que no sabe inglés, ni sabe usar el traductor y que??. Es curioso aquí en meneamé hablan mucho de programadores, que saben cosas que el resto no sabe, que están un escalón por encima y cosas de ese tipo. Algún tipo de complejo tienen que tener para darse tantos aires. https://sites.google.com/site/codigodedescuento/codigo-promocional-groupalia
#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?
#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".
#101 "Tampoco sé qué lenguaje inició esto"
Ensamblador, y el lenguaje máquina antes que él.
"Leñe, ahora que lo mencionas, a mí lo que me parece retorcido es usar "arreglo" "
Dudo que alguien que no sea algún tipo de ludópata o incluso algún tipo de extraño alcohólico use semejante término sin ruborizarse. Y no es por ofender a #80, pero es que es así.
Alguien que me diga qué pinta el punto 8 en esa lista. Es como decir: Fact 10: When you boot your computer, the processor starts working
El punto 5, lo de que empieza a contar desde 0, pues bien, deformación profesional, pero en el mundo real ve al banco a retirar pasta y que el cajero te devuelva 10 billetes contando del 0 al 9 (por poner un ejemplo), a ver si tu cerebro es tan "cool" cuando se trata de pasta.
#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.
#96 Ojo, que yo en ningún momento argumento nada en contra de contar desde 0 en el mundo de la programación, no se por qué me incluyes.
Lo que quería decir es que en esa lista sobra ese punto, el de que un programador cuenta siempre desde 0, se sobreentiende que no sólo en su trabajo. No me lo creo (sí creo que hayan excepciones) y me parece algo que usa para justificar a los demás que los programadores son seres de luz y el resto ignorantes de la vida.
Resumiendo: ¿Haces todas tus cuentas (vida personal incluida) contando desde 0? Me parece bien. Seguro que los que trabajan en banca cuentan desde cero y con decimales, y todavía estoy por ver en portada de MNM una lista de este tipo con lo que los profesionales de la banca saben pero la mayor parte de la gente no. Dicho esto ahora me arrepiento de no haber votado este envío como irrelevante.
#96 No sé por qué supones que nos quejamos de una cosa u otra.
La mayoría de lenguajes cuentan desde cero, incluso muchos que no usan punteros ni offsets de memoria (como todos los lenguajes de scripting), por la sencilla razón de que ya está establecido como mayoritario.
Y sí, con certeza ya lo sabíamos, teniendo en cuenta los comentarios.
#96 No es una idea tan ininteligible, en la realidad se podría ver. Por ejemplo que seamos 10 y nos digan que nos sentamos en la fila 5 a partir del asiento 4.
La primera posición es la 4 (4+ desplazamiento 0), segunda 5 (4+1), etc, y el ultimo asiento es el 13 (4+9).
#127 Mucha gente se pierde haciendo ese tipo de cuentas cuando tienes un ordinales, vamos, nadie lo hace porque normalmente no tiene que hacerlo, y cuando lo hace se suele perder.
En mi ejemplo de antes, mucha gente te diría que el rango en el que se sientan (al ser 10) es del 4 a 14 algo intuitivo pero erróneo.
#97 A todo esto, yo creo que sería más simple si para los siglos y los años se hiciera lo mismo. Hay un montón de cálculos históricos que tienen errores debido al inexistente año "cero". Uno de ellos precisamente el del calendario que usamos.
#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.
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.
#32 Muy buena esa anotación, no es lo mismo cardinal que ordinal. Aunque sea menos intuitivo para muchos, a mi me parece más lógico decir que el primer piso es la planta baja.
Aunque en el fondo me da igual, mientras no empiecen a usar fracciones o números irracionales...
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.
#7 Si sigues la máxima de dejar el código mejor de como lo encontraste no termina todo siendo un caos.
#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.
#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 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?
#12 Startup sin financiación.
Está previsto empezar a facturar en abril.
Lo que buscamos son administradores de sistemas, pero podemos valorar desarrolladores con experiencia en las tecnologías que usamos.
Docker, elasticsearch, mongo, node, express, handlebars, angular, bootstrap
Estoy en otra startup donde estamos a la espera de que se firme un contrato con unos inversores (la firma es inminente desde febrero...)
En esa no sé que planes de contratación tienen.
#15 Uff, de todas esas la única que se me da bien es hacer el mongo.
#15 Veo todas esas tecnologías y subo otras cinco más.
¿Alguien quiere trabajar en mi startup?
#86 qué 5?
Yo no ofrezco trabajo.
He dicho claramente que ni tengo financiación ni estoy facturando.
Cuando contratemos será a sysadmins.
#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.
#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...
#21 creeme, tambien son ñapas
#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.
#8 la máxima es «si funciona, no lo toques!»
#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.
#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.
#55 ¿Qué desarrollas tú y cuál es tu experiencia en ello? Por curiosidad, más que nada.
#55 hago esto: https://crowdference.org
#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.
#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.
#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...
#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.
#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.
#7 Amén.
#7 Tanto lio para que luego llegue cualquiera, te programe un Candy Crash Saga en 2 ratos y se lleve la pasta que tu jamás imaginaste.....
Si si, el delicado equilibrio es el de los capullos que apuntamos en el sector por cuatro perras y puteaos.
#4 #7 Es que pare eso están los programadores, para solventar marrones e intentar encajar una sucesión de ñapas con más o menos éxito. Bueno, para éso y para hacer realidad las flipadas de algunos jenios.
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
#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.
#5 #3 ¿No podríais pasaros por casa un rato a sintonizarme la TDT?
#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.
#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.
#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?"
#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.
#35 A mi me lo han pedido, literalmente, true story.
#5 Yo les digo: Es linux o mac? No, lo siento. No entiendo de Viru,....de windows.
#5 A la tercera vez que me llamaban por tonterías les instalaba linux, mano santo, ya no me llamaban, no sé si era porque no lo podían romper o porque llamaban a otro que les instalase windows.
Saludos
#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
#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.
#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#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.
#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... )
#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.
#3 "pringaohowto.txt" te solucionará la vida... (googlealo)
La #3 la voy a grabar en una placa de mármol.
#3 Se me ha roto la tostadora. Si eso ya te invito a 1 caña.
#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.
#37 positivo solo por las últimas cinco palabras.
#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.
#46 Al menos admitirás que Javascript se parece a Java lo que una pepsi a una lavadora.
#59 Javascript is to Java as hamburguer is to ham
Para mí lo peor de Js es el nombre, que crea falsas expectativas.
#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).
#63 http://youmightnotneedjquery.com/
La cosa ha cambiado en los últimos años, por suerte
#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.
#46 Puede que tengas razón, pero yo en algunos proyectos, de tanto callback he acabado con un código espagueti inmanejable. Admito que puede ser culpa mía, por falta de metodología adecuada o lo que sea. Pero ese mismo código en java, por decir uno, no me ocurre.
#81 A veces es complicado evitar eso, pero hay maneras de mitigarlo: http://callbackhell.com/
#46 Te compadezco por haber tenido que ganarte el pan en los dos lenguajes más mierders conocidos por la humanidad.
#94 No he mencionado PHP ni VB, no sé de qué me hablas.
#94 Todo el que no lo entiende, se mete con el pobre JS.
En realidad es potente de cojones, siempre que no tengas la cabeza con forma de clase de tantos años haciendo lo mismo una y otra vez. si nos empeñamos en utilizar JS como si fuese Java o C++, normal que sea una mierda.
#46 No creo que esté reñido eso que comentas, algunos lenguajes interpretados son muy atractivos porque puedes hacer cosas muy fácilmente, el problema es que esa libertad de entender casi cualquier cosa que le eches luego genera muchas ambigüedades que son un problema.
En general mientras más cosas hace el interprete por ti sin que te des cuenta, menos vas a entender que pasa en casos complejos que no dan resultados intuitivos.
Alguien menciona PHP, también tiene ese problema, o peor aún, PHP nunca fue un lenguaje, se le fueron añadiendo cosas sobre la marcha.
#37 de hecho en VB puedes definir el array como
Dim OstiasEnVinagre(1 to 5) as integer
Y tiene 5 comenzando en el 1
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.
#30 Y el mecanico, albañil, cirujano...la entradilla es un poco chorra.
#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.
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.
#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.
Ñapas...
Es aquí donde los programadores os chupais las pollas unos a otros?
#60 no seas así hombre .
A ver ... que no lo digo para ofender a nadie, pero que se perfectamente que es un algortimo y cantarle las 40 a quien programa con el culo y me deja la máquina frita
#60 Yo quiero un sub donde los admin de sistemas podamos llorar agusto.
1) En desarrollo funciona perfecto.
2) La aplicacion va fluida, el servidor necesita mad RAM
3) No sabemos nada de ese bloq en la BBDD las consultas tienen un timeout adecuado.
4) El servidor quadcore, es un poco escaso, el fabricante recimienda un opteron
Etc... mandarme la buambulancia me la he ganado.
#76 docker
Programador = /= Técnico
Igual que conductor de automóvil =/= Mecanico
#18 no.
Programador != técnico
Igual que diseñador de automoviles != mecanico
Igual que dios != medico
O algo así
#44 Depende del lenguaje unos se pone != otros !== o otros directamente ni los nombro.
#50 ¿En qué lenguajes se pone !==?
#66 Supongo que ha confundido el comparador de tipo !== (de varios lenguajes) con el comparador de diferencia !=.
Ha querido ir de listo, de todos modos no sé si no ha entendido mi comentario o ha desviado el tema sin más.
Podría haber dicho que en otros lenguajes se utiliza (si, si, incluso para strings), que desafortunado la verdad.
cc/ #50
#67 No he querido de ir listo, aqui el se ha resbalado ahora eres tú
En Java también se pone !==, además de php creo que también sirve.
http://docs.oracle.com/javase/tutorial/java/nutsandbolts/op2.html
#100 Y vuelves a intentar ir de listo sin ni leer mi comentario.
En PHP !== NO es sinónimo de diferente. Se utiliza para comparaciones de tipo. Si tu comparas (0 == true) te dará false y en mucho casos (como funciones que retornan una posición que puede ser cero) te conviene poder comparar también el tipo para que 0 se interprete como false. y para eso existen !== y ===
En el tutorial deJAVA que has enviado NI NOMBRA !==
#100 En Java no tiene sentido !== ni === ya que tiene una tipado fuerte, es decir, no puedes comparar tipos diferentes. En cambio en lenguajes de tipado débil como PHP y Javascript donde las variables puedes ser desde un carácter a un objeto que tu crees, se necesita un instrucción que supla la falta de tipado.
#66 javascript
"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.
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.
#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
#29 En general sí, cualquier buen profesional debe valorar siempre las alternativas, sin embargo, en muchos casos sí se puede tener todo. Aunque mientras más forma empieza a tomar tu sistema, siempre se tienen que tomar más compromisos.
#4 PHP.
Déjate un punto y coma en el sitio equivocado y puedes descojonar una web entera.
#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.
#26 "Si no lo aprendes por las buenas, lo aprendes por las malas."
Santa verdad.
#25 C. Cómete un asterisco de dos y observa como ese puntero va a tomar por culo cuando menos te lo esperas.
#62 Es lo que tienen los malvados compiladores, suelen tomarse en serio el análisis sintáctico.
#90 O cuando no el preprocesador se ríe en tu jeta.
#90 Si PHP al colegayonseca le parece chungo, mejor que no vea esto:
http://en.wikipedia.org/wiki/International_Obfuscated_C_Code_Contest
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.
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...
#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...
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
No estoy de acuerdo con el punto 1.
#1 Explanation needed.
#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.
#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....
#65 efectivamente.
Supón que el dinero no es un problema:
¿Que prefieres un mercedes o un Tata?
#65 Jajajajajaa lo mismo he pensado yo, suuuuper tiennnno.
Supongo que algunos lo miramos desde la cruda óptica de la consultoría egpañola, no desde el mundo de arcoiris y unicornios de las startups molonas (...que envidia...)
#4 ¿En qué departamento de Márketing dices que trabajas?
#4 JAJAJAJAJAJJAJ
#4 Actualmente estoy trabajando en evolutivos de una de las empresas de
Banca mas fuerte de España (no diré más pero imagino que ya sabréis cual), y te dan ganas de dejar tu dinero
Bajo la colcha.
Violin.
Arca.
#4
#1 ni yo en el 0
#1 Creo que se refiere a que cuando conoces bien algo también llegas a conocer sus debilidades y puntos críticos. Eso ocure cuando sabes "mirar bajo el capó" y entender lo que hay debajo y lo que puede haber. Ejemplo: cuando te conectas a una wifi abierta y desconocida y navegas a través de sistemas de terceros que examinan y almacenan tus datos. O como cuando whatsapp no encriptaba los mensajes y los trasmitía por canal inseguro...
#1 Esto es que has visto pocas aplicaciones que lleven unos cuantos annos en producción.
#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?).
#1 Yo sí. Conozco programadores que pasan varios kilos de querer entender el hardware y el SO para el que desarrollan. O son completamente inútiles con el ordenador hasta el punto de necesitar ayuda para montarse el entorno de desarrollo desde cero. Los que realmente son buenos programadores, son bastante más espabilados y eficientes.
Otra cosa muy distinta es que usen esa estrategia del "no se" para escaquearse de hacer de pringao-howto para otros por amor al arte, cosa que me parece muy loable.
El punto nueve me recuerda la frase: Es que yo soy de letras
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.
"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.
#42 En Modula-2 se empieza como quieras:
TYPE ArrayDef = ARRAY[12..25] OF INTEGER;
Verdad # 10
A muchos nos da pereza leer en inglés o simplemente no lo dominamos. Pero que no se entere el resto, que somos gente de tecnología y nuestro dominio del inglés es incuestionable.
#75 bastante penosa esa verdad
Yo si puedo elegir entre leer en castellano e inglés, siempre inglés. Es la forma de que al final te cueste prácticamente lo mismo.
Erronea. Acorde al punto 5, debieran ser 8 verdades y empezar en Fact #0
#45 Supongo que entiendo a qué te refieres, pero tu ejemplo está mal. Si cuenta del 0 al 9 te devolvería 10 billetes, como si cuenta del 10135 al 10144, o del 1 al 10.
#53 Siguen siendo 9, en todo caso la numeración estaría mal.
Para mi programar es crear, por eso me encanta.
#42 pues si:
http://rosettacode.org/wiki/Retrieving_an_Element_of_an_Array#Delphi.2FObject_Pascal.2FStandard_Pascal
foo : array[1..10] of integer;
Super fan del 4 y el 7
Sí, y también hay mucha gente que no sabe inglés, ni sabe usar el traductor y que??. Es curioso aquí en meneamé hablan mucho de programadores, que saben cosas que el resto no sabe, que están un escalón por encima y cosas de ese tipo. Algún tipo de complejo tienen que tener para darse tantos aires.
https://sites.google.com/site/codigodedescuento/codigo-promocional-groupalia
"Counting starts from zero, not one" Puto delphi: algunos índices empiezan en cero y otros en uno.
#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?
#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".
#101
"Tampoco sé qué lenguaje inició esto"
Ensamblador, y el lenguaje máquina antes que él.
"Leñe, ahora que lo mencionas, a mí lo que me parece retorcido es usar "arreglo" "
Dudo que alguien que no sea algún tipo de ludópata o incluso algún tipo de extraño alcohólico use semejante término sin ruborizarse. Y no es por ofender a #80, pero es que es así.
Alguien que me diga qué pinta el punto 8 en esa lista. Es como decir:
Fact 10: When you boot your computer, the processor starts working
El punto 5, lo de que empieza a contar desde 0, pues bien, deformación profesional, pero en el mundo real ve al banco a retirar pasta y que el cajero te devuelva 10 billetes contando del 0 al 9 (por poner un ejemplo), a ver si tu cerebro es tan "cool" cuando se trata de pasta.
El resto de puntos ok.
#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.
#96 Donde dije "no se puede acceder multiplicando el puntero por el índice" quise decir "no se puede acceder sumando el puntero con el índice".
#101 Si, es lo que explico en #96
#96 Ojo, que yo en ningún momento argumento nada en contra de contar desde 0 en el mundo de la programación, no se por qué me incluyes.
Lo que quería decir es que en esa lista sobra ese punto, el de que un programador cuenta siempre desde 0, se sobreentiende que no sólo en su trabajo. No me lo creo (sí creo que hayan excepciones) y me parece algo que usa para justificar a los demás que los programadores son seres de luz y el resto ignorantes de la vida.
Resumiendo: ¿Haces todas tus cuentas (vida personal incluida) contando desde 0? Me parece bien. Seguro que los que trabajan en banca cuentan desde cero y con decimales, y todavía estoy por ver en portada de MNM una lista de este tipo con lo que los profesionales de la banca saben pero la mayor parte de la gente no. Dicho esto ahora me arrepiento de no haber votado este envío como irrelevante.
#96 No sé por qué supones que nos quejamos de una cosa u otra.
La mayoría de lenguajes cuentan desde cero, incluso muchos que no usan punteros ni offsets de memoria (como todos los lenguajes de scripting), por la sencilla razón de que ya está establecido como mayoritario.
Y sí, con certeza ya lo sabíamos, teniendo en cuenta los comentarios.
#96 No es una idea tan ininteligible, en la realidad se podría ver. Por ejemplo que seamos 10 y nos digan que nos sentamos en la fila 5 a partir del asiento 4.
La primera posición es la 4 (4+ desplazamiento 0), segunda 5 (4+1), etc, y el ultimo asiento es el 13 (4+9).
#127 Mucha gente se pierde haciendo ese tipo de cuentas cuando tienes un ordinales, vamos, nadie lo hace porque normalmente no tiene que hacerlo, y cuando lo hace se suele perder.
En mi ejemplo de antes, mucha gente te diría que el rango en el que se sientan (al ser 10) es del 4 a 14 algo intuitivo pero erróneo.
Se empieza en el cero porque ese número historicamente define el offset del elemento, hijnorantes.
#97 A todo esto, yo creo que sería más simple si para los siglos y los años se hiciera lo mismo. Hay un montón de cálculos históricos que tienen errores debido al inexistente año "cero". Uno de ellos precisamente el del calendario que usamos.
Fact 5
Counting starts from zero, not one.
Poco ha programado éste para decir semejante estupidez.
No sé por qué mnm ha colocado mi comentario aquí
#22 Poco ha programado éste para decir semejante estupidez.
.
#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.
#24 en pascal se empieza a contar en 1.
#24 Otro que empieza desde 1
#24 también en Matlab el primer índice es el 1.
#83 Y en R
#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.
#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.
#32 Muy buena esa anotación, no es lo mismo cardinal que ordinal. Aunque sea menos intuitivo para muchos, a mi me parece más lógico decir que el primer piso es la planta baja.
Aunque en el fondo me da igual, mientras no empiecen a usar fracciones o números irracionales...
#32
numerar.
(Del lat. numerāre).
1. tr. Contar por el orden de los números.
http://lema.rae.es/drae/?val=numerar
Ouch.