eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingCo jest nie tak z C++ (było: Rust)Re: Co jest nie tak z C++ (było: Rust)
  • X-Received: by 10.31.96.140 with SMTP id u134mr7087vkb.4.1504020721756; Tue, 29 Aug
    2017 08:32:01 -0700 (PDT)
    X-Received: by 10.31.96.140 with SMTP id u134mr7087vkb.4.1504020721756; Tue, 29 Aug
    2017 08:32:01 -0700 (PDT)
    Path: news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!news.cyf-kr.edu.pl!news.nask
    .pl!news.nask.org.pl!news.unit0.net!peer02.am4!peer.am4.highwinds-media.com!pee
    r02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!v29no1076896qtv.0!
    news-out.google.com!j49ni1425qtc.1!nntp.google.com!u11no1074216qtu.1!postnews.g
    oogle.com!glegroupsg2000goo.googlegroups.com!not-for-mail
    Newsgroups: pl.comp.programming
    Date: Tue, 29 Aug 2017 08:32:01 -0700 (PDT)
    In-Reply-To: <b...@g...com>
    Complaints-To: g...@g...com
    Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=159.205.151.11;
    posting-account=xjvq9QoAAAATMPC2X3btlHd_LkaJo_rj
    NNTP-Posting-Host: 159.205.151.11
    References: <f...@g...com>
    <1...@g...com>
    <7...@g...com>
    <b...@g...com>
    <a...@n...v.pl>
    <2...@g...com>
    <a...@n...v.pl>
    <on23a3$85s$1@node1.news.atman.pl>
    <a...@n...v.pl>
    <on75ke$g4u$1@node2.news.atman.pl>
    <5...@g...com>
    <onfotu$lh6$1@node1.news.atman.pl>
    <0...@g...com>
    <3...@g...com>
    <6...@g...com>
    <c...@g...com>
    <d...@g...com>
    <5...@g...com>
    <c...@g...com>
    <3...@g...com>
    <6...@g...com>
    <c...@g...com>
    <6...@g...com>
    <f...@g...com>
    <0...@g...com>
    <f...@g...com>
    <d...@g...com>
    <5...@g...com>
    <a...@g...com>
    <4...@g...com>
    <8...@g...com>
    <f...@g...com>
    <a...@g...com>
    <b...@g...com>
    User-Agent: G2/1.0
    MIME-Version: 1.0
    Message-ID: <0...@g...com>
    Subject: Re: Co jest nie tak z C++ (było: Rust)
    From: "M.M." <m...@g...com>
    Injection-Date: Tue, 29 Aug 2017 15:32:01 +0000
    Content-Type: text/plain; charset="UTF-8"
    Content-Transfer-Encoding: quoted-printable
    X-Received-Body-CRC: 733264553
    X-Received-Bytes: 24950
    Xref: news-archive.icm.edu.pl pl.comp.programming:211385
    [ ukryj nagłówki ]

    On Tuesday, August 29, 2017 at 3:26:48 PM UTC+2, g...@g...com wrote:
    > W dniu poniedziałek, 28 sierpnia 2017 18:39:17 UTC+2 użytkownik M.M. napisał:
    >
    > > > No właśnie, i moim zdaniem to programy komputerowe powinny
    > > > z automatu testować wszystko -- formułować różne "hipotezy"
    > > > i dokonywać pomiarów.
    > >
    > > Czyli programować w języku myślenia oznacza coś w rodzaju, żeby
    > > programować komputery, może z wykształceniem matematycznym, ale na
    > > pewno bez informatycznego. Hmmm idea fajna, a jak z tym jest w
    > > praktyce? Podajesz linki do swoich sukcesów, może w praktyce to
    > > jest bardziej możliwe niż mi się wydaje?
    >
    > Nie wiem, czy to, co zrobiłem, można nazwać "sukcesami".

    Podałeś programy które były zwarte, przejrzyste i umiały
    rozwiązać jakieś problemy. Jest to argument za tym, że
    można w jakimś stopniu osiągnąć, do czego miałem wątpliwości.
    Oczywiście jest to sukces w jakimś stopniu, następnym
    stopniem byłby język jeszcze bardziej wysokopoziomowy.

    > Raczej określiłbym to mianem szkiców, ale owszem takie podejście
    > jest możliwe. Pewnie tak naprawdę największym problemem nie
    > jest nawet brak narzędzi, tylko sztywność ludzkiego myślenia
    > (którą moim zdaniem takie języki jak C++ tylko cementują).
    Próbuję rozluźnić swoje myślenie, ale to chyba nie o to chodzi :)
    Raczej chodzi o odwalenie bardzo ciężkiej roboty. Robota ta
    sprowadzałaby się do zaprojektowania nowego, bardzo wysokopoziomowego
    języka programowania i narzędzi, przynajmniej efektywnego kompilatora.


    > > > Jeżeli idzie o mnie, to kiedy zacząłem się uczyć Scheme'u,
    > > > studiując "Strukturę i Interpretację Programów Komputerowych",
    > > > kilka lat zajęło mi oduczenie się wszystkich nawyków, które
    > > > przyniosłem z C i C++.
    > > Czy możesz powiedzieć uczciwie, co zyskałeś na tym, a co straciłeś?
    >
    > Nie wydaje mi się, żebyśmy -- ucząc się nowych rzeczy -- coś tracili.
    I oczywiście nie pytałem o to co straciłeś przez naukę, chociaż też
    się traci, zawsze jest chociażby koszt alternatywny. Dzięki temu
    że pozbyłeś się nawyków z C++, a nabraleś nowych, możesz zapewne jedne
    zadania rozwiązywać (w jakimś sensie) lepiej, a inne gorzej. Pytałem o
    jakiś przegląd takich zadań.


    > Jeżeli idzie o to, co zyskałem, to przede wszystkim właśnie zdolność
    > do patrzenia na programowanie jako na "esencję myśli", choć
    > pewnie nie brzmi to zbyt zrozumiale w oderwaniu od konkretnych
    > przykładów.
    Już wyjaśniliśmy co to znaczy, chodzi po prostu o opis algorytmów w
    bardziej naturalnym a mniej formalnym języku, chodzi o język
    programowania bardzo wysokiego poziomu.

    > > > Zależy, co rozumiesz przez "sztuczną inteligencję",
    > > > ale historycznie rzecz biorąc jakieś bardziej dojrzałe
    > > > systemy sztucznej inteligencji mamy co najmniej od
    > > > lat 80.
    > > Miałem na myśli system, który z dużym prawdopodobieństwem
    > > odgadnie cel jaki programista chce zrealizować.
    >
    > Ale dlaczego system miałby cokolwiek odgadywać? Dlaczego
    > programista nie miałby wprost wyrażać tego, co chce osiągnąć?

    Nie chodziło mi o takie odgadywanie, jak pokerzysta odgaduje
    karty przeciwnika. Raczej chodziło mi o to co opisałem jak
    rozumiem sztuczną inteligencję na potrzeby naszej rozmowy.
    Chodziło o to, aby kompilator ustalił jaki algorytm realizuje
    wpisany kod przez programistę, następnie aby kompilator odszukał
    zbioru równoważnych algorytmów i zaproponował kilka najlepszych
    algorytmów z tego zbioru. Programista mógłby wprost podawać
    zakresy danych, wartości, rozmiary danych w trakcie profilowania.

    Słowa "odgadywać" użyłem tylko dlatego, że nie znam algorytmu
    który dany kod klasyfikuje do zbioru algorytmów.

    > Tym zresztą wydaje mi się programowanie w swojej istocie:
    > praktyką mającą rozjaśnić zdolność formułowania myśli.
    Dla inżyniera "zaprogramować" znaczy "zrozumieć". Języki
    programowania są bardzo jednoznaczne. Jeśli potrafimy
    napisać program który rozwiązuje jakiś problem, to jednoznacznie
    możemy stwierdzić, że rozumiem ten problem. Więc jest
    dużo prawdy w tym co mówisz, bez względu na użyty
    język programowania.

    Co jednak, gdy do danego problemu używamy sieci neuronowej
    mającej 60mln wag? Tego żaden geniusz nie zrozumie :)



    > > Przy odgadywaniu
    > > jedynie może opierać się na analizie meta-kodu i jakiś dodatkowych
    > > skąpych wskazówek, np. może zadać pytania tylko do sytuacji
    > > dwuznacznych. Następnie wygeneruje sub-optymalny kod w C, z
    > > wariantami dostosowanymi do różnych rozmiarów/rozkładów
    > > danych wejściowych.
    >
    > Ciekawostka -- William Byrd pracuje nad edytorem "Barliman",
    > który jest zdolny do czegoś w tym rodzaju. W zeszłym roku
    > miał na ten temat interesującą prezentację (tyle że pokazywał
    > na raczej prostych przykładach):
    >
    > https://www.youtube.com/watch?v=er_lLvkklsk
    Będę musiał spojrzeć.



    > > > A one miały jakieś tytuły?
    > > Tak, nie wszystkie mam do dziś w biblioteczce, niektóre wydałem,
    > > zgubiłem, miałem pożyczone. Miałem ze 20 sztuk tego, począwszy
    > > od C++ do idiotów, skończywszy na Lippmanie i Stroustrupie.
    > > Dlaczego dopytujesz o konkretne tytuły? Teraz mam, licząc z
    > > daleka i patrząc słabym wzrokiem, 13 tytułów na półce.
    >
    > Pytam z ciekawości. Czasem zdarza mi się oglądać prezentacje
    > Suttera i Meyersa (który -- jak wspominałem -- odwrócił się
    > ostatnio od C++ w stronę D)
    Z ciekawszych to Lippman "model obiektu w C++" i Stroustrap "projektowanie i
    rozwój języka C++". Bieleckiego tytułu nie pamiętam, a już nie mam jej
    na swojej półce.


    > > > Jedyny sposób, żeby się przekonać, to sprawdzić.
    > > Trochę sprawdzałem w Javie.
    >
    > Wydaje mi się, że warto spróbować np. Haskella, bo on jednak
    > produkuje natywny kod, a leniwa ewaluacja potrafi niekiedy
    > drastycznie ograniczyć zużycie ramu (a innym razem wręcz przeciwnie,
    > ale to inna historia)
    Ok.


    > > > Sztucznej inteligencji jest dość sporo. I nie mam na myśli
    > > > jakichś systemów deep-learningowych, które naśladują działanie
    > > > ludzkiego mózgu (i czasem robią naprawdę imponujące rzeczy),
    > > > ale raczej pomysły w rodzaju superkompilatora Valentina Turchina,
    > > > albo systemu Burstalla-Darlingtona do transformacji programów,
    > > > albo systemu Boyera-Moore'a do dowodzenia twierdzeń o własnościach
    > > > programów. To są rzeczy z lat 80. XX wieku.
    > >
    > > Ok, ale jeśli podwaliny teoretyczne są takie dobre to dlaczego
    > > programy napisane w Pythonie działają nadal wolno? Nikomu nie
    > > chce się napisać porządnego kompilatora do Pythona?
    >
    > Nie wiem. Mi się nie chce, na przykład.
    > Swego czasu Peter Norvig zrobił porównanie Pythona do Common Lispa,
    > o tutaj; http://norvig.com/python-lisp.html
    W tej chwili nie załadowała mi się strona.

    >
    > > > Czy są jakieś fundamentalne powody, dla których miałoby nie być
    > > > możliwe?
    > > Nie wiem. To ja pytam. Dlaczego programy napisane w Pythonie są
    > > wolne?
    >
    > Podejrzewam, że to raczej kwestie społeczne, niż technologiczne.
    > Ale nie wiem, bo nie siedziałem w Pythonie na tyle głęboko, żeby
    > sięgać po narzędzia w rodzaju PyPy -- dla moich potrzeb CPython
    > z reguły wystarczył, a większej aplikacji w tym języku raczej
    > nie chciałbym pisać, choćby ze względu na brak statycznej kontroli
    > typów.
    Hmmm czyli jaki język jest najlepszy do pisana dużych aplikacji,
    rzędu 30 koderów (plus reszta zespolu) i dwa lata czasu?


    > > > Nie jestem pewien. Herbert Simon i Allen Newell robili w IPL naprawdę
    > > > imponujące rzeczy, ale raczej nie dałoby się zakochać w tym języku.
    > > > Z Javą mam podobne odczucie -- z niektórych prostych rzeczy czyni
    > > > rzeczy wymagające sporego wysiłku (pewnie sporo zmieniło wprowadzenie
    > > > lambdy w Javie 8 pod tym względem, ale nie powiedziałbym, żeby lambdy
    > > > stanowiły kanoniczną część Javy)
    > > Mogę jakiś minimalny przykład poprosić, co jest w Javie
    > > pracochłonne, a w Scali, Rybym, Pythonie, itd, łatwe?
    >
    > Na przykład chcesz wygenerować listę trójek pitagorejskich o współczynnikach
    mniejszych od 100, i przekazać ją do jakiejś funkcji f.
    > W takim np. Haskellu byś napisał
    >
    > f [(x,y,z) | x <- [1..100], y <- [x..100], z <- [y..100], x^2+y^2==z^2]
    >
    > w Pythonie byłoby podobnie, choć nieco bardziej rozwlekle (i bez kontroli typów)
    >
    > f([(x,y,z) for x in range(1,100) for y in range(x,100) for z in range(y,100)
    > if x**2 + y**2 == z**2])
    >
    > A jak by takie coś wyglądało w Javie albo C++?
    > Ja sobie wyobrażam mniej więcej coś takiego:
    >
    > #include <bardzo dużo nagłówków>
    >
    > List<Tuple<int, int, int> > triples;
    > for(int x = 1; x < 100; ++x)
    > {
    > for(int y = x; y < 100; ++y)
    > {
    > for(int z = y; z < 100; ++z)
    > {
    > if(pow(x, 2) + pow(y, 2) == pow(z, 2))
    > {
    > triples.add(new Tuple<int, int, int>(x, y, z));
    > }
    > }
    > }
    > }
    > f(triples);

    C++ przegrywa na starcie, bo ilość kodu jest większa o konieczność
    zdefiniowania funkcji, zmiennych, nazw typu. Zobacz ten kod:
    gen( max_d , max , prev, depth, vals[], f_mkVector, f_test ) {
    vector v;
    if( depth == max_d ) {
    if( f_test(vals) )
    v = f_mkVector( vals , depth );
    } else for( i=prev ; i<max ; i++ ) {
    vals[depth] = i;
    v += gen( max_d , max , i , depth+1 , vals , f_test );
    }
    return v;
    }

    Ma tylko 6 linijek kodu obliczeniowego, reszta to definicje i
    deklaracje. Jest mocno sparametryzowany. Może pracować na
    dowolnym zakresie zmiennych, na dowolnej głębokości. Można
    podać dowolny uchwyt do funkcji testującej i budującej dane
    wyjściowe. Hmmm w C++ jest dużo kodu pełniącego rolę informacyjną
    dla kompilatora, kodu algorytmicznego nie ma aż tak dużo, a
    parametryzowanie wskaźnikami do funkcji, lub obiektami wirtualnym
    powoduje, że kod jest bardzo uniwersalny.


    Przy tym zadaniu mój "język myślenia" wyglądał tak:
    buduj( max_depth, depth, reszta_parametrów ) {
    if( max_depth == depth ) {
    if( testuj(...) )
    return wynik;
    }
    for( i=0 ; i<max ; i++ )
    wynik += buduj( max_depth, depth+1 , ... );
    return wynik;
    }
    Hmmm podobny do kodu algorytmicznego w C++.



    > Oczywiście, nawiasów klamrowych można by było nie używać,
    > ale wtedy przyszedłby manager i powiedział (słusznie) że takie
    > są standardy kodowania w firmie.
    Można bylo jeszcze posłużyć się rekurencją. Kodu jest więcej
    niż w Pythonie, ale procedura jest uniwersalna, dla różnych
    funkcji testujących i budujących wynik.

    > Co do Javy to nie wiem, bo nie używałem, ale wyobrażam sobie,
    > że podobnie (zresztą to Ty mi powiedz, bo może się mylę)
    Bardzo podobnie bym napisał w Javie.

    Chyba że dopuszczasz poslużenie się bibliotekami, to jest
    http://www.cplusplus.com/reference/algorithm/next_pe
    rmutation/
    Ale to już nie jest porównanie języków, tylko dostępnych bibliotek.




    > > > Jeżeli korzystasz w swoim programie z gotowych kolekcji, które mają
    > > > kompatybilne interfejsy, ale różnią się charakterystyką wydajnościową,
    > > > to użycie algorytmów genetycznych do optymalizacji rodzajów kolekcji,
    > > > z których chcesz korzystać, jest trywialne.
    > > Może się nie zrozumieliśmy dlatego, że ja miałem na myśli skompilowany
    > > program, a Ty myślisz o skompilowaniu przed testowaniem. Tak, na
    > > poziomie kodu źródłowego (koncepcyjnie, niekoniecznie w realizacji)
    > > takie zadanie jest trywialne.
    >
    > No, robienie tego rodzaju rzeczy na skompilowanym kodzie to chyba
    > robienie sobie mocno pod górkę?

    Zależy jak to jest użyte. Sieczkę templatów przeplatanych ifdefami
    można zawsze zrobić ;-)


    > > > Ale nie zgadzamy się w kwestii rozumienia pojęcia "sztuczna inteligencja".
    > > > Pewnie Ty rozumiesz to pojęcie dosłownie, a ja -- historycznie, [...]
    > > Rozumiem dosłownie, ale niekoniecznie w dowolnym obszarze zastosowania.
    > > Chodziło mi o AI zdolne do generowania sub-optymalnego kodu na podstawie
    > > meta-kodu, albo na podstawie języka bardzo wysokiego poziomu.
    >
    > Ale do generowania kodu i do opisywania języków mamy bardzo dobre narzędzia.
    > Wystarczy spojrzeć sobie np. na taki Inform 7.

    Rozmawialiśmy o języku myślenia z kompilatorem generującym
    sub-optymalny kod asemblerowym. Nie znam Informu, dałby radę? Jeśli tak, to
    czemu python nie ma szybkiego kompilatora?



    > > > Pokazywałem ten przykład w swojej magisterce, opisując, w jaki sposób
    > > > można stworzyć system reguł, pozwalający przekształcać mniej więcej
    > > > tak zapisanego quicksorta w implementację porównywalną wydajnościowo
    > > > z C.
    > > Czyli zrobiłeś taki początek sztucznej inteligencji jaką miałem
    > > na myśli. Mi to imponuje, ale mam też pytanie: jak z przekształcaniem
    > > innych algorytmów?
    >
    > Raczej bym powiedział, że udało mi się przerzucić sznurek przez Wielki Kanion
    > (a może nawet przez Nie Taki Wielki Kanion), niż wybudować most.
    > Ale też raczej nie nazywałbym tego "sztuczna inteligencją", tylko próbą
    > wypracowania metodologii tworzenia wydajnych programów które są też
    > łatwe do zrozumienia dla ludzi,

    CHyba wiem dlaczego trudno się nam dogadać. Nie zdefiniowaliśmy, co to
    oznacza łatwe do zrozumienia dla ludzi. Mnie się C++ na początku wyawał
    bardzo robaczywy (czytaj: miał nadmiar operatorów), a potem stał się
    przejrzysty. Pojęcie "trudny" już po krótkim treningu może zmienić się
    na "łatwy".

    Zastanawiam się co się pojawiło w moim umyśle, gdy wymyśliłem nowy
    rodzaj sztucznych sieci neuronowych. Hmmmm to nawet nie był metakod.
    Chyba pojawił się wykres z przebiegiem funkcji i zarys dowodu, że
    to się wyuczy dowolnych danych uczących. A co się pojawialo gdy
    wymyśliłem algorytmy do uczenia tych sieci? Zazwyczaj pojawiała się
    tylko jedna pętla. Dla mnie taki język programowania jest językiem
    myślenia i jest łatwy. Jednak dla innych on będzie nie tylko
    trudny, ale nigdy nie będzie zrozumiał, ponieważ mam za sobą
    setki godzin przemyśleń i ta jedna pętla w trakcie kodowania skojarzy
    mi się z drugą pętlą, a ta druga z setką ifów, o których myślałem
    nawet lata temu. Może nie ma czegoś takiego jak łatwy język
    programowania w języku myślenia, bo język myślenia jest tylko pozornie
    łatwy? W języku myślenia nie musimy ŚWIADOMIE myśleć o każdym
    szczególe, ponieważ te szczegóły podpowie nam podświadomość
    gdy będą potrzebne. A to że nie myślimy o zawiłych szczegółach w
    danej chwili ŚWIADOMIE, nie oznacza że w ogóle nie są one elementem
    języka myślenia.

    Myślę że ulegamy złudzeniu chcąc zrobić język programowania tak
    bardzo przyjazny dla ludzi, aby miał on coś wspólnego z językiem
    myślenia. Ulegamy złudzeniu dlatego, że nie jesteśmy świadomi
    potężnego mechanizmu kojarzenia jaki zachodzi w naszym umyśle.
    Taki język nigdy nie powstanie, chyba że komputer pozna nasze
    myśli i skojarzenia.

    > a jednocześnie skalowalne i przenośne
    > (w przeciwieństwie do C++, który pozwala tworzyć wydajne programy,
    > które są potem trudne do zrozumienia i albo nieskalowalne, albo
    > nieprzenośne)
    Kompilatory C++ są na wiele platform, biblioteki też. A zrównoleglanie w
    ogóle bywa trudne, napisz np. optymalnie zrównoleglany algorytm
    cięć alpha-beta w dowolnym języku. Zrównoleglanie prostych algorytmów to
    jedna linijka dzięki OpenMP. A podobno robią wersję OpenMP na środowisko
    rozproszone... Na starym forku też nie tak ciężko się zrównoleglało.



    > > > W swojej pracy mam:
    > > > - opis składni BNF języka Scheme, składający się z dwóch reguł i kilku
    > > > nieformalnych dopowiedzeń
    > > > - implementację maszyny wirtualnej, modelującej z grubsza działanie
    > > > i zestaw instrukcji typowych procesorów, zaimplementowaną w 200 linijkach
    > > > języka Scheme (śmiem twierdzić, że tak czytelnego, jak tylko się da)
    > > > - asembler przekształcający kod z etykietami do kodu z ustalonymi
    > > > adresami, w 30 linikach
    > > > - interpreter języka Scheme w nim samym, w ok. 60 linijkach
    > > > - kompilator używanego przeze mnie podzbioru Scheme'u do zestawu rozkazów
    > > > powyższej maszyny wirtualnej, zajmujący ok. 300 linijek
    > >
    > > Wszystko bardzo zwięzłe. 30 linijek, 60, nawet 300 to bardzo mało. Może
    > > będę musiał poczytać o Scheme :)
    >
    > Ciekawostka, o której dowiedziałem się niedawno, to że Alexander Stepanov
    > swoją koncepcję iteratorów, przeniesioną potem do STLa, najpierw
    > rozwijał właśnie w Scheme:
    > http://stepanovpapers.com/schemenotes/notes.pdf
    Jestem zaciekawiony tym językiem.


    >
    > > > co do C++ i Javy, to oczywiście mógłym go używać jako metajęzyka do
    > > > opisywania przekształceń, ale nie spodziewałbym się, żebym coś w ten
    > > > sposób zyskał, a poza tym nie mógłbym liczyć na to, że wynik mojej
    > > > pracy mógłby mieć szansę stosować się sam do siebie (pewnie też dużo
    > > > bym stracił na czytelności)
    > > Brzmi to bardzo ciekawie.
    >
    > Jeżeli idzie o "autoaplikatywność", to najciekawszy wynik, jaki znam,
    > nosi nazwę "Projekcji Futamury". Zgrabnie opowiedział o tym Tom Stuart:
    >
    > https://www.youtube.com/watch?v=n_k6O50Nd-4
    Ok, dzięki za linka.


    Pozdrawiam

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: