Комментарии 186
Только один вопрос: а зачем становиться Delphi-программистом?
если ты не знаешь для чего нужен паскаль, соответственно тебе не нужна информация о паскале, а соответственно нет смысла писать этот комментарий (это называется последовательная логика, ваще читарская штука)
у меня есть развернутый ответ на твой вопрос, но вместо него я решил ответить так, потому что этот комментарий в духе "когда не знаешь до чего долюбиться, но долюбиться надо" -_-
Так зачем программистом то становиться дельфячим?
Курсовую работу сделать и забыть про объектный паскаль навсегда.
Я в основном пишу для микроконтроллеров. Но как всегда, кому-то нужно писать и программы для настройки устройства с ПК или пример взаимодействия с другим целевым устройством. И оказалось, что "набросать окошко с кнопками" проще всего в Лазарусе. Причем легко пересобирается как под win x86, так и под linux aarch64 или armf.
И лицензионная чистота соблюдается. Легче было бы писать на си, т.к. уже описаны структуры или прочее в реализации со стороны устройства, но найти gui-фреймворк c такой же интеграцией в IDE и простотой использования - я не смог. QT монстр со сложными лицензиями и его может не оказаться на целевом девайсе. Python - тоже не везде есть и не сравниться с нативным приложением. По итогу Lazarus со своим паскалем оказался более подходящим для этой ниши.
wxWidgets внезапно. В связке с gcc работает и в винде и в линуксе. В качестве IDE - CodeBlocks или CodeLite. Ну плюсом какой-нибудь wxFormBuilder, wxSmith, wxCrafter...
Да, но лазарус оказался реально более проще в использовании. Как появилось приложение fpcupdeluxe, то вся кросс-компиляция добавляется в пару кликов.
Вполне возможно. Я не пробовал.
Честно сказать, я под виндой до 17-го года работал - там на каким-то этапе был MSVC + MFC, потом ушли на Builder.
А с 17-го года вообще на AS/400 (IBM i) перешел, а тут все вообще другое и проблемы совсем другие и принципы работы системы другие.
Qt пробовал - во-первых монстр, во-вторых, они построены на несколько иных, нежели винда, принципах. И поверх WinAPI это все ложится несколько странновато.
wxWidgets попроще и попонятнее, но вот с версткой интерфейсов там придется вникать в концепцию сайзеров (некий контейнер для интерфейсных объектов), что может не сразу зайти если долго на WinAPI работал.
А Паскаль как-то сразу (еще в 90-х) мимо меня прошел. Т.е. читать код "со словарем" могу, но писать на нем никогда не приходилось. Ну просто не было такой необходимости, а без необходимости и стимула учить его не было.
С# - окошки в visual studio набросать проще простого. C# - Си подобный язык. Опять же опыт в мэйн-стримовском языке. Лицензионная чистота??? Lazarus - фри, в том числе для коммерческого использования??? Так зачем делфи?
Даже не знаю как добавить поддержку С# на образах собранных старым buildroot. Или сейчас можно собрать C#-приложение статически под gtk? У лазаруса лицензия GPL/LGPL с разрешением сборки коммерческих приложений. C делфи не работаю, но видимо их кроссплатформенная FireMonkey тоже имеет своих приверженцев. Т.ч. кто-то на Go перепрыгнул (кстати сырой по поддержке GTK показался год назад),а кто-то и на паскале сидит. Не вижу причин их винить в этом. :)
Затем, что Делфи на порядок быстрее развивается, особенно в последние годы. Затем, что среда разработки, RTL и фреймворки на Делфи гораздо функциональнее и да.т намного больше возможностей. В том же числе и кроссплатформенная разработка. Моим клиентом для ChatGPT (под все платформы сразу) пользуются достаточно много людей, хотя я просто опубликовал его на GitHub.
Я спросил, не для чего писать на Delphi, а для чего становиться Delphi-программистом человеку, не знающему программирование. Так и вижу его мысли - 1. Выучить Delphi за 2 часа; 2. Пойти программировать микроконтроллеры, благо позиций навалом, особенно для самых зеленых джуиоров; 3. Получать биг профит!
Ага ага.
А почему учат brainfuck? Потому что могут. Так и паскаль учат потому, что его преподают там где учатся или есть знакомый который его знает. Не вижу причин критиковать язык как первый для обучения, для чего он и создавался.
Статья называется не "как понять основы программирования через Delphi" , а "как стать Delphi-программистом". Это две большие разницы. Но даже и для обучения гораздо лучше Питон - знание его можно потом просто углублять и уже становиться нужным на рынке труда.
Так тем более - если б статья называлась "как стать актуальным, в понятном для всех смысле, программистом" то я бы понял ваши претензии. А так человек как назвал - так и написал. Схожу поищу в инете статью "как стать музыкантом на лютне" и там тоже спрошу "а зачем?"
А какой лучше для изучения - то это вкусовщина. Я вот считаю, что для изучения нужны языки со строгой типизацией и без приколов, когда невозможно визуально увидеть ошибку из-за замены пробела табом.
Из-за последнего, даже js лучше питона в плане первого языка, несмотря на свои приколы с типизацией. Питон же чудо как хорош как универсальная замена bash-скриптам\batch-файлам, но как первый язык - брррр, ужас
даже js лучше питона в плане первого языка
в чемже js лучше то? в питоне хоть ооп есть похожий на настоящий
или скобочки важнее?
p.s. а чтобы не упарыватся пробелами с табом, надо просто нормальную ide юзать, а не в блокноте писать
Я же говорю - вкусовщина. Я не готов развивать этот холивар, извините
в питоне хоть ооп есть
И это минус питона, а не плюс.
минус в том что ооп есть? почему это минус? (чувствую вы с голангом сравниваете)
Оно там не к месту. Питон хорош для скриптования небольших, детерминированных последовательностей операций с не очень сложной логикой. Для написания масштабных ООП проектов он неудобен. И главное зачем? Ну лично я убежден, что ООП не помогает, а наоборот мешает разрабатывать сложные приложения, но это вопрос дискуссионный. Но если уж так хочется ООП, то есть же джава, например, она для этих целей подходит гораздо лучше во всех смыслах - и надёжнее и быстрее и кросплатформеннее. Так зачем из хорошего скриптового языка пытаться изображать плохую версию джавы?
теория теорией, но мы имеем факт что на питоне пишут большие и огромные проекты
мне сначала как у бывшего джависта подгорало...но потом я както познал дзен...;) наблюдая очередной раз скачок как "типы нинужны, ооп нинужно, написал и сразу впрод, ничево не компилится, ttm ttm ttm!!" -->> "впиливаем контроль типов, впиливаем валидацию входящих данных, давайте делать абстракции, начинаем делить монолит потомучто уже пи..ц"
на питоне пишут проекты потому что их легко начинать, а не как на джаве, два месяца пишем обвязку, потом бизнес логику через полтора года релиз....
а на питоне за месяц наваял на коленке мвп ..и вам уже бабки капают... а через два года получается переходы как я выше описал
а наличие ооп в языке позволяет это делать проще без смены стека
на питоне пишут проекты потому что их легко начинать
Да, я уверен, что именно поэтому. Как человек, перепробовавший кучу языков и парадигм, подтверждаю, что начать на питоне легче всего. Другое дело, что на питоне тяжелее закончить, или даже довести код до состояния MVP, когда можно получить с него от какую то отдачу, но начать действительно легко. Тяжелее по времени, трудозатратам, а значит и деньгам. Но человеческая психология работает так, что заказчику легче выделить деньги на тот проект, который легче начать, чем на тот, который легче осуществить.
Да именно как раз это и было решением нашей компании, когда нам понадобился бэк для некоторых проектов. Решили взять питон, т.к. наши разработчики были заняты, а казалось проще найти питон-разработчиков.
Итого:
Найти квалифицированного Питониста оказалось очень сложно. Он может и знает сколько-то Питон, но запросы SQL для него - уже сложно.
Бэк в итоге действительно достаточно быстро подняли. И он частично заработал. Но как только дело дошло до реальных данных (где бд уже по нескольку тысяч записей), то получили массу проблем с производительностью, что повлекло за собой создание кучи кеширований. Но даже с ним производительность не устраивала.
Кеширование создало ещё ряд проблем с тем, что бд не статичная и в итоге кто-то получает актуальную информацию, а кто-то - нет.
Все это переросло в итоге на год затраченного времени и по факту не рабочий бэк.
За две недели я переписал весь бэк на компилируемый другой язык - на Делфи, кстати, который прекрасно справляется с нагрузкой, динамической бд (потому что без кеша) и ростом БД.
И вот вопрос. А действительно ли на Питоне быстро начать проект? Как прототип - да, на тестовых данных - супер, но как конечный продукт - нет.
Найти квалифицированного Питониста оказалось очень сложно. Он может и
знает сколько-то Питон, но запросы SQL для него - уже сложно.
так вы миддла-джуна взяли в итоге?
ктож с нуля проекты силами миддла начинает, потому что все что вы описываете мне очень знакомо, это какраз то что делают миддлы
Но как только дело дошло до реальных данных (где бд уже по нескольку
тысяч записей), то получили массу проблем с производительностью, что
повлекло за собой создание кучи кеширований. Но даже с ним
производительность не устраивала.
правильно, потому что что делают миддлы, берут туториал по фреймворку и слово в слово делают, про SQL вы уже верно упомянули...но это "прошлый век же, есть ORM" пилим по туториалами - получаем адовое тормозилище, почему? а потому что ORM генерит такой пи...ц что я чуть тут словами на хабре матом не написал...но миддл не достаточно квалифицирован чтобы понять, а в мануале это не написано
За две недели я переписал весь бэк на компилируемый другой язык - на
Делфи, кстати, который прекрасно справляется с нагрузкой, динамической
бд (потому что без кеша) и ростом БД.
повторюсь потому что вы сеньор на делфи, а на питоне вам писал от силы миддл
дело не в языке
Тоже самое можно сделать на голанге который все боготворят вокруг
мой коллега помню прям от счастья плакал...говорит во как хорошо, на яве пишешь всякое new Thread и следить за потоками геморрой... а тут пишешь go перед вызовом и прям моногопоточность во все щели!!! го круче!!! ничего лишнего всё само
Я прям под стол упал, а какже утечки горутин? как же синхронизация? квадратные глаза и "это всё само под капотом както делается, магия, 21 век, не то что ваша ява и сишарп!!!"
вот такой человек запилит вам с нуля сервис на голанге который круче питона и явы...а потом он начнет память на сервере жрать и потоки как не в себя.. и будем чё опять на делфи переписывать?
Я вот считаю, что для изучения нужны языки со строгой типизацией и без приколов
Я бы добавил еще "без UB"
я не пишу комменты потому что меня заминусят, а я хочу докончить хотя бы планируемые статьи, но на вопрос ветки надо ответить
если отвечать на слова, и если ты не хочешь знать паскаль, значит тебе и базы данных ненужны (они все тоже алголаобразные, да и к тому же паскальные загоны ассемблера унаследовали, процедуры, вложенные в заголовки функции, даже циклы репиат унтил, а раз тебе ненужны базы данных значит и работать ты можешь только фронтендером)
если ты приходишь в программирование и задаешь вот такие вопросы, значит тебе не надо быть программистом, настоящее программирование это искусство, искусство неразрывно связано с мастерством, а настоящий мастер - это вечный ученик, ты не станешь программистом зная только питон, или только веб, или только с++, для того чтобы стать настоящзим программистом надо получить полноту понимания, и только после этого (при достаточном упорстве и изобретательности ты получишь шанс стать настоящим программистом)
преимущества "программиста" как потенциала человеческой синергии куда больше чем многие себе представляют и понимают, а если тебе нужны только деньги, иди в манагеры или банкиры
для меня большая проблема это мобильная (могильная) разработка, и ассемблер, я отпихиваюсь си шарпом и веб вайв (а ассемблер просто тяжело, не хочу думать), но мне рано или поздно все равно придется овладеть обоими
Затем же, зачем становиться шарпистом или плюсовиком - разработка ПО.
Я знаю, для чего был создан Паскаль
Не нужен сейчас, а именно был создан. И я писал на нем и на Delphi, когда ты еще под стол пешком ходил, в лучшем случае. Но все это совершенно не отменяет моего вопроса, который чёткий и ясный. И главное, актуальный.
Потому, что человек так захотел.
Видимо ваш вопрос не понимают, если его приходится три раза повторить. Нет смысла ничего не меня его повторять. Перефразируйте, может будет полегче.
Да вот пока не видно ни одного человека, который, прочитав эту статью, захотел бы с нуля стать Delphi-программистом 😎
Скорее всего нулевые программисты тут не ходят, про какой бы язык не шла речь.
И уж точно врядли имеют возможность и причину тут об этом заявлять. Вы ждали под этой статьей комментария: "спасибо, теперь я знаю кем стану"?
Язык не завис в 2005 и развивается постоянно. Так что он не менее актуален, чем C# или C++. Гуглим, удивляемся.
Гугльнул, удивился.
https://www.tadviser.ru/index.php/Статья:Рейтинг_востребованности_языков_программирования
- не вошёл в десятку самых востребованных и вообще никуда не вошёл.
https://habr.com/ru/articles/651585/
- не вошёл в двадцатку.
У меня есть коммерческий опыт разработки на Паскале и Дельфи (Дельфи прекрасен, на тот момент и ещё долго после afaik ничего сопоставимого уровня для создания GUI просто не было... MFC – боль), но я задаюсь тем же вопросом.
К сожалению, это по сути мёртвый язык/среда, возможностей применения (кроме как чисто для себя) практически нет :-(.
ЗЫ: Также цепанула фраза в начале статьи – мол, Objective Pascal ничем не отличается от C++. Это верно, лишь если ограничиваться "C с классами".
ЗЫ2: На всякий случай плюсанул в карму, даже если не согласен насчёт полезности и т.п. – сама тема достаточно интересна для обсуждения, а знание практик Паскаля/Дельфи даст выигрыш и при последующем программировании на других языках.
возможностей применения (кроме как чисто для себя) практически нет
Чем он не подходит для решения "современных" проблем? Этот язык мертвый именно для вас, ведь вы не интересуетесь его развитием, а оно далеко не нулевое.
В основном малым количеством вакансий.
Это как-то не вяжется с "возможностей применения ... практически нет"
Вяжется. Увы, это некая воронка угасания языка: нет вакансий – люди не учат язык – нет специалистов – на новых проектах выбирают другой язык, чтобы было легче найти специалистов – нет вакансий...
Паскаль – прекрасный язык, Дельфи – замечательная среда, но, увы, некогда они проиграли C++.
Для прикладных целей: писать утилитки для себя и для работы delphi\freepascal вполне удобны.
Делфи не проигрывал плюсам, Делфи проиграл Шарпу, потому что МС не мало палок в колеса понаставила. Перекупила себе родоначальника Делфи, который сейчас и занимается Шарпом (он же и TypeScript создал). Перетащила в Шарп почти все фишки Делфи и идеи среды разработки.
Однако у Делфи до сих пор есть не мало преимуществ перед Шарпом.
Независимость исполнительного файла
Скорость сборки проекта и развертывания
Производительность
Удобство создания GUI и возможности GUI (даже не смотря на WPF)
Простота создания собственных контролов и интеграция в среду
Открытость кода, не смотря на проприетарность языка
Я, видимо, постарше вас и успел увидеть именно как Дельфи проиграл плюсам). Это уже потом у плюсов часть поляны отжали новые языки. А потом появились ещё более новые, впитавшие в себя то, что было в паскале, но чего не хватало в плюсах – к примеру, в котлине и свифте есть нормальный switch (даже лучше паскалевского).
ЗЫ: и я прекрасно знаю преимущества Дельфи. Я ж говорю – имею опыт работы на нём, не для себя – для заказчика. Было очень удобно.
Все что вы описываете. это по нынешним временам уже довольно узкая сфера разработки десктопных приложений
независимость файла? - это уже лет 10 как никого не волнует
скорость сборки? - это крайне несущественный показатель выбора инструмента (ну разве что он не трое суток собирается)
производительность? - возможно соглашусь, мне не с чем сравнить
собственные контролы и интеграция - опятьже это применимо сугубо в нише десктопной разработки
открытость кода? всмысле исходник компилятора доступен?
пока это выглядит как "нужно быстрое приложение на десктоп но в си у нас никто не умеет, а C# как и Java тормозят насколько мы слышали"
Речь не только о десктоп разработке. Делфи давно не только Десктоп и тем более, не только под Винду.
Клиент ChatGPT
На скрине не хватает только МакОС и иОС сборки, но она тут имеется
Собственные контролы - это про любую платформу. Суть здесь в том, что создавать собственные наборы контролов и компонент в Делфи проще, чем где-либо (потом можно опубликовать в штатный менеджер пакетов). И всё это будет доступно визуально другим разработчикам, которые не будут тратить время вообще ни на что, просто кинув компонент на форму и настроив его.
Например, тот же ChatGPT. Я создал невизуальный компонент, который достаточно кинуть на форму, вписать токен и название модели. А дальше в событии выбрать куда выводить текст (или сложное содержимое), функции и по кнопке вызвать метод с промптом. Т.е. на полноценный чат уйдет не больше 5 минут (с учетом открытия среды).
Hidden text
Просто ради моей собственной эрудиции, а возможно и будущего мастхава - есть Delphi под Linux и ARM? Т.е. есть уже дельфовая альтернатива Qt? Или?
Делфи давно не только Десктоп и тем более, не только под Винду.
а я про Винду ни слова и не сказал
сейчас всё gui смещается в веб, из-за чего такие извраты как электрон стали нормой... и я теперь понимаю почему, не надо держать отдельного программиста для gui для каждой платформы, берешь фронтовика и он тебе интерфейс и на андройде и на десктопе и в вебе делает, потому что код и принципы одинаковые
достаточно кинуть на форму,
на какую форму? вы опять про десктоп приложения?
или предложите писать веб сервисы на делфи с серверным рендерингом в 23 году?
На работе - да. Дома Delphi 11 CE
Скорость сборки важна. xkcd#303.
А вот ваш последний абзац – это аккурат то, что сейчас больше всего играет против дельфи. Ну нет смысла затевать новый проект на языке, для которого на рынке в 10 раз меньше программистов.
я был программистом делфи + MSSQL.
а потом встретил c# :)
даже не знаю, где используют делфи, разве только для поддержки старых проектов
А, кстати, несколько лет назад мне по работе потребовалось наваять несложное приложение для планшета на Андроиде. Я вроде всё по учебнику делал, но процесс с Андроид студей был весьма тернист, что-то там компилялось с ошибкой, в общем я и так и сяк, убил на это дело пару дней и уже был готов взять MIT App Inventor, но наткнулся на Embarcadero, а поскольку я довольно много программировал на Дельфи четверть века назад, то приложение на удивление легко набросалось буквально за вечер и всё заработало сразу и без проблем. Там "планка вхождения" реально ниже. Надо будет Delphi 12 Athens на досуге глянуть.
Да что ж такое. Я не спрашивал, для чего Delphi может пригодиться программисту по жизни. Может и ассемблер пригодиться, и даже какой-нибудь PL/1 - ну мало чего новый проект потребует. Я спросил совершенно другое.
Если вы про востребованность на рынке, то она есть, небольшая конечно, но есть. По немецкому рынку вакансий - зайдите скажем на monster.de, вбейте там Delphi и вы их увидите. У нас до сих пор старые проекты живы. Ну и как язык для обучения вполне норм. Опять же обычно единственным языком сейчас не ограничиваются, как второй-третий язык почему бы и нет. Кокуренция к тому же невелика.
Только один вопрос: а зачем становиться Delphi-программистом?
Там конкуренция меньше чем у других ЯП , и зп высокие даже у джуна на фоне других языков
Можно сюда или в личку кинуть хотя бы пять открытых позиций по Delphi с высокими зарплатами?
Хх ру вам на помощь, у джуна на старте зп в среднем 100к, где вы видели такое на других ЯП, не считая c++ с минимум конкуренции?
а реально сеньором потом стать с 350к+? и работу через 10 лет найти?
Какова вероятность, что вы на других языках будете 350 получать без знания английского , в России не так уж и много таких вакансий скажу вам, если смотреть язык python , другими не интересуюсь, т.к разрабатываю на питоне???
Работа будет также и через 10 лет, т.к легаси системы у крупных корпоратов никуда не денутся а разгребать это кому-то надо...
Какова вероятность, что вы на других языках будете 350 получать без знания английского
ну не маленькая вероятность, я больше получаю, английский у меня правда B1 но он на нынешней работе мне не нужен
Ну вы скорее исключение из правила, т.к большинство получают до 200 т.р в среднем, исходя из вакансий на хх.ру и даже 200 уже выше среднего как по мне..
А тут без конкуренции, человек с ходу получать будет 100+, к тому же потом ему ничего не мешает изучить другие направления и поднять свое зп ещё выше
Уверен раз у вас оплата 350+, то и знаете вы не один ЯП, что также не мешает другим быть также
я не думаю что я прям исключение из сеньоров, разве что меня в менеджмент тянет, все мои коллеги с кем я работал (сеньорских грейдов) получают 300+ которые из РФ не уехали
Это еще при том что я например не смогу пройти собес в яндекс или в гугл
по вакансиям на хх такое себе оценивать рынок зарплат потому что там большинство вакансий с высокими грейдами без вилок
Но и моя логика тоже имеет обоснование, синьоров не так уж и много, по сравнению с джунами и мидлами, тут просто момент такой, что не каждый хочет быть синьором, но вот что точно, так это каждый хочет зарабатывать с ходу хорошо, и людям семейным с детьми , устраиваться на позицию джуна с зп менее 100к не каждый решиться в том числе конкуренцию побороть не каждый осилит, поэтому изучить делфи и найти работу, думаю будет проще и выгоднее на старте, а уже потом можно и другие варианты искать по увеличению зарплатной вилки , изучив другие ЯП уже получая относительно больше других
К примеру, богатая палитре Com объектов (компонентов, или готовых шаблонов для кнопок, полей ввода текста, картинок, и тд, кароч не надо изобретать велосипеды).
Полный бред. К Паскалю это не имеет никакого отношения. Это библиотека VCL, основанная на стандартных Windows Common Controls (ComCtl).
И, кстати, COM объекты это совсем про другое.
И та же самая библиотека может использоваться в Borland C++ Builder. Который фактически тот же Delphi, но не на Паскале, а на С++
При этом для C++ есть и другие фреймворки - Qt, wxWidgets, MFC тот же... Которые точно также все это реализуют.
Короче, очередной бред "мамкиного погромиста".
Моё мнение - если и писать под vcl (ну вдруг так получилось), то уж лучше на c++ чем на pascal.
Знание c++ хоть где-то потом может пригодиться (хоть оно в билдере и со своими приколами), а знание паскаля, это.. ну примерно - как 1С (в смысле - очень узкая ниша).
Хотя, наверное, паскаль лучше приспособлен для обучения. Я тоже когда-то с него начинал.
На билдере в своей время немало писал. Из ну вот совсем специфического - разве что property (на мой взгляд весьма удобная штука) и реальная поддержка борландовским компилятором типа long double (80 бит, для остальных компиляторов long double == double).
Но с современными версиями стандартов там совсем никак. Даже не знаю - живо оно еще или нет.
Так что сейчас если и писать, то использовать кроссплатформенные gcc + Qt (правда, там с лицензией какие-то непонятки были вроде бы) или wxWidgets (OpenSource).
Короче, очередной бред "мамкиного погромиста".
Да автор своим циклом статей откровенно стебется :) Как бы ему только до бана случайно не достебаться :))
С нетерпением жду статью про C#, т.к. я спец именно в нем.
При этом для C++ есть и другие фреймворки - Qt, wxWidgets, MFC тот же... Которые точно также все это реализуют.
Не совсем - в отличии от VCL они требуют приложения своих библиотек к исполняемому файлу.
Ну, строго говоря (по крайней мере для билдера) VCL можно было как статиком линковать, так и динамиком (с дополнительынми DLL).
С Qt не приходилось работать много, а wxWidgets точно также можно собирать как статическими библиотеками, так и динамическими и линковать соответственно.
Так что тут нет каких-то радикальных отличий.
Тонко, очень тонко)
Особенности концепции языка предполагают создание новых переменных только в заголовках
Поскольку речь всё-таки о Delphi, то это уже не так: Inline Variable Declaration
Любите шарпы, но пишете на пасквиле?
Писаки на си называются насильниками если что
А язык не Delphi называется? Объектным Паскалем он был до Delphi 6.
Еще у паскаля есть одна уникальная причуда, это процедуры (на ровне с функциями), так как это высокоуровневый язык программирования (спроектированный под концепцию ооп) работа предполагается со сложно составными объектами (с классами), и, специально для свойств внутри этих классов (для переменных внутри класса, класс — это пользовательский тип данных) были созданы процедуры (для изменения содержимого, которое ассоциировано со свойством).
Извините, но что это за бред про процедуры?
Почитал статью как в начало нулевых вернулся ;))
А COM разве не считается устаревшим стандартом?
PascalABC - когда нужно что-либо быстро запрограммировать. Можно использовать в качестве калькулятора.
В качестве калькулятора удобно использовать адресную строку Chrome.
А если без интернета?
Хм, проверил – без интернета не считает (это показывает, как часто я бываю без интернета). Чаще я бываю без десктопа.
Ну, тогда любой привычный язык с REPL. Сейчас для меня это, скорей всего, будет javascript. Как вы понимаете, опять же в браузере, только уже в девелоперской консоли).
Консоль инструментов разработчика Хрома (та, что открывается по F12)
Интересно, кто в Вашем понимании "начинающий программист" (НП)? Вот у меня, например, по-прежнему вызывают временный паралич умственной деятельности некоторые словосочетания типа "парадигма программирования". Вы с самого начала закидываете непонятными терминами типа "биос", "драйвер", "пиксель". Это для "самых маленьких"?
Потом сразу запускаете Lazarus. Где его взять, как, чего и т.д.? В первом листинге присутствуют, в частности, кнопка и поле ввода, но перед этим ни слова, что сначала надо их добавить на форму. Листинг огромен! Да, большая часть - это комментарии, но НП может об этом не подозревать. Пытаюсь представить себя в роли этого НП: я бы, наверное, пал духом при виде такого.
Мне в роли НП (да даже не обязательно в программировании, просто в роли новичка) хотелось бы сразу увидеть некий положительный результат: Ух, ты! Работает! Классно! Применительно к программированию - тот самый "привет, мир!"; "меня зовут {имя}, мне {n} лет"; уравнения простенькие, может быть. Если б я был "самым маленьким", то не уверен, что с помощью этой статьи за час смог бы хоть небольшого успеха достичь.
И ещё. Если Вы стремитесь своими статьями пробудить интерес к программированию у новичков, то, думаю, не стоит использовать в примерах слова типа "быдлокодер". Как-то не очень воодушевляет.
Аж ностальгию словил, мой первый язык =)
Чего автору не занимать, так это упорства в продвижении бреда! Секты примерно так и самоогранизуются, удачи вам и всех благ!
Как стать Delphi-программистом за час «для самых маленьких»
Автор вы юзаете Lazarus?
Ведь Lazarus верно?
Час? Как-то долговато.
То, что мертво, должно оставаться среди мертвых, ему ничего делать в мире живых.
Последняя версия Delphi (и спецификации языка и версия среды) вышли в прошлом месяце. Предыдущая версия вышла пол года назад. Продукт, который стоит не малых денег с регулярным обновлением и поддержкой - глупо называть "мертвым".
Пока существуют легаси продукты авторы делфи будут доить этот рынок, выпуская новые версии среды программирования мышкой, в этом и не приходится сомневаться. Но если одно только наличие работающих легаси систем является доказательством "не мертвости", то тогда и кобол живее всех живых.
По-моему я сказал, что язык развивают, а не что на него есть рабочие места. Именно наличие развития говорит о том, что язык НЕ мертв. Или вы этот текст просто пропускаете?
Софт пишется на Делфи в том числе и даже больше новый. С нуля. А не только участвуют в поддержании легаси. Я сейчас занимаюсь исключительно новыми разработками. В разных местах. И люди, с которыми общаюсь, пишут в основном новый софт, а не допиливают старый. А с учетом того, что я больше осведомлен о разработках на Делфи, то мой аргумент весомее, нежели ваши сомнения.
Давайте мы будем ориентироваться не на ваш субъективный информационный пузырь ("я делфи разработчик и в моей компании, где все пишут на делфи, новые проекты мы тоже делаем на делфи"), а на объективную информацию. Вот, например, статистика по доли языка в открытых вакансиях по миру: лидер JavaScript с 53%, C# имеет 28%, C++ 23%, а делфи занимает аж 1% рынка, проигрывая F# и едва обходя хаскелл. Да, живее всех живых, что уж тут скажешь.
я делфи разработчик и в моей компании, где все пишут на делфи, новые проекты мы тоже делаем на делфи
Это вы для себя сами придумали, дабы было удобно ответить.
Я создаю проекты не только в своей компании, где работаю, но и участвую в разработке сторонних проектов совершенно сторонних людей. Я общаюсь с разными людьми, и не только в РУ сегменте.
А ваша статистика не основана ни на чем и будет справедлива только для тех языков, проекты на которых доступны всем (или ими пользуются в публичном доступе и/или они в опенсорсе).
На Делфи как правило создаю коммерческие продукты, которые нацелены на конкретных пользователей, а не ширпотреб, очень много софта создано для внутреннего использования.
Помимо всего этого, несмотря на то, что я специально заметил, что речь НЕ О РАБОЧИХ МЕСТАХ, вы снова приводите статистику рабочих мест. Т.е. вы вообще не читаете то, что вам пишут?
Его используют в банках (А Сбер недавно выпустил публичный софт на Делфи для пользователей)
Скрин
Altium Designer - софт для электронщиков по работе с платами
FL Studio - софт для создания музыки
Ceramic3D - софт для дизайна интерьера и рендера
Toad for Oracle - менеджер СУБД для Oracle
Game Maker Studio - софт для создания игр
HeidiSQL - менеджер СУБД для MySQL и иже с ним
Everest - софт для сбора и мониторинга информации о ПК
Почти весь софт Auslogics
Inno Setup - мастер создания установщиков
Я могу так долго продолжать
Я могу так долго продолжать
вы пишите в каком году софт то этот был написан
Toad писался в 98 году, и не Ораклом
FL Studio - 97 год
HeidiSQL - 06 год
Game Maker Studio
на делфи только первые версии были, сейчас уже шарп
еще пара примеров - какието нишевые софтины судя по всему написанные одним-двумя человеками
Его используют в банках (А Сбер недавно выпустил публичный софт на Делфи для пользователей)
Его не используют специально. это зачастую сторонний софт который случайно туда попал по историческим причинам
Есть например довольно известный внутри процессинговой отрасли софт, для управления банкоматами, написанный на делфи в начале нулевых
довольно корявое поделие сделанное на коленке двумя программистами, один из которых на тот момент когда я с ним сталкивался был уже в пенсионном возрасте
есть некая вероятность что сбер купил эту контору вместе с софтом
Софт Сбер на скрине - это софт на современном фреймворке (FMX) и современном компиляторе, который не совместим с тем, что был с самого начала (VCL). Это софт, которого раньше не было. Максимальный возраст проекта может быть где-то лет 5. Но я сильно в этом сомневаюсь, потому что тогда FMX ещё не был так стабилен, чтоб на нём писать публичный софт
Так сложилось, что свой продукт мы начали писать в 1996. Сейчас имеем 3млн строк на Delphi. Продукт из категории САПР отлично продается за рубежом и входит в топ 20 среди аналогичного софта. В 2022 все наши конкуренты дружно встали и ушли из России, после чего мы стали здесь практически монополистами. Госкомпании дружно заливают нас деньгами и требуют перехода на Linux. Поэтому стек Microsoft, включая C#, который "всего" в 2 раза медленнее нативного Delphi не подходит. Миграция на "плюсы" потребует кучи времени и не приведет к росту функциональности системы. Какая у нас альтернатива Delphi? Требуются программисты на Delphi, з/п выше средней по отрасли. Специфика продукта: расчеты, графика, геометрия, практически не используем базы данных.
3 млн за четверть века -- это даже мало :) Либо у вас очень эффективная кодовая база с погашенными техдолгами.
А что за САПР,если не секрет?
включая C#, который "всего" в 2 раза медленнее нативного Delphi
Навскидку на этом:
https://github.com/Mark-Kovalyov/CardRaytracerBenchmark
получаю С# x64 - 9.4, Delphi x64 - 16.8 секунды (однопоток, консольный вывод в Дельфи отключен). Меньше - лучше, то есть С# быстрее почти в 2 раза.
Почему? Ну, JIT C# основан вероятно на C++, а кодогенерация в плюсовых компиляторах со временем улучшается. У Дельфи она застряла на уровне 2000-х по причине неустроенности (перепродажи) и нехватки ресурсов на разработку.
Я понимаю, почему вы держитесь за написанные и отлаженные млн. строк, просто слегка просвещаю насчёт современного соотношения сил.
Думаю, у них всё упирается в затраты на выделение/освобождение памяти (когда платишь за удобство GC быстродействием), кодогенератор-то понятно, какой лучший код выдаст.
Ничто не мешает писать на C# код минимизирующий использование GC - value-type, Span, ArrayPool/ObjectPool, ref, поинтеры и т.д. Скорее у них все упирается в то, что называют "Skill Issue"
Можно, но это изрядно убьёт удобство C# и для получения легко поддерживаемого кода потребует довольно высоких навыков.
На любом языке программирования, хоть Делфи, хоть C# хоть JS или Python нужные профессиональные навыки чтобы писать хороший и поддерживаемый код. Я не знаю такого языка программирования, который можно дать команде безграммотных "индусов" и они напишут идеально поддерживаемое приложение просто потому что это такой волшебный язык. Опять же, оптимизация работы с памятью делается в тех местах, где она нужна, какой-нибудь простой обработчик нажатия кнопки можно писать максимально удобно и просто, с LINQ и прочим, так как это не hot path.
Offtopic: словосочетание «безграммотных "индусов"» сделало мой день :-)
Насчёт оптимизации – всё так. Но всё же не зная конкретных задач – трудно сказать, что в них можно выжать из разных языков в плане оптимизации и в плане удобства поддержки кода. Да плюс ещё могут вылезать какие-то менее очевидные вещи – например, Apple в своё время отказалась от использования GC в пользу reference counting, довольно любопытная история.
Ну эппл отказалась, а гугл наоборот использует java c GC в андроид - видим ли мы какую-то категорическую качественную разницу в приложениях? Я бы не сказал.
А вы полюбопытствуйте, почему именно отказались (они не просто отказались, не попробовав: несколько лет у них поддержка GC была), чем за это заплатили, что получили.
Это вопрос компромиссов, Apple предпочёл один компромисс (учитывающий их специфику – высокие требования к плавности и отзывчивости интерфейса), Google другой.
Конкретно в CardRaytracerBenchmark нет никаких затрат на выделение/освобождение памяти, там только куча математики.
Я не уверен в оптимальности тамошнего кода. Я добавил inline модификаторы и с 19сек, на моей машине, я уже получил 14сек. Так что хорошо бы взять того, кто сначала нормально напишет код, а потом уже сверять.
Компилятор Делфи не застрял в 2000-х, вы заблуждаетесь. Да, он не такой оптимальный, как некоторые для С++, но в конечных задачах на C#, где как правильно обычный код, как и на Делфи - и Делфи выигрывает в производительности конечной программы, если не заниматься в C# сильной оптимизацией.
Так же, замечу, что хоть Дельфовый компилятор и развивается, но не так быстро, как хотелось бы. В нем до сих пор мало интринсиков. И поддерживается не так много новых инструкций процессоров (в частности для векторов).
И ещё, хочу обратить внимание, что люди держаться за Делфи не потому что на нём млн.ы строк написаны, не потому что Легаси надо как-то поддерживать. На данный момент нового софта пишут не меньше, чем раньше.
Компилятор Делфи не застрял в 2000-х, вы заблуждаетесь.
У меня есть проект, который собирается разными версиями Дельфи начиная с D5/1999, недавно протестировал его на D12/2023.
И какая же разница в скорости исполняемого кода за 24 года?
Никакой! Ну может 1%, на уровне погрешности.
Потому что там в основном целочисленные расчёты, и единственное заметное улучшение компилятора (плавающая точка на SSE в x64) не влияет.
Так вот и получается, что для моих целей прогресса в компиляторе нет, и он застрял даже можно сказать в 90-х.
Андроиды и прочие платформы не особо интересны, разве что Линукс... впрочем, по сообщениям там ещё хуже со скоростью, потому что это криво (с отключенной оптимизацией) прикрученный LLVM. Кто-то может проверить кардтрейсер на Дельфи/Линуксе?
На Си у меня нет проекта в точности аналогичного дельфийскому, но тот же кардтрейсер на gcc версий 4.9 и 12 (между ними 8 лет) показывает на разных ф-ях ускорение 10-20%, а иногда 2+ раза, если новая версия векторизовала, а старая нет. С компилятором 1999 года разница должна быть ещё больше хотя бы из-за поддерживаемого набора инструкций.
Проект 90х годов нужно переписывать на новые конструкции. Новые (другие) типы. Также, использовать новую математику, интринсики и т.д. Всего этого не было тогда или было в другом виде. Компилятор изменился, инструкции новые тоже есть. Но большая часть кода осталась старой для обратной совместимости. Те же object до сих пор существуют и работают (правда, давно уже deprecated). Я уверен на 100%, что переписав код, пусть частично, под новую версию, с использованием новых подходов, скорость увеличится.
Да даже в примере выше, я немного модифицировал код (не такой и старый) и он показал прирост скорости почти в полтора раза.
Новые (другие) типы. Также, использовать новую математику, интринсики и т.д.
Какие конкретно? Про SSE я знаю и объяснил, почему это не сработало.
И речь шла о том, что некоторые ускоряют код вообще без изменений. Именно это я и называю "прогресс в компиляторе". Либо сильно ускоряют при умеренных изменениях (затачивание под векторизацию).
Единственное, что в Дельфи можно придумать с умеренными изменениями, это распараллеливание циклов. Но если очень захотеть, то можно их параллелить и в D5, хотя это и неудобно без анонимок.
Инлайн работает криво и довольно часто замедляет вместо ускорения. И кардтрейсер у меня тоже замедлил.
Покажу как я прикручивал инлайн к кардтрейсеру. И конечно проверял - да, заинлайнилось, но медленнее на 2 секунды.
И что не так?
function Add(Const v1, v2: TVector): TVector; overload; inline;
begin
Result.x := v1.x + v2.x;
Result.y := v1.y + v2.y;
Result.z := v1.z + v2.z;
end;
function Dot(Const v1, v2: TVector): TFloat; overload; inline;
begin
Result := v1.x * v2.x + v1.y * v2.y + v1.z * v2.z;
end;
function Dot(Const v1: TVector): TFloat; overload; inline;
begin
Result := v1.x * v1.x + v1.y * v1.y + v1.z * v1.z;
end;
function Init(x,y,z : TFloat): TVector; inline;
begin
Result.x := x; Result.y := y; Result.z := z;
end;
// в tracer:
p := o + TVector.Create(-k, 0, -(j + 4));
b := p * d;
c := p * p - 1;
q := b * b - c;
// ->
p := Add(o, Init(-k, 0, -(j + 4)));
b := Dot(p, d);
c := Dot(p) - 1;
q := b * b - c;
А вот тест бенчмарка C# на моей машине
х32 C# примерно равен скорости исполнения x64 Delphi
x64 C# медленнее чем x64 Delphi на 1.3сек
На вашем же скриншоте написана ошибка запуска. А происходит она потому что первый тест это запуск с версией .net core, которая у вас не собралась. https://github.com/Mark-Kovalyov/CardRaytracerBenchmark/blob/master/c-sharp/run.cmd В результате вы смотрите только бенчмарк для .NET Framework, оптимизацией и развитием которого MS уже много лет не занимается.
Версия MSBuild 17.7.4+3ebbd7c49 для .NET
Определение проектов для восстановления...
Все проекты обновлены для восстановления.
CSC : error CS5001: Программа не содержит статического метода "Main", подходящего для точки входа. [D:\Projects\#Fork\C
ardRaytracerBenchmark\c-sharp\card-raytracer.csproj]Это из-за того, что папка с исходниками совпадает с выходной. Новые SDK в этой ситуации отказываются автоматически включать исходники в проект.
Замените <Compile Remove="card-raytracer-mt.cs" />в проекте на <Compile Include="card-raytracer.cs" />
Да и netcopreapp2.1 надо заменить на что по-свежее, net7.0 там или net8.0
Ну в общем вот. Быстрее где-то на 1.2сек. Но повторяю, что стоит написать на Делфи более актуальный код. Я бы занялся, но времени хватает, только что на Хабре языком чесать)
Тут на Делфи х64
Просто напомню, что началось все с утверждения "C#, который "всего" в 2 раза медленнее нативного Delphi". А касательно оптимизации - .net версия там так же без особых мыслей сделана, те же хинты для инлайнинга в C# тоже можно было бы расставить и использовать MathF вместо Math. Да и, к примеру, не удивлюсь если вот этот кусок побайтовой записи в файл занимает больше времени чем весь остальной код
res.WriteByte((Byte)p.x);
res.WriteByte((Byte)p.y);
res.WriteByte((Byte)p.z);
Ну что касается "написать правильно", то например C++ можно относительно небольшими правками разогнать в разы, я про это целую статью писал:
https://habr.com/ru/articles/685228/
Дельфи от этих правок ускоряется гораздо меньше, потому что векторизацию компилятор не умеет совсем. Хотите SIMD - только хардкор, только ассемблерные простыни вручную.
кодогенерация в плюсовых компиляторах со временем улучшается
Вот только при этом системные требования к откомпилированным программам все растут и растут.
Это вы красиво зашли :-). Сейчас ностальгирующие по Delphi деды вроде меня вас запомнят, и потом вам будет, где искать разработчиков. Вероятно, даже не таких плохих, как обычно видишь на собесах.
Поэтому стек Microsoft, включая C#, который «всего» в 2 раза медленнее нативного Delphi не подходит.
С учетом что последняя версия .net показывает в большинстве бенчамарков производительность сопоставимую с С++, то либо делфи обладает какой-то невероятной скоростью работы, в разы быстрее С++, во что крайне сложно поверить, либо, что более вероятно, вы просто заблуждаетесь.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/csharpcore-gpp.html
Программист некромант
Особенности концепции языка предполагают создание новых переменных только в заголовках
Неужели?
program Test;
begin
var MyVar := '123'; //string
writeln(MyVar);
end.Еще у паскаля есть одна уникальная причуда, это процедуры (на ровне с функциями), так как это высокоуровневый язык программирования (спроектированный под концепцию ооп) работа предполагается со сложно составными объектами (с классами), и, специально для свойств внутри этих классов (для переменных внутри класса, класс — это пользовательский тип данных) были созданы процедуры (для изменения содержимого, которое ассоциировано со свойством).
Этот бред мы просто пропустим. И да, язык не "спроектирован под концепцию ООП". Язык мультипарадигменный. Хочешь - используй ООП, хочешь ФП.
Не в обиду разработчикам с++ и с (которые работали всю жизнь только с С, С++, «сибразины»), но у паскаля есть множество неоспоримых плюсов перед с++ (хе‑хе ну вы поняли с++ и плюсы), просто мало кто о них знает в меру собственных знаний.
К примеру, богатая палитра Com объектов (компонентов, или готовых шаблонов для кнопок, полей ввода текста, картинок, и тд, кароч не надо изобретать велосипеды).
Как это вообще относится к языку? Это никак к нему не относится. Это VCL - GUI фреймворк. И да, язык можно использовать БЕЗ VCL и даже для создания сложных программ с GUI.
Lazarus - это НЕ ПРО Delphi. Это про FPC! Это разные языки и с каждым кодом всё больше и больше между ними разница.
PUBLISHED ничем не отличается от PUBLIC. Это специальный модификатор, который используется при регистрации класса в среде разработки для работы в DesignTime!
Вы, к слову, прекрасный представитель "БЫДЛО кодера" на Паскале.
Модификаторы доступа НЕ пишутся на каждую строчку и не относятся к конкретной строчке! Модификатор доступ - это СЕКЦИЯ!
По этому, когда вы напишите следующее
... class
PRIVATE MyField: integer;
MyString: string;
end;MyString - ТОЖЕ private! Потому что следует писать вот так:
... class
private
MyField: integer; //private
MyAnotherField: string; //private
public
MyString: string; //public
MyInt: integer; //public
end;Несмотря на то, что я люблю Delphi ваша статья заслуженно получает минус от меня. Причины:
Вы учите плохому. Подходы не верные. Используете антипаттерны и, хоть вы и пишите, что в Делфи можно избавиться от низкоуровневого программирования, вы используете постоянно символ "@" - который позволяет получить прямой адрес. Это делать, без необходимости вообще не надо. А я уже и не помню, когда подобное писал.
Очень много синтаксических ошибок и много не верной (не актуальной) информации. Когда говорят о COM объектах - подразумевают не контролы VCL, которые технически ими являются, но обернуты очень глубоко фреймворком. И к самому языку они никак не относятся!
У вас очень плохой багаж знаний современного Delphi. А помимо всего этого, вы вроде как говорите о Delphi, но используете FPC и среду Lazarus, которые никак не связаны с Delphi!
Современный Delphi сильно вырос по сравнению с FPC и среда разработки RAD Studio на порядок превосходит Lazarus.
Вакансий на HH:
Delphi: 265 (-7) ~90k (22-270)
Pascal: 83 (-3) ~90k (30-180)
Python: 3697 (-32) ~60k (8-500)
C#: 2088 (-33) ~50k (15-275)
C++: 2595 (-34) ~100k (25-450)
Swift: 455 (-16) ~100k (30-350)
Java: 3413 (-37) ~75k (15-200)
Visual Basic: 97 (-5) ~90k (20-200)
Go: 1118 (-1) ~90k (25-400)
Ruby: 173 (-3) ~130k (25-350)
Kotlin: 1065 (-22) ~100k (15-450)
Rust: 105 (-1) ~150k (50-400)
Fortran: 6 (0) ~180k (180-180)
Dart: 134 (0) ~140k (30-300)
Flutter: 227 (-3) ~80k (30-300)
FireMonkey: 1 (0) ~65k (65-65)
Electron: 93 (-2) ~175k (70-350)
Lazarus: 12 (-1) ~100k (20-120)
React Native: 274 (-6) ~80k (30-320)
PostgreSQL: 4877 (-68) ~70k (15-250)Вот такую статистику я в боте вывожу. Здесь запрос на HH на 100 свежих позиций. Ну и общее кол-во вакансий тоже показывается.
1 число - это всего вакансий (в скобках - разница с предыдущим значением). 2 - медианная зп (на последних 100 вакансий), 3 - вилка
Для меня Паскаль стал хорош в обучении тем, что строго следил и говорил мне, что я должен был описать каждую переменную, которую хочу использовать.
Вставлю свои пять копеек. А чего это Вы какую-то страшную IDE используете? Есть же Embarcadero RAD Studio Community 10.xx бесплатная, со всеми подсветками, переходами по имплементации и т.п. фишками нормальной IDE. По мне, так полная (могу ошибаться) копия Visual Studio в плане функционала.
Visual Studio - это копия RAD Studio =)
В последней версии Community Edition Embarcadero опять учудили - удалили компилятор командной строки! Вы по прежнему можете делать всё, но некоторые вещи теперь должны делать через Ж или опять слегка пиратить. Конечно дарёному (бесплатному) коню в зубы не смотрят. Но при всей моей привязанности к Дельфи политика Embarcadero иногда, мягко говоря, своеобразная.
Я не качал последней версии, у меня на домашнем компе стоит, скачанная больше года назад 10ть - точка какая-то версия. На лэптопе с работы стоит полноценная лицензионная 11ая.
Я писал сразу GUI для измерительной программы и командная строка нужна была больше для проверки очень ограниченной части функционала отдельных кусков и прогона некоторых идей. Командная строка работала отлично.
Все подобные баги - это ведь извечная проблема всего бесплатного :(
Интересно, 24 людям (на моменть написания этого комментария), которые поставили плюс этой статье, что именно в ней понравилось?
Многоэтажную конструкцию:
StringGrid1.Cells[0,0]:='б';
StringGrid1.Cells[1,0]:='ы';
StringGrid1.Cells[2,0]:='д';
StringGrid1.Cells[3,0]:='л';
StringGrid1.Cells[4,0]:='о';
StringGrid1.Cells[5,0]:='к';
StringGrid1.Cells[6,0]:='о';
StringGrid1.Cells[7,0]:='д';
StringGrid1.Cells[8,0]:='е';
StringGrid1.Cells[9,0]:='РРР';можно было заменить всего на одну строчку:
StringGrid1.Rows[0].DelimitedText := 'б ы д л о к о д е ррр'Результат будет тот же! )))
круто, особенно круто когда ты хочешь написать простой аудиоплеер, который берет kate token для vk, что бы можно было обращаться к audio.get, пишешь код, создал класс с панельками и кнопками на них, поместил его в TObjectList<T>, начинаешь создавать объекты на scrollbox, а потом выясняется что если на скроллбоксе есть панели, то скроллбокс тупо отказывается скроллиться мышкой... Толи теряет фокус толи еще что-то... тупо вручную приходится... отвращение у меня от delphi... Даже не стал тратить время, удалил delphi вместе с кодом.
постоянно какие-то костыли приходится изобретать...
а что в других языках? взял, сделал и работает! без костылей, без каких либо проблем, как задумал так и работает.
В какой среде разработки "взял, сделал и работает"? Нужно по быстрому приложение на windows накидать со сложным интерфейсом, а так как лет 7 на виндовс ничего не разрабатывал возник вопрос на чем делать, поискал и принял решение, что Делфи, наверное, подходит лучше всего(тем более когда-то много на нем писал). Или может есть более удобный "язык" программирования под виндовс, чтобы создание интерфейса не стало сложнее самой программы и расчетов?
а что в других языках? взял, сделал и работает!
ага конечно, только в других языках уже очень давно, чтобы собрать helloworld надо половину интернета перелопатить и кучу мануалов чтобы оно просто компилироваться начало
на какомнить C# в вижуалстудии кучу гигабайт софта устанавливается который может недоустановится по какимто причинам и ты иди копайся чё у него там заклинило
про всякие си я вообще молчу, питон...это для буйнопомешанных только графический софт писать
вот реально, каким бы я не был противником делфей, но в данном случае это реально самый простой способ сделать софтину с gui не вникая во всякие тулчейны и прочее
Я все же считаю что Visual Studio будет попроще. Что-то простое на Delphi и правда сделать быстрее, но вот шаг в сторону - и прут зависимости, которые непонятно как вообще устанавливать. Настолько непонятно, что однажды в интернете я встретил совет установить Delphi заказчику, чтобы он мог запускать программы :-) В то же время последнее время в .NET все зависимости идут с программой просто по умолчанию.
Хотя я могу и ошибаться, всё же я сравниваю свои воспоминания о древнем Delphi 7 и актуальный .NET 8.
В отличие от дотнета Делфи компилирует сразу в один ехе. И никакие зависимости по умолчанию не требуются.
И даже для сборки не требуется ставить все в среду. Достаточно указать исходники и запустить билд.
Сложности с зависимостями возникают у новичков, когда он хочет открыть у себя сторонний проект и с ним поработать. Тогда в среду нужно установить все дизайнтайм пакеты.
Однако, это в основном проблемы старых версий. Давно уже в делфи имеется штатный менеджер пакетов, который ещё и сам все установит при открытии проекта.
Я уверен, что будь у вас больше опыта в работе с делфи, вы бы так не писали.
Именно с дотнетом шаг в сторону и "пиши пропало", в Делфи же даже штатные фреймворки и весь ртл открыт для изучения и даже частично для модификации.
Но ещё раз повторюсь, что если на руках у вас собранный ехе, никаких зависимостей ему не требуется. Все внутри.
Все эти проблемы от вашей же некомпетентности в инструменте.
По поводу скролбокса и панелек. Если что, то ваша проблема в том, что вы не понимаете, что контролы (если мы говорим конечно о VCL) - это виндовые объекты. И панельки - тоже контролы. А все контролы обрабатывают события. Когда у тебя под мышкой панель - именно она получает событие. И это не "фишка" делфи, это так работает winapi! В winforms на шаре у тебя было бы все в точности так же.
Как стать Delphi-программистом за час «для самых маленьких»