Почему НЕ НАДО программировать на Delphi

[debi12345]

А что там не так в DLL?

нельзя полагаться на перехват исключений в коде ДЛЛ (кстати - весьма часто используемый ход), не договорившись с системным обработчиком аппаратных исключений о делегировании результатолв обработки, а это уже о-о-очень платформенно-зависимые дела. Для "выни" есть фикс-юнит, а вот для остальных.. кто знает ?

[NTFS]

Я о том и говорю. Что в Delphi получаем "из коробки", в FPC нужно допиливать руками. Можно называть это особенностью, можно - недостатком. Но факт остается фактом.

[debi12345]

FPC=0.9*Delphi*Ncpu*Nos. Сравнивать узкоспециализрованную софтину с таким всеохватывающим монстром...

[zub]

NTFS

Уверенность на 99,9%, что собранный бинарник не упадет у клиента с криком SIGSEGV Без иронии.

Прям падает по вине Лазаря или ФПЦ, а не изза шаловливых рук? НЕВЕРЮ! Если код скомпиленый DELPHI работает, а онже скомпиленый FPC падает - ищи баги в коде, а не клейми LAZARUS\FPC

[debi12345]

Прям падает по вине Лазаря или ФПЦ, а не изза шаловливых рук?

Код нормальный (100% совместимый с ObjectPascal), но перехват исключений в ДЛЛ требует спецмодуля, не входящего в ФПЦ, и пару команд вокруг каждого EXCEPTION FRAME. Другое дело, что лично я о проблеме с перехватом исключений услышал 1-й раз, но уже через 5 (!!!) минут нашел 100% работающее решение (тот самый модуль, о котором кричит буквально весь ИНЕТ). То есть проклятия в адрес ФПЦ по этой теме - от тех кому ФПЦ не нужен и кто и не пытался решать эту проблему Все-то делов - погуглить

Добавлено спустя 5 минут 3 секунды:

но перехват исключений в ДЛЛ

Важнейшее уточнение - АППАРАТНЫХ исключений (БД-исключения и прочее софтварное ФПЦ ловит сам).

[NTFS]

debi12345
Спасибо за пояснения, я просто пытаюсь ответить на вопрос топика. Какие преимущества имеет Delphi перед Lazarus/FPC? Отсутствие под Win32 тех проблем, которые мы обсуждаем уже вторую страницу. То, что в FPC эта проблема решается - прекрасно, но для прикладного программиста под Windows, использующего Delphi, проблемы нет! Просто нет.

[alexey38]

Спасибо за пояснения, я просто пытаюсь ответить на вопрос топика. Какие преимущества имеет Delphi перед Lazarus/FPC? Отсутствие под Win32 тех проблем, которые мы обсуждаем уже вторую страницу. То, что в FPC эта проблема решается - прекрасно, но для прикладного программиста под Windows, использующего Delphi, проблемы нет! Просто нет.

Отдельные моменты, особенно, что касается учета кроссплатформенности, в Лазаре/ФПС действительно проработаны слабо. И плохо то, что выявленные косячки со временем не переходят в решения по умолчанию - это и есть слабое звено ФПС и Лазаря. Здесь однозначно чувствуется отсутствие ресурсов и сил у команды разработчиков. Это не упрек, это констатация факта. И бесплатность проекта не позволяет лидерам разработки концентрировать ресурсы и усиливать команду разработчиков. И по существу те копейки, которые мы сэкономили не купив Лазаря (а его просто скачав), мы с лихвой тратим на чтение форумов, на дополнительную проработку. Собственно отсюда и возникают мнения, что опенсорс дороже проприетарного ПО.

Конечно решение найти можно в любой ситуации. Я помню, как еще 20 лет, я все проекты (включая оконный пользовательский интерфейс) писал на ассемблере, все работало быстро, разработка интерфейса занимала времени меньше, чем сегодня, т.к. библиотеки были продуманы, имелся язык описания форм и т.п. Вместо всяких jmp и меток, использовались макросы, так что код был поход на выскокоуровневый. И тогда, я точно знал, что могу сделать все. Хорошее было время. Потом писал на BP 7.0, была своя графическая оконная библиотека, была многозадачность (возможность под ДОСом запуска нескольких exe-файлов, с переключением задач), был идеальный отладчик под DPMI режим, когда блоки памяти (через систему сегмента и смещеня) выделялись без перекрытия, так что некоторые ошибки вылавливались намного быстрее, чем сейчас. Это был самый золотой период.

А потом стала доминировать винда. На 2012 год, VCL и LCL работаю хуже и медленее, чем то, что работало на 286 компе 20 лет назад. И ради универсальности - все это пришлось похоронить.
Собственно сегодня огромные команды разработчиков не могут сделать то, что я делал один на слабом компе 20 лет назад будучи школьником или студентом. И это все называется платой за универсальность.

[debi12345]

Здесь однозначно чувствуется отсутствие ресурсов и сил у команды разработчиков.

У "абракадабры" бы тем более не хватило тянуть столько процов и операционок, тем более не получая вистов "за поддержку некой операционки" и т.п.

Отдельные моменты, особенно, что касается учета кроссплатформенности, в Лазаре/ФПС действительно проработаны слабо

Потому что это самые трудные моменты, с учетом гигантского охвата ФПЦ по этой части. И это - одна из причин смерти кайликса и прочих НЕопенсорных попыток

Добавлено спустя 26 минут 21 секунду:

Собственно сегодня огромные команды разработчиков не могут сделать то, что я делал один на слабом компе 20 лет назад будучи школьником или студентом

==============
Ну, хотел бы посмотреть например на макро-ассмеблерный код OnCalcFields датасета, извлеченного из PostgerSQL-базы Вместе с процедурой коннекта, извлечения данных, маппинга типов...

[alexey38]

У "абракадабры" бы тем более не хватило тянуть столько процов и операционок, тем более не получая вистов "за поддержку некой операционки" и т.п.

Плохо только то, что не берут висты.

Потому что это самые трудные моменты, с учетом гигантского охвата ФПЦ по этой части. И это - одна из причин смерти кайликса и прочих НЕопенсорных попыток

Вопрос не в сложности задачи, а в желании сделать лучше. В опенсорсе личное мнение сильно влияет на то, что делается или неделается. Кто-то считает, что, например, OLE - это "г", и OLE из идейных соображений, а не из-за сложности не появится в ФПС и соответственно Лазаре. Ни кого не волнует потребность, только личная позиция определяет все.

Ну, хотел бы посмотреть например на макро-ассмеблерный код OnCalcFields датасета, извлеченного из PostgerSQL-базы Вместе с процедурой коннекта, извлечения данных, маппинга типов...

Тогда PostgerSQL просто еще не было (он был где-то в американском университете), и датасетов еще не было. А СУБД мы писали, пусть не меганавороченную, но тоже объектно-реляционную, с удобным конфигуратором, с индексами. Начинали на асме, потом перешли на BP 7, т.к. ломы было писать менеджер памяти. Что касается асма, то когда сделали макросы под конструкции типа IF, ELSE, FOR, WHILE, REPEAT и т.п., то писать OnCalcFields на нем не сложнее, чем на паскале. На асме неудобно писать сложные выражения (приходится разбивать на операции), а остальное практически то же самое.

[stikriz]

Спасибо за пояснения, я просто пытаюсь ответить на вопрос топика. Какие преимущества имеет Delphi перед Lazarus/FPC?

Вопрос топика писать или не писать на паскале. Человек в статье вообще не ведает о Лазарусе, и призывает не писать на Дельфи, т.е. не писать на паскале. Это я так, к слову.
А что не так с safecall? Кто-то пробовал использовать safecall? Я вот, сейчас выдернул шнурок из сетевухи и удачно словил исключение сети... Что не так я делаю?

Добавлено спустя 2 минуты 55 секунд:
А... Ну, да Я же тупой Все вызовы обрамляю try except raise и в dll есть GetLastError: WideString.

[Widowmaker]

<< Кто-то считает, что, например, OLE - это "г", и OLE из идейных соображений, а не из-за сложности не появится в ФПС и соответственно Лазаре. >>
Вообще-то OLE/COM/DCOM/COM+ -- г... по определению, к тому же основанное на изначально порочной концепции, этакий гибрид ишака и канарейки. Даже и сами мелкомягкие, несколько лет назад пихавшие его во все мыслимые и немыслимые виндовские приложения, последнее время изрядно поувяли насчёт его перспектив. А в фпц/лазаре он, скорее всего, не появится по двум простым причинам: а) неизлечимой некроссплатформенности; б) общей бесполезности. Кроме того, будет очень жалко, если в фпц/лазаре начнутся пляски с внедрением всяких .net-штучек в ущерб уже сделанному, о чём ходят упорные слухи.

[alexey38]

Вообще-то OLE/COM/DCOM/COM+ -- г... по определению, к тому же основанное на изначально порочной концепции, этакий гибрид ишака и канарейки. Даже и сами мелкомягкие, несколько лет назад пихавшие его во все мыслимые и немыслимые виндовские приложения, последнее время изрядно поувяли насчёт его перспектив. А в фпц/лазаре он, скорее всего, не появится по двум простым причинам: а) неизлечимой некроссплатформенности; б) общей бесполезности. Кроме того, будет очень жалко, если в фпц/лазаре начнутся пляски с внедрением всяких .net-штучек в ущерб уже сделанному, о чём ходят упорные слухи.

Какие бы пороки не сидели в концепции OLE/COM/DCOM/COM+, но в виду наличия большого числа серверов, созданных на этих технологиях, для решения реальных практических задач - это просто необходимо. Для Российского рынка - это офисные продукты микрософта и 1С.
Например, заказчику нужен некий оформленный отчет, и он за него может заплатить всего 5 т.р. (обороты и прибыли большего не позволяют). Чтобы разработка отчета была рентабельна, то на все и вся (включая внедрение) нужно затратить желательно 4 часа, край 1 день. На дорогу затратишь 1 - 2 часа (в зависимости от пробок). На узучение задачи (обсуждение с заказчиком) и на внедрение (обучение пользователя) нужно потратить 1 час. На тестирование тоже 1 час (если будет хоть один баг, то придется еще раз ехать, что губит рентабельность). На разработку остается от 10 минут до 1 часа. Соответственно если инструмент разработчика позволяет писать простые продукты за 10 минут (чтение из БД или из Excel или из 1C и формирование оформленного отчета в Word со всем форматированием, рамочками, выделением цветов и прочей чешуи), то такой разработчик в шоколаде. Если требуется 1 день только на разработку, то такой разработчик будет либо бедным, либо вынужден искать другую работу.

Успешный программист - это как солдат, который не может выбирать противника. Есть задача - решай, будешь тупить и тормозить - погибнешь сам. Но некоторые программеры, часто причатсные к опенсорс разработке напоминают нытиков, "мол то плохое, порочное - я не буду", такие не приспособлены к реальной жизни, они могут существовать только в инкубаторах со специальными условиями. А кто их даст? Единицы нытиков становятся успешными (воля случая). А те, кто решают любые задачи (даже связанные с переработкой г..на), те достигают и уважения и успеха, ведь в жизни иногда приходится даже чистить туалеты (и не путем сноса всего дома).

[debi12345]

try except raise

RAISE - повторная генерация исключения - из DLL в программу, уже с обработанным кодом ошибки ?

Добавлено спустя 5 минут 34 секунды:

Например, заказчику нужен некий оформленный отчет, и он за него может заплатить всего 5 т.р. (обороты и прибыли большего не позволяют). Чтобы разработка отчета была рентабельна, то на все и вся (включая внедрение) нужно затратить желательно 4 часа, край 1 день. На дорогу затратишь 1 - 2 часа (в зависимости от пробок). На узучение задачи (обсуждение с заказчиком) и на внедрение (обучение пользователя) нужно потратить 1 час. На тестирование тоже 1 час (если будет хоть один баг, то придется еще раз ехать, что губит рентабельность). На разработку остается от 10 минут до 1 часа. Соответственно если инструмент разработчика позволяет писать простые продукты за 10 минут (чтение из БД или из Excel или из 1C и формирование оформленного отчета в Word со всем форматированием, рамочками, выделением цветов и прочей чешуи), то такой разработчик в шоколаде. Если требуется 1 день только на разработку, то такой разработчик будет либо бедным, либо вынужден искать другую работу.

О господи ! Это что за такие зверские сроки ?! Таких даже в США нет. Ну разве что из-боязни упустить каждую копейку

[NTFS]

debi12345

Это что за такие зверские сроки ?!

Нормальные сроки. 10-30 минут на кодирование простой программы типа "возьми отсюда - положи сюда".
Конечно, лично я стараюсь избегать подобных проектов, но иногда приходится.

[alexey38]

О господи ! Это что за такие зверские сроки ?! Таких даже в США нет. Ну разве что из-боязни упустить каждую копейку

Во-первых, США не является эталоном по производительности труда, в России она обычно выше (речь об эффективности разработки).
Во-вторых, а сколько требуется времени на написание программы длиной 10-30 строк + (стандартный шаблон)? Пусть даже 50 строк, при цене в 5 т.р. - это уже 100 руб. (3 бакса) за 1 строку кода. Это очень высокая цена.
Есть проекты объемом в миллионы строк, там при таких ценах были бы миллиардные бюджеты.

Правильно подобранные инструменты и технологии позволяют создавать эффективные решения. Тот же OLE позволяет совместить паскаль и WordBasic, когда прототип кода получаем записью макроса в Ворде, поэтому 10 минут хватает за глаза. И выполняя заказ ценой в 5 т.р. за 4 часа, ты не торопишься, успеваешь раза 2-3 попить чай, побалтать на отвлеченные темы с закаазчиком и с юзерами. Все спокойно, все довольны и счастливы.