On Monday, August 28, 2017 at 11:29:25 AM UTC-4, M.M. wrote:
> On Monday, August 28, 2017 at 4:29:04 PM UTC+2, Adam M wrote:
> > On Sunday, August 27, 2017 at 2:08:56 AM UTC-4, AK wrote:
> > > Użytkownik "M.M." <m...@g...com> napisał:
> > >
> > > >> Ceownik/Krzyzowiec chcacy pisac w innych jezykach ? Raczej zupelny unikat.
> > > > To chyba ja już wiem, dlaczego mamy diametralnie inne perspektywy.
> > > > Obserwowałem tylko takich, którym bardzo zależało, wręcz wychodzili
> > > > sami z inicjatywą.
> > >
> > > ..i tak trzymaj ! (powaznie). Na innych szkoda zwyczajnie czasu.
> > >
> > > >> O wiele czesciej "muszacy" (vide slawetny Ober-Ayatollah C++
> > > > > Sektor van Skijlen)
> > > >
> > > > Jeśli musi a nie chce, to mamy mucha po urwaniu ostatniej nogi traci słuch :)
> > >
> > > 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 :)
> > >
> > > >> Mowilem tu lata temu wiec powtorze jakze IMHO ma wciaz prawdziwa maksyme:
> > > >>
> > > >> "Czym sie rozni programista C++? Tym, ze zanim jeszcze zakoduje,
> > > >> juz optymalizuje!"
> > > >
> > > > Ok, masz rację, że ta pokusa do optymalizacji się pojawia mimowolnie.
> > >
> > > Alez chce (i czynie to!), ale dopiero wtedy _gdy to rzeczywiscie jest
potrzebne_,
> > > ale nie za wczasu.
> > > 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 :(
> >
> > Przyklad kolegi w typ przypadku jest nie na miejscu - w czasie zaczynania
aptymalizacji kodu ale emulatora nie bylo wiadomo czy 80286 bedzie dostepny (a
dodatkowo z dalaczonym 80287 - w tamtych czasach duzo PC AT nie mialo dokladanego
20287 bo kosztowal extra - dodakowo byly ograniczenia COCOM na sprzedaz do
demoludow). W tym przypadku optymalizazja byla uzasadniona - jak to mowi przyslowie
(niestety po angielsku) - hindsight is always 20/20.
> > Na problem nad-optymalizacji C++ cierpia glownie programisci starszego pokolenia
ktorzy wiekszosc czasu spedzili walczac z kompilatorami w latach 90tych - gdzie
doswiadczony programista mogl zoptymalizowac kod lepiej niz kompilator.
> > W dzisiejszych czasach w wiekszosci przypadkow nowoczesny kompilator jest zawsze
lepszy od programisty w optymalizacji kodu na docelowy procesor (Co nie znaczy ze jak
programista spieprzyl kod to kompilator to poprawi).
>
> W latach 90tych było inaczej. Kompilatory nie dość że kompilatory generowały
> kiepski kod, to jeszcze nie umiały malutkich funkcji wstawiać inline.
> Wszelkie próby napisać kodu przyjaznego dla kompilatora kończyły się
> totalną sieczką z punktu programisty czytającego ten kod. W dzisiejszych
> czasach nie widać dużych zmian w czasie wykonania po drobnej zmianie,
> zatem mam pytanie: co to znaczy (w tym kontekście) że programista
> spieprzył kod?
Tzn ze kod jest napisany nieefektywnie z powodu np. uzycia zlego algorytmu (albo zle
skalujacego sie algorytmu) - wtedy nawet najlepiej optymalizujacy kompilator nic nie
da.
>
>
> > >
> > > > 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.
> > >
> > Tak - wszyscy tak bardzo kochaja Pythona - zycze wielu skucesow w napisaniu
wielowatkowego programu w Pythonie (a dokladnie w CPythonie - najpopularniejszej
wersji) bez odwolywania sie do magicznych sztuczek. Python jest bardzo fajnym
jezykiem do prototypowania i szybkiej roboty - ale bez przesady - napisanie duzego
systemu w Pythonie to czysty masochizm.
>
> Dlaczego to masochizm? Myślałem że pisze się przyjemnie.
Male programy do kilkunastu-tysiecy lini napisane w wieksszosci przez jednego
programiste lub maly zespol (2-3 osoby) dobrze wspolpracujacych programistow - jak
najbardziej - bardzo przyjemnie sie pisze.

Duze systemy po kilkaset tysiecy lini kodu napisane w duzym zespole pisze sie
fatalnie

Programy silnie wielowatkowe - pisanie tego w Pythonie to pomylka (lub sztuka dla
sztuki bo w najgorszym przypadku zamiast przyrostu predkosci mozemy dostac strate).
>
> Pozdrawiam