Przejście z Delphi 7 na XE7

Witam. Jakiś czas temu dość intensywnie programowałem na Delphi 7. Ostatnimi czasy doszedłem do wniosku, że czas odświeżyć sobie trochę wiedzę, ale jednocześnie przesiąść się na coś nowszego. Mam tu na myśli XE 7. Czy to będzie bolesny przeskok? Widziałem tak po pierwszej godzinie zabawy, że naprawdę sporo rzeczy się zmieniło.

To zależy jak szybko ktoś przyswaja wiedzę czy chce się uczyć nowości (a nie musi) ale do wszystkiego idzie się przyzwyczaić. Fakt przez lata wiele się zmieniło nie tylko w środowisku ale i w języku (doszło trochę rzeczy i wprowadzono UNICODE) ale to raczej nie problem się nauczyć... stopniowo, bo chyba nie musisz wszystkich nowości poznać na jutro więc raczej rozejdzie się po kościach. O bolesnym przeskoku można by było mówić gdybyś miał jakieś duże projekty przenieść na nowe środowisko.

"Doszło trochę rzeczy" to eufemizm.
Przejście z Delphi7 do XE7 zmienia wszystko, poza ogólną filozofią programowania w Delphi. A Unicode to najmniejszy problem - albo inaczej, to żaden problem w przypadku nowych projektów.
Jest mnóstwo zmian w tym co widać (np. IDE) i w tym czego nie widać (język i jego możliwości, kompilator), ale na szczęście generalnie są to zmiany na lepsze.
Tak czy siak - absolutnie warto migrować do XE7 i omijać szerokim łukiem XE6, zwłaszcza jeśli ktoś będzie używał baz danych.

Można, tylko po co? Jeśli to nie jest wymaganie zewnętrzne, np. masz projekt, który musisz przenieść, albo bo pracujesz w firmie, która używa Delphi i myśli nad zakupem nowej wersji, to nie lepiej ten czas poświęcić na nauczenie się innego, nowocześniejszego języka / technologii? Twoje pytanie brzmi trochę jak "znam Perla 5, czy trudno się przestawić na Perla 6" albo "znam VB6, czy warto iść w VB.NET?" Podejrzewam, że ilość pracy jaką musiałbyś włożyć w nauczenie się C# / Javy będzie w sumie niewiele większa, a wzrost Twojej wartości jako programista na rynku pracy i możliwości znacznie większe. Nawet najnowsze Delphi jest mocno w tyle względem tych technologii pod praktycznie każdym względem (IDE, kompatybilność z bazami danych, język programowania, wsparcie społeczności open-source, wsparcie techniczne firm trzecich, stabilność działania, jakość produkowanego kodu wynikowego, cena).

Krolik napisał(a):

Można, tylko po co? Jeśli to nie jest wymaganie zewnętrzne, np. masz projekt, który musisz przenieść, albo bo pracujesz w firmie, która używa Delphi i myśli nad zakupem nowej wersji, to nie lepiej ten czas poświęcić na nauczenie się innego, nowocześniejszego języka / technologii?

No to zacznijmy flame; co to za nowocześniejsza, lepsza, wszystko-mająca technologia? .NET a może Java? Pewnie, ale zależy do czego - bo w pewnych kwestiach Delphi bije jedno i drugie na głowę, a w innych jest dokładnie odwrotnie.
Poza tym, nie wiem jak OP, ale ja Delphi znam doskonale i mogę zrobić w nim wszystko czego potrzebuję i to niejednokrotnie szybciej, lepiej i taniej niż w powyższych. Tylko na takie pytanie każdy musi odpowiedzieć sobie sam, to nie jest takie oczywiste...

Twoje pytanie brzmi trochę jak "znam Perla 5, czy trudno się przestawić na Perla 6" albo "znam VB6, czy warto iść w VB.NET?" Podejrzewam, że ilość pracy jaką musiałbyś włożyć w nauczenie się C# / Javy będzie w sumie niewiele większa, a wzrost Twojej wartości jako programista na rynku pracy i możliwości znacznie większe.

Pokaż mi te znacznie większe możliwości, chętnie się z nimi zapoznam.

Nawet najnowsze Delphi jest mocno w tyle względem tych technologii pod praktycznie każdym względem (IDE, kompatybilność z bazami danych, język programowania, wsparcie społeczności open-source, wsparcie techniczne firm trzecich, stabilność działania, jakość produkowanego kodu wynikowego, cena).

No to weźmy te względy;

• IDE; to w sumie jest kwestia gustu, ale ja lubię swoje IDE. Doposażone w MMX, CnWizards i DI nie odstaje za bardzo od innych bardzo dobrych.
• kompatybilność z bazami danych; no tu chyba się totalnie zapędziłeś, Delphi od zawsze oferowało doskonałe wsparcie dla baz danych i nic w tym względzie się nie zmieniło na gorsze. Jest tylko lepiej, czyli dostępność FireDAC, UniDAC;a i ORMów.
• język programowania; to jest zawsze kwestia gustu. Ktoś wychowany na C nigdy tego nie łyknie, jak ja nigdy nie łyknę składni Basicowo podobnej. Co do możliwości samego język, czego Ci brak?
• wsparcie społeczności open-source; fakt, nie ma tego tyle co np. dla .NET czy Java, ale bez przesady - nie ma tez pustyni. A samych projektów OpenSource przez ostatnie 4 lata pojawiło się naprawdę sporo.
• wsparcie techniczne firm trzecich; chodzi o dostępność komercyjnych dodatków? Jet ich cała masa.
• stabilność działania; jest sporo narzekań na stabilność IDE w sieci, ale z mojego doświadczenia wygląda to całkowicie inaczej niż można tam wyczytać. Potrafię np. nie wyłączać IDE przez miesiąc i cały czas działa stabilnie. To chyba wystarczająco stabilnie?
• jakość produkowanego kodu wynikowego; rozumiem, że jakość kodu np. Javy jest "lepsza" niż Delphi? Jaasne... OK, może nie nadaje się to do pisania po wyciągnięciu z pudełka super-wydajnych i zoptymalizowanych rozwiązań, ale co się nadaje? A do "normalnych" biznesowych zastoso0wań jest wystarczająco dobrze. A może i bardzo dobrze.
• cena; Fakt - Delphi jest za drogie, zwłaszcza patrząc na to z naszego podwórka.

@Krolik, czego nie rozumiesz, kiedy powiedziałem Ci, że nie będę dyskutował w komentarzach?

MongDB (programista, który nie umie szukać informacji - ciekawe...):
http://docs.mongodb.org/ecosystem/drivers/community-supported-drivers/
Polecam ten ostatni, bo jest naprawdę dobry a cały mORMot (to nie jest tylko ORM) bije na głowę wydajnością WCFa i rozwiązania Javove.
Poza tym - rozumiem, że stawiasz na MongoDB wszystko jak leci?

FireDAC, czyli oficjalna wspiera przez producenta warstwa DAL dla Delphi obsługuje Oracle i fafnaście innych baz danych. Włącznie z dedykowanymi extrasami dla poszczególnych - jak chociażby Events dla Firebird (Jybird też to wspiera, od pół roku. Delphi od ponad 10 lat - i co z tego?) lub BLOB streaming ze wsparciem dla filestream w MSSQL.

Nie interesują mnie opinie korpo-koderów i ich czy "to jeszcze żyje?". Oni mają wydzielony kawałek do zrobienia i nic więcej ich nie obchodzi. I na niczym innym się nie znają, najczęściej... Ale nieważne. To nie jest dyskusja, tylko Twoja subiektywna opinia, poza tym absolutnie nie na temat.
A temat nie dotyczy pytania czy Delphi jest dobre dla kogoś, kto wchodzi na rynek pracy, tylko o różnice pomiędzy XE7 a 7.
Rozumiem, że posiadasz szerokie doświadczenie w jednym i drugim, aby cokolwiek sensownego, dla odmiany, powiedzieć? No to powiedz w końcu.

Poza tym, można powiedzieć że jestem programistą Delphi i jakoś na brak pracy nie narzekam, a wręcz przeciwnie. Ale zgoda - nie jestem typowym programistą a tym bardziej typowym pracownikiem.
Co do startupów - pokaż mi jakiś naprawdę ciekawy, który nie będzie kalką tego co znane od lat. Al tak naprawdę... język czy tam IDE, to sprawa drugorzędna. Jeśli weźmiesz najlepsze dostępne narzędzie i średnich "fachowców" to otrzymasz mierny produkt. A mierny dlatego, bo nie wszystko wiedza i rozumieją z zakresu bibliotek i możliwości języka, a przede wszystkim - ze świecą szukać programisty, który interesuje się i zna na dziedzinie problemu.
I odwrotnie - jeśli weźmiesz średnie narzędzia i doskonałych fachowców, to otrzymasz doskonały produkt.
Załóżmy, że Delphi jest średnie - ale to naprawdę zależy do czego.

MongDB (programista, który nie umie szukać informacji - ciekawe...):

To, co wkleiłeś, to nie jest oficjalny sterownik od MongoDB, a "community-supported-driver". Takie sterowniki znajdzie się dla najbardziej niszowej, absurdalnej technologii i ich istnienie niczego nie dowodzi. Dla firm takie strowniki praktycznie nie istnieją, bo nie można nabyć do nich wsparcia technicznego. Liczy się, to co producent bazy wspiera oficjalnie. Javę, C#, Pythona, JS wspiera, Delphi nie wspiera. Dla mnie to wystarczające aby uznać, że Delphi ma gorszą kompatybilność z bazami danych (zwłaszcza nowymi) niż nowsze technologie.

A FireDAC to tylko warstwa abstrakcji, a nie sterownik. Bazuje na sterowniku do innego języka (zapewne C) i wprowadza dodatkowy własny narzut.

jakość produkowanego kodu wynikowego; rozumiem, że jakość kodu np. Javy jest "lepsza" niż Delphi? Jaasne...

Na ogół jest lepsza, czasem nawet znacznie:
http://stackoverflow.com/questions/18610419/how-to-use-modern-cpu-instructions-in-delphi-java-faster-than-delphi
http://webandlife.blogspot.com/2011/12/c-performance-vs-delphi-performance.html

Ale to nie jest nawet zasługa Javy czy .NET, a tego, że kompilator Delphi jest zwyczajnie słaby i dostaje bęcki nawet od FPC:
http://delphihaters.blogspot.com/2014/05/scimark-and-in-lining-inside-story.html

W samych bibliotekach Delphi jest parę rzeczy zrobionych słabo z punktu widzenia wydajności - np. copy-on-write strings czy cała zabawa w reference counting (smart pointery). Nowe wersje Delphi XE mają wprawdzie mniej błędów niż poprzednie wersje Delphi (Delphi 2007-2010 miały bug na bugu), ale wydajnościowo rewolucji nie było.

http://sohu.io/questions/142710/does-delphi-xe-produce-faster-code-than-delphi-2007

Nie sądzę, aby tak mała firma jak Embarcadero z tak ambitnym planem (wsparcie dla Android, iOS, Windows, własny kompilator, własne IDE i jeszcze własne stery do baz danych; co będzie następne - własny OS?) miała jeszcze zasoby aby popracować porządnie nad kompilatorem. To nie jest Microsoft czy Oracle z miliardami dolarów płacący seniorom po 200-300k USD rocznie.

To nie jest dyskusja, tylko Twoja subiektywna opinia, poza tym absolutnie nie na temat.

O, wreszcie coś do rzeczy. I dlatego uparcie pisałem w komentarzu - bo komentarz to miejsce na tematy poboczne.

Żeby było na temat, to podam jeden przykład Delphi 7 vs XE jaki mi się nasunął. W XE np. będziesz chciał poznać np. lambdy wprowadzone w 2009r. (nazwane nie wiedzieć czemu metodami anonimowymi). O ile pisanie z lambdami w języku z GC nie jest jakimś wyczynem (C#, F#, Java, Scala), bo system przejmuje na siebie prawidłowe zarządzanie cyklem życia obiektów złapanych w kontekście lambdy, to w przypadku Delphi już nie jest tak prosto - w sumie bez dogłębnego zrozumienia co się dzieje pod spodem, i co robi kompilator łatwo wpakować się w tarapaty lub ciekawe przypadki brzegowe:
http://stackoverflow.com/questions/9282103/anonymous-method-in-project-leaks-memory

Z drugiej strony, zmiany w języku wcale nie były znowu takie rewolucyjne - tu masz listę zmian w jednej z odpowiedzi:
http://stackoverflow.com/questions/8460037/list-of-delphi-language-features-and-version-in-which-they-were-introduced-depre

@Krolik Ty masz chyba jakieś kompleksy jak "niszowa technologia Delphi" Ci nie pasuje to po co udzielasz się w tym dziale ...?
Aby nie odbiec od tematu wątku dodam że idzie bez problemu przekompilować projekty z Delphi 7 oparte o BDE, oczywiście zalecaną technologią jest FireDac.

Pozwolę sobie zignorować powyższą świętą wojnę i zaproponuję autorowi wątku tak:

• możesz spróbować przejść na Free Pascal (darmo, Linux/Windows/Mac/etc.)
• możesz przejść na C# (nowocześniejszy język, wbudowany framework GUI, ma webdev, IDE za darmo w wersji VS Community lub MonoDevelop)

XE7 jest dobre jeśli Twoja firma ma już na to licencję i nie wie co z nią zrobić (zdarza się).
Jeśli masz zamiar spiracić to można równie dobrze wybrać drogę legalną (patrz wyżej).
Jeśli masz zamiar kupić - to wg mnie szkoda kasy.
Głównie przez vendor lock-in dla sterowników baz danych (komercyjne sterowniki firm trzecich - jeśli są, nie są czymś czego chciałbym używać bez źródeł, czyli dodatkowy koszt).
Bywa że klient chce sam rozwijać aplikację, przy koszcie Delphi XEx taka możliwość jest od razu mniej atrakcyjna od konkurencji.

Gdyby proponowali kompilator Delphi za darmo + okrojone IDE za jakieś grosze (do 500 zł) to można by się zastanawiać.
Może z czasem zmądrzeją. Ale raczej małe szanse na to.

Ja napisze jeszcze jedno do 31 marca można było zakupując Delphi XE7 przy okazji w cenie Delphi XE7 nabyć XE8 bo była promocja teraz już jej nie ma. Swoją drogą myślę że Embarcadero źle robi nie wypuszczając darmowej wersji środowiska dla amatorów hobbystów i tym odstrasza ludzi którzy na początku ucząc się chcą czegoś darmowego i wybierają VS a przecież nikt kto załóżmy kilka lat siedział na C# (w VS) nie przejdzie nagle na Delphi.

Krolik napisał(a):

MongDB (programista, który nie umie szukać informacji - ciekawe...):

To, co wkleiłeś, to nie jest oficjalny sterownik od MongoDB, a "community-supported-driver". Takie sterowniki znajdzie się dla najbardziej niszowej, absurdalnej technologii i ich istnienie niczego nie dowodzi.

Prawda, znajdą się takie sterowniki i nieprawda, że to niczego nie dowodzi. Mogę obsłużyć MongoDB z poziomu Delphi czy nie mogę? Oczywiście, że mogę.
Chcesz mieć support - to zapłać np. mORMotowi i będziesz miał, na stronie jest informacja jak to zrobić.

Dla firm takie strowniki praktycznie nie istnieją, bo nie można nabyć do nich wsparcia technicznego. Liczy się, to co producent bazy wspiera oficjalnie. Javę, C#, Pythona, JS wspiera, Delphi nie wspiera. Dla mnie to wystarczające aby uznać, że Delphi ma gorszą kompatybilność z bazami danych (zwłaszcza nowymi) niż nowsze technologie.

A możesz sobie uznawać co Ci się żywnie podoba, tylko to wygląda co najmniej kuriozalnie...
To, że na oficjalnej stronie MongoDB nie ma wsparcie nie świadczy o tym, że Delphi nie ma dobrego wsparcia do baz danych w ogóle. To jet piramidalna bzdura!

Dla mnie takie rozwiązania często mają większy sens, niż oficjalne i komercyjne - support jest po prostu lepszy, a reakcja na błędy jest praktycznie natychmiastowa.
Dla ogromnej korporacji z setkami developerów faktycznie może to być nie do przyjęcia. Ale ja takiej korpo nie prowadzą, nie będę i nawet nie chciałbym. Poza tym, to co robi 30 programistów Javy zrobi 3 programistów Delphi:
http://stevepeacocke.blogspot.com/2013/05/delphi-why-wont-it-just-die.html
I mogę tak do jutra, i Ty też - czego to dowodzi? Niczego, poza tym, że ktoś zrobił sobie jakiś test i można w nim udowodnić wszystko.

A FireDAC to tylko warstwa abstrakcji, a nie sterownik. Bazuje na sterowniku do innego języka (zapewne C) i wprowadza dodatkowy własny narzut.

Naprawdę?
Rozumiem, że taki np. ADO.NET to też warstwa abstrakcji, bo działa dokładnie w ten sam sposób co FireDAC (zresztą podobieństw jest więcej, ale pewnie nie masz o tym zielonego pojęcia, bo dla Ciebie FireDAC to tylko kontrolka do obsługi bazy danych) - czyli korzysta de-facto z oficjalnej biblioteki producenta bazy danych na daną platformę. Czyli np. dla MSSQL będzie to SQL Server NativeClient, dla Firbird będzie to fFbClient itd.

jakość produkowanego kodu wynikowego; rozumiem, że jakość kodu np. Javy jest "lepsza" niż Delphi? Jaasne...

Na ogół jest lepsza, czasem nawet znacznie:
http://stackoverflow.com/questions/18610419/how-to-use-modern-cpu-instructions-in-delphi-java-faster-than-delphi
http://webandlife.blogspot.com/2011/12/c-performance-vs-delphi-performance.html

Poważnie? No zobacz, a ja znalazłem co innego:
http://compaspascal.blogspot.com/2009/06/delphi-is-fast-very-fast.html

Ale to nie jest nawet zasługa Javy czy .NET, a tego, że kompilator Delphi jest zwyczajnie słaby i dostaje bęcki nawet od FPC:
http://delphihaters.blogspot.com/2014/05/scimark-and-in-lining-inside-story.html

W samych bibliotekach Delphi jest parę rzeczy zrobionych słabo z punktu widzenia wydajności - np. copy-on-write strings czy cała zabawa w reference counting (smart pointery).

Akurat obsługa stringów w Delphi jest szalenie wygodna, ale zgoda że trzeba uważać (czyli pamiętać o przekazywaniu wartości przez const lub var) w newralgicznych miejscach, które wymagają wydajności. A najlepiej uczynić z tego nawyk.
To nie jest argument na nie, tylko na tak dla Delphi - ale coś za coś.

Poza tym, nie porównaj mi tu ref countingu do języków z wbudowanych GC - to zupełnie inna filozofia programowania!
I dlatego (i nie tylko dlatego), moje serwery napisane w Delphi przy tym samym obciążeniu zeżrą 233x mniej ramu od Javy i 300x mniej niż .NET dla identycznych rozwiązań. Zachowując przy tym co najmniej taką samą wydajność. CO NAJMNIEJ. Wiem, że to może boleć kogoś, kto na co dzień używa najnowocześniejszych technologii, a tu pojawia się coś co powinno zdechnąć dekadę temu i na dodatek "robi robotę".
Rozumiem, że dla "firmy" to bez znaczenia, bo ma być "nowocześnie" a nie dobrze.
Ach, źródło:
http://blog.synopse.info/post/2012/11/23/Speed-comparison-between-WCF,-Java,-DataSnap-and-mORMot

Zaraz mi powiesz, że to się nie liczy dla firmy bo nie ma oficjalnego wsparcia. OK, ale dokładnie w ten sam sposób możesz wywalić wszelkie otwarte projekty.

Nowe wersje Delphi XE mają wprawdzie mniej błędów niż poprzednie wersje Delphi (Delphi 2007-2010 miały bug na bugu),

Coś tam słyszałeś, ale niedokładnie...
Bug na bugu był w D2009, a D2007 jest jednym z najstabilniejszych IDE.
W D2010 było znacznie lepiej, ale dalej sypało się na typach generycznych.

ale wydajnościowo rewolucji nie było.
http://sohu.io/questions/142710/does-delphi-xe-produce-faster-code-than-delphi-2007
Bo i nie o wydajność tam chodziło, tylko o rozwinięcie języka, który utknął na prawie 10 lat!
Nie sądzę, aby tak mała firma jak Embarcadero z tak ambitnym planem (wsparcie dla Android, iOS, Windows, własny kompilator, własne IDE i jeszcze własne stery do baz danych; co będzie następne - własny OS?)

To miał być sarkazm? To akurat nie wyszło. Widzisz, ala mnie np. jest to doskonałe rozwiązanie. Ale ja nie wymagam od rozwiązań mobilnych wydajności graficznej jak gra - to ma pracować i zarabiać pieniądze dla firmy, a nie oszałamiać graficznymi fajerwerkami.

miała jeszcze zasoby aby popracować porządnie nad kompilatorem. To nie jest Microsoft czy Oracle z miliardami dolarów płacący seniorom po 200-300k USD rocznie.

Znów subiektywna opinia poparta "rzetelnymi" faktami... Może tak - pożyjemy, zobaczymy.

To nie jest dyskusja, tylko Twoja subiektywna opinia, poza tym absolutnie nie na temat.

O, wreszcie coś do rzeczy. I dlatego uparcie pisałem w komentarzu - bo komentarz to miejsce na tematy poboczne.

Żeby było na temat, to podam jeden przykład Delphi 7 vs XE jaki mi się nasunął. W XE np. będziesz chciał poznać np. lambdy wprowadzone w 2009r. (nazwane nie wiedzieć czemu metodami anonimowymi).

Znowu coś tam słyszałeś, ale nie do końca rozumiesz.
W Delphi nie ma wyrażeń-lambda do dziś.
W Delphi są metody anonimowe, a metoda anonimowe to nie jest wyrażenie-lambda. Doczytasz, to załapiesz różnicę.

O ile pisanie z lambdami w języku z GC nie jest jakimś wyczynem (C#, F#, Java, Scala), bo system przejmuje na siebie prawidłowe zarządzanie cyklem życia obiektów złapanych w kontekście lambdy, to w przypadku Delphi już nie jest tak prosto - w sumie bez dogłębnego zrozumienia co się dzieje pod spodem, i co robi kompilator łatwo wpakować się w tarapaty lub ciekawe przypadki brzegowe:
http://stackoverflow.com/questions/9282103/anonymous-method-in-project-leaks-memory

I rozumiem, że dla Ciebie to wada, bo Delphi nie ma GC?
Zrozum w końcu, że Delphi to nie jest język zarządzalny i rządzi się zupełnie innymi prawami.
Poza tym, mam rozumieć że w Java czy .NET nie da się napisać złego kodu bez wycieków? ;-)

Bo to co podałeś, to jest właśnie przykład błędnego wykorzystania możliwości języka. I nie wymaga to jakiegoś "dogłębnego zrozumienia", tylko zrozumienia po prostu jak i kiedy jest zwalniana pamięć w Delphi dla typów z ref-countingiem. Napisane w dokumentacji jak wół, tylko trzeba ją jeszcze przeczytać ze zrozumieniem... Fakt, tu może być problem.

Z drugiej strony, zmiany w języku wcale nie były znowu takie rewolucyjne - tu masz listę zmian w jednej z odpowiedzi:
http://stackoverflow.com/questions/8460037/list-of-delphi-language-features-and-version-in-which-they-were-introduced-depre

Może dla kogoś, kto pisze w Java lub .NET zmiany nie są rewolucyjne. Ale dla środowiska jest dokładnie odwrotnie, bo w końcu Delphi zaczyna nadążać za nowoczesnymi językami, ale ważniejsze jest to, że dzięki temu pojawiło się mnóstwo bardzo ciekawych bibliotek. A nie było to możliwe, bez wprowadzenia tych mało rewolucyjnych zmian...

Reasumując - Delphi to nie .NET czy Java. I bardzo dobrze. Prawda, że Java czy .NET oferują bogatszy język i znacznie więcej kodu/przykładów/bibliotek community.
Ale to nie oznacza, że Delphi jest złe czy gorsze. Aczkolwiek na siłę można udowodnić wszystko, również to, że Java i .NET jest gorsze od Delphi. Ale to zabawa dla gimbusów i mnie w to nie wciągaj.

jakość produkowanego kodu wynikowego; rozumiem, że jakość kodu np. Javy jest "lepsza" niż Delphi? Jaasne...

Na ogół jest lepsza, czasem nawet znacznie:
http://stackoverflow.com/questions/18610419/how-to-use-modern-cpu-instructions-in-delphi-java-faster-than-delphi
http://webandlife.blogspot.com/2011/12/c-performance-vs-delphi-performance.html

Poważnie? No zobacz, a ja znalazłem co innego:
http://compaspascal.blogspot.com/2009/06/delphi-is-fast-very-fast.html

Fajnie, tylko jak to się ma do solidnego benchmarku z kodem źródłowym? SciMark robi troszkę więcej niż iterację po jednej tablicy. Zresztą ten wklejony przez Ciebie benchmark jest bez wartości, bo nawet nie podano która wersja, ani jak uruchamiane, ani nie podane opcje kompilacji... Odkąd pamiętam Delphi nigdy nie generowało bardzo dobrego kodu. To, że coś jest natywne, nie oznacza że jest szybkie.

http://www.delphitools.info/2011/02/08/the-limitations-of-delphis-inline/

Ok, powiesz, że znowu wyciągnąłem jednostkowy przypadek. To w takim razie zobaczmy, jakie optymalizacje umie robić obecnie kompilator Delphi.

Jedną z najważniejszych optymalizacji kodu jest inlining. Oficjalna dokumentacja do XE7 na temat inline stwierdza:

• Inlining will not occur on any form of late-bound method. This includes virtual, dynamic, and message methods.
• Constructors and destructors will not be inlined.
• Routines that are not defined before use cannot be inlined.
• Code can be inlined within packages, however, inlining never occurs across package boundaries.
• If a routine is defined in the interface section and it accesses symbols defined in the implementation section, that routine cannot be inlined.
  ...

Delphi przegrywa tu z Javą na całej linii (tak, Java umie inlineować we wszystkich wyżej wymienionych przypadkach, nie wiem, jak z .NET, bo aż tak dobrze nie znam, ale podejrzewam że w większości tych przypadków CLR też sobie radzi).
Podobnie jest z innymi bardziej zaawansowanymi optymalizacjami - loop unrolling, wektoryzacja SSE/AVX, usuwanie locków, scalar-replacement, których w Delphi po prostu nie ma w ogóle i nawet z dokumentacji nie można się dowiedzieć, jaki jest stan.

Oczywiście nie twierdzę, aby miało to jakieś wielkie znaczenie w aplikacjach biznesowych, ale odnoszę się do Twojego zupełnie błędnego twierdzenia, jakoby Delphi miało lepszy kompilator niż Java i .NET. Otóż nie, kompilator Delphi jest obecnie w epoce kamienia łupanego, i pod względem stabilności / poprawności i jeśli chodzi o wydajność generowanego kodu.

Poza tym, nie porównaj mi tu ref countingu do języków z wbudowanych GC - to zupełnie inna filozofia programowania!
I dlatego (i nie tylko dlatego), moje serwery napisane w Delphi przy tym samym obciążeniu zeżrą 233x mniej ramu od Javy i 300x mniej niż .NET dla identycznych rozwiązań. Zachowując przy tym co najmniej taką samą wydajność. CO NAJMNIEJ. Wiem, że to może boleć kogoś, kto na co dzień używa najnowocześniejszych technologii, a tu pojawia się coś co powinno zdechnąć dekadę temu i na dodatek "robi robotę".

Po pierwsze refcounting jest pewną ułomną formą GC.
Po drugie z narzutem 233x i 300x to jest oczywista bzdura. Samo istnienie GC takiego jak w .NET czy Java nie powoduje narzutu pamięciowego większego niż fragmentacja w systemach z ręcznym zarządzaniem pamięci. Poza tym Twoje serwery napisane w Delphi mają duże szanse zajmować nieskończenie wiele więcej RAMu. Wystarczy mały memory-leak, a w Delphi o to bardzo łatwo (zwłaszcza, że kompilator ma bugi i sam wprowadza wycieki tam gdzie ich być nie powinno - np. http://qc.embarcadero.com/wc/qcmain.aspx?d=123194, http://qc.embarcadero.com/wc/qcmain.aspx?d=118135). Prawdopodobnie to jest powód, dla którego w Delphi nie pisze się oprogramowania serwerowego, a tylko aplikacje klienckie. One chodzą na tyle krótko, że małego wycieku tu lub tam nikt nie zauważy.

Bug na bugu był w D2009, a D2007 jest jednym z najstabilniejszych IDE.

D2007 może był w miarę stabilny (też mi się wywalił parę razy), ale tu mówimy o XE7.
Bug na bugu jest nadal w podstawowych elementach takich jak kompilator - wystarczy popatrzeć na tickety QC.

http://qc.embarcadero.com/wc/qcmain.aspx?d=128648 (kompilator usuwa prawidłowy kod, przy wyłączonych optymalizacjach)
http://qc.embarcadero.com/wc/qcmain.aspx?d=124878 (kompilator generuje inny semantycznie kod przy włączonych optymalizacjach)

To nie są jakieś przypadki brzegowe w egzotycznych miejscach specyfikacji języka. To są bugi w podstawowych miejscach jak przypisania i pętle.

A, no i zdarzają sie takie kwiatki:
http://stackoverflow.com/questions/27701294/why-does-delphi-xe7-ide-hangs-and-fails-on-out-of-memory-exception
To pewnie dlatego, że Delphi napisano w Javie i ten wredny GC powoduje 266x większe zużycie pamięci... :D

W D2010 było znacznie lepiej, ale dalej sypało się na typach generycznych.

Kompilatory C++ miały problemy ze znacznie potężniejszym systemem template'ów (którym można zrobić wszystko co w mocno ograniczonych genericsach Delphi) tak gdzieś koło roku 1998. Później już nie miały.

Bo i nie o wydajność tam chodziło, tylko o rozwinięcie języka, który utknął na prawie 10 lat!

No utknął i to właśnie widać, a przyszłość jest niepewna. A co ja innego pisałem? Czy warto odświeżać sobie wiedzę na temat języka, który utknął na 10 lat i teraz desperacko próbuje gonić inne technologie dodając na szybko rzeczy, które konkurencja miała 10-15 lat temu (genericsy, metody anonimowe itp.), wprowadzając przy okazji krytyczne błędy w podstawowych funkjcach?

Moim zdaniem warto się uczyć technologii, które są innowacyjne, które wprowadzają nowości i od których inni ściągają pomysły. Ewentualnie takich, które ściągają, ale robią to dobrze i wprowadzają własne ulepszenia (jak C# ściągał z Javy, a teraz Java ściąga z C#).

Rozumiem, że na bazy danych już się nie bijemy? Dlaczego, wkroczyłeś na grząski teren?

Krolik napisał(a):

jakość produkowanego kodu wynikowego; rozumiem, że jakość kodu np. Javy jest "lepsza" niż Delphi? Jaasne...

Na ogół jest lepsza, czasem nawet znacznie:
http://stackoverflow.com/questions/18610419/how-to-use-modern-cpu-instructions-in-delphi-java-faster-than-delphi
http://webandlife.blogspot.com/2011/12/c-performance-vs-delphi-performance.html

Poważnie? No zobacz, a ja znalazłem co innego:
http://compaspascal.blogspot.com/2009/06/delphi-is-fast-very-fast.html

Fajnie, tylko jak to się ma do solidnego benchmarku z kodem źródłowym? SciMark robi troszkę więcej niż iterację po jednej tablicy. Zresztą ten wklejony przez Ciebie benchmark jest bez wartości, bo nawet nie podano która wersja, ani jak uruchamiane, ani nie podane opcje kompilacji... Odkąd pamiętam Delphi nigdy nie generowało bardzo dobrego kodu. To, że coś jest natywne, nie oznacza że jest szybkie.

Czytałeś w ogóle odpowiedź na to zapytanie w SO? Nie czytałeś, bo gdybyś czytał ze zrozumieniem, to wiedziałbyś skąd takie różnice i dlaczego wersja 64bit Delphi jest w tych benchmarkach szybsza od wersji 32bit. I być może szybsza od Javy.
Ale rozumiem - to nie jest po Twojej myśli.

http://www.delphitools.info/2011/02/08/the-limitations-of-delphis-inline/

Ok, powiesz, że znowu wyciągnąłem jednostkowy przypadek. To w takim razie zobaczmy, jakie optymalizacje umie robić obecnie kompilator Delphi.

Jedną z najważniejszych optymalizacji kodu jest inlining. Oficjalna dokumentacja do XE7 na temat inline stwierdza:

• Inlining will not occur on any form of late-bound method. This includes virtual, dynamic, and message methods.
• Constructors and destructors will not be inlined.
• Routines that are not defined before use cannot be inlined.
• Code can be inlined within packages, however, inlining never occurs across package boundaries.
• If a routine is defined in the interface section and it accesses symbols defined in the implementation section, that routine cannot be inlined.
  ...

Delphi przegrywa tu z Javą na całej linii (tak, Java umie inlineować we wszystkich wyżej wymienionych przypadkach, nie wiem, jak z .NET, bo aż tak dobrze nie znam, ale podejrzewam że w większości tych przypadków CLR też sobie radzi).

Zrozum w końcu, że Delphi to nie Java.
Jedno i drugie ma swoje ograniczenia i w jednym i drugim, coś można zrobić inaczej.
Równie dobrze mógłbym napisać, że Java jest do bani, bo w Delphi mogę napisać zwykłą procedurę (nie metodę), która jest inline.
To taki sam merytoryczny argument, jak Twoje.

Podobnie jest z innymi bardziej zaawansowanymi optymalizacjami - loop unrolling, wektoryzacja SSE/AVX, usuwanie locków, scalar-replacement, których w Delphi po prostu nie ma w ogóle i nawet z dokumentacji nie można się dowiedzieć, jaki jest stan.

Oczywiście nie twierdzę, aby miało to jakieś wielkie znaczenie w aplikacjach biznesowych, ale odnoszę się do Twojego zupełnie błędnego twierdzenia, jakoby Delphi miało lepszy kompilator niż Java i .NET.
A gdzie ja napisałem, że Delphi ma lepszy kompilator od Javy? A tak, napisałem - ma szybszy kompilator. Bardzo szybki, ale czy lepszy? Nie sądzę. Natomiast szybkośc kompilacji wpływa na wygodę użytkownika, a Delphi jest po prostu wygodne.
Otóż nie, kompilator Delphi jest obecnie w epoce kamienia łupanego, i pod względem stabilności / poprawności i jeśli chodzi o wydajność generowanego kodu.

To Twoja opinia poparta wycinkami z sieci.
Moja opinia jest inna - porównuję wydajność i stabilność własnych rozwiązań z korpo potęgami i jakoś nie mam kompleksów.
I nie chodzi mi o syntetyczne testy kompilatora, tylko o faktyczną "używalność" konkretnego oprogramowania u klienta.

Poza tym, nie porównaj mi tu ref countingu do języków z wbudowanych GC - to zupełnie inna filozofia programowania!
I dlatego (i nie tylko dlatego), moje serwery napisane w Delphi przy tym samym obciążeniu zeżrą 233x mniej ramu od Javy i 300x mniej niż .NET dla identycznych rozwiązań. Zachowując przy tym co najmniej taką samą wydajność. CO NAJMNIEJ. Wiem, że to może boleć kogoś, kto na co dzień używa najnowocześniejszych technologii, a tu pojawia się coś co powinno zdechnąć dekadę temu i na dodatek "robi robotę".

Po pierwsze refcounting jest pewną ułomną formą GC.

To taka sama prawda, że hulajnoga jest pewną ułomną formą samolotu.

Po drugie z narzutem 233x i 300x to jest oczywista bzdura.

Widziałeś testy? Wykresy? Rozumiem, że to bzdura... Z mojego punktu widzenia to nie jest bzdura, bo zaczyna wchodzić w tę technologię na poważnie i widzę jej ogromny potencjał i nie boję się skalowania tego rozwiązania. Nie sztuką jest dodać kolejny klaster serwerów do obsługi kolejnego tysiąca żądań. Pewnie, Java zrobi to za mnie, bo nie muszę się zastanawiać jak coś zrobi - robi się automagicznie i już.

Samo istnienie GC takiego jak w .NET czy Java nie powoduje narzutu pamięciowego większego niż fragmentacja w systemach z ręcznym zarządzaniem pamięci.

To dlaczego, praktycznie z definicji, zapotrzebowanie na pomięć serwerów aplikacyjnych napisanych w Java jest tak ogromne? Z czego to wynika?

Poza tym Twoje serwery napisane w Delphi mają duże szanse zajmować nieskończenie wiele więcej RAMu. Wystarczy mały memory-leak, a w Delphi o to bardzo łatwo

No proszę Cię! Powinieneś jeszcze dodać, że równie łatwo zrobić w Delphi błąd krytyczny (tzw. AV, czyli Access Violation) w przypadku kiedy weźmiemy obiekt, który nie został zainicjowany i coś tam będziemy chcieli z nim zrobić - np. wywołać jego metodę.
I to jest oczywista bzdura.
Równie łatwo można sobie palec rozwalić młotkiem - to znaczy, że mam nie używać młotka do wbijania gwoździ tylko postawić fabrykę, która za mnie automagicznie zrealziuje zadanie? Bo tak soię to robi w Java... Ale ja chciałem tylko gwóźdź wbić!

W Delphi nie ma GC. Kropka.
I nie ma sensu dyskutować, czy to dobrze czy źle.
GC ma ogromną rzeszę zwolenników i spore grono przeciwników. Coś za coś.

(zwłaszcza, że kompilator ma bugi i sam wprowadza wycieki tam gdzie ich być nie powinno - np. http://qc.embarcadero.com/wc/qcmain.aspx?d=123194, http://qc.embarcadero.com/wc/qcmain.aspx?d=118135). Prawdopodobnie to jest powód, dla którego w Delphi nie pisze się oprogramowania serwerowego, a tylko aplikacje klienckie. One chodzą na tyle krótko, że małego wycieku tu lub tam nikt nie zauważy.

Prawdopodobnie konfabulujesz.
W Delphi nie pisze się serwerów w takiej ilości jak w Java, bo do tego jest wymagana daleko większa wiedza i doświadczenie niż klikanie formatek. Co powoduje, że trudniej znaleźć programistów do takiego zadania. A w Java - proszę, bierzesz 10 studentów albo 50, biorą gotowe biblioteki, składają to do jakoś kupy, nie martwiąc się przy tym pamięcią (no bo przecież jest GC) i jakoś to działa. A jak zaczyna zwalniać, to stawia się kolejny klaster i jest git. Siła nowoczesnej technologii :)

Sam producent Delphi narobił to ogromną szkodę, bo cały (nieprzerwani do dziś - wystarczy poczytać sobie manuala w kontekście LiveBindings) czas lansuje klikacwo zamiast porządnego kodu.
Co nie znaczy, że w Delphi nie da się pisać wysokiej jakości kodu.

Bug na bugu był w D2009, a D2007 jest jednym z najstabilniejszych IDE.

D2007 może był w miarę stabilny (też mi się wywalił parę razy), ale tu mówimy o XE7.

Rozumiem, że żadne inne IDE nie wywaliło Ci się nigdy? Naprawdę, mam w to uwierzyć?
Idąc dalej - programy napisane w Java nie zawierają błedów? ;-)

Bug na bugu jest nadal w podstawowych elementach takich jak kompilator - wystarczy popatrzeć na tickety QC.

http://qc.embarcadero.com/wc/qcmain.aspx?d=128648 (kompilator usuwa prawidłowy kod, przy wyłączonych optymalizacjach)
http://qc.embarcadero.com/wc/qcmain.aspx?d=124878 (kompilator generuje inny semantycznie kod przy włączonych optymalizacjach)

To nie są jakieś przypadki brzegowe w egzotycznych miejscach specyfikacji języka. To są bugi w podstawowych miejscach jak przypisania i pętle.

A, no i zdarzają sie takie kwiatki:
http://stackoverflow.com/questions/27701294/why-does-delphi-xe7-ide-hangs-and-fails-on-out-of-memory-exception
To pewnie dlatego, że Delphi napisano w Javie i ten wredny GC powoduje 266x większe zużycie pamięci... :D

Nie, to dlatego że część IDE napisano w .NET i uj wie po co. I to jest prawda z tym .NETem ;-)
Z mojego doświadczenia jasno wynika, że większość problemów ze stabilnością IDE wynika z instalacji zabugowanych komponentów firm trzecich/open source.

Ależ ja nie twierdzę, że błędów nie ma. Są, a niektóre są... nie będę się wyrażał. Na szczęście, jest z tym coraz lepiej.
Wszędzie są błędy - mam Ci powklejać podobne ze światka Java? Po co, sam doskonale o nich wiesz.

W D2010 było znacznie lepiej, ale dalej sypało się na typach generycznych.

Kompilatory C++ miały problemy ze znacznie potężniejszym systemem template'ów (którym można zrobić wszystko co w mocno ograniczonych genericsach Delphi) tak gdzieś koło roku 1998. Później już nie miały.

Bo i nie o wydajność tam chodziło, tylko o rozwinięcie języka, który utknął na prawie 10 lat!

No utknął i to właśnie widać, a przyszłość jest niepewna. A co ja innego pisałem? Czy warto odświeżać sobie wiedzę na temat języka, który utknął na 10 lat i teraz desperacko próbuje gonić inne technologie dodając na szybko rzeczy, które konkurencja miała 10-15 lat temu (genericsy, metody anonimowe itp.), wprowadzając przy okazji krytyczne błędy w podstawowych funkjcach?

Moim zdaniem warto się uczyć technologii, które są innowacyjne, które wprowadzają nowości i od których inni ściągają pomysły. Ewentualnie takich, które ściągają, ale robią to dobrze i wprowadzają własne ulepszenia (jak C# ściągał z Javy, a teraz Java ściąga z C#).

Delphi i platformy mobilne - wystarczająco innowacyjnie?
Jeden kod i GUI na wszystkie platformy, to piękna idea jest... Rozumiem, że to nie jest innowacyjne?

wloochacz napisał(a):

Rozumiem, że na bazy danych już się nie bijemy? Dlaczego, wkroczyłeś na grząski teren?

Co miałem powiedzieć w tej kwestii, to powiedziałem. Dalsza dyskusja na ten temat to niepotrzebny flame, na dodatek raczej off-topic. Ale skoro już tak bardzo chcesz dyskutować na ten temat, to proszę bardzo. W kwestii sterowników do Mongo:

• sterownik od Synopse: po pierwsze to nie jest sterownik, a cały ORM z własnym zestawem konektorów, zresztą pisany głównie pod SQLite, MongoDB jest tam tylko jednym z wielu dodatków. Po drugie jest na GPL/LGPL, czyli bardzo mało przyjaznej licencji dla korporacji. Cokolwiek chcę zmienić, to muszę publikować - wiele firm nawet mocno promujących open-source banuje soft na *GPL. Po trzecie tego GPLa można by nawet przeboleć, gdyby firma oferowała wsparcie techniczne i licencję komercyjną, ale nic takiego na ich stronie nie znalazłem (synopse.info). Tymczasem link na ich stronie "get support" kieruje na... forum. Ba, oni nawet normalnej strony nie mają, tylko mają stronę projektu OSS oraz jakiegoś bloga.

• sterownik do MongoDB na GitHubie (https://github.com/gerald-lindsly/mongo-delphi-driver): chyba brak wersji 64-bitowej, a w każdym raziennie wiadomo, bo każą kompilować z flagą -m32, dokumentacja szczątkowa (odsyłają do kodu źródłowego unit testów, całych trzech - to jakiś joke chyba), nie wiadomo nawet z którymi wersjami mongo to działa, aktywność projektu na poziomie 0, zero pull requestów, 5 bugów, 4 zamknięte, jeden wisi od 2012 roku, ostatni commit 2 lata temu, większość kodu niezmieniana od 3 lat... Serio? Ten sterownik w praktyce nie istnieje, nawet dla projektów hobbystycznych. Na miejscu twórców MongoDB usunąłbym go z listy natychmiast, bo ludzie niepotrzebnie czas tracą na oglądanie tego.

• pebongo - niedokończony sterownik (MongoDB oficjalnie określa go jako "early stage"), ostatnia aktywność rok temu - ktoś zmienił README, ostatnia realna aktywność 2 lata temu... J.w. projekt praktycznie nie istnieje.

• TMongoWire - już lepiej, jakaś mizerna aktywność jest, choć 10 zgłoszonych bugów, to trochę mało. Dokumentacja szczątkowa. Wsparcia komercyjnego brak, popularność projektu nikła, projekt rozwijany przez jedną osobę.

• Alcinoe - nie wspiera nowszych wersji Delphi (XE5+), wersja 64-bitowa jest powolna wg oficjalnej dokumentacji, licencja GPL (nawet nie LGPL), brak wsparcia technicznego, brak dokumentacji, poza szczątkowym wiki na SF

Podsumowując - dla najpopularniejszego NoSQLa jest straszna mizeria. A jak jest dla innych? Jeszcze gorzej:

• Cassandra - jest PasCassa, do łączenia się używa Thrift/RPC, który jest praktycznie "deprecated" i będzie usunięty w przyszłych wersjach Cassandry, nie posiada większości funkcji dostępnych w sterownikach oficjalnych, ostatnia aktualizacja w 2013 roku
• CouchBase - nie znalazłem sterownika, przynajmniej Google nic o takowym nie wie na pierwszej stronie
• HBase - j.w. nie znalazłem nic :(
• na bardziej niszowe systemy już nie patrzyłem - ale praktycznie mam 100% pewności, że albo nie ma sterownika, a jak jest to jakiś hobbystyczny, niekompletny projekt napisany przez jedną osobę

Delphi też zdaje się ignorować całkowicie systemy MapReduce, czyli jeśli chcesz robić poważniejsze analizy danych, to musisz się nauczyć innego języka:

• Apache Hadoop - nie ma nic
• Apache Spark - nie ma nic

A jeśli uważasz, że wyciągam tu jakieś niszowe NoSQLowe rozwiązania, aby specjalnie pogrążyć Delphi, to weźmy jakiegoś popularnego RDBMSa spoza wielkiej trójki. Np. IBM DB/2. Google zdaje się nie wiedzieć nic na ten temat, ale w końcu natrafiłem na wątek: http://codeverge.com/embarcadero.delphi.firedac/firedac-native-driver-support-for/1989029 Serio? Tylko ODBC?
Tymczasem dla innych jezyków: http://www-01.ibm.com/support/docview.wss?uid=swg21385217 (pierwszy wynik w Google dla "IBM DB/2 client drivers").

Czytałeś w ogóle odpowiedź na to zapytanie w SO? Nie czytałeś, bo gdybyś czytał ze zrozumieniem, to wiedziałbyś skąd takie różnice i dlaczego wersja 64bit Delphi jest w tych benchmarkach szybsza od wersji 32bit. I być może szybsza od Javy.

Czytałem i dalej w tym samym wątku autor napisał, że sprawdział ten kod na 64-bitowej wersji i, owszem, jest minimalnie szybszy, ale nadal jest znacznie wolniejszy od Javy.

Zrozum w końcu, że Delphi to nie Java.

Nigdy nie twierdziłem inaczej. Ale nie chodzi o to, że Delphi to nie Java, tylko że Delphi ma słabszy kompilator od Javy, .NET, C i C++. Czy ma to znaczenie dla konkretnego projektu, czy nie, to inna kwestia, ale wkurza mnie jak ktoś powtarza mity o rzekomej wydajności aplikacji pisanych w Delphi. Nigdy kompilatory od Borlanda nie produkowały kodu wysokiej jakości na równi z kompilatorami innych firm (Microsoft, Intel; później również GCC). Przy czym kiedyś różnice były mniejsze, teraz się powiększyły, bo inne kompilatory poszły do przodu, a Delphi stało w miejscu i nadal nie umie nawet porządnie kodu inline'ować.

Jedno i drugie ma swoje ograniczenia i w jednym i drugim, coś można zrobić inaczej.
Równie dobrze mógłbym napisać, że Java jest do bani, bo w Delphi mogę napisać zwykłą procedurę (nie metodę), która jest inline.

Problem w tym, że ja mogę napisać w Javie zwykłą procedurę (nie metodę), która będzie inline...

To taki sam merytoryczny argument, jak Twoje.

Brak konkretnych mechanizmów optymalizacji w kompilatorze na podstawie oficjalnej dokumentacji to dla Ciebie nie jest merytoryczny argument?

A gdzie ja napisałem, że Delphi ma lepszy kompilator od Javy? A tak, napisałem - ma szybszy kompilator. Bardzo szybki, ale czy lepszy? Nie sądzę. Natomiast szybkośc kompilacji wpływa na wygodę użytkownika, a Delphi jest po prostu wygodne.

Zaraz, zaraz, to ja pisałem o tym wyraźnie że Delphi produkuje kod gorszej jakości niż Java. Ty napisałeś "Jasneee...." czyli polemizowałeś z moim twierdzeniem dot. kodu wynikowego. Teraz zmieniasz temat. Ale ok, nie bedę się spierał, czy Java ma szybszy kompilator, czy Delphi, bo obydwa są tu w czołówce. Dopóki klikam "Run" i nie czekam na kompilację ani sekundy, nie ma to znaczenia. A na wygodę programisty to bardziej niż szybka kompilacja wpływa sprawnie działające sprawdzanie błędów w kodzie w czasie pisania. Coś, czego Delphi nadal nie opanowało - EI nie zawsze podkreśla błędy tam gdzie są, a za to często podkreśla błędy, tam gdzie ich nie ma (nie mówiąc już o tym, że w pewnych wersjach Delphi trzeba było EI wyłączyć całkowicie, bo lagował / wieszał / crashował IDE / miał wycieki pamięci).

Po drugie z narzutem 233x i 300x to jest oczywista bzdura.

Widziałeś testy? Wykresy? Rozumiem, że to bzdura... Z mojego punktu widzenia to nie jest bzdura, bo zaczyna wchodzić w tę technologię na poważnie i widzę jej ogromny potencjał i nie boję się skalowania tego rozwiązania. Nie sztuką jest dodać kolejny klaster serwerów do obsługi kolejnego tysiąca żądań. Pewnie, Java zrobi to za mnie, bo nie muszę się zastanawiać jak coś zrobi - robi się automagicznie i już.

Widziałem testy i widziałem wykresy, bo robię optymalizację systemów opartych na Javie niemal na codzień. Z wyjątkiem patologicznych przypadków użycia pamięci przez aplikację (tj. aplikację produkującą śmieci w tempie liczonym w GB/s), GC niemal nigdy nie jest problemem.

To dlaczego, praktycznie z definicji, zapotrzebowanie na pomięć serwerów aplikacyjnych napisanych w Java jest tak ogromne? Z czego to wynika?

Z domyślnej konfiguracji dostosowanej do ich przeznaczenia oraz dużej ilości kodu, który ładują. Przecież serwerów aplikacyjnych nie stawia się na telefonie z 2 GB RAM, tylko na serwerach z 64-512 GB RAM. Ale jak ktoś chce i troszkę przytnie ustawienia, to serwer apikacyjny albo system baz danych napisany w Javie spokojnie można postawić na Raspberry Pi z 512 MB RAM na wszystko (włączając OS).

Poza tym Twoje serwery napisane w Delphi mają duże szanse zajmować nieskończenie wiele więcej RAMu. Wystarczy mały memory-leak, a w Delphi o to bardzo łatwo

No proszę Cię! Powinieneś jeszcze dodać, że równie łatwo zrobić w Delphi błąd krytyczny (tzw. AV, czyli Access Violation) w przypadku kiedy weźmiemy obiekt, który nie został zainicjowany i coś tam będziemy chcieli z nim zrobić - np. wywołać jego metodę.
I to jest oczywista bzdura.
Równie łatwo można sobie palec rozwalić młotkiem - to znaczy, że mam nie używać młotka do wbijania gwoździ tylko postawić fabrykę, która za mnie automagicznie zrealziuje zadanie? Bo tak soię to robi w Java... Ale ja chciałem tylko gwóźdź wbić!

Porównanie trochę głupie, bo zarówno Java, .NET jak i Delphi służą do tego samego celu - do pisania aplikacji biznesowych. Ty chcesz z tym młotkiem iść na budowę wysokościowca, na dodatek bez kasku. Najwyżej zrobisz unik jak coś będzie spadało Ci na głowę :D

W Delphi nie ma GC. Kropka.
I nie ma sensu dyskutować, czy to dobrze czy źle.
GC ma ogromną rzeszę zwolenników i spore grono przeciwników. Coś za coś.

Zwolennicy/przeciwnicy mało mnie interesują. Mnie interesują naukowo potwierdzone fakty. A badania naukowe wyraźnie stwierdzają, że oprogramowanie pisane w językach zarządzanych ma mniejszą liczbę defektów, niż pisane w językach niezarządzanych. Delphi nie wzięto pod uwagę, ale spokojnie można przyjąć, że plasowałoby się gdzieś między C i C++:

http://macbeth.cs.ucdavis.edu/lang_study.pdf

Podobnie języki funkcyjne są lepsze od imperatywnych. Platformy Java/.NET mają pod tym względem bardzo dużo do zaoferowania (F#, Scala, Clojure) - w Delphi jesteś skazany na archaicznego Pascala na sterydach.

W Delphi nie pisze się serwerów w takiej ilości jak w Java, bo do tego jest wymagana daleko większa wiedza i doświadczenie niż klikanie formatek. Co powoduje, że trudniej znaleźć programistów do takiego zadania. A w Java - proszę, bierzesz 10 studentów albo 50, biorą gotowe biblioteki, składają to do jakoś kupy, nie martwiąc się przy tym pamięcią (no bo przecież jest GC) i jakoś to działa. A jak zaczyna zwalniać, to stawia się kolejny klaster i jest git. Siła nowoczesnej technologii :)

No jasne, zwłaszcza Google, Apple, Twitter, Facebook, Sony, Walmart czy eBay piszą swoje serwery Javowe studentami, a jak coś nie wyrabia, to nie problem - przecież stać ich na dorzucenie 10000 serwerów w ciągu jednego dnia :D

Rozumiem, że żadne inne IDE nie wywaliło Ci się nigdy? Naprawdę, mam w to uwierzyć?

Kiedyś Eclipse. Przez błędy w kodzie natywnym wywoływanym przez SWT.
InteliJ IDEA - nigdy. Owszem, zdarzyły się drobne błędy - błędy objawiające się tym, że IDE sygnalizowało jakiś błąd wewnętrzny, oferowało automatyczną opcję abyt zgłosić to do JetBrains, ale po kliknięciu OK zawsze działało dalej, najwyżej jakaś funkcja nie była dostępna / nie działała. Przy czym takie rzeczy to w wersjach EAP / unstable, na których pracuję praktycznie non stop. Tzn. EAP jest tak stabilne, że okazyjnie raz na pół roku jakiś mało krytyczny błąd naprawdę mi nie przeszkadza.

Idąc dalej - programy napisane w Java nie zawierają błedów? ;-)

Nie rozmawiamy o błędach w aplikacjach, tylko w środowisku developerskim. Takie rzeczy jak kompilator powinny być stabilne jak skała. W Delphi nie są. Błąd w stylu "kompilator produkuje semantycznie nieprawidłowy kod" są niedopuszczalne dla wersji produkcyjnej.

Wszędzie są błędy - mam Ci powklejać podobne ze światka Java? Po co, sam doskonale o nich wiesz.

Błędy są wszędzie, ale nie podobne. Proszę, znajdź mi błąd, gdzie kompilator Javy źle skompilował przypisanie do zmiennej albo pętlę. A nawet jeśli się taki by jakimś cudem znalazł, to dla Javy jest więcej niż jeden kompilator i więcej niż jeden JVM a na dodatek te oficjalne mają otwarty kod źródłowy, więc jak komuś bardzo zależy może poprawić błąd sam lub komuś zapłacić za naprawienie. W Delphi tak nie ma - jesteś skazany na łaskę/niełaskę Embarcadero, które często wypuszcza poprawki tylko w nowej wersji i jeszcze każe sobie za nią płacić.

Moim zdaniem warto się uczyć technologii, które są innowacyjne, które wprowadzają nowości i od których inni ściągają pomysły. Ewentualnie takich, które ściągają, ale robią to dobrze i wprowadzają własne ulepszenia (jak C# ściągał z Javy, a teraz Java ściąga z C#).

Delphi i platformy mobilne - wystarczająco innowacyjnie?
Jeden kod i GUI na wszystkie platformy, to piękna idea jest... Rozumiem, że to nie jest innowacyjne?

Idea jest piękna, ale wykonanie pozostawia wiele do życzenia. Wsparcia na iOS na razie nie ma (brak kompilatora 64-bitowego), kontrolki w Androidzie też nie są natywne z Android SDK, tylko rysowane przez biblioteki Delphi. Delphi nie produkuje natywnych aplikacji na Android, bo w Androidzie natywne są aplikacje w bajtkodzie Dalvik, a nie aplikacje oparte na NDK. Efekt jest taki, że hello world na Androida waży 6 MB.

Czy jest innowacyjne? Raczej nie, bo inni mieli to wcześniej. Choćby Xamarin, Qt, JavaFX, RoboVM. Czy same klikadełka GUI w nich są lepsze od Delphi, tego nie wiem, bo nie siedzę w mobilnych, ale na pewno są oparte o lepsze języki programowania.

Krolik napisał(a):

wloochacz napisał(a):

Rozumiem, że na bazy danych już się nie bijemy? Dlaczego, wkroczyłeś na grząski teren?

Co miałem powiedzieć w tej kwestii, to powiedziałem. Dalsza dyskusja na ten temat to niepotrzebny flame, na dodatek raczej off-topic. Ale skoro już tak bardzo chcesz dyskutować na ten temat, to proszę bardzo. W kwestii sterowników do Mongo:

• sterownik od Synopse: po pierwsze to nie jest sterownik, a cały ORM z własnym zestawem konektorów, zresztą pisany głównie pod SQLite,

Po pierwsze bazujesz na nagłówkach z dokumentacji (ORM tu, SQLite tam - faktycznie jest tego w manualu pełno), a to nie jest prawda.
Tak - ma własnego ORMa.
Nie, nie trzeba korzystać z całości, można po kawałkach.
I nie - NIE jest pisany głównie pod SQLite. Tak było i jest pewien ogon w postaci nazewnictwa, ale biblioteka zmieniła się znacznie na plus. Bardzo znacznie.

MongoDB jest tam tylko jednym z wielu dodatków. Po drugie jest na GPL/LGPL, czyli bardzo mało przyjaznej licencji dla korporacji. Cokolwiek chcę zmienić, to muszę publikować - wiele firm nawet mocno promujących open-source banuje soft na *GPL. Po trzecie tego GPLa można by nawet przeboleć, gdyby firma oferowała wsparcie techniczne i licencję komercyjną, ale nic takiego na ich stronie nie znalazłem (synopse.info). Tymczasem link na ich stronie "get support" kieruje na... forum. Ba, oni nawet normalnej strony nie mają, tylko mają stronę projektu OSS oraz jakiegoś bloga.

Ciężko mi z tym dyskutować, jest jak jest. Ale to co jest, jest naprawdę bardzo dobrej jakości o niebanalnych możliwościach.

• sterownik do MongoDB na GitHubie (https://github.com/gerald-lindsly/mongo-delphi-driver): chyba brak wersji 64-bitowej, a w każdym raziennie wiadomo, bo każą kompilować z flagą -m32, dokumentacja szczątkowa (odsyłają do kodu źródłowego unit testów, całych trzech - to jakiś joke chyba), nie wiadomo nawet z którymi wersjami mongo to działa, aktywność projektu na poziomie 0, zero pull requestów, 5 bugów, 4 zamknięte, jeden wisi od 2012 roku, ostatni commit 2 lata temu, większość kodu niezmieniana od 3 lat... Serio? Ten sterownik w praktyce nie istnieje, nawet dla projektów hobbystycznych. Na miejscu twórców MongoDB usunąłbym go z listy natychmiast, bo ludzie niepotrzebnie czas tracą na oglądanie tego.

• pebongo - niedokończony sterownik (MongoDB oficjalnie określa go jako "early stage"), ostatnia aktywność rok temu - ktoś zmienił README, ostatnia realna aktywność 2 lata temu... J.w. projekt praktycznie nie istnieje.

• TMongoWire - już lepiej, jakaś mizerna aktywność jest, choć 10 zgłoszonych bugów, to trochę mało. Dokumentacja szczątkowa. Wsparcia komercyjnego brak, popularność projektu nikła, projekt rozwijany przez jedną osobę.

• Alcinoe - nie wspiera nowszych wersji Delphi (XE5+), wersja 64-bitowa jest powolna wg oficjalnej dokumentacji, licencja GPL (nawet nie LGPL), brak wsparcia technicznego, brak dokumentacji, poza szczątkowym wiki na SF

Podsumowując - dla najpopularniejszego NoSQLa jest straszna mizeria. A jak jest dla innych? Jeszcze gorzej:

• Cassandra - jest PasCassa, do łączenia się używa Thrift/RPC, który jest praktycznie "deprecated" i będzie usunięty w przyszłych wersjach Cassandry, nie posiada większości funkcji dostępnych w sterownikach oficjalnych, ostatnia aktualizacja w 2013 roku
• CouchBase - nie znalazłem sterownika, przynajmniej Google nic o takowym nie wie na pierwszej stronie
• HBase - j.w. nie znalazłem nic :(
• na bardziej niszowe systemy już nie patrzyłem - ale praktycznie mam 100% pewności, że albo nie ma sterownika, a jak jest to jakiś hobbystyczny, niekompletny projekt napisany przez jedną osobę

Delphi też zdaje się ignorować całkowicie systemy MapReduce, czyli jeśli chcesz robić poważniejsze analizy danych, to musisz się nauczyć innego języka:

• Apache Hadoop - nie ma nic
• Apache Spark - nie ma nic

A jeśli uważasz, że wyciągam tu jakieś niszowe NoSQLowe rozwiązania, aby specjalnie pogrążyć Delphi,

Poniekąd tak uważam :) Dla mnie bazy NoSQL, na dziś, to też jest egzotyka i nisza. po prostu nie mam takich potrzeb, ale i nie neguję że jest to potrzebne w innych zastosowaniach.

to weźmy jakiegoś popularnego RDBMSa spoza wielkiej trójki. Np. IBM DB/2. Google zdaje się nie wiedzieć nic na ten temat, ale w końcu natrafiłem na wątek: http://codeverge.com/embarcadero.delphi.firedac/firedac-native-driver-support-for/1989029 Serio? Tylko ODBC?
Tymczasem dla innych jezyków: http://www-01.ibm.com/support/docview.wss?uid=swg21385217 (pierwszy wynik w Google dla "IBM DB/2 client drivers").

Ten wątek traktuje o DB/2 AS-400 - i wierz mi to jest zupełna egzotyka i ma niewiele wspólnego z normalną wersją DB/2. Widziałem jedną taką instalację w dużej firmie wywodzącej się z czasów PRL; egzotyka...
Natomiast natywne wsparcie dla DB/2 jest oferowane przez FireDAC i DBExpress (oraz BDP i BDE, ale to też już egzotyka):
http://docwiki.embarcadero.com/Libraries/XE7/en/FireDAC.Phys.DB2.TFDPhysDB2DriverLink
http://www.ibm.com/developerworks/data/library/techarticle/dm-0312swart/

I tak - spora grupa implementacji sterowników FireDAC bazuje na ODBC. Też mi się wydawało, że to problem (dodatkowa warstwa i narzut) i lipa - ale tak nie jest.
Dość powiedzieć, że sam MS zabił OLEDB na rzecz ODBC, ciekawe prawda?
Dlatego też, SQLServer Native Client for OLEDB został określony jako deprecated
https://msdn.microsoft.com/en-us/library/hh967418.aspx

Czytałeś w ogóle odpowiedź na to zapytanie w SO? Nie czytałeś, bo gdybyś czytał ze zrozumieniem, to wiedziałbyś skąd takie różnice i dlaczego wersja 64bit Delphi jest w tych benchmarkach szybsza od wersji 32bit. I być może szybsza od Javy.

Czytałem i dalej w tym samym wątku autor napisał, że sprawdział ten kod na 64-bitowej wersji i, owszem, jest minimalnie szybszy, ale nadal jest znacznie wolniejszy od Javy.

Widzę, że zrozumienie zależy od punktu siedzenia, no więc autor napisał tam tak:
"I suspect comparable to Java JITted executable.
And, in respect to Java, any Delphi executable will use much less memory than the JVM, so here, Delphi executables are perfectly on the track!"

Powiedz, gdzie tam jest napisane, że "[...] (kod) nadal jest znacznie wolniejszy od Javy"?

Zrozum w końcu, że Delphi to nie Java.

Nigdy nie twierdziłem inaczej. Ale nie chodzi o to, że Delphi to nie Java, tylko że Delphi ma słabszy kompilator od Javy, .NET, C i C++. Czy ma to znaczenie dla konkretnego projektu, czy nie, to inna kwestia, ale wkurza mnie jak ktoś powtarza mity o rzekomej wydajności aplikacji pisanych w Delphi. Nigdy kompilatory od Borlanda nie produkowały kodu wysokiej jakości na równi z kompilatorami innych firm (Microsoft, Intel; później również GCC). Przy czym kiedyś różnice były mniejsze, teraz się powiększyły, bo inne kompilatory poszły do przodu, a Delphi stało w miejscu i nadal nie umie nawet porządnie kodu inline'ować.

Jedno i drugie ma swoje ograniczenia i w jednym i drugim, coś można zrobić inaczej.
Równie dobrze mógłbym napisać, że Java jest do bani, bo w Delphi mogę napisać zwykłą procedurę (nie metodę), która jest inline.

Problem w tym, że ja mogę napisać w Javie zwykłą procedurę (nie metodę), która będzie inline...

To taki sam merytoryczny argument, jak Twoje.

Brak konkretnych mechanizmów optymalizacji w kompilatorze na podstawie oficjalnej dokumentacji to dla Ciebie nie jest merytoryczny argument?

A gdzie ja napisałem, że Delphi ma lepszy kompilator od Javy? A tak, napisałem - ma szybszy kompilator. Bardzo szybki, ale czy lepszy? Nie sądzę. Natomiast szybkość kompilacji wpływa na wygodę użytkownika, a Delphi jest po prostu wygodne.

Zaraz, zaraz, to ja pisałem o tym wyraźnie że Delphi produkuje kod gorszej jakości niż Java. Ty napisałeś "Jasneee...." czyli polemizowałeś z moim twierdzeniem dot. kodu wynikowego. Teraz zmieniasz temat. Ale ok, nie bedę się spierał, czy Java ma szybszy kompilator, czy Delphi, bo obydwa są tu w czołówce. Dopóki klikam "Run" i nie czekam na kompilację ani sekundy, nie ma to znaczenia.

OK. A wstawki asemblerowe w kodzie Delphi się liczą jako Delphi czy nie? :D
Prawda - asm to nie Delphi, ale w samym RTLu jest sporo kodu w asm.

A na wygodę programisty to bardziej niż szybka kompilacja wpływa sprawnie działające sprawdzanie błędów w kodzie w czasie pisania.
Nie zgadzam się z tym po całości, czyli z tym sprawdzaniem błędów podczas pisania.
Coś, czego Delphi nadal nie opanowało - EI nie zawsze podkreśla błędy tam gdzie są, a za to często podkreśla błędy, tam gdzie ich nie ma (nie mówiąc już o tym, że w pewnych wersjach Delphi trzeba było EI wyłączyć całkowicie, bo lagował / wieszał / crashował IDE / miał wycieki pamięci).

Racja, tak było i nadal są z tym problemy. Osobiście uważam, że to owczy pęd za innymi rozwiązaniami, które tak naprawdę niewiele wnosi do samego pisania kodu.
Jednak jest pewna różnica pomiędzy sprawdzaniem ortografii a kodem podczas pisania, a IDE to nie procesor tekstu.
Ale to moja opinia i nie musisz się z nią zgadzać; mnie po prostu ten mechanizm przeszkadza i zawsze go wyłączam.

Po drugie z narzutem 233x i 300x to jest oczywista bzdura.

Widziałeś testy? Wykresy? Rozumiem, że to bzdura... Z mojego punktu widzenia to nie jest bzdura, bo zaczyna wchodzić w tę technologię na poważnie i widzę jej ogromny potencjał i nie boję się skalowania tego rozwiązania. Nie sztuką jest dodać kolejny klaster serwerów do obsługi kolejnego tysiąca żądań. Pewnie, Java zrobi to za mnie, bo nie muszę się zastanawiać jak coś zrobi - robi się automagicznie i już.

Widziałem testy i widziałem wykresy, bo robię optymalizację systemów opartych na Javie niemal na codzień. Z wyjątkiem patologicznych przypadków użycia pamięci przez aplikację (tj. aplikację produkującą śmieci w tempie liczonym w GB/s), GC niemal nigdy nie jest problemem.

To dlaczego, praktycznie z definicji, zapotrzebowanie na pomięć serwerów aplikacyjnych napisanych w Java jest tak ogromne? Z czego to wynika?

Z domyślnej konfiguracji dostosowanej do ich przeznaczenia oraz dużej ilości kodu, który ładują.

Z dużej ilości **niepotrzebnego **kodu, który ładują.
Ale OK - w Delphi jest podobnie, wystarczy porównać np. mORMota z DataSnapem.

Przecież serwerów aplikacyjnych nie stawia się na telefonie z 2 GB RAM, tylko na serwerach z 64-512 GB RAM. Ale jak ktoś chce i troszkę przytnie ustawienia, to serwer apikacyjny albo system baz danych napisany w Javie spokojnie można postawić na Raspberry Pi z 512 MB RAM na wszystko (włączając OS).

Ale to już nie jest ta sama Java, tylko "Java SE Embedded" prawda?

Poza tym Twoje serwery napisane w Delphi mają duże szanse zajmować nieskończenie wiele więcej RAMu. Wystarczy mały memory-leak, a w Delphi o to bardzo łatwo

No proszę Cię! Powinieneś jeszcze dodać, że równie łatwo zrobić w Delphi błąd krytyczny (tzw. AV, czyli Access Violation) w przypadku kiedy weźmiemy obiekt, który nie został zainicjowany i coś tam będziemy chcieli z nim zrobić - np. wywołać jego metodę.
I to jest oczywista bzdura.
Równie łatwo można sobie palec rozwalić młotkiem - to znaczy, że mam nie używać młotka do wbijania gwoździ tylko postawić fabrykę, która za mnie automagicznie zrealziuje zadanie? Bo tak soię to robi w Java... Ale ja chciałem tylko gwóźdź wbić!

Porównanie trochę głupie, bo zarówno Java, .NET jak i Delphi służą do tego samego celu - do pisania aplikacji biznesowych. Ty chcesz z tym młotkiem iść na budowę wysokościowca, na dodatek bez kasku. Najwyżej zrobisz unik jak coś będzie spadało Ci na głowę :D

Yhm. Nie skomentuję, bo widać nie zrozumiałeś. Albo nie chcesz zrozumieć.

W Delphi nie ma GC. Kropka.
I nie ma sensu dyskutować, czy to dobrze czy źle.
GC ma ogromną rzeszę zwolenników i spore grono przeciwników. Coś za coś.

Zwolennicy/przeciwnicy mało mnie interesują. Mnie interesują naukowo potwierdzone fakty. A badania naukowe wyraźnie stwierdzają, że oprogramowanie pisane w językach zarządzanych ma mniejszą liczbę defektów, niż pisane w językach niezarządzanych. Delphi nie wzięto pod uwagę, ale spokojnie można przyjąć, że plasowałoby się gdzieś między C i C++:

http://macbeth.cs.ucdavis.edu/lang_study.pdf

Przejrzałem pobieżnie, ale nie wydaje mi się to takie oczywiste - muszę doczytać dokładnie.

Podobnie języki funkcyjne są lepsze od imperatywnych. Platformy Java/.NET mają pod tym względem bardzo dużo do zaoferowania (F#, Scala, Clojure) - w Delphi jesteś skazany na archaicznego Pascala na sterydach.

E tam, zależy do czego; daleki jestem od takiego generalizowania.
Poza Delphi nie posiada maszyny wirtualnej i pewne elementy (metaprogramowania) z zakresu programowania aspektowego (ok, trochę odszedłem od tematu) jest tu po prostu niemożliwe do zrobienia, albo można to zrobić ale znacznie większym nakładem sił niż w Java/C#.
Ale to tak jakby mieć pretensje, że samochód nie chce pływać...

W Delphi nie pisze się serwerów w takiej ilości jak w Java, bo do tego jest wymagana daleko większa wiedza i doświadczenie niż klikanie formatek. Co powoduje, że trudniej znaleźć programistów do takiego zadania. A w Java - proszę, bierzesz 10 studentów albo 50, biorą gotowe biblioteki, składają to do jakoś kupy, nie martwiąc się przy tym pamięcią (no bo przecież jest GC) i jakoś to działa. A jak zaczyna zwalniać, to stawia się kolejny klaster i jest git. Siła nowoczesnej technologii :)

No jasne, zwłaszcza Google, Apple, Twitter, Facebook, Sony, Walmart czy eBay piszą swoje serwery Javowe studentami, a jak coś nie wyrabia, to nie problem - przecież stać ich na dorzucenie 10000 serwerów w ciągu jednego dnia :D

Dokładnie tak!

Rozumiem, że żadne inne IDE nie wywaliło Ci się nigdy? Naprawdę, mam w to uwierzyć?

Kiedyś Eclipse. Przez błędy w kodzie natywnym wywoływanym przez SWT.
InteliJ IDEA - nigdy. Owszem, zdarzyły się drobne błędy - błędy objawiające się tym, że IDE sygnalizowało jakiś błąd wewnętrzny, oferowało automatyczną opcję abyt zgłosić to do JetBrains, ale po kliknięciu OK zawsze działało dalej, najwyżej jakaś funkcja nie była dostępna / nie działała. Przy czym takie rzeczy to w wersjach EAP / unstable, na których pracuję praktycznie non stop. Tzn. EAP jest tak stabilne, że okazyjnie raz na pół roku jakiś mało krytyczny błąd naprawdę mi nie przeszkadza.

Idąc dalej - programy napisane w Java nie zawierają błedów? ;-)

Nie rozmawiamy o błędach w aplikacjach, tylko w środowisku developerskim. Takie rzeczy jak kompilator powinny być stabilne jak skała. W Delphi nie są. Błąd w stylu "kompilator produkuje semantycznie nieprawidłowy kod" są niedopuszczalne dla wersji produkcyjnej.

Wszędzie są błędy - mam Ci powklejać podobne ze światka Java? Po co, sam doskonale o nich wiesz.

Błędy są wszędzie, ale nie podobne. Proszę, znajdź mi błąd, gdzie kompilator Javy źle skompilował przypisanie do zmiennej albo pętlę. A nawet jeśli się taki by jakimś cudem znalazł, to dla Javy jest więcej niż jeden kompilator i więcej niż jeden JVM a na dodatek te oficjalne mają otwarty kod źródłowy, więc jak komuś bardzo zależy może poprawić błąd sam lub komuś zapłacić za naprawienie. W Delphi tak nie ma - jesteś skazany na łaskę/niełaskę Embarcadero, które często wypuszcza poprawki tylko w nowej wersji i jeszcze każe sobie za nią płacić.

Prawda - jestem skazany na niełaskę.
Nieprawda, bo zmienia się polityka wsparcia; poprawki będą utrzymywane do 2,5 roku od daty premiery danej wersji środowiska.
Bo to co było do tej pory (czyli nowa wersja co pół roku dostępna jak upgrade z $$$), to skandal.

Moim zdaniem warto się uczyć technologii, które są innowacyjne, które wprowadzają nowości i od których inni ściągają pomysły. Ewentualnie takich, które ściągają, ale robią to dobrze i wprowadzają własne ulepszenia (jak C# ściągał z Javy, a teraz Java ściąga z C#).

Delphi i platformy mobilne - wystarczająco innowacyjnie?
Jeden kod i GUI na wszystkie platformy, to piękna idea jest... Rozumiem, że to nie jest innowacyjne?

Idea jest piękna, ale wykonanie pozostawia wiele do życzenia.

Żadne tego typu rozwiązanie nie jest idealne.
A Delphi ma tu sporo do zaoferowania.

Wsparcia na iOS na razie nie ma (brak kompilatora 64-bitowego), kontrolki w Androidzie też nie są natywne z Android SDK, tylko rysowane przez biblioteki Delphi.

Wsparcie iOS z kompilatorem 64bitowym jest od wersji XE8.
http://www.embarcadero.com/press-releases/major-new-release-rad-studio-xe8

Kontrolki nie są natwyne, ale mogą być. I to nie jest żadna tam jakaś trudność. Wszystko zależy od tego, czy naprawdę komuś na tym zależy - mi, niespecjalnie.

Delphi nie produkuje natywnych aplikacji na Android, bo w Androidzie natywne są aplikacje w bajtkodzie Dalvik, a nie aplikacje oparte na NDK. Efekt jest taki, że hello world na Androida waży 6 MB.

Nie wiem czy zauważyłeś, ale następuje powrót do kompilacji do kodu natywnego.
Chyba w wersji 4.4 Andka pojawiła się możliwość odpalania systemu i usług jako natywnych (nie pomnę szczegółów w tej chwili, ale można znaleźć), a nie jako app Dalivikowych. Dlaczego? Ze względu na wydajność właśnie.
Możemy się spierać co to znaczy natywny, dla mnie to jest właśnie NDK czyli Native Development Kit :)

Czy jest innowacyjne? Raczej nie, bo inni mieli to wcześniej. Choćby Xamarin, Qt, JavaFX, RoboVM. Czy same klikadełka GUI w nich są lepsze od Delphi, tego nie wiem, bo nie siedzę w mobilnych, ale na pewno są oparte o lepsze języki programowania.

Właśnie - nie siedzisz, a zlotu ptaka to faktycznie wygląda podobnie. Tylko tak to już w naszej branży jest, że diabełek tkwi w szczegółach.
I o ile w Delphi da się napisać faktyczną aplikację multiplatform z dokładnie tym samym kodem i UI, to w Xamarin jest to niemożliwe.
Są niezbędne zmiany, mniejsze lub większe. Oczywiście nie jest to żaden problem dla większej firmy, która posiada odpowiednie kompetencje dla różnych OSów.
Delphi poszło inną drogą, która jest wygodniejsza dla mniejszych zespołów - w efekcie czego "hello world" waży 6 MB.
Mnie to zupełnie nie przeszkadza, dla mnie to tylko 6 MB, zwłaszcza że appka potem nie rozrasta się znacznie w miarę dodawania nowych funkcjonalności ;-)

Czyli podsumowując kwestię baz danych: do najpopularniejszych relacyjnych baz danych działa dobrze (do tych, które są obsługiwane w samym FireDac), dla popularnych NoSQLi jak Mongo czy Cassandra można liczyć na częściową integrację projektami opensource bez komercyjnego wsparcia technicznego, natomiast dla bardziej egzotycznych jak IBM DB/2 na AS/400, Couchbase lub HBase jest zupełna lipa. Tymczasem w przypadku .NET, Javy i C niemal każdy producent bazodanowy wypuszcza własne, oficjalne sterowniki, ze wsparciem technicznym, które pozwalają wykorzystać pełną funcjonalność i wydajność systemu bazy danych, robione przez ludzi, którzy znają wewnętrzną strukturę silnika systemu bazy danych. Dla mnie to jest jednak dość duża różnica. Np. miałem okazję używać otwartych sterowników do Cassandry wypuszczonych przez firmy trzecie i porównać to sobie z otwartymi sterownikami oficjalnymi - jest to przepaść w jakości kodu, kompletności funkcji jak i wsparcia technicznego.

Widzę, że zrozumienie zależy od punktu siedzenia, no więc autor napisał tam tak:
"I suspect comparable to Java JITted executable.
And, in respect to Java, any Delphi executable will use much less memory than the JVM, so here, Delphi executables are perfectly on the track!"

Powiedz, gdzie tam jest napisane, że "[...] (kod) nadal jest znacznie wolniejszy od Javy"?

Pierwszy komentarz w pierwszej odpowiedzi (tej zaakceptowanej):
"In fact the code emitted by the Delphi x64 compiler for this example is no faster than that emitted by the x86 compiler."
-- David Hefferman

I to akurat jest dość zrozumiałe, bo z samego faktu, że kod jest 64-bitowy nie wynika automatycznie, że będzie działał szybciej. Zwłaszcza jeśli kompilator jest ubogi w optymalizacje.

OK. A wstawki asemblerowe w kodzie Delphi się liczą jako Delphi czy nie? :D
Prawda - asm to nie Delphi, ale w samym RTLu jest sporo kodu w asm.

Jeżeli w RTLu jest kod w asm, to jest to kolejny dowód, że kompilator Delphi jest słaby. Po co mieliby robić wstawki asemblerowe, gdyby kompilator produkował optymalny kod? Poza tym, jeśli masz w kodzie wstawki asemblerowe, to zapomnij o tym co napisałeś dalej - jeden kod na wszystkie platformy.

A na wygodę programisty to bardziej niż szybka kompilacja wpływa sprawnie działające sprawdzanie błędów w kodzie w czasie pisania.

Nie zgadzam się z tym po całości, czyli z tym sprawdzaniem błędów podczas pisania. (...)
sobiście uważam, że to owczy pęd za innymi rozwiązaniami, które tak naprawdę niewiele wnosi do samego pisania kodu.
Jednak jest pewna różnica pomiędzy sprawdzaniem ortografii a kodem podczas pisania, a IDE to nie procesor tekstu.
Ale to moja opinia i nie musisz się z nią zgadzać; mnie po prostu ten mechanizm przeszkadza i zawsze go wyłączam.

Może nie doceniasz użyteczności tego, bo miałeś do czynienia ze słabym sprawdzaniem kodu? Niedorobiony podkreślacz błędów faktycznie byłby bardzo denerwujący i bym go wyłączył. Ale jeśli podkreślanie błędów nie laguje przy pisaniu i jest w 100% zgodne z tym co powie kompilator, to jest bardzo duże przyspieszenie pisania. Zwłaszcza w językach, które mają silniejszy system typów niż Delphi i gdzie programuje się dużo bardziej generycznie. Bo tu nie tyle chodzi o sprawdzanie składni, a właśnie o sprawdzanie semantyczne, na poziomie systemu typów - a to bywa nietrywialne. Do tego dochodzi inteligentne podpowiadanie metod, zależne od kontekstu, które aby było wygodne, musi być bardzo szybkie i bezbłędne; jeśli byłoby powolne i niekompletne, to by tylko denerwowało i też bym wyłączył.

Z dużej ilości **niepotrzebnego **kodu, który ładują.
Ale OK - w Delphi jest podobnie, wystarczy porównać np. mORMota z DataSnapem.

To już nie jest kwestia języka, tylko tego jak ktoś projektuje aplikację. Ale, w .NET i Javie ładują moduły dynamicznie i jak sensownie zorganizujesz kod, to można zminimalizować ilość niepotrzebnego kodu. W Delphi wprawdzie można robić DLLe i je ładować dynamicznie, ale jak je ostatnio używałem, były ograniczone do eksportowania praktycznie tylko zwykłych funkcji i ich przygotowanie/używanie wiązało się z dodatkową pracą po stronie programisty.

Przecież serwerów aplikacyjnych nie stawia się na telefonie z 2 GB RAM, tylko na serwerach z 64-512 GB RAM. Ale jak ktoś chce i troszkę przytnie ustawienia, to serwer apikacyjny albo system baz danych napisany w Javie spokojnie można postawić na Raspberry Pi z 512 MB RAM na wszystko (włączając OS).

Ale to już nie jest ta sama Java, tylko "Java SE Embedded" prawda?

Ta sama Java. Java Embedded to Java działająca na np. kartach inteligentnych albo w amplitunerach.
W przypadku Raspberry Pi aplikacji nie trzeba rekompilować ani inaczej pakować, jedynie uważać na ustawienia pamięci - wiele serwerów ma domyślnie skonfigurowane np. buforowanie albo wielkości pul wątków z myślą o dużej maszynie serwerowej. Na małym sprzęcie trzeba to poprzycinać.

Podobnie języki funkcyjne są lepsze od imperatywnych. Platformy Java/.NET mają pod tym względem bardzo dużo do zaoferowania (F#, Scala, Clojure) - w Delphi jesteś skazany na archaicznego Pascala na sterydach.

E tam, zależy do czego; daleki jestem od takiego generalizowania.

Ja też i właśnie na platformie .NET i Java mam wybór - ciekawych i popularnych języków na te platformy jest przynajmniej kilka (wszystkich jest kilkaset na obie platformy, ale większość bardzo niszowa). W przypadku Delphi wybór jest chyba tylko między Delphi i niezbyt zgodnym ze standardem C++ (chyba że się coś ostatnio ruszyło, ale odkąd pamiętam, Borland traktował C++ po macoszemu).

No jasne, zwłaszcza Google, Apple, Twitter, Facebook, Sony, Walmart czy eBay piszą swoje serwery Javowe studentami, a jak coś nie wyrabia, to nie problem - przecież stać ich na dorzucenie 10000 serwerów w ciągu jednego dnia :D

Dokładnie tak!

Owszem, stać ich, ale to jest problem. Te firmy nie mają pieniędzy na wyrzucanie w błoto. I wierz mi, wydajność ma bardzo wysoki priorytet, zwłaszcza że te farmy serwerów ciągnął niebotyczne ilości prądu.

(...) zmienia się polityka wsparcia; poprawki będą utrzymywane do 2,5 roku od daty premiery danej wersji środowiska.
Bo to co było do tej pory (czyli nowa wersja co pół roku dostępna jak upgrade z $$$), to skandal.

Dobrze wiedzieć, że ktoś wreszcie poszedł po rozum do głowy. Kiedy wypuszczą darmową wersję do zastosowań komercyjnych?

Wsparcie iOS z kompilatorem 64bitowym jest od wersji XE8.
http://www.embarcadero.com/press-releases/major-new-release-rad-studio-xe8

Ok, dzięki, niby flame, a zawsze się czegoś można dowiedzieć. :)

Kontrolki nie są natwyne, ale mogą być. I to nie jest żadna tam jakaś trudność. Wszystko zależy od tego, czy naprawdę komuś na tym zależy - mi, niespecjalnie.

Problem jest zwykle wtedy, gdy wychodzi nowa wersja iOSa / Androida i zmienia się styl kontrolek. Wtedy aplikacje w Delphi nagle zaczynają odstawać wyglądem i zchowaniem od reszty systemu. Poza tym jakoś nie wierzę, aby te rysowane kontrolki działały identycznie dobrze jak te z SDK. Kiedyś Delphi używało natywnych kontrolek na Windows i to właśnie było fajne, bo aplikacje działały i wyglądały jak aplikacje Windows, a nie paskudnie jak aplikacje napisane w Javowym Swingu.

Nie wiem czy zauważyłeś, ale następuje powrót do kompilacji do kodu natywnego.
Chyba w wersji 4.4 Andka pojawiła się możliwość odpalania systemu i usług jako natywnych (nie pomnę szczegółów w tej chwili, ale można znaleźć), a nie jako app Dalivikowych. Dlaczego? Ze względu na wydajność właśnie.
Możemy się spierać co to znaczy natywny, dla mnie to jest właśnie NDK czyli Native Development Kit :)

To jest wewnętrzny aspekt implementacyjny samego Androida. Aplikacje nadal się kompiluje do kodu pośredniego, a ART w chwili instalacji kompiluje to do kodu maszynowego. Po prostu zmienili sposób kompilacji z JIT (dość słabego) na AOT. Nadal zalecanym sposobem pisania aplikacji natywnych jest pisanie ich w Javie i używanie oficjalnego SDK. NDK jest zalecane tylko do bardzo wymagających apikacji typu gry, które muszą mieć dostęp niskopoziomowy.

Krolik napisał(a):

Czyli podsumowując kwestię baz danych: do najpopularniejszych relacyjnych baz danych działa dobrze (do tych, które są obsługiwane w samym FireDac),

Delphi nie samym FireDACiem stoi; jest mnóstwo alternatywnych bibliotek - jedne są gorsze inne bardzo dobre. Jeden są za free - inne nie.
Tak czy siak, jest tego od metra.
I tak czy siak - FireDAC to de-facto kupiony przez Embarcadero AnyDAC, na szczęście razem z kodem "kupili" też autora, bo jego rozwój ma ręce i nogi ;-)
Reasumując - wsparcie dla relacyjnych baz danych w Delphi jest dobre i bardzo dobre.

dla popularnych NoSQLi jak Mongo czy Cassandra można liczyć na częściową integrację projektami opensource bez komercyjnego wsparcia technicznego, natomiast dla bardziej egzotycznych jak IBM DB/2 na AS/400, Couchbase lub HBase jest zupełna lipa.

NoSQL Emba ostatnio zauważyła i pojawiła się taka informacja w roadmap, czyli będzie.
Osobiście o to bym kopii nie kruszył.

Tymczasem w przypadku .NET, Javy i C niemal każdy producent bazodanowy wypuszcza własne, oficjalne sterowniki, ze wsparciem technicznym, które pozwalają wykorzystać pełną funcjonalność i wydajność systemu bazy danych, robione przez ludzi, którzy znają wewnętrzną strukturę silnika systemu bazy danych.

Nie do końca się mogę tym zgodzić; co ma biblioteka do obsługi bazy danych do "wewnętrzną strukturę silnika systemu bazy danych"?
Nic lub niewiele ma; a zabić serwer bazodanowy można z dowolnego języka korzystając z dowolnej technologii.
FireDAC na platformie Windows bazuje w dużej części na sterownikach ODBC - czyli tych oficjalnych i wspieranych przez producentów RDBMS.

Dla mnie to jest jednak dość duża różnica. Np. miałem okazję używać otwartych sterowników do Cassandry wypuszczonych przez firmy trzecie i porównać to sobie z otwartymi sterownikami oficjalnymi - jest to przepaść w jakości kodu, kompletności funkcji jak i wsparcia technicznego.

No i OK - to są Twoje doświadczenia, których nie możesz automatycznie przenosić na wszystkie inne dostępne języki/technologie.
Ale zgadzam się - bazy NoSQL są traktowane przez Emba po macoszemu. Przynajmniej to tak wygląda na dzień dzisiejszy.

Widzę, że zrozumienie zależy od punktu siedzenia, no więc autor napisał tam tak:
"I suspect comparable to Java JITted executable.
And, in respect to Java, any Delphi executable will use much less memory than the JVM, so here, Delphi executables are perfectly on the track!"

Powiedz, gdzie tam jest napisane, że "[...] (kod) nadal jest znacznie wolniejszy od Javy"?

Pierwszy komentarz w pierwszej odpowiedzi (tej zaakceptowanej):
"In fact the code emitted by the Delphi x64 compiler for this example is no faster than that emitted by the x86 compiler."
-- David Hefferman

I to akurat jest dość zrozumiałe, bo z samego faktu, że kod jest 64-bitowy nie wynika automatycznie, że będzie działał szybciej. Zwłaszcza jeśli kompilator jest ubogi w optymalizacje.

I tak i nie; automatycznie to może jedynie wynikać to, że kod x64 jest wolniejszy od kodu x32 - zwłaszcza przy obsłudze typów całkowitych.
Natomiast tam chodzi o co innego - o wewnętrzną implementację typów zmiennoprzecinkowych przez kompilator Delphi, która jest wydajniejsza w przypadku kompilacji na x64. I tyle.

OK. A wstawki asemblerowe w kodzie Delphi się liczą jako Delphi czy nie? :D
Prawda - asm to nie Delphi, ale w samym RTLu jest sporo kodu w asm.

Jeżeli w RTLu jest kod w asm, to jest to kolejny dowód, że kompilator Delphi jest słaby. Po co mieliby robić wstawki asemblerowe, gdyby kompilator produkował optymalny kod? Poza tym, jeśli masz w kodzie wstawki asemblerowe, to zapomnij o tym co napisałeś dalej - jeden kod na wszystkie platformy.

Masz rację, takich cudów i haków w Delphi jet od groma. Podobnie z menadżerami pamięci - tez jest ich od groma, a kilka z nich ma naprawdę ciekawe haki.
A wszystko dlatego, że coś tam kuleje, gdzie indziej dali ciała, itd.

Ale kod dalej jest multiplatform, mimo wstawek ASM; po prostu wstawki są otoczone odpowiednimi dyrektywami. Po prostu na np. Androida jest inny kompilator i on korzysta z wersji tzw. PurePascal, a kompilator dla Win32 korzysta z wersji ASM.
Wszystko działa :)

A na wygodę programisty to bardziej niż szybka kompilacja wpływa sprawnie działające sprawdzanie błędów w kodzie w czasie pisania.

Nie zgadzam się z tym po całości, czyli z tym sprawdzaniem błędów podczas pisania. (...)
sobiście uważam, że to owczy pęd za innymi rozwiązaniami, które tak naprawdę niewiele wnosi do samego pisania kodu.
Jednak jest pewna różnica pomiędzy sprawdzaniem ortografii a kodem podczas pisania, a IDE to nie procesor tekstu.
Ale to moja opinia i nie musisz się z nią zgadzać; mnie po prostu ten mechanizm przeszkadza i zawsze go wyłączam.

Może nie doceniasz użyteczności tego, bo miałeś do czynienia ze słabym sprawdzaniem kodu? Niedorobiony podkreślacz błędów faktycznie byłby bardzo denerwujący i bym go wyłączył.

Może i nie miałem, a może po prostu tego nie lubię; lata nawyków robią swoje.

Ale jeśli podkreślanie błędów nie laguje przy pisaniu i jest w 100% zgodne z tym co powie kompilator, to jest bardzo duże przyspieszenie pisania. Zwłaszcza w językach, które mają silniejszy system typów niż Delphi i gdzie programuje się dużo bardziej generycznie.

Ciekawość - a jaki to język ma dużo silniejszy system typów niż w Delphi?

Bo tu nie tyle chodzi o sprawdzanie składni, a właśnie o sprawdzanie semantyczne, na poziomie systemu typów - a to bywa nietrywialne. Do tego dochodzi inteligentne podpowiadanie metod, zależne od kontekstu, które aby było wygodne, musi być bardzo szybkie i bezbłędne; jeśli byłoby powolne i niekompletne, to by tylko denerwowało i też bym wyłączył.

Co do wsparcia IDE dla kodu generycznego - zostawmy to, nie będę bronił straconej sprawy ;-)
Innymi słowy - to co widziałem na np. stronie www.postsharp.net to rakieta na cukier w porównaniu do tego co oferuje Delphi.
I tyle.

Z dużej ilości **niepotrzebnego **kodu, który ładują.
Ale OK - w Delphi jest podobnie, wystarczy porównać np. mORMota z DataSnapem.

To już nie jest kwestia języka, tylko tego jak ktoś projektuje aplikację. Ale, w .NET i Javie ładują moduły dynamicznie i jak sensownie zorganizujesz kod, to można zminimalizować ilość niepotrzebnego kodu. W Delphi wprawdzie można robić DLLe i je ładować dynamicznie, ale jak je ostatnio używałem, były ograniczone do eksportowania praktycznie tylko zwykłych funkcji i ich przygotowanie/używanie wiązało się z dodatkową pracą po stronie programisty.

Przecież serwerów aplikacyjnych nie stawia się na telefonie z 2 GB RAM, tylko na serwerach z 64-512 GB RAM. Ale jak ktoś chce i troszkę przytnie ustawienia, to serwer apikacyjny albo system baz danych napisany w Javie spokojnie można postawić na Raspberry Pi z 512 MB RAM na wszystko (włączając OS).

Ale to już nie jest ta sama Java, tylko "Java SE Embedded" prawda?

Ta sama Java. Java Embedded to Java działająca na np. kartach inteligentnych albo w amplitunerach.
W przypadku Raspberry Pi aplikacji nie trzeba rekompilować ani inaczej pakować, jedynie uważać na ustawienia pamięci - wiele serwerów ma domyślnie skonfigurowane np. buforowanie albo wielkości pul wątków z myślą o dużej maszynie serwerowej. Na małym sprzęcie trzeba to poprzycinać.

Podobnie języki funkcyjne są lepsze od imperatywnych. Platformy Java/.NET mają pod tym względem bardzo dużo do zaoferowania (F#, Scala, Clojure) - w Delphi jesteś skazany na archaicznego Pascala na sterydach.

E tam, zależy do czego; daleki jestem od takiego generalizowania.

Ja też i właśnie na platformie .NET i Java mam wybór - ciekawych i popularnych języków na te platformy jest przynajmniej kilka (wszystkich jest kilkaset na obie platformy, ale większość bardzo niszowa). W przypadku Delphi wybór jest chyba tylko między Delphi i niezbyt zgodnym ze standardem C++ (chyba że się coś ostatnio ruszyło, ale odkąd pamiętam, Borland traktował C++ po macoszemu).

No jasne, zwłaszcza Google, Apple, Twitter, Facebook, Sony, Walmart czy eBay piszą swoje serwery Javowe studentami, a jak coś nie wyrabia, to nie problem - przecież stać ich na dorzucenie 10000 serwerów w ciągu jednego dnia :D

Dokładnie tak!

Owszem, stać ich, ale to jest problem. Te firmy nie mają pieniędzy na wyrzucanie w błoto. I wierz mi, wydajność ma bardzo wysoki priorytet, zwłaszcza że te farmy serwerów ciągnął niebotyczne ilości prądu.

(...) zmienia się polityka wsparcia; poprawki będą utrzymywane do 2,5 roku od daty premiery danej wersji środowiska.
Bo to co było do tej pory (czyli nowa wersja co pół roku dostępna jak upgrade z $$$), to skandal.

Dobrze wiedzieć, że ktoś wreszcie poszedł po rozum do głowy. Kiedy wypuszczą darmową wersję do zastosowań komercyjnych?

Wsparcie iOS z kompilatorem 64bitowym jest od wersji XE8.
http://www.embarcadero.com/press-releases/major-new-release-rad-studio-xe8

Ok, dzięki, niby flame, a zawsze się czegoś można dowiedzieć. :)

Kontrolki nie są natwyne, ale mogą być. I to nie jest żadna tam jakaś trudność. Wszystko zależy od tego, czy naprawdę komuś na tym zależy - mi, niespecjalnie.

Problem jest zwykle wtedy, gdy wychodzi nowa wersja iOSa / Androida i zmienia się styl kontrolek. Wtedy aplikacje w Delphi nagle zaczynają odstawać wyglądem i zchowaniem od reszty systemu.

I dlatego Emba zaprojektowała dla FireUI zestaw styli (skórek) dla kontrolek wizualnych. Po to, aby one udawały wyglądem standard - lub nie. Jak się komu podoba.

Poza tym jakoś nie wierzę, aby te rysowane kontrolki działały identycznie dobrze jak te z SDK. Kiedyś Delphi używało natywnych kontrolek na Windows i to właśnie było fajne, bo aplikacje działały i wyglądały jak aplikacje Windows, a nie paskudnie jak aplikacje napisane w Javowym Swingu.

Bywa różnie, ale jest coraz lepiej. Na szczęście nawet na dziś porównanie do SWINGa ma się jak pięść do nosa; znaczy w FireUI jest daleko, daleko lepiej.

Nie wiem czy zauważyłeś, ale następuje powrót do kompilacji do kodu natywnego.
Chyba w wersji 4.4 Andka pojawiła się możliwość odpalania systemu i usług jako natywnych (nie pomnę szczegółów w tej chwili, ale można znaleźć), a nie jako app Dalivikowych. Dlaczego? Ze względu na wydajność właśnie.
Możemy się spierać co to znaczy natywny, dla mnie to jest właśnie NDK czyli Native Development Kit :)

To jest wewnętrzny aspekt implementacyjny samego Androida. Aplikacje nadal się kompiluje do kodu pośredniego, a ART w chwili instalacji kompiluje to do kodu maszynowego. Po prostu zmienili sposób kompilacji z JIT (dość słabego) na AOT. Nadal zalecanym sposobem pisania aplikacji natywnych jest pisanie ich w Javie i używanie oficjalnego SDK. NDK jest zalecane tylko do bardzo wymagających apikacji typu gry, które muszą mieć dostęp niskopoziomowy.

No i tą drogą, czyli NDK, poszło Delphi w multiplatform. Ma to swoje wady i ma zalety, jak wszystko.

Ciekawość - a jaki to język ma dużo silniejszy system typów niż w Delphi?

Praktycznie każdy zarządzany - np. Java / C#. Ale trochę nie o to mi chodziło.

Miałem na myśli języki takie jak Coq, Haskell, Scala, *ML, ADA, Rust. O Haskellu i Scali to nawet krążą dowcipy w stylu "jeśli się kompiluje, to znaczy, że działa, więc wysyłamy do klienta".

Istotna tu jest ekspresywność systemu typów, tj. jakie rzeczy da się wyrazić w systemie typów w taki sposób, aby kompilator jak najdokładniej odrzucał programy z błędami, a przepuszczał programy prawidłowe. Oczywiście zawsze jest jakaś "szara strefa" nieprawidłowych programów, które się prawidłowo kompilują (a potem źle działają) oraz programów prawidłowych, które się nie kompilują (tzn. prawidłowych składniowo, ale nieprawidłowych jeśli chodzi o reguły systemu typów - wtedy programista się oczywiście wkurza na kompilator), i chodzi właśnie o to, aby była jak najmniejsza. Niestety tak jest, że zmniejszenie tej strefy wiąże się ze znacznym wzrostem stopnia skomplikowania kompilatora i jego systemu typów. Do tego stopnia, że programista nie jest już w stanie samemu łatwo określić, czy dany program się skompiluje, czy nie. I wtedy właśnie system sprawdzania "w locie" jest bardzo użyteczny i bardzo przyspiesza pracę.