On Feb 8, 4:05 am, "M.M." <m...@g...com> wrote:
> W dniu czwartek, 7 lutego 2013 23:51:34 UTC+1 użytkownik Andrzej Jarzabek napisał:
>
> > Podobno Ada jest takim językiem.
>
> Kiedyś tak o Perlu słyszałem. Czasami nie wiem czego słuchać :)

Jeśli ktoś ci mówił o Perlu, że jest "ekstremalnie elegancki i
jednocześnie wydajny", to raczej nie powinieneś słuchać tej osoby w
żadnej kwestii.

> > Poza tym "język wydajny" to poewne nieporozumienie - z cech języka mogą
> > wynikać pewne narzuty ograniczające czy zwiększające wydajność, ale
> > rzeczywista praktyczna wydajność zależy od optymalizacji kompilatora, a
> > te z kolei są mocno skorelowane z popularnością.
>
> Chodziło właśnie o te ograniczenia, a właściwie to nie tylko o nie.
> Do niektórych języków napisanie dobrego kompilatora jest możliwe i język
> tego nie ogranicza w żaden sposób, ale zadanie może być znacznie trudniejsze i
> to pod względem implementacyjnym jak i pod względem algorytmicznym, kompilacja
> mogłaby trwać za długo.

W praktyce te teoretyczne kwestie nie mają aż takiego znaczenia. Bez
problemu da się wymyśleć język, który ma wszystkie zalety C++, ale
łatwiej się do niego pisze kompilator czy może się szybcie kompilować.
Co z tego, skoro w momencie wymyślenia nikt tego języka nie używa,
więc zainteresowanie rozwijaniem kompilatora jest znikome. W pięciu i
tak nie napiszecie kompilatora, który optymalizuje lepiej niż gcc czy
icc.

> Ciekawe zagadnienie, ja zawsze myślałem że to właśnie do takiego języka
> jak C++ trudniej napisać dobry kompilator.

Może i trudniej, ale dzięki popularności ludzie robią to i tak - bo
jest powód, bo komuś opłaca się pakować w to dużą kasę.

> > Np. że możesz napisać jeden kod, który obsłuży obydwa przypadki.
>
> Chyba nie zrozumiem tego, w C też pisze się uniwersalne procedury i
> obsługuje wiele przypadków.

Możesz mieć i cały swój program w jednej funkcji i w niej obsługiwać
wszystkie przypadki, nadal każdy przypadek obsługuje inny kawałek
kodu.

Chodzi o to, żeby mieć _jeden kawałek kodu_, który bierze obiekt x i
pobiera jego właściwość o nazwie y, który obsługuje przypadek kiedt x
jest strukturą a y polem struktury i przypadek, kiedy x jest hashmapą
a y kluczem w hashmapie.

> > Nie mam pojęcia do czego ci te Varianty, rozmawialiśmy o tym, że w
> > językach dynamicznych możesz mieć zmienne przyjmujące wartości dowolnego
> > typu lub funkcje zwracające wartości dowolnego typu. Pisałeś, że w C++
> > masz to samo dzięki typowi Variant. No więc nie masz.
>
> Liczymy tak:
> suma od 1 do N ( p_i * (c_i - a_i) )
> N - ilość cech języka
> p_i  - prawdopodobieństwo użyca
> c_i  - korzyści jakie niesie wybrany język w cesze i
> a_i  - korzyści jakie niesie najlepszy niewybrany język w cesze i.
>
> Jeśli do warianta nie mogę wrzucić czegoś, co przydaje się bardzo rzadko,
> to mówię że mogę wrzucić tam wszytko ( p_i jest bliskie zera i nie
> zmienia wartości powyższego wzoru ).

OK, więc jeśli używasz np. jakiejś biblioteki, to twierdzisz, że jest
bezużyteczna, bo ty jej nie używasz i w związku z tym nie potrafisz
sobie wyobrazić, po co by miała być komukolwiek potrzebna?

> > A w językach z dynamicznym systemem typów nie trzeba. I na tym polega
> > różnica - w C++ tego po prostu nie zrobisz i tyle, żaden QVariant czy
> > hashmap ci nie pomoże.
>
> No tak, ale ten fakt musi się jeszcze jakoś przekładać na praktyczne
> korzyści, w przeciwnym razie rozmawiamy o czymś niepotrzebnym.

No to się przekłada, tylko że może dla ludzi, którzy używają innych
rzeczy, niż ty. Zauważ, że jeśli ktoś programuje komputer przez
dziurkowanie kart perforowanych, to mu nawet mnemoniki assemblerowe
niepotrzebne.

> > O makrach i szablonach w C++ można wiele powiedzieć, ale na pewno nie
> > to, że są wygodne i proste w użyciu.
>
> Też nie przepadam, zwłaszcza za makrami. Ale jak w php świeżo dodane
> pola otaczam dolarami i klamrami to też mi się robi niedobrze.

Nie znam PHP, ale oczywistym rozwiązaniem jest nie używanie PHP.
Przecież to, co piszesz to (chyba?) jakas kwestia składniowa, bez
związku z dynamicznym systemem typów. W każdym razie istnieje wiele
języków dynamicznie typowanych, w których nie otacza się żadnych pól
nawiasami i klamrami, a też działają.

> > Wprowadzasz duplikację.
>
> Jaką duplikację?

Napisałeś tę samą funkcję dwa razy - raz dla structa, drugi raz dla
hashmapy.

> > No i pojawiają się dalsze problemy, co na przykład, jeśli chcesz
> > skopiować structa i owej kopii dołożyć kilka nowych pól?
> > Piszesz konwersję kopiującą wszystkie składowe do hashmapy?
>
> Dlaczego tak jest źle?
> new_hashmap = old_hasmap;
> new_hashmap['nowe_pole1'] = wartość1;
> new_hashmap['nowe_pole2'] = wartość2;

Chcesz skopiować _structa_.

Czyli:
Hashmap convert_from(some_struct s)
{
Hashmap result;
hashmap["width"]=s.width;
hashmap["height"]=s.height
[...]
return hashmap;
}

> > I tak dla każdego typu? I nie widzisz w tym nic niewygodnego?
>
> No właśnie nie widzę.

Popatrz na przykład powyżej i powiedz, co się dzieje, jak się zmienia
definicja some_struct.