Здравствуйте, PeterOfLight, Вы писали:
POL>Вот недавно задавал аналогичный вопрос по Firemonkey из Delphi XE3. POL>Но вот Lazarus. На днях вышла финальная версия 1.0
валится он со страшной силой при отладке.
Re[2]: А почему бы не использовать Lazarus для shareware?
> POL>Вот недавно задавал аналогичный вопрос по Firemonkey из Delphi XE3. > POL>Но вот Lazarus. На днях вышла финальная версия 1.0 > > валится он со страшной силой при отладке.
5 лет если не больше они делали релиз 1.0 и оно все также валится и глючит?
ну окей, подождем еще 5 лет.
Posted via RSDN NNTP Server 2.1 beta
Re: А почему бы не использовать Lazarus для shareware?
Здравствуйте, PeterOfLight, Вы писали:
POL>Вот недавно задавал аналогичный вопрос по Firemonkey из Delphi XE3. POL>Но вот Lazarus. На днях вышла финальная версия 1.0 POL>Идеально для дельфистов чтобы писать shareware. POL>Лично я попробую перенести мой проект с Turbo Delphi на Lazarus.
Имхо, не взлетит.
Я пробовал перевести на Freepascal + Lazarus свой shell extension для контекстного меню Windows Explorer, ибо срочно понадобиласть 64-битность. Там одна DLL, минимум UI из VCL, ничего особенного.
В общем, терпение мое лопнуло уже на этапе портирование кода Delphi -> Freepascal. То каких-то пропертей нет в TImageList, то где-то у методов не та видимость, то их параметры не так объявлены, то другое, то третье. Ну, то есть можно было бы помучиться и таки портировать проект посредством копи-пасте недостающего кода из VCL и кучи $IFDEF, и добиться компилирования этого кода.
И тогда мне подумалось: если даже с портированием такие проблемы, то как это все будет работать, если будет вообще? А в 64-х битах? А тащить две версии своих собственных библиотек для Delphi и FPC? И как это все поддерживать?
И плюнул я и переписал все на VC++.
Короче говоря, я сильно пожалел, что изначально не стал делать проект на VC++. В итоге, при всем моем почтении и многолетней приверженности Pascal и Delphi, я перестал ими пользоваться. Совсем перестал.
Delphi, несмотря на все свои замечательные плюшки для программистов, просто не успевает за изменениями в технологиях ведущих компаний. Имхо единственный путь для них — это продаться или плотно партнерствовать с кем-то типа гугла или эппла. Т.е. чтобы Delphi был официальным инструментом разработки под одну из платформ. И если для Delphi еще можно хотя бы представить такую перспективу, то о перспективах FPC+Lazarus смешно даже думать.
Не мучайтесь, пользуйтесь мейнстримовыми инструментами ведущих производителей хотя бы в своих новых проектах.
Такое вот вам мое категорическое imho
Re[3]: А почему бы не использовать Lazarus для shareware?
Здравствуйте, qwertyop, Вы писали:
>> валится он со страшной силой при отладке. Q>5 лет если не больше они делали релиз 1.0 и оно все также валится и глючит? Q>ну окей, подождем еще 5 лет.
не, ну по сравнению с предыдущими версиями все стало лучше, но writeln все еще наш лучший друг при реальной отладке
Re[2]: А почему бы не использовать Lazarus для shareware?
На самом деле мы используем Lazarus в нашем продукте. Одна программа (точнее клиентская часть большого продукта) сделана для Mac и скомпилирована в Lazarus. Уже три года. Глюков нет (кроме редких наших багов, которые фиксились).
Теперь думаем перевести весь продукт на Lazarus чтобы получить полную кросс-платформенность — Windows и Mac.
Delphi мне нравится быстрой компиляцией. EXE'шники компактные и работают ВЕЗДЕ на любой Windows без необходимости тащить какие-то рантаймы или доустанавливать .Net Framework'и. Еще нравится строгость языка, деление на модули, что очень повышает качество кода. Ну и конечно большой опыт работы на Delphi. Я привык к языку Delphi/Pascal. Моя эффективность явно снизиться при переходе на другой язык из-за необходимости переучиваться + потеря наработанных исходников и библиотек.
У нашего продукта несколько конкурентов, один из них тоже на Delphi. И наш продукт и у конкурентов — это серьезные программы — результат многих лет работы далеко не одного человека. Нет никакого желания переносить это на другой язык.
Возможно вы удивитесь, но уже три года отказались от сторонних компонентов (кроме базовых из Delphi). Нас не устраивают возможности чужих контролов которые требовались под наше приложение, плюс чужие баги, не хотелось зависеть качества чужого кода. Да и в основном нужны уникальные контролы специфичные только для нашего продукта — все пришлось писать самим.
Также контролы никогда не устанавливаем визуально. Все свои контролы создаются в рантайме. Да, это замедляет слегка разработку, но зато полный контроль над исходниками — не надо ничего переустанавливать когда один программист что-то изменил в исходниках контролов. Также я могу скомпилировать апдейт к предыдущей версии продукта со старой версией контролов, просто быстро распаковав нужный архив исходников.
Продукт у нас успешный, на рынке скоро 14 лет. В компании работает 9 человек.
Re: А почему бы не использовать Lazarus для shareware?
Здравствуйте, PeterOfLight, Вы писали: POL>Но вот Lazarus. На днях вышла финальная версия 1.0
Размер экзешника — это капец. Пока хватает Turbo Delphi нафик, а если переходить то VC++.
64 бита да есть, пробовал сделать dll-ку хукать 64-битные процессы — как только она не глючила. Дело закончилось VC++.
Кросс платформенный опять же да, но чтоб скомпилить под линукс из винды нужно станцевать не один неестественный танец. Code Typhoon упрощает, но до простоты далеко.
Re[2]: А почему бы не использовать Lazarus для shareware?
Если исключить debug информацию, то EXE будет сравнительно небольшим — около 2 MB. Конечно в Turbo Delphi еще меньше, но просто видимо Lazarus больше цепляет всяких библиотек из LCL. В конечном приложении размер будет почти одинаковым. Наш APP под Mac получился похожим по размеру на Windows версию.
Кстати в новом Delphu XE3 EXE файл уже от 10 (VCL) до 20 MB (Firemonkey) в пустом приложении (окно и кнопка).
Re: А почему бы не использовать Lazarus для shareware?
Есть еще C++ Builder. Кажется что его и не использует никто почти. Хотя преимуществ вагон — все прелести дельфи в плане быстрой разарботки интерфейса плюс C++ и stl. Интерфейс VCL, ядро C++. Ядро кросс-платформенное, Windows, Mac, iOS, Android — везде нативный интерфейс и родная среда разработки, а ядро общее. Красота.
A>Есть еще C++ Builder. Кажется что его и не использует никто почти. Хотя преимуществ вагон — все прелести дельфи в плане быстрой разарботки интерфейса плюс C++ и stl. Интерфейс VCL, ядро C++. Ядро кросс-платформенное, Windows, Mac, iOS, Android — везде нативный интерфейс и родная среда разработки, а ядро общее. Красота.
Покажи мне файл сделанный Билдером под iOS и Android интересно поглядеть.
Здравствуйте, KARPOLAN, Вы писали:
A>>Есть еще C++ Builder. Кажется что его и не использует никто почти. Хотя преимуществ вагон — все прелести дельфи в плане быстрой разарботки интерфейса плюс C++ и stl. Интерфейс VCL, ядро C++. Ядро кросс-платформенное, Windows, Mac, iOS, Android — везде нативный интерфейс и родная среда разработки, а ядро общее. Красота.
KAR>Покажи мне файл сделанный Билдером под iOS и Android интересно поглядеть.
Логика на сях, а интерфейс делается в "родном" для платформы иде, т.е. XCode для ios и MacOS, Билдер (раз уж так хочется дельфей) или VC для винды. Что там с андроидом и линуксов пока не в курсе, но по слухам тоже все ок. ВинФон вроде тоже одумался и поддержка натива будет.
Один хрен универсальный кросс-платформенный интерфейс это что-то из области фантастики. Если раньше, до эпохи планшеток и тач-скринов, еще как то можно было извратиться, то теперь об этом не стоит и заикаться.
A>>>Есть еще C++ Builder. Кажется что его и не использует никто почти. Хотя преимуществ вагон — все прелести дельфи в плане быстрой разарботки интерфейса плюс C++ и stl. Интерфейс VCL, ядро C++. Ядро кросс-платформенное, Windows, Mac, iOS, Android — везде нативный интерфейс и родная среда разработки, а ядро общее. Красота.
KAR>>Покажи мне файл сделанный Билдером под iOS и Android интересно поглядеть.
A>Логика на сях, а интерфейс делается в "родном" для платформы иде, т.е. XCode для ios и MacOS, Билдер (раз уж так хочется дельфей) или VC для винды. Что там с андроидом и линуксов пока не в курсе, но по слухам тоже все ок. ВинФон вроде тоже одумался и поддержка натива будет.
Ясно, значит ты обычный теоретег... А я то думал счастье рядом
Здравствуйте, PeterOfLight, Вы писали:
POL>Возможно вы удивитесь, но уже три года отказались от сторонних компонентов (кроме базовых из Delphi). Нас не устраивают возможности чужих контролов которые требовались под наше приложение, плюс чужие баги, не хотелось зависеть качества чужого кода. Да и в основном нужны уникальные контролы специфичные только для нашего продукта — все пришлось писать самим.
Золотые слова!
На самом деле, имхо, самый большой шанс Lazarus-а на завоевание какой-то доли рынка связан как раз с тем, что может сформироваться какая-то культура библиотек и компонентов для него. Для Delphi это всё было не очень хорошо.
