IDE, които имахме преди 30 години… и които загубихме
Оригиналът е на JULIO MERINO
Даниел Десподов преди 47 секунди 1 СподелиНай-четени
АвтомобилиДаниел Десподов - 11:22 | 30.12.2023JAC започва всеобщото произвеждане на първия в света електрически автомобил с натриево-йонна батерия
ХардуерЕмил Василев - 14:24 | 29.12.2023Русия възнамерява да възобнови производството на аналогови чипове въз основа на опита на Съюз на съветските социалистически републики и Беларус
НаукаСветлин Желев - 0:22 | 31.12.2023Китай разгласи създаването на най-мощния детонационен мотор за хиперзвукови полети
Даниел Десподовhttps://www.kaldata.com/Новинар. Увличам се от модерни технологии, осведомителна сигурност, спорт, просвета и изкуствен интелект.Научих се да програмирам в края на 80-те и началото на 90-те години на предишния век. Тогава не разбирах какво върша и за какво инструментите, които използвах, бяха впечатляващи поради рестриктивните мерки на хардуера, с който разполагахме. През годините натрупах повече познания и в този момент ми е доста забавно да взема DOSBox-а, с цел да изпитам още веднъж тези стратегии и да ги сравня със настоящето положение на нещата.
Този път желая да прегледам текстовите IDE, които имахме в епохата преди Windows да завладее промишлеността на персоналните компютри. Искам да направя това, тъй като на тези IDE може да се завижда, даже спрямо днешните IDE. Сякаш преживяхме тъмна ера, в която множеството от тези функционалности бяха изгубени за много дълги години, с цел да се появят още веднъж в този момент.
Останете тук, с цел да се насладите на едно носталгично пътешестване обратно във времето и да побъбрим малко за раздутостта на кода или по този начин наречения „ bloatware “. Но по-важното е да прочетете публикацията, с цел да добиете визия за това по какъв начин беше преди, с цел да можете да оцените по-критично сегашното.
Първите редактори и текстови потребителски интерфейси
През 90-те години на предишния век съвсем всяка стратегия за DOS имаше пълноекранен текстов потребителски интерфейс (TUI) с текстови прозорци, сенки, цветове и поддръжка на мишката. Ето единствено един образец:
Всяка стратегия беше като обособен остров, тъй като интерфейсът ѝ бе неповторим. Въпреки това всички те си приличаха на външен тип – 80х25 знака не оставяха място за многообразие, а и по метода на работа, тъй че разликите не пречеха на удобството за прилагане и известността. Веднага откакто научиш, че клавиш Alt отваря менютата, а Tab се придвижва през полетата за въвеждане и бутоните, можеш да навигираш с лекост в съвсем всяка стратегия.
Но дано поговорим за редакторите. От версия 5 (1981 г.) MS-DOS се доставяше с текстовия редактор, показан нагоре, който точно с TUI интерфейс. Този редактор „ работеше “, само че бе доста неуместен за програмиране: трябваше да излезете от редактора, с цел да компилирате и стартирате кода, а когато още веднъж стартирате редактора, трябваше независимо да се върнете там, където сте били преди.
„ В моята къщурка “ използвахме нещото, наречено SideKick Plus (1984 г.), което в действителност не беше редактор на код: това беше по-скоро система за ръководство на персоналната информация (PIM) с вграден бележник. Но най-интересното в нея беше, че тя бе Terminate and Stay Resident (TSR) стратегия, което означаваше, че работи във фонов режим и можете да я извикате когато и да е, като натиснете Ctrl+Alt.
Можете да мислите за тази TSR функционалност като за рудиментарна многозадачност за една операционна система, която в действителност нямаше никаква многозадачност. Тя бе в действителност ефикасна, тъй като бързото превключване сред редактиране на кода и неговото компилиране е доста значимо за ефикасния вътрешен цикъл на разработка.
По това време обаче от няколко години към този момент имаше същински IDE. Turbo Pascal 1.0 (1983 г.) сподели първи проблясъци на интегрирано ръководство, макар че към момента не разполагаше с емблематичния TUI. QuickBASIC 2.0 (1986 г.) сподели по-„ обичаен “ TUI (същият като EDIT.COM, тъй като е същият редактор), а MS-DOS 5 се доставяше с QBasic, орязана версия на QuickBASIC, която не позволяваше компилиране на нативен код, само че имаше същия външен тип и характерности.
Серията Borland Turbo
По мое мнение перлата на IDE е по-късната серия Borland Turbo, която включва Turbo C++ (1990 г.), Turbo Assembler и Turbo Pascal. Тези IDE бяха характерни за обособените езици, имаха TUI на цялостен екран и бяха извънредно мощни.
Ето какво имахме. Осветяване на синтаксиса:
Интеграция на компилатора и диагностика:
И още: интегрирано ръководство на плановете и система за сглобяване на обособените файлове:
Дебъгер с точки на спиране, следене на стека и други:
И даже цялостна справочна система:
Не забравяйте, че всичко това се случва при започване на 90-те години на предишния век – доскоро повече от 30 години все още на писане на този текст.
Бях разпален консуматор на Turbo C++, от който научих доста. Спомням си, че използвах тяхната библиотека conio.h, с цел да осъществявам лични TUI, а по-късно и вградената им библиотека graphics.h, с цел да си поиграя с реализирането на графични интерфейси. И забележете: това беше преди появяването на интернет. За мнозина нямаше метод просто да „ видят по какъв начин работят нещата “ в Stack Overflow: IDE трябваше да е разполагаем незабавно (което си беше тъкмо така) и да е самодостатъчен, с цел да ви предложи пълноценна разработка.
Съвременните текстови IDE
Както и да е. Да забравим за предишното и да погледнем какво имаме през днешния ден в региона на TUI. Не желая да преглеждам графичните потребителски интерфейси, защото… ами Visual Basic беше върхът на графичното програмиране и към този момент го нямаме – в действителност това е тематика за друга публикация (добре, имате Gambas… само че кой знае за него?).
Най-близкият по-съвременен еквивалент на средата Borland Turbo C++ е RHIDE. Както можете да видите на изображението по-долу, средата наподобява необикновено сходна – и ще ви бъде простено да кажете, че е Turbo C++. За страдание, тя е предопределена единствено за DOS и наподобява е съвсем изоставена, като последната ѝ версия е отпреди 7 години.
След това имаме Free Pascal. Това е най-близо до остарялата версия, само че с съвременна кодова база, работеща и на Unix системи и употребяваща терминали с всевъзможен размер.
И най-после, QB64. Прилича доста на Microsoft QuickBasic, но… не се заблуждавайте: макар че наподобява на TUI, в действителност е приложение с графичен интерфейс, което имитира TUI. Не можете да стартирате QB64 в терминал.
Както Free Pascal, по този начин и QB64 се поддържат и развиват относително интензивно, като последните им версии излязоха през 2021 година, само че значително са подценявани, тъй като са архаични езици, от които в наши дни множеството хора не се интересуват.
Защо въобще се нуждаем от TUI IDE?
Справедливо е да се запитаме: „ На кого му пука? Всеки десктоп и преносим компютър към този момент работи с графична операционна система! “
И това е един прекрасен въпрос. Като цяло евентуално нямате потребност от текстова среда за разработка. Ако предпочитате VSCode, неговите благоприятни условия за отдалечена работа са отлични, а VSCode има задоволително добър графичен интерфейс, без да е пълноценно IDE. Но има няколко неща, които VSCode не ни дава.
Първото е, че TUI IDE е превъзходен за работа на отдалечени машини – даже по-добър от VSCode. Можете елементарно да употребявате SSH към всяка машина и да стартирате IDE. Комбинирайте това с tmux и ще получите „ цялостна “ многозадачност. Да, можете да употребявате клиент за далечен работен плот вместо SSH, само че постоянно съм считал това за неловко заради латентността и неправилната интеграция с локалните директни пътища на декстопа.
Второ, разширенията за далечен работен плот на VSCode не са с отворен код, което не е огромен проблем… с изключение на обстоятелството, че не работят, да речем, на FreeBSD и няма метод това да се оправи. Така че това прави невероятно отдалеченото свързване с главния ми сървър за разработка посредством VSCode.
И третото нещо е… намаляването на потреблението на систематичните запаси.
Раздуване на всички места
Не мога да приключа, без да кажа няколко думи за „ раздуването на кода “. Borland Turbo C++, с всичките си плюсове и минуси (потребителски интерфейс, C++ инструментариум, интегрирани ръководства…), заема по-малко от 9 MB след инсталиране и работи в границите на 640 KB RAM.
За съпоставяне, Helix заема 16 MB на диска, което е много впечатляващо (и, почтено казано, неочаквано), до момента в който Doom Emacs е към 500 MB и употребява доста MB RAM. Имайте поради обаче, че нито едно от тези цифри не регистрира инструменталните вериги за програмните езици или помощните системи, а те в наши дни заемат още доста гигабайти дисково пространство.
За да получим „ същинска “ IDE, би трябвало да преминем към графични стратегии като IntelliJ или VSCode. VSCode, да вземем за пример, заема към 350 MB на диска (изненадващо по-малко от Doom Emacs), само че ще погълне компютъра ви като обяд: въпреки всичко това е Electron. Като се отхвърлих от VSCode и прекосих към Doom Emacs, забелязах доста огромна спестовност в живота на батерията на преносимия компютър.
Така че въпросът, на който желая да отговоря, е: напреднахме ли доста за тези 30 години? Съвременните IDE имат малко по-добри принадлежности за рефакторинг, по-добри функционалности и поддържат повече езици, само че по същество… не са се трансформирали доста. Единствената основна разлика, която започваме да виждаме, може да бъде програмирането благодарение на изкуствен интелект, само че това е функционалност, предоставяна най-вече от отдалечена услуга, а не от местен код!
И това е всичко за през днешния ден. Аз, от своя страна, на драго сърце ще продължа да употребявам всички Doom Emacs, Vim, VSCode и IntelliJ съгласно случая. Весела Нова година, в случай че още празнувате!
