On Sunday, August 27, 2017 at 8:08:56 AM UTC+2, AK wrote:
> Pracodawca/zycie/rzeczywistosc mu urwal wszystkie nogi (zmusil do C#:)
> Z satysfakcja obserwowalem jak zaczal.. chawilc C# :)
> (choc oczywiscie te jego chwalenia juz zawsze trzeba brac z rezerwa -
> zapewne znow chwali tylko to co.. ON sam zna/uzywa :)
Może to jest tak jak w tym kawale, w którym szef nie wie czy ma
leniwych pracowników, czy kiepskich. Jak im daje dwa razy większą
wypłatę, to ma pewność ;-)

A poważnie, to powinno być inaczej niż piszesz. Przejście z Javy,
C#, Pythona na C++ kojarzy mi się z takimi i innymi perturbacjami.
W Javie, C# i Pythonie łatwiej się programuje, trzeba mniej napisać,
głowę ma się mniej zaprzątniętą optymalizacją, szybciej jest radocha z
efektów. Szczególnie jest fajnie, gdy mam narzucone takie języki, bo
wtedy za potencjalnie zbyt małą wydajność i brak pamięci nie ja
odpowiadam. Dla mnie programować w takich językach, to radość w sercu.


> Alez chce (i czynie to!), ale dopiero wtedy _gdy to rzeczywiscie jest potrzebne_,
> ale nie za wczasu.
Szkoda że mogę rozmawiać tylko o amatorskich programach, jak np.
szachach. Dobrze jednak, że właśnie to przydarzyło mi się w
trakcie programowania szachów. Koledzy interfejs konsolowy mieli
napisane na typie char[256], ja, może bardziej wprawiony w
C++, nonszalancko zrobiłem na stringu i text-buforze. Potem
zacząłem robić turnieje z głębokością przeszukiwania ustawioną
na 2 ruchy w głąb. Wąskie gardło z przeszukiwania drzewa
przeszło na readLine, konwersje unicode, konwersje daty, i
mallocki w stringu. Cała praca poszła do kosza, musiałem
robić od nowa, oczywiście doświadczenie mi zostało, protokołów
nie musiałem się uczyć od nowa.


> PS: Pamietam dobrze taki fakt z moje pierwszej "przemyslowej" pracy (WSK Rzeszow
87r).
> Kolega z zespolu - doskonaly inzynier i numeryk napisal w czystym ASM na PC obsluge
> floating point bo w/g niego orginalne emulatory z kompilatorow/osobne typu emu287
> byly za wolne - i fakt ze byly ale... Sprawa byla powazna bo dotyczyla metod FEM
ktorych
> obliczenia trwaly (uklady rownan rozniczkowych czastkowych) dniami i nocami.
> Kod byl doskonaly, scisle zoptymalizowany (timingi rozkazow uwzglednione itp).
> Wydawalo sie wypas (bo byl to z programistycznego punktu widzenia wypas!) choc ja
mialem
> wlasne zdanie w sensie celowosci tego, choc wiedza merytoryczna nie dorastalem
Koledze
> do piet (no ale mialm juz za soba kilka ladnych lat z duzych maszyc wiec..)
> Skutek finalny: _w praktyce_ zysk byl kilka procent , a za kilka miesiecy pojawili
sie AT-ki
> z koprocesorami i cala jego robota (kilka miesiecy) poszla sie zwyczajnie (...)
pasc :(

Cóż mogę powiedzieć. Raczej wszystko jest oczywiste. Po pierwsze, trudno jest
oszacować i nakład pracy na optymalizację, i rozwój sprzętu komputerowego,
choć ostatnimi czasy w operacjach jednowątkowych procesory nie przyspieszają, a
nawet zwalniają. Po drugie, trudno jest przewidzieć o ile się przyspieszy
daną optymalizacją. Po trzecie, nie zawsze wiadomo, jaki będzie zysk z
przyspieszenia o 10%, o 20%, itd. Decyzję o przeprowadzeniu optymalizacji
podejmujemy zazwyczaj w warunkach ogromnej niepewności. Więc rzucanie się
na pisanie dużego fragmentu kodu w takim asemblerze, że w razie zmian w
kodzie/sprzęcie całość pójdzie do kosza, jest zazwyczaj szaleństwem, albo
treningiem, ludzie chcą często z ciekawości lub w ramach nauki sprawdzić.
Z drugiej strony, C++ to nie jest taki asembler, a czasami zwykłe
zakodowanie w C++ z minimalną ilością optymalizacji - wystarczy.
Kolejne optymalizacje zazwyczaj wymagają i więcej pracy, i mniej
przyspieszają.

Jakiś czas temu pisałem program w C++ właśnie bardzo normalnie z minimalną
ilością optymalizacji. Ani razu w trakcie rozwoju projektu nie zapędziłem
się w optymalizacyjny kozi róg. Nawet trzy systemy udało mi się zintegrować w
jeden, co prawda, przy integracji trochę kodu przepisałem, ale to
było relatywnie mało w porównaniu do całego nakładu pracy.


> > Może coś nie tak z moją spostrzegawczością, ale naprawdę nie widzę w tym
> > nic cennego dla mnie.
>
> Ale zobaczysz :) Sam jestem ciekaw.
> Podstaw Pythona nauczysz sie w godzine.

Ale co zobaczę? Chcesz mi pokazać że w pythonie pisze się znacznie mniej
kodu - to wiem, naprawdę szkoda naszego czasu i wysiłku. Chcesz udowodnić, że w
pół godziny jako programista C++ nie rozwiążę tamtych zadań optymalnie,
myślę że masz rację, a ja nie o to się kłóciłem - to jest totalne
nieporozumienie. Czy może chcesz się pośmiać ze mnie, że pętlę
umieszczam na zewnątrz klamerek [], zamiast w środku, a ja się
pośmieję, że nawet w pythonie są krotki w celach optymalizacyjnych?
To by była totalna głupota, więc chyba tego też nie chcesz... Nie
wiem do czego zmierzasz, co zobaczę? A może chcesz mi pokazać że to
będzie działało szybciej niż C++? To tak, to podejmuję wyzwanie.
Albo chcesz mi udzielić darmowej lekcji Pythona... to nie wiem czy
warto, bo w sieci jest sporo materiałów.

Pozdrawiam