В 90-е годы это название знали все. Даже те, кто не пользовался Паскалем. В течение почти 20 лет Турбо Паскаль преподавали в школах и техникумах, иногда в институтах.
Как минимум полтора десятка лет другой их продукт — Delphi — был одной из самых известных и популярных у нас в России сред разработки. И, кстати, живет до сих пор.
Как же получилось так, что фирма, создавшая два, можно сказать, революционных продукта — исчезла без следа? Я расскажу свою версию. С моей точки зрения, это рассказ о роли личности руководителя в судьбе фирмы.
Первая встреча с Turbo Pascal
Я впервые увидел Turbo Pascal 5.0. в 1989 году, на первой «своей» IBM PC XT. Тогда для меня это было что‑то на грани чуда.
Ведь как в те времена делалось «в норме»:
Запускаем текстовый редактор и пишем/правим текст программы.
Сохраняем, закрываем редактор.Запускаем транслятор (сейчас говорят компилятор), указывая в виде аргумента файл с текстом программы.
Если в программе нет ошибок — получаем так называемый объектный модуль, содержащий алгоритмы нашей программы в машинных кодах, но без привязки к адресам в памяти.Запускаем линкер (редактор связей), указывая ему файл(ы) с объектными модулями, он собирает их в готовую программу, устанавливая адреса для каждой переменной и каждой подпрограммы, и указывая эти адреса там, где эти объекты вызываются.
Теперь программу можно запустить на выполнение.Запускаем программу, проверяем, как она работает.
Ну, если работает не так — понятное дело, правим. т. е. повторяем весь цирк сначала.
А чаще всего уже на шаге 2 сталкиваемся с тем, что транслятор обнаруживает ошибки в тексте, и выдает в отдельный файл — в строке ХХХ у вас какая‑то фигня, а в строке YYY нет точки с запятой. И теперь надо открыть редактор, найти эту строку, и исправить ее.
Запустив Турбо‑Паскаль, ты работаешь в текстовом редакторе. И не выходя из него, можешь нажать одну клавишу — чтоб программа откомпилировалась и запустилась.
Завершив прогон программы — возвращаешься в редактор.

Если у тебя в тексте программы что‑то не так — тебе не сообщают об этом. Не заставляют искать в тексте ту ошибочную строку. Тебя сразу автоматически отправляют на ту строку, где ошибка, остается только исправить ее. В общем, если до этого задача «скомпилировать написанную программу» занимала неделю, то теперь это делалось за два часа.
Потом выяснилось еще много интересных вещей — тут, оказывается, можно выполнять программу по строкам, на ходу выяснять значения переменных, и даже менять их, и многое‑многое другое. Но это было уже привычное — у нас прекрасный инструмент, он, оказывается, теперь умеет еще и вот это. Но вот это первое ощущение чуда — мне дали в руки инструмент, и я почувствовал себя всемогущим — запомнилось на всю жизнь.
В общем, на фоне привычных компиляторов Турбо Паскаль смотрелся как пулемет Максима среди дульнозарядных мушкетов. И было понятно, почему его так назвали. Также понятно, почему он получил такую популярность у начинающих программистов, а также преподавателей и студентов.
За его скорость и удобство ему можно было бы простить многое — даже если бы это был «игрушечный» компилятор, способный откомпилировать и собрать только маленькую учебную программу — популярность была бы ему обеспечена. А уж если этот инструмент мог создавать более‑менее крупные программы с приличным качеством — его производитель, наверное, должен был бы озолотиться? Ну, давайте познакомимся с теми, кто это сделал.
1981 Основание фирмы Borland
Сама фирма началась с того, что в 1981 Нильс Енсен (Niels Jensen), Оле Хенриксен (Ole Henriksen) и Могенс Глад (Mogens Glad) основали компанию MIT — Market In Time.
Чем именно они будут заниматься — парни и сами пока не знали, они просто верили в персональные компьютеры, в свои силы и в свою удачу. И поначалу они просто писали программы для малых машин под управлением ОС CP/M.
В 1982 они посетили выставку CP/M-82, проходившую в Сан‑Франциско. И сделали вывод, что если они хотят продавать свои программы в США — им надо иметь американскую компанию, располагающуюся в США, а не в Ирландии.
Кан-варвар из дикого леса
А еще они познакомились с Филиппом Каном. Который в то время имел хулиганские склонности, ездил на мотоцикле, играл на саксофоне, имел высшее образование в области математики и оконченную консерваторию, жил в США нелегально, поскольку не имел грин‑карты… Зато он очень хорошо представлял, чем он хочет заняться для того, чтоб заработать денег.
Так что наши три датчанина приняли его в свою фирму. И саму фирму переназвали. Вроде как именно Кан предложил название Borland, означавшее на кельтском «лесная страна».
Надо сказать, Кан всегда отличался любовью к неординарным решениям на грани хулиганства, к нарушению правил, что с одной стороны осложняло его взаимодействие с другими владельцами фирмы, с другой стороны часто обеспечивало успех его начинаниям.
Одна из статей о нем (к тому времени уже директоре Борланда, богатом и знаменитом) так и называлась — «Кан‑Варвар» (Kahn the Barbarian).
Доли капитала в Borland были распределены так: Niels Jensen (250,000 акций), Ole Henriksen (160,000), Mogens Glad (100,000), Kahn (80,000). т. е. вроде как младший партнер. Филипп Кан становится президентом и генеральным директором (CEO) фирмы Borland, и в этой должности он будет 12 лет, до 1995.
1983 Появление Turbo Pascal
А идея у Кана была, собственно, в том, чтоб сделать удобную среду разработки. И еще хотелось быстрый компилятор, чтоб не приходилось идти курить, пока он пережевывает текст твоей программы.
В сущности, тут вроде ничего нового или революционного не было. Эта идея носилась в воздухе. Да, собственно, уже существовавший к тому времени Бейсик можно считать воплощением этой идеи. Но у Кана это действительно получилось, и получилось так хорошо, что его вариант стал по сути образцом для всех будущих.
Итак, в 1982 Кан начинает двигать свое направление, и находит талантливого программиста, тоже увлеченного этой идеей. А самое главное — этот программист уже сделал свою версию компилятора Паскаля под ОС CP/M. Теперь они начинаю делать Паскаль под MS DOS, и не просто компилятор, а именно среду разработки. И в 1983 у них выходит первая версия.

1982 В Borland приходит Андерс Хейлсберг (Anders Hejlsberg), разработчик Blue Label Pascal.
1983 Выпущена первая версия Turbo Pascal.
Название хорошо отражает основную суть. Компилятор был очень быстрым. У нормальных людей компиляция программы занимала от 5 минут до получаса, в Турбо Паскале же компиляция занимала не более 5 секунд. Надо сказать, Борланд всегда отличалась меткими названиями.
Новый продукт предполагалось продавать учебным заведениям. По недорогой цене. $49.99. При стоимости нормальных профессиональных компиляторов порядка $300.
Емкость рынка в первом приближении оценивалась в 30 000 потенциальных покупателей. Ну, т. е. если все они купят новую программу, то фирма получит полтора миллиона долларов. В реальности, естественно, купят далеко не все.
В реальности в первый месяц продаж Борланд набрал 3000 покупателей. Соответственно, 150 000 долларов.
Местные банки даже стали отказываться оплачивать чеки и кредитные карточки, подозревая компанию в мошенничестве.
Через два года (1985) журнал Байт сообщил о «поразительной для компьютерного языка цифре» в 250 000 экземпляров. (т. е. в 8 раз больше максимальной первоначальной оценки!).
Это 12 с половиной миллионов долларов. Определенно, это был оглушительный успех!
Еще через полгода цифры достигли 400 000 проданных экземпляров и, соответственно, 20 миллионов долларов.
1985-1990 Рост и развитие
Последующие годы фирма активно развивает направление средств разработки. Появляются несколько языков со знакомой средой разработки — Turbo Basic, Turbo Assembler, Modula 2, Turbo Prolog, Turbo C (позже Borland C).
Идет активное соревнование с Microsoft в этой области, до середины 90-х.
В 1990–92 в Паскале появляется объектно‑ориентированное программирование. И следом — объектно‑ориентированная библиотека Turbo Vision, предназначенная для разработки современных (на то время) программ с окнами, меню, контекстной гипертекстовой подсказкой и т. д.
В Turbo Vision содержится красивая стройная концепция управления окнами, элементами окна, проверки вводимых в окно данных, взаимодействия элементов. В результате разработка таких программ становится намного проще и быстрее. В то же время сам Turbo Vision мог служить прекрасным примером — что такое ООП, зачем оно нужно, и как его применять. Многие программисты на нем учились, несколько программистов пытались сделать из него графический пакет. Одна из крупнейших программистских фирм нашего города продолжала писать программы с использованием Turbo Vision аж до начала 2000-х, когда уже всюду стоял Windows.
Cобственно, на том же Turbo Vision была сделана новая интегрированная среда Turbo Pascal 6.0. Это характерный для Borland подход — самим пользоваться тем, что они разрабатывают на продажу. При таком подходе продукт действительно получается удобным и качественным, потому что разработчик сам видит, что в его изделии удобно, а что можно улучшить, и он же имеет все средства чтоб улучшить его. Наверное, именно поэтому все продукты Борланда отличаются высоким качеством и удобством.
Кроме того, развиваются еще несколько продуктов совершенно других направлений:
Eureca — пакет для решения дифференциальных уравнений;
SideKick — нечто вроде пакета офисных программ, включая текстовый редактор, календарь, калькулятор, адресную книгу и телефонный номеронабиратель;
Quattro Pro — электронная таблица.
Похоже, что руководители фирмы, заработав на Турбо Паскале, хотят вложить эти деньги в развитие, и пытаются развивать любое направление, потенциально сулящее перспективы. Вот только не могут выбрать — в каком именно направлении развиваться? — и пытаются развиваться во всех направлениях одновременно.
Конкурируют с Microsoft в области языков разработки. Надо сказать, достаточно успешно. Аж до конца 90-х. (И даже, пожалуй, до конца 2000х, но это уже другая история.)
Осваивают область разработки баз данных, в которой на то время катастрофически не хватает нормальных языков разработки алгоритмов и весьма бедно по части средств ввода данных. Тут Борланд предпринимает несколько крупных шагов, невзирая на затраты.
Приобретается Ansa Software и ее СУБД Paradox. Через некоторое время появляется выделенный пакет библиотечных функций Paradox Engine, который можно использовать для работы с Парадоксовскими таблицами из программ на C и Паскале.
В 1991 покупается Ashton‑Tate — производитель знаменитого DBase. А значит, надо либо как‑то объединить эти два продукта — DBase и Paradox — в одну концепцию, либо они будут конкурировать между собой, съедая деньги фирмы.
(Помимо этого, Ashton‑Tate на тот момент владеет еще одной СУБД — InterBase, это уже полноценный сервер баз данных, работающий в клиент‑серверной архитектуре, поддерживающий большие СУБД и способный на тот момент конкурировать с недавно появившимся MS SQL Server. Но работать с ним надо уже принципиально по‑другому, не так, как с DBase и Paradox: если первым надо давать команды типа «перейди на следующую запись», «удали запись», «прочитай поле Х текущей записи» и т. п. — то взаимодействие с InterBase полностью основано на отправке SQL‑запросов, которые уже выполняются этим сервером БД, при непобходимости посылая в ответ небольшую порцию данных. т. е. совсем другая логика построения программы, другие возможности. Можно сказать, что DBase и Paradox — это «игрушечные» СУБД, упрощенно реализующие функции работы с таблицами на уровне файлов; InterBase же — уже вполне «взрослая» СУБД, работающая по современным стандартам и сравнимая по возможностям с ведущими на то время Oracle, DB/2, и пытающимся дотянуться до них MS SQL Server.)
Кан пытается объединить направление языков разработки и направление баз данных, команду Turbo и команду DBase, но это ему не удается. Слишком разные команды, слишком много людей, слишком много функционала нужно объединить и привести к какому‑то общему знаменателю. Это в конце концов приводит к финансовым проблемам и вынужденным сокращениям персонала в начале 90-х.
Microsoft же активно включается и в это соревнование, приобретя Fox Software и его Fox Pro — клон DBase, который он далее много лет развивает. (Параллельно разрабатывая MS SQL Server и MS Access). В общем, в области разработки СУБД у них идет конкуренция, сравнимая с Курской Дугой…
А еще один фронт конкуренции разворачивается в области офисных пакетов. Microsoft начинает продвигать свой MS Office. Borland заключает соглашение с Word Perfect и начинает разработку и продвижение Borland Office, включающих в себя текстовый процессор Word Perfect и электронную таблицу Quattro Pro.
Надо сказать, меня удивляет то, что Borland, при несопоставимости размеров, мало того что конкурировал с Microsoft — он в некоторых сферах еще и конкурировал более успешно!
1993 Империя наносит ответный удар
А в 93 примерно годах случается MS Windows 3.1. Стремительно завоевав популярность и заставив Турбо Паскаль (и прочие среды разработки) мгновенно морально устареть.
Теперь надо программировать под Windows! Потому что там не только окошки и графика «как у Макинтоша». Там еще и многозадачность, и управление памятью (до 16 мегабайт на процесс! до 256 мегабайт на машину! да столько вообще не бывает!), и общие средства взаимодействия программ, и многое‑многое другое.
Требуется новая среда разработки. Которая позволит с приемлемой скоростью разрабатывать программы под Windows. Потому что «каноническим способом», рекомендованным Microsoft, программа в одно окно содержит до трех тысяч строк кода и требует, соответственно, месяц работы. (В то время как на Паскале с использованием Turbo Vision программу с парой окон можно сделать за день. Но — только под DOS.)
Судя по всему, Борланд серьезно занялся направлением быстрой разработки под Windows, и в 1992 выпустил Object Vision — инструмент для разработки несложных приложений под Windows. Там окно можно было собрать мышкой из стандартных элементов буквально за полчаса. Вот только работало медленно, и в плане разрабатываемого функционала было чрезмерно скромно. Поэтому не пошло. Тем более, что и стоимость была — 495 долларов. Это вам не 49 баксов за Турбо Паскаль! Пользователи громко роптали. Цена была уменьшена до 250 долларов. Но это не помогло.
Я помню растерянность и разброд среди программистов Паскаля тех лет. Кто‑то переходил на C, чтобы научиться писать под windows. Кто‑то использовал только что появившийся Visual Basic, поскольку он позволял что‑то сделать под Windows. Кто‑то вообще уходил из программирования. Один мой друг занялся администрированием Юникса, и с тех пор к программированию так и не вернулся.
На рынке средств разработки СУБД воцарился MS Fox Pro, сначала в DOS‑версии, а с января 1993 — под Windows, называясь теперь уже Visual Fox Pro.
1995 Возвращение джедая
Давным-давно, в далекой-далекой галактике...
В 1993 году команда Андерса Хейлсберга начала разработку нового языка и новой интегрированной среды. В 1995 разработка была завершена и продукт вышел на рынок.
В 1995 Borland выпустил в продажу новый продукт — Delphi 1.0. За скромные 49.95 долларов. Что это такое — поняли не сразу.

В первую очередь - это была интегрированная среда разработки под Windows.
В которой те самые окна, называемые формами, делались очень легко. Одним пунктом меню создаем пустую форму, умеющую все, что должно уметь приличное окно.
А теперь из палитры инструментов — вон там, вверху‑справа — выбираем элементы управления — кнопки, строки ввода, галочки, меню и т. п. — и кладем на форму. И в инспекторе — вон, слева табличка — настраиваем свойства элемента.
т. е. форму (окно, диалоговое окно) мы собираем мышкой. Минуты за три можно собрать окошко. (Ну, если стараться, чтоб было красиво и удобно — то дольше, конечно).
Этот способ собирания приложений мышкой получил специальное название — RAD (Rapid Application Development).
У Microsoft такое тоже было. В флагманских продуктах того момента — Visual Basic и Visual Fox Pro. С существенными отличиями, а именно — элементы управления, используемые Basic и Fox, надо было разрабатывать отдельно, на С, по технологии COM, что требовало особых знаний и навыков.
В Delphi же эти компоненты делались на том же Паскале, что и прочие программы, и даже начинающий программист мог доработать компонент под себя, унаследовав от него свой компонент и дописав к нему нужное. Но в комплект входило и отдельное руководство по разработке компонентов.
Поэтому впоследствии программистами были написаны сотни, если не тысячи разнообразных компонентов под Delphi.
И да, это была среда с универсальным высокоуровневым языком, т. е. сделать мы тут можем примерно все что угодно, а не что‑то заранее регламентированное и жестко ограниченное, как в DBase и FoxPro.
А еще — тут был механизм доступа к базам данных. Причем, не к каким‑то конкретным, а практически к любым. Для конкретной СУБД нужно было только написать драйвер, вызывающий ее функции.
А сама программа практически не зависела от используемой СУБД. И вот это было действительно мощным шагом вперед! Как и использование языка SQL. Который тут тоже можно было использовать универсально. Как для доступа к клиент‑серверным СУБД, так и для работы с файловыми типа DBase или Paradox.
В общем, новая среда разработки решала сразу несколько давно назревших проблем:
Быстрая разработка программ под Windows
Быстрая и удобная разработка визуальной части (разработка форм на основе RAD)
Работа с базами данных. Любых форматов!
Собственно, название Delphi содержало намек на Дельфийский оракул из греческих мифов, и на название флагмана СУБД того времени — Oracle (оракул). Мол, мы вашему оракулу тут целый город построили, располагайтесь.
Кстати, новая среда была достаточно скромна в требованиях. Я ее запускал на 386-й машине с 40 MHz процессором и 4 МБ памяти. Правда, работало очень медленно. Но в документации было честно указано — требуется 8 МБ.
Позже я попробовал, и убедился, что при 8 МБ памяти работает нормально, при 12 и выше — просто летает, а еще больше ставить вроде не имеет смысла — быстрее уже не становится, даже на 32 МБ.
В отличие от MS Visual Fox Pro, где было указано требование 4 МБ, но ни на 4, ни на 8 нормально работать было невозможно. Нормальная работа Visual Fox Pro начиналась при 32 МБ, что для того времени было ну ооочень много.
1995-96 Неожиданный поворот
Вот второй раз фирма Борланд делает прорывный продукт, сравнимый, наверное, с пулеметом Максима. Конкурируя с гигантской империей Microsoft. Вот чего можно было ожидать далее?
А далее, внезапно, в том же 1995 году Филипп Кан уходит с поста генерального директора. Причина — несогласие с членами совета директоров относительно направлений дальнейшего развития фирмы.
В конце 1996 Кан окончательно покидает Борланд и организует уже другие фирмы, занимаясь совсем другими вещами.
И вот это мне совершенно непонятно. При всем сложном характере Кана, это выглядит как если б после Курской Дуги и Сталинграда товарища Жукова сняли с командования.
Видимо, основателей фирмы достало воевать, и они решили пожить спокойно, и порулить фирмой как полагается, по правилам. И дальше мы увидим, что у них получилось.
В 1996 фирму Борланд оставляет и Андерс Хейлсберг. Уходит в Microsoft. Там он будет разрабатывать новую среду разработки и новый язык. C# и Visual Studio.
Вам когда‑нибудь наниматель платил три миллиона долларов за то, чтоб вы устроились к нему на работу?
В 1996, меньше чем через год, вышла вторая версия Delphi. Выходит она в трех редакциях. Самая дешевая стоит 500 долларов. Самая дорогая — 2000.
Собственно, это практически перекрыло дорогу широкому распространению Delphi на западе. Учитывая, что Visual Basic в минимальных вариантах был доступен практически бесплатно в составе MS Office, неудивительно, что простые приложения с формами и базами данных делали на нем, а более серьезные… ну, в основном тоже на нем…
Похоже, что стратегия Кана, продававшего продукты дешево, работала лучше?
А Борланд через некоторое время заявляет, что средства разработки (Delphi, C++ Builder и прочие) отныне не являются для фирмы основным стратегическим направлением. Основным же направлением будут средства поддержки жизненного цикла разработки программ. Они даже сделали несколько интересных инструментов. Вот только ни один из этих инструментов не получил особой популярности, и ни один не прожил долго.
1996-2000 Продолжаем движение по прямой
Следующие несколько лет среда Delphi линейно развивается — появляются некоторые усовершенствования в редакторе и отладчике, но в коде сохраняются старые недоделки, и вообще возникает ощущение, что команде разработчикоов не хватает то ли людей, то ли сил, и эта нехватка чувствуется все сильнее.
Команда Delphi (все‑таки это была хорошая, сильная команда!) еще делает какие‑то шаги, вводит какие‑то новшества. Появляется MIDAS — средство для разработки клиент‑серверных программ трехслойной архитектуры, на какое‑то время появляется OLEEnterprise — пакет для разработки распределенных корпоративных приложений на основе технологии COM/DCOM, и в следующих версиях исчезает без следа.
2000 и далее – метания
В 2003 появляется Kylix — среда для разработки под Linux. И через год‑два исчезает. То есть разработчики еще несколько лет пользуются им, но новых версий уже не появляется.
InterBase в какой‑то момент становится системой с открытым кодом. Вскоре выделяется клон, называемый FireBird, и команда, которая его поддерживает — он жив до сих пор, и до сих пор его можно приобрести бесплатно. Но сам Borland через некоторое время возвращается к платному InterBase, сильно отстающему от бесплатного клона и по функционалу, и по количеству неисправленных ошибок.
Далее также однократно засвечивается интересный продукт Bold for Delphi.
Он интересен тем, что программа строится на основе UML‑модели. Исходя из той же модели строится структура базы данных и логика оперирования данными в БД‑ создание, чтение, изменение и удаление объектов (CRUD).
Можно сказать это одна из первых ORM систем. Правда, в практическом применении проявляет себя довольно слабо, работает медленно, и построение запросов осуществляется чрезмерно примитивно и потому неэффективно.
Позже появляется продолжение этой разработки — уже под.Net, называется ECO — Enterprize Core Objects. Позволяет очень быстро построить несложную программу, работающую с несколькими таблицами, автоматически построить базу данных для нее, автоматически построить формы для редактирования объектов и навигации по ссылкам.
Вот только запросы к БД строятся настолько неэффективно, что для практического применения система совершенно непригодна. И тоже существует она всего пару лет.
Microsoft тем временем выдает новую платформу для разработки,.Net. И программисты начинают переходить с Delphi на C# и Visual Studio. Сначала по одному, а с 2005–2010 — уже массово..Net становится очень популярным.
Borland выпускает новую версию среды — с возможностью разработки под.Net. Вот только если в Delphi среду снабдили набором удобных компонентов, сделавших разработку программ быстрой и удобной, то теперь на это просто не хватило сил. И пользователям предложили использовать компоненты, использовавшиеся в Visual Studio — набор «Windows Forms».
А в следующей версии его убрали, и вместо него предложили использовать библиотеку VCL.Net.
В общем, теперь поведение Borland по отношению к пользователям уже никоим образом не отражает политики совместимости со старыми версиями — наоборот, оно скорее похоже на попытки шпиона оторваться от хвоста.
На мой взгляд, такие странности в поведении говорят о глубоком кризисе руководства и неспособности управлять процессом.
Эпилог
В конце двухтысячных годов остатки компании Borland были проданы компании Embarcadero, которая и сейчас продолжает продавать продукт Delphi.
Филипп Кан, уйдя из Borland, основал еще несколько фирм. Одну из них он продал компании Motorola за 325 миллионов долларов. Позже он занялся производством фитнес‑браслетов. Похоже он в очередной раз угадал, на что будет спрос.
Вот и вся история. На мой взгляд, она о том, что успех фирмы в первую очередь зависит от того, есть ли у ее директора понимание — куда он хочет идти и вести фирму.
Комментарии (520)

BiTL
24.09.2025 00:04Неплохая ретроспектива. Поймал немного вьетнамских флешбеков.
Использовал и Turbo Basic 1.0 и Turbo Pascal 5,6,7, и Turbo Assembler, и Delphi (начиная с win 3.1).
В плане работы с БД всегда бесило, что BDE надо устанавливать отдельно, а мне всегда хотелось чтобы программа была самодостаточная :) А потом еще этот FireBird, который в таскбаре висел...
Severn Автор
24.09.2025 00:04Когда-то было такое решение, чтоб внедрить BDE-шные драйверы в программу. Но уже не вспомню, как это делалось.
Но вообще, BDE был не без глюков, я его как-то правил (были исходники), там иногда случались взаимоблокировки сессий, а у меня было трехслойное приложение... Потом вместо BDE стал использовать FIBPlus, и блокировки с зависаниями пропали.

Siemargl
24.09.2025 00:04Когда-то было такое решение, чтоб внедрить BDE-шные драйверы в программу.
через installshield делалось, была даже урезанная бесплатная express версия (или в комплекте энтерпрайз редакции шла)

BiTL
24.09.2025 00:04так это просто инсталятор, который BDE-шляпу устанавливал вместе с программой.
Я же предпочитал, чтобы вообще ничего лишнего в систему не устанавливалось, да и вообще нелюбил инсталяторы (и сейчас не люблю). Программа должна быть в виде stand-alone и не требовать никакой проклятой инсталяции :)

ManulVRN
24.09.2025 00:04От BDE избавлялся, как только находил компоненты для работы конкретно с моими базами. Для Оракла была отличная библиотека DOA (Direct Oracle Access), для работы с DBase файлами тоже нашел какие-то компоненты. Встроенный набор для построения отчетов, кажется QReport, был даже не борландовской разработки, они у сторонней конторы их приобрели "чтобы было". Помню, была у меня в отчете двойная группировка (группа внутри группы) и, когда внутренняя группа заканчивалась в конце страницы, итоги по внешней группе не печатались на новой странице. Просто выпадала строка итогов. Сколько я бился, полагая, что у меня в приложении какая-то ошибка, сколько пытался подстроиться, чтобы итоги по группе не совпадали с концом страницы... В итоге, когда интернет слегка подразвился, выяснил, что это хорошо известный баг библиотеки, на который производителю плевать. "Используйте другой генератор отчетов". Что я и сделал.
Эх, были времена...

raskolbas_rbc
24.09.2025 00:04В то время появился бесплатный Fast reports, который на голову был выше, им пользовались очень долго

Severn Автор
24.09.2025 00:04И был очень классно сделан!
И, кстати, в версии под .Net сделан так же хорошо.
И по сей день жив, как под Delphi, так и под C#.

PerroSalchicha
24.09.2025 00:04Он, по-моему, никогда не был бесплатным, там была триалка без исходников, которая печатала до пяти страниц и с сообщением о триале, или что-то в этом роде. Но лицензия была недорогая.

raskolbas_rbc
24.09.2025 00:04Возможно, может мы его и купили сразу, это в 96 или 97 году было, все на этих отчётах в банке строилось

spacediver
24.09.2025 00:04взаимоблокировки
Сергей Дмитриевич Кузнецов (1949-2023), две недели по модему качавший в Россию стандарт SQL 1995, ненавидел это слово)) Транзанкции не могут друг друга блокировать, они друг про друга не знают!
Синхронизационный тупик))
Кстати, и слово deadlock не содержит указания ни на какое "взаимо-".

Severn Автор
24.09.2025 00:04Ну, строго говоря, блокируют друг друга не транзакции, а сессии, в которых делаются блокировки. Так что Сергей Дмитриевич прав, и я с ним не спорю. )
А если лезть в механизмы - то в сессиях производится обращение к критической секции, и взаимоблокировка случается когда два потока блокируют по критической секции и пытаются заблокировать вторую, блокированную другим потоком.
Ох и геморрой был разматывать эти блокировки в BDE в сервере приложений!

Buzzzzer
24.09.2025 00:04А еще где то в те времена была библиотека KOL & MCK от Владимира Кладова, которая вместо гигантских (на то время) приложений умудрялась компилятся в очень компактный размер

paulsv77
24.09.2025 00:04Вроде, достаточно было BDE библиотеки закинуть в папку с программой.

BiTL
24.09.2025 00:04На сколько я помню, нужно было установить BDE, еще и настроить через утилиту конфигурации. Да, наверняка это все можно заскриптовать в интсталяторе (или т.п.), но просто положить либы в папку, так не работало. По крайней мере в те годы, когда я использовал Delphi, а это был 96-97 :)

DmitryKuzmenko
24.09.2025 00:04я занудный, не могу не заметить, что "в таскбаре" висел не Firebird, а InterBase. В Дельфи входил только InterBase. Firebird - никогда.

Severn Автор
24.09.2025 00:04FireBird в Delphi не входил, вы правы. Но в таскбаре он прекрасно висит, вот смотрите

Я, как, наверное и большинство, предпочту использовать именно бесплатный FB, а не глючный IB.

DmitryKuzmenko
24.09.2025 00:04так-то я про таскбар не спорю :-). Да и про "глючный ИБ" тоже - еще для 2009 отправил 4 багрепорта, их так и не исправили.

infund
24.09.2025 00:04Похоже, в лохматом году был на вашей конференции где-то на Водном стадионе, что ли...

zaskoche
24.09.2025 00:04FireBird живее всех живых, сейчас 5.0 и 6.0 не за горами, заимел платный "клон" в лице RedDatabase. В таскбаре не висит, ресурсы не жрёт. Наибольшее распространен в Бразилии, на втором месте Россия. Часть разрабов наша, часть из них же это разрабы RedDatabase.

Severn Автор
24.09.2025 00:04Я помню еще питерский клон Yaffil, потом слившийся с командой FireBird, если не ошибаюсь. Там они научились комбинировать индексы и очень быстро искать, скажем, при условиях по полям Name и INN и при индексах по каждому из этих полей, но без индекса по ним обоим. Поиск прям очень быстро стал работать.
Ну, там еще много хорошего было, уже и не вспомню точно, почти 20 лет прошло...

Kroligoff
24.09.2025 00:04
Когда начинаю хоронить Delphi всегда прикладываю свежий TIOBE, несмотря того что много растерял пользователей в былые времена, язык популярен, даже сейчас есть много преимуществ.

BiTL
24.09.2025 00:04Тут вроде бы хоронят (точнее поминают, ибо уже давно померла) компанию Borland, а не Delphi.
В 2009 году поглощена британской компанией Micro Focus. Годом ранее активы, связанные со средствами разработки и выделенные в предприятие CodeGear, проданы компании Embarcadero.
antperetz
24.09.2025 00:04Кстати, Micro Focus поглотила Novell NetWare, интересно было бы почитать такую же статью как NetWare "профукали".
В 2022 году Micro Focus была куплена компанией OpenText, что означает, что активы Novell теперь находятся под контролем OpenText.

forever_live
24.09.2025 00:04Забавно, что почти нигде в истории перехода Борланда в Идеру не упоминается ещё одно промежуточное звено, Inprise. При том, что четвёртая версия делфи, емнип, имела в своём названии именно это имя, а не борланд.
Выглядит как будто бы борланд много раз перекидывался из рук в руки, как горячая картошка. И только эмбаркадера сумела его удержать.

PerroSalchicha
24.09.2025 00:04Забавно, что почти нигде в истории перехода Борланда в Идеру не упоминается ещё одно промежуточное звено, Inprise.
Это не промежуточное звено, это была та же Borland, но с новым брендом, который, как предполагалось, подчеркивал тогда их смену вектора с массовых инструментов разработки на дорогие корпоративные тулзы (что их и погубило). Integrate the Enterprise.

forever_live
24.09.2025 00:04Какая-то невнятная, значит, смена вектора получилась, потому что следующие версии делфи снова назывались борланд, вплоть до Codegear.

Severn Автор
24.09.2025 00:04Я счел эту подробность неважной, хотя она хорошо укладывается в общую канву беспорядочных метаний.
А насчет Ембаркадеро - тут чуть другое. Сами остатки Борланда, действительно, уже не имели сил, чтоб что-то удержать. А Ембаркадеро - старая фирма, которая, по всей вероятности, не собиралась впадать ни в какие кризисы, и просто выкупила по дешевке команду Delphi, как старый лендровер у колхозника-раздолбая, чтоб отремонтировать в своем гараже и пользоваться.

Akon32
24.09.2025 00:04и просто выкупила по дешевке команду Delphi, как старый лендровер у колхозника-раздолбая, чтоб отремонтировать в своем гараже и пользоваться.
Выкупила в 2008, ремонтировать начала с 2014, результат появился ближе к 2021...

PerroSalchicha
24.09.2025 00:04Я могу сказать, что CodeGear Delphi 2007, т.е. спустя две или три пропащие версии, был неплохим и современным. Они сами проделали уже тогда большую работу над ошибками, IDE там стала стабильной, современной и функциональной. Но время было упущено. И опять же таки, не было бесплатных версий.

Akon32
24.09.2025 00:04Delphi не был современным языком с момента появления С++ (т.е. никогда). Он всегда отставал по функциям от C++, Java, C#, Python и прочих популярных языков. Фичи языка реализовывались даже медленее, чем в Java! К ~2021 году его допилили почти до современного уровня (а ещё подключили LSP - вот тогда IDE стала стабильной!), а дальше я не в курсе, хотя версии выходят регулярно.
В чём плюсы, благодаря которым Delphi получил популярность: прогрессивный для своего времени редактор форм для RAD; ООП, которое сделало возможным написание огромных серьёзных программ.
PerroSalchicha
24.09.2025 00:04Delphi не был современным языком с момента появления С++ (т.е. никогда).
Неправда ваша. В Delphi тогда недоставало дженериков, и это был его единственный недостаток как языка в 2007-м году. Так, по количеству синтаксического сахара был плюс-минус паритет. В шарпе локальные функции появились в конце 2010-х, а анонимные функции в том же 2007-м, в дельфи локальные функции были от рождения, а анонимные появились в 2009-м вместе с дженериками.
прогрессивный для своего времени редактор форм для RAD
Я бы сказал, и сейчас прогрессивный :)

n0isy
24.09.2025 00:04Видимо данный чарт не отражает действительности: вы верите в то, что уровень дельфи вырос на 25 процентов за год? )) даже если это 0.5 процента от 2 процентов, вы верите в то, что он вообще вырос?
Вот в то, что перл и делфи где-то рядом, я верю.

aim
24.09.2025 00:04судя по тому количеству вирусни которая в последнее время стала появляться на delphi - табличка кажется правдивой.

markedo
24.09.2025 00:04Меня больше смутило, что "популярность" SQL уровнем ниже, чем Delphi и Perl. Ну или JS на уровне VB -- тоже звучит сомнительно.

Severn Автор
24.09.2025 00:04Ну, на SQL не так много пишут. С тех пор, как появились хорошие средства разработки программ с БД, бизнес-логику удобнее писать на других языках.
Я вот вообще даже SQL-запросы по большей части программно генерировал, а не писал руками.

Vedomir
24.09.2025 00:04А потом сгенерированный программно запрос начинает тормозить и никто не знает, что с этим делать...

Severn Автор
24.09.2025 00:04С чего бы это вдруг? Если программист не может починить SQL-запрос, то что он тут делает? И как он его генератор написал?
Что-то вы себе напридумывали свое, нам такого не надо.

bolk
24.09.2025 00:04На TIOBE нельзя ориентироваться. Он просто считает сколько ссылок выходит по поисковому запросу в поисковике. То есть любой язык по которому много писали в прошлом будет в топе. Это, разумеется, открывает дорогу к манипуляциям (поклонники Перла, например, не так давно воспользовались этим, начав много спамить словом Perl).

papani
24.09.2025 00:04О, как раз такую табличку видел на прошлой неделе на Pascal Conference 2025. Ian Barker ее презентовал насколько я помню. Он много и красноречиво рассказывал, что на дельфи написано много софта например для аэропортов. И даже новые проекты на нем начинают.
А закончил он свой спич словами "Is Delphi dead? No!!!"
Если верить ему, то не все так и плохо и хоронить, как обычно, рановато. =) Работа продолжается + есть еще FreePascal - там судя по сообщениям в телеграмме тоже активная работа идет.

Vedomir
24.09.2025 00:04А как считается TIOBE? Что он отражает?
Я бы больше смотрел на количество вакансий, зарплаты по ним, соотношение зарплаты/резюме, количество написанных на нем в наше время успешных проектов (тут конечно сложнее с непубличным корпоративным софтом), количество доступных библиотек и пакетов в пакетном менеджере.
Со стороны руководителя еще и на количество резюме и доступных на рынке специалистов.

PerroSalchicha
24.09.2025 00:041982 В Borland приходит Андерс Хейлсберг (Anders Hejlsberg), разработчик Blue Label Pascal.
Насколько я понимаю, почему именно Паскаль - это тоже не случайность, т.е. Филипп Кан был студентом у Никлауса Вирта.

CitizenOfDreams
24.09.2025 00:04В конце двухтысячных годов остатки компании Borland были проданы компании Embarcadero, которая и сейчас продолжает продавать продукт Delphi.
Ага, я как-то попытался попробовать ее бесплатную версию. Пока вбивал свои данные для регистрации и получал лицензию (на год,блин) - уже и пробовать расхотелось. Так даже и не запустил скачанную программу. По-моему, в девяностые оригинальный крякнутый Борланд было быстрее найти и поставить.

randomsimplenumber
24.09.2025 00:04Золотая лихорадка закончилась а продавцы лопат пытаются продавать остатки.

Honomer
24.09.2025 00:04До сих пор на диске лежит инсталлен 7 дельфи

Severn Автор
24.09.2025 00:04Я им даже пользовался не так давно. У нас контора копирует базы данных по нормативам, там до сих пор некоторые поставщики присылают данные в парадоксовских таблицах, и порой их приходится обрабатывать - вот, пришлось накатать небольшую приблуду на Дельфах. )

APh
24.09.2025 00:04Запускаем транслятор (сейчас говорят компилятор)
Нет. Так сейчас не говорят. И никогда не говорили. Ибо транслятор — общее понятие: программа, которая переводит код с одного языка на другой.
Компилятор — частный случай транслятора. Интерпретатор — тоже частный случай транслятора. Есть ещё...
уже существовавший к тому времени Бейсик можно считать воплощением этой идеи
Бейсик — это язык. Он не накладывает ограничений на среду разработки. Есть и IDE для Бейсика, и CLI. Есть интерпретаторы, есть и компиляторы с Бейсика.

Severn Автор
24.09.2025 00:04Спасибо за уточнения. В общем, вы правы, но, полагаю, это не настолько существенно, чтоб вносить правки в статью?

aso
24.09.2025 00:04Кмк - было бы неплохо в качестве демонстрации автором понимания сути применяемых терминов. Интерпретатор, как очевидно, будучи разновидностью транслятора - не создаёт объектных файлов, к примеру. И интерпретаторы языка Бейсик - не были IDE в нормальном понимании этого слова. Они могли "работать" в качестве интерпретатора командного языка - собственно, в "домашних" 8-битных компьютерах они частенько так и работали.
P.S. У Борланда - были ещё проблемы с неймингом продуктов, был Turbo C, Turbo C++, Borland C++, причём номера версий первых двух - частично перекрывались, хотя сами они были разными продуктами. Turbo C++ потом продолжал выпускаться "для энтузиастов" некоторое время дальше.
artptr86
24.09.2025 00:04Для Бейсика Майкрософт делал и компиляторы, и IDE, притом версия с полноценным редактором вышла даже раньше, чем у Borland.
Microsoft QuickBasic 2.0 (1986)

Borland Turbo Pascal 4.0 (1987)


lubagov
24.09.2025 00:04Да MS QBasic был интерпретатором (с версии 4.0, встроенной в редактор, до существовал компилятор), а Borland Turbo Basic - компилятором. А на MS Visual basic вполне можно получить заветный EXE. Я кстати ещё видел его подобие для DOS, нашел как то файлик такого VB когда ходил в кружок программирования, и был удивлен, под дос формочки и можно мышкой компоненты перетаскивать.
Однако как правило все-же Basic был интерпретатором, и да, часто применялся во многих домашних компьютерах. В клонах спектрума, в компах на базе КР580ВМ80 (Intel 8080), в качестве командной оболочки. Думаю тут, тоже обошлось не без Майкрософт. И если уж на то пошло, то какая-никакая IDE была даже в спектруме по крайней мере интерпретатор сразу после набора строки кода, показывал где ошибка, ну пусть не шибко информативно, в основном ? знаком вокруг места с ошибкой, без четких указаний, хотя написать в том редакторе программу длиннее 100строк было уже мучением.

aso
24.09.2025 00:04Ага.
Мне ТурбоПаскаль первоначально не зашёл - то, что я видел - запускалось в виде кучи каких-то разноцветных окошек-квадратиков, с которыми было непонятно, что делать. И это при том, что паскаль я изучал "вприглядку" по книжке - заметно раньше, и он мне нравился. И только с версии 5.5 (?), с TurboVision - я на него "запал". Хотя я переписал в пинарнике его раскраску - под то, что увидел у QuickBasic'а - чёрное поле, голубые (cyan) линии, оформляющие окошки, голубым же поле выбранного пункта меню - и белый цвет такста программы.
P.S. Можно вспомнить, кстати, что QuckBasic отличался от "классического" бейска кардинально, и выглядел "почти как паскаль" - там уже были структурные операторы, емнп и прочие полагающиеся плюшки. Оригинальный же бейсик - был крайне примитивен (что, собственно, заложено в его названии), и оператор программы в нём - обязательно должен был иметь цифровую метку, операторы исполнялись в порядке номеров меток, оператор без метки - исполнялся интерпретатором немедленно.

n0isy
24.09.2025 00:04Из-за повсеместного использования VM понятия все равно перемешались. Тот же Visual Basic указанный в статье, создаёт exe файл, состоящий из call dll чуть более чем полностью. Он компилятор или интерпретатор? А .Net?
Или к примеру JavaScript не создаёт exe, но перед выполнением код транслируется в довольно бинарный формат V8. Куда его отнести?

ris58h
24.09.2025 00:04Тот же Visual Basic указанный в статье, создаёт exe файл, состоящий из call dll чуть более чем полностью. Он компилятор или интерпретатор?
Очевидно, компилятор, а результат компиляции - exe.
А .Net?
А что .Net?
JavaScript не создаёт exe
Конечно не создаёт. Как ЯП может создавать exe?
но перед выполнением код транслируется в довольно бинарный формат V8
Посмотрел Nashorn Engine, который выполняет JavaScript, и не нашел никакого V8 внутри. Может плохо искал, конечно.

AlexMih
24.09.2025 00:04Очевидно, компилятор, а результат компиляции - exe
Речь идет о том, что если результат - exe, то это не всегда означает, что это сделал компилятор.
Были такие интерпретаторы, которые умели не только построчно выполнять ваш текст программы, но и создавать из него exe. В этот exe файл они помещали сам интерпретатор, и полностью исходный текст. При запуске exe интерпретатор начинал этот текст интерпретировать.
Программист был доволен: продал exe, круто, как все порядочные программисты. Пользователь был доволен: получил один exe, запустил - работает. Хакер тоже был доволен: при некоторой сноровке исходные коды прямо в текстовом виде из такого exe можно было выколупать обратно.

PerroSalchicha
24.09.2025 00:04Были такие интерпретаторы, которые умели не только построчно выполнять ваш текст программы, но и создавать из него exe.
Я не знаю про такие, но если взять как пример классический .NET или классический Visual Basic, всё это компиляторы, но компиляторы с виртуальной машиной. Компилятор и там, и там присутствует, но компилирует не в бинарные коды, а в MSIL в случае дотнета, и в подобный по сути P-code в случае классического VB, которые потом выполняются виртуальной машиной, каким-то образом скомпонованной с вашим приложением.

Feedman
24.09.2025 00:04Такой компилятор был в foxpro 2.6. Он либо генерировал исполняемые файлы для своего рантайма (fxp кажется), либо мог делать exe, в котором был рантайм и сама программа.
P.S. возможно таким компилятором был турбобейсик. У него, насколько помню, минимальный exe был килобайт 70-80.

artptr86
24.09.2025 00:04QuickBasic делал exe, слинковывая со своим рантаймом. Что было в ранних версиях — не знаю. Позже компилятор генерировал p-code.

ris58h
24.09.2025 00:04В этот exe файл они помещали сам интерпретатор, и полностью исходный текст. При запуске exe интерпретатор начинал этот текст интерпретировать.
В этом случае такой "интерпритатор" ничего не интерпретирует. Так что вопрос "интерпритатор или компилятор" не имеет смысла.

RoasterToaster
24.09.2025 00:04Но товарища Жукова и сняли с командования и отправили в захолустье, когда посчитали, что все битвы выиграны:)
Когда люди выигрывают много битв, они могут начать претендовать на новый уровень власти. И тут только два варианта: делить власть или с глаз долой

Severn Автор
24.09.2025 00:04Вот да, но надо ж сначала выиграть эту войну!
А тут - "иди, мальчик, дальше мы сами повоюем, по инструкции ..."

RoasterToaster
24.09.2025 00:04ИТ это бесконечная война) расслабились, свели счёты, повышать уровень власти не стали.

BlackMokona
24.09.2025 00:04Ну так руководство могло решить, что и так уже всё в шоколаде. Осталось доить клиентов, да плевать в потолок. И первые годы выходило этим заниматься успешно, судя по статье.

Rsa97
24.09.2025 00:04IMHO, самым ценным для начинающего разработчика был встроенный в IDE хелп по языку. По нажатию Ctrl+F1 открывалось описание именно той функции или конструкции языка, на которой сейчас стоял курсор.

Severn Автор
24.09.2025 00:04Это в какой версии такое было? Я такого не помню даже.

BiTL
24.09.2025 00:04в любой, если пакет "справки" установлен.

Severn Автор
24.09.2025 00:04Ох ты ж! А я просто описание языка читал по книжке. Помню, читал запоем - случилось купить книжки с описанием по-русски.

BiTL
24.09.2025 00:04ну, книжки тоже хорошее дело. В интегрированной справке-то была только краткая инфа. К слову, это было уже в Qbasic и QuickBasic (для DOS), даже с примерами кода. В Turbo Pascal тоже было, но как-то скупо.

WaldemarsonTheForester
24.09.2025 00:04Фаронова, наверное, книги... Эх, были времена... :-)

Akr0n
24.09.2025 00:04Может быть, Фленова?

PerroSalchicha
24.09.2025 00:04Фаронова. Флёнов, это про работу на компьютере вообще - DOS, Windows, MS Office. По Паскалю настольная книга была от Фаронова

WaldemarsonTheForester
24.09.2025 00:04Да нет, Фаронова. Когда у Фаронова первая книга по Паскалю вышла, Фленов подростком еще был. При всем уважении к его талантам, рановато ему было учебные пособия писать. Скорее, он сам тоже Фаронова читал тогда :-)

zuek
24.09.2025 00:04Эх, у меня аж четырёхтомник его был, по седьмому паскалю... зачитал до отвала корешков =)

RTFM13
24.09.2025 00:04Фаронов

Помню книжка отличалась полным отсутствием воды и была очень емкая при скромном формате и хорошо подходила и для изучения с нуля и в качестве справочника.
Были еще, кажется, по ООП и турбовижн такого же формата других цветов. Помню было удобно доставать по цвету корешка с полки.

maxdev
24.09.2025 00:04Фаронов "Библиотека Turbo Vision"

Нашел у себя. Живет рядом с Диккенсом. По ООП и не было, а Основы если и были, то не дожили. И эта не сильно нужна, но рука не поднимается выкинуть. Подача материала в ней отличная.

Nikeware
24.09.2025 00:04Когда-то при наличии MSDN подписки вся справка по любым продуктам и технологиям от Microsoft была интегрирована в Visual Studio и устанавливалась локально в интранет сети. Не имея интернета, можно было спокойно "покурить" MSDN и разобраться в том или ином API. Попробуйте сейчас это сделать без доступа в интернет :-)
p.s. chm - формат давно уже "закопали". А ведь хорошаю вещь была.
Severn Автор
24.09.2025 00:04А еще, помнится, лет 10-15 назад у MS были подробные, обстоятельные, хорошо переведенные хелпы на все библиотеки. А сейчас иногда совсем "на отвяжись" сделано бывает.

Vedomir
24.09.2025 00:04Появится необходимость, появится и оффлайн формат. У StackOverflow очень долго была оффлайновая версия, не знаю что с ней сейчас, видел проект несколько лет назад по сборке ответов и вопросов оттуда в pdf учебники.
Собственно даже тот же дипсик запущенный локально это оффлайновая справка.

exadmin
24.09.2025 00:04Вот мой MSDN для делфия, оказывается до сих пор есть: https://delphiworld.narod.ru/_all_articles_.html

PerroSalchicha
24.09.2025 00:04Первый раз я это увидел ещё в пятом Турбо Паскале, точнее, моя версия была 5.5, там, где ООП завезли. И я по этому гайду выучил сам язык.
К слову, самый крутой хелп был как раз в Delphi 1. Там был не только хелп собственно по Паскалю и библиотекам, но был и хелп по заголовочным файлам WinAPI, причём уже сконвертированный под Паскаль. После этой версии они уже так не заморачивались, отправляли читать виндовый SDK от Майкрософт, и самому переводить хедеры.

artptr86
24.09.2025 00:04Справка по языку была уже в первой версии с IDE — Turbo Pascal 4.0, выпущенной в 1987 году.

Gaikotsu
24.09.2025 00:04А еще была такая хорошая вещь как SWAG - эдакий оффлайновый SO по паскалю :)
В нем тоже много чего интересного можно было почерпнуть.

gruzoveek
24.09.2025 00:04Крутые были для своего времени и турбо паскаль, и делфи. Я с них и начинал программировать. На делфи 7 даже дипломную работу писал. Имел толстенные книги по делфи, в сети находил неочевидные какие то фишки, интересно было. Так то вообще много чего понаписал в ту пору. А потом появились смартфоны, ну я и перешел вообще на джаву и в веб, php+js.

BigBrother
24.09.2025 00:04И вот это мне совершенно непонятно. При всем сложном характера Кана, это выглядит как если б после Курской Дуги и Сталинграда товарища Жукова сняли с командования.
Статья интересная, но слегка портят впечатления несколько отсылок к боевым действиям. В наше неспокойное время хотелось бы хотя бы на IT-ресурсах обойтись без военной тематики.
К тому же приведенное сравнение тут не совсем уместно: товарищ Жуков никакого отношения к Сталинградской битве не имел, потому ни снимать, ни награждать его не было оснований.

DSolodukhin
24.09.2025 00:04товарищ Жуков никакого отношения к Сталинградской битве не имел
Как минимум, Жуков был представителем Ставки на Сталинградском фронте и занимался координацией действий фронта с соседними.
Так же в мемуарах он утверждает, что вместе с Василевским принял активное участие в разработке плана операции "Уран", но вот тут доказательств нет, ибо "Засекречено."

AlexGorky
24.09.2025 00:04В Turbo Vision содержится красивая стройная концепция управления окнами
И тени! Там были тени, которые двигались вместе с окном. Это придавало эффект объёмности, что было нереально круто.
Напомню - мы говорим не про графику, а про текстовый экран 80*25 символов.

beerchaser
24.09.2025 00:04В TV была система очередей сообщений. После понимания этой концепции переход на програмирование на Win (VS 6) не составил большого труда.

LeonidPr
24.09.2025 00:04
WaldemarsonTheForester
24.09.2025 00:04Там очень-очень нестандартные расширения C++ использовались. Это и плохо, и хорошо одновременно.

DmitryKuzmenko
24.09.2025 00:04В компиляторе Turbo C была опция -quirks (причуды), для компиляции кода от Microsoft C с его какими-то тогдашними глюками. Это такой стёб был. Еще там была какая-то история как сотрудники Borland на какой-то вечеринке напоили сотрудников Microsoft. Такая была веселуха меж-компанийная.

Nikeware
24.09.2025 00:04Я будучи ещё студентом в середине 90х написал на ней свою первую программу под Windows (клон популярной в те времена игры Lines :-). В Borland C++ была "интересная" идея "связывания" методов класса для обработки событий Windows.
Что-то типа virtual void OnCreate(...) = WM_CREATE;
Правда не прижилось, потому как было собственным расширением компилятора, а не стандартом языка С++.

user-book
24.09.2025 00:04Каким же крутым был Вижуал Студио в свое время, который как я понимаю разрабатывал тот же человек который создал Борланд.
Сейчас этот VSC шаг в перед в плане кросплатформиности и системы плагинов и выстрел в обе ноги одновременно по стабильности, вылизаности и возможности создавать оконные приложения.

desu7
24.09.2025 00:04Так Visual Studio и Visual Studio Code это два разных продукта же.

user-book
24.09.2025 00:04Вот именно!
Раньше специально держал раздел с виндой только ради него потому что было просто приятно работать и очень быстро накидывалось оконное под винду без танцев.
Причем прирост такой что даже имея что-то кроссплатформенное на Qt4 проще быстро перекинуть на вижуал и там собрать, будучи уверенным что оно будет валидно работать и не крашить.
UPD
если кто не знал - мягкие закрыли развитие вижуала сделав упор на VSC, потеряв по сути огромный пласт наработок в плане IDE
molnij
24.09.2025 00:04UPDесли кто не знал что мягкие закрыли развитие вижуала сделав упор на VSC, потеряв по сути огромный пласт наработок в плане IDE
В сентябре публичная бетка 2026 студии вышла :)

user-book
24.09.2025 00:04О, так они таки "вернули все в зад"?
Ну я "имел счастье" застать момент когда появился VSC а о вижуале начали говорить как об "устаревшем". Тогда еше как раз VSC был в сотни раз кривее чем сейчас.
Причем скипнул не сразу, а года через два где-то.
Посмотрел википедию - куча версий уже вышла с того момента.
Забавно как они чисто менеджерскими приколами с "посмотрим по рынку" потеряли пользователя, который покупал лицензию (пиздецки дорогую между прочим, благо студенческую скидку можно было получить просто публикуясь). И я уверен что не один такой.
holgw
24.09.2025 00:04VS живее всех живых, никакого курса на замену его на VSC нет (и не было). Вся энтерпрайзная разработка под .NET вообще живет либо на VS, либо на Rider от JetBrains. VS Code это замечательный универсальный редактор кода, но все равно не полноценная IDE.
Не, я помню конечно тот период времени на взлете VSC когда про него везде писали что это бесплатная кросcплатформенная альтернатива VS, но сами майки никогда так его не позиционировали и время показало что это два разных продукта, для разных задач, хоть и с пересекающимся функционалом.

ImagineTables
24.09.2025 00:04И как она? Неотключаемый слив кода через Copilot, поди? Думаю, на что переходить с 2022-й. Или так и продолжать в ней сидеть, пока рак не свистнет?

molnij
24.09.2025 00:04Жду релиза, чот стал старый и ленивый возится с превьюхами и их чистками )
Но в новостях конечно AI в каждой первой строчке, можно обмазываться с ног до головы :(

Nikeware
24.09.2025 00:04https://en.wikipedia.org/wiki/Visual_Studio#History
"Сижу" на этом продукте ещё со времён Visual C++ 6.0

Yami-no-Ryuu
24.09.2025 00:04Автор не застал Vi/Emacs/MultiEdit/QEdit где всё это прикручивалось?

randomsimplenumber
24.09.2025 00:04Между прикручивалось и работает сразу есть небольшая разница. Прикрутить к vim много чего можно.

Severn Автор
24.09.2025 00:04Это было уже позже. Да, мультиедит был крут, но TP был маленьким чудом именно для своего времени.
Знаете, это вот как для меня в 1990 было чудом притащить в электрохимическую лабораторию лазер, чтоб подсветить - что там делается в ячейке с расплавом?
Лазер (зеленый) тогда был размером полтора метра в длину и 10 см в диаметре, и включался в розетку. А вот сейчас можно лазерную указку таскать в кармане. Это круто, но уже никого не удивляет.Или как смартфон у вас в кармане - сколько там мегагерц и мегабайт? А ведь впечатляет не так, как 20-мегагерцовый PC AT c мегабайтом памяти и 40 мегабайтами HDD.
А если брать времена мультиедита - это, вроде бы, середина 90-х? - то тогда для меня было чудом CodeInsight. Помните? Когда начинаешь набирать имя, а редактор тебе уже готов подставить его полностью? И еще когда он подсказывает тебе, какие параметры у процедуры?
А вот сейчас и это уже привычно.
unreal_undead2
24.09.2025 00:04Это было уже позже.
В Gnu Emacs в 1989'ом не было M-x compile?
PS Насколько вижу, в те времена в код поддержки компиляции из редактора изменения вносились
diff -rc2N dist-18.52/lisp/compile.el dist-18.53/lisp/compile.el
*** dist-18.52/lisp/compile.el Mon Jul 18 00:26:46 1988
--- dist-18.53/lisp/compile.el Thu Dec 29 14:25:03 1988
WaldemarsonTheForester
24.09.2025 00:04В Gnu Emacs в 1989'ом не было M-x compile?
Его не было под DOS. По мотивам были Demacs и MicroEMACS. Но по удобству это разве что с треть��й версией "турбины" сравнивать (да и то не в пользу Emacs-like), а не с четвертой-пятой, про которые идет речь.
Ну и плюс это еще где-то взять надо было, если мы про наши реалии говорим. А "турбина" расползалась сама, как вирус :-)

unreal_undead2
24.09.2025 00:04Если говорить про DOS и наши реалии то, как уже написал, многие начинали как раз таки с IDE от Borland и только потом разбирались с отдельной компиляцией/линковкой.

chapai22
24.09.2025 00:04Мультиэдит это песня и любовь, досовый.
Макроязык которым все пишется и обработка текста и файлов, и оконное, и хоть мелкая база данных и даже исполнение кусочков ассемблера., причем сам ME редактор написан на макроязыке, а интерпретатор ядро - как раз на турбо паскале, .
я я этот ME и хачил и переводил,и макросы писал раскидистые. А уж когда появился декомпилятор - то просто правил весь ME целиком.

infund
24.09.2025 00:04А в чем состояла необходимость тащить в заголовок нецензурщину?

JohnWang
24.09.2025 00:04Согласен, среди читателей есть школьники и беременные женщины, правильнее было бы назвать так:
"Как B*****d просрали все полимеры"

randomsimplenumber
24.09.2025 00:04Школьники как раз могут значительно расширить словарный запас комментатора.

randomsimplenumber
24.09.2025 00:04Отсылка к древнему мему, сэр.

infund
24.09.2025 00:04Да я как бы в курсе «древнего мема». Я спросил о цели и о допустимости матерщины прямо в заголовке. Что, уже можно начинать публикацию прям с мата? Не в мужском же сортире стены читаем, не?
Впрочем, похоже, по рекомендации администрации, заголовок был изменен.
Я уж молчу о том, что глагол так и не согласован по числу с существительным.

randomsimplenumber
24.09.2025 00:04Я смотрю проще. Задаю себе вопрос: правда ли заголовок станет лучше, если заменить ужасное слово про$р@ли на какое то другое? Или если буквы заменить- никто же не догадается, что имел в виду автор? А потом думаю: кто смог опознать мем - тот уже достаточно взрослый чтобы оценить шутку юмора. А кто не смог.. Ну, вряд ли ему будет понятен текст про древних борландов.
Зы Так - хуже. Все знают, что полимеры не профукивают

Severn Автор
24.09.2025 00:04Вы можете определить, что такое матерщина, а что такое нецензурные слова? И чем они отличаются от грубых слов?
Или так, по наитию, называете как попало?
infund
24.09.2025 00:04Я просто не хочу видеть в заголовках слово «просрать». Оставляю классификацию этого слова вам.

randomsimplenumber
24.09.2025 00:04Но в комментариях оно есть. Вы сами его написали ;)

Severn Автор
24.09.2025 00:04Да, простите, испортился я в 90-е, подрастерял интеллигентность, набрал нехорошего культурного контекста. Теперь ведь и не вспомню, из какого фильма взялась эта крылатая фраза.

BiTL
24.09.2025 00:04хватит на 90-е наговаривать. Фраза про "просрали все полимеры" - это 2005-й год, из записи совещания у начальника цеха на одном из предприятий «Северстали».

Maccimo
24.09.2025 00:04Тяжко живётся в наше время выпускникам Института Благородных Девиц.
Вечно им мерещится нецензурщина там, где её отродясь не было.
WaldemarsonTheForester
24.09.2025 00:04Выпускник Института Девиц - нет ли тут пропаганды чего-то не того? :-)

drafterleo
24.09.2025 00:04Вполне допускается использовать слово выпускник в отношении лиц любого пола (типа, официально-деловой стиль без лишней феминитивщины ;)).

unreal_undead2
24.09.2025 00:04Ведь как в те времена делалось "в норме"
У меня и большинства знакомых, начинавших в те времена, программирование на более-менее серьёзных машинках начиналось именно с Turbo C/Pascal с IDE, про запуск компилятора/линкера из командной строки, make и т.д. узнавали уже позже.
Хотя примерно тогда же был доступ к ЕС ЭВМ, там всё "по классике", только ещё запуск компилятора/линкера шёл через заклинания ЯУЗ в начале исходника, которые все просто копировали друг друга не особо понимая.

Panzerschrek
24.09.2025 00:04Мне кажется, что сама бизнес-модель продажи компиляторов и других средств разработки себя изжила. С одной стороны появились открытые и тем самым бесплатные компиляторы вроде GCC и clang, с другой стороны библиотеки для GUI вроде Qt. Microsoft так же сделала свои инструменты разработки по большей части открытыми, ибо непрямой профит в виде привлечения разработчиков на свою платформу оказался выше профита от продажи инструментов разработки. В такой ситуации нету смысла покупать что-то, аналоги которого есть за бесплатно и которые иногда даже лучше платных продуктов.

BiTL
24.09.2025 00:04библиотеки для GUI вроде Qt
Жаль эта дрянь вылезла за пределы линуксов

randomsimplenumber
24.09.2025 00:04Альтернативы есть ?

BiTL
24.09.2025 00:04нативные API

randomsimplenumber
24.09.2025 00:04Кому не нужно кроссплатформенность и интересно играться в CreateWindowEx - их же никто не заставляет писать на Qt?

BiTL
24.09.2025 00:04плохо что не заставляют не писать на Qt ;)

randomsimplenumber
24.09.2025 00:04Может, дело не в qt а в программе? Может, запретить тормозной говнокод?

Einherjar
24.09.2025 00:04В век кроссплатформенных приложений писать мало-мальски сложный гуй на нативных апи под три десктопных ос... завидую количеству вашего свободного времени. Вот бы мне лишний человеко-год

NeoCode
24.09.2025 00:04А чем вам Qt не нравится? ИМХО прекрасная библиотека.

BiTL
24.09.2025 00:04Наверное для программиста прекрасная. А мне как пользователю не очень. Я правда хз, может она на Винде и не так плоха. Но на МакОС это тормозное глючное угробище. Ну, по крайней мере программы, которые юзают Qt.

Severn Автор
24.09.2025 00:04Да, скорей всего вы правы. Недаром же Microsoft дает Студию бесплатно. Я полагаю, Борланды именно на этом в частности прокололись.

BiTL
24.09.2025 00:04Когда Борланд гавкнулся Майки еще Студию вполне себе продавали, и еще долго.

Panzerschrek
24.09.2025 00:04Я 2008-ю Visual Studio бесплатно скачал, уже тогда была какая-то бесплатная, но ограниченная версия. Примерно в тоже-время была доступна IDE под названием Code::Blocks, которая конечно коммерческим IDE уступала, но всё-же была вполне рабочей.

BiTL
24.09.2025 00:04Ну были какието там бесплатные версии для студентов ) Без права создавать на них коммерческие продукты.
Code::Blocks не был конкурентом Delphi. Там же небыло визуальной среды "рисования" интерфейсов.

Severn Автор
24.09.2025 00:04Уже не помню цены, но, кажется, Студия стоила около 50 долларов. А по каким-то программам начала-середины 2000х ее давали и бесплатно. А Delphi стоили на порядок дороже, нереально для покупки на себя лично.

onets
24.09.2025 00:04В 2006 году Майкрософт проводил презентации в кинотеатрах (по крайней мере в моем городе). Там выдали всем бесплатно vs standard + Ms sql 2005 standard + лицензию на подключение к Ms sql 1 шт. Получился полный набор для старта. С того времени я и стал программистом.

chapai22
24.09.2025 00:04Борланды именно на этом в частности прокололись.
Не совсем на этом. а на MSDN - для корпораций это было как воздух. Плюс платный саппорт разных уровней, причем нижние включены в MSDN.
А аналога у борланда, и сил сделать подобное не было.
Severn Автор
24.09.2025 00:04Ну, это уже другой фактор. Может быть, тоже значимый, тут мне сложно судить.

chapai22
24.09.2025 00:04третий фактор - стабильность поставщика.(что он завтра не пропадет и будет совместим с следующими виндами, продуктами и так далее.) для большого бизнеса это важно и MS понимали.
ну и если у вас все продукты от ms то смысл рисковать в зоопарк.

svl87
24.09.2025 00:04Ну хз, бизнес Intellij вполне успешен. И если для их продуктов есть более-менее неплохие бесплатные аналоги, то для узкоспециализированных средств иногда бесплатных аналогов нет или они совсем убогие

Klenov_s
24.09.2025 00:04С удовольствием кодил на Турбо паскале, а потом купил толстую книжку по турбо вижн и наткнулся на какие-то непонятные вещи в коде ))) Так я узнал, что бывает ООП )))
А уж на делфях извращался со всякими компонентами, очень мне нравилась красивую графику в них делать ))

Severn Автор
24.09.2025 00:04Ой, тоже помню ступор от этого непонятного кода с понятными операторами. Долго на это дивился, не понимая. Но однажды мне в руки попала дискетка с описанием Turbo Vision. 250 страниц на чистом аглицком языке! (Благо, в школе дали хорошую базу, смог прочесть)
Я ж его читал как детектив! Все выходные не отрываясь! А потом вечерами!
И скрипел всеми шестеренками в голове, пытаясь освоить новый подход.
Зато как классно было потом! Когда я понял, как контролировать ввод данных в окне!
Когда я однажды поспорил с начальником, и на спор написал за неделю учебную программу, рассчитывающую колебательный контур и строящую кривые его характеристик!
И охреневший начальник минут 10 сосредоточенно пытался заставить программу дать сбой. А она его увещевала, что, мол, в данном поле вводится частота, которая не бывает отрицательной. И предлагала ввести верхний предел графика выше, чем нижний. И не давала вводить буквы в цифровые величины.Вы когда-нибудь видели человека, которые только что съел лимон целиком? Вот такая у него была физиономия, когда он встал и сказал - "Ну, ничего..." Похоже, эти слова стоили ему больших усилий.
Ну, понятное дело. Сам он писал на Фокс Про, и у него на то, чтоб заставить одно диалоговое окно более-менее вменяемо работать, уходило с месяц. И то после этого его программы то и дело выдавали "Abort, Retry, Fail?"
И мне даже трудно было бы ему объяснить, почему у меня окно работает, и на его написание уходит один день.
Maccimo
24.09.2025 00:04однажды мне в руки попала дискетка с описанием Turbo Vision. 250 страниц на чистом аглицком языке!
В дистрибутиве Borland Pascal 7, продававшемся в РФ, документация по Turbo Vision была переведена на русский. Шла в виде электронной книги с интерфейсом, на этой самой Turbo Vision написанном.

Severn Автор
24.09.2025 00:04О, вам повезло. А мы купили с документацией только на английском. Я эту красивую книжку из института спер, когда уходил - был такой грех.

Maccimo
24.09.2025 00:04Печатная документация была на английском, а вот документация по Turbo Vision на отдельной дискете таки на русском. Можно поискать в спираченных дистрибутивах.

Severn Автор
24.09.2025 00:04А насчет красивых компонентов - как не вспомнить Чарльза Калверта и его талмуд?

Javian
24.09.2025 00:04В школах/колледжах до сих пор Паскаль могут учить. Только теперь он FreePascal

Daimos
24.09.2025 00:04Ага, 10-й класс в Беларуси, вот дочь написала
Скрытый текст
// Написать программу, которая сформирует массив из n чисел из промежутка
// [-100, 100] случайным образом. Вывести на экран элементы массива, делящийся на 5 и не делящийся на 2.
var
a: array [1..1000] of integer;
n,s: integer;begin
s:=0;
writeln ('Введите количество чисел в массиве');
readln (n);
writeln ('Массив:');
for var i := 1 to n do
begin
a[i] := random (-100,100);
write (a[i],' ');
end;
writeln;
for var i:= 1 to n do
begin
if (a[i] mod 5=0) and (a[i] mod 2 <> 0) then
begin
s:= s+1;
writeln ('ответ:', a[i]);
end;
end;
if s=0 then writeln ('Нет подходящих элементов массива');
end.

AlexMih
24.09.2025 00:04Delphi убило то, что она вышла конкурировать на рынок программ, работающих с базами данных, с откровенно слабым продуктом BDE. Слабым с точки зрения условного программиста, до тех пор сидевшего на FoxPro DOS, и решившего перевести свой продукт на Delphi. Разумеется, тот условный программист - это был я.
FoxPro DOS в середине 90-х уже была мощным и совершенным продуктом, которая выжала всю возможную магию из файлового доступа к данным. Особым шиком была технология битовых карт Рашмора, которая позволяла в поиске и фильтрации использовать несколько независимых индексов для различных условий. Другими словами, можно было наложить фильтр по нескольким полям на датасет в десятки тысяч записей, и это отрабатывало мгновенно.
С высоты сегодняшнего дня мы понимаем, что в технологии клиент-сервер так не делают, и такую программу следовало бы переосмыслить и переписать слой доступа к данным. Но в том-то и беда, что Borland хвастливо позиционировал свою BDE как on-place замену файл-серверным технологиям в существующих программах. А в результате такой замены программы просто начинали работать гораздо медленнее, потому что аналогичные фильтры, наложенные на те же данные, в BDE индексов использовать не умели и дико тормозили.
Имея прекрасный по тем временам сервер Interbase, им следовало бы сосредоточиться на новой клиент-серверной технологии, развивая для этого все компоненты и перетягивая на них старые файл-серверные приложения, может с какими-то тулами миграции. Но они не сделали это приоритетом и упустили возможности. Что можно сказать. Жаль, хорошее было время.

Severn Автор
24.09.2025 00:04Вот тут мне сложно с вами спорить, потому что у нас несколько различаются области. С Фоксом я практически не работал, но помню, что индексы они научились использовать очень хорошо и быстро, и за счет этого Фокс и вылез - именно как самая быстрая из DBase-подобных СУБД.
Но в то же время я помню, что та же 1С использовала движок CodeBase - насколько я понимаю, это как раз тот же, что и в Фоксе. И считала итоги по остаткам в магазине по 20 минут. Я натравил на ту же таблицу (1С-овский регистр) простую программку с BDE-шным SQL-запросом. И получил итог за 15 секунд.
Так что тут вопрос может быть сложнее, чем кажется.Что BDE был сыроват - я спорить не буду. Но с вашей формулировкой насчет "откровенно слабого продукта" категорически не соглашусь. Тут главное было то, что BDE мог работать с любыми СУБД. А насчет скорости... Ну, во 2 или 3 версии Дельф можно было уже от BDE отказаться - я, скажем, стал использовать InterBase и компоненты IBX, потом FiBPlus. А универсальность обращения с базам данных осталась.
И главное - назовите, у кого еще был инструмент, позволяющий работать с разными СУБД одинаковым образом? Да только у Borland и Microsoft. И все!
Но если хотите, с удовольствием с вами пообщаюсь, вспомним былое )

AlexMih
24.09.2025 00:04Вы правы, конечно, BDE - это огромная проделанная работа, внушающая уважение. Но все же заявленная универсальность работы с разными БД так и осталась мало полезной на практике. Беда в том, что дьявол в мелочах - различиях в работе с NULL, датами, BLOB в разных СУБД все же не позволял сколько-нибудь объемному приложению просто переключить драйвер и начать работать с другой СУБД. Ну и печально то, что это потребовало бы ужать SQL запросы до общего куцого даже по тем меркам ANSI SQL-89, в то время как у ��аждой СУБД в диалектах SQL уже были свои вкусности, которые отпадали при работе через BDE. Смутно помню, нельзя было делать подзапросы SELECT FROM (SELECT..), WHERE field IN (SELECT) и многое другое.
В итоге все кто находил возможность отказаться от BDE, испытывали облегчение.

RedEyedAnonymous
24.09.2025 00:04Потому что “каноническим способом”, рекомендованным Microsoft, программа в одно окно содержит до трех тысяч строк кода и требует, соответственно, месяц работы.
Шта?! Какое "одно окно"? "Hello, world" был бы гораздо меньше. Зарегистрировать оконный класс (десяток-полтора строк), написать "оконную процедуру" (ну, два десятка), вызвать CreateWindow и создать цикл обработки сообщений... из трёх строк.
Приложение, которое делает что-то осмысленное... ну, пусть три тысячи строк, но один чорт там основное время займёт функциональность, а не GUIта.
randomsimplenumber
24.09.2025 00:04Ну да. И каждый пункт меню регистрировать. И каждую иконку на тулбаре. И callback на все чихи прописать. Gui на чистому windows api как brainfuck.

RedEyedAnonymous
24.09.2025 00:04Да ничего там особенно ужасного нет, и точно не брейнфак: https://ciprianf.hashnode.dev/win32-api-programming-using-menus
Классическое олдовое ООП "с сообщениями".

randomsimplenumber
24.09.2025 00:04Ничего ужасного, кроме простыней кода. А в Delphi все получалось автоматически. Причем, если надо, никто не мешал лезть под капот и дергать windows api руками.

RedEyedAnonymous
24.09.2025 00:04Из этих простыней получались бинарники меньше сотни КИЛОбайт, которым для работы хватало голой винды, в отличие от десятков мегабайт всякого [censored] с электроном и что там ещё нынче модно.
Впрочем, бинарники из-под Delphi по 7ю версию включительно тоже было достаточно компактными, если не тащить туда самосвал сторонних компонентов.
randomsimplenumber
24.09.2025 00:04бинарники меньше сотни КИЛОбайт
Кого волнует размер? В то время, когда бинарники стали занимать мегабайты, дискеты уже вышли из употребления. А по сети - быстрее скачать чем носиться с флешкой.

Vedomir
24.09.2025 00:04>от десятков мегабайт всякого [censored] с электроном
Почему десятков, сотен.

randomsimplenumber
24.09.2025 00:04VS code - 150 mb. Кроме мерзкого electron, там ничего нет, правда?

Vedomir
24.09.2025 00:04Вопрос терминологии и точности выражения. Для меня hello world в 150-180 мегабайт это не десятки мегабайт, точно. Десятки мегабайт это 30-50 там. Наверное формально под "сотни" тоже не подходит. Хотя, в принципе, почти две сотни мегабайт, так что все таки сотни.
VS Code - это вы инсталлятор считаете или установленное приложение? У меня сейчас она на диске 438 мегабайт весит и я не уверен, что это все ее файлы.

kryvichh
24.09.2025 00:04У меня и сейчас бинарники небольших программок с GUI (VCL) и БД (MS Access, SQLite) - 4 - 6 Мб. Скомпиленные в Delphi 12.

Severn Автор
24.09.2025 00:04Ну, насчет десятков мегабайт - это точно не про те времена. Тогда программа могла занимать триста килобайт, и мой друг говорил, что это много, мол, на С будет меньше. Согласен, говорю, но вот ты эти триста килобайт положи на гигабайтный диск, отвернись на минуточку, и попробуй их там найти. Для того времени дисковое пространство было уже дешевым, даже в памяти программа на 300 килобайт тоже была не особо обременительна.
А про сотни мегабайт - это уже сейчас ухитряются делать. Как они это ухитряются - я пока даже не очень понимаю )

BiTL
24.09.2025 00:04даже в памяти программа на 300 килобайт тоже была не особо обременительна.
Как сказать... Если она в реальном режиме работала, то 300 кб EXE-шник это обременительно, ведь обычно сколько было DOS-памяти свободной? 570-580kb (при условии что мы все очень тчательно сконфигурировали, юзаем himem.sys, грузим резидентные драйверы в верхнюю память и т.д.
И того, 300Кб ехе, 16кб на стэк, и остается 250 кб, которые мы сможем использовать для массивов и динамически-выделенной памяти. Туды-сюды и уже аут.

Severn Автор
24.09.2025 00:04Видите ли, с точки зрения сложности разработки размер бинарника не имеет значения, а вот размер исходного текста - как раз имеет. Поэтому простыней кода и стараемся избегать.

RedEyedAnonymous
24.09.2025 00:04...а потом пользователь плюётся на тормозное bloatware. Зато священная корова-программист не перенапрягся, бедняжечка.

Severn Автор
24.09.2025 00:04Ну, если вы любите длинные простыни кода - это ваше право.
А насчет когда напрягаться, а когда не стоит - тут каждый за себя решает.
Почему вы связываете это со скоростью работы программы - мне вообще непонятно. Скорость работы формы (если мы о ней) зависит прежде всего от того, сколько действий ей приходится совершать при том или ином событии. И если программист понимает, что форма делает - то он сможет сделать так, чтоб она работала нормально и комфортно. Если не понимает - может сделать так, что форма будет по десять раз пересчитывать и перерисовывать себя, и, соответственно, будет тормозить.
А почему вы связываете тормознутость формы и то, насколько задолбался программист - мне непонятно. Похоже, пытаетесь убедить меня ложными доказательствами. Не убедили.

Severn Автор
24.09.2025 00:04Ну, в то время ходил пример, как нужно писать программу под Windows. Возможно, в этом примере было наворочено много такого, без чего можно было обойтись. Но мы в то время еще не успели изучить функции Windows, и разобраться что надо что нет не могли.
А в ваших программах все окна были такие простые? Или были окна более сложные? Ну, вот я прикидываю - надо обрабатывать как минимум клавиатуру, мышь, события закрытия формы, завершения ОС, смены фокуса, сколько их еще наберется?

Jijiki
24.09.2025 00:04так да, и вы тоже правы, можно смотреть на подход java или на математику, по началу кажется, хоп-хоп, щас я напишу как думаю библиотеку, и со временем, когда допиливается например математическая библиотека или оконная библиотека, она обростает всякими поддерживающими 'модулями' назову так, тоесть функционалом и по итогу мы получаем ну почти тоже самое :) а на старте просто окно вызвать да и на Иксах удобнее, вот взять Window Manager идею например с XReparent(типо стековый) и вокруг этого XReparent и этого функционала WM с виду простенький обрастёт кодом - поддерживающим эту концепцию

NeoCode
24.09.2025 00:04А как развивался сам язык Delphi по мере появления новых версий? Обычно все пишут о фичах новых языков, а Delphi вроде как достаточно старый, поэтому "научно-популярных" статей про него на том же Хабре негусто. Но вот мне интересно все что связано с языками программирования как таковыми. К примеру в C++Builder используется интересное расширение С++ - "свойства", вероятно и в Delphi тоже. Еще вроде бы RTTI там достаточно продвинутый (но тоже какие-то слухи из инета, я на Дельфи не писал ничего, а на Билдере чисто для себя совсем немного и лет 20 назад). В общем, это намек для энтузиастов Delphi/Builder, было бы интересно почитать про особенности языков.

PerroSalchicha
24.09.2025 00:04К примеру в C++Builder используется интересное расширение С++ - "свойства", вероятно и в Delphi тоже.
Ну как бы в С++ Builder архитектуру завезли из Delphi, а не наоборот, будь-то свойства, RTTI, библиотека компонент, пакеты, и изначально Delphi по фичам шла примерно на одну версию впереди.
По версиям - вторая стала 32-битной, под Win95/NT, в третью завезли интерфейсы, поддержку СОМ, очень круто расширили IDE (там уже в 1997-м было и автодополнение кода, и сниппеты, и плагины) и библиотеку компонент.

Severn Автор
24.09.2025 00:04О, свойства - это прекрасная вещь! Это обобщение поля, позволяющее присваивать и читать значение. Но в общем виде свойство может быть и переменной (полем), и чем-то более сложным - и тогда чтение и/или запись выполняются специальной процедурой/функцией.
А важно то, что эти детали от пользователя скрыты - он просто обращается к свойству, и все.За счет этого можно, например, сделать свойство так, чтоб при каждом изменении оно не только меняло собственно значение, но еще, к примеру, куда-то сигнализировало, что значение поменялось.
Собственно, именно на свойствах и строилась работа компонентов в Дельфах, за счет чего они "жили" прямо в проектируемых формах, без необходимости компиляции программы.
И да, в C# свойства тоже есть.

Severn Автор
24.09.2025 00:04RTTI - возможность не зная типа объекта, все же обратиться к его свойствам или методам.
В Delphi для этого нужно было объявить свойство опубликованным (published), и зарегистрировать класс (RegisterType(AType: Type)).
После этого можно было в программе спросить - нет ли в регистрированных вот такого класса? А какие зарегистрированные классы у нас есть? А вот этот объект - вот нам ссылочку дали, а какого он типа не знаем, сказали что Object - а может, он гораздо сложнее? - он какого типа?Также можно было обратиться опубликованному свойству этого объекта - по имени - мол, говорят, у этого объекта есть свойство по имени 'Color' - дай-ка его значение? А теперь запиши в него цвет Red.
А еще можно было зарегистрировать процедуру и потом тоже выполнить ее - просто зная ее имя.
В Delphi RTTI в основном использовался для загрузки форм из файла ресурса.
Сейчас в Java и C# такие операции очень распространены и называются сериализацией (сохранение объектов и значений их свойств и полей в файл - обычно текстовый, .xml, но в принципе можно куда угодно) и десериализацией (соответственно, восстановление - читаем файл, создаем объекты).Сейчас в Java и C# это реализовано значительно шире, и называется Reflection. Доступно для всех публичных классов, их методов и свойств. Т.е. можно посмотреть, какие классы есть в нашей программе или в загруженном модуле; ощупать их свойства и методы (т.е. заранее вообще не зная, какие там свойства - просто получить их список, и прочитать значение любого из них; например, так можно копировать списки объектов заранее неизвестного типа).
Можно также создавать экземпляры неизвестных классов - вот, я в файле конфигурации провитал, что надо создать класс TrehmernayaHren, и проверил - у нас в программе есть определение такого класса, вот давай-ка создадим его экземпляр. И, например, запишем куда-нибудь.
Где реально это можно использовать?
Ну, например, я делал библиотеку для создания форм, которая могла отобразить на экране любой объект. Просто создается форма, далее проходим по свойствам объекта, выясняем их типы и названия, и для каждого свойства создаем метку с названием свойства и элемент управления соответствующего типа. И привязываем к этому свойству. Или просто присваиваем этому элементу значение свойства. Т.е. форма для редактирования объекта строится автоматически, "на лету". Очень удобно, если тебе приходится показывать и редактировать много разных объектов достаточно простой структуры. (Для объектов сложной структуры такая автоформа получается достаточно сложной, и неудобной, поэтому лучше все же нарисовать форму "руками".
Или другой пример - сохранение объектов в базу данных. В общем виде - имеем объект, выясняем его тип, ищем в БД таблицу с таким именем (можем и создать такую таблицу). Далее проходимся по всем свойствам, и каждое свойство записываем в колонку с именем, соответствующим имени свойства.
И наоборот - создаем объект, и прочитываем его свойства в таблице, дальше работаем с ним.
Тут мы фактически один раз прописываем процедуры генерации SQL-запросов, и дальше просто говорим - дай мне объект типа "Contractor" с идентификатором #13245, дальше программа сама генерирует SQL-запрос, выполняет, создает объект и присваивает прочитанные значения свойств.Третий пример - к работающей программе подгружаем новый модуль (.dll) - и в главной форме появляются новые пункты меню, выполняющие какие-то новые функции, описанные в этом подгруженном модуле. Причем когда программист эту программу писал, он не знал про этот модуль, этого модуля еще вообще не было.
С помощью того же Reflection можно заставить программу создать новые типы и их функции. Но этого я не пробовал, поэтому только укажу, что такое можно.

Siemargl
24.09.2025 00:04а потом появляются статьи на Хабре "почему тормозит рефлексия в Свифт" =)

Severn Автор
24.09.2025 00:04Тюуууу.... А может, не рефлексия тормозит, а программа, где эта рефлексия используется где не надо?

Siemargl
24.09.2025 00:04Строго говоря, везде рефлексию рекомендуют использовать с оглядкой на её минусы. А поиск нужного метода по таблице никогда скорости не добавлял.
Просто в свифте на это много завязано исторически.

Severn Автор
24.09.2025 00:04Дык конечно ) Инструмент надо использовать там, где он нужен, и так, как нужно )
Вот смотрите - мои примеры рефлексии - там во всех случаях задержка невелика, и главное - не критична. Рефлексия используется один раз, а дальше работа уже без нее.А вот если б мы ко всем свойствам через рефлексию по имени обращались - было бы медленно, хотя кому-то и показалось бы что так проще.
Кстати, вот в сериализации могут быть тормоза как раз из-за этого... Ну, тоже наверное зависит от того, как реализовать...

alan008
24.09.2025 00:04Развивается, но слабо и странно. Хорошее - дженерики, анонимные методы - завезли уже давно лет 10-15 назад. А в самых последних версиях появлялось "ну такое", например объявление переменных через var прямо в коде, как в C/C#, а не заранее в отдельном блоке. Вот в сентябре 2025 вышла новая версия - тернарный условный оператор завезли (этакий IfThen), чтобы писать x := if a > b then a else b
Но даже на мой чисто паскалевский взгляд это многословно и неудобно. У меня есть функция IfThen и я лучше напишу x := IfThen(a>b, a, b);

unC0Rr
24.09.2025 00:04Но с функцией ifthen очевидная проблема: все три аргумента вычисляются до вызова функции. Это может приводить к проблемам производительности, нарушениям в работе с памятью и т.п. Нельзя написать IfThen(a <> nil, a^.value, 0)

alan008
24.09.2025 00:04Да, верно, хотел написать об этом, но не стал грузить ). Иногда это мешает, иногда не мешает. Согласен, что на уровне языка/компилятора этот оператор будет работать более "ожидаемо" и корректно.

kemm
24.09.2025 00:04У меня есть функция IfThen и я лучше напишу x := IfThen(a>b, a, b);
Выполнив и a, и b...

alan008
24.09.2025 00:04Да. Ну вот жили с этим 20+ лет и не сильно страдали )) Там где это мешало, там приходилось писать обычный if .. then .. else. Честно говоря, их тернарный не особо экономит строки кода
Ну было
if a > b then
x := a
else
x := b
Можно (хоть и не нужно) написать это в одну строку if a > b then x := a else x := b
А они сделали x := if a>b then a else b
И много ли байтиков сэкономилось? Да, я старый брюзга :)))

ThingCrimson
24.09.2025 00:04Спасибо, поностальгировал! С Borland и Turbo Pascal связана бОльшая часть моей личной истории как «программиста»: после машинных кодов на Б3-34 / МК-61, бейсика на Д3-28, фортрана на ЕС ЭВМ мне повезло попасть на Turbo Pascal 2.0 на Robotron PC 1715 (CP/M). Это была любовь с первого взгляда!
Потом Turbo Pascal 3.0 на ЕС-1840 (DOS), и далее вплоть до Borland Pascal 7.0 (вытребовал с работодателя купить полную коробочную версию, печатные руководства там просто шикарные были). По некоторым из написанных мной программ до сих пор названивают, консультируются…
А потом пришли Windows, и я понял что пора переквалифицироваться в управд^W системные администраторы. С тех пор только мелочь на Shell / AWK / Perl / C (присматриваюсь к Python).

Octagon77
24.09.2025 00:04А я помню иначе. Turbo Pascal не был самодостаточным, к нему был нужен ещё Side Kick - резидентная программа которая выскакивала по шорткату. Подробности рабочего процесса не помню.
А сгубили Борланд два фактора. Первый - Delphi нуждалась в переводе заголовков с С на Паскаль, это было как невидимая, до столкновения, стена - всё просто-просто и потом сразу никак. На это дело попытались бросить народные массы, Project Jedi называлось, но нельзя быть милым народу и корпорациям. Второй - руководство Борланд соблазнили проникновением на корпоративный рынок - там можно и за $500, и за фантастические цены Эмбаркадеро продавать, и без .NET, корпоративной приблуды, никак. После этого из Delphi сделали дойную корову - обирали до нитки и всё спускали на корпоратиыные мечты.
Я помню как восхищался Микрософт - перетащить конкурента из разработки софта, где он выше на голову, на обихаживание корпораций, где уже Микрософт выше на две головы... Примерно в это же время Микрософт внедрила в сознание Линукс сообщества идею быть доступнее для "простого пользователя", это была очень похожая и столь же удачная психологическая операция которой я восхищался даже больше.
От себя я бы добавил отсутствие в Delphi родного компонента для двумерного и трёхмерного рисования. Это отсекло многих энтузиастов из народа.
Забавно, что всё, что было нужно сделать,таки было сделано, и уже ничего не помогло. Как и с Линукс - он таки стал ближе к "простому пользователю" в том смысле, как это предлагалось - появилмсь и работают графические конфигураторы, и точно так же как с Delphi эффект нудевой. Вывод - дорога ложка к обеду.

Severn Автор
24.09.2025 00:04Нет, SideKick к нему точно не требовался. Другой вопрос, что программисты могли его любить, там был в частности программистский калькулятор.
Вот насчет компонента для двухмерного и трехмерного рисования - не знаю, мне кажется, это довольно специфичная область, и вряд ли наличие/отсутствие такого компонента могло иметь решающий эффект.
Но соглашусь, что иметь его было бы приятно.

forever_live
24.09.2025 00:04Первый раз увидел слово SideKick в этой статье, что не мешало пользоваться Turbo Pascal разных версий много лет.

Octagon77
24.09.2025 00:04Могу только посочувствовать - во времена Дос и Турбо Паскаля Вы тратили много сил зря. Попыток предположить что происходит сейчас - не делаю, карму берегу...

georgiy08
24.09.2025 00:04В течение почти 20 лет Турбо Паскаль преподавали в школах и техникумах, иногда в институтах.
Не уверен насчёт 20 лет, так как его до сих пор продолжают преподавать

MiIs
24.09.2025 00:04На мой взгляд, причины затухания продуктов Borland, в общем-то передовых для своего времени, в том, что они перестали ловить "поток развития" индустрии:
1 Язык программирования и платформа Java и связанные с ним технологии уровня Предприятия (бесплатны).
Вытеснили Delphi c приложений уровня предприятия.
2 Платформа Microsoft .Net и языки C# и Visual Basic.Net (по большей части бесплатны)
Вытеснили Delphi c desktop-приложений уровня департамента-отдела.
3 Open Source: PHP, Python, Ruby (потом JavaScript) вытеснили с Web-разработки.
4 Концентрация на одной парадигме: Визуальное формошлепство.
Порог входа низкий, и первые шаги быстрые.
Как результат - много низкоквалифицированных разработчиков.
Но потом начинается ад с поддержкой и изменением их "формочек".
К Web-разработке не смогли приспособиться каким-то приемлемым способом.Особенность для России и бывших республик СССР - 1С, которая вытеснила с уровня мелко-средних предприятий.

ProLimit
24.09.2025 00:04" 4 Концентрация на одной парадигме: Визуальное формошлепство. " - после прочтения статьи как раз сложилось ощущение, что все наоборот. Если бы они и дальше все силы вкладывали в мега-популярный Delphi, который их по сути и кормил, а не пытались конкурировать со всеми подряд. Визуальный IDE - это ж золотое дно, и если у тебя он лучший в мире. Переписывай компилятор под другие языки (не меняя базы), - опыт уже был, сделали же C++ Builder. Далее добавили бы C#, Java - и опять на коне. Можно быть в тренде, просто поддерживая новые технологии в старом продукте.

artptr86
24.09.2025 00:04У C# в Visual Studio на тот момент визуальный редактор был не хуже. Тем более, он фактически поддерживался из коробки в самом .NET, а потому шансов конкурировать с Майкрософтом на этом поле уже не было. Они попытались, но с их ценовой политикой шансов было немного.
Для Java Борланд с 1997 года выпускал JBuilder, но Java была и остаётся более популярна в энтерпрайзе, а не как десктопная плафторма.

gmtd
24.09.2025 00:04Первые несколько лет на Java писали в основном именно десктопные GUI приложения
Можно даже было из них сгенерить exe со встроенной JRE

anshdo
24.09.2025 00:04Ну, начнем с того, что если бы Борланд не дал сманить Хейлсберга, то никакого C# не было бы.

artptr86
24.09.2025 00:04Мне кажется, что в планах у Майкрософта и так было создать альтернативу Java (Хейлсберг как раз J++ первым делом разработал), то есть его и нанимали по сути для такой задачи. Даже без него они бы, вероятно, сделали что-то похожее. К C# (через Managed C++) они ушли просто потому что Sun запретил им дальнейший EEE в отношении Java. Как вариант, был бы язык, более похожий на Java, или гибрид Java и Visual Basic.

Severn Автор
24.09.2025 00:04Очень вероятно, что таки разработали бы. Про Java ведь Гейтс на самом деле говорил, что он всем хорош, кроме того, что разработан не нами.

Severn Автор
24.09.2025 00:04Ну, Кан, возможно, и не дал бы.
Но Кан ушел. А Гейтс предложил три миллиона баксов. Ну, согласитесь, устоять трудно )

AlexMih
24.09.2025 00:044 Концентрация на одной парадигме: Визуальное формошлепство
Как раз нет, с этим у Delphi все было в порядке. Надоело формошлепить - откладывай в сторонку визуальный редактор, бери код, и делай что хочешь - хоть динамический UI твори из кода, хоть вообще пиши что-то общее - новые компоненты, утилиты командной строки, DLL, компиляторы, да хоть операционные системы.

Severn Автор
24.09.2025 00:04Да, но для этого надо было понять, что система глубже, чем кажется на первый взгляд.
А для этого надо ж документацию читать. Или книжку хотя бы Архангельского какого-нибудь.
Так что товарищ прав - Delphi провоцировал начинающих писать примитивно и плохо, как это ни парадоксально. А они уже несли заразу дальше...
HemulGM
24.09.2025 00:04Делфи провоцировал писать быстро минимальное рабочее приложение. Для простых и не масштабных программ, быстрый способ связывать события и писать код на месте - это не плохо. Не говоря уже о том, что на самом деле, код формы и логики у вас отделен (dfm/fmx и pas). Это совсем не то же самое, когда вы описываете кодом UI и тут же пишете бизнес логику. В делфи всегда отделен код формы и бизнес-логики, пусть события и напрямую связаны с формой.
А в масштабных проектах уже есть умеющий программист, который применит один из шаблонов проектирования.

Severn Автор
24.09.2025 00:04"на самом деле, код формы и логики у вас отделен (dfm/fmx и pas) "
Этого вы просто не поняли. В форме ее компоненты и код - это один класс. И если у вас в этом классе, например, редактируется накладная, и описана логика работы этой накладной - это плохо.
Потому что если вы захотите сделать другую форму для той же накладной (иногда бывает надо) - вам придется эту логику накладной повторять, или она не будет правильно работать.
А отделить бизнес-логику от форм - означает реализовать класс накладная, который отрабатывает именно эту логику. Может быть, еще умеет подгружать данные этой накладной из БД и записывать туда. Но никаких форм там нет, и ни о каких формах он не знает.
Тогда вы в принципе можете в программе нарисовать форму для накладной - и не париться, будучи уверенным, что логику накладная отработает. И в другой форме - где, допустим, не одна накладная, а целый список - эта логика тоже отработается.
Или сделать что-то с накладными - например, напечатать все накладные, введенные сегодня. Или перепровести накладные по данному клиенту.

HemulGM
24.09.2025 00:04Форма - это форма, это структура окна (dfm/fmx). Как окно отображается и что в нем располагается - это задача, которую решает эта структура (разметка). Это часть "View" в паттерне MVC.
Файл модуля (pas), содержащий именно класс окна и обработчики кнопок - это "Controller" в MVC.
И осталось только реализовать этот самый класс "Накладная", с которым будет общаться ваша форма, это "Model" в MVC.
Для работы этого механизма, мы обращаемся к классу Контроллера, создаем экземпляр и работаем с накладной. Любое другое окно, которое хочет работать с накладной использует именно Модель и если нужно, может обращаться к другому Контроллеру накладной.
Ни View, ни Model не знают ничего друг о друге. Controller знает обе сущности.

PerroSalchicha
24.09.2025 00:04Delphi же никак не побуждала использовать ни паттерн MVC, ни паттерн MVVC. В типичном Delphi-приложении бизнес-логика была не отделена ни от контроллера, ни от модели, и лишь частично - от представления, и это была каша у начинающих программистов, да и у многих не начинающих тоже.

Severn Автор
24.09.2025 00:04Совершенно верно.
Кстати, Мартин Фаулер не настаивает на отделении контроллера от формы (представления), но настоятельно рекомендует отделять форму (представление) от модели.
В этом случае мы получим представление+контроллер в одном флаконе.
Как то я видел название для такого - DocumentView, и вроде как раз утверждалось, что Delphi ориентировались на такую архитектуру представления.Честно скажу, я пока так и не приучился отделять контроллеры от форм. )

Severn Автор
24.09.2025 00:04Вы неправы, файл модуля - это логика формы, т.е. визуального представления, а не контроллер. Вы посмотрите, в этом файле класс формы создается. И отделить это визуальное представление от этого файла, или заменить его другим, вряд ли у вас получится.
Если вам нужно сохранить какой-то сценарий работы формы - типа, вот по этой кнопке мы подгрузим данные, а вот по этой - их вот так обработаем - вот это как раз логика контроллера. И она, по идее, должна реализовываться в отдельном классе, не в форме.
Именно для того, чтоб обеспечить возможность использовать с тем же контроллером другую форму. В которой эти кнопки могут быть другими, или вообще быть пунктами контекстного меню. Или форма может быть собрана на других компонентах. А контроллер и логика его работы (сценарий) останется неизменным.
А насчет накладной вы правы, это Модель.

raskolbas_rbc
24.09.2025 00:04Что-то вспомнил разговор с одним погромистом в банке, году так в 2000, насчёт Delphi:
"Да ваш Делфи полное дерьмо, вон, я на нем написал программу, там 3 раза форму ввода открыл - и все, память кончилась"

Siemargl
24.09.2025 00:04вранье, форма сама по себе не освобождадась, но реиспользовался уже созданный объект
Да и жрала памяти копейки

tas
24.09.2025 00:04В отличие от MS Visual Fox Pro, где было указано требование 4 МБ, но ни на 4, ни на 8 нормально работать было невозможно. Нормальная работа Visual Fox Pro начиналась при 32 МБ, что для того времени было ну ооочень много.
У меня как раз было 4 МБ и 5-я MS Visual Fox Pro на них летала. Вот 9-й версии да, 4 МБ было мало.

Severn Автор
24.09.2025 00:04Вот тут не скажу, какую версию я запускал. Помню только, что это было в 1996.

myswordishatred
24.09.2025 00:04Помню как классе, кажется, в восьмом я твёрдо решил стать программистом и со слезами на глазах просил у родителей "Ну какую-нибудь книжку о программировании"
Уж не знаю, кто им там насоветовал, но через недельку-две мне подарили огромную книгу по Delphi 7 с установочным диском. Надо сказать, написана она была хорошо, по крайней мере на уровне переменные-условия-циклы-массивы я всё схватил практически сразу.
А когда ещё несколько недель спустя я долистал книгу до работы с графическим интерфейсом это мне просто башню снесло. Это что же получается, я в восьмом классе могу накидать кнопок с полями на форму и написать программу прямо как врослые дяди?
В общем, до этого я ещё думал о том, какая же профессия мне больше подойдёт, то после этого открытия никаких сомнений не осталось.

PerroSalchicha
24.09.2025 00:04огромную книгу по Delphi 7 с установочным диском.
Небось, "Руководство разработчика" Тексейра и Пачеко?

myswordishatred
24.09.2025 00:04За давностью лет уже и не вспомню. Погуглил обложки -- вроде бы похожие.

AlexeyK77
24.09.2025 00:04На дельфи в 90 и начале 200х было написано огромное количество учетного клиент-серверного софта в банках и предприятиях. Технология прямо и просто решала задачи. Но делфи ничего не предложила конкурентного в дальнейшем для 3х звенок, эту нишу забрала J2EE и для интерпрайз веб приложений.
Но для десктоп ПО она по-прежнему актуальна.

Severn Автор
24.09.2025 00:04А как энергетики этот Delphi любили! Я как-то посмотрел, какие программы они делали для управления электрическими сетями...

AlexeyK77
24.09.2025 00:04У Борланда случилась потеря фокуса развития, метания, не приносившие финансового результата. Кто-то еще помнит такое недоразумение как Borland C++ Builder X.

urvanov
24.09.2025 00:04Борланд - это отличный пример, что нужно следить не за загруженностью сотрудников по часам, а за тем, чтобы они делали действительно нужную и полезную задачу.

wiolowan
24.09.2025 00:04Помню, как народ надувал губу, что у Турбо Паскаля экзешник "Hello, world" занимает 2 Мб... Посмотрели бы они на Electron..

randomsimplenumber
24.09.2025 00:04Что то многовато. В те времена, когда турбо паскаль был актуален, любое exe помещалось на дискету. На Delphi, да, можно и больше сделать. Но hello world (без .vcl) тоже на дискету помещался.

WaldemarsonTheForester
24.09.2025 00:04Третья версия вообще .com выдавала :-) Который по определению в 64К влезать должен. Да и потом все было скромненько. Что-то не сходится.

a3d
24.09.2025 00:04Это враньё. У меня не было винчестера на XT, и дисководы были 720 кБ, при этом на турбопаскале я спокойно писал, пользовался его редактором, компилятором, и��терактивным хелпом. Hellow World занимал не думаю что больше 10 килобайт, скорее меньше.
И да, памяти было 640 Кб, и все прекрасно работало, летало даже.

Severn Автор
24.09.2025 00:04Насколько я помню, самые маленькие программы на TP у нас были по нескольку килобайт. Пацаны у меня баловались резидентными программами, так то для них даже 40 килобайт считалось много.

BiTL
24.09.2025 00:04еще бы... в 40кб на Паскале можно 3д-графику с музыкой напихать, даже если не пользоваться EXE-пакерами.
Товарищ выше просто мегабайты с килобайтами перепутал, за давностью лет.
jaguard
24.09.2025 00:04Стандартный носитель информации был 1.44 Мб, кому бы такие ехе нужны были? Их же не запишешь никуда, а ведь еще данные есть.

unC0Rr
24.09.2025 00:04Программе было доступно максимум 640 килобайт (тех самых, которых всем хватит) и это включая сам бинарник, всё адресуемое пространство ограничивалось одним мегабайтом, поэтому ни о каких мегабайтных ехешниках речи быть не может.

WaldemarsonTheForester
24.09.2025 00:04Ну, тут, как раз, есть варианты разные. DOS ориентировался на размер, указанный в заголовке .exe-файла, а не на собственно размер файла. И это можно было творчески использовать. Но борландовские компиляторы к этому не прибегали.

anshdo
24.09.2025 00:04В TP были оверлейные модули, которые можно было по мере надобности в память загружать и выгружать, эдакий прообраз DLL. Так что бинарники теоретически могли быть и больше 640 кб.

WaldemarsonTheForester
24.09.2025 00:04Посмотрел доки, освежил память, можно было ручками через COPY склеить .exe и .ovl, и в шестом Турбо Паскале ovelay unit умел из такой конструкции грузить оверлеи. Может, и в более ранних версиях умел. Так что технически сам .exe файл мог быть действительно сильно больше 640 KB.

Buzzzzer
24.09.2025 00:04Это Дельфи с vcl 1.5 метра весил, даже с пустой формой. После turbo pascal и написания всяких резидентников под DOS мой внутренний перфекционист очень сильно негодовал из за размера, поэтому я извращался на kol&mck вместо vcl и получалось вполне годно, но костылей там тоже было много.

BiTL
24.09.2025 00:04Тем неменее были способы уменьшить размер EXE-шника Delphi до нескольких десятков килобайт (или даже меньше, не вспомню сейчас). Без UPX, конечно.

unC0Rr
24.09.2025 00:04Это в какой версии? Мне помнится что-то в районе 400 килобайт с пустой формой и около 30 пустая программа, если не играться с ключами компиляции.

Barnaby
24.09.2025 00:04Меньше. И там были разделяемые библиотеки, если их не компилить статически, а ставить отдельно то было меньше.

PerroSalchicha
24.09.2025 00:04Та ну, такого не было никогда, килобайт десять-двадцать он занимал, если не ошибаюсь. В Delphi пустая форма с такой надписью, в зависимости от версии, занимала килобайт 150-400, и то, если не использовать KOL. На Турбо Паскале я писал графический редактор на компе с 480К ОЗУ, и там хватало места и для DOS, и для Паскаля, и для самого редактора, и ещё чуток оставалось.

a3d
24.09.2025 00:04Кто-то практически смог заставить какой-то аналог turbo vision for Python выглядеть и работать также как в те времена, в текстовом цветном виде с рамочками, radio button и т.д.

sergey_prokofiev
24.09.2025 00:04Году в 2000м, товарищ попросил сделать простенькую программу чтобы отслеживать контракты/ордера для своей фирмы на 3 калеки. С помощью Delphi+DevExpress+(dBase?) я за полдня наваял поделку. Чуваку понравилось и он ушел в закат. Я о нем забыл допив выставленное пиво.
Какое же было мое удивление, когда в районе 2020 года мне незнакомый чувак(номер тлф не менялся все это время) с вопросом про то что какая то моя софтина не запускается. Как выыяснилось, это все тот же чувак. Он все эти 20 лет использовал мою поделку в своей фирме(которая так и осталась размером в 3 калеки), использовал как основой рабочий инструмент. А тут пришлось мигрировать на новую винду и все поломалось. Оправившись от удивления, я сказал что не взлетит - сорцов нет. Нифига, сорцы я ему по доброте душевной подарил 20 лет назад.
В общим обновил я ему все и отдал. За тоже символическое пиво.

Vedomir
24.09.2025 00:04И среда разработки поднялась на современной ОС? Я видел программы на Delphi 6 и Visual Basic 6 (еще не .net) несколько лет назад и там обычно развертывание нужной версии IDE да еще с нестандартными плагинами дичайший квест был.

PerroSalchicha
24.09.2025 00:04И среда разработки поднялась на современной ОС?
Delphi 7 я на десятке несколько лет назад ставил, установилась, заработала. По-моему, дефолтные пакеты надо было руками после инсталлятора доустановить, или что-то в этом роде, я уже не помню. Шестая тоже должна установиться, там такой же 32-битный инсталлятор. Более ранние устанавливаться не должны, там инсталлятор 16 бит.

forever_live
24.09.2025 00:04А что ей будет-то? Должно всё работать. Начиная с четвёртой делфи поставится и на седьмую винду, а начиная с 2007й и на десятой винде заработает. Но к авторам нестандартных плагинов могут быть вопросы, да.

Severn Автор
24.09.2025 00:04У меня Delpi 7 под Windows 7 встал без проблем.
Как будет работать на Win 10 - попробую, скажу.

HemulGM
24.09.2025 00:04Delphi 7 на Win11 работает без проблем. Как и все даже старые собранные программы

Vedomir
24.09.2025 00:04Спасибо, не ожидал такой кучи ответов, конкретно мне это не нужно, я и видел такие проекты последний раз года четыре назад в в совсем другой оранизации и даже там уже над ними не работал, хотя пытались к ним подключить.

OlegZH
24.09.2025 00:04Оправившись от удивления, я сказал что не взлетит - сорцов нет. Нифига, сорцы я ему по доброте душевной подарил 20 лет назад.
Просто рождественская история какая-то! Пушистая программистская история.

ss-pol
24.09.2025 00:04Microsoft же активно включается и в это соревнование, приобретя Fox Software и его Fox Pro - клон DBase, который он далее много лет развивает.
Микрософт уничтожила Foxpro вполне целенаправленно. И к развалу Борланда приложила руку тоже, судя по "В 1996 фирму Борланд оставляет и Андерс Хейлсберг. Уходит в Microsoft. "...
Файловые БД живут и процветают - посмотрите на тот же sqlite. Прикрутить клиент-сервера к старому подходу тоже было вполне возможно.Сколько производных проектов и продуктов было уничтожено вместе с Фокспро... Очень жаль...
Главный урок, который я из этого вынес - нельзя полагаться на собственнические продукты, технологии, протоколы. Как раз тогда перешёл на ГНУ/Линукс.
BiTL
24.09.2025 00:04Микрософт уничтожила Foxpro вполне целенаправленно
Туда ему и дорога
И к развалу Борланда приложила руку
Еще и советский геймдев подорвала, переманив Пажитнова!
Сколько производных проектов и продуктов было уничтожено вместе с Фокспро...
А сколько было уничтожено вместе с MS-DOS! Ужас! Негодяйский Микрософт!
А еще майкрософт купила Skype, который был написан на Delphi, и убила его за это.
Total Commander и The Bat! пока мужественно держатся!Как раз тогда перешёл на ГНУ/Линукс.
Соболезную

Vedomir
24.09.2025 00:04Только открытый софт спасает от рабской зависимости от вендора, Microsoft и кучу своих технологий похоронила - те же WinForms или WPF так что тут нет никакой особой зловредности в отношении других фирм, крупные корпорации в равной мере и свое хоронят. Ну про кладбище гугл тоже многие знают.

ss-pol
24.09.2025 00:04Только открытый софт спасает от рабской зависимости от вендора
Полностью, конечно, не спасает, но сильно эту зависимость снижает. К сожалению это работает не всегда. Крупные проекты СПО так или иначе находятся либо под контролем либо под сильным влиянием корпораций.

Vedomir
24.09.2025 00:04Если корпорация делает то, что надо пользователям, то и нормально, а вот убить или радикально сменить направление уже нельзя, примеров успешных форков много, вроде MariaDB

ss-pol
24.09.2025 00:04Согласен, глобально СПО в этом плане здорово изменило расклад даже для крупных проектов. Зависимость от собственника ПО сменилась на зависимость от спонсоров СПО. Что уже весьма неплохо, потому что спонсоров может быть много разных.

Vedomir
24.09.2025 00:04Ключевое здесь множественное число. Не понравится один спонсор, можно выбрать другого или самому стать спонсором (в том числе коллективно).
Открытые исходники не столько про бесплатность, сколько про конкуренцию для разработчиков проекта.
Такое антимонопольное законодательство на общественных началах.
Не "мы будем сами дописывать вместо плохого разработчика" а "мы заплатим другому разработчику" хотя в очень крупных компаниях возможен и вариант дописывания.

ss-pol
24.09.2025 00:04Не понравится один спонсор, можно выбрать другого
но можно и не найти... увы
Всё это более-менее работает для мелких проектов, но с крупными беда.
Vedomir
24.09.2025 00:04А много открытых проектов, у которых основной спонсор делает вот прямо сильно не нравящиеся сообществу вещи?
Я помню не так много обратных случаев, и в них спонсоров меняли вполне успешно - например MariaDB.

ss-pol
24.09.2025 00:04А много открытых проектов, у которых основной спонсор делает вот прямо сильно не нравящиеся сообществу вещи?
Кого ты подразумеваешь под сообществом? Разве кто-то кого-то спрашивает, что им нравится, а что нет? Конечно, рядовые пользователи могут жаловаться, но реально повлиять на что-то они не могут, потому что даже если они и дают денег, то немного и нерегулярно. Разработка обычно управляется конкретными людьми, которые принимают решения, что будет, а что нет. В крупных проектах они на зарплате. Вот на их решения и влияют спонсоры. Степень влияния оценить со стороны трудно, ведь договорённости происходят не публично. Но в принципе оценить степень влияния работодателя на наёмного работника несложно, она велика, хоть и не безгранична. Работник теоретически может уволиться и попытаться форкнуть гигантский проект (что почти невозможно в общем случае). Ну или найти другую корпорацию, которая будет продвигать альтернативную линию...

Einherjar
24.09.2025 00:04Microsoft и кучу своих технологий похоронила - те же WinForms или WPF
Вы о чем? И то и другое полностью поддерживается на сегодняшний день. И даже новые фичи получает.

Vedomir
24.09.2025 00:04Давайте я задам вам простой вопрос - почему Microsoft сделала Visual Studio Code не на WinForms, не на WPF ни на одной своей десктопной технологии, а вообще на Electron со всеми его известными недостатками?
Даже если не вдаваться во внутренние технические подробности кроссплатформенность стала обязательным требованием для любой технологии построения не-веб приложений лет 10 назад если не 20. В том числе для продуктов самой Microsoft, они даже для себя не имеют подходящей технологии.
И даже сообщество пыталось - во времена самостоятельности Xamarin они пытались запилить WinForms под Linux. Microsoft купила их и закрыла этот проект.
Microsoft со времен смерти этих двух технологий успела сделать еще несколько фреймворков для построения не-веб приложений и большую часть тоже похоронила. UWP был и умер. Silvelight пролетел вообще незаметно. Потом были Xamarin Forms который мутировал в MAUI и который вроде как до сих пор не имеет поддержки Linux. Есть еще WinUI. Может еще что-то есть, я уже так пристально не слежу.
То что в WinForms и WPF правятся какие-то мелочи это не поддержка, это в лучшем случае поддержание коматозника на жизнеобеспечении, в худшем приукрашивание трупа.
Пример того как WPF должен был поддерживаться - это Avalonia, сторонней компании пришлось написать аналог WPF с нуля чтобы можно было приложение на WPF на тот же Мак портировать.
Десять лет назад я переводил статью про проблемы с производительностью WPF и в ней ссылался на другую статью Семь лет WPF: что изменилось? в 2013 ��оду уже писали, что в WPF ничего не изменилось за 7 лет, не смотря на массу проблем.

Einherjar
24.09.2025 00:04не на WPF ни на одной своей десктопной технологии, а вообще на Electron со всеми его известными недостатками?
Они не кроссплатформенные. Как один единственный продукт может говорить о живости или неживости других технологий?
То что в WinForms и WPF правятся какие-то мелочи это не поддержка, это в лучшем случае
Чего вам нехватает?
Пример того как WPF должен был поддерживаться - это Avalonia,
Только подавляющее большинство того что вы подразумеваете под "поддержкой" это портирование фич из WPF. Даже возможность перехвата необработанных исключений добавили буквально пару месяцев назад.

Vedomir
24.09.2025 00:04>Они не кроссплатформенные.
Так про это и речь. В живые технологии, развиваемые и поддерживаемые, добавляют поддержку новых платформ.
В том числе от Microsoft - у них есть живые аналогичные продукты, например MAUI.
>Как один единственный продукт может говорить о живости или неживости других технологий
Ну так давайте посмотрим но другие современные продукты - например Teams они давно даже у Microsoft кроссплатформенные.
Teams тоже на Electron и React вроде как планировали на React Native перейти.
>Только подавляющее большинство того что вы подразумеваете под "поддержкой" это портирование фич из WPF
Учитывая, что это крохотная независимая компания из пары десятков человек, которым пришлось написать аналог WPF с нуля, это не удивительно.

Einherjar
24.09.2025 00:04Так про это и речь. В живые технологии, развиваемые и поддерживаемые, добавляют поддержку новых платформ.
Вы смешиваете в кучу развитие и поддержку. Мертвая технология очевидно не получает ни того ни другого. В данном случае это очевидно не так. WinApi тоже не особо то меняется с годами. И, внезапно, туда не добавляют поддержку новых платформ. Мертво? Тогда попробуйте сделать приложение которое его не использует (в том числе косвенно).
Куча энтерпрайза сидит на винформах и впфе и еще десятилетиями будут сидеть, им не нужны ни линукс ни какие то еще революционные нововведения. Вот это показатель живости технологии, а не ежемесячное добавление глючащих свистоперделок.
ни давно даже у Microsoft кроссплатформенные.
Судя по отсутствию ответа на вопрос чего нехватает тому же WPF, и приведенные примеры фреймворков которые функционально в лучшем случае можно назвать вяло догоняющими, я правильно понял что кроссплатформенность это единственный ваш критерий живости/мертвости технологии?
А яблочный SwiftUI или что там у них тогда тоже мертвый? Там же нет фичи сделать гуй под виндовс
В том числе от Microsoft - у них есть живые аналогичные продукты, например MAUI.
Так там линукс не поддерживается, по вашей логике значит он тоже мертв.

Uporoty
24.09.2025 00:04Ну так давайте посмотрим но другие современные продукты - например Teams они давно даже у Microsoft кроссплатформенные.
Тут чуть сложнее. От Teams требуется не только работать на разных платформах, но и работать в браузере. Поэтому совершенно логично разрабатывать его на веб-технологиях, а не на десктопном (пусть и кросс-платформенном) фреймворке.

artptr86
24.09.2025 00:04Так это же у них стратегическое решение: не создавать публично доступные графические тулкиты под конкурирующие платформы, потому что это может нести риск для самой платформы Windows.

Vedomir
24.09.2025 00:04>не создавать публично доступные графические тулкиты под конкурирующие платформы
Уже нет, разве что Linux до сих пор в немилости, как исключение. А так они давно пытаются делать такие тулкиты, просто они вместо развития старых технологий, делают новый.
Я уже не слежу особо, мне без поддержки Linux не интересно, но последнее вроде MAUI.

Uporoty
24.09.2025 00:04почему Microsoft сделала Visual Studio Code не на WinForms, не на WPF ни на одной своей десктопной технологии, а вообще на Electron со всеми его известными недостатками?
Потому что начинали делать его не они, а Github (еще до покупки мелкомягкими) со своим Atom. А когда Atom взлетел, MS его форкнули и частично переписали.
Потом были Xamarin Forms который мутировал в MAUI и который вроде как до сих пор не имеет поддержки Linux. Есть еще WinUI.
При работе на Windows MAUI как раз использует виджеты WinUI.

PerroSalchicha
24.09.2025 00:04Потому что начинали делать его не они, а Github (еще до покупки мелкомягкими) со своим Atom. А когда Atom взлетел, MS его форкнули и частично переписали.
Я не думаю, что они там форкали что-то из самого Атома. Да и не могу сказать, что Атом "взлетел", слово "летать" ему было не знакомо, из всех текстовых редакторов это был единственный, который у меня отображал буквы медленнее, чем я их набираю. По-моему, его не любил никто :)
Но Электрон, как фреймфорк, писался как раз под Атом, и назывался на момент создания VS Code еще Atom Shell. Вот этот фреймворк и объединял оба продукта, больше ничего.

Severn Автор
24.09.2025 00:04"из всех текстовых редакторов это был единственный, который у меня отображал буквы медленнее, чем я их набираю"
Еще ФоксПро так умел. Что досовский, что визуальный под виндоус.
Слушайте, так может это у Микрософта просто такой, понимаете, кИрасивый нацИональный обычай? Чтоб текст в среде отображался медленнее, чем программист его набирает?

PerroSalchicha
24.09.2025 00:04Слушайте, так может это у Микрософта просто такой, понимаете, кИрасивый нацИональный обычай?
Я бы поддержал, но на Фоксе работать не довелось, а Атом был у меня еще гитхабовский и на убунте. Я, наоборот, был приятно удивлен, когда перешел на VS Code. Не знаю, что там они сделали с Электроном, но оно было, и, наверное, остается единственным хорошо работающим приложением на нем.

Severn Автор
24.09.2025 00:04Ну, Гейтс с Каном друг друга оценивали достаточно адекватно, сильно не любили, но очень уважали. Так что развалить конкурента, тем более такого - очень даже правильный ход, ничего личного, просто бизнес.

apcs660
24.09.2025 00:04Спасибо за статью, писал когда то в турбо паскале - ничего уже не вспомню толком, на задворках памяти осталось что индекс массивов в нем начинался с 1.
Из тех же времен: встретил как то на проекте сына (в годах уже) основателя Novell Netware - он рассказал как Билл Гейтс был у них в гостях, а я вспомнил как в 90е изучал немного netware. Сик транзит глория мунди...

forever_live
24.09.2025 00:04индекс массивов в нем начинался с 1
Нет, индекс массивов в нём может начинаться с 1. Но не обязан.

apcs660
24.09.2025 00:04С 95 года не касался Паскаля (визуализация расчетов была на нем в дипломе) - помню что по умолчанию была 1 и меня это "заедало" так как до него начинал на С и впоследствии, 1 по умолчанию нигде не встречал. Делфи прошел мимо меня - следующим языком была Java, и в целом, сишный синтаксис привычнее. Но на Паскале нормальные игрушки делали и обманку Нортона, студентами, неплохой язык, меньше ошибок чем в С у начинающих

BiTL
24.09.2025 00:04да нет там никакого умолчания. Массивы также как и везде. С "1" начинается индекс символа в типе string, к которому вы как к массиву можете обратится , потому что первый байт (с индексом "0") это длина строки.

apcs660
24.09.2025 00:04Может память подводит, глянул спеку (пардон не все открывается без впн а я на мобиле)
https://www.cs.bilkent.edu.tr/~guvenir/courses/CS315/iso7185pascal.pdf
По возрасту Паскаль с которым работал начиная с 1989 по 1995, глава 6.4.3.2:
Any type designated packed and denoted by an array-type having as its index-type a denotation of a subrange-type specifying a smallest value of 1 and a largest value of greater than 1, and having as its component-type a denotation of the char-type, shall be designated a string-type.
The corresp ondence of character-strings to values of string-types is obtained by relating the individual
string-elements of the character-string, taken in textual order, to the components of the values of the string-type in order of increasing index.Возможно у вас более свежий опыт и версия прсвежее.
А то на ANSI C как то пришлось работать на одном проекте а там большей части привычных функций не оказалось к сожалению которым привык

randomsimplenumber
24.09.2025 00:04В паскале границы массива можно указать при обьявлении. А в Delphi вроде как кроме паскалевских коротких строк есть и 0-terminated.

Severn Автор
24.09.2025 00:04Скажу вам, как старый пасквилянт старому сишнику )
Теоретически, можно было объявить тип массива с индексом от нуля до нужного вам значения. Что-то типа такого
Type
TIndex0_9 = 0..9;
TArray0_9Integer = Array[TIndex0_9] of Integer;
var MyArray: TArray0_9Integer;

RedEyedAnonymous
24.09.2025 00:04Можно проще - TSomeArray = array[0..9] of SomeType;
А если приспичит, то и array['A'..'Z'] of SomeType.
HemulGM
24.09.2025 00:04Проще
var SomeArray := [1, 2, 3]; или var SomeArray: TArray<TSomeType>;Давно использую только динамические массивы

RedEyedAnonymous
24.09.2025 00:04Я имел в виду TurboPascal, а также Delphi по 7ю версию включительно. Что там дальше с типами нагромоздили - уже не отслеживал. Ну, развивается - и хорошо... кому-то.
Динамические массивы - они слегка в другую сторону. Статические с индексацией не целыми числами из моего второго примера в давние времена сходили за жалкое подобие словарей и были временами полезны - для таблиц подстановки и т.п.

forever_live
24.09.2025 00:04Нет, в массивах вообще не было никакого умолчания. Индекс первого элемента всегда надо было указывать явно в определении типа или переменной.
vara: array[3..5] of char;Потом появились открытые массивы и динамические массивы, в которых начальный индекс фиксирован, и это 0.
Вот в строках индекс первого элемента всегда был 1, до недавнего времени.

kipar
24.09.2025 00:04Помимо крутой статьи в целом, удивлен упоминанием Eureka.
Была у нас на лабах в универе, хотя параллельно с ней был и матлаб, но было удивительно видеть символьные вычисления, решение уравнений и построение графиков (т.е. по сути всё чем мы пользовались из матлаба) в досовской программе с интерфейсом турбо-бейсика.
PerroSalchicha
24.09.2025 00:04Была у нас на лабах в универе, хотя параллельно с ней был и матлаб
Первая мысль в моей голове: "Так матлаб же тоже под DOS!" Потом глянул на календарь: "Ах, да..."

ALexKud
24.09.2025 00:04А я вернулся к старой двухзвенке и она на новой delphi очень даже неплоха в корпоративной сети с SQL Server и даже с SQLite через FireDac драйвер.
Практически мгновенная компиляция, остутствие тормозов даже при работе через VPN выгодно отличает связку DElphi+SQLserver+хранимые процедуры от PHP, программы которой даже не запускаются на старых компах под Win10.

Severn Автор
24.09.2025 00:04Еще вопрос - а для чего и почему используете хранимые процедуры?
Их же отлаживать и менять на порядок сложнее, чем алгоритм на Паскале?
Или вам так критична скорость? Или просто вам нравится писать это на SQL?
HemulGM
24.09.2025 00:04Конечно важна скорость. Хранимые процедуры работают на порядок быстрее, без перегонки тонны данных

ALexKud
24.09.2025 00:04Логику в хранимых процедурах применяю потому что проще разрабатывать приложения баз данных, чем использовать одни запросы, особенно если нужна сложная обработка данных и даже не только это, а то что код запросов не хранится на клиенте и я использую триггеры БД для хранения всех корректировок схемы и таблиц БД, пользователей, хранимок, короче всего DML. Приложения у меня сложные и я применяю не только хранимки, но и функции, синонимы и системные иногда объекты SQL Server. Насчет что писать сложнее на SQL чем на обычном языке - это не так. Просто SQL это немного другой подход в программировании, тут требуется хорошее знание SQL и умение оптимизировать SQL код и еще много чего архитектурного в создании приложений БД. Сейчас я заканчиваю портирование одного своего приложения на SQLite. Там нет хранимок и я ощутил насколько неудобно и сложно разрабатывать в локальной БД приложение со сложной логикой без хранимок. Где все делает одна хранимая процедура, с запросами иногда приходится городить огород из последовательных наборов запросов и усложнять код на клиенте. Использование CTE не всегда выручает, но помогает. В общем объединение двух БД, серверной и локальной получилось, но проблем с локальной БД SQLite и ее запросами было много. Там где работает простой код запроса хранимки SQLserver, перенос запроса в SQLite иногда не работает и приходится его оптимизировать, меняя много чего в коде. Думал что это будет быстро сделано, так как рельсы уже были, но паровоз пришлость строить заново.

Gradiens
24.09.2025 00:04Помню где-то в 2002-2004 перешел на Borland C++ Builder. Это вам не турбо паскаль!
Если надо было менять заголовочные файлы - все, работа вставала. Приходилось днем наугад что-то писать и на ночь запускать компиляцию.
Наша компания обращалась в поддержку Борланда, рассказала о проблеме. Типа, вот проект, компиляция занимает 6 часов.
Они такие: что, правда 6 часов? Не может быть!
Мы: ну да, вот пруф.
Они: Серьезно? И оно у вас успешно скомпилилось? И не упало??

Source
24.09.2025 00:04Ух, ностальгия. Я начинал осваивать программирование в Delphi 6. И это была реально классная и быстрая IDE. Delphi 7 тоже был хорош. А вот, начиная с Delphi 8 всё покатилось куда-то под откос. Кажется, фокус компании сместился на C# Builder, но он ожидаемо проиграл Visual Studio. Ещё была странная шляпа в виде Delphi for PHP.
В общем, в районе 2006 года я и перешёл на C# для десктопных приложений и на PHP для веба. Только уже не на продуктах Borland/CodeGear, а на VisualStudio и PHP Expert Editor.
P.S. Кстати, посмотрел, буквально 2 недели назад вышла новая мажорная версия RAD Studio, так что Delphi то всё ещё довольно активно развивается.

BloodyEagle
24.09.2025 00:04PHP Expert Editor
о, да... Сам в нем начинал кодить на PHP. Помнится была бесплатная лицензия "для жителей СНГ" :)

antaki93
24.09.2025 00:04Считаю несправедливым, что нигде (даже в комментариях) не упомянут Lazarus — свободный кроссплатформенный аналог Delphi с классическим UI. Иногда пользуюсь, чтобы набросать что-нибудь быстро для личных нужд.

Nikollor48
24.09.2025 00:04Плюсую. Нравится, что можно собрать нативный бинарь под Linux и Windows из одного кода. ОPM подкинул пакет и поехали

Nikollor48
24.09.2025 00:04Хорошая ретроспектива. Главный урок Борланда - продуктовый гений не спасает от управленческого расползания

gmtd
24.09.2025 00:04Borland JBuilder забыли
Написан был на Java, в конце 90-х еще вродеОсновная среда для разработки на Java какое-то время, если не ошибаюсь

Sergey1124
24.09.2025 00:04Когда поняли что JBuilder не может конкурировать с Eclipse, сделали JBuilder 2007 основанный на Eclipse. У нас в Питере была команда участвовавшая в разработке, и я в ней работал какое-то время. Помню делали функциональность позволяющую генерировать код по темплейтам, это должна была быть киллер-фича сильно ускоряющая разработку.

alexey_public
24.09.2025 00:04И вот никто не вспомнил - а ведь для Delphi сущес��вует просто шикарный DeveloperExpress, это целый отдельный мир, который просто нечем заменить. Поэтому стоит не очень приятно. Но он того стоит. Писать приложения для БД на нём это сказка, тот же TreeView - который позволяет строить иерархическое дерево записей автоматически по нужным индексам, при это все методы фильтрации, сортировки, фиксированных столбцов и прочая... прочая...

PerroSalchicha
24.09.2025 00:04И вот никто не вспомнил - а ведь для Delphi существует просто шикарный DeveloperExpress
Я прямо сейчас его использую. Он уже много-много лет существует не для Delphi, а для всего - и под WinForms, и под WPF, и под ASP.NET, и под React. Двоякие впечатления, если честно. С одной стороны, да, настолько навороченных элементов управления не найдёшь. С другой стороны, там за несколько десятилетий их существования наворочено куча легаси-слоёв, куча избыточности, и хотя сложные вещи там делаются проще, но простые - наоборот, намного сложнее.

alan008
24.09.2025 00:04Плюсую, это оооооочень огромная куча классов, где внутри всё настолько архи-сложно, что начинаешь думать "я просто хотел табличку", а не табличищу, умеющую строить звездолет и улетать в космос (навеяно старым мемом, что в один момент разработчики программы Nero Burning Rom сначала добавили в программу видео редактор, потом написали свою ОС, построили звездолет и улетели в космос)

alexey_public
24.09.2025 00:04Но результат зато просто изумительный, просто надо потратить относительно много времени на вход, зато потом всё делается легко и быстро.

alexey_public
24.09.2025 00:04Это да, поэтому под свои цели работы с DevExpress я давным давно написал набор прокладок, чтобы все основные типовые действия вызывать быстро и легко. Наверное надо было выложить на гитхаб, но как-то не сложилось.

Severn Автор
24.09.2025 00:04Он есть, и не только для Delphi. Для .Net и C# он тоже есть.
И знаете, что самое приятное? Что и для Delphi, и для C# элементы управления в DEEditors устроены почти одинаково, во всех есть свойство Value, например, содержащее редактируемое значение.Хорошие компоненты, только дорогие и тяжелые.

Akon32
24.09.2025 00:04DevExpress хорош, но до гибкости HTML не дотягивает.

alexey_public
24.09.2025 00:04Согласен. Но - я не встречал решений на html, которые просто повторили бы devepress. А сам devexpress можно всегда по желанию доработать, он продаётся с исходниками, бери и переделывай.

eugeneyp
24.09.2025 00:04Еще пропущена веха про Linux Powerhouse, когда Corel и Borland хотели объединиться. Вот новость про это https://www.linuxtoday.com/developer/linuxpr-corel-inprise-borland-merger-to-create-linux-powerhouse/
Т.к. у Borland был аналог Office и Kylix, а у Corel сборка Corel Linux и CorelDraw работающий на Linux через Wine. Но насколько я помню из новостей закончилось это тем что MS купила акций Corel и Borland.
Severn Автор
24.09.2025 00:04Кажется, тогда у Corel был еще и WordPerfect. Вот насчет объединиться не знаю, но сотрудничать вроде действительно хотели. И потом вроде появился Corel Office.
В общем, маркетинговые войны в полный рост, с объединением против общих врагов, фланговыми атаками и т.п. - Джек Траут был бы доволен )

NightBlade74
24.09.2025 00:04Turbo Assembler не имел своей среды разработки, как самостоятельный продукт он оставался обычным компилятором командной строки. Правда, он включался в некоторые версии Turbo Pascal и Turbo C. А вот отладчик Turbo Debugger имел UI аналогичный средам разработки Turbo.
В 1995 Borland выпустил в продажу новый продукт - Delphi 1.0.
Что это такое - поняли не сразу.На самом деле уже как четыре года существовал Visual Basic, который, при всех его ограничениях имел вполне себе нормальную RAD. А в том же 1995 вышел VB 4.0, который умел делать как 16-битные, так и 32-битные приложения, работать с COM/ActiveX и любыми БД, был бы драйвер. Т.е. в данном случае 16-битный Delphi опоздал, хоть Borland и исправила свою ошибку, ударными темпами выпустив вторую версию, правда, задорого... Ну и другие RAD под Windows уже существовали.

alan008
24.09.2025 00:04В районе 2016 года из команды Delphi (уже не помню какая фирма ей владела в тот момент, скорее всего уже Embarcadero/IDERA) ушел разработчик компилятора Delphi - Allen Bauer
Cсылка на сообщение об этом:
http://blog.therealoracleatdelphi.com/2016/02/a-new-adventure.html

alan008
24.09.2025 00:04Все пишут, мол Delphi уже отжил свое. Но на чем тогда создавать GUI под Винду в 2025 году? С# как на уровне самого .NET так и на уровне GUI-фреймворков под винду штормит так, что страшно делается.
Вы посмотрите сравнительную табличку в этой статье, это ж неадекватно:

artptr86
24.09.2025 00:04Пишите на Qt. Заодно будет возможность портировать программу на Linux и Mac.
Или на Avalonia, если .NET. Оно тоже кросс-платформенное и уже достаточно стабильное.

alan008
24.09.2025 00:04Delphi сейчас пробует кросс платформу, причем уже довольно давно. Но там столько всяких "если", что это уже отдельная история. В линуксе к паскальному коду проще Лазарус прикрутить без всякой кросс платформы. Визуальщина правда будет уже на других, лазарусовских, компонентах.

HemulGM
24.09.2025 00:04Delphi давно позволяет создавать кроссплатформенные приложения. При чем один и тот же проект может быть собран сразу под все платформы (win, lin, mac, ios, android). И позволяет даже одни и те же формы параллельно адаптировать под разные экраны. При этом будет полноценная поддержка любого dpi на всех устройствах, т.к. рендер ui не зависит по сути от api и поддерживает работу на direct2d, directx, opengl, skia, opengles, cairo, gdi+ и и.д. На всех платформах доступен и 2d и 3d контекст.
Ну и собирать приложения под все платформы можно на одной машине.

Severn Автор
24.09.2025 00:04Звучит здОрово.
Может, наберусь смелости сам попробовать.
А какие у него системные требования к установке? Под Windows 7 можно?А вот чуть выше - https://habr.com/ru/articles/949956/comments/#comment_28877930 - пишут, что кроссплатформенность с оговорками.
Может, расскажете чуть подробнее об этих оговорках?
Вот мне хотелось бы собрать, допустим, приложение под Windows (допустим, серверная часть и клиентская), и плюс два легких клиента под смартфоны - Android и IOS.
Насколько это окажется сложно?
HemulGM
24.09.2025 00:04Единственная оговорка - это то, что под Линукс создание GUI требует установки дополнительной части, называемой FMXLinux, которая не установлена по умолчанию и устанавливается в пару кликов из менеджера пакетов GetIt. Эта часть, по сути, является реализацией платформы Linux для FMX.
Чуть поясню
В FMX есть слой абстракции для работы создания GUI. А для каждой платформы есть собственная реализация работы с ОС и при сборке используется конкретная реализация. Для Windows - FMX.Platform.Win и т.д. соответственно. FMXLinux как раз предоставляет FMX.Platform.Linux и всю прослойку для работы приложения.
FMXLinux доступна только в Architect версии среды разработки (как, собственно, и в целом возможность компилировать под Линукс). В бесплатной версии или версиях ниже Architect нет возможности собирать под Линукс.
Работать FMX будет без проблем на Win7 и с ручными доработками (не советую) на WinXP SP3. Проблемы в основном с тем, что под WinXP нет дефолтного рендера Direct2D, который появился только в Vista. На Vista я не тестировал и не тестировал на XP другие графические бэкенды, например просто GPU (DX).
Клиент серверное приложение создать максимально просто. Есть и бэкенд фреймворки: MARS (простой, REST), DMVC (сложный, REST, ORM), Horse, mORMot и другие. Для клиентских приложений есть штатный набор компонентов для работы REST (можно получить данные и вывести в датасет даже в дизайнтайм). Либо просто использовать System.Net и асинхронные запросы.
Создавать под Андроид не составляет никакого труда. Из коробки будет билдиться сразу. Для сборки под iOS требуется XCode (т.е. нужна машина на MacOS или виртуалка). Для сборки под Линукс требуется подключиться к любой Линукс машине и получить SDK (делается всё автоматически и достаточно сделать это один раз), ну и требуется Architect версия среды.
Всё это не сложно делать, если знаешь как делать. С нуля будет сложнее, но документация и инструкции есть в docwiki.
Я использую MARS и свою библиотеку FastAPI для клиентского приложения (также временами пишу полноценный генератор кода на основе OpenAPI, MARS умеет его сам генерировать на основе кода бэкенда). Т.е. пишем бэк, получаем openapi спецификацию, получаем набор модулей для клиента для работы с сервером.
Либо, использую JsonToDelphiClass
Написанный мною же на Delphi + FMX



Ну и можете посмотреть что у меня ещё есть на GitHub, в том числе на FMX

Siemargl
24.09.2025 00:04аналог дельфи это банальный винформс

Uporoty
24.09.2025 00:04а аналог дельфи FMX - это MAUI (или та же Avalonia, если нужна поддержка Linux)

Siemargl
24.09.2025 00:04Вообще-то нет.
Мяуи это декларативная разработка на xaml, более продвинутая, но и более тормозная.
fmx же это просто кроссплатформенная vcl со стилями

HemulGM
24.09.2025 00:04Это не кроссплатформенная vcl со стилями. Это сильное заблуждение.
FMX - это html+css подобный подход с дизайнером как самой формы, так и стилей элементов. Это возможность создавать как растровые стили элементов, так и векторные. Это возможность использовать возможности GPU для рендеринга, в том числе шейдеры.
Vcl так же близок к FMX как Winforms к Avalonia.

Siemargl
24.09.2025 00:04Я специально пролистал учебник по Файрманки, никакой декларативной разработки интерфейса там нет.

HemulGM
24.09.2025 00:04Я и не говорил о декларативной разработке UI, я говорил о подходе. При котором есть Модель (класс контрола), а есть его Представление (стиль).
Стиль в FMX гораздо сложнее, чем просто шкурка. Стили в FMX - это как классы CSS, только которые ты не кодом описываешь, а визуально. Любой контрол может использовать любой стиль. И каждый контрол может использовать отдельный стиль.

Severn Автор
24.09.2025 00:04"есть Модель (класс контрола), а есть его Представление (стиль)"
Это откуда вы такие термины взяли для данного случая?
Модель и Представление - это о данных, с которыми работает программа.
А класс контрола - это, извините, никак не модель. Это служебный класс, используемый в элементах представления.
Простите, но вы сильно путаетесь в терминологии. Либо исповедуете идеи какой-то экзотической школы.

HemulGM
24.09.2025 00:04В FMX класс контрола - это Модель. Потому что по сути, класс контрола хранит лишь данные и не говорит о том, как он должен отображаться. Не говоря уже о том, что класс контрола может быть основан на TPresentableControl, который позволяет переключать презентационный класс. Например, есть класс TMemo, который основан на TPresentableControl, что позволяет отображать в окне как обычный контрол FMX, так и нативный для платформы контрол у которого будет свой собственный реальный Handle. А сам TMemo - это лишь контейнер для данных.

Siemargl
24.09.2025 00:04Нет. Модель в MVC - это всегда бизнес - данные, а не способы и методы их отображения. Поэтому контрол - никогда Моделью быть не может.
Впрочем, профдеформация, продажника.

Siemargl
24.09.2025 00:04Внезапно, декларативная разработка UI, и есть подход, точнее целая методика разработки.

unclegluk
24.09.2025 00:04... И Борланд, Парадоксов друг.
Больше всего интересно, как нелегал стал директором. Что, прям вот пришел к властям, сказал «Я тут становлюсь директором мега крутой конторы, Дельфи замутим, в будущем, простите засранца и дайте грин-карту.», а те такие: «Нураз так, то тогда ладно. Держи.»?

Severn Автор
24.09.2025 00:04Ну, если у тебя есть работа (с тобой готовы заключить контракт) - значит, ты имеешь право тут жить и работать, как я понимаю. Соответственно, тебе выдадут как минимум рабочую визу. А прожив по ней энное время, уже не так сложно получить и постоянную - если ты тут уже прожил два года, ни разу не буянил, не попадал в полицию, тебя не ловили с наркотиками и т.п, И имеешь работу, причем не разнорабочего, а компьютерщика...

apxi
24.09.2025 00:04Так до сих пор если нужно набросать небольшую программу которая будет содержать только exe файл выбора то особо и нет, Delphi или Lazarus.

RTFM13
24.09.2025 00:04Если прям совсем простую, то да. Но это как из пушки по воробьям.
Но современный интерфейс проще не будет, чем qt/material. А то может и сложнее выйдет, когда выяснится, что половина (если не все) визуальных компонентов нужный функционал не поддерживают. Плюс паскаль все таки специфичная штука.
По факту удел делфи это больше энтерпрайзный легаси.

HemulGM
24.09.2025 00:04Это вы говорите о старых версиях среды и о базовом Виндовом фреймворке - VCL. Однако, уже давно существует кроссплатформенный GUI фреймворк (FMX), сильно отличающийся от VCL. Которому почти никогда не требуется наличие сторонних компонентов для реализации 90% всех запросов. И речь о современных запросах. Не требуются не только сторонние компоненты, но и даже написание вручную не требуется, потому что используется механизм на подобие HTML+CSS, но в то же время не имеющий ничего общего с вебом.
Ну и про легаси. Легаси проекты не будут работать на современных версиях Делфи. Так что, либо переписываешь проект, либо пишешь на старых версиях. Однако, свежие версии используют в большинстве случаев.

RTFM13
24.09.2025 00:04Коцептуально это тот же qt/material и тут у делфи уже нет такого преимущества, которое было тогда, когда в тренде были статические формы.

HemulGM
24.09.2025 00:04Преимущество есть. Если в qt ты всё так же кодом, используя qss, настраиваешь отображение представления, то в Delphi для настройки представления (не контрола, а его представления) есть отдельный дизайнер.

Дизайнер стилей (не формы) И помимо этого, подход со стилями позволяет иметь в стиле другой контрол. Т.е., если тебе потребуется кнопка в кнопке (как на скрине), то я добавляю в стиль контрол кнопки и тоже задаю ему стиль. После этого, все контролы кнопок (которые используют этот стиль) на форме будут иметь вид кнопки с кнопкой внутри и позволят получать доступ к ней.

alan008
24.09.2025 00:04У нас как раз энтерпрайз на VCL. Под последней версией Delphi, но это всё равно легаси по своей сути, т.к. VCL, Windows messages, Windows Threads (+OmniThreadLibrary, которая опять же прибита к Windows Threads) + JEDI + много всяких визуальных компонентов, для которых, конечно же, ни в каком FMX простых аналогов не найдется.

HemulGM
24.09.2025 00:04Какие, например, аналоги требуются? Мне интересно, что вам не хватает и насколько вы знаете возможности fmx. Потому что fmx самостоятельно в чистом виде покрывает больше половины уникальных сторонних компонентов

alexey_public
24.09.2025 00:04DveloperExpress вряд ли. Они сами кого хочешь покроют и ещё останется :-)

kapojko
24.09.2025 00:04А в чём проблема использовать C/C++, а стандартную библиотеку слинковать статически? Да и Go изначально таким же был, не знаю, как сейчас.
Хотя лично я никогда не понимал, в чём прелесть ограничения себя одним exe-файлом. Ну пусть рядом пара dll лежит, это же не проблема. Вообще, в плане простоты и переносимости, я в последнее время пришёл к python для этих задач. Пара простых действий (venv, pip, python), и всё работает на любой платформе, от сервера до embedded linux.
VGoudkov
24.09.2025 00:04Попробуйте как-нибудь провести "пару простых действий" без интернета. Вот совсем-совсем. И без доступных во внутренней сетке зеркал. Приходите к серверу или даже рабочей станции с воздушным зазором, вставляете flash, и накатываете...

kapojko
24.09.2025 00:04Без интернета, очевидно, это так не заработает. Но я не агитирую за питон на все случаи жизни, я просто поделился своим конкретным опытом, что даже на embedded linux платформах (я не говорю про остальной парк пк и серверов на разных ОС) для меня именно такая конфигурация стала самой простой и универсальной.
Если вам необходимо работать в подобных задачах оффлайн, понимаю, что скомпилированная программа с зависимостями может быть проще. Думаю, есть способ сделать такой трюк и с питоном, но это не лежит на поверхности, я так не делал. Однако, по-прежнему не понимаю, чем пачка dll (если мы говорим про Windows) мешает по сравнению со статически слинкованным exe. У меня был ряд внутренних рабочих программ, которые нужно было так использовать, никаких сложностей не возникало.

zuek
24.09.2025 00:04Соглашусь - в "суровом энтерпрайзе" именно так и бывает - сначала сервер в "учебной" среде настраивается до рабочей конфигурации, потом проводится его аудит (УИБом ли, вендором ли - не суть), и он переезжает в изолированную среду, а если вдруг надо что-то обновить, то привет wsusoffline и прочие хождения с внешним накопителем в ЦОД (хорошо, если на той же территории, где работаешь)... плюс ещё программно-аппаратные ревизоры типа Соболя или иного зверя, которые изрядно недолюбливают любые изменения в "охраняемом периметре"...

Uporoty
24.09.2025 00:04нужно набросать небольшую программу которая будет содержать только exe файл
современный дотнет отлично умеет собираться в один файл и в AOT.

progchip666
24.09.2025 00:04Турбопаскаль как то нме не зашёл, а вот Delphy начиная с середины девяностых я долго юзал!
Очень мне нравилась её объектная модель и революционный по тем временам интерфейс.

skovpen
24.09.2025 00:04В истории dBase->Visual Fox Pro как-то Clipper упущен, был достаточно популярен

Severn Автор
24.09.2025 00:04Ну, я ж писал пост не про базы данных на файлах DBF, а про средства разработки программ с использованием баз данных.
И под базами данных я подразумеваю в основном клиент-серверные СУБД на основе SQL, а не файловые СУБД. Файловые СУБД типа dBase, FoxBase, Clipper, да и Paradox - это ограниченный вариант, где, скажем, принципиально отсутствуют триггеры и хранимые процедуры (за исключением случаев, когда сама среда реализует работу триггеров - как, возможно, делала FoxPro - не знаете, она это умела?), как правило, отсутствует ссылочная целостность (говорят, в Фоксе она была как-то реализована, не знаю, правда ли, но в 1С ее нет до сих пор, хотя 1С был сделан на фоксовском движке CodeBase), и не факт, что есть SQL. Как правило, отсутствуют транзакции.
Большинство моих знакомых разработчиков, работавших на этих системах, вообще не имели понятия о том, что такое транзакции и ссылочная целостность, некоторые путал�� понятия таблицы и базы данных.Поэтому да, о файловых СУБД я упоминаю минимально. Скорее я бы развернул тему сравнения Oracle, MS SQL Server и InterBase/FireBird, там для меня больше интересных вещей.
Ну и потом, я ж не работал на Клиппере или Фоксе, так что ж я о них писать буду? Пусть о них напишут те, кто на них работал. Я сам Фокс только немного потрогал, а писал на Delphi и C#, ну и на SQL, конечно, вот об этом могу рассуждать более-менее адекватно.

Siemargl
24.09.2025 00:04CodeBase не имеет ничего общего с фоксом, кроме поддержки файлов. Другой разработчик, другой код

Severn Автор
24.09.2025 00:04Ну, я слышал, что в Фоксе как раз Codebase использовался. Могу ошибаться, конечно, я не особо этим интересовался.

Siemargl
24.09.2025 00:04У CodeBase очень специфичное именование функций в таблице импорта dll, типа d4open, c4init etc
Вот в 1С она используется
Исходники, кстати, доступны.

VGoudkov
24.09.2025 00:04Borland "профукал" несколько не таким способом. Точнее, на некоторых аспектах в статье не заострено особого внимания. А зря.
Так вот... в одной далёкой галактике одна компания на букву M решила, что всё, что работало до этого на Win32 - это уже как-то несовременно. И сказала буквально следующее - в новых релизах все пользовательские программы будут работать только на .Net. И сама Windows тоже будет на .Net. А кто не успел - повторит судьбу Win16 приложений.
Компания Borland на примерно тот момент имела практически лучшую IDE для быстрой разработки. И звалась она Delphi 7. (Может быть и 6, я уж не упомню). В то же самое время (о чём в статье кстати сказано) Borland решила активно играть в ALM (Application Lifecyle Management) и прочие не-разработческие истории.
И началось шоу. Следующая вышедшая на .Net версия Delрhi была ужасной. Нет, она была настолько кошмарной, что работать на ней было невозможно. Сообщество разработчиков пожало плечами и осталось на Delphi 7. Следующая версия была вроде как получше, но тоже такое себе. Как пример - туда тоже не завезли Unicode. Это можно было решить сторонними компонентами, но по сути требовало полной переработки приложения. В BDE баги были тоннами. Сообщество в очередной раз пожало плечами, но многие уже задумались о том, что делать дальше.
Всё это наложилось на совершенно ушибленную ценовую политику и отсутствие бесплатных Starter версий. Да, серьёзно! Вы не могли вкатится в технологию, не заплатив приличной суммы денег. И получали за них мягко говоря сомнительного качества продукт. Если мне не изменяет склероз, то была даже какая-то программа - обменяй свои свежие лицензии на Delphi на лицензии на Delphi 7 (последняя версия на Win32).
Мир тем временем шёл вперёд, Web интерфейс для внутрикорпоративных приложений потихоньку начал становиться стандартом, появлялись разные интересные технологии и возможности. Что сделала Borland - ничего! Выпустила очередной релиз, который опять толком не работал. Сделай они хотя бы возможность транслировать dfm в Web-страницу (все метаданные и сценарии обработки собственно у них уже были) - и их бы носили на руках. Но нет.
Только в 2006 году появилась RAD Studio, на которой можно было разрабатывать, а не бороться со средой разработки. Но паровоз к этому моменту уже ушёл.
PS: Возможно кто-то вспомнит Sybase PowerBuilder, который в ряде аспектов не уступал, а то и превосходил по своим возможностям. Был куплен и убит SAP...

alan008
24.09.2025 00:04Возможно влияет еще и то, что сейчас всю разработку забрал себе очень крупный энтерпрайз (Яндексы и Гуглы) и они делают либо на самых популярных технологиях (на которые легко находить разрабов), либо просто как им удобно, часто на самодельных внутренних инструментах. Т.е. если бы в каждой фирме требовалось писать свои мини программы и утилиты, может Delphi и был бы вполне жив, т.к. он прост и удобен. Но все сейчас хотят готового, коробочного или облачного от крупных вендоров, а крупные вендоры выбирают технологии исходя из "найдем ли мы быстро 10 тыщ разрабов, умеющих делать это". И одно тянет за собой другое, Delphi теряет комьюнити и популярность. Хотя я бы и C# не назвал супер популярным и все эти 100500 версий .Net фреймворка, которые надо доустанавливать в систему вместо того, чтобы просто был один EXE-шник, который "just works", не добавляет радости в "быстрой разработке .Net приложений". Деплоймент в дотнете отвратительный, имхо. Особенно когда надо приложение раздать на неск тыщ юзеров, у каждого из которых разные версии винды, не всегда есть права устанавливать нужные версии .net , разные версии приложений требуют разных версий .Net и т.д. и т.п. Если на это еще наложить 32/64 битность + зависимости из DLL. Такая каша.

DieSlogan
24.09.2025 00:04Зачем? Во времена XP надо было накатить 4-й NET и выкатывать приложения через ClickOnce. У меня даже враппер был, который позволял получить и установить обновление в удобное мне время прямо во время работы (на терминалах оплаты это было особенно актуально). Вся головная боль по поводу перезаписи приложения в момент его работы, отсутствие админ доступа, всё вот это решалось в ClickOnce.
А разницы 32/64 тоже не ощущалось, если только не требовалось работы с какой-то древней либой 32 бит. Компиляция AnyCPU делала своё дело.

Siemargl
24.09.2025 00:04Ещё была Powersoft/Sybase Optima++
Мне больше нравилась чем Сибилдер, чистый С++ без расширения, без БДЕ

OlegZH
24.09.2025 00:04Ведь, это удивительно. Была бы бесплатная версия с набором базовых компонентов, и с платными наборами специализированных компонентов для коммерческой разработки... Базовых компонентов могло бы хватить на большинство ситуаций. Плюс прозрачная модель разработки ПО и компонентов. Зато была бы широкая распространённость. Можно было бы рискнуть замахнуться на некий индустриальный стандарт.

zuek
24.09.2025 00:04Ну, современный Delphi (RAD Studio) имеет некоммерческую версию (да, с рядом ограничений, которые парой веток назад уже достаточно подробно расписали)... но есть и Lazarus, и прочие "значительно более дешёвые" варианты...

PerroSalchicha
24.09.2025 00:04Ну, современный Delphi (RAD Studio) имеет некоммерческую версию
Проблема в том, что она совсем вообще некоммерческая. На VS Code или там VS 2022 Community вы можете писать софт с какой угодно лицензией. А лицензия некоммерческой Delphi, по сути, разрешает ее использование только если вы вообще не пишете софт за деньги.

zamsisadmin
24.09.2025 00:04Мы изучали Delphi ещё в 2013-14 когда очевидно он был мертв как и сама среда разработки Borland

OlegZH
24.09.2025 00:04А что мешает сейчас взять Delphi и делать приложения на нём? Наверняка сейчас находятся те, кто до сих пор используют Delphi. Что не хватает лично Вам?

IUIUIUIUIUIUIUI
24.09.2025 00:04Что не хватает лично Вам?
Интересных проектов либо хорошо оплачиваемой работы над неинтересными проектами.
То есть, непонятно, зачем брать Delphi, когда есть хаскель для не сильно требовательных к близости к железу проектов, rust — для требовательных, плюсы — для хорошо оплачиваемого легаси, и какой-нибудь идрис с агдой — для души.

VladSynoptic
24.09.2025 00:04Насколько я помню, Turbo Prolog - это не продукт Борланда. Его создал другой датчанин, Лео Шоу-Йенсен, я у него работал

OlegZH
24.09.2025 00:04Можно многое и довольно верно рассуждать о роли личности (в истории), говорить о тактических и стратегических просчётах, вспоминать про конкурентов (кто проспал, а кто бдил и победил). Но я хочу указать на следующие три системных дефекта.
Во-первых, сама по себе идея писать обработчики разного рода событий, вроде бы и хороша, но её постоянное использование иссушает мозги. Когда мы пишем программу в процедурном стиле, то мы излагаем последовательную логику решения той или иной задачи. Написание обработчиков лежит поперёк этой логики. Да, писать обработчики, вроде бы, и можно, но как это делать правильно? В этом смысле, некоторые современные технологии (вроде REST и его реализации в виде библиотеки Fast API), отчасти, возвращают нам процедурный подход. Для того, чтобы написание обработчиков имело смысл, надо было иметь развитую теорию событий, то есть — классификацию этих самых событий и принципы взаимодействия этих событий. Главный вопрос — это вопрос о том, кто отвечает за обработку событий, где и при каких обстоятельствах производится обработка. Глядя из дня сегодняшнего, довольно любопытно представить себе некий вариант реализации в Delphi зависимостей, в том смысле, в котором они понимаются и реализованы, например, в Fast API. Соответственно, это всё могло бы (и, возможно, должно было) стать частью более продвинутой реализации языка Delphi.
Во-вторых, сама по себе идея интегрированной среды разработки — это и не плохая идея, но в чём именно она состояла? Она состояла в том, чтобы иметь некие специальные публичные (опубликованные) свойства, которые работают под непосредственным управлением конфигуратора (инспектор объектов). Здорово! При этом, в самом исходном коде можно было проверить, что сейчас происходит: мы находимся в режиме конфигуратора/дизайнера или приложение выполняется (штатным образом). Кроме того, тип каждого свойства определял редактор для работы с ним в конфигураторе/дизайнере. Беда в том, что мало кто создавал новые редакторы. В то же время, профессиональная разработка на Delphi предполагала создание таких специализированных объектов. Более того, предполагалось создание и мастеров — специализированных процедур для работы со сложными свойствами. Мастер — это последовательность диалоговых окон, прохождение которых приводит к корректному заполнению соответствующего свойства. Ещё одна идея — это модули данных. Понятное дело, если бы это всё грамотно развить, то можно было бы получить крайне эффективную систему разработки, а так Delphi выглядела (да и, по сути, оказалась на самом деле) как большая недоделка с большим, но таки не реализованным потенциалом.
Ещё одна беда Delphi — это основа, то есть — компоненты ОС Windows. Delphi имел бы успех, если бы смог (изначально) предложить некую обобщённую модель разработки, не основанную на системных компонентах. (Эту задачу, кажется, не решила библиотека FireMonkey.) Между тем, наличие такой модели (разумеется, нашедшей отражение в языке программирования) могло бы помочь многократно переиспользовать один и тот же программный код (когда, например, имеется некий "движок", нативным образом реализованный для конкретной операционной системе, или имеется некая среда, вроде CLR.NET). И, потом, если в VCL описывается некоторый компонент, то, сначала, новые свойства этого компонента описываются как защищённые, и уже затем только публикуются (published). Это очень неудобно. Если, например, необходимо реализовать специализированный компонент, который обрабатывает события некоторого визуального или невизуального компонента, то, конечно же, было бы удобнее иметь дело с публичными (public) свойствами. (Впрочем, этот вопрос требует отдельного рассмотрения. Могу этим заняться на досуге.) Ну и, конечно, всегда производит неизгладимое впечатление то, как раздувается программа, когда ты кликаешь на списке столбцов какой-нибудь таблицы, и появляются отдельные объекты для работы с отдельными столбцами. И, вообще, если бы в Delphi можно было бы с лёгкостью клепать собственные DataSet'ы и DataSource'ы (и аналогичные объекты) для работы с различными базами данных, то, опять же, Delphi ждал бы успех.
И, в-третьих, Delphi ждал провал, потому что пришли web-приложения. Возможно, это и есть главная причина заката фирмы Borland. Если бы эра настольных приложений продолжилась, то фирма Borland. могла бы занять доминирующее положение. Но здесь я высказываю уже свою личную току зрения, и она заключается в том, что во многих случаях (если не во всех), настольные приложения лучше, чем web-приложения. Лично мне было бы гораздо удобнее иметь в операционной системе модуль для работы с форумами и, подключаясь к различным форумам, вести переписку, централизовано и единообразно сохраняя её в локальную базу данных (и, при этом никак не завися от вкусов web-дизайнера). Можно было бы даже с легкостью представить множество старых приложений, реализованных на Turbo Vision, которые могли бы продолжать безошибочно работать в современную эпоху. Мало того, что это быстро работало бы, это было бы ещё и более безопасно, так как текстовый режим закрывает множество дыр в безопасности.
А, вообще, было бы интересно посмотреть на альтернативную реальность, где активно развивалась бы Delphi. Как выглядел бы сам язык программирования? Как выглядел бы процесс разработки? Можно было попробовать заглянуть в эту альтернативную реальность. Но для этого потребуется много экспериментировать. Лично мне было бы интересно туда заглянуть...

shark14
24.09.2025 00:04Как сейчас вспоминаю это зловещее "заклинание" в виде ошибки драйвера EGAVGA.BGI, которой непременно сопровождался каждый запуск "синего экрана" Turbo Pascal 7.0. Ну и отсутствие автосохранения тоже, конечно (и то, как преподаватель вбивал юным талантам идею, что нужно нажимать кнопку сохранения после каждой написанной строчки).
Зато как приятно было получить результат в виде компилирующейся, работающей и красиво рисующей очередные фигуры Лиссажу программы!

forever_live
24.09.2025 00:04Странные вещи вы рассказываете. Для работы текстового IDE графический драйвер был не нужен. С автосохранением, вроде, особых проблем не было, но точно не помню. Будет настроение, выкопаю в архивах, посмотрю.

BiTL
24.09.2025 00:04автосохранения в TP 7.0 нет, но и ошибку EGAVGA.BGI он не выдает при запуске. Это у товарища что-то там сломанное видимо было.
Ну и использовать графические библиотеки Паскаля, это такое себе... Они ж там с 87-го года не менялись :) Может для школьных и ПТУшных учителей и ок, у них методички тех же лет.
Rayven2024
24.09.2025 00:04Для тех лет отличная графика была.... Игры тех лет на нём же часто и писали, часто с asm вставками или целиком на асме... Си был сильно сложнее в изучении, да и менее доступен зачастую.

BiTL
24.09.2025 00:04На Паскале писали. Но не с помощью графических библиотек поставляемых с Паскалем, аля Graph.

shark14
24.09.2025 00:04Драйвер был нужен, чтобы запустить графическую (не консольную) программу, думал, что это понятно из контекста про рисование фигур Лиссажу :)
Думаю, что очень многие начинали изучать программирование именно с графики, особенно если речь про школу. А потом уже переходили на написание чисто консольных программ.

BiTL
24.09.2025 00:04Думаю, что очень многие начинали изучать программирование именно с графики
В Турбо Паскале графика начиналась сasm
mov ax, 13h
int 10h
end;
randomsimplenumber
24.09.2025 00:04Uses Crt,Graph;

BiTL
24.09.2025 00:04фу :)

PerroSalchicha
24.09.2025 00:04Ну-ка, нарисуйте мне окружность на экране, после
asm mov ax, 13h int 10h end;:)

BiTL
24.09.2025 00:04uses crt; Var Screen: Array[0..199,0..319] of Byte absolute $a000:$0000; Procedure Circle(x0,y0,r0,c0: Integer); Var x1,y1,r02_r2 : Integer; begin x1:=0; y1:=r0; r02_r2:=r0+r0+1; repeat Screen[y0+y1,x0+x1]:=c0; Screen[y0+y1,x0-x1]:=c0; Screen[y0-y1,x0+x1]:=c0; Screen[y0-y1,x0-x1]:=c0; Screen[y0+x1,x0+y1]:=c0; Screen[y0+x1,x0-y1]:=c0; Screen[y0-x1,x0+y1]:=c0; Screen[y0-x1,x0-y1]:=c0; Dec(r02_r2,x1+x1+1); Inc(x1); if r02_r2<=0 then begin Dec(y1); Inc(r02_r2,y1+y1+1); end; until x1>y1; end; begin asm mov ax, 13h int 10h end; circle(160,100, 40, 15); readkey; end.
В идеале, конечно тоже на ассемблер переписать :)
PerroSalchicha
24.09.2025 00:04Мне кажется, круг у вас не получится, получится нечто с гиперболическими гранями. И к тому же, без учета соотношения сторон дисплея. Поэтому uses Graph + штатная Circle все-таки рулят :)
К тому же они позволяют делать
кроссплатформенныйкроссвидеокартовый код, а у вас дисплей гвоздями прибит на VGA 320x200x256
BiTL
24.09.2025 00:04Вопервых, я ведь запускал этот код, прежде чем ответить.
Во-вторых, поправку на то что в 320х200 пиксели не квадратные - можно добавить. А можно включить режим, в котором будут квадратные пиксели. Вобщем не суть...
Дело в том, что ваш Graph не поддерживает 256-цветный режим (по крайней мере я не видел таких bgi-драйверов), и придется довольствоваться древними 16-цветными режимами, или вообще монохромным :)
Далее, рутины в Grpaph тормозные, и не предполагают работы с анимацией. А также мы не имеем воозможности модифицировать код под себя. В моем случае я могу делать с окружностью что угодно, сделать ее градиентной, добавить заливку, переделать ее под планарный modex-режим.
Не, конечно юзать готовые либы это норм, если нет цели кодить на низком уровне и что-то изобретать. А хочется просто нарисовать окружность :)
Но есть же более продвинутые либы чем штатный graph :)кроссвидеокартовый код
13h режим любой видеокартой поддерживается, даже современными. Игры в DOS под VGA практически все были в 13h-режиме.
И вообще, если уж кодить графон в Паскале, то интереснее и полезнее это было делать на низком уровне. Имхо :)
PerroSalchicha
24.09.2025 00:04Вопервых, я ведь запускал этот код, прежде чем ответить.
У вас есть под рукой настроенный эмулятор DOS с Турбо-Паскалем? О_о Ладно, я тоже попробую.
Дело в том, что ваш Graph не поддерживает 256-цветный режим (по крайней мере я не видел таких bgi-драйверов), и придется довольствоваться древними 16-цветными режимами, или вообще монохромным :)
Обижаете. Есть и vga256.bgi, и vesa.bgi, который умел в режимы SVGA. Они ж потому и драйверы, что предлагали единый интерфейс под разные видеокарты.
Далее, рутины в Grpaph тормозные, и не предполагают работы с анимацией.
Так они вас вообще никак не ограничивают в анимациях и прочих фишках. Это же не виндовый GDI, у вас там прямой доступ к железу открыт. Хотите, используете готовые библиотечные функции, там всякие рамочки рисовать или кнопочки, или шрифты юзать (векторные, кстати). Хотите - свои пишите, они прекрасно будут сосуществовать с библиотечными.
13h режим любой видеокартой поддерживается, даже современными. Игры в DOS под VGA практически все были в 13h-режиме.
Ну это на богатом, VGA во времена Паскаля. Я с CGA начинал :)
UPD: Не, не получается у вас круг:


BiTL
24.09.2025 00:04У вас есть под рукой настроенный эмулятор DOS с Турбо-Паскалем? О_о
Посмотрите мою последнюю статью: https://habr.com/ru/articles/937350/
Вопросы отпадут. Да, я из тех чудиков, у которых не только DOS-эмулятор с ТурбоПаскалем есть, но и 386 и 486-й работающие (и использующийся) компьютеры есть, и да, там тоже ТурбоПаскаль имеется :)Обижаете. Есть и vga256.bgi, и vesa.bgi, который умел в режимы SVGA.
Ну, в штатном дистрибутиве этого точно не было :)
А так-то, для TP было написано масса всего, с поддержкой "из коробки" мышки, gif, jpeg, и т.д.они прекрасно будут сосуществовать с библиотечными.
Не всегда. В моем случае Graph просто лишним будет.

infund
24.09.2025 00:04но и 386 и 486-й работающие
А у меня 8088 работающий (не скажу, что часто используемый, но душу греющий). Пара статей про него тут на Хабре, и даже с примером приложения на TP.

Rayven2024
24.09.2025 00:04Помню какой восторг был в ~1998 от готического шрифта в Паскале и какое разочарование что там не было русских букв.

PerroSalchicha
24.09.2025 00:04Я радиус окружности увеличил, чтобы было лучше заметно. Вот вам для сравнения, белая - по вашему алгоритму, зеленая - circle из модуля graph:

Да, я из тех чудиков, у которых не только DOS-эмулятор с ТурбоПаскалем есть, но и 386 и 486-й работающие (и использующийся) компьютеры есть, и да, там тоже ТурбоПаскаль имеется :)
Мое почтение, коллега!

BiTL
24.09.2025 00:04белая - по вашему алгоритму, зеленая - circle из модуля graph:
Да алгоритм-то не мой, конечно (из фидоэхи). Но он рабочий. И да, я вижу и без зеленой окружности, что у вас он кривую "окружность" рисует. Мне даже любопытно теперь, как это у вас получилось :) Можно скрин программы? Может скопипастили как-то криво? )

Rsa97
24.09.2025 00:04Откройте для себя алгоритм Брезенхэма.
По нему и круг получается круглым, и прямая прямой. И всё в целых числах безо всякой тригонометрии.

IUIUIUIUIUIUIUI
24.09.2025 00:04Круг и с тригонометрией не обязан быть круглым. Например, если это круг в L₁-норме или в L_\inf-норме.

PerroSalchicha
24.09.2025 00:04Может скопипастили как-то криво? )
Действительно, моя вина. Опечатался в одном месте.

BiTL
24.09.2025 00:04ну, вы хотели чтобы получилось "нечто с гиперболическими гранями" оно у вас подсознательно и получилось :)
Зато теперь у вас есть DosBox и Turbo Pascal, только cycles в конфиге ДосБокса советую побольше выставить ( Cycles=60000 это примерно Пентиуму 100Мгц соответствует)

Rayven2024
24.09.2025 00:04Проблема низкого уровня - привязка к железу. Чуть другая видеокарта или монитор и переписывая программу или учитывай всё это при написании...
Но что тупила графика из Graph - помню хорошо.

BiTL
24.09.2025 00:04Да не было проблем с "чуть другой видеокартой" и тем более монитором. У видеокарт были стандарты и обратная совместимость. Если карта поддерживала VGA, значит так, как прописано в стандартах, и обычно также поддерживала CGA/EGA.
К тому же у нас еще есть BIOS, который выступает слоем совместимости.
А уж монитор тут вообще не причем. Чего это вы навыдумывали?

zuek
24.09.2025 00:04Ошибок BGI не помню, а вот эпический "Runtime error 200 - devision by zero" после апгрейда до Pentium врезался глубоко в память... и после недолгого дебага в спираченной IDA, я научился его патчить, заменяя, в не менее легально используемом, чем IDA, Hiew несколько байт (то ли div, то ли loop) на nop...

shuhray
24.09.2025 00:04Знакомый программист Влад Патрышев (1952-го года рождения) там работал и говорит, там была идея, что понимать сложный код не обязательно, а надо правильно тестировать. К новому коду писали много тестов. Как работает старый код, никто не знал, при попытке что-то в нём изменить все тесты рушились.

BiTL
24.09.2025 00:04А кто видел такую "делфи"? :)


PerroSalchicha
24.09.2025 00:04Это еще ладно. Вот кто видел бетку первого С++ Билдера? :)

BiTL
24.09.2025 00:04Ebony?

PerroSalchicha
24.09.2025 00:04Да, она самая. У меня была первая реакция, что какой-то неудачный шутник в отделе решил над ярлыком Билдера поиздеваться. Потом увидел, что бетку так зовут. Эбеновое дерево, видите ли.

artemt
24.09.2025 00:04Никогда не программировал на Pascal, в школе мы программы Basic на листочках сдавали а учитель их интерпретировал. Устроившись три года назад программистом C# в Газпромбанк, получил задание перенести функционал из одной системы в другую, разобравшись с бизнес-логикой по коду. Код оказался на Pascal. Ну что сказать, нормальный этот ваш Pascal, только устарел немного.

HemulGM
24.09.2025 00:04Тот, с которого вы переписывали устарел. Современные далеко не уступает С#.
Крохотные примеры


OlegZH
24.09.2025 00:04Это же всё — вопрос синтаксиса. Разве это не похоже на Go, C# и Rust?

HemulGM
24.09.2025 00:04Ну так вопрос как раз в это. Чем именно устарел "Паскаль"?
В нем (языке Делфи) сейчас имеются почти все современные конструкции и приемы: анонимные функции, инлайн переменные, выведение типов, дженерики, масштабная рефлексия (атрибуты и прочее), инлайн оптимизация методов, конкатенация массивов, хелперы, перегрузка операторов и многое другое

artemt
24.09.2025 00:04Убедили и слегка удивили, Pascal не устарел. Я думал, он застыл в своём развитии. Тогда почему Pascal не составляет сильной конкуренции C#, Java, Go etc.? Старые проекты не в счёт. В чём причина: слабый инструментарий, отсутствие финансовой поддержки крупной корпорации, ограниченность применения, отсутствие киллерфичи, недостатки языка всё-таки, ...?

HemulGM
24.09.2025 00:04Прошу прощения, я не специально нажал "минус". Промахнулся с телефона. Не обращайте на него внимания.
Проблем скорее всего несколько:
Инструмент платный для коммерческой разработки (хоть и плата единоразовая)
Инструмент не опенсорс, в том числе компилятор. Это может мешать развитию или политике конкретного клиента.
Среда разработки не кроссплатформенная и работает, пока, только под Windows.
Я думаю, это основные проблемы. В остальном инструмент не сильно уступает современным решениям, а во многом превосходит.

sdramare
24.09.2025 00:04Pascal не составляет сильной конкуренции C#, Java, Go etc.
Потому что дело не в языке, а в том, что стоит за ним. C# продвигается майкрософтом - конференции, реклама, поддержка для всех продуктов. За Java стоят миллионы существующих энтерпрайз приложений и их команды. И когда такая команда стартует новый проект, то естественно выбирает опять джаву. Что касается Го, то он много лет точно так же был не особо популярен, пока не выяснилось что он очень хорошо подходит для быстрой разработки микросервисов/девопса и на него стали переходить в первую очередь со всях node.js решений. Плюс Го удобен тем, что вокруг него можно собирать команда разработчиков с разных стэков - примитивный синтакст могут быстро освоилить хоть джависты, хоть плюсовики.

OlegZH
24.09.2025 00:04В нем (языке Делфи) сейчас имеются почти все современные конструкции и приемы...
Вот я и спрашиваю, что мешает использовать Delphi сегодня?

HemulGM
24.09.2025 00:04Скорее всего, мешает незнание текущего положения дел. Мало рекламы и новостных постов. И мешает устоявшееся в ИТ сообществе, хоть и не совсем верное, мнение о Delphi и Pascal.
Спроси любого, кто "не любит" Делфи о том, что в нем изменилось за последнее время - никто из них тебе не ответит. Однажды они решили или где-то прочитали, что Делфи - плохо и всё на этом.

PerroSalchicha
24.09.2025 00:04Скорее всего, мешает незнание текущего положения дел.
Мешает, скорее, отсутствие этих самых киллер-фич при наличии некоторых недостатков. Вот если у вас есть существующий проект на Delphi, вы его и будете развивать, причин бросать его в общем-то и нет. А надо ли начинать на ней новый проект? Минусы-то очевидны:
Она стоит денег для коммерческой разработки, в то же время конкуренты бесплатные или доступны по копеечной подписке.
Специалистов по ней на рынке мало. Джуны ее учить не хотят, опытных разработчиков зарплаты по Delphi не особо привлекают, т.е. у вас частенько будет кадровый голод
В общем-то эти два недостатка не так чтобы и критичны, и могли бы быть перевешены какой-то киллер-фичей, ну так нет же ее, этой киллер-фичи.

randomsimplenumber
24.09.2025 00:04А что за киллер фича у него? В нем есть то же что у плюсов? Ок, зачем нам еще одни плюсы, но с begin..end ?

HemulGM
24.09.2025 00:04Он более удобен для написания, чем плюсы.
Он более безопасен, потому что использование указателей в нём или выделение памяти вручную - редкий случай и во многих проектах вообще не используется.
Помимо самого языка, вся экосистема более продумана изначально и более проста в освоении. В штатной поставке очень большая библиотека: от хелперов для даты и времени, строк, чисел и т.д. до методов шифрования, хеширования, кодировки и т.п. В штатной поставке есть даже библиотека для работы с любыми S3-compatibility хранилищами и библиотека для клиент-серверной трансляции.
Другими словами, преимущества не столько в самом языке, сколько в библиотеке готовых решений

randomsimplenumber
24.09.2025 00:04Он более безопасен, потому что использование указателей в нём или выделение памяти вручную - редкий случай и во многих проектах вообще не используется.
Так и на полюсах так делать не принято. Разве что кто-то пишет на плюсах код на Си.
В штатной поставке очень большая библиотека
boost напоминает ;)

HemulGM
24.09.2025 00:04Да, напоминает, но в Delphi это по сути часть языка. Вдобавок ко всему имеются два штатных фреймворка: виндовый VCL и кроссплатформенный FMX. Всё это тесно связано и работать со всем этим гораздо удобнее.
Работа с JSON, BSON, XML, сериализация/десериализация, работа с HTTP, REST, FTP, SMTP. Всё это есть из коробки и не нужно бороться с зоопарком библиотек и их версий.

holgw
24.09.2025 00:04В штатной поставке очень большая библиотека: от хелперов для даты и времени, строк, чисел и т.д. до методов шифрования, хеширования, кодировки и т.п. В штатной поставке есть даже библиотека для работы с любыми S3-compatibility хранилищами и библиотека для клиент-серверной трансляции.
Так и в любом зрелом языке все это есть, в чем преимущество-то?
Всё это есть из коробки и не нужно бороться с зоопарком библиотек и их версий.
Да нет никакой борьбы в том что��ы нужные библиотеки подтянуть пакетным менеджером. Ну и в .NET и Java, например, большая часть тоже из коробки есть и не надо даже в пакетный менеджер лазить.

OlegZH
24.09.2025 00:04В нем есть то же что у плюсов?
C++ Builder — это прямой наследник Delphi.
А то, что касается языка... Сейчас многие языки примерно одинаковы. Ну, там, особенности синтаксиса. В любом языке программирования можно реализовать одно и то же. Язык программирования никогда не предлагается сам по себе, а вместе со средой разработки и с технологией разработки приложений.
Главное, что нужно знать, что Delphi — это компилируемый язык. Лично мне я в алголоподобных языках импонирует возможность явного описания ряда концепций. Например:
file of record begin /// endДа, в Python есть итераторы и явное (на уровне языка) поддержка изобразительных средств. Но это всё требует развития: новые элементы языка, подходящие изобразительные средства, прямая поддержка всяких там MVC и т.д. и т.п.
Не стоит искать какие-то "киллер-фичи". Был бы программист, а язык найдётся. ;-)

HemulGM
24.09.2025 00:04В Делфи тоже есть итераторы и конструкции типа:
for var Item in List do writeln(Item.Text);я давно использую
В том числе есть и генераторы

HemulGM
24.09.2025 00:04Или вот ещё примеры подражания питону
Скрытый текст
procedure Fun3; begin { >>> a = ['Mary', 'had', 'a', 'little', 'lamb'] >>> for i in range(len(a)): ... print(i, a[i]) } var a := ['Mary', 'had', 'a', 'little', 'lamb']; for var i in range(len(a)) do Writeln(i, ' ', a[i]); end;procedure Fun10; function isPrime(n: integer): Byte; begin for var i := 2 to n div 2 do if n mod i = 0 then Exit(0); Result := 1; end; begin var numPrimes := 0; for var i in Range(2, 250001) do Inc(numPrimes, isPrime(i)); writeln(numPrimes); end;procedure Fun6; begin { >>> def make_incrementor(n): ... return lambda x: x + n ... >>> f = make_incrementor(42) >>> f(0) 42 >>> f(1) 43 } var make_incrementor := function(n: int): TFunc<int, int> begin Result := function(x: int): int begin Result := x + n end; end; var f := make_incrementor(42); writeln(f(0)); writeln(f(1)); end;procedure Fun1; begin for var Ch in Range(1, 10, 0.501) do WriteLn(Ch); end; procedure Fun2; begin for var N in (function(AFrom, ATo: int): TArray<int> begin SetLength(Result, ATo - AFrom + 1); for var i := AFrom to ATo do Result[i - AFrom] := Random(10); end)(1, 10) do WriteLn(N); end;

PerroSalchicha
24.09.2025 00:04А что за киллер фича у него? В нем есть то же что у плюсов?
Delphi, это чутка другая квалификация разработчика, это не аналог плюсов, это аналог сишарпа, но под полностью нативную сборку. Главное преимущество Delphi над плюсами - в нем нет темплейтов/макросов, и соответственно, сам язык спасает мозг программиста от попыток уйти в метапрограммирование :)

Siemargl
24.09.2025 00:04отсутствие возможностей не является преимуществом.
это все равно что говорить, что одноногий зато не убьется на бегу

PerroSalchicha
24.09.2025 00:04отсутствие возможностей не является преимуществом.
это все равно что говорить, что одноногий зато не убьется на бегу
Отсутствие возможностей делать плохо называется "безопасность" или "надежность". А безопасность и надежность - это хорошо. Да, автомобиль с системой экстренной остановки ограничит вас в возможности раздавить пешехода или усложнит вам задачу разбиться об мост. Но разве это не преимущество? Так же и с метапрограммированием. Да, оно популярно среди разработчиков на С++, у него масса своих фанатов, и в какой-то мере это неплохая тренировка для ума. Но написанный таким образом код чаще всего тяжелый и в отладке, и в сопровождении. Это банально делает развитие проекта медленным и дорогим.

Siemargl
24.09.2025 00:04макросы и шаблоны на безопасность влияют мало, особенно шаблоны - там такой же контроль типов

PerroSalchicha
24.09.2025 00:04Проблема шаблонов в том, что они как goto, генерируют спагетти-код. Например, я когда-то писал расширения для РНР, сейчас оно там на С написано, достаточно чистый и понятный код. Четвертая версия пыхи была написана на С++. Написана она была профессиональными чуваками, но макросы там имели, по-моему, семиуровневую вложенность. Очевидно, тот, кто их писал, в них разбирался, но другим разбираться в этом была боль и страдания. Мне, например, надо было в движок добавить поддержку глобального пула коннектов к базе данных. Там пул был, но работал в рамках одной сессии, а мне надо было поддерживать общий пул для всех приложений и сессий всего веб-сервера. И я на разбор этих макросов потратил в разы больше времени, чем собственно на реализацию. Полагаю, я такой был не один, если в последующих версиях пыху переписали вообще полностью, и на языке без макросов :)
И это только один пример, который первым пришел в голову. А так, их стопицот было. Проще вспомнить проекты, где макросы/шаблоны не вредили сопровождению кода, чем те, где вредили. И я даже могу сказать: шаблоны дают чистый профит там, где надо сделать общий враппер для разных типов данных. Но в Delphi для этого есть дженерики, которые имеют даже синтаксис похожий.

Siemargl
24.09.2025 00:04то что ты путаешь шаблоны с макросами, говорит не о вреде шаблонов, а только о твоей квалификации

PerroSalchicha
24.09.2025 00:04Не "ты", а "вы", и не путаю, а обобщаю. В С++ макросы и шаблоны - всего лишь разновидности кодогенератора.

IUIUIUIUIUIUIUI
24.09.2025 00:04Да и сам C++ — разновидность кодогенератора, ведь по нему же ассемблерный код генерируется. Следовательно, C++ — это как макросы. Да и Delphi, в принципе, тоже.

Siemargl
24.09.2025 00:04про отсутствие возможностей ради безопасности это к фанатам раста - там тоже надо программировать одной рукой, потому что две ссылки одновременно запрещены

IUIUIUIUIUIUIUI
24.09.2025 00:04Лучше всего для программирования — это, конечно, джаваскрипт, не так ли? Никаких тебе ограничений и контроля со стороны глупого тайпчекера!

HemulGM
24.09.2025 00:04Тогда отсутствие дизайнера в декларативных гуи - это минус, потому что в Делфи можно легко писать декларативно, а вот во многих других нет дизайнеров

OlegZH
24.09.2025 00:04В нем есть то же что у плюсов?
Знаете. У Pascal'я есть одна важная особенность: модульность. Вы оформляете модуль, у которого есть раздел объявлений (interface) и раздел реализации (implementation). Трудно назвать это "киллер-фичей", но вещь очень важная. В C/C++ очень много возни с заголовочными файлами. В этом смысле, Pascal'е есть большая концептуальная чистота, выражаемая набором ключевых слов. Никто не мешает реализовать и в C/C++ аналогичные подходы, но тогда потребуются дополнительные языковые средства. Что там написано в новейших стандартах, мне не известно. Не просветите?

DieSlogan
24.09.2025 00:04Как по мне, чем-то схож в своей многословности с Basic.
В своё время, учась в школе игрался с VB, а потом когда начал изучать C, то уже сложно было в институте писать лаболаторки на Delphi. Делал их на MSVC++ с использованием MFC. Учителя не знали как запустить, но технически это был ООП. Я даже экзамен по ООП сдал, написав всё на C++. Правда, написал я от балды, но преподы этого не знали и ставили "отл." в зачё��ке.

varton86
24.09.2025 00:04У Microsoft такое тоже было. В флагманских продуктах того момента — Visual Basic и Visual Fox Pro. С существенными отличиями, а именно — элементы управления, используемые Basic и Fox, надо было разрабатывать отдельно, на С, по технологии COM, что требовало особых знаний и навыков.
Про Visual FoxPro и Basic уточню: не нужно было писать элементы управления на C, у них были свои встроенные элементы управления, которых было вполне достаточно. COM в основном использовался для соединения с другими источниками данных (Excel, etc).

Siemargl
24.09.2025 00:04COM в основном использовался для соединения с другими источниками данных (Excel, etc).
очевидно, это недостаток встроенных возможностей

Severn Автор
24.09.2025 00:04Что значит "не надо писать"? Вы хотели сказать, что они уже есть, и поэтому их не надо писать?
Ну, так тогда и во всех других средах их так же "не надо писать".Речь-то шла о том, чтоб при желании написать свой компонент, такой как тебе надо. Или, может быть, чуток доработать существующий.
И вот тут и вылезает разница: в Delphi это сделать довольно легко. А в Visual Basic и Visual Fox Pro это не сделать. Нужно использовать другой язык, и на нем делать, и не так оно просто.
На C#, кстати, с компонентами еще проще чем в Delphi. Может быть поэтому для него компонентов просто безумное количество.
varton86
24.09.2025 00:04Я сказал то, что сказал. У вас написано, что "элементы управления, используемые Basic и Fox, надо было разрабатывать отдельно" Я уточнил, что у них уже были свои стандартные компоненты (окна, кнопки, переключатели, поля ввода и т.д.) Их вполне хватало для всего, если учесть, что фокс в основном использовался для офисных задач. Хотя, как только вышел VFoxPro 3.0, я начало преферанса на нем даже написал (раздачу карт).

woof_woof
24.09.2025 00:04>Object Vision, 1992
Что-то мне все же кажется Object Windows Library (OWL) и в 1991, как ответ MS создал MFC





sgenie
А еще Jensen уходит и уводит с собой топ разработчиков и открывают свою фирму JPI -Jensen and Partners International - делают JPI Модула и C++, обалденно элегантные компайлеры
Feedman
Угу. Причем как раз в тот момент, когда были сделаны компиляторы для С (то, что мы знаем как Турбо-це было у кого-то куплено, что во многом и послужило причиной развода Кана и Йенсена), Модула и Ада. Глянул - сайт с Clarion еще работает, не знаю, жив ли сам продукт и сколько в нем осталось от компиляторов TopSpeed.
vvmtutby
И продукт жив, и компиляторы от JPI/TopSpeed.
Clarion IDE позволяет редактировать и компилировать на различных языках программирования, доступных в пакете Softvelocity Clarion (а именно собственно Clarion, C++/C, TopSpeed Modula-2 и Assembler):
ClarionMultiLanguage project
Проект протестирован в Clarion 10.0.12799 и Clarion 11.0.13244 (Windows), но может быть открыт и в предыдущих версиях. Есть дополнительный файл проекта, созданный в Clarion 5, и подпроект, адаптированный для CDD 3 (DOS).
Sollex
Clarion ещё живой о_0
Nikollor48
Вставлю ремарку, JPI не только компиляторы, но и культура инженерии. Документация и примеры были на голову выше среднего по рынку
dimas
TopSpeed были шикарные компиляторы и особенно документация.
Одна беда, когда их купил Кларион под себя, они забили/закрыли их как отдельный продукт ...