Koniec delphi?

Wygląda na to że nie doczekamy się delphi dla pda bo delphi już nie będzie produkowane Chyba że ktoś inny to pociągnie.

http://www.idg.pl/news/88708.html

Z tego co wiem to Delphi 2006 ma już ten ficzer, i jest już dostępne.
Nawet podobno działa :-)

Watpie by Borland sprzedal Delphi. To tak jakby Microsoft sprzedal Windowsa Poprostu nie sprzedaje sie czegos co bylo poniekad najstarszym i najdoskonalszym (najlepiej dopracowanym) dzieckiem firmy.

Ale faktem jest, że wystawił Delphi na sprzedaż. Czy znajdą chętnych to już inna sprawa.

Niestety Object Pascal ma juz swoje lata - czytaj wady i zalety. Powstaja takie zabawki jak C# i Delphi lekko sie deaktualizuje pomimo dodawania nowych bibliotek czy rozszerzen.

Niestety Object Pascal ma juz swoje lata - czytaj wady i zalety. Powstaja takie zabawki jak C# i Delphi lekko sie deaktualizuje pomimo dodawania nowych bibliotek czy rozszerzen.

Sorry, ale za przeproszeniem piep... Rownie dobrze mozna by powiedziec ze Basic ma swoje lata i sie deaktualizuje, a mimo to dalej jest rozwijany i ma swoich zwolennikow. Jak ktos chce sie szybko nauczyc programowac to wybierze cos latwiejszego niz C (bez wzgledu na typ) i moze dojsc do perfekcji w danym jezyku programowania tak ze jego programy nie beda wiele odbiegac od programow napisanych w C (tak wiem pisze cos co niektorzy moga uznac za herezje, ale to szczera prawda). Poprostu liczy sie dobra znajomosc jezyka, jego rozwoj (byleby nie w zla strone ) i optymalizacja kodu.

coz w zasadzie masz racje ale po to powstaja rozne jezyki zeby mozna bylo dobrac najodpowiedniejszy do zadanego problemu.
Np
szybko stworzony i Ladny Interfejs do programu biznesowego -> Delphi, VB czy C#
Szybki i bezpieczny system wieloprocesowy -> ADA,
wieloplatformowa aplikacja sieciowa -> Java (i jej odmiany)
zagadnienia RealTime -> C ewentualnie C++
Problemy Matematyczne -> Matlab czy tez Prolog, Fortran.

I tu lezy roznica miedzy projektantem systemu i programista.
Ten pierwszy definiuje i dokladnie precyzuje problem, wybiera system i jezyk, a programista implementuje przydzielone zadanie.  
Wybor jezyka jest wazny. Bo po co np meczyc sie z imlementacja mnozenia maciezy wielowymiarowych, transformacji etc. kiedy w Matlabie jest to od reki dostepne.

Wiem ze odbieglo to od tematu watku jakim jest Delphi, ale np. Rational ze swoim narzedziem Rose tez doszedl do granic i zrezygnowal z niego.
W pewnym momencie poprostu dalszy naklad pracy nad rozwojem narzedzia przekracza potencjalne zyski. System stal sie tak zagmartwany ze rozwoj = napisanie czesci od podstaw, a to sie moze nie kalkulowac.
Zwlaszcza przy tak silnym konkurencie jakim jest VS z VB, C# czy J#.

z drugiej strony Szkoda ze Borland rezygnuje. Konkurencja pobudza, a bez tak silnej konkurencji jaka byl Borland MS moze osiasc na laurach.


Pozdrawiam

No to wyglada na to ze Borland nie calkowicie pozbyl sie Delphi (i calej reszty IDE). Borland podzielil sie na 2 firmy i teraz srodowiska programistyczne beda wydawane z DevCo (co jest poniekad firma-corka Borland'a - ci sami ludzie, stare programy, ale nazwa bedzie nowa). Przy okazji szukaja nazw dla swoich produktow:

http://blogs.borland.com/MichaelSwindell/archive/2006/05/26/24962.aspx
http://blogs.borland.com/MichaelSwindell/archive/2006/05/25/24935.aspx

C# leży przy ObjectPascalu Delphi wcale nie musi być rozwijalne, czego wam tam mało? 2006 mieli wszystkie rodzaje Pascala i po co tu cokolwiek rozwijać, skoro jest tam wszystko co możliwe? Ja powiem więcej - Delphi 8 wystarczy już do pisania w OP pod .NET i to wystarcza całkowicie.
C++ jakoś stoi w miejscu od długiego czasu, a nadal jest przez wszystkich używany.
Najgorszy dzisiaj jest wg mnie C#, tandenta podróbka Javy, szkoda na to czasu.

edit

A co do sprzedania firmy - tak jak mówi post powyżej, zresztą przeczytajcie newsa na 4programmers.net o tym.

Najgorszy dzisiaj jest wg mnie C#, tandenta podróbka Javy, szkoda na to czasu.

A co takiego go czyni najgorszym?  

Pisałem już o tym na innym forum i nie bardzo teraz mi się chce to powtarzać
Po prostu MS zamiast wspierać dobre języki, to tworzy nowy prawie identyczny jak Java, który współpracuje wpełni z .NET, aby zastąpić Javę w Windows Vista. Jest to nowy język, aczkolwiek nie widzę w nim przyszłości.

Zastąpić Javę w Windows Vista? A w ogóle jakakolwiek Java tam była od czasów MS Java? Nie sądzę, by zabronili instalowania JRE/JDK sunowskiego. Java jest w paru miejscach mocno do tyłu z "trendi" nowościami, jak web services i w ogóle porządna obsługa XML, strasznie boli ogrom przeróżnych bibliotek spełniających te same zadania, z których naprawdę wartościowych jest niewiele, a te jeszcze w ogóle trzeba znaleźć i nauczyć się obsługiwać przebijając się przez źródła, bo dokumentacji jak na lekarstwo (nie, Javadoc nie wystarcza jako "programmer's guide"). Wdarła się tam przez to bylejakość, godziny ślęczenia nad deskryptorami XML, gdzie każdy ma inną semantykę lub zabawa z xdocletami, a bardzo obiecujący JEE 5 dopiero raczkuje - może wreszcie się skończy dostosowywanie rozwiązań do technologii. Niestety póki co to C# z .NETem jest o wiele nowocześniejszy i cieszy się coraz większym zainteresowaniem. Ja pracuję jako javowiec, od 1,5 roku nie daje się firmy przerzucić na coś nowszego, niż 1.4.2, mimo że sporo współpracowników bardzo ubolewa, że z 5.0 nie może pracować, nawet do aplikacji klienckich. A co dopiero przeskoczyć na JEE5, które jeszcze niedawno było projektem, teraz póki co tylko Glassfish jest pełną implementacją serwera aplikacji tej wersji. To musi się jeszcze wygrzać, co daje kolejny rok poznawania, testowania i sprawdzania, jak się zachowuje. Cząstkowe implementacje standardu w Jbossie niespecjalnie ratują sytuację, bo tracimy przenośność kodu i nie programujemy w JEE, ale pod JBossa. Gdzie tu przenośność i uniwersalność?
Jestem pewien, że Microsoft nikomu nie będzie zakazywał korzystania z Javy zarówno jako platformy klienckiej i serwerowej. .NET zyskuje sobie zwolenników nie tylko w środowisku Windows - Mono rośnie w siłę. Widzę że jesteś po prostu uprzedzony do wytworów Microsoftu, węsząc na każdym kroku próbę monopolizowania rynku i spisek światowy. Tak jak ktoś Cię na 4programmers.net zapytał (sprawdziłem Cię ) - programowałeś w .NET? Wiesz jak się z tym przyjemnie pracuje? I jakie masz doświadczenia z J2EE? Nic o nich nie napisałeś, więc jestem ciekaw, skąd taka bezwzględna preferencja wobec Javy.

Z pewnością obie platformy mają swoje zalety i wady, dla mnie powszechna otwartość kodu bibliotek javowych nie jest zaletą, ale nie mówię też że pełna komercjalizacja bibliotek .NETowych jest dobra. Tutaj wybór jest o wiele prostszy, bo jest ich mniej, ale za to wiele bardziej dopracowanych rozwiązań. Co jednak najlepsze, wiele wiele bibliotek dodatkowych do JEE posiada swoje funkcjonalne odpowiedniki w samej .NET, bez instalowania żadnych dodatków, więc także sporo dostajemy za darmo.
Sprawdź sobie tylko, co oferuje .NET Framework 3.0.

p.s. swoją drogą. Mylisz się - IE7 będzie też dla XP SP2.

IMHO zaczyna to coraz bardziej przypominać dyskusje religijną
Kocham Java'e, lubię C#.
W Java'ie lubię to, że jest przemyślana i rzadko, ale to bardzo rzadko coś mnie zaskakuje. Nie lubię za to Swinga.
W C# rażą mnie takie rzeczy jak rozróżnienie na metody wirtualne i niewirtualne [w moich oczach odbiera to bardzo dużo C#], złamanie enkapsulacja przez właściwości dzięki czemu ktoś mi w kodzie pisze:
image = IMAGE;
i ja nie wiem, że to IMAGE wykona mi jakiś kod. Wole Java'owskie:
image = getImage();
[Wiem, że w C# się też tak da, boli mnie to, że w zapatrzeniu na Delphi dali w ogóle taką możliwość]
Boli mnie też to, że patrząc na deklarację klasy w C# nie wiem czy ona coś rozszerza czy implementuje i nie podoba mi się udziwnianie polegające na przyjmowaniu sztucznej konwencji, że interfejsy piszemy z I na początku [bo to jest obejście tego, że w ramach odróżniania się od Java'y zrobiono to tak a nie inaczej].
W całej technologii Java'owej ubóstwiam to, że pisze sobie kod na Windows a mogę go uruchomić na AIX [na Windows też ]. .NET jest na razie bardzo ograniczony w tej międzyplatformowości.
C# z .NET tworzące ASP.NET mają olbrzymią zaletę w porównaniu do J2EE. Prostotę. Ale to jest dobre gdy pisze się szybko małe aplikacje, przy kobyłach które mają być rozłożone pomiędzy wiele maszyn zaczynają się problemy.
C# lubię jeszcze za łatwe pisanie na PocketPC.
Ogólnie uważam, że Java jest bardziej przemyślana. Jednak ma wady polegające na tym, że wiele rzeczy można zrobić na wiele sposobów. To niby zaleta, ale zaleta wtedy gdy developerzy znają wiele bibliotek i potrafią wybierać na podstawie doświadczeń, a zwykle tak nie jest

Odnośnie propertiesów - tak jak widzę w swojej firmie, kod getterów i setterów w kodzie javowym w 99% wygląda mniej więcej tak:
public Image getImage() {
    return image;
}
gdzie image to oczywiście prywatny atrybut.
I chyba dlatego wprowadzono właściwości do C#, bo sporo kodu było w ten sposób "ozdobionego" i daje to pewnego rozróżnienie - funkcja robi coś rzeczywiście konkretnego. Na początku mnie to nieco dziwiło, dlaczego właśnie owych "getImage()" i "setImage()" nie ma, a tu patrzcie, niespodzianka - wystarczy po prostu image = IMAGE. Jak chcę, IMAGE mogę wystawić jako publiczny atrybut, albo i opakować w get i set i kodu klienckiego nie muszę zmieniać. Nic tutaj nie łamie enkapsulacji w większym stopniu, niż generowanie getterów i setterów dla prywatnych atrybutów w Javie. Bo to jest z grubsza to samo, ale atrybut sugeruje, że ewentualnie stojący za nim kod jest, a może powinien być, odpowiednio prosty, by służył wyłącznie wyciągnięciu informacji.
Ale i Javowa metoda jest dobra, zależy, jak wszystko inne, od preferencji.

Przedrostek "I" dla interfejsów jest chyba przejęty z C++. Dlaczego jednak dodawanie "Impl" do nazwy klasy implementującej w Javie nie jest udziwnieniem? Często widuję "I_" w projektach javowych i co wtedy?

Wybór bibliotek oczywiście jest właśnie pod tym względem dobry, że jest duży, ale, tak jak wcześniej zaznaczałem, trzeba stracić masę czasu, by oddzielić te porządnie działające i łatwe w użyciu od tych niedopracowanych, skomplikowanych - często jest to kwestia przejściu z taką biblioteką całego projektu od początku do końca. Taka Chiba - zapowiadała się pięknie na papierze, a kogo zapytam o nią, kto z nią spędził "trochę" więcej czasu, to mam wrażenie że powinienem się daleko odsunąć.   Portlety? Szybko wykańczać wersję 2.0! Axis - łoboże.

Wybór jest prosty - asembler x86.  

MacBirdie - moim zdaniem czas Javy (a w tym też programowałem, choć doskonale Javy nie znam) dobiega końca, bo po prostu wypiera ją C# (który jak tu mówi poprzednik też nie jest idealny). No i dochodzimy do tego wniosku - co z tego? Ja i tak uważam, że każdy powinien programować w tym czym mu wygodnie, bo liczą się efekty. Tak czy siak Java jest dla mnie nadal stratą czasu

edit

MacBirdie - nie widziałem jeszcze Twojego postu wyżej jak to pisałem Na Assemblera nie ma co narzekać

Najgorszy dzisiaj jest wg mnie C#, tandenta podróbka Javy, szkoda na to czasu.

[C#] Jest to nowy język, aczkolwiek nie widzę w nim przyszłości.

MacBirdie - moim zdaniem czas Javy (a w tym też programowałem, choć doskonale Javy nie znam) dobiega końca, bo po prostu wypiera ją C# (który jak tu mówi poprzednik też nie jest idealny). No i dochodzimy do tego wniosku - co z tego? Ja i tak uważam, że każdy powinien programować w tym czym mu wygodnie, bo liczą się efekty. Tak czy siak Java jest dla mnie nadal stratą czasu

Musisz się zdecydować, albo zamilcz na wieki.  
[chyba że jest Was tam więcej ]

Nie masz szacunku dla ludzi z rozdwojeniem jaźni

A tak na poważnie to wszędzie mówię jedno i to samo - dwa pirewsze cytaty na wzajem się uzupełniają "Szkoda na to czasu, bo nie widzę w tym przyszłości."
Trzeci cytat - zgadza się, mogę mówić, że Java i C# są be, ale i tak zawsze liczą się efekty A skoro już mówimy  o tym w czym najlepiej się programuje to jest to oczywiście C++

Odnośnie propertiesów - tak jak widzę w swojej firmie, kod getterów i setterów w kodzie javowym w 99% wygląda mniej więcej tak:

Kod: [Zaznacz]

public Image getImage() {
    return image;
}
gdzie image to oczywiście prywatny atrybut.
I chyba dlatego wprowadzono właściwości do C#, bo sporo kodu było w ten sposób "ozdobionego" i daje to pewnego rozróżnienie - funkcja robi coś rzeczywiście konkretnego. Na początku mnie to nieco dziwiło, dlaczego właśnie owych "getImage()" i "setImage()" nie ma, a tu patrzcie, niespodzianka - wystarczy po prostu image = IMAGE. Jak chcę, IMAGE mogę wystawić jako publiczny atrybut, albo i opakować w get i set i kodu klienckiego nie muszę zmieniać. Nic tutaj nie łamie enkapsulacji w większym stopniu, niż generowanie getterów i setterów dla prywatnych atrybutów w Javie. Bo to jest z grubsza to samo, ale atrybut sugeruje, że ewentualnie stojący za nim kod jest, a może powinien być, odpowiednio prosty, by służył wyłącznie wyciągnięciu informacji.

Z tym, że widząc getImage() ja wiem, że wołana jest metoda [i tutaj jest bardziej skomplikowana ], w przypadku właściwości nie wiem tego, może być to czytanie pola, a może być wołanie metody. To mnie boli i w tym widze naruszenie enkapsulacji, ponieważ nie wiem czy odczytanie jakiejś właściwości nie zmieni mi obiektu.

Przedrostek "I" dla interfejsów jest chyba przejęty z C++. Dlaczego jednak dodawanie "Impl" do nazwy klasy implementującej w Javie nie jest udziwnieniem? Często widuję "I_" w projektach javowych i co wtedy?

Gdy pracowałem w Motoroli to taki kod po prostu by nie przeszedł inspekcji
To "I" jest konwencją którą stosuje się miedzy innymi dlatego by można było się domyśleć, że gdy mamy :Icostam to jest to interfejs, a gdy :costam to klasa. To jest sztuczne udziwnienie, w Java'ie jest to ładniej rozwiązane:
class JakasTam extedns JakasSuperTam implemments JakisTam

Wybór bibliotek oczywiście jest właśnie pod tym względem dobry, że jest duży, ale, tak jak wcześniej zaznaczałem, trzeba stracić masę czasu, by oddzielić te porządnie działające i łatwe w użyciu od tych niedopracowanych, skomplikowanych - często jest to kwestia przejściu z taką biblioteką całego projektu od początku do końca. Taka Chiba - zapowiadała się pięknie na papierze, a kogo zapytam o nią, kto z nią spędził "trochę" więcej czasu, to mam wrażenie że powinienem się daleko odsunąć.   Portlety? Szybko wykańczać wersję 2.0! Axis - łoboże.

Się całkowicie zgadzam :-)
Nadmiar bibliotek wg. teorii pozwala na lepsze dopasowanie do projektu, w rzeczywistości zaciemnia sprawę

"Szkoda na to czasu, bo nie widzę w tym przyszłości."

To od razu powinieneś powiedzieć, że na Javę i C# szkoda Ci czasu, a nie tu mącisz i na Microsoft wszystko zwalasz.

RMK - wszelkie "podpowiadajła" mówią, czy pobierasz pole obiektu, czy propertiesa, o. Ale wydaje mi się, że properties właśnie wprowadzono po to, by wykorzystywać je w prostych przypadkach i wprowadzić dla nich bardziej naturalną składnię, niż dla wszystkiego zestaw getter-setter. Czasem większy porządek jest w kodzie, gdy mamy proste coś = coś innego, niż wszędzie coś = getCośInnego(). Ale to nie znaczy, że nie wykorzystuje się getCośtamów() w kodzie C#. Dla mnie to nadal preferowana metoda dla bardziej złożonych operacji, szczególnie gdy może się zdarzyć, że w czasie takiej operacji może wystąpić poważniejszy błąd. Fakt, propertiesy mogą być w pewnych sytuacjach mniej intuicyjne, ale ustalająć jakąś konwencję, można problemów uniknąć, albo z propertiesów nie korzystać.

wszelkie "podpowiadajła" mówią, czy pobierasz pole obiektu, czy propertiesa, o.

Możliwe, ale musisz "wjechać" na ten kod, szczerze to nie wyobrażam sobie inspekcji takiego kodu z kartki papiery, przecież biedny reader miałby poważny problem ze sparafrazowaniem:
image = IMAGE;

Ale wydaje mi się, że properties właśnie wprowadzono po to, by wykorzystywać je w prostych przypadkach i wprowadzić dla nich bardziej naturalną składnię, niż dla wszystkiego zestaw getter-setter. Czasem większy porządek jest w kodzie, gdy mamy proste coś = coś innego, niż wszędzie coś = getCośInnego(). Ale to nie znaczy, że nie wykorzystuje się getCośtamów() w kodzie C#. Dla mnie to nadal preferowana metoda dla bardziej złożonych operacji, szczególnie gdy może się zdarzyć, że w czasie takiej operacji może wystąpić poważniejszy błąd. Fakt, propertiesy mogą być w pewnych sytuacjach mniej intuicyjne, ale ustalająć jakąś konwencję, można problemów uniknąć, albo z propertiesów nie korzystać.

Tak, można nie korzystać, ale wszędzie namawia się do korzystania, bo to taki "fajny" ficzer, dodatkowo jeżeli w firmie nie ma jeszcze konwencji kodowania to jest pewne, że ktoś zacznie używać

Dla mnie ten ficzer, to silenie się by .NET był wielojęzykowy [a nie jest, bo nie da się nań przenieść bez przepisywania starego kodu w C++ czy nawet VB] to naciski marketodiów. Wydaje mi się, że gdyby .NET i C# pozbawić tych kilku "ułatwiaczy" to Microsoft dostałby świetną technologie, tak ma świetną technologie z dziwnymi dodatkami.
Rozumiem, że .NET jest metodą obrony Microsoftu przed Javą i mogę to zrozumieć w końcu od momentu gdy Sun zabronił Microsoftowi zabaw z Javą to Microsoft stał się swego rodzaju zakładnikiem Suna. Sam lepszą przyszłość wróże Java'ie, niestety C#, ASP.NET i .NET stają się powoli "łatwymi" narzędziami. Aplikacje webową napisać może każdy, to jest dobre, ale powoduje też, że jakość kodu większości aplikacji staje się delikatnie mówiąc dyskusyjna

Ale i w PHP można napisać porządny kod, więc gdzie potrzebny dobry specjalista, tam taki się znajdzie.
Fakt że Java odstrasza chętnych szybkiej i łatwej rozrywki programistycznej, ale nie można się tak zupełnie odgradzać.

Ale i w PHP można napisać porządny kod, więc gdzie potrzebny dobry specjalista, tam taki się znajdzie.

Można :-) Ale większość ludzi pozostaje na poziomie niezbyt porządnego kodu

Fakt że Java odstrasza chętnych szybkiej i łatwej rozrywki programistycznej, ale nie można się tak zupełnie odgradzać.

A Java'ie też można się pobawić ja np. teraz próbuję wykorzystać smutny fakt dostanie od firmy telefonu służbowego, zabawami z J2ME i pisaniem aplikacji w tym cosiu [i powiem wprost, że jest upierdliwe, ale da się zawalczyć ]

A czy to źle, że ktoś pisze nie ładny kod? Zaglądnijcie sobie w źródła np. PostNuke (wychwalają tą kupe pod niebiosa):

echo "<div align=\"center"\>"
."Hello $uname. You have";
if (pnModAvaibles('Messages') {
echo "<span class=\"pn-normal\">$num Messages</span>"
."</div>";
}

Zapisywanie zmiennych w " ", slashe (po cholere to nie wiem), każda linia tekstu osobno przerywa funkcję echo, w dodatku ten cały kod jest nie do edycji, trzeba by to pisać od nowa. Większego syfu to ja jeszcze w życiu nie widziałem, a wszyscy się dziwią czemu to tak wolno chodzi   Pomijam już to, że PN używa AdoDB, a obsługuje tylko MySQL  

I co? Więcej takich programistów, mniejsza konkurencja Same pozytywy

PostNuke niestety tak ma. To już i tak postęp w porównaniu z PHPNuke. A obejrzyj sobie kod eCommerce.      

A mam pytanie czy sam TurboPascal* dziala normalnie na PPC??

* - z niego powstal delphi.

TurboPascal to rozbudowana wersja Pascala, są tam już m.in. procedury. Poza tym Delphi to nie język, tylko kompilator. Język to ObjectPascal
A czy działa na PPC to zależy jak z niego skorzystasz

Borland mimo wszystko lubi nazywać Dephi językiem.
Zaś sam TurboPascal nie działa na PocketPC. Niektórzy jednak używają go na PCC przy pomocy DosEmu. Jeżeli zaś chodzi o samą kompilację programów w Pascalu na PPC to pomocny może się tu okazać Free Pascal Compiler.
Sam jednak odradzałbym ładowanie się w Pascala i Delphi bo na dzień dzisiejszy języki te mają bardzo niepewną przyszłość.
Sam twórca Turbo Pascala i Delphi pracuje od 10 lat dla Microsoftu i tworzy C#.

Ważne są efekty. Dla mnie C# ma niepewną przyszłość, a Delphi może być wieczne Tak czy siak jest Kylix, Lauzarus i oby dwa te programy używają ObjectPascala, a Kylix to jest to samo co Delphi (nie licząc 2005 i 2006). Ale potocznie przyjęło się mówić Delphi na język, ale jak już ktoś musi to DelphiPascal

Sęk w tym, że Delphi jako język umarł. Borland nowe ficzery wkłada do Delphi.NET, ale Delphi dla Win32 jest takie samo od Delphi 7 czyli od 2002 roku.
Delphi.NET też nie zdobywa sobie zbyt wielu przyczółków głównie ze względu na toporność IDE z serii 2005 i 2006 [o Delphi 8 nie ma co wspominać]. No i naturalnym wyborem języka dla .NET jest C#.
Development software'u to teraz głównie Java, C# i C/C++.
Z moich obserwacji wynika, że teraz Delphi to głównie małe, często jednoosobowe firmy. Powstają w nim świetne programy [vide Total Commander], ale sam język jeżeli nie dorobi się nowych wydań to niestety lub stety umrze.

A ciekawe czy ktoś wymyśli emulator procesora Intel dla programów Delphi w Pocket PC, i do tego jakiś programik w panelu sterowania który przez nas wpisuje do rejestru ścieżki plików dla których ma się uruchamiać.