Delphi и его диалект в FPC - прекрасные языки, причем достаточно современные. Все эти годы он не топтался на месте: добавили языковые фишки вроде неймспейсинга, дженериков, анонимных функций, допилили компилятор и сделали бэкэнд на LLVM для кроссплатформенности, сделали поддержку самых разных платформ. Даже пробовали интегрировать с .NET!
С этим никто не спорит, но лично я считаю правильным ходом было бы отдать компилятор Delphi в Open Source и тогда очень быстро и IDE для всех осей появятся и много чего еще. Но что-то мне подсказывает что такое не произойдет.
Но современным новичкам изо всех щелей пихают убогий петухон и жабоскрипт (он норм) и из за огромного числа либ для выполнения почти любых задач, люди иногда перестают думать сами и собирают программы из всего готового
Ну про Delphi в свое время говорили также, что в нем не надо сильно знать программирование а просто подключать контролы и писать биндинги. Стандартный курс обучения включал только основы языка а все остальное время обучающиеся учились как пользоваться IDE.
Заголовок не соответствует содержимому статьи потому что причем тут зумеры? А по сабжу описание выглядит каким-то слишком уж оторванным от жизни. Только на одной моей работе был человек комиты которого были как днем так и в 3 часа ночи но это был его личный выбор. Сам же я на первой же работе обжегся когда перерабатывал чтобы "не подводить кого-то там" и ездил в командировки за свой счет и много еще каких шишек набил. Остаться на час максимум можно если прям очень сильно горит прод и то обычно просто надо подставить костылек или откатить прошлую версию а уже на следующий день со свежей головой разобраться что там была за шляпа.
C# может и сделан по лекалам Java, только вот WinForms, на половину, до сих пор состоит из тех же классов с теми же именами, что и VCL в Delphi.
WinForms это древняя технология существующая до сих пор только потому что есть легаси написанное на ней. И вообще ничего удивительного в копировании хороших вещей от конкурента нет, этим все занимаются.
Ну и если посмотреть на современные возможности Delphi и экосистемы, то мы имеем штатный кроссплатформенный фреймворк FMX (под все платформы), сторонний (от нашего разработчика) нативный фреймворк для Android/iOS - FGX, кучу веб-фреймворков, включая бэкенд фреймворки и фронтенд фреймворки (MARS, Horse, DMVC, UniGUI, TMS Web Core, mORMot, RAD Server и т.д.).
Всё это позволяет покрыть почти все что нужно
Еще раз я не говорю инструмент что-то не умеет и он плох в том что он делает. Проблема лежит не в технической плоскости, а в том что у него маленькое сообщество (по сравнению с мейнстримными языками) а также маленькая известность. Одно это дает очень много недостатков инструменту (банально попробуйте настроить github actions для проекта delphi) уменьшает фонд новичков (потому что на курсах учат модно-молодежные технологии). Все эти процессы не происходят одномоментно, все это растягивается на годы, но факт в том что Delphi как инструмент сейчас не особо популярен и то что он может или нет этого не изменит.
Как по мне в свое время надо было отдавать в Open Source компилятор языка и IDE это дало бы сильнейший буст популярности а также дало "лишние руки" на поддержку все этого добра, но это надо было делать до того как появился Free Pascal и Lazarus, сейчас уже поезд ушел.
А МС, купивший акции Борланда тут не при чем. И совсем не участвовал в установке курса инструмента.
C#, руками главного архитектора, взяли что можно из Delphi и вели его напрямую в провал имея право голоса купленными акциями.
А Borland только простите Delphi имел в портфолио? Вообще то у него в портфолио была целая россыпь языков. И эта история о которой Вы говорите очень туманна и голословно утверждать что вот прям чтобы Delphi убить это было сделано.
.NET конкурировал с Java и был сделан по лекалам Java и Delphi тут совсем ни при чем. Конкурентом Delphi был Visual Basic потому что эти два продукта были очень сильно похожи по функционалу (и существовали в одно время) и возможностям и нацелены на один и тот же сегмент рынка. Выводы в статье крайне спорные. Delphi как продукт как существовал в своей нише так и существует, уменьшение популярности связано с тем что в начале нулевых произошел сильный сдвиг на Web платформу всего что только можно и Delphi как инструмент нацеленный на desktop разработку стал мало кому нужен, потому что и desktop разработка стала мало кому нужна. Попытка в мобилки была обречена на провал потому что там властвуют не сдвигаемые технологии, на андроиде Java которая вряд ли куда-то денется а там и Kotlin-ы подтянулись а на iOS даже не стоит пытаться тамошняя публика умеет только в инструменты самого эпла и боготворит их. Кроссплатформа для мобил тоже обречена на провал, потому что там высочайшая конкуренция. Что с серверами и веб? Там тоже уже давно много мастодонтов которых тяжко сдвинуть. Также тут есть доля злой шутки, язык Pascal и его производные в сообществе считались (и до сих пор много кем считаются) "игрушечным" не серьезным языком, это примерно как с PHP до сих пор много людей считают что он плох просто потому что кто-то где-то его поливал гомном. Delphi программисты считались теми кто "программирует мышкой", т.е. сам по себе инструмент не воспринимался серьезно. И я это не выдумал я сам начинал как Delphi программист и первые деньги заработал именно разрабатывая на Delphi. Итого проблема не в инструменте как таковом (а он хорош) а в том что компания инструмент делавшая (все компании) не подстроились под рынок во время и упустили огромные сегменты куда могли зайти первыми и стать мейнстримом.
Отнюдь, для хорошего GUI на Qt придется приложить гораздо больше сил, чем в Delphi (RAD Studio)
И конечно же бенчмарки Вы сможете сходу приложить?
При этом всё так же на выходе один исполнительный файл без лишних зависимостей.
Вы можете убрать лишние зависимости и в Qt не поверите, и даже можно слинковать статически в один файл. Вот только теперь внимание вопрос, а что это дает? Клиенту абсолютно фиолетово один у Вас файл или нет. А linux-ах дак вообще это даже хорошо потому что клиент легко может затащить qt-овые зависимости сам и шарить их между приложениями и не только.
Webpack в свое время стал популярен потому что был проще в конфигурации чем его более возрастные конкуренты на тот момент. Vite сейчас молодой и пока не обросший сложностью инструмент, будем надеяться что его не постигнет судьба webpack-а через время.
Информацию вы вольны искать любым доступным способом, можете сами найти, может вам что-то передаст заказчик или предаставит специалистов, которые поделятся сакральными знаниями.
Вопрос был как лично Вы и Ваша команда это делаете.
Бухгалтерские отчеты - это типовая задача, для этого даже полуфабрикаты в виде 1С есть, а то и готовые конфигурации
Расскажите как происходит "полное погружение" в предметную область, мне серьезно интересно. Вот допустим сегодня Вы начинаете новый проект знания о предметной области которого у Вас равны нулю. Какие нужны действия команды для погружения? Допустим Ваш новый проект связан с бухгалтерией, Ваши знания ограничиваются что бухгалтерия это что-то связанное с расчетом денег (ну допустим). Допустим заказчик присылает Вам 200 отчетов которые должны генериться Вашим проектом с минимальными объяснениями на бухгалтерском языке, все отчеты разные и нужны для разного. Какие Ваши и команды действия по погружению в предметную область и сколько времени это может занять? Как будет распределение погружения между командой, и если да то как потом погруженные сведения будут передаваться между командой? И в целом как выглядит процесс?
Универсальное правило о чем? Я вообще то наоборот говорю что все проекты разные поэтому градировать их на типовые и сложные или еще какие-то бесмысленно.
Для меня это звучит противоположно. Наверняка есть множество градаций той или иной меры кастомности и сложности. Но что именно вы хотите показать этим вопросом?
Что градировать проекты бессмысленно, в "типовом" проекте может появиться сложная задача и "сложный" проект может наполовину состоять из типовых задач.
Требования к приложению - это проекция хотелок заказчика на реалии приложения. Если эти хотелки можно реализовать лучше и/или дешевле иным образом, то требования нужно поменять. Это как раз одна из целей обсуждения с командой.
Вроде бы у меня была простая мысль а мы до сих пор не на одной волне.
Временные рамки сильно утрирированы, но поздние митинги (часов в 7-8 вечера по Мск) с заказчиком из США - это прям типичная ситуация. Кому-то нравится сдвинутый на вечер рабочий график, кому-то - нет.
Может быть и утрировано (хотя на одной из моих работа был близкий к этому график) но чтобы по Вашей логике все работало то вся команда как минимум должна любить сдвинутый вечер, иначе как она (команда) целиком будет встречаться с заказчиком?
Учитывая вашу дотошность, упомяну, что под предсказыванием будущего имеется в виду не "бл* буду точно произойдет!", а оценка вероятности возможных будущих событий, а также принятие соответствующих решений в тех случаях когда оценочная вероятность превышает, например, 50%
Уж простите за дотошность но обычно в контексте "предсказаний" единственный критерий их результата это "сбылось" или "не сбылось" причем он проверяется когда-то потом в будущем по факту сего действа. Все ладно не буду душнить сойдемся на том что это стоит все же более корректно называть "планирование будущего" чем предсказание :)
PO приходит с такой-то проблемой, а уже требования по тому, как эту проблему можно решить - обсуждается с командой и выводятся требования к задаче.
Еще раз - Обсуждают реализацию требований (т.е. как решить проблему с которой пришел заказчик) а не сами требования (то что заказчик пришел с этой проблемой в принципе и надо ли оно ему вообще). Не вижу здесь противоречий, Вы написали ту же мысль.
Вы утрируете. В той или иной степени навык предсказывания будущего есть у каждого. Да хоть на уровне "завтра настанет утро и я пойду на работу". А развитие этого навыка по отношению к проработке архитектуры достигается за счет знаний, опыта, набитых шишек, а также погружения в предметную область.
Это не навык предсказания будущего, это просто опыт. Навык предсказания будущего как раз был бы если бы Вы придя в новую для себя предметную область, новый тип проекта и новую область разработки могли что-то там "предсказать" и это работало.
Поэтому на достаточно сложных проектах обычно работают специально выделенные команды, а не мимопробегающие фрилансеры. А на типовых проектах - типовые сценарии развития, там настолько много внимания не требуется.
Ну т.е. "типовые" и "сложные" проекты никогда не пересекаются и существуют в каких-то разных мирах?
Вполне укладывается в концепции SCRUM, где вся команда на равных обсуждает требования с PO.
Обсуждают реализацию требований а не сами требования.
Средства связи в наше время уже достаточно неплохо развиты, чтобы устраивать телефонференции хоть через океаны и материки.
Ну окей Ваш заказчик доступен по Вашему местному времени с 23 до 3 часов ночи. Связь решила эту проблему? :)
что это за навык такой? как его развить? у Вас развит? Если да то расскажите сколько раз он Вам помог и в чем?
Это требует плотного погружения в предметную область, тесного общения с заказчиком и накопления некоторого багажа опыта.
Полное погружение в предметную область возможна при full time работе на одном проекте и прямые контакты всей команды с заказчиком что уже звучит мало реалистично и применимо скорее к продуктовым командам и финтеху (потому что и там и там заказчик обычно сидит если не в той же комнате то точно в том же здании).
Проблема этого явления кроется в том что многие люди считают что они знают будущее могут считать что легко угадают куда дальше пойдет то или иное решение. И действительно иногда это работает, и заранее подготовленная подушечка выручает через время, но бывает и наоборот. Я бы сказал что оптимальная практика в данном случае начинать решение задачи всегда с самого простого решения, да оно будет не расширяемым/оптимальным/т.п. но оно будет решать задачу на момент ее возникновения. Т.е. сегодня задача решить 2+2, делаем одну функцию которая просто делает 2+2 внутри. Через неделю бизнес понял что 2+2 не достаточно и надо решить задачу 2+2*x/100, окей мы вернулись к нашей функции и добавили параметр x и обновили формулу. Да пример примитивный но на самом деле в реальности такой подход довольно часто работает, я и сам его применяю. Новый модуль делается максимально просто потому что и бизнес не всегда понимает что в нем будет до конца, а потом по мере того как модуль начнет обрастать деталями можно рассмотреть какие подходы и паттерны могут помочь с его решением и если подходят то уже внедрять. Переписывать несколько раз новые модули это обычная практика. А вообще могу сказать что людей с похожими заболеваниями тоже много, например "Микросервис головного мозга" и "SOLID головного мозга".
С этим никто не спорит, но лично я считаю правильным ходом было бы отдать компилятор Delphi в Open Source и тогда очень быстро и IDE для всех осей появятся и много чего еще. Но что-то мне подсказывает что такое не произойдет.
Ну про Delphi в свое время говорили также, что в нем не надо сильно знать программирование а просто подключать контролы и писать биндинги. Стандартный курс обучения включал только основы языка а все остальное время обучающиеся учились как пользоваться IDE.
Заголовок не соответствует содержимому статьи потому что причем тут зумеры? А по сабжу описание выглядит каким-то слишком уж оторванным от жизни. Только на одной моей работе был человек комиты которого были как днем так и в 3 часа ночи но это был его личный выбор. Сам же я на первой же работе обжегся когда перерабатывал чтобы "не подводить кого-то там" и ездил в командировки за свой счет и много еще каких шишек набил. Остаться на час максимум можно если прям очень сильно горит прод и то обычно просто надо подставить костылек или откатить прошлую версию а уже на следующий день со свежей головой разобраться что там была за шляпа.
"Джентльменам принято верить на слово" (с)
Пример будет?
Если Вам и сравнивать нечем то зачем Вы утверждаете о то что к чему-то надо прилагать больше сил чем другому?
WinForms это древняя технология существующая до сих пор только потому что есть легаси написанное на ней. И вообще ничего удивительного в копировании хороших вещей от конкурента нет, этим все занимаются.
Еще раз я не говорю инструмент что-то не умеет и он плох в том что он делает. Проблема лежит не в технической плоскости, а в том что у него маленькое сообщество (по сравнению с мейнстримными языками) а также маленькая известность. Одно это дает очень много недостатков инструменту (банально попробуйте настроить github actions для проекта delphi) уменьшает фонд новичков (потому что на курсах учат модно-молодежные технологии). Все эти процессы не происходят одномоментно, все это растягивается на годы, но факт в том что Delphi как инструмент сейчас не особо популярен и то что он может или нет этого не изменит.
Как по мне в свое время надо было отдавать в Open Source компилятор языка и IDE это дало бы сильнейший буст популярности а также дало "лишние руки" на поддержку все этого добра, но это надо было делать до того как появился Free Pascal и Lazarus, сейчас уже поезд ушел.
А Borland только простите Delphi имел в портфолио? Вообще то у него в портфолио была целая россыпь языков. И эта история о которой Вы говорите очень туманна и голословно утверждать что вот прям чтобы Delphi убить это было сделано.
.NET конкурировал с Java и был сделан по лекалам Java и Delphi тут совсем ни при чем. Конкурентом Delphi был Visual Basic потому что эти два продукта были очень сильно похожи по функционалу (и существовали в одно время) и возможностям и нацелены на один и тот же сегмент рынка. Выводы в статье крайне спорные. Delphi как продукт как существовал в своей нише так и существует, уменьшение популярности связано с тем что в начале нулевых произошел сильный сдвиг на Web платформу всего что только можно и Delphi как инструмент нацеленный на desktop разработку стал мало кому нужен, потому что и desktop разработка стала мало кому нужна. Попытка в мобилки была обречена на провал потому что там властвуют не сдвигаемые технологии, на андроиде Java которая вряд ли куда-то денется а там и Kotlin-ы подтянулись а на iOS даже не стоит пытаться тамошняя публика умеет только в инструменты самого эпла и боготворит их. Кроссплатформа для мобил тоже обречена на провал, потому что там высочайшая конкуренция. Что с серверами и веб? Там тоже уже давно много мастодонтов которых тяжко сдвинуть. Также тут есть доля злой шутки, язык Pascal и его производные в сообществе считались (и до сих пор много кем считаются) "игрушечным" не серьезным языком, это примерно как с PHP до сих пор много людей считают что он плох просто потому что кто-то где-то его поливал гомном. Delphi программисты считались теми кто "программирует мышкой", т.е. сам по себе инструмент не воспринимался серьезно. И я это не выдумал я сам начинал как Delphi программист и первые деньги заработал именно разрабатывая на Delphi. Итого проблема не в инструменте как таковом (а он хорош) а в том что компания инструмент делавшая (все компании) не подстроились под рынок во время и упустили огромные сегменты куда могли зайти первыми и стать мейнстримом.
И конечно же бенчмарки Вы сможете сходу приложить?
Вы можете убрать лишние зависимости и в Qt не поверите, и даже можно слинковать статически в один файл. Вот только теперь внимание вопрос, а что это дает? Клиенту абсолютно фиолетово один у Вас файл или нет. А linux-ах дак вообще это даже хорошо потому что клиент легко может затащить qt-овые зависимости сам и шарить их между приложениями и не только.
Webpack в свое время стал популярен потому что был проще в конфигурации чем его более возрастные конкуренты на тот момент. Vite сейчас молодой и пока не обросший сложностью инструмент, будем надеяться что его не постигнет судьба webpack-а через время.
Вопрос был как лично Вы и Ваша команда это делаете.
А что тогда не типовая задача?
Расскажите как происходит "полное погружение" в предметную область, мне серьезно интересно. Вот допустим сегодня Вы начинаете новый проект знания о предметной области которого у Вас равны нулю. Какие нужны действия команды для погружения? Допустим Ваш новый проект связан с бухгалтерией, Ваши знания ограничиваются что бухгалтерия это что-то связанное с расчетом денег (ну допустим). Допустим заказчик присылает Вам 200 отчетов которые должны генериться Вашим проектом с минимальными объяснениями на бухгалтерском языке, все отчеты разные и нужны для разного. Какие Ваши и команды действия по погружению в предметную область и сколько времени это может занять? Как будет распределение погружения между командой, и если да то как потом погруженные сведения будут передаваться между командой? И в целом как выглядит процесс?
Тоже неплохой вариант
Универсальное правило о чем? Я вообще то наоборот говорю что все проекты разные поэтому градировать их на типовые и сложные или еще какие-то бесмысленно.
Что градировать проекты бессмысленно, в "типовом" проекте может появиться сложная задача и "сложный" проект может наполовину состоять из типовых задач.
Вроде бы у меня была простая мысль а мы до сих пор не на одной волне.
Может быть и утрировано (хотя на одной из моих работа был близкий к этому график) но чтобы по Вашей логике все работало то вся команда как минимум должна любить сдвинутый вечер, иначе как она (команда) целиком будет встречаться с заказчиком?
Уж простите за дотошность но обычно в контексте "предсказаний" единственный критерий их результата это "сбылось" или "не сбылось" причем он проверяется когда-то потом в будущем по факту сего действа. Все ладно не буду душнить сойдемся на том что это стоит все же более корректно называть "планирование будущего" чем предсказание :)
Еще раз - Обсуждают реализацию требований (т.е. как решить проблему с которой пришел заказчик) а не сами требования (то что заказчик пришел с этой проблемой в принципе и надо ли оно ему вообще). Не вижу здесь противоречий, Вы написали ту же мысль.
Это не навык предсказания будущего, это просто опыт. Навык предсказания будущего как раз был бы если бы Вы придя в новую для себя предметную область, новый тип проекта и новую область разработки могли что-то там "предсказать" и это работало.
Ну т.е. "типовые" и "сложные" проекты никогда не пересекаются и существуют в каких-то разных мирах?
Обсуждают реализацию требований а не сами требования.
Ну окей Ваш заказчик доступен по Вашему местному времени с 23 до 3 часов ночи. Связь решила эту проблему? :)
что это за навык такой? как его развить? у Вас развит? Если да то расскажите сколько раз он Вам помог и в чем?
Полное погружение в предметную область возможна при full time работе на одном проекте и прямые контакты всей команды с заказчиком что уже звучит мало реалистично и применимо скорее к продуктовым командам и финтеху (потому что и там и там заказчик обычно сидит если не в той же комнате то точно в том же здании).
Проблема этого явления кроется в том что многие люди считают что они
знают будущеемогут считать что легко угадают куда дальше пойдет то или иное решение. И действительно иногда это работает, и заранее подготовленная подушечка выручает через время, но бывает и наоборот. Я бы сказал что оптимальная практика в данном случае начинать решение задачи всегда с самого простого решения, да оно будет не расширяемым/оптимальным/т.п. но оно будет решать задачу на момент ее возникновения. Т.е. сегодня задача решить 2+2, делаем одну функцию которая просто делает 2+2 внутри. Через неделю бизнес понял что 2+2 не достаточно и надо решить задачу 2+2*x/100, окей мы вернулись к нашей функции и добавили параметр x и обновили формулу. Да пример примитивный но на самом деле в реальности такой подход довольно часто работает, я и сам его применяю. Новый модуль делается максимально просто потому что и бизнес не всегда понимает что в нем будет до конца, а потом по мере того как модуль начнет обрастать деталями можно рассмотреть какие подходы и паттерны могут помочь с его решением и если подходят то уже внедрять. Переписывать несколько раз новые модули это обычная практика. А вообще могу сказать что людей с похожими заболеваниями тоже много, например "Микросервис головного мозга" и "SOLID головного мозга".