🚀 go-pugleaf

Witam

Sebastian Kaliszewski wrote:

> Seweryn Habdank-Wojewódzki 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!
> 
> Tzn? Jest po pierwsze bardziej uniwersalna niż lista w C++

Tak.

> , jest lepiej 
> wpasowana do języka

Nie wydaje mi się, że lepiej.

> a w razie czego podstawienie zamiast niej czegoś 
> własnego nie wpływa mi na miejsca użycia.

A niby z czym w C++ masz problemy?

>>>>>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.
> 
> To jest skutek użycia języka który nie pomaga w bezpieczym pisaniu.

Chrzanienie -- mieszanie paskudnych zwyczajów C z językiem C++. Porównaj
sobie chociażby projekt MFC i GTKMM.

Jak chcesz podawać takie przykładziki, to wejdź sobie na Active... i tam w
sekcji recips dla Pythona poszukaj sobie przykładzików. Cała ich masa jest
tak napisana, jakby ludzie pisali w BASIC dla ZX. Projektu zero. Obsługa
błędów o ile zrobiona, to na poziomie "if :".
Wieź mi tu nie zalatuj przykładami kodu powstałymi w czasie kiedy Python był
co najwyżej w umyśle GvR. A GvR i wielu innych nauczyli się na tych
programach. Sam zresztą dobrze wiesz, że tego dziurawego systemu nikt nigdy
nie przepisze od zera. Poczekam co bedą ludzie mówili o programach w
Pythonie które będą równie stare jak ten system, bo na razie to mądrale
gadają i gadają, a wielkich projektów w Pythonie jest mało.

To co już obserwuję, to kaskada zależności pomiędzy wersjami i to dotczy
kodu w górę jak i w dół.
 
>>>>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.
> 
> To jest sytuacja jak najbardziej typowa.

Nie wiedzę o czym mówisz. W kodzie shared_ptr z boosta nie widzę żadnej
synchronizacji, więc nie wiem o czym mówisz.

>>>>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.
> 
> O maszynach lispowych słyszał?

Nie.

> Gdy wszyscy babrali się w command-line to 
> te cusie miały pełnoekranowy interfejs i bajery które reszta świata
> odkryła 10 lat później.

Dziś wiele rzeczy, które są od lat w Adzie ludzie odkrywają. To samo dotyczy
C++. Szablony były dawno, a niektórzy jej odkrywają dziś.
 
>> Słowem Gigant.
> 
> No właśnie tak!

Powiedz mi dlaczego Lispa określasz mianem giganta, a C++. Przecież lispa ma
więcej odmian niż jest różnych implementacji kompilatorów C++. Przenośność
kodu jest na poziomie 0. A jednak Ty go wychwalasz. Jakaś sprzeczność.

>>>>>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.
> 
> Jak potrzebowałem pożądnego rozwiązania to zrobiłe sobie sam. Mam stukturę
> o niewiadomej wielkości (a skąd mam wiedzieć ile obiektów zaraz zamierza
> utworzyć program korzystający ze Śmieciucha) która często gwałtownie
> rośnie. Wbudowany vector nie ma regulkacji tempa wzrostu a kurczenie jest
> w ogóle arbitrane (i zwykle po prostu nie występuje) -- zrobiłem sobie
> swój.

O jak mi przykro, że mogłeś się wykazać. A w Pythonie to takie predykcje są
robione w liście i w GC. I tak wolę C++ rozwiązania, bo są bardziej
dedykowane -- w zakresie swojego użycia są szybsze i mniej zajmują ramu.
 
>> O widzisz i tu sam się ugryzłeś w ogon :-D. Ten język jest niebezpieczny,
>> bo nie traci czasu na zabezpieczenia niebezpiecznych rzeczy.
> 
> Traci czas na duperele, takie jak synchronizacja shared_ptr której nie
> użyję w 95% wypadków.

Tak. Wiem. A synchronizacje w Pythonie nie istnieją -- podobno to jest
bezpieczny język? A w ogóle pokaż mi te synchronizacje w kodzie
boost::shared_ptr.
 
>> 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.
> 
> Nie mam takiej możlwości ani w przypadku wbudowanego new i delete ani w
> przypadku shared_ptr, itd...

Pokaż mi odpowiedniki w Pythonie.
 
>>>>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.
> 
> Haskell jest bardzo dobrze przemyślany, ale wymaga zupełnie innego
> "mind-set" niż języki imperatywne. C++ jest po prostu nieprzemyślany.

A może jest tak, że rzeczy proste robi się w nim w dziwny sposób, a rzeczy
dziwne w prosty sposób. Jakoś nie widzę różnicy pomiędzy komplikacją
szablonów i Haskella.
 
>>>>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ą.
> 
> Wolisz go mieć na sobie?

Dla mnie awaria to awaria. Czy na sobie to jest inna sprawa. Ale wolę
widzieć jak cieknie.
 
>> 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.
> 
> W silniku nie jest czysto.
> Jak ktoś zgubi olej to niedojedzie. Ale lepiej 
> żeby od razu nie został nim oblany.

Widzisz dla mnie lepiej jak zostanie oblany. Serwery mają działać długo. Jak
coś źle działa to nie zawsze tanie rozwiązanie polega ma resecie. Jak jest
jakiś bug gdzieś w aplikacyjne dla Xińskiego to sobie on może ją resetować.
Ja wolę takiego scenariusza nie rozważać. Wolę kiedy moja aplikacja u mnie
w sytuacji złego działania będzie oblewać mnie wrzącym olejem niż, żeby
serwer potem dziwnie działał. Rozumiem, że dziś miarą jakości jest marka
dyskontu spożywczego. Dawniej jak ktoś przychodził do Ciebie z reklamacją,
to jako sprzedawca (lub producent) paliłeś się ze wstydu, że zrobiłeś
badziewie.

> A jak się chłodnica zwali to ma nie 
> oblać kierowcy wrzątkeim.

To nie jest kwestia chłodnicy. To jest kwestia innych rzeczy.

> C++ to taki samochód, co przy pierwszej drobnej awarii traci hamulce,
> kierownica się blokuje a na kierowcę leci gorący olej i borygo.

Tak. To bardzo dobry język, bo low-quality koderzy dostają ciężkie baty.
Rozumiem, że dziś jest potrzeba zawodówek informatycznych -- chłopaki po SP.
nr 1023 z Pustkowia piszą łepsajty. Super nie zamierzam im zabierać chleba.
Są języki trudne i do nich trzeba podchodzić inaczej.

Zresztą Ty Sebastian nie doceniasz tego ile dało Ci C++ nawet jeśli
poparzyłeś się olejem nie raz i nie dwa razy. Pokaż mi rodowitego Py
kodera, który napisał swoje GC. 
Już Ci mówiłem jeśli za kodera jest za wiele napisane, to on potem sam nie
potrafi być twórczy. 

Np. systemy rozproszone najlepiej programują/projektują Ci co poczuli gorzki
smak C, C++ i innych języków brzydkich. Gawiedź pisząca w PHP, zazwyczaj
nie ma pojęcia o podstawowych kłopotach zarówno związanych z PHP jak i z
systemami rozproszonymi. To jest tylko przykład, ale w każdym
profesjonalnym fragmencie informatyki są takie zadania gdzie trzeba mieć
dużą wiedzę i należy posługiwać się technikami w sposób trikowy. 
Np. korzystanie z wszelakich frameworków jest zawsze nie intuicyjne i
trikowe. Nawet jeśli to jest proste (patrz tutek do Plone nie wspomnę o
EJB, który jest jak ASM w swiecie łepsajtów). Nie widzę osobiście żadnej
różnicy, trzeba się uczyć i nieustannie podnosić kwalifikacje i tyle. Jak
nie to w każdym języku szybko człowiek dołączy do Legacy People (tm).

Pozdrawiam.

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