🚀 go-pugleaf

Dnia Thu, 22 Nov 2007 16:11:08 +0100, Sebastian Kaliszewski skrobie:
> 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...

... która dobrze prezentuje się w tutorialach, ale w praktyce nie ma
różnicy, czy ten lukier składniowy jest, czy nie?

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

Ach i och. Perl i Tcl jako tuple wykorzystują ten swój podstawowy zbiornik,
zwany (akurat w obu) listą.

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

Jak to niejednolity! Jest cholernie jednolity. Do tego stopnia, że nie da się
zrobić standard-conformant listy jednokierunkowej (pojedynczo wiązanej), a
niektóre ciołki (jak np. autor języka D) nie rozumie, dlaczego do sprawdzania
czy string jest pusty trzeba robić if ( s.enpty() ), zamiast normalnie
if ( s.size() ).

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

Weź ty się z łaski swojej nie ośmieszaj, dobrze?

Gdybyś mi zrobił kod, w którym w jakikolwiek sposób polegasz na stabilności
wartości iteratorów do wektora po DOWOLNEJ modyfikacji tego wektora to razem z
tym kodem odesłałbym cię na zieloną trawkę.

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

A, jasne, oczywiście! Usunięcie elementu ze środka też oczywiście nie zmieni
mi względnego położenia obiektów od tego miejsca w dal.

Czy ty na prawdę tak na siłę chcesz coś udowodnić, że aż nie omieszkasz się
kompromitować?

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

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

Szczegółowo proszę - jak mogę przechowywać wartość, która będzie mi określała
pozycję elementu w zbiorniku i dopóki ten element będzie w zbiorniku, nie
zmieni się nigdy po jakiejkolwiek modyfikacji tego zbiornika.

Jak już dyskutujemy, to dyskutujmy konkretnie - jeśli masz jakieś sensowne
zarzuty, to je poprzyj. Na razie uciekasz w kąt.

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

No więc czym przepraszam chcesz uzasadnić twierdzenia, jakoby bezpiecznych
języków ktokolwiek potrzebował?

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

> Pascal, Algol68, Lisp.

Pascal? Bezpieczny? Chyba jaja sobie robisz.

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

Taaa...

O tym, dlaczego przemysł olewa Lispa, też nie ma sensu pisać.

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

Ano właśnie.

Ktoś mi mówił - nie wiem, czy nie Qrczak - że ta składnia taka miała
początkowo być tylko składnią pośrednią, a jako user-friendly składnia miało
być opracowane co innego. No ale podobno jakoś zaczęli używać tego języka w
tej składni wewnętrznej i nikomu się już nie chciało pisać normalnej składni.

Efekt jest taki, że może jakby ktoś zrobił z tego sensowną składnię, to może i
Lisp przyjąłby się bardziej. A tak - cóż.

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

Opisałem, jaką właściwość posiada list, której nie posiada vector.

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

To znajdź i wklej - dopóki tego nie zrobisz, dla mnie bredzisz od rzeczy.

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

Javę, powiadasz? Tam, gdzie mapa nazywa się Map, a strumień Stream?
Smalltalk to dla ciebie jest licząca się reszta świata?
Skryptowce, wśród których masz Tcl-a z Tablicą, Perla z Haszem i Pythona ze
Słownikiem?

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

Możliwe, ale nie sądzę, żeby się to dało zrobić w jakikolwiek sposób inaczej.

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

Oczywiście, że działało (jeśli oczywiście mówimy o M$VC 5.0 + SP2, które
obsługiwało np. przestrzenie nazw).

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

Z tego, co BS napisał w "DAEC++", rozważano wiele możliwości, jeśli chodzi o
sprawdzanie dopasowania wzorców. Okazało się, że takie będzie najmniej
kłopotliwe.

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

O tyle dobrze :)

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

Wyjątki są dynamiczne, czy tego chcesz, czy nie. Pytanie tylko, na ile chcemy
mieć do nich statyczne wsparcie, bo trzeba sobie zdawać sprawę z tego, że
wszelkie statyczne wsparcie to potencjalne utrudnienia dla użytkownika.

Poza tym, Java nie jest wcale taka znów dynamiczna. Nie widzę w tym względzie
żadnych większych różnic od C++.

> [...]
> > (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óż, trudno mi się nie zgodzić :)

Ale linuxowe implementacje akurat takich problemów nie mają (na szczęście, bo
inaczej to nie wiem, gdzie bym tą aplikację uruchomił!).

Myślałem nawet, żeby podesłać tą moją aplikację ludziom od Cygwina, żeby sobie
poprawili - ale niestety o uwolnieniu tego kodu to trzeba by ewentualnie
później pomyśleć, bo na razie niestety nie ja jestem jego właścicielem.

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

Dobrze, nawet się zgadzam. To teraz przystaw to do praktycznych możliwości
realizacji powyższych założeń.

Jeśli chodzi np. o odwołanie się do zerowego wskaźnika, to masz tu dwie
możliwości: albo w języku sprawdzasz wskaźnik przed każdym odwołaniem
(usuwając jedynie zbędne sprawdzenia, gdy jest to bezużyteczne), albo
posiadasz platformę wirtualną, na której uruchamiany jest program, i która to
platforma sama posiada odpowiednie właściwości pozwalające na wygenerowanie
wyjątku w takim przypadku. W obu przypadkach mamy do czynienia z dodatkowym
narzutem, który jest tylko czasem akceptowalny.

Jeśli chodzi o wiszące wskaźniki, to sprawę załatwia odśmiecacz, ale on z
kolei wprowadza dodatkowe wady. Niezależnie od tego, czy się z tym zgadzasz,
czy nie :)

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

O ile sobie przypominam, w systemie Mach istniały "wątki", które należało
ręcznie przełączać poprzez wykonanie odpowiedniej funkcji.

Wątki po prostu powinny pracować na niezależnych danych. Ta aplikacja, którą
zrobiłem, przykładowo, używa wątków do tunelowania dostępu. Od strony Javy
wątki zapewniają jedynie bezpośrednią komunikację z engine'em w tym sensie, że
wątek główny pisze do socketu, a wątek dedykowany czyta i aktualizuje pola
stanu.

Mało co prawda napisałem w życiu aplikacji z użyciem wątków, ale jak na razie
zawsze obchodziłem się bez muteksów. Używałem jedynie volatile.

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java is answer for a question that has never been stated"