В этой статье мы рассмотрим десяток сред разработки, оказавших самое большое влияние за последние тридцать лет программирования. IDE ранжированы по порядку, от десятого места до первого.
▍ 10. THINK C
При создании приложения для первого Macintosh необходимо было использовать Macintosh Programmer’s Workshop (MPW). Так как Macintosh сильно опережал другие системы своего времени благодаря своему графическому интерфейсу пользователя, программирование для него было совершенно иным процессом, чем, например, разработка для систем наподобие DOS. MPW компании Apple был предназначена для опытных программистов и имела приличную цену. Когда в середине 1986 года Think Technologies выпустила Lightspeed C, это существенно упростило программирование на Macintosh.
Think C (ранее называвшаяся Lightspeed C) стартовала столь мощно, что знаменитый журнал BYTE в сентябре 1986 года назвал её продуктом месяца. Она сочетала в себе мощные возможности, простой GUI и чрезвычайно конкурентоспособную цену примерно в $200 (около $500 по современным ценам), притом, что за MPW C просили больше $600 (больше $1500 по современным ценам). Think C также имела отладчик уровня исходного кода, который сегодня мы воспринимаем как нечто само собой разумеющееся.
Так как интерфейс пользователя Macintosh был чем-то новым и неслыханным, разработчикам нужна была возможность создавать пользовательские интерфейсы. Apple продавала небольшой инструмент под названием ResEdit, который распространялся как отдельный продукт или как часть пакета MPW. Отдельно он стоил примерно $100-$200 (сегодня около $500). В те времена программирование было дорогостоящим занятием. Сегодня WYSIWYG-редакторы GUI стали бесплатным и стандартным дополнением любой современной IDE, ResEdit оказался первым нативным WYSIWYG-редактором GUI.
▍ 9. Apple Xcode
Задолго до выпуска в 2007 году iPhone компания Apple выпустила IDE под названием Xcode, бывшее основным и единственным официальным IDE Apple для создания приложений macOS, iPhone, iPad, WatchOS, CarPlay и всех других платформ экосистемы Apple. Когда Apple перешла с классического Macintosh на OSX, разработчикам пришлось сильно меняться. THINK C, Apple MPW и CodeWarrior на Macintosh System 8+ предназначались для C и C++, а на новой OSX преимущественно использовался Objective C с Xcode IDE на основе NextStep.
Появление Xcode также ознаменовало конец многих IDE для системы Macintosh, которые не портировали IDE целиком и все библиотеки времени выполнения на новую OSX, по сути, являвшуюся NextStep. Все библиотеки и объекты на новой OSX идентифицировались префиксом NS, подчёркивающим их происхождение от NextStep. Кроме новизны самой Xcode, полностью сменилась и парадигма Apple. Разработчиков для экосистемы Apple и в прошлом, и в настоящем в большей или меньшей степени вынуждали использовать среду разработки Apple. Это уже было частично справедливо в случае MPW, но с появлением Xcode стратегия замкнутой экосистемы «огороженного сада» усилилась.
Хотя для macOS позволяют писать программы многие другие IDE, например, MonoDevelop, с появлением iOS для iPhone, iPadOS для iPad, watchOS для Apple Watch и CarPlay для автомобильных развлекательных систем разработчики практически были вынуждены пользоваться Xcode, если хотели иметь доступ ко всей экосистеме Apple и всем возможностям. С другой стороны, ежегодная плата в $99 за программу Apple Developer — это справедливая цена, учитывая, что она включает в себя все инструменты разработки и распространение через Apple App Store.
Xcode — это, вероятно, первая IDE для большой замкнутой экосистемы. Это потрясающая IDE с огромными преимуществами замкнутой экосистемы, хотя у неё иногда возникают трудности с поспеванием за прогрессом. Появление языка программирования Swift как замены Objective C повысило привлекательность разработки для платформ Apple.
▍ 8. vim
Выпущенный в 1976 году vi (расшифровывается как Visual) и vim (расшифровывается как Vi Improved) стал практически стандартным редактором для Unix и Linux. Да, существует emacs, и это тоже хороший редактор. Однако в 2015 году на Stack Overflow проводился опрос, который выявил, что vim используется шире, чем emacs. Как vim удалось выжить, учитывая множество появившихся за эти годы современных IDE?
Ответ очень прост: он не отставал от времени. В нём есть подсветка синтаксиса, отладка замечательно работает, а сам vim быстр. Очень быстр. Как только вы освоитесь с горячими клавишами, то не захотите пользоваться ничем иным даже для простого редактирования. Особенно если вы всё равно целый день работаете в терминале.
Vim также обладает преимуществом высокой портируемости между всеми операционными системами. Он может работать в Windows, Linux, Mac, больших мейнфреймах, MacBook и сетевом роутере. Благодаря этой портируемости vim доступен разработчикам на любой платформе, которым потребуется удобное редактирование файлов конфигурации, исходного кода и многого другого. Более новые версии, например, Neovim, ещё больше повышают удобство разработки, придерживаясь при этом функциональности vi и vim. Вполне вероятно, что vim проживёт ещё много десятков лет. Это был один из первых и самых популярных редакторов для Unix и по-прежнему остаётся главным выбором в Linux и Unix. Особенно любят опытные разработчики vim за его скорость и удобную работу с клавиатуры.
▍ 7. CodeWarrior
Когда Apple перешла с процессоров 68k на платформу PowerPC, компании наподобие Symantec, владевшей тогда THINK C, вынуждены были выполнять миграцию своих IDE на новую процессорную архитектуру. Компания под названием MetroWerks работала над новым CodeWarrior IDE со многими участниками бывшей команды разработки THINK C. CodeWarrior известна своей простотой использования, меньшим по сравнению с MPW компании Apple временем компиляции и привлекательной ценой. Её первый релиз вышел в 1993 году.
За промежуток времени с 1994 до 2002 года CodeWarrior стала доминирующей IDE разработки приложений для Mac OS 8 и 9. В своей истории развития Apple переходила от процессоров 68k к PowerPC, потом к Intel, а затем на новые Apple Silicon с архитектурой arm64. Каждая смена аппаратной платформы становится полным кошмаром для производителей IDE. THINK C и CodeWarrior оказались единственными IDE, получившими серьёзную долю рынка профессиональной разработки ПО на Macintosh с конца 80-х до начала 2000-х. Но и их потом вытеснила собственная IDE Apple — Xcode. И не потому, что Xcode была существенно лучше, а благодаря тому, что Apple смогла вынудить разработчиков пользоваться Xcode, сильно усложнив выживание на платформе сторонним IDE.
▍ 6. IntelliJ IDEA
Когда в середине 1990-х появился язык Java, IDE для него было мало. Часто при написании кода на Java использовались простые редакторы, а код компилировался в командной строке. Вероятно, первыми выдающимися IDE для Java стали Netbeans и Microsoft Visual J++. IntelliJ IDEA была выпущена в январе 2001 года и имела продвинутые функции навигации по коду и рефакторинга.
IntelliJ и по сей день считается одной из самых продвинутых IDE. Вероятно, ей может бросить вызов только полнофункциональная Microsoft Visual Studio. Кроме наличия в ней всех воображаемых функций, IntelliJ также продемонстрировала превращение IDE из легковесных редакторов кода в (иногда монструозные) среды разработки с бесконечными вариантами настройки. Разработчикам иногда требуется несколько дней, чтобы освоиться в новых современных IDE. IntelliJ начала эпоху полнофункциональных интегрированных сред разработки, вместивших все необходимые разработчикам инструменты в одно приложение.
▍ 5. Eclipse
Примерно во время появления IntelliJ была выпущена Eclipse. Хотя Eclipse изначально предназначалась для языка программирования Java, она быстро расширилась на все известные нам языки. Более того, обширная среда плагинов позволяла делать всё и со всем. Конечно, IntelliJ и сегодня можно использовать со множеством разных языков, например, PHPStorm для PHP, и многими другими, Eclipse, по сути, стала первой IDE, нацеленной на многоязычность, многоплатформенность и многофункциональность.
Нет почти ничего, что нельзя было бы собрать при помощи Eclipse. От C++ до PHP, Python и Go.
В Eclipse есть плагины для всего. Eclipse начала эпоху открытой среды разработки, которую может использовать каждый для создания собственной IDE. В конечном итоге, Eclipse временами кажется слишком хаотичной, однако несмотря на своё будущее и недостатки, Eclipse заслужила особое место в зале славы, потому что дала свободу рынку сред разработки. Я написал своё первое приложение Google App Engine в Eclipse в 2008 году. На пике популярности Eclipse компания Microsoft всё ещё продавала свои среды разработки за внушительные суммы. Eclipse была бесплатной, полнофункциональной и влюбляла в себя разработчиков с первого взгляда.
▍ 4. Dreamweaver, Flash и Fireworks
1995-й и последующие годы стали временем бурного развития world wide web и появления таких должностей, как веб-мастер, а позже и веб-разработчик. Большинство IDE того времени, например, выдающаяся Visual C++ 1995 года, проектировалось под разработку приложений для десктопов и серверов. С точки зрения дизайна предлагаемый ими максимум заключался в конструкторе WYSIWYG GUI для целевой операционной системы, позволяющем проектировать окна, списки и кнопки. Для браузера они ничего предложить не могли.
Именно в это время компании наподобие Macromedia выпустили свои продукты. ПО Macromedia Dreamweaver было WYSIWYG-редактором HTML, а позже CSS и JavaScript. Первая версия Dreamweaver была только для Macintosh, за ней последовала и версия для Windows. Пик популярности Dreamweaver пришёлся на время пузыря Новой Экономики в 1999-2002 годах. Dreamweaver UltraDev 4 была самой совершенной IDE для веб-разработки того времени. В ней не только присутствовали функции разработки для фронтенда (JavaScript, HTML и CSS), но и имелась поддержка Microsoft ASP с серверным JavaScript и Visual Basic, JSP, PHP и собственного ColdFusion компании Macromedia.
Macromedia Flash и её скриптовый язык ActionScript предоставляли безграничные возможности создания любых мультимедийных приложений, запускаемых в браузере с установленным плагином Flash. Кто-то всегда будет помнить её как кошмар, для других это был невероятный опыт. При помощи Flash люди создавали свои первые игры для веба, на первых популярных сайтах потокового воспроизведения видео и аудио использовался Flash, а владельцы веб-сайтов любили анимированные заставки на главной странице. Flash и программирование на ActionScript стали идеальным представителем той эпохи, какой она нам запомнилась.
Рассказ об инструментах веб-разработки Macromedia был бы неполон без упоминания Fireworks. Хотя Flash, учитывая существование ActionScript, можно считать средой разработки, Fireworks похожа на редактор векторной графики. Однако в Fireworks есть интегрированный генератор кода, позволяющий нарезать графику, встраивать анимации и экспортировать HTML-содержимое, в том числе и необходимые фрагменты кода на JavaScript. Dreamweaver, Flash и Fireworks были неслыханными WYSIWYG-инструментами, поднявшими понятие WYSIWYG на совершенно новый уровень. Хотя Dreamweaver по-прежнему существует, Flash и Fireworks были заброшены после приобретения Macromedia компанией Adobe. Сегодня Dreamweaver является частью Adobe Creative Cloud. Если вам интересна история веб-разработки, то прочитайте мою статью A tale from 30 years of HTML.
▍ 3. Microsoft Word and Excel
Несмотря на мемы о людях, пишущих код в Microsoft Word, любой, нажимавший ALT+F11 в Excel для Windows, знает, что к чему. В Word, PowerPoint и Excel есть полнофункциональная среда разработки Visual Basic For Applications. Сама IDE очень похожа на Visual Basic 6 1998 года и позже. В ней используется исключительно Visual Basic 6 (также называемый VB6). Впервые VBA появился в Excel в 1993. Билл Гейтс представлял VBA как универсальный язык макросов, и именно такую функцию он выполнял десятки лет.
Электронные таблицы и, в частности, Excel были основным бизнес-приложением на компьютерах, начиная с 1980-х. По популярности с ними были сравнимы только текстовые редакторы наподобие Microsoft Word и приложения для создания презентаций наподобие Microsoft PowerPoint. Возможность наличия полной IDE с новым Visual Basic 6 внутри Microsoft Excel позволяла пользователям подключать электронные таблицы к любому источнику данных и заставлять их выполнять любые задачи. Хотите автоматически собрать список сетевых хостов в локальной сети в таблицу? Excel и VBA могут сделать это автоматически.
VBA не ограничен простыми алгоритмами и базовыми макросами. Он включает в себя полный конструктор GUI, классы, модули и практически всё, что есть в VB6. Это превращает обычные листы Excel, документы Word и презентации PowerPoint в готовые приложения. VBA — это секрет, стремительно завоевавший пакету Microsoft Office доминирующее положение на рынке. IDE больше не были отдельными приложениями, теперь в крупных приложениях имелся свой IDE. Это ознаменовало начало эпохи расширения стандартных приложений при помощи IDE, интегрированных в сами приложения.
▍ 2. Borland C++ Builder и Delphi
Название Borland было известно всем в мире сред разработки ПО в 1980-х, 1990-х и до начала 2000-х. У Borland имелись знаменитый C++ Builder, Delphi как потомок Turbo Pascal, купленная компанией dBase и многое другое. При обсуждении IDE в 90-х было не обойтись без упоминания Borland. Многие из выдающихся приложений для Windows 90-х были написаны при помощи ПО Borland. Вузы учили молодых разработчиков на C++ в Borland Builder. Лично я сам изучал C и C++ в ПО Borland для DOS и Windows.
Delphi была для Borland тем, чем был Visual Basic для Microsoft. В конце 90-х и начале 2000-х сообщества Visual Basic и Delphi были очень популярны. Delphi, являясь диалектом Object Pascal, жива по сей день и остаётся самым серьёзным конкурентом Microsoft Visual Basic. В обеих IDE Borland имелись продвинутые редакторы GUI, имевшие множество мелких преимуществ перед продуктами Microsoft. Кроме того, Borland предлагала более широкий спектр элементов управления пользовательским интерфейсом, а Microsoft придерживалась стандартных компонентов Windows.
Многие годы Borland C++ и Delphi конкурировали с Microsoft Visual C++ и Visual Basic. В этой фазе ожесточённой борьбы между Borland и Microsoft были придуманы одни из самых мощных функций, например, автозавершение кода, сложная подсветка синтаксиса, простые в использовании компоненты, упрощённые абстрактные системные API и многое другое. Многие помнят браузерные войны той эпохи, однако разработчики вспоминают и войны IDE, происходившие в то же время между Microsoft и Borland.
▍ 1. Microsoft Visual Studio
Номер один, неоспоримый чемпион в тяжёлом весе среди интегрированных сред разработки за тридцать лет — это Microsoft с её ПО Visual Studio, развивавшееся с Visual C++ и Visual Basic до Visual Studio .NET с C# и Visual Studio Code. С момента основания Microsoft компания делала упор на разработку ПО и инструменты для него. Microsoft BASIC был фундаментальным продуктом компании. Microsoft — гигант в продаже ПО, но по своей сути это гигант в разработке ПО.
Знаменитая речь (или, скорее, танец) Стива Балмера «разработчики, разработчики, разработчики» не просто стала Интернет-мемом на все времена. Она также подчеркнула важность для Microsoft постоянного привлечения разработчиков и обеспечение большой доли рынка в сообществе разработчиков ПО. Пока кто-то задавался вопросом, зачем Microsoft купила Github, инсайдеры хорошо понимали, что Microsoft не хочет позволить никому бросать ей вызов в мире инструментов и сервисов для разработки ПО.
Microsoft Windows 3 и её графический интерфейс пользователя — не стали чем-то новым, ведь уже существовал Macintosh. Однако ситуацию полностью изменила Microsoft Visual Basic IDE. В Visual Basic появилась возможность перетаскивать элементы интерфейса или управления на холст окна. Благодаря этому, Microsoft начала в 1991 году эпоху визуального программирования. Разработчики теперь могли визуально проектировать приложение с чётким видением интерфейса пользователя, а значит, и UX. Это ознаменовало начало эры дизайна ПО для пользователей.
Visual Studio 6 стала поворотным моментом для Microsoft и Visual Studio. Это была первая Visual Studio для работы с базами данных, способностью собирать приложения и библиотеки для Windows, Pocket PC серверных приложений для IIS с ASP, элементы управления ActiveX, и многое другое. Кроме того, Visual Studio 6 можно было расширять, чтобы создавать сборки для платформ наподобие PalmOS. Компоненты ActiveX и COM позволили использовать в Windows сторонние компоненты.
В 2000 году Microsoft выпустила новый язык программирования C#, который станет соперником популярного языка Java и будет использовать новый фреймворк .NET. Фреймворк .NET был полной библиотекой классов, абстрагирующей Windows API. Также был выпущен Visual Basic .NET, дающий Visual Basic более беспроблемный доступ к функциональности Windows через фреймворк .NET. Microsoft Visual Studio продолжила эволюционировать и превратилась в богатую функциями монструозную среду, сравнимую с IntelliJ IDEA.
Учитывая, что IDE стали ещё больше, прожорливей к ресурсам и тяжеловесней, а все их функции и сложность не были нужны многим разработчикам, в начале 2010-х постепенно началась тенденция перехода более простым редакторам. Благодаря редакторам наподобие Sublime Text, выпущенному 2008 году, Github Atom, выпущенному в 2015 году и Notepad++, уже завоёвывавшему долю рынка с 2003 года, масштаб перехода от полнофункциональных IDE обратно к редакторам был существенным. Microsoft быстро отреагировала на эту тенденцию и выпустила в 2015 году легковесную среду разработки Visual Studio Code.
Согласно опросу разработчиков, проведённому в 2022 году StackOverflow, 74,48% разработчиков использовало Visual Studio Code. Microsoft уже тридцать лет продолжает доминировать на рынке IDE, имея долю рынка намного больше 60%. Сегодня VSCode поддерживает все языки программирования, работает в Windows, macOS и Linux. Благодаря Github, Copilot она предоставляет самые современные функции автоматического завершения кода при помощи ИИ. Она поддерживает контроль версий, отладку, расширения и просто бесконечное количество возможностей.
Ни одна компания за прошедшие тридцать пять лет не внесла такой вклад в развитие интегрированных сред разработки, как Microsoft. Именно поэтому Microsoft и семейство Visual Studio заслуживают первого места в списке революционных IDE, повлиявших на разработку ПО.
Telegram-канал с розыгрышами призов, новостями IT и постами о ретроиграх ????️
Комментарии (164)
PuerteMuerte
31.07.2023 13:04+94Странная подборка. Есть какие-то рядовые IDE с нишевых платформ на момент выхода этих IDE, вроде Xcode или CodeWarrior. Зато нет IDE, совершивших, собственно, революцию в мире IDE:
Borland Turbo Pascal: собственно, вообще первая IDE, плюс, долгое время она задавала новые планки стандартов в IDE - встроенный отладчик, контекстная справка, средства удалённой отладки, UI-фреймворк и т.д.
Visual Basic (а не упомянутый VBA из Word и Excel, и не Visual Studio): первая IDE с визуальным редактором интерфейсов и компонентной моделью, которая в 1991-м году определила основные принципы построения IDE до сегодняшнего дня.
dph
31.07.2023 13:04+5Еще была линейка VisualAge от IBM, с интеграцией с VCS и прочими прикольными штуками, в первую очередь VisualAge for Smalltalk.
geher
31.07.2023 13:04+1Шикарный был проект. Даже как-то пришлось программировать на VisualAge для С++ под полумух (OS/2). Давал больше возможностей для визуального программирования невизуальной части, чем Delphi, но был существенно сложнее в использовании.
Жаль, что его больше нет с нами. Дольше всего продержался для Smalltalk.
SpiderEkb
31.07.2023 13:04Было. Они даже свои языки, родной средой для которых была их платформа AS/400, RPG и COBOL туда вывести.
dph
31.07.2023 13:04Там даже PL/1 был и REXX )
SpiderEkb
31.07.2023 13:04PL/1 у IBM тогда вообще в почете был. Активно его пытались развивать, но где-то переборщили и оно под собственной тяжестью загнулось.
Хотя, тут где-то недавно вспоминали - обнаружили что в современном RPG достаточно много "отголосков" PL/1 (хотя изначально RPG вообще от табуляторов шел) в плане синтаксиса и идеологии.
Halt
31.07.2023 13:04+9«вообще первая IDE»
Алан Кей смотрит на вас с удивлением.
Smalltalk-80 IDE PuerteMuerte
31.07.2023 13:04Ну это же Смоллтолк, это не совсем IDE. Это объектно-ориентированная ОС, предок Java VM.
Halt
31.07.2023 13:04+6Интересный у вас подход. Smalltalk — это в первую очередь философия разработки, а во вторую именно что интегрированная среда, в которой программа и ее среда разработки неразрывно связаны (хотя и отделимы).
Интегрированная среда разработки с контекстно-зависимым автодополнением и подсветкой синтаксиса, встроенный отладчик, система интроспекции и структурной навигации по коду, интегрированная же справка, собственно GUI, горячая замена методов, автоматизированные рефакторинги и многое другое, чего до сих пор нет в других языках. Не говоря уже про языковые фичи, которые тоже были впервые введены именно в Smalltalk, как например полиморфные интерфейсы с классами, итераторы, декораторы, TDD.Да что говорить, вот например разворот журнала Byte за 81 год, где все можно прочитать самому. То что люди все это не поняли и забили на добрых двадцать лет, а потом изобрели заново, не делает это «вообще первым».
А то, что его интерфейс до сих пор можно запустить вместо ОС… ну это как минимум не хуже, чем «просто IDE». Предок JVM? Ну наверное, примерно как микроскоп можно назвать предком молотка.
VladimirFarshatov
31.07.2023 13:04Исторически первая ИДЕ, все же наверное Фортран-2 Ершова, или как там он назывался. 1979г. НГУ "underground" ..
полистал ниже .. где Рапира, Школьница? ТОР для Ямахи? Впрочем, последнее все же просто текстовый редактор, но .. хорош. Слишком.
gimntut
31.07.2023 13:04Это же перевод. Было бы странно увидеть в американской статье советские программы
K0styan
31.07.2023 13:04CodeWarrior помимо прочего долго была основной IDE для встраиваемых систем Motorola/Freescale. Не удивлюсь, если в этом статусе она оказалась более знаковой, чем как IDE для маков.
sav13
31.07.2023 13:04+15Я бы сюда обязательно добавил бы FoxPro. Очень много было написано на нем
SpiderEkb
31.07.2023 13:04+2А я бы тогда вспомнил бы Clarion под DOS.
Который сам умел генерировать законченный код и экранные формы для работы с описанной таблицей
DikSoft
31.07.2023 13:04+6Очень любопытный был продукт.
Сразу генерировал словари и структуру данных + базовые обёртки для них вместе с интерфейсом. Не выжил из-за совершенно дикого и особенного по структуре собственного языка. Некоторое время серьёзно конкурировал с Clipper. Clipper, как более традиционный и здорово расширяемый, вышел победителем, но потом не выдержал переноса в Windows и плавно ушел с арены.
Ну и если уж заводить речь про IDE времён DOS, то стоит упомянуть Multi Edit, который был хорошо приспособлен за счет расширений становиться полноценной IDE для кучи языков.
Сейчас не могу понять, как в режиме VGA50 я мог сидеть в в нём целые дни на 14' ЭЛТ мониторе!
vvmtutby
31.07.2023 13:04Если и конкурировал, то с FoxPro.
Ничего сверх-нетрадиционного в ЯП Clarion нет.
Wiki вообще уверена, что это Modula-2 семейство ( не совсем)
vagon333
31.07.2023 13:04+2Ничего сверх-нетрадиционного в ЯП Clarion нет.
Не совсем ЯП, но в среде есть.
В Clarion, еще с DOS v2.0:
- отдельно описание схемы базы данных
- UI с привязкой к элементам схемы.
Т.е. списки, формы, выпадающие списки не в воздухе, с ручным кодом, а с привязкой через UI к данным. При изменении настроек работы с данными, код менять не нужно было - авто-генерился.
Эта концепция добавила надежность в разработку - когда UI привязан к элементам данных, "сломать" такой код значительно сложнее.
Представьте что у вас соблюдается ссылочная целостность при связях UI и схемы.
Плюс, масса кода генерилась автоматом, с возможностью вставить свой в т.н. точки вставки. Т.е. авто-генеримый код перестраивался при изменении настроек приложения через UI.
После курсов в 1992, когда Арсис познакомил с Clarion под DOS, разработал на нем до 2004. Сейчас как раз в том городе, где офис Clarion (TopSpeed -> SoftVelocity) и размещался (Pompano Beach). Для меня было как-то классно остаться именно здесь.vvmtutby
31.07.2023 13:04С Clarion я работал плотно. Закупили у "Арсис" и CfD 2.X, и обновление до CDD 3.X
Выше ( не вы) писали, что Clarion a) не выжил b) и не выжил именно из-за встроенного в среду языка программирования.
На деле: жив, выходят новые версии и т.п. Соответственно, раз нет события, то нет и его причины.
Так же существует альтернативная реализация -- clarion2javaDikSoft
31.07.2023 13:04Выше ( не вы) писали, что Clarion a) не выжил b) и не выжил именно из-за встроенного в среду языка программирования.
Вот это сюрприз, не знал, что он жив. Мне казалось, что он исчез полностью. Подскажите, в какой глубинной нише он нынче обитает?
PS Может ещё и Progress где-то живёт?
SpiderEkb
31.07.2023 13:04- отдельно описание схемы базы данных
- 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 идею, то ли все это просто "витало в воздухе" в те времена, но на мой взгляд очень похоже. Язык описания данных, описание экранных форм которые не надо рисовать в рантайме, а можно просто работать с ними как с файлом...
DikSoft
31.07.2023 13:04Последние 6 лет работаю с AS/400
Видел такую систему, когда в начале нулевых работал в ПФР. Она там ещё живая? Или Вы её ещё где-то используете до сих пор?
Hokum
31.07.2023 13:04А почему «до сих пор», IBM продолжает выпускать свои мейнфреймы. Да, это нишевые системы, встретишь их не часто, но прекрасно работают, держат требуемую нагрузку. Большая, мощная СУБД. Это, конечно, «другой мир», но тоже интересный.
Поработать с ними не было случая, но в банках стоят, и думаю, что до прошлого года вполне себе обновлялись.
DikSoft
31.07.2023 13:04+2Просто она относится к редкому вымирающему виду, обслуживать и содержать котрый стоит адских денег, но слезать с него ещё дороже. Примерно, как легендарный COBOL. )
В банках мне не довелось увидеть. Стало интересно, в каких сферах это используется сегодня.
SpiderEkb
31.07.2023 13:04+1Она отнюдь не вымирающий вид. Вполне себе развивающаяся система. Просто нишевая. Нов своей нише очень производительная, очень надежная.
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'ов, тут делается намного проще.
Короче, тут можно бесконечно долго рассказывать :-)
SpiderEkb
31.07.2023 13:04-1Ну вот как пример чем нравится 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, а если надо что-то низкоуровневое - С/С++ И все это прекрасно собирается в одну программу.
mayorovp
31.07.2023 13:04То есть вы вместо использования стандартной функции преобразования даты пишете вот такое каждый раз и считаете это нормальным?
На самом деле это должен был быть пример того чем не нравится RPG. Я не понимаю почему вы это записываете в плюс.
Кроме того, тут видна проблема ещё и в экосистеме в целом. Ну не должно быть в нормальной системе такого формата даты как CYYMMDD.
SpiderEkb
31.07.2023 13:04-1То есть вы вместо использования стандартной функции преобразования даты пишете вот такое каждый раз и считаете это нормальным?
Не везде. Там, где требуется высокая эффективность. Стандартные функции работы с датами больше грузят процессор и занимают больше времени.
В тех ситуациях, когда такие преобразования выполняются 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.
Хранить в виде даты? Там тоже свои минусы в других местах вылезут...
mayorovp
31.07.2023 13:04Погодите, у вас CYYMMDD — это число, а не строка? То есть язык позволяет неявно преобразовать строку в число, и вы ещё утверждаете что заботитесь о производительности?! Да что с этим миром не так?..
SpiderEkb
31.07.2023 13:04Не язык позволяет, а на данной платформе есть формат чисел с фиксированной точкой, который для положительных чисел в памяти совпадает со строковым представлением. Есть и другой формат (тоже с фиксированной точкой), который не совпадает.
От языка все это не зависит совсем. Все тоже самое можно и на С написать. С тем же результатом.
И да. Высокая производительность достигается именно тогда, когда вы знает как оно устроено внутри и как работает. А не просто тупо лепишь готовые конструкции.
Как мне говорил один "разработчик" с позволения сказать, на прошлой работе - "это невозможно потому что в используемом нами фреймворке такого нет. Пришлось ткнуть носом с системные API и показать как желается средствами системных API.
PuerteMuerte
31.07.2023 13:04+2Не везде. Там, где требуется высокая эффективность. Стандартные функции работы с датами больше грузят процессор и занимают больше времени.
Так а в чём высокая эффективность-то? Вы же используете zoned числа, которые сами по себе на низком уровне вообще не числа, а тоже сложная структура, как и строки, и имеют те же проблемы с производительностью. Если бы вы работали не на AS/400, а практически на любой РС-платформе, дата/время у вас были бы обычным числом, хранилось бы в СУБД также в числовом формате, любые операции также выполнялись с помощью числовой арифметики, и вы вообще бы не сталкивались с этой проблемой.
Короче говоря, hiload наложенный на mission critical имеет свои особенности и свои требования.
Ну вот поэтому это тупиковый путь. Вы страдаете и делаете всякие выкрутасы, чтобы упаковать все ваши бизнес-требования в ограниченные возможности одного дорогущего чёрного шкафа, в то время как в другом мире просто поставят ещё пару копеечных юнитов в стойку (это если данные business-critical, и их обработку нельзя чужому облаку делегировать).
SpiderEkb
31.07.2023 13:04+1Это не мейнфреймы. Мейнфремы у IBM - платформа IBM z. Которая "выросла" из System/370
IBM i - middleware. Выросла из System/38, далее AS/400. Изначально задумывалась как платформа для малого и среднего бизнеса. Но получилась настолько удачной и масштабируемой, что сейчас и в крупном бизнесе успешно используется.
Сейчас сделали новый проц Power10. Там вообще возможность объединять много процессоров в кластер высокопроизводительной шиной, причем, контроллер шины интегрирован в кристалл. Т.е. фактически просто процессоры стыкуются между собой. И могут использовать все ресурсы, включая опреративную память, совместно.
Т.е. очень легко масштабируется - купили 5 машинок сцепили между собой - получили одну фактически, потребовалось мощность нарастить - купили еще 3 машинки - подцепили и мощность вашего "сервера" выросла.
PuerteMuerte
31.07.2023 13:04+1Т.е. очень легко масштабируется - купили 5 машинок сцепили между собой - получили одну фактически
А вы ничего не преувеличиваете? Я-то уже давно не работаю с AS/400, и новинками не интересовался, но чисто физика против этого. Для памяти DDR5, например, за один такт свет проходит примерно 5-15 сантиметров, в зависимости от частоты. Ну т.е. сделать общее виртуальное ОЗУ технически-то всегда можно, но если процессор одной машины будет пытаться напрямую работать с ОЗУ другой машины, через какой-то кабель и преобразователи, латентность там будет огромная, и в реальной работе нужно будет такие операции во-первых, выявлять, во-вторых, ограничивать только для случаев крайней необходимости.
Поэтому такая архитектура может иметь смысл только если процессоры стоят в одной машине и очень желательно, на одной плате.
unreal_undead2
31.07.2023 13:04Лет двадцать назад встречался с подобной штукой на обычной x86 архитектуре - два физических сервера в стойке от того же IBM объединялись специальным кабелем, после чего операционка это видела как одну SMP систему. Понятно, что NUMA эффекты типа большей latency при обращении к "чужой" памяти были, но в принципе оно работало, при разумном разделении по данным код вполне параллелился.
SpiderEkb
31.07.2023 13:04+1Она не просто "до сих пор" используется, но и вполне себе развивается. Про ПФР слышал. Слышал, что где-то на РЖД есть машинки. В банках (у нас в Альфе, в Райфе, в Росбанке точно, может еще где есть).
Сейчас, кстати, оно называется IBM i (есть еще IBM z - это уже мейнфремы которые выросли из System/370).
На LinkedIn есть несколько групп тематических, на SO есть теги #rpg (это не про игры, как раз про язык RPG), #rpgle (современная версия RPG интегрированная в концепцию ILE), #ibm-midrange... Ну и так ресурсов хватает англоязычных.
Система нишевая, но свою долю рынка имеет.
Мы сейчас сидим на Power9 и версии 7.4. Но уже есть Power10 (говорят, что теоретически возможно купить хоть и не так просто) и версия 7.5.
В целом, мощно, надежно, интересно т.к. ни на что не похоже - совсем иные концепции заложены.
static_cast
31.07.2023 13:04+12Про Emacs упомянуто только то, что это менее распостраненная альтернатива Vim-у. Ну-ну.
GospodinKolhoznik
31.07.2023 13:04-1Да, существует Linux, и это тоже хорошая ОС. Однако проводился опрос, который выявил, что Windows используется шире, чем Linux ;)
abulanov
31.07.2023 13:04+7А прообразом всех VSCode и JetBrains был замечательный Multi Edit
grumbler70
31.07.2023 13:04+1... особенно классно, что он мог работать в VGA режиме на 50 строк или в EGA на 43.
PuerteMuerte
31.07.2023 13:04+3Во времена DOS сложно было найти редактор/IDE, которые не умели бы в EGA/VGA текстовые режимы.
AlexeyK77
31.07.2023 13:04+11Что запомнил эпохального со времен ДОС:
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 - это лучшее что было.
sav13
31.07.2023 13:04+2Borland Delphi/Builder - это лучшее что было.
Ну до сих пор есть RAD Studio
Для визуальной разработки интерфейсов очень неплохо даже
larasage
31.07.2023 13:04+12) IDE Borland Turbo (pascal,c/c++) + Turbo Vision. Все что было позже - лишь повторение и улучшение. Еще был компилятор Turbo Basic.
Turbo Prolog :)
Machirodont
31.07.2023 13:04+12"В старину при написании кода вы видели лишь чёрный текст на белом фоне" - ну да, ну да.
zatim
31.07.2023 13:04+6Правильнее было бы написать: белый текст на синем фоне.
RalphMirebs
31.07.2023 13:04+9Белый на чёрном, зелёный на чёрном, янтарный на чёрном. Обычные монохромные терминалы больших ЭВМ.
HemulGM
31.07.2023 13:04+6Могли бы свежую версию IDE от наследника Borland показать
simenoff
31.07.2023 13:04Подсказки по коду есть?
Автоформатирование есть?
HemulGM
31.07.2023 13:04Только автодополнение, автозавершение, сниппеты, ... Чтоб он предсказывал что ты напишешь - нет. Такого пока нет. Если речь о copilot или его аналогах. Сделали бы, если б ChatGPT отвечал быстро, а не через 20 секунд. Помощник такой уже есть. Может найти ошибку, сгенерировать, исправить или конвертировать код. Ну или объяснить. (вот тут)
Автоформатирования тоже нет (если честно, в VS оно меня раздражает немного, но это личное). Есть ручное, сочетанием клавиш (удобно, не навящиво). Да и многие, закостенелые даже этим не пользуются.
Но сделать всё это можно, если захотеть. Достаточно написать пакет, расширяющий функционал (по сути обычный пакет как и все). Была бы у меня нужда, сделал бы. У среды есть документированное API с доступом почти куда угодно (редактор, LSP, окна, меню и т.д.)
Вот, например, я делал монитор как в VS. Делов на 2 часа
Скрин
FDA847
31.07.2023 13:04+1Автоформатирование есть и уже довольно давно. Вызывается по Ctrl+D. Под него куча настроек.
HemulGM
31.07.2023 13:04+1Это не автоформатирование, это просто форматирование, о котором я тоже упомянул. Автоформатирование - это когда редактор каждый раз форматирует код при его изменении. Откройте visual studio и посмотрите, как это работает с шарпом
FDA847
31.07.2023 13:04+3А-а-а, это. И хорошо, что нет. В Visual Studio дико раздражает. Намного удобнее написать код, а потом вручную отформатировать. Привык так в Delphi и в MPLAB X IDE (вроде на базе NetBeans сделана).
PuerteMuerte
31.07.2023 13:04В Visual Studio дико раздражает.
Оно ж там тоже вручную форматирует, по Ctrl+K + D. Или вы по VS Code?
mayorovp
31.07.2023 13:04Именно VC, оно форматирует при вводе закрывающей фигурной скобки или точки с запятой. Впрочем, форматирует не слишком агрессивно и раздражает только при попытках в табличное форматирование.
Вот кто и правда раздражает — так это Rider. Мало того что ультимативно перехреначивает код под свой собственный стиль — так ещё и любит "вытянуть" сложный запрос по вертикали вдоль правой границы текста.
VladimirFarshatov
31.07.2023 13:04А разве не Джетбрайн со своим агрессивным форматированием, проверкой синтаксиса, в т.ч. и неймингов? Особенно в Го..
mayorovp
31.07.2023 13:04+2Rider — он же как раз от Jetbrains.
Что же до Го — это и вовсе особенный мир, в котором форматирование встраивается не в IDE, а чуть ли не в компилятор.
gatoazul
31.07.2023 13:04Пытался выучить Го. Он сразу же стал с меня требовать ставить открывающую скобку в той же строке, где if, и ни в коем случае не на следующей.
На этом наше знакомство и закончилось.
Не люблю тупых программ, считающих себя умнее, чем я.
Hokum
31.07.2023 13:04+1Он как раз «тупой», поэтому и хочет, чтобы все было написано одинаково. ????
И единообразие форматирование кода в Го - подкупает. Нет такого, что одна команда пишет так, другая сяк. Всё +- одинаково. :)
Daddy_Cool
31.07.2023 13:04+2Был такой замечательный язык/среда Clarion, для БД. Сам не работал, но люди рядом работали и очень хвалили. Первая (видимо) система визуального программирования, это потом уже появился Visual Basic.
Вот здесь обзорная статья:
https://habr.com/ru/articles/555246/
simenoff
31.07.2023 13:04+2Эх, кто бы запилил современную среду типа Delphi (C# и Qt - не то пальто)
Hokum
31.07.2023 13:04+7Так пользуйтесь Delphi. Приложения позволяет создавать в том числе и под мобильные устройства и официально есть бесплатная версия - Community Edition. А и там дженерики появились.
Ну или Lazarus - по мотивам Delphi 7, кроссплатформено.HemulGM
31.07.2023 13:04+2Инлайн объявление, выведение типов, анонимки, таски, for in, for var in. В новой версии ожидаются мультистроки в редакторе. Кучу всякого доставили
ilriv
31.07.2023 13:04+1Жаль что никак не избавятся от багов в C++ Builder
Daddy_Cool
31.07.2023 13:04А что там за баги? У нас были проблемы с многопоточностью. Вы какой версией пользуетесь? Ощущение, что 6-я версия живее всех живых.
Судя по обзору новой версии (от декабря 21 года), чего-то существенно нового/важного не появилось.
https://habr.com/ru/articles/597353/ilriv
31.07.2023 13:04+1Да много чего было. Например приложение и IDE зависали намертво из-за потери соединения между ними.
barsik_unlimited
31.07.2023 13:04-2до сих пор пишем на работе на шестом билдере, с виду кажется старым и неуклюжим (что неверно), зато невероятно прост и умеет всё, кроме разве что сборки под мобилки
Grom2025
31.07.2023 13:04К сожалению баги были и не только с threads.
https://habr.com/ru/articles/217189/
Как дела обстоят в Embarcadero на данный момент не знаю, успешно портировался на gcc.
SpiderEkb
31.07.2023 13:04Ну, строго говоря, Builder - адаптация Delphi под С++. И версии Builder отставали (в те времена, когда имел дело с ним) на одну от версий Delphi. Т.е. сначала делали Delphi, потом уже переносили все это в Builder.
Но баги там были. Как-то напоролся в каких-то объектах VCL на то, что там индексация не с 0 как в С++, а с 1 как в Паскале. Т.е. забыли адаптировать. В каком именно месте не помню уже сейчас - лет 6 прошло с тех пор как на другую систему ушел.
Вообще, насколько помню, там в С-шной версии VCL куча чего бала на Паскале. И можно было паскалевские dcu к сишным проектам цеплять.
А так борландовский компилятор нравился.. Во-первых, при использовании статических библиотек он умел выдергивать из них только те модули, которые реально нужны. С тем же gcc у меня такое не получалось (может, просто не умею).
Кроме того, это единственный компилятор (из тех, с которыми приходилось работать), который реально поддерживает long double (10 байт). У остальных long double типа понимает, но по факту - тот же 8-байтовый double.
Так что в целом воспоминания о нем достаточно позитивные остались.
Malizia
31.07.2023 13:04Кто бы завёз нормальный IntelliSense в VS как в Rider - цены бы не было. А так приходится держать две IDE.
Hokum
31.07.2023 13:04Visual Assist, хорошая вещь. Работает шустро, работу студии не блокирует пока парсит, да и в целом хорошо показал себя на относительно большом проекте.
siberianlaika
31.07.2023 13:04+6GNU/Emacs как всегда не существует. Уже почти 40 лет с момента создания и до v29.1 вышедшей на днях не существует. И да, дальше можно писать, что "это не ide, а редактор такой, а мы здесь про настоящие ide" или вообще, что даже не редактор, а мы не поняли что это. Ну хоть про vim в статье вспомнили :) Успешного вам программирования в Microsoft Word!
PuerteMuerte
31.07.2023 13:04+1GNU/Emacs как всегда не существует.
Здесь была статья не "справочник всех существующих IDE", а всего лишь описание некоторых IDE, которые, по мнению автора, оказали существенное влияние на подходы к разработке софта. Почему бы в этот список включать Emacs, который абсолютно справедливо как инструмент разработки не был инновационным, не понятно.
K0styan
31.07.2023 13:04+1Вот как раз Emacs (правда, не GNU/Emacs, а оригинальный) в 70-х был революционным. Точнее так: он был одним из нового поколения редакторов кода, которые наконец-то позволяли просто набирать символы в том месте, где он должны были появляться, и при этом они появлялись сразу после нажатия. Один из - но самый известный и до сих пор живой.
Я поработал, правда, только в формате институской лабораторной на старом терминале с более древним редактором. Каждая строчка кода добавляется отдельной командой. Посмотреть, что в результате получилось, можно только выполнив другую команду. Можно заменить любую строчку новой, а вот вставить новую между, скажем, 3-й и 4-й (чтобы новая стала 4-й, а та сместилась на 5-ю) - уже нельзя. Поэтому между каждой строчкой с рабочим кодом напихивалось 2-3 nop-а, на случай, если на их место понадобится что-то ещё вписать.
То ещё удовольствие. Просто редактор "жмёшь кнопки - видишь буквы" - уже революция после тех терминальных штук.
unreal_undead2
31.07.2023 13:04Каждая строчка кода добавляется отдельной командой. Посмотреть, что в результате получилось, можно только выполнив другую команду.
Бейсик на 8битных компьютерах практически всегда так работал.
GospodinKolhoznik
31.07.2023 13:04Вот Бейсик на 8битках, это же была IDE по-совместительсву ОС. И как по мне, эта концепция ось-ide была довольно уютной.
unreal_undead2
31.07.2023 13:04+1Уже вспомнили лисп машины и Smalltalk, где эта концепция в те же времена была ещё и полнофункциональной с нормальными редактором/дебаггером и т.д. А так ввести сразу после включения компьютера 10 PRINT 2+2 конечно удобно, но что-то потяжелее набирать по строчкам так себе - Turbo Basic с нормальным редактором кода после этого казался чудом )
K0styan
31.07.2023 13:04Был БК0010-01, но тамошние нюансы уже стёрлись из памяти. Помню только команду REN, которая переименовывала все строки с шагом 10, именно чтобы промежуточные типа 15-25-35 втискивать.
IvanPetrof
31.07.2023 13:04А ссылки в GOTO перебивались?
unreal_undead2
31.07.2023 13:04Да, иначе какой смысл ) Но в ранних Бейсиках (и на Фокале в оригинальной БК 0010) такого не было.
Gummilion
31.07.2023 13:04Подозреваю, что это был ed или какая-то из его модификаций (а в ранних версиях MS-DOS его аналог назывался edln). Да, по сравнению с таким даже vi был гигантским прыжком вперед.
unreal_undead2
31.07.2023 13:04В ed'е всегда можно вставить строчку в любое место (команда a или i). А edlin до 32-битной Windows 10 дожил.
eugeneyp
31.07.2023 13:04+3А где Paradox, JBuilder, QBasic?
JBuilder для первого выпуска был на уровне Delphi, dbSwing позволяли делать UI с работой БД не намного хуже Delphi. И в 97-м году Wizards позволяли быстро делать стартовое приложение. Сейчас он мутировал в Oracle JDeveloper.
Нет ни одного IDE для ассемблера, Tasm и т.п. это тоже был прорыв.
Статья оставляет впечатление что составлен список IDE, которые повлияли на развитие ПО автора статьи.
SpiderEkb
31.07.2023 13:04+1Немножко все в кучу смешали.
На мой взгляд тут два направления
IDE, входящее в состав какого-то продукта и заточенная исключительно под этот продукт. Со времен DOS - продукты линейки Turbo от Borland - Basic, Pascal, C, C++ - все они включали в себя то, что сейчас принято называть IDE. Но оно было заточено и плотно интегрировано с конкретным компилятором.
Туда же - Clarion, FoxPro и иже с ними.
Аналогично линейка Quick от MS
Позже, Под Win - Delphi/CBuilderIDE, которые настраивались под любой язык/компилятор. Первая ласточка - MultiEdit. Далее - Eclipse, VSC, vim, emacs...
Тут IDE само себе самостоятельный продукт с возможностью подключения плагинов для интеграции с нужными языками - синтаксис, линтеры, системы сборки, отладчики и т.п.
Это все-таки разные направления и разные концепции.
ss-nopol
31.07.2023 13:04+1Первая ласточка - MultiEdit. Далее - Eclipse, VSC, vim, emacs...
Всё же первый в этом списке Emacs. Multiedit появился позже.
VladimirFarshatov
31.07.2023 13:04Я бы выделил третье направление: ИДЕ + ОС или частично. Интеграция средств разработки с элементами сборки, запуска, отладки, линковки .. Тут, кмк, порядок все же такой:
Фортран-2 Ершова (1979, когда работал с ним, но оно раньше)
Смалталк
Рапира, Школьница
aax
31.07.2023 13:04-3Как vim удалось выжить, учитывая множество появившихся за эти годы современных IDE? На мой скромный взгляд, потому что он не навешивет на Ваш исходник кучу скрытых от разработчика непрозрачных прослоек, сильно тормозащих написанное ПО.
Тоесть концепт многих современных IDE, это популярно говоря ультимативный "java-стайл", когда независимо от Вашего желания в угоду преносимости кода фатально снижается его производительность. Отсюда и довольно типичный результат, когда для того же самого функционала системные требования ПО растут, с годами, в десятки раз.
Особенно чувствителен эффект "современных IDE" во встроенном ПО микроконтроллеров, причем если к Arduino-IDE, заточенной под первоначальное вхождение, претензий нет, то к STM-овской Cube-IDE, предназначенной вроде как не только начинающим, вопросы уже есть.
MiraclePtr
31.07.2023 13:04+2в угоду преносимости кода фатально снижается его производительность
Не только в угоду переносимости, еще в угоду скорости разработки и простоты поддержки/расширения этого кода.
Там, где снижение производительности фатально - там подобные языки/фреймворки не используются. Во многих случаях это не фатально.На мой скромный взгляд, потому что он не навешивет на Ваш исходник кучу скрытых от разработчика непрозрачных прослоек, сильно тормозащих написанное ПО.
Vim и Emacs в этом плане вообще ничем не отличается от какого-нибудь Visual Studio Code, CLion или любой другой IDE. IDE - это просто продвинутый редактор текста с функциями навигации, рефакторинга и интеграцией других инструментов (например, отладчика).
Вы путаете IDE и рантаймы/фреймворки/кодогенераторы.aax
31.07.2023 13:04-2Не думаю, что я что-то путаю фраза звучит "Как vim удалось выжить, учитывая множество появившихся за эти годы современных IDE?". Что же касается "Cube-IDE", "Arduino-IDE", то эту устоявшуюся классификацию и терминологию, как вы понимаете не я сегодня изобрел. А вопрос мой "Cube-IDE" сводится к тому, что эта официальная вендорская IDE заточена лишь под "java-стайл". Иной стиль написания программ в ней не назовешь удобным и практичным.
SpiderEkb
31.07.2023 13:04Не только в угоду переносимости, еще в угоду скорости разработки и простоты поддержки/расширения этого кода.Там, где снижение производительности фатально - там подобные языки/фреймворки не используются. Во многих случаях это не фатально.
Там куча аспектов - абстракции (которых может быть много уровней), универсальность (когда используются некие "усредненные" алгоритмы, дающие наилучший результат на широком спектре структур данных, но проигрывающие в случае какой-то конкретной структуре специализированным алгоритмам) или когда определение в рантайме "а с чем же мы сейчас работаем" привносит некоторый оверхед, "безопасность" - специально дать разработчику затупленный нож чтобы не дай бог не порезался...
В среднем это не сильно заметно до тех пор, пока не встает вопрос о предельной эффективности.
Но все это относится в первую очередь к фреймворкам, но не к IDE, которые по сути есть текстовые редакторы со специфическими возможностями и расширениями.
aax
31.07.2023 13:04-2Строго по определению IDE — это интегрированная среда разработки, (integrated development environment). Она может быть минималистичной, а может включать в свой состав фремворки и прочие средства разработки ПО.
aax
31.07.2023 13:04-1Про "Не только в угоду переносимости, еще в угоду скорости разработки и простоты поддержки/расширения этого кода" благодарю за развитие мысли. Это тоже ультимативный "java-стайл". Другой вопрос, java-стайл, несмотря на ряд его достоинств далеко не универсален.
mayorovp
31.07.2023 13:04+1Под словом "integrated" всё же обычно понимают интеграции с компилятором, отладчиком, гитом, облачными хостингами — всё то что используется в процессе разработки ПО.
Фреймворки и библиотеки никогда частью IDE не являлись, как и средствами разработки.
SpiderEkb
31.07.2023 13:04Для некоторых фреймворков таки делаются заточенные под них инструменты. Например, QTCreator, wxFormBuilder...
mayorovp
31.07.2023 13:04Да, но это всё равно инструмент для фреймворка, а не фреймворк как часть инструмента.
Писать программу использующую QT можно хоть в QTCreator, хоть в Visual Studio, хоть в vim.
И я несколько сомневаюсь, что в QTCreator так уж невозможно написать программу, которая QT не использует.
SpiderEkb
31.07.2023 13:04Да, но это всё равно инструмент для фреймворка, а не фреймворк как часть инструмента.
Да, так. Инструмент в дополнение к фреймворку. В целом можно тоже рассматривать как IDE для конкретного фреймворка.
Ogra
31.07.2023 13:04+1Несколько не соглашусь. Вот тот же Delphi - он же не с гитом интегрировался, а с визуальным редактором для VCL - а ведь это фрэймворк.
Все же IDE - это немножко больше, чем текстовый редактор с расширениями.
HemulGM
31.07.2023 13:04+1А я с вами не соглашусь.
1. Delphi (RAD Studio), интегрирован и с гитом. Да, там есть инструменты для работы с контролем версий из коробки.Ещё там есть даже возможности визуального проектирования классов (диаграммы)
VCL в среде интегрирован снаружи (с помощью пакетов), а не изнутри среды как часть среды. Из коробки, да. И частично интегрирован и изнутри (но это не точно), возможно убрав пакеты страницы в общих настройках тоже просто исчезнут.
Фреймворк можно интегрировать в любой момент на достаточно глубоком уровне. Например, есть фреймворк FGX, который предоставляет очень большие возможности при работе со средой. Там своя большая экосистема (ссылка).
Как и сам FMX, который из коробки встраивает свой собственный дизайнер. А ведь есть и много других фреймворков с интеграцией (UniGUI, TMS Web Core и другие). И все они наполняют среду в момент работы с проектом своим инструментарием (не говоря уже о компонентах).
По сути, RAD Studio может заменить QtCreator, если написать расширение для него. Интегрировать в настройки в рантайм (в рантайм IDE). И так далее.
И для этого даже не надо согласовывать с разработчиками среды. IDE имеет большое API.
Ogra
31.07.2023 13:04А когда в Дельфи появились инструменты для работы с контролем версий из коробки? Кажется, уже после заката популярности.
HemulGM
31.07.2023 13:04Если верить docwiki, то в 2016 всего лишь. Да и в целом, большая часть инструментов появилась после 2010 года.
Ogra
31.07.2023 13:04+1Я в википедии нашел Subversion в 2010 году ( https://en.wikipedia.org/wiki/History_of_Delphi_(software) ) . При том, что я что-то там писал на Дельфи 7 в 2002-2003 годах, и вот тогда Дельфи - это было круто. Так что я все еще остаюсь при своем мнении, что IDE вполне могут включать в себя фреймворки и инструменты для работы с ними.
HemulGM
31.07.2023 13:04Могут, не спорю. Какие-то IDE только для одного фреймворка и делаются. Но это очень хорошо. И я рад, что в Delphi с этим всё нормально.
PuerteMuerte
31.07.2023 13:04+1А когда в Дельфи появились инструменты для работы с контролем версий из коробки?
Ну как бы "из коробки" - не особо-то и принципиально. У Delphi ещё более двадцати лет назад был Devrace Athlant, который стоил недорого, интегрировался с разными системами контроля версий, делал это прозрачно и прямо из окна проекта, когда сие вообще не было мейнстримом в других системах.
WASD1
31.07.2023 13:04+1Ни приоритеты ни логика не ясны. На первых местах стоят не прорывные, а просто "неплохие" технологии которые всплыли когда звёзды сошлись. По-моему так быть не должно.
Как должен выглядеть список по моему мнению:
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 дело не дошло.
Ogra
31.07.2023 13:04Ваш список неверен. Я пробовал все IDE из этого списка ;) И я уверен, что многое великое здесь пропущено просто по той причине, что не может такого быть, чтобы я знал все "революционные IDE, повлиявшие на разработку ПО". Тот же Smalltalk, упомянутый в статье, появился до моего рождения.
И уж точно не Visual Studio Code записывать в революционные. LSP - эволюционная фича, логичное развитие идей Eclipse.
WASD1
31.07.2023 13:041. 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".
unreal_undead2
31.07.2023 13:04Такие рекламные ролики такие недостатки не показывают
Smalltalk скорее опередил время - требовал достаточно дорогую железяку, причём ещё и в однопользовательском режиме. У Apple сделать более-менее доступную копию компьютера с подобным GUI удалось только со второй попытки, а уж про ООП и IDE Джобс вспомнил только когда его из Apple выгнали ) Форт наоборот - хорош для небольших проектов на маленьких компьютерах, на промышленную разработку большими командами не особо масштабируется.
ilriv
31.07.2023 13:04+2Delphi приспособлен к написанию больших программм. Система пятнадцать лет не развивалась из-за того что команда тратила свои скудные ресурсы на .NET, и всё равно оставалась достаточно актуальной.
Borland/Codegear/Embarcadero это всё-таки не Microsoft, не Apple, не Sun/Oracle. Им надо было либо уходить в opensource, либо искать партнёров.
В идеальном мире можно было бы себе представить альянс Borland/Nokia/Red Hat для адаптации Delphi под Linux и превращения Delphi в основную систему программирования под Linux.
PuerteMuerte
31.07.2023 13:04+2Им надо было либо уходить в opensource, либо искать партнёров.
Им надо было всего лишь продолжать совершенствовать линейку Delphi 7, не метаясь в стороны с экспериментами, а также не уничтожать вход для новых специалистов, полностью отказываясь на полтора десятилетия от доступных community-редакций. Ну, точнее, она там формально была, но ни для разработки, ни для обучения в принципе не годилась, ни по лицензии, ни по функционалу.
Delphi стала мегапопулярной, когда полнофункциональная редакция стоила $50. А потеряла всю свою популярность, когда самая минимально пригодная редакция стоила $700.
HemulGM
31.07.2023 13:04RIP Delphi - ты не смог приспособиться к написанию больших программ.
Ну это ложь)
event1
31.07.2023 13:04+2Eclipse, по сути, стала первой IDE, нацеленной на многоязычность, многоплатформенность и многофункциональность
А до этого сиволапые и не знали про многоязычность, многоплатформенность и многофункциональность. Двумя абзацами выше автор (справедливо) пишет про vim, который работает на любом утюге, но это, видимо, не та многоплатформенность. Емаксу, c ~6k плагинами до великого Иклипса с 1200 плагинами, в плане многоязыности и многофункциональности, видимо тоже, как до Китая пешком.
Ну и великий VS, который всего за 20 лет заборол Борланд на собственной платформе, и то, только потому, что заставил всех использовать закрытую технологию, конечно на первом месте. Как сейчас помню: после многих лет на Дельфи, запускаю MS Visual Studio C 6.0, а он (внезапно) оказывается ни хрена не Visual. Контролы на форму мышкой затащить нельзя! Надо было создавать ресурсы и писать какие-то магические файлы, чтобы они компоновались. Хорошо хоть этот позор пришлось делать только один раз.
SpiderEkb
31.07.2023 13:04после многих лет на Дельфи, запускаю MS Visual Studio C 6.0, а он (внезапно) оказывается ни хрена не Visual. Контролы на форму мышкой затащить нельзя! Надо было создавать ресурсы и писать какие-то магические файлы, чтобы они компоновались. Хорошо хоть этот позор пришлось делать только один раз.
Да ладно?
Я с ними мало работал, на Win 3.11 только. Там был MSVC 1.52 (и том же дистрибутиве шел MSVC 2.0 для WinNT 3.5).
Так вот там все это было можно. Все это делалось вполне себе визуально. Мышкой. И, кстати, приложения были "легче" чем в Builder'е. Потому что в билдере все настряпанные формы создавались сразу при старте приложения и висели невидимыми в памяти (для иного подхода надо было специально ручки приложить). MSVC честно создавал форму только когда это нужно и при закрытии прибивал ее.
MSVC была оберткой над стандатрными виндовыми контролами, в билдер что-то такое свое изобретал (и не все свойства виндовых контролов были доступны - иногда приходилось несколько химичить).
Ну и там еще был ряд идеологических различий.
Честно скажу - MSVC мне нравился больше.
Gummilion
31.07.2023 13:04Не, мышкой в Visual studio что-то можно было рисовать, но по-моему редактор ресурсов там был отдельным приложением. И чтобы потом использовать эти формы в коде - была куча Wizard-ов, которым надо было указывать, что с чем связывать, без мануалов там фиг разберешься, как это делается.
HemulGM
31.07.2023 13:04+1И, кстати, приложения были "легче" чем в Builder'е. Потому что в билдере все настряпанные формы создавались сразу при старте приложения и висели невидимыми в памяти (для иного подхода надо было специально ручки приложить). MSVC честно создавал форму только когда это нужно и при закрытии прибивал ее.
Ручки приложить? Это кнопочку одну нажать что ли?
Это дело пяти секунд и 4 кликов.
PuerteMuerte
31.07.2023 13:04Так вот там все это было можно. Все это делалось вполне себе визуально. Мышкой. И, кстати, приложения были "легче" чем в Builder'е.
Особо ничего там визуально не делалось, только редактор ресурсов был, в котором можно было диалоговый ресурс состряпать на языке описания ресурсов. Но визуальный редактор ресурсов был и в турбо-паскале. Да, создать диаложек из ресурсов, сие для винды проще, чем создавать его программным путём, ну и кода в вашем приложении меньше получается, вы по сути скармливаете описание формы винде, а она по нему там создаёт диалог. Но зато и контроля над созданной формой у вас намного меньше.
По сути, реально визуальным в ранней Visual Studio был только редактор Visual Basic.
perfect_genius
31.07.2023 13:04запускаю MS Visual Studio C 6.0, а он (внезапно) оказывается ни хрена не Visual.
Тоже очень удивил этот обман.
AzatJ
31.07.2023 13:04+1Не понятно почему Visual studio и VsCode вместе, между ними столько же общего как у java с javascript
john1
31.07.2023 13:04+1Многие помнят браузерные войны той эпохи, однако разработчики вспоминают и войны IDE, происходившие в то же время между Microsoft и Borland.
Ох, эти священные войны на популярных тогда форумах... сколько бессонных ночей было потрачено на доказывание оппоненту, что
мой папа круче твоегомой ЯП / IDE круче твоего!К слову сказать, про Delphi и C#, так как там и там выступал один и тот же автор - Андерс Хейлсберг, и я, как сторонник Delphi, в время тех священных войн изучал "противника" и с удивлением обнаружил тогда, что все интересные фичи Андерс забрал с собой из Delphi в C# (сейчас вспомню только property, но список у меня был большой), более того сама IDE Visual Studio чуть ли не дословно повторяла Delphi (т.е. открыв в первый раз VS - ты себя чувствовал как рыба в воде), а архитектура для написания расширений для IDE и вовсе дословно копировала из Delphi даже имена методов. Понятно, что всё это было ярко заметно только на тот момент, сейчас и VS и C# ушли очень далеко, и теперь уже Delphi их копирует, но справедливости ради, когда говорят что C# это какая то компиляция C++ и Java - это немножко неправильно, всё таки папой больше был Delphi.
PuerteMuerte
31.07.2023 13:04+1C# это какая то компиляция C++ и Java - это немножко неправильно
Именно так, в C# от C++ нет вообще ничего, ни в парадигме программирования, ни в синтаксисе языка. C#, это гибрид Delphi и Java.
NeoCode
31.07.2023 13:04+2Кстати, по разнице дизайна тогда и сейчас. Вот на самом первом скриншоте (ToolBook) - там скорее всего 16 цветов, шрифт конечно ужасный, но насколько же классные там кнопки на тулбаре! Прямо так и хочется мышкой их нажать. А сейчас с современными разрешениями и truecolor - вроде и шрифты нормальные, и тёмные темы научились делать, а вот от тулбаров с хорошими жирными кнопками к сожалению отошли, как и вообще от четкости в GUI.
osipov_dv
сказать что я удивлен, не увидев turbo c/pascal от борланда под дос, ничего не сказать.
martyncev
del
DennisP
А также Microsoft QuickBASIC
buratino
и QuickC
gev
GW Basic =)
DennisP
IDE с обязательными номерами строк :)
gev
аахахах
cher-nov
Это Вы ещё JPI TopSpeed не видели...
https://web.archive.org/web/20120111161303/http://www.nf-team.org/drmad/stuff/t.htm
unreal_undead2
Про TopSpeed в своё время только читал, как и большинство людей вокруг, а вот с Turbo C/Pascal многие начинали более-менее серьёзное программирование, помыкавшись до этого с Бейсиком/Фокалом...
Komrus
С Fortran'ом, с fortran'ом перед этим помыкавшись. На ЕСках :)
После чего Turbo Pascal - как манна небесная был :)
unreal_undead2
У меня фортран на EC 1045 и Turbo C на писишках были примерно в одно время )
Stawros
Ещё в школе наткнулся на отличную русскоязычную справку в Турбо Паскале с гиперссылками и примерами, что сразу сподвигло изучать язык и программирование в частности даже за пределами преподаваемого на уроках. Думаю если бы не это, то я бы и не стал программистом.
asso
Мне повезло еще больше. Я не наткнулся на русскоязычную справку в Турбо Паскале. Из-за это приходилось читать её на английском. Так я и выучил английский. В жизни очень пригодилось :)
PuerteMuerte
Для этого надо было, чтобы Паскаль соседствовал с каким-то переводчиком на компьютере, потому что в обычных бумажных словарях лексики не хватало. Русскоязычная справка действительно рулила. В моём случае это был Турбо Паскаль 5.5, когда электронных переводчиков вообще практически не было, только какие-то примитивные подстрочники, и то, фиг найдёшь дискетку на рынке.
asso
У меня был только бумажный советский словарь. Слов не хватало, но догадаться из контекста было можно. Необходимость листать бумажные страницы в поисках нужного слова хорошо стимулировала память. Так по справке и примерам освоил Turbo Vision. А потом появился Delphi и все добытые в боях со словарем знания библиотек отправились на свалку истории, а английский язык остался.
PuerteMuerte
Я разачаровался в этом подходе буквально сразу же, на первой ошибке Invalid media type.
unreal_undead2
У меня такое ощущение, что смысл всех этих слов интуитивно воспринял по компьютерным сообщениям/хелпам. Программировал на Turbo C в старших классах, словаря под рукой не было, только бумажная книжка собственно по C, школьной базы хватало, чтобы додуматься до смысла непонятных слов.
klirichek
У нас вроде был Фаронов. И это было ещё время бумажных книг (в аккурат 30 лет назад). Сам турбо-паскаль продавался в книжном магазине - в виде коробки с кучей установочных дискет.
EevanW
Borland немалую толику своей популярности получил именно за обширную встроенную документацию в своих продуктах, которая на тот момент превосходила всех.
Nagisa
Согласен, и совсем странно не увидеть тут мощнейшую IDE проектирования баз данных - Clarion for Dos 2.1 (1989). Все проектирование - визуальное, даже поздний FoxPro не смог догнать.
SpiderEkb
Уже вспомнили :-)