eGospodarka.pl
eGospodarka.pl poleca

Ilość wypowiedzi w tym wątku: 131

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

strony : 1 ... 10 . [ 11 ] . 12 ... 14


Szukaj w grupach

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: