🚀 go-pugleaf

Witam

Sebastian Kaliszewski wrote:


>>>>W Pythonie są jedyne słuszne rozwiązania np. jedyna słuszna lista i
>>>>nie płaczesz?
>>>
>>>W Pythonie mam rozwiązania bardziej elastyczne.
>> 
>> A jaka niby elastyczność jest zaimplementowana w Pythonowej liście?
> 
> Taka, że możesz ją podstawić czymkolwiek co "kwacze tak jak lista" i
> będzie dobrze.

To jest elastyczność algorytmów, tudzież kodu pracującego na liście a NIE
listy. Sama lista jest zamknięta!

> W Pythonie masz pełno "use any file-like object here and 
> you'll be fine, use any iterable collection there, etc).

Tak, wiem, ale to nie są ficzery tych kawałków języka, tylko samego języka,
generalnie komponenty języka Python nie są
wytyczalne/kustomizowalne/zmienialne.

Pokaż mi jak pięknie Python obsłuży kodowanie np. maziovii lub UTF-16? Nie
mówię, że w c++ to jest proste, ale może Python to potrafi to i ugryzie
takie kodowanie. Albo kiedy masz bazę danych taką surową, do której ciężko
o frejmłork, to wiedząc, że View będzie pracować na 20 000 danych jak
zapodajesz kontenerowi, że teraz akurat bedziesz chciał pracować na 20 000
danych dla View, ale algorytm dataminingowy potrzebuje 250 000 i ten
kontener ma być przygotowany również na to.
 
> To po całym chrzanieniu się w zrobieniu traitsów, localesów, itd, tego
> stringa, który niezależnie od platformy trzyma punkty kodowe unicode w
> jednym znaku, nie użyjesz nigdzie, poza wypisywaniem i czytaneim ze
> strumieni, gdzie biblioteka standardowa standardowo oczekuje stringa.

Super masz 100% racji, jeden bidny string po pierwsze nie jest kontenerem
jako takim. Lista pythonowa, też nie jest stringiem.

Kiedy zrobisz vector "dziwnych" znaków, to to zadziała i to super.
 
>>>Coś mi się zdaje, że zapomniałeś o której stornie pisałeś.
>> 
>> Cały czas pisze o 47.
> 
> Ale w tym na co ja odpowiadałem pisałeś o zupełnie inny slajdzie.
> Straciłeś tracking.

Nie. Cały czas piszę o tym slajdzie. Tylko raz skomentowałem 3.
 
>>>Włąmy to są przede wszystkim na domowe pecety, chodzące pod kontrolą
>>>softu pewnego dużego producenta pisanego głównie w C i C++.
>> 
>> Rozumiem że mówisz o UNIX np: Linux, Solaris, AIX czy HP-UX prawda? ;-)
> 
> Źle rozumiesz ;)

To znaczy, że dobrze rozumiem, że to nie jest wina C++, tylko prywatnych
spraw firmy o której myślimy i która większość softu na skrobnięte w C :-D.
 
>> Ot takie "specjalistyczne" sprawy związane z użyciem range vs. xrange.
>> Używając range szybko giniesz.
> 
> Nie. Najwyżej masz wooolny kod.

Przede wszystkim, co przy range miałem to "Out of memory", a nie wolny kod.
I to przy wartościach, które przy xrange są normalne -- naszczęście
nauczyłem się, że nowy styl Pythona sugeruje użycie xrange i tak też robię
stosuję trick w postaci xrange.
 
>> Jest adnotacja, że by używać xrange. To samo
>> jest w C++. Czegoś używasz, bo wydaje się być naturalne, ale adnotacja w
>> książce wskazuje jaka powinna być droga.
> 
> W przypadku range i xrange obie przenajmniej są funkcjami, ich podstaowwe
> użycie jest takie samo a dokumentacja jednego i drugiego leży obok.

Hmm... może i leży. Josuttis u mnie leży na półce powyżej monitora.
 
>> No więc w C++ będziesz miał smart_ptr, na razie są one w boost (i nie
>> tylko np. g++ ma już w sobie mocną wersję tr1).
> 
> Tyle że wbrew zasadzie you don't pay for what you don't use, w każdym
> użyciu zapłacę za sychronizację wątkową choć 95% wskazywanych obiektów
> nigdy pomiędzy wątkami nie będzie przekazywane.

Jak masz taki projekt to tak.

> A różnica w wydajności jest znaczna -- mniej więcej 2 razy.

Pokaż mi gdzie masz wszystko o czym piszesz i wydajność większą niż w C++.
 
> Co to znaczy ewidentnie niewłaściwe? W C++ sprawa jest poważnie
> zagmatwana, bo poza niejawnymi rzutowaniami masz jeszcze coś takiego jak
> promocja typów (też dziedzictwo z C, ale czy nie można było tego zostawić
> tylko dla extern "C"?).

Tego nie wiem. Traktuję to jako spadek historyczny. Na pewno kiedy powstawał
C++ tak było lepiej. To, że mi to nie odpowiada nie oznacza, że mam rację,
bo mam tylko swój punkt widzenia i zapewne nie uwzględniłem wielu
czynników.
 
>> Tego nie potrafię ocenić z punktu widzenia języka, który powstał w
>> latach '80, wtedy języki w ogóle oferowały mnóstwo ficzerów, w
>> szczególności Python miał stabilną wersję i C++ miał dobry wzorzec
>> do "skopiowania".
> 
> Akurat dynamicznych rozwiązań wtedy było duuużo -- wszelkie Lispy i
> Smalltalki były u szczytu.

Smalltalk może był u szczytu i może napisano w nim tak wiele softu, że teraz
uginamy się pod dziedzictwem tego języka -- w szczególności projektanci
Javy to smaltalkowcy, którzy nie poprawili umierającego języka tylko
zrobili lepsze C++ -- takie ono jest lepsze, że sam mówisz o nim źle.

A Lisp, no po prostu gigant softu król wyznaczający szosy dla maluczkich.
Jak widać mamy w tym języku popisane systemy operacyjne, aplikacje
multimedialne, GUI, łepsajty, aplikacje bankowe, gry, ... itd.
Słowem Gigant.

>>>2. Jeśli weźmiesz mechanizmy dynamiczne, to tu masz kolejne, poważne
>>>spowolnienie, w dodatku algorytm zmniejszania rozmiaru jest arbitralny
>> 
>> A tablice to sobie możesz zmniejsza?
> 
> Tablica jest lżejsza. Natomiast w wektorze zmiany rozmiarów są arbitralne.
> Przy dużych danych są też parszywie powoooolne (co powiesz na zamieranie
> programu na kilka senund sic(!) -- zupełnie jak wczesne GC z Javy 1.0) --
> i szybkie nie będą, ale przydałąby się możliwość trochę lepszego
> sterowania niż .reserve().

Mnie to wystarczy. Tak jak Piotr przewiduję liczbę elementów osadzanych w
kontenerze i o stosowną liczbę go powiększam. Lepszym rozwiązaniem jest
napisanie alokatora, ale tylko raz tak poważnie podszedłem do zadania więc
nie mam wielkiego doświadczenia w pisaniu alokatorów.

>>>(a co jest dobre do wszystkiego nie jest dobre w niczym).
>> 
>> Rozumiem, że mówisz o liście w Pythonie.
> 
> W Pythnie zwykle nie wymagam skrajnej wydajności. Na użycie C++ musi być
> jakieś uzasadnienie.

O widzisz i tu sam się ugryzłeś w ogon :-D. Ten język jest niebezpieczny, bo
nie traci czasu na zabezpieczenia niebezpiecznych rzeczy. Jeśli chcesz je
zabezpieczyć robisz to sam i według swojego uznania eliminujesz
niebezpieczeństwa i używasz sposobów adekwatnych do sytuacji. 
Np. po co w aplikacji jednowątkowej mieć synchronizację wątków? 
Albo mając aplikację wielowątkową widząc gdzie się one spotykają
synchronizujesz dokładnie to co jest wspólne i w sposób najbardziej
odpowiedni. Jeśli aplikacja jest "event driven" to używasz monitorów, jeśli
np. zmienna jest zmieniana "na zmianę" przez kolejne wątki, to może lepiej
użyć mutexa, nic na siłę, robisz co uważasz za stosowne. 
I tak np. piszę aplikacje przede wszystkim wieloprocesowe i ostatnio
rozproszone, żadne języki wysokiego rzędu nie oferują mi tego co
potrzebuję. Nauka surowego C++ od zera pozwala mi przenieść myślenie z
wątków na procesy oraz z lokalnych problemów na rozproszone (np.
rozproszone przydzielanie zasobów z pokoleniowym zliczaniem referencji).

>>>Jak w Śmieciuchu zastąpiłem vector włąsną klasą to miałem zysk wydajności
>>>ok 30%.
>> 
>> Rozumiem. A w Pythonie też zastępujesz listę swoim wydajniejeszym kodem?
>> Czy może jest tak, że język nie ułatwia takich manewrów i lepiej nie
>> kombinować?
> 
> Język specjalnie nie utrudnia, ale specyfika jesgo jest taka, że żadziej
> potrzebuję.

No więc jak Py Cię rozleniwia, to zdecydowanie rozumiem, czemu narzekasz na
C++ który wymaga pracowitości.

>>>Przykładziki pokazują problemy a nie styl kodowania mający na celu te
>>>problem obchodzić.
>> 
>> Nie. Przykładzik pokazuje kod, którego nigdy żaden n00by nie napisze.
>> To są hakerskie triki. Jeszcze raz podkreślam przykład na stronie 47 jest
>> extra dziwny. Żaden n00by w C++ tak kodu nie napisze -- pomijam n00by C
>> piszący w C++.
> 
> Problemem nie są nooby robiące program na zaliczenie. Ale ludzie
> doświadczeni, którzy dostali nowe wyzwanie -- nauczenie się C++.

Doświadczeni, czy Legacy people(tm)? Jak mnie nauka Haskella idzie opornie,
to nie narzekam, że język jest do bani.
 
>>>A od kiedy uważam J za dobry język? Toż to przerośnięte, ciężkie krówsko,
>>>typowy overdesign.
>> 
>> 
>> Ach! Dawno nie słyszałem takiego określenia. Poproszę jeszcze o jakiś
>> przymiot na C# i może jakiś na Haskella.
> 
> C# to krówsko nieco w stosunku do J poprawione, ale zato nie dające
> wygonić się poza oborę MS.
> 
> A Hakell? Tego, że tak powiem, słabo znam. Może: "Napisany przez
> zboczeńców dla zboczeńców" ;)

Uh! Toś przywalił.

> Mam tu na myśli pozytywne znaczenie, nacechowane podziwem. Tak jak
> podziwiam gości którzy myślą drzewkami i dla nich lispowe S-expressions są
> de best. 

Szkoda, że tak nie piszesz o Spiricie i MPL.

>>>>No to mnie pouczyłeś. Np. takie numpy jest napisane oczywiście w
>>>>Pythonie ;-).
>>>
>>>Chodzi o to, że Python nie cierpi tak jak C++ z powodu śmieci z C.
>> 
>> Cierpi, czy nie cierpi to jest kwestia tego jak elegancko śmieci są
>> upchane pod dywan.
> 
> Raczej czy mamy klapę od silnika, aby było ciszej i jak olej pocieknie to
> żeby został pod klapą.

Widzisz mnie to nie rajcuje, że jak olej cieknie to zostaje pod klapą. Dla
mnie pod klapą ma być równie czyściutko jak na klapie. W szczególności, że
jak tak każdy zacznie olewać kiedy mu cieknie, byle nie na szybę, to
będziemy jeździć na drogach posmarowanych olejem, a od tego do wypadków na
szeroką skalę jest tylko krok.

Widzisz rozumiem, że dziś opłaca się kupić serwer i umieścić na nim jedną
aplikację i jeśli coś cieknie, to cieknie tej jednej aplikacji, ale zdarza
się, że tak strasznie pocieknie, że aplikacja nie ma oleju i silnik się
zatrze.

A bardziej softwareowo to np. UB przy niedeterminizmie panującym w
aplikacjach wieloprocesowych i wielowątkowych to jest jak cios boksera wagi
piórkowej w stosunku do ciosu boksera wagi ciężkiej. Wolę mieć postawioną
czujność od początku, aby być czujnym tam gdzie trzeba. Nie ma takiej
osoby, która nie mając pojęcia o problemach na takim czy innym poziomie,
ale trudnych potrafi rozwiązać nowy problem jeszcze trudniejszy. 
Czy kupujący zaliczenia studenci potrafią potem w pracy coś wykonać sami? 
Na pewno potrafią kupić sami.

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/