A nivel informático, recuerdo con mucho cariño, la época de principios de los años 90. En aquel momento, bastaba con saber lenguaje C y Clipper.
MS-DOS 3.30 era el sistema operativo más difundido, acababa de lanzarse DR-DOS 5 y MS-DOS 5 mientras que MS-DOS 6 y DR-DOS 6.0, estaban aún por salir. Se usaba Windows 3, luego 3.1 y después 3.11, pero solamente por parte de usuarios sin demasiados conocimientos, a modo de shell, o bien para necesidades muy específicas.
Aunque ya existía el 80486 de Intel (luego i486), la mayoría de ordenadores, montaban procesadores 8086, 80186, o 80286 y sus clones (NEC V20, V30, …). Los 386 estaban reservadas para la gama alta. Lo normal era disponer de entre 512 Kb. y 2 Mb. de memoria RAM, en muchos casos sin disco duro, y en los mejores casos, de hasta 80 Mb.
Las redes sólo disponibles en grandes universidades y corporaciones, se basaban en variantes de Novell Netware, y aún había software que se escribía completamente en ensamblador, en Turbo Pascal o incluso en BASIC compilado.
El conocimiento se encontraba en revistas, algunos centros de formación y sobre todo en libros. No había tutoriales, ni apenas documentación electrónica.
Sin embargo, el software verdaderamente profesional, solamente tenía dos opciones, o se usaba Clipper para programas de base de datos y gestión, o se usaba C para el resto. En ese resto, se incluían los juegos, los programas de ofimática, y por supuesto las utilidades.
Lo último era Clipper 5, Turbo C 2.0, o Borland C++ 2.0, una firma que esta presente en la mayoría de software de calidad comercial. Casi nadie sabía C++, y los enfoques a objetos que había, eran más bien basados en objetos que orientados a objetos.
De hecho, si Microsoft C era tu compilador, podías escribir rutinas en C, que se invocaban como código nativo desde Clipper.
Era una época sencilla, en las que sólo había una plataforma (DOS), y que dominando dos lenguajes, tenías acceso a todas las posibilidades.
Ahora el ecosistema de plataformas es enorme: Web, Windows, OSX, Android, iOS, Windows Phone, Linux, … cada uno con sus propias herramientas de desarrollo. Hay que saber HTML, CSS, Javascript, PHP y algún framework (Lazarus, Symphony), bases de datos relacionales (MySQL, Oracle, SQL Server); C/C++, Object Pascal, Swift u Objective-C, Java, C# o VB.NET, … Naturalmente cada uno con sus propios entornos de desarrollo.
Para ponerlo más difícil, en general desarrollar para una plataforma, requiere disponer de plataforma, y emularla o virtualizarla no suele ser suficiente. Así que prepárate para gastar dinero en un Mac, una tableta Android, un iPhone y un PC.
Sí, qué época principios y mediados de los noventa, los programadores eran los reyes del mambo. Ahora son los monigotes de las consultoras.
Turbo C y Turbo Pascal, qué gratos recuerdos…
La lista actual de las materias que hay que saber es inmensa, lo peor es que apenas llegas a dominar una (ajax, por ejemplo, o phyton) ya caduca y llega otra, y vuelta a lo mismo. Algunas profesiones dicen eso de «reciclarse», deberían ver lo que supone ser informático, programador o desarrollador, eso sí es reciclarse.
Yo me he quedado en VB (5, nada de mongoladas de Net) y de ahí no paso. Para lo que quiero me sirve, y para lo que no me sirva ya hay lenguajes interpretados (javascript, java, o cualquier «fumanchú» de esos) que me saca del apuro.
Por otro lado, antes el conocimiento, como bien indicas, había que buscarlo. Ahora hay tanto y de tantas plataformas que lo difícil no está en encontrar ese conocimiento, sino en saber elegir algo que pasado mañana no puedas ni compilar porque no haya plataforma que lo soporte, o por cualquier otra razón.
Por supuesto, nada es eterno, y no hay cosa más caduca que la informática, pero un poco de sentido común no vendría nada mal. Ahora a todos les ha dado por CSS y herramientas interpretadas, e incluso se habla ya de compilación en la nube. En la nube sí. En la nube están muchos. Mejor les fuera con bajar de la nube. Pero bah, es una batalla perdida, lo mejor es la Inteligencia Artificial y que ella programe. «Hazme una app para gestión del correo electrónico», y aplicación al canto. Una app para sacar la basura (por decir algo 😀 ) y aplicación al minuto siguiente funcionando. Mientras eso no llegue esto es un in pass, una travesía en el desierto, una gilipollez sin razón ninguna entre lo que ERA (y recalco era) un auténtico programador, y lo que es hoy en día, un menda al que ponen ahí y lo rodean de nombrecitos que nadie entiende y lo más curioso es que creen que él sí lo entiende y le divierte (e incluso muchos hasta piensan que lo haría gratis por diversión 😀 ).
IA y todos sobraremos. IA en una mano y en la otra mi VB de siempre y, por en medio, todo basura Guti. Pero a la IA le tienen un miedo atroz, porque saben que si dominara ella todos los politicuchos y demás sobrarían. Algo que no pueden controlar no lo quieren. Porque de la IA (y esta es otra) estamos a dos pasos, pero no quieren ni les interesa, y cuanto más puedan alargarlo mejor.
Por cierto, para entretenerse un rato:
http://apuntandoalpalo.com/amanecer-inteligencia-artificial-fin-codigo/
bianamaran, Visual Basic nunca ha sido el hijo predilecto de casi nadie. En la época, contaba con algunos entusiastas, entre los que me cuento. Había que entender que VB estaba hecho para lo que estaba hecho. Un lenguaje sencillo, pero a la vez relativamente potente, y un IDE magnífico. Con el paso del tiempo, cada vez quedamos menos personas que entiendan ese concepto. Si quiero potencia, me voy a C++, pero si quiero algo sencillo, VB era la opción. Similar en concepto, apenas nos queda ya Lazarus/Delphi pero ambos sobre Pascal, que es bastante más estricto que Basic, y por tanto menos fácil de aprender.
Una pregunta, ¿por qué no te pasaste a VB6? VB5 fue el primero en generar código nativo, pero en VB6, era bastante más eficiente.
De la IA, tu mismo lo comentas. Estamos a dos pasos. Los robots, están ya a un paso solamente. Casualmente estaba preparando un artículo sobre ambas.
VB.NET, nunca tuvo sentido, ya no era un lenguaje fácil, ¿entonces para que aprenderlo? Si tenías C# que era casi igual, pero más potente y eficiente.
Sí, sí usé VB6, pero para instalarlo no se si recuerdas que era obligatorio instalar toda la siniestra parafernalia de la máquina virtual de Microsoft, y no se que más. Un palo. Así que VB5 es casi lo mismo pero lo instalas en un plis y consume unos recursos ínfimos. Por eso me gusta más.
Lo de VB.NET no se entiende, y me alegra encontrar a alguien experto como tú que comparta esa misma opinión (o que yo comparto la tuya, vaya, da lo mismo). Porque con toda la gente que hablo de pasada sobre la plataforma .Net se emocionan como si vieran una tía en pelotas (:D). No lo entiendo. Bueno, en parte es porque Microsoft se ha empeñado en que se trabaje para .Net y la gente lo vea como el no va más, pero si buceamos un poco por la historia .Net es una tomadura de pelo comparado con todo lo que había en su día. Eso sí, sin .Net no eres nadie a nivel de curro, porque en todos lados lo piden.
Pues ahora que tengo Windows 10 en casa, intenté lo de VB6, y nada de nada. No había caído en que VB5 pudiera dar menos problemas, así que le echaré un vistazo. Además recuerdo que en la red había un VB6 SP5 parcheado y que funcionaba en Windows 7 u 8, pero le he perdido la pista, así que me viene al dedillo.
A ver, la plataforma .NET, tiene muchas cosas buenas. C# es un lenguaje bonito, Visual C++ permite seguir generando código nativo como hasta ahora, pero además código manejado .NET. Al ser interpretado/compilado JIT, eso permite depurar mucho más fácilmente. Pero su principal ventaja es que es multiplataforma (exacto como Java). Sin embargo, Microsoft no quiso explotar ese nicho en su momento, y lo hicieron proyectos libres en su defecto. Ahora en Redmond, se quieren apuntar al carro de Android, MacOS, Linux, … pero ya es tarde. Y entre tanto, el precio a pagar es un rendimiento bajo, un consumo de memoria elevado, y la dependencia del framework de .NET. ¡Todo para que sólo funcione en Windows! Sin ir más lejos, lo que hacía VB (recordemos que VB4, por ejemplo generaba código para Win16 y Win32), o sea, dos plataformas.
Siempre he pensado que si VB hubiera seguido, el éxito de .NET habría sido muy limitado. Vamos exactamente igual que ha pasado con Delphi al existir Lazarus. Al fin y al cabo, sacrificaron VB, para que así la gente quisiera más a la nueva creación.
Con todo ello, han perdido otro tren, ahora sólo Apple innova, los únicos que apostaron por código nativo en los móviles y las tabletas, y ahora resulta que eso es lo que la gente quiere. Rendimiento, poco consumo de memoria, y duración de batería. Lo último que han hecho, lenguaje Swift compilado a nivel de servidor, así que si quieres rendimiento, .NET va a dejar de ser la apuesta, también con los WebForms a nivel de servidor…
¡Qué recuerdos! CA-Clipper, Blinker, dBase3+…. !Mis primeros programas con 13 o 14 años!.
Disfruté muchísimo esa época y me llevó a seguir con esto.
Veo que no sólo compartimos afición por los relojes.
¡Un saludo amigo!
Por lo que he ido viendo Ender_Wiggin, los relojes y la informática, no se porqué van bastante de la mano. A ello añadiría en muchos casos, la escritura, el afeitado, …
Yo comencé programando en Turbo C 🙂
Manuel, Turbo C es sin duda un campeón. Imagino que ya conoces su historia, pero…
https://www.javiergutierrezchamorro.com/historia-de-borland-turbo-borland-c-c-inprise-borland-c-builder/289
Muchas gracias por el artículo, añoro aquella pantalla azul de Turbo C/Borland C++ y con los textos en colores a la hora de programar.
Yo igual Manuel. Buenos tiempos aquellos los del Turbo C.
En 1999 yo andaba con VB6, después de haber pasado por unos cuantos lenguajes… luego me metí con la página web del curro y desde entonces no me he despegado de PHP.
Ahora, después de 17 años casi todo lo hago con PHP, tengo servidores Windows que ejecutan servicios escritos en PHP, no digo más.
Yo hago webapp siempre que puedo, es mucho más sencillo hoy en día, con html, jquery, css (bootstrap como base) y php (cakePHP, por ejemplo) te montas en poco tiempo cosas muy chulas que funcionan muy bien tanto en escritorio como en móvil. ¿Ejemplos?: generación de códigos de barras en PDF, control de servicios (viewlog de un servicio), envío automático de facturas electrónicas vía FACE… además de otras apps más específicas de mi curro.
También tengo montones de tareas automatizadas mediante scripts, bien en PHP o AutoIt, dependiendo de la tarea (y del estado de ánimo, que también importa). Han sido 17 años de automatización constante… hoy en día mis compañeros y yo no sobreviviríamos al día a día sin ellas.
Para mi, si no es un script de línea de comandos es una webapp, ya casi no le veo sentido a las apps de escritorio típicas… ojo, hablo de las cosas que me toca hacer, no que no deban existir las app de escritorio. Si puedo elegir y el problema encaja (o lo puedo hacer encajar fácilmente) con una webapp para allá que voy… y de momento no me arrepiento.
Saludos
Hemos seguido caminos bastante similares Fernando. Supongo que es lo normal, que el desarrollo desktop pasara a cliente-servidor y luego a web o WebApp. Sin embargo, hecho de menos la eficiencia del código nativo. Vamos, que incluso VB6, le daba palizones a PHP 7.1…
Ahora que mencionas AutoIt, me encanta. Sencillo, genera ejecutables, y muy, pero que muy potente. Me gusta mucho también.
Hombre, aunque PHP se ha metido de lleno en mejorar el rendimiento, con una estrategia muy inteligente que está dando muy buenos resultados, no deja de ser código interpretado.
Sin embargo es curioso, para gestionar los resultados de las elecciones para el curro he creado una web, en ella se cargaban los resultados (unos tar.gz con csv y un mdb), en mi equipo (i5/8Gb) tardaba el tar.gz unos 90 segundos, en el servidor «de producción» (máquina virtual con 2vCPU y 6Gb de RAM) tardaba unas 9 veces menos. El mdb era 120 segundos contra 10…
En mi experiencia un script que procesa sin salida alguna a otro que va volcando datos por la salida estandar da una diferencia de tiempos asombrosa… a ver si un día tonto hago unas pruebas de concepto.
Así a priori te diría que la memoria del servidor, y sus discos, por mucho que estén virtualizados, serán más rápidos que los de tu PC, por eso la notable mejora.
¿Es posible además que el servidor corra Linux, o UNIX? Lo digo porque en mi experiencia, la entrada salida en Linux, es mucho más eficiente que en Windows. Por no hablar de que PHP, también corre un poquito más.
Pero claro, 9 veces más veloz, es demasiada diferencia… Si descubres el misterio haciendo tus pruebas, me encantaría conocer la causa.
Pues un Windows 10 Pro vs Windows Server 2008 R2 SP1…
De todas formas para lo que es yo estimaba que una importación de unos 5 minutos era perfectamente asumible, al final es una operación que se hace una vez, lo que interesa es que los datos de salida sean correctos, de ahí que creara la webapp que nos permite gestionar de forma sencilla un tema que hace diez años requería muchos pasos manuales y ejecutar a mano una serie de consultas sql bastante críticas…
Sobre la posible causa hay que tener en cuenta que tres consultas al MDB generan más de 3000 inserts en MySQL, así que si el rendimiento del disco no es bueno….
Pero lo dicho, a ver si un día me pongo a hacer algunos test, será divertido…
Pero hilando más fino, la importación del tar.gz genera también unos 3000 inserts, lo que pasa que en el MDB tenemos unos 260 insert y cerca de 3000 updates, y el update tiene una penalización enorme…
Ahora si me has dejado despistado Fernando. Ambas máquinas con Windows, y no tiene que ver con los inserts en MySQL.
Yo comencé con dBase III+ y luego CA-Clipper 5.x con rtlink y luego blinker en los 90, que recuerdos aquellos, donde conseguir una librería que manejase el puntero del ratón (en modo consola) era todo un desafío, lograr imprimir algo con formato utilizando los códigos ESC/P también. Extraño esos EXEs regordetes siempre acompañados por unos cuantos DBFs.
Saludos.
Hernán, recuerdo haber usado TLINK de Borland o LINK de Microsoft al principio, que eran mucho más rápidos, aunque no soportaran overlays. Claro, eso fue hasta que salió Blinker, que era más rápido, soportaba overlays, y miles de cosas más. RTLINK (de Pocket Soft, que se hicieron famosos con RTPatch), era más lento que el caballo del malo. Que paciencia para enlazar un sencillo programita como PE.PRG.
Tengo un vago recuerdo de DLINK, pero quizás es de los tiempos de Clipper 87 o así.
Yo arranque con QuickBasic (El que dejaba compilar!), Luego Turbo Pascal, luego Delphi, de ahi a ASP (VBScript), luego C# (Forms y ASP.net) y en los ultimos años PHP.
Hoy dia uso casi a diario PHP, C# y Javascript (node.js), pero extraño esa epoca en los 90 con Pascal
He escrito hace un tiempo un articulo sobre Pascal ayer y hoy, espero les guste: http://puntoequis.com.ar/donde-esta-pascal-hoy/
Muchas gracias John MOhl. He leído el artículo y es muy interesante. Te ficho a mi lector de RSS.
Otro nostálgico que empezó a cacharrear en la década de los 80 con un MSX y con estudios de FP2.
Esa Formación Profesional con RPG, Cobol y Pascal. Luego a nivel profesional, dBaseIII+, dBase IV, Clipper, Clipper CA-Tools, Blinker…
Uff…, casi se me llenan los ojos de lágrimas recordando esos años en los que intentábamos crear programas (en mi caso siempre he hecho gestión) para Windows con Fivewin.
Aún tengo todos los paquetes de software en un armario porque no tengo valor de deshacerme de ellos, son parte de mi historia.
Y también tengo cientos de discos de 5,25 y 3,5 como vosotros. Seguro que algunos tienen material interesante.
He encontrado el blog por una entrada en meneame y ya me habéis ganado como amigo. Seguiré por aquí.
Saludos,
Javier
Siempre es un placer encontrar un nuevo lector fiel Javier Pérez. Viendo tu pasado de xBase, estoy seguro que te encantarán las entradas relacionadas con retroinformática.