Przyszłość Delphi vs przyszłość Javy

masz rację, jeżeli jakaś firma ma... tylko że to nie jest rozwój a powolny upadek - bo takich firm jest coraz mniej ...
a nowych systemów tworzonych w delphi jest jak na lekarstwo - dlaczego - bo nie ma dobrej polityki zachęcającej NOWYCH użytkowników -
ostatnim prorozwojowym krokiem twórców delphi było wypuszczenie Turbo Delphi - teraz powoli zbierają zabawki ...

Delphi umiera i upada tak jak, co roku linuksiarze krzyczą, że Microsoft idzie na dno ;p Moim zdaniem XE5 powoduje że powstała fajna alternatywa do pisania na smartfonach. Jedynym plusem drogich licencji jest to, że kupując dostajesz WSZYSTKIE starsze wersje za darmo. Nie jest to downgrade tylko dodatkowe licencje - można używać ich na raz jako dwa niezależne programy z dwoma kluczami licencyjnymi. Wydajesz kupę kasy ale kupujesz paczkę programów. Inna kwestia czy to się przyda.

Ale czym ma mnie Delphi przekonać, skoro ceną nie może?
Jakoś nie widzę jego ogromnej przewagi na żadnym polu.

Pomijając już nawet wszelkiego rodzaju -Sparki, jeśli chcę zacząć komercyjny produkt, w przypadku VS mogę zacząć od darmowej wersji, a jak zarobię - kupić Pro za niecałe 3000 zł.
W przypadku Delphi już na początek muszę kupić Pro za ponad 4000 zł.
Ale VS to raczej odpowiednik RAD Studio a nie samego Delphi, więc właściwie nie 4000 ale prawie 8000...

No więc czym ma mnie Delphi przekonać?
Bo begin end to mogę mieć też w darmowym Lazarusie...

EDIT.

Właśnie odkryłem istnienie czegoś takiego jak Visual COBOL.
Więc nawet COBOL ma „przyszłość”. Ktoś to na pewno kupuje (banki?), ceny nawet nie podają, zapewne absurdalna.
Programista COBOLa też na pewno sporo zarobi...

Ale to już skrajna nisza, i w taką też niszę się Delphi stacza.

Masz dużo racji. Ja bardziej jestem przekonany co do Free Pascala i Lazarusa. Pisząc w Delphi i C++ borlandowskim i ich narzędziach widzę jakie są kiepskie ( szczególnie przed XE) ale to nie sprawia, ze delphi nie ma przyszłości. Może uściślijmy pojęcie przyszłość ??

PS. Ciekawe jakby Oracle zniknęło, każdy producent oprogramowania w Javie szybko zwinąłby interes po kolejnym exploicie, który by zaorał to Javowe piekiełko.

Oracle mógłby kupić Embarcadero podczas jednych weekendowych zakupów i nawet nie zauważyłby zmiany w budżecie. Ale tego nie zrobi, bo nie widzi w Embarcadero ani przyszłości, ani żadnego zagrożenia.

Dokładnie - nie widzi zagrożenia bo to nie ten sektor ;) Mam wrażenie, że wszystko co nie jest z Twojej dziedziny i nie jest flagowym przedstawicielem nie ma przyszłości i jest kiepskie. Wobec takiej ignorancji mam wątpliwości, czy jakakolwiek dyskusja ma sens, gdyż do rzeczowej na pewno nie należy, kiedy na każdą zaletę delphi wyciągasz armatę popularności javy i gloryfikację jezyków cl...

Krolik napisał(a):

PS. Ciekawe jakby Oracle zniknęło, każdy producent oprogramowania w Javie szybko zwinąłby interes po kolejnym exploicie, który by zaorał to Javowe piekiełko.

Oracle mógłby kupić Embarcadero podczas jednych weekendowych zakupów i nawet nie zauważyłby zmiany w budżecie. Ale tego nie zrobi, bo nie widzi w Embarcadero ani przyszłości, ani żadnego zagrożenia.

Strasznie się tej Javy trzymasz, no więc proszę. Mogliby wydać trochę z tych pieniędzy na porządne przetestowanie swojego oprogramowania, żebym nie padł ofiarą kolejnych ataków hakerskich:

"In the last six months, two million users have been targeted in cyber-attacks using Java exploits"

Źródło http://www.kaspersky.com/about/news/virus/2013/Is_there_any_protection_against_Java_exploits

przez 12 miesięcy w 2013 znaleźli tylko 161 krytycznych luk ;), czyli wychodzi, że w Javie co 2 dzień znajdywano krytyczną lukę pozwalającą infekować miliony użytkowników! Niezły wynik :) faktycznie Delphi może pozazdrościć popularności wsród hakerów, twórców malware kitów, exploitów i wszelkiej maści internetowych szumowin :), w świecie IT chyba nie ma innej, równie badziewnej i zabugowanej rzeczy jak Java i JRE. 161 krytycznych luk prowadzących do exploitacji, jest coś gorszego?

Jaka jest rada firmy Kaspersky na Javę?

"The only surefire way to prevent an attack is to ensure that none of the necessary software that the exploit pack requires is installed on the computer"

PS. Oracle jest "taaak" bogate, że do instalatora Javy dodaje AskToolbara - http://www.reddit.com/r/java/comments/16k7hi/java_installer_ask_toolbar_seriously/ i mimo, że było tak za Sun-a, postanowili to zostawić, zawsze to parę centów do przodu na ciśnięciu badziewia userom :)

Coś słabo z tymi desktopowymi aplikacjami w Delphi. Total Commander ma 20 lat i od tamtej pory nic się nie wydarzyło? Skype ma w Delphi naklepane tylko oryginalne GUI ( http://www.quora.com/Skype/What-programming-language-was-Skype-originally-written-in ) - nie wiadomo nawet czy coś z tego kodu Delphi jeszcze pozostało.

Zresztą Delphi jest chyba Windows-only, czyż nie? Jak ktoś chce klepać coś Windows-only to raczej wybierze .NET

"In the last six months, two million users have been targeted in cyber-attacks using Java exploits"

Czy Ty w ogóle rozumiesz artykuły, które przytaczasz? Czy powtarzasz medialną papkę?

Wszystkie exploity Javy dotyczą czegoś, czego Delphi nigdy nie umiało i nie będzie umieć: bezpiecznego wykonywania niezaufanego kodu. Eksploity są tworzone na Javę dlatego, że plugin Java jest na 80% maszyn, a przełamanie zabezpieczeń daje pełną kontrolę - możliwość wykonania praktycznie dowolnego kodu. Żadna inna technologia nie daje takiej możliwości, bo Flash i JavaScript (w których też były odkrywane dziury 0-day) mają dość duże ograniczenia funkcjonalne.

Jeśli chodzi o Javę zabezpieczenie jest proste: nie odpalasz kodu z niezaufanego źródła na nieaktualnej Javie. Dotyczy to przede wszystkim appletów - najprościej nie instalować pluginu w przeglądarce, choć obecnie wszystkie przeglądarki pytają, czy uruchomić kod. Natomiast dziury te nie dotyczą normalnych aplikacji napisanych w Javie i nie narażają użytkowników programów Javy na żadne niebezpieczeństwo, nawet jeśli Java nie jest zaktualizowana; i nawet jeśli jest to oprogramowanie serwerowe (przedpotopowa, dziurawa Java 1.4 jest nadal używana w niektórych bankach na serwerach i nikt się sensacjami o dziurach w JRE nie przejmuje).

Dla porównania, gdybyś chciał wykonać niezaufany kod napisany w Delphi, to masz przerąbane na starcie. Jedna wielka dziura - nie ma absolutnie żadnej ochrony, żadnego sandboxa, żadnego systemu zabezpieczeń. Wykonuje kod jak leci z pełnymi uprawnieniami właściciela. W tym sensie nikt się tym nie przejmuje i nie robi sensacji, bo to nie jest zastosowanie Delphi.

Generalnie Twoja argumentacja jest taka, że trzymanie pieniędzy na stole jest lepsze od trzymania w sejfie, bo w pewnych modelach sejfu odkryto wady umożliwiające otwarcie go przez niepowołane osoby.

Dlatego sprowokowałem ten temat przy okazji tego nowego Delphi, które umożliwia tworzenie pod Windows, Maca, iOS i Androida. Jak dla mnie to spore wydarzenie, które jednak chyba zostało przeoczone przez te wieloletnie dobijanie Delphi zmianami firmy czy usilnym kopiowaniem Visual Studio

.NET, Java, C++ też umożliwiają. Żadna rewelacja. Po co kodować coś w Pascalu jak można w bardziej ekspresywnym języku z lepszymi narzędziami, lepszym kompilatorem i jeszcze za darmo? Poza tym rozwiązania przenośne na kliencie akurat się słabo sprawdzają. Jak się chce zrobić dobrą aplikację, to się pisze na każdą platformę osobno. Więc nic nie szkodzi na przeszkodzie napisać w C# na Windows, w C++ na Linuksa, w Javie na Androida a w Objective-C na iOS.

Jak jesteśmy już przy pisaniu wieloplatformowym to czy Delphi potrafi generować kod działający w przeglądarce (JS)?
Bo z C#, Javy, C, C++ można taki kod uzyskać bez większych problemów.

A, i jeszcze odnośnie Skype'a, to tak jak myślałem, Skype ma z Delphi wspólne jedynie okienka na Windows. Wszystko co najważniejsze, czyli trzon, napisano w C++:

The functional core components which did the heavy lifting under the UI have always been the same C/C++ as Ahti pointed out.

Za: http://www.quora.com/Skype/What-programming-language-was-Skype-originally-written-in

A, i jeszcze w kwestii wydajności:

http://stackoverflow.com/questions/19273413/android-app-created-by-delphi-xe5-starts-very-slow

i tried a few samples off android apps and my impression is that android apps designed with XE5 runs very slowly, they start very slowly, almost 4 secs with a black screen, that ruins the whole experience.

Tak, Java nigdy nie będzie tak szybka jak "język niskiego poziomu Delphi". LOL.

Krolik napisał(a):

"In the last six months, two million users have been targeted in cyber-attacks using Java exploits"

Czy Ty w ogóle rozumiesz artykuły, które przytaczasz? Czy powtarzasz medialną papkę?

Wszystkie exploity Javy dotyczą czegoś, czego Delphi nigdy nie umiało i nie będzie umieć: bezpiecznego wykonywania niezaufanego kodu. Eksploity są tworzone na Javę dlatego, że plugin Java jest na 80% maszyn, a przełamanie zabezpieczeń daje pełną kontrolę - możliwość wykonania praktycznie dowolnego kodu. Żadna inna technologia nie daje takiej możliwości, bo Flash i JavaScript (w których też były odkrywane dziury 0-day) mają dość duże ograniczenia funkcjonalne.

Panie @Krolik - 161 exploitów na rok to nie medialna papka - to fakty! Kłóć się z Kasperskym. Nawet na Flasha nie ma tylu luk co na Javę. To porażka numer 1 jeśli chodzi o bezpieczeństwo komputerów. Faktycznie - żadna inna technologia nie dała możliwości na tyle exploitów.

Krolik napisał(a):

Dla porównania, gdybyś chciał wykonać niezaufany kod napisany w Delphi, to masz przerąbane na starcie. Jedna wielka dziura - nie ma absolutnie żadnej ochrony, żadnego sandboxa, żadnego systemu zabezpieczeń. Wykonuje kod jak leci z pełnymi uprawnieniami właściciela. W tym sensie nikt się tym nie przejmuje i nie robi sensacji, bo to nie jest zastosowanie Delphi.

Generalnie Twoja argumentacja jest taka, że trzymanie pieniędzy na stole jest lepsze od trzymania w sejfie, bo w pewnych modelach sejfu odkryto wady umożliwiające otwarcie go przez niepowołane osoby.

Delphi nie zostało stworzone do takich celów. Mylisz kategorie kolego. Śmieszne jest to, że mówisz ile to Oracle ma kasy, a fakty są faktami - Java jest dziurawa jak sito, nie podważysz tych 161 krytycznych luk. Oracle najwidoczniej trzyma pieniądze na jachtach swoich właścicieli, a nie w działach R&D.

Krolik napisał(a):

.NET, Java, C++ też umożliwiają. Żadna rewelacja. Po co kodować coś w Pascalu jak można w bardziej ekspresywnym języku z lepszymi narzędziami, lepszym kompilatorem i jeszcze za darmo? Poza tym rozwiązania przenośne na kliencie akurat się słabo sprawdzają. Jak się chce zrobić dobrą aplikację, to się pisze na każdą platformę osobno. Więc nic nie szkodzi na przeszkodzie napisać w C# na Windows, w C++ na Linuksa, w Javie na Androida a w Objective-C na iOS.

No widzisz, a teraz nie trzeba, nie rozumiem co cię tak boli, że wreszcie w Delphi można pisać na tyle platform? Dostałeś kiedyś pałę z pascala na studiach, że tak ci to uwiera?

Krolik napisał(a):

Jak jesteśmy już przy pisaniu wieloplatformowym to czy Delphi potrafi generować kod działający w przeglądarce (JS)?
Bo z C#, Javy, C, C++ można taki kod uzyskać bez większych problemów.

To pokaż jakiś swój kod w C#, Javy, C, C++, który działa jako JS. Chętnie zobaczę to cudo.

Krolik napisał(a):

A, i jeszcze odnośnie Skype'a, to tak jak myślałem, Skype ma z Delphi wspólne jedynie okienka na Windows. Wszystko co najważniejsze, czyli trzon, napisano w C++:

Trzon JVM napisano też w C++.

PS. "Over 200 sites running on JBoss servers, including some that belong to governments and universities have been hacked and infected with these Web shell applications"

http://www.computerworld.com/s/article/9244149/Hackers_exploit_JBoss_vulnerability_to_compromise_servers

Jak widać nie tylko plugin do przeglądarki jest dziurawy. Całkiem niedawno ;), faktycznie technologia, co do której można mieć pewność, że w końcu ktoś Ci się włamie na serwer albo wykorzysta lukę w pluginie przeglądarki.

To pokaż jakiś swój kod w C#, Javy, C, C++, który działa jako JS. Chętnie zobaczę to cudo

Nie muszę. Google zrobił to za mnie: AdWords, AdSense, Google Groups, Orkut, Blogger, Wallet, Flights, etc.

Trzon JVM napisano też w C++.

A OS napisano w C, a procesor napisano w VHDL... Mylisz warstwy. Główna funkcjonalność Skype nie została napisana w Delphi. Główna funkcjonalność IntelliJ IDEA, za którą ludzie płacą, została napisana w Javie (łącznie z kompilatorem).

PS. "Over 200 sites running on JBoss servers, including some that belong to governments and universities have been hacked and infected with these Web shell applications

Dziura w Jbossie nie JVM. No i co z tego? Będziesz każdą dziurę teraz w każdym programie Javowym na sieci wyszukiwał? W każdym złożonym programie komputerowym są błędy. W Delphi też. Z mojego skromnego doświadczenia aplikacje w Delphi sypią się znacznie częściej niż Javowe - o, np. porównajmy DevC++ z Eclipsem albo IDEĄ :D

Delphi nie zostało stworzone do takich celów. Mylisz kategorie kolego. Śmieszne jest to, że mówisz ile to Oracle ma kasy, a fakty są faktami - Java jest dziurawa jak sito, nie podważysz tych 161 krytycznych luk. Oracle najwidoczniej trzyma pieniądze na jachtach swoich właścicieli, a nie w działach R&D.

No nie było stworzone, więc nie wiem po grzyba wyciągnąłeś temat dziur w sandboksie JRE, który służy do innych celów, i który nie jest używany w 99% softu Javowego?

Śledzę aktualizacje Javy na bieżąco i w przeciwieństwie do większości użytkowników, czytam release-notes. Dziura dziurze nierówna, a firmy takie jak Kaspersky mają zawsze interes w tym, aby zrobić sensację publikując duże liczby wrzucając wszystkie dziury do jednego worka. Przypominam sobie jedną jedyną dziurę, jakieś kilka lat temu, która mogła dotyczyć oprogramowania serwerowego, które pisaliśmy. Dziura dotyczyła różnych platform (PHP też) nie tylko Javy i jedyny jej skutek był taki, że można było zrobić Denial Of Service (ale nie przejąć kontrolę).

Inna kwestia, że właśnie nie jest dziurawa, bo Oracle załatał te 161 dziur. Jakby nie załatał, to taki Kaspersky nie miałby nawet o czym pisać, bo to nie oni te dziury odkryli. Większość tych dziur została załatana zanim publika o nich wiedziała. Błędy są w każdym oprogramowaniu. Poza tym jak Embacadero zrobi cokolwiek porównywalnego funkcjonalnością z Javą lub .NET, to wtedy pogadamy o jakości oprogramowania, a teraz ta dyskusja jest na poziomie "a u Was biją Murzynów".

faktycznie technologia, co do której można mieć pewność, że w końcu ktoś Ci się włamie na serwer albo wykorzysta lukę w pluginie przeglądarki.

Tak, a ludzie w Google, Facebooku, Amazonie i co drugim banku to idioci i używają tej dziurawej Javy a nie Delphi. Nic tylko włamać im się na serwery.

Proponuję przenieść wątek do działu Flame.

Krolik napisał(a):

Dziura w Jbossie nie JVM. No i co z tego? Będziesz każdą dziurę teraz w każdym programie Javowym na sieci wyszukiwał? W każdym złożonym programie komputerowym są błędy. W Delphi też. Z mojego skromnego doświadczenia aplikacje w Delphi sypią się znacznie częściej niż Javowe - o, np. porównajmy DevC++ z Eclipsem albo IDEĄ :D

Nie trzeba daleko szukać - http://beta.slashdot.org/story/196709

"Oracle is posting patches for all its products next Tuesday, which include 36 exploits for Java alone and over 140 for all Oracle products currently supported, included over 80 that require no authentication to execute."

Styczeń 2014 ;), tylko 36 exploitów. Oracle chyba woli zatrudniać marynarzy na te jachty właściciela niż na testowanie kodu http://en.wikipedia.org/wiki/Rising_Sun_(yacht)

Już jakiś czas obserwuję ten wątek i niestety z dywagacji na temat przyszłości Delphi użytkownicy zrobili porównywarkę języków na wielu szczeblach...

Przypominam więc, że temat nie dotyczy dziur w Javie, więc proponuję powrócić do tematu; Jeśli ktokolwiek chce porównywać różne języki to załóżcie wątek we Flame, a tutaj dajcie już spokój; Poza tym porównanie Delphi i Javy jest nieporozumieniem - inne technologie wykonywania kodu, inne przeznaczenie języków itd. itd.; Jedyne sensowne porównanie mogłoby być powiędzy Delphi a C/C++ - reszta języków to inna bajka;

Póki dyskusja jest w miarę kulturalna i nie sypią się wyzwiska - temat może pozostać tutaj; Jednak jeśli tak dalej pójdzie to faktycznie trzeba będzie wątek przenieść do Flame, gdzie każdy będzie mógł przyłączyć się do mierzenia siurków :]

Piszecie tak jakbyście komuś chcieli udowodnić że macie licencję na wróżenie z fusów.
Przecież to flejm pierwszej wody i jedyne co tu można napisać to opinię lub fakty dotyczące aktualnego stanu rynku.

Pytanie: Czy Delphi można uruchomić w przeglądarce?

Tak:

• http://delphicodemonkey.blogspot.com/2013/10/turbopascal-pcode-compiler-implemented.html
• http://www.itwriting.com/blog/5456-compile-object-pascal-to-javascript-with-smart-mobile-studio.html

Pytanie: Czy jest dużo ofert pracy w Delphi?
pracuj.pl/Delphi/programista: dzisiaj 1 szt.
pracuj.pl/Java/programista: nie chciało mi się liczyć, ale ponad 20

Pytanie: Czy produkt Delphi jest dobrze zarządzany?
(opinia)

• za dużo rzeczy chcą zrobić dobrze
• brak wersji darmowej środowiska (chyba że chodzi o Lazarus - ale wtedy po co komercyjna)?
• soft zmienia ciągle właściciela
• język wspierany tylko przez Embarcadero i ... FPC

Pytanie: Czy aplikacja typy desktop zrobiona w Delphi wygląda dobrze?

Tak, DevExpress nadal wspiera VCL chociaż na samym końcu listy produktów.

Pytanie: Czy aplikacja typy desktop zrobiona w Delphi jest szybka?

Nigdy nie miała być. Delphi to środowisko przede wszystkim do pracy z bazami danych, w tej niszy
to baza danych decyduje czy aplikacja jest szybka.
Zresztą zawsze można użyć wyspecjalizowane DLL-ki jeśli robimy np. coś z analizą widma gwiazd lub tym podobne.

Pytanie: W czym dzisiaj robi się aplikacje desktop?
C++/Qt
Delphi
BCB
Lazarus
C#
ew.
C++/MFC?
Java SE / Swing (wygląda tak sobie, ale jest przenośne bez rekompilacji)

Ile z tych środowisk ma darmowe wersje?

Edit: dodałem Java i Lazarus (ten ostatni jako osobne środowisko).

Pytanie: Czy Delphi można uruchomić w przeglądarce?

Tak:

• http://delphicodemonkey.blogsp[...]code-compiler-implemented.html
• http://www.itwriting.com/blog/[...]-with-smart-mobile-studio.html

Pierwsze to kompilator Pascala napisany w JS, nie kompilator Pascala do JS.
Drugie to zajawka marketingowa czegoś, co jest w fazie "closed Alpha". Ciekawe, ale zamknięty kod nie wróży niestety nic dobrego - miną zapewne lata zanim będzie to używalne, a też nie bardzo wiem jak oni chcą na tym zarabiać.

Nigdy nie miała być. Delphi to środowisko przede wszystkim do pracy z bazami danych, w tej niszy
to baza danych decyduje czy aplikacja jest szybka.

Pytanie: czy Delphi faktycznie ma przysżłość jako platforma do pracy z bazami danych?

Nie, ponieważ brakuje oficjalnych sterowników do wielu baz. Oficjalne sterowniki są zawsze w pierwszej kolejności wypuszczane na .NET i Javę, C i C++, później na Pythona, Rubyego, PHP. Brak oficjalnych sterowników to duży problem dla klienta - oznacza, że trzeba korzystać ze sterowników firm trzecich i wtedy inna firma świadczy pomoc techn. dot. sterownika, a inna dot. bazy danych. Już widzę to odbijanie piłeczki, kiedy jakieś zapytanie nie działa. "to wina bazy! nie, to wina sterownika! nie to wina bazy, zadzwońcie do nich! Ale oni twierdzą, że to wina sterownika!" itp. Do tego sterowniki firm trzecich nigdy nie mają takiej wydajności / funkcjonalności jak sterowniki oficjalne (w najlepszym razie opakowują sterownik oficjalny, np. ODBC, JDBC albo natywny dla C/C++).

Żeby Embarcadero liczyło się serio na tym rynku, to musiałoby nawiązać partnerstwa z firmami produkującymi bazy danych, następnie w jakiejś formie zapłacić za certyfikację (lub napisanie) sterowników. Z punktu widzenia vendora baz danych, ponieważ Delphi jest dość niszowe, napisanie i utrzymywanie sterowników do Delphi we własnym zakresie po własnych kosztach nie wchodzi w grę. No i do tego nie ma wcale dużej presji na sterowniki do Delphi - nasi klienci jęczeli o sterowniki do .NET i Pythona a o tym, żeby ktoś chciał Delphi nie słyszałem.

Nawet do otwartoźródłowego PostgreSQL nie ma otwartych konektorów Delphi. Wszystkie wymienione na stronie PostgreSQL są zamknięte i komercyjne. Dla wielu korporacji to może być "deal breaker" (nie cena, tylko zamkniętość konektorów).

Najtrafjniejszym pytaniem w kwestii przyszlosci produktu jest pytanie: "Co moze ten produkt zaoferowac, dlaczego ten, a nie zaden inny?". Niestety nikt w tym watku nawet nie staral sie odpowiedziec na to pytanie.

[Wypowiadam sie z roli osoby malo lubiacej pascalo-podobne zabawki]
Delphi na pewno nie moze zaoferowac atrakcyjnej ceny produktu, szerokiej gamy zastosowan. Czy nawet nie wspiera edukacji mlodziezy/projektow OS, tak jak chociazby MS czy JB (niektorzy to nazywaja zniewalaniem). Ciezko jest wybierac produkt do rozwoju softu uzywanego w biznesie, jesli sie jako tako nie mialo z nim stycznosci wczesniej, ani nie mozna sie nim "pobawic".

Ofc. Fanatycy i ludzie rzezbiacy w brazie zawsze beda, wiec w najblizszych dziesiecioleciach, raczej bedzie sie slyszec o Delphi, jednak przy zalozeniu konsekwentnosci dzialan firmy opiekujacej sie tym produktem, nie ma co wrozyc jakichs rewelacji.

Nie wiem z którym postem to powiązać, ale gdyby ktoś chciał poprogramować strony w Pascalu:

http://www.morfik.com/
i
http://stackoverflow.com/questions/3793112/what-web-application-framework-for-delphi-is-recommended

Ew. jeśli ktoś jest fascynatem COBOL-a to też mam link...

Jak na miliardy dolarów zysku - Oracle chyba przeznacza jedynie pieniądze z AskToolbara na testowanie podatności Java na exploitację skoro co miesiąc tyle luk wychodzi, nie mówię o generalnych poprawkach, ale o krytycznych lukach, dlaczego tyle luk nie ma np. w Google Chrome?

Już po prostu nie mogę patrzeć jak ktoś sieje bemyślny FUD, bez sprawdzenia źródeł.
Masz, porównanie luk w Chrome i w JRE.

Chrome: http://www.cvedetails.com/product/15031/Google-Chrome.html?vendor_id=1224
Firefox: http://www.cvedetails.com/product/3264/Mozilla-Firefox.html?vendor_id=452
JRE: http://www.cvedetails.com/product/1526/SUN-JRE.html?vendor_id=5

12 exploitów na Chrome vs 4 na JRE
175 dziur w Chrome w 2013 roku vs 131 dziur w JRE w 2013 roku.
895 dziur w Chrome od 2008 roku vs 435 dziur w JRE od 2001 roku (dłuższy okres)
6 podatności zdalnego wykonania kodu w Chrome w 2013 roku vs 4 takie błędy w JRE.

Weighted Average CVSS Score za ostatni rok (im wyżej, tym bardziej krytyczna luka):
Chrome: 7.3
Firefox: 8
JRE: 7.7

Inna rzecz, że porównanie jest jabłek z gruszkami, bo przeglądarka www to trochę inne zastosowanie niż JRE. Przeglądarka cały czas pracuje z niezaufanym kodem, a w JRE sandbox jest to tylko jedną z wielu funkcji, do tego rzadko wykorzystywana. Siłą rzeczy przeglądarka powinna być dużo bardziej odporna. A jakoś nie jest...

Delphi w zestawieniach nie ma po 2006 roku, bo ma chyba za małą popularność...

Skoro już jesteśmy przy zagrożeniach - ręka do góry, kto ma Acrobat Readera i kto otwiera nim pdfy z Internetu? ;)
W 2013 roku 59 luk umożliwiających zdalne wykonywanie kodu. CVSS Score za ostatni rok: 9.9 (skala jest do 10.0). O, to jest wynik! :)

http://www.cvedetails.com/product/921/Adobe-Acrobat.html?vendor_id=53

To co przestajesz siać FUD od tego momentu, a my wracamy do tematu czy Delphi ma przyszłość (i zostawiamy Javę w spokoju)?

Bank of New York Mellon, który kupił swój pierwszy komputer mainframe w roku 1955, nadal utrzymuje główne aplikacje napisane właśnie w COBOL-u na komputerach tej klasy, wykorzystując wydajność rzędu 52,000 MIPS na dziewięciu maszynach, przy czym obciążenie to rośnie o 10% rocznie. Przy takiej skali ponowne napisanie aplikacji nie jest uzasadnione biznesowo, istotne zyski przynosi zatem dobudowanie front-endów webowych i rozwój istniejącej infrastruktury. patrz: http://www.computerworld.pl/artykuly/381612/Czy.COBOL.umiera.html

Próbowałem znaleźć jak Embarcadero sobie radzi od strony finansowej i poniosłem porażkę. Jedyne dane jakie udało mi się znaleźć urywają się w roku 2006, co jest zrozumiałe o tyle, że od 2007 roku Embarcadero jest prywatną firmą, nie jest notowane na giełdzie i nie ma obowiązku publikować rocznych raportów.

Wg quandl.com, w 2006 roku przychód wyniósł $57.6 mln. Obecnie wikipedia podaje przychód za 2012 rok: $100 mln i zatrudnienie ok. 500 osób. Czyli idzie im troszkę lepiej, ale szału nie ma. Raczej stabilizacja niż dynamiczny wzrost. Inna rzecz, że przy 500 osobach i równoczesnym rozwoju kilku produktów na kilku frontach raczej nie poszaleją, zwłaszcza że wszystko jest closed-source i nie mają pomocy od społeczności.

@Krolik:

Krolik napisał(a):

Tylko RDBMSy, do tego nie wszystkie popularne i tylko nieoficjalne konektory, niecertyfikowane przez żadnego vendora baz danych. Do tego chwalą się na głównej jakimś niszowym Interbasem, a znacznie popularniejszych Teradata, Vertica, Cassandry, MongoDB, Redisa, Riaka, Couchbase, Membase, czy Solra nie ma. Cały czas sprawiają wrażenie, że przybyli do nas z połowy lat 90-tych.
(...)

Nawet do otwartoźródłowego PostgreSQL nie ma otwartych konektorów Delphi. Wszystkie wymienione na stronie PostgreSQL są zamknięte i komercyjne. Dla wielu korporacji to może być "deal breaker" (nie cena, tylko zamkniętość konektorów).
(...)

To jest pozycjonowane jako technologia do obsługi baz danych czy nie jest? Po co dają stery od Oracla? Oracle będziesz instalował na każdej końcówce na desktopie?

Tak gwoli ścisłości, żeby ten wątek nie był czystym hejtowaniem:

Teradata (FireDAC): http://docwiki.embarcadero.com/RADStudio/XE5/en/Overview_%28FireDAC%29
MongoDB (OSS): http://docs.mongodb.org/ecosystem/drivers/community-supported-drivers/
Cassandra (OSS): http://pascassa.codeplex.com/
PostgreSQL (komercyjne, ze źródłami): https://www.microolap.com/products/connectivity/postgresdac/
PostgreSQL (komercyjne, ze źródłami): http://www.devart.com/pgdac/

Reszty nie znam i nie chce mi się szukać, ale jeśli ma interfejs do C to może też mieć interfejs do Delphi przy niezerowym oczywiście nakładzie pracy.

A co do Oracla, to nie wiem po co chciałbyś instalować go na końcówkach?

ale ja nie mam żadnych pretensji - stwierdzam tylko fakt, że nie ma oficjalnych sterów, co pośrednio świadczy o tym, że Delphi na rynku aplikacji bazodanowych się nie liczy. Nie ma, bo nie widzimy najmniejszego interesu w ich dostarczaniu do Delphi, skoro nikt Delphi nie używa do nowych projektów (warzywniak jadący na programiku do fakturowania kupionym na DobreProgramy to nie jest dla nas żaden klient). Tak samo jak nie widzimy sensu wypuszczania sterów do COBOLa. Identycznie uważa 10Gen, Cloudera, Couchbase, Oracle, IBM i inni producenci baz danych. - Krolik

Dobrze wiedzieć, że wypowiadasz się w imieniu całej firmy (DataStax?), muszę się ich zapytać czy oni także uważają, że pojedynczy, nawet drobny klient dla nich się nie liczy.

Popatrzmy na rozwój samego języka Delphi:

1. Genericsy - dodane w D2009, 5 lat po Javie, 4 lata po C#, i na dodatek słabsze
2. Closures - dodane w D2009 (metody anonimowe), 10+ lat po Javie (Java 1.1) i 6+ po C#
3. GC - brak
4. Inferencja typów - brak
5. Stringi Unicode - D2009, 14 lat po Javie (Java 1.0) i 6+ po C#
6. Wsparcie dla 64-bitów - Delphi XE2, znowu kilka lat po Javie i C# i bardzo duże kilka (blisko 10) po C++ (nie ma niestety dokłądnych danych, kiedy support 64 bitowy został dodany, ale praktycznie był od początku)

Ok, zgoda - Delphi się rozwija. Ale innowatorem już nie jest. Kiedyś było.

No pierwsze parę postów się ciekawie czytało potem się tylko gównoburza zrobiła. Ma ktoś popcorn?

Całkiem ciekawa lista

http://www.embarcadero.com/products/delphi/whats-new

1 IDE to rule them all ;)

@Bartosz Wójcik, owszem, moderatorzy tutaj mogą więcej. Mogą przenosić wątki i zmieniać im tytuły. Naprawdę głupio by było, gdyby wszyscy użytkownicy mieli takie uprawnienia, prawdopodobnie powstałby totalny chaos.

Poza tym, moderatorzy to zwykli użytkownicy, mogą mieć swoje poglądy i ich bronić, tak jak Ty możesz. @Krolik argumentuje, że Delphi nie ma przyszłości, bo inne technologie są lepsze. Ty możesz zbijać te argumenty, ale nie oburzaj się, że ktoś ma inne poglądy, i nie wyciągaj bycia moderatorem, jako argumentu w dyskusji...

GC było od wielu lat (interface), generics można było symulować przez $I, "Inferencja typów" w Delphi nie była potrzebna bo był Variant, reszta - http://edn.embarcadero.com/article/41820

Ty serio, czy żartem?

Interface ze zliczaniem referencji to jest co najwyżej jakaś namiastka GC, a o problemach jakie z tym są już linka raz wklejałem i nie chce mi się powtarzać. Niestety Embarcadero nie publikuje informacji nawet o tym jak to zliczanie referencji jest zrealizowane, bo wbrew pozorom dobre zliczanie referencji jest zrobić trudno. Poza tym nie bardzo kumam, po co mieszać interfejsy ze zliczaniem referencji - powiązanie dwóch zupełnie różnych koncepcji, które powinny być niezależne od siebie, a nie są.

Generics to można symulować sobie nawet w C makrami - i co z tego, ale mają mnóstwo wad.
Genericsy w Delphi są namiastką genericsów w innych językach i są znacznie mniej ekspresywne nawet od dość kiepskich genericsów Javy: http://stackoverflow.com/questions/19160740/how-to-translate-java-generics-into-delphi. Ale mieliśmy z Javą nie porównywać, więc porównajmy sobie z C# albo Scalą/Kotlinem... Tu dopiero wypadają blado. Gdzie np. kowariancja/kontrawariancja argumentów generycznych? Ano nie ma. C#/.NET wprawdzie zrzynał początkowo dużo z Javy i był jakby followerem, ale przy okazji zrzynania poprawili i przeprojektowali masę rzeczy. Efekt jest taki, że wiele rzeczy w .NET jest zrobionych znacznie lepiej (np. wspomniane genericsy), a Javie ciężko teraz to naprawić. Natomiast Delphi niestety woli zrzynać ale częściowo, bez głębszego przemyślenia i bez wprowadzania innowacji, i serio genericsy wyglądają tak jakby je wrzucili od niechcenia żeby zamknąć gęby ludziom wytykającym, że Delphi genericsów nie ma.

Inferencja typów i Variant. Ech. Ty wiesz w ogóle co to jest inferencja typów i do czego służy? I wiesz, że są języki, które posiadają oba te rozwiązania? Skoro posiadają oba, to znaczy, że jedno nie zastępuje drugiego.

Można pójść dalej: popatrzmy sobie na zestaw kolekcji i struktur danych jakie oferuje Delphi XE5. Np. weźmy słowniki. Jest tylko TDictionary i TObjectDictionary? Serio? W 2014 roku? Nawet nie napisali nic w dokumentacji o złożoności operacji ani w jakiej strukturze danych jest to zaimplementowane. A gdzie zbiory, słowniki posortowane, słowniki zachowujące porządek, wielosłowniki, słowniki bezpieczne ze względu na wątki, kolekcje współbieżne, kolejki priorytetowe, kolejki blokujące, ....? Podstawy są, ale w porównaniu z tym co nawet jest w .NET, Javie, Pythonie, Rubym, C++ STL/Boost, to jest bardzo biednie i trochę ciężko w tym zaprogramować cokolwiek innego niż prosty frontend przekładający dane z bazy na formatki. I tak w ogóle wielki sukces, że w końcu jest TDictionary, bo do 2009 roku programiści Delphi musieli trzymać słowniki w TList (oh, chociaż pewnie się mylę, na pewno jakaś firma oferowała komponent THashMap, kosztujący tylko $200 :P).

1 IDE to rule them all

Hmm, zobaczmy jak wygląda integracja z Gitem tego IDE #1. Wpisujemy git w wyszukiwarkę dokumentacji dla XE5 i co? I nic. Null. Zero. A, źle, przepraszam: Nil. To może jest mercurial? Też nie (ani hg, ani mercurial). O, jest SVN. Suuuper! Nowoczesność pierwsza klasa, Delphi zawsze na czasie.
Zaraz ktoś napisze, że jest plugin do gita, no i faktycznie - jest. TortoiseGIT, który się instaluje w Windows Explorerze. JEdnak nie to rozumiem jako pełnoprawną integrację z IDE.

Co do innych zalet: wszystkie "nowości" wymienione na liście Delphi XE inne platformy mają od dawna. W kwestii wieloplatformowości na zabawki mobilne, Xamarin/.NET był wcześniej (a i tak wieloplatformowość to mrzonka; jak chce się zrobić naprawdę dobrą aplikację, to się robi dedykowane na każdą platformę w oficjalnym SDK), 64-bity ma praktycznie wszystko co się rusza od lat, co do integracji z bazami danych trudno coś wywnioskować z tego marketingowego bełkotu, w czym to niby lepsze od integracji z bazami danych jaką oferują platformy mainstreamowe (Ruby, Python, Java, .NET, PHP, ...) na które są sterowniki bezpośrednio od producenta bazy.

że gdy Java ponosiła porażkę jako narzędzie do tworzenia apletów webowych, w Delphi powstało tysiące desktopowych aplikacji ze względu na łatwość tworzenia okienkowych i bazodanowych aplikacji zgodnie z duchem RAD.

Myślę, że powinieneś się zatrudnić w jakimś dziale propagandy...
Ale analogia poniekąd ciekawa, więc pociągnijmy ją dalej.

Java odniosła niesamowity sukces właśnie na polu appletów. Applety były wszędzie, każdy chciał je mieć, do tego stopnia, że nikt się nie zastanawiał czy naprawdę są potrzebne. Sun nie był przygotowany na ten wysyp technologii appletowej, Java była przeznaczona oryginalnie do instalacji w urządzeniach wbudowanych, nie była za to dobrze przygotowana jako platforma do robienia GUI (applety zjadały mnóstwo RAMu, ładowały się długo, Java była interpretowana a nie kompilowana natywnie, GC powodowało lagi, do tego jeszcze spór z Microsoftem spowodował zablokowanie Javy na Windows na jakiejś archaicznej wersji 1.1). Efekt był taki, że w pewnym momencie użytkownicy mieli tego dość i applety zaczęły tracić szybko popularność na rzecz Flasha, który wtedy był wprawdzie bardziej ograniczony funkcjonalnie, ale robił dobrze to, czego chcieli spece od marketingu - dobrze wyświetlał oczojebne reklamy. Teraz Flash oczywiście jest be, bo jest znacznie lepsza technologia: HTML5 + JS. Flash i applety Java zostały wprawdzie zepchnięte w niszę (nadal są używane, ale nowych raczej się nie pisze), ale Java wyszła ze starcia cało, bo okazało się, że rewelacyjnie radzi sobie na serwerze, a później w aplikacjach mobilnych (Android) i paradoksalnie w końcu chwyciła też we wbudowanych (SmartTV, kino domowe, kserokopiarki, sprzęty użytku domowego itp.).

Sytuacja z Delphi jest analogiczna. Delphi urosło na fali aplikacji desktopowych, bo jedyną konkurencję jaką miało to VB (od którego zresztą Borland zrzynał rozwiązania pełnymi garściami). Obecnie jednak aplikacje desktopowe są spychane w niszę. W dużych korporacjach aplikacje desktopowe nie są lubiane, bo wiążą się z wysokim kosztem administracji. W przypadku aplikacji webowej, wystarczy aktualizować OS i przeglądarkę, a wszystkie aplikacje są zarządzane centralnie, więc upgrade się robi się szybko i bezboleśnie, a poprawki można wrzucać na bieżąco. Dobrze zrobione aplikacje webowe spokojnie dorównują wygodą używania aplikacjom desktopowym. Przeciętny użytkownik domowy z kolei używa kilku aplikacji desktopowych i całego mnóstwa aplikacji mobilnych / webowych. O ile jednak Java po zniknięciu rynku appletów zdobyła nowe nisze, to o Delphi tego powiedzieć nie można. Na mobilnych jest raczej trochę późno, na serwerowe się zupełnie nie nadaje, technologia leżąca u podstaw Delphi jest przestarzała, relatywnie słaba (Object Pascal) i raczej goni innych niż wyznacza trendy, a desktop - czyli jedyna ostoja Delphi traci na znaczeniu. No i do tego jeszcze w międzyczasie pojawiła się mocna konkurencja (.NET, C++ Qt, Adobe Air/Flex a nawet JavaFX*).

Podsumowując - moim zdaniem Delphi ma mniej więcej taką przyszłość jak applety Javy. Bardzo popularne kiedyś, będzie nadal czasem używane, znajdą się też tacy, co zrobią czasem w tym coś nowego, a nawet będą próby wskrzeszenia (takie jak JavaFX, vide Delphi XE) kończącze się mniejszym lub większym krótkoterminowym sukcesem. Mimo to na jakiś przełom raczej nie liczyłbym.

• Tak, sam byłem zdziwiony, ale znam firmę w Polsce, która w tym robiła jakieś korporacyjne coś dla klienta, bo łatwiej im było tymi samymi programistami robić frontend i backend.