Новый Большой проект на FPC - стоит ли рискнуть?

[petrovv]

Да стоит, смелее, будет все хорошо, придут опыт и удовлетворение от сделанной работы. Если прижмет, можно будет написать библиотеки на чем нибудь другом и подцепить их.

[FedeX]

А что смущает в Паскале? Чем он не пригоден для большого проекта?
У него глючный выходной код? - НЕТ.
Лазарус неудобен в написании и требует больше усилий чем Ява? - НЕТ.
Недостаток компонентов? - НЕТ.
Засмеют ява-программисты? -ДА, но посоревнуйтесь с ними на небольшом проекте и будете смеяться Вы.

>У него глючный выходной код? - НЕТ.
Может сейчас уже лучше, но раньше помню много настрадался когда пытался подключить к проекту две динамические библы написанные на FPC - оказалось баг компилятора FPC, и ещё что-то было уже не помню тоже с багами компилятора связанное..
>Лазарус неудобен в написании и требует больше усилий чем Ява? - НЕТ.
Лазарус удобен, но до Эклипса/Нетбинса/Идеи ему всеже далеко. Требует больше усилий? - скажу по опыту отладка многопоточного сетевого приложения для FPC и Java это как земля и небо.
>Недостаток компонентов? - НЕТ.
По сравнению с ява - ДА. А особенно стабильных проверенных временем компонентов - много ДА
>Засмеют ява-программисты? -ДА
Ява программисты сами непрочь пописать на Паскале когда это уместно, но в данном случае это так же уместно как писать ICQ клиент на ассемблере (я бы не отказался от такого, если бы он работал быстро и ел мало памяти, но трудозатраты...).

ПС.: у меня сейчас проект на С++, и я бы все отдал за возможность писать его на Паскале (ни в коем случае ни на яве!), но под платформы/фреймворк которые мы используем это к сожалению почти невозможно (Android, Iphone, Airplay SDK)

[NTFS]

Как обычно, мнения разделились

Меня в первую очередь смущает возможность поймать именно глючную компиляцию большого кода.
Вопрос ко всем: разработчики FreePascal принимают заказы на исправление/доработку, подкрепленные тугриками?
Если да, то я буду готов немного проплачивать, чтобы обнаруженные мной проблемы исправляли в разумные сроки.

Добавлено спустя 5 минут 53 секунды:
Помимо уже указанных выше проблем с dll, я периодически натыкался на падение программы без Exception (в дельфи аналогичный код давал обычное исключение), конкретные приходы при работе с ассемблерными вставками, интересное поведение при нехватке кучи.... много еще чего.
Так как компилятор бесплатный (и по факту - единственный нормальный для работы с Паскалем на Linux), то с этим спокойно мирился. Но сейчас начинается конкретно дрожь в руках...

[Ism]

Код: Выделить всё

Дебет Плюс

Большего кошмара я не встречал. В смысле тормозов и поедания ресурсов.


И кто мешает писать совместно ? Для чего какой инструмент подходит. Клиентские части например писать на Lazarus (Можно будет легко перенести в Linux)

Вообще у меня опыта больших проектов нет, но думаю все зависит от прямизны рук программистов , а не среды разработки.

[WAYFARER]

В смысле тормозов и поедания ресурсов.

ага, есть такое, при использовании derby, а с PostgreSQL или Oracle вполне нормально).

я периодически натыкался на падение программы без Exception

Если использовать с++ ошибок будет на порядок больше, все исключения так же придется обрабатывать самому...

конкретные приходы при работе с ассемблерными вставкам

А так ли они нужны?

[NTFS]

>Если использовать с++ ошибок будет на порядок больше, все исключения так же придется обрабатывать самому.

Вы не поняли - у меня бывало, что программа на FPC при выполнении неверной операции (условно, деление на ноль) вместо генерации Exception просто завершала работу. Это было очень неудобно - приходилось вставлять кучу отладочного кода.
Полагаю, что в компиляторах C++ или Java такой проблемы нет.

[Mr.Smart]

NTFS данная проблема возникает при использовании dll т.к. не реализован (на сколько я знаю) отлов эксепшенов из неё в основной программе.

[NTFS]

Т.е., если я вызываю dll из приложения и в dll происходит необработанное исключение - программа его не увидит и молча упадет?

[Mr.Smart]

В большинстве случаев. Т.ч. пишите правильные библиотеки

Добавлено спустя 1 минуту 4 секунды:
Хотя помнится на нашем форуме это обсуждалось и даже было найдено решение. Поиск поможет.

[.wOvAN]

А что смущает в Паскале? Чем он не пригоден для большого проекта?
У него глючный выходной код? - НЕТ.

Да, глюков и недоработок очень много + исправления на багтрекере проталкивать не очень просто.

Недостаток компонентов? - НЕТ.

Да, особенно в качественных.

[coyot.rush]

KOL
Поддерживаются Delphi2, Delph3, Delphi4, Delphi5, Delphi6, Delphi7, BDS 2005-2009, Kylix а так же Free Pascal Compiler 1.0.5 и выше. Библиотека KOL позволяет разрабатывать чрезвычайно компактные GUI-приложения для Windows (начиная с приблизительно 14К без сжатия - при условии использования предлагаемой замены системных модулей system, sysinit и др.)
К библиотеке прилагается генератор справки (xHelpGen), создающий подробную документацию по библиотеке в html-формате. Справка формируется на основе комментариев в исходных текстах, так что разработчики всегда имеют доступ к самой свежей и полной документации.
Предоставляется также библиотека зеркальных классов MCK (Mirror Classes Kit), обеспечивающая возможность визуальной разработки проектов на базе объектов KOL.

Дополнительные модули и компоненты KOL&MCK http://kolmck.net/r_adds.htm
KOL-CE/ru http://wiki.lazarus.freepascal.org/KOL-CE/ru

[Logo]

Ясно.
Пишите в Делфи.

Цитата дня:
Лазарус удобен, но до Эклипса/Нетбинса/Идеи ему всеже далеко.

[alexs]

Лазарус удобен, но до Эклипса/Нетбинса/Идеи ему всеже далеко

Может просто вы привыкли к этим IDE?
Мна очень тяжко работать в нетбине - ну не похож он на нормальный RAD IDE.

[Андрей Варкентин]

Лазарус удобен, но до Эклипса/Нетбинса/Идеи ему всеже далеко

Может просто вы привыкли к этим IDE?
Мна очень тяжко работать в нетбине - ну не похож он на нормальный RAD IDE.

+100500
Eclipse, NetBeans для меня не авторитет Если говорить о разработке клиентских ГУИ-приложений однозначно Delphi\Lazarus. Если пишем голую логику, тут как бы вариантов больше. Но есть одно золотое правило, писать проще на том языке, которым лучше владеешь. И для себя сделал выводы, что главное не сам язык, а обвязка (юниты, библиотеки, компоненты, среда разработки). Если знаешь язык и для него существует вся требуемая инфраструктура - смело кидаемся в бой. Немного противоречиво, но правда

ЗЫ для пользовательских GUI-приложений использую Лазарус, для Python/PHP - Komodo Edit 6.

[debi12345]

На паскале нахлебаешься программировать групповую работу с базой. Держать целостность данных при падении программы просто жесть. Разделение доступа...

А зачем это программировать? Использовать любую нормальную СУБД. Например, Firebird...

Ага, точно ВрЕменные таблицы, одноименные для всех коннектов, но каждая - со своими данными внутри коннекта.
Блокировки таблиц, сбрасываемые на транзакциях. Однако нумераторы независимы от транзакций.
Именованные сэйвпойнты. То есть все, что нужно для разруливания проблем на уровне БД.