🚀 go-pugleaf

Seweryn Habdank-Wojewódzki wrote:
>>>Czemu zawsze kłócimy się o to samo?
>>
>>Fatum? ;)
> 
> 
> No to mamy pecha :-D.
>  
> 
>>>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. W Pythonie masz pełno "use any file-like object here and you'll be 
fine, use any iterable collection there, etc).

W C++ jest zaś tak, że choć zrobisz sobie
#if(sizeof(unsigned int) >= 4)
  typedef
    std::basic_string<unsigned int, my_unicode_char_traits<unsigned int> >
    ustring;
#else
  typedef
    std::basic_string<unsigned long, my_unicode_char_traits<unsigned long> >
    ustring;
#endif

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.

A wystarczyłoby, żeby biblioteka tam gdzie oczekuje napisu zamiast czekać na 
const char* czy const std::string& czekała na const std::string_like&, gdzie 
std::string_like jest specjalnym typem na który wszystko co użytkownik chce 
traktować tak jak string było konwertowalne (użytkonik pisze w swojej klasie 
operator const string_like&), i z czego biblioteka wyciągała to co jej 
potrzebne. Sam string_like nie udostępniałby nic poza konwersją i jej 
okolicami, tak żeby nikt nie nadużył go do czegoś innego.

Inna rzecz to to, że rozmaite kustomizacje są starsznie ciężkie. Przykład 
takiego Micrsoft-like designu to całe iostream. Proste użycie -- OK, ale 
zrobienie czegoś własnego to kupa pisania, w tym np. łatwa do zrobienia źle 
i trudna do weryfikacji obsługa locali czy choćby samego zarządzania buforem 
-- choć 90% implementacji użytkownika zamierzałoby zrobić to tak samo 
(zamierzało, bo w realizacji będzie kupa bugów) to projektant całości nie 
wpadł na ten pomysł i tych błędogennych i niejasnych (i ohydnie, kryptycznie 
ponazywanych co już samo w sobie o czymś świadczy) elementów w żaden sposób 
nie wydzielił. W sensownie zaprojektowanej bibliotece miałbyś coś jak 
filelike_stream_bufer gdzie użytkownik miałby przeciążyć dwie chronione 
metody wirtualne -- read i write, mające interfejs jak funkcje o tych samych 
lub podobnych nazwach w 99.9% używanych systemów.


>>>A w ogóle pokaż mi co w Pythonie jest tym Testamentem? W
>>>itertoolsach są różne rzeczy ale testamentu nie widzę, sama lista też nie
>>>ma testamentu?
>>
>>W Pythonie iterator zna blisko obiekt iterowany i nie ma invalidacji
>>iteratorów. W Pythonie nie ma też problemu z przedwczesną śmiercią obiektu
>>iterowanego (dzięki GC).
> 
> 
> Przedwczesną, co to niby znaczy? Jak masz kontener i zanim związany
> iterator, to możesz tak jak w metodzie erase dla listy, zwrócić wskaźnik na
> następny element.
> 
> Natomiast *dokładnie* to co zrobiłeś w testamencie nie widzę w Pythonie, ale
> pewnie słabo patrzę.
>  
> 
>>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.


>>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 ;)


>>>C++ zakłada, że języka używa wykształcony koder, a nie gamoń.
>>
>>C++ zakłada, że koder zna wszystkie pułapki.
> 
> 
> NIE. To co Pokazał Pan F. nie jest w duchu C++.

O duchu też mówił. Że się zmienił.

> To jest jedyny naturalny błąd. Reszta błędów wynika albo z syfiastego stylu
> kodowania np. szkoła Pana F.

Wynika z naturalnego stylu kodowania w C++. Z używania podstawowych ficzerów 
języka w naturalny sposób dla jakiego zostały oryginalnie (nie)pomyślane. 
Nowy styl w żadym wypadku nie jest naturalny dla języka. Jest naturalny dla 
gości którzy się wielokrotnie sparzyli i dziś kombinują naokoło.

>, albo niedouczenia n00by używają char *
> zamiast stringa.

Taaaak. Zwłaszcza że w samej bibliotece standardowej w wielu miejscach nie 
da się nie użyć char*. I że literały napisowe to jest takie nieco zwichnięte 
const char*.

> Podkreślam n00by, bo w tych przypadkach użycie char *
> wynika nie z celowego sposobu kodowania, ale z faktu, że ktoś kiedyś kupił
> książkę do C coś przeczytał, nie przeczytał, że C ma specjalne utilki do
> pracy na char * i teraz robi w kodzie dziwy nad dziwami.

No właśnie. Nienaturalny styl, zrobiony przez poparzonych językiem.


> Kolejny błąd n00by to jest bałaganiarstwo w rzutowaniach. Raz używa typu
> size_t, drugi raz int, innym razem long, a jeszcze innym unsigned short.

A żeby było czysto to powinien użyć std::jakiś_tam_container<jakiś tam typm, 
jakiś tam alokator>::size_type (szkoda, że nie dłużej)

> A błędy pokazywane przez Pana F nie pochodzą z kursu dla n00bów, to są
> bardzo wysublimowane i spreparowane przykładziki.

To są krótkie przykłądy pokazujące rzeczywioste, poważne, problemy

>>>>Ale nie wszędzie kod najbardziej oczywisty jest kodem niebezpiecznym i
>>>>niestylowym. To jest domena C++.
>>>
>>>Zapewne. To niech lewary nie piszą w C++! Nie wszyscy maja maturę, nie
>>>wszyscy kończą studia, nie wszyscy muszą pisać w C++.
>>>Nikomu nie każe pisać w C++.
>>
>>Ale przez te wszystkie nieoczywiste drogi, nawet nie-lewary popełniają,
>>często bardzo poważne a zarazem trudne do znalezienia, błędy.
> 
> Zgadza się. Chociaż dokładnie to samo czuję pisząc w Pythonie (zapewne nie
> spełniam poprzednika implikacji -- jestem PyLewar :-) )
> 
> Ot takie "specjalistyczne" sprawy związane z użyciem range vs. xrange.
> Używając range szybko giniesz.

Nie. Najwyżej masz wooolny kod.

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


>>>>>Jeśli gdzieś są takie zwyczaje to
>>>>>kończy się to na posiadaniu GC.
>>>>
>>>>I dobrze. GC znane jest od ponad 40 lat.
>>>
>>>To nie jest odpowiedź na moje pytanie.
>>
>>Problem własności rozwiązauje się właśnie za pomocą GC, lub reference
>>countingu.
> 
> 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. A różnica w wydajności jest 
znaczna -- mniej więcej 2 razy.


>>>>>To jest właśnie poziom haków Pana F.
>>>>
>>>>Nie, pan F. pokazuje rzeczywiste przypadki rzeczywistych kardynalnych
>>>>błędów projektu samego języka, a to jest pokazanie nadużycia mechanizmu
>>>>skąd inąd przydatnego.
>>>
>>>Ach tak. A może skądinąd rzutowania rodem z C też są czasem przydatne?
>>
>>Rzutpowania rodem z C nic ciekawego nie wnoszą.
> 
> Właśnie to jest ustalane w innym wątku. Mnie osobiście np. niejawne
> konwersje denerwują, ale to jest domena kompilatora, aby rzucał
> ostrzeżenia/błędy przy ewidentnie niewłaściwych rzutowaniach.

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"?).

>>>>>Zrobić coś nie całkiem tak, jak to się powinno robić, a potem gadać o
>>>>>wadach.
>>>>
>>>>Co jest niecałkiem tak? UB, gdy masz głupi, prosty błąd użycia iteratora?
>>>
>>>Wskaźnik to nie iterator. Tam przede wszystkim pojawia się paskudne
>>>rzutowanie na bar.
>>
>>Zapomniałeś o którym slajdzie pisałeś.
> 
> Cały czas piszę o 47. Ten slajd jest dla mnie szczytem hakerstwa (w sensie
> lokalnego maksimum w obrębie slajdów Pana F.).
>  

j.w. Ustosunkowywałem się do Twojej wywiedzi dotyczącej zupełnie innego slajdu.


>>>>Przykazywany jest wskaźnik na obiekt klasy pochodnej do funkcji
>>>>oczekującej wskaźnika na obiekt klasy bazowej -- to jest *standardowe*
>>>>użycie polimorfizmu. To, że funkcja oczekuje przekazania tablicy, tylko
>>>>przygłupi, kulawy język nie miesza tablice ze wskaźnikami to jest to co
>>>>jest.
>>>
>>>To jest spadek z C.
>>
>>skoro tak, to należało wprowadzić odpowiednie dynamiczne mechanizmy
>>pilnowania porządku. A nie zbyć sprawę UBekiem.
> 
> 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.


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


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


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


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


>>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" ;)
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. 
Ale i to i to, tak czy siak, słabo mapuje się na umysł przeciętnego 
programmeresa. Łagodne podejście funkcyjne jest fajne, ale taka czystość 
jaką reprezentuje Haskell jest dla mnie na dłuższą metę nie do zniesienia. z 
gruntu stanowe IO po prostu ma inną impedancję niż z gruntu bezstanowe 
programowanie funkcyjne. Monady to jest wybieg dla dopasowania impedancji, 
ale dla mnie to jest właśnie, wybieg.


> Będę miał kolekcję pejoratywów na języki kompilowalne :-D -- do użycia w
> następnych flejmach.

Proszę bardzo :)


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


pzdr
\SK