On 2011-03-12 22:13, Przemek O. wrote:
> 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.

Przemysł != automatyka. Przemysłem jest też drukowanie faktur.

>> 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.

Kod pośredni nie ma nic wspólnego z metaprogramowaniem. Co ciekawe chyba
w 2009 coś tam w Delphi dłubano przy genarykach ale nie wiem z jakim
skutkiem. Na pewno skutek to żaden dla dydaktyki.

>> 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.

Delphi jest nieprzenośny z definicji. C/C++ z głupoty.

>> 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ć.

Cały czas rozmawiamy w kontekście dydaktyki. Interesuje mnie wsparcie w
postaci pieryliarda rozwiązanychproblemów.

> 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?

- Panie profesorze, może na jutrzejszych zajęciach coś powiemy o mapach?
- To proszę zrobić składkę.

> Sam vector jest zrozumiały, ale zapis array of integer nawet tłumaczony
> z angielskiego na polski już coś znaczy.

Jeśli to jest istotne dydaktycznie to poponuje COBOLa.

> 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.

Jeśli piszesz logikę typu "onclikc() { sql.execute() }" to faktycznie.
Jesli potrzebujesz obrobić dane *nie* sqlem to już by się przydało.

> 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.

Zwiechy podczas zwalniania formy z steka przycisków jakoś nie stanowią
problemu dla usera bo to nie są aplikacje *real* time.

> 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ć.

Z pamiętnika managera:

Mamy 40 developerów znających się na Delphi.

a) zwalniamy wszystkich i zatrudniamy studentów pisząc w C#

b) męczymy się w Delphi bacznie patrząc ko będzie jutro właścicielem

Co wybrać, hmmm ...

>> 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?

Jak jest wiedzą statystyki. Ja ch nie mam. Mam poszlaki.

> W Delphi też można użyć odpowiednią bibliotekę i wykonać po prostu sort,
> bez konieczności jego implementacji.

Bo delphi to taki soft do pisania onklików. Jakiekolwiek "wypasione"
algorytmy kosztuja pieniądze. Mocno to dydaktyczne.