Научих се да програмирам в края на 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 според случая. Весела Нова година, ако още празнувате!
Всичко важно от света на технологиите, директно в пощата ти.
С абонирането приемате нашите Условия и Политика за поверителност. Може да се отпишете с един клик по всяко време.
Коментирайте статията в нашите Форуми. За да научите първи най-важното, харесайте страницата ни във Facebook, и ни последвайте в Google Новини, TikTok, Telegram и Viber или изтеглете приложението на Kaldata.com за Android, iPhone, Huawei, Google Chrome, Microsoft Edge и Opera!
