Comments 646
А еще Jensen уходит и уводит с собой топ разработчиков и открывают свою фирму JPI -Jensen and Partners International - делают JPI Модула и C++, обалденно элегантные компайлеры
Угу. Причем как раз в тот момент, когда были сделаны компиляторы для С (то, что мы знаем как Турбо-це было у кого-то куплено, что во многом и послужило причиной развода Кана и Йенсена), Модула и Ада. Глянул - сайт с Clarion еще работает, не знаю, жив ли сам продукт и сколько в нем осталось от компиляторов TopSpeed.
Clarion - жив ли сам продукт и сколько в нем осталось от компиляторов TopSpeed ?
И продукт жив, и компиляторы от 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).
Вставлю ремарку, JPI не только компиляторы, но и культура инженерии. Документация и примеры были на голову выше среднего по рынку
TopSpeed были шикарные компиляторы и особенно документация.
Одна беда, когда их купил Кларион под себя, они забили/закрыли их как отдельный продукт ...
Неплохая ретроспектива. Поймал немного вьетнамских флешбеков.
Использовал и Turbo Basic 1.0 и Turbo Pascal 5,6,7, и Turbo Assembler, и Delphi (начиная с win 3.1).
В плане работы с БД всегда бесило, что BDE надо устанавливать отдельно, а мне всегда хотелось чтобы программа была самодостаточная :) А потом еще этот FireBird, который в таскбаре висел...
Когда-то было такое решение, чтоб внедрить BDE-шные драйверы в программу. Но уже не вспомню, как это делалось.
Но вообще, BDE был не без глюков, я его как-то правил (были исходники), там иногда случались взаимоблокировки сессий, а у меня было трехслойное приложение... Потом вместо BDE стал использовать FIBPlus, и блокировки с зависаниями пропали.
Когда-то было такое решение, чтоб внедрить BDE-шные драйверы в программу.
через installshield делалось, была даже урезанная бесплатная express версия (или в комплекте энтерпрайз редакции шла)
От BDE избавлялся, как только находил компоненты для работы конкретно с моими базами. Для Оракла была отличная библиотека DOA (Direct Oracle Access), для работы с DBase файлами тоже нашел какие-то компоненты. Встроенный набор для построения отчетов, кажется QReport, был даже не борландовской разработки, они у сторонней конторы их приобрели "чтобы было". Помню, была у меня в отчете двойная группировка (группа внутри группы) и, когда внутренняя группа заканчивалась в конце страницы, итоги по внешней группе не печатались на новой странице. Просто выпадала строка итогов. Сколько я бился, полагая, что у меня в приложении какая-то ошибка, сколько пытался подстроиться, чтобы итоги по группе не совпадали с концом страницы... В итоге, когда интернет слегка подразвился, выяснил, что это хорошо известный баг библиотеки, на который производителю плевать. "Используйте другой генератор отчетов". Что я и сделал.
Эх, были времена...
Это, кажется, был урезанный QuickReport.
В то время появился бесплатный Fast reports, который на голову был выше, им пользовались очень долго
И был очень классно сделан!
И, кстати, в версии под .Net сделан так же хорошо.
И по сей день жив, как под Delphi, так и под C#.
Он, по-моему, никогда не был бесплатным, там была триалка без исходников, которая печатала до пяти страниц и с сообщением о триале, или что-то в этом роде. Но лицензия была недорогая.
Возможно, может мы его и купили сразу, это в 96 или 97 году было, все на этих отчётах в банке строилось
Насколько я помню, печатал он все. Но с водяными знаками "Пробная версия" или что-то типа того. В платной версии эти отметки исчезали.
Т.е. можно было нормально отладить программу, даже обкатать на пользователях, и лишь потом купить FR.
взаимоблокировки
Сергей Дмитриевич Кузнецов (1949-2023), две недели по модему качавший в Россию стандарт SQL 1995, ненавидел это слово)) Транзанкции не могут друг друга блокировать, они друг про друга не знают!
Синхронизационный тупик))
Кстати, и слово deadlock не содержит указания ни на какое "взаимо-".
Ну, строго говоря, блокируют друг друга не транзакции, а сессии, в которых делаются блокировки. Так что Сергей Дмитриевич прав, и я с ним не спорю. )
А если лезть в механизмы - то в сессиях производится обращение к критической секции, и взаимоблокировка случается когда два потока блокируют по критической секции и пытаются заблокировать вторую, блокированную другим потоком.
Ох и геморрой был разматывать эти блокировки в BDE в сервере приложений!
А еще где то в те времена была библиотека KOL & MCK от Владимира Кладова, которая вместо гигантских (на то время) приложений умудрялась компилятся в очень компактный размер
Вроде, достаточно было BDE библиотеки закинуть в папку с программой.
я занудный, не могу не заметить, что "в таскбаре" висел не Firebird, а InterBase. В Дельфи входил только InterBase. Firebird - никогда.
FireBird в Delphi не входил, вы правы. Но в таскбаре он прекрасно висит, вот смотрите
Я, как, наверное и большинство, предпочту использовать именно бесплатный FB, а не глючный IB.
FireBird живее всех живых, сейчас 5.0 и 6.0 не за горами, заимел платный "клон" в лице RedDatabase. В таскбаре не висит, ресурсы не жрёт. Наибольшее распространен в Бразилии, на втором месте Россия. Часть разрабов наша, часть из них же это разрабы RedDatabase.
Я помню еще питерский клон Yaffil, потом слившийся с командой FireBird, если не ошибаюсь. Там они научились комбинировать индексы и очень быстро искать, скажем, при условиях по полям Name и INN и при индексах по каждому из этих полей, но без индекса по ним обоим. Поиск прям очень быстро стал работать.
Ну, там еще много хорошего было, уже и не вспомню точно, почти 20 лет прошло...
А чего бы не жить, прекрасный сервер баз данных а главное очень быстро работает и не требователен к ресурсам.
Когда начинаю хоронить Delphi всегда прикладываю свежий TIOBE, несмотря того что много растерял пользователей в былые времена, язык популярен, даже сейчас есть много преимуществ.
Тут вроде бы хоронят (точнее поминают, ибо уже давно померла) компанию Borland, а не Delphi.
В 2009 году поглощена британской компанией Micro Focus. Годом ранее активы, связанные со средствами разработки и выделенные в предприятие CodeGear, проданы компании Embarcadero.
Кстати, Micro Focus поглотила Novell NetWare, интересно было бы почитать такую же статью как NetWare "профукали".
В 2022 году Micro Focus была куплена компанией OpenText, что означает, что активы Novell теперь находятся под контролем OpenText.
Забавно, что почти нигде в истории перехода Борланда в Идеру не упоминается ещё одно промежуточное звено, Inprise. При том, что четвёртая версия делфи, емнип, имела в своём названии именно это имя, а не борланд.
Выглядит как будто бы борланд много раз перекидывался из рук в руки, как горячая картошка. И только эмбаркадера сумела его удержать.
Забавно, что почти нигде в истории перехода Борланда в Идеру не упоминается ещё одно промежуточное звено, Inprise.
Это не промежуточное звено, это была та же Borland, но с новым брендом, который, как предполагалось, подчеркивал тогда их смену вектора с массовых инструментов разработки на дорогие корпоративные тулзы (что их и погубило). Integrate the Enterprise.
Я счел эту подробность неважной, хотя она хорошо укладывается в общую канву беспорядочных метаний.
А насчет Ембаркадеро - тут чуть другое. Сами остатки Борланда, действительно, уже не имели сил, чтоб что-то удержать. А Ембаркадеро - старая фирма, которая, по всей вероятности, не собиралась впадать ни в какие кризисы, и просто выкупила по дешевке команду Delphi, как старый лендровер у колхозника-раздолбая, чтоб отремонтировать в своем гараже и пользоваться.
и просто выкупила по дешевке команду Delphi, как старый лендровер у колхозника-раздолбая, чтоб отремонтировать в своем гараже и пользоваться.
Выкупила в 2008, ремонтировать начала с 2014, результат появился ближе к 2021...
Пока ремонтировали, колхозники разбежались по другим колхозам.
Я могу сказать, что CodeGear Delphi 2007, т.е. спустя две или три пропащие версии, был неплохим и современным. Они сами проделали уже тогда большую работу над ошибками, IDE там стала стабильной, современной и функциональной. Но время было упущено. И опять же таки, не было бесплатных версий.
Delphi не был современным языком с момента появления С++ (т.е. никогда). Он всегда отставал по функциям от C++, Java, C#, Python и прочих популярных языков. Фичи языка реализовывались даже медленее, чем в Java! К ~2021 году его допилили почти до современного уровня (а ещё подключили LSP - вот тогда IDE стала стабильной!), а дальше я не в курсе, хотя версии выходят регулярно.
В чём плюсы, благодаря которым Delphi получил популярность: прогрессивный для своего времени редактор форм для RAD; ООП, которое сделало возможным написание огромных серьёзных программ.
Delphi не был современным языком с момента появления С++ (т.е. никогда).
Неправда ваша. В Delphi тогда недоставало дженериков, и это был его единственный недостаток как языка в 2007-м году. Так, по количеству синтаксического сахара был плюс-минус паритет. В шарпе локальные функции появились в конце 2010-х, а анонимные функции в том же 2007-м, в дельфи локальные функции были от рождения, а анонимные появились в 2009-м вместе с дженериками.
прогрессивный для своего времени редактор форм для RAD
Я бы сказал, и сейчас прогрессивный :)
Действительно, отдельные фичи выпускались раньше, чем в некоторых других языках, однако суммарно язык+инструменты+библиотеки были весьма убогие, глючные, избыточные, с кучей легаси (хотя отдельные вещи замечательны, например DevExpress). Я могу долго описывать эти проблемы, хотя что-то уже подзабыл. В промышленном применении приходилось делать dll'ки c кусками кода из стандартной библиотеки С++, например, потому что "обычной" функциональности в библиотеках на Delphi не было вообще, типа стабильной или частичной сортировки. А ещё местами gcc выдавал в 10 раз более быстрый код, чем компилятор сего языка.
Я бы сказал, и сейчас прогрессивный :)
Для каких-то примитивных форм - возможно... Для работы с layout engine приходилось каждый раз обходить кучу глюков этого инструмента. Без layout engine кнопки создавали собой странный облик при изменении размера окна, особенно когда появились hidpi мониторы. Мне даже казалось, что набить создание окошек в коде таки быстрее, чем искать нужные свойства в этом редакторе (ну, если бы автодополнение не глючило). Гибкость по сравнению с HTML+CSS - никуда не годится.
Видимо данный чарт не отражает действительности: вы верите в то, что уровень дельфи вырос на 25 процентов за год? )) даже если это 0.5 процента от 2 процентов, вы верите в то, что он вообще вырос?
Вот в то, что перл и делфи где-то рядом, я верю.
судя по тому количеству вирусни которая в последнее время стала появляться на delphi - табличка кажется правдивой.
Меня больше смутило, что "популярность" SQL уровнем ниже, чем Delphi и Perl. Ну или JS на уровне VB -- тоже звучит сомнительно.
Ну, на SQL не так много пишут. С тех пор, как появились хорошие средства разработки программ с БД, бизнес-логику удобнее писать на других языках.
Я вот вообще даже SQL-запросы по большей части программно генерировал, а не писал руками.
А потом сгенерированный программно запрос начинает тормозить и никто не знает, что с этим делать...
С чего бы это вдруг? Если программист не может починить SQL-запрос, то что он тут делает? И как он его генератор написал?
Что-то вы себе напридумывали свое, нам такого не надо.
А почему вы думаете, что он сам писал его генератор? Он взял какой-нибудь готовый ORM, чтобы не изобретать велосипед.
Юрий, ну про себя-то я точно знаю, что написал генерацию запросов сам )
Или вы имели в виду ситуацию, когда моим модулем пользуется другой программист, и не может разобраться в сгенерированном запросе?
Ну, тут два варианта:
1. Это опытный программист, он разберется.
2. Это младший программист, он разобраться не может. Тогда ему придется обратиться ко мне или к другим старшим товарищам.
Я беру именно ту ситуацию, которую описал - генератор запросов создан в той команде, которая пишет программу.
Если рассматривать ситуацию, когда генератор запросов продается и используется какой-то другой командой - тут да, тут может потребоваться техподдержка от команды-разработчика.
Скажем, последние годы я пользуюсь ORM DataObjects.Net фирмы Xtensive, и иногда приходится обращаться к ним за помощью.
(Впрочем, со скоростью выполнения запросов вопросов не было.)
Если бы у них не было техподдержки - возможно, мы бы использовали другую ORM, скажем, ту же Entity Framework.
На TIOBE нельзя ориентироваться. Он просто считает сколько ссылок выходит по поисковому запросу в поисковике. То есть любой язык по которому много писали в прошлом будет в топе. Это, разумеется, открывает дорогу к манипуляциям (поклонники Перла, например, не так давно воспользовались этим, начав много спамить словом Perl).
О, как раз такую табличку видел на прошлой неделе на Pascal Conference 2025. Ian Barker ее презентовал насколько я помню. Он много и красноречиво рассказывал, что на дельфи написано много софта например для аэропортов. И даже новые проекты на нем начинают.
А закончил он свой спич словами "Is Delphi dead? No!!!"
Если верить ему, то не все так и плохо и хоронить, как обычно, рановато. =) Работа продолжается + есть еще FreePascal - там судя по сообщениям в телеграмме тоже активная работа идет.
А как считается TIOBE? Что он отражает?
Я бы больше смотрел на количество вакансий, зарплаты по ним, соотношение зарплаты/резюме, количество написанных на нем в наше время успешных проектов (тут конечно сложнее с непубличным корпоративным софтом), количество доступных библиотек и пакетов в пакетном менеджере.
Со стороны руководителя еще и на количество резюме и доступных на рынке специалистов.
Ну тиобе это такой рейтинг, который составляют наиоснове количества гугл запросов. Такой себе рейтинг. Перл чуть ли не на уровне Го подлетел в этом году, хотя по факту конечно его ИСПОЛЬЗОВАНИЕ не увеличилось
1982 В Borland приходит Андерс Хейлсберг (Anders Hejlsberg), разработчик Blue Label Pascal.
Насколько я понимаю, почему именно Паскаль - это тоже не случайность, т.е. Филипп Кан был студентом у Никлауса Вирта.
В конце двухтысячных годов остатки компании Borland были проданы компании Embarcadero, которая и сейчас продолжает продавать продукт Delphi.
Ага, я как-то попытался попробовать ее бесплатную версию. Пока вбивал свои данные для регистрации и получал лицензию (на год,блин) - уже и пробовать расхотелось. Так даже и не запустил скачанную программу. По-моему, в девяностые оригинальный крякнутый Борланд было быстрее найти и поставить.
О, вспомнили, славатруду.
Запускаем транслятор (сейчас говорят компилятор)
Нет. Так сейчас не говорят. И никогда не говорили. Ибо транслятор — общее понятие: программа, которая переводит код с одного языка на другой.
Компилятор — частный случай транслятора. Интерпретатор — тоже частный случай транслятора. Есть ещё...
уже существовавший к тому времени Бейсик можно считать воплощением этой идеи
Бейсик — это язык. Он не накладывает ограничений на среду разработки. Есть и IDE для Бейсика, и CLI. Есть интерпретаторы, есть и компиляторы с Бейсика.
Спасибо за уточнения. В общем, вы правы, но, полагаю, это не настолько существенно, чтоб вносить правки в статью?
Кмк - было бы неплохо в качестве демонстрации автором понимания сути применяемых терминов. Интерпретатор, как очевидно, будучи разновидностью транслятора - не создаёт объектных файлов, к примеру. И интерпретаторы языка Бейсик - не были IDE в нормальном понимании этого слова. Они могли "работать" в качестве интерпретатора командного языка - собственно, в "домашних" 8-битных компьютерах они частенько так и работали.
P.S. У Борланда - были ещё проблемы с неймингом продуктов, был Turbo C, Turbo C++, Borland C++, причём номера версий первых двух - частично перекрывались, хотя сами они были разными продуктами. Turbo C++ потом продолжал выпускаться "для энтузиастов" некоторое время дальше.
Для Бейсика Майкрософт делал и компиляторы, и IDE, притом версия с полноценным редактором вышла даже раньше, чем у Borland.
Microsoft QuickBasic 2.0 (1986)
Borland Turbo Pascal 4.0 (1987)
Да MS QBasic был интерпретатором (с версии 4.0, встроенной в редактор, до существовал компилятор), а Borland Turbo Basic - компилятором. А на MS Visual basic вполне можно получить заветный EXE. Я кстати ещё видел его подобие для DOS, нашел как то файлик такого VB когда ходил в кружок программирования, и был удивлен, под дос формочки и можно мышкой компоненты перетаскивать.
Однако как правило все-же Basic был интерпретатором, и да, часто применялся во многих домашних компьютерах. В клонах спектрума, в компах на базе КР580ВМ80 (Intel 8080), в качестве командной оболочки. Думаю тут, тоже обошлось не без Майкрософт. И если уж на то пошло, то какая-никакая IDE была даже в спектруме по крайней мере интерпретатор сразу после набора строки кода, показывал где ошибка, ну пусть не шибко информативно, в основном ? знаком вокруг места с ошибкой, без четких указаний, хотя написать в том редакторе программу длиннее 100строк было уже мучением.
Ага.
Мне ТурбоПаскаль первоначально не зашёл - то, что я видел - запускалось в виде кучи каких-то разноцветных окошек-квадратиков, с которыми было непонятно, что делать. И это при том, что паскаль я изучал "вприглядку" по книжке - заметно раньше, и он мне нравился. И только с версии 5.5 (?), с TurboVision - я на него "запал". Хотя я переписал в пинарнике его раскраску - под то, что увидел у QuickBasic'а - чёрное поле, голубые (cyan) линии, оформляющие окошки, голубым же поле выбранного пункта меню - и белый цвет такста программы.
P.S. Можно вспомнить, кстати, что QuckBasic отличался от "классического" бейска кардинально, и выглядел "почти как паскаль" - там уже были структурные операторы, емнп и прочие полагающиеся плюшки. Оригинальный же бейсик - был крайне примитивен (что, собственно, заложено в его названии), и оператор программы в нём - обязательно должен был иметь цифровую метку, операторы исполнялись в порядке номеров меток, оператор без метки - исполнялся интерпретатором немедленно.
А который из Бейсиков Вы именуете "классическим"? Я начинал на "спектрумовском", продолжил на "УКНЦ", чуть зацепил gwbasic, потом был TurboBASIC, QBasic, QuickBasic (последние два были неотличимы синтаксически, но один был интерпретатором, и шёл в составе MS DOS, а второй был компилируемым, и шёл как самостоятельный продукт), ну а потом набежали всякие вижулы, а я перестал считать себя программистом.
С Паскалем я тоже познакомился до "Турбо" - на тех же школьных УКНЦ, потом был TurboPascal (кажется, какая-то пятая версия) во дворце пионеров, на УПК, и это был восторг... да, графика реализована через внешние BGI, но всё остальное - космос! - чего только стоили массивы, отображаемые на конкретную область памяти (например, для работы с тестовым экраном, или любимым мной 300*240*8bit, за давностью подзабыл, вроде MODE 13), ассемблерные вставки, отключение обработчиков исключений... Чуть зацепил BorlandPascal for Windows 7.0,7.1, но мне, привыкшему работать с сущностями (видеопамять, принтеры, мышь, клавиатура, порты ввода-вывода, Memory Control Block и вот это всё) на низком уровне, оно не зашло - всё-таки я "мыслил на ассемблере", а при таком подходе каждый слой абстракций снижает эффективность. В итоге, переродился в админа - тут как раз бывает очень полезно понимать, из-за чего возникают конфликты IRQ и прочие низкоуровневые приключения.
Dartmouth BASIC.
Один оператор - одна строка.
Если оператор начинается с численной метки, то это - программа, если нет - то он исполняется немедленно.
В программе операторы исполняются в порядке меток (по этому рекомендовалось при написании программы инкрементировать последовательные операторы с шагом в ~10).
(Ну и всё прочее, типа однобуквенных переменных и т.д.)
Структурного программирования - нет от слова совсем.
Из-за повсеместного использования VM понятия все равно перемешались. Тот же Visual Basic указанный в статье, создаёт exe файл, состоящий из call dll чуть более чем полностью. Он компилятор или интерпретатор? А .Net?
Или к примеру JavaScript не создаёт exe, но перед выполнением код транслируется в довольно бинарный формат V8. Куда его отнести?
Тот же Visual Basic указанный в статье, создаёт exe файл, состоящий из call dll чуть более чем полностью. Он компилятор или интерпретатор?
Очевидно, компилятор, а результат компиляции - exe.
А .Net?
А что .Net?
JavaScript не создаёт exe
Конечно не создаёт. Как ЯП может создавать exe?
но перед выполнением код транслируется в довольно бинарный формат V8
Посмотрел Nashorn Engine, который выполняет JavaScript, и не нашел никакого V8 внутри. Может плохо искал, конечно.
Очевидно, компилятор, а результат компиляции - exe
Речь идет о том, что если результат - exe, то это не всегда означает, что это сделал компилятор.
Были такие интерпретаторы, которые умели не только построчно выполнять ваш текст программы, но и создавать из него exe. В этот exe файл они помещали сам интерпретатор, и полностью исходный текст. При запуске exe интерпретатор начинал этот текст интерпретировать.
Программист был доволен: продал exe, круто, как все порядочные программисты. Пользователь был доволен: получил один exe, запустил - работает. Хакер тоже был доволен: при некоторой сноровке исходные коды прямо в текстовом виде из такого exe можно было выколупать обратно.
Были такие интерпретаторы, которые умели не только построчно выполнять ваш текст программы, но и создавать из него exe.
Я не знаю про такие, но если взять как пример классический .NET или классический Visual Basic, всё это компиляторы, но компиляторы с виртуальной машиной. Компилятор и там, и там присутствует, но компилирует не в бинарные коды, а в MSIL в случае дотнета, и в подобный по сути P-code в случае классического VB, которые потом выполняются виртуальной машиной, каким-то образом скомпонованной с вашим приложением.
В этот exe файл они помещали сам интерпретатор, и полностью исходный текст. При запуске exe интерпретатор начинал этот текст интерпретировать.
В этом случае такой "интерпритатор" ничего не интерпретирует. Так что вопрос "интерпритатор или компилятор" не имеет смысла.
От того, что exe-шник, созданный компилятором состоит из вызовов подпрограмм чуть менее чем полностью - он не становится исходником, это вполне себе нормальных exe-шник. В случае псевдокомпиляции - это будет "прямой шитый код". Исходного кода там не будет. Можно, конечно, предусмотреть наличие исходного кода "специально" - как это делается в Форте - но это уже другой вопрос.
Мне нравится определение из статьи Distinguishing an Interpreter from a Compiler:
Мне нравится определение из статьи Distinguishing an Interpreter from a Compiler, что компилятор от интерпретатора можно отличить по времени выполнения:
у компилятора оно зависит только от объёма исходной программы, а у интерпретатора оно ещё зависит и от данных, которые программа обрабатывает.
Также интерпретаторы зачастую содержат внутри себя компиляторы.
у компилятора оно зависит только от объёма исходной программы, а у интерпретатора оно ещё зависит и от данных, которые программа обрабатывает.
Это не совсем правильно, это имеет смысл только для каких-то совсем древних кейсов, когда все переменные программы выделялись на этапе компиляции. С тех пор, как появилось ООП, это уже не работает.
у компилятора оно зависит только от объёма исходной программы
Объёма, измеряемого в чём? Вот это довольно короткая программа, но компилируется долго (5 секунд):
constexpr unsigned fib(int n)
{
if (n ≤ 2)
return 1;
return fib(n - 1) + fib(n - 2);
}
int main()
{
constexpr auto r = fib(20);
return r;
}Тут главное, что нет зависимости от данных, которые обрабатывает компилируемая программа.
Вот это довольно короткая программа, но компилируется долго (5 секунд):
Мне даже страшно представить, что там наворотили внутри компилятора С++, что статическое вычисление в двадцать уровней рекурсии простенькой функции он просчитывает 5 секунд на современном компьютере. Интерпретатор из 1980-х на РС ХТ, который делал эту же самую работу, справлялся как-то быстрее.
А, чёрт, я тут случайно оставил старый вариант (потому что сначала написал код здесь, а потом скопировал его в редактор, чтобы подобрать константу, но забыл его здесь обновить, лол). 5 секунд собирается, конечно, вариант с 33 вместо 20.
Но, впрочем, там не только 20 уровней рекурсии, там ещё и O(fib(n + 1)) сложений надо сделать, а это уже несколько дольше, особенно в интерпретируемом режиме. ghci вот тоже пару секунд на это тратит.
Но товарища Жукова и сняли с командования и отправили в захолустье, когда посчитали, что все битвы выиграны:)
Когда люди выигрывают много битв, они могут начать претендовать на новый уровень власти. И тут только два варианта: делить власть или с глаз долой
Вот да, но надо ж сначала выиграть эту войну!
А тут - "иди, мальчик, дальше мы сами повоюем, по инструкции ..."
Кстати, по статье не совсем понятно - он сам ушёл или "его ушли".......
ИТ это бесконечная война) расслабились, свели счёты, повышать уровень власти не стали.
Ну так руководство могло решить, что и так уже всё в шоколаде. Осталось доить клиентов, да плевать в потолок. И первые годы выходило этим заниматься успешно, судя по статье.
IMHO, самым ценным для начинающего разработчика был встроенный в IDE хелп по языку. По нажатию Ctrl+F1 открывалось описание именно той функции или конструкции языка, на которой сейчас стоял курсор.
Это в какой версии такое было? Я такого не помню даже.
в любой, если пакет "справки" установлен.
Ох ты ж! А я просто описание языка читал по книжке. Помню, читал запоем - случилось купить книжки с описанием по-русски.
ну, книжки тоже хорошее дело. В интегрированной справке-то была только краткая инфа. К слову, это было уже в Qbasic и QuickBasic (для DOS), даже с примерами кода. В Turbo Pascal тоже было, но как-то скупо.
Фаронова, наверное, книги... Эх, были времена... :-)
Может быть, Фленова?
Фаронова. Флёнов, это про работу на компьютере вообще - DOS, Windows, MS Office. По Паскалю настольная книга была от Фаронова
Да нет, Фаронова. Когда у Фаронова первая книга по Паскалю вышла, Фленов подростком еще был. При всем уважении к его талантам, рановато ему было учебные пособия писать. Скорее, он сам тоже Фаронова читал тогда :-)
Фаронов
Помню книжка отличалась полным отсутствием воды и была очень емкая при скромном формате и хорошо подходила и для изучения с нуля и в качестве справочника.
Были еще, кажется, по ООП и турбовижн такого же формата других цветов. Помню было удобно доставать по цвету корешка с полки.
По-моему, все-таки не в любой, а начиная с четвертой.
Когда-то при наличии MSDN подписки вся справка по любым продуктам и технологиям от Microsoft была интегрирована в Visual Studio и устанавливалась локально в интранет сети. Не имея интернета, можно было спокойно "покурить" MSDN и разобраться в том или ином API. Попробуйте сейчас это сделать без доступа в интернет :-)
p.s. chm - формат давно уже "закопали". А ведь хорошаю вещь была.
А еще, помнится, лет 10-15 назад у MS были подробные, обстоятельные, хорошо переведенные хелпы на все библиотеки. А сейчас иногда совсем "на отвяжись" сделано бывает.
Появится необходимость, появится и оффлайн формат. У StackOverflow очень долго была оффлайновая версия, не знаю что с ней сейчас, видел проект несколько лет назад по сборке ответов и вопросов оттуда в pdf учебники.
Собственно даже тот же дипсик запущенный локально это оффлайновая справка.
Вот мой MSDN для делфия, оказывается до сих пор есть: https://delphiworld.narod.ru/_all_articles_.html
Первый раз я это увидел ещё в пятом Турбо Паскале, точнее, моя версия была 5.5, там, где ООП завезли. И я по этому гайду выучил сам язык.
К слову, самый крутой хелп был как раз в Delphi 1. Там был не только хелп собственно по Паскалю и библиотекам, но был и хелп по заголовочным файлам WinAPI, причём уже сконвертированный под Паскаль. После этой версии они уже так не заморачивались, отправляли читать виндовый SDK от Майкрософт, и самому переводить хедеры.
Справка по языку была уже в первой версии с IDE — Turbo Pascal 4.0, выпущенной в 1987 году.
Я английский язык так выучил
А еще была такая хорошая вещь как SWAG - эдакий оффлайновый SO по паскалю :)
В нем тоже много чего интересного можно было почерпнуть.
Крутые были для своего времени и турбо паскаль, и делфи. Я с них и начинал программировать. На делфи 7 даже дипломную работу писал. Имел толстенные книги по делфи, в сети находил неочевидные какие то фишки, интересно было. Так то вообще много чего понаписал в ту пору. А потом появились смартфоны, ну я и перешел вообще на джаву и в веб, php+js.
И вот это мне совершенно непонятно. При всем сложном характера Кана, это выглядит как если б после Курской Дуги и Сталинграда товарища Жукова сняли с командования.
Статья интересная, но слегка портят впечатления несколько отсылок к боевым действиям. В наше неспокойное время хотелось бы хотя бы на IT-ресурсах обойтись без военной тематики.
К тому же приведенное сравнение тут не совсем уместно: товарищ Жуков никакого отношения к Сталинградской битве не имел, потому ни снимать, ни награждать его не было оснований.
товарищ Жуков никакого отношения к Сталинградской битве не имел
Как минимум, Жуков был представителем Ставки на Сталинградском фронте и занимался координацией действий фронта с соседними.
Так же в мемуарах он утверждает, что вместе с Василевским принял активное участие в разработке плана операции "Уран", но вот тут доказательств нет, ибо "Засекречено."
В Turbo Vision содержится красивая стройная концепция управления окнами
И тени! Там были тени, которые двигались вместе с окном. Это придавало эффект объёмности, что было нереально круто.
Напомню - мы говорим не про графику, а про текстовый экран 80*25 символов.
Это была классная библиотека.
Учился окошкостроению и ооп на ней.
Сначала на паскале, потом на си.
До сих пор энтузиасты ее поддерживают
В TV была система очередей сообщений. После понимания этой концепции переход на програмирование на Win (VS 6) не составил большого труда.
А еще была библиотека
Правда я уже на плюсах ее юзал.
Помнится, она мне намного больше нравилась, чем MFC.
Это, видимо тоже была начальная попытка поддержать разработку под винду.
Еще до delphi/c++ builder
Если я не ошибаюсь, она входила в Borland Pascal for Windows? От 93, кажется, года? В комплекте Borland Pascal 7.0?
Или я путаю?
Там очень-очень нестандартные расширения C++ использовались. Это и плохо, и хорошо одновременно.
Я будучи ещё студентом в середине 90х написал на ней свою первую программу под Windows (клон популярной в те времена игры Lines :-). В Borland C++ была "интересная" идея "связывания" методов класса для обработки событий Windows.
Что-то типа virtual void OnCreate(...) = WM_CREATE;
Правда не прижилось, потому как было собственным расширением компилятора, а не стандартом языка С++.
Каким же крутым был Вижуал Студио в свое время, который как я понимаю разрабатывал тот же человек который создал Борланд.
Сейчас этот VSC шаг в перед в плане кросплатформиности и системы плагинов и выстрел в обе ноги одновременно по стабильности, вылизаности и возможности создавать оконные приложения.
Так Visual Studio и Visual Studio Code это два разных продукта же.
Вот именно!
Раньше специально держал раздел с виндой только ради него потому что было просто приятно работать и очень быстро накидывалось оконное под винду без танцев.
Причем прирост такой что даже имея что-то кроссплатформенное на Qt4 проще быстро перекинуть на вижуал и там собрать, будучи уверенным что оно будет валидно работать и не крашить.
UPD
если кто не знал - мягкие закрыли развитие вижуала сделав упор на VSC, потеряв по сути огромный пласт наработок в плане IDE
UPDесли кто не знал что мягкие закрыли развитие вижуала сделав упор на VSC, потеряв по сути огромный пласт наработок в плане IDE
В сентябре публичная бетка 2026 студии вышла :)
О, так они таки "вернули все в зад"?
Ну я "имел счастье" застать момент когда появился VSC а о вижуале начали говорить как об "устаревшем". Тогда еше как раз VSC был в сотни раз кривее чем сейчас.
Причем скипнул не сразу, а года через два где-то.
Посмотрел википедию - куча версий уже вышла с того момента.
Забавно как они чисто менеджерскими приколами с "посмотрим по рынку" потеряли пользователя, который покупал лицензию (пиздецки дорогую между прочим, благо студенческую скидку можно было получить просто публикуясь). И я уверен что не один такой.
VS живее всех живых, никакого курса на замену его на VSC нет (и не было). Вся энтерпрайзная разработка под .NET вообще живет либо на VS, либо на Rider от JetBrains. VS Code это замечательный универсальный редактор кода, но все равно не полноценная IDE.
Не, я помню конечно тот период времени на взлете VSC когда про него везде писали что это бесплатная кросcплатформенная альтернатива VS, но сами майки никогда так его не позиционировали и время показало что это два разных продукта, для разных задач, хоть и с пересекающимся функционалом.
И как она? Неотключаемый слив кода через Copilot, поди? Думаю, на что переходить с 2022-й. Или так и продолжать в ней сидеть, пока рак не свистнет?
https://en.wikipedia.org/wiki/Visual_Studio#History
"Сижу" на этом продукте ещё со времён Visual C++ 6.0
Автор не застал Vi/Emacs/MultiEdit/QEdit где всё это прикручивалось?
Между прикручивалось и работает сразу есть небольшая разница. Прикрутить к vim много чего можно.
Это было уже позже. Да, мультиедит был крут, но TP был маленьким чудом именно для своего времени.
Знаете, это вот как для меня в 1990 было чудом притащить в электрохимическую лабораторию лазер, чтоб подсветить - что там делается в ячейке с расплавом?
Лазер (зеленый) тогда был размером полтора метра в длину и 10 см в диаметре, и включался в розетку. А вот сейчас можно лазерную указку таскать в кармане. Это круто, но уже никого не удивляет.
Или как смартфон у вас в кармане - сколько там мегагерц и мегабайт? А ведь впечатляет не так, как 20-мегагерцовый PC AT c мегабайтом памяти и 40 мегабайтами HDD.
А если брать времена мультиедита - это, вроде бы, середина 90-х? - то тогда для меня было чудом CodeInsight. Помните? Когда начинаешь набирать имя, а редактор тебе уже готов подставить его полностью? И еще когда он подсказывает тебе, какие параметры у процедуры?
А вот сейчас и это уже привычно.
Это было уже позже.
В 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
В Gnu Emacs в 1989'ом не было M-x compile?
Его не было под DOS. По мотивам были Demacs и MicroEMACS. Но по удобству это разве что с третьей версией "турбины" сравнивать (да и то не в пользу Emacs-like), а не с четвертой-пятой, про которые идет речь.
Ну и плюс это еще где-то взять надо было, если мы про наши реалии говорим. А "турбина" расползалась сама, как вирус :-)
Мультиэдит это песня и любовь, досовый.
Макроязык которым все пишется и обработка текста и файлов, и оконное, и хоть мелкая база данных и даже исполнение кусочков ассемблера., причем сам ME редактор написан на макроязыке, а интерпретатор ядро - как раз на турбо паскале, .
я я этот ME и хачил и переводил,и макросы писал раскидистые. А уж когда появился декомпилятор - то просто правил весь ME целиком.
есть еще XEmacs на иксах наверно
А в чем состояла необходимость тащить в заголовок нецензурщину?
Согласен, среди читателей есть школьники и беременные женщины, правильнее было бы назвать так:
"Как B*****d просрали все полимеры"
Отсылка к древнему мему, сэр.
Да я как бы в курсе «древнего мема». Я спросил о цели и о допустимости матерщины прямо в заголовке. Что, уже можно начинать публикацию прям с мата? Не в мужском же сортире стены читаем, не?
Впрочем, похоже, по рекомендации администрации, заголовок был изменен.
Я уж молчу о том, что глагол так и не согласован по числу с существительным.
Я смотрю проще. Задаю себе вопрос: правда ли заголовок станет лучше, если заменить ужасное слово про$р@ли на какое то другое? Или если буквы заменить- никто же не догадается, что имел в виду автор? А потом думаю: кто смог опознать мем - тот уже достаточно взрослый чтобы оценить шутку юмора. А кто не смог.. Ну, вряд ли ему будет понятен текст про древних борландов.
Зы Так - хуже. Все знают, что полимеры не профукивают
Вы можете определить, что такое матерщина, а что такое нецензурные слова? И чем они отличаются от грубых слов?
Или так, по наитию, называете как попало?
Да, простите, испортился я в 90-е, подрастерял интеллигентность, набрал нехорошего культурного контекста. Теперь ведь и не вспомню, из какого фильма взялась эта крылатая фраза.
Тяжко живётся в наше время выпускникам Института Благородных Девиц.
Вечно им мерещится нецензурщина там, где её отродясь не было.
Ведь как в те времена делалось "в норме"
У меня и большинства знакомых, начинавших в те времена, программирование на более-менее серьёзных машинках начиналось именно с Turbo C/Pascal с IDE, про запуск компилятора/линкера из командной строки, make и т.д. узнавали уже позже.
Хотя примерно тогда же был доступ к ЕС ЭВМ, там всё "по классике", только ещё запуск компилятора/линкера шёл через заклинания ЯУЗ в начале исходника, которые все просто копировали друг друга не особо понимая.
Мне кажется, что сама бизнес-модель продажи компиляторов и других средств разработки себя изжила. С одной стороны появились открытые и тем самым бесплатные компиляторы вроде GCC и clang, с другой стороны библиотеки для GUI вроде Qt. Microsoft так же сделала свои инструменты разработки по большей части открытыми, ибо непрямой профит в виде привлечения разработчиков на свою платформу оказался выше профита от продажи инструментов разработки. В такой ситуации нету смысла покупать что-то, аналоги которого есть за бесплатно и которые иногда даже лучше платных продуктов.
библиотеки для GUI вроде Qt
Жаль эта дрянь вылезла за пределы линуксов
Альтернативы есть ?
нативные API
Кому не нужно кроссплатформенность и интересно играться в CreateWindowEx - их же никто не заставляет писать на Qt?
В век кроссплатформенных приложений писать мало-мальски сложный гуй на нативных апи под три десктопных ос... завидую количеству вашего свободного времени. Вот бы мне лишний человеко-год
А чем вам Qt не нравится? ИМХО прекрасная библиотека.
Да, скорей всего вы правы. Недаром же Microsoft дает Студию бесплатно. Я полагаю, Борланды именно на этом в частности прокололись.
Когда Борланд гавкнулся Майки еще Студию вполне себе продавали, и еще долго.
Я 2008-ю Visual Studio бесплатно скачал, уже тогда была какая-то бесплатная, но ограниченная версия. Примерно в тоже-время была доступна IDE под названием Code::Blocks, которая конечно коммерческим IDE уступала, но всё-же была вполне рабочей.
Уже не помню цены, но, кажется, Студия стоила около 50 долларов. А по каким-то программам начала-середины 2000х ее давали и бесплатно. А Delphi стоили на порядок дороже, нереально для покупки на себя лично.
Борланды именно на этом в частности прокололись.
Не совсем на этом. а на MSDN - для корпораций это было как воздух. Плюс платный саппорт разных уровней, причем нижние включены в MSDN.
А аналога у борланда, и сил сделать подобное не было.
Ну хз, бизнес Intellij вполне успешен. И если для их продуктов есть более-менее неплохие бесплатные аналоги, то для узкоспециализированных средств иногда бесплатных аналогов нет или они совсем убогие
С удовольствием кодил на Турбо паскале, а потом купил толстую книжку по турбо вижн и наткнулся на какие-то непонятные вещи в коде ))) Так я узнал, что бывает ООП )))
А уж на делфях извращался со всякими компонентами, очень мне нравилась красивую графику в них делать ))
Ой, тоже помню ступор от этого непонятного кода с понятными операторами. Долго на это дивился, не понимая. Но однажды мне в руки попала дискетка с описанием Turbo Vision. 250 страниц на чистом аглицком языке! (Благо, в школе дали хорошую базу, смог прочесть)
Я ж его читал как детектив! Все выходные не отрываясь! А потом вечерами!
И скрипел всеми шестеренками в голове, пытаясь освоить новый подход.
Зато как классно было потом! Когда я понял, как контролировать ввод данных в окне!
Когда я однажды поспорил с начальником, и на спор написал за неделю учебную программу, рассчитывающую колебательный контур и строящую кривые его характеристик!
И охреневший начальник минут 10 сосредоточенно пытался заставить программу дать сбой. А она его увещевала, что, мол, в данном поле вводится частота, которая не бывает отрицательной. И предлагала ввести верхний предел графика выше, чем нижний. И не давала вводить буквы в цифровые величины.
Вы когда-нибудь видели человека, которые только что съел лимон целиком? Вот такая у него была физиономия, когда он встал и сказал - "Ну, ничего..." Похоже, эти слова стоили ему больших усилий.
Ну, понятное дело. Сам он писал на Фокс Про, и у него на то, чтоб заставить одно диалоговое окно более-менее вменяемо работать, уходило с месяц. И то после этого его программы то и дело выдавали "Abort, Retry, Fail?"
И мне даже трудно было бы ему объяснить, почему у меня окно работает, и на его написание уходит один день.
А насчет красивых компонентов - как не вспомнить Чарльза Калверта и его талмуд?
В школах/колледжах до сих пор Паскаль могут учить. Только теперь он FreePascal
Ага, 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.
Delphi убило то, что она вышла конкурировать на рынок программ, работающих с базами данных, с откровенно слабым продуктом BDE. Слабым с точки зрения условного программиста, до тех пор сидевшего на FoxPro DOS, и решившего перевести свой продукт на Delphi. Разумеется, тот условный программист - это был я.
FoxPro DOS в середине 90-х уже была мощным и совершенным продуктом, которая выжала всю возможную магию из файлового доступа к данным. Особым шиком была технология битовых карт Рашмора, которая позволяла в поиске и фильтрации использовать несколько независимых индексов для различных условий. Другими словами, можно было наложить фильтр по нескольким полям на датасет в десятки тысяч записей, и это отрабатывало мгновенно.
С высоты сегодняшнего дня мы понимаем, что в технологии клиент-сервер так не делают, и такую программу следовало бы переосмыслить и переписать слой доступа к данным. Но в том-то и беда, что Borland хвастливо позиционировал свою BDE как on-place замену файл-серверным технологиям в существующих программах. А в результате такой замены программы просто начинали работать гораздо медленнее, потому что аналогичные фильтры, наложенные на те же данные, в BDE индексов использовать не умели и дико тормозили.
Имея прекрасный по тем временам сервер Interbase, им следовало бы сосредоточиться на новой клиент-серверной технологии, развивая для этого все компоненты и перетягивая на них старые файл-серверные приложения, может с какими-то тулами миграции. Но они не сделали это приоритетом и упустили возможности. Что можно сказать. Жаль, хорошее было время.
Вот тут мне сложно с вами спорить, потому что у нас несколько различаются области. С Фоксом я практически не работал, но помню, что индексы они научились использовать очень хорошо и быстро, и за счет этого Фокс и вылез - именно как самая быстрая из DBase-подобных СУБД.
Но в то же время я помню, что та же 1С использовала движок CodeBase - насколько я понимаю, это как раз тот же, что и в Фоксе. И считала итоги по остаткам в магазине по 20 минут. Я натравил на ту же таблицу (1С-овский регистр) простую программку с BDE-шным SQL-запросом. И получил итог за 15 секунд.
Так что тут вопрос может быть сложнее, чем кажется.
Что BDE был сыроват - я спорить не буду. Но с вашей формулировкой насчет "откровенно слабого продукта" категорически не соглашусь. Тут главное было то, что BDE мог работать с любыми СУБД. А насчет скорости... Ну, во 2 или 3 версии Дельф можно было уже от BDE отказаться - я, скажем, стал использовать InterBase и компоненты IBX, потом FiBPlus. А универсальность обращения с базам данных осталась.
И главное - назовите, у кого еще был инструмент, позволяющий работать с разными СУБД одинаковым образом? Да только у Borland и Microsoft. И все!
Но если хотите, с удовольствием с вами пообщаюсь, вспомним былое )
Вы правы, конечно, BDE - это огромная проделанная работа, внушающая уважение. Но все же заявленная универсальность работы с разными БД так и осталась мало полезной на практике. Беда в том, что дьявол в мелочах - различиях в работе с NULL, датами, BLOB в разных СУБД все же не позволял сколько-нибудь объемному приложению просто переключить драйвер и начать работать с другой СУБД. Ну и печально то, что это потребовало бы ужать SQL запросы до общего куцого даже по тем меркам ANSI SQL-89, в то время как у каждой СУБД в диалектах SQL уже были свои вкусности, которые отпадали при работе через BDE. Смутно помню, нельзя было делать подзапросы SELECT FROM (SELECT..), WHERE field IN (SELECT) и многое другое.
В итоге все кто находил возможность отказаться от BDE, испытывали облегчение.
Потому что “каноническим способом”, рекомендованным Microsoft, программа в одно окно содержит до трех тысяч строк кода и требует, соответственно, месяц работы.
Шта?! Какое "одно окно"? "Hello, world" был бы гораздо меньше. Зарегистрировать оконный класс (десяток-полтора строк), написать "оконную процедуру" (ну, два десятка), вызвать CreateWindow и создать цикл обработки сообщений... из трёх строк.
Приложение, которое делает что-то осмысленное... ну, пусть три тысячи строк, но один чорт там основное время займёт функциональность, а не GUIта.
Ну да. И каждый пункт меню регистрировать. И каждую иконку на тулбаре. И callback на все чихи прописать. Gui на чистому windows api как brainfuck.
Да ничего там особенно ужасного нет, и точно не брейнфак: https://ciprianf.hashnode.dev/win32-api-programming-using-menus
Классическое олдовое ООП "с сообщениями".
Ничего ужасного, кроме простыней кода. А в Delphi все получалось автоматически. Причем, если надо, никто не мешал лезть под капот и дергать windows api руками.
Из этих простыней получались бинарники меньше сотни КИЛОбайт, которым для работы хватало голой винды, в отличие от десятков мегабайт всякого [censored] с электроном и что там ещё нынче модно.
Впрочем, бинарники из-под Delphi по 7ю версию включительно тоже было достаточно компактными, если не тащить туда самосвал сторонних компонентов.
бинарники меньше сотни КИЛОбайт
Кого волнует размер? В то время, когда бинарники стали занимать мегабайты, дискеты уже вышли из употребления. А по сети - быстрее скачать чем носиться с флешкой.
>от десятков мегабайт всякого [censored] с электроном
Почему десятков, сотен.
VS code - 150 mb. Кроме мерзкого electron, там ничего нет, правда?
Вопрос терминологии и точности выражения. Для меня hello world в 150-180 мегабайт это не десятки мегабайт, точно. Десятки мегабайт это 30-50 там. Наверное формально под "сотни" тоже не подходит. Хотя, в принципе, почти две сотни мегабайт, так что все таки сотни.
VS Code - это вы инсталлятор считаете или установленное приложение? У меня сейчас она на диске 438 мегабайт весит и я не уверен, что это все ее файлы.
У меня и сейчас бинарники небольших программок с GUI (VCL) и БД (MS Access, SQLite) - 4 - 6 Мб. Скомпиленные в Delphi 12.
Ну, насчет десятков мегабайт - это точно не про те времена. Тогда программа могла занимать триста килобайт, и мой друг говорил, что это много, мол, на С будет меньше. Согласен, говорю, но вот ты эти триста килобайт положи на гигабайтный диск, отвернись на минуточку, и попробуй их там найти. Для того времени дисковое пространство было уже дешевым, даже в памяти программа на 300 килобайт тоже была не особо обременительна.
А про сотни мегабайт - это уже сейчас ухитряются делать. Как они это ухитряются - я пока даже не очень понимаю )
даже в памяти программа на 300 килобайт тоже была не особо обременительна.
Как сказать... Если она в реальном режиме работала, то 300 кб EXE-шник это обременительно, ведь обычно сколько было DOS-памяти свободной? 570-580kb (при условии что мы все очень тчательно сконфигурировали, юзаем himem.sys, грузим резидентные драйверы в верхнюю память и т.д.
И того, 300Кб ехе, 16кб на стэк, и остается 250 кб, которые мы сможем использовать для массивов и динамически-выделенной памяти. Туды-сюды и уже аут.
Видите ли, с точки зрения сложности разработки размер бинарника не имеет значения, а вот размер исходного текста - как раз имеет. Поэтому простыней кода и стараемся избегать.
...а потом пользователь плюётся на тормозное bloatware. Зато священная корова-программист не перенапрягся, бедняжечка.
Ну, если вы любите длинные простыни кода - это ваше право.
А насчет когда напрягаться, а когда не стоит - тут каждый за себя решает.
Почему вы связываете это со скоростью работы программы - мне вообще непонятно. Скорость работы формы (если мы о ней) зависит прежде всего от того, сколько действий ей приходится совершать при том или ином событии. И если программист понимает, что форма делает - то он сможет сделать так, чтоб она работала нормально и комфортно. Если не понимает - может сделать так, что форма будет по десять раз пересчитывать и перерисовывать себя, и, соответственно, будет тормозить.
А почему вы связываете тормознутость формы и то, насколько задолбался программист - мне непонятно. Похоже, пытаетесь убедить меня ложными доказательствами. Не убедили.
Ну, в то время ходил пример, как нужно писать программу под Windows. Возможно, в этом примере было наворочено много такого, без чего можно было обойтись. Но мы в то время еще не успели изучить функции Windows, и разобраться что надо что нет не могли.
А в ваших программах все окна были такие простые? Или были окна более сложные? Ну, вот я прикидываю - надо обрабатывать как минимум клавиатуру, мышь, события закрытия формы, завершения ОС, смены фокуса, сколько их еще наберется?
так да, и вы тоже правы, можно смотреть на подход java или на математику, по началу кажется, хоп-хоп, щас я напишу как думаю библиотеку, и со временем, когда допиливается например математическая библиотека или оконная библиотека, она обростает всякими поддерживающими 'модулями' назову так, тоесть функционалом и по итогу мы получаем ну почти тоже самое :) а на старте просто окно вызвать да и на Иксах удобнее, вот взять Window Manager идею например с XReparent(типо стековый) и вокруг этого XReparent и этого функционала WM с виду простенький обрастёт кодом - поддерживающим эту концепцию
А как развивался сам язык Delphi по мере появления новых версий? Обычно все пишут о фичах новых языков, а Delphi вроде как достаточно старый, поэтому "научно-популярных" статей про него на том же Хабре негусто. Но вот мне интересно все что связано с языками программирования как таковыми. К примеру в C++Builder используется интересное расширение С++ - "свойства", вероятно и в Delphi тоже. Еще вроде бы RTTI там достаточно продвинутый (но тоже какие-то слухи из инета, я на Дельфи не писал ничего, а на Билдере чисто для себя совсем немного и лет 20 назад). В общем, это намек для энтузиастов Delphi/Builder, было бы интересно почитать про особенности языков.
К примеру в C++Builder используется интересное расширение С++ - "свойства", вероятно и в Delphi тоже.
Ну как бы в С++ Builder архитектуру завезли из Delphi, а не наоборот, будь-то свойства, RTTI, библиотека компонент, пакеты, и изначально Delphi по фичам шла примерно на одну версию впереди.
По версиям - вторая стала 32-битной, под Win95/NT, в третью завезли интерфейсы, поддержку СОМ, очень круто расширили IDE (там уже в 1997-м было и автодополнение кода, и сниппеты, и плагины) и библиотеку компонент.
О, свойства - это прекрасная вещь! Это обобщение поля, позволяющее присваивать и читать значение. Но в общем виде свойство может быть и переменной (полем), и чем-то более сложным - и тогда чтение и/или запись выполняются специальной процедурой/функцией.
А важно то, что эти детали от пользователя скрыты - он просто обращается к свойству, и все.
За счет этого можно, например, сделать свойство так, чтоб при каждом изменении оно не только меняло собственно значение, но еще, к примеру, куда-то сигнализировало, что значение поменялось.
Собственно, именно на свойствах и строилась работа компонентов в Дельфах, за счет чего они "жили" прямо в проектируемых формах, без необходимости компиляции программы.
И да, в C# свойства тоже есть.
RTTI - возможность не зная типа объекта, все же обратиться к его свойствам или методам.
В Delphi для этого нужно было объявить свойство опубликованным (published), и зарегистрировать класс (RegisterType(AType: Type)).
После этого можно было в программе спросить - нет ли в регистрированных вот такого класса? А какие зарегистрированные классы у нас есть? А вот этот объект - вот нам ссылочку дали, а какого он типа не знаем, сказали что Object - а может, он гораздо сложнее? - он какого типа?
Также можно было обратиться опубликованному свойству этого объекта - по имени - мол, говорят, у этого объекта есть свойство по имени 'Color' - дай-ка его значение? А теперь запиши в него цвет Red.
А еще можно было зарегистрировать процедуру и потом тоже выполнить ее - просто зная ее имя.
В Delphi RTTI в основном использовался для загрузки форм из файла ресурса.
Сейчас в Java и C# такие операции очень распространены и называются сериализацией (сохранение объектов и значений их свойств и полей в файл - обычно текстовый, .xml, но в принципе можно куда угодно) и десериализацией (соответственно, восстановление - читаем файл, создаем объекты).
Сейчас в Java и C# это реализовано значительно шире, и называется Reflection. Доступно для всех публичных классов, их методов и свойств. Т.е. можно посмотреть, какие классы есть в нашей программе или в загруженном модуле; ощупать их свойства и методы (т.е. заранее вообще не зная, какие там свойства - просто получить их список, и прочитать значение любого из них; например, так можно копировать списки объектов заранее неизвестного типа).
Можно также создавать экземпляры неизвестных классов - вот, я в файле конфигурации провитал, что надо создать класс TrehmernayaHren, и проверил - у нас в программе есть определение такого класса, вот давай-ка создадим его экземпляр. И, например, запишем куда-нибудь.
Где реально это можно использовать?
Ну, например, я делал библиотеку для создания форм, которая могла отобразить на экране любой объект. Просто создается форма, далее проходим по свойствам объекта, выясняем их типы и названия, и для каждого свойства создаем метку с названием свойства и элемент управления соответствующего типа. И привязываем к этому свойству. Или просто присваиваем этому элементу значение свойства. Т.е. форма для редактирования объекта строится автоматически, "на лету". Очень удобно, если тебе приходится показывать и редактировать много разных объектов достаточно простой структуры. (Для объектов сложной структуры такая автоформа получается достаточно сложной, и неудобной, поэтому лучше все же нарисовать форму "руками".
Или другой пример - сохранение объектов в базу данных. В общем виде - имеем объект, выясняем его тип, ищем в БД таблицу с таким именем (можем и создать такую таблицу). Далее проходимся по всем свойствам, и каждое свойство записываем в колонку с именем, соответствующим имени свойства.
И наоборот - создаем объект, и прочитываем его свойства в таблице, дальше работаем с ним.
Тут мы фактически один раз прописываем процедуры генерации SQL-запросов, и дальше просто говорим - дай мне объект типа "Contractor" с идентификатором #13245, дальше программа сама генерирует SQL-запрос, выполняет, создает объект и присваивает прочитанные значения свойств.
Третий пример - к работающей программе подгружаем новый модуль (.dll) - и в главной форме появляются новые пункты меню, выполняющие какие-то новые функции, описанные в этом подгруженном модуле. Причем когда программист эту программу писал, он не знал про этот модуль, этого модуля еще вообще не было.
С помощью того же Reflection можно заставить программу создать новые типы и их функции. Но этого я не пробовал, поэтому только укажу, что такое можно.
а потом появляются статьи на Хабре "почему тормозит рефлексия в Свифт" =)
Тюуууу.... А может, не рефлексия тормозит, а программа, где эта рефлексия используется где не надо?
Строго говоря, везде рефлексию рекомендуют использовать с оглядкой на её минусы. А поиск нужного метода по таблице никогда скорости не добавлял.
Просто в свифте на это много завязано исторически.
Дык конечно ) Инструмент надо использовать там, где он нужен, и так, как нужно )
Вот смотрите - мои примеры рефлексии - там во всех случаях задержка невелика, и главное - не критична. Рефлексия используется один раз, а дальше работа уже без нее.
А вот если б мы ко всем свойствам через рефлексию по имени обращались - было бы медленно, хотя кому-то и показалось бы что так проще.
Кстати, вот в сериализации могут быть тормоза как раз из-за этого... Ну, тоже наверное зависит от того, как реализовать...
Развивается, но слабо и странно. Хорошее - дженерики, анонимные методы - завезли уже давно лет 10-15 назад. А в самых последних версиях появлялось "ну такое", например объявление переменных через var прямо в коде, как в C/C#, а не заранее в отдельном блоке. Вот в сентябре 2025 вышла новая версия - тернарный условный оператор завезли (этакий IfThen), чтобы писать x := if a > b then a else b
Но даже на мой чисто паскалевский взгляд это многословно и неудобно. У меня есть функция IfThen и я лучше напишу x := IfThen(a>b, a, b);
Но с функцией ifthen очевидная проблема: все три аргумента вычисляются до вызова функции. Это может приводить к проблемам производительности, нарушениям в работе с памятью и т.п. Нельзя написать IfThen(a <> nil, a^.value, 0)
У меня есть функция IfThen и я лучше напишу x := IfThen(a>b, a, b);
Выполнив и a, и b...
Да. Ну вот жили с этим 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
И много ли байтиков сэкономилось? Да, я старый брюзга :)))
Спасибо, поностальгировал! С 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).
А я помню иначе. Turbo Pascal не был самодостаточным, к нему был нужен ещё Side Kick - резидентная программа которая выскакивала по шорткату. Подробности рабочего процесса не помню.
А сгубили Борланд два фактора. Первый - Delphi нуждалась в переводе заголовков с С на Паскаль, это было как невидимая, до столкновения, стена - всё просто-просто и потом сразу никак. На это дело попытались бросить народные массы, Project Jedi называлось, но нельзя быть милым народу и корпорациям. Второй - руководство Борланд соблазнили проникновением на корпоративный рынок - там можно и за $500, и за фантастические цены Эмбаркадеро продавать, и без .NET, корпоративной приблуды, никак. После этого из Delphi сделали дойную корову - обирали до нитки и всё спускали на корпоратиыные мечты.
Я помню как восхищался Микрософт - перетащить конкурента из разработки софта, где он выше на голову, на обихаживание корпораций, где уже Микрософт выше на две головы... Примерно в это же время Микрософт внедрила в сознание Линукс сообщества идею быть доступнее для "простого пользователя", это была очень похожая и столь же удачная психологическая операция которой я восхищался даже больше.
От себя я бы добавил отсутствие в Delphi родного компонента для двумерного и трёхмерного рисования. Это отсекло многих энтузиастов из народа.
Забавно, что всё, что было нужно сделать,таки было сделано, и уже ничего не помогло. Как и с Линукс - он таки стал ближе к "простому пользователю" в том смысле, как это предлагалось - появилмсь и работают графические конфигураторы, и точно так же как с Delphi эффект нудевой. Вывод - дорога ложка к обеду.
Нет, SideKick к нему точно не требовался. Другой вопрос, что программисты могли его любить, там был в частности программистский калькулятор.
Вот насчет компонента для двухмерного и трехмерного рисования - не знаю, мне кажется, это довольно специфичная область, и вряд ли наличие/отсутствие такого компонента могло иметь решающий эффект.
Но соглашусь, что иметь его было бы приятно.
Первый раз увидел слово SideKick в этой статье, что не мешало пользоваться Turbo Pascal разных версий много лет.
В течение почти 20 лет Турбо Паскаль преподавали в школах и техникумах, иногда в институтах.
Не уверен насчёт 20 лет, так как его до сих пор продолжают преподавать
На мой взгляд, причины затухания продуктов 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С, которая вытеснила с уровня мелко-средних предприятий.
" 4 Концентрация на одной парадигме: Визуальное формошлепство. " - после прочтения статьи как раз сложилось ощущение, что все наоборот. Если бы они и дальше все силы вкладывали в мега-популярный Delphi, который их по сути и кормил, а не пытались конкурировать со всеми подряд. Визуальный IDE - это ж золотое дно, и если у тебя он лучший в мире. Переписывай компилятор под другие языки (не меняя базы), - опыт уже был, сделали же C++ Builder. Далее добавили бы C#, Java - и опять на коне. Можно быть в тренде, просто поддерживая новые технологии в старом продукте.
У C# в Visual Studio на тот момент визуальный редактор был не хуже. Тем более, он фактически поддерживался из коробки в самом .NET, а потому шансов конкурировать с Майкрософтом на этом поле уже не было. Они попытались, но с их ценовой политикой шансов было немного.
Для Java Борланд с 1997 года выпускал JBuilder, но Java была и остаётся более популярна в энтерпрайзе, а не как десктопная плафторма.
Первые несколько лет на Java писали в основном именно десктопные GUI приложения
Можно даже было из них сгенерить exe со встроенной JRE
Ну, начнем с того, что если бы Борланд не дал сманить Хейлсберга, то никакого C# не было бы.
Мне кажется, что в планах у Майкрософта и так было создать альтернативу Java (Хейлсберг как раз J++ первым делом разработал), то есть его и нанимали по сути для такой задачи. Даже без него они бы, вероятно, сделали что-то похожее. К C# (через Managed C++) они ушли просто потому что Sun запретил им дальнейший EEE в отношении Java. Как вариант, был бы язык, более похожий на Java, или гибрид Java и Visual Basic.
Ну, Кан, возможно, и не дал бы.
Но Кан ушел. А Гейтс предложил три миллиона баксов. Ну, согласитесь, устоять трудно )
добавляли. и jbuilder был и Delphi.net
оказались мало кому нужны
4 Концентрация на одной парадигме: Визуальное формошлепство
Как раз нет, с этим у Delphi все было в порядке. Надоело формошлепить - откладывай в сторонку визуальный редактор, бери код, и делай что хочешь - хоть динамический UI твори из кода, хоть вообще пиши что-то общее - новые компоненты, утилиты командной строки, DLL, компиляторы, да хоть операционные системы.
Да, но для этого надо было понять, что система глубже, чем кажется на первый взгляд.
А для этого надо ж документацию читать. Или книжку хотя бы Архангельского какого-нибудь.
Так что товарищ прав - Delphi провоцировал начинающих писать примитивно и плохо, как это ни парадоксально. А они уже несли заразу дальше...
Делфи провоцировал писать быстро минимальное рабочее приложение. Для простых и не масштабных программ, быстрый способ связывать события и писать код на месте - это не плохо. Не говоря уже о том, что на самом деле, код формы и логики у вас отделен (dfm/fmx и pas). Это совсем не то же самое, когда вы описываете кодом UI и тут же пишете бизнес логику. В делфи всегда отделен код формы и бизнес-логики, пусть события и напрямую связаны с формой.
А в масштабных проектах уже есть умеющий программист, который применит один из шаблонов проектирования.
"на самом деле, код формы и логики у вас отделен (dfm/fmx и pas) "
Этого вы просто не поняли. В форме ее компоненты и код - это один класс. И если у вас в этом классе, например, редактируется накладная, и описана логика работы этой накладной - это плохо.
Потому что если вы захотите сделать другую форму для той же накладной (иногда бывает надо) - вам придется эту логику накладной повторять, или она не будет правильно работать.
А отделить бизнес-логику от форм - означает реализовать класс накладная, который отрабатывает именно эту логику. Может быть, еще умеет подгружать данные этой накладной из БД и записывать туда. Но никаких форм там нет, и ни о каких формах он не знает.
Тогда вы в принципе можете в программе нарисовать форму для накладной - и не париться, будучи уверенным, что логику накладная отработает. И в другой форме - где, допустим, не одна накладная, а целый список - эта логика тоже отработается.
Или сделать что-то с накладными - например, напечатать все накладные, введенные сегодня. Или перепровести накладные по данному клиенту.
Форма - это форма, это структура окна (dfm/fmx). Как окно отображается и что в нем располагается - это задача, которую решает эта структура (разметка). Это часть "View" в паттерне MVC.
Файл модуля (pas), содержащий именно класс окна и обработчики кнопок - это "Controller" в MVC.
И осталось только реализовать этот самый класс "Накладная", с которым будет общаться ваша форма, это "Model" в MVC.
Для работы этого механизма, мы обращаемся к классу Контроллера, создаем экземпляр и работаем с накладной. Любое другое окно, которое хочет работать с накладной использует именно Модель и если нужно, может обращаться к другому Контроллеру накладной.
Ни View, ни Model не знают ничего друг о друге. Controller знает обе сущности.
Delphi же никак не побуждала использовать ни паттерн MVC, ни паттерн MVVC. В типичном Delphi-приложении бизнес-логика была не отделена ни от контроллера, ни от модели, и лишь частично - от представления, и это была каша у начинающих программистов, да и у многих не начинающих тоже.
Совершенно верно.
Кстати, Мартин Фаулер не настаивает на отделении контроллера от формы (представления), но настоятельно рекомендует отделять форму (представление) от модели.
В этом случае мы получим представление+контроллер в одном флаконе.
Как то я видел название для такого - DocumentView, и вроде как раз утверждалось, что Delphi ориентировались на такую архитектуру представления.
Честно скажу, я пока так и не приучился отделять контроллеры от форм. )
Вы неправы, файл модуля - это логика формы, т.е. визуального представления, а не контроллер. Вы посмотрите, в этом файле класс формы создается. И отделить это визуальное представление от этого файла, или заменить его другим, вряд ли у вас получится.
Если вам нужно сохранить какой-то сценарий работы формы - типа, вот по этой кнопке мы подгрузим данные, а вот по этой - их вот так обработаем - вот это как раз логика контроллера. И она, по идее, должна реализовываться в отдельном классе, не в форме.
Именно для того, чтоб обеспечить возможность использовать с тем же контроллером другую форму. В которой эти кнопки могут быть другими, или вообще быть пунктами контекстного меню. Или форма может быть собрана на других компонентах. А контроллер и логика его работы (сценарий) останется неизменным.
А насчет накладной вы правы, это Модель.
Что-то вспомнил разговор с одним погромистом в банке, году так в 2000, насчёт Delphi:
"Да ваш Делфи полное дерьмо, вон, я на нем написал программу, там 3 раза форму ввода открыл - и все, память кончилась"
Частично так.
В отличие от MS Visual Fox Pro, где было указано требование 4 МБ, но ни на 4, ни на 8 нормально работать было невозможно. Нормальная работа Visual Fox Pro начиналась при 32 МБ, что для того времени было ну ооочень много.
У меня как раз было 4 МБ и 5-я MS Visual Fox Pro на них летала. Вот 9-й версии да, 4 МБ было мало.
Помню как классе, кажется, в восьмом я твёрдо решил стать программистом и со слезами на глазах просил у родителей "Ну какую-нибудь книжку о программировании"
Уж не знаю, кто им там насоветовал, но через недельку-две мне подарили огромную книгу по Delphi 7 с установочным диском. Надо сказать, написана она была хорошо, по крайней мере на уровне переменные-условия-циклы-массивы я всё схватил практически сразу.
А когда ещё несколько недель спустя я долистал книгу до работы с графическим интерфейсом это мне просто башню снесло. Это что же получается, я в восьмом классе могу накидать кнопок с полями на форму и написать программу прямо как врослые дяди?
В общем, до этого я ещё думал о том, какая же профессия мне больше подойдёт, то после этого открытия никаких сомнений не осталось.
ух... Delphi7 навсегда останется в моем сердце
На дельфи в 90 и начале 200х было написано огромное количество учетного клиент-серверного софта в банках и предприятиях. Технология прямо и просто решала задачи. Но делфи ничего не предложила конкурентного в дальнейшем для 3х звенок, эту нишу забрала J2EE и для интерпрайз веб приложений.
Но для десктоп ПО она по-прежнему актуальна.
А как энергетики этот Delphi любили! Я как-то посмотрел, какие программы они делали для управления электрическими сетями...
@HemulGM наверное помнит как звали того чувака, который ваял MES на Delphi. Имя вылетело из головы, но там было нечто монструозное.
У Борланда случилась потеря фокуса развития, метания, не приносившие финансового результата. Кто-то еще помнит такое недоразумение как Borland C++ Builder X.
Борланд - это отличный пример, что нужно следить не за загруженностью сотрудников по часам, а за тем, чтобы они делали действительно нужную и полезную задачу.
Помню, как народ надувал губу, что у Турбо Паскаля экзешник "Hello, world" занимает 2 Мб... Посмотрели бы они на Electron..
И на размер приложений в наших мобильных телефонах.
Что то многовато. В те времена, когда турбо паскаль был актуален, любое exe помещалось на дискету. На Delphi, да, можно и больше сделать. Но hello world (без .vcl) тоже на дискету помещался.
Третья версия вообще .com выдавала :-) Который по определению в 64К влезать должен. Да и потом все было скромненько. Что-то не сходится.
Это враньё. У меня не было винчестера на XT, и дисководы были 720 кБ, при этом на турбопаскале я спокойно писал, пользовался его редактором, компилятором, интерактивным хелпом. Hellow World занимал не думаю что больше 10 килобайт, скорее меньше.
И да, памяти было 640 Кб, и все прекрасно работало, летало даже.
2208 байт
Насколько я помню, самые маленькие программы на TP у нас были по нескольку килобайт. Пацаны у меня баловались резидентными программами, так то для них даже 40 килобайт считалось много.
еще бы... в 40кб на Паскале можно 3д-графику с музыкой напихать, даже если не пользоваться EXE-пакерами.
Товарищ выше просто мегабайты с килобайтами перепутал, за давностью лет.
Стандартный носитель информации был 1.44 Мб, кому бы такие ехе нужны были? Их же не запишешь никуда, а ведь еще данные есть.
Программе было доступно максимум 640 килобайт (тех самых, которых всем хватит) и это включая сам бинарник, всё адресуемое пространство ограничивалось одним мегабайтом, поэтому ни о каких мегабайтных ехешниках речи быть не может.
Ну, тут, как раз, есть варианты разные. DOS ориентировался на размер, указанный в заголовке .exe-файла, а не на собственно размер файла. И это можно было творчески использовать. Но борландовские компиляторы к этому не прибегали.
В TP были оверлейные модули, которые можно было по мере надобности в память загружать и выгружать, эдакий прообраз DLL. Так что бинарники теоретически могли быть и больше 640 кб.
Посмотрел доки, освежил память, можно было ручками через COPY склеить .exe и .ovl, и в шестом Турбо Паскале ovelay unit умел из такой конструкции грузить оверлеи. Может, и в более ранних версиях умел. Так что технически сам .exe файл мог быть действительно сильно больше 640 KB.
Это Дельфи с vcl 1.5 метра весил, даже с пустой формой. После turbo pascal и написания всяких резидентников под DOS мой внутренний перфекционист очень сильно негодовал из за размера, поэтому я извращался на kol&mck вместо vcl и получалось вполне годно, но костылей там тоже было много.
Меньше. И там были разделяемые библиотеки, если их не компилить статически, а ставить отдельно то было меньше.
Та ну, такого не было никогда, килобайт десять-двадцать он занимал, если не ошибаюсь. В Delphi пустая форма с такой надписью, в зависимости от версии, занимала килобайт 150-400, и то, если не использовать KOL. На Турбо Паскале я писал графический редактор на компе с 480К ОЗУ, и там хватало места и для DOS, и для Паскаля, и для самого редактора, и ещё чуток оставалось.
Если не изменяет память, то первые версии TP могли генерить com файлы.
Кто-то практически смог заставить какой-то аналог turbo vision for Python выглядеть и работать также как в те времена, в текстовом цветном виде с рамочками, radio button и т.д.
Году в 2000м, товарищ попросил сделать простенькую программу чтобы отслеживать контракты/ордера для своей фирмы на 3 калеки. С помощью Delphi+DevExpress+(dBase?) я за полдня наваял поделку. Чуваку понравилось и он ушел в закат. Я о нем забыл допив выставленное пиво.
Какое же было мое удивление, когда в районе 2020 года мне незнакомый чувак(номер тлф не менялся все это время) с вопросом про то что какая то моя софтина не запускается. Как выыяснилось, это все тот же чувак. Он все эти 20 лет использовал мою поделку в своей фирме(которая так и осталась размером в 3 калеки), использовал как основой рабочий инструмент. А тут пришлось мигрировать на новую винду и все поломалось. Оправившись от удивления, я сказал что не взлетит - сорцов нет. Нифига, сорцы я ему по доброте душевной подарил 20 лет назад.
В общим обновил я ему все и отдал. За тоже символическое пиво.
У меня так учетная программа для сервис-центра работала лет 8 )
И среда разработки поднялась на современной ОС? Я видел программы на Delphi 6 и Visual Basic 6 (еще не .net) несколько лет назад и там обычно развертывание нужной версии IDE да еще с нестандартными плагинами дичайший квест был.
Виртуалку подымал емнип с 7й виндой и там разворачивал.
И среда разработки поднялась на современной ОС?
Delphi 7 я на десятке несколько лет назад ставил, установилась, заработала. По-моему, дефолтные пакеты надо было руками после инсталлятора доустановить, или что-то в этом роде, я уже не помню. Шестая тоже должна установиться, там такой же 32-битный инсталлятор. Более ранние устанавливаться не должны, там инсталлятор 16 бит.
Да вроде как старые исходники вполне можно на современной версии Delphi открыть и пересобрать. Или даже на Lazarus.
А что ей будет-то? Должно всё работать. Начиная с четвёртой делфи поставится и на седьмую винду, а начиная с 2007й и на десятой винде заработает. Но к авторам нестандартных плагинов могут быть вопросы, да.
У меня Delpi 7 под Windows 7 встал без проблем.
Как будет работать на Win 10 - попробую, скажу.
Delphi 7 на Win11 работает без проблем. Как и все даже старые собранные программы
Спасибо, не ожидал такой кучи ответов, конкретно мне это не нужно, я и видел такие проекты последний раз года четыре назад в в совсем другой оранизации и даже там уже над ними не работал, хотя пытались к ним подключить.
Оправившись от удивления, я сказал что не взлетит - сорцов нет. Нифига, сорцы я ему по доброте душевной подарил 20 лет назад.
Просто рождественская история какая-то! Пушистая программистская история.
Microsoft же активно включается и в это соревнование, приобретя Fox Software и его Fox Pro - клон DBase, который он далее много лет развивает.
Микрософт уничтожила Foxpro вполне целенаправленно. И к развалу Борланда приложила руку тоже, судя по "В 1996 фирму Борланд оставляет и Андерс Хейлсберг. Уходит в Microsoft. "...
Файловые БД живут и процветают - посмотрите на тот же sqlite. Прикрутить клиент-сервера к старому подходу тоже было вполне возможно.
Сколько производных проектов и продуктов было уничтожено вместе с Фокспро... Очень жаль...
Главный урок, который я из этого вынес - нельзя полагаться на собственнические продукты, технологии, протоколы. Как раз тогда перешёл на ГНУ/Линукс.
Микрософт уничтожила Foxpro вполне целенаправленно
Туда ему и дорога
И к развалу Борланда приложила руку
Еще и советский геймдев подорвала, переманив Пажитнова!
Сколько производных проектов и продуктов было уничтожено вместе с Фокспро...
А сколько было уничтожено вместе с MS-DOS! Ужас! Негодяйский Микрософт!
А еще майкрософт купила Skype, который был написан на Delphi, и убила его за это.
Total Commander и The Bat! пока мужественно держатся!
Как раз тогда перешёл на ГНУ/Линукс.
Соболезную
Только открытый софт спасает от рабской зависимости от вендора, Microsoft и кучу своих технологий похоронила - те же WinForms или WPF так что тут нет никакой особой зловредности в отношении других фирм, крупные корпорации в равной мере и свое хоронят. Ну про кладбище гугл тоже многие знают.
Только открытый софт спасает от рабской зависимости от вендора
Полностью, конечно, не спасает, но сильно эту зависимость снижает. К сожалению это работает не всегда. Крупные проекты СПО так или иначе находятся либо под контролем либо под сильным влиянием корпораций.
Если корпорация делает то, что надо пользователям, то и нормально, а вот убить или радикально сменить направление уже нельзя, примеров успешных форков много, вроде MariaDB
Согласен, глобально СПО в этом плане здорово изменило расклад даже для крупных проектов. Зависимость от собственника ПО сменилась на зависимость от спонсоров СПО. Что уже весьма неплохо, потому что спонсоров может быть много разных.
Ключевое здесь множественное число. Не понравится один спонсор, можно выбрать другого или самому стать спонсором (в том числе коллективно).
Открытые исходники не столько про бесплатность, сколько про конкуренцию для разработчиков проекта.
Такое антимонопольное законодательство на общественных началах.
Не "мы будем сами дописывать вместо плохого разработчика" а "мы заплатим другому разработчику" хотя в очень крупных компаниях возможен и вариант дописывания.
Не понравится один спонсор, можно выбрать другого
но можно и не найти... увы
Всё это более-менее работает для мелких проектов, но с крупными беда.
А много открытых проектов, у которых основной спонсор делает вот прямо сильно не нравящиеся сообществу вещи?
Я помню не так много обратных случаев, и в них спонсоров меняли вполне успешно - например MariaDB.
А много открытых проектов, у которых основной спонсор делает вот прямо сильно не нравящиеся сообществу вещи?
Кого ты подразумеваешь под сообществом? Разве кто-то кого-то спрашивает, что им нравится, а что нет? Конечно, рядовые пользователи могут жаловаться, но реально повлиять на что-то они не могут, потому что даже если они и дают денег, то немного и нерегулярно. Разработка обычно управляется конкретными людьми, которые принимают решения, что будет, а что нет. В крупных проектах они на зарплате. Вот на их решения и влияют спонсоры. Степень влияния оценить со стороны трудно, ведь договорённости происходят не публично. Но в принципе оценить степень влияния работодателя на наёмного работника несложно, она велика, хоть и не безгранична. Работник теоретически может уволиться и попытаться форкнуть гигантский проект (что почти невозможно в общем случае). Ну или найти другую корпорацию, которая будет продвигать альтернативную линию...
>Кого ты подразумеваешь под сообществом? Разве кто-то кого-то спрашивает, что им нравится, а что нет?
А как это работает в коммерческих продуктах? Ни один разработчик ведь не опрашивает каждого пользователя индивидуально.
Но если компания видит, что чужой продукт не нравится пользователям и видит потребность у пользователей в альтернативном продукте - то она вкладывается в разработку и выпуск такого продукта, в расчете переманить пользователей.
Точно так же если открытым продуктом все недовольны, то разработчик, группа разработчиков или даже целая компания могут вложиться в форк, в расчете переманить пользователей к себе.
Кто именно будет пользователями может различаться - в качестве пользователей могут например выступать и другие компании, которые в случае появления новой команды разработки с форком, лучше удовлетворяющим их потребности, будут спонсировать новую команду и перестанут спонсировать старую.
Разные открытые проекты по разному финансируются - та же википедия (и ее софтовые проекты вроде MediaWiki) за счет пожертвований обычных людей, а не компаний, некоторые за счет продажи своей базы пользователей (в хорошем смысле, ставят за деньги поиск по умолчанию) вроде Firefox, некоторые просто из расчета на внимание и популярность, никому не хочется делать проект, которым никто не будет пользоваться.
Примеры таких успешных форков вполне есть - MariaDB, LibreOffice - вроде и еще есть, но это из тех, что у всех на слуху.
Но, как правило, сама возможность такого развития событий удерживает основную команду разработки от принятия не нравящихся пользователям шагов.
А как это работает в коммерческих продуктах? Ни один разработчик ведь не опрашивает каждого пользователя индивидуально.
Ты здесь противопоставляешь СПО продукт и коммерческий. Но "коммерческий продукт" может быть вполне СПО, здесь нет никакого противоречия. Фирма-разработчик может зарабатывать не на продаже лицензии на приложение, а на каких-то сопутствующих вещах. Например Редхат распространяет дистрибутив с СПО, разрабатывает несколько больших продуктов под лицензией СПО, участвует в разработке разных других СПО-продуктов, как в качестве спонсора, так и в качестве разработчика. Даже Микрософт, как ни странно, тоже за этим замечена. С этой точки зрения разрабатываемые ими продуты СПО вполне себе "коммерческие".
И в принципе, казалось бы, ты прав, фирмы и корпорации должны следить за тем чтобы пользователи оставались довольны и приносили им денюжку. Но всё равно на первом месте в их деятельности стоит получение прибыли, а удовлетворение потребностей пользователей уже на втором, если не на третьем. И это является решающим при принятии каких-то стратегических решений. Соответственно корпорация, разрабатывающая или спонсирующая какой-то продукт СПО принимает решения, которые в первую очередь гарантирует и улучшает её будущую прибыль, закрепляет её положение как "владельца" продукта и это далеко не всегда улучшает продукт для пользователя.
Тут можно привести несколько примеров, их есть у меня. Но я думаю основная мысль и так понятна.
>Ты здесь противопоставляешь СПО продукт и коммерческий. Но "коммерческий продукт" может быть вполне СПО, здесь нет никакого противоречия.
Я не противопоставляю, я ровно наоборот, говорю, что это очень близкие вещи.
Открытые исходники - это в том числе вполне коммерческая разработка, где у автора нет монополии на свой проект. Не понравятся его действия, продолжить развивать проект могут другие люди, которым не надо переизобретать его с нуля.
Такое антимонопольное законодательство на общественных началах, усиливающие конкуренцию.
Механика переключения ровно та же, что и в разработке конкурирующего продукта без открытых исходников - просто она здесь на порядок или даже на пару порядков проще.
>Но всё равно на первом месте в их деятельности стоит получение прибыли, а удовлетворение потребностей пользователей уже на втором, если не на третьем.
При наличии конкуренции для получения прибыли придется удовлетворять пользователей или они уйдут к конкурентам.
Открытые лицензии просто очень сильно облегчают и удешевляют эту конкуренцию.
Не понравятся его действия, продолжить развивать проект могут другие люди, которым не надо переизобретать его с нуля.
Да, но в случае крупных проектов форк могут потянуть на сегодняшний день только корпорации. О чём я и говорю.
Вот прямо только корпорации? Мозилла вроде не самая большая компания, но тянет полноценный браузер, одно из самых сложных классов ПО на данный момент, их в мире сколько всего сталось, три?
Одиночка не потянет крупные проекты, но для них не обязательно нужна прямо огромная корпорация.
Вот прямо только корпорации? Мозилла вроде не самая большая компания, но тянет полноценный браузер, одно из самых сложных классов ПО на данный момент, их в мире сколько всего сталось, три?
Да, форк Мозиллы потянет только очень крупная компания. Никакой фонд СПО или подобная общественная организация на сегодняшний день не потянет разработку форка Мозиллы или аналога.
> Одиночка не потянет крупные проекты, но для них не обязательно нужна прямо огромная корпорация.
Ну может не огромная, но нужна достаточно крупная коммерческая структура. И даже такой пока ни одной не нашлось, хотя они наверное есть. Однако не существует общественного фонда, который бы это потянул. То есть организации, которая бы действовала в общественных интересах и не зависела бы от крупных спонсоров.
>Однако не существует общественного фонда, который бы это потянул.
Mozilla - это некоммерческая организация. Ну если быть занудой, коммерческая компания, принадлежащая некоммерческой организации.
Mozilla - это некоммерческая организация.
И что они форкнули? Мы говорим о форке (Мозиллы). Очевидно Мозилла не форкала Мозиллу. Внимательнее надо быть.
Речь шла о форке. Форк крупного проекта подразумевает что организация, которая этим займётся
1. В обозримые сроки соберёт команду разработчиков, которая в сжатые сроки сможет разобраться с крупным чужим проектом.
2. Сможет финансировать и управлять их работой
3. Не будет корпорацией или крупной компанией.
Со всей ответственностью утверждаю, на сегодняшний день организации СПО, способной на это, в мире не существует.
Большие трудности возникнут даже у корпорации уже на первом этапе. Но у неё уже есть люди, которых она может перекинуть откуда-то, поэтому шансы есть.
если быть занудой, коммерческая компания, принадлежащая некоммерческой организации
А если не быть занудой? Положа руку на сердце, как ты считаешь, ставит ли корпорация Mozilla Corporation (принадлежащая фонду Мозилла и нанимающая разработчиков) на первое место прибыль или интересы общества?
Является ли проект Мозилла независимым от корпораций?
Какая организация СПО по-твоему способна его форкнуть?
Вот прямо только корпорации? Мозилла вроде не самая большая компания
Не Майкрософт, конечно, но тем не менее, несколько сотен сотрудников и несколько сотен миллионов долларов оборота в год.
Да, но и проект по сложности один из самых тяжелых в мире. Подавляющее большинство ПО намного проще. Основной костяк команды Vue например - это 18 человек.
Так или иначе, относительно небольшая компания/команда вполне может справиться, не нужны гиганты вроде Microsoft или Google.
Да, но и проект по сложности один из самых тяжелых в мире.
Я не думаю, что там нужна прям таки огромная команда. В команде Word было около сотни человек включая маркетинг, когда они делали аналогичный по функционалу продукт, и с отображением сложного текста со встроенными объектами, и с каскадными стилями, и с программно-управляемой DOM.
Аналоги Word делает куча компаний, в том числе достаточно небольших. А браузеры - считанные единицы. Word все-таки отображает те документы, которые создают в нем, а браузеру нужна совместимость с самым диким и непредсказумым кодом со всего мира. И кроме собственно доакументов там видео, трехмерная графика, звук и куча всего вплоть до поддержки геймпадов. Но за глубину анализа не поручусь, внутрь не смотрел, так, взгляд извне.
А браузеры - считанные единицы.
Активно развивающихся браузерных движков было десятка два до тех пор, пока на рынке не стал доминировать один. Просто аналоги Word - это продукты для корпоративного рынка, где их можно продавать. А на браузерном движке ты чёрта с два что-то заработаешь, если у тебя нет своей или спонсорской крутой экосистемы, к которой ты можешь его бесплатно приложить.
И кроме собственно доакументов там видео, трехмерная графика, звук и куча всего вплоть до поддержки геймпадов
Ворд тоже так умеет. Просто задачи у него обычно другие.
>Ворд тоже так умеет.
Стало интересно, а что именно он умеет? Можно ли внутри документа Word создать трехмерную игру с аппаратным ускорением графики и поддержкой геймпадов, проигрывание и живую трансляцию видео с современным кодировщиком?
https://www.youtube.com/shorts/9CmTvAk8emE
В принципе, непосредственно слоя трехмерного ускорения в Ворде нет. Но зато есть возможность программирования.
Разработкой Мозиллы занимается именно корпорация https://en.wikipedia.org/wiki/Mozilla_Corporation
Принадлежит некоммерческому фонду, но тем не менее, самая что ни на есть корпоративная коммерческая корпорация :)
Microsoft и кучу своих технологий похоронила - те же WinForms или WPF
Вы о чем? И то и другое полностью поддерживается на сегодняшний день. И даже новые фичи получает.
Давайте я задам вам простой вопрос - почему 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 лет, не смотря на массу проблем.
не на WPF ни на одной своей десктопной технологии, а вообще на Electron со всеми его известными недостатками?
Они не кроссплатформенные. Как один единственный продукт может говорить о живости или неживости других технологий?
То что в WinForms и WPF правятся какие-то мелочи это не поддержка, это в лучшем случае
Чего вам нехватает?
Пример того как WPF должен был поддерживаться - это Avalonia,
Только подавляющее большинство того что вы подразумеваете под "поддержкой" это портирование фич из WPF. Даже возможность перехвата необработанных исключений добавили буквально пару месяцев назад.
>Они не кроссплатформенные.
Так про это и речь. В живые технологии, развиваемые и поддерживаемые, добавляют поддержку новых платформ.
В том числе от Microsoft - у них есть живые аналогичные продукты, например MAUI.
>Как один единственный продукт может говорить о живости или неживости других технологий
Ну так давайте посмотрим но другие современные продукты - например Teams они давно даже у Microsoft кроссплатформенные.
Teams тоже на Electron и React вроде как планировали на React Native перейти.
>Только подавляющее большинство того что вы подразумеваете под "поддержкой" это портирование фич из WPF
Учитывая, что это крохотная независимая компания из пары десятков человек, которым пришлось написать аналог WPF с нуля, это не удивительно.
Так про это и речь. В живые технологии, развиваемые и поддерживаемые, добавляют поддержку новых платформ.
Вы смешиваете в кучу развитие и поддержку. Мертвая технология очевидно не получает ни того ни другого. В данном случае это очевидно не так. WinApi тоже не особо то меняется с годами. И, внезапно, туда не добавляют поддержку новых платформ. Мертво? Тогда попробуйте сделать приложение которое его не использует (в том числе косвенно).
Куча энтерпрайза сидит на винформах и впфе и еще десятилетиями будут сидеть, им не нужны ни линукс ни какие то еще революционные нововведения. Вот это показатель живости технологии, а не ежемесячное добавление глючащих свистоперделок.
ни давно даже у Microsoft кроссплатформенные.
Судя по отсутствию ответа на вопрос чего нехватает тому же WPF, и приведенные примеры фреймворков которые функционально в лучшем случае можно назвать вяло догоняющими, я правильно понял что кроссплатформенность это единственный ваш критерий живости/мертвости технологии?
А яблочный SwiftUI или что там у них тогда тоже мертвый? Там же нет фичи сделать гуй под виндовс
В том числе от Microsoft - у них есть живые аналогичные продукты, например MAUI.
Так там линукс не поддерживается, по вашей логике значит он тоже мертв.
>Судя по отсутствию ответа на вопрос чего нехватает тому же WPF
Вы явно уже забыли, с чего весь разговор начался, потому что я в еще начале привел две статьи как раз о проблемах WPF, у них там еще и в комментариях накидали много чего. Давайте я вам приведу это еще раз - о проблемах с производительностью, далее о проблемах внутри самого WPF включая комментарии, например вот этот.
Впрочем может в расскажете, что нового было в WPF за последние лет пять? Что там менялось и как, насколько значимы были эти изменения? Можно статьей.
Вот например список изменений в живой технологии от Microsoft - MAUI, всего лишь за год.
Давайте сравним с WPF?
>А яблочный SwiftUI или что там у них тогда тоже мертвый?
Вообще не слежу за ним. Развивается ли он и как активно развивается не знаю. Вроде он кроме десктопов поддерживает и яблочные планшеты и мобилки как минимум?
>Куча энтерпрайза сидит на винформах и впфе и еще десятилетиями будут сидеть, им не нужны ни линукс ни какие то еще революционные нововведения.
Есть какие-то подтверждающие это цифры? Как мне казалось, типичные новые приложения в энтерпрайзе уже лет 15 как почти исключительно на вебе разрабатываются, благо сам в энтерпрайзе варюсь. Типичное корпоративное приложение - это не фотошоп с автокадом, ему веба вполне хватает, тем более современного и оффлайн режим как правило не нужен. Что-то старое на что денег нет на переработку может и висеть хоть на Винформах, но например у Авалонии вполне себе активно покупают их продукт по портированию WPF приложений на Мак - значит спрос есть.
Так то в энтерпрайзе и на Коболе куча приложений работает по сей день, вы же не будете его живым называть?
Так это же у них стратегическое решение: не создавать публично доступные графические тулкиты под конкурирующие платформы, потому что это может нести риск для самой платформы Windows.
>не создавать публично доступные графические тулкиты под конкурирующие платформы
Уже нет, разве что Linux до сих пор в немилости, как исключение. А так они давно пытаются делать такие тулкиты, просто они вместо развития старых технологий, делают новый.
Я уже не слежу особо, мне без поддержки Linux не интересно, но последнее вроде MAUI.
Потому что начинали делать его не они, а Github (еще до покупки мелкомягкими) со своим Atom. А когда Atom взлетел, MS его форкнули и частично переписали.
Я не думаю, что они там форкали что-то из самого Атома. Да и не могу сказать, что Атом "взлетел", слово "летать" ему было не знакомо, из всех текстовых редакторов это был единственный, который у меня отображал буквы медленнее, чем я их набираю. По-моему, его не любил никто :)
Но Электрон, как фреймфорк, писался как раз под Атом, и назывался на момент создания VS Code еще Atom Shell. Вот этот фреймворк и объединял оба продукта, больше ничего.
"из всех текстовых редакторов это был единственный, который у меня отображал буквы медленнее, чем я их набираю"
Еще ФоксПро так умел. Что досовский, что визуальный под виндоус.
Слушайте, так может это у Микрософта просто такой, понимаете, кИрасивый нацИональный обычай? Чтоб текст в среде отображался медленнее, чем программист его набирает?
просто некоторые печатают быстрее, чем думают. даже анекдот такой есть =)
Слушайте, так может это у Микрософта просто такой, понимаете, кИрасивый нацИональный обычай?
Я бы поддержал, но на Фоксе работать не довелось, а Атом был у меня еще гитхабовский и на убунте. Я, наоборот, был приятно удивлен, когда перешел на VS Code. Не знаю, что там они сделали с Электроном, но оно было, и, наверное, остается единственным хорошо работающим приложением на нем.
Ну, Гейтс с Каном друг друга оценивали достаточно адекватно, сильно не любили, но очень уважали. Так что развалить конкурента, тем более такого - очень даже правильный ход, ничего личного, просто бизнес.
Спасибо за статью, писал когда то в турбо паскале - ничего уже не вспомню толком, на задворках памяти осталось что индекс массивов в нем начинался с 1.
Из тех же времен: встретил как то на проекте сына (в годах уже) основателя Novell Netware - он рассказал как Билл Гейтс был у них в гостях, а я вспомнил как в 90е изучал немного netware. Сик транзит глория мунди...
индекс массивов в нем начинался с 1
Нет, индекс массивов в нём может начинаться с 1. Но не обязан.
С 95 года не касался Паскаля (визуализация расчетов была на нем в дипломе) - помню что по умолчанию была 1 и меня это "заедало" так как до него начинал на С и впоследствии, 1 по умолчанию нигде не встречал. Делфи прошел мимо меня - следующим языком была Java, и в целом, сишный синтаксис привычнее. Но на Паскале нормальные игрушки делали и обманку Нортона, студентами, неплохой язык, меньше ошибок чем в С у начинающих
да нет там никакого умолчания. Массивы также как и везде. С "1" начинается индекс символа в типе string, к которому вы как к массиву можете обратится , потому что первый байт (с индексом "0") это длина строки.
Может память подводит, глянул спеку (пардон не все открывается без впн а я на мобиле)
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 как то пришлось работать на одном проекте а там большей части привычных функций не оказалось к сожалению которым привык
В паскале границы массива можно указать при обьявлении. А в Delphi вроде как кроме паскалевских коротких строк есть и 0-terminated.
Скажу вам, как старый пасквилянт старому сишнику )
Теоретически, можно было объявить тип массива с индексом от нуля до нужного вам значения. Что-то типа такого
Type
TIndex0_9 = 0..9;
TArray0_9Integer = Array[TIndex0_9] of Integer;
var MyArray: TArray0_9Integer;
Можно проще - TSomeArray = array[0..9] of SomeType;
А если приспичит, то и array['A'..'Z'] of SomeType.
Проще
var SomeArray := [1, 2, 3];
или
var SomeArray: TArray<TSomeType>;Давно использую только динамические массивы
Я имел в виду TurboPascal, а также Delphi по 7ю версию включительно. Что там дальше с типами нагромоздили - уже не отслеживал. Ну, развивается - и хорошо... кому-то.
Динамические массивы - они слегка в другую сторону. Статические с индексацией не целыми числами из моего второго примера в давние времена сходили за жалкое подобие словарей и были временами полезны - для таблиц подстановки и т.п.
Нет, в массивах вообще не было никакого умолчания. Индекс первого элемента всегда надо было указывать явно в определении типа или переменной.
var
a: array[3..5] of char;
Потом появились открытые массивы и динамические массивы, в которых начальный индекс фиксирован, и это 0.
Вот в строках индекс первого элемента всегда был 1, до недавнего времени.
Зато там есть case по диапазону, а в сишном switch такого нет.
Case по диапазону много где нет, фича хорошая, соглашусь. В java. недавно case для строк прикрутили, своеобразно, вроде через хеш, то есть патч. Паскаль вполне нормальный легкий для вхождения язык, писал на нем игрушки, имитатор Нортона, редактор спрайтов, визуализацию оптимизации градиентного спуска в дипломе (вычислял на Фортране) - вопросов нет. Вот что мне сломало мозг, так это visual basic script, на серверной части один раз пришлось патчить - не зашло на 140%, измучился с ним. Примерно дюжину языков пробовал, даже Бейсик нормально, но этот кракозябр крови мне попил. Workplace for IBM Image Services, в нем он сидел.
Помимо крутой статьи в целом, удивлен упоминанием Eureka.
Была у нас на лабах в универе, хотя параллельно с ней был и матлаб, но было удивительно видеть символьные вычисления, решение уравнений и построение графиков (т.е. по сути всё чем мы пользовались из матлаба) в досовской программе с интерфейсом турбо-бейсика.
А я вернулся к старой двухзвенке и она на новой delphi очень даже неплоха в корпоративной сети с SQL Server и даже с SQLite через FireDac драйвер.
Практически мгновенная компиляция, остутствие тормозов даже при работе через VPN выгодно отличает связку DElphi+SQLserver+хранимые процедуры от PHP, программы которой даже не запускаются на старых компах под Win10.
Насколько я помню, FireDac платный. Что-то изменилось?
А серверную часть в таком варианте можно под любую ОС собрать? Или?
Еще вопрос - а для чего и почему используете хранимые процедуры?
Их же отлаживать и менять на порядок сложнее, чем алгоритм на Паскале?
Или вам так критична скорость? Или просто вам нравится писать это на SQL?
Конечно важна скорость. Хранимые процедуры работают на порядок быстрее, без перегонки тонны данных
Логику в хранимых процедурах применяю потому что проще разрабатывать приложения баз данных, чем использовать одни запросы, особенно если нужна сложная обработка данных и даже не только это, а то что код запросов не хранится на клиенте и я использую триггеры БД для хранения всех корректировок схемы и таблиц БД, пользователей, хранимок, короче всего DML. Приложения у меня сложные и я применяю не только хранимки, но и функции, синонимы и системные иногда объекты SQL Server. Насчет что писать сложнее на SQL чем на обычном языке - это не так. Просто SQL это немного другой подход в программировании, тут требуется хорошее знание SQL и умение оптимизировать SQL код и еще много чего архитектурного в создании приложений БД. Сейчас я заканчиваю портирование одного своего приложения на SQLite. Там нет хранимок и я ощутил насколько неудобно и сложно разрабатывать в локальной БД приложение со сложной логикой без хранимок. Где все делает одна хранимая процедура, с запросами иногда приходится городить огород из последовательных наборов запросов и усложнять код на клиенте. Использование CTE не всегда выручает, но помогает. В общем объединение двух БД, серверной и локальной получилось, но проблем с локальной БД SQLite и ее запросами было много. Там где работает простой код запроса хранимки SQLserver, перенос запроса в SQLite иногда не работает и приходится его оптимизировать, меняя много чего в коде. Думал что это будет быстро сделано, так как рельсы уже были, но паровоз пришлость строить заново.
Помню где-то в 2002-2004 перешел на Borland C++ Builder. Это вам не турбо паскаль!
Если надо было менять заголовочные файлы - все, работа вставала. Приходилось днем наугад что-то писать и на ночь запускать компиляцию.
Наша компания обращалась в поддержку Борланда, рассказала о проблеме. Типа, вот проект, компиляция занимает 6 часов.
Они такие: что, правда 6 часов? Не может быть!
Мы: ну да, вот пруф.
Они: Серьезно? И оно у вас успешно скомпилилось? И не упало??
Ух, ностальгия. Я начинал осваивать программирование в 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 то всё ещё довольно активно развивается.
Считаю несправедливым, что нигде (даже в комментариях) не упомянут Lazarus — свободный кроссплатформенный аналог Delphi с классическим UI. Иногда пользуюсь, чтобы набросать что-нибудь быстро для личных нужд.
Хорошая ретроспектива. Главный урок Борланда - продуктовый гений не спасает от управленческого расползания
Borland JBuilder забыли
Написан был на Java, в конце 90-х еще вроде
Основная среда для разработки на Java какое-то время, если не ошибаюсь
Точно, был такой. Но, кажется, всего одна или две версии вышли?
У меня друг потом искал его, найти не мог, плакался.
Когда поняли что JBuilder не может конкурировать с Eclipse, сделали JBuilder 2007 основанный на Eclipse. У нас в Питере была команда участвовавшая в разработке, и я в ней работал какое-то время. Помню делали функциональность позволяющую генерировать код по темплейтам, это должна была быть киллер-фича сильно ускоряющая разработку.
И вот никто не вспомнил - а ведь для Delphi существует просто шикарный DeveloperExpress, это целый отдельный мир, который просто нечем заменить. Поэтому стоит не очень приятно. Но он того стоит. Писать приложения для БД на нём это сказка, тот же TreeView - который позволяет строить иерархическое дерево записей автоматически по нужным индексам, при это все методы фильтрации, сортировки, фиксированных столбцов и прочая... прочая...
И вот никто не вспомнил - а ведь для Delphi существует просто шикарный DeveloperExpress
Я прямо сейчас его использую. Он уже много-много лет существует не для Delphi, а для всего - и под WinForms, и под WPF, и под ASP.NET, и под React. Двоякие впечатления, если честно. С одной стороны, да, настолько навороченных элементов управления не найдёшь. С другой стороны, там за несколько десятилетий их существования наворочено куча легаси-слоёв, куча избыточности, и хотя сложные вещи там делаются проще, но простые - наоборот, намного сложнее.
Плюсую, это оооооочень огромная куча классов, где внутри всё настолько архи-сложно, что начинаешь думать "я просто хотел табличку", а не табличищу, умеющую строить звездолет и улетать в космос (навеяно старым мемом, что в один момент разработчики программы Nero Burning Rom сначала добавили в программу видео редактор, потом написали свою ОС, построили звездолет и улетели в космос)
Это да, поэтому под свои цели работы с DevExpress я давным давно написал набор прокладок, чтобы все основные типовые действия вызывать быстро и легко. Наверное надо было выложить на гитхаб, но как-то не сложилось.
Он есть, и не только для Delphi. Для .Net и C# он тоже есть.
И знаете, что самое приятное? Что и для Delphi, и для C# элементы управления в DEEditors устроены почти одинаково, во всех есть свойство Value, например, содержащее редактируемое значение.
Хорошие компоненты, только дорогие и тяжелые.
DevExpress хорош, но до гибкости HTML не дотягивает.
Fmx даёт гибкость html
Согласен. Но - я не встречал решений на html, которые просто повторили бы devepress. А сам devexpress можно всегда по желанию доработать, он продаётся с исходниками, бери и переделывай.
Я тоже не встречал, хотя, по идее, это всё и на html реализовать можно. Вероятно, какая-то специфика платформы web, что на HTML всякие навороченные таблички не нужны. А может потому, что dx коммерческий и проработан весьма глубоко.
По поводу доработки - встречал какие-то вещи, которые не кастомизировались в рамках dx, но не помню уже. Динамическая генерация GUI что ли?..
Да, просто потому что хороший сложный интерфейс в веб не делают - основной упор на телефоны, а там кроме 3-5 строчек всё равно ничего не видно. Смысла нет стараться.
И по инерции и там где могут - тоже делают попроще. И это печально.
А вот что не кастомизировалось даже не знаю, там ведь исходники в комплекте идут. И можно сделать что угодно, я пару раз кое-что правил для своих целей, приходилось накладывать патч при обновлениях.
Еще пропущена веха про 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.
Turbo 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 уже существовали.
В районе 2016 года из команды Delphi (уже не помню какая фирма ей владела в тот момент, скорее всего уже Embarcadero/IDERA) ушел разработчик компилятора Delphi - Allen Bauer
Cсылка на сообщение об этом:
http://blog.therealoracleatdelphi.com/2016/02/a-new-adventure.html
Все пишут, мол Delphi уже отжил свое. Но на чем тогда создавать GUI под Винду в 2025 году? С# как на уровне самого .NET так и на уровне GUI-фреймворков под винду штормит так, что страшно делается.
Вы посмотрите сравнительную табличку в этой статье, это ж неадекватно:
Пишите на Qt. Заодно будет возможность портировать программу на Linux и Mac.
Или на Avalonia, если .NET. Оно тоже кросс-платформенное и уже достаточно стабильное.
Delphi сейчас пробует кросс платформу, причем уже довольно давно. Но там столько всяких "если", что это уже отдельная история. В линуксе к паскальному коду проще Лазарус прикрутить без всякой кросс платформы. Визуальщина правда будет уже на других, лазарусовских, компонентах.
Delphi давно позволяет создавать кроссплатформенные приложения. При чем один и тот же проект может быть собран сразу под все платформы (win, lin, mac, ios, android). И позволяет даже одни и те же формы параллельно адаптировать под разные экраны. При этом будет полноценная поддержка любого dpi на всех устройствах, т.к. рендер ui не зависит по сути от api и поддерживает работу на direct2d, directx, opengl, skia, opengles, cairo, gdi+ и и.д. На всех платформах доступен и 2d и 3d контекст.
Ну и собирать приложения под все платформы можно на одной машине.
Звучит здОрово.
Может, наберусь смелости сам попробовать.
А какие у него системные требования к установке? Под Windows 7 можно?
А вот чуть выше - https://habr.com/ru/articles/949956/comments/#comment_28877930 - пишут, что кроссплатформенность с оговорками.
Может, расскажете чуть подробнее об этих оговорках?
Вот мне хотелось бы собрать, допустим, приложение под Windows (допустим, серверная часть и клиентская), и плюс два легких клиента под смартфоны - Android и IOS.
Насколько это окажется сложно?
Единственная оговорка - это то, что под Линукс создание 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
аналог дельфи это банальный винформс
Вообще-то нет.
Мяуи это декларативная разработка на xaml, более продвинутая, но и более тормозная.
fmx же это просто кроссплатформенная vcl со стилями
Это не кроссплатформенная vcl со стилями. Это сильное заблуждение.
FMX - это html+css подобный подход с дизайнером как самой формы, так и стилей элементов. Это возможность создавать как растровые стили элементов, так и векторные. Это возможность использовать возможности GPU для рендеринга, в том числе шейдеры.
Vcl так же близок к FMX как Winforms к Avalonia.
Я специально пролистал учебник по Файрманки, никакой декларативной разработки интерфейса там нет.
Я и не говорил о декларативной разработке UI, я говорил о подходе. При котором есть Модель (класс контрола), а есть его Представление (стиль).
Стиль в FMX гораздо сложнее, чем просто шкурка. Стили в FMX - это как классы CSS, только которые ты не кодом описываешь, а визуально. Любой контрол может использовать любой стиль. И каждый контрол может использовать отдельный стиль.
"есть Модель (класс контрола), а есть его Представление (стиль)"
Это откуда вы такие термины взяли для данного случая?
Модель и Представление - это о данных, с которыми работает программа.
А класс контрола - это, извините, никак не модель. Это служебный класс, используемый в элементах представления.
Простите, но вы сильно путаетесь в терминологии. Либо исповедуете идеи какой-то экзотической школы.
В FMX класс контрола - это Модель. Потому что по сути, класс контрола хранит лишь данные и не говорит о том, как он должен отображаться. Не говоря уже о том, что класс контрола может быть основан на TPresentableControl, который позволяет переключать презентационный класс. Например, есть класс TMemo, который основан на TPresentableControl, что позволяет отображать в окне как обычный контрол FMX, так и нативный для платформы контрол у которого будет свой собственный реальный Handle. А сам TMemo - это лишь контейнер для данных.
Внезапно, декларативная разработка UI, и есть подход, точнее целая методика разработки.
Ни Delphi, ни Lazarus или Free Pascal там, конечно, не вспоминают.
... И Борланд, Парадоксов друг.
Больше всего интересно, как нелегал стал директором. Что, прям вот пришел к властям, сказал «Я тут становлюсь директором мега крутой конторы, Дельфи замутим, в будущем, простите засранца и дайте грин-карту.», а те такие: «Нураз так, то тогда ладно. Держи.»?
И Борланд, Парадоксов друг.
Запах старой Компьютерры
Ну, если у тебя есть работа (с тобой готовы заключить контракт) - значит, ты имеешь право тут жить и работать, как я понимаю. Соответственно, тебе выдадут как минимум рабочую визу. А прожив по ней энное время, уже не так сложно получить и постоянную - если ты тут уже прожил два года, ни разу не буянил, не попадал в полицию, тебя не ловили с наркотиками и т.п, И имеешь работу, причем не разнорабочего, а компьютерщика...
Так до сих пор если нужно набросать небольшую программу которая будет содержать только exe файл выбора то особо и нет, Delphi или Lazarus.
Если прям совсем простую, то да. Но это как из пушки по воробьям.
Но современный интерфейс проще не будет, чем qt/material. А то может и сложнее выйдет, когда выяснится, что половина (если не все) визуальных компонентов нужный функционал не поддерживают. Плюс паскаль все таки специфичная штука.
По факту удел делфи это больше энтерпрайзный легаси.
Это вы говорите о старых версиях среды и о базовом Виндовом фреймворке - VCL. Однако, уже давно существует кроссплатформенный GUI фреймворк (FMX), сильно отличающийся от VCL. Которому почти никогда не требуется наличие сторонних компонентов для реализации 90% всех запросов. И речь о современных запросах. Не требуются не только сторонние компоненты, но и даже написание вручную не требуется, потому что используется механизм на подобие HTML+CSS, но в то же время не имеющий ничего общего с вебом.
Ну и про легаси. Легаси проекты не будут работать на современных версиях Делфи. Так что, либо переписываешь проект, либо пишешь на старых версиях. Однако, свежие версии используют в большинстве случаев.
Коцептуально это тот же qt/material и тут у делфи уже нет такого преимущества, которое было тогда, когда в тренде были статические формы.
Преимущество есть. Если в qt ты всё так же кодом, используя qss, настраиваешь отображение представления, то в Delphi для настройки представления (не контрола, а его представления) есть отдельный дизайнер.
И помимо этого, подход со стилями позволяет иметь в стиле другой контрол. Т.е., если тебе потребуется кнопка в кнопке (как на скрине), то я добавляю в стиль контрол кнопки и тоже задаю ему стиль. После этого, все контролы кнопок (которые используют этот стиль) на форме будут иметь вид кнопки с кнопкой внутри и позволят получать доступ к ней.
Мой легаси переполз с 7 на Токио. Правда там примитив.
У нас как раз энтерпрайз на VCL. Под последней версией Delphi, но это всё равно легаси по своей сути, т.к. VCL, Windows messages, Windows Threads (+OmniThreadLibrary, которая опять же прибита к Windows Threads) + JEDI + много всяких визуальных компонентов, для которых, конечно же, ни в каком FMX простых аналогов не найдется.
А в чём проблема использовать C/C++, а стандартную библиотеку слинковать статически? Да и Go изначально таким же был, не знаю, как сейчас.
Хотя лично я никогда не понимал, в чём прелесть ограничения себя одним exe-файлом. Ну пусть рядом пара dll лежит, это же не проблема. Вообще, в плане простоты и переносимости, я в последнее время пришёл к python для этих задач. Пара простых действий (venv, pip, python), и всё работает на любой платформе, от сервера до embedded linux.
Попробуйте как-нибудь провести "пару простых действий" без интернета. Вот совсем-совсем. И без доступных во внутренней сетке зеркал. Приходите к серверу или даже рабочей станции с воздушным зазором, вставляете flash, и накатываете...
Без интернета, очевидно, это так не заработает. Но я не агитирую за питон на все случаи жизни, я просто поделился своим конкретным опытом, что даже на embedded linux платформах (я не говорю про остальной парк пк и серверов на разных ОС) для меня именно такая конфигурация стала самой простой и универсальной.
Если вам необходимо работать в подобных задачах оффлайн, понимаю, что скомпилированная программа с зависимостями может быть проще. Думаю, есть способ сделать такой трюк и с питоном, но это не лежит на поверхности, я так не делал. Однако, по-прежнему не понимаю, чем пачка dll (если мы говорим про Windows) мешает по сравнению со статически слинкованным exe. У меня был ряд внутренних рабочих программ, которые нужно было так использовать, никаких сложностей не возникало.
Соглашусь - в "суровом энтерпрайзе" именно так и бывает - сначала сервер в "учебной" среде настраивается до рабочей конфигурации, потом проводится его аудит (УИБом ли, вендором ли - не суть), и он переезжает в изолированную среду, а если вдруг надо что-то обновить, то привет wsusoffline и прочие хождения с внешним накопителем в ЦОД (хорошо, если на той же территории, где работаешь)... плюс ещё программно-аппаратные ревизоры типа Соболя или иного зверя, которые изрядно недолюбливают любые изменения в "охраняемом периметре"...
wxWidgets со статической линковкой, вроде бы он еще жив
достаточно csc под net 4.5
Кстати да, если тебя не устраивает писать на С/С++, то альтернатив то нет. Сам сейчас пишу плагины на Delphi, версию под x86 компилирую в семёрке, а x64 в лазарусе, по весу 80КБ и 150КБ получаю, бинарники самодостаточны и будут железно работать абсолютно у всех.
Турбопаскаль как то нме не зашёл, а вот Delphy начиная с середины девяностых я долго юзал!
Очень мне нравилась её объектная модель и революционный по тем временам интерфейс.
В истории dBase->Visual Fox Pro как-то Clipper упущен, был достаточно популярен
dBase - FoxPro - Clipper, но круче всех был Clarion под Dos. Ну и потом и под Windows
Ну, я ж писал пост не про базы данных на файлах DBF, а про средства разработки программ с использованием баз данных.
И под базами данных я подразумеваю в основном клиент-серверные СУБД на основе SQL, а не файловые СУБД. Файловые СУБД типа dBase, FoxBase, Clipper, да и Paradox - это ограниченный вариант, где, скажем, принципиально отсутствуют триггеры и хранимые процедуры (за исключением случаев, когда сама среда реализует работу триггеров - как, возможно, делала FoxPro - не знаете, она это умела?), как правило, отсутствует ссылочная целостность (говорят, в Фоксе она была как-то реализована, не знаю, правда ли, но в 1С ее нет до сих пор, хотя 1С был сделан на фоксовском движке CodeBase), и не факт, что есть SQL. Как правило, отсутствуют транзакции.
Большинство моих знакомых разработчиков, работавших на этих системах, вообще не имели понятия о том, что такое транзакции и ссылочная целостность, некоторые путали понятия таблицы и базы данных.
Поэтому да, о файловых СУБД я упоминаю минимально. Скорее я бы развернул тему сравнения Oracle, MS SQL Server и InterBase/FireBird, там для меня больше интересных вещей.
Ну и потом, я ж не работал на Клиппере или Фоксе, так что ж я о них писать буду? Пусть о них напишут те, кто на них работал. Я сам Фокс только немного потрогал, а писал на Delphi и C#, ну и на SQL, конечно, вот об этом могу рассуждать более-менее адекватно.
Был сильно удивлен, когда узнал, что PLSQL Developer написан на Дельфи. Оракл разрабам привет )))
Borland "профукал" несколько не таким способом. Точнее, на некоторых аспектах в статье не заострено особого внимания. А зря.
Так вот... в одной далёкой галактике одна компания на букву 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...
Возможно влияет еще и то, что сейчас всю разработку забрал себе очень крупный энтерпрайз (Яндексы и Гуглы) и они делают либо на самых популярных технологиях (на которые легко находить разрабов), либо просто как им удобно, часто на самодельных внутренних инструментах. Т.е. если бы в каждой фирме требовалось писать свои мини программы и утилиты, может Delphi и был бы вполне жив, т.к. он прост и удобен. Но все сейчас хотят готового, коробочного или облачного от крупных вендоров, а крупные вендоры выбирают технологии исходя из "найдем ли мы быстро 10 тыщ разрабов, умеющих делать это". И одно тянет за собой другое, Delphi теряет комьюнити и популярность. Хотя я бы и C# не назвал супер популярным и все эти 100500 версий .Net фреймворка, которые надо доустанавливать в систему вместо того, чтобы просто был один EXE-шник, который "just works", не добавляет радости в "быстрой разработке .Net приложений". Деплоймент в дотнете отвратительный, имхо. Особенно когда надо приложение раздать на неск тыщ юзеров, у каждого из которых разные версии винды, не всегда есть права устанавливать нужные версии .net , разные версии приложений требуют разных версий .Net и т.д. и т.п. Если на это еще наложить 32/64 битность + зависимости из DLL. Такая каша.
Зачем? Во времена XP надо было накатить 4-й NET и выкатывать приложения через ClickOnce. У меня даже враппер был, который позволял получить и установить обновление в удобное мне время прямо во время работы (на терминалах оплаты это было особенно актуально). Вся головная боль по поводу перезаписи приложения в момент его работы, отсутствие админ доступа, всё вот это решалось в ClickOnce.
А разницы 32/64 тоже не ощущалось, если только не требовалось работы с какой-то древней либой 32 бит. Компиляция AnyCPU делала своё дело.
Ещё была Powersoft/Sybase Optima++
Мне больше нравилась чем Сибилдер, чистый С++ без расширения, без БДЕ
Ведь, это удивительно. Была бы бесплатная версия с набором базовых компонентов, и с платными наборами специализированных компонентов для коммерческой разработки... Базовых компонентов могло бы хватить на большинство ситуаций. Плюс прозрачная модель разработки ПО и компонентов. Зато была бы широкая распространённость. Можно было бы рискнуть замахнуться на некий индустриальный стандарт.
Ну, современный Delphi (RAD Studio) имеет некоммерческую версию (да, с рядом ограничений, которые парой веток назад уже достаточно подробно расписали)... но есть и Lazarus, и прочие "значительно более дешёвые" варианты...
Ну, современный Delphi (RAD Studio) имеет некоммерческую версию
Проблема в том, что она совсем вообще некоммерческая. На VS Code или там VS 2022 Community вы можете писать софт с какой угодно лицензией. А лицензия некоммерческой Delphi, по сути, разрешает ее использование только если вы вообще не пишете софт за деньги.
Выглядит как дикая дичь. Связываться с компилятором, который вставляет свои ватермарки.. Просто зачем? Зачем брать на себя дополнительные обязательства, если ты не партнер embracadero? Вот одна из причин, почему при всем удобстве новых Delphi туда особо не бегут. Можно просто писать на плюсах и ни в чем не быть никому обязанным.
Хуже. Использовать легально бесплатную дельфи можно если ты бомж. Доход (любой, не только от программирования на Д) менее 5К $ в год
Мы изучали Delphi ещё в 2013-14 когда очевидно он был мертв как и сама среда разработки Borland
А что мешает сейчас взять Delphi и делать приложения на нём? Наверняка сейчас находятся те, кто до сих пор используют Delphi. Что не хватает лично Вам?
Что не хватает лично Вам?
Интересных проектов либо хорошо оплачиваемой работы над неинтересными проектами.
То есть, непонятно, зачем брать Delphi, когда есть хаскель для не сильно требовательных к близости к железу проектов, rust — для требовательных, плюсы — для хорошо оплачиваемого легаси, и какой-нибудь идрис с агдой — для души.
что-то я не встречал вакансий и проектов delphi
Есть вакансии, не переживай. А проекты, например, Сбербанк сравнительно недавно выпустил кроссплатформенное приложение СберПро на Delphi + FMX
Даже я в ходе своих собственных поисков встретил по крайней мере одну такую вакансию.
А ещё мне интересно, используют ли Delphi|/C++ Builder в компании Компас. Помнится, я где-то в начале нулевых прослышал про эту компанию, и с тем, что они делали некий аналог конфигуратора 1C. Там был редактор форм и библиотеки для генерации пользовательского интерфейса налету. Что у них сейчас, и как?
Насколько я помню, Turbo Prolog - это не продукт Борланда. Его создал другой датчанин, Лео Шоу-Йенсен, я у него работал
Можно многое и довольно верно рассуждать о роли личности (в истории), говорить о тактических и стратегических просчётах, вспоминать про конкурентов (кто проспал, а кто бдил и победил). Но я хочу указать на следующие три системных дефекта.
Во-первых, сама по себе идея писать обработчики разного рода событий, вроде бы и хороша, но её постоянное использование иссушает мозги. Когда мы пишем программу в процедурном стиле, то мы излагаем последовательную логику решения той или иной задачи. Написание обработчиков лежит поперёк этой логики. Да, писать обработчики, вроде бы, и можно, но как это делать правильно? В этом смысле, некоторые современные технологии (вроде 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. Как выглядел бы сам язык программирования? Как выглядел бы процесс разработки? Можно было попробовать заглянуть в эту альтернативную реальность. Но для этого потребуется много экспериментировать. Лично мне было бы интересно туда заглянуть...
Вот честно, прочитав все это в голове засветился баннер "плохому танцору..."
Мне ничто не мешает в данный момент писать на Delphi 7 современную информационную систему с современным же веб интерфейсом в виде isapi расширения под IIS. И за 20+ лет разработки могу сказать что Delphi прекрасен. При этом работал и на Java и на Net Core разрабатывая всякое большое и сложное. Delphi точно так же может все что нужно, а Java/C# ничем особенным не зацепили.
Лично вам никто не мешает, но насколько легко ее будет развивать и поддерживать другим людям, насколько легко работодателю будет найти таких людей? Это еще не говоря о том, что она будет гвоздями прибита к Windows и IIS.
Можно и FCGI-модули для Nginx делать, с помощью вот этой REST-библиотеки.
Странные вопросы.
В чем развитие и поддержка будет отличаться от чего-либо написанного на другом языке? Java или C# сразу что ли наделяют разраба скилами написания идеального кода? Нет. Бардак есть везде. Зависит от разработчиков и организации процессов. В моем случае все ключевые моменты давно допилены напильником, а грабли найдены и обезврежены. Расширять функционал по образу и подобию не сложно. Максимум можно с веб-частью заморочиться.
Сейчас найти толковых спецов в принципе проблема по любому стэку. Все толковые сидят при деле. Рынок же наполнен вкатунами алчущими бабла. Так что и тут отличий нет. Хотя будет даже проще, т.к. не придется рыться в сортах вкатунов, ведь их на текущий момент не учат Delphi :)
Что такого в Windows? Это что ли какая то редкость? Нет. К тому же IIS есть абсолютно в любой редакции форточек. Так что проблема опять надумана. Зато в случае IIS есть плюс - производительность, т.к. сайт представляет собой по сути часть IIS и потому работает шустрее других вариантов.
В чем развитие и поддержка будет отличаться от чего-либо написанного на другом языке? Java или C# сразу что ли наделяют разраба скилами написания идеального кода? Нет. Бардак есть везде
Не в этом дело. Если у вас софтинка написана на C# или там JavaScript, вы можете пойти на рынок труда и найти там разработчика. Или взять кого-то из существующей команды. Но чёрта с два вы найдете нормального миддла-дельфиста на рынке труда в 2025-м году. Они где-то в каком-то месте существуют, но их немного, и без работы они обычно не сидят. Для остальных языков рынок труда как раз живой, и на проект вы себе всегда кого-то найдете.
Что такого в Windows? Это что ли какая то редкость? Нет. К тому же IIS есть абсолютно в любой редакции форточек.
В качестве веб-сервера, да, редкость. Если ваше приложение пишется под конкретную контору, то это не проблема. Если вы планируете его распространять, то это уже проблема, ваши потенциальные клиенты с 99% вероятностью захотят хостить на чём-то другом, отличном от IIS.
Как сейчас вспоминаю это зловещее "заклинание" в виде ошибки драйвера EGAVGA.BGI, которой непременно сопровождался каждый запуск "синего экрана" Turbo Pascal 7.0. Ну и отсутствие автосохранения тоже, конечно (и то, как преподаватель вбивал юным талантам идею, что нужно нажимать кнопку сохранения после каждой написанной строчки).
Зато как приятно было получить результат в виде компилирующейся, работающей и красиво рисующей очередные фигуры Лиссажу программы!
Странные вещи вы рассказываете. Для работы текстового IDE графический драйвер был не нужен. С автосохранением, вроде, особых проблем не было, но точно не помню. Будет настроение, выкопаю в архивах, посмотрю.
автосохранения в TP 7.0 нет, но и ошибку EGAVGA.BGI он не выдает при запуске. Это у товарища что-то там сломанное видимо было.
Ну и использовать графические библиотеки Паскаля, это такое себе... Они ж там с 87-го года не менялись :) Может для школьных и ПТУшных учителей и ок, у них методички тех же лет.
Драйвер был нужен, чтобы запустить графическую (не консольную) программу, думал, что это понятно из контекста про рисование фигур Лиссажу :)
Думаю, что очень многие начинали изучать программирование именно с графики, особенно если речь про школу. А потом уже переходили на написание чисто консольных программ.
Думаю, что очень многие начинали изучать программирование именно с графики
В Турбо Паскале графика начиналась с asm
mov ax, 13h
int 10h
end;
Uses Crt,Graph;
фу :)
Ну-ка, нарисуйте мне окружность на экране, после
asm
mov ax, 13h
int 10h
end;:)
uses 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.
В идеале, конечно тоже на ассемблер переписать :)
Мне кажется, круг у вас не получится, получится нечто с гиперболическими гранями. И к тому же, без учета соотношения сторон дисплея. Поэтому uses Graph + штатная Circle все-таки рулят :)
К тому же они позволяют делать кроссплатформенный кроссвидеокартовый код, а у вас дисплей гвоздями прибит на VGA 320x200x256
Вопервых, я ведь запускал этот код, прежде чем ответить.
Во-вторых, поправку на то что в 320х200 пиксели не квадратные - можно добавить. А можно включить режим, в котором будут квадратные пиксели. Вобщем не суть...
Дело в том, что ваш Graph не поддерживает 256-цветный режим (по крайней мере я не видел таких bgi-драйверов), и придется довольствоваться древними 16-цветными режимами, или вообще монохромным :)
Далее, рутины в Grpaph тормозные, и не предполагают работы с анимацией. А также мы не имеем воозможности модифицировать код под себя. В моем случае я могу делать с окружностью что угодно, сделать ее градиентной, добавить заливку, переделать ее под планарный modex-режим.
Не, конечно юзать готовые либы это норм, если нет цели кодить на низком уровне и что-то изобретать. А хочется просто нарисовать окружность :)
Но есть же более продвинутые либы чем штатный graph :)
кроссвидеокартовый код
13h режим любой видеокартой поддерживается, даже современными. Игры в DOS под VGA практически все были в 13h-режиме.
И вообще, если уж кодить графон в Паскале, то интереснее и полезнее это было делать на низком уровне. Имхо :)
Вопервых, я ведь запускал этот код, прежде чем ответить.
У вас есть под рукой настроенный эмулятор DOS с Турбо-Паскалем? О_о Ладно, я тоже попробую.
Дело в том, что ваш Graph не поддерживает 256-цветный режим (по крайней мере я не видел таких bgi-драйверов), и придется довольствоваться древними 16-цветными режимами, или вообще монохромным :)
Обижаете. Есть и vga256.bgi, и vesa.bgi, который умел в режимы SVGA. Они ж потому и драйверы, что предлагали единый интерфейс под разные видеокарты.
Далее, рутины в Grpaph тормозные, и не предполагают работы с анимацией.
Так они вас вообще никак не ограничивают в анимациях и прочих фишках. Это же не виндовый GDI, у вас там прямой доступ к железу открыт. Хотите, используете готовые библиотечные функции, там всякие рамочки рисовать или кнопочки, или шрифты юзать (векторные, кстати). Хотите - свои пишите, они прекрасно будут сосуществовать с библиотечными.
13h режим любой видеокартой поддерживается, даже современными. Игры в DOS под VGA практически все были в 13h-режиме.
Ну это на богатом, VGA во времена Паскаля. Я с CGA начинал :)
UPD: Не, не получается у вас круг:
У вас есть под рукой настроенный эмулятор DOS с Турбо-Паскалем? О_о
Посмотрите мою последнюю статью: https://habr.com/ru/articles/937350/
Вопросы отпадут. Да, я из тех чудиков, у которых не только DOS-эмулятор с ТурбоПаскалем есть, но и 386 и 486-й работающие (и использующийся) компьютеры есть, и да, там тоже ТурбоПаскаль имеется :)
Обижаете. Есть и vga256.bgi, и vesa.bgi, который умел в режимы SVGA.
Ну, в штатном дистрибутиве этого точно не было :)
А так-то, для TP было написано масса всего, с поддержкой "из коробки" мышки, gif, jpeg, и т.д.
они прекрасно будут сосуществовать с библиотечными.
Не всегда. В моем случае Graph просто лишним будет.
Не, не получается у вас круг:
Это у вас не получается :) У меня норм.
Я радиус окружности увеличил, чтобы было лучше заметно. Вот вам для сравнения, белая - по вашему алгоритму, зеленая - circle из модуля graph:
Да, я из тех чудиков, у которых не только DOS-эмулятор с ТурбоПаскалем есть, но и 386 и 486-й работающие (и использующийся) компьютеры есть, и да, там тоже ТурбоПаскаль имеется :)
Мое почтение, коллега!
белая - по вашему алгоритму, зеленая - circle из модуля graph:
Да алгоритм-то не мой, конечно (из фидоэхи). Но он рабочий. И да, я вижу и без зеленой окружности, что у вас он кривую "окружность" рисует. Мне даже любопытно теперь, как это у вас получилось :) Можно скрин программы? Может скопипастили как-то криво? )
Круг без тригонометрии не обязан быть круглым.
Откройте для себя алгоритм Брезенхэма.
По нему и круг получается круглым, и прямая прямой. И всё в целых числах безо всякой тригонометрии.
Круг и с тригонометрией не обязан быть круглым. Например, если это круг в L₁-норме или в L_\inf-норме.
Может скопипастили как-то криво? )
Действительно, моя вина. Опечатался в одном месте.
Проблема низкого уровня - привязка к железу. Чуть другая видеокарта или монитор и переписывая программу или учитывай всё это при написании...
Но что тупила графика из Graph - помню хорошо.
Да не было проблем с "чуть другой видеокартой" и тем более монитором. У видеокарт были стандарты и обратная совместимость. Если карта поддерживала VGA, значит так, как прописано в стандартах, и обычно также поддерживала CGA/EGA.
К тому же у нас еще есть BIOS, который выступает слоем совместимости.
А уж монитор тут вообще не причем. Чего это вы навыдумывали?
Ошибок BGI не помню, а вот эпический "Runtime error 200 - devision by zero" после апгрейда до Pentium врезался глубоко в память... и после недолгого дебага в спираченной IDA, я научился его патчить, заменяя, в не менее легально используемом, чем IDA, Hiew несколько байт (то ли div, то ли loop) на nop...
Знакомый программист Влад Патрышев (1952-го года рождения) там работал и говорит, там была идея, что понимать сложный код не обязательно, а надо правильно тестировать. К новому коду писали много тестов. Как работает старый код, никто не знал, при попытке что-то в нём изменить все тесты рушились.
А кто видел такую "делфи"? :)
Никогда не программировал на Pascal, в школе мы программы Basic на листочках сдавали а учитель их интерпретировал. Устроившись три года назад программистом C# в Газпромбанк, получил задание перенести функционал из одной системы в другую, разобравшись с бизнес-логикой по коду. Код оказался на Pascal. Ну что сказать, нормальный этот ваш Pascal, только устарел немного.
Тот, с которого вы переписывали устарел. Современные далеко не уступает С#.
Крохотные примеры
Это же всё — вопрос синтаксиса. Разве это не похоже на Go, C# и Rust?
Ну так вопрос как раз в это. Чем именно устарел "Паскаль"?
В нем (языке Делфи) сейчас имеются почти все современные конструкции и приемы: анонимные функции, инлайн переменные, выведение типов, дженерики, масштабная рефлексия (атрибуты и прочее), инлайн оптимизация методов, конкатенация массивов, хелперы, перегрузка операторов и многое другое
Убедили и слегка удивили, Pascal не устарел. Я думал, он застыл в своём развитии. Тогда почему Pascal не составляет сильной конкуренции C#, Java, Go etc.? Старые проекты не в счёт. В чём причина: слабый инструментарий, отсутствие финансовой поддержки крупной корпорации, ограниченность применения, отсутствие киллерфичи, недостатки языка всё-таки, ...?
Прошу прощения, я не специально нажал "минус". Промахнулся с телефона. Не обращайте на него внимания.
Проблем скорее всего несколько:
Инструмент платный для коммерческой разработки (хоть и плата единоразовая)
Инструмент не опенсорс, в том числе компилятор. Это может мешать развитию или политике конкретного клиента.
Среда разработки не кроссплатформенная и работает, пока, только под Windows.
Я думаю, это основные проблемы. В остальном инструмент не сильно уступает современным решениям, а во многом превосходит.
Могу сказать за себя, без обобщений. Хотя я и начинал с Паскаля и работал Дельфи, потом с нее съехал.
Язык многословен - даже в Обероне лишние Бегин убрали.
Проблемы с ВинАпи - они сишные, актуальные трансляции запаздывали.
Когда я уже писал на С++полноценный 32-битный код, сокамерники на Дельфи/паскале дрючились с DPMI.
Да, я переписал лично Turbo Vision под Watcom C++.
Единственный плюс Д, который еще и актуален - быстрая компиляция.
Pascal не составляет сильной конкуренции C#, Java, Go etc.
Потому что дело не в языке, а в том, что стоит за ним. C# продвигается майкрософтом - конференции, реклама, поддержка для всех продуктов. За Java стоят миллионы существующих энтерпрайз приложений и их команды. И когда такая команда стартует новый проект, то естественно выбирает опять джаву. Что касается Го, то он много лет точно так же был не особо популярен, пока не выяснилось что он очень хорошо подходит для быстрой разработки микросервисов/девопса и на него стали переходить в первую очередь со всях node.js решений. Плюс Го удобен тем, что вокруг него можно собирать команда разработчиков с разных стэков - примитивный синтакст могут быстро освоилить хоть джависты, хоть плюсовики.
В нем (языке Делфи) сейчас имеются почти все современные конструкции и приемы...
Вот я и спрашиваю, что мешает использовать Delphi сегодня?
Скорее всего, мешает незнание текущего положения дел. Мало рекламы и новостных постов. И мешает устоявшееся в ИТ сообществе, хоть и не совсем верное, мнение о Delphi и Pascal.
Спроси любого, кто "не любит" Делфи о том, что в нем изменилось за последнее время - никто из них тебе не ответит. Однажды они решили или где-то прочитали, что Делфи - плохо и всё на этом.
Скорее всего, мешает незнание текущего положения дел.
Мешает, скорее, отсутствие этих самых киллер-фич при наличии некоторых недостатков. Вот если у вас есть существующий проект на Delphi, вы его и будете развивать, причин бросать его в общем-то и нет. А надо ли начинать на ней новый проект? Минусы-то очевидны:
Она стоит денег для коммерческой разработки, в то же время конкуренты бесплатные или доступны по копеечной подписке.
Специалистов по ней на рынке мало. Джуны ее учить не хотят, опытных разработчиков зарплаты по Delphi не особо привлекают, т.е. у вас частенько будет кадровый голод
В общем-то эти два недостатка не так чтобы и критичны, и могли бы быть перевешены какой-то киллер-фичей, ну так нет же ее, этой киллер-фичи.
Киллер-фича есть. Это кросплатформенность. Т.е. на одной кодовой базе можно собирать приложения для различных платформ. Это как минимум удобно, особенно если проект новый. Не нужен зоопарк всяких средств разработки.
Киллер-фича есть. Это кросплатформенность
Киллер-фича, это нечто, дающее вашему продукту крутое преимущество над другими. Смотрите, я на скриншоте самых популярных языков TIOBE отметил зелёно-фиолетовыми стразиками языки, которые не поддерживают кросс-платформенность нативно, и не имеют мощных кросс-платформенных фреймворков:
Поэтому нет, кросс-платформенность в 2025-м, это не киллер-фича, а рядовой функционал любого средства разработки общего назначения.
Из этих языков мало кто умеет на одной машине собрать приложение сразу под все платформы. Т.е. не требует, например, для сборки под Linux собирать из Linux. Тем более Visual Basic.
Из этих языков мало кто умеет на одной машине собрать приложение сразу под все платформы.
Да как раз все умеют, кроме С и С++ (причем последний тоже в принципе умеет, хотя и надо предварительно повозиться с кросс-компилятором, и Qt пересобрать под таргет-платформу). Visual Basic, это, очевидно, также кросс-платформенный VB.NET, может быть, в какой-то мере ещё VBA там сидит в этой цифре, но то тулзовина вне контекста платформ.
Ну и конкретно по возможности собирать на одной машине под разные платформы, эта фича уж точно не является "киллерской". Ну сможете вы под винду собрать линуксовый бинарник. Что вы там с ним будете делать? Запустить и протестировать, вам нужна будет все равно хотя бы виртуалка с линуксом. А если она есть, то на ней и собирать точно так же можно. А под macOS вы никаким инструментом не сможете собрать приложение, если у вас нет собственно Мака, т.к. эппловский тулчейн доступен только там.
Я собираю все релизы на одной машине. В том числе для мака. Тестировать можно почти напрямую все платформы кроме мака (мак только в виртуалке). А для других есть WSL, WSA. И не надо вообще ничего делать со средой разработки. Отладка, при этом также на одной машине доступна. Я могу хоть сейчас запустить одно и то же приложение на в винде сразу для всех этих платформ одновременно. Это удобно интегрировано в среду, не требует почти никаких настроек.
Киллер-фичей в Delphi является то, что в нём всё удобно сделано для разработки сразу: Отладчик? - удобный, Удаленная отладка? - пожалуйста, делается буквально в один клик, Построение интерфейса - отлично, Редактор кода - супер, Пакетный менеджер - есть, Работа на нескольких мониторах - пожалуйста, Разделение редактора кода - конечно, Не усложненный язык - да, синтаксический сахар - есть и до сих пор подсыпают и т.д.
Я собираю все релизы на одной машине. В том числе для мака.
Но мак же у вас есть, хотя бы виртуализированный? Delphi же наверняка не подпишет вам маковское приложение на виндовой машине, по крайней мере, без какого-нибудь сервера, запускающего удаленно на маке тулчейн для подписи.
Киллер-фичей в Delphi является то, что в нём всё удобно сделано для разработки сразу
Ну ок, а почему вы думаете, что вот всего перечисленного нет у других? Я не питонист, я не скажу как там, но вот например в Visual Studio есть абсолютно всё то же самое. Более того, вы даже можете отлаживать приложения, работающие в облаке. А, ещё все это бесплатно и без ограничений.
Вообще нет. Нет ни нормального дизайнера, для современных интерфейсов, все кодом, xaml'ом. Не говоря уже о том, что в ней нет всего этого сразу. Ты не можешь написать приложение с использованием дизайнера и собрать всё это на одной машине
Вообще нет. Нет ни нормального дизайнера, для современных интерфейсов, все кодом, xaml'ом
Для классических xaml'овых форм как раз дизайнер есть. Кодом xaml писать неудобно, сильно громоздкий. А обычные html-based веб-морды, там дизайнеры не прижились банально потому, что кодом их верстать заметно быстрее выходит. Конечная цель IDE ведь обеспечить продуктивность.
А что за киллер фича у него? В нем есть то же что у плюсов? Ок, зачем нам еще одни плюсы, но с begin..end ?
Он более удобен для написания, чем плюсы.
Он более безопасен, потому что использование указателей в нём или выделение памяти вручную - редкий случай и во многих проектах вообще не используется.
Помимо самого языка, вся экосистема более продумана изначально и более проста в освоении. В штатной поставке очень большая библиотека: от хелперов для даты и времени, строк, чисел и т.д. до методов шифрования, хеширования, кодировки и т.п. В штатной поставке есть даже библиотека для работы с любыми S3-compatibility хранилищами и библиотека для клиент-серверной трансляции.
Другими словами, преимущества не столько в самом языке, сколько в библиотеке готовых решений
Он более безопасен, потому что использование указателей в нём или выделение памяти вручную - редкий случай и во многих проектах вообще не используется.
Так и на полюсах так делать не принято. Разве что кто-то пишет на плюсах код на Си.
В штатной поставке очень большая библиотека
boost напоминает ;)
Да, напоминает, но в Delphi это по сути часть языка. Вдобавок ко всему имеются два штатных фреймворка: виндовый VCL и кроссплатформенный FMX. Всё это тесно связано и работать со всем этим гораздо удобнее.
Работа с JSON, BSON, XML, сериализация/десериализация, работа с HTTP, REST, FTP, SMTP. Всё это есть из коробки и не нужно бороться с зоопарком библиотек и их версий.
В штатной поставке очень большая библиотека: от хелперов для даты и времени, строк, чисел и т.д. до методов шифрования, хеширования, кодировки и т.п. В штатной поставке есть даже библиотека для работы с любыми S3-compatibility хранилищами и библиотека для клиент-серверной трансляции.
Так и в любом зрелом языке все это есть, в чем преимущество-то?
Всё это есть из коробки и не нужно бороться с зоопарком библиотек и их версий.
Да нет никакой борьбы в том чтобы нужные библиотеки подтянуть пакетным менеджером. Ну и в .NET и Java, например, большая часть тоже из коробки есть и не надо даже в пакетный менеджер лазить.
Он более безопасен, потому что использование указателей в нём или выделение памяти вручную - редкий случай и во многих проектах вообще не используется.
Рад за другие проекты, но я видел те, где использование GetMem/FreeMem вместо динамических массивов широко практиковалось потому, что это якобы быстрее, а ещё была своя реализация корутин через вложенные функции и манипуляции со стеком на ассемблере. :-D
В нем есть то же что у плюсов?
C++ Builder — это прямой наследник Delphi.
А то, что касается языка... Сейчас многие языки примерно одинаковы. Ну, там, особенности синтаксиса. В любом языке программирования можно реализовать одно и то же. Язык программирования никогда не предлагается сам по себе, а вместе со средой разработки и с технологией разработки приложений.
Главное, что нужно знать, что Delphi — это компилируемый язык. Лично мне я в алголоподобных языках импонирует возможность явного описания ряда концепций. Например:
file of record
begin
///
endДа, в Python есть итераторы и явное (на уровне языка) поддержка изобразительных средств. Но это всё требует развития: новые элементы языка, подходящие изобразительные средства, прямая поддержка всяких там MVC и т.д. и т.п.
Не стоит искать какие-то "киллер-фичи". Был бы программист, а язык найдётся. ;-)
В Делфи тоже есть итераторы и конструкции типа:
for var Item in List do
writeln(Item.Text);я давно использую
В том числе есть и генераторы
Или вот ещё примеры подражания питону
Скрытый текст
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;А что за киллер фича у него? В нем есть то же что у плюсов?
Delphi, это чутка другая квалификация разработчика, это не аналог плюсов, это аналог сишарпа, но под полностью нативную сборку. Главное преимущество Delphi над плюсами - в нем нет темплейтов/макросов, и соответственно, сам язык спасает мозг программиста от попыток уйти в метапрограммирование :)
отсутствие возможностей не является преимуществом.
это все равно что говорить, что одноногий зато не убьется на бегу
отсутствие возможностей не является преимуществом.
это все равно что говорить, что одноногий зато не убьется на бегу
Отсутствие возможностей делать плохо называется "безопасность" или "надежность". А безопасность и надежность - это хорошо. Да, автомобиль с системой экстренной остановки ограничит вас в возможности раздавить пешехода или усложнит вам задачу разбиться об мост. Но разве это не преимущество? Так же и с метапрограммированием. Да, оно популярно среди разработчиков на С++, у него масса своих фанатов, и в какой-то мере это неплохая тренировка для ума. Но написанный таким образом код чаще всего тяжелый и в отладке, и в сопровождении. Это банально делает развитие проекта медленным и дорогим.
макросы и шаблоны на безопасность влияют мало, особенно шаблоны - там такой же контроль типов
Проблема шаблонов в том, что они как goto, генерируют спагетти-код. Например, я когда-то писал расширения для РНР, сейчас оно там на С написано, достаточно чистый и понятный код. Четвертая версия пыхи была написана на С++. Написана она была профессиональными чуваками, но макросы там имели, по-моему, семиуровневую вложенность. Очевидно, тот, кто их писал, в них разбирался, но другим разбираться в этом была боль и страдания. Мне, например, надо было в движок добавить поддержку глобального пула коннектов к базе данных. Там пул был, но работал в рамках одной сессии, а мне надо было поддерживать общий пул для всех приложений и сессий всего веб-сервера. И я на разбор этих макросов потратил в разы больше времени, чем собственно на реализацию. Полагаю, я такой был не один, если в последующих версиях пыху переписали вообще полностью, и на языке без макросов :)
И это только один пример, который первым пришел в голову. А так, их стопицот было. Проще вспомнить проекты, где макросы/шаблоны не вредили сопровождению кода, чем те, где вредили. И я даже могу сказать: шаблоны дают чистый профит там, где надо сделать общий враппер для разных типов данных. Но в Delphi для этого есть дженерики, которые имеют даже синтаксис похожий.
то что ты путаешь шаблоны с макросами, говорит не о вреде шаблонов, а только о твоей квалификации
Не "ты", а "вы", и не путаю, а обобщаю. В С++ макросы и шаблоны - всего лишь разновидности кодогенератора.
Да и сам C++ — разновидность кодогенератора, ведь по нему же ассемблерный код генерируется. Следовательно, C++ — это как макросы. Да и Delphi, в принципе, тоже.
Полушуточный комментарий, но к размышлению.
В интернете никто не знает, что ты - кот, потому обычно на ты (с)
Чтобы требовать обращение на Вы, надо быть старше по возрасту, званию или должности. Я могу сразу сказать, что у Вас в этим могут быть проблемы =)
они как goto
что вы к нему вечно цепляетесь? Этот оператор, при правильном использовании наоборот чистит код от спагетти-кода.
про отсутствие возможностей ради безопасности это к фанатам раста - там тоже надо программировать одной рукой, потому что две ссылки одновременно запрещены
Чрезмерная забота о безопасности и надёжности - называется "гиперопека", и оччень мешает жить и работать.
Автомобиль с экстренной системой торможения - может остановить вас на ж/д переезде перед приближающимся поездом или на перекрёстке перед несущимся прямо на вас автомобилем - в этом смысле "плюсовый" подход, требующий явного подтверждения, что вы "хотите именно так" - гораздо разумнее.
В общем, к сожалению - но у Дельфи нет никаких "киллер-фич".
Для безопасной разработки имеется Ада - язык в публичном доступе, в отличие от корпоративного Дельфи, с имеющимися свободными компиляторами и поддержкой свободных сред разработки.
Интерфейсами - сейчас занимаются специальные люди, и пользуются для этого html/xml и что-нибудь по типу Питона - с динамической типизацией, а серьёзная обработка - делается в бэкэнде на чём угодно.
IDE в "старом" смысле - т.е. единая интегрированная программа/пакет программ с редактированием и компиляцией "прямо из оболочки" - на сегодня уступила своё место "расширенным редакторам", так сказать - типа Эклипса, VSCode, которые сами вызывают соотв. компиляторы/линкеры.
Встраивать дополнительные фичи "прямо в язык" - анафига? Современный подход (уже давно) - делает более-менее компактный язык, а всё реализуем библиотеками. Нафига язык-то курочить?
Ну вот люди годами изучали язык, специализировались на нём - оппа, а давайте прикрутим к нему свои нестандартные расширения...
Ну так ими - будут пользоваться с осторожностью - и только если у вас уже есть достаточно большое коммюнити.
Тогда отсутствие дизайнера в декларативных гуи - это минус, потому что в Делфи можно легко писать декларативно, а вот во многих других нет дизайнеров
потому что в Делфи можно легко писать декларативно
Я времена FMX уже не застал, поэтому как там, не знаю, но в VCL декларативного программирования как такового не было. DFM-файл формы, это по сути императивный скрипт, последовательность операций SomeProperty := SomeValue. Декларативное программирование подразумевает декларацию поведения, а не задание свойств. Вот как-нибудь так:
<Button disabled={isLoading}/>Здесь все выглядит похоже, но суть другая, здесь происходит не просто присваивание значения, а связывание представления и данных, и изменение переменной isLoading в рантайме приводит к изменению свойства у кнопки.
Отрицаем наличие дизайнеров в Wpf и Qt?
быстрая разработка простых проектов.
быстрая компиляция
В нем есть то же что у плюсов?
Знаете. У Pascal'я есть одна важная особенность: модульность. Вы оформляете модуль, у которого есть раздел объявлений (interface) и раздел реализации (implementation). Трудно назвать это "киллер-фичей", но вещь очень важная. В C/C++ очень много возни с заголовочными файлами. В этом смысле, Pascal'е есть большая концептуальная чистота, выражаемая набором ключевых слов. Никто не мешает реализовать и в C/C++ аналогичные подходы, но тогда потребуются дополнительные языковые средства. Что там написано в новейших стандартах, мне не известно. Не просветите?
А что за возня с хидерами?
Вы оформляете модуль, у которого есть раздел объявлений (interface) и раздел реализации (implementation). Трудно назвать это "киллер-фичей", но вещь очень важная.
Весьма убийственная "фича", когда в разных модулях требуется описать классы, которых циклически ссылаются друг на друга через private поля. Почему-то private поля должны быть описаны в interface, хотя это же детали реализации? А если вдруг оказывается, что 2 модуля циклически ссылаются друг на друга через implementation, то компилятор создаёт программу, которая по-тихому дико глючит, без всяких предупреждений или ошибок компиляции. Циклические ссылки "из interface" <-> "из implementation", тем не менее, разрешены. Примерно во всех остальных языках в подобных ситуациях проблем не возникает.
Дорого. Мне жалко отдать 3000$, если есть бесплатные альтернативы.
Кривая реализация этих современных конструкций...
Паскаль многословен. Ближе к Аде, чем к Расту
Как по мне, чем-то схож в своей многословности с Basic.
В своё время, учась в школе игрался с VB, а потом когда начал изучать C, то уже сложно было в институте писать лаболаторки на Delphi. Делал их на MSVC++ с использованием MFC. Учителя не знали как запустить, но технически это был ООП. Я даже экзамен по ООП сдал, написав всё на C++. Правда, написал я от балды, но преподы этого не знали и ставили "отл." в зачётке.
Современные далеко не уступает С#
А вы наверните в одной строке generic'ов и lambda-выражений - удивитесь многословности.
Ну как минимум, потому что нет лямбда выражений. Есть только анонимные функции пока. Это только пока
Не припомню, а в чём разница?
Анонимная функция - функция, не имеющая имени.
Лямбда - частный случай анонимной функции, которая имеет особый синтаксис.
В делфи есть анонимные функции, но нет лямбда-выражений.
В делфи есть анонимные функции, но нет лямбда-выражений.
Вероятно, и нет появятся. Нет вообще никаких препятствий добавить лямбды, если у вас есть анонимные функции. Это просто чуток другой синтаксис для одного и того же элемента языка. Но лямбда-выражение не особо вписывается в синтаксис Delphi, полагаю, это основная причина, почему их там нет.
У Паскаля, наверное, вообще политика такая - чтоб было проще, и чтоб не вводить новый синтаксис без необходимости.
А вот в C# скорее наоборот - чуть что, вводится новый синтаксический элемент - то лябды, то LINQ, то еще чего... В результате изучение C# намного сложнее, чем Паскаля, по моим ощущениям.
Так что вполне возможно, что действительно просто не хотят вводить новое без необходимости.
Такие пожелания есть в Jira по Делфи и синтаксис есть, который неплохо вписывается в язык. Так что будет. Nullsafety в бета уже тестируется.
У Microsoft такое тоже было. В флагманских продуктах того момента — Visual Basic и Visual Fox Pro. С существенными отличиями, а именно — элементы управления, используемые Basic и Fox, надо было разрабатывать отдельно, на С, по технологии COM, что требовало особых знаний и навыков.
Про Visual FoxPro и Basic уточню: не нужно было писать элементы управления на C, у них были свои встроенные элементы управления, которых было вполне достаточно. COM в основном использовался для соединения с другими источниками данных (Excel, etc).
COM в основном использовался для соединения с другими источниками данных (Excel, etc).
очевидно, это недостаток встроенных возможностей
Что значит "не надо писать"? Вы хотели сказать, что они уже есть, и поэтому их не надо писать?
Ну, так тогда и во всех других средах их так же "не надо писать".
Речь-то шла о том, чтоб при желании написать свой компонент, такой как тебе надо. Или, может быть, чуток доработать существующий.
И вот тут и вылезает разница: в Delphi это сделать довольно легко. А в Visual Basic и Visual Fox Pro это не сделать. Нужно использовать другой язык, и на нем делать, и не так оно просто.
На C#, кстати, с компонентами еще проще чем в Delphi. Может быть поэтому для него компонентов просто безумное количество.
Я сказал то, что сказал. У вас написано, что "элементы управления, используемые Basic и Fox, надо было разрабатывать отдельно" Я уточнил, что у них уже были свои стандартные компоненты (окна, кнопки, переключатели, поля ввода и т.д.) Их вполне хватало для всего, если учесть, что фокс в основном использовался для офисных задач. Хотя, как только вышел VFoxPro 3.0, я начало преферанса на нем даже написал (раздачу карт).
>Object Vision, 1992
Что-то мне все же кажется Object Windows Library (OWL) и в 1991, как ответ MS создал MFC
Quattro Pro и Paradox я в школе проходил. be like❤️🤗
Под винду была не Object Vision, а Object Windows Library, сокращенно OWL. И, возможно это тоже было ошибкой, что они ее сделали на своих расширениях языка, и в какой-то момент стало понятно что проще переходить на MFC, чем что-то делать на этом.
Update: погуглил, оказывается Object Vision тоже была, но не для плюсов. Для плюсов был OWL.
Еще как минимум в РФ была странная команда кто продавала и рулила BorUG (Borland user Group), когда на том же Borland Contest за более высокие места вручали никому не нужный тогда, в начале 90-х, Quattro Pro, вместо Turbo C++, мотивируя тем, что он "больше стоит у нас". Видимо был неликвид, который надо было сбагрить :)
А про Netscape и 3dfx подобных статей не было?
Кто компилял паскаль в ассемблер pdp11, потом в obj и наконец sav?
Добавьте в карму пользователю rt11sj )
Кстати Дельфи покупал за $850 версию 8. До сих пор черные коробочки где-то валяются )
Что-то мне кажется, на ДВК сразу в .obj транслировалось. Потом в .sav, да.
А вот чтоб в ассемблер - не помню... 1988-90 год.
Помню такое. Причем, раз все равно компиляется в макроассемблер, то можно было в тексте паскаля писать вставки на макроассемблере, которые работали.
Еще помню что на одну системную дискету не влазили одновременно транслятор и линковщик, поэтому были две системные дискеты, она с редактором и транслятором, вторая - с линковщиком. Соответственно, перед линковкой системную дискету меняли. ОС, естественно не перегружали - ей было все равно :) Исходники и объектники - во втором дисководе.
Да, на одну дискету не лезли! Но можно было разными сторонами вставлять, вроде.
Дисковод был односторонним, емнип, а дискеты бывали двухсторонними.
А еще в ДВК 2м не было места для графического адаптера (контроллер дисковода и контроллер для сети типа звездочка занимали корзины).
Поэтому игруху приходилось компилять на 2м и потом грузить на ученический ДВК 1, чтобы посмотреть что вышло. Да еще .sav так просто ученику не загрузишь. Была специальная программа из Зеленограда, которая грузила sav, но там был счетчик от нелегального копирования - 10 раз работала, потом портила себя. Пришлось искать счетчик )
Какая графика на ДВК-2М? Там же алфавитно-цифровой терминал 15-ИЭ-00-013, подключаемый через последовательный порт. :)
Какая графика на ДВК-2М? Там же алфавитно-цифровой терминал 15-ИЭ-00-013,
Не обязательно. Они бывали и с парой плат "контроллер символьного монитора" + "контроллер графического дисплея", которые тоже подключались через последовательный порт, но умели и в графику. Хотя ДВК и графика, это вообще больная тема.
КГД
Контроллер графического дисплея (КГД) содержит 16 килобайт памяти (К565РУ6), включается как надстройка и позволяет выводить монохромную графику 400 × 286 точек. Совместно с контроллерами КСМ или КСД это позволяло отображать текстовую и графическую информацию. Коммутация и смешивание видеосигналов осуществляется на плате КГД, и программно можно выбрать, показывать ли только текстовый, только графический, или оба экрана.
Для платы КГД написаны множество графических программ: игры, графические редакторы, обучающие программы. Существуют версии языков Бейсик и Фокалс поддержкой КГД. Также существует драйвер электронного диска DE.SYS, позволяющий использовать память КГД как дисковое устройство. Несмотря на небольшую ёмкость, это позволяет радикально ускорить работу из-за уменьшения числа обращений к дисководам. Энтузиасты устанавливали на плату КГД микросхемы К565РУ5 вместо РУ6, что не мешало работе графического адаптера, но увеличивало ёмкость электронного диска в 4 раза, до 64 КБ.
Были ребята в Зелике ASP. Писали игрухи на ДВК графические - Supercobra, Бармен и портировпли на БК. Все же на ДВК прогать было приятнее, чем на БК.
Нам в школе поставили класс ДВК в 86, а в 87 проапгрейдили КГД. Даже Фокал умел с ним работать (зомбически).
Я вычитал в журнале Электроника как напрямую обращаться к КГД, что позволило на коленке написать спрайтовую систему. Конечно, на асме, чтобы это хоть как-то работало. Запилил игруху и даже на бк перенес. А потом 11 класс и подготовка к поступлению - стало не до пет проектов )
КГД и КЦГД - это уже ДВК 3 и выше, конструктив другой, со встроенным монитором, и корзиной установленной вертикально позади кинескопа в корпусе. А речь шла про ДВК-2М.
Забыли JBuilder, в котором тоже был удобный редактор GUI для Java.
ИМХО Borland был задавлен Microsoft. Примерно как Netscape. У вас хороший коммерческий продукт ? А мы будем раздавать свой бесплатно ! Борланд предлагает OWL и VCL, а мы будем всем раздавать MFC ! Исход предсказуем.
Потом Борланд походу набрал кредитов и вступил в игру по созданию уберсуперпупер комплекта полного цикла разработки софта. Тогда же в эту игру вступили Microsoft и IBM. Например Борланд среди прочих купил разработчика интегрированной среды разработки с UML - фирму TogetherSoft, в это же время IBM купила Rational. Покупок было много и каждый вроде как собрал вожделенный полный комплект (не только среды разработки но и свои системы контроля требований, контроля версий, багтрекинг оптимизирующие пакеты, UML и тп.
Я как раз в то время работал в TogetherSoft и оказался в Borland.
Если бы мне сказали что я буду работать в Борланд, когда я был студентом я бы не поверил, а вот когда реально оказался было уже не так радостно, хотя на тот момент Борланд еще не надорвался. Но буквально через пару лет уже все. Жаль. Не люблю Мелкософт.
ИМХО Borland был задавлен Microsoft.
Сами они себя задавили. Сначала перекрыли себе воздух - придавили приток новых разработчиков, сделав свои продукты дорогими и недоступными для новичков. Потом разогнали существующую клиентскую базу, прекратив развивать продукты в течении длительного по ИТ-меркам периода времени.
Борланд предлагает OWL и VCL, а мы будем всем раздавать MFC ! Исход предсказуем.
MFC же никогда не была конкурентом VCL. Второе намного сложнее и функциональнее.
Например Борланд среди прочих купил разработчика интегрированной среды разработки с UML - фирму TogetherSoft, в это же время IBM купила Rational.
Да, только и те, и другие не подумали, что бизнесу нужен не столько встроенный громоздкий и неудобный способ документирования, сколько интеграция с контролем версий, поддержка различных методов аутентификации, средства SSO, и так далее.
Пробовал Jbuilder - уперся в иероглифы вместо русских букв. Еще и работала Ява тогда на 486, мягко говоря , не быстро...Фсе
Эх, ребята, я на TP в середине девяностых еще будучи школьником написал свою первую игру - Арканоид ) Ну и всякие утилитки тогда писал, типа, ANSI в ASCII и пр
Ставь лайк если был активным участником форума "Мастера Delphi"
"Ах, как внезапно кончился диван..."
Кстати, между паскалём под DOS и Delphi 1 был ещё Borland Pascal With Objects 7.0 For Windows в 1993. Выделялся серенькими формами (по-умолчанию окна в 3.1 были белые) и "трёхмерными" кнопками с большими иконками с тенями, радиобатонами, вкладками, панелями и прочими свистелками под названием Borland Windows Custom Controls ака BWCC. Вполне себе продукт своей эпохи, и, кажется, там даже были какие-то зачатки 32 бит.
Ну это и был Borland Pascal 7, там в одной инсталяхе и DOS и Windows версии шли. А сам язык (его вариация) называется Object Pascal. В Delphi тоже он, а "Delphi" это среда. Но сейчас это уже не важно :)
На самом деле предыдущий комментатор в целом прав, только версии чуток перепутал. Был там еще Turbo Pascal for Windows, отдельный и самостоятельный продукт, хронологически вышел, если не ошибаюсь, между TP6 и BP7.
Сейчас (с недавних пор), Delphi - это уже не среда, а название языка. А среда называется RAD Studio
Изначально, это было и название языка, и название среды. Всё-равно, сейчас вспоминается и сама среда и используемый в ней язык. C++ Builder — это та же среда, но на базе другого языка прогарммирования, но исходные библиотеки всё-равно были написаны на Object Pascal (Delphi), имелись только соответствующие заголовочные файлы на C++. А RAD — это, скорее, общее название среды, предназначенной для быстрой (rapid) разработки.
Изначально, это было и название языка, и название среды
Изначльно это было только название среды. Маркетинг тогда ещё CodeGear переименовал Object Pascal в Delphi где-то в нулевые. Ну, время летит незаметно и быстро, поэтому коллега @HemulGMи написал "с недавних пор" :)
Да многое стирается со временем.
Я ещё помню Turbo Pascal 5.0, среда разработки которого была написана ещё, видимо, на Turbo Professional. Была в своё время такая библиотека. Потом сразу возник turbo Pascal 5.5 с процедурными типами и ООП. Вместо Turbo Proffesional была предложена Object Professional. Но на пороге уже была Turbo Vision. Я пытался что-то делать на Turbo Professional. Кажется, там было удобнее с отработкой нажатий клавиш, а Turbo Vision неприятно поразила какой-то мудрёностью. (Такое же странное впечатление у меня потом было и от MFC. Где-то в другой теме говорят, что есть хорошая библиотека WTL. Не знаю. Не пробовал.)
Эххх.
Сколько всего писалось! И где, теперь, всё это? Сколько было вложено человеко-часов?!! Код пишется только для того, чтобы умереть. При этом, решаются одни и те же задачи!
Мне повезло тоже попользоваться Delphi. Мой путь был: Basic, ASM, потом на курсах Pascal один год, потом год Delphi. И забавно, что препод (хороший чел) высказал мнение (и мы его приняли само собой), что Delphi - это лишь этап. А вот в следующем году - будет С++, и вот это уже будет настоящий язык! Действительно был С++, я его учил с энтузиазмом, Страуструп был настольной книгой.
И я старался изо всех сил, а та лёгкость создания апликух, что была с Delphi - всё не приходила. Только много лет спустя я понял что ей придти было и не суждено, что Delphi был не столько гениален, сколько просто правильно сделан. А вот C++ - это трясина
Как Borland «профукали все полимеры»