On Friday, June 2, 2017 at 12:01:15 PM UTC+2, AK wrote:
> Użytkownik "slawek" <f...@f...com> napisał:
> > On Fri, 2 Jun 2017 09:14:49 +0200, "AK" <n...@n...net> wrote:
> >> Przeszedłeś (niestety z sukcesem) test na małpę.
> >
> > A ja ci szczerze napiszę: jesteś prymitywnym chamem i do tego mało dowcipnym.
Nawet jeżeli
> > potrafisz programować w COBOLU to i tak brak ci umiejętności pracy w zespole.
> >
> > I jeszcze jedno: cham nie oznacza tu pochodzenia ze wsi, ale brak kultury i
kindersztuby.
>
> Prawdziwym chamem i prymitywem jest ten, ktory dla swoich blizej niesprecyzowanych
> fiksacji/natrectw/"niedopieszczenia" zwyczajnie oklamuje

To się nazywa kłamca, a nie koniecznie cham.


> innych/mlodych (i tym samym wypacza
> widziana przez nich rzeczywistosc).
>
> Idiotyzmem jest Twoja sugestia ze w Javie czy innych C# rownie latwo popelnic
powazny blad

Na grupie już było mnóstwo rozmów na ten temat. W literaturze często
czytywałem, że w Javie popełnia się mniej błędów, że w Javie powstał
jakiś duży program bez ani jednego błędu, itd... W końcu uwierzyłem.
Kiedyś sam tak na grupie napisałem, że w Javie popełnia się mniej
błędów - wyśmiano mnie.

Myślę, że nie możecie dojść do porozumienia, bo używacie zbyt ogólnych
określeń. Pojęcie "błąd" jest bardzo ogólne. Błąd może być algorytmiczny,
program nie daje poprawnych wyników dla wszystkich danych wejściowych -
co tutaj pomoże język wyższego poziomu? Błąd może być w bibliotece - a
co tutaj pomoże język wyższego poziomu? Błąd może być wydajnościowy,
programista nie użył szybszego algorytmu - język wyższego poziomu tutaj
może nawet zaszkodzić, bo języki niższego poziomu mają mniejszy narzut
liniowy. W końcu błąd może polegać na tym, że ktoś się pieprznął używając
arytmetyki wskaźników, albo dziedziczenia wirtualnego - cóż, w Javie
nie ma takich konstrukcji językowych, więc się nikt w Javie w ten sposób
nie pieprznie ;-)



> czy "ogarnac" kod co w jakims assemblerze.
> Co do mojego "potrafienia" to potrafilem i potrafie programowac produkcyjnie w
Algolu, Simuli,
> FORTRANie, COBOLU (slabo:), kilku BASICach (w tym VB), PL/I, ASMx86, C/C++,
Pascalu,
> Iconie, Tclu, Pythonie, C# i Javie (wciaz slabo:). Dotknalem kiedys tez Prologa,
Moduli2, (niestety)
> Perla,
> czy takich "zabytkow" jak APL (na Merze60 lub 400 - nie pamietam), czy Planu
(rodzaju assemblera na
> Odrze).
> Nie wymieniam to po to, aby sie chwalic (bo to zwykle mlotki/dluta sa:) ale zeby
unaocznic
> z jakiej perspektywu odradzam "niskopoziomowki" - zwlaszcza dzisiaj - i to nawet w
embedded.
> Niskopoziomowo nalezy pisac dopiero wtedy gdy wszytsko inne zawiedzie,

Dlatego że można napisać w wysokopoziomowych językach plus dobre środowisko
szybciej i taniej, a niekoniecznie dlatego, że popełnia się mniej błędów.


> gdyz po prostu i zwyczajnie
> jezyki niskopoziomowe (tak tak, w tym C i C++) sa wielokrotnie bardziej
niebezpieczne niz te
> wyzszego poziomu.

Dobrze używany C++ wraz z dobrymi bibliotekami i dobrym środowiskiem
programowania umożliwia szybkie i (relatywnie) tanie stworzenie
wielu aplikacji. Chyba (dobrzy) programiści w Javie są drożsi niż
(dobry) programiści w C++? Dobrze użyty język C++ jest językiem
wysokiego poziomu ze wszystkimi ważnymi w naszym kontekście znamionami
języka wysokiego poziomu, czyli: kompilator/środowisko/biblioteka
wyręczą programistę w czasochłonnej implementacji wielu szczegółów.

Z językiem C jest gorzej, chociażby dlatego, że kompilator sam nie
wywoła destruktora.



> Poza tym wymagaja o wiele bardziej wiedzy _praktycznej_ niz teoretycznej niz jakies
Javy czy
> inne C# czy Pythony:)

Bo ja wiem... Raczej nie o to chodzi, problemem znowu jest brak precyzji
językowej. W C++ jest znacznie większa swoboda wyboru implementacji. Można
użyć tablic globalnych, automatycznych, statycznych, składowych, alokowanych,
bibliotecznych wektorów z jednej z kilku popularnych bibliotek, w końcu można
se taki wektor sam napisać, bym zapomniał, można i w asemblerze podmienić
ramkę stosu, a przecież jeszcze, kompilatory mają opcję że same przesuwają
ramkę stosu... W innych językach aż tak dużej swobody nie ma, a nawet
jakby była, to z powodu narzutu liniowego na czas wykonania, analizowanie
wielu implementacji nie bardzo ma sens. Zgadzam się, że potrzeba więcej
doświadczenia aby w C++ tak dobrze żonglować implementacjami i mieć
wyczucie która implementacja jak wpłynie na wydajność. Jednak jeśli pisze
się w C++ po prostu bezpieczny kod utrzymując szybkie tempo pisania, to
w C++ jest potrzebne to samo doświadczenie co w innych językach: doświadczenie
programistyczne.


> PS: Co do mej "zespolowosci". W Zespole pracowac potrafie dobrze. Fakt, iz nie
potrafie pracowac
> w bezmyslnym stadzie "nowoczesnych" niewolnikow podazajacym jak cma bez chwili
refleksji za kolejnym
> silver bullet (ostatnio stal sie nim scrum:)

Mieszacie w jednym wątku pracę zespołową z zaletami i wadami języków
programowania.


> Dinozaur
Pterodaktyl