🚀 go-pugleaf

Witam

Sebastian Kaliszewski wrote:

> Witam
> 
> 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?

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

>>>>Tak. A i tak kolesie pokroju Pana F. nie używają jej -- przykład tablica
>>>>obiektów typu foo rzutowana na bar*.
>>>
>>>To czemu język na to pozwala?
>> 
>> A Python pozwala kasować metody, czemu?
> 
> Bo jest dynamiczny.
> 
>> Czemu nie ma sekcji prywatnej w klasach?
> 
> Została uznana za zbędną w języku o filozofii jaką reprezentuje Python
> 
>> Czy python zakłada dobrą wolę kodera? Słusznie.
> 
> Tak.
> 
>> 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++. Jedynym częstym błędem
popełnianym w C/C++ to jest ufność, że znamy długość tablicy.

To jest jedyny naturalny błąd. Reszta błędów wynika albo z syfiastego stylu
kodowania np. szkoła Pana F., albo niedouczenia n00by używają char *
zamiast stringa. 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.

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 błędy pokazywane przez Pana F nie pochodzą z kursu dla n00bów, to są
bardzo wysublimowane i spreparowane przykładziki.

> MPL to jest nadużycie przypadkowej Turing-completeness szablonów. Jest
> więc dziwne w użyciu a rzucane błędy kompilatora są "zabawne". No i
> zobaczyć build aplikacji trwający 3 dni -- bezcenne :)

Prosiłem o przykład. 

Podałeś, że 3 linie kompilują się 1 dzień, teraz mówisz o trzech dniach,
rozumiem, że mowa o 9 liniach. Jednak nie pokazałeś ich.
 
>>>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. 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.
 
>>>>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).

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

A czy w noszą, czy nie. To nie wiem. np. przesyłanie danych binarnych, tak
właśnie robisz. 

Bardzo mi się podoba implementacja tego typu rzutowań w Pythonie (moduł
fpconst). Tam jest typowe rodem z C wpakowywanie danych binarnych.
I nie mówię tego z przekąsem, bo moduł właśnie dzięki takiemu sposobowi
podejścia do kodowania jest prosto napisany i działa bardzo dobrze.
 
>>>>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.).
 
>>>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". 
 
> 1. Wektor oznacza adresowanie pośrenie, tablica niekoniecznie (albo w
> najgorszym przypadku wzgłedem stosu) -- procesory OOO obsługują tablice
> nieco szybciej.

OK. Ale nie w kontekście tego przykładu o którym pisze Pan F.

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

> (a co jest dobre do wszystkiego nie jest dobre w niczym).

Rozumiem, że mówisz o liście w Pythonie.

> 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ć?

> 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++.
 
>>>Mamy język w którym są tablice, ale nie można ich używać, tylko jakiś
>>>cięzkich typów bibliotecznych, bo język jest spieprzony. To są Jaja na
>>>Resorach(tm).
>> 
>> Tak. Jaja na resorach. Zrób sobie statystykę ile ludzi używa surowych
>> tablic w innych językach?
> 
> W tych dobrych? Tylko perwerci nie używają.

A jaką to niby tablice ma Python? Ma bardzo zaawansowaną listę/deque.
Java ma tablice C# ma tablice i tam ludzie i tak wolą kontenery. W J
chociażby dlatego, że interfejsy kontenerów są wspólne.
 
> 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. 

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

>>>Kod w C często jest kodem w C++.
>> 
>> To jest wina edukacji i legacy people.
> 
> Ależ skąd. Wiele programów w C to programy zarazem w C++.

Rozumiem. Ale jak piszesz od początku w C++, to kod jest mocno inny niż w
typowym C.
 
>>>>>>Mi to w ogóle ten kod nie działa, a jak go poprawiłem to mi działa
>>>>>>dobrze.
>>>>>
>>>>>Taaaak??!?!?!? O, to ciekawe!

Jeszcze raz napiszę. Kod pierwotnie poprawiłem przy użyciu bar** i
polimorfizmu dynamicznego.

Później użyłem jednego szablonu i też kod działa, przy niskim poziomie
dynamizmu.

Pozdrawiam.

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