.
Я программист не очень профессиональный, знаю только Delphi, но нашёл себе нишу, в которой востребована креативность. И создалось ощущение, что мой стиль программирования вообще относительно часто принят у дельфистов. Грубо говоря, под C++ написано много библиотек, а под Delphi мало, и это убивает Delphi; с другой стороны, Delphi в целом более правильный и удобный ЯП, позволяющий писать сложные алгоритмы с меньшим количеством ошибок. Отсюда предположение, что сишниками становятся программисты, которым проще найти библиотеки, изучить документацию и так далее; а дельфистами становятся те, кому проще изобрести велосипед а не искать готовое. У меня это выражено в крайней степени.
"Ты должен сделать добро из зла, потому что его больше не из чего сделать". АБ Стругацкие.
Здравствуйте, Khimik, Вы писали:
K>Я программист не очень профессиональный...
Я сам не очень профессиональный, но большинство знакомых мне языков (думаю, с десяток наберется) в своей базе позволяют реализовать практически любые свои алгоритмические фантазии примерно с одинаковым количеством ошибок. Просто где-то писанины больше, где-то меньше. Делфи (ну и билдер, конечно тоже) прекрасный язык и платформа (были лет 20 назад точно, сейчас — хз) и прекрасно интегрируется с сишными либами через DLL.
. K>Я программист не очень профессиональный, знаю только Delphi, но нашёл себе нишу, в которой востребована креативность.
Не забываем подчеркнуть свою исключительность
K>И создалось ощущение, что мой стиль программирования вообще относительно часто принят у дельфистов.
Да-да, это не я пишу говнокод, это просто так принято
K>Грубо говоря, под C++ написано много библиотек, а под Delphi мало, и это убивает Delphi;
Потому что у Дельфи язык — говно
K>с другой стороны, Delphi в целом более правильный и удобный ЯП, позволяющий писать сложные алгоритмы с меньшим количеством ошибок.
То-то ты сортировку который день сделать не можешь
K>Отсюда предположение, что сишниками становятся программисты, которым проще найти библиотеки, изучить документацию и так далее; а дельфистами становятся те, кому проще изобрести велосипед а не искать готовое.
Репрезентативная выборка из одного человека. Можно начинать делать вселенского масштаба выводы.
На самом деле это конечно же не так.
Когда я работал на Дельфях, стандартный алгоритм решения проблемы у коллег был такой: 1) Ищем родной компонент для решения проблемы. Если компонент найден, проблема решена. 2) Ищем сторонний компонент для решения проблемы. Если компонент найден, проблема решена. 3) Компонент не найден — проблема не имеет решения.
Сишники и плюсовики как раз не любят искать готовое и читать документацию. Именно поэтому для C/C++ так много библиотек. Да вот тот же Линукс родился потому, что человеку не хотелось готового.
K>У меня это выражено в крайней степени.
Да, ещё раз не забываем подчеркнуть свою исключительность. Не то, что всякое сишное быдло, которое даже в "научные" разделы форума не заглядывает.
. K>Я программист не очень профессиональный, знаю только Delphi
Это вообще не важно.
K> Грубо говоря, под C++ написано много библиотек
При желание их можно использовать из delphi
K>с другой стороны, Delphi в целом более правильный и удобный ЯП
К сожалению правильных и удобных нет. Везде есть компромиссы.
K>позволяющий писать сложные алгоритмы с меньшим количеством ошибок.
Ошибки можно делать даже не в алгоритмах, а в предположениях на которых строится алгоритм и от яп это никак не зависит.
K>Отсюда предположение, что сишниками становятся программисты, которым проще найти библиотеки, изучить документацию и так далее
Это вы еще js, python, perl, php, java,... не видели где есть огромные централизованные репозитории с библиотеками которые устанавливаются лёгким движением.
K>а дельфистами становятся те, кому проще изобрести велосипед а не искать готовое.
Что бы изобрести некоторые велосипеды надо иметь уровень знаний не доступный большинству программистов. Поэтому народ не заморачивается и встраивает библиотеки из fortran-а в python
Здравствуйте, пффф, Вы писали:
п> K>Грубо говоря, под C++ написано много библиотек, а под Delphi мало, и это убивает Delphi;
п> Потому что у Дельфи язык — говно
Только Марти мог пи3дануть такую #уйню. Спалился, окончательно. Реверс, это точно он!
Здравствуйте, SergeyIT, Вы писали:
П>>Когда я работал на Дельфях, стандартный алгоритм решения проблемы у коллег был такой...
SIT>Так ты работал или коллеги?
Я работал и решал задачи, а коллеги искали компоненты.
Здравствуйте, пффф, Вы писали:
П>Я работал и решал задачи, а коллеги искали компоненты.
Ну прям про студентов нынешних (не всех).
А кто создавал компоненты? У вас таких не было?
ЗЫ
Многое, конечно, зависит от задач.
Когда-то работал с Дельфи, решал задачи, искал копоненты редко, создавал свои... В одной фирме был едиственным Дельфи разработчиком (из 20-50 программистов на С++). Не помню, чтобы находили баги в моих прогах,
(кроме 1 случая — в окне один контрол на 1 пиксел сдвинут оказался)
И по прошлому опыту — не вижу особой разницы на чем писать на Паскале или С++. Перейдя на линукс, использовал как Лазарус, так и QTCreator.
Здравствуйте, SergeyIT, Вы писали:
П>>Я работал и решал задачи, а коллеги искали компоненты.
SIT>Ну прям про студентов нынешних (не всех). SIT>А кто создавал компоненты? У вас таких не было?
Компоненты у нас не создавали.
Нетривиальные задачи решал я на плюсах (в C++ билдере, чтобы остальным можно было пользоваться).
SIT>ЗЫ SIT>Многое, конечно, зависит от задач.
И от дельфистов. В основной массе это просто формошлёпы
SIT>Когда-то работал с Дельфи, решал задачи, искал копоненты редко, создавал свои... В одной фирме был едиственным Дельфи разработчиком (из 20-50 программистов на С++). Не помню, чтобы находили баги в моих прогах, SIT>(кроме 1 случая — в окне один контрол на 1 пиксел сдвинут оказался)
Никто не говорит, что на Дельфях можно делать хорошие вещи. Вопрос в том, сколько людей могут это.
SIT>И по прошлому опыту — не вижу особой разницы на чем писать на Паскале или С++. Перейдя на линукс, использовал как Лазарус, так и QTCreator.
Дельфи как система — очень хороша была. Тут спору нет. А вот язык, который был взят там за базу — Паскаль — полный отстой. Да, на нём можно тоже что-то делать. Ценой невероятных усилий, по сравнению с плюсами.
Здравствуйте, Khimik, Вы писали: K>Я программист не очень профессиональный, знаю только Delphi, но нашёл себе нишу, в которой востребована креативность. И создалось ощущение, что мой стиль программирования вообще относительно часто принят у дельфистов. Грубо говоря, под C++ написано много библиотек, а под Delphi мало, и это убивает Delphi; с другой стороны, Delphi в целом более правильный и удобный ЯП, позволяющий писать сложные алгоритмы с меньшим количеством ошибок. Отсюда предположение, что сишниками становятся программисты, которым проще найти библиотеки, изучить документацию и так далее; а дельфистами становятся те, кому проще изобрести велосипед а не искать готовое. У меня это выражено в крайней степени.
Вы угадали с точностью до ровно наоборот.
Популярность Delphi исторически была связана с тем, что это не просто Object Pascal, а RAD-среда, которая оптимизирована для быстрого создания виндового UI.
Поэтому за время, которое нужно было C++ программисту для компиляции сэмпла "окно с тремя табами", Delphi-программист нашлёпывал форму с табами, меню, датагридом и привязкой к базе на Paradox, и успевал всё это запустить.
При этом минимальные изменения типа "а давайте мы контент с табов 'Настройки' и 'Предпочтения' перенесём на один таб 'Опции', и расположим в виде двух окошек со сплиттером между ними" могли программиста на Watcom C++ занять на неделю, а на Delphi делались за несколько минут.
Характерным отличием Delphi от основного конкурента — VB с его ActiveX-компонентами — было то, что компоненты Delphi писались на том же Delphi. Программисту на VB, который упёрся в ограничения компонента ActiveX, ничего не оставалось сделать, как признать задачу неразрешимой. Ну, либо осваивать целиком совершенно другой язык и среду разработки, чтобы навелосипедить свой собственный ActiveX.
В теории, такое отличие Delphi должно было стимулировать "формошлёпов" осваивать компонентостроение и писать переиспользуемый код. Тем более, что вся VCL поставлялась в исходниках, и при желании можно было в отладчике пошагово посмотреть, как работает любой из коробочных компонентов.
Однако на практике невыносимая лёгкость формошлёпства привела к тому, что подавляющее большинство Delphi-программистов и знать не хотели, как там оно устроено под капотом. Как тут по соседству написали: есть компонент — есть решение, нет компонента — нет решения.
Исключения из этого, конечно, же, случались (а иначе кто бы написал все эти 100500 библиотек компонентов в дополнение к стандартной палитре), но статистически они были совершенно незначимы.
Далее, выбор Хейльсбергом Object Pascal в качестве языка сыграл с пользователями Delphi дурную шутку. Паскаль сам по себе прекрасно подходит для изучения алгоритмов; а вот писать на нём повторно используемые алгоритмы практически невозможно. Отсутствие обобщённых типов и перегрузки операторов приводило к тому, что алгоритм сортировки писал себе примерно каждый (либо сводил всё к существующим решениям).
В целом, по сравнению с примерно любым современным языком, Delphi очень сильно мешает писать сложные алгоритмы с меньшим количеством ошибок. Тупо нет нужных средств декомпозиции алгоритмов.
В сочетании с RAD-особенностями это и привело к знаменитому качеству типичного дельфийского кода, где вся бизнес-логика написана в обработчиках типа Button1Click, а если есть два похожих сценария — то один из другого сделан просто копипастой с заменой пары строчек.
Альтернативные языки повышали порог вхождения в индустрию. С одной стороны, это затрудняло написание приложений (особенно если приложение по природе своей — это фронт-енд к какой-нибудь реляционке); с другой стороны, "нашлёпанные" без понимания сути вещей приложения просто не взлетали. Да, в до-MFC-шную эпоху виндовое приложение на С++ должно было вручную выгребать сообщения из очереди; с другой стороны — автор такого приложения был вынужден знать матчасть и понимать, как именно два клика превращаются в двойной клик.
Поэтому там, где дельфийский программист на вопрос "а можно сделать, чтобы хелп показывался по тройному клику на кнопку?", уверенно отвечал "нет" (потому что у кнопки нет события OnTripleClick), плюсовый программист просто делал свою реализацию детектирования тройного клика.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S> Далее, выбор Хейльсбергом Object Pascal в качестве языка сыграл с пользователями Delphi дурную шутку. Паскаль сам по себе прекрасно подходит для изучения алгоритмов; а вот писать на нём повторно используемые алгоритмы практически невозможно. Отсутствие обобщённых типов и перегрузки операторов приводило к тому, что алгоритм сортировки писал себе примерно каждый (либо сводил всё к существующим решениям).
Это, конечно, глупость несусветная. Особенно про перегрузку операторов (запахло костыльным дженерик-мафом ). Например, дженерики появились в дельфях всего на три года позже, чем в шарпе. А во времена турбовижн алгоритмы кастомизировались — та-да-м — процедурными типами!
S> В целом, по сравнению с примерно любым современным языком, Delphi очень сильно мешает писать сложные алгоритмы с меньшим количеством ошибок. Тупо нет нужных средств декомпозиции алгоритмов.
S> В сочетании с RAD-особенностями это и привело к знаменитому качеству типичного дельфийского кода, где вся бизнес-логика написана в обработчиках типа Button1Click
Штука втом, что это поведение демонстрируют все человеческие особи у которых такая возможность есть, независимо от используемого языка. Просто потому что могут (да, как тот кот, что яйца лижет). И ленивы. И шарписты так фигачат с винформсами и сисиплюсники с кутей и жабщики, когда пилят под ведро (только там это все усугубляется еще ручной работой). В общем, ха. Три раза.
Короче. Самым убойным аргументом против паскаля является... У них там begin/end!
Здравствуйте, rudzuk, Вы писали:
R>Это, конечно, глупость несусветная. Особенно про перегрузку операторов (запахло костыльным дженерик-мафом ).
При чём тут женерик-маф? Я на Delphi оттрубил своё по полной программе, так что пишу с полной ответственностью.
Банально никаких коллекций на Delpgi не было, кроме TList.
Сделать простую штуку типа "отсортировать список по пользовательскому критерию" — боль, ужас, унижение.
R>Например, дженерики появились в дельфях всего на три года позже, чем в шарпе.
И на 20 лет позже, чем в C++.
R>А во времена турбовижн алгоритмы кастомизировались — та-да-м — процедурными типами!
Ага. Расскажите мне, во сколько строк кода запишется на Object Pascal какая-нибудь банальщина типа "обойти граф, заданный моей объектной моделью, в глубину, отфильтровав по параметру, частично заданному пользователем, и собрать некую агрегатную величину". Ну там — берём AST программы, ищем узлы-референсы, заимпортированные из модуля X, для них считаем сумму условной вычислительной сложности.
На более-менее любом современном языке это будет весьма простой генератор/итератор, за которым .filter(...).map(...).reduce(...).
На Delphi остаётся только пердолиться с "процедурными типами" и/или Visitor Pattern.
R>
Возможно, на современном Delphi ситуация как-то поменялась; в том, который был актуален во времена расцвета его популярности, всё это суровая правда.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
R>> S>Возможно, на современном Delphi ситуация как-то поменялась; в том, который был актуален во времена расцвета его популярности, всё это суровая правда.
Чуть лучше, чем в условном Delphi7. Но всё равно плохо. 2 главные проблемы
1)
Нет аналога yield return. Итераторы откровенно задолбаешся писать.
2) очень громоздкий синтаксис анонимных функций.
Delphi
Positions.Sum(function (APos: TSmetaPosition): Currency begin Result := APos.Price; end)
vs
C#
Positions.Sum(pos => pos.Price)
Еще нет аналогов extension методов для интерфейсов/дженерик типов (хотя например для НЕ дженерик классов есть). Но это хоть криво-косо но можно решить типами-обертками
Здравствуйте, Sinclair, Вы писали:
S>Далее, выбор Хейльсбергом Object Pascal в качестве языка сыграл с пользователями Delphi дурную шутку. Паскаль сам по себе прекрасно подходит для изучения алгоритмов; а вот писать на нём повторно используемые алгоритмы практически невозможно. Отсутствие обобщённых типов и перегрузки операторов приводило к тому, что алгоритм сортировки писал себе примерно каждый (либо сводил всё к существующим решениям). S>В целом, по сравнению с примерно любым современным языком, Delphi очень сильно мешает писать сложные алгоритмы с меньшим количеством ошибок. Тупо нет нужных средств декомпозиции алгоритмов.
И в Go до недавнего времени и в Java до 5 версии не было генериков. И ничего — через interface{} / Object прекрасно все алгоритмы писались.
Я больше скажу — ни в Go, ни в Java у меня не было никакой необходимости писать какие-то обобщённые алгоритмы.
И я даже ещё больше скажу. Крамольную вещь. Те, кто любят писать обобщённые алгоритмы, как правило, тратят время впустую на ментальную гимнастику вместо того, чтобы решать проблемы. Поэтому ругать конкретно Pascal считаю некорректным. Нормальный язык, никак не ограничивающий программиста. И во многих отношениях на порядок лучше того же С++.
По остальным пунктам в целом согласен, но главная проблема Delphi это то, что её не смогли адекватно развивать. Уж не знаю, кто конкретно был в этом виноват, но если бы за Delphi стоял Microsoft с нормальным финансированием, а не какие-то неизвестные компании, пытающиеся урвать хоть что-то перед очередной перепродажей, если бы тот же Хейлсберг её продолжал развивать, скорей всего с ней всё было бы хорошо.
S>Альтернативные языки повышали порог вхождения в индустрию. С одной стороны, это затрудняло написание приложений (особенно если приложение по природе своей — это фронт-енд к какой-нибудь реляционке); с другой стороны, "нашлёпанные" без понимания сути вещей приложения просто не взлетали. Да, в до-MFC-шную эпоху виндовое приложение на С++ должно было вручную выгребать сообщения из очереди; с другой стороны — автор такого приложения был вынужден знать матчасть и понимать, как именно два клика превращаются в двойной клик.
И как же? Я вот не знаю, как формируется WM_LBUTTONDBLCLK.
Это потому, что начинал с Дельфи?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
