Pascal - po co to komu? 9 pytań i stwierdzeń

pomimo że kilkakrotnie im przypomniano że nikt tu o żadnych bazach danych nie mówi.

W tym sęk. Szukasz nie rozwiązania, lecz problemu.

Nie wiem czy śmiać się czy płakać nad wami

Zależy. Jeśli piszesz dramat to płacz, komedię śmiej, a jeśli jesteś zaczepny z natury to zagospodaruj lepiej swój czas.

I jedno. Słabo czytasz. Nie jestem programistą delphi, a moja styczność z tym językiem nie była duża. Nie uważam delphi za coś, w czym zleciłbym nowy projekt.

Delphi od początku miało być wyrocznią komunikującą się z bazami danych, więc jakiekolwiek ich przetwarzanie w delphi bez nich wygląda tak, jakbyś w c# pisał bez stdliba. Ale czy to coś złego? Niekoniecznie, bo masowe dane powinny siedzieć... w bazie.

Szczery Jacek napisał(a):

Ja też nic nie mam do pascala ani delphi, ale już ten jeden przykład pokazuje, że delphi dalej tkwi głęboko zakorzenione w filozofii z lat 90 ubiegłego wieku. Takich kwiatków jak usuwanie bezpośrednie linii z textboxa jest na pewno więcej, a w dzisiejszych czasach stanowią one przykład jak nie należy pisać kodu.

No i potwierdziło się, że klepacze pascalowi w ogóle nic nie wiedzą o dobrych praktykach i wzorcach w programowaniu, jak jeden z drugim zobaczył słowo "select" to upiera się, że to jakieś głupoty bo "to robota komponentu bazy danych jest", pomimo że kilkakrotnie im przypomniano że nikt tu o żadnych bazach danych nie mówi.

Mogłem się nad wami jeszcze bardziej poznęcać i podać naprawdę skomplikowane zapytanie linq, z kilku kolekcji, gdzie analogiczny kod w delphi rozrósłby się do 100 linii zamiast jednej. No cóż, niepotrzebny " lukier składniowy' a implementacja to rzecz do pominięcia.

Nie wiem czy śmiać się czy płakać nad wami.

Tak się składa, że kolekcja jest swojego rodzaju bazą danych. Kwestia podejścia do problemu jest różna i zazwyczaj nie ma jedynie słusznej.

Dodatkowo nie wiem, po co mieszasz wzorce projektowe do tego, to, że w kontrolce mogę w odpowiedni sposób zmienić dane nie ma nic do wzorców projektowych. Dane od części wizualnej mogą byc oddzielone, ale nie pomyślałeś o jednym, aktualizacja przetrzymywanych nie musi następować wraz ze zmianą w widoku. W widoku zmieniaj danej jak chcesz, na koniec pozostaw dane bez zmian, lub zmień, wedle tego co zostało zmienione w widoku. Część widokową masz odseparowaną od rzeczywistych danych - dane robocze zawsze potrzebujesz mieć. Jeśli masz gotowy komponent, który ułatwi Tobie obróbkę danych, uważasz za coś złego, to nie bardzo rozumiem ułatwienia w zapisie, których się domagasz, bo one wg Ciebie sa czytelne. Jedne ułatwienia sa dobre, inne sa fuj? I nie nie jestem jakimś entuzjastom pascalowym, jest to jeden z kilku języków programowania używanych w pracy. Po prostu narzędzie jak każde inne nadające się do pewnych celów.

Tak jak napisał somekind - bezpośrednie manipulowanie danymi w kontrolce to błąd. Od tego się już odchodzi. Jest DataBinding, adaptery itd. Której części nie rozumiesz?

Co do kolekcji i baz danych. Pytanie było o filtrowanie listy obiektów a wy ciągle linkujecie mi jakieś operacje które realizują zapytania do bazy danych. Wtf? Przyznajcie po prostu że delphi nie dorobił się niczego analogicznego do linq i tyle. Duma nie pozwala czy co?

Szczery Jacek napisał(a):

Przyznajcie po prostu że delphi nie dorobił się niczego analogicznego do linq i tyle. Duma nie pozwala czy co?

DELPHI NIE MA LINQ ani niczego podobnego. Czy to wg ciebie skreśla język jako taki?

BTW czy np. w c++ jest linq lub coś podobnego?

Przecież przetłumaczyć na Delphi sporny kod to żaden problem. Można do tego wykorzystać nieznacznie przerobiony EasyLINQ http://www.alien.at/?p=333 trzeba dodać obsługę właściwości Length z tego co parzyłem dałoby się bez problemu (a może nawet istnieje inna implementacja już mająca to w sobie) i kod nie byłby dłuższy (może o ze 2-3 linijki przez deklarację zmiennych w bloku var) od wspomnianego kodu w C# i co na to @Szczery Jacek ?

Szczery Jacek napisał(a):

No i potwierdziło się, że klepacze pascalowi w ogóle nic nie wiedzą o dobrych praktykach i wzorcach w programowaniu, jak jeden z drugim zobaczył słowo "select" to upiera się, że to jakieś głupoty bo "to robota komponentu bazy danych jest", pomimo że kilkakrotnie im przypomniano że nikt tu o żadnych bazach danych nie mówi.

A skąd wiesz że nic nie wiedzą? Myślisz że w DELPHI nie da się zastosować dobrych praktyk i wzorców projektowych? No to masz tu przykład:

http://www.danieleteti.it/a-simple-start-with-mvp-in-delphi-for-win32-part-1/

I można sobie implementować więcej tego a i z pewnością coś na wzór ArrayAdaptera pod Androida do ListView też pewnie dałoby się coś takiego zaimplementować w DELPHI, biorąc pod uwagę np. zachowanie DBGrid przy połączeniu z datasource i automatyczne uaktualnianie widoku przy odczycie danych z baz.

No ok można, można szkoda tylko że dziś już mało kogo interesuje co można (na siłę) w martwej technologii. Sorry, czaz przyjąć prawdę na klatę zamiast walić focha w każdym poście.

Hmm... Może czas w końcu przyjąć na klatę, że Delphi i Free Pascal jako najpopularniejsze dialekty Pascala nie są martwe i jeszcze długo nie będą?

A skąd wiem... może stąd:

Patryk27 napisał(a):

P.S. jaki jest odpowiednik w pascalu tego kodu w c#?(...)

Wykorzystanie komponentu do baz danych, np. MySQL? :|

Widać wyraźnie jak to programiści delphi są na czasie z nowymi technologiami. Wiem, że po tym gdy zadałem wam temat rozpoczęło się rozpaczliwe szukanie czy ktoś w pascalu nie zaimplementował jakiejś protezy linq (po tym gdy wikipedia powiedziała co to jest), ale bądżmy szczerzy - masturbatorzy delphi nawet z reguły nie wiedzą co to.

Nie chodzi zresztą o linq, chodzi o zasadę, mogę jeszcze i z 10 podobnych rzeczy wam wyszukać. I rezultat będzie ten sam

furious programming napisał(a):

Hmm... Może czas w końcu przyjąć na klatę, że Delphi i Free Pascal jako najpopularniejsze dialekty Pascala nie są martwe i jeszcze długo nie będą?

W twojej głowie nie będą, ale w branży informatycznej dawno już są. Hobbyści uzywają, poza tym nikt.

Szczery Jacek napisał(a):

W twojej głowie nie będą, ale w branży informatycznej dawno już są. Hobbyści uzywają, poza tym nikt.

Zakładając nawet, że to jest język dla hobbistów to... co to zmienia? Daj im spokój w tym co robią, nikt tu z nas butami w Twoje zabawki nie wchodzi, natomiast Ty jesteś jakiś tryhard hater.

spartanPAGE napisał(a):

pomimo że kilkakrotnie im przypomniano że nikt tu o żadnych bazach danych nie mówi.

W tym sęk. Szukasz nie rozwiązania, lecz problemu.

To nie jest szukanie, to jest rzeczywisty problem. Pisanie pętli zupełnie niepotrzebnie zajmuje czas i ekran, LINQ pozwala sobie tego oszczędzić.

Delphi od początku miało być wyrocznią komunikującą się z bazami danych, więc jakiekolwiek ich przetwarzanie w delphi bez nich wygląda tak, jakbyś w c# pisał bez stdliba.

I może jeszcze Delphi nie obsługuje kolekcji w pamięci, tylko bazy danych? o.O

Niekoniecznie, bo masowe dane powinny siedzieć... w bazie.

Dane w bazie powinny siedzieć wtedy, gdy jest potrzeba trzymania danych w bazie. Dane mogą pochodzić z różnych źródeł, a potrzeba ich efektywnego przetwarzania i przeszukiwania to nie jest nic niezwykłego.

kaczus napisał(a):

Dodatkowo nie wiem, po co mieszasz wzorce projektowe do tego, to, że w kontrolce mogę w odpowiedni sposób zmienić dane nie ma nic do wzorców projektowych.

MVC, MVP, MVVM, mówi Ci to coś?

Dane od części wizualnej mogą byc oddzielone, ale nie pomyślałeś o jednym, aktualizacja przetrzymywanych nie musi następować wraz ze zmianą w widoku. W widoku zmieniaj danej jak chcesz, na koniec pozostaw dane bez zmian, lub zmień, wedle tego co zostało zmienione w widoku.

W sensownej architekturze źródłem danych dla widoku są obiekty widoków, a do aktualizacji danych w źródle służą inne obiekty. Dzięki temu można uniknąć bajzlu w kodzie i wielu godzin debugowania.

abrakadaber napisał(a):

DELPHI NIE MA LINQ ani niczego podobnego. Czy to wg ciebie skreśla język jako taki?

To nie pytanie do mnie, ale moim zdaniem nie. Każdy język ma swoje wady i zalety, języki trzeba dobierać według zastosowania i celu.

Ale jeśli ktoś ma zamiar bredzić, że możliwość krótszego zapisu jakiejś operacji nie jest zaletą języka, to niech lepiej już pójdzie dalej perforować swoje karty.

@somekind - muszę coś sprostować. U nich w delphi nie ma żadnego bindowania ani żadnego view modelu. Po prostu wpisują bezpośrednio tekst do kontrolki a jak chcą go zmienić to znów wpisują ręcznie inny tekst. Nie ma tam żadnego bindowania ani żadnej logiki prezentacji. Operowanie jest bezpiśrednio na wewnętrznej kolekcji zaszytejvw kontrolce, nie ma rozdzielenia warstw. Dlatego padło pytanie o usuwanie linii.

Czyli stare podejście i spaghetti code ciężki w utrzymaniu. A delphiarze nie rozumieją o czym piszesz bo to dla nich zbyt wysoki poziom abstrakcji. Dziś delphi uczy tylko złych nawyków i szkodliwych przyzwyczajeń, mamy tu właśnie kilka tego przykładów.

Ciekaw jestem, gdzie pracujecie ;)
Osobiście miałem okazję pracować już w 3 miejscach. W pierwszych dwóch Delphi (7 i 5) - Pierwszy system duży, sprzedawane za granicę, kasa leci ciurkiem. W drugim przypadku używany przez NFZ (kasa też konkretna "na serwis i rozwój"). Obecnie pisze w .Net.
Delphi ma kilka podstawowych zalet - bardzo responsywne IDE (na komputerach z 2007 roku działało bez "zwiech"). Obecnie mam średniej wielkości projekt .Net - bez silnej maszyny z i5 czy i7 nie ma nawet sensu odpalanie IDE, nie mówiąc o kompilowaniu itp...

Jak myślicie - czy klient chętniej zapłaci za gotowe, działające rozwiązanie, czy za projekt rozwiązania, który "ma poprawną architekturę" i "rokuje nadzieję na przyszłość"?

O tym pisałem już wcześniej. Programiści Delphi są potrzebni do ciągnięcia starych projektów. Ale nikt nie rozpoczyna nowych projektów w tej technologii, bo jest już przestarzała, źle zaprojektowana i uczy tylko złych nawyków.

Sam przyznałeś że ciągniesz tylko stare projekty i to nawet w Delphi5. To jest ok, ale przyszlosci nie ma.

Ta nie ma kolejny raz udowadniasz że jesteś zwykłym trollem i NIE MASZ POJĘCIA O DELPHI znaFco tematu który może przez 2 min. miał do czynienia z Delphi w wersji nie nowszej niż 7. Jasne jak już pisałem Delphi to Pascal 7 (lub starszy) napisany pod DOS'a... i w ogóle na nowych systemach się nie uruchamia. http://docwiki.embarcadero.com/RADStudio/XE8/en/Model_View http://docwiki.embarcadero.com/RADStudio/XE8/en/LiveBindings_in_RAD_Studio

Weź Panie kończ i wstydu sobie oszczędź. W delphi 7 nie było bindowania. Ale mogłeś sobie je sam zrobić, jeśli potrafiłeś.
W nowszych wersjach środowiska Delphi od kilku lat jest bindowanie dostępne (od serii XE).
Wypowiadasz się o tym o czym nie masz pojęcia. Czyli jesteś zwykłym złamasem.

somekind napisał(a)

Skoro można w Delphi bindować kontrolki z obiektami, to skąd ta krucjata przeciwko temu?

Stąd, że ta funkcjonalnośc to tylko namiastka tego co jest w .net albo javie. I zasadniczo nie nadaje się do niczego. Aczkolwiek, ci co pisali tu wcześniej wygladają jakby nie wiedzieli że to jest.

Szczery Jacek napisał(a):

Programiści Delphi są potrzebni do ciągnięcia starych projektów. Ale nikt nie rozpoczyna nowych projektów w tej technologii, bo jest już przestarzała, źle zaprojektowana i uczy tylko złych nawyków.

Nie byłbym tego taki pewien :-) Może co do zamkniętego i własnościowego DELPHI to i masz rację ale co do open sourcowego Lazarusa to wydaje mi się że opowiadasz bajki :-)

Nie rozumiem dlaczego jedziesz po tym DELPHI (i jak sądzę Lazarusie), sugerujesz złe praktyki zupełnie chyba bezpodstawnie albo po prostu przesadzasz.

Po pierwsze. Żeby była mowa o tym bindowaniu i użyciu jakiejś tam StringListy, tak jak w Androidzie jest np. ArrayAdapter, który pozwala na podpięcie listy stringów do celów operacji na ListView albo GridView, to trzeba by pod DELPHI/Lazarusa taką odpowiednią kontrolkę napisać. Jaki to jest problem?

Pod drugie, już tu wcześniej dałem przykład, że w DELPHI (jak i w Lazarusie również) można bez najmniejszych problemów napisać dowolną aplikację desktopową, w oparciu o wzorzec model-widok-prezenter (pasywny widok), ten wzorzec jest przecież bardzo popularny i znany. Oczywiście żeby było jasne, jest też FPCUnit, więc można bez najmniejszych problemów pisać testy jednostkowe.

Ale jest pewien problem. Kontrolki niewizulane np. do połączeń z bazą danych, timer i inne tego typu rzeczy, jako że jest to zintegrowane z oprogramowaniem typu RAD, wręcz zachęcają do obsadzania takich w formatce i faktycznie tak jak piszesz, chyba wręcz zachęca do pisania w starym stylu przez tzw. "wyklikanie".

Oczywiście jest DataModule i tam można wywalić wszystkie niewizualne kontrolki, w DELPHI/Lazarus ułatwieniem jest jednak to, że jak się je obsadzi w DataModule czy też w formatce, to masz z boku podgląd jakie to ma właściwości, co jest moim zdaniem dużym ułatwieniem.

Może zamiast jechać po tej rzekomo przestarzałej i rzekomo zdychającej technologii (dobry żart, jakoś nie sądzę żeby Lazarus chylił się ku upadkowi :) ) należałoby wyjść z tego założenia, że aplikacje desktopowe (a do tego doskonale nadaje się DELPHI albo Lazarus) pisze się trochę inaczej niż aplikacje webowe albo mobilne.

Oby tak dalej :-) Skoro tak jedziesz po tej technologii to może napiszesz konkretniej co jest teraz trendy i co będzie trendy przez co najmniej 10 lat do przodu?