freepascal.ru

Сорян за философский и холиварный вопрос. Стоит ли в 2019 рассматривать Lazarus как приемлимый инструмент для написания всякого учетного софта (склад, биллинг и т.п.) для психа-одиночки с мотором? Или не мучиться и сразу засесть за новый MS Net Core 3.0 с его WPF?


Вводные такие:
- я из программирования ушел 10 лет назад, но поддерживаю старый проект (склад, MSSQL, интерфейс на Visual Foxpro). Вроде пора на что-то переползать, но все не соберусь.

- FPC не знаю, просто почитываю ваш сайт.

- мне актуальна только OS Windows.

- Firebird уважаю, особенно за наличие Embedded версии, в MSSQL мне ее не хватает, даже решился попробовать перейти на него, т.к. MSSQL Express ставится по полчаса, а мне обычно работа в сети не нужна, только 1 юзер. Но бывает и 2-3.

- пугает в Лазарусе и FPC отсутствие сборщика мусора. Это сильный гемор для CRUD приложения ?

- в Net (я его тоже суко не знаю, но слышал:) есть LINQ - аналог фоксовского способа херачить SQL- обработку таблиц прямо в коде. С датасетами поработал в VBA (из Access)- бледное подобие правой руки (Фокса). Боюсь, в FPC тоже самое.

- Приложения WPF не зависят от разрешения экрана, это очень круто. Я так прнимаю, ответа на этот вопрос у сообщества FPC пока нет? Есть у меня пару проектов 20-летней давности под разрешение 800х600, а у юзеров уже мониторы Full HD. Жуткое зрелище.

- Безусловный бонус FPC+Lazarus - реальная и понятная бесплатность. У MS все мутно, но вроде Community edition бесплатна для мелких разрабов.

- Строки вроде в VFP геморойные. Когда считаешь деньги и килограмы, отвлекаться на осталное как бы и не хочется.

В общем, простите за сумбур, прошу высказываться.

Как раз его и стоит использовать для нормальной разработчки систем учёта с применением СУБД. Для рисования всяких морд к СУБД подходит лучше всего.
1. MS SQL поддерживается. Клиентские приложения могут быть как виндовые так и линуховые. Хотя я сам с этой СУБД связываться больше не хочу.
2. Паскаль в FPC хорош. Причём проблем с обратной совместимостью нет. Ну и изучить его не сложно.
3. Клиенты под винду не чем не отличаются от клиентов под другие платформы (ну если только не задаваться целью специально)
4. Для работы с FireBird куча способов (библиотек).
5. А в чём проблема со сборщиком? Для многих случаев в лазаре даже код писать не надо. Главное запросы к СУБД построить верно. Ну и главное правило не стоит забывать - если ты породил объект - то ты его должен и убить:

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

aaa:=TAaa.create;
try
твои обработки
finally
  FreeAndNil(aaa);
end

6. Тут вообще идеалогия другая - твои запросы - это компонненты. Не надо их размазывать в код. Сопровождение гораздо легче.
Т.е. на форму/дата модуле лежит запрос - а в коде только

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

Query.Execute;

И запросы отделены от визуального представления данных из них.
7. Автомасштабирование интерфейса уже года 2 как есть. Главное - на забудь нарисовать изображения кнопок для масштабов 150% и 200%.
8. А ещё - можешь сам присоединиться к разработке ...
9. Ну в паскале строгая типизиация типов - просто так строку не сложишь с килограммом. Или ты не про это?

alexs писал(а): Ну в паскале строгая типизиация типов - просто так строку не сложишь с килограммом.

Ну это "просто так" не сложишь, а вообще есть всевозможные "варианты", есть переменные без типа, есть приколы вроде Т1(@T2^), которые полностью развязывают руки даже для "глубоко несовместимых" типов, да много чего есть например сравнительно недавно, открыл для себя ключ {$POINTERMATH ON} ( арифметика указателей) и.т.д. Но факт в том, что в отличии от Си++ паскаль подобные фокусы НЕ ПООЩРЯЕТ "по умолчанию" .... а так в FPC есть даже любимые "насильниками" операторы "++" и "--" и еще много чего из "мира Си"...

Но главный ПЛЮС паскаля в почти полной однозначности всех конструкций языка ... а то в том же Си++ символ "*"(звездочка) это и умножить и признак указателя и еще "черт знает что и сбоку бантик" в зависимости от контекста ...

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

Снег Север писал(а):Alex2013, вообще-то есть куда более удобная вещь - variant переменные. И именно они широко используются в недрах всяких датасетов.

Я про variant написал в первую очередь (просто это настолько очевидно, что разжевывать до "состояния манной каши" было бы уже чезчур неуважительно по отношению к ТС )
Зы
Извиняюсь за опечатки! Видимо вчера меня уже "два известных японских супергероя по-имени ЗеВота и ДреМота" одолевали...

Lazarus мне ценен тем что он действительно полостью бесплатный из всех существующих быстрых систем разработок (Delphi/Visual Studio/Qt - все они хотят денег и стоят как авто, разве что Eclipse IDE полностью свободный). С богатыми контролами, особенно в сфере баз данных.
Когда работаешь в одиночку и взрослые дяди требуют выполнения копирайта - это очень важно.

Если нужно делать большое - Big проджект с концами Web - то Lazarus тут очень слабый. C Java/C# легче будет.

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

Sergej_S писал(а):пугает в Лазарусе и FPC отсутствие сборщика мусора. Это сильный гемор для CRUD приложения ?

"Сборщик мусора" актуальный в виртуальных машинах, где твой код работает не напрямую с операционной системой. Какой-нибудь простое предложение легко может скушать гигабайты памяти. Пример Android Studio (Java) - только при 8гб можно продолжительно работать.

FreePascal работает напрямую с системой.

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

Sergej_S писал(а): есть LINQ - аналог фоксовского способа херачить SQL- обработку таблиц прямо в коде. С датасетами поработал в VBA (из Access)- бледное подобие правой руки (Фокса). Боюсь, в FPC тоже самое.

LINQ это не с нуля придуманный механизм работы с базой данных. и от DataSet никуда не ушли.
Он базируется на на DataSet, только синтаксис внедрен в компилятор. И компилятор сам расписывает работу с Dataset

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

Sergej_S писал(а):Безусловный бонус FPC+Lazarus - реальная и понятная бесплатность. У MS все мутно, но вроде Community edition бесплатна для мелких разрабов.

Сейчас политика MS - вскормить толпу программистов на своих продуктов. В свое время они проспали Java, которая плотно засела в корпоративном сегменте, и эру мобилок Google/Apple.
Но сейчас у них есть сильные решения, даже в сфере без операционных систем(Arduino/STM). Идет захват сфер связанных с Linux.
Им не хватает программистов.

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

Alex2013 писал(а):Но главный ПЛЮС паскаля в почти полной однозначности всех конструкций языка ... а то в том же Си++ символ "*"(звездочка) это и умножить и признак указателя и еще "черт знает что и сбоку бантик" в зависимости от контекста ...

сейчас в gcc компилятор сильно будет возмущается что нет явного приведения типов. метит места как ошибки.

У Delphi сейчас тоже есть Community edition.

olegy123 писал(а):сейчас в gcc компилятор сильно будет возмущается что нет явного приведения типов. метит места как ошибки.

Кстати, gcc, в отличие от прошлых времён, сейчас даёт довольно внятное описание ошибки. И поскольку описание сильно совпадает с clang'овским, я думаю, что они его оттуда и позаимствовали...

olegy123 и всем спасибо за полезные замечания.

Снег Север писал(а):У Delphi сейчас тоже есть Community edition.

5000$ лимит по прибыли. ИМХО, NET Core Community заманчивее для новых разработчиков (тут лимит 5 программеров).

alexs писал(а):9. Ну в паскале строгая типизиация типов - просто так строку не сложишь с килограммом. Или ты не про это?

Строгая типизиация меня не пугает, м.б. это даже лучше. Я про utf-8 с ее полтора байтами на символ, я только с ASCII работал.

alexs писал(а):6. Тут вообще идеология другая - твои запросы - это компонненты. Не надо их размазывать в код. Сопровождение гораздо легче. Т.е. на форму/дата модуле лежит запрос - а в коде только Query.Execute

Для гридов и отчетов - не спорю, это может и удобно. А для больших расчетов? Делал как-то давно начисление жителям по теплосчетчикам - там было тыщи на 2 строк хитровыделанных расчетов. Писать эти начисления TSQL я не отважился по ряду причин, в основном из-за невозможности пошагово дебажить и менее удобной работы с курсорами SQLa по сравнению с их аналогами в фоксе. Знаю, считать на клинте считается некошерно. Что скажите? Или все-таки такие расчеты надо писать на SQLe?


P.S. Я пока планирую базу перевести с MSSQL Express на Firebird, интерфейс временно фоксовский оставлю, т.к. изучение Лазаря в свободное от работы время затянется надолго. Расскажите плиз про ключевые поля. В mssql все они у меня GUID типа, в FB тоже есть его аналог - UUID. Но, насколько я понял, родной механизм FB - автоинкриментные числовые поля. Будут ли у меня проблемы с UUID, когда я клиента перепишу на Лазаре? Например, компоненты RxLib и другие работают с ними? Кто-то из вас использует UUID?

Sergej_S, с ключевыми полями работают датасеты, а не средства отображения данных. А датасеты используют драйверы и штатные средства сервера баз данных. Правильно организовали таблицы в базе, правильно составили SQL запросы, вам правильно результат и отобразится.

Sergej_S писал(а):Расскажите плиз про ключевые поля. В mssql все они у меня GUID типа, в FB тоже есть его аналог - UUID. Но, насколько я понял, родной механизм FB - автоинкриментные числовые поля. Будут ли у меня проблемы с UUID, когда я клиента перепишу на Лазаре? Например, компоненты RxLib и другие работают с ними? Кто-то из вас использует UUID?

Разницы особой нет. UUID также генерируются в триггерах, как и smallint/integer/bigint. Но ... поскольку автоинкрементные поля используются в качестве суррогатных ключей (первичных и вторичных/ссылочных), то они должны быть уникальными. В случае smallint/integer/bigint это гарантируется в пределах диапазона типа, а UUID-тип теоретически имеет возможность повториться, тогда получишь коллизию.

Я UUID использую в качестве доп.поля записи в основном для репликации, когда надо отличить одну запись от другой, у которых значения неск. полей совпадают.

Sergej_S писал(а):Я про utf-8 с ее полтора байтами на символ, я только с ASCII работал.

Вообще не проблема. Одычные операции со строками без тизменения. Для посимвольной - UTF8Pos, UTF8Copy, UTF8Delete.

Sergej_S писал(а):Делал как-то давно начисление жителям по теплосчетчикам - там было тыщи на 2 строк хитровыделанных расчетов

Я в таком же проекте эту логику вообще вынес на сервер - делал расчёты по начислению на хранимых процедурах. Наиболее оптимальное быстродействие было.
Но и если на клиента тянуть данные - то тоже проблем нет. Только трафик бешеный получается. Поэтому в итоге я переписал.

Sergej_S писал(а):Будут ли у меня проблемы с UUID, когда я клиента перепишу на Лазаре? Например, компоненты RxLib и другие работают с ними? Кто-то из вас использует UUID?

GUID/UUID не несёт смысловой нагрузки для пользователя - поэтому его не надо отображать. А так - по факту это обычная строка в большинстве наборов данных. Какая может быть проблема с ней?
Но вообще - для PK надо использовать автоинкременты. Они гарантируются сервером уникальными в отличии от GUID.

У .net нет и близко того что есть из наследия Delphi т.е. в Lazarus. Нет нормальных DataSource (в .Net), там только какой то убогий биндинг, еще более ублгие таблицы, к котором непонятно как прикрутить убогий же биндинг. А если хочется ещё и менять данные в полях ввода, то ПРОПАЛО! Короче Лазарь это то что Вам нужно.
У меня на нём вот такое https://github.com/Tango600/dcl5, и много чего написано и вот опять пишу систему аналитики.

Tango
Топикстартер 2,5 года ждал твоего ответа. Вот теперь он сможет спокойно приступить к работе

Ждал 2.5, но придется еще 2 года подождать, пока учебу закончу (в совсем другой сфере и на старости лет - поэтому не до хобби). Зато потом как начну говнокодить, ух.
Старые проекты все также на фоксе поддерживаю, но за Лазарусом периодически поглядываю.