-
101. Data: 2017-08-11 09:58:49
Temat: Re: Rust
Od: Roman Tyczka <n...@b...no>
On Thu, 10 Aug 2017 22:27:23 +0200, slawek wrote:
>> Java i C# to swiat (prawie) wylacznie referencyjny.
>
> Java tak. C# nie. Bo struktury są typami wartościowymi.
>
> Wypadało COŚ WIEDZIEĆ zanim się zacznie pisać.
Słowo "prawie" coś Ci mówi czy dać link do słownika?
--
pozdrawiam
Roman Tyczka
-
102. Data: 2017-08-11 11:34:20
Temat: Re: Rust
Od: Maciej Sobczak <s...@g...com>
> > I wybieram C++ jako główny język gdyż wraz z biblioteką Qt daje przenośność i
możliwości.
>
> Hehe Ale sie usmialem:),
> C++ to najgorszy jezyk jaki poznalem.
Ale przecież nie napisał, że jest najlepszy, tylko że "wraz z biblioteką Qt daje
przenośność i możliwości". I tu ma rację, niezależnie od wad tego języka. Pokrycie
platform (przenośność) i niszy rynkowych (możliwości) w C++ jest znacznie lepsze, niż
w innych językach i dlatego C++ jest dobrą inwestycją zawodową. Od mikrokontrolera po
chmury serwerów, w każdej branży, od safety-critical po rozrywkowe. A to, że jest
brzydki, to pikuś - wydaje mi się nawet, że każdy język, który chce go poprawić
(również Rust) jest jeszcze brzydszy.
> Nie zmienia faktu (ze C++ to syf) moje ponad 30-etnie w nim stricte prtodukcyjne
> doswiadczenie
Jak na ironię, nie miałbyś tego doświadczenia, gdyby język nie miał tych dwóch cech.
Po prostu nie miałbyś potrzeby tego języka tak długo i w tylu różnych projektach
używać. W tym kontekście, C++ mógł być Twoją najlepszą zawodową inwestycją. :-)
--
Maciej Sobczak * http://www.inspirel.com
-
103. Data: 2017-08-11 11:40:09
Temat: Re: Rust
Od: Maciej Sobczak <s...@g...com>
> > Ciekawszym tematem jest napisanie programu, np. w C, do sprawdzania poprawności
innego programu, np. w C.
>
> Dlaczego? Na MT też można napisać program w C, jakie różnice masz
> na myśli?
Różnice są takie, jak pomiędzy Computer Science a Software Engineering.
Computer Science mówi, że czegoś tam się w ogólności nie da zrobić na maszynie
Turinga a Software Engineering mówi, że coś szczególnego da się zrobić np. w C.
I to jest różnica pomiędzy teorią a praktyką (w temacie sprawdzania poprawności).
--
Maciej Sobczak * http://www.inspirel.com
-
104. Data: 2017-08-11 14:03:12
Temat: Re: Rust
Od: slawek <f...@f...com>
On Fri, 11 Aug 2017 02:34:20 -0700 (PDT), Maciej Sobczak
<s...@g...com> wrote:
> wraz z biblioteką Qt daje przenośność i możliwo?=
> ?ci". I tu ma rację, niezależnie od wad tego języka. Pokry=
> cie platform (przenośność) i niszy rynkowych (możliwo=
> ści) w C++ jest znacznie lepsze, niż w innych językach i dla=
Narzędzia dla C i C++ są powszechnie dostępne, ale programy w nich
napisane nie są w 100% przenośne.
Między innymi nie jest ustalone czym jest int.
W dodatku Komitern ustala kolejne wersje, które są implementowane jak
komu się chce. Na przykład w C powinien być typ bool, a bywa że go
nie ma.
Pod tym względem Java jest nieco lepsza.
-
105. Data: 2017-08-11 14:34:22
Temat: Re: Rust
Od: Maciej Sobczak <s...@g...com>
> Narzędzia dla C i C++ są powszechnie dostępne, ale programy w nich
> napisane nie są w 100% przenośne.
Na tej zasadzie większość programów w Javie też nie jest przenośna. Np. system
korzystający z bazy danych Oracle (a jakże) nie zadziała na innym serwerze, gdzie
takiej bazy nie ma. Podobnie, apka napisana w Javie na telefon też nie zadziała na
czymś innym, niż telefon (nawet na telefonie z innym systemem nie zadziała). Itd. Ta
przenośność to fikcja.
> Między innymi nie jest ustalone czym jest int.
Jest ustalone. Jest to znacznie lepiej ustalone, niż np. pojemność dysku albo system
plików dla funkcji w Javie obsługujących pliki. I jakoś nikt nie marudzi, że w Javie
nie jest ustalone, czym jest plik. A przynajmniej nikomu ten brak ustaleń nie
przeszkadza a korzystaniu z plików.
> W dodatku Komitern ustala kolejne wersje,
Po to jest.
> które są implementowane jak
> komu się chce.
Komitet nie ma władzy nad programistami, którzy usilnie implementują coś niezgodnie
ze standardem. Ale to chyba nie jest wina komitetu? Albo języka?
> Na przykład w C powinien być typ bool, a bywa że go
> nie ma.
W C jest. Natomiast w jakimś programie udającym kompilator C, może nie być.
> Pod tym względem Java jest nieco lepsza.
W Javie jest "community", któro sądzi, że ustala "kolejną wersję" a korporacje i tak
implementują jak zechcą i jeszcze destabilizują społeczność sprawami w sądzie o te
implementacje. W czym ta sytuacja jest lepsza?
Bo nie zrozumiałem.
--
Maciej Sobczak * http://www.inspirel.com
-
106. Data: 2017-08-11 14:43:04
Temat: Re: Rust
Od: slawek <f...@f...com>
On Fri, 11 Aug 2017 05:34:22 -0700 (PDT), Maciej Sobczak
<s...@g...com> wrote:
> Na tej zasadzie większość programów
> w Javie też nie jest przenośna.
Program w Javie jest uruchamiany przez JVM, czyli zawsze widzi "taki
sam komputer". Nie ważne czy IBM PC, czy Apple, czy Linux czy
Android. Ups... z Androidem byłyby małe problemy. Ale to zupełnie
inna historia.
-
107. Data: 2017-08-11 14:53:34
Temat: Re: Rust
Od: "M.M." <m...@g...com>
On Friday, August 11, 2017 at 2:03:15 PM UTC+2, slawek wrote:
> On Fri, 11 Aug 2017 02:34:20 -0700 (PDT), Maciej Sobczak
> <s...@g...com> wrote:
> > wraz z biblioteką Qt daje przenośność i możliwo?=
> > ?ci". I tu ma rację, niezależnie od wad tego języka. Pokry=
> > cie platform (przenośność) i niszy rynkowych (możliwo=
> > ści) w C++ jest znacznie lepsze, niż w innych językach i dla=
>
> Narzędzia dla C i C++ są powszechnie dostępne, ale programy w nich
> napisane nie są w 100% przenośne.
>
> Między innymi nie jest ustalone czym jest int.
>
> W dodatku Komitern ustala kolejne wersje, które są implementowane jak
> komu się chce. Na przykład w C powinien być typ bool, a bywa że go
> nie ma.
>
> Pod tym względem Java jest nieco lepsza.
Pod względem przenośności i w ogóle pod względem wygody programowania?
W moim odczuciu jest o niebo lepsza. Wiadomo, nie chodzi strikte o
język, tylko też o narzędzia. Bo co stoi na przeszkodzie, aby
napisać kompilatory do C++ na różne platformy w których int
ma zawsze 32bity? Chyba poza wydajnością nie ma żadnych przeszkód?
Generalnie to ja bym programował tylko w Javie. Bardzo lubię
Javę, miałem nawet okres w swoim życiu, gdy tylko programowałem w
Javie i w C++ nie chciałem. Potem się zniechęciłem, nie do języka, nie
zmieniło się nic pod tym względem że lubię Javę, nadal jakoś
tak po prostu miło się pisze w Javie, kod jest taki przejrzysty,
bez sieczki spowodowanej nadmierną ilością operatorów lub szablonów,
dużo jest gotowych bibliotek, właśnie jest ta dobra przenośność, itd...
Ale problemy były gdy uruchamiałem programy korzystające intensywnie z
dużej pamięci. Gdy wezmę np. taką Wekę (pakiet do uczenia maszynowego) i
wrzucę plik o rozmiarze rzędu 3MB, to Weka potrafi się wywalić gdy
ma mniej niż 1GB !!! Zazwyczaj ustawiam 1.2GB do takiej zabawy. Gdy
Weka zrobi jedną epokę w uczeniu multi layer perceptron, to moja
implementacja zrobi może z 50, a też często używam wektorów a
nie wskaźników. Wektor czy lista z szablonów C++ potrafi mieć
narzut pamięciowy 2-3 krotny, jednak pomimo tego, napisane w C++ potem]
działa lepiej, szybciej, jest tak jakby bardziej przewidywalne.
Kiedyś kilka gier typu szachy-warcaby w Javie napisałem. Programy
te nie korzystały intensywnie z pamięci, ponieważ większość
pamięci było allokowane raz na starcie programu i potem trzymane w
specjalnych tablicach. Innymi słowy nie robiłem ciągle new. Za to
programy te miałem dużą tablicę hashującą. Okazało się, że w
analogicznych programach w C++ ta duża tablica hashująca mogła
być 2-3 razy większa, ponieważ właśnie w Javie był taki duży
narzut pamięciowy.
W Javie każdy obiekt i każda tablica są dynamiczne, wątpię żeby
optymalizator potrafił tablicę lub obiekt położyć na stosie
procesora. Allokowanie na stercie jest wolne. Dostęp do nowo
zaalokowanej pamięci może jest w miarę szybki, ale w trakcie
allokowania rzadko działa cache, a dostęp do niebuforowanej
pamięci jest wolny.
No i niestety, z wielką przykrością, rzadko sięgam po ten
piękny, przyjemny i przenośny język programowania.
Ktoś czytając to mógłby pomyśleć, że Java ma same wady, ale
tak nie jest. Kompilatory mogą wygenerować z kodu bajtoweg
Javy bardzo efektywny kod maszynowy, i już kiedyś widziałem
jak ten sam algorytm napisany w Javie działa szybciej niż w
C++. Ale po pierwsze w C++ jeszcze można było zoptymalizować,
chociażby poprzez wstawki assemblerowe, a tamten algorytm
nie korzystał intensywnie z dużej pamięci.
Pozdrawiam
-
108. Data: 2017-08-11 14:55:45
Temat: Re: Rust
Od: slawek <f...@f...com>
On Fri, 11 Aug 2017 05:34:22 -0700 (PDT), Maciej Sobczak
<s...@g...com> wrote:
> Podobnie, apka napisana w Javie na telefon też nie zadziała na c=
> zymś innym, niż telefon
Jak nie zadziała jak zadziała?
Odpala się AVD i nie ma problemu.
-
109. Data: 2017-08-11 15:15:41
Temat: Re: Rust
Od: "M.M." <m...@g...com>
On Friday, August 11, 2017 at 2:55:48 PM UTC+2, slawek wrote:
> On Fri, 11 Aug 2017 05:34:22 -0700 (PDT), Maciej Sobczak
> <s...@g...com> wrote:
> > Podobnie, apka napisana w Javie na telefon też nie zadziała na c=
> > zymś innym, niż telefon
>
> Jak nie zadziała jak zadziała?
>
> Odpala się AVD i nie ma problemu.
Moje też działały.
-
110. Data: 2017-08-11 15:17:08
Temat: Re: Rust
Od: slawek <f...@f...com>
On Fri, 11 Aug 2017 05:34:22 -0700 (PDT), Maciej Sobczak
<s...@g...com> wrote:
> > Na przykład w C powinien być typ bool, a bywa że go
> > nie ma.
> W C jest. Natomiast w jakimś programie udającym kompilator C, mo=
> że nie być.
Ciekawe, bo w K&R nic o tym nie ma.
Ok, w MSVC 2015 jest, w MSVC 2010 nie ma.
A jeszcze spróbuj zdefiniować globalną zmienną y0 w C. Albo sprawdź,
do czego rozwija się M_PI.
W C bohatersko i łatwo rozwiązuje się problemy z przenośnością
nieznane w Javie.