W dniu 2011-03-12 07:57, Sebastian Biały pisze:
> a) nie ma sensownego miejsca w przemysle (traci na rzecz głównie Java/C#)

Po pierwsze, Delphi nigdy nie miało sensownego miejsca w przemyśle, bo
nie do tego jest/było stworzone. A sztuczne naginanie jednego języka do
wszystkich możliwych zastosowań jest jak dla mnie czynnikiem wskazującym
brakiem wiedzy.
Po drugie, co masz na myśli przemysł. Ja mam na myśli sterowanie
urządzeniami. Fakt, sterownika w Delphi się nie da napisać. Ale
oprogramowanie do sterowania maszynami to w dawniejszych czasach sam
pisałem, i znam osoby które do dziś się tym zajmują. I na brak pracy nie
narzekają.

> b) brak metaprogramowania (cast hell)

I dobrze. Czym innym jest wynikowy program natywny, a czym innym
kompilowany do kodu pośredniego. Niemniej podobną funkcjonalność osiąga
się w inny sposób.

> c) nieprzenosny

Tak samo jak i C/C++/C$ z VS jeśli odwołuje się do zasobów specyficznych
dla systemu operacyjnego. Nie rób tego w Delphi i też będzie przenosny.

> d) wsparcie spadające asymptotycznie do zera

Jakiś konkret? Bo żaden z poważnych dostawców bibliotek/frameworków,
sterowników dla urządzeń które miały wsparcie dla Delphi nie zrezygnował
z niego. Ba w nowych wersjach powstają nawet nowe rozwiązania o których
do tej pory można było w Delphi pomarzyć.

> e) brak sesnownych biblitek algorytmicznych i struktur danych, wszystko
> trzeba pstrykac ręcznie lub czekać "na następną wersję Delphi za pół roku".

Cienko ze znajomością. Może dlatego, że dla Delphi takie biblioteki
(poważne) są w większości płatne, bo to środowisko komercyjne. A może
właśnie o to chodzi? Że nie ma darmowych?

>>> Efekty: W pascalu nie ma mapy, listy. Wynik: Pascalowcy rozwiązuja
>>> wszelkie problemy na tablicach. Taaaak, tablice są najlepsze, po h...
>>> komu jakieś kontenery i abstrakcje w języku.

Tak zgadzam się, domyślnie nie ma. Poprzez biblioteki - ma.

> Na sąsiedniej grupie zapytalem (bez złych intencji, naprawdę miałem
> potrzebe użyć) gdzie znajdę mapę we wspólczesnym Delphi ... okazalo się
> że jestem tępym kretynem bo array jest szybsze.

Nie wypowiadam się. Może faktycznie jest szybsze :P

>> Dla początkujących tak. Więc (posługując się Twoim przykładem) dla
>> każdego bardziej zrozumiałym będzie array of integer niż
>> std::vector<int>.
>
> Nie widze różnicy.
>
>> W pierwszym przypadku wystarczy że przetłumaczy z
>> angielskiego na polski i wie o co chodzi, w drugim już nie jest tak
>> prosto.
>
> Że niby array jest jasne a vector nie?

Ehh, ja teraz też nie widzę różnicy, ale jak wieku temu podchodziłem do
programowania, to dziwnym trafem pascal wydał się łatwiejszy niż c.
Sam vector jest zrozumiały, ale zapis array of integer nawet tłumaczony
z angielskiego na polski już coś znaczy. Konwencja std::vector<int> już
budzi pewne wątpliowści. Np. co to jest ten std, po co dwa dwókropki
itd. itp. To są oczywiste oczywistości, ale jestem bardziej niż pewien,
że osoba która zaczyna będzie miała z tym kłopot.

> Po co ma *nie* być GC? Żeby powstal nastepny milion programów które źle
> zarządzają pamięcią? Pewne klasy problemów można łatwiej rozwiązać z GC,
> co ważniejsze są to problemy występujące częściej (takie jaki GUI, bazy
> czyli domena Delphi). Nikt nie stosuje na poważnie Pascala/Delphi do
> aplikacji np. realtime gdzie zarzadznei pamięcią ma znaczenie. Zazwyczaj
> zorwiązuje się problemy klasy "wystawianie faktur" a w pl "wystawianie
> recept" gdzie GC jest przydatny.

Po pierwsze, jeśli by tworzyć oprogramowanie zgodne z koncepcją RAD to
GC nie jest potrzebne, bo nie licząc wywalenia się programu nie ma
możliwości żeby coś gdzieś wyciekło.
Po drugie, jeśli komuś przestaje to wystarczać, to znaczy że dorósł do
poważnego programowania i wtedy już ma pojęcie co i gdzie może mu wyciekać.
Dla Twojej informacji, Delphi się nie stosuje w aplikacjach typu real
time nie dlatego że nie ma GC, ale dlatego, że aplikacje są uruchamiane
na systemu Windows, który z założenia nie może być stosowany w
aplikacjach tego typu.
Zresztą samo GC nie jest żadnym rozwiązaniem, a w sumie to jest większym
problemem. Nie wiem czy pamiętasz jak pojawił się .NET. Z wielkim hura
skoczyliśmy do pisania aplikacji w tym czymś. I co się okazało, że
aplikacje mają zwiechy w dowolnym momencie, trwające zauważalny czas. Co
było przyczyną? Ano - słabe komputery, windows 98SE i nieszczęsne
zwalnianie zasobów przez GC.

Mówisz, że w Delphi robi się problemy typu "wystawianie faktur". Może
zaciekawi Cię, że firma notowana na WIG20 ma cały system obsługujący
całą firmę produkcyjną. I to system nowy, a nie rozwijany od lat. I ma
możliwość modyfikacji samego siebie i to w trakcie pracy. I jeszcze
wiele możliwość których jak twierdzisz w wymierającym języku nie da się
zrealizować.

> Ile procent w skali rynku? Bo ja ostatnio widzialem bardzo dużo
> programów napisanych w AtariBASICu na jakiejś starej kasecie, jeśli Cię
> to intertesuje.

Rynku całościowego - nie mam pojęcia, nie jestem statystykiem. Ale,
jeśli chodzi o konkretne zastosowania to mam większe pojęcie.

>> nie było, że to oprogramowanie do wystawiania recept, to o czym pisze
>> steruje tomografami, rezonansami, służy do diagnostyki obrazowej, badań
>> przesiewowych itd itp.
>
> Zupełnie jak oprogramowanie napisane w C++, Javie, C#. Lisp na ten
> oprzykład lata w kosmos. W dodatku miałem okazję rozmawiać z programista
> który popełnił fragment sterownika do rezonanu magnetycznego w ...
> VisualBasicu.

No i? Przecież to Ty starasz się udowodnić że w Delphi się już nic nie
pisze, a teraz wypisujesz że zupełnie jak pisane w C++, Javie itd. To w
końcu jak jest?

Ja nie muszę niczego udowadniać, nie mam w tym żadnego interesu. Ba jako
programista Delphi w niszowej dziedzinie jest nawet niewskazane żebym
popularyzował Delphi jako język/środowisko. Im mniej jest programistów
Delphi (dodatkowo znających specyfikę danej dziedziny) tym ja mam
większe zarobki. A firmy nie przeniosą się na inne
platformy/języki/środowiska skoro mają kompletną bazę, doświadczenie i
zainwestowane grube pieniądze.

> Trzeba mieć minimalną wiedzę statystyczną. A ponieważ nikt nie posiada
> obiektywnej musimy bazować na subiektywnych opiniach.

Też nikt nie sili się na sugerowanie że jego opinia jest obiektywna. Ty
dajesz swoją wiedzę, ja częściowo Cie wyprowadzam z błędu i być może
skorygujesz Ty swoją wiedzę w danym temacie, a być może i po części ja.

> Na początek pokazał bym std::sort. Dzieki temu statystycznie więcej osób
> będzie w stanie napisać wydajny kod zamiast pisać popsute implementacje
> bubble sort za każdym razem. Co nie przeszkodzi idiotom i tak spieprzyć,
> ale przynajmniej nie sortowanie.

To zależy, można dać rybę, a można dać wędkę. Nie uważam, żeby wszystko
trzeba było pokazywać na poziomie implementacji, trzeba uczyć
wykorzystywać w pełni posiadane narzędzie wraz ze wszystkimi jego
dobrodziejstwami. Jednak na początku należy pokazać na czym to polega.
Zresztą w takim razie, po co uczyć teorii, wszystkie podstawowe rzeczy
są już zaimplementowane w odpowiednich bibliotekach.
W Delphi też można użyć odpowiednią bibliotekę i wykonać po prostu sort,
bez konieczności jego implementacji.

> PS. Gdzie sa studenci który na studiach z informatyki, w szczególności
> kierunkach dla programistow nie siedzieli jeszcze przed edytorem kodu? Z
> mojej obserwacji wynika że to szum statystyczny.

Oj... Na studia robiłem już w XXI wieku (bo wcześniej mi się nie
chciało, nie miałem potrzeby, czasu i tona innych wymówek). Więc na moim
roczniku i trybie zaczynało 300 parę osób (politechnika) a skończyło
jakieś 25-30? Jak dla mnie to oddaje poziom osób studiujących
programowanie. To chyba raczej nie jest szum statystyczny.

--
pozdrawiam,
Przemysław Osmański, SoftSYSTEM
www.soft-system.pl
www.kochamjedzenie.pl - portal dla ludzi którzy kochają jedzenie