Użytkownik "M.M." <m...@g...com> napisał:

> Potem Javę reklamowano [...]
> i że jest językiem pozbawionym wad C++.

Bo to szczera prawda :)

> Jeśli chodzi o zalety programowania w C++, to ja zauważyłem
> jedno. Programiści którzy zadali sobie trud nauki programowania
> w C++, potem lepiej i szybciej odnajdowali się w innych
> środowiskach.

Zauwazyles czy "wydumales" ?
Programisci zaczynajacy od C++ sa tak skrzywieni niesionnymi przez lata
krzyzami, ze z najwiekszym trudem odnajduja sie w innych jezykach.
Ciagle kurczowo trzymaja sie rozwiazan/sposobow znanych z C++.

Moze sie pobawimy ? Zadania trywialne (nie trzeba stosowac nic poza samym jezykiem).
Zobaczymy jak sie odnajdziesz w pythonie.

1. Sprawdz w petli w C++ i w Pythonie czy wszystkie elementy kolekcji
sa > 3.4 i <= 56.8.
2. Znajdz w petli w C++ i w Pythonie pierwszy element kolekcji > 3.4 i <= 56.8.
3. Znajdz w petli w C++ i w Pythonie wszystkie element kolekcji > 3.4 i <= 56.8.

(kazde w/w to osobne zadanie).


> Mutacja, czyli modyfikacja istniejącego obiektu.
> Na przykład takie coś, co wyszło w rozmowie z AK, w Pythonie:
>
> a = [1,2,3]
> b = [4,5,6]
> a += b
>
> w trzeciej linijce tablica "a" została zmodyfikowana, czy też
> doszło do "mutacji". faktycznie może "mutacja" nie ma w języku polskim
> najlepszej konotacji, ale często mówi się np. o obiektach albo zmiennych
> niemutowalnych.

A co niby jet zlego w mutacji?
W zyciu nie wystepuje ? Hę ?:)
Ogolniej:
Narzucanie na sile sztucznego, ale "jedynie slusznego" paradygmatu (np funkcyjnego)
prowadzi do wyobcowania jezyka go narzucajacego (tak sie stalo z Lispem czy innymi
funcyjnymi) mimo, ze ten paradygmat moze i jest krancowo elegancki i spojny z
naukowego
punktu widzenia. Bo dzis dobry jezyk programowania to taki, ktory dla przecietnego
czlowieka
(a juz dzis programisci to calkiem przecietni goscie - o wiele bardziej przecietni
niz kiedys:).
Normalka gdy sztuka staje sie zwyklym rzemioslem) nie stwarza ciezkiego do
przyswojenia
poziomu abstrakcji - slowem jest "naturalny" w uzyciu - bliski "normalnemu zyciu".
Dlatego tak sie spopularyzowal wlasnie Python mimo, ze na mnie jako barrardzo jego
nielicznym
wtedy "admiratorze" wieszano ponad 10 lat temu psy i tu i gdzie indziej /wlasciwie
wszedzie/
(i to nawet ze strony naprawde luminarzy nauki i ludzi bardzo IMHO madrych).
Zreszta podobnie bylo np. z raczkujacym wtedy .NET/C# szczegolnie ze strony
Ayatollahow C++ - dalli mi popalic :).
Dlaczego wiec mialem juz wtedy racje ? Bo:
1. trzeba poznac _w praktyce_ min 5 roznych j.prog. (a najlepje >>10) zeby moc zaczac
w ogole
sie wypowiadac.
2. trzeba sie ciagle interesowac nawet nieznanymi i nowymi
3. _nie trzeba samego siebie oklamywac_ -> nie jest oprawda ze to co znam z definicji
jest najlepsze
:)
/czyli trzeba dorosnac:)/)
4. trza miec zwyczajnie nosa (a aby go miec trzeba WSZYSTKIE j.programowania
zwyczajnie lubiec -
i to bardzo:)))

wsio

AK

do góry

W dniu piątek, 25 sierpnia 2017 18:27:06 UTC+2 użytkownik AK napisał:
> Użytkownik "fir" <p...@g...com> napisał:
>
> > robie switcha (drzewko ifow)
>
> .. i tu lezysz wydajnosciowo ze swym assemblerem przed byle kompilatorem C...
>
> AK

nie pisalem tego z mysla o specjalnej wydajnosci (tylko o prostocie i latwosci
pisania) choc mysle ze wydajnosciowo jest ok

sam glowny switch w takim asmie nie jest az tak szeroki - choc strcompare i tak sie
narobi

if( StringCompare(word[0], "mov") )
{
if( StringCompare(word[1], "eax")
{
if( StringCompare(word[2], "ebx")
{
FlushByte(0x89);
FlushByte(0xd8);
continue;
}
if( StringCompare(word[2], "ecx")
{

FlushByte(0x89);
FlushByte(0xc8);

continue;

}


}
if( StringCompare(word[1], "ebx")
{
//...
}

}

if( StringCompare(word[0], "push") )
{
//.....
}

if( StringCompare(word[0], "call") )
{
//....
}

tak to mniej wiecej wyglada, switch jest w kodzie objetosciowo dlugi
ale jest prosty i mz nie jest zbyt obciazaacy

dzieki continue mozna na czczesnie nie pisac elsów

jako ze kilka mnemonikow jest najpopularniejszych mozna je wrzucic na poczatek,
string compare
u mnie zwraca nie tylko czy rowne ale tez czy niejsze czy wieksze wiec tez mozna by
uzyc (ale mi sie nawet nie chce)

wydajnosc moim zdaniem nie jest tu problemem

do góry

On Friday, August 25, 2017 at 10:52:15 PM UTC+2, slawek wrote:

> Innymi słowy: gdyby kurczowo trzymać się prawa Ahmadla to nie
> istniałaby takie firmy jak MS, Intel, Google, Samsung itd. - każda
> zatrudnia olbrzymie ilości ludzi, a przecież z prawa Ahmadla wynika
> że to niepotrzebne.
True.

Gdyby kurczowo trzymać się teorii, to nic by nie osiągnięto.
Przykładowo nigdy by nie napisano dobrego programu do gry w
szachy, nie wspominając o grze GO. Obie gry mają zbyt wiele
stanów do zapamiętania/przeszukania, więc algorytm mini-max,
ani nawet alpha-beta, nie może być zastosowany. Programy
jedynie grałyby w warcaby 32-polowe i to tylko na super-komputerach,
bo tylko tam są wystarczająco duże dyski.

Tak to już jest z teoriami, są zbyt wyidealizowane aby je
dosłownie stosować do rzeczywistości.

Pozdrawiam

do góry

On Saturday, August 26, 2017 at 12:00:17 PM UTC+2, AK wrote:
> Użytkownik "M.M." <m...@g...com> napisał:
>
> > Potem Javę reklamowano [...]
> > i że jest językiem pozbawionym wad C++.
>
> Bo to szczera prawda :)

W C++ też można pisać ładny kod, podobny do Javy. Można do
minimum ograniczyć preprocesor, przeciążanie operatorów, można
używać dużo metod wirtualnych i jakiś tam mądrych wskaźników :)
Problem jest w ludziach. Gdy piszą w C++ to się martwią że
jakiś tam procesor ma jakiś tam rejestr i jak nie zrobią
dziesięciu zagnieżdżonych/zapętlonych #ifdef, to jakaś wersja
kompilatora się nie domyśli sam jak ten rejestr wykorzystać.


> > Jeśli chodzi o zalety programowania w C++, to ja zauważyłem
> > jedno. Programiści którzy zadali sobie trud nauki programowania
> > w C++, potem lepiej i szybciej odnajdowali się w innych
> > środowiskach.
>
> Zauwazyles czy "wydumales" ?
Zauważyłem.


> Programisci zaczynajacy od C++ sa tak skrzywieni niesionnymi przez lata
> krzyzami, ze z najwiekszym trudem odnajduja sie w innych jezykach.
> Ciagle kurczowo trzymaja sie rozwiazan/sposobow znanych z C++.
Ale ja nie mówię o programistach kompulsywnych bez motywacji :)
Mówię o programistach którzy chcą programować w innych językach.
Mogę przyznać jedynie odrobinę racji, że gdy programują w Javie i
coś zamula, to myślą, że w C++ by to zoptymalizowali - a nie po
to biorą Javę.



> Moze sie pobawimy ? Zadania trywialne (nie trzeba stosowac nic poza samym
jezykiem).
> Zobaczymy jak sie odnajdziesz w pythonie.
>
> 1. Sprawdz w petli w C++ i w Pythonie czy wszystkie elementy kolekcji
> sa > 3.4 i <= 56.8.
> 2. Znajdz w petli w C++ i w Pythonie pierwszy element kolekcji > 3.4 i <= 56.8.
> 3. Znajdz w petli w C++ i w Pythonie wszystkie element kolekcji > 3.4 i <= 56.8.
>
> (kazde w/w to osobne zadanie).

Hmmm może moje słowa "lepiej i szybciej odnajdowali się" brzmią trochę
jak "znali składnię innego języka bez nauki", ale na pewno nie to
miałem na myśli. Chodziło o to, że jak ktoś w C++ przebrnął przez
różne dziedziny programowania, a potem uczy się Pythona lub innego
Rubiego, to znacznie łatwiej i szybciej ta nauka postępuje. To trochę
tak jak z grą na skrzypcach, niby zupełnie nie ma nic wspólnego z
naukami ścisłymi. A podobno Einsteinowi dzięki grze na skrzypcach
wyrósł kawałek mózgu, który potem ułatwił lub wręcz umożliwił mu
opracowanie teorii względności.


Pozdrawiam

do góry

Użytkownik "fir" <p...@g...com> napisał:
> Użytkownik "fir" <p...@g...com> napisał:
>
> > robie switcha (drzewko ifow)
>
> .. i tu lezysz wydajnosciowo ze swym assemblerem przed byle kompilatorem C...
>
> AK

> nie pisalem tego z mysla o specjalnej wydajnosci (tylko o prostocie i latwosci
pisania)

ok

> choc mysle ze wydajnosciowo jest ok

Eh.. O hashtable slyszal ?
Dzisiejsze kompilatory potrafia to uskutacznic (ne tylko dla switcha).

AK

do góry

Użytkownik "M.M." <m...@g...com> napisał:

>> > Potem Javę reklamowano [...]
>> > i że jest językiem pozbawionym wad C++.
>>
>> Bo to szczera prawda :)
>
> W C++ też można pisać ładny kod, podobny do Javy. Można do
> minimum ograniczyć preprocesor, przeciążanie operatorów,
> [...]

Alez mozna!, ale da sie tez zle (i to latwo/"normalnie").
W Javie sie tak latwo nie da i to jest ta "drobna" roznica

> Problem jest w ludziach.

Tak. Jak zawsze.
Ludzie ogolnie sie dziela na:
1. ku potomnosci (blizni mi brat)
2. po mnie chocby potop (mam to/innych w d..)
Tak sie sklada ze od poczatku swej drogi zawodowej
wykres czestosci obu postaw wsrod polskich progranistow
przypomina X. Ostatnie lata to nawt wydaje mi sie megalomansko,
ze prawa-dolna noga tego x jest neico krotsza tylko dlatego ze
opiera sie jedynie na mym brzuchu. Gdy jego zabraknie (a to juz niebawem)
to osiagnie wreszcie "upragnione" 0 :)

>> > Jeśli chodzi o zalety programowania w C++, to ja zauważyłem
>> > jedno. Programiści którzy zadali sobie trud nauki programowania
>> > w C++, potem lepiej i szybciej odnajdowali się w innych
>> > środowiskach.
>>
>> Zauwazyles czy "wydumales" ?

> Zauważyłem.

Ok. No to mamy diametralnie inne perspektywy.
Ciekawe ktora prawdziwsza/blizsza rzeczywistosci.

> Ale ja nie mówię o programistach kompulsywnych bez motywacji :)
> Mówię o programistach którzy chcą programować w innych językach.

Ceownik/Krzyzowiec chcacy pisac w innych jezykach ? Raczej zupelny unikat.
O wiele czesciej "muszacy" (vide slawetny Ober-Ayatollah C++ Sektor van Skijlen)

> Mogę przyznać jedynie odrobinę racji, że gdy programują w Javie i
> coś zamula, to myślą, że w C++ by to zoptymalizowali - a nie po
> to biorą Javę.

Mowilem tu lata temu wiec powtorze jakze IMHO ma wciaz prawdziwa maksyme:

"Czym sie rozni programista C++? Tym, ze zanim jeszcze zakoduje, juz optymalizuje!"

>> Moze sie pobawimy ? Zadania trywialne (nie trzeba stosowac nic poza samym
jezykiem).
>> Zobaczymy jak sie odnajdziesz w pythonie.
>>
>> 1. Sprawdz w petli w C++ i w Pythonie czy wszystkie elementy kolekcji
>> sa > 3.4 i <= 56.8.
>> 2. Znajdz w petli w C++ i w Pythonie pierwszy element kolekcji > 3.4 i <= 56.8.
>> 3. Znajdz w petli w C++ i w Pythonie wszystkie element kolekcji > 3.4 i <= 56.8.
>>
>> (kazde w/w to osobne zadanie).
>
> Hmmm może moje słowa "lepiej i szybciej odnajdowali się" brzmią trochę
> jak "znali składnię innego języka bez nauki", ale na pewno nie to
> miałem na myśli.

Ok, ale pobawmy sie.
Napisz prosze w C++ i w Pythonie w/w zadanka.
Napisz je po ptostu "tak z palca", jak umiesz, zeby bylo uczciwie i adekwatnie.
Chce (a i dla Ciebie mysle byloby to cenne) jak/na ile C++ wycisnal na Tobie pietno.

AK

do góry

W dniu sobota, 26 sierpnia 2017 14:43:35 UTC+2 użytkownik AK napisał:
> Użytkownik "fir" <p...@g...com> napisał:
> > Użytkownik "fir" <p...@g...com> napisał:
> >
> > > robie switcha (drzewko ifow)
> >
> > .. i tu lezysz wydajnosciowo ze swym assemblerem przed byle kompilatorem C...
> >
> > AK
>
> > nie pisalem tego z mysla o specjalnej wydajnosci (tylko o prostocie i latwosci
pisania)
>
> ok
>
> > choc mysle ze wydajnosciowo jest ok
>
> Eh.. O hashtable slyszal ?
> Dzisiejsze kompilatory potrafia to uskutacznic (ne tylko dla switcha).
>
od hashtable przypuszczam kod zrobilby sie brzydszy a ten switch moim zdaniem nie
jest wcale za wolny

do góry

Użytkownik "fir" <p...@g...com> napisał:

> Eh.. O hashtable slyszal ?
> Dzisiejsze kompilatory potrafia to uskutacznic (ne tylko dla switcha).
>
> od hashtable przypuszczam kod zrobilby sie brzydszy a ten switch moim
> zdaniem nie jest wcale za wolny

Dla "call" jest teoretycznie ok 6 razy wolniejszy niz hastablowany.

PS: ...o perfect-hash slyszal? Np. kompilatorach powszechnie stosowany do
"lookup-u" slow kluczowych. Jest nawet przeciez dynamic perfect-hash (dla
przypadku gdy zestaw do wyszukania sie zmienia/jest dynamiczny).

AK

do góry

W dniu sobota, 26 sierpnia 2017 15:15:03 UTC+2 użytkownik AK napisał:
> Użytkownik "fir" <p...@g...com> napisał:
>
> > Eh.. O hashtable slyszal ?
> > Dzisiejsze kompilatory potrafia to uskutacznic (ne tylko dla switcha).
> >
> > od hashtable przypuszczam kod zrobilby sie brzydszy a ten switch moim
> > zdaniem nie jest wcale za wolny
>
> Dla "call" jest teoretycznie ok 6 razy wolniejszy niz hastablowany.
>
> PS: ...o perfect-hash slyszal? Np. kompilatorach powszechnie stosowany do
> "lookup-u" slow kluczowych. Jest nawet przeciez dynamic perfect-hash (dla
> przypadku gdy zestaw do wyszukania sie zmienia/jest dynamiczny).
>
pewnie pomysle o optymalizacji jak ktos zacznie z sensem asemblowac tym asemblerem
cos tak duzego (co to by moglo byc?) ze to zacznie trwac dluzej niz sekunde (i nie z
powodu dyskow)- i to wtedy raczej zrobie zwykla optymalizacje switcha -- na razie
jakos tego zapotrzebowania wogole nie widze ;c
(ew jakbym nie mial totalnie nic do roboty ;c )

gorzej ze nie che mi sie wklepywac tych wszystkich menmonikow, glownie chodzi o te
wersje na charow i shortow, AX AH AL BX BL BH etc, zreszta chyba nawet zwykle skoki
albo nawet mov eax maja wersje skrocone (tj takie ktorych operand nie jes 32 bitowy
tylko jakies krotsze wersje 16 bit 8 bit).. troche jest w tym grzebania

do góry

Użytkownik "fir" <p...@g...com> napisał:

> pewnie pomysle o optymalizacji jak ktos zacznie z sensem asemblowac tym asemblerem

Nikt nie zacznie, bo zwykly popularny kompilator C zrobi to o wiele wydajniej niz
twoj assembler.

> na razie jakos tego zapotrzebowania wogole nie widze ;c

.. co mnie w ogole nie dziwi.. czy ty widzisz cokolwiek dalej niz czubek wlasnego
nosa :) ?

> gorzej ze nie che mi sie wklepywac tych wszystkich menmonikow, glownie chodzi o te
wersje
> na charow i shortow, AX AH AL BX BL BH etc,
> zreszta chyba nawet zwykle skoki albo nawet mov eax maja wersje skrocone (tj takie
ktorych
> operand nie jes 32 bitowy tylko jakies krotsze wersje 16 bit 8 bit)..

no to d..pa ! :)

np. ...na stosowaniu tych wersji skrocoonych polegala kiedys optymalizacja kodu
assemblerowego.

np powszechnie stosowalo sie (i kompiltaory C tez to wtedy juz umialy):

push cs
call near ptr addr_fun

zamiast mniej wydajnego ;

call far ptr addr_fun

Takich "sztuczek" bylo wiele.
Ja np. stosowalem dosc czesto:

mov bx, sp

i indeksowalen stos bx-em

zamiast standarowej wtedy "rozbiegowki" funkcji:

push bp
mov bp, sp
...
pop bp

ale nie miejsce i pora. Raczej ciekawostka historyczna. z czasow x86

PS: Dobrym assemblerowcem bedziesz, gdy bedziesz mial w kapuscie
wryte zarowno mnemoniki jak i czasy wykonania rozkazow (no ok, dzis
juz nie tak - cale szczescie - wazne:). Juz nic nie pamietam prawie
ale CF (far ret) i C3 (near ret) wrylo sie w stary leb.
Robilo wrazenie gdy (slawek zapewne pamieta/potwierdzi) pisalo sie
w niejakim programie "debug" programy "z palca" szesnastkowo :)
PS1: Kiedys rozpoznawalo sie prawiczka w ASM86 gdy pisal mov ax, 0
miast xor ax,ax. Dzis (i znow cale szczecie:) przestalo i to miec znaczenie.

AK

do góry