Помню 1998 год. Тогда процентов 80 (если не больше) знакомых писали на Delphi.
Удобная среда, быстрая разработка действительно работающих программ. Куча компонентов, куча статей, советов. Торри, Мастера Delphi, Королевство Delphi.
Уже в 2012 никого из знакомых на Delphi не осталось.
Где Борланд свернул не туда? Почему просрали такой ВЕЛИКИЙ продукт?
Насколько я понял, сейчас им владеет какая-то Эмбаркадера. Интересно, какие у них финансовые показатели?
07.07.25 06:15: Перенесено из 'Компьютерные священные войны'
K>Где Борланд свернул не туда? Почему просрали такой ВЕЛИКИЙ продукт?
чего великого-то? ты еще скажи, что за веб-формс было будущее
кстати винформс таки еще здравствует
имхо проблема борланда в том, что у них не было единой философии. единого концепта. были точечные по большому счету штуки типа пакетов типа турбопрофешинал или турбовижен. но это точечное. не философия. а вот у мс именно единая философия.
поражает почему существуют всяческие пхп и яваскрипты. одно объяснение — количеством берут. хотя кого не спроси — и то и то откровенно все ненавидят и обсирают.
K>Где Борланд свернул не туда? Почему просрали такой ВЕЛИКИЙ продукт?
Главный писатель свернул в Микрософт же, делать c#.
Интересно, его обидели в борланде, или просто денег больше предложили?
Данное сообщение является художественным произведением и освещает вымышленные события в вымышленном мире. Все совпадения с реальностью являются случайными. Не является инвестиционной рекомендацией.
O>Интересно, его обидели в борланде, или просто денег больше предложили?
понял видимо что направление тупиковое и решил не гробить свои амбиции. не? как у Пелевина — "я считаю, что будущее все равно за синематографом"
U>имхо проблема борланда в том, что у них не было единой философии. единого концепта. были точечные по большому счету штуки типа пакетов типа турбопрофешинал или турбовижен. но это точечное. не философия. а вот у мс именно единая философия. U>поражает почему существуют всяческие пхп и яваскрипты. одно объяснение — количеством берут. хотя кого не спроси — и то и то откровенно все ненавидят и обсирают.
O>>Интересно, его обидели в борланде, или просто денег больше предложили? U>понял видимо что направление тупиковое и решил не гробить свои амбиции. не? как у Пелевина — "я считаю, что будущее все равно за синематографом"
И есть теперь что то сравнимое с инструментами Борланд в нашем безумном мире ИИ?
Ты с ними работал и понимаешь о чем речь?
Или реально не понимаешь,
что мы деградировали по сравнению с инструментами Борланд,
даже с учетом под санкционной в РФ Idea и WebStorm?
P>Это точно про Дельфи?
это про турбопскаль. в винде померло автоматически и логично.
P>И какая же тогда философия была у MS?
а вот ТАКАЯ! че ты услышать хотел? лично что мне в мс нравится — отсутствие хаоса, что они поощряют в отличие от. где каждый херачит кто во что горазд.
не спас бы. если хаос заложен в концепт разработки, ни к чему хорошему это не приведет
уверен, что известный сорт кофе тоже сгниет рано или поздно, если в мс не полные кретины сидят сейчас, конечно.
Y>И есть теперь что то сравнимое с инструментами Борланд в нашем безумном мире ИИ? Y>мы деградировали по сравнению с инструментами Борланд,
Ну можно на WPF писать как на Delphi (обработчики в Form.Button_OnClick()), и даже редактировать дизайн и текстовую разметку в 2 параллельных окнах (а не переключая туда-сюда окно дизайн/dfm as text).
Данное сообщение является художественным произведением и освещает вымышленные события в вымышленном мире. Все совпадения с реальностью являются случайными. Не является инвестиционной рекомендацией.
Y>Ты с ними работал и понимаешь о чем речь? Y>Или реально не понимаешь, Y>что мы деградировали по сравнению с инструментами Борланд, Y>даже с учетом под санкционной в РФ Idea и WebStorm?
нет. не особо. ты о чем? чем это круче инструментов, предлагаемых стандартом бесплатной вс2022 к примеру, даже если решарпер туда не ставить и прочие инструменты?
Здравствуйте, Kocur, Вы писали:
K>Помню 1998 год. Тогда процентов 80 (если не больше) знакомых писали на Delphi. K>Удобная среда, быстрая разработка действительно работающих программ. Куча компонентов, куча статей, советов. Торри, Мастера Delphi, Королевство Delphi. K>Уже в 2012 никого из знакомых на Delphi не осталось. K>Где Борланд свернул не туда? Почему просрали такой ВЕЛИКИЙ продукт?
Лично я думаю дело было так.
1. Сначала был некий диалект ассемблера.
2. Потом его заменил Си.
3. Си стал языком на котором пишут операционки.
4. Си улучшили до C++.
5. На C++ написали кучу кроссплатформенных библиотек GUI.
6. Всё остальное стало не нужно.
Фишка в том, что для поддержания операционок всё равно понадобится определённое количество программистов Си (процедурное, функциональное). И этот язык можно условно считать особым подмножеством C++ (+объектное, +обобщённое). Я уже не раз указывал на факт, что кроме Си и C++ ничего по сути и не осталось. Java, C#, Go, Rust и многие другие это нишевые языки программирования. И что особо важно зависимые от конкретных компаний и фондов. Но самое главное всем остальным не повезло стать языками операционок.
По большому счёту все проекты не на Си или C++ скорее всего не выдержат испытание травами временем. Это Страуструп только в своём интервью говорил, что делал язык программирования программы на котором будут работать спустя десятилетия. И те же программисты с RSDN (очевидно калька на MSDN) на том же C# рано или поздно отвалятся и уйдут. И всё, новых уже не будет в таком количестве. Так же как Delphi не стимулирует новый прирост программистов.
да кроме шуток. ни одного проекта на классической яве не видел ( а видел штук как минимум 5 ) где бы не было хаоса.
вот почему на незнакомом проекте на шарпе я знаю куда лезть и без проблем нахожу все что мне нужно? на яве мне надо поднимать кучу народа на помощь? ) это о чем-то говорит...
Здравствуйте, Osaka, Вы писали:
O>Главный писатель свернул в Микрософт же, делать c#.
Он свалил в 96 году, во времена выхода Delphi 2. Все дальнейшее развитие происходило без его участия. Напомню, самой удачной версией считается Delphi 7 (у тех, кто свежее не пробовал).
Борланд сгубило не это. Они просто поверили, что смогут тягаться с МС на равных, не обладая ни возможностями ни ресурсами МС. Во времена Delphi 6 была сделана попытка покорения Linux — выпустили Kylix на дико кривом Qt того времени. Kylix продержалась три версии и бесславно померла. Выпускали версии Delphi с поддержкой .NET (начиная с Delphi 7, кажется), которая длилась аж по Delphi 2009. Delphi 8 была чисто .NET-продуктом — провал. Одновременно выпускали JBuilder для Java и C# Builder с собственным компилятором C#. Короче, распылили ресурсы вместо развития основного продукта. После чего решили переориентировать бизнес и продукты разработчиков выделили в отдельную компанию (что, нужно заметить, пошло им, продуктам, на пользу). Сейчас у Delphi все хорошо: поддержка всех актуальных платформ и недосягаемая для конкурентов юзабельность и скорость разработки.
Здравствуйте, rudzuk, Вы писали:
R>Сейчас у Delphi все хорошо: поддержка всех актуальных платформ и недосягаемая для конкурентов юзабельность и скорость разработки.
ой да ладно! В чем он выигрывает перед тем же React Native с огромным сообществом?
Здравствуйте, wl., Вы писали:
R>>Сейчас у Delphi все хорошо: поддержка всех актуальных платформ и недосягаемая для конкурентов юзабельность и скорость разработки.
wl.>ой да ладно! В чем он выигрывает перед тем же React Native с огромным сообществом?
K>Уже в 2012 никого из знакомых на Delphi не осталось.
K>Где Борланд свернул не туда? Почему просрали такой ВЕЛИКИЙ продукт?
Делфи позволяла наклепать гуй быстро, наформошлепить. Как раз в 90ых в конце это все начало уходить в веб в жабоскрипт в итоге. Сам по себе паскаль был популярен для обучения только в восточной Европе, в других странах учили c++ и qt удалось сделать нормальный альтернативный гуй. Когда все ушло на дотнет, то продукты борланда действительно стали отставать и цепляться за паскаль смысла вообще не стало, последние калеки пилящие десктопные приложения перешли на c# и все
Здравствуйте, Kocur, Вы писали:
K>Где Борланд свернул не туда? Почему просрали такой ВЕЛИКИЙ продукт?
Думаю, начало поворота было, когда решили переименоваться в Inprise, параллельно с раздуванием чувства собственного величия и цен на свои изделия. Это примерно в 1997-м году произошло. Но на чем конкретно уже споткнулись — это на Delphi 8 в 2003-м, которая предназначалась исключительно для разработки под .NET. При этом отказались от VCL и нативной компиляции. Решили, что смогут тут напрямую конкурировать с MS со средствами разработки под MS-овский же продукт. Но что-то пошло не так...
Но может еще раньше не то, что не туда свернули, но задержались с развитием. Delphi 1 появилась поздновато — в 1995-м году, не поддерживала 32-битный софт и предназначалась для разработки софта под Win 3.x. Хотя была совместима с 95-й. И это в году, когда вышла 95-я винда, а NT уже пару лет было. Концептуально (дизайнер форм, обработчики событий для интерфейсных элементов, выбор компонент) Delphi при этом была похожа на Visual Basic, хотя и выгодно отличалась от него. Но первый VB то вышел еще в 1991-м году. А версия VB в 1995-м могла создавать и 32-битные программы.
Здравствуйте, rudzuk, Вы писали:
R> Сейчас у Delphi все хорошо: поддержка всех актуальных платформ и недосягаемая для конкурентов юзабельность и скорость разработки.
По отзывам (сам уже не пробую) эта поддержка довольно кривая. Впрочем дело даже не в ней, а в том, что непонятно зачем кому-то надо сейчас начинать новый проект на Delphi? Получается вендорлок на недешевую проприетарную вещь, причем малоизвестную.
M>Но может еще раньше не то, что не туда свернули, но задержались с развитием. Delphi 1 появилась поздновато — в 1995-м году, А версия VB в 1995-м могла создавать и 32-битные программы.
Та не!
Уже Delphi 2 в в 1996-м году делала 32-битные программы
Здравствуйте, Kocur, Вы писали:
K>Помню 1998 год. Тогда процентов 80 (если не больше) знакомых писали на Delphi. K>Удобная среда, быстрая разработка действительно работающих программ.
Кто эти 80%? Я попробовал Delphi, потом перешёл на VC++ 6 и первая работа программистом была на нём. Писал свои компоненты на делфи, но 99% делфистов было "если для проблемы нет компонента, — проблема нерешаемая". VC++ 6-й рвал дельфю по производительности.
Здравствуйте, Kocur, Вы писали:
K>Та не! K>Уже Delphi 2 в в 1996-м году делала 32-битные программы
В 1996-м позволяла, в 1995-м еще нет. И на тот момент это было существенное опоздание. По-хорошему, вообще должны была быть еще в 1991-92-м году версия борланд паскаля с поддержкой 32-бит через экстендеры.
Здравствуйте, Kocur, Вы писали:
M>>В 1996-м позволяла, в 1995-м еще нет. И на тот момент это было существенное опоздание.
K>не было
Сейчас как-то не ощущается темп 90-х, поэтому может казаться, что опоздание на год-два ничего не значит. Тогда все быстрее менялось. И железо и актуальный софт. Причем переход 16 бит — 32 бита это было не как 32/64. В общем повторю, первая Delphi была вещь для разработки под Win 3.x, в то время как в 95-м она уже стремительно устаревала с появлением Win95. Еще и OS/2 подпирала и NT и все 32-битные.
Да, продукт получился хорошим и быстро завоевал популярность и все же, по-моему, темп был упущен. Критичным это не стало, но потом пошли и другие косяки.
Здравствуйте, Michael7, Вы писали:
M>Сейчас как-то не ощущается темп 90-х, поэтому может казаться, что опоздание на год-два ничего не значит. Тогда все быстрее менялось. И железо и актуальный софт. Причем переход 16 бит — 32 бита это было не как 32/64. В общем повторю, первая Delphi была вещь для разработки под Win 3.x, в то время как в 95-м она уже стремительно устаревала с появлением Win95. Еще и OS/2 подпирала и NT и все 32-битные.
Ну хз, как подпирало. Во-первых, приложения 16 бит работали в 95ой, да и в NT, думаю, тоже.
В ВУЗ я поступил в 96, в первом семестре были основы какие-то компьютерные, на них мы изучали Windows 3.11 For Workgroups.
Потом, году в 97ом, я нашел в фидошке халтуру — написать приложуху под винду, и надо было писать на первой дельфи. Там надо было клавиатурный ввод в диалогах по-особенному обработать, нестандартно — суть в том, что чел ходит с ноутом и снимает показания с разных датчиков, вроде тупо смотрит на индикаторы, и вводит в прогу, и чтобы одной рукой держать ноут, а другой жмакать, и было задумано нестандартное поведение. Суть в том, что заказал чел из Шлюмберже, и Win16 было принципиальным требованием. Т.е. изучение 16ти-битной винды в вузе можно отнести к российской отсталости, но Шлюмберже, даже российский филиал, вряд ли был отсталой конторой
M>Да, продукт получился хорошим и быстро завоевал популярность и все же, по-моему, темп был упущен. Критичным это не стало, но потом пошли и другие косяки.
Косяки пошли, когда они на .NET перехали. А так, на седьмой дельфе я и в 2008ом еще клепал проги для автоматизации бизнеса аптечной сети
Когда ругают Delphi на форумах,
то внутри немножко улыбаюсь.
Delphi мне помог создать софт, которым пользуются сейчас десятки тысяч человек и который принес несколько миллионов долларов.
И изменил мою жизнь как я и не мечтал. И среди моих друзей тоже есть те, кто сейчас зарабатывают с помощью своего софта на Delphi.
А форумные активисты могут продолжать ругать Delphi и рассказывать про чудесные другие языки.
Лучший инструмент тот, с помощью которого можно изменить свою жизнь к лучшему.
K>говорят, седьмая была лучшей
Мы переехали на современные варианты и они тоже вполне хороши.
Здравствуйте, Kocur, Вы писали:
M>>Косяки пошли, когда они на .NET перехали. А так, на седьмой дельфе я и в 2008ом еще клепал проги для автоматизации бизнеса аптечной сети
K>говорят, седьмая была лучшей
Если честно, принципиальных отличий 7ки от 5ки не помню, 5ка тоже была весьма неплоха
Здравствуйте, Pzz, Вы писали:
Pzz>О Борланда не было особых шансов: просто кто-то ехал по своим делам на паровом катке, и их, Борланда, домик оказался у катка на дороге.
И в чём это выражается? По-моему Борланд во всём виноват сам — они распылили ресурсы (Kylix, Delphi for .net и прочее). При этом они не развивали базу собственного продукта: АТД появились уже в эмбаркадере, дженерики ЕМНИП тоже, их сетвевые библиотеки, во главе с indy представляли из себя мерзкое убожище. Я когда-то писал на делфе, и сам себе делал стэк, очередь, хэшсет — это ппц.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Michael7, Вы писали:
M>Сейчас как-то не ощущается темп 90-х, поэтому может казаться, что опоздание на год-два ничего не значит. Тогда все быстрее менялось. И железо и актуальный софт. Причем переход 16 бит — 32 бита это было не как 32/64. В общем повторю, первая Delphi была вещь для разработки под Win 3.x, в то время как в 95-м она уже стремительно устаревала с появлением Win95. Еще и OS/2 подпирала и NT и все 32-битные.
Интересно, где у тебя все так молниеносно менялось в 90х?
Реально используемых полезных прикладных продуктов и заказов на разработку под Винду (тем более под 32) было кот наплакал.
Большинство контор сидело практически еще на Досовских продуктах (кто-то чуть ли не до 2000х), а в 3ей Винде только пасьянсы раскладывали.
95ая вообще официально вышла в августе 95го. Массово применяться на рабочих компах стала скорее в 97ом.
А ты говоришь Дельфя отставала с поддержкой 32 бит.
Многие и рады были бы испытать когнитивный диссонанс, но нечем.
Здравствуйте, Kocur, Вы писали:
R>>Сейчас у Delphi все хорошо: поддержка всех актуальных платформ и недосягаемая для конкурентов юзабельность и скорость разработки.
K>гамно делает твоя Delphi для Android
Здравствуйте, Michael7, Вы писали:
R>> Сейчас у Delphi все хорошо: поддержка всех актуальных платформ и недосягаемая для конкурентов юзабельность и скорость разработки.
M>По отзывам (сам уже не пробую) эта поддержка довольно кривая.
Это, как смотреть и с чем сравнивать .
M>Впрочем дело даже не в ней, а в том, что непонятно зачем кому-то надо сейчас начинать новый проект на Delphi?
А почему нет? Инструмент-то отличный. Куча коробочного софта пишется на Delphi. Ну не к МС же в телегу прыгать, которые сами не могут разобраться на чем они предлагают писать гуй из 100500 своих и не своих гуй-фреймворков.
M>Получается вендорлок на недешевую проприетарную вещь, причем малоизвестную.
Здравствуйте, wl., Вы писали:
K>>>гамно делает твоя Delphi для Android R>>Delphi сама ничего не делает, не наговаривай.
wl.>всё правильно, никто уже практически не помнит, как писать программы на языке Паскаль
ЛПП. Только платящих клиентов более 3 млн. Сколько еще пиратящих, сколько еще на лазаре... Так что, "Оставь свои девичьи фантазии, Иванова" (c)
Здравствуйте, Matrix_Failure, Вы писали:
M_F>Когда ругают Delphi на форумах, M_F>то внутри немножко улыбаюсь.
M_F>Delphi мне помог создать софт, которым пользуются сейчас десятки тысяч человек и который принес несколько миллионов долларов.
Вот. Главное же- это приносит ли использование дельфи баблосики, или нет и вообще интересно ли в той предметной области.
M_F>И изменил мою жизнь как я и не мечтал. И среди моих друзей тоже есть те, кто сейчас зарабатывают с помощью своего софта на Delphi.
Приведи вакансии, компвнии что-ли. Я в году 2005 наверное, видел компанию, которая писала на дельфи- они пришли тогда в Ростов пилить их складскую систему. Компания славилась штрафами за опоздание на 1 минуту и метриками- нормативами, сколько десятков их говно-формочек нужно поменять в день программисту.
Да. Вот такой мне запомнилась Дельфи (я вроде испольщовал 4 и 5 версии)- простой для лепки повторяющихся незамысловатых форм, сливающей по скорости исполнения VC++ 6 в десятки раз, не дающей простоты при любой чуть шаг влево-шаг вправо задаче. А была ещё C++ Builder — там архитекты накурились тяжёлыми наркотиками и сделали обвязку VCL из дельфи (тормозной паскаль) на C++.
M_F>Delphi мне помог создать софт, которым пользуются сейчас десятки тысяч человек и который принес несколько миллионов долларов. M_F>И изменил мою жизнь как я и не мечтал. И среди моих друзей тоже есть те, кто сейчас зарабатывают с помощью своего софта на Delphi.
Здравствуйте, Kocur, Вы писали:
K>Уже в 2012 никого из знакомых на Delphi не осталось.
K>Где Борланд свернул не туда? Почему просрали такой ВЕЛИКИЙ продукт?
У них было очень точечное позиционирование.
Технологии вне Дельфи менялись, и очень быстро. Кроме как быстрой разработки в дельфях было мало чего хорошего. Чем ниже уровень, тем больше граблей.
Дельфи это чисто десктоп. Такое начало заканчиваться в середине нулевых. Потом все перешло на веб+бакенд.
Здравствуйте, Артём, Вы писали:
Аё>Да. Вот такой мне запомнилась Дельфи (я вроде испольщовал 4 и 5 версии)- простой для лепки повторяющихся незамысловатых форм, сливающей по скорости исполнения VC++ 6 в десятки раз, не дающей простоты при любой чуть шаг влево-шаг вправо задаче.
Странно, у меня сложилось впечатление, что Дельфи генерил весьма быстрый код. Может, у вас там просто криворукие программисты сидели? Да и зачем в незамысловатых формах какое-то быстродействие?
Аё>А была ещё C++ Builder — там архитекты накурились тяжёлыми наркотиками и сделали обвязку VCL из дельфи (тормозной паскаль) на C++.
Билдер был хорош, я им ещё с первой версии пользовался. Та же простота построения гуя, как в Дельфи, плюс мощь плюсиков. Единственно, очень долго собирал
M>Ну хз, как подпирало. Во-первых, приложения 16 бит работали в 95ой, да и в NT, думаю, тоже.
Работали. И даже в OS/2 работали.
M> Суть в том, что заказал чел из Шлюмберже, и Win16 было принципиальным требованием. Т.е. изучение 16ти-битной винды в вузе можно отнести к российской отсталости, но Шлюмберже, даже российский филиал, вряд ли был отсталой конторой
Да, Win3.x была еще востребована и даже средства разработки под нее, еще где-то до 2000-го года, иногда и больше. Могу привести аналогичные примеры, что тоже на одной из работ даже еще в начале нулевых, требовалась совместимость.
Но мы ведь говорим про компанию, которая началась как разработчик удобных компиляторов и IDE и представляется, что для лидирующего положения на рынке необходимо было выпускать актуальные для нового железа и софта средства. А вот с этим у борланда что-то пошло не так. Хотя, надо отметить, что Borland C++ был заметно более актуализированным и даже, емнип, уже в 1992-м имелись дополнения для создания 32-битных программ для MS-DOS, чего не стали делать для Паскаль-среды.
M>Косяки пошли, когда они на .NET перехали. А так, на седьмой дельфе я и в 2008ом еще клепал проги для автоматизации бизнеса аптечной сети
Да, 7-я дельфи стала, можно сказать, вершиной развития борландовской дельфи, своего рода классикой.
Здравствуйте, paucity, Вы писали:
P>Здравствуйте, Michael7, Вы писали:
M>>Сейчас как-то не ощущается темп 90-х, поэтому может казаться, что опоздание на год-два ничего не значит. Тогда все быстрее менялось. И железо и актуальный софт. Причем переход 16 бит — 32 бита это было не как 32/64. В общем повторю, первая Delphi была вещь для разработки под Win 3.x, в то время как в 95-м она уже стремительно устаревала с появлением Win95. Еще и OS/2 подпирала и NT и все 32-битные.
P>Интересно, где у тебя все так молниеносно менялось в 90х?
Не поверишь, но в институте. Все-таки реальной наукой занимались, в том числе, в связи с Курчатовским институтом и те же 32 бита еще как востребованы были. В том числе из-за линейной адресации памяти. Помню компы с Pentium Pro под WinNT уже в начале 1996-х стояли и на них работали. В том числе двухпроцессорные конфигурации с 64-128 Мб RAM. Конечно использовались совсем другие компиляторы, например, NDP Fortan и NDP C, в том числе для машин Dec и процессоров Альфа, но хотелось более удобных IDE Borland, в том числе Delphi. С высоты времени это несколько блажью кажется, да и борланды кажется особо не позиционировались для чего-то связанного с научными или инженерными расчетами, но все-таки.
M>Но мы ведь говорим про компанию, которая началась как разработчик удобных компиляторов и IDE и представляется, что для лидирующего положения на рынке необходимо было выпускать актуальные для нового железа и софта средства. А вот с этим у борланда что-то пошло не так. Хотя, надо отметить, что Borland C++ был заметно более актуализированным и даже, емнип, уже в 1992-м имелись дополнения для создания 32-битных программ для MS-DOS, чего не стали делать для Паскаль-среды.
А у Борланда были актуальные среды для разработки под винду
В 1991 году вышла версия 3.0 с поддержкой сборки Windows-приложений. Спустя год вышло обновление 3.1, в котором был реализован оконный IDE и шаблоны приложений OWL 1.0 и Turbo Vision 1.0.
Начиная с версии 4.0 (1993 год) в продукте удалена поддержка сборки MS-DOS приложений, и IDE стал полностью Windows-ориентированным. В 1995 году вышла 4.52 с поддержкой Windows 95 и OWL 2.5. В марте 1996 года выходит 5.0, которая стала поддерживать Windows NT 3.51 (Windows NT 4.0 тогда ещё была в разработке).
А вот борландовский экстендер что-то не взлетел, dos4gw тут выиграл
Здравствуйте, rudzuk, Вы писали:
M>>По отзывам (сам уже не пробую) эта поддержка довольно кривая.
R>Это, как смотреть и с чем сравнивать .
Не буду спорить, этих устриц я не ел, но все же сложилось такое впечатление.
M>>Впрочем дело даже не в ней, а в том, что непонятно зачем кому-то надо сейчас начинать новый проект на Delphi?
R>А почему нет? Инструмент-то отличный. Куча коробочного софта пишется на Delphi. Ну не к МС же в телегу прыгать, которые сами не могут разобраться на чем они предлагают писать гуй из 100500 своих и не своих гуй-фреймворков.
Сейчас нативный гуй вообще стал малопопулярным, типа сервер (в т.ч. локальный) + браузер наше все, а где пишется и чтобы кросплатформенный, то часто на электроне. Или Qt, если что-то менее тормозное хочется. Lazarus недооценен, по-моему. React Native стремительно модным становится и для мобильного и для десктопного софта.
M>>Получается вендорлок на недешевую проприетарную вещь, причем малоизвестную.
R>Delphi мало известная? В десятке TIOBE
Может я в своем инфопузыре кручусь, но как-то молодежь про Delphi, по-моему, вообще редко слышала.
Здравствуйте, Marty, Вы писали:
M>А у Борланда были актуальные среды для разработки под винду
Я не говорил, что не было сред под винду. Я о том, что Delphi появилась только в 1995-м и как ни крути, но уже устаревающей винды. А с 32-битной поддержкой вообще были проблемы. Так-то был Turbo Pascal for Windows, емнип, еще в 1991-м году. Если бы Delphi оказалась первой средой такого рода вообще, то может и ничего, но у MS их Visual Basic еще в 1991-м появился. Так что 1-й Delphi стоило появиться хотя бы на год раньше.
M>А вот борландовский экстендер что-то не взлетел, dos4gw тут выиграл
В том числе потому что тоже опоздал. Экстендеры от PharLap и dos4gw их опередили, емнип, тоже на год, если не больше.
LVV>>Когда Филип Кан ушел. U>не спас бы. если хаос заложен в концепт разработки, ни к чему хорошему это не приведет U>уверен, что известный сорт кофе тоже сгниет рано или поздно, если в мс не полные кретины сидят сейчас, конечно.
Ну, пока он был у руля, у Борланда проблем не было...
Совпадение ?
Не думаю...(с)
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Marty, Вы писали:
Аё>>Да. Вот такой мне запомнилась Дельфи (я вроде испольщовал 4 и 5 версии)- простой для лепки повторяющихся незамысловатых форм, сливающей по скорости исполнения VC++ 6 в десятки раз, не дающей простоты при любой чуть шаг влево-шаг вправо задаче.
M>Странно, у меня сложилось впечатление, что Дельфи генерил весьма быстрый код.
Мой пример из жизни- трансляция символов путём обращения к массиву по индексу, на дельфи ужасно тормозило, скажем, 20 секунд. На целероне 300 если что . Я написал асм вставку, стало 0.001секунд. Потом написал такое же на VC++ 6- заняло столько же 0.001 секунд без асм вставки.
M> Может, у вас там просто криворукие программисты сидели? Да и зачем в незамысловатых формах какое-то быстродействие?
Проф. программировать я начал на VC++ 6 и там требовалось быстродействие.
Аё>>А была ещё C++ Builder — там архитекты накурились тяжёлыми наркотиками и сделали обвязку VCL из дельфи (тормозной паскаль) на C++.
M>Билдер был хорош, я им ещё с первой версии пользовался. Та же простота построения гуя, как в Дельфи, плюс мощь плюсиков. Единственно, очень долго собирал
Построение гуя уровня школоты, из кубиков лего. Что-то более навороченное, кастомное- "для такого компонент не написали".
Ещё кирпич в огород борланда с его паскалем- делал лабораторку на турбо паскале с матричными операциями (решение системы уравнений или типа того)- вылез известный на тот момент баг с арифметикой, типа на пне 1 норм а на пне 2 оно глюкало. ЧСХ у Си-шников такой проблемы не было (MS C вроде- смежная специальность группа, пересекались). Но тогда я ещё не знал C.
Здравствуйте, Артём, Вы писали:
M>>Странно, у меня сложилось впечатление, что Дельфи генерил весьма быстрый код. Аё>Мой пример из жизни- трансляция символов путём обращения к массиву по индексу, на дельфи ужасно тормозило, скажем, 20 секунд. На целероне 300 если что . Я написал асм вставку, стало 0.001секунд. Потом написал такое же на VC++ 6- заняло столько же 0.001 секунд без асм вставки.
Что такое "трансляция символов"? Табличная подстановка? Я думаю, ты какую-то кривую херню там сделал
M>>Билдер был хорош, я им ещё с первой версии пользовался. Та же простота построения гуя, как в Дельфи, плюс мощь плюсиков. Единственно, очень долго собирал Аё>Построение гуя уровня школоты, из кубиков лего. Что-то более навороченное, кастомное- "для такого компонент не написали".
На Дельфи можно и нормальный гуй было делать. А билдер я использовал как раз потому, что на Паскале не было кучи плюсовых фич, из-за чего писать код там было, мягко скажем, неудобно.
Я как раз на билдере и писал то, для чего не было стандартных компонентов
Аё>Ещё кирпич в огород борланда с его паскалем- делал лабораторку на турбо паскале с матричными операциями (решение системы уравнений или типа того)- вылез известный на тот момент баг с арифметикой, типа на пне 1 норм а на пне 2 оно глюкало. ЧСХ у Си-шников такой проблемы не было. Но тогда я ещё не знал C.
Бага была в проце, и как раз в ранних первых пнях. У сишников были бы те же проблемы, так как бага аппаратная.
Гугл ничего не знает о багах в плавучке, специфических именно для Дельфи
Здравствуйте, Артём, Вы писали:
Аё>Ещё кирпич в огород борланда с его паскалем- делал лабораторку на турбо паскале с матричными операциями (решение системы уравнений или типа того)- вылез известный на тот момент баг с арифметикой, типа на пне 1 норм а на пне 2 оно глюкало.
Ничего не путаешь, баг именно с арифметикой? Помню был баг Runtime 200, возникавший в модуле CRT из-за багованного счетчика производительности для задержек. Там было измерение времени исполнения фиксированного числа циклов. Где-то примерно с P200-PII оно начало становиться нулевым в пределах погрешности и возникала ошибка деления на ноль. Были патчи как для стандартной борландовской библиотеки, так и для готовых экзешников.
Здравствуйте, Marty, Вы писали:
M>Бага была в проце, и как раз в ранних первых пнях. У сишников были бы те же проблемы, так как бага аппаратная.
Бага (FDIV Pentium bug) была довольно редкая, на нее еще надо было суметь нарваться. Для некоторых специфических сочетаний делимого и делителя результат получался с повышенной погрешностью, емнип после 4-го знака после запятой. Сомневаюсь, что его можно было заметить в студенческих лабах.
M>Гугл ничего не знает о багах в плавучке, специфических именно для Дельфи
Вероятно это т.н. ошибка Runtime 200 на слишком быстрых процессорах. Сообщением выше написал о ней. Но это не арифметическая ошибка, а баг в коде счетчика производительности в модуле CRT.
U>а вот ТАКАЯ! че ты услышать хотел? лично что мне в мс нравится — отсутствие хаоса, что они поощряют в отличие от. где каждый херачит кто во что горазд.
У микрософта есть (был) хорошой инженерный подход, думаю это наследие Катлера.
Но у них беда с менеджентом, изза чего все инженерно хорошие вещи они часто просирают.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Kocur, Вы писали:
K>Помню 1998 год. Тогда процентов 80 (если не больше) знакомых писали на Delphi.
Это (широкое распространение Delphi), кажется, и правда было особенностью России. В остальном мире популярны были другие языки и среды.
(К сожалению, с цифрами я это подтвердить не могу — скорее личные ощущение, и обсуждение со "старшими товарищами" этого момента в районе 2000-х)
K>Где Борланд свернул не туда? Почему просрали такой ВЕЛИКИЙ продукт?
Подобный вопрос на этом форуме задавался не раз.
Вот, например, одно из подобных обсуждений (10 лет назад — как время летит!) https://rsdn.org/forum/tools/5950132.1
Просто навскидку из того что перечисляли:
— не успевали за сменой тенденций в разработке. По сути, самое сильное в Delphi было — разработка desktop под Windows. Остальное или так толком и не появилось (Web — только не очень очевидные сторонние решения) или появилось с большим опозданием: мобильная разработка, кроссплатформенная разработка, ...
— серьезные проблемы с качеством
— неудачные метания/эксперименты (те же Delphi.Net (8-я), Kylix/CLX), которые съели не мало ресурсов, но результат особо не дали.
— не самые доступные цены и достаточно неудобные лицензии (на фоне или вообще бесплатных или довольно недорогих версий у конкурентов)
Ну и, конечно, все эти переходы из рук в руки, доверия к будущему продукта ну никак не добавляли.
K>Насколько я понял, сейчас им владеет какая-то Эмбаркадера. Интересно, какие у них финансовые показатели?
Так это с 2008, т.е. она Борланду принадлежала меньше по времени, чем текущему владельцу (если считать, что Delphi 1 — это 1995 год).
Здравствуйте, yoyozhik, Вы писали:
Y>И есть теперь что то сравнимое с инструментами Борланд в нашем безумном мире ИИ?
Qt. Он кроссплатформенный работает от десктопов до эмбедщины. А когда Дельфи расцветал, был мир десктопов на винде и этот ваш говно мамонта Юникс, и какая-то там опенсорс-поделка Линукс. Никто особо о кроссплатформенности не думал. А она очень сильно отрасль изменила.
Все долгоживущие платформы подразумевали кроссплатформенность. UNIX/C, C++, Java, PHP, go, rust, JS, python.
K>>Помню 1998 год. Тогда процентов 80 (если не больше) знакомых писали на Delphi. МР>Это (широкое распространение Delphi), кажется, и правда было особенностью России. В остальном мире популярны были другие языки и среды.
Просто у нас в школах Паскаль был в качестве учебного языка, вот и результат.
Сейчас в США учебный язык питон — и теперь он везде вокруг.
Вобщем хочешь продвинуть свой язык — сделай его понятным школьникам и так сказать пролоббируй его в школах.
Как много веселых ребят, и все делают велосипед...
K>>Где Борланд свернул не туда? Почему просрали такой ВЕЛИКИЙ продукт? Pzz>До MS дошло, что если ты владеешь самой распространенной платформой в мире, неплохо бы еще и инструменты к этой платформе под себя подгрести.
И дошло это до них когда Борланд решил поиграть в кроссплатформ выпустив Kylix. Возможно МС узрела в этом реальную угрозу винде, и подергала за какието невидимые нам ниточки, результатом чего стало вначале переход Борланда на .НЕТ, а потом и вообще полный кирдык.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Артём, Вы писали:
M>>Странно, у меня сложилось впечатление, что Дельфи генерил весьма быстрый код. Аё>Мой пример из жизни- трансляция символов путём обращения к массиву по индексу, на дельфи ужасно тормозило, скажем, 20 секунд. На целероне 300 если что . Я написал асм вставку, стало 0.001секунд. Потом написал такое же на VC++ 6- заняло столько же 0.001 секунд без асм вставки.
Может тебе забыли рассказать об отключаемой проверке границ, при работе с массивами Так-то, со скоростью все весьма не плохо
.
Аё>Ещё кирпич в огород борланда с его паскалем- делал лабораторку на турбо паскале с матричными операциями (решение системы уравнений или типа того)- вылез известный на тот момент баг с арифметикой, типа на пне 1 норм а на пне 2 оно глюкало. ЧСХ у Си-шников такой проблемы не было (MS C вроде- смежная специальность группа, пересекались). Но тогда я ещё не знал C.
Turbo Pascal закончился в начале 1994. Баг с пентиумной плавучкой (Pentium FDIV) вылез в конце 1994 (в Delphi для него предусмотрен воркараунд). Второй пень вообще через три года вышел.
Здравствуйте, Артём, Вы писали:
Аё>Да. Вот такой мне запомнилась Дельфи (я вроде испольщовал 4 и 5 версии)- простой для лепки повторяющихся незамысловатых форм, сливающей по скорости исполнения VC++ 6 в десятки раз, не дающей простоты при любой чуть шаг влево-шаг вправо задаче. А была ещё C++ Builder — там архитекты накурились тяжёлыми наркотиками и сделали обвязку VCL из дельфи (тормозной паскаль) на C++.
Турбовижн на паскале был довольно компактным. Плюсовый вариант это просто чудовище, ни в какую память не влазило.
Здравствуйте, Marty, Вы писали:
M>Странно, у меня сложилось впечатление, что Дельфи генерил весьма быстрый код. Может, у вас там просто криворукие программисты сидели? Да и зачем в незамысловатых формах какое-то быстродействие?
Генерил может и быстрый, но тамошняя орхетектура это слои слоев.
Здравствуйте, Pauel, Вы писали:
M>>Странно, у меня сложилось впечатление, что Дельфи генерил весьма быстрый код. Может, у вас там просто криворукие программисты сидели? Да и зачем в незамысловатых формах какое-то быстродействие?
P>Генерил может и быстрый, но тамошняя орхетектура это слои слоев.
Да не так уж чтобы и слои слоёв, но это не важно, код она генерила неплохо, а Тёмчикова задача с таблицей никаким боком к "орхетектуре" VCL не имеет отношения.
Впрочем, как я понял, Тёмчик страдал по ТурбоПаскалю, там никаких слоёв слоёв нет, там максимум была ТурбоВижн, которая проста, как пробка. Ну и ТурбоПаскаль тоже не был тормозом, вполне был шустрый
Здравствуйте, rudzuk, Вы писали:
Аё>>Ещё кирпич в огород борланда с его паскалем- делал лабораторку на турбо паскале ....
R>Turbo Pascal закончился в начале 1994. Баг с пентиумной плавучкой (Pentium FDIV) вылез в конце 1994 (в Delphi для него предусмотрен воркараунд). Второй пень вообще через три года вышел.
В 2002 году, настолько хорошие знакомые, что не мог им отказать, "сосватали" мне девочку, чтоб помогать ей с лабораторками и курсовыми по программированию за небольшую мзду.
Отгадай, что мне пришлось доставать из архивов?
Многие и рады были бы испытать когнитивный диссонанс, но нечем.
Здравствуйте, paucity, Вы писали:
p> R>Turbo Pascal закончился в начале 1994. Баг с пентиумной плавучкой (Pentium FDIV) вылез в конце 1994 (в Delphi для него предусмотрен воркараунд). Второй пень вообще через три года вышел.
p> В 2002 году, настолько хорошие знакомые, что не мог им отказать, "сосватали" мне девочку, чтоб помогать ей с лабораторками и курсовыми по программированию за небольшую мзду.
p> Отгадай, что мне пришлось доставать из архивов?
Я этому нисколько не удивлен, потому что TP или Delphi 7 пользуются даже сейчас. Я о том, что пенять на компилятор, последняя версия которого вышла раньше, чем обнаружились проблемы в процах, это несколько странно
Здравствуйте, Marty, Вы писали:
M>Что такое "трансляция символов"? Табличная подстановка? Я думаю, ты какую-то кривую херню там сделал
Конвертация кириллицы кодировки. Да, херня было использовать дельфи.
M>>>Билдер был хорош, я им ещё с первой версии пользовался. Та же простота построения гуя, как в Дельфи, плюс мощь плюсиков. Единственно, очень долго собирал Аё>>Построение гуя уровня школоты, из кубиков лего. Что-то более навороченное, кастомное- "для такого компонент не написали".
M>На Дельфи можно и нормальный гуй было делать.
Можно кастомные компоненты делать, но разница в скорости разработки пропадала. А тогда зачем вообще дельфи нужен, если взрослые пасаны делали на VC6 и без асм вставок.
M>Я как раз на билдере и писал то, для чего не было стандартных компонентов
Кастомные компоненты полностью на C++? Который наследуется от паскалевского класса. Зашибись.
M>Бага была в проце, и как раз в ранних первых пнях. У сишников были бы те же проблемы, так как бага аппаратная.
У MS-сишников не было той проблемы. Может, у борланд C она была- хз.
Здравствуйте, rudzuk, Вы писали:
R>Может тебе забыли рассказать об отключаемой проверке границ, при работе с массивами
Тогда теряется смысл в паскале
Кста я игрался с ключиками- отключение проверки сразу x2 к производительности давало. Что как бэ намекает на ненужность паскаля.
Здравствуйте, rudzuk, Вы писали:
R>Я о том, что пенять на компилятор, последняя версия которого вышла раньше, чем обнаружились проблемы в процах, это несколько странно
У MS C не было той проблемы, хотя он тоже был старым. Турбо паскаль использовался на лабах, да он был старым. За Си меня бы не поругали, просто его не было в программе и я его тогда не знал. Паскаль я знал с 5-6 класса школы.
Здравствуйте, Артём, Вы писали:
M>>Что такое "трансляция символов"? Табличная подстановка? Я думаю, ты какую-то кривую херню там сделал Аё>Конвертация кириллицы кодировки. Да, херня было использовать дельфи.
В любом случае, хоть Дельфи, хоть ТурбоПаскаль — что-то ты сделал через жопу. И эта жопа была не в Дельфи или ТП
M>>На Дельфи можно и нормальный гуй было делать. Аё>Можно кастомные компоненты делать, но разница в скорости разработки пропадала. А тогда зачем вообще дельфи нужен, если взрослые пасаны делали на VC6 и без асм вставок.
Ты много делал кастомных "компонент" на VC6? Ноль целых ноль десятых? А я, так-то, делал свои классы виндовых контролов, вернее, контролов, полностью совместимых с виндовой идеологией и которые можно использовать в любых виндовых приложениях. А ты, видимо, что-то на MFC лабал, унаследовался от чего-то, пару событий перехватил, и типа сделал свой контрол. Так на VCL это элементарно делалось
M>>Я как раз на билдере и писал то, для чего не было стандартных компонентов Аё>Кастомные компоненты полностью на C++? Который наследуется от паскалевского класса. Зашибись.
Нет, на VCL я делал интерфейс, а на плюсах решал прикладную задачу. Но вообще да, не было проблем отнаследоваться от класса VCL и сделать что-то своё на плюсах.
Нужды в кастомных компонентах не возникало, хватало стандартных, +JDLib, да настройки имеющихся
M>>Бага была в проце, и как раз в ранних первых пнях. У сишников были бы те же проблемы, так как бага аппаратная. Аё>У MS-сишников не было той проблемы. Может, у борланд C она была- хз.
Ты даже проблему не смог идентифицировать, о чем тут говорить? Если это вообще была проблема, а не твои кривые руки.
Здравствуйте, Артём, Вы писали:
Аё>У MS C не было той проблемы, хотя он тоже был старым. Турбо паскаль использовался на лабах, да он был старым. За Си меня бы не поругали, просто его не было в программе и я его тогда не знал. Паскаль я знал с 5-6 класса школы.
Баги есть везде. Ты наверняка и сейчас кучу времени тратишь на борьбу с багами в чужих либах. Но поныть ты решил за Дельфи/ТурбоПаскаль, от того, что тебе оно детскую травму нанесло при сдаче лабораторки
Здравствуйте, Артём, Вы писали:
R>>Может тебе забыли рассказать об отключаемой проверке границ, при работе с массивами Аё>Тогда теряется смысл в паскале Аё>Кста я игрался с ключиками- отключение проверки сразу x2 к производительности давало. Что как бэ намекает на ненужность паскаля.
Ты же щас на всяких джавах пишешь? Перепиши на плюсах, получишь x10 производительности. Возможно, это намекнёт тебе на ненужность твоих джав
Здравствуйте, Marty, Вы писали:
M>В любом случае, хоть Дельфи, хоть ТурбоПаскаль — что-то ты сделал через жопу. И эта жопа была не в Дельфи или ТП
Ещё раз — на Дельфи проблема тормозов решалась ASM вставкой, но на плюсах и так было быстро. Что ещё нужно тебе объяснять? ДА я писал в то время на x86 ASM-е тоже. После перехода на VC++ — только хаковые thunk-и, которых потом похерили с защитой исполняемого кода.
A thunk usually refers to a small piece of code that is called as a function, does some small thing, and then JUMPs to another location (usually a function) instead of returning to its caller.
M>Ты много делал кастомных "компонент" на VC6? Ноль целых ноль десятых?
Много. Если ты не заметил — любой мало-мальски продвинутый чарт, редактор, грид — это кастомный компонент. В то время я писал на MFC+WTL.
M>Нет, на VCL я делал интерфейс, а на плюсах решал прикладную задачу.
Т.е. формошлёпил. ЧТД.
M>Нужды в кастомных компонентах не возникало, хватало стандартных, +JDLib, да настройки имеющихся
+1 к формошлёпил. ЧТД.
M>Ты даже проблему не смог идентифицировать, о чем тут говорить? Если это вообще была проблема, а не твои кривые руки.
Скомпилированная прога, корректный код и т.п. тупо падала без видимой причины на одном компе и работала на другом. По причине толи хака толи ещё чего, использованного Борландом на старых процах, а более новые процы это поломали.
Здравствуйте, Marty, Вы писали:
M>Ты же щас на всяких джавах пишешь? Перепиши на плюсах, получишь x10 производительности. Возможно, это намекнёт тебе на ненужность твоих джав
UI пишу на Typescript, и в том числе кастомные компоненты, многопоточку (WebWorker) и т.п. Переписать на C++ (на Qt Quick) в принципе возможно, но инвестиции в это не отобъются — оно должно бегать на десктопе и на мобилках, оно бегает, в память влазит. Qt Quick предназначен для простых маленьких интерфейсов afaik в кофеварках, а у нас жирный клиент в вебе.
Жаву (микросервисы) редко трогаю.
Здравствуйте, Kocur, Вы писали:
K>Где Борланд свернул не туда? Почему просрали такой ВЕЛИКИЙ продукт?
Если кратко, то появление Java и .NET Framework было основной причиной.
А так, Java и .NET многим дали поддых, не только Дельфе. Судя по всему, в США в 90-е роль Дельфей наряду с Visual Basic играл часто и Смолток — средство для создания корпоративных клиентских приложений для доступа к базе данных. Кстати, это одна из главных ниш и Дельфей тоже. Если помните, было такое классное средство как Visual Age for Smalltalk. Ну, и где этот Смолток сейчас? Так, что-то осталось от былой славы, бледная тень.
Ну, а то, что Дельфи были популярны в России, разве это сильно помогло Борланду? Разве многие платили деньги? Риторический вопрос.
Здравствуйте, Marty, Вы писали:
M>Да не так уж чтобы и слои слоёв, но это не важно, код она генерила неплохо, а Тёмчикова задача с таблицей никаким боком к "орхетектуре" VCL не имеет отношения.
Дельфи это RAD, выйти за эти рамки они так и не сумели. Какой тут код генерится — дело десятое.
Типичный цикл жизни приложений на делфи — писали-писали писали, и перешли на MSVC или .Net
M>Впрочем, как я понял, Тёмчик страдал по ТурбоПаскалю, там никаких слоёв слоёв нет, там максимум была ТурбоВижн, которая проста, как пробка. Ну и ТурбоПаскаль тоже не был тормозом, вполне был шустрый
Турбовижн на паскале тоже был далеко не самым шустрым. Получше плюсового с т.з. памяти, но по перформансу очень слабоват.
Здравствуйте, Kocur, Вы писали:
D>>Ну, а то, что Дельфи были популярны в России, разве это сильно помогло Борланду? Разве многие платили деньги? Риторический вопрос.
K>А сейчас кто платит?
Вот в том и дело, что на Java и .NET гораздо реже возникает необходимость в оплате инструментов. Там можно полностью легально (смысл слова сильно размыт сейчас в 2025) вести разработку. И так было с самого начала появления этих технологий. Компиляторы у них бесплатные. Можно найти и бесплатные редакторы. Правда, с отладкой будет тяжелее, но навороченная отладка нужна не всегда (по моим ощущениям сверх-заумная отладка чаще нужна или для какого-то запущенного легаси, где на проекте команда полностью сменилась уже раз по пять или по десять, или где авторы явно злоупотребляют императивным программированием, но, тем не менее, хороший отладчик может пригодиться всегда). Да и к тому же, есть всякие Community Edition для IDE, которые подходят для небольших групп разработчиков. То есть, Java и .NET с самого начала были доступными платформами для большинства разработчиков.
Теперь пункт два. В Java и .NET — сборщики мусора. В нише корпоративного софта для доступа к БД (чуть ли не основной нише Дельфи) этого хватает за глаза, а само программирование сильно упрощается. Это доказал еще Смолток, но он по-сложнее будет как и язык, как и платформа (в использовании). Да и опять же, в 90-е основные реализации Смолтока были коммерческими, то есть не такими и доступными.
Сейчас сборщики мусора достаточно эффективны, а порой даже поражают в некоторых сценариях использования своей результативностью (например, если писать код в стиле функционального программирования, где объекты короткоживущие, и почти нет ссылок со старого поколения на новое, что позволяет быстро очищать и удалять самое молодое поколение объектов — тут даже джемаллоки и тисималлоки могут напрячься). А в случае эрланга так, вообще, сборка мусора становится soft real time (там плодятся тысячи и миллионы сборщиков мусора по одному на каждый процесс, чтобы рилтайм работал)
Здравствуйте, Marty, Вы писали:
M> Аё>У MS C не было той проблемы, хотя он тоже был старым. Турбо паскаль использовался на лабах, да он был старым. За Си меня бы не поругали, просто его не было в программе и я его тогда не знал. Паскаль я знал с 5-6 класса школы.
M> Баги есть везде. Ты наверняка и сейчас кучу времени тратишь на борьбу с багами в чужих либах. Но поныть ты решил за Дельфи/ТурбоПаскаль, от того, что тебе оно детскую травму нанесло при сдаче лабораторки
Марти, чего с тобой случилось? Я начинаю волноваться
Здравствуйте, Артём, Вы писали:
А> R>Я о том, что пенять на компилятор, последняя версия которого вышла раньше, чем обнаружились проблемы в процах, это несколько странно
А> У MS C не было той проблемы, хотя он тоже был старым. Турбо паскаль использовался на лабах, да он был старым. За Си меня бы не поругали, просто его не было в программе и я его тогда не знал. Паскаль я знал с 5-6 класса школы.
Видимо MS C был не настролько старым, раз его не задело Ну не Борланд же виноват в косяках Интела, ну...
Здравствуйте, Артём, Вы писали:
А> R>Может тебе забыли рассказать об отключаемой проверке границ, при работе с массивами
А> Тогда теряется смысл в паскале А> Кста я игрался с ключиками- отключение проверки сразу x2 к производительности давало. Что как бэ намекает на ненужность паскаля.
Смешной ты. Проверка, обычно, включается в отладочных сборках и отключается в релизных.
Здравствуйте, dsorokin, Вы писали:
d> Сейчас сборщики мусора достаточно эффективны, а порой даже поражают в некоторых сценариях использования своей результативностью
Эти боевые песни поются со времен появления Java и .NET, а по факту... Читаешь статью на хабре с описание фишек решарпера, а в комментах все жалуются, что это говно умудряется тормозить на девелоперских тачках, с кучей оперативы и быстрыми SSD. Android Studio — та же самая история. Реальность немного отличается, от бравурных лозунгов.
Здравствуйте, rudzuk, Вы писали:
R>Здравствуйте, dsorokin, Вы писали:
d>> Сейчас сборщики мусора достаточно эффективны, а порой даже поражают в некоторых сценариях использования своей результативностью
R>Эти боевые песни поются со времен появления Java и .NET, а по факту... Читаешь статью на хабре с описание фишек решарпера, а в комментах все жалуются, что это говно умудряется тормозить на девелоперских тачках, с кучей оперативы и быстрыми SSD. Android Studio — та же самая история. Реальность немного отличается, от бравурных лозунгов.
Реальность разная бывает — она многогранная. Уже давно нельзя сказать, что языки с ручным управлением памятью создают более быстрый код для абсолютно всех случаев. Уже давно так нельзя сказать. Впрочем, мы уже входим в область религии. Поэтому дальше развивать тему не стану. Замечу лишь то, что числодробилками мир программирования далеко не ограничивается. Если мало аллокаций, то спору нет, а если их много, то здесь возникают вопросы и очень большие вопросы, особенно, если граф объектов запутанный и с большим количеством циклов. Ну, ладно! Я — не проповедник.
И мы уходим от темы. Я лишь обозначил, что сборки мусора часто хватает за глаза, и это — одна из причин падения интереса к Дельфям
Здравствуйте, ononim, Вы писали:
O>Просто у нас в школах Паскаль был в качестве учебного языка, вот и результат.
Да, слышал такую версию и, пожалуй, с ней согласен.
Дополнительно, думаю, имело значение, то, что в 90-е у нас не было проблем с доступом к любому инструменту (да, не вполне законно, тут не поспоришь) и можно было брать что угодно.
А Delphi — он воспринимался как очень простой и удобный инструмент, чтобы делать профессионально выглядящие приложения (это ведь реально очень круто смотрелось, когда в лабораторных делаются не просто консольная программка, а полноценный GUI). Так что в ВУЗах (и даже в школах) Delphi стал очень популярным.
O>Вобщем хочешь продвинуть свой язык — сделай его понятным школьникам и так сказать пролоббируй его в школах.
Да, в какой-то мере так и есть, наверное.
Здравствуйте, Артём, Вы писали:
Аё>Ещё раз — на Дельфи проблема тормозов решалась ASM вставкой,
Ещё раз — ты не осилил Дельфи
Аё>но на плюсах и так было быстро. Что ещё нужно тебе объяснять? ДА я писал в то время на x86 ASM-е тоже. После перехода на VC++ — только хаковые thunk-и, которых потом похерили с защитой исполняемого кода. Аё>
Аё>A thunk usually refers to a small piece of code that is called as a function, does some small thing, and then JUMPs to another location (usually a function) instead of returning to its caller.
Я знаю, что такое thunk
M>>Ты много делал кастомных "компонент" на VC6? Ноль целых ноль десятых? Аё>Много. Если ты не заметил — любой мало-мальски продвинутый чарт, редактор, грид — это кастомный компонент. В то время я писал на MFC+WTL.
Это от убогости виндовых контролов и MFC, которое в основном только оборачивало стандартные виндовые контролы. И ты вряд ли писал всё с нуля, а только перехватывал некоторые события в сстандартных контролах. А в VCL было много чего сразу из коробки, и там легко было настраивать нестандартное поведение и вид.
M>>Нет, на VCL я делал интерфейс, а на плюсах решал прикладную задачу. Аё>Т.е. формошлёпил. ЧТД.
Типа, задеть хочешь?
M>>Нужды в кастомных компонентах не возникало, хватало стандартных, +JDLib, да настройки имеющихся Аё>+1 к формошлёпил. ЧТД.
Ты тоже формошлёпил, только делал это через боль и страдание
M>>Ты даже проблему не смог идентифицировать, о чем тут говорить? Если это вообще была проблема, а не твои кривые руки. Аё>Скомпилированная прога, корректный код и т.п. тупо падала без видимой причины на одном компе и работала на другом. По причине толи хака толи ещё чего, использованного Борландом на старых процах, а более новые процы это поломали.
Ты определись уже, Дельфи или ТурбоПаскаль. Потому что в Делфь таких проблем не было, а про проблему ТП тебе уже рассказали. Её можно было пофиксить, но у тебя мозгов не хватило на это
Здравствуйте, Michael7, Вы писали:
M>Не поверишь, но в институте. Все-таки реальной наукой занимались, в том числе, в связи с Курчатовским институтом и те же 32 бита еще как востребованы были. В том числе из-за линейной адресации памяти. Помню компы с Pentium Pro под WinNT уже в начале 1996-х стояли и на них работали. В том числе двухпроцессорные конфигурации с 64-128 Мб RAM. Конечно использовались совсем другие компиляторы, например, NDP Fortan и NDP C, в том числе для машин Dec и процессоров Альфа, но хотелось более удобных IDE Borland, в том числе Delphi. С высоты времени это несколько блажью кажется, да и борланды кажется особо не позиционировались для чего-то связанного с научными или инженерными расчетами, но все-таки.
Не знаю, что там было в 90ых годах, но в 10ых дельфи генерила просто отвратительный код для вещ. чисел. Умудрилась сливать даже nodejs
Здравствуйте, rudzuk, Вы писали:
M>> Баги есть везде. Ты наверняка и сейчас кучу времени тратишь на борьбу с багами в чужих либах. Но поныть ты решил за Дельфи/ТурбоПаскаль, от того, что тебе оно детскую травму нанесло при сдаче лабораторки
R>Марти, чего с тобой случилось? Я начинаю волноваться
Со мной всё хорошо. Ты про то, что я не сказал, что Паскаль — говно как язык? Ну так это по умолчанию же
Здравствуйте, rudzuk, Вы писали:
R>Читаешь статью на хабре с описание фишек решарпера, а в комментах все жалуются, что это говно умудряется тормозить на девелоперских тачках, с кучей оперативы и быстрыми SSD.
Это проблема решарпера, в ванильной студии всё шустро.
Здравствуйте, Jack128, Вы писали:
J>Не знаю, что там было в 90ых годах, но в 10ых дельфи генерила просто отвратительный код для вещ. чисел. Умудрилась сливать даже nodejs
Она и в 90-х такой же генерировала, ассемблерные вставки в критических местах ускоряли FPU x87-й код буквально раз в 10, если не больше. Так что я и сказал, что с высоты времени попытки там использовать софт от Borland выглядят неправильным подходом. Тем не менее, GUI имело значение тоже, да и с ассемблерными вставками скорость уже нормальной была.
Кстати, тогда еще об одном косяке можно говорить. То, что они похоже совсем забили на оптимизацию кода. В отличие от них компиляторы MS генерировали может не самый быстрый код, но все же намного лучше.
Здравствуйте, Jack128, Вы писали:
J> Не знаю, что там было в 90ых годах, но в 10ых дельфи генерила просто отвратительный код для вещ. чисел. Умудрилась сливать даже nodejs
В 2011 вышла XE2, у которой в 64-битном режиме плавучка на SSE2.
Здравствуйте, Kocur, Вы писали:
K>А сейчас кто платит?
Вот, кстати, хороший вопрос! Возможно, ответ на него во многом определяет ответ на исходный (из вашего первого сообщения).
IDE и компиляторы — это достаточно сложные, а значит дорогие в производстве продукты.
И для закрытых продуктов основным спонсором будет компания-производитель, которая
— обеспечивает финансирование разработки IDE/компиляторов за счет их продажи
— зарабатывает на чем-то ином, а IDE/компиляторы себя не окупают, но требуются для использования вместе с другими продуктами (например, как у производителей железа) или для удержания разработчиков на своей платформе, ... или что-то в этом роде.
Так вот, я, конечно, могу что-то опускать, но у меня нынешняя картинка такова:
— коммерческих производителей IDE осталось по пальцам одной руки, из широко известных это Microsoft, JetBrains и Embarcadero (остальные это, в основном, всякие экзотические решения, типа Understand, которые позиционируются больше как инструмент для статического анализа кода)
— коммерческих (точнее, закрытых — кто из них продается, а кто отдается так, определить не всегда просто) компиляторов чуть больше, но там или какое-то в прошлом успешное legacy (типа Ada/Cobol/Fortran/Lisp/...), или С/C++ от производителя железа или операционки.
— основной заработок в IDE — продажа лицензий/подписок крупным разработчикам ПО (крупным по объему персонала, а значит лицензий), а это ныне: аутсорс, SaaS/сервисы, ... ну и может какие-то давно разрабатываемые продукты.
Так вот, мне кажется, что Borland еще когда объявила о том что сосредоточится на ПО для поддержки жизненного цикла разработки, а IDE выведет в отдельное подразделение (CodeGear, которое потом и купил Embarcadero) понимал, что не сможет зарабатывать на IDE и от них проще избавиться, чем тянуть.
МР>Так вот, мне кажется, что Borland еще когда объявила о том что сосредоточится на ПО для поддержки жизненного цикла разработки, а IDE выведет в отдельное подразделение (CodeGear, которое потом и купил Embarcadero) понимал, что не сможет зарабатывать на IDE и от них проще избавиться, чем тянуть.
А Борланд-то сама куда делась? Чем сейчас занимается?
Куда ее работники (светлые головы) разбежались? Про Хейлсберга слышал
Здравствуйте, Kocur, Вы писали:
K> А Борланд-то сама куда делась? Чем сейчас занимается?
K> Куда ее работники (светлые головы) разбежались? Про Хейлсберга слышал
Ее купила компания Micro Focus. Светлые головы выделились в CodeGear, которая продолжила разработку продуктов для разработчиков.
Здравствуйте, rudzuk, Вы писали:
R>Видимо MS C был не настролько старым, раз его не задело Ну не Борланд же виноват в косяках Интела, ну...
Борланд. Так же было с яблоками- девлоперы использовали хак с таблицей адресов или типа того, вышла следующая версия макоси (ещё до X было дело) и всё "поломала". MS C был таким же старым, и продукты старые, которые в 90% были собраны именно MS C а никаким не борландом- не сломались.
Здравствуйте, Kocur, Вы писали:
K>А Борланд-то сама куда делась? Чем сейчас занимается? K>Куда ее работники (светлые головы) разбежались? Про Хейлсберга слышал
Знаю только то, что пишут в Wikipedia.
— В 2006 они выделили все инструменты разработчика (IDE, компиляторы, InterBase) в отдельное подразделение (CodeGear), а себе оставили продукты по управлению ЖЦ ПО (ALM)
— В 2008 CodeGear был куплен Embarcadero (на тот момент достаточно известный, но не в России производитель инструментов для работы с БД), который сам был куплен в 2015 компанией Idera (которая начинала как разработчики средств бэкапирования, а потом за счет массовой покупки других компаний, собрала нехилый пакет инструментов аналитики, разработки, тестирования, ... — правда, как я понял, они не пытаются как-то это интегрировать, а просто владеют кучей брендов)
— А сам Borland был куплен в 2009-ом Micro Focus (как я понимаю, компания жила на разработке и поддержке всякого legacy — Cobol/Corba/...), который был куплен в 2022 OpenText (его я знаю только как производителя одноименной ECM + недавно узнал, что они поглотили Documentum — звезду первой величины в ECM)
Я к тому, что отследить "кто, где и как" в такой круговерти слияний и поглощений, можно только имея прямые контакты, а я ни с кем из Borland никогда не был знаком, да и за компанией не следил
Здравствуйте, Артём, Вы писали:
А> R>Видимо MS C был не настролько старым, раз его не задело Ну не Борланд же виноват в косяках Интела, ну...
А> Борланд. Так же было с яблоками- девлоперы использовали хак с таблицей адресов или типа того, вышла следующая версия макоси (ещё до X было дело) и всё "поломала". MS C был таким же старым, и продукты старые, которые в 90% были собраны именно MS C а никаким не борландом- не сломались.
Какие еще хаки, когда у пенька был аппаратный баг в команде деления???
Здравствуйте, rudzuk, Вы писали:
R>В 2011 вышла XE2, у которой в 64-битном режиме плавучка на SSE2.
там проблема была не в SSE2, а в отвратительном кодогенераторе. Грубо говоря, он все операции с плавучкой проводил через память, включая временные переменные.
То есть код вида S := Sqrt(a*a+b*b+c*c) компилировался в последовательность из
FLD a
FMUL a
FST t1
FLD b
FMUL b
FST t2
FLD t1
FADD t2
FST t1
FLD c
FMUL c
FST t2
FLD t1
FADD t2
FST t1
FLD t1
FSQRT
FST s
Когда вот такое чудо выполняется в цикле, то можно охренеть от тормозов. Поэтому даже самые безрукие разработчики вроде меня, столкнувшись с таким поведением, вкрячивали ассемблерные вставки при работе с плавающей запятой.
Ну, то есть может быть переход на SSE2 у них совпал с более вменяемым распределением локалов по регистрам — тогда, возможно, результат был чуть менее плачевным. А если нет — то увы, вот это вот тасование значений туда-сюда убивает всю производительность.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, dsorokin, Вы писали:
D>А так, Java и .NET многим дали поддых, не только Дельфе. Судя по всему, в США в 90-е роль Дельфей наряду с Visual Basic играл часто и Смолток — средство для создания корпоративных клиентских приложений для доступа к базе данных. Кстати, это одна из главных ниш и Дельфей тоже. Если помните, было такое классное средство как Visual Age for Smalltalk. Ну, и где этот Смолток сейчас? Так, что-то осталось от былой славы, бледная тень.
Всё верно. Смолток умер под гнётом собственной жадности — плюсовый компилятор было решено распространять бесплатно, а смоллток был настолько прекрасен, что за него ломили вполне ощутимую сумму.
Ну, вот в итоге законопослушные западные разработчики и перебежали на значительно менее совершенные среды.
Дельфи в РФ был популярен прежде всего потому, что у нас платить за лицензии просто никому не приходило в голову. Купил в переходе метро один диск за сто рублей — и всё, можно пару сотен разработчиков трудоустроить.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
При этом бейсик боролся до конца.
Проблема в том, что Борланд сильно уступает по массе и размерам каткам
Ну и писали на нем в основном то в странах СНГ, где он был по сути бесплатным.
и солнце б утром не вставало, когда бы не было меня
S>При этом бейсик боролся до конца. S>Проблема в том, что Борланд сильно уступает по массе и размерам каткам S> Ну и писали на нем в основном то в странах СНГ, где он был по сути бесплатным.
Я тут посмотрел рейтинг языков TIOBE и удивился: Delphi на 9-м месте.
Здравствуйте, Kocur, Вы писали:
S>>При этом бейсик боролся до конца. S>>Проблема в том, что Борланд сильно уступает по массе и размерам каткам S>> Ну и писали на нем в основном то в странах СНГ, где он был по сути бесплатным.
K>Я тут посмотрел рейтинг языков TIOBE и удивился: Delphi на 9-м месте.
K>Это что, за счет СНГ?
Я бы не стал полагаться на TIOBE. Возьмем https://survey.stackoverflow.co/2024/technology#most-popular-technologies-language-prof
Его используют меньше 2%
Здравствуйте, Sinclair, Вы писали:
S> Ну, то есть может быть переход на SSE2 у них совпал с более вменяемым распределением локалов по регистрам — тогда, возможно, результат был чуть менее плачевным. А если нет — то увы, вот это вот тасование значений туда-сюда убивает всю производительность.
Вот так это выглядит на XE2:
procedure test;
var
S, a,b,c : Double;
begin
S := Sqrt(a*a+b*b+c*c);
end;
Здравствуйте, rudzuk, Вы писали:
S>> Ну и писали на нем в основном то в странах СНГ, где он был по сути бесплатным.
R>Получается, Борланд писал для неплатящего СНГ? Ну это же чушь полнейшая!
Ну в итоге Борланда и нет, а Embarcadero тоже тю-тю
7 мая 2008 года корпорация Borland объявила о продаже своей дочерней компании CodeGear. CodeGear занималась созданием популярных средств разработки программного обеспечения: Delphi, C++Builder и другими. В итоге, Embarcadero приобрела CodeGear за $23 млн и с обязательством погашения $7 млн долгов Borland.
7 октября 2015 года Embarcadero была куплена компанией Idera Software[1][2][…].
Я очень люблю Паскаль, обожаю Delphi и очень огорчен, что Борланд прекратил существование.
Теперь пишу на C# созданный создателем Delphi.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Ну в итоге Борланда и нет, а Embarcadero тоже тю-тю
Что за глупости... Стала частью другой компании, как отдельная единица. Как занималась развитием Delphi и C++Builder, так и продолжает это делать. За нее, кстати, заплатили 450 млн.
Здравствуйте, ononim, Вы писали: O>так случилось что у меня нашелся делфи 6, и вот: http://files.rsdn.org/69464/delphi6_float.png
Да, код чуууточку получше, чем я помню по 1999му году. Научились применять стек в пределах одного выражения При этом вместо FLD ST(0)/FMUL, выполняется FMUL c memory location, что хуже по пропускной способности, несмотря на кэш.
Кстати, если вас не затруднит — можете скомпилировать вот такой вариант кода?
s := a*a;
s := t + b*b;
s := t + c*c;
s := Sqrt(s);
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Kocur, Вы писали:
K>Помню 1998 год. Тогда процентов 80 (если не больше) знакомых писали на Delphi.
Сильно до. Когда купила им нафиг не нужный Ashton-Tate (1991).
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, ononim, Вы писали: O>>так случилось что у меня нашелся делфи 6, и вот: http://files.rsdn.org/69464/delphi6_float.png S>Да, код чуууточку получше, чем я помню по 1999му году. Научились применять стек в пределах одного выражения При этом вместо FLD ST(0)/FMUL, выполняется FMUL c memory location, что хуже по пропускной способности, несмотря на кэш.
Ничего они не научились, просто в этом примере аргументы имеют тип double, который может быть непосредственно использован как memory location в FPU инструкциях.
Если поменять на Extended, получится та же хрень с сохранением в память...
Здравствуйте, Sinclair, Вы писали:
S>Всё верно. Смолток умер под гнётом собственной жадности — плюсовый компилятор было решено распространять бесплатно, а смоллток был настолько прекрасен, что за него ломили вполне ощутимую сумму. S>Ну, вот в итоге законопослушные западные разработчики и перебежали на значительно менее совершенные среды.
Вроде Страуструп подавал идею С++ — как близкий к железу C без накладных расходов медленного Смоллтока. Про платность Смоллтока он не упоминал. Это уже потом пошла тема "дешевле докупить плашку памяти, чем искать баги порчи памяти у C++". С++ был прекрасен вначале, то того, как из него нагородили противоречивый костыле-всемогутор.
Здравствуйте, Артём, Вы писали:
Аё>Вроде Страуструп подавал идею С++ — как близкий к железу C без накладных расходов медленного Смоллтока. Про платность Смоллтока он не упоминал. Это уже потом пошла тема "дешевле докупить плашку памяти, чем искать баги порчи памяти у C++". С++ был прекрасен вначале, то того, как из него нагородили противоречивый костыле-всемогутор.
А когда это было? Просто самый первый эффективный сборщик мусора впервые появился именно в Смолтоке, и это было где-то в районе 84-85 годов. Пишу по памяти. Сейчас это обычно называется сборкой на основе поколений, а тогда сами создатели назвали его как-то похоже на "эфемерную" сборку (ephemerial). Точного названия не помню. Прочитал в одной книге по лиспу.
Возможно, что Страуструп говорил о более раннем сборщике мусора, который действительно был медленным.
K>Где Борланд свернул не туда? Почему просрали такой ВЕЛИКИЙ продукт?
Продукт просрали примерно в тот момент, когда коллектив безумно продуктивных творцов с горящим взором сменился на резиновоголовых манагеров, которых ничего, кроме стрижки купонов, в продукте не интересует (Inprise, Embarcadero, и прочие корпорастные бизнес-сущности).
S>Его используют меньше 2%
Что тоже чрезвычайно дофига, на минуточку. Вполне может так статься, что в абсолютных цифрах Дельфя ничего и не потеряла, а просто-напросто размылась доля: с 1998-го программизм разросся как на дрожжах. От нишевой профессии фанатиков до вторых юристов-экономистов, коих наплодили, как собак нерезанных.
Здравствуйте, dsorokin, Вы писали:
D>А когда это было? Просто самый первый эффективный сборщик мусора впервые появился именно в Смолтоке, и это было где-то в районе 84-85 годов. Пишу по памяти. Сейчас это обычно называется сборкой на основе поколений, а тогда сами создатели назвали его как-то похоже на "эфемерную" сборку (ephemerial). Точного названия не помню. Прочитал в одной книге по лиспу.
Там дело не в сборщике мусора, а в гомоиконичности. То есть когда Кей говорил "всё есть объект" он имел в виду "всё есть объект". Безо всяких исключений.
В частности, чтобы сложить три и четыре в Смолтоке мы посылаем объекту "три" сообщение "прибавь" с параметром "четыре", а в ответ нам приезжает результат-объект "7".
Ну, ок, "сообщения" там были вызовами методов, а не шинным обменом между акторами, но идея сохраняется — нет никаких "нативных целых", есть ссылки на объект-число.
Примерно как джавовские референс-типы Integer или Float, или забоксенные дотнетовые value-типы.
Статическая типизация сего затруднена потому, что классы — тоже объекты, и мы запросто можем "на лету" добавить к классу "целое число" новый метод.
И вообще у любого класса есть метод "обработать неизвестное сообщение".
Поэтому написать какой-то магический джит, который из вот этих вот вызовов виртуальных методов сделает эффективный ассемблерный код с MOV EAX, 3; ADD EAX, 4 — крайне тяжело.
В итоге, эффективность смоллтока приближается к джаваскрипту, причём снизу (потому что первый смолток занимал пару тысяч строк и был написан отцами-основателями за несколько недель, а в современные JS-машины вбуханы тыщи человеко-лет).
D>Возможно, что Страуструп говорил о более раннем сборщике мусора, который действительно был медленным.
Страуструп в первую очередь говорил о возможности не платить за абстракции, которыми не пользуешься.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, zx zpectrum, Вы писали:
z> K>Где Борланд свернул не туда? Почему просрали такой ВЕЛИКИЙ продукт?
z> Продукт просрали примерно в тот момент, когда коллектив безумно продуктивных творцов с горящим взором сменился на резиновоголовых манагеров, которых ничего, кроме стрижки купонов, в продукте не интересует (Inprise, Embarcadero, и прочие корпорастные бизнес-сущности).
Чего это ты Inprise с Embarcadero в один ряд поставил? Inprise это тупо самопереименование Борланда, которое они расшифровывали, как Integration Enterprise. Через пару лет переименовались обратно (клоуны штопаные). Embarcadero была и есть девелоперской компанией, которая разрабатывала инструментарий для БД на продуктах Борланда. К слову, Embarcadero привнесла в Delphi очень много нового: и серьезное развитие языка и покрытие платформ. И, вроде как, не намерены останавливаться
Здравствуйте, zx zpectrum, Вы писали:
ZZ>Что тоже чрезвычайно дофига, на минуточку. Вполне может так статься, что в абсолютных цифрах Дельфя ничего и не потеряла, а просто-напросто размылась доля: с 1998-го программизм разросся как на дрожжах.
нет-нет, очень много программистов ушли с Delphi, тысячи
Здравствуйте, Michael7, Вы писали:
M>Но мы ведь говорим про компанию, которая началась как разработчик удобных компиляторов и IDE и представляется, что для лидирующего положения на рынке необходимо было выпускать актуальные для нового железа и софта средства. А вот с этим у борланда что-то пошло не так. Хотя, надо отметить, что Borland C++ был заметно более актуализированным и даже, емнип, уже в 1992-м имелись дополнения для создания 32-битных программ для MS-DOS, чего не стали делать для Паскаль-среды.
В те времена у Borland были едва ли не лучшие IDE, я всего лет 20 назад послдний раз пользовался Turbo C. И TurboVision по своим временам был весьма удобным. А вот для настоящего GUI у них как-то не получилось сделать что-то достойное. Может, по части IDE у них что-то и бло достойное, но полноценно не поддреживало ни один годный toolkit. Я ещё помню времена, когда скачать из inet'а, скжаем, netbeans было чем-то нереальнм, а на CD'юках как раз можно было найти самые разные товрения Borland. Но я хорошо помню, что на их альтернативе написать ничего толком невозможно было. Тогда, кстати, на java можно было делать applets для web ui, а CSS в Web ещё едва набирал популярность, AJAX — ещё только в проекте.
Это я уже видел (не уверен, что там была включена оптимизация). Я про код спрашиваю, потому-что он не эквивалентен предыдущему, где все вычисления делаются в одном выражении.
Здравствуйте, Ilya81, Вы писали:
I>В те времена у Borland были едва ли не лучшие IDE, я всего лет 20 назад послдний раз пользовался Turbo C. И TurboVision по своим временам был весьма удобным. А вот для настоящего GUI у них как-то не получилось сделать что-то достойное.
У них для GUI OWL (СОВА) была, в принципе, вполне можно было на нём что-то делать, я даже пробовал. Я, правда, поздно с ней познакомился, вышел C++ Builder 1.0, там уже VCL была
I>Может, по части IDE у них что-то и бло достойное, но полноценно не поддреживало ни один годный toolkit.
Вот эту фразу вообще не понял
I>Я ещё помню времена, когда скачать из inet'а, скжаем, netbeans было чем-то нереальнм, а на CD'юках как раз можно было найти самые разные товрения Borland. Но я хорошо помню, что на их альтернативе написать ничего толком невозможно было. Тогда, кстати, на java можно было делать applets для web ui, а CSS в Web ещё едва набирал популярность, AJAX — ещё только в проекте.
procedure Test;
var
a, b, c, s : Double;
begin
a := Random;
b := Random;
c := Random;
s := a * a;
s := s + b * b;
s := s + c * c;
s := Sqrt(s);
WriteLn(s);
end;
Project1.dpr.13: begin
0000000000424F80 4883EC48 sub rsp,$48
0000000000424F84 660F7F7C2430 movdqa dqword ptr [rsp+$30],xmm7
0000000000424F8A 660F7F742420 movdqa dqword ptr [rsp+$20],xmm6
Project1.dpr.14: a := Random;
0000000000424F90 E86B03FEFF call Random
0000000000424F95 660F29C6 movapd xmm6,xmm0
Project1.dpr.15: b := Random;
0000000000424F99 E86203FEFF call Random
0000000000424F9E 660F29C7 movapd xmm7,xmm0
Project1.dpr.16: c := Random;
0000000000424FA2 E85903FEFF call Random
Project1.dpr.18: s := a * a;
0000000000424FA7 660F28CE movapd xmm1,xmm6
0000000000424FAB F20F59CE mulsd xmm1,xmm6
Project1.dpr.19: s := s + b * b;
0000000000424FAF 660F28D7 movapd xmm2,xmm7
0000000000424FB3 F20F59D7 mulsd xmm2,xmm7
0000000000424FB7 F20F58CA addsd xmm1,xmm2
Project1.dpr.20: s := s + c * c;
0000000000424FBB 660F28D0 movapd xmm2,xmm0
0000000000424FBF F20F59D0 mulsd xmm2,xmm0
0000000000424FC3 F20F58CA addsd xmm1,xmm2
Project1.dpr.21: s := Sqrt(s);
0000000000424FC7 660F29C8 movapd xmm0,xmm1
0000000000424FCB E88005FEFF call Sqrt
0000000000424FD0 660F29C1 movapd xmm1,xmm0
Project1.dpr.23: WriteLn(s);
0000000000424FD4 488B0D45800000 mov rcx,[rel $00008045]
0000000000424FDB E82018FEFF call @Write0Ext
0000000000424FE0 4889C1 mov rcx,rax
0000000000424FE3 E83818FEFF call @WriteLn
Project1.dpr.24: end;
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, Ilya81, Вы писали:
I>>В те времена у Borland были едва ли не лучшие IDE, я всего лет 20 назад послдний раз пользовался Turbo C. И TurboVision по своим временам был весьма удобным. А вот для настоящего GUI у них как-то не получилось сделать что-то достойное.
M>У них для GUI OWL (СОВА) была, в принципе, вполне можно было на нём что-то делать, я даже пробовал. Я, правда, поздно с ней познакомился, вышел C++ Builder 1.0, там уже VCL была
I>>Я ещё помню времена, когда скачать из inet'а, скжаем, netbeans было чем-то нереальнм, а на CD'юках как раз можно было найти самые разные товрения Borland. Но я хорошо помню, что на их альтернативе написать ничего толком невозможно было. Тогда, кстати, на java можно было делать applets для web ui, а CSS в Web ещё едва набирал популярность, AJAX — ещё только в проекте.
M>Да нормально можно было всё написать
Не сказал б, как уж он там назвался, JavaBuilder что ли, — можно было, конечно, и на нём написать, если постараться, ибо когда-то его найти было проще. Но NetBeans я впервые скачал из inet'а только тогда, когда такое стало реально, ибо на CD'юках он мне так и не попался, но при этом на дискету не умещался. И вот тогда я оценил разницу!
И C++ Builder не сильно лучше по этой части, хоть там, конечно, не сказать, чтоб сильно хуже, чем в MS Visual Studio тех времэн, которй на CD'юках вполне можно было найти.
В общем, у Borland хоршо было сделано только во времена псведографики.
Здравствуйте, Ilya81, Вы писали:
I>Не сказал б, как уж он там назвался, JavaBuilder что ли, — можно было, конечно, и на нём написать, если постараться, ибо когда-то его найти было проще. Но NetBeans я впервые скачал из inet'а только тогда, когда такое стало реально, ибо на CD'юках он мне так и не попался, но при этом на дискету не умещался. И вот тогда я оценил разницу!
Причем тут JavaBuilder?
I>И C++ Builder не сильно лучше по этой части, хоть там, конечно, не сказать, чтоб сильно хуже, чем в MS Visual Studio тех времэн, которй на CD'юках вполне можно было найти.
Как RAD, Delphi и аналогичный ей по RAD-функционалу C++ Builder просто на порядки превосходил MSVС, у которой был MFC и убогий редактор ресурсов, на которых все приложения и строились
I>В общем, у Borland хоршо было сделано только во времена псведографики.
Здравствуйте, Marty, Вы писали:
I>>И C++ Builder не сильно лучше по этой части, хоть там, конечно, не сказать, чтоб сильно хуже, чем в MS Visual Studio тех времэн, которй на CD'юках вполне можно было найти.
M>Как RAD, Delphi и аналогичный ей по RAD-функционалу C++ Builder просто на порядки превосходил MSVС, у которой был MFC и убогий редактор ресурсов, на которых все приложения и строились
MFC — конечно, та еще штука! Одна обработка сообщений чего стоила (хотя кто-то пишет до сих пор).
C++ Builder для GUI был для меня значительно проще, чем та же Visual Studio 6. Однако, я помню, что тогда все говорили, что MSVC 6 создавало код лучше даже ваткома. Поэтому было ощущение сопричастности к чему-то такому великому, когда запускали эту самую Visual Studio 6. Компилятор Visual C++ уже тогда (в районе 1999-2000) был очень распиарен.
С другой стороны, помню, что в одной из версий Far Manager пытались соскочить на MSVC с борландовского компилятора, а потом вернулись обратно на Borland C++. Автор тогда заявил, что не увидел преимуществ. Жаль, конечно, что компилятор перестали активно развивать.
Вообще, вспоминая то время, помню, что у меня была статья в компьютерном журнале (сейчас такие не выпускают), посвященная сравнению компиляторов С++. Там в одной табличке было название 6-7 компиляторов C++ только для одной винды!
Нет, конечно, мы тогда были юны и молоды, и нам уже по этому приятно вспоминать то время, но все же скажу, что разнообразия тогда в программировании было значительно больше. Сейчас же наблюдаю какой-то туннельный эффект, когда все говорят об одних и тех же технологиях. Чем больше о них говорят, тем больше создается ощущение, что только ими и пользуются, а значит, еще больше людей начинает пользоваться такими технологиями, о которых говорят, что заставляет людей еще больше о них говорить. Такой саморазгоняющийся цикл, если говорить в терминах "системного мышления" (systems thinking). Один индекс TIOBE чего стоит!
А на обочине остается много интересного и даже полезного, но о котором почти не говорят. А если добавить, что молодые люди почти не читают книг, то они часто и не знают о том, что есть за пределами информационного шума в интернете. Как они узнают?
D>А на обочине остается много интересного и даже полезного, но о котором почти не говорят. А если добавить, что молодые люди почти не читают книг, то они часто и не знают о том, что есть за пределами информационного шума в интернете. Как они узнают?
Здравствуйте, dsorokin, Вы писали:
D>С другой стороны, помню, что в одной из версий Far Manager пытались соскочить на MSVC с борландовского компилятора, а потом вернулись обратно на Borland C++. Автор тогда заявил, что не увидел преимуществ. Жаль, конечно, что компилятор перестали активно развивать.
Кроме всего прочего, у Борланда для С++ были свои расширения (да у всех они были и есть), типа fastcall, property.
Тут больше проблема не в Delphi, а в управляемых средах. Java и C#.
C# разрабатывал тот же что и Delphi — Андерс Хейлсберг.
И Delphi в том же .Net сильно отставал от C#, а Visual Studio до сих пор одна из лучших.
Беда Delphi в том, что его не взяла под крыло MS в отличие от бэйсика.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> И Delphi в том же .Net сильно отставал от C#, а Visual Studio до сих пор одна из лучших.
В чем он отставал-то? В том, что дженерики появились позже? Впрочем, отставание от владельца платформы в подобной ситуации, оно, как-бы, само-собой разумеющееся. Борланду просто не стоило связываться с .NET, попадая в прямую зависимость от конкурента. VCL for .NET, кстати, была приятнее WinForms (я смотрел и то и другое).
S> Беда Delphi в том, что его не взяла под крыло MS в отличие от бэйсика.
Слава Богу, что МС не прикасалась своими руками к Delphi, нето, получился бы второй шарп. Но, Бог миловал!
Здравствуйте, rudzuk, Вы писали:
S>> Беда Delphi в том, что его не взяла под крыло MS в отличие от бэйсика.
R>Слава Богу, что МС не прикасалась своими руками к Delphi, нето, получился бы второй шарп. Но, Бог миловал!
Ну вот многие и миновали Delphi перейдя на шарп.
Сейчас шарп один из лучших языков.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, rudzuk, Вы писали:
S>> Беда Delphi в том, что его не взяла под крыло MS в отличие от бэйсика.
R>Слава Богу, что МС не прикасалась своими руками к Delphi, нето, получился бы второй шарп. Но, Бог миловал!
но если бы мелкософт купил Delphi, десятки тысяч российских программистов сидели бы сейчас на Delphi и было бы море вакансий. А так...
Здравствуйте, Marty, Вы писали:
M>Как RAD, Delphi и аналогичный ей по RAD-функционалу C++ Builder просто на порядки превосходил MSVС, у которой был MFC и убогий редактор ресурсов, на которых все приложения и строились
Вообще, на сколько я могу судить, именyо RAD инструментом у Microsoft (до появления С# и его поддержки в Visual Studio) выступал Visual Basic, у которого была приличная поддержка OLE/ActiveX, был достаточно удобный дизайнер GUI и простая модель работы с формами/компонентами (по сути, программист писал код обработки разных событий — загрузки формы, щелчков на кнопки, ...)
Т.е. сами ActiveX могли создаваться где угодно, а VB выступал этаким инструментом "склейки" в конечное приложение (и это, имхо, было серьезным недостатком, потому что в Delphi компоненты и конечное приложение делались на одном языке и одним инструментом, а в "мире MS" было такое деление).
Причем за счет того, что среда была единая (хотя бы внешне) и для VB в Visual Studio и для Visual Basic for Aplication (VBA в том же Office) — распространилось это очень широко (например, можно было что-то накатать как макросы в офисе, а потом вынести отдельным приложением)
Коллега рассказывал, что в районе середины 2000-х в некоей Лондонской консалтинговой (юридической) компании видел всю автоматизацию построенную чисто на макросах Office.
И, кстати, то что Microsoft до сих пор продолжает (хоть и практически в режиме "вялой поддержки") возиться с Visual Basic в .Net — косвенно указывает на количество когда-то написанного кода (я почти уверен, что для новых проектов его практически не выбирают)
Здравствуйте, dsorokin, Вы писали:
D>Вообще, вспоминая то время, помню, что у меня была статья в компьютерном журнале (сейчас такие не выпускают), посвященная сравнению компиляторов С++. Там в одной табличке было название 6-7 компиляторов C++ только для одной винды!
Имхо, такое количество и сейчас наберётся
D>А на обочине остается много интересного и даже полезного, но о котором почти не говорят.
Например?
Многие и рады были бы испытать когнитивный диссонанс, но нечем.
Здравствуйте, paucity, Вы писали:
D>>А на обочине остается много интересного и даже полезного, но о котором почти не говорят.
P>Например?
Я уже лет 15 назад сильно подсел на ФП (познакомился много раньше). Тогда как раз была волна интереса к ФП. Я так и остался на той волне. Поэтому в моем списке будут все языки от хаскеля, F# и до Common Lisp со схемой и clojure. По своему мне нравится каждый из них. Вот буквально сейчас интересует эрланг.
Вообще, мне чаще нравятся языки, чем нет. Везде есть своя изюминка. Везде свой стиль или даже набор стилей. Есть своя эстетика. Лишь необходимость каждый день писать на них код может испортить мое впечатление. По своему мне даже C++ нравятся... Скорее, я больше устаю от языков, они могут просто надоесть. Но пройдет время, и уже кажется, что не так все и плохо было.
Утилитарного отношения к языкам у меня нет. Нет отношения исключительно как к инструменту. Это еще и образ мысли, и идеи, и возможности, а вместе с ними еще и ограничения. У каждого языка есть свои ограничения, точнее ограничения в том, как мы их можем использовать. Относится ко всем языкам.
А так, кроме ФП, мне вот очень даже интересен смолток (smalltalk). Свой первый большой заход к нему сделал лет 12-14 назад. Еще тогда показался интересным.
Как-то очень давно увлекался еще и фортом с прологом. Интересны были Ада и Модула-2 наряду с паскалем. Да и ассемблером увлекался — мне понравился для VAX-32 (как и понравился его предшественник для PDP-11, который был на бэкашках с ДВК), а вот интеловский ассемблер так и не зашел, хотя пытался учить по книге супер-популярного тогда Нортона.
Для меня нормально, когда мне нравится то, что не очень популярно. В этом проявляется нонконформизм, который отчасти мне присущ (не путать с асоциальностью). Возможно, еще из-за этого у меня такой список языков. Если бы сейчас было популярным ФП, то возможно, что я бы фанател от C++, C# и питона. Исключать нельзя. Но все же, как-то так получается, что ФП сейчас не в моде. Может быть, тому есть фундаментальные причины. Кто бы только знал их?
Здравствуйте, Kocur, Вы писали:
K> R>Слава Богу, что МС не прикасалась своими руками к Delphi, нето, получился бы второй шарп. Но, Бог миловал!
K> но если бы мелкософт купил Delphi, десятки тысяч российских программистов сидели бы сейчас на Delphi и было бы море вакансий. А так...
Если бы МС купил Delphi, то первое что они сделали бы, это изговняли его до неузнаваемости, а потом слили, как Скайп, например. Понимаешь, C# появился для бестолковок, и был назван созвучно C/C++, чтобы они почувствовали себя настоящими мужиками. У Delphi в этом варианте истории не могло быть счастливого будущего.
Здравствуйте, Serginio1, Вы писали:
S> R>Слава Богу, что МС не прикасалась своими руками к Delphi, нето, получился бы второй шарп. Но, Бог миловал!
S> Ну вот многие и миновали Delphi перейдя на шарп.
Ну и скатертью дорога
S> Сейчас шарп один из лучших языков.
Дядя Сережа, ты меня так не смеши больше. Навалить всего в кучу не означает сделать хороший язык.
Здравствуйте, dsorokin, Вы писали:
D>>>А на обочине остается много интересного и даже полезного, но о котором почти не говорят.
P>>Например?
D>... языки от хаскеля, F# и до Common Lisp со схемой и clojure.
...
Имхо, не хайп конечно, но сказать, что об этом не говорят, тоже нельзя
Многие и рады были бы испытать когнитивный диссонанс, но нечем.
Здравствуйте, Marty, Вы писали:
M> R>Если бы МС купил Delphi, то первое что они сделали бы, это изговняли его до неузнаваемости,
M> Если ты про язык, то говно невозможно изговнять, оно уже и так говно
Здравствуйте, rudzuk, Вы писали:
M>> R>Если бы МС купил Delphi, то первое что они сделали бы, это изговняли его до неузнаваемости,
M>> Если ты про язык, то говно невозможно изговнять, оно уже и так говно
R>Я про плюсы вообще ничего не сказал
Здравствуйте, rudzuk, Вы писали:
R>Если бы МС купил Delphi, то первое что они сделали бы, это изговняли его до неузнаваемости, а потом слили, как Скайп, например. Понимаешь, C# появился для бестолковок, и был назван созвучно C/C++, чтобы они почувствовали себя настоящими мужиками. У Delphi в этом варианте истории не могло быть счастливого будущего.
Да зачем микрософту нужны были бы Delphi? Во времена Visual Studio 6 у них был Visual J++. Это такая их собственная реализация Java, из-за которой Sun подала на них в суд и выиграла дело. А подали они в суд, потому что испугались. В те времена у микрософта была одна из лучших реализаций Java, если кто помнит. Скорее всего, что даже лучшая на той же винде.
Так вот, Visual J++ я запускал. Мне очень даже понравилось. Можно даже сказать, что это была одна из самых приятных в использовании реализаций Java для GUI на тот момент, но где легко было нарваться на ограничения по кроссплатформенности. И даже в одной книге микрософтовского издательства (где-то валялась раньше у меня) была заявлено, что Visual J++ лучше других подходит для воплощения идей COM/ActiveX. Я так понял, что даже лучше, чем VisualBasic (который без окончания ".NET"). Оставляю слова на совести того автора. Может быть, так оно и было.
Ну, вот зачем им Delphi? В микрософте взяли Visual J++ за основу, слегка изменили язык (провели "капитализацию" названий), добавили IL и всю сопутствующую экосистему, а потом назвали .NET Framework. У них был уже прекрасный задел в виде Visual J++. Они стартовали уже с очень хорошей позиции. И дельфи туда, ну, никак не вписывались.
Здравствуйте, dsorokin, Вы писали:
d> Да зачем микрософту нужны были бы Delphi? Во времена Visual Studio 6 у них был Visual J++. Это такая их собственная реализация Java, из-за которой Sun подала на них в суд и выиграла дело. А подали они в суд, потому что испугались. В те времена у микрософта была одна из лучших реализаций Java, если кто помнит. Скорее всего, что даже лучшая на той же винде.
Вот именно, что только на винде. МС и сделала все, чтобы свою Java привязать к Windows. Про Embrace, Extend, and Extinguish в курсе же, да?
d> Ну, вот зачем им Delphi? В микрософте взяли Visual J++ за основу, слегка изменили язык (провели "капитализацию" названий), добавили IL и всю сопутствующую экосистему, а потом назвали .NET Framework. У них был уже прекрасный задел в виде Visual J++. Они стартовали уже с очень хорошей позиции. И дельфи туда, ну, никак не вписывались.
Так я и не говорю, что МС хотела Delphi Я лишь ответил на озвученное предположение. На самом деле, Delphi была удобна МС, т.к. являлась средством разработки под ее платформу и не конкурировала с продуктами МС. Все, что было интересно МС, это продвижение Windows, на которой она зарабатывала. Этим же обусловливалось и расширение Java в сторону плотнейшей интеграции с виндами. Кстати, после закрытия проекта Kylix (кроссплатформенный Delphi, переживший три версии) ходили слухи, что именно МС надавила на Борланд для его закрытия (она могла т.к. владела приличным пакетом акций Борланда).
Здравствуйте, dsorokin, Вы писали:
D>... И даже в одной книге микрософтовского издательства (где-то валялась раньше у меня) была заявлено, что Visual J++ лучше других подходит для воплощения идей COM/ActiveX.
Странно было бы, если Microsoft Press заявил бы о какой-то мелкомякговской технологии что-то другое
Ну и то, что COM/ActiveX вне MS вообще не жильцы были, надо напомнить?
(собственно, суд-то и был из-за MS'овских заявлений о совместимости J++ с Java; да, и чуть-чуть раньше выхода 6ой студии).
Многие и рады были бы испытать когнитивный диссонанс, но нечем.
Здравствуйте, dsorokin, Вы писали:
D>MFC — конечно, та еще штука! Одна обработка сообщений чего стоила (хотя кто-то пишет до сих пор).
D>C++ Builder для GUI был для меня значительно проще, чем та же Visual Studio 6.
Ну т.е. на Delphi и C++ Builder сидели те, кому нужно попроще — не настолько steep learning curve и не нужно глубоко копать под капотом. Ибо кастомные компоненты упирались в всё те же обработчики сообщений, тооько продираться через слои абстракции. Ещё у MFC была из коробки Document View Controller- был wizard на создание своего WYSIWYG приложения. У Delphi же была ориентация на очень быстрое формошлёпство.
Здравствуйте, Артём, Вы писали:
D>>C++ Builder для GUI был для меня значительно проще, чем та же Visual Studio 6.
Аё>Ну т.е. на Delphi и C++ Builder сидели те, кому нужно попроще — не настолько steep learning curve и не нужно глубоко копать под капотом. Ибо кастомные компоненты упирались в всё те же обработчики сообщений, тооько продираться через слои абстракции.
И это говорит нам формошлёп на тайпскрипте
В VCL не надо было продираться ни через какие слои абстракции, все события винапи там уже были в виде пропертей onXXX, которым надо было просто назначить обработчик.
Аё>Ещё у MFC была из коробки Document View Controller- был wizard на создание своего WYSIWYG приложения.
WYSIWYG нужен одному проценту приложений
Аё>У Delphi же была ориентация на очень быстрое формошлёпство.
Это то, на что заточены или пытаются заточится все современные фронт-энд фреймворки
Здравствуйте, Артём, Вы писали:
Аё>Ну т.е. на Delphi и C++ Builder сидели те, кому нужно попроще — не настолько steep learning curve и не нужно глубоко копать под капотом. .... Ещё у MFC была из коробки Document View Controller- был wizard на создание своего WYSIWYG приложения.
Аргументы этих двух предложений противоречат друг-другу, не находишь?
Ну и ты уверен,что тот mfc wizard создавал прям таки WYSIWYG?
Аё>У Delphi же была ориентация на очень быстрое формошлёпство.
Странно было бы, если бы продукты (хоть от Борланда, хоть от МС), продвигаемые как средства для RAD, не предоставляли такой возможности. Ну а то, что под "капотом" этих форм, зависило только от рук и мозгов, кто формы девелопер
Многие и рады были бы испытать когнитивный диссонанс, но нечем.
Здравствуйте, paucity, Вы писали:
P>Аргументы этих двух предложений противоречат друг-другу, не находишь?
На Delphi может быть, в теории и можно было бы создать MVC и в теории можно писать быстрый код, но на практике, дальше формочек оно не шло.
P>Ну и ты уверен,что тот mfc wizard создавал прям таки WYSIWYG?
Прям таки MVC, а WYSIWYG дальше отрисовку самому имплементить.
P> Ну а то, что под "капотом" этих форм, зависило только от рук и мозгов, кто формы девелопер
Да. VC++ девлопер шёл и писал фичу, а Delphi девклопер опускал руки "эту задачу сделать невозможно- компонент не существует для неё".
Здравствуйте, Marty, Вы писали:
M>Тёмчик фантазирует о том, что он был крутой девелопер на визивуге с MFC, не то, что всякие формошлёпы
На чисто MFC я писал недолго- быстро перешли на + ATL/WTL и потом я перешёл на кросс-платформу. MFC был тяжёлым легаси по сути. Я вообще не считаю программистов на MFC какими-то выдающимися, просто на их фоне Delphi программисты это уровень развития дет. сад.
Здравствуйте, Михаил Романов, Вы писали:
МР>И, кстати, то что Microsoft до сих пор продолжает (хоть и практически в режиме "вялой поддержки") возиться с Visual Basic в .Net — косвенно указывает на количество когда-то написанного кода (я почти уверен, что для новых проектов его практически не выбирают)
Я не совсем понимаю кому вообще VB.NET был нужен? Как язык он же не совместим ни с VBA, ни просто с VB. Если кто сильно привык к бейсику, ему все-равно пришлось переучиваться. При том вызывать макросы VBA можно было и из C# в .NET
Здравствуйте, novitk, Вы писали:
N>Сильно до. Когда купила им нафиг не нужный Ashton-Tate (1991).
Хе, очень похоже, что так и есть. Учитывая, что Ashton-Tate до этого проиграла суд, на котором они хотели остальным запретить использовать формат dbf, при том в Borland уже была своя локальная реляционная СУБД Paradox (которую тоже купили, но сильно ранее). Хотя не исключено на 1991-й поддались магии громкого имени, все же Ashton-Tate, можно сказать, создала рынок таких субд, а Borland хотелось стать "кровавым энтерпрайзом". Может готовую клиентскую базу хотели окучить.
Здравствуйте, Michael7, Вы писали:
M>Я не совсем понимаю кому вообще VB.NET был нужен?
Простите, но тут напрашивается ответ в стиле Капитана Очевидность.
Тем, у кого:
— была солидная кодовая база на VB5/6
— была готовая опытная команда VB-разработчиков
— не было ресурсов (и смысла) переписывать код на C#
— было желание переехать на новую платформу (.Net) и инструментарий к ней.
M>Как язык он же не совместим ни с VBA, ни просто с VB. Если кто сильно привык к бейсику, ему все-равно пришлось переучиваться.
А что значит "не совместим"?
Ну были различия, местами значительные. Но... я сейчас полистал статьи про миграцию — да списки большие, но всё равно это в целом тот же язык.
Причем была куча инструментов для помощи в миграции.
Были оставлены специальные фичи для совместимости (типа объявления массива с 1)
Были сторонние решения которые поддерживали, например, функции со старым поведением (типа Len6() вместо Len() и MsgBox6() вместо MsgBox())
На сколько я помню (сейчас нет возможности проверить), вплоть до 2008 студии шла поддержка встроенного конвертера.
Короче, скорее всего миграция не была совсем уж простой, но это была миграция, а не переписывание проекта с 0.
Т.е. условные человеко-недели или месяцы, но не годы.
M>При том вызывать макросы VBA можно было и из C# в .NET
Нет, VBA здесь особо не при делах. Речь, как я понимаю, в первую очередь о миграции VB6->VB.Net
Здравствуйте, rudzuk, Вы писали:
R>В чем он отставал-то? В том, что дженерики появились позже? Впрочем, отставание от владельца платформы в подобной ситуации, оно, как-бы, само-собой разумеющееся. Борланду просто не стоило связываться с .NET, попадая в прямую зависимость от конкурента. VCL for .NET, кстати, была приятнее WinForms (я смотрел и то и другое).
В том, что не было GC. И даже костылей из плюсов типа всяких shared_ptr/auto_ptr не было.
Здравствуйте, novitk, Вы писали:
n> R>В чем он отставал-то? В том, что дженерики появились позже? Впрочем, отставание от владельца платформы в подобной ситуации, оно, как-бы, само-собой разумеющееся. Борланду просто не стоило связываться с .NET, попадая в прямую зависимость от конкурента. VCL for .NET, кстати, была приятнее WinForms (я смотрел и то и другое).
n> В том, что не было GC. И даже костылей из плюсов типа всяких shared_ptr/auto_ptr не было.
Гхм. Попробуй почитать внимательно, о чем вообще речь идет.
Здравствуйте, rudzuk, Вы писали:
n>> В том, что не было GC. И даже костылей из плюсов типа всяких shared_ptr/auto_ptr не было. R>Гхм. Попробуй почитать внимательно, о чем вообще речь идет.
+1, не уследил за контекстом.
Здравствуйте, rudzuk, Вы писали:
S>> Сейчас шарп один из лучших языков.
R>Дядя Сережа, ты меня так не смеши больше. Навалить всего в кучу не означает сделать хороший язык.
Ну вот как раз в Delphi многого и не хватает, по сравнению даже с C# под .Net Framework 3.5 когда я окончательно перестал писать на Delphi.
А вот по сравнению с .Net 8 уже небо и земля.
Попробуй сделать некоторые задачи на C# используя весь набор инструментов. Это полезно для развития нейронных связей!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, Ilya81, Вы писали:
I>>Не сказал б, как уж он там назвался, JavaBuilder что ли, — можно было, конечно, и на нём написать, если постараться, ибо когда-то его найти было проще. Но NetBeans я впервые скачал из inet'а только тогда, когда такое стало реально, ибо на CD'юках он мне так и не попался, но при этом на дискету не умещался. И вот тогда я оценил разницу!
M>Причем тут JavaBuilder?
Ну помн, было у Borland какое-то такое творение, название помню примерно. И была ситуация, что другой IDE для Java под рукой не бло, т. е. на CD'юках было не найти, а скачать NetBeans из inet'а ещё было не реально. И помню, когда такая возможность уже появилас.
I>>И C++ Builder не сильно лучше по этой части, хоть там, конечно, не сказать, чтоб сильно хуже, чем в MS Visual Studio тех времэн, которй на CD'юках вполне можно было найти.
M>Как RAD, Delphi и аналогичный ей по RAD-функционалу C++ Builder просто на порядки превосходил MSVС, у которой был MFC и убогий редактор ресурсов, на которых все приложения и строились
А что там редактировать? Для картинок, если их клепать самому, есть сторнние редакторы. Строки теста — там более, можно просто скопировать откуда-то. А с целостностью проекта Visual Studio и тогда не сильно хуже справлялся, конечно, не то, что нанче, но что у Borland сильно лучше было? Переход к реализации метода, поиск мест использования — у Borland большое превосходство в этом было? Не помню такого. Вообще не помню крупнх новшеств в сранвении с Turbo C, вот там по тем временам было на высоте.
Здравствуйте, Serginio1, Вы писали:
S>Ну вот как раз в Delphi многого и не хватает, по сравнению даже с C# под .Net Framework 3.5 когда я окончательно перестал писать на Delphi. S>А вот по сравнению с .Net 8 уже небо и земля.
S>Попробуй сделать некоторые задачи на C# используя весь набор инструментов. Это полезно для развития нейронных связей!
Только есть один нюанс...
У меня вот программа на .NET (C# / F#). Когда беру версию с Авалонией, то под линукс с компиляцией AOT получается 48 мегабайт. Инсталятор ужимается до 26 мегабайт. А вот с WPF инсталятор под винду получается размером 11 мегабайт. Причем, устанешь ждать, когда соберется версия с AOT, а вот без AOT очень живо собирает.
В нашем случае вариант с Дельфей ближе к моему варианту с Авалонией. А с WPF платформа .NET отказывается использовать AOT.
У меня там визуальный редактор диаграмм, решатель и компилятор уравнений, вывод графиков и таблиц, да всякие вспомогательные редакторы.
Конечно, мне сборщик мусора очень много, где помогает, он многое упрощает и прощает, но что-то многовато будет. Эти 48 мегабайт немного напрягают меня.
А какие у вас размеры бинарей на Дельфе и Лазарусе?
P.S. Есть расхожее мнение, что, скажем, для Common Lisp получаются огромные бинари. Это не всегда так. У меня есть заготовка редактора диаграмм (которую можно пользоваться уже сейчас, строить диаграммы, экспортировать в PDF и EMF), которую я написал на LispWorks с использованием CAPI. Так вот, LispWorks создает для винды у меня бинарь размером 10 мегабайт, который ужимается до 3 мегабайт 700 килобайт. Новый LispWorks сейчас не купишь, но все же приятная штука. Мне очень нравится LispWorks.
P.P.S. Я, конечно, все понимаю. Мегабайты сейчас никого не смущают, да и десктопы сейчас не в моде. На одной моей работе мы упаковывали JRE в инсталятор, и нормально было. Но все равно есть какое-то ощущение неправильности от всего этого. Как-то не нравится мне, что так сильно распухают десктопные программы. Какой-то здесь дух противоречия
Здравствуйте, Ilya81, Вы писали:
I>А что там редактировать?
Диалоги/формы
I>Для картинок, если их клепать самому, есть сторнние редакторы.
При чем тут картинки?
I>Строки теста — там более, можно просто скопировать откуда-то.
При чем тут строки?
I>А с целостностью проекта Visual Studio и тогда не сильно хуже справлялся, конечно, не то, что нанче, но что у Borland сильно лучше было? Переход к реализации метода, поиск мест использования — у Borland большое превосходство в этом было? Не помню такого. Вообще не помню крупнх новшеств в сранвении с Turbo C, вот там по тем временам было на высоте.
На MSVC/MFC или WTL ты сначала делал вручную или в редакторе ресурсов диалог, затем вручную делал в сорцах карту сообщений для этого диалога, вручную прописывал там обработчики событий, потом делал в классе прототипы этих обработчиков, потом в .cpp делал их реализацию. Да, переход от прототипа метода к его реализации в MSVC вроде даже работал.
И на самом деле — это тоже самое формошлёпство, что и на Дельфях/Билдере, только через боль и страдание. Пока дельфист делал 10 формочек для автоматизации бизнеса-процессов, гордый MSVC с трудом осиливал сделать одну, и это хорошо если всё сразу заработало, а бизнес логику он уже потом начинал пилить, когда делфист/билдерист уже шел пить пиво на заработанную премию.
В Дельфях/Билдере же ты создавал форму, перекидывал с палитры компонентов контролы, а также невизуальные компоненты, для баз данных, например, потом, выделяя контролы, ты настраивал в окне Property Editor нужные свойства, простым дабл кликом по пропертям обработчиков они создавались (тело в дельфях и прототип/тело в плюсах) и сразу приписывались контролу/компоненту.
Это было супер удобно для построения интерфейсов. Сейчас всякие C#, Qt с QtCreator'ом и прочие пытаются приблизиться к этому идеалу, но получается всё равно сложно и не так удобно, с кучей каких-то костылей.
Еше у Борланда были property, они их и в свой плюсовый компилятор добавили для поддержки VCL, вот это жалко что так и не попало в стандарт, те же кутишники его пытаются эмулировать при помощи своего moc-компилятора, но получилось так себе
D>У меня вот программа на .NET (C# / F#). Когда беру версию с Авалонией, то под линукс с компиляцией AOT получается 48 мегабайт. Инсталятор ужимается до 26 мегабайт. А вот с WPF инсталятор под винду получается размером 11 мегабайт. Причем, устанешь ждать, когда соберется версия с AOT, а вот без AOT очень живо собирает.
D>В нашем случае вариант с Дельфей ближе к моему варианту с Авалонией. А с WPF платформа .NET отказывается использовать AOT.
D>У меня там визуальный редактор диаграмм, решатель и компилятор уравнений, вывод графиков и таблиц, да всякие вспомогательные редакторы.
D>Конечно, мне сборщик мусора очень много, где помогает, он многое упрощает и прощает, но что-то многовато будет. Эти 48 мегабайт немного напрягают меня.
D>А какие у вас размеры бинарей на Дельфе и Лазарусе?
D>P.S. Есть расхожее мнение, что, скажем, для Common Lisp получаются огромные бинари. Это не всегда так. У меня есть заготовка редактора диаграмм (которую можно пользоваться уже сейчас, строить диаграммы, экспортировать в PDF и EMF), которую я написал на LispWorks с использованием CAPI. Так вот, LispWorks создает для винды у меня бинарь размером 10 мегабайт, который ужимается до 3 мегабайт 700 килобайт. Новый LispWorks сейчас не купишь, но все же приятная штука. Мне очень нравится LispWorks.
D>P.P.S. Я, конечно, все понимаю. Мегабайты сейчас никого не смущают, да и десктопы сейчас не в моде. На одной моей работе мы упаковывали JRE в инсталятор, и нормально было. Но все равно есть какое-то ощущение неправильности от всего этого. Как-то не нравится мне, что так сильно распухают десктопные программы. Какой-то здесь дух противоречия
48 мегабайт это не о чем. Прошли те времена когда «640КБ должно быть достаточно для каждого»!
Во главе угла сейчас скорость программирования и удобство распространения.
Особенно облака.
Здравствуйте, dsorokin, Вы писали:
D>Теперь пункт два. В Java и .NET — сборщики мусора. В нише корпоративного софта для доступа к БД (чуть ли не основной нише Дельфи) этого хватает за глаза, а само программирование сильно упрощается. Это доказал еще Смолток, но он по-сложнее будет как и язык, как и платформа (в использовании). Да и опять же, в 90-е основные реализации Смолтока были коммерческими, то есть не такими и доступными.
D>Сейчас сборщики мусора достаточно эффективны, а порой даже поражают в некоторых сценариях использования своей результативностью (например, если писать код в стиле функционального программирования, где объекты короткоживущие, и почти нет ссылок со старого поколения на новое, что позволяет быстро очищать и удалять самое молодое поколение объектов — тут даже джемаллоки и тисималлоки могут напрячься). А в случае эрланга так, вообще, сборка мусора становится soft real time (там плодятся тысячи и миллионы сборщиков мусора по одному на каждый процесс, чтобы рилтайм работал)
Я слшал, что XNA как раз со своим garbage collector некогда провалился, так что это как раз скорее в минус, хотя других достоинств много. В Swift другое решние, если кто забудет вызвать delete/dealloc, но у него куча сових недостатков.
Здравствуйте, rudzuk, Вы писали:
R>Так я и не говорю, что МС хотела Delphi Я лишь ответил на озвученное предположение. На самом деле, Delphi была удобна МС, т.к. являлась средством разработки под ее платформу и не конкурировала с продуктами МС. Все, что было интересно МС, это продвижение Windows, на которой она зарабатывала. Этим же обусловливалось и расширение Java в сторону плотнейшей интеграции с виндами. Кстати, после закрытия проекта Kylix (кроссплатформенный Delphi, переживший три версии) ходили слухи, что именно МС надавила на Борланд для его закрытия (она могла т.к. владела приличным пакетом акций Борланда).
Но на Novell давит не стали, стоит заметить. Теперь он вроде тоже кем-то поглощён, не помню уже.
Здравствуйте, Kocur, Вы писали:
K>Где Борланд свернул не туда? Почему просрали такой ВЕЛИКИЙ продукт?
Где-то читал, что серьезные финансовые проблемы у Борланда начались еще до выхода Delphi. Проблемы были настолько серьезными, что поговаривали что Борланд обанкротится.
Delphi был действительно великим продуктом, и не просто спас Борланд от банкротства, но позволил вырваться в лидеры. Однако каким бы технически продвинутым этот продукт ни был, проблемы с маркетингом и стратегическими решениями никуда не делись, на Западе Дельфи не был таким популярным как у нас, а у нас все пользовались пиратской версией, скорее всего они так и не смогли монетизировать свой неожиданый успех и принять правильные стратегические решения. После Микрософт переманил к себе ведущих разработчиков, думаю Микрософт по финансам мог сделать им такое предложение от, которого они не могли отказаться, но есть подозрение, что дело далеко не только в финансах. Ну а дальше Микрософт их просто раздавил.
Здравствуйте, ksandro, Вы писали:
k> на Западе Дельфи не был таким популярным как у нас, а у нас все пользовались пиратской версией, скорее всего они так и не смогли монетизировать свой неожиданый успех и принять правильные стратегические решения.
Здравствуйте, Ilya81, Вы писали:
I> Но на Novell давит не стали, стоит заметить. Теперь он вроде тоже кем-то поглощён, не помню уже.
Какой из Novell был конкурент Где был Novell и где гуевая винда. К тому же в Novell 5 завезли Java, которая на хорошем железе того времени (чистокровном межделмаше) еле-еле проворачивала свои объектные иерархии
Здравствуйте, Serginio1, Вы писали:
S> R>Дядя Сережа, ты меня так не смеши больше. Навалить всего в кучу не означает сделать хороший язык.
S> Ну вот как раз в Delphi многого и не хватает, по сравнению даже с C# под .Net Framework 3.5 когда я окончательно перестал писать на Delphi.
Еще раз повторю очень простую, казалось-бы, мысль: наваленная куча всего в шарпе не делает его хорошим языком. Шарп стал настолько офигительным, что сама МС шарахается от него, как от чумного, переписывая бэкенд облачного офиса с шарпа на раст. Очень хороший показатель офигительности, как языка, так и инфраструктуры.
S> А вот по сравнению с .Net 8 уже небо и земля.
Совершенно верно. Дотнетчики подтерлись собственными мантрами о супер джитах (которыми полоскали мозги на протяжении двадцати лет) и усиленно пытаются в AOT. Выходит хреново, но уж как есть
S> Попробуй сделать некоторые задачи на C# используя весь набор инструментов. Это полезно для развития нейронных связей!
Мне не нужен "весь набор инструментов". Мне нужен минимум позволяющий решать задачи. Ты бы отвлекался временами от пересказа рекламных листовок, для развития критического мышления полезно.
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, Ilya81, Вы писали:
I>>А что там редактировать?
M>Диалоги/формы
Синхронизация текстовым представлением и впрям неудобной была, но до XUL я не помню ничего сильно лучше, везде свои проблемы, и AWT лет 20 с хвостико назад — далеко не блеск был.
I>>Строки теста — там более, можно просто скопировать откуда-то.
M>При чем тут строки?
Редактирование ресурсов — вроде это строки в основной своей массе, или нет?
I>>А с целостностью проекта Visual Studio и тогда не сильно хуже справлялся, конечно, не то, что нанче, но что у Borland сильно лучше было? Переход к реализации метода, поиск мест использования — у Borland большое превосходство в этом было? Не помню такого. Вообще не помню крупнх новшеств в сранвении с Turbo C, вот там по тем временам было на высоте.
M>На MSVC/MFC или WTL ты сначала делал вручную или в редакторе ресурсов диалог, затем вручную делал в сорцах карту сообщений для этого диалога, вручную прописывал там обработчики событий, потом делал в классе прототипы этих обработчиков, потом в .cpp делал их реализацию. Да, переход от прототипа метода к его реализации в MSVC вроде даже работал.
Речь про заголвочные .h или про что? Тут согласен, что неудобно, когда для создания класса нужны отдельно .h и .cpp, в java, которому уже лет 30, с этим сильно прще.
M>И на самом деле — это тоже самое формошлёпство, что и на Дельфях/Билдере, только через боль и страдание. Пока дельфист делал 10 формочек для автоматизации бизнеса-процессов, гордый MSVC с трудом осиливал сделать одну, и это хорошо если всё сразу заработало, а бизнес логику он уже потом начинал пилить, когда делфист/билдерист уже шел пить пиво на заработанную премию.
Не помню такого. Это в awt появилис хот скол-нибудь удобные средства отображения коллекций, к примеру. И в ранних версиях android sdk было что-то похожее.
M>В Дельфях/Билдере же ты создавал форму, перекидывал с палитры компонентов контролы, а также невизуальные компоненты, для баз данных, например, потом, выделяя контролы, ты настраивал в окне Property Editor нужные свойства, простым дабл кликом по пропертям обработчиков они создавались (тело в дельфях и прототип/тело в плюсах) и сразу приписывались контролу/компоненту.
И как там было с текстовым представлением? Property Editor полезен, только если позабл, как что-то называется.
M>Это было супер удобно для построения интерфейсов. Сейчас всякие C#, Qt с QtCreator'ом и прочие пытаются приблизиться к этому идеалу, но получается всё равно сложно и не так удобно, с кучей каких-то костылей.
C# более или менее созрел лишь лет 15 назад, только поэтому я не привожу в сравнение. Но до сих пор ничего удобнее XAML для клепания UI я не видел, стандартнй android sdk, к примеру, до этого уровня всё равно не дотягивает, хотя улучшения было немало с первх версий. Но MFC был сделан под GDI, когда графические процессоры были ещё экзотикой.
Здравствуйте, rudzuk, Вы писали:
R>Здравствуйте, Ilya81, Вы писали:
I>> Но на Novell давит не стали, стоит заметить. Теперь он вроде тоже кем-то поглощён, не помню уже.
R>Какой из Novell был конкурент Где был Novell и где гуевая винда. К тому же в Novell 5 завезли Java, которая на хорошем железе того времени (чистокровном межделмаше) еле-еле проворачивала свои объектные иерархии
Может, от того, что не конкурент, конечно. Хотя Suse одно время был лучшей ОСью по моему впечатлению. Но я намекаю на Mono.
Здравствуйте, paucity, Вы писали:
P>Здравствуйте, Ilya81, Вы писали:
I>>Но на Novell давит не стали, стоит заметить.
P>Да никто впрямую не давил ни на Дельфи, ни на Новелл.
P>Тупо маркет и собственные ошибки.
P>Новелл, имхо, сам себя "похоронил" после 4.1x NET Ware.
P>NET Ware 5+ на фоне развития NT4/2000 и Linux'ов просто никому не вперлась добровольно.
Так Suse — это их творение, помнится мне. Не все дистрибутив linux одинаковые. Но потом, лет 10 назад, всё ж качество у них стало прадать.
Здравствуйте, Ilya81, Вы писали:
I> R>Какой из Novell был конкурент Где был Novell и где гуевая винда. К тому же в Novell 5 завезли Java, которая на хорошем железе того времени (чистокровном межделмаше) еле-еле проворачивала свои объектные иерархии
I> Может, от того, что не конкурент, конечно. Хотя Suse одно время был лучшей ОСью по моему впечатлению. Но я намекаю на Mono.
А что моно? МС сперва его ограничила:
После заключения Microsoft договорённости с компанией Novell[7] платформа Mono была официально признана реализацией .NET на Unix-подобных операционных системах (Linux, macOS и других). Однако договорённость касается только Novell и клиентов Novell; также технологии ASP.NET, ADO.NET и Windows.Forms не были стандартизированы ECMA/ISO, и использование их в Mono находится под угрозой юридических претензий со стороны Microsoft (претензии возможны только в странах, где существуют патенты на программное обеспечение[8]). Mono предоставляет реализацию ASP.NET, ADO.NET и Windows.Forms, но в то же время рекомендует не использовать эти API.[8]
Здравствуйте, ksandro, Вы писали:
K>Где-то читал, что серьезные финансовые проблемы у Борланда начались еще до выхода Delphi. Проблемы были настолько серьезными, что поговаривали что Борланд обанкротится.
Там выше novitk вспомнил, что в 1991-м году Borland купили Ashton-Tate — это была дорогая и действительно ненужная покупка. Еще они попытались конкурировать с MS на рынке офисных средств, примерно тогда начали выпускать Borland Office как конкурент Microsoft Office. Но что-то, как говорится, пошло не так. Интересно, многие ли сейчас вообще вспомнят о существовании такого продукта, а также о dBase и Ashton-tate?
I>>>Строки теста — там более, можно просто скопировать откуда-то.
M>>При чем тут строки?
I>Редактирование ресурсов — вроде это строки в основной своей массе, или нет?
Нет конечно. Строки ты мог и прямо в коде "зашить", а вот без ресурсов диалогов ты ни один диалог не создашь, не, ну можно самому создать в рантайме шаблон, и создать диалог через CreateDialogIndirect, но это ещё большие боль и страдание
M>>На MSVC/MFC или WTL ты сначала делал вручную или в редакторе ресурсов диалог, затем вручную делал в сорцах карту сообщений для этого диалога, вручную прописывал там обработчики событий, потом делал в классе прототипы этих обработчиков, потом в .cpp делал их реализацию. Да, переход от прототипа метода к его реализации в MSVC вроде даже работал.
I>Речь про заголвочные .h или про что? Тут согласен, что неудобно, когда для создания класса нужны отдельно .h и .cpp, в java, которому уже лет 30, с этим сильно прще.
Нет, речь про то, что надо было проделать кучу ручной работы, какой — я написал, а в дельфях это всё делалось автоматом в несколько кликов.
M>>И на самом деле — это тоже самое формошлёпство, что и на Дельфях/Билдере, только через боль и страдание. Пока дельфист делал 10 формочек для автоматизации бизнеса-процессов, гордый MSVC с трудом осиливал сделать одну, и это хорошо если всё сразу заработало, а бизнес логику он уже потом начинал пилить, когда делфист/билдерист уже шел пить пиво на заработанную премию.
I>Не помню такого. Это в awt появилис хот скол-нибудь удобные средства отображения коллекций, к примеру. И в ранних версиях android sdk было что-то похожее.
Какого ты не помнишь?
M>>В Дельфях/Билдере же ты создавал форму, перекидывал с палитры компонентов контролы, а также невизуальные компоненты, для баз данных, например, потом, выделяя контролы, ты настраивал в окне Property Editor нужные свойства, простым дабл кликом по пропертям обработчиков они создавались (тело в дельфях и прототип/тело в плюсах) и сразу приписывались контролу/компоненту.
I>И как там было с текстовым представлением?
Всё предварительно настроенное сохранялось в текстовом .dfm, но туда никто не лазал обычно, потому что не было нужды
I>Property Editor полезен, только если позабл, как что-то называется.
А если не забыл, удобнее ручками текст править (не забывая о синтаксисе этого "текста"?)
То-то сейчас все делают тоже самое
M>>Это было супер удобно для построения интерфейсов. Сейчас всякие C#, Qt с QtCreator'ом и прочие пытаются приблизиться к этому идеалу, но получается всё равно сложно и не так удобно, с кучей каких-то костылей.
I>C# более или менее созрел лишь лет 15 назад, только поэтому я не привожу в сравнение. Но до сих пор ничего удобнее XAML для клепания UI я не видел, стандартнй android sdk, к примеру, до этого уровня всё равно не дотягивает, хотя улучшения было немало с первх версий.
Ну вот XAML — это и есть попытка шарпистов сделать так же удобно, как было в дельфях
I>Но MFC был сделан под GDI, когда графические процессоры были ещё экзотикой.
Здравствуйте, Ilya81, Вы писали:
I>Я слшал, что XNA как раз со своим garbage collector некогда провалился, так что это как раз скорее в минус, хотя других достоинств много. В Swift другое решние, если кто забудет вызвать delete/dealloc, но у него куча сових недостатков.
Сборка мусора бывает разной. "Stop the world" в java видел.
Как я понял, то, как прикрутили сборку мусора в эрланге — это одна из самых крутых фишек эрланга. Там обеспечивается soft real-time, но стиль программирования должен быть в идеале функциональным. Это прочитал из книг. Как оно в реальных проектах — не видел.
В общем, у каждого (виртуального) процесса отдельная куча с отдельной сборкой мусора. Между процессами нет общей памяти (кроме двоичных данных, которые располагаются в отдельной куче и передаются через простой подсчет ссылок — там не может быть циклов). Если падает один процесс, то это не затрагивает другие. А философия такая, что пусть процессы падают, если что пошло не так. Потом они поднимаются супервизором. Супервизоры образуют дерево. Плюс вытесняющая многозадачность, где каждому процессу отводится определенное количество редукций (взвешенная оценка количества операций). Процессы легковесные. Легко можно создать под миллион процессов.
Все это выглядит так заманчиво! Даже если не нужен навороченный сервис 24 на 7, то интересно даже было бы попробовать как микросервис для REST на том же Elixir (скрестили эрланг с руби) или даже на чистом эрланге.
Здравствуйте, Michael7, Вы писали:
M>Там выше novitk вспомнил, что в 1991-м году Borland купили Ashton-Tate — это была дорогая и действительно ненужная покупка. Еще они попытались конкурировать с MS на рынке офисных средств, примерно тогда начали выпускать Borland Office как конкурент Microsoft Office. Но что-то, как говорится, пошло не так. Интересно, многие ли сейчас вообще вспомнят о существовании такого продукта, а также о dBase и Ashton-tate?
Borland Office — даже такое было? Надо же, не знал
Здравствуйте, dsorokin, Вы писали:
D>В общем, у каждого (виртуального) процесса отдельная куча с отдельной сборкой мусора. Между процессами нет общей памяти (кроме двоичных данных, которые располагаются в отдельной куче и передаются через простой подсчет ссылок — там не может быть циклов).
Так куча для того и делалась, чтобы те, кому сейчас нужна память, взять сколько надо из общей кучи, а потом вернуть, чтобы другие, при необходимости, могли переиспользовать эту память под свои нужды. А то, что ты описываешь, не особо от стека отличается
Здравствуйте, Ilya81, Вы писали:
R>>Какой из Novell был конкурент Где был Novell и где гуевая винда. К тому же в Novell 5 завезли Java, которая на хорошем железе того времени (чистокровном межделмаше) еле-еле проворачивала свои объектные иерархии
I>Может, от того, что не конкурент, конечно. Хотя Suse одно время был лучшей ОСью по моему впечатлению. Но я намекаю на Mono.
Речь идёт о середине 90ых и о флагманском продукте Novell того времени — Novell NetWare со своими сетевыми протоколами IPX/SPX. Suse же была куплена Novell только в 2003ем году.
У тебя какие-то странные и нерелевантные сведения об истории развития как ОС, так и систем разработки. Откуда ты их черпаешь?
Здравствуйте, Ilya81, Вы писали:
I>Так Suse — это их творение, помнится мне. Не все дистрибутив linux одинаковые. Но потом, лет 10 назад, всё ж качество у них стало прадать.
Тебе неправильно помнится. Они купили SuSe после того, как всё просрали со своим NetWare, SuSe развивался самостоятельно до этого в течении почти 10ти лет
Здравствуйте, Kocur, Вы писали:
K>Borland Office — даже такое было? Надо же, не знал
Borland Office is an office suite published by Borland built around WordPerfect, Paradox, and Quattro Pro. It competed unsuccessfully against Microsoft Office. It was later acquired by Novell and renamed "PerfectOffice", and then later became "Corel Office".
Release notes
Borland Office 2.0 includes WordPerfect 6.0, Paradox 4.5, Quattro Pro 5.0, and Presentation Adviser.
Requires a 386 or higher, 4MB of ram, 16MB of hard drive space, and Windows 3.1.
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, Ilya81, Вы писали:
I>>>>Строки теста — там более, можно просто скопировать откуда-то.
M>>>При чем тут строки?
I>>Редактирование ресурсов — вроде это строки в основной своей массе, или нет?
M>Нет конечно. Строки ты мог и прямо в коде "зашить"...
Не лучший вариант.
M>>>И на самом деле — это тоже самое формошлёпство, что и на Дельфях/Билдере, только через боль и страдание. Пока дельфист делал 10 формочек для автоматизации бизнеса-процессов, гордый MSVC с трудом осиливал сделать одну, и это хорошо если всё сразу заработало, а бизнес логику он уже потом начинал пилить, когда делфист/билдерист уже шел пить пиво на заработанную премию.
I>>Не помню такого. Это в awt появилис хот скол-нибудь удобные средства отображения коллекций, к примеру. И в ранних версиях android sdk было что-то похожее.
M>Какого ты не помнишь?
Что в delph было удобного для отображения списков, например. Может, в какой-то моент появилос. I>>Property Editor полезен, только если позабл, как что-то называется.
M>А если не забыл, удобнее ручками текст править (не забывая о синтаксисе этого "текста"?) M>То-то сейчас все делают тоже самое
Разумеется. Я, конечно, знавал любителей клепать диаграммы баз даннх в редакторах схем, где для создания одной таблиц порой требовалос гигантское количество дейстий мышью, мне этого не понять, мне несравнимо проще написать SQL. Так что не искючаю и любителей всяких Property Editor, и этого мне не понять. Разве что синтаксис очен сложнй, но, к примеру в iOS storyboards я часто ради формирования id только пользуюс встроенным редактором, а в омногих случаях предпочитаю xib/storybaord поправить вручную.
M>>>Это было супер удобно для построения интерфейсов. Сейчас всякие C#, Qt с QtCreator'ом и прочие пытаются приблизиться к этому идеалу, но получается всё равно сложно и не так удобно, с кучей каких-то костылей.
I>>C# более или менее созрел лишь лет 15 назад, только поэтому я не привожу в сравнение. Но до сих пор ничего удобнее XAML для клепания UI я не видел, стандартнй android sdk, к примеру, до этого уровня всё равно не дотягивает, хотя улучшения было немало с первх версий.
M>Ну вот XAML — это и есть попытка шарпистов сделать так же удобно, как было в дельфях
А в какй-то версии delphi удобнее? Ну я не смотрел соотвестующую версию, значит.
I>>Но MFC был сделан под GDI, когда графические процессоры были ещё экзотикой.
M>А причем тут GDI и графические процессоры?
Ну для начала неизбежны разне принципы построения UI, графический процессор быстро выполняет composing, а на центральном процессоре часто быстрее отдельные линии перерисовавть, а заполнять прямоугольные области, не особенно пользуяс полупрозрачностью. Соотвественно, ориентированность на GDI для поддержания единого стандарта.
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, Ilya81, Вы писали:
R>>>Какой из Novell был конкурент Где был Novell и где гуевая винда. К тому же в Novell 5 завезли Java, которая на хорошем железе того времени (чистокровном межделмаше) еле-еле проворачивала свои объектные иерархии
I>>Может, от того, что не конкурент, конечно. Хотя Suse одно время был лучшей ОСью по моему впечатлению. Но я намекаю на Mono.
M>Речь идёт о середине 90ых и о флагманском продукте Novell того времени — Novell NetWare со своими сетевыми протоколами IPX/SPX. Suse же была куплена Novell только в 2003ем году.
M>У тебя какие-то странные и нерелевантные сведения об истории развития как ОС, так и систем разработки. Откуда ты их черпаешь?
Кстати, после закрытия проекта Kylix (кроссплатформенный Delphi, переживший три версии) ходили слухи, что именно МС надавила на Борланд для его закрытия (она могла т.к. владела приличным пакетом акций Борланда).
сомневаюс, что здес
Речь идёт о середине 90ых
Если и раньше 3-го года, но уж всяко в нынешнем веке. Про NetWare я уже тогда мало что слышно было, а TCP/IP к тому времени уже был всеобщим стандартом.
I>>>Не помню такого. Это в awt появилис хот скол-нибудь удобные средства отображения коллекций, к примеру. И в ранних версиях android sdk было что-то похожее.
M>>Какого ты не помнишь?
I>Что в delph было удобного для отображения списков, например. Может, в какой-то моент появилос.
В дельфи были, как минимум, все виндовые контролы, только использовались они не через винапи, а гораздо удобнее. Ну и куча сторонних. Если из виндовых — то обычный ListBox — чем тебе не список?
I>>>Property Editor полезен, только если позабл, как что-то называется.
M>>А если не забыл, удобнее ручками текст править (не забывая о синтаксисе этого "текста"?) M>>То-то сейчас все делают тоже самое
I>Разумеется.
Что разумеется?
I>Я, конечно, знавал любителей клепать диаграммы баз даннх в редакторах схем, где для создания одной таблиц порой требовалос гигантское количество дейстий мышью, мне этого не понять, мне несравнимо проще написать SQL.
Прикинь, диаграммы баз данных иногда рисуют, чтобы понимать структуру базы данных, даже если сами таблицы были созданы текстовым SQL. А иногда даже удобно нарисовать диаграмму, а по ней автоматом сгенерить код SQL, если инструмент такой есть в наличии — просто тупо по тому, что под каждую СУБД могут быть свои нюансы этого SQL, хотя, когда используешь только одну СУБД, то обычно все нюансы уже заучил.
I>Так что не искючаю и любителей всяких Property Editor, и этого мне не понять. Разве что синтаксис очен сложнй, но, к примеру в iOS storyboards я часто ради формирования id только пользуюс встроенным редактором, а в омногих случаях предпочитаю xib/storybaord поправить вручную.
Я, было дело, кой чо делал для андроида, а там всё в XML описывается, и есть всякие визуальные типа Property Editor. Только вот они там ужасно убогие, и только поэтому я ручками писал XML, а иногда и генерил какими-нибудь скриптами. Только это не про Дельфи — там это было супер удобно.
M>>Ну вот XAML — это и есть попытка шарпистов сделать так же удобно, как было в дельфях
I>А в какй-то версии delphi удобнее? Ну я не смотрел соотвестующую версию, значит.
Да в любой 1-7. Ты, видимо, Дельфи только на картинках и видел
I>>>Но MFC был сделан под GDI, когда графические процессоры были ещё экзотикой.
M>>А причем тут GDI и графические процессоры?
I>Ну для начала неизбежны разне принципы построения UI, графический процессор быстро выполняет composing, а на центральном процессоре часто быстрее отдельные линии перерисовавть, а заполнять прямоугольные области, не особенно пользуяс полупрозрачностью. Соотвественно, ориентированность на GDI для поддержания единого стандарта.
Так и причем тут GDI и графические процессоры? Это проблемы нижнего слоя — рендерера, как и что рисовать. К удобству построения UI это не имеет никакого отношения, если, конечно, криворукие архитекторы не протащили подобные зависимости по разным слоям архитектуры
M>>У тебя какие-то странные и нерелевантные сведения об истории развития как ОС, так и систем разработки. Откуда ты их черпаешь?
I>
I>Кстати, после закрытия проекта Kylix (кроссплатформенный Delphi, переживший три версии) ходили слухи, что именно МС надавила на Борланд для его закрытия (она могла т.к. владела приличным пакетом акций Борланда).
I>сомневаюс, что здес I>
I>Речь идёт о середине 90ых
I>Если и раньше 3-го года, но уж всяко в нынешнем веке. Про NetWare я уже тогда мало что слышно было, а TCP/IP к тому времени уже был всеобщим стандартом.
Novell NetWare 4 — 1993 — вот тут они с ней неплохо вылезли, так, например, в 1996ом у нас в универе сеть была на ней (или может уже на 4.1)
Novell NetWare 4.1 — 1996
Windows NT 4 — 1996 — вот тут Novell покатился в жопу
Novell NetWare 5 — 1998 — тут уже полетел в жопу
Novell NetWare 5.1 — 2000 — тут уже плотно приземлился туда
Novell NetWare 6 — 2001 — пытаются дёргаться
Borland Kylix 3 — 2002
Покупка Novell'ом SuSe — 2003
Novell Open Enterprise Server (OES) — 2003 — SuSe как опция, на каком ядре работать
Mono — 2004
RIP Borland Kylix — 2005
I>Может, от того, что не конкурент, конечно. Хотя Suse одно время был лучшей ОСью по моему впечатлению.
Novell был полудохлый и помирал с 96го года. Борланд же выпекал версии Дельфей и потом Kylix практически ежегодно
I>Но я намекаю на Mono.
Kylix — конкурент ДотНету. Mono — считай халявный порт на другую платформу ядра майкрософтовской экосистемы
Здравствуйте, Marty, Вы писали:
M>Novell NetWare 4.1 — 1996 M>Windows NT 4 — 1996 — вот тут Novell покатился в жопу
Нет. В 96м еще вовсю использовали и активно внедряли именно NetWare.
Ибо, NT4 хоть и была лучше предшественника, но до какого-то (3го? 4го?) сервис пака была, как бы это помягче сказать, ну глючновата, да и после паков не все работала без танцев с бубном.
Ну и планы, бюджеты и инерция были за NetWare.
Я тогда занимался как раз сетями. NetWare 4.1 или комбинация NetWare 4.1 + NT4 были массовы до начала 2000.
M>Novell NetWare 5.1 — 2000 — тут уже плотно приземлился туда
Там, 2000х Windows подтянулся, и кузнец NetWare стала не нужна.
На 5ку переходили, наверное, только очень сильно забюрократированные конторы, в которых версии софта и бюджет под них сильно заранее отливались в камне и не могло быть пересмотренно ничего.
Многие и рады были бы испытать когнитивный диссонанс, но нечем.
Здравствуйте, Артём, Вы писали:
Аё>Ещё у MFC была из коробки Document View Controller- был wizard на создание своего WYSIWYG приложения.
MFC базируется на Windows API.
И при этом в MFC нет ориентиции на RAD (быстрое формошлёпство)
MFC в своё время был популярен прежде всего за счёт близости к Windows, и при этом — у него была лекговесность.
При этом, применение C++ и WinAPI в составе MFC проектов — позволяло делать интересные (на то время) разработки.
Аё>У Delphi же была ориентация на очень быстрое формошлёпство.
+100500
Да, тикие продукты как Delphi и C++Builder действительно ориентированы на RAD — Rapid Application Development
Единственное, что мешает им сегодня — отсутствие кросс-платформенности
ИМХО — именно "проворонив" кроссплатформу — Борланд свернул не туда...
Здравствуйте, paucity, Вы писали:
M>>Novell NetWare 4.1 — 1996 M>>Windows NT 4 — 1996 — вот тут Novell покатился в жопу
P>Нет. В 96м еще вовсю использовали и активно внедряли именно NetWare.
P>Ибо, NT4 хоть и была лучше предшественника, но до какого-то (3го? 4го?) сервис пака была, как бы это помягче сказать, ну глючновата, да и после паков не все работала без танцев с бубном.
P>Ну и планы, бюджеты и инерция были за NetWare.
P>Я тогда занимался как раз сетями. NetWare 4.1 или комбинация NetWare 4.1 + NT4 были массовы до начала 2000.
Дык, покатился, но не быстренько. Как файловый сервер его ещё использовали, да. Но что-то остальное уже работало под NT. А полетел уже в жопу он попозже, да
И это в конторах с налаженной уже инфрой. А я начал работать в 99ом разрабом в говноконторе, ну и админил там. Сначала была одноранговая сеть Win9X на коксиале, через год с небольшим я пробил сервак (на W2K Server) и витую пару со свичами, поднял там Active Directory, а про Новел я вообще даже и думать не собирался
M>>Novell NetWare 5.1 — 2000 — тут уже плотно приземлился туда
P>Там, 2000х Windows подтянулся, и кузнец NetWare стала не нужна.
Здравствуйте, AlexGin, Вы писали:
AG> Да, тикие продукты как Delphi и C++Builder действительно ориентированы на RAD — Rapid Application Development
AG> Единственное, что мешает им сегодня — отсутствие кросс-платформенности
В сегодняшнюю Delphi кроссплатформу завезли почти 14 лет назад.
AG> ИМХО — именно "проворонив" кроссплатформу — Борланд свернул не туда...
У Борланда была кроссплатформа — Kylix. Появилась в 2001.
Здравствуйте, AlexGin, Вы писали:
AG>MFC в своё время был популярен прежде всего за счёт близости к Windows, и при этом — у него была лекговесность.
Шито?!!111
Наверное, из-за легковесности Microsoft'ского MFC в том же Microsoft родилась WTL
AG>При этом, применение C++ и WinAPI в составе MFC проектов — позволяло делать интересные (на то время) разработки.
На C++ Builder можно было делать не хуже, и я, так-то, делал
Аё>>У Delphi же была ориентация на очень быстрое формошлёпство. AG>+100500 AG>Да, тикие продукты как Delphi и C++Builder действительно ориентированы на RAD — Rapid Application Development
А сейчас все поголовно пытаются сделать что-то для быстрого формошлепства, но пока не очень получается.
AG>Единственное, что мешает им сегодня — отсутствие кросс-платформенности
AG>ИМХО — именно "проворонив" кроссплатформу — Борланд свернул не туда...
Kylix же.
Имхо, проблема в том, что они сделали CLX вместо VCL для кроссплатформы, а надо было делать кроссплатформенный VCL. И я не вижу особых препятствий для этого — тот же wxWidgets а) использует нативные контролы платформы (как минимум Win/Lin), и, соответственно, на этих платформах аппы выглядят и работают как родные; б) разработка на wxWidgets очень похожа на разработку на MFC или WTL — соответственно, как я вижу, особых проблем сделать VCL под линукс нет.
wxWidgets же, ранее wxWindows, была начата в 92ом году:
Вначале wxWindows был нацелен на Xview и MFC 1.0. Пользователи Borland C++, жаловавшиеся на привязку к MFC, таким образом, стали переписывать программы на чистый Win32. Поскольку XView открывал путь на Motif, то перенос на Motif был запущен весьма оперативно.
В 1997 году новая версия wxWindows 2 API была спроектирована при помощи Маркуса Холзема (который ещё во времена создания рассылки создал Xt-направление wxWindows). Вольфрам Глогер предложил идею портирования wxWindows на GTK, и Роберт Роблинг создал необходимые графические элементы пользователя, адаптированные для GNOME. Он стал основоположником разработки wxGTK, и поныне оставаясь главным специалистом в разработке Unix/Linux-порта wxWidgets.
В 1998 году порт для Windows и порт для GTK были совмещены и выложены под управлением системы CVS. Вадим Цейтлин присоединился к проекту, чтобы поспособствовать разработке огромной части дизайна и кода. Штефан Чомор также в 1998 начал создание порта на MacOS.
1999 год обозначен приходом программиста с именем Вацлав Славик (Vaclav Slavik). Он создал внушительные wxHTML-классы и основанный на HTML просмотрщик справочных файлов.
В 2000 году фирма SciTech Inc. профинансировала начало разработки wxUniversal — собственный для wxWindows набор графических элементов пользователя для использования на платформах, у которых пока что нет никаких графических элементов пользователя.
В 2002 году Джулиан Смарт и Роберт Ройблинг добавили порт wxX11, используя wxUniversal.
В июле 2003 года wxWindows начала запускаться на Windows CE, а Роберт Ройблинг продемонстрировал wxGTK-приложение, запущенное на встраиваемой платформе GPE Linux.
По идее, в wxWindows/wxWidgets уже всё было готово, чтобы взять её за бэкэнд.
Хотя, погуглил, они вроде не заново всё под линукс делали, а заюзали Qt:
В 2001 году Borland реализовал версию Delphi под Linux, названную Kylix. Вместо библиотеки VCL использовалась кроссплатформенная CLX (оболочка для Qt). IDE Kylix базировался на библиотеках Wine.
Тут хз, конечно, что лучше, Qt или wxWidgets, особенно на тот момент. Но я делал когда-то свой фреймворк для гуя в рамках своей плагинной системы, и Win32 и wxWidgets версии у меня получились очень похожими, а вот кутишную версию с ихними сигналами и слотами и мок-компилятором я начал делать, но не осилил до того же состояния, что и версии Win32 и wxWidgets, и моя кроссплатформа собиралась только под Win32 и под Linux c wxWidgets. Qt я думал туда присунуть, чтобы можно было выбирать, какой GUI-бэкэнд нужен под Linux — у кого-то могли уже быть наработки под Qt, а я хотел сделать универсальную либу
Им имхо надо было не переименовывать либу компонентов VCL->CLX (это уже отпугивает), а делать кроссплатформенную VCL, полностью совместимую с предыдущими версиями VCL, чтобы просто открыть старый дельфийский проект в новом Кайликсе и просто его собрать под линукс, это бы не отпугивало неясной по срокам перспективой переделки старых проектов. А то, вон, кхимики до сих пор теперь мучаются.
Здравствуйте, rudzuk, Вы писали:
AG>> Единственное, что мешает им сегодня — отсутствие кросс-платформенности
R> В сегодняшнюю Delphi кроссплатформу завезли почти 14 лет назад.
И получилось говно. Им надо было делать бесшовную кроссплатформу во времена первого Кайликса, полностью совместимую с предыдущими Дельфями, 25 лет назад. Тогда бы от них разрабы бы не разбежались бы.
AG>> ИМХО — именно "проворонив" кроссплатформу — Борланд свернул не туда...
R> У Борланда была кроссплатформа — Kylix. Появилась в 2001.
Вот эта херня меня и отпугнула тогда, много гемора было с этим Кайликсом. А когда они его потом прикрыли, то вообще с Борландом связываться желания больше не возникало. Хотя, я на старых Дельфях/Билдере 7 лабал бизнес-аппы в одной конторе уже в конце нулевых, но там просто было уже давно заведено лабать на седьмых Дельфях приложухи для доступа в MS SQL, а Билдер я туда привнёс, потому что на Дельфях нормально ничего нельзя сделать.
Здравствуйте, Marty, Вы писали:
M> R> В сегодняшнюю Delphi кроссплатформу завезли почти 14 лет назад.
M> И получилось говно.
Кто тебе сказал???
M> Им надо было делать бесшовную кроссплатформу во времена первого Кайликса, полностью совместимую с предыдущими Дельфями, 25 лет назад. Тогда бы от них разрабы бы не разбежались бы.
Это означало бы полную ревизию VCL с гарантированной потерей обратной совместимости при негарантированном результате. Выбор у них был небольшой
M> R> У Борланда была кроссплатформа — Kylix. Появилась в 2001.
M> Вот эта херня меня и отпугнула тогда, много гемора было с этим Кайликсом.
У меня гемора небыло Да, на виндах CLX выглядел, как говно (это к Qt претензии), но на линуксе был весьма органичен.
Здравствуйте, rudzuk, Вы писали:
M>> R> В сегодняшнюю Delphi кроссплатформу завезли почти 14 лет назад.
M>> И получилось говно.
R>Кто тебе сказал???
Это моё оценочное мнение
M>> Им надо было делать бесшовную кроссплатформу во времена первого Кайликса, полностью совместимую с предыдущими Дельфями, 25 лет назад. Тогда бы от них разрабы бы не разбежались бы.
R>Это означало бы полную ревизию VCL с гарантированной потерей обратной совместимости при негарантированном результате. Выбор у них был небольшой
Обратная совместимость от старших версий к младшим разве кем-то когда-то делалась?
А гарантированность результата... Хм... Ну я делал свой гуй как-то, Win32/WTL и wxWidgets, и у меня в одно лицо вполне получилось за несколько месяцев. VCL конечно побольше, но там в конторе и умных людей по идее побольше, чем у меня
R>У меня гемора небыло Да, на виндах CLX выглядел, как говно (это к Qt претензии), но на линуксе был весьма органичен.
Ну, значит, ошиблись в выборе GUI бекэнда — надо было брать wxWidgets, он как родной и там и там.
А виндовая аудитория таки для них была основной кормовой базой, и этим говном их нельзя было отпугивать. А к кому претензии, к Qt или ещё к кому-то — это уже пофик, когда конечный результат выглядит как говно
Здравствуйте, Marty, Вы писали:
M>На MSVC/MFC или WTL ты сначала делал вручную или в редакторе ресурсов диалог, затем вручную делал в сорцах карту сообщений для этого диалога, вручную прописывал там обработчики событий, потом делал в классе прототипы этих обработчиков, потом в .cpp делал их реализацию. Да, переход от прототипа метода к его реализации в MSVC вроде даже работал.
+100500
Я много работал с этой технологией. Могу сказать, что когда приноровишься — это всё уже делаешь "на_автомате" и много времени оно не занимает.
M>И на самом деле — это тоже самое формошлёпство, что и на Дельфях/Билдере, только через боль и страдание. Пока дельфист делал 10 формочек для автоматизации бизнеса-процессов, гордый MSVC с трудом осиливал сделать одну, и это хорошо если всё сразу заработало, а бизнес логику он уже потом начинал пилить, когда делфист/билдерист уже шел пить пиво на заработанную премию.
Я видел другое — в это время делфист/билдерист начинает биться с багами проекта, в то время как MFC-разработчик уже готовится к презентации...
Мне также запомнилось, как C++Builder IDE внезапно падала. Такая среда как MSVS-6 при этом — стояла стабильно, как скала.
M>Это было супер удобно для построения интерфейсов. Сейчас всякие C#, Qt с QtCreator'ом и прочие пытаются приблизиться к этому идеалу, но получается всё равно сложно и не так удобно, с кучей каких-то костылей.
Если ты про сегодняшний QtCreator — то этот современный продукт на две/три головы выше Delphi/Builder 10-ти летней давности.
Также он совершеннее, нежели современный Lazarus.
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, AlexGin, Вы писали:
AG>>MFC в своё время был популярен прежде всего за счёт близости к Windows, и при этом — у него была лекговесность. M>Шито?!!111
Именно так — какая DLL библиотека (фреймворк) окажется более легковесной, нежели MFC???
Я не идеализирую MFC — никак нет. Но для 1990-х это был гигантский шаг вперёд!
M>Наверное, из-за легковесности Microsoft'ского MFC в том же Microsoft родилась WTL
Ну а почему же на C# (.NET)?
AG>>При этом, применение C++ и WinAPI в составе MFC проектов — позволяло делать интересные (на то время) разработки.
M>На C++ Builder можно было делать не хуже, и я, так-то, делал
Да, я также делал — формошлепство на C++Builder 5.0 (VCL) и капитальные проекты на MSVC-2003 — MFC/WinAPI
И всё это — на C++
Здравствуйте, AlexGin, Вы писали:
M>>На MSVC/MFC или WTL ты сначала делал вручную или в редакторе ресурсов диалог, затем вручную делал в сорцах карту сообщений для этого диалога, вручную прописывал там обработчики событий, потом делал в классе прототипы этих обработчиков, потом в .cpp делал их реализацию. Да, переход от прототипа метода к его реализации в MSVC вроде даже работал. AG>+100500 AG>Я много работал с этой технологией. Могу сказать, что когда приноровишься — это всё уже делаешь "на_автомате" и много времени оно не занимает.
Я работал и там и там довольно много. Хоть на автомате, хоть нет, но MFC/WTL кучу времени сжирает на эту тупую хрень
M>>И на самом деле — это тоже самое формошлёпство, что и на Дельфях/Билдере, только через боль и страдание. Пока дельфист делал 10 формочек для автоматизации бизнеса-процессов, гордый MSVC с трудом осиливал сделать одну, и это хорошо если всё сразу заработало, а бизнес логику он уже потом начинал пилить, когда делфист/билдерист уже шел пить пиво на заработанную премию. AG> AG>Я видел другое — в это время делфист/билдерист начинает биться с багами проекта, в то время как MFC-разработчик уже готовится к презентации...
Тут ведь как — для MFC просто нужна была гораздо большая квалификация, и да, средний дельфист был менее квалифицирован. Но под автоматизацию бизнеса Дельфи был таки на порядки более заточен. А на каких проектах ты видел торжество MFC-разработчика?
AG>Мне также запомнилось, как C++Builder IDE внезапно падала. Такая среда как MSVS-6 при этом — стояла стабильно, как скала.
Билдер изредка падал, было дело в ранних версиях. А MSVS-6 как была убогим говном во времена C++ Builder 1.0, так и оставалась убогим говном во времена C++ Builder 5.0. MSVS начала походить на нормальную IDE только после выхода MSVS2002/7.0
M>>Это было супер удобно для построения интерфейсов. Сейчас всякие C#, Qt с QtCreator'ом и прочие пытаются приблизиться к этому идеалу, но получается всё равно сложно и не так удобно, с кучей каких-то костылей. AG> AG>Если ты про сегодняшний QtCreator — то этот современный продукт на две/три головы выше Delphi/Builder 10-ти летней давности.
Он отстойнее 7го билдера. Что я, QtCreator'а что ли не видел?
AG>Также он совершеннее, нежели современный Lazarus.
Здравствуйте, AlexGin, Вы писали:
AG>>>MFC в своё время был популярен прежде всего за счёт близости к Windows, и при этом — у него была лекговесность. M>>Шито?!!111
AG>Именно так — какая DLL библиотека (фреймворк) окажется более легковесной, нежели MFC???
Я когда тыкал в MFC палочкой, сложилось впечатление, что MFC — жирная бесполезная библиотека, поэтому долгое время писал на WinAPI при помощи сначала своих обёрток, а потом при помощи WTL. И при том и при другом варианте никакие DLL не были нужны, а размер EXE был минимальным.
Поискал, кстати, MFC — mfc42.dll — больше мегабайта, но это древняя MFC, из второй половины 90ых.
wxbase28_vc.dll от примерно 2011 года — на пару сотен метров меньше. Но это уже на 13 лет старше либа, и я не искал в сети, просто на своём компе поискал
При этом у MFC кроме обёрток на гуем я хз что там было, а в VCL были например супер удобные классы для доступа к СУБД. И для того, чтобы сделать по базе какой-то отчет, не надо было неделями пехаться с ручной работой с каким-нибудь ODBC, а можно было мышкой за полчаса накидать компонент на форму и настроить их, и всё просто работало
AG>Я не идеализирую MFC — никак нет. Но для 1990-х это был гигантский шаг вперёд!
Ты просто ничего другого не знал, как я понимаю. Как наш Артёмка. Один снобизм — ааа, он быстро смог сделать то, на что я тратил недели — фоормошлёёёёёп...
M>>Наверное, из-за легковесности Microsoft'ского MFC в том же Microsoft родилась WTL AG> AG>Ну а почему же на C# (.NET)?
Не распарсил, что на C#?
AG>>>При этом, применение C++ и WinAPI в составе MFC проектов — позволяло делать интересные (на то время) разработки.
M>>На C++ Builder можно было делать не хуже, и я, так-то, делал AG> AG>Да, я также делал — формошлепство на C++Builder 5.0 (VCL) и капитальные проекты на MSVC-2003 — MFC/WinAPI AG>И всё это — на C++
Так-то, C++Builder 5.0 — это 2000ый год, а MSVC2003 — сам понимаешь, какой год.
Я могу понять, что тебе мешало заниматься формошлёпством на MSVC/MFC — отсутствие там такой возможности. Я не могу понять, что тебе мешало делать капитальные проекты на C++Builder 5.0... Возможно, незнание VCL или ещё какая-то проблема с компетентностью
Здравствуйте, Marty, Вы писали:
M> M>> Им надо было делать бесшовную кроссплатформу во времена первого Кайликса, полностью совместимую с предыдущими Дельфями, 25 лет назад. Тогда бы от них разрабы бы не разбежались бы.
M> R>Это означало бы полную ревизию VCL с гарантированной потерей обратной совместимости при негарантированном результате. Выбор у них был небольшой
M> Обратная совместимость от старших версий к младшим разве кем-то когда-то делалась?
Ты говоришь о бесшовной кроссплатформе, это понимать как? Я понимаю так, что берешь код написаный под старую VCL, компилируешь на новой и получаешь переносимый гуй. Так вот это фантастика.
M> А гарантированность результата... Хм... Ну я делал свой гуй как-то, Win32/WTL и wxWidgets, и у меня в одно лицо вполне получилось за несколько месяцев. VCL конечно побольше, но там в конторе и умных людей по идее побольше, чем у меня
Сравнил конечно... Одно дело, если бы VCL изначально проектировалась под кроссплатформу, и совсем другое, когда VCL затачивалась специально под винду и к моменту решения о кроссплатформе был накоплен гигантский объем кода у клиентов и вендоров компонент. Поэтому решение о новом гуй-фреймворке было логичным.
M> R>У меня гемора небыло Да, на виндах CLX выглядел, как говно (это к Qt претензии), но на линуксе был весьма органичен.
M> Ну, значит, ошиблись в выборе GUI бекэнда — надо было брать wxWidgets, он как родной и там и там.
M> А виндовая аудитория таки для них была основной кормовой базой, и этим говном их нельзя было отпугивать. А к кому претензии, к Qt или ещё к кому-то — это уже пофик, когда конечный результат выглядит как говно
На самом деле все было достаточно неплохо. Ну не беда, что типичное бизнес-приложение не умеет в темы XP (гуй на CLX):
Здравствуйте, rudzuk, Вы писали:
R>Ты говоришь о бесшовной кроссплатформе, это понимать как? Я понимаю так, что берешь код написаный под старую VCL, компилируешь на новой и получаешь переносимый гуй. Так вот это фантастика.
Именно так. И никакой фантастики я в этом не вижу.
M>> А гарантированность результата... Хм... Ну я делал свой гуй как-то, Win32/WTL и wxWidgets, и у меня в одно лицо вполне получилось за несколько месяцев. VCL конечно побольше, но там в конторе и умных людей по идее побольше, чем у меня
R>Сравнил конечно... Одно дело, если бы VCL изначально проектировалась под кроссплатформу, и совсем другое, когда VCL затачивалась специально под винду
wxWidgets вообще был сделан на базе MFC, а в результате стал кроссплатформенной либой. И живет до сих пор, в отличие от VCL.
Состав контролов, и принципы работы гуя (сообщения, и их выборка из очереди сообщений, и рассылка подписчикам) — это универсально для всех систем. Только в кути пошли по своему пути, и сделали свои сигнал-слоты (в принципе, это чем-то похоже на VCL обработчики onXXX), но сделали это через свой moc-компилятор. А тот же wxWidgets остался очень похожим на MFC, и без лишних сущностей типа moc, и я не вижу проблем, почему на нём нельзя было сделать полностью совместимый VCL.
Не вижу проблем, почему с VCL нельзя было сделать аналогично. Да, в кишочках были бы изменения, но снаружи можно было сделать всё совместимое.
Можно было просто взять тот же кроссплатформенный wxWidgets в качестве GUI-бекэнда
R>и к моменту решения о кроссплатформе был накоплен гигантский объем кода у клиентов и вендоров компонент. Поэтому решение о новом гуй-фреймворке было логичным.
Только этот объём кода был, скорее всего, заточен не на винду уже, а на VCL. А если он был заточен на винду — то тогда не понятно, как создание новой CLX оставляло совместимость с этой кодовой базой и почему надо было делать CLX, а не развивать VCL
Здравствуйте, Marty, Вы писали:
M> R>Ты говоришь о бесшовной кроссплатформе, это понимать как? Я понимаю так, что берешь код написаный под старую VCL, компилируешь на новой и получаешь переносимый гуй. Так вот это фантастика.
M> Именно так. И никакой фантастики я в этом не вижу.
Ну вот смотри, простой пример. У оконных контролов есть метод CreateParams, где потомок может определенным образом модифицировать параметры окна для достижения нужного эффекта (например: Params.ExStyle := Params.ExStyle or WS_EX_...). Как такому коду обеспечивать переносимость бесшовную? Изображать внутреннюю реализацию винапи?
M> R>Сравнил конечно... Одно дело, если бы VCL изначально проектировалась под кроссплатформу, и совсем другое, когда VCL затачивалась специально под винду
M> wxWidgets вообще был сделан на базе MFC, а в результате стал кроссплатформенной либой.
Хорошо, когда ты опенсорс и у тебя нет обязательств сохранять совместимость
M> И живет до сих пор, в отличие от VCL.
Так и VCL живет.
M> Не вижу проблем, почему с VCL нельзя было сделать аналогично. Да, в кишочках были бы изменения, но снаружи можно было сделать всё совместимое.
В том и дело, что без влезания в кишочки не писался ни один серьезный компонент.
M> R>и к моменту решения о кроссплатформе был накоплен гигантский объем кода у клиентов и вендоров компонент. Поэтому решение о новом гуй-фреймворке было логичным.
M> Только этот объём кода был, скорее всего, заточен не на винду уже, а на VCL. А если он был заточен на винду — то тогда не понятно, как создание новой CLX оставляло совместимость с этой кодовой базой и почему надо было делать CLX, а не развивать VCL
Штука в том, что VCL это очень тонкая обертка над виндовыми контролами (за исключением самоотрисовывающихся контролов), поэтому чуть что и ты уже дергаешь винапи. Потому появление CLX было логичным шагом: кому не нужна кроссплатформа спокойно сидят на VCL, кому нужна, тем придется портировать свой код на новый фреймворк. Ровно та же история произошла потом и с FMX.
Здравствуйте, rudzuk, Вы писали:
R>Ну вот смотри, простой пример. У оконных контролов есть метод CreateParams, где потомок может определенным образом модифицировать параметры окна для достижения нужного эффекта (например: Params.ExStyle := Params.ExStyle or WS_EX_...). Как такому коду обеспечивать переносимость бесшовную? Изображать внутреннюю реализацию винапи?
Отремапить константы на аналогичные на другой платформе, может конечно надо немножко что-то дописать.
M>> И живет до сих пор, в отличие от VCL.
R>Так и VCL живет.
Правда, что ли?
M>> Не вижу проблем, почему с VCL нельзя было сделать аналогично. Да, в кишочках были бы изменения, но снаружи можно было сделать всё совместимое.
R>В том и дело, что без влезания в кишочки не писался ни один серьезный компонент.
Пруфов не будет?
R>Штука в том, что VCL это очень тонкая обертка над виндовыми контролами (за исключением самоотрисовывающихся контролов), поэтому чуть что и ты уже дергаешь винапи. Потому появление CLX было логичным шагом: кому не нужна кроссплатформа спокойно сидят на VCL, кому нужна, тем придется портировать свой код на новый фреймворк. Ровно та же история произошла потом и с FMX.
wxWidgets — тоже не жирная обёртка, и изначально была на MFC. Но живет как-то. Я допускаю, что писатели библиотек компонентов таки дергали винапи, а вот конечному пользователю в винапи лазать было не нужно от слова совсем. А для писателей компонентов можно было сделать некоторый слой совместимости. Всяко лучше, чем кидать всех виндовых пользователей и или создавать новую ветку компонентов
Здравствуйте, Marty, Вы писали:
M> Отремапить константы на аналогичные на другой платформе, может конечно надо немножко что-то дописать.
Если бы все было так просто...
M> R>Так и VCL живет.
M> Правда, что ли?
Всем бы так жить!
M> R>В том и дело, что без влезания в кишочки не писался ни один серьезный компонент.
M> Пруфов не будет?
Какие тебе пруфы-то нужны? Открой, какой-нибудь TBX да посмотри
M> R>Штука в том, что VCL это очень тонкая обертка над виндовыми контролами (за исключением самоотрисовывающихся контролов), поэтому чуть что и ты уже дергаешь винапи. Потому появление CLX было логичным шагом: кому не нужна кроссплатформа спокойно сидят на VCL, кому нужна, тем придется портировать свой код на новый фреймворк. Ровно та же история произошла потом и с FMX.
M> wxWidgets — тоже не жирная обёртка, и изначально была на MFC. Но живет как-то.
wxWidgets — изначально кроссплатформенный проект:
Проект под названием wxWindows (w от Windows, x от X Window System)[5] был основан в 1992 году, когда Джулиан Смарт работал в Эдинбургском Университете над инструментом диаграммирования под названием «Hardy». Вместо того, чтобы выбирать между разработкой его для рабочей станции Sun или для платформы PC, Джулиан предпочёл применить кроссплатформенный фреймворк. Поскольку мощность существующих кроссплатформенных фреймворков была ограничена, а отделение не имело необходимого бюджета для написания такового, то он решил написать его самостоятельно.
Поэтому не нужно сравнивать его с VCL, где о кроссплатформе никогда не думали.
M> Я допускаю, что писатели библиотек компонентов таки дергали винапи, а вот конечному пользователю в винапи лазать было не нужно от слова совсем.
Только если ты готов был довольствоваться тем, что предоставляла VCL. Но чуть шаг в сторону и: сделать в листбоксе несколько столбцов можно было только через винапи. Любая кастомная отрисовка сложнее паинтбокса — здравствуйте GetDC, BitBlt и т.д. Хочешь как-то по-особенному рулить ричедитом — посылаешь ему сообщения. Короче, не рассказывай мне, как оно было на VCL, я его много кушал.
Здравствуйте, rudzuk, Вы писали:
M>> Пруфов не будет?
R>Какие тебе пруфы-то нужны? Открой, какой-нибудь TBX да посмотри
Если бы я помнил/знал, что такое TBX...
M>> wxWidgets — тоже не жирная обёртка, и изначально была на MFC. Но живет как-то.
R>wxWidgets — изначально кроссплатформенный проект: R>
Проект под названием wxWindows (w от Windows, x от X Window System)[5] был основан в 1992 году, когда Джулиан Смарт работал в Эдинбургском Университете над инструментом диаграммирования под названием «Hardy». Вместо того, чтобы выбирать между разработкой его для рабочей станции Sun или для платформы PC, Джулиан предпочёл применить кроссплатформенный фреймворк. Поскольку мощность существующих кроссплатформенных фреймворков была ограничена, а отделение не имело необходимого бюджета для написания такового, то он решил написать его самостоятельно.
Вначале wxWindows был нацелен на Xview и MFC 1.0. Пользователи Borland C++, жаловавшиеся на привязку к MFC, таким образом, стали переписывать программы на чистый Win32.
R>Поэтому не нужно сравнивать его с VCL, где о кроссплатформе никогда не думали.
Да нет проблем. Но только в wxWidgets сделали, значит и в VCL можно было. Могли wxWidgets взять за бекэнд
M>> Я допускаю, что писатели библиотек компонентов таки дергали винапи, а вот конечному пользователю в винапи лазать было не нужно от слова совсем.
R>Только если ты готов был довольствоваться тем, что предоставляла VCL. Но чуть шаг в сторону и: сделать в листбоксе несколько столбцов можно было только через винапи.
По-моему, даже через WinAPI в ListBox'е нельзя было сделать несколько столбцов. Да и никогда не нужно было — были же многоколоночные ListView. А в VCL был ещё TGrid (или как-то так), у которого нет прямого аналога в Win32.
R>Любая кастомная отрисовка сложнее паинтбокса — здравствуйте GetDC, BitBlt и т.д. Хочешь как-то по-особенному рулить ричедитом — посылаешь ему сообщения.
Только не было никаких сырых винапишных GetDC и BitBlt, а были VCL обёртки для них и были VCL-методы получения этих обёрток. А обёртки над HDC, которые переносимы на другой бекэнд, помимо WinGDI, даже я делал ещё в детском садикеинституте
R>Короче, не рассказывай мне, как оно было на VCL, я его много кушал.
Я кушал не только VCL, но и много писал кроссплатформенные аппы, и сам делал совместимые обёртки. И я не на пустом месте говорю, что это не так сложно, я даже в одно лицо вполне справлялся.
Здравствуйте, Michael7, Вы писали:
M>Интересно, многие ли сейчас вообще вспомнят о существовании такого продукта, а также о dBase и Ashton-tate?
Ну я их конечно же помню — но это оттого, что у меня с них карьера началась. dBase III (точнее, РЕБУС), потом Clipper, и далее со всеми остановками.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Marty, Вы писали:
M>Поискал, кстати, MFC — mfc42.dll — больше мегабайта, но это древняя MFC, из второй половины 90ых.
Ну один мегабайт (даже в те времена) — размер небольшой. Поэтому она и легковесная.
M>При этом у MFC кроме обёрток на гуем я хз что там было, а в VCL были например супер удобные классы для доступа к СУБД.
Так ведь с этим же никто же и не спорит:
Прикладнуха (организационная, корпоративная и бухгалтерская) — VCL и C++Builder 5.0 — ну или Delphi.
Системные и околосистемные разработки — такие как SCADA, например — MSVC: MFC и WinAPI.
M>И для того, чтобы сделать по базе какой-то отчет, не надо было неделями пехаться с ручной работой с каким-нибудь ODBC,
Это вроде так, но и не так: если в библиотеке этого компонента не было — имели место проблемы.
В общем — шаг влево/вправо — расстрел.
А вот на MFC сделать свой (custom-ный) компонент. Или же приспособить какой-нибудь Active-X — было нормальной практикой.
M>Ты просто ничего другого не знал, как я понимаю.
Много чего тогда знал и пробовал. Но достойных варианотов, кроме как MFC и VCL (каждый в своей нише) — тогда просто ешё не создали.
M>Как наш Артёмка. Один снобизм...
Предлагаю не переходить на личности
M>Не распарсил, что на C#?
Ну C#; .NET; WindowsFroms — это новое, по тем временам, направление разработки настольных приложений.
Которое вскоре отодвинуло MFC и VCL далеко на задний план. Все мы стройными рядами перешли на C# в середине 2000-ных.
M>Так-то, C++Builder 5.0 — это 2000ый год, а MSVC2003 — сам понимаешь, какой год.
Ну справедливости ради, следует отметить что многие (в том числе и в нашей рабочей группе) на C++Builder 5.0 сидели до конца 2000-ных.
M>Я могу понять, что тебе мешало заниматься формошлёпством на MSVC/MFC — отсутствие там такой возможности.
Здесь не совсем так — просто на MSVC/MFC большие трудозатраты на формошлепство. Возможность — там есть, но (тут спорить не стану) — это легче на VCL.
M>Я не могу понять, что тебе мешало делать капитальные проекты на C++Builder 5.0...
Возможно, незнание VCL или ещё какая-то проблема с компетентностью
Я посмотрю на твою компетентность, когда тебе в окне SCADA системы потребуется изобразить резервуар масла с насосом и датчиками давления, температуры и т.д.
При этом — всё должно жить в динамике: насос работать (вращение ротора), датчики — показывать изменения, при переходе через threshold — аварийный сигнал...
Вот тут и окажется — что MFC/WinAPI более приспособлен для этого, нежели VCL.
Здравствуйте, Marty, Вы писали:
M>Altium Designer написан на дельфях, кстати. Капитальный проект или формошлёпство?
Мы разве рассматриваем от слова "вообще что есть на сегодня"?
Или в плане историческом: "20-25 лет назад", что было во времена популярности компании Борланд?
Вроде как все-таки второе.
В википедии насчет этого продукта: Written in: Delphi, C#, C++
Здравствуйте, AlexGin, Вы писали:
M>>Поискал, кстати, MFC — mfc42.dll — больше мегабайта, но это древняя MFC, из второй половины 90ых.
AG>Ну один мегабайт (даже в те времена) — размер небольшой. Поэтому она и легковесная.
wxWidgets тогда тоже легковесная
AG>Это вроде так, но и не так: если в библиотеке этого компонента не было — имели место проблемы.
У меня не было проблем
AG>В общем — шаг влево/вправо — расстрел.
Такое мнение сложилось от того, что на Дельфях было много слабых программистов, и всё. А так — никакого расстрела, ничего такого, что можно сделать на MFC, и нельзя на VCL, не было
AG>А вот на MFC сделать свой (custom-ный) компонент. Или же приспособить какой-нибудь Active-X — было нормальной практикой.
На VCK — тоже самое
M>>Не распарсил, что на C#?
AG>Ну C#; .NET; WindowsFroms — это новое, по тем временам, направление разработки настольных приложений. AG>Которое вскоре отодвинуло MFC и VCL далеко на задний план. Все мы стройными рядами перешли на C# в середине 2000-ных.
Я писал про WTL, откуда тут появился C#?
AG>Я посмотрю на твою компетентность, когда тебе в окне SCADA системы потребуется изобразить резервуар масла с насосом и датчиками давления, температуры и т.д. AG>При этом — всё должно жить в динамике: насос работать (вращение ротора), датчики — показывать изменения, при переходе через threshold — аварийный сигнал... AG>Вот тут и окажется — что MFC/WinAPI более приспособлен для этого, нежели VCL.
А в чем проблемы сделать подобное на VCL? Чего тут такого сложного?
Здравствуйте, AlexGin, Вы писали:
M>>Altium Designer написан на дельфях, кстати. Капитальный проект или формошлёпство?
AG>Мы разве рассматриваем от слова "вообще что есть на сегодня"? AG>Или в плане историческом: "20-25 лет назад", что было во времена популярности компании Борланд? AG>Вроде как все-таки второе.
Да
AG>В википедии насчет этого продукта: AG>Written in: Delphi, C#, C++
AG>То есть — всё таки там больше C#, нежели Delphi
С чего бы такой вывод?
Altium в своё время купила P-CAD. Чат гопота говорит:
САПР P-CAD был написан преимущественно на языке Turbo Pascal (Object Pascal).
Вот ключевые детали о его разработке:
Основной язык: Turbo Pascal (Borland Pascal / Object Pascal). Это был основной язык разработки для создания ядра системы, интерфейса пользователя и функциональных модулей P-CAD.
Операционная система: DOS (MS-DOS / PC-DOS). P-CAD был изначально разработан как 16-битное приложение для операционной системы DOS. Поздние версии (начиная примерно с P-CAD 2000) пытались работать под Windows, но часто представляли собой "оболочки" над DOS-ядром или имели гибридную архитектуру.
Среда разработки: Скорее всего, использовалась Borland Turbo Pascal (а позднее, возможно, Borland Pascal) и соответствующие инструменты для DOS.
Теперь вики:
Altium Designer — комплексная система автоматизированного проектирования (САПР) радиоэлектронных средств, разработанная австралийской компанией Altium. Ранее эта же фирма разрабатывала САПР P-CAD, который приобрёл необычайную популярность среди российских разработчиков электроники. В 2008 году фирма Altium заявила о прекращении поставки программных пакетов P-CAD, и предложила разработчикам использовать программу Altium Designer, которая появилась в 2000 году и изначально имела название Protel. В 2006 был проведён ребрендинг программного продукта и он получил текущее название, последняя версия которого называется Altium Designer 21.
С учетом того, что Протел вышел в 2000ом году (как раз на пике популярности Дельфи), что контора ранее купила и некоторое время развивала P-CAD, написанный на паскале, и того, что первый дот нет вышел в 2002ом году — есть все основания утверждать, что Altium Designer написан на дельфях.
Кстати, в Альтиуме можно писать скрипты, расширяющие функциональность, и, внезапно, они пишутся на паскале, что тоже намекает.
У нас в конторе была какая-то система ведения управления проектами, Союз-PLM, он на шарпе написан, с ним некоторые САПРы умели интегрироваться худо бедно — так, Альтиум умеет извлекать из него схемоту и либы компонентов, и вот на шарпе, я уверен, написана только эта интеграционная часть, а остальное с Паскаля никто не стал бы переписывать
Здравствуйте, Marty, Вы писали:
M> R>Какие тебе пруфы-то нужны? Открой, какой-нибудь TBX да посмотри
M> Если бы я помнил/знал, что такое TBX...
https://github.com/plashenkov/TBX
M> R>wxWidgets — изначально кроссплатформенный проект: M> R>Проект под названием wxWindows (w от Windows, x от X Window System)[5] был основан в 1992 году, когда Джулиан Смарт работал в Эдинбургском Университете над инструментом диаграммирования под названием «Hardy». Вместо того, чтобы выбирать между разработкой его для рабочей станции Sun или для платформы PC, Джулиан предпочёл применить кроссплатформенный фреймворк. Поскольку мощность существующих кроссплатформенных фреймворков была ограничена, а отделение не имело необходимого бюджета для написания такового, то он решил написать его самостоятельно.
M> Вначале wxWindows был нацелен на Xview и MFC 1.0. Пользователи Borland C++, жаловавшиеся на привязку к MFC, таким образом, стали переписывать программы на чистый Win32.
Не пойму, что ты хочешь этим сказать. Что пользователей билдера обделили вниманием?
M> Да нет проблем. Но только в wxWidgets сделали, значит и в VCL можно было. Могли wxWidgets взять за бекэнд
Зачем VCL нужен был какой-то бекэнд, когда задача ее переносимости вообще не стояла?
M> R>Только если ты готов был довольствоваться тем, что предоставляла VCL. Но чуть шаг в сторону и: сделать в листбоксе несколько столбцов можно было только через винапи.
M> По-моему, даже через WinAPI в ListBox'е нельзя было сделать несколько столбцов.
LBS_MULTICOLUMN, LB_SETCOLUMNWIDTH. Не помню в какой версии Delphi это стало поддерживаться из коробки.
M> Да и никогда не нужно было — были же многоколоночные ListView.
Все бы руководствоваться принципом "мне не нужно". В ListView каждый элемент это отдельный и довольно тяжелый объект, тогда, как в ListBox это просто строка. Это легче и ресурсов требует меньше. Кроме того, ListBox поддерживал виртуальные списки, а у ListView такой функциональности небыло.
M> R>Любая кастомная отрисовка сложнее паинтбокса — здравствуйте GetDC, BitBlt и т.д. Хочешь как-то по-особенному рулить ричедитом — посылаешь ему сообщения.
M> Только не было никаких сырых винапишных GetDC и BitBlt, а были VCL обёртки для них и были VCL-методы получения этих обёрток.
В том то и дело, что были вызовы API. Использовать обертки VCL было не всегда возможно и не всегда оправдано (кто думал о кроссплатформе-то, а?).
M> R>Короче, не рассказывай мне, как оно было на VCL, я его много кушал.
M> Я кушал не только VCL, но и много писал кроссплатформенные аппы, и сам делал совместимые обёртки. И я не на пустом месте говорю, что это не так сложно, я даже в одно лицо вполне справлялся.
Так никто и не говорит, что это сложно. Речь о том, что задачи такой небыло. А когд она появилась, было уже поздно проворачивать фарш назад.
Здравствуйте, Sinclair, Вы писали:
S> M>Интересно, многие ли сейчас вообще вспомнят о существовании такого продукта, а также о dBase и Ashton-tate?
S> Ну я их конечно же помню — но это оттого, что у меня с них карьера началась. dBase III (точнее, РЕБУС), потом Clipper, и далее со всеми остановками.
Коллега, мое почтение. dBase III, КАРАТ, FoxPro, Clipper
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, Ilya81, Вы писали:
M>>>Ну вот XAML — это и есть попытка шарпистов сделать так же удобно, как было в дельфях
I>>А в какй-то версии delphi удобнее? Ну я не смотрел соотвестующую версию, значит.
M>Да в любой 1-7. Ты, видимо, Дельфи только на картинках и видел
Как минимум в университете изучал, тогда творения Borland на CD'юках было найти проще многого осталного. Как минимум до 4-й версии, если не больше, не помню средств содания списков с заданным layout элементов.
I>>>>Не помню такого. Это в awt появилис хот скол-нибудь удобные средства отображения коллекций, к примеру. И в ранних версиях android sdk было что-то похожее.
M>>>Какого ты не помнишь?
I>>Что в delph было удобного для отображения списков, например. Может, в какой-то моент появилос.
M>В дельфи были, как минимум, все виндовые контролы, только использовались они не через винапи, а гораздо удобнее. Ну и куча сторонних. Если из виндовых — то обычный ListBox — чем тебе не список?
И что там с заданным layout элементов? Хотя б уровен AWT когда был достигнут?
I>>>>Property Editor полезен, только если позабл, как что-то называется.
M>>>А если не забыл, удобнее ручками текст править (не забывая о синтаксисе этого "текста"?) M>>>То-то сейчас все делают тоже самое
I>>Разумеется.
M>Что разумеется?
Вручную редактировать удобнее, чем бесчисленные действия мышью.
I>>Я, конечно, знавал любителей клепать диаграммы баз даннх в редакторах схем, где для создания одной таблиц порой требовалос гигантское количество дейстий мышью, мне этого не понять, мне несравнимо проще написать SQL.
M>Прикинь, диаграммы баз данных иногда рисуют, чтобы понимать структуру базы данных, даже если сами таблицы были созданы текстовым SQL. А иногда даже удобно нарисовать диаграмму, а по ней автоматом сгенерить код SQL, если инструмент такой есть в наличии — просто тупо по тому, что под каждую СУБД могут быть свои нюансы этого SQL, хотя, когда используешь только одну СУБД, то обычно все нюансы уже заучил.
Если разный SQL нужен, то нужно ещё и согласованность поддерживать, тогда проще средства какого-то ORM задействовать. А иначе проще SQL написать, диаграммы при необходимости сгенерировать из созданной базы данных.
I>>Так что не искючаю и любителей всяких Property Editor, и этого мне не понять. Разве что синтаксис очен сложнй, но, к примеру в iOS storyboards я часто ради формирования id только пользуюс встроенным редактором, а в омногих случаях предпочитаю xib/storybaord поправить вручную.
M>Я, было дело, кой чо делал для андроида, а там всё в XML описывается, и есть всякие визуальные типа Property Editor. Только вот они там ужасно убогие, и только поэтому я ручками писал XML, а иногда и генерил какими-нибудь скриптами. Только это не про Дельфи — там это было супер удобно.
Мне не понять этого удобства.
I>>>>Но MFC был сделан под GDI, когда графические процессоры были ещё экзотикой.
M>>>А причем тут GDI и графические процессоры?
I>>Ну для начала неизбежны разне принципы построения UI, графический процессор быстро выполняет composing, а на центральном процессоре часто быстрее отдельные линии перерисовавть, а заполнять прямоугольные области, не особенно пользуяс полупрозрачностью. Соотвественно, ориентированность на GDI для поддержания единого стандарта.
M>Так и причем тут GDI и графические процессоры? Это проблемы нижнего слоя — рендерера, как и что рисовать. К удобству построения UI это не имеет никакого отношения, если, конечно, криворукие архитекторы не протащили подобные зависимости по разным слоям архитектуры
Современные процессоры далеко не настолько быстрее, чтоб проблемы нижнего слоя можно было игнорировать.
Здравствуйте, Ilya81, Вы писали:
M>>Да в любой 1-7. Ты, видимо, Дельфи только на картинках и видел
I>Как минимум в университете изучал, тогда творения Borland на CD'юках было найти проще многого осталного.
Значит, очень хорошо забыл
I>Как минимум до 4-й версии, если не больше, не помню средств содания списков с заданным layout элементов.
TListBox
I>И что там с заданным layout элементов? Хотя б уровен AWT когда был достигнут?
Я понятия не имею, что такое AWT
M>>Что разумеется?
I>Вручную редактировать удобнее, чем бесчисленные действия мышью.
Смотря как сделано. В Дельфи было сделано хорошо, и мышью всё делалось в несколько кликов, вместо бесконечной писанины в каком-нибудь XAML
M>>Я, было дело, кой чо делал для андроида, а там всё в XML описывается, и есть всякие визуальные типа Property Editor. Только вот они там ужасно убогие, и только поэтому я ручками писал XML, а иногда и генерил какими-нибудь скриптами. Только это не про Дельфи — там это было супер удобно.
I>Мне не понять этого удобства.
Твоя проблема
M>>Так и причем тут GDI и графические процессоры? Это проблемы нижнего слоя — рендерера, как и что рисовать. К удобству построения UI это не имеет никакого отношения, если, конечно, криворукие архитекторы не протащили подобные зависимости по разным слоям архитектуры
I>Современные процессоры далеко не настолько быстрее, чтоб проблемы нижнего слоя можно было игнорировать.
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, Ilya81, Вы писали:
I>>Вручную редактировать удобнее, чем бесчисленные действия мышью.
M>Смотря как сделано. В Дельфи было сделано хорошо, и мышью всё делалось в несколько кликов, вместо бесконечной писанины в каком-нибудь XAML
Вы знаете, чем заканчивается использование всех этих визуальных редакторов ("дезигнеров")?
Вот, допустим, вы обновили Visual Studio, а это неизбежно, если вы долго работаете над одним проектом в команде. И у новой версии поменялся кодо-генератор по дизайнеру форм, что тоже обычное дело. Вот вам нужно добавить кнопку, просто одну кнопку на форму. И что у нас получается?
Вот вы добавляете мелкую такую кнопку, а у вас, бах, весь код новый кодо-генератор переделал, просто напрочь все перепахал.
Кто по-сообразительнее, те обычно этот мусор весь убирают, а в текстовом редакторе меняют ровно то, что относится к вашей новой кнопке. Или даже так, генерируют новый код через дизайнер форм, а потом из такого кода руками убирают весь этот новоявленный рефакторинг так, чтобы дизайнер мог вновь подхватить сделанные вручную изменения.
В той же Visual Studio для WinForms это довольно четко было видно. То есть, грамотный коммит состоял только в том, чтобы добавить одну кнопку, потому что никто не хотел связываться с тем, а что там новый кодо-генератор навытворял в коде. Обычно какая-нибудь сущая фигня в изменениях, там окончание другое или еще что, а вот весь автоматически генерируемый код нелепо перелопачен.
Ну, и кому это счастье надо? Зачем тогда нужен визуальный редактор форм, если он вставляет палки в колеса, если с ним приходится мучаться?
И я не говорю еще о том, что случайное касание мышью может также привести к куче бессмысленно перелопаченного кода, потому что опять же изменилась версия кодогенератора.
Поэтому при работе с визуальными дизайнерами форм функция "revert" — это самая основная.
Вот для быстрого прототипирования визуальные дизайнеры хороши. Это чтобы накидать, увидеть, а потом выбросить
Здравствуйте, dsorokin, Вы писали:
M>>Смотря как сделано. В Дельфи было сделано хорошо, и мышью всё делалось в несколько кликов, вместо бесконечной писанины в каком-нибудь XAML
D>Вы знаете, чем заканчивается использование всех этих визуальных редакторов ("дезигнеров")?
D>Вот, допустим, вы обновили Visual Studio, а это неизбежно, если вы долго работаете над одним проектом в команде. И у новой версии поменялся кодо-генератор по дизайнеру форм, что тоже обычное дело. Вот вам нужно добавить кнопку, просто одну кнопку на форму. И что у нас получается?
D>Вот вы добавляете мелкую такую кнопку, а у вас, бах, весь код новый кодо-генератор переделал, просто напрочь все перепахал.
D>Кто по-сообразительнее, те обычно этот мусор весь убирают, а в текстовом редакторе меняют ровно то, что относится к вашей новой кнопке. Или даже так, генерируют новый код через дизайнер форм, а потом из такого кода руками убирают весь этот новоявленный рефакторинг так, чтобы дизайнер мог вновь подхватить сделанные вручную изменения.
D>В той же Visual Studio для WinForms это довольно четко было видно. То есть, грамотный коммит состоял только в том, чтобы добавить одну кнопку, потому что никто не хотел связываться с тем, а что там новый кодо-генератор навытворял в коде. Обычно какая-нибудь сущая фигня в изменениях, там окончание другое или еще что, а вот весь автоматически генерируемый код нелепо перелопачен.
D>Ну, и кому это счастье надо? Зачем тогда нужен визуальный редактор форм, если он вставляет палки в колеса, если с ним приходится мучаться?
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, Ilya81, Вы писали:
M>>>Да в любой 1-7. Ты, видимо, Дельфи только на картинках и видел
I>>Как минимум в университете изучал, тогда творения Borland на CD'юках было найти проще многого осталного.
M>Значит, очень хорошо забыл
I>>Как минимум до 4-й версии, если не больше, не помню средств содания списков с заданным layout элементов.
M>TListBox
Может, и забыл, но не помню там средств задать произволный layout элементов.
I>>И что там с заданным layout элементов? Хотя б уровен AWT когда был достигнут?
M>Я понятия не имею, что такое AWT
Но как раз в AWT, помнится мне, я для такой возможности впервые видел стандартные средства, пусть и не самые удобные, но лучше, чем вручную клепать полностью. Что-то похожее было потом в ранних версиях Android в его стандартном SDK.
Здравствуйте, Ilya81, Вы писали:
M>>TListBox
I>Может, и забыл, но не помню там средств задать произволный layout элементов.
Что значит — произвольный?
I>>>И что там с заданным layout элементов? Хотя б уровен AWT когда был достигнут?
M>>Я понятия не имею, что такое AWT
I>Но как раз в AWT, помнится мне, я для такой возможности впервые видел стандартные средства, пусть и не самые удобные, но лучше, чем вручную клепать полностью. Что-то похожее было потом в ранних версиях Android в его стандартном SDK.
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, Ilya81, Вы писали:
I>>Но как раз в AWT, помнится мне, я для такой возможности впервые видел стандартные средства, пусть и не самые удобные, но лучше, чем вручную клепать полностью. Что-то похожее было потом в ранних версиях Android в его стандартном SDK.
M>Чем тебе TListBox не угодил?
M>Или тут
M>Чего тебе не хватает?
I>>Может, и забыл, но не помню там средств задать произволный layout элементов.
M>Что значит — произвольный?
То и значит — на каждй элмент списка не одну строку, а две, одна в середине сверху, другая справа внизу, разными шрифтами, а слева внизу картинка; или наоборот во всяком смысле; в т. ч. две картинки, одна в рамке, также три строки, какие-то с линией слева, и все прочие возможне сочетания. Там есть возможность это задать?
Здравствуйте, Ilya81, Вы писали:
I>То и значит — на каждй элмент списка не одну строку, а две, одна в середине сверху, другая справа внизу, разными шрифтами, а слева внизу картинка; или наоборот во всяком смысле; в т. ч. две картинки, одна в рамке, также три строки, какие-то с линией слева, и все прочие возможне сочетания. Там есть возможность это задать?
Конкретно за TListBox не скажу, протащены ли в него эти возможности, но в каких-то контролах точно было. Суть в том, отвечаешь на сообщение int OnMeassureItem(int idx) и возвращаешь высоту конкретной строки, это нужно, чтобы список мог просчитать полную высоту, а потом обрабатываешь сообщение void OnDrawItem(TCnavas *pCanvas, int idx), и рисуй там как твоей душе угодно. Всё очень просто.
Я конечно не точно из дельфей события описал, и на сишечке, это просто для иллюстрации принципа.
Возможно, эти события кидались не в контрол, а на форму, тогда там ещё указатель на контрол передавался
И так можно было практически любой контрол самому рисовать, внешний вид мог быть свой кастомный, а поведение полностью соответствовало стандартному.
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, Ilya81, Вы писали:
I>>Так Suse — это их творение, помнится мне. Не все дистрибутив linux одинаковые. Но потом, лет 10 назад, всё ж качество у них стало прадать.
M>Тебе неправильно помнится. Они купили SuSe после того, как всё просрали со своим NetWare, SuSe развивался самостоятельно до этого в течении почти 10ти лет
Есть в моём утерждении неточност, конечно. Но я даже не помню этого, поскольку на CD'юках ме этот NetWare в те времене не попадался, а когда появилас возможност скачивать из inet'а установочные образы, про NetWare особенно уже никто не вспоминал. С момента, как я впервые скачал Suse, ещё 20 лет не прошло, а до того из inet'а столько было не скачать.
Здравствуйте, Ilya81, Вы писали:
M>>Что значит — произвольный?
I>То и значит — на каждй элмент списка не одну строку, а две, одна в середине сверху, другая справа внизу, разными шрифтами, а слева внизу картинка; или наоборот во всяком смысле; в т. ч. две картинки, одна в рамке, также три строки, какие-то с линией слева, и все прочие возможне сочетания. Там есть возможность это задать?
Мы все еще про список говорим?
Многие и рады были бы испытать когнитивный диссонанс, но нечем.
Здравствуйте, Ilya81, Вы писали:
M>>Тебе неправильно помнится. Они купили SuSe после того, как всё просрали со своим NetWare, SuSe развивался самостоятельно до этого в течении почти 10ти лет
I>Есть в моём утерждении неточност, конечно. Но я даже не помню этого, поскольку на CD'юках ме этот NetWare в те времене не попадался, а когда появилас возможност скачивать из inet'а установочные образы, про NetWare особенно уже никто не вспоминал. С момента, как я впервые скачал Suse, ещё 20 лет не прошло, а до того из inet'а столько было не скачать.
NetWare была сетевой ОС, не ОС, умеющей взаимодействовать по сети как тот же Windows 3.11 For Workgroups, а серверной ОС, на которой строилась сетевая инфраструктура на предприятиях, и, соответственно, на сидюках для обычных пользователей её появление примерно так же вероятно, как появление какой-нибудь HP-UX. Ну и сидюки у нас массово распространились, когда NetWare была уже состоявшейся системой, и уже понемногу сдавала позиции, на сидюках были новые прорывные ОС, Win95/WinNT4, а те же линупсы, например, не особо часто на сидюках встречались.
Здравствуйте, paucity, Вы писали:
P>Здравствуйте, Ilya81, Вы писали:
M>>>Что значит — произвольный?
I>>То и значит — на каждй элмент списка не одну строку, а две, одна в середине сверху, другая справа внизу, разными шрифтами, а слева внизу картинка; или наоборот во всяком смысле; в т. ч. две картинки, одна в рамке, также три строки, какие-то с линией слева, и все прочие возможне сочетания. Там есть возможность это задать?
P>Мы все еще про список говорим?
А что, ни разу не случалос такой видеть? Хотя б в мобильнх приложениях для online-покупок карточки товаров в списке? Или desktop должен отставать?
Turbo Pascal закончился в начале 1994. Баг с пентиумной плавучкой (Pentium FDIV) вылез в конце 1994 (в Delphi для него предусмотрен воркараунд). Второй пень вообще через три года вышел.
