En esta nueva entrega de los vídeos de los abuelos cebolleta de la informática se puede experimentar durante más de diez minutos la (literalmente) más tediosa forma de introducir un programa en el IBM 1401: girando ruedecitas y pulsando interruptores a un lado y a otro para alimentar a la bestia con el código, letra a letra.
Comentarios
#0 Eso es porque eres un jovenzuelo; en mis tiempos, los programas los cincelábamos en la roca más húmeda de la cueva.
#1 Bufff que recuerdos cuando introdujeron el primer cincel, todos dudabamos de su capacidad para registrar datos sobre la piedra pero al final se tuvo que acabar imponiendo, aun recuerdo a los mas reticentes que seguian esculpiendo procedimientos y funciones mordisqueando poco a poco el marmol.
#3 Cómo han cambiado los tiempos, madre mía. Recuerdo que si dabas mal el golpe de cincel y escribías un 1 en lugar de un 0, te podías pasar todo el precámbrico depurando aquello a la luz de una tea de grasa de mamut.
#9 Ah que teniais luz, nosotros picabamos durante la noche de los tiempos, antes de que toda energia fuese concebida.
#11 Puf, soy un nativo tecnológico comparado contigo.
#12 Yo hice animacion por ordenador de la cabecera de saber y ganar
#15 Y así quedó.
#29 una mierda, en mis tiempos vivíamos en un charco, cazabamos lo que podíamos y jugábamos sólo con un palo
Quiero decir, tal vez en sus tiempos los programas solo los usaba un usuario a la vez, una copia en ejecución, ... Además de otras limitaciones.
Si tanto sabe, al kernel de linux podría ayudar, sus conocimientos serán apreciados.
#29 Yo creo que hay alguien más viejo en el equipo de Saber y Ganar: el tío que hace sus animaciones.
#11 Que avanzado, ¡picabas! nosotros tomábamos estiercol fresco de ave y con el ácido que posee, formábamos las instrucciones sobre piedras especiales sensibles al ácido y debíamos esperar a que el sol hiciese su parte fijando. Adjunto el documento de requisitos y los que intervenían en eso.
#44 #3 #9 A mi me subcontrató una cárnica por medio de una ETT durante 6 días para programar vuestra evolución.
Al 7º, al paro.
Así quedó.
#44 Pues a mi esas manos, me da que fue el trabajo de fin de curso de unos niños de primarias.
#3 ¡Qué pijos que teníais dientes! En mis tiempos aún no habíamos evolucionado de los peces cartilaginosos, y teníamos que horadar la piedra desgastándola con las aletas.
#16 aletas dice, nosotros las bacterias unicelulares utilizamos cilios, flagelos y cambios de densidad para rascar la roca
#26 ¡Qué avanzados! Cuando estaba conviviendo como virus establecíamos los bits mediante los estados de vivo y latente en las diferentes posiciones de la célula.
#61 buah, en mis tiempos cuando solo éramos moléculas sueltas teníamos que grabar los programas interaccionando por casualidad en rocas de silicio.
#61 cuando éramos átomos recién formados tras el big badaboom estableciamos los bits según el spin de nuestros electrones.
Y aquí paro, que nos metemos en computación cuántica
#26 Y hoy día se lo cuentas a los jóvenes y no se lo creen.
#3
43 años tiene el chiste.
#3 El iCincel.
#3 ¿Qué arquitectura usabais?
#63 En pizarra
#67 Eso es el IDE a mi no me engañas.
#68 https://es.wikipedia.org/wiki/Arquitectura_en_pizarra_(inform%C3%A1tica)
#69 Oh dios mío... otra mas...
¿Pulsando interruptores?
Los verdaderos programadores usan mariposas
Real programmers
https://xkcd.com/378/
#0 Es verdad...hoy en día tenemos que pulsar teclas...que son interruptores...
#2 Son pulsadores.
#2 Son pulsadores no interruptores sino al al dar a una tecla pasaría esto:
sssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss
Y por eso se habla de pulsar una tecla o de pulsación de teclas, porque son pulsadores e introducen pulsos.
Salu2
Y en las misiones Apolo el codigo se cosía, literalmente.
#5 Eso no era código, eso era el entramado de las memorias de núcleos de ferrita.
#6 Era el codigo máquina. Más o menos, el equivalente a lo que describe la noticia.
#7 Que no, que son memorias de núcleos o anillos de ferrita. Mira -> http://www.teknoplof.com/2009/11/25/memorias-de-nucleos-de-ferrita/
#10 La memoria lleva la información del programa que ha de ejecutarse. Cada anillo de ferrita representa un bit, y en función de como se "cosa" el cobre representaba un uno o un cero. Lo que hacían es compilarse el código a ejecutar a mano y luego se enviaba a otro departamento para que lo cosieran. En la siguiente generación, el codigo a ejecutar se metía con interruptores, luego se utilizó un teclado. Hasta que inventaron el Fortran.
#14 No, no es en función de como se cosa. Los hilos llevan corriente y polarizan los anillos en un sentido o en el otro (0 o 1). También hay hilos de borrado y de reescritura... Es la estructura de una memoria antigua, y no tiene nada que ver con los lenguajes de programación. En fin, déjalo; no te pongas más en ridículo; en serio.
#17 Déjalo tu porque el AGC tenía memorias de nucleos de magnéticos (RAM) y nucleos cableados (ROM) (Core Rope) donde iba el software. O sea que si hay módulos con programas "cosidos" a medida.
https://es.wikipedia.org/wiki/Apollo_Guidance_Computer
https://es.wikipedia.org/wiki/Memoria_de_n%C3%BAcleos_cableados
https://en.wikipedia.org/wiki/Core_rope_memory
https://hackaday.com/2016/09/02/decoding-rediscovered-rope-memory-from-the-apollo-guidance-computer/
Estás dando una lección erronea
#20 Vamos, que ni idea. Fin.
#17 No te pases de listo, porque se ve que tienes poca idea sobre lo que dices. Y si, tiene que ver con los lenguajes de programación, en cuanto que estos han terminado eliminando todo este trabajo tedioso que se hacia hasta los años 70's. No te voy a escribir un comentario de tres paginas para explicarte toda la evolución. Pero hay mucha literatura al respecto, que se ve que no has leído.
#17 Vas de listo y quedas como el culo. La ROM del AGC se cosía en anillos de ferrita ("Memoria de Nucleos Cableados", o "Core Rope Memory" en inglés) tal como dice@gonas. Una de las razones principales era que la ROM debía soportar vibraciones extremas y ser inmune a la radiación electromagnética.
Por aquel entonces también existía la RAM de núcleos magnéticos ("Memoria de toros", o "Magnetic Core Memory" en inglés), que es con lo que te estás confundiendo (y con la que también contaban las computadoras de vuelo de Apollo, aunque en una escala mucho mas reducida).
#75 No voy de listo, soy listo. Y tú te equivocas.
#14 Creo que los anillos de ferrita ya iban engarzados en una malla. La grabación del programa consistía en magnetizarlos en un sentido o en el otro, pero sin moverlos ya. Estas memorias se podían borrar y regrabar.
#18 Puede que lo que describes fueran mejoras tecnológicas. Las primeras versiones, por lo menos las del Apollo XI se cosían.
#c-14" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2982743/order/14">#14 tiene razón.
En las misiones Apolo los programas se cosían (sí, a mano) en una madriz y por decirlo de alguna manera, eran el equivalente a la memoria ROM o mejor dicho, al firmware. Si se detectaba un error había que tirar todo el entramado. Obviamente, el programa se escribía en el lenguaje que correspondiera.
https://github.com/chrislgarry/Apollo-11
# THIS ROUTINE TAKES THE SHAFT AND TRUNNION ANGLES AS READ BY THE CM OPTICAL SYSTEM AND CONVERTS THEM INTO A UNIT
# VECTOR REFERENCED TO THE NAVIGATION BASE COORDINATE SYSTEM AND COINCIDENT WITH THE SEXTANT LINE OF SIGHT.
#
# THE INPUTS ARE 1) THE SEXTANT SHAFT AND TRUNNION ANGLES ARE STORED SP IN LOCATIONS 3 AND 5 RESPECTIVELY OF THE
# MARK VAC AREA. 2) THE COMPLEMENT OF THE BASE ADDRESS OF THE MARK VAC AREA IS STORED SP AT LOCATION X1 OF YOUR
# JOB VAC AREA.
#
# THE OUTPUT IS A HALF-UNIT VECTOR IN NAVIGATION BASE COORDINATES AND STORED AT LOCATION 32D OF THE VAC AREA. THE
# OUTPUT IS ALSO AVAILABLE AT MPAC.
COUNT 23/GEOM
SXTNB SLOAD* RTB # PUSHDOWN 00,02,04,(17D-19D),32D-36D
5,1 # TRUNNION = TA
CDULOGIC
RTB PUSH
SXTLOGIC
SIN SL1
PUSH SLOAD* # PD2 = SIN(TA)
3,1 # SHAFT = SA
RTB PUSH # PD4 = SA
CDULOGIC
COS DMP
2
STODL STARM # COS(SA)SIN(TA)
SIN DMP
STADR
STODL STARM +2 # SIN(SA)SIN(TA)
COS
STOVL STARM +4
STARM # STARM = 32D
MXV VSL1
NB1NB2
STORE 32D
RVQ
SXTLOGIC CAF 10DEGS- # CORRECT FOR 19.775 DEGREE OFFSET
ADS MPAC
CAF QUARTER
TC SHORTMP
TC DANZIG
Tenía una memoria RAM de 1024 palabras (de 16 bits + 1 de paridad) y el firmware ocupaba otras 11 kilo palabras.
https://en.wikipedia.org/wiki/Apollo_Guidance_Computer#Memory
#10 Así he conocido yo alguna "antigua" calculadora
#6 #7 Gonas tiene razón.
Realmente ambos estais en lo cierto pero estais hablando de cosas diferentes, por un lado Gonas está hablando de una Core Rope Memory, una memoria ROM al uso por lo que había que programarla, y por otro lado Gobolino está hablando de la Core Memory (Memoria magnética) , memoria RAM.
La memoria magnética no tenía tantos hilos de cobre cruzando los toroides de ferrita como tiene la Rope Memory.
https://commons.wikimedia.org/wiki/File:KL_Kernspeicher_Makro_1.jpg#/media/File:KL_Kernspeicher_Makro_1.jpg
https://en.wikipedia.org/wiki/Core_rope_memory
https://en.wikipedia.org/wiki/Magnetic-core_memory
#6 Eso es cableado de una ROM no memoria de ferrita la memoria de ferrita son 1 -2 vueltas de cobre de cada bobinado, eso es ROM a lo bestia cableada.
https://es.wikipedia.org/wiki/Memoria_de_n%C3%BAcleos_cableados
#6. Tienes toda la razón, parecen núcleos de ferrita para las memorias, pero como #5 apunta el código realmente acababa 'tomando forma' en esas mismas memorias de núcleos de ferrita, lo que no quiere decir que con cada programa diferente 'el cosido' de las ferritas fuera fisicamente diferente.
Cuando estaba en la escuela programábamos el 8085 en código máquina a través de una consola que le fallaban algunos botones en una panel didáctico. Eso sí que era un suplicio. Aquí el panel didáctico.
#22 Menos mal que al final estudie electrónica
#22 Lo mejor era debuggear el programa. No sabías si te habías confundido al introducir las instrucciones, traducirlas al código máquina o si tu programa era el que no funcionaba.
#22 boooo! 8085, 68000 rules!
Ahora, sin embargo, programar es tan "fácil" que una de las cosas más duras de la profesión es lidiar con la mierda de los juntalíneas que son contratados porque (parece) que saben programar.
#4 amén.
#4 otra lacra de la profesión bastante tediosa de lidiar son los programadores con el ego subido y un alto concepto de si mismos.
#40 Yep. Con los mediocres del ego subido y con los mediocres que dicen que los buenos tienen "el ego subido" por no admitir sus chapuzas.
#47 mi experiencia después de unos cuantos años me dice que esos egos y esos "los buenos, los juntalineas de mierda, los que no asumen sus chapuzas por lo bueno que otro es etc " se dan con mayor frecuencia cuanto más "abajo" estás. Es sencillo, yo a uno de esos egos empezaría por preguntarle, si eres tan bueno que haces aquí lidiando con juntalineas?
Por ponerte un ejemplo, yo no me considero un juntalineas pero tampoco un crack, trabajo en un equipo internacional para una empresa bastante tocha de fuera, ni cárnica, ni subcontrata ni nada por el estilo, con gente realmente buena (y cuando digo buena, digo putos cracks). Nunca he visto un ego más alto que otro, ni un comentario tan despectivo como el tuyo sobre los conocimientos de otra persona.
#51 "si eres tan bueno que haces aquí lidiando con juntalineas?"
Puede que acabes de empezar, y señalizar que eres bueno a empresas que no te conocen de nada no fácil, por no hablar de que tienes que pasar por el filtro de recursos humanos. Puede que seas vago y no te hayas puesto a buscar otro curro. Además, si eres bueno de verdad, las empresas regulares es posible que te descarten tras la entrevista por considerar que te acabarás yendo (sea cierto o no) y las empresas buenas es posible que no te lleguen ni a entrevistar si no subes código a github y no tienes suficiente experiencia en el CV ¿Por qué iban a contratar a alguien con el CV prácticamente en blanco? ¿Un par de años de experiencia en una empresilla regulera? Sin embargo si tienes un proyecto chulo que podría acabar siendo un servicio, subirlo a github tiene cierto peligro (nadie es perfecto y es poner en riesgo los datos de tus posibles clientes si tienes alguna brecha de seguridad).
Luego también está el hecho de que igual no te quieres mover de ciudad, o te gusta el ambiente de la empresa y tus compañeros, etc.;
Por cierto a veces los juntalíneas son los jefes.
Además, una cosa es ser bueno, y otra es ser decente. Si eres decente pero no muy bueno los juntalíneas te joden igual y la mayoría de la empresas que te van a contratar van a tener a alguno por ahí.
La gracia para mí es ser el malo dentro de una empresa buena, no el bueno de una empresa mediocre
Si en España se valorase el talento de verdad, no estaríamos como estamos.
#51 "Nunca he visto un ego más alto que otro, ni un comentario tan despectivo como el tuyo sobre los conocimientos de otra persona."
Igual es porque no hay chapuzas épicas como las que se ven en ciertos sitios
#47 Trabajar con alguien que tenga tu nivel de humildad y empatía debe ser una experiencia "inolvidable" vamos, un gustazo.
#72 Imagínate algo así:
https://www.quora.com/Our-CTO-is-a-very-bad-software-developer-but-he-loves-to-code-and-always-submits-bad-code-What-should-I-do/answer/Miles-Fidelman
#CC 51
#40 Todavía no me he encontrado ninguna empresa donde no haya, el típico "listo" que se dedica a echar pestes del código de los demás y luego ves su código y no puede ser mas mediocre, en cambio, los que mejor programan los he visto cayaditos y a sus mierdas, cumpliendo arquitectura, principios y dando soporte a los que no sabían.
El efecto desarrollador diva.
#4 Y cuya formación consiste en un curso del inem.
Pues en mis tiempos...
#41 Grande Dilbert...
Otro fascinante caso de Microsiervos posteando cosas sin nombrar la fuente o el vía. Y van ya...
#32 Lo de siempre, el video pertenece a CuriousMarc
Un apasionado de la electrónica que se dedica a reparar ordenadores antiguos, hace poco reparó junto con un equipo de dos personas más un Xerox Alto y la unidad de disco "Diablo" que tampoco iba muy bien.
¿Pero al final la máquina pone el café o no?
En mi primer trabajo, hace ya 20 años, tuve que programar automarcadores de prefijos telefónicos cutres (la época de Ono, Tele2, Jazztel con los prefijos). Eso si que era un dolor, sobre todo para discriminar las llamadas locales.
Llegué a hacerme un script que los programaba usando el modem, pero nunca llegó a ir fino del todo.
Pues el IBM 1401 que sale en la imagen no se solía programar precisamente con interruptores, que como vemos también se podía, normalmente se utilizaban las unidades de cinta y tarjetas perforadas (Punch Card).
En este vídeo se puede ver como cargan un compilador de Fortran II en el IBM 1401 desde la unidad de cinta para despues compilar un programa que meten mediante tarjetas perforadas, al principio falla y tienen que depurar a base de ver las luces que se han encidido en el panel de control del ordenador para ver donde se ha producido el error.
Es curioso lo que le cuesta compilar y hacer los cálculos que se le piden al ordenador. Al parecer este ordenador no era capaz de hacer cálculos muy complejos de una manera rápida, vamos que había que hacerlos por el cuento de la vieja.
Todavía recuerdo cuando mi primo me trajo un taco de tarjetas de cartón gris perforadas donde había programado un Pacman.
O eso me dijo...
Pero que me vas a contar a mi, chaval, que yo traje los interruptores a Bilbao.
Más triste y más duro fue lo mío, que programaba en Cobol
Cualquier tiempo pasado no fue mejor.
Alguien sabe de algún museo o algo donde se pueda experimentar en persona esos ordenadores?
Aquí sí que era importante optimizar el código.
¿Pulsando botones? Los buenos programadores sólo necesitaban un soldador y estaño.
Se ve que no sabe lo que se paga ahora por programar
#73 se paga de Puta madre,supongo que te refieres en España que salvo algunas excepciones, se paga bastante mal.
#80 Sí, en España, claro. Aunque de aquella se pagaba muchísimo también en aquí.
#83 si, en otra época se pagaba mucho mejor, en todo. Vamos para atrás.
Si claro, y cuando yo empece a programar no había Maven, ni había docker, ni eclipses, ni intellij idea, ni spring framework, ni hibernate, etc... Y hace mas de un siglo, no había ordenadores, todo se hacia de forma manual.
Y programar hoy en dia es para nada fácil. Nunca se sabe lo suficiente. Yo tengo que saber java, spring, hibernate, sql, javascript, angular, react, css, html, xml, json, docker, maven, git, nodejs y pollas en vinagre. Y metete a programar en el frontend con nodejs que eso ya es el caos absoluto, donde hay tropecientas librerías para hacer lo mismo, y tienes que estar que si dependencias para hacer esto y para hacer esto otro. Y luego ponte a probar tu aplicación web en todos los navegadores, que no siempre funciona a la primera sino llevas cuidado.
Si, programar hoy en dia esta tirado, antes era muy difícil.
Los que hoy se dicen "programadores" son simples albañiles que pegan ladrillos hechos por otros, y lo hacen tan mal que el muro está lleno de agujeros y se derrumba.
#13 Todos los programadores pegan ladrillos. Algunos ladrillos son más grandes que otros.
Pero los programas eran más simples.
ahora se escriben solos