Lazarus vs Delphi (embarcadero Community Edition)

0

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

2
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?

0
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?

3

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)
0
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.

1

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.

0
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?

2

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.

4

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. ;)

0
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:

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ł.

0

@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.

0

@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ć.

0
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ć.

1

Kolejny bubel znaleziony przypadkowo.

Opcja Export as HTML z menu File jedynie połowicznie wspiera schemat kolorów edytora kodu. Sam mam tło edytora jako prawie czarne, keywordy białe, dyrektywy i komentarze jasnoszare i identyfikatory średnio-szare. Natomiast w wyeksportowanym dokumencie, kolory tekstu są takie same jak w edytorze, ale tło dokumentu jest zawsze białe…

Wyeksportowany kod wygląda po otwarciu w przeglądarce tak:

shitty code.png

a powinien wyglądać tak (zmieniłem tylko kolor tła, za pomocą narzędzi deweloperskich w przeglądarce):

good code.png

To już nawet nie chodzi o to, że to narzędzie nie zostało porządnie przetestowane, w tym manualnie sprawdzone wyniki dla różnych ustawień (bo nie zostały), ale ktoś kto je pisał chyba robił robotę ”na odpitol”, byle jakieś tam było. No bo jak można było pomyśleć o wsparciu kolorów edytora, jednocześnie nie myśląc o kolorze jego tła…? :/

Albo wspieramy kolorystykę edytora w całości, ale w ogóle i używamy jakiejś predefiniowanej palety.


Tak swoją drogą to opcja ta jest dość biedna (pomijając bug związany ze statycznym kolorem tła).

Fajnie by było, gdyby oprócz samego kodu, do dokumentu trafiło także numerowanie linii – nie jest to zbyt trudne do zrobienia. Można by się też zastanowić nad breakpointami. Natomiast jeśli o kolorystykę chodzi, to super by było, gdyby kod opatrzony nieaktywnymi dyrektywami (jak w przykładzie który podałem, kod w sekcjach $IFNDEF WINDOWS) był tak samo kolorowany jak w edytorze (u mnie: ciemniejszymi literami):

editor code.png

I fajnie by też było, gdyby dało się wyeksportować tylko zaznaczone linie aktywnego dokumentu, a nie całego modułu. A jeśli mowa o całych modułach, to dobrze by było wyeksportować wszystkie (wszystkie projektu, wszystkie otware w edytorach lub w wybranym edytorze).

Poza tym przydałby się jakieś pośrednie okienko dialogowe z możliwością wyboru nazwy docelowego pliku, a także kilku podstawowych opcji (wybór schematu kolorów, elementów edytora i kodu itd.) oraz podgląd ”wydruku”, tak aby przed zapisem było wiadomo jak kod będzie wyglądać. Całość najlepiej w formie prostego kreatora, na kształt instalatorów. Zwykły SaveDialog to stanowczo za mało.

Dlaczego nikt o tym nie pomyślał? Nie mam pojęcia…

1 użytkowników online, w tym zalogowanych: 0, gości: 1