W dniu 2019-12-14 o 11:16, Piotr Chamera pisze:
> W dniu 2019-12-14 o 09:01, Mateusz Viste pisze:
>> 2019-12-13 o 17:58 -0800, osobliwy nick napisał:
>>> No własnie zniechęciłem się nieco do tego języka, z drugiej jednak
>>> strony tak jak pisał kolega, widzę, że jest on uniwersalny, dużo firm
>>> w tym programuje.
>>
>> C++ to kosmiczna armata do strzelania w orbitalną gwiazdę śmierci.
>> Zainteresuj się "zwykłym" C - wielokrotnie łatwiejszym do ogarnięcia
>> (co nie znaczy że łatwiej w nim pisać bezbłędne programy). A jeśli
>> później poczujesz potrzebę dodania plusów, to się tych plusów douczysz.
>>
>>> Ale już na wstępie pisząc swój pierwszy program w
>>> C++ napotykam schody, bo tak jak pisałem w poprzednim wątku chcę
>>> robić przykładowo obliczenia na liczbach 128-bitowych. I już jest
>>> problem, bo C++ nie obsługuje takich liczb.
>>
>> W gcc i clang można korzystać z liczb 128 bitowych dzięki rozszerzeniu
>> GNU języku - nie ma potrzeby niczego dodawać, typ dostępny jest z
>> marszu. Wystarczy go zadeklarować:
>>
>> __uint128_t mojaliczba;
>>
>> Korzystam z tego na co dzień do obliczeń masek IPv6.
>
> To nie będzie takie proste. W przykładzie podanym przez OP zaczynamy
> od liczby rzędu 2^128, ale w ostatniej iteracji mamy już liczbę rzędu
> 2^148

Przepraszam, odniosłem się do poprzedniego wątku, w tym 128 bitów
powinno wystarczyć.

do góry

> > W sensie - jaka jest wartość dodana tego języka Ć?
>
> Sam chwilę temu pisałeś o problemach z wołaniem Javy z C# albo na odwrót.

Sam chwilę temu pisałem, że moduł napisany w C++ mogę załadować do Javy i .NETa.
Więc jeśli celem jest napisanie takiego modułu, to wiem, jak to zrobić bez
konieczności sięgania po nowe (niedopracowane?) narzędzia.

Więc pytam, jaka jest wartość dodana, skoro bez tego narzedzia nie mam problemu z
osiąganiem swoich celów.

> > To używaj wybranego podzbioru. Wtedy taki (pod)język będzie mniej złożony.
>
> Tylko skąd będę wiedział, który podzbiór jest tym właściwym?

Zapytasz na grupie dyskusyjnej? Podpatrzysz implementację innego produktu z tej samej
lub zbliżonej dziedziny?
A może przy takich poszukiwaniach niechcący nauczysz się całego języka i wtedy sam
będziesz mógł taki podzbiór wybrać?

> Jaki konkretnie sukces osiągnął Python przed zainteresowaniem się nim przez Google?

A co w ogóle jest miarą sukcesu języka programowania? Bo skoro twierdzisz, że Python
osiągnął ten sukces po inwestycji ze strony Googla, to chyba masz jakiś pogląd na to,
czym ten sukces jest?

> Nie. Oznacza instytucje, które dysponują zasobami. Jeżeli pytasz o jakie korporacje
chodzi, to przede wszystkim Microsoft z Visual C++, oraz Intel, któty raz że ma
produkt w postaci ICC, a dwa że kontrybuuje do GCC, bo mu to zwiększa sprzedaż
procesorów.

I to są świetne powody, żeby zainteresować się tym językiem planując własny produkt.

> Sukces C++ wyniknął stąd, że znalazły się podmioty, które zrobiły dla niego dobre
narzędzia.

Super! Dobre narzędzia to kolejny powód, żeby się tym językiem zainteresować.
Po co tracić czas na języki, do których nie ma dobrych narzedzi?

> > Dlatego też zachodzi podejrzenie, że do zadania z tego wątku też będzie to dobry
wybór.
>
> Może będzie. Trzymam kciuki.

Wszyscy trzymamy.

> Sądzę, że raczej bierze się to stąd, że łatwiej znaleźć developerów C++ niż Common
Lispa (w pierwszym przypadku) i łatwiej uzyskać dobrą wydajność w C++ niż w Javie (w
drugim przypadku).

To są same świetne powody, żeby wybrać C++ do kolejnego projektu.

> W każdym razie clou jest takie, że rozwijanie projektu jest czymś innym, niż
utrzymanie produktu.

Nie dostrzegam tego clou. Nie widzę sensu rozwijania produktu w jakimś języku, który
nie będzie się nadawał do dalszego utrzymania tego produktu - chociażby dlatego, że
skazałbym się na koszt przepisywania tego produktu. Praktyka pokazuje, że rozwiązania
tymczasowe mają zdumiewającą zdolność przetrwania, więc najlepiej ich z góry uniknąć
i od razu zrobić dobrze (o ile w ogóle mamy długofalową wizję co to ma oznaczać - ale
jeżeli plan jest komercyjny, to jakaś wizja najwyraźniej jest).

--
Maciej Sobczak * http://www.inspirel.com

do góry

> tak jak pisałem w poprzednim wątku chcę robić przykładowo obliczenia na liczbach
128-bitowych. I już jest problem, bo C++ nie obsługuje takich liczb.

Obsługuje, od paru lat. Co prawda jako "nieoficjalne" rozszerzenie, ale nie widzę
powodu, żeby miało Cię to ograniczyć.
Przykład:

~/temp $ cat test.cpp
#include <iostream>

int main()
{
__int128_t i = 42;
__int128_t j = 7;

__int128_t k = i * j;

for (int bit = 127; bit >=0; --bit)
{
std::cout << ((k & ((__int128_t)1 << bit)) != 0);
}
std::cout << '\n';
}

~/temp $ c++ test.cpp
~/temp $ ./a.out
0000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000
000000000000000100100110
~/temp $

Wynik na ekranie to oczywiście, binarnie, 128-bitowy efekt mnożenia 42*7.
Nie użyłem do tego żadnej biblioteki, kompilator to obsłużył "od ręki". I mam
pewność, że raczej nie da się tego zrobić szybciej (w sensie wydajności kodu).

--
Maciej Sobczak * http://www.inspirel.com

do góry

W dniu sobota, 14 grudnia 2019 20:02:41 UTC+1 użytkownik Maciej Sobczak napisał:
> > > W sensie - jaka jest wartość dodana tego języka Ć?
> >
> > Sam chwilę temu pisałeś o problemach z wołaniem Javy z C# albo na odwrót.
>
> Sam chwilę temu pisałem, że moduł napisany w C++ mogę załadować do Javy i .NETa.
> Więc jeśli celem jest napisanie takiego modułu, to wiem, jak to zrobić bez
konieczności sięgania po nowe (niedopracowane?) narzędzia.
> Więc pytam, jaka jest wartość dodana, skoro bez tego narzedzia nie mam problemu z
osiąganiem swoich celów.

Jeżeli idzie o Javę, to obawiam się, że korzystając z Twojej metody będziesz się
musiał sam martwić o to, żeby przeportować i utrzymywać swój moduł na każdą
interesującą Cię platformę. Czyli najważniejszą cechę Javy - przenośność pomiędzy
platformami - wyrzucasz do kosza.
Dodatkowo wołanie kodu natywnego jest na JVM kosztowne, i stosując je, tracisz JVMowe
optymalizacje.
Więc chociażby taka.

> > > To używaj wybranego podzbioru. Wtedy taki (pod)język będzie mniej złożony.
> >
> > Tylko skąd będę wiedział, który podzbiór jest tym właściwym?
>
> Zapytasz na grupie dyskusyjnej? Podpatrzysz implementację innego produktu z tej
samej lub zbliżonej dziedziny?
> A może przy takich poszukiwaniach niechcący nauczysz się całego języka i wtedy sam
będziesz mógł taki podzbiór wybrać?

Się uśmiałem.
C++ jest językiem, którego nie ogarniają sami jego twórcy, więc nie sądzę, żeby
osobie łażącej po grupach dyskusyjnych było dane nauczyć się "całego" języka.

> > Jaki konkretnie sukces osiągnął Python przed zainteresowaniem się nim przez
Google?
>
> A co w ogóle jest miarą sukcesu języka programowania? Bo skoro twierdzisz, że
Python osiągnął ten sukces po inwestycji ze strony Googla, to chyba masz jakiś pogląd
na to, czym ten sukces jest?

Tak. W przypadku języków programowania sukcesem jest popularność.
I jeżeli spojrzysz na rankingi popularności, to z łatwością dostrzeżesz, że Python
zaczął się na nim pojawiać w okolicach 2000-2001 roku.
Czyli mniej więcej w czasie kiedy kierownik działu badań w Googlu napisał ten tekst:
https://norvig.com/python-lisp.html

> > Sukces C++ wyniknął stąd, że znalazły się podmioty, które zrobiły dla niego dobre
narzędzia.
>
> Super! Dobre narzędzia to kolejny powód, żeby się tym językiem zainteresować.
> Po co tracić czas na języki, do których nie ma dobrych narzedzi?

Zdecydowanie nie warto.
Ale C++ nie jest jedynym językiem, dla którego istnieją dobre narzędzia.

> > W każdym razie clou jest takie, że rozwijanie projektu jest czymś innym, niż
utrzymanie produktu.
>
> Nie dostrzegam tego clou. Nie widzę sensu rozwijania produktu w jakimś języku,
który nie będzie się nadawał do dalszego utrzymania tego produktu - chociażby
dlatego, że skazałbym się na koszt przepisywania tego produktu.

Paul Graham swego czasu pisał dużo na temat wyboru Common Lispu do swojego start-upu.
Jego zdaniem to właśnie użycie tego języka dawało im przewagę nad konkurencją, bo
mogli bardzo szybko dodawać do swojego produktu nowe ficzery, tym samym prześcigając
konkurencję. Innymi słowy, zdaniem Grahama, jeśli by wybrali inny język, to produkt
albo nigdy by nie powstał, albo by przegrał.
I podejrzewam, że Graham ma w tym przypadku rację - bo koniec końców to jego produkt.
I nawet jeżeli ocena języka programowania jest subiektywna, to jeżeli ktoś na
przykład czerpie frustrację z używania jakiegoś języka, to raczej trudno się
spodziewać, żeby zaszedł w nim dalej od kogoś, kto używa swojego języka z
przyjemnością. (I z dotychczasowych wypowiedzi wynika, że Osobliwy Nick nie był
szczególnie zadowolony z C++, więc pewnie w jego przypadku warto rozejrzeć się za
jakimiś alternatywami)

Natomiast w tej historii to nie Graham i nie Persson poniósł koszty przepisywania,
tylko - odpowiednio - Yahoo i Microsoft. Z tego co wiem, autorzy kodu byli raczej
zadowoleni z transakcji, a przepisanie go na C++ było czymś, co miało sens z
perspektywy nabywców (a dlaczego tak było? Bo może mieli u siebie zatrudnionych wielu
doświadczonych programistów C++, w związku z czym przepisanie kodu na ten język miało
dla nich sens)

Dlatego jeśli miałbym wybierać pomiędzy tym, czy projekt ma być zrealizowany, a tym,
czy do realizacji projektu mam użyć C++, i nigdy go nie ukończyć, to raczej bym się
nie zastanawiał.

> Praktyka pokazuje, że rozwiązania tymczasowe mają zdumiewającą zdolność
przetrwania, więc najlepiej ich z góry uniknąć i od razu zrobić dobrze (o ile w ogóle
mamy długofalową wizję co to ma oznaczać - ale jeżeli plan jest komercyjny, to jakaś
wizja najwyraźniej jest).

Jasne, że lepiej robić dobrze, niż źle, ale problem jest taki, że o tym, co w danym
przypadku znaczy "dobrze", a co "źle", dowiadujemy się dopiero po fakcie.

do góry

> Jeżeli idzie o Javę, to obawiam się, że korzystając z Twojej metody będziesz się
musiał sam martwić o to, żeby przeportować i utrzymywać swój moduł na każdą
interesującą Cię platformę.

Akurat C++ jest dużo bardziej przenośny, niż Java, więc nie martwi mnie to zbytnio.

> Czyli najważniejszą cechę Javy - przenośność pomiędzy platformami - wyrzucasz do
kosza.

Mój moduł będzie przenośny nawet na te platformy, na których JVM w ogóle nie da się
zrobić. Problem więc jest dokładnie odwrotny - decydując się na pisanie takiego
modułu pod kątem Javy, ograniczyłbym sobie ilość docelowych platform. To brzmi
głupio, ale faktycznie, wielu ludzi właśnie tak się z własnej woli ogranicza.

> Dodatkowo wołanie kodu natywnego jest na JVM kosztowne,
> i stosując je, tracisz JVMowe optymalizacje.

Akurat doświadczenie z wydajnością czegokolwiek podpowiada mi, że mój moduł będzie
wtedy i tak najszybszą częścią takiego składaka. Więc znowu nie martwiłbym się tym
zagadnieniem.

> C++ jest językiem, którego nie ogarniają sami jego twórcy,

Nie szkodzi. Ważne, że ogarnęli go twórcy wszystkich tych projektów, które w C++
odniosłu sukces - a które nawet sam tutaj przytoczyłeś.

> Tak. W przypadku języków programowania sukcesem jest popularność.
> I jeżeli spojrzysz na rankingi popularności, to z łatwością dostrzeżesz, że Python
zaczął się na nim pojawiać w okolicach 2000-2001 roku.
> Czyli mniej więcej w czasie kiedy kierownik działu badań w Googlu napisał ten
tekst: https://norvig.com/python-lisp.html

Nie wiązałbym tej popularności z tym konkretnie artykułem. Przypuszczam nawet, że
jeśli ktoś nie interesował się LISPem, to na ten artykuł w ogóle nie trafił.

Guido został zatrudniony w Google'u w 2005. Python był już wtedy bardzo dobrze
rozpoznawalny, w top 10 (https://www.youtube.com/watch?v=Og847HVwRSI). I raczej nie
był to efekt jakiegoś artykułu napisanego dla fanów LISPa.

> Ale C++ nie jest jedynym językiem, dla którego istnieją dobre narzędzia.

Tak. Ale nie zaproponowałeś żadnego innego, który by ten warunek spełniał.

> Paul Graham swego czasu pisał dużo na temat wyboru Common Lispu do swojego
start-upu. Jego zdaniem to właśnie użycie tego języka dawało im przewagę nad
konkurencją, bo mogli bardzo szybko dodawać do swojego produktu nowe ficzery, tym
samym prześcigając konkurencję.

Dokładnie tak samo tłumaczą swoje wybory wszyscy inni, którzy osiągnęli jakiś sukces.
Co płynnie przenosi nas do wniosku, że wybór języka może być drugorzędny:

> I podejrzewam, że Graham ma w tym przypadku rację - bo koniec końców to jego
produkt. I nawet jeżeli ocena języka programowania jest subiektywna, to jeżeli ktoś
na przykład czerpie frustrację z używania jakiegoś języka, to raczej trudno się
spodziewać, żeby zaszedł w nim dalej od kogoś, kto używa swojego języka z
przyjemnością.

To prawda. Ale ponieważ powstało wiele produktów, które osiągnęły sukces, to może być
też tak, że istotnym składnikiem sukcesu nie jest wybór języka, tylko entuzjazm do
jego używania.

> (I z dotychczasowych wypowiedzi wynika, że Osobliwy Nick nie był szczególnie
zadowolony z C++, więc pewnie w jego przypadku warto rozejrzeć się za jakimiś
alternatywami)

Z dotychczasowych wypowiedzi wynika, że w ogóle nie był zadowolony ze swoich
osiągnięc programistycznych, więc na dzień dzisiejszy chyba każdy język startuje z
równej pozycji. Ale jeżeli składnik subiektywny ma odegrać istotną rolę, to tego
oczywiście nie rozstrzygniemy. Osobliwy sam musi to zrobić.

> Natomiast w tej historii to nie Graham i nie Persson poniósł koszty przepisywania,
tylko - odpowiednio - Yahoo i Microsoft. Z tego co wiem, autorzy kodu byli raczej
zadowoleni z transakcji, a przepisanie go na C++ było czymś, co miało sens z
perspektywy nabywców (a dlaczego tak było? Bo może mieli u siebie zatrudnionych wielu
doświadczonych programistów C++, w związku z czym przepisanie kodu na ten język miało
dla nich sens)

Mogło tak być. Czyli kierował nimi entuzjazm.
Ale skoro ostatecznie osiągnęli sukces, to najwyraźniej nie była to zła decyzja.

> Dlatego jeśli miałbym wybierać pomiędzy tym, czy projekt ma być zrealizowany, a
tym, czy do realizacji projektu mam użyć C++, i nigdy go nie ukończyć, to raczej bym
się nie zastanawiał.

Ale nie ma przesłanek do twierdzenia, że w C++ byś go nie ukończył. To raczej pachnie
uprzedzeniami.

--
Maciej Sobczak * http://www.inspirel.com

do góry

W dniu niedziela, 15 grudnia 2019 23:38:50 UTC+1 użytkownik Maciej Sobczak napisał:
> > Jeżeli idzie o Javę, to obawiam się, że korzystając z Twojej metody będziesz się
musiał sam martwić o to, żeby przeportować i utrzymywać swój moduł na każdą
interesującą Cię platformę.
>
> Akurat C++ jest dużo bardziej przenośny, niż Java, więc nie martwi mnie to zbytnio.

Jeżeli Twoim targetem (np. biznesowym) jest Java, to powinno.
Język Ć jest zaś jeszcze bardziej przenośny, niż C++.

> > Tak. W przypadku języków programowania sukcesem jest popularność.
> > I jeżeli spojrzysz na rankingi popularności, to z łatwością dostrzeżesz, że
Python zaczął się na nim pojawiać w okolicach 2000-2001 roku.
> > Czyli mniej więcej w czasie kiedy kierownik działu badań w Googlu napisał ten
tekst: https://norvig.com/python-lisp.html
>
> Nie wiązałbym tej popularności z tym konkretnie artykułem. Przypuszczam nawet, że
jeśli ktoś nie interesował się LISPem, to na ten artykuł w ogóle nie trafił.

W takim razie z czym byś tę popularność wiązał?

> Guido został zatrudniony w Google'u w 2005. Python był już wtedy bardzo dobrze
rozpoznawalny, w top 10 (https://www.youtube.com/watch?v=Og847HVwRSI). I raczej nie
był to efekt jakiegoś artykułu napisanego dla fanów LISPa.

Sądzę, że wątpię. Python pojawił się na wykresie w roku 2001, tak więc niedługo po
tym, jak Norvig zaczął go promować. I nie chodzi oczywiście o jeden artykuł. Chodzi o
zastąpienie Common Lispa Pythonem w dydaktyce sztucznej inteligencji.

> > Ale C++ nie jest jedynym językiem, dla którego istnieją dobre narzędzia.
>
> Tak. Ale nie zaproponowałeś żadnego innego, który by ten warunek spełniał.

Tak konkretnie to zaproponowałem dwa: Racketa i Haskella.
Racket jest moim faworytem jeżeli idzie o łatwość użycia i przenośność: można go
łatwo zainstalować wraz z prostym w obsłudze IDE na najważniejszych platformach (tj.
Windows, OS X i Linux) albo używać w przeglądarce bez instalacji
(https://www.wescheme.org).

Haskella trudniej zainstalować na Windowsie (choć też bez przesady), i nie ma "w
pudełku" prostych w użyciu narzędzi, ale kompilator GHC zazwyczaj produkuje dobrze
zoptymalizowany kod.

> > I podejrzewam, że Graham ma w tym przypadku rację - bo koniec końców to jego
produkt. I nawet jeżeli ocena języka programowania jest subiektywna, to jeżeli ktoś
na przykład czerpie frustrację z używania jakiegoś języka, to raczej trudno się
spodziewać, żeby zaszedł w nim dalej od kogoś, kto używa swojego języka z
przyjemnością.
>
> To prawda. Ale ponieważ powstało wiele produktów, które osiągnęły sukces, to może
być też tak, że istotnym składnikiem sukcesu nie jest wybór języka, tylko entuzjazm
do jego używania.

Może tak być. Dlatego stoję na stanowisku, że w miarę możliwości warto używać takich
języków, które wzbudzają entuzjazm, a unikać takich, które powodują frustrację. (Co
jest oczywiście cechą indywidualną)

do góry

> > Akurat C++ jest dużo bardziej przenośny, niż Java, więc nie martwi mnie to
zbytnio.
>
> Jeżeli Twoim targetem (np. biznesowym) jest Java, to powinno.

Nie, bo Java będzie tylko podzbiorem targetów mojego modułu.

> Język Ć jest zaś jeszcze bardziej przenośny, niż C++.

Nie. Bo jeżeli zaczynasz traktować język jako źródło do translacji, to C++ też tak
można wykorzystać (nota bene, pierwszy "kompilator" C++ to był translator do innego
języka). Rozsądny podzbiór C++ da się translować na dowolny inny język imperatywny,
zapewne również na język Ć.

Oznacza to, że zarówno C++ jak i Ć można translować na coś innego, ale C++ można
jeszcze kompilować na dowolną platformę bezpośrednio (i można robić to tak dobrze, że
nie ma już motywacji do translowania C++ na inny język). Z tego wynika, że zakres
zastosowań C++ jest większy, niż Ć.

Czyli nie ma takiej rzeczy, którą można zrobić z Ć a której nie można zrobić z C++.
Dlatego pytam o wartość dodaną. Nadal jej nie widzę.

[Python]
> W takim razie z czym byś tę popularność wiązał?

Potrzebny był nowy Perl. Python wypełnił tą niszę proponując świeższą składnię, w
szczególności bardziej atrakcyjną dla początkujących.

> Sądzę, że wątpię. Python pojawił się na wykresie w roku 2001, tak więc niedługo po
tym, jak Norvig zaczął go promować.

Jeżeli objawem tej promocji był wspomniany przez Ciebie artykuł napisany dla
dotychczasowych fanów LISPa, to ta promocja nie miała wpływu dokładnie na nic.

> I nie chodzi oczywiście o jeden artykuł. Chodzi o zastąpienie Common Lispa Pythonem
w dydaktyce sztucznej inteligencji.

O, teraz ciekawiej. Ale sztuczna inteligencja stała się buzzwordem jeszcze później.
Python rozpowszechnił się zupełnie bez wsparcia ze strony AI. Dzisiaj to (wzajemne)
wsparcie jest bardzo widoczne, ale np. ja uczyłem się Pythona zanim ktokolwiek z
mojego otoczenia zaczął w ogóle mówić o AI.

Więc ponownie, nie wiązałbym ze sobą tych nurtów.

Z Quory (bo akurat tam mi wyskoczyło):

https://www.quora.com/Why-is-Python-so-popular-despi
te-being-so-slow

Na tej stronie słowa LISP i AI nie występują ani razu, więc chyba nikt z dyskutantów
nie dostrzega związków Pythona z tymi dwoma.
Jest natomiast wzmianka o zastosowaniach, które wcześniej były domeną właśnie Perla.

[o dostępności dobrych narzędzi]
> Tak konkretnie to zaproponowałem dwa: Racketa i Haskella.

To jaki dobry generator kodu z UMLa polecasz, albo generatory serializatorów dla
różnych standardów komunikacyjnych, albo porządny debugger (również zdalny), albo
chociaż coś do automatycznej generacji dokumentacji z kodu (z diagramami)? Albo
jakieś niezależne analizatory statyczne?

> Racket jest moim faworytem jeżeli idzie o łatwość użycia i przenośność:

Niech zgadnę - przenośność jeszcze mniejsza, niż w Javie?

> można go łatwo zainstalować wraz z prostym w obsłudze IDE na najważniejszych
platformach (tj. Windows, OS X i Linux)

iOS, Android? Jakiś RTOS? Bare-metal?

A jakbym chciał dla odmiany jakieś *trudne* w obsłudze IDE, to da radę?
Bo czasem mogę chcieć.

> albo używać w przeglądarce bez instalacji (https://www.wescheme.org).

Czad. Ale czas, kiedy on-line'owy kompilator (albo interpreter) C++ robił wrażenie,
już dawno minął.

> Haskella trudniej zainstalować na Windowsie

Wiem, próbowałem. Za to C++ mam w tylu różnych stanach skupienia, że sam nie
pamiętam.

[składnik subiektywny]
> Może tak być. Dlatego stoję na stanowisku, że w miarę możliwości warto używać
takich języków, które wzbudzają entuzjazm, a unikać takich, które powodują
frustrację. (Co jest oczywiście cechą indywidualną)

Tak.

--
Maciej Sobczak * http://www.inspirel.com

do góry

W dniu poniedziałek, 16 grudnia 2019 20:02:06 UTC+1 użytkownik Maciej Sobczak
napisał:
> > > Akurat C++ jest dużo bardziej przenośny, niż Java, więc nie martwi mnie to
zbytnio.
> >
> > Jeżeli Twoim targetem (np. biznesowym) jest Java, to powinno.
>
> Nie, bo Java będzie tylko podzbiorem targetów mojego modułu.

O, ciekawe.
Ile razy w życiu napisałeś moduł w C++ który miał być wołany z Javy?

> > Język Ć jest zaś jeszcze bardziej przenośny, niż C++.
>
> Nie. Bo jeżeli zaczynasz traktować język jako źródło do translacji, to C++ też tak
można wykorzystać (nota bene, pierwszy "kompilator" C++ to był translator do innego
języka). Rozsądny podzbiór C++ da się translować na dowolny inny język imperatywny,
zapewne również na język Ć.
>
> Oznacza to, że zarówno C++ jak i Ć można translować na coś innego, ale C++ można
jeszcze kompilować na dowolną platformę bezpośrednio (i można robić to tak dobrze, że
nie ma już motywacji do translowania C++ na inny język). Z tego wynika, że zakres
zastosowań C++ jest większy, niż Ć.

Jakoś nie podążam za argumentem. Ć można użyć wszędzie tam, gdzie można użyć C++, ale
także tam, gdzie nie można, czyli np. na host-agnostic JVM. I z tego wynika, że
zakres zastosowań C++ jest większy, niż Ć?

> [Python]
> > W takim razie z czym byś tę popularność wiązał?
>
> Potrzebny był nowy Perl. Python wypełnił tą niszę proponując świeższą składnię, w
szczególności bardziej atrakcyjną dla początkujących.

Rzeczywiscie, konkret. "Potrzebujemy nowego Perla". "Ale co jest nie tak ze starym
Perlem? Ma przepastne repozytorium modułów CPAN"

> > Sądzę, że wątpię. Python pojawił się na wykresie w roku 2001, tak więc niedługo
po tym, jak Norvig zaczął go promować.
>
> Jeżeli objawem tej promocji był wspomniany przez Ciebie artykuł napisany dla
dotychczasowych fanów LISPa, to ta promocja nie miała wpływu dokładnie na nic.

Skąd wiesz?

> Z Quory (bo akurat tam mi wyskoczyło):
>
> https://www.quora.com/Why-is-Python-so-popular-despi
te-being-so-slow
>
> Na tej stronie słowa LISP i AI nie występują ani razu, więc chyba nikt z
dyskutantów nie dostrzega związków Pythona z tymi dwoma.
> Jest natomiast wzmianka o zastosowaniach, które wcześniej były domeną właśnie
Perla.

Wśród natłoku domorosłych teorii jedna odpowiedź się wydaje dość interesująca:

"I've been using Python since 2000, and my first contact was probably in 1998.

At that time Python was already a popular language in some circles. It was starting
to see serious use as a language for system automation tasks. Some notable
applications written in Python at that time included:
- The original version of the Google crawler. [...]"

> [o dostępności dobrych narzędzi]
> > Tak konkretnie to zaproponowałem dwa: Racketa i Haskella.
>
> To jaki dobry generator kodu z UMLa polecasz, albo generatory serializatorów dla
różnych standardów komunikacyjnych, albo porządny debugger (również zdalny), albo
chociaż coś do automatycznej generacji dokumentacji z kodu (z diagramami)? Albo
jakieś niezależne analizatory statyczne?

Jeżeli idzie o dokumentację kodu, to Racket ma Scribble i całą potężną bibliotekę do
generowania grafiki - wszystko w pakiecie. Z Haskellem jest podobnie - obsługuje
funkcjonalność "literate programming" prosto z pudełka, a do tego można użyć bardzo
eleganckiej biblioteki do tworzenia diagramów o nazwie Diagrams.
Jeżeli idzie o statyczną analizę, to Haskell sam w sobie jest przepotężnym narzędziem
do analizy statycznej, natomiast w Rackecie masz Typed/Racket oraz system kontraktów,
jak również język Redex do tworzenia systemów typów.

Jeżeli idze o generowanie kodu z UMLa, to raczej stronię od UMLa i wydaje mi się to
raczej umierającym wymysłem.

Jeżeli idzie o "generatory serializatorów dla różnych standardów komunikacyjnych", to
nie bardzo wiem, o czym mówisz, ale w jakieś 3 sekundy znalazłem to:
https://docs.racket-lang.org/generator/index.html
i to:
https://hackage.haskell.org/package/protocol-buffers

> > można go łatwo zainstalować wraz z prostym w obsłudze IDE na najważniejszych
platformach (tj. Windows, OS X i Linux)
>
> iOS, Android? Jakiś RTOS? Bare-metal?

Nawet widziałem na Commodore 64

> A jakbym chciał dla odmiany jakieś *trudne* w obsłudze IDE, to da radę?
> Bo czasem mogę chcieć.

Oczywiście, jest wtyczka do Emacsa.

do góry

> > Nie, bo Java będzie tylko podzbiorem targetów mojego modułu.
>
> O, ciekawe.
> Ile razy w życiu napisałeś moduł w C++ który miał być wołany z Javy?

https://en.wikipedia.org/wiki/Java_Native_Access

Również: https://www.teamdev.com/jniwrapper

[Ć]
> Jakoś nie podążam za argumentem. Ć można użyć wszędzie tam, gdzie można użyć C++,
ale także tam, gdzie nie można, czyli np. na host-agnostic JVM.

Host-agnostic JVM? A co to takiego?
Kazdy JVM jaki znam, jest natywnym, nieprzenośnym programem.

> I z tego wynika, że zakres zastosowań C++ jest większy, niż Ć?

Jeżeli można translować w obu kierunkach (a w sensownym podzbiorze można), to już na
tej podstawie można powiedzieć, że zakres jest taki sam. A skoro C++ można
*dodatkowo* kompilować bezpośrednio na docelową platformę (a o kompilatorach Ć nie
słyszałem), to jest to dodatkowa cecha, której Ć nie ma. Więc zakres zastosowań C++
jest większy.

[Python]
> Rzeczywiscie, konkret. "Potrzebujemy nowego Perla". "Ale co jest nie tak ze starym
Perlem? Ma przepastne repozytorium modułów CPAN"

Gdyby ze starym Perlem było wszystko OK, to Python nie miałby przestrzeni do
zagospodarowania. W szczególności największym problemem starego Perla było to, że był
stary. Ta branża tego nie lubi.
A skoro ludzie używają Pythona tam, gdzie wcześniej używaliby Perla, to najwyraźnie
ta zmiana kulturowa była potrzebna (i udana).

> > Jeżeli objawem tej promocji był wspomniany przez Ciebie artykuł napisany dla
dotychczasowych fanów LISPa, to ta promocja nie miała wpływu dokładnie na nic.
>
> Skąd wiesz?

Bo artykuł był skierowany do użytkowników LISPa - i gdyby tak było, to liczba
użytkowników Pythona mogłaby co najwyżej osiągnąć liczbę użytkowników LISPa i to
zakładając, że wszyscy byliby tak zachwyceni, że 100% tej populacji by zmieniło
język.

Mam jednak wrażenie, że w czasie jak ten pan pisał ten artykuł, to Python już był
dalej w wyścigu. I właśnie dlatego w ogóle ten artykuł napisał.

> Wśród natłoku domorosłych teorii jedna odpowiedź się wydaje dość interesująca:
>
> "I've been using Python since 2000, and my first contact was probably in 1998.
>
> At that time Python was already a popular language in some circles. It was starting
to see serious use as a language for system automation tasks. Some notable
applications written in Python at that time included:
> - The original version of the Google crawler. [...]"

Tak. Python był już tak popularny, że został tam użyty. A potem potem porzucony na
rzecz lepszych rozwiązań.
Ale nie nazywałbym tego "inwestowaniem w Pythona", co sugerowałeś. Dla mnie
inwestowanie w Pythona zaczęło się wraz z zatrudnieniem Guido. Czyli właściwie wtedy,
gdy już nie trzeba było w Pythona inwestować. To był (spóźniony) ruch marketingowy i
tyle.

BTW - YouTube to też Python (oczywiście nie liczymy streamingu). Przynajmniej kiedyś
tak było.

> [o dostępności dobrych narzędzi]
[...]

Ładne przykłady, chociaż w kontekście komunikacji bardziej myślałem o standardach
takich jak ASN.1 albo OMG (CORBA, DDS, itd.), natomiast w temacie analizatorów
statycznych zdecydowanie nie miałem na myśli własnego systemu typów, tylko narzędzia
takie jak LDRA, Parasoft, Klocwork, itp.

> Jeżeli idze o generowanie kodu z UMLa, to raczej stronię od UMLa i wydaje mi się to
raczej umierającym wymysłem.

Nic podobnego. W ogóle nie chce umrzeć.

No i dalej nic nie ustaliliśmy.

--
Maciej Sobczak * http://www.inspirel.com

do góry

On Tue, 17 Dec 2019 10:19:51 -0800 (PST), Maciej Sobczak wrote:

>> I z tego wynika, że zakres zastosowań C++ jest większy, niż Ć?
>
> Jeżeli można translować w obu kierunkach (a w sensownym podzbiorze
> można), to już na tej podstawie można powiedzieć, że zakres jest taki
> sam. A skoro C++ można *dodatkowo* kompilować bezpośrednio na docelową
> platformę (a o kompilatorach Ć nie słyszałem), to jest to dodatkowa
> cecha, której Ć nie ma. Więc zakres zastosowań C++ jest większy.

Dziwna ta logika.
W ten sam sposób JS jest wg tej teorii lepszy od TS, a przecież to
nieprawda. TS dodaje statyczne typowanie, interfejsy, OOP i kilka innych
ficzerów. Ale ostatecznie transpiluje się go do JS, więc jest gorszy niż
JS?

--
pozdrawiam
Roman Tyczka

do góry