🚀 go-pugleaf

Sektor van Skijlen wrote:
>>Seweryn Habdank-Wojewódzki wrote:
>>[ o listach]
>>
>>>>, jest lepiej 
>>>>wpasowana do języka
>>>
>>>Nie wydaje mi się, że lepiej.
> 
>>LOL, W pythonie lista ma reprezentację w samej składni.
> 
> I to ma niby świadczyć o lepszym wpasowaniu do języka?

Ddaj do tego for, składnię dla splajsów, itd...


> WSZYSTKIE języki skryptowe mają takie właśnie "wsparcie językowe" do tzw.
> list, bo jest to w tych językach podstawowy i niemalże jedyny zbiornik.

Nie jedyny. Tu masz jeszcze tuple, słownik i zbiór -- czyli cały podstawowy 
zestaw. W bibliotece masz jesczcze następne (np talię).

>>>>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 C++ niby uniwersalne kontenery uniwersalne nie są, w miarę uniwersalność 
>>kończy się na vector i deque oraz map i multimap.
> 
> 
> Bo mniej więcej na tym kończą się kontenery w C++. Do vector i deque dorzuć
> jeszcze list, do map i multimap dorzuć set i multiset i masz komplet.

Tylko czemu interfejs jest tak parszywie niejednolity? begin/end to trochę mało.

> Poza tym nie wiem, dlaczego właściwie uważasz, że vector jest bardziej
> uniwersalny, niż list.  To prawda, że vector nadaje się do tzw. "większości
> zastosowań", ale ma jedną bardzo paskudną wadę: unieważnienie iteratorów
> następuje tam po każdej modyfikacji liczebności zbiornika.

Po każdej po której zmienia się capacity. capacity zaś zmienia się tylko 
czasami.

> Miałem właśnie
> ostatnio taki przypadek, że musiałem trzymać iteratory do elementów, żeby je
> móc szybko usuwać.

To możesz trzymać indeksy elementów i usuwac po begin()+index.


> Podpowiesz mi może, jakiego rozwiązania powinienem użyć w Pythonie?

wbudowanej listy albo deque -- zależnie co robisz.


>>>Wieź mi tu nie zalatuj przykładami kodu powstałymi w czasie kiedy Python był
>>>co najwyżej w umyśle GvR.
> 
>>Języki bezpieczne znane są od ponad 45 lat. Języki w których nie ma 
>>podstawoych dziur w systemie typów były popularne już blisko 40 lat temu sic(!).
> 
> A są nadal?

Ze dwa się ostały. Czasem pod smutowaną postacią, ale są.

> Powiedz, o które języki ci chodzi, to będziemy przynajmniej wiedzieli, na czym
> stoimy.

Pascal, Algol68, Lisp.

[...]
[o lispie już inni pisali, nie będę powtarzał]

>>>A jednak Ty go wychwalasz. Jakaś sprzeczność.
> 
>>Ja go specjalnie nie wychwalam. Po prostu stwierdzam fakt. Różne inne języki 
>>nieudolnie naśladują rozwiązania w Lispie znane od 30 lat.
> 
> Po prostu tłumaczą te ficzery na "ludzki język" :)

Też tak można przyjąć :) No bo on istotnie jest mało ludzki (szczególnie 
jego najstarsze części, ponoć w nowoczesnym kodzie już rzadko używane, ale 
zawsze co klasyka to klasyka -- car, cdr, cadr, brum-brum-pip ;) ).

>>>>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.
> 
>>W Pythonie włąsny kontener zrobię łatwiej i wygodniej niż w C++.
> 
> To ja poproszę o przykład - tak jak wyżej opisałem std::list.

Gdzie opisałeś std::list???

Co do przykładu -- na sieci pełno.


>>>I tak wolę C++ rozwiązania, bo są bardziej
>>>dedykowane -- w zakresie swojego użycia są szybsze i mniej zajmują ramu.
> 
>>Są kiepskie. Sztywne i równocześnie nadmiernie skomplikowane. I niewiedzieć 
>>czemu ponazywali różne rzeczy inaczej niż reszta świata.
> 
> Co nazywasz "resztą świata" - Javę, czy Lispa?

Javę, Smalltalka, skryptowce, itd...


>>>>>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.
> 
>>Haskell jest starannie przemyślany i ma ogromną wyrażalność. Szablony nie są 
>>ani przemyślane anie nie da się w nich sensownie wyrazić żadnej konkretnej 
>>złożoności -- trzeba stanąć na głowie żeby zrealizować zwykły warunek.
> 
> 
>>Szablony były zresztą (czasami panicznie) łatane. Stąd takie dziwności jak 
>>Koenig lookup, SFiNaE itd.
> 
> Koenig lookup jest tylko uporządkowaniem spraw,

Których nikt za wczasu nie przemyślał.

> a SFiNaE było od samego
> początku podstawą funkcjonowania szablonów w C++.

I wszelakich tricków na nich opartych. Ale od początku to toto nie było. 
Zobacz takie MSVC 5.0 -- tu np. nie działało.

> Można oczywiście kwestionować sensowność "ograniczania przez użycie" oraz
> sensowność sposobu pracy komitetu, który wysysa sobie z palca reguły języka,
> do których potem producenci kompilatorów muszą wyharatać implementacje (bo
> jakby goście wcześniej zauważyli te spaghetti-messages, to może losy wzorców
> potoczyłyby się inaczej). Ale na ówczesny stan wiedzy rozwiązanie wydawało się
> najlepsze.

Wydawało? Czy się raczej wyłoniło się z chaosu (poprzedzających implementacji).


> Ale jeśli wydaje ci się, że języki, których standardy są robione równolegle z
> referencyjną implementacją, nie posiadają idiotyzmów, to jesteś w błędzie.

Nie wydaje mi się.

> Właśnie ostatnio się o tym przekonałem. Java, jako jedyny język z grupy
> Java/C#/C++, posiada ścisłe wyjątki.
[...]
> I to jest ficzer, który mocno utrudnia życie, nie sądzę żeby przyczyniał się
> do zwiększenia jakości developmentu, a zmienić go już nie będzie można. A do
> wzorców w C++ definiowanie ograniczeń dodać można.
> 
> I która z tych pomyłek jest bardziej spektakularna?

Ze specyfikacjami wyjąytków to jest tak, że zwalono je zarówno w C++ jak i w 
Javie, przy czym statyka Javowa lepiej pasuje do C++ a dynamika z C++ do Javy.

[...]
> (przy okazji - część w C++ to w miarę uniwersalny agent zdalnie uruchamianych
> aplikacji; osiągnęła aktualnie jakość przedprodukcyjną - czytaj trzeba
> pousuwać zbędne printy do cerr i zmienić sposób logowania pracy - i w trakcie
> jej developmentu nie napotkałem do tej pory ani jednego UB, ani SIGSEGV.
> Faktem jest jednak, że nie chodzi pod Cygwinem, bo jest jakiś problem z
> pthreads:)

Cóż, pthreads i ich implemetnacje to historia sama w sobie.


>>>>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.
> 
> 
>>Klient ma gdzieś, czy koder dostał baty czy ucieło mu głowę czy co innego. 
>>Klient nie ma zamiaru bycia oblanym olejem i borygo.
> 
> 
> Moment - może najpierw zastanówmy się, o czym w ogóle rozmawiamy.
> 
> Czy rozmawiamy o języku, który przed każdą operacją wykonuje 10 sprawdzeń, czy
> na pewno tak, czy o platformie wykonania, która potrafi wszelkie tego typu
> wycieki odpowiednio "zamaskować"?

Ani o tym ani o tym. Chodzi o to, by błędy wykonania były "contained". Niech 
sobie będzie abort, wyjątek, cokolwiek, ale niech po pierwsze będzie a po 
drugie niech będzie tylko to (a nie losowa poprawka do przetwarzanych danych).

>>>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.
> 
>>Tylko niektóre są trudne nie przez złożoność problemów które się wnich 
>>rozwiązuje tylko przez brak jakiegokolwiek projektu i robienie na zasadzie 
>>zlepku rozmaitych, dobrych i złych, ale dla paru wariatów "sexi" pomysłów.
> 
> Zgadza się - ale na te zwykle są gotowe rozwiązania, tylko wystarczy się
> rozejrzeć.
> 
> Natomiast "łatwe języki" zwykle dają złudzenie łatwości tematu w przypadku
> trudnych zagadnień. Jednym z takich trudnych zagadnień jest wielowątkowość.

Wielowątkowość jest parszywa z zasady. Musi zostać albo ładnie przykryta 
(przy czym nie znam łądnego przykrycia; nie znam Koguta, Qrczak mówi że tam 
jest to ładnie zapakowane, jak rozumiem) albo po prostu zlikwidowana (choćby 
na rzecz włókien i wieloprocesowości).

[...]

pzdr
\SK