Lazarus vs Delphi (embarcadero Community Edition)

Witam,
teraz jedno i drugie (Lazarus i Delphi) do części zastosowań darmowe.
Co lepsze? Jak do tego podchodzić?

darekdarek napisał(a):

Witam,
teraz jedno i drugie (Lazarus i Delphi) do części zastosowań darmowe.
Co lepsze? Jak do tego podchodzić?

Lepsze do czego? Do sterowania choinką na Raspberry Pi czy programowania ERP dla fabryki rowerów?

vpiotr napisał(a):

darekdarek napisał(a):

Witam,
teraz jedno i drugie (Lazarus i Delphi) do części zastosowań darmowe.
Co lepsze? Jak do tego podchodzić?

Lepsze do czego? Do sterowania choinką na Raspberry Pi czy programowania ERP dla fabryki rowerów?

Do programowania ERP dla fabryki rowerów.
Zresztą obojętne - czy jest obszar w którym Lazarus będzie lepszy?

Lazarus jest lepszy w:

• w darmowości (darmowe bez ograniczeń na dochód)
• w działaniu na Linuksie
• w perspektywie długości wsparcia (nie zniknie - masz pełne źródła)

vpiotr napisał(a):

darekdarek napisał(a):

Witam,
teraz jedno i drugie (Lazarus i Delphi) do części zastosowań darmowe.
Co lepsze? Jak do tego podchodzić?

Lepsze do czego? Do sterowania choinką na Raspberry Pi czy programowania ERP dla fabryki rowerów?

Żadne z powyższych.

W Lazarusie jest pełno WTF jeśli chodzi o stabilność. Mniej funkcji niż w Delphi, ale da się pisać i możesz używać komercyjnie. Delphi musisz bulić jak za zboże. Szczerze to odradzał bym, produkty firmy Embarcadero ze względu na licencjonowanie, jakość i wsparcie. Jednak musząc wybierać wybrał bym Delphi.

somedev napisał(a):

W Lazarusie jest pełno WTF jeśli chodzi o stabilność.

Masz na myśli stabilność samego IDE? Chyba nie stabilność programu wynikowego?

To i to. Ide potrafi sie wykrzaczyć, czy błędnie działać, a sam LCL też ma błędy w runtime, szczególnie jak chcesz przenosić kod między środowiskami. Jakieś liby stylu LazSerial, też nie za bardzo sobie radzi zmieniając platforme. Ta dewiza "Write once, compile everywhere" to tylko marketing.

Lazarus potrafi się wysypać w najmniej oczekiwanym momencie, czasem za sprawą absolutnie podstawowych czynności. I to nie że wyskoczy błąd i dana operacja zostanie przerwana – poleci wewnątrz wyjątek, nie zostanie złapany i wyskakuje komunikat AFAIR z przyciskami Continue i Abort. Nieważne co się wybierze, bo kontynuacja oznacza ”wiszenie” zaciętego IDE, a przerwanie jest równoznaczne z ubiciem procesu i utratą danych niezapisanych w danej sesji.

Przedwczoraj mało mnie krew nie zalała, gdy takie błędy dostawałem podczas edycji filtrów w oknie komunikatów. Z jakiegoś powodu IDE utworzyło dwa różne filtry o takim samym ID i przy próbie usunięcia jednego z nich leciał wyjątek, który nie był ubsługiwany. Z poziomu środowiska nic nie dało się zrobić – musiałem ręcznie usuwać te filtry bezpośrednio z plików konfiguracyjnych środowiska.

Inny przykład wyjątku z d**y? Ustawić kursor na wbudowanym identyfikatorze, nie posiadającym deklaracji (np. instrukcji Break) i użyć funkcji Find declaration. W oknie komunikatów pojawi się to:

Codetools, Errors, 1:
Error: EAccessViolation: Access violation

Tyle dobrze, że ten wyjątek środowiska nie wywala i można dalej normalnie pracować.

Takich małych utrudnień jest masa – niektóre całkowicie wykrzaczają IDE, pozostałe co najwyżej wkurzają (nie wpływają na stabilność). Mimo wszystko tego typu niedociągnięć z wersji na wersję jest coraz mniej, więc prace idą w dobrym kierunku i środowisko jest coraz bardziej stabilne. Sam radzę sobie z tym po prostu pamiętając czego nie robić, aby nie wykrzaczyć IDE.

Żeby opisać wszystkie bolączki to trzeba by spory artykuł wysmarować. Sam nauczyłem się pracować z tym środowiskiem, unikać wszelkich problemów i zapamiętywać kolejne napotkane, aby móc ich unikać w przyszłości. Mimo wszystko jestem z niego zadowolony – przynajmniej za nic nie muszę płacić i mam pełen dostęp do źródeł (z paskudnym, niejednolitym formatowaniem, ale co poradzić…).

Natomiast społeczność jest na tyle duża i obeznana, że w przypadku trudniejszych problemów zawsze jest się do kogo zwrócić o pomoc i tę pomoc chętnie i szybko się otrzyma, a wszystkie zgłaszane błędy są rozpatrywane i dość sprawnie łatane w kolejnych trunkach.

Podsumowując – Lazarus to środowisko, w którym bohatersko pokonuje się trudności nieznane w żadnym innym IDE. ;)

furious programming napisał(a):

Inny przykład wyjątku z d**y? Ustawić kursor na wbudowanym identyfikatorze, nie posiadającym deklaracji (np. instrukcji Break) i użyć funkcji Find declaration. W oknie komunikatów pojawi się to:

Kopiuj

Codetools, Errors, 1:
Error: EAccessViolation: Access violation

Tyle dobrze, że ten wyjątek środowiska nie wywala i można dalej normalnie pracować.

Takich małych utrudnień jest masa – niektóre całkowicie wykrzaczają IDE, pozostałe co najwyżej wkurzają (nie wpływają na stabilność). Mimo wszystko tego typu niedociągnięć z wersji na wersję jest coraz mniej, więc prace idą w dobrym kierunku i środowisko jest coraz bardziej stabilne. Sam radzę sobie z tym po prostu pamiętając czego nie robić, aby nie wykrzaczyć IDE.

czy masz gdzieś linki do tych błędów na bugtrackerze? Jeśli nie, to byłoby miło gdybyś je dodał.

@hnb: z chęcią bym zgłosił te błędy, ale nie mogę się zalogować na bugtrackera. Zapomniałem danych do logowania (ostatnio logowałem się z pięć lat temu), a narzędzie do przypominania hasła nie jest mi w stanie pomóc.

Jeśli chodzi o te kilka wymienionych błędów, to ja nie wiem co nich myśleć. Ktoś testuje w ogóle te narzędzia? Bo coś mi się wydaje, że albo nie są one testowane, albo robione jest to po łebkach.

@furious programming:

w takim razie najlepiej założyć nowe konto. Lazarus jest testowany przed każdym wydaniem na kilka tygodni przed. Są wewnętrzne RC przed wydaniem stabilnej wersji i automatyczne testy (niestety testy nie są wstanie wychwycić wszystkiego).

To prawda, że edytor kodu jest czasem zawodny ale jednocześnie jest bardziej zaawansowany niż edytor w Delphi.

Unikając raportowania błędów sytuacja się nie poprawi, często każdy dev Lazarusa ma pewne przećwiczone schematy i ciężko napotkać na błędy, stąd też Twoje testy/odmienny sposób pracy/wyłapane błędy są cenne i warto to raportować.

hnb napisał(a):

w takim razie najlepiej założyć nowe konto.

Nie no wystarczyłoby się odezwać do admina i poprosić o pomoc. Tyle że przymierzam się do kontaktu już od dobrych dwóch lat i jakoś zawsze o tym zapominam, bo mam kupę innych rzeczy na głowie. :/

Lazarus jest testowany przed każdym wydaniem na kilka tygodni przed. Są wewnętrzne RC przed wydaniem stabilnej wersji i automatyczne testy (niestety testy nie są wstanie wychwycić wszystkiego).

Nie wątpię w to, że testy (w postaci kodu) są przeprowadzane, ale czy jest w ekipie tester, który siada, odpala IDE, ładuje jakiś większy projekt i po prostu katuje środowisko? Coś mi się wydaje, że organoleptycznie nikt nie testuje tych narzędzi, bo na sporo niedoróbek/błędów wpada się praktycznie od razu, przy podstawowych czynnościach (jak np. owy Find Declaration).

To prawda, że edytor kodu jest czasem zawodny […]

„Czasem” to delikatne niedomówienie, bo np. praca z okienkiem completion box w połaczeniu z generykami to istna katorga – nie da się używać. Do tego jeszcze te durne pozycje typu text, które nie wiem po co są dodawane, skoro zaśmiecają listę. No ale to nie sam edytor kodu jest winien.

[…] ale jednocześnie jest bardziej zaawansowany niż edytor w Delphi.

Nie wiem, nie używam Delphi, więc nie mam porównania. Co jak co, ale z edytora kodu jestem akurat bardzo zadowolony – masa funkcji, korzystam chyba ze wszystkich.

Unikając raportowania błędów sytuacja się nie poprawi, często każdy dev Lazarusa ma pewne przećwiczone schematy i ciężko napotkać na błędy, stąd też Twoje testy/odmienny sposób pracy/wyłapane błędy są cenne i warto to raportować.

No to raczej oczywiste. Postaram się ogarnąć ten temat, a jeśli bardzo nie będzie mi się chciało to chciaż na forum dam znać, niech to ktoś dorzuci na bugtrackera. Wiele napotkanych problemów już jest zgłoszonych (np. problem z nie znikaniem hintów), więc najpierw muszę sprawdzić czy w ogóle mam co zgłaszać.