🚀 go-pugleaf

Witam

Sebastian Kaliszewski wrote:

>>>>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(!).
>> 
>> Tak i gdyby wtedy informatyka bazowała tylko na nich to do dziś byśmy
>> mieli tylko maszyny do pisania. Niebezpieczne języki pozwoliły wejść na
>> orbitę szybkości.
> 
> Nonsens. Wiele innych kompilowanych języków by się nadawało.

Ale się nie nadały. Przykro mi. Naprawdę. Wiem jak to jest kiedy produkty
bardzo dobrej jakości przegrywają z produktami marki "dyskont".
Trzeba jednak żyć w takiej a nie innej rzeczywistości i starać się robić
najlepiej jak się da, ale tak, aby dało się jakoś sprzedać np. w postaci
projektu naukowego lub produktu dla klientów wymagających jakości. Jednak
odnoszę wrażeni, że języki, które kiedyś były rewelacyjne, były jak poezja
Norwida, niedoceniane i poszły w odstawkę. W przyszłości się do nich wróci,
aczkolwiek obserwuje trywializację. Np. Sun odgrzebuje starocie nadając im
nowe nazwy, ale nie poprawia niczego, tylko psuje i rzutuje na Javę, co MHO
źle się skończy (patrz projekty Scala i Fortress).
 
>> A gdyby nie te niebezpieczne języki, to dziś nie miałbyś tych
>> niby lepszych bezpiecznych języków nowej generacji. Python w ogóle by nie
>> istniał, bo jego reference implementation stoi po pachy w C.
> 
> Mogłoby równie dobrze stać w innym języku kompilowanym, hgdyby to ten
> język był językiem API OS.

No ale niestety API OS są paskudnie C-owate :-). Coś się tam Java wychyla
poprawiając Pana Boga -- nieudolnie naśladując Unix'a. Ale nie ma to w
ogóle porównania wydajnościowego, chociaż jak mnie ktoś uświadomił na
WallStreet zapłacą za dowolną liczbę komputerów więc ich przebicie 10 razy
liczba maszyn w stosunku do Unixa nie boli, do póki nie dojdą do zagadnień,
kiedy komunikacja stanie się ciężarem.
 
>> O tak? A czy Piotr nie wspomniał, że w wersji MT?
> 
> W paru kompilatorach nie maż wersji nie MT. Albo biblioteki których
> używasz są skompilowane w wersji MT i już -- bo w normalnej sytuacji to ma
> koszt przyzerowy a nie ma kłopotów jak ktoś włączy drugi wątek.

OK. Wyślę Ci kod shared_ptr wyciągnięty z Linuxa programem bcp. Będziesz
miał wersję ST, chcesz?
 
>> I czy nie możesz mieć swojej banalnej implementacji bez tej
>> synchronizacji?
> 
> Zrób to sam(tm) -- mantra C++.

Wyślę Ci.
 
>> Ale ja nie słyszę o tych jezykach, nie widzę ofert pracy, nie widzę
>> projektów (a już w mojej działce to w ogóle). Proszę oświeć mnie, bedę
>> wdzięczny.
> 
> Ludzie jedzcie guano! Miliardy much nie mogą się mylić!

Sebastian. Wszystko jest dobrze. Rozumiem Twoje dążenie do ideału. Kłopot
polega np. na tym, że do super języków nie ma ekip koderskich.

Lokalnie tutaj możemy uznać że Kogut jest jednym z bliskich ideałowi.
OK. załóżmy, że go umiemy. I teraz biorę ten język i mówię obcej kompanii
"chłopaki od dziś piszemy w Kogucie". Co oni na to? 

Co manago finansowy na to? Kiedyś ktoś mi powiedział, że manago nie może
zmuszać ludzi do nauki języka, bo oni za chwilę przyjdą po podwyżkę. 

Znajomość i nauka drugiego trzeciego, k-tego języka musi wyjść od ludzi
samych, bo wtedy finansista nie przylatuje z wrzaskiem, że za duże koszty
są generowane. Jego nie obchodzi to, że ekipa znająca dziś jeden język
jutro 3, dziś i jutro przyniesie stratę 100%, pojutrze zysk 500%. 
Manago finansowy patrzy, aby jemu kichany Annual Turnover się poprawiał, bo
ma w planie na koniec roku prezentację i tam wykres musi iść do góry.

Teraz mi powiedz jaki wybierasz język, aby jednak ekipa coś więcej
potrafiła. Przede wszystkim taki, który jest znany, bądź poznawalny kosztem
hobby. Zatem muszą to być języki nie tyle idealne, co języki mające taki a
nie inny support. Szybko okazuje się, że nawet jeśli ja znam Koguta, to mój
qmpel nie całkiem i ma problemy z poznaniem. Tak więc szybko topnieje
liczba ideałów, które mogą być używane w ekipie koderskiej. Do tego
dochodzą listy dyskusyjne tutki itd. Jakbyś nie patrzył, na grupach o C,
++, J, Py, jest spory ruch a takiego Lispa nie widzę. Jest oczywiście
grupa "funkcyjna", ale tam ruch jest mały, żeby nie powiedzieć znikomy.
 
> Python ma kilka lekkich wtrętów funkcyjnych. Ale AFAIR nie ma choćby
> rozwijania rekursji ogonowej (a w każdym razie na to gwarancji) więc kod w
> sytlu funkcyjnym, bez pętli, w Pythonie leży conajmniej źle.

Nie bądźmy purytańscy. Nie chodzi o pisanie tak samo, chodzi o możliwość
przeniesienia abstrakcji myślowej.
 
>>>W Pythonie włąsny kontener zrobię łatwiej i wygodniej niż w C++.
>> 
>> I jest równie wydajny i zajmuje równie mało ramu, co?
> 
> Python jakoś duuużo nie żre (zwykle mniej niż Java). Włącz sobie Psyco i
> porównaj.

Włączam i porównuje. Zresztą na grupie z Py, jeden kolo wyleciał, że mu Ru,
czy Perl lepiej działają. A ja sprawdziłem z Psyco i mi wyszło w Py
najlepiej. Ale Psyco ma wadę, nie hula na 64-bit w pełnej krasie, co w
sytuacji pisania kodu dla serwerów jest dziś niemiłe.
 
> np. owo nieszczęsne map (co to nie ma już dictionary?) czy nawet vector
> (zamiast array czy dyn_array czy dynamic_array).

Znaczy się, co? Nazwy Ci przeszkadzają?
 
> Nie mówiąc już o "super wygodnym" wykonywaniu takich dupereli jak
> sprawdzenie czy w mapie jest dany klucz.

map::count(klucz)?
 
>> Ile lat potrzebujesz aby napisać (skopiować) swojego shared_ptr, bez tej
>> nieszczęsnej synchronizacji?
> 
> Czytać kod boosta? Dziękuję, postoję.

Po co czytać, chociaż ja czytam. Użyj bcp i już.
 
>> A ja i tak nie widzę gdzie w pliku boost/shared_ptr.hpp jest
>> synchronizacja, poproszę o pomoc publiczności.
> 
> Publiczność (w osobie Piotra Wyderskiego) już pomogła :)

Z całym szacunkiem Piotr wskazał kod dla SPARKA. Wskarzę dla mojego marnego
Athlona na Linuxie i tam nie ma synchronizacji. Nawet pofatygowałem się,
aby przeglądnąć powstały asm i są używane tylko normalne komendy.
 
>> Zresztą, nie kapuję Twojego płaczu, kiedyś płakałeś, że nic nie jest
>> synchronizowane, teraz płączesz, że tr1::shared_ptr jest synchronizowany.
>> Nie rozumiem o co chodzi?
> 
> Dziecko wylane z kompielą?

Rozumiem. Ja nie wylewam dzieci, mogę Ci przesłać tego shared_ptr bez
synchronizacji.
 
> Nie ma:)
> Jest w lepszym miejscu :)

Dla mnie z mojego punktu widzenia wydajności nie ma znaczenia gdzie ona jest
jeśli jest.

>>>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.
>> 
>> Z czego SFINAE przynosi korzyści.
> 
> Tricki i nieczytelny kod.

:-D

To samo na razie myślę o Haskellu. Ale planuję to zmienić.
 
> Rozumiem że mowa o DBE (DataBase engines). Większość jest pisana po prostu
> w języku systemowym. Coś co dla poperawnego działania wymaga
> niebuforowanego dostępu do dysku, kontroli procesów (tego co ginie co nie)
> itd pisze sie raczej w języku systemowym.

A systemy czemu są pisane w paskudnych językach?
 
> Np. bezpieczniejszy od C/C++ fortran często lepiej się optymalizuje, bo on
> może zagwarantować np. takei rzeczy że nie ma aliasingu.

No i? Mój braciszek jakieś pół roku temu przepisywał kod fortrana na C, bo
już nie miał kto tego (fortrana) pilnować -- jemu przyszła brudna robota,
aby nowe nie fortranowe pokolenie cos kapowało. Zresztą, jak przepisał to
na C, to kompania, za wrapowała kod w C# i teraz mają dwa poziomy "of
understanding" -- 1. Ci co kojarzą C i C# i ci co tylko *jarzą* C#.
 
> Znam dużo popularnego softu nie w C++. Działa. Dobrze działa. I nie umiera
> od czasu do czasu z informacją że jakiś generał Protection się pomylił
> (soft pisany przez wojsko ;) ?). Np. taki Jedit, czy Eclipse, czy parę
> dobrych webserwerów.

O tak. Nawet w KDE klikam na ikonę KDevelop i program się otwiera. Klikam na
Eclipse i czekam i czekam ... idę po napój ... wracam jest. Z Netbeansami
jest jeszcze gorzej. A ram? Mam 1.5GB i o jak strasznie mało dla tego
Eclipse/Netbeans. Muszę kupić sobie więcej. W ogóle mam kiepskie komputery,
musze kupić lepsze. 

Szkoda tylko, że kiedy napiszę ten sam program obliczeniowy w C/C++ w stylu
dla "Unixa" i to samo w J. to wersja paskudniaczkowa zjada mniej ramu i
jest szybsza. 

Albo co jest często lepsze. Mogę połknąć tyle samo ramu, ale mam w pamięci
więcej danych, co np w dataminingu jest korzystniejsze. Zatem wolę
mieć "Unix" + C/C++ niż J.

Oczywiście piszę o swoim stanowisku, bo algorytmy jako takie nie mają
ŻADNEGO wsparcia w językach, więc gadanie, że w J ma to czy tamto w klasach
wbudowanych jest dla mnie o picowaniem. Mam worek danych ma algorytm i
mielę i wypluwam wyniki. Albo wersja RT, mielę i wypluwam wyniki on-line, a
jakiś zewnętrzny obserwator pobiera jest sobie przez ustalony interfejs
komunikacyjny.

A co do webserwerów w J -- nic mi o nich nie mów. Już pisałem że np. EJB
przy Plone to jak asembler przy C++.

>>>A może to to że gawiedź pisząca PHP to właśnie, w znacznej większości,
>>>gawiedź a nie specjaliści.
>> 
>> Ale wśród języków bezpiecznych takiej gawiedzi jest masa, bo oni czują
>> się tam bezpiecznie.
> 
> Tak samo tego jest pełno w C a nawet assemblerze.

Oczywiście, że tak. W szczególności, co mnie irytuje, C Legacy People (tm), 
którzy twierdzą, że umieją C++.
 
> [... duże ciach gdzie się zgadzam ...]

Cieszę się, że mamy jakieś punkty zgodności :-D.

Pozdrawiam.

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