🚀 go-pugleaf

Dnia Wed, 21 Nov 2007 14:45:24 +0100, Sebastian Kaliszewski skrobie:
> 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?

Oj, Sebastian... gdybym cię nie znał, to bym myślał jeszcze, że mówisz
poważ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.
Z drugiej strony, poza językami funkcjonalnymi trudno znaleźć języki ogólnego
przeznaczenia z najpopularniejszych, które nie są skryptowe i mają takie listy
w języku.

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

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

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

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

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

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

> Ada to jest rzecz całkem nowa i młoda w porównianiu do paru innych języków.

A może byś tak napisał coś do rzeczy, zamiast rzucać sloganami?

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

> Słyszałeś o Common Lisp? CLISP?

Owszem, jest to jedna z odmian Lispa, z ponad 10 łącznie. Cytując za
Wikipedią:

Common Lisp (1984), as described by Common Lisp: The Language (CLTL) . a
consolidation of several divergent attempts (ZetaLisp, Spice Lisp, NIL, and
S-1 Lisp) to create successor dialects[6] to MACLISP, with substantive
influences from the Scheme language as well. This version of Common Lisp was
available for a wide range of platforms and was accepted by many as a de facto
standard[7] until the publication of ANSI Common Lisp (ANSI X3.226-1994).

Podczas gdy oryginalna specyfikacja Lispa pochodzi z roku 1958.

Co oznacza, że po prostu zebrała się pewna ekipa i połączyła 5 "najlepszych"
dialektów Lispa w jedno. I tak powstała kolejna odmiana Lispa. Sam fakt, że
zatwierdził to ANSI nie świadczy jeszcze o tym, że nagle wszyscy użytkownicy
Lispa nagle przestawili się na "nowy standard". Nie mam co prawda żadnych
informacji ntt., ale już sam fakt, jak długo dogorywał ARM C++ (a i nadal
pewnie nie zdechł do końca) pozwala mi wątpić, jakoby istniał jakikolwiek
"wspólny i jedyny standard Lispa".

Sam C++, od czasów ARM, dorobił się dialektów raptem trzech (w porywach). A i
tak nie ma to tu specjalnie mówić o dialektach, biorąc pod uwagę, że chodzi tu
właściwie o rozszerzenia Borlanda i Microsoftu (rozszerzeń gcc nie liczę, bo w
ostatnich wersjach rozpirzyli wszystkie rozszerzenia na cztery wiatry).

> >  Przenośność
> > kodu jest na poziomie 0.

> To nie jest prawda

Czyżby?

> > 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" :)

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

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

> >>>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, a SFiNaE było od samego
początku podstawą funkcjonowania szablonów w C++.

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.

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.

Właśnie ostatnio się o tym przekonałem. Java, jako jedyny język z grupy
Java/C#/C++, posiada ścisłe wyjątki.

Efekt jest taki, że zamiast skupić się w trakcie "dewelopmentu" na tym, żeby
przynajmniej działał optymistyczny scenariusz, a wszelki "error handling"
odłożyć na później, pierwsza rzecz, z którą muszę walczyć, żeby mi się
kompilował kod, to z zaprogramowaniem polityki obsługi błędnych sytuacji przez
wyjątki. Zazwyczaj efekt jest tego taki, że polityka obsługi błędów jest
odwalona na kolanie i zrobiona na łapu-capu, bo chciałbym jak najszybciej,
najtańszym kosztem otrzymać wreszcie coś, co mogę sprawdzić, czy zechce
działać.

A to w Javie nie przelewki, bo tam znacznie większa ilość błędnych sytuacji
jest sygnalizowana wyjątkami, niż w C++. Efekt tego przykładowo jest taki, że
jak w C++ mogę sobie zrobić (tak, wiem, że to POSIX, ale chodzi mi o
praktykę):

sleep( 10 );

to w Javie trzeba zrobić:

try { Thread.sleep( 10 ); } catch ( InterruptedException e ) {}

I tu właśnie nasuwa się pomału sugestia, dlaczego ścisłe wyjątki są głupim
rozwiązaniem: po prostu, w większości normalnej pracy dany wyjątek nie ma
szansy wystąpić. Jeśli, dajmy na to, jakaś funkcja przyjmuje liczby całkowite
i dla ujemnych rzuca StupidValueException, to po cholerę mam robić try/catch,
skoro wywołuję ją z abs(value) ?

Sam nawet byłem kiedyś zwolennikiem ścisłych wyjątków - wydawało mi się, że
zrobienie ścisłych wyjątków pomogłoby statycznie wyeliminować "unexpected
exception", a także zrobić jakiś sensowny użytek z ograniczeń na wyjątki.
Nadal uważam, że pomysł jest wart rozważenia, ale do tematu należy podchodzić
cholernie ostrożnie. A właściwie to jedyną sensowną formę sprawdzanych
wyjątków widziałbym w postaci dodatkowego narzędzia, które wykonuje dokładne
śledzenie wyjątków i wskazuje, gdzie może wystąpić nieoczekiwane zwinięcie
przez wyjątek. Nawet już są narzędzia, które to robią, tylko po prostu jedynym
dodatkiem byłaby możliwość używania tej informacji przez kompilator w celu
zoptymalizowania kodu (eliminacji zbędnych sprawdzeń w czasie wykonywania).

Gdyby używać takiego narzędzia, można by się bawić w ograniczenia na wyjątki.
Jeśli to narzędzie byłoby wystarczająco wiarygodne, wtedy można by W RAZIE
CHCIEJSTWA (a w razie niechciejstwa nie) używać organiczeń na wyjątki i
przechwytywać je w odpowiednich miejscach. Często nawet w wielu API ma sens
posiadanie osobno funkcji rzucającej wyjątek i nie rzucającej wyjątku, czy
nawet posiadanie funkcji, która przejmie wszystkie wyjątki i ewentualnie
zwróci wartość błędu.

A co jeszcze ciekawsze, nie wszystkie wyjątki w Javie wymagają jawnej obsługi.
Czyli - ścisłe, ale nie do końca?

Ja wiem - ścisłe do końca nie miałyby w ogóle sensu, bo wtedy każde jedno
głupie odwołanie się do dowolnego wskaźnika na obiekt należałoby obwarować
łapaniem np. NullPointerException. Ale to nie powoduje bynajmniej, że te
ścisłe nie do końca wyjątki mają tego sensu więcej.

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?

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

> ???
> Jeśli już, to właśnie C++ z jego UB i heisenbugami to jest jakość dysnontu 
> zpożywczego.

z pożywczego, czy bez, heisenbugi zdarzają się tak samo w C++, jak i w Javie.
A ja robię właśnie aplikację, której część jest w Javie (GWT), część w C++ i
część w Tcl-u i mogę powiedzieć jedno: jak na razie najbardziej męczy mnie
Java - ale to pewnie dlatego, że Javę najmniej znam. Moje pierwsze wrażenia są
takie: nigdy niczego nie można być pewnym na 100% :)

(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++ 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ć"?

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

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

> A może to to że gawiedź pisząca PHP to właśnie, w znacznej większości, 
> gawiedź a nie specjaliści. Od specjalisty wymagam znajomości Podstawowych
> Kłopotów (powinieneś na to dac (tm) :) ) związanych z systemami 
> rozproszonymi, współbieżnymi, z algorytmiką, bazami danych, systemami 
> operacyjnymi, rachunkiem prawdopodibieństwa, teorią mnogości, analizą i 
> algebrą. Ot takie mam drobne wymagania dla kogoś kto uważa się za specjalistę.

No i słusznie. Ale tak się akurat składa, że Języki Przemysłowo-Biznesowe(tm)
są w większości chwytane przez tych, którzy o powyższych sprawach nie mają
bladego pojęcia.

> Kiedyś uczestniczyłem we flejmie bodaj na p.c.programming, gdzie jakiś facet 
>   wypisywał jak to jego 16-letni syn kasuje wszystkich tych specjalistów i 
> jak jest de best programmer i w ogóle (bodaj kontekst dotyczył tego po co te 
> studia czy też czemu "oni" tyle pieniędzy chcą za "duperel" -- nie 
> pamiętam). Zapytałem czy jego syn mógłby mi łaskawie sprowadzić prostą bazę 
> (projekt bazy) do 3. postaci normalnej. Odpowiedzi nie dostałem :)

> Cóż, każdy Polak zna się na medycynie, ekonomii i architekturze, a jego syn 
> na informatyce ;)

Nieważne, kto strzela gole, ważne kto jest sędzią :)


-- 
//  _    ___         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"