IDE, которые были у нас 30 лет назад… и которые мы потеряли

Я учился программировать в конце 1980-х — начале 1990-х годов. Тогда я не совсем понимал, что я делаю и почему инструменты, которые я использовал, были впечатляющими, учитывая ограничения имеющегося у нас железа. С годами я приобрел больше знаний, и теперь мне очень интересно взять в руки DOSBox, чтобы заново испытать те программы и сравнить их с нынешним положением дел.

В этот раз я хочу рассмотреть текстовые IDE, которые были у нас в ту эпоху, пока Windows не поглотила индустрию ПК. Я хочу сделать это потому, что тем IDE можно было позавидовать, даже по сравнению с нынешними. Создается впечатление, что мы пережили темную эпоху, когда большинство этих функций было утрачено на долгие годы, а появились они вновь только сейчас.

Оставайтесь, чтобы насладиться ностальгической поездкой в прошлое и немного поразглагольствовать о «раздутости». Но, что более важно, прочитайте статью, чтобы получить представление о том, что было раньше, чтобы более критично оценивать настоящее.

Первые редакторы и текстовые пользовательские интерфейсы

В 1990-х годах почти каждая программа под DOS имела полноэкранный текстовый пользовательский интерфейс (TUI) с текстовыми окнами, тенями, цветами и поддержкой мыши. Вот лишь один пример:

Редактор MS-DOS (он же EDIT.COM) с одним из окон настроек. Обратите внимание на строку меню, диалог со списком селекторов и кнопок, а также строку состояния, документирующую навигационные ярлыки.

Каждая программа была своим собственным островом, потому что ее интерфейс был уникален. Однако все они были похожи внешне — 80x25 символов не оставляли места для разнообразия — и по принципу работы, так что различия не мешали удобству использования и узнаваемости. Как только вы узнали, что клавиша Alt открывает меню, а Tab перемещает по полям ввода и кнопкам, вы могли с легкостью ориентироваться практически в любой программе.

Но давайте поговорим о редакторах. Начиная с версии 5 (1981) MS-DOS поставлялась с текстовым редактором TUI, который показан выше. Этот редактор «работал», но он был очень неудобен для программирования: вам нужно было выйти из редактора, чтобы скомпилировать и запустить код, а когда вы снова запускали редактор, вам нужно было вернуться к тому месту, где вы были раньше.

«В моем доме» мы использовали нечто под названием SideKick Plus (1984), который на самом деле не был редактором кода: это была скорее система управления персональной информацией (PIM) со встроенным блокнотом. Но самое интересное в нем было то, что это была Terminate and Stay Resident (TSR) программа, то есть она работала в фоновом режиме, и вы могли вызвать ее в любой момент, нажав Ctrl+Alt.

Главный экран SideKick Plus после нажатия Ctrl+Alt для его вызова. Обратите внимание, что DOS остается в фоновом режиме.

Считайте эту функцию TSR рудиментарной многозадачностью для ОС, в которой на самом деле не было многозадачности. Это было действительно эффективно, потому что быстрое переключение между редактированием кода и сборкой очень важно для эффективного внутреннего цикла разработки. (И, кстати, этот опыт объясняет поток редактирования кода в EndBASIC ^[1]. Я не реализовал эквивалент Ctrl+Alt, но много раз думал об этом).

Однако к этому моменту настоящие 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 и были чрезвычайно мощными.

Вот, посмотрите, что у нас было. Подсветка синтаксиса:

Borland Turbo C++ с «Hello World» для демонстрации подсветки синтаксиса.

Интеграция с компилятором и диагностика:

Borland Turbo C++ после компиляции программы выдает предупреждение о том, что я не вернул значение из main().

Интегрированное управление проектом и системой сборки:

Управление проектами и многооконные возможности в Borland Turbo C++. На рисунке вы видите два исходных файла C++, один из которых зависит от другого, и окно проекта, в котором перечислены все файлы, которые необходимо скомпилировать.

Отладчик с точками останова, трассировкой стека и т.п:

Сеанс отладки с программой, содержащей несколько функций, точку останова и текущий стек вызовов.

И даже полное справочное руководство:

Интегрированная в Borland Turbo C++ справочная система с программой «Hello World» на заднем плане и справкой по printf.

Помните: все это было в начале 1990-х — чуть более 30 лет назад на момент написания этой статьи.

Я был заядлым пользователем Turbo C++, с помощью которого я многому научился. Я помню, как использовал их библиотеку conio.h для реализации собственных TUI, а затем их встроенную библиотеку graphics.h, чтобы поиграть с реализацией графических интерфейсов. И заметьте: это было еще до Интернета. Для многих не было возможности просто «посмотреть, как все работает» в Stack Overflow: IDE должна была быть доступной сразу (что и было реализовано) и самодостаточной, чтобы предложить вам полный опыт разработки.

А что было с Linux в те времена?

Сравним эти IDE с Linux начала 1990-х годов.

В Linux почти все программы также были текстовыми, но они не поставлялись с полноэкранным пользовательским интерфейсом. Это просто не было «путем Unix». Я помню, как смотрел на инструмент настройки X11 (XF86Setup) или программу установки OpenBSD и был шокирован тем, насколько они были упрощены. Даже я, молодой подросток, не имевший почти никакого «настоящего» опыта программирования, уже писал более красивые программы.

В любом случае, это не остановило меня в моем стремлении отказаться от использования Windows. Я продолжал изучать Linux и вскоре столкнулся с «лучшими» редакторами, которые рекомендовали все книги и сообщества в Интернете: Vim и Emacs. И я не мог понять, почему их так хвалят. Использование этих редакторов было похоже на возврат в прошлое. Это действительно были полноэкранные программы, но они казались довольно заумными. В Vim была подсветка синтаксиса, но до IDE ему было далеко. Emacs можно было настроить на интеграцию с некоторыми функциями помощи в программировании, но он был далек от того, чтобы «запустить и забыть», как семейство Turbo IDE.

Просто посмотрите на сегодняшнюю конфигурацию Emacs по умолчанию, которая не сильно изменилась (если вообще изменилась) с тех пор. У него есть окна, но они не прорисованы. У него не было цветов (а теперь почти нет), потому что зачем? В нем не было поддержки мыши. У нее есть строка меню, но это просто прикол? Если вы нажмете M-`, как сказано в инструкции, вы столкнетесь с действительно странным интерфейсом для навигации по меню — что заставляет задуматься, зачем они вообще потрудились потратить целую строку экранного пространства, чтобы показать строку меню, которая ничего не делает.

Свежая установка Emacs в консоли, со стандартным экраном приветствия в фоновом режиме и «меню», открывающимся после нажатия M-`.

А теперь попробуйте дать это любому человеку с небольшим опытом программирования и попросить его создать, скомпилировать и отладить программу. Ему будет сложно просто ориентироваться в редакторе, и он не найдет ни одной функции, которая позволила бы управлять проектами или запустить компилятор.

Для сравнения, при написании этого поста я запустил Turbo C++ в DOSBox, смог создать проект «hello world» и сориентироваться в среде за считанные минуты — и все это без предварительных знаний (все, что я знал, к настоящему моменту уже забыто). Среда интуитивно понятна и, как IDE, интегрирована с ней.

Современные текстовые IDE

Как бы то ни было. Давайте забудем о прошлом и посмотрим на то, что мы имеем сегодня в области TUI. Я не хочу рассматривать графические интерфейсы, потому что… ну, Visual Basic был вершиной графического программирования, а у нас его больше нет — и это тоже тема для другой статьи (ладно, у вас есть Gambas… но кто о нем знает?).

Ближайшим более современным эквивалентом среды Borland Turbo C++ является RHIDE ^[2]. Как вы можете видеть на рисунке ниже, среда выглядит невероятно похожей — и вас бы простили, если бы вы сказали, что это Turbo C++. К сожалению, она предназначена только для DOS и, похоже, уже практически заброшена, а ее последний релиз вышел 7 лет назад.

RHIDE IDE показывает ту же программу «hello world», что и раньше, без ошибок и предупреждений после компиляции.

Далее у нас есть Free Pascal ^[3]. Это наиболее близкий к старому вариант, но с современной кодовой базой, работающий на Unix-системах и использующий терминалы любого размера.

IDE Free Pascal с тривиальной программой «hello world» и перекрывающимися окнами для встроенной таблицы ASCII и калькулятора.

И, наконец, QB64 ^[4]. Он очень похож на Microsoft QuickBasic, но… не дайте ему обмануть вас: хотя он и выглядит как TUI, на самом деле это GUI-приложение, которое имитирует TUI. Вы не можете запустить QB64 в терминале.

QB64 IDE, которая выглядит текстовой, но на самом деле является графической.

И Free Pascal, и QB64 поддерживаются и относительно активно развиваются, их последние релизы вышли в 2021 году… но в основном их игнорируют, потому что они представляют собой архаичные языки, которые в наши дни не интересуют большинство людей.

«Настоящие» современные консольные IDE

Итак, что же мы имеем на сегодняшний день для современных языков?

На сегодняшний день, похоже, актуальными являются Neovim ^[5], Doom Emacs ^[6] или даже Helix ^[7]. Эти редакторы очень мощные и, благодаря различным плагинам, предлагают разумные IDE-подобные возможности. Однако, как по мне, ни один из них не дает того опыта, который давали предыдущие продукты Borland: их интерфейсы непонятны, а из-за мультиязычности они «мастера на все руки, да путем ничего и не умеют», если хотите.

В любом случае, предпочтительным «простым» редактором TUI, основываясь на том, что я наблюдал в ненормальном обсуждении microsoft/terminal#16440, кажется… GNU Nano… который нормальный, он работает, но во-первых: это не IDE, и во-вторых, для меня это выглядит как WordStar. Да, я знаю, что это не WordStar: если вам нужен WordStar, то ближе всего к нему будет Joe, но внешний вид Nano напоминает мне о моем первом опыте работы с текстовым процессором во времена CP/M. Вот, смотрите:

Редактор GNU Nano в его стандартной настройке, с открытым пустым файлом.

Так что, несмотря на наличие мощных консольных редакторов в наши дни, они не дают того же опыта работы, что и 30 лет назад. На самом деле, кажется, что за эти 30 лет мы во многом регрессировали, и только сейчас достигли паритета с некоторыми функциями, которыми обладали раньше.

Естественно, что популярность TUI уменьшилась, как только графические ОС набрали обороты, и достаточно интересно, что они возвращаются только сейчас. Что касается причин, то я думаю, что мы должны благодарить изобретение LSP (Language Server Protocol) за большую часть недавнего прогресса в этой области. Редакторы TUI были «законсервированы» в течение многих лет, потому что создание функций IDE для них требовало много усилий, а их небольшая база сопровождающих не могла позволить себе их реализовать. LSP открыла доступ к существующим языковым интеграциям и вернула интерес к старым и надежным Vim и Emacs. Надеемся, что грядущий BSP сделает еще больше для того, чтобы эти TUI стали более похожими на IDE.

Зачем вообще нужны TUI IDE?

Справедливо будет спросить: «Да кого это волнует? На каждом настольном компьютере и ноутбуке теперь работает графическая ОС!»

И это хороший вопрос. В общем, вам, вероятно, не нужна текстовая IDE. Если вы предпочитаете VSCode, то его возможности удаленной работы превосходны, и VSCode имеет достаточно хороший графический интерфейс, не являясь полноценной IDE. Но есть несколько вещей, которых VSCode нам не дает.

Первое — это то, что TUI IDE отлично подходит для работы на удаленных машинах — даже лучше, чем VSCode. Вы можете с легкостью подключиться по SSH к любой машине и запустить IDE. Объедините это с tmux, и вы получите «полноценную» многозадачность. Да, вы можете использовать клиент удаленного рабочего стола вместо SSH, но я всегда находил это неудобным из-за задержек и неправильной интеграции с шорткатами локального декстопа.

Во-вторых, расширения удаленной работы VSCode не имеют открытого исходного кода, что не является большой проблемой… за исключением того факта, что они не работают, скажем, на FreeBSD, и нет способа это исправить. Таким образом, это делает невозможным удаленное подключение к моему основному серверу разработки с помощью VSCode.

И третье — это… снижение потребления ресурсов.

Раздутость повсюду

Я не могу уйти, не поразглагольствовав немного о «раздутости». Borland Turbo C++, со всеми его плюсами и минусами (пользовательский интерфейс, набор инструментов C++, интегрированные руководства...), занимает менее 9 МБ после установки и работает в пределах 640 Кб оперативной памяти.

Для сравнения, Helix занимает 16 Мб на диске, что довольно впечатляюще (и, честно говоря, неожиданно), а Doom Emacs — около 500 Мб и потребляет много Мб оперативной памяти. Заметьте, однако, что ни одно из этих чисел не учитывает инструментальных цепочек для языков или справочных систем, а они в наше время занимают гигабайты дискового пространства.

Чтобы получить «настоящую» IDE, мы должны перейти к графическим программам, таким как IntelliJ или VSCode. VSCode, например, занимает около 350 МБ на диске (на удивление меньше, чем Doom Emacs), но он съест ваш компьютер на обед: это же Electron, в конце концов. Отказавшись от VSCode и перейдя на Doom Emacs, я заметил очень большую экономию времени автономной работы ноутбука.

Итак, вопрос, на который я хочу ответить — сильно ли мы продвинулись за 30 лет? Современные IDE имеют несколько лучшие инструменты рефакторинга, лучшие возможности и поддерживают больше языков, но по сути… они не сильно изменились. Единственным существенным отличием, которое мы начинаем видеть, может быть программирование с помощью искусственного интеллекта, но это функция, предоставляемая в основном удаленным сервисом, а не локальным кодом!

И это все на сегодня. Со своей стороны, я с удовольствием продолжу использовать все Doom Emacs, Vim, VSCode и IntelliJ в зависимости от ситуации. Счастливого Рождества, если вы празднуете!

Мой канал с материалами про код, технологии и просто интересное: IT Insights ^[8].