Comments 181
сказать что я удивлен, не увидев turbo c/pascal от борланда под дос, ничего не сказать.
del
А также Microsoft QuickBASIC
сказать что я удивлен, не увидев turbo c/pascal от борланда под дос, ничего не сказать.
Это Вы ещё JPI TopSpeed не видели...
https://web.archive.org/web/20120111161303/http://www.nf-team.org/drmad/stuff/t.htm
Ещё в школе наткнулся на отличную русскоязычную справку в Турбо Паскале с гиперссылками и примерами, что сразу сподвигло изучать язык и программирование в частности даже за пределами преподаваемого на уроках. Думаю если бы не это, то я бы и не стал программистом.
Мне повезло еще больше. Я не наткнулся на русскоязычную справку в Турбо Паскале. Из-за это приходилось читать её на английском. Так я и выучил английский. В жизни очень пригодилось :)
Из-за это приходилось читать её на английском. Так я и выучил английский.
Для этого надо было, чтобы Паскаль соседствовал с каким-то переводчиком на компьютере, потому что в обычных бумажных словарях лексики не хватало. Русскоязычная справка действительно рулила. В моём случае это был Турбо Паскаль 5.5, когда электронных переводчиков вообще практически не было, только какие-то примитивные подстрочники, и то, фиг найдёшь дискетку на рынке.
У меня был только бумажный советский словарь. Слов не хватало, но догадаться из контекста было можно. Необходимость листать бумажные страницы в поисках нужного слова хорошо стимулировала память. Так по справке и примерам освоил Turbo Vision. А потом появился Delphi и все добытые в боях со словарем знания библиотек отправились на свалку истории, а английский язык остался.
У нас вроде был Фаронов. И это было ещё время бумажных книг (в аккурат 30 лет назад). Сам турбо-паскаль продавался в книжном магазине - в виде коробки с кучей установочных дискет.
Borland немалую толику своей популярности получил именно за обширную встроенную документацию в своих продуктах, которая на тот момент превосходила всех.
Согласен, и совсем странно не увидеть тут мощнейшую IDE проектирования баз данных - Clarion for Dos 2.1 (1989). Все проектирование - визуальное, даже поздний FoxPro не смог догнать.
Странная подборка. Есть какие-то рядовые IDE с нишевых платформ на момент выхода этих IDE, вроде Xcode или CodeWarrior. Зато нет IDE, совершивших, собственно, революцию в мире IDE:
Borland Turbo Pascal: собственно, вообще первая IDE, плюс, долгое время она задавала новые планки стандартов в IDE - встроенный отладчик, контекстная справка, средства удалённой отладки, UI-фреймворк и т.д.
Visual Basic (а не упомянутый VBA из Word и Excel, и не Visual Studio): первая IDE с визуальным редактором интерфейсов и компонентной моделью, которая в 1991-м году определила основные принципы построения IDE до сегодняшнего дня.
Еще была линейка VisualAge от IBM, с интеграцией с VCS и прочими прикольными штуками, в первую очередь VisualAge for Smalltalk.
Шикарный был проект. Даже как-то пришлось программировать на VisualAge для С++ под полумух (OS/2). Давал больше возможностей для визуального программирования невизуальной части, чем Delphi, но был существенно сложнее в использовании.
Жаль, что его больше нет с нами. Дольше всего продержался для Smalltalk.
Писал на VisualAge for Java 20+ лет назад. Это было что-то с чем-то конечно, но сейчас я бы на таком не стал писать.
Было. Они даже свои языки, родной средой для которых была их платформа AS/400, RPG и COBOL туда вывести.
Там даже PL/1 был и REXX )
PL/1 у IBM тогда вообще в почете был. Активно его пытались развивать, но где-то переборщили и оно под собственной тяжестью загнулось.
Хотя, тут где-то недавно вспоминали - обнаружили что в современном RPG достаточно много "отголосков" PL/1 (хотя изначально RPG вообще от табуляторов шел) в плане синтаксиса и идеологии.
«вообще первая IDE»
Алан Кей смотрит на вас с удивлением.
Ну это же Смоллтолк, это не совсем IDE. Это объектно-ориентированная ОС, предок Java VM.
Интересный у вас подход. Smalltalk — это в первую очередь философия разработки, а во вторую именно что интегрированная среда, в которой программа и ее среда разработки неразрывно связаны (хотя и отделимы).
Интегрированная среда разработки с контекстно-зависимым автодополнением и подсветкой синтаксиса, встроенный отладчик, система интроспекции и структурной навигации по коду, интегрированная же справка, собственно GUI, горячая замена методов, автоматизированные рефакторинги и многое другое, чего до сих пор нет в других языках. Не говоря уже про языковые фичи, которые тоже были впервые введены именно в Smalltalk, как например полиморфные интерфейсы с классами, итераторы, декораторы, TDD.
Да что говорить, вот например разворот журнала Byte за 81 год, где все можно прочитать самому. То что люди все это не поняли и забили на добрых двадцать лет, а потом изобрели заново, не делает это «вообще первым».
А то, что его интерфейс до сих пор можно запустить вместо ОС… ну это как минимум не хуже, чем «просто IDE». Предок JVM? Ну наверное, примерно как микроскоп можно назвать предком молотка.
Исторически первая ИДЕ, все же наверное Фортран-2 Ершова, или как там он назывался. 1979г. НГУ "underground" ..
полистал ниже .. где Рапира, Школьница? ТОР для Ямахи? Впрочем, последнее все же просто текстовый редактор, но .. хорош. Слишком.
CodeWarrior помимо прочего долго была основной IDE для встраиваемых систем Motorola/Freescale. Не удивлюсь, если в этом статусе она оказалась более знаковой, чем как IDE для маков.
Я бы сюда обязательно добавил бы FoxPro. Очень много было написано на нем
Второй или пятый?
А я бы тогда вспомнил бы Clarion под DOS.
Который сам умел генерировать законченный код и экранные формы для работы с описанной таблицей
Очень любопытный был продукт.
Сразу генерировал словари и структуру данных + базовые обёртки для них вместе с интерфейсом. Не выжил из-за совершенно дикого и особенного по структуре собственного языка. Некоторое время серьёзно конкурировал с Clipper. Clipper, как более традиционный и здорово расширяемый, вышел победителем, но потом не выдержал переноса в Windows и плавно ушел с арены.
Ну и если уж заводить речь про IDE времён DOS, то стоит упомянуть Multi Edit, который был хорошо приспособлен за счет расширений становиться полноценной IDE для кучи языков.
Сейчас не могу понять, как в режиме VGA50 я мог сидеть в в нём целые дни на 14' ЭЛТ мониторе!
Если и конкурировал, то с FoxPro.
Ничего сверх-нетрадиционного в ЯП Clarion нет.
Wiki вообще уверена, что это Modula-2 семейство ( не совсем)
Ничего сверх-нетрадиционного в ЯП Clarion нет.
Не совсем ЯП, но в среде есть.
В Clarion, еще с DOS v2.0:
- отдельно описание схемы базы данных
- UI с привязкой к элементам схемы.
Т.е. списки, формы, выпадающие списки не в воздухе, с ручным кодом, а с привязкой через UI к данным. При изменении настроек работы с данными, код менять не нужно было - авто-генерился.
Эта концепция добавила надежность в разработку - когда UI привязан к элементам данных, "сломать" такой код значительно сложнее.
Представьте что у вас соблюдается ссылочная целостность при связях UI и схемы.
Плюс, масса кода генерилась автоматом, с возможностью вставить свой в т.н. точки вставки. Т.е. авто-генеримый код перестраивался при изменении настроек приложения через UI.
После курсов в 1992, когда Арсис познакомил с Clarion под DOS, разработал на нем до 2004. Сейчас как раз в том городе, где офис Clarion (TopSpeed -> SoftVelocity) и размещался (Pompano Beach). Для меня было как-то классно остаться именно здесь.
С Clarion я работал плотно. Закупили у "Арсис" и CfD 2.X, и обновление до CDD 3.X
Выше ( не вы) писали, что Clarion a) не выжил b) и не выжил именно из-за встроенного в среду языка программирования.
На деле: жив, выходят новые версии и т.п. Соответственно, раз нет события, то нет и его причины.
Так же существует альтернативная реализация -- clarion2java
Выше ( не вы) писали, что Clarion a) не выжил b) и не выжил именно из-за встроенного в среду языка программирования.
Вот это сюрприз, не знал, что он жив. Мне казалось, что он исчез полностью. Подскажите, в какой глубинной нише он нынче обитает?
PS Может ещё и Progress где-то живёт?
- отдельно описание схемы базы данных
- UI с привязкой к элементам схемы.
Последние 6 лет работаю с AS/400. И вот там картина очень похожая. Есть т.н. DDS - Data Descriptions Specifications - фактически это некий язык описания схем данных. На нем можно описывать все - "физические файлы" (таблицы), "логические файлы" (что-то типа индексов, но мощнее т.к. там можно описывать и вычисляемые поля и допусловия и join-ы по нескольким таблицам), "дисплейные файлы" (экранные формы), "принтерные файлы" (форматированные отчеты для вывода на принтер)...
Таблица, например, выглядит так:
A R CPJPFR
A CPJCHK 10A TEXT('Название -
A проверки')
A COLHDG('Проверка')
A CPJPARM 10A TEXT('Название -
A параметра')
A COLHDG('Параметр')
A CPJVAL 100A TEXT('Настроечные -
A значения в формате -
A регулярных выражений')
A COLHDG('Настройка')
A CPJRCODE 7A TEXT('Код решения -
A соответствующий -
A непройденой проверке')
A COLHDG('Код решения')
A CPJULM 4A TEXT('Пользователь -
A последнего изменения')
A COLHDG('Пользователь')
A CPJTLM Z TEXT('Время -
A последнего изменения')
A COLHDG('Дата и время')R CPJPFR - имя формата записи (в одном файле может быть несколько разных форматов), дальше идут описания поле - имя, тип, описание, заголовок...
Описание индекса:
A UNIQUE
A R CPJPFR PFILE(CPJPF)
A K CPJCHK
A K CPJPARMИли так
A R ECHDPFR PFILE(ECHDPF)
A K ECHDLMRK
* список полностью загружен
A S ECHDRDY COMP(EQ 'Y')
* и не откатывался
A ECHDRLB COMP(EQ ' ')
S - select - допусловие для включение записей в индекс. В данном случае "включать в индес только те записи, у которых поле ECHDRDY = 'Y' и поле ECHDRLB не заполнено (пустое)"
Есть обратная операция - O - omit - не включать записи, удовлетворяющие заданным условиям.
Для экранных форм еще богаче:
A R CPJFMDB
A RTNCSRLOC(&ZHRFMT &ZHFLD)
A BLINK
A PUTOVR
A OVERLAY
A CHANGE(84)
A ZHFLD 10A H
A ZHRFMT 10A H
A 3 7'Проверка. . . . :'
A ZLCHK 10A O 3 26TEXT('Код проверки')
A OVRDTA
A ZLDSC 38A O 3 38TEXT('Описание проверки')
A OVRDTA
A 4 7'Параметр. . . . :'
A ZLPARM 10 O 4 26TEXT('Имя параметра')
A OVRDTA
A 6 7'Значение. . . . :'
A ZLVAL 100A B 6 26
A TEXT('Значение параметра')
A N03 68 COLOR(GRN)
A N03N68 COLOR(WHT)
AO 03N73 DSPATR(HI)
A 03 DSPATR(PC)
A 03 73 DSPATR(RI)
A 03 73 COLOR(RED)
A 68 DSPATR(PR)
A OVRDTA
A CHECK(LC)
A CNTFLD(50)
A 8 7'Код решения . . :'
A ZLRCOD 7 B 8 26
A TEXT('Код решения соотвествующий не-
A пройденной проверке')
A N04 68 COLOR(GRN)
A N04N68 COLOR(WHT)
AO 04N73 DSPATR(HI)
A 04 DSPATR(PC)
A 04 73 DSPATR(RI)
A 04 73 COLOR(RED)
A 68 DSPATR(PR)
A OVRDTA
A ZLRCDSC 38 O 8 38TEXT('Описание кода результата')
A OVRDTA
A 19 7'Пользователь изменения:'
A ZLULM 4A O 19 32TEXT('Пользователь изменения')
A OVRDTA
A ZLULMD 35A O 19 38TEXT('Пользователь изменения')
A OVRDTA
A 20 7'Время изменения. . . :'
A ZLTLM 26A O 20 32TEXT('Время изменения')
A OVRDTA04, 68, 73 - т.н. "индикаторы" - нумерованные логические переменные при помощи которых можно управлять внешним видом -
N04 68 - "индикатор 04 false, индикатор 68 true" - в этом случае текст будет зеленым.
N04N68 - оба false при этом текст белый.
Все что начинается с ZL.. - имена полей. Присваиваем им нужные значения, выводим форму на экран и получаем (write) и получаем вот такое:
То что зеленое - только для чтение. Белое - доступно для изменения. Выполняем read - система ждет когда пользователь заполнит поля доступные для ввода и нажмет Enter. После это возврат в программу и в переменных ZL... соотв. значения.
Возвращаясь к IDE. Для всего этого есть RDi - Rational Development for i фактически Eclipse с кучей специфических плагинов. В том числе и для визуального редактирования этих самых форм
с возможностью переключения на ручное редактирование кода формы
В целом можно только гадать - то ли Баррингтон подсмотрел у IBM идею, то ли все это просто "витало в воздухе" в те времена, но на мой взгляд очень похоже. Язык описания данных, описание экранных форм которые не надо рисовать в рантайме, а можно просто работать с ними как с файлом...
ктулху можно вызвать, читая эти скриншоты!
Последние 6 лет работаю с AS/400
Видел такую систему, когда в начале нулевых работал в ПФР. Она там ещё живая? Или Вы её ещё где-то используете до сих пор?
А почему «до сих пор», IBM продолжает выпускать свои мейнфреймы. Да, это нишевые системы, встретишь их не часто, но прекрасно работают, держат требуемую нагрузку. Большая, мощная СУБД. Это, конечно, «другой мир», но тоже интересный.
Поработать с ними не было случая, но в банках стоят, и думаю, что до прошлого года вполне себе обновлялись.
Просто она относится к редкому вымирающему виду, обслуживать и содержать котрый стоит адских денег, но слезать с него ещё дороже. Примерно, как легендарный COBOL. )
В банках мне не довелось увидеть. Стало интересно, в каких сферах это используется сегодня.
Она отнюдь не вымирающий вид. Вполне себе развивающаяся система. Просто нишевая. Нов своей нише очень производительная, очень надежная.
https://www.itjungle.com/2023/03/22/ibm-i-has-a-future-if-kept-up-to-date-idc-says/
https://www.openlegacy.com/blog/ibm-application-modernization
В целом ориентирована на ситуации, когда параллельно работает большое количество заданий (JOB) и все это работает с БД (БД - DB2 for i) там интегрирована непосредственно в систему (можно даже сказать что система вокруг БД построена).
Сама система построена так, что накладные расходы на переключение контекста заданий практически сведены к нулю.
Основной язык - RPG. Хотя поддерживается ("из коробки") - COBOL, C/C++ ну и конечно системный CL (Commayl Language) который тоже компилируемый, с возможность объявления типизированных переменных.
Все это объединено в концепцию ILE - Integrated Language Environment - можно написать кусок кода на С, кусок на RPG и объединить в один программный объект (что-то типа LLVM).
Более 80% кода в этой системе написано на RPG - удобный язык для реализации всякой бизнес-логики. Тут и работа с датой-временем и нативная поддержка форматов с фиксированной точкой (и операции всякие типа "присвоение с округлением"). Мощные средства работы со строками, очень гибкие возможности описания сложных структур данных. То, что в том же C придется делать путем кучи union'ов, тут делается намного проще.
Короче, тут можно бесконечно долго рассказывать :-)
Ну вот как пример чем нравится RPG.
Есть у нас достаточно распространенная задача преобразования формата даты например из *ISO - YYYY-MM-DD в *CYMD - CYYMMDD где C - признак столетия (0 - 20-й век, 1 - 21-й век). Т.е. дата 2023-08-02 будет выглядеть как 1230802. Ну так у нас хранятся даты в наше АБС (не знаю почему, но так принято).
Входная дата - строка. Выходная - число типа zoned(7:0) (это такой формат с фиксированной точкой - 7 знаков, 0 после запятой).
Можно использовать стандартные средства языка - преобразовать строку в дату, а потом дату в число уже в другом формате. Но это не очень эффективно там, где плотность вызовов такого преобразования велика. Можно сделать проще (используя особенности формата zoned и используемой на IBM i русской кодировки EBCDIC 1025
Описываем структуры данных, которые будем использовать в качестве шаблонов для входных и выходных форматов
dcl-ds dsCYMD qualified;
cent int(3);
YY char(2);
MM char(2);
DD char(2);
CYMD zoned(7: 0) pos(1) inz(0);
end-ds;
dcl-ds dsISO qualified;
CC1 int(3); // первый символ столетия - 1 байт
*n char(1); // второй символ столетия (не интересует тут)
YY char(2);
*n char(1); // разделитель
MM char(2);
*n char(1); // разделитель
DD char(2);
dte char(10) pos(1);
end-ds;Здесь *n - неименованное поле (нам оно не нужно для работы). То, что в С обычно обозначается как dummy, reserved, tmp и т.д.
pos (для CYMD в первой структуре и dte во второй) - позиция поля внутри структуры. Фактически, эти поля перекрывают все остальное (типа union в С, но гибче - перекрытие может быть частичным, например, третье поле может перекрывать вторую половину первого и первую половину второго).
Строго говоря, можно и без неименованных переменных обойтись, просто позиционированием:
dcl-ds dsISO qualified;
CC1 int(3); // первый символ столетия - 1 байт
YY char(2) pos(3);
MM char(2) pos(6);
DD char(2) pos(9);
dte char(10) pos(1);
end-ds;а дальше "преобразование", которое сводится к
dsISO.dte = dte;
dsCYMD.cent = dsISO.CC1 - 1;
// остальное просто переносим
eval-corr dsCYMD = dsISO;
rslt = dsCYMD.CYMD;
Заносим полученную на вход строку dte в шаблон в поле dte.
признак столетия у нас 2 или 1 - вычитаем 1 получаем 1 или 0 - результат заносим в выходной шаблон.
Операция eval-corr - присвоение значений полей одной структуры полям с такими же именами второй структуры. Т.е. короткая запись для
dsCYMD.YY = dsISO.YY;
dsCYMD.MM = dsISO.YY;
dsCYMD.DD = dsISO.DD;когда полей несколько десятков это короче и удобнее.
Ну и заносим в возвращаемый результат то, что у нас лежит в выходном шаблоне в поле CYMD. Все!
Трюк основан на то, что формат zoned положительные числа хранит в памяти как F в старшем полубайте и цифра с младшем. Т.е. 1230802 в памяти лежит как F1 F2 F3 F0 F8 F0 F2. Но! в нашей кодировке цифры 0..9 имеют коды F0..F9. Т.е. положительное zoned число 1230802 и строка '1230802' в памяти лежат абсолютно одинаково. Что и позволяет совершать такие вот трюки...
Понятно, что данный конкретный случай можно и на С сделать примерно также, но структуры бывают достаточно сложные, со многими перекрытиями, иногда частичными, когда одно поле перекрывает два куска двух других соседних полей... И вот там очень не хватает в С возможности явно указывать смещение поля от начала структуры (в битовых полях это есть, а в обычных нет).
А еще есть перекрытие для элементов массивов - overlay В С для этого придется описывать отдельную структуру + union и делать массив union'ов...
Вообще, так сложилось, что тут всю сложную бизнес-логику пишем на RPG, а если надо что-то низкоуровневое - С/С++ И все это прекрасно собирается в одну программу.
То есть вы вместо использования стандартной функции преобразования даты пишете вот такое каждый раз и считаете это нормальным?
На самом деле это должен был быть пример того чем не нравится RPG. Я не понимаю почему вы это записываете в плюс.
Кроме того, тут видна проблема ещё и в экосистеме в целом. Ну не должно быть в нормальной системе такого формата даты как CYYMMDD.
То есть вы вместо использования стандартной функции преобразования даты пишете вот такое каждый раз и считаете это нормальным?
Не везде. Там, где требуется высокая эффективность. Стандартные функции работы с датами больше грузят процессор и занимают больше времени.
В тех ситуациях, когда такие преобразования выполняются 100500 раз на вызов приходится думать о том, как сделать все быстрее.
Для нас вообще совершенно нормально решать задачи, связанные с достаточно сложной обработкой десятков и сотен миллионов записей. И каждая поставка обязательно проходит нагрузочное тестирование через Performance Explorer. Поэтому да - если нужно один раз что-то сконвертировать, проще использовать стандарт. Но когда все это носит массовый характер - такие подходы часто позволяют сэкономить 3-5% процессорного времени.
И тут нужно понимать, что ваша задача будет работать параллельно с еще десятком тысяч других. И неэффективно реализованный код может начать тормозить другие процессы. Вплоть до инцидентов когда, например, в период пиковой нагрузки (когда утилицация процессора превышает 90%) люди вдруг не могу в магазине расплатиться картой - "нет ответа от банка". Или ппрохождение платежей (а их у нас может сотня миллионов в стуки идти) начинает тормозить потому что тормозят проверки контроля платежей система расчетов.
Или вот такое от сопровождения прилетает:
Коллеги, сервис *** за последние 5 недель увеличил потребление процессорных ресурсов в 3 раза!!!
Он уже является 2-м по величине сервисом после *****.
В качестве альтернативы мы рассматриваем перенос запуска сервиса на резервный сервер, но там есть лаг по отставанию до 10 мин.
Заказчикам сервиса это может не понравиться :(
Речь в данном случае о сервисе комплаенс-проверок клиента. Весьма востребованный сервис с крайне высокой плотностью вызовов.
Короче говоря, hiload наложенный на mission critical имеет свои особенности и свои требования. И часто приходится прибегать к нестандартным решениям радо достижения предельной эффективности.
Подавляющее большинство решений тут выстрадано. И есть куча нефункциональных требований что можно а что нельзя.
Например, мы не используем (практически) динамический SQL (да, RPG позволяет включать SQL в RPG код) когда запрос стоится в рантайме - такой подход тащит за собой существенные накладные расходы на построение плата запроса в рантайме при каждом вызове. Только статика, где план запроса строится в compile time. Хотя порой это бывает не очень удобно.
Мы стараемся избегать использования group by вкупе с агрегатными функциями - SQL тут не всегда хорош, быстрее и эффективнее (в разы! - подтверждено многочисленными замерами PEX статистики) сделать избыточны, но линейный запрос, а всю группировку и агрегирование организовать уже в процессе потоковой обработки результата.
Тут много всяких тонкостей и хитростей. И эффективность всегда ставится впереди скорости разработки и удобства разработчика.
Не всем это нравится (кому-то более по душе механически ляпать приложения из готовых кирпичиков-фреймворков), но так есть.
Кроме того, тут видна проблема ещё и в экосистеме в целом. Ну не должно быть в нормальной системе такого формата даты как CYYMMDD.
А чем он хуже любого другого? Только тем, что непривычен?
Хранить дату в виде строки - плохая идея с точки зрения эффективности поисков, сравнений и т.п.
Перегонять строку YYYY-MM-DD в число YYYYMMDD - ну тоже самое что и в CYYMMDD.
Хранить в виде даты? Там тоже свои минусы в других местах вылезут...
Погодите, у вас CYYMMDD — это число, а не строка? То есть язык позволяет неявно преобразовать строку в число, и вы ещё утверждаете что заботитесь о производительности?! Да что с этим миром не так?..
Не язык позволяет, а на данной платформе есть формат чисел с фиксированной точкой, который для положительных чисел в памяти совпадает со строковым представлением. Есть и другой формат (тоже с фиксированной точкой), который не совпадает.
От языка все это не зависит совсем. Все тоже самое можно и на С написать. С тем же результатом.
И да. Высокая производительность достигается именно тогда, когда вы знает как оно устроено внутри и как работает. А не просто тупо лепишь готовые конструкции.
Как мне говорил один "разработчик" с позволения сказать, на прошлой работе - "это невозможно потому что в используемом нами фреймворке такого нет. Пришлось ткнуть носом с системные API и показать как желается средствами системных API.
Не везде. Там, где требуется высокая эффективность. Стандартные функции работы с датами больше грузят процессор и занимают больше времени.
Так а в чём высокая эффективность-то? Вы же используете zoned числа, которые сами по себе на низком уровне вообще не числа, а тоже сложная структура, как и строки, и имеют те же проблемы с производительностью. Если бы вы работали не на AS/400, а практически на любой РС-платформе, дата/время у вас были бы обычным числом, хранилось бы в СУБД также в числовом формате, любые операции также выполнялись с помощью числовой арифметики, и вы вообще бы не сталкивались с этой проблемой.
Короче говоря, hiload наложенный на mission critical имеет свои особенности и свои требования.
Ну вот поэтому это тупиковый путь. Вы страдаете и делаете всякие выкрутасы, чтобы упаковать все ваши бизнес-требования в ограниченные возможности одного дорогущего чёрного шкафа, в то время как в другом мире просто поставят ещё пару копеечных юнитов в стойку (это если данные business-critical, и их обработку нельзя чужому облаку делегировать).
Это не мейнфреймы. Мейнфремы у IBM - платформа IBM z. Которая "выросла" из System/370
IBM i - middleware. Выросла из System/38, далее AS/400. Изначально задумывалась как платформа для малого и среднего бизнеса. Но получилась настолько удачной и масштабируемой, что сейчас и в крупном бизнесе успешно используется.
Сейчас сделали новый проц Power10. Там вообще возможность объединять много процессоров в кластер высокопроизводительной шиной, причем, контроллер шины интегрирован в кристалл. Т.е. фактически просто процессоры стыкуются между собой. И могут использовать все ресурсы, включая опреративную память, совместно.
Т.е. очень легко масштабируется - купили 5 машинок сцепили между собой - получили одну фактически, потребовалось мощность нарастить - купили еще 3 машинки - подцепили и мощность вашего "сервера" выросла.
Т.е. очень легко масштабируется - купили 5 машинок сцепили между собой - получили одну фактически
А вы ничего не преувеличиваете? Я-то уже давно не работаю с AS/400, и новинками не интересовался, но чисто физика против этого. Для памяти DDR5, например, за один такт свет проходит примерно 5-15 сантиметров, в зависимости от частоты. Ну т.е. сделать общее виртуальное ОЗУ технически-то всегда можно, но если процессор одной машины будет пытаться напрямую работать с ОЗУ другой машины, через какой-то кабель и преобразователи, латентность там будет огромная, и в реальной работе нужно будет такие операции во-первых, выявлять, во-вторых, ограничивать только для случаев крайней необходимости.
Поэтому такая архитектура может иметь смысл только если процессоры стоят в одной машине и очень желательно, на одной плате.
Лет двадцать назад встречался с подобной штукой на обычной x86 архитектуре - два физических сервера в стойке от того же IBM объединялись специальным кабелем, после чего операционка это видела как одну SMP систему. Понятно, что NUMA эффекты типа большей latency при обращении к "чужой" памяти были, но в принципе оно работало, при разумном разделении по данным код вполне параллелился.
Она не просто "до сих пор" используется, но и вполне себе развивается. Про ПФР слышал. Слышал, что где-то на РЖД есть машинки. В банках (у нас в Альфе, в Райфе, в Росбанке точно, может еще где есть).
Сейчас, кстати, оно называется IBM i (есть еще IBM z - это уже мейнфремы которые выросли из System/370).
На LinkedIn есть несколько групп тематических, на SO есть теги #rpg (это не про игры, как раз про язык RPG), #rpgle (современная версия RPG интегрированная в концепцию ILE), #ibm-midrange... Ну и так ресурсов хватает англоязычных.
Система нишевая, но свою долю рынка имеет.
Мы сейчас сидим на Power9 и версии 7.4. Но уже есть Power10 (говорят, что теоретически возможно купить хоть и не так просто) и версия 7.5.
В целом, мощно, надежно, интересно т.к. ни на что не похоже - совсем иные концепции заложены.
Про Emacs упомянуто только то, что это менее распостраненная альтернатива Vim-у. Ну-ну.
А прообразом всех VSCode и JetBrains был замечательный Multi Edit
Что запомнил эпохального со времен ДОС:
1) для бизнеса FoxPro - IDE и среда исполнения в одном флаконе. Визуальный оконный интерфейс, окна, гриды - все это влазило на дискетку и быстро работало. После dbase, clipper просто космос. Но должен признать, что видел очень много учетного ПО написанного на клиппере.
2) IDE Borland Turbo (pascal,c/c++) + Turbo Vision. Все что было позже - лишь повторение и улучшение. Еще был компилятор Turbo Basic.
3) IDE типа Microsoft Quick C были, но на фоне Борланда терялись.
Очень много ПО, особенно игры было написано на Watcom C, но в наших краях на нем мало кто писал. IDE у него было, корявенькое на фоне борланда, но рабочее.
Windows
4) Microsoft Visual Basic, Visual Fox Pro, Visual C
5) Borland Delphi/Builder - это лучшее что было.
Borland Delphi/Builder - это лучшее что было.
Ну до сих пор есть RAD Studio
Для визуальной разработки интерфейсов очень неплохо даже
Делфи и RAD есть еще в виде Lazarus https://www.lazarus-ide.org/
и конечно Free Pascal https://www.freepascal.org/
И всякие дико прожорливые:
"Кути" типа QT Creator и вся их ветка.
И Android Studio и т.п.
2) IDE Borland Turbo (pascal,c/c++) + Turbo Vision. Все что было позже - лишь повторение и улучшение. Еще был компилятор Turbo Basic.
Turbo Prolog :)
"В старину при написании кода вы видели лишь чёрный текст на белом фоне" - ну да, ну да.
Могли бы свежую версию IDE от наследника Borland показать
Только автодополнение, автозавершение, сниппеты, ... Чтоб он предсказывал что ты напишешь - нет. Такого пока нет. Если речь о copilot или его аналогах. Сделали бы, если б ChatGPT отвечал быстро, а не через 20 секунд. Помощник такой уже есть. Может найти ошибку, сгенерировать, исправить или конвертировать код. Ну или объяснить. (вот тут)
Автоформатирования тоже нет (если честно, в VS оно меня раздражает немного, но это личное). Есть ручное, сочетанием клавиш (удобно, не навящиво). Да и многие, закостенелые даже этим не пользуются.
Но сделать всё это можно, если захотеть. Достаточно написать пакет, расширяющий функционал (по сути обычный пакет как и все). Была бы у меня нужда, сделал бы. У среды есть документированное API с доступом почти куда угодно (редактор, LSP, окна, меню и т.д.)
Вот, например, я делал монитор как в VS. Делов на 2 часа
Скрин
Автоформатирование есть и уже довольно давно. Вызывается по Ctrl+D. Под него куча настроек.
Это не автоформатирование, это просто форматирование, о котором я тоже упомянул. Автоформатирование - это когда редактор каждый раз форматирует код при его изменении. Откройте visual studio и посмотрите, как это работает с шарпом
А-а-а, это. И хорошо, что нет. В Visual Studio дико раздражает. Намного удобнее написать код, а потом вручную отформатировать. Привык так в Delphi и в MPLAB X IDE (вроде на базе NetBeans сделана).
В Visual Studio дико раздражает.
Оно ж там тоже вручную форматирует, по Ctrl+K + D. Или вы по VS Code?
Именно VC, оно форматирует при вводе закрывающей фигурной скобки или точки с запятой. Впрочем, форматирует не слишком агрессивно и раздражает только при попытках в табличное форматирование.
Вот кто и правда раздражает — так это Rider. Мало того что ультимативно перехреначивает код под свой собственный стиль — так ещё и любит "вытянуть" сложный запрос по вертикали вдоль правой границы текста.
А разве не Джетбрайн со своим агрессивным форматированием, проверкой синтаксиса, в т.ч. и неймингов? Особенно в Го..
Rider — он же как раз от Jetbrains.
Что же до Го — это и вовсе особенный мир, в котором форматирование встраивается не в IDE, а чуть ли не в компилятор.
Был такой замечательный язык/среда Clarion, для БД. Сам не работал, но люди рядом работали и очень хвалили. Первая (видимо) система визуального программирования, это потом уже появился Visual Basic.
Вот здесь обзорная статья:
https://habr.com/ru/articles/555246/
Так пользуйтесь Delphi. Приложения позволяет создавать в том числе и под мобильные устройства и официально есть бесплатная версия - Community Edition. А и там дженерики появились.
Ну или Lazarus - по мотивам Delphi 7, кроссплатформено.
Инлайн объявление, выведение типов, анонимки, таски, for in, for var in. В новой версии ожидаются мультистроки в редакторе. Кучу всякого доставили
Жаль что никак не избавятся от багов в C++ Builder
А что там за баги? У нас были проблемы с многопоточностью. Вы какой версией пользуетесь? Ощущение, что 6-я версия живее всех живых.
Судя по обзору новой версии (от декабря 21 года), чего-то существенно нового/важного не появилось.
https://habr.com/ru/articles/597353/
Да много чего было. Например приложение и IDE зависали намертво из-за потери соединения между ними.
до сих пор пишем на работе на шестом билдере, с виду кажется старым и неуклюжим (что неверно), зато невероятно прост и умеет всё, кроме разве что сборки под мобилки
К сожалению баги были и не только с threads.
https://habr.com/ru/articles/217189/
Как дела обстоят в Embarcadero на данный момент не знаю, успешно портировался на gcc.
Ну, строго говоря, Builder - адаптация Delphi под С++. И версии Builder отставали (в те времена, когда имел дело с ним) на одну от версий Delphi. Т.е. сначала делали Delphi, потом уже переносили все это в Builder.
Но баги там были. Как-то напоролся в каких-то объектах VCL на то, что там индексация не с 0 как в С++, а с 1 как в Паскале. Т.е. забыли адаптировать. В каком именно месте не помню уже сейчас - лет 6 прошло с тех пор как на другую систему ушел.
Вообще, насколько помню, там в С-шной версии VCL куча чего бала на Паскале. И можно было паскалевские dcu к сишным проектам цеплять.
А так борландовский компилятор нравился.. Во-первых, при использовании статических библиотек он умел выдергивать из них только те модули, которые реально нужны. С тем же gcc у меня такое не получалось (может, просто не умею).
Кроме того, это единственный компилятор (из тех, с которыми приходилось работать), который реально поддерживает long double (10 байт). У остальных long double типа понимает, но по факту - тот же 8-байтовый double.
Так что в целом воспоминания о нем достаточно позитивные остались.
В Паскале нет индексации с 1, кроме как в строках.
Суть в том, что в классическом Паскале индексация в массивах всегда явно определяется пользователем. Там действительно понятие "индексация с 1" отсутствует как класс.
В паскале статические массивы могут иметь совершенно разные индексы.
1. Любой диапазон (целочисленный) array[-100..100] of ...
2. Перечисляемый тип. array[Boolean] of ..., array[TDayOfWeek] of ...
А динамические массивы всегда с 0.
Это опция, а не правило Паскаля.
В Паскле вообще индексы могут быть енумами.
type
TEnum = (V1, V2, V3, V4, V5);
TMyArr = array[TEnum] of Byte;
begin
var Arr: TMyArr;
Arr[TEnum.V1] := 1;
Arr[TEnum.V2] := 2;
Arr[TEnum.V3] := 3;
Arr[TEnum.V4] := 4;
Но это не значит, что в Паскале индексация массивов - это енумы, верно?
Обычные, динамические массивы начинаются с 0. Вот это - правило
GNU/Emacs как всегда не существует. Уже почти 40 лет с момента создания и до v29.1 вышедшей на днях не существует. И да, дальше можно писать, что "это не ide, а редактор такой, а мы здесь про настоящие ide" или вообще, что даже не редактор, а мы не поняли что это. Ну хоть про vim в статье вспомнили :) Успешного вам программирования в Microsoft Word!
GNU/Emacs как всегда не существует.
Здесь была статья не "справочник всех существующих IDE", а всего лишь описание некоторых IDE, которые, по мнению автора, оказали существенное влияние на подходы к разработке софта. Почему бы в этот список включать Emacs, который абсолютно справедливо как инструмент разработки не был инновационным, не понятно.
Вот как раз Emacs (правда, не GNU/Emacs, а оригинальный) в 70-х был революционным. Точнее так: он был одним из нового поколения редакторов кода, которые наконец-то позволяли просто набирать символы в том месте, где он должны были появляться, и при этом они появлялись сразу после нажатия. Один из - но самый известный и до сих пор живой.
Я поработал, правда, только в формате институской лабораторной на старом терминале с более древним редактором. Каждая строчка кода добавляется отдельной командой. Посмотреть, что в результате получилось, можно только выполнив другую команду. Можно заменить любую строчку новой, а вот вставить новую между, скажем, 3-й и 4-й (чтобы новая стала 4-й, а та сместилась на 5-ю) - уже нельзя. Поэтому между каждой строчкой с рабочим кодом напихивалось 2-3 nop-а, на случай, если на их место понадобится что-то ещё вписать.
То ещё удовольствие. Просто редактор "жмёшь кнопки - видишь буквы" - уже революция после тех терминальных штук.
Каждая строчка кода добавляется отдельной командой. Посмотреть, что в результате получилось, можно только выполнив другую команду.
Бейсик на 8битных компьютерах практически всегда так работал.
и не только на 8битных
Вот Бейсик на 8битках, это же была IDE по-совместительсву ОС. И как по мне, эта концепция ось-ide была довольно уютной.
Уже вспомнили лисп машины и Smalltalk, где эта концепция в те же времена была ещё и полнофункциональной с нормальными редактором/дебаггером и т.д. А так ввести сразу после включения компьютера 10 PRINT 2+2 конечно удобно, но что-то потяжелее набирать по строчкам так себе - Turbo Basic с нормальным редактором кода после этого казался чудом )
Был БК0010-01, но тамошние нюансы уже стёрлись из памяти. Помню только команду REN, которая переименовывала все строки с шагом 10, именно чтобы промежуточные типа 15-25-35 втискивать.
Подозреваю, что это был ed или какая-то из его модификаций (а в ранних версиях MS-DOS его аналог назывался edln). Да, по сравнению с таким даже vi был гигантским прыжком вперед.
А где интегрированные среды Лисп-машин - это же мать всех этих сред?
Статья про IDE без паскаля смотрится весьма странно.
А где Paradox, JBuilder, QBasic?
JBuilder для первого выпуска был на уровне Delphi, dbSwing позволяли делать UI с работой БД не намного хуже Delphi. И в 97-м году Wizards позволяли быстро делать стартовое приложение. Сейчас он мутировал в Oracle JDeveloper.
Нет ни одного IDE для ассемблера, Tasm и т.п. это тоже был прорыв.
Статья оставляет впечатление что составлен список IDE, которые повлияли на развитие ПО автора статьи.
Немножко все в кучу смешали.
На мой взгляд тут два направления
IDE, входящее в состав какого-то продукта и заточенная исключительно под этот продукт. Со времен DOS - продукты линейки Turbo от Borland - Basic, Pascal, C, C++ - все они включали в себя то, что сейчас принято называть IDE. Но оно было заточено и плотно интегрировано с конкретным компилятором.
Туда же - Clarion, FoxPro и иже с ними.
Аналогично линейка Quick от MS
Позже, Под Win - Delphi/CBuilderIDE, которые настраивались под любой язык/компилятор. Первая ласточка - MultiEdit. Далее - Eclipse, VSC, vim, emacs...
Тут IDE само себе самостоятельный продукт с возможностью подключения плагинов для интеграции с нужными языками - синтаксис, линтеры, системы сборки, отладчики и т.п.
Это все-таки разные направления и разные концепции.
Первая ласточка - MultiEdit. Далее - Eclipse, VSC, vim, emacs...
Всё же первый в этом списке Emacs. Multiedit появился позже.
Я бы выделил третье направление: ИДЕ + ОС или частично. Интеграция средств разработки с элементами сборки, запуска, отладки, линковки .. Тут, кмк, порядок все же такой:
Фортран-2 Ершова (1979, когда работал с ним, но оно раньше)
Смалталк
Рапира, Школьница
Как vim удалось выжить, учитывая множество появившихся за эти годы современных IDE? На мой скромный взгляд, потому что он не навешивет на Ваш исходник кучу скрытых от разработчика непрозрачных прослоек, сильно тормозащих написанное ПО.
Тоесть концепт многих современных IDE, это популярно говоря ультимативный "java-стайл", когда независимо от Вашего желания в угоду преносимости кода фатально снижается его производительность. Отсюда и довольно типичный результат, когда для того же самого функционала системные требования ПО растут, с годами, в десятки раз.
Особенно чувствителен эффект "современных IDE" во встроенном ПО микроконтроллеров, причем если к Arduino-IDE, заточенной под первоначальное вхождение, претензий нет, то к STM-овской Cube-IDE, предназначенной вроде как не только начинающим, вопросы уже есть.
Не думаю, что я что-то путаю фраза звучит "Как vim удалось выжить, учитывая множество появившихся за эти годы современных IDE?". Что же касается "Cube-IDE", "Arduino-IDE", то эту устоявшуюся классификацию и терминологию, как вы понимаете не я сегодня изобрел. А вопрос мой "Cube-IDE" сводится к тому, что эта официальная вендорская IDE заточена лишь под "java-стайл". Иной стиль написания программ в ней не назовешь удобным и практичным.
Не только в угоду переносимости, еще в угоду скорости разработки и простоты поддержки/расширения этого кода.Там, где снижение производительности фатально - там подобные языки/фреймворки не используются. Во многих случаях это не фатально.
Там куча аспектов - абстракции (которых может быть много уровней), универсальность (когда используются некие "усредненные" алгоритмы, дающие наилучший результат на широком спектре структур данных, но проигрывающие в случае какой-то конкретной структуре специализированным алгоритмам) или когда определение в рантайме "а с чем же мы сейчас работаем" привносит некоторый оверхед, "безопасность" - специально дать разработчику затупленный нож чтобы не дай бог не порезался...
В среднем это не сильно заметно до тех пор, пока не встает вопрос о предельной эффективности.
Но все это относится в первую очередь к фреймворкам, но не к IDE, которые по сути есть текстовые редакторы со специфическими возможностями и расширениями.
Строго по определению IDE — это интегрированная среда разработки, (integrated development environment). Она может быть минималистичной, а может включать в свой состав фремворки и прочие средства разработки ПО.
Про "Не только в угоду переносимости, еще в угоду скорости разработки и простоты поддержки/расширения этого кода" благодарю за развитие мысли. Это тоже ультимативный "java-стайл". Другой вопрос, java-стайл, несмотря на ряд его достоинств далеко не универсален.
Под словом "integrated" всё же обычно понимают интеграции с компилятором, отладчиком, гитом, облачными хостингами — всё то что используется в процессе разработки ПО.
Фреймворки и библиотеки никогда частью IDE не являлись, как и средствами разработки.
Для некоторых фреймворков таки делаются заточенные под них инструменты. Например, QTCreator, wxFormBuilder...
Да, но это всё равно инструмент для фреймворка, а не фреймворк как часть инструмента.
Писать программу использующую QT можно хоть в QTCreator, хоть в Visual Studio, хоть в vim.
И я несколько сомневаюсь, что в QTCreator так уж невозможно написать программу, которая QT не использует.
Несколько не соглашусь. Вот тот же Delphi - он же не с гитом интегрировался, а с визуальным редактором для VCL - а ведь это фрэймворк.
Все же IDE - это немножко больше, чем текстовый редактор с расширениями.
А я с вами не соглашусь.
1. Delphi (RAD Studio), интегрирован и с гитом. Да, там есть инструменты для работы с контролем версий из коробки.
Ещё там есть даже возможности визуального проектирования классов (диаграммы)
VCL в среде интегрирован снаружи (с помощью пакетов), а не изнутри среды как часть среды. Из коробки, да. И частично интегрирован и изнутри (но это не точно), возможно убрав пакеты страницы в общих настройках тоже просто исчезнут.
Фреймворк можно интегрировать в любой момент на достаточно глубоком уровне. Например, есть фреймворк FGX, который предоставляет очень большие возможности при работе со средой. Там своя большая экосистема (ссылка).
Как и сам FMX, который из коробки встраивает свой собственный дизайнер. А ведь есть и много других фреймворков с интеграцией (UniGUI, TMS Web Core и другие). И все они наполняют среду в момент работы с проектом своим инструментарием (не говоря уже о компонентах).
По сути, RAD Studio может заменить QtCreator, если написать расширение для него. Интегрировать в настройки в рантайм (в рантайм IDE). И так далее.
И для этого даже не надо согласовывать с разработчиками среды. IDE имеет большое API.
А когда в Дельфи появились инструменты для работы с контролем версий из коробки? Кажется, уже после заката популярности.
Если верить docwiki, то в 2016 всего лишь. Да и в целом, большая часть инструментов появилась после 2010 года.
Я в википедии нашел Subversion в 2010 году ( https://en.wikipedia.org/wiki/History_of_Delphi_(software) ) . При том, что я что-то там писал на Дельфи 7 в 2002-2003 годах, и вот тогда Дельфи - это было круто. Так что я все еще остаюсь при своем мнении, что IDE вполне могут включать в себя фреймворки и инструменты для работы с ними.
А когда в Дельфи появились инструменты для работы с контролем версий из коробки?
Ну как бы "из коробки" - не особо-то и принципиально. У Delphi ещё более двадцати лет назад был Devrace Athlant, который стоил недорого, интегрировался с разными системами контроля версий, делал это прозрачно и прямо из окна проекта, когда сие вообще не было мейнстримом в других системах.
Quick Basic незаслуженно забыл
а кто помнит Komodo professional?
Ни приоритеты ни логика не ясны. На первых местах стоят не прорывные, а просто "неплохие" технологии которые всплыли когда звёзды сошлись. По-моему так быть не должно.
Как должен выглядеть список по моему мнению:
Turbo Pascal - потому, что был первой массовой IDE в которой был интегрирован цикл разработки: Typing - Compiling - Running - Debugging.
Visual Studio Code - потому, что первый кто имплеменитировал LSP (Language Server Protocol): дав возможность разделить написание языкового сервера от фронтэнда-IDE-редактора.
Borland Delphi - первый качественный IDE, органически расширяемый компонентами с оконным фреймворком. Всё по отдельности было до. Но соединено вместе и такой высокой планкой качества было впервые в Delphi (в 1999 MS Visual Studio в подмётки не годилось Borland Delpi). RIP Delphi - ты не смог приспособиться к написанию больших программ.
MS Visual Studio (или 5?) - до C# был массовой, но плохой IDE. Потом стал массовой и хорошей.
Eclipse (или 4?) - за то, что был долгое время (пока MS Visual Studio балду пинало "мы так видим разработку") был передовым тулом "как хорошо бы делать IDE".
IntellyJ Idea - за то, что сейчас наверное лучший IDE tool-chain.
[g]vim / emacs - утешительный приз за хорошую попытку собрать open-source IDE с плагинами. К сожалению до LSP дело не дошло.
Ваш список неверен. Я пробовал все IDE из этого списка ;) И я уверен, что многое великое здесь пропущено просто по той причине, что не может такого быть, чтобы я знал все "революционные IDE, повлиявшие на разработку ПО". Тот же Smalltalk, упомянутый в статье, появился до моего рождения.
И уж точно не Visual Studio Code записывать в революционные. LSP - эволюционная фича, логичное развитие идей Eclipse.
1. Smalltalk-80 system browser (https://www.youtube.com/watch?v=JLPiMl8XUKU) - дейтсвительно выглядит как полноценная IDE. Если там была возможность просмотреть весь исходный код как исходники - её следует поставить на 1е место, а turbo-pascal перенести в 4 или ниже. С одним примечанием: в таких технологиях (ещё forth сюда же) - просто должны быть фатальные недостатки по которым они не взлетели. Такие рекламные ролики такие недостатки не показывают, неплохо бы понять их.
1.1 Например могу ли я - написать программу в виде текста (от и до), запустить её и отдебажить? Или эта система позволяла использовать только приложения, без полноценного цикла написания...отладки для всех остальных?
2 Разница между LSP + VSCode (первая его имплементация) vs Eclipse - в том, что в Eclipse не было языкового сервера, доступного другим фронтэндам (IDE-редакторам), а в LSP + VSCode был. Несомненно революция несомненно 2 место - сразу полсле "создания полноценной IDE".
Такие рекламные ролики такие недостатки не показывают
Smalltalk скорее опередил время - требовал достаточно дорогую железяку, причём ещё и в однопользовательском режиме. У Apple сделать более-менее доступную копию компьютера с подобным GUI удалось только со второй попытки, а уж про ООП и IDE Джобс вспомнил только когда его из Apple выгнали ) Форт наоборот - хорош для небольших проектов на маленьких компьютерах, на промышленную разработку большими командами не особо масштабируется.
Delphi приспособлен к написанию больших программм. Система пятнадцать лет не развивалась из-за того что команда тратила свои скудные ресурсы на .NET, и всё равно оставалась достаточно актуальной.
Borland/Codegear/Embarcadero это всё-таки не Microsoft, не Apple, не Sun/Oracle. Им надо было либо уходить в opensource, либо искать партнёров.
В идеальном мире можно было бы себе представить альянс Borland/Nokia/Red Hat для адаптации Delphi под Linux и превращения Delphi в основную систему программирования под Linux.
Им надо было либо уходить в opensource, либо искать партнёров.
Им надо было всего лишь продолжать совершенствовать линейку Delphi 7, не метаясь в стороны с экспериментами, а также не уничтожать вход для новых специалистов, полностью отказываясь на полтора десятилетия от доступных community-редакций. Ну, точнее, она там формально была, но ни для разработки, ни для обучения в принципе не годилась, ни по лицензии, ни по функционалу.
Delphi стала мегапопулярной, когда полнофункциональная редакция стоила $50. А потеряла всю свою популярность, когда самая минимально пригодная редакция стоила $700.
Версия под Linux (Kylix) появилась давно, еще когда популярность Delphi была на пике. Но большого успеха не было.
Но большого успеха не было.
Ну так проблема была не в идее (современные кросс-платформенные системы разлетаются как горячие пирожки, а в то, что программирование с визуальным дизайнером - вещь, доказала ещё сама Delphi), а в реализации. Kylix имела кучу ограничений в применении и капризов, была дорогой, а самое неприятное - её кросс-платформенность для Delphi-разработчиков была довольно бесполезной. Она не имела совместимости с существующим Delphi-кодом, и для миграции проектов на Linux их надо было, по сути, писать заново, уже на кросс-платформенной библиотеке CLX. Которая, к тому же, по функционалу плелась далеко позади оригинальной VCL.
RIP Delphi - ты не смог приспособиться к написанию больших программ.
Ну это ложь)
7. У emacs есть плагин клиента LSP в виде lsp-mode. Может неполную, но очень близкую к IDE среду можно получить, и люди используют. У vim/neovim вроде тоже есть интеграция.
Eclipse, по сути, стала первой IDE, нацеленной на многоязычность, многоплатформенность и многофункциональность
А до этого сиволапые и не знали про многоязычность, многоплатформенность и многофункциональность. Двумя абзацами выше автор (справедливо) пишет про vim, который работает на любом утюге, но это, видимо, не та многоплатформенность. Емаксу, c ~6k плагинами до великого Иклипса с 1200 плагинами, в плане многоязыности и многофункциональности, видимо тоже, как до Китая пешком.
Ну и великий VS, который всего за 20 лет заборол Борланд на собственной платформе, и то, только потому, что заставил всех использовать закрытую технологию, конечно на первом месте. Как сейчас помню: после многих лет на Дельфи, запускаю MS Visual Studio C 6.0, а он (внезапно) оказывается ни хрена не Visual. Контролы на форму мышкой затащить нельзя! Надо было создавать ресурсы и писать какие-то магические файлы, чтобы они компоновались. Хорошо хоть этот позор пришлось делать только один раз.
после многих лет на Дельфи, запускаю MS Visual Studio C 6.0, а он (внезапно) оказывается ни хрена не Visual. Контролы на форму мышкой затащить нельзя! Надо было создавать ресурсы и писать какие-то магические файлы, чтобы они компоновались. Хорошо хоть этот позор пришлось делать только один раз.
Да ладно?
Я с ними мало работал, на Win 3.11 только. Там был MSVC 1.52 (и том же дистрибутиве шел MSVC 2.0 для WinNT 3.5).
Так вот там все это было можно. Все это делалось вполне себе визуально. Мышкой. И, кстати, приложения были "легче" чем в Builder'е. Потому что в билдере все настряпанные формы создавались сразу при старте приложения и висели невидимыми в памяти (для иного подхода надо было специально ручки приложить). MSVC честно создавал форму только когда это нужно и при закрытии прибивал ее.
MSVC была оберткой над стандатрными виндовыми контролами, в билдер что-то такое свое изобретал (и не все свойства виндовых контролов были доступны - иногда приходилось несколько химичить).
Ну и там еще был ряд идеологических различий.
Честно скажу - MSVC мне нравился больше.
Не, мышкой в Visual studio что-то можно было рисовать, но по-моему редактор ресурсов там был отдельным приложением. И чтобы потом использовать эти формы в коде - была куча Wizard-ов, которым надо было указывать, что с чем связывать, без мануалов там фиг разберешься, как это делается.
И, кстати, приложения были "легче" чем в Builder'е. Потому что в билдере все настряпанные формы создавались сразу при старте приложения и висели невидимыми в памяти (для иного подхода надо было специально ручки приложить). MSVC честно создавал форму только когда это нужно и при закрытии прибивал ее.
Ручки приложить? Это кнопочку одну нажать что ли?
Это дело пяти секунд и 4 кликов.
Так вот там все это было можно. Все это делалось вполне себе визуально. Мышкой. И, кстати, приложения были "легче" чем в Builder'е.
Особо ничего там визуально не делалось, только редактор ресурсов был, в котором можно было диалоговый ресурс состряпать на языке описания ресурсов. Но визуальный редактор ресурсов был и в турбо-паскале. Да, создать диаложек из ресурсов, сие для винды проще, чем создавать его программным путём, ну и кода в вашем приложении меньше получается, вы по сути скармливаете описание формы винде, а она по нему там создаёт диалог. Но зато и контроля над созданной формой у вас намного меньше.
По сути, реально визуальным в ранней Visual Studio был только редактор Visual Basic.
запускаю MS Visual Studio C 6.0, а он (внезапно) оказывается ни хрена не Visual.
Тоже очень удивил этот обман.
Не понятно почему Visual studio и VsCode вместе, между ними столько же общего как у java с javascript
Многие помнят браузерные войны той эпохи, однако разработчики вспоминают и войны IDE, происходившие в то же время между Microsoft и Borland.
Ох, эти священные войны на популярных тогда форумах... сколько бессонных ночей было потрачено на доказывание оппоненту, что мой папа круче твоего мой ЯП / IDE круче твоего!
К слову сказать, про Delphi и C#, так как там и там выступал один и тот же автор - Андерс Хейлсберг, и я, как сторонник Delphi, в время тех священных войн изучал "противника" и с удивлением обнаружил тогда, что все интересные фичи Андерс забрал с собой из Delphi в C# (сейчас вспомню только property, но список у меня был большой), более того сама IDE Visual Studio чуть ли не дословно повторяла Delphi (т.е. открыв в первый раз VS - ты себя чувствовал как рыба в воде), а архитектура для написания расширений для IDE и вовсе дословно копировала из Delphi даже имена методов. Понятно, что всё это было ярко заметно только на тот момент, сейчас и VS и C# ушли очень далеко, и теперь уже Delphi их копирует, но справедливости ради, когда говорят что C# это какая то компиляция C++ и Java - это немножко неправильно, всё таки папой больше был Delphi.
Кстати, по разнице дизайна тогда и сейчас. Вот на самом первом скриншоте (ToolBook) - там скорее всего 16 цветов, шрифт конечно ужасный, но насколько же классные там кнопки на тулбаре! Прямо так и хочется мышкой их нажать. А сейчас с современными разрешениями и truecolor - вроде и шрифты нормальные, и тёмные темы научились делать, а вот от тулбаров с хорошими жирными кнопками к сожалению отошли, как и вообще от четкости в GUI.
Перевод статьи, которая сгенерирована в BING в режиме "сбалансированный"?
В чем её ценность, кроме кармы РуВДС?
Мало того что нет личного взгляда и опыта автора. Так ещё имхо упущены некоторые значимые ИДЕ.
Для большинства пунктов не понимаю в чем именно был прорыв революционный. Если он действительно есть, то его и надо было подсветить.
Где-то тихо плачет забытый IAR
Ни в статье ни в комментах никто не не упомянул про Code::Blocks (https://www.codeblocks.org) что несколько удивляет.
Революционные IDE, повлиявшие на разработку ПО