W dniu piątek, 8 lutego 2013 11:20:30 UTC+1 użytkownik Maciej Sobczak napisał:

> Ale przecież ja nigdzie nie napisałem, że wszyscy taką decyzję powinni
> podjąć. Da się to zrobić i niech każdy oceni, czy powinien. Na tym polega
> różnorodność w biznesie - gdyby wszyscy robili to samo i tak samo, to rynku
> by nie było.
Trochę abstrahując od powyższego akapitu: jaki wybór ma dziś ktoś, kto
szuka języka kompilowanego, wydajnego, z dużą ilością różnych bibliotek i
narzędzi? Czym warto się zainteresować, kolejność ważna:
1) C++
2) C
3) Delphi
Jakie języki następne? Kiedyś mój entuzjazm wzbudzał język D, ponieważ miał być
językiem C++ pozbawionym cech asemblerowych. Zdaje się że umarł?

Pozdrawiam

do góry

On 2013-02-08, M.M. <m...@g...com> wrote:
> Trochę abstrahując od powyższego akapitu: jaki wybór ma dziś ktoś, kto
> szuka języka
[...]
> z dużą ilością różnych bibliotek i
> narzędzi?
[...]
> Jakie języki następne?

Innymi słowy: jakie są inne, nieznane szerzej języki, które są
popularne, mimo że nie są znane?

Czy ty się zastanawiałeś nad tą wypowiedzią?

--
Secunia non olet.
Stanislaw Klekot

do góry

W dniu piątek, 8 lutego 2013 14:12:34 UTC+1 użytkownik Stachu 'Dozzie' K. napisał:

> Innymi słowy: jakie są inne, nieznane szerzej języki, które są
> popularne, mimo że nie są znane?
> Czy ty się zastanawiałeś nad tą wypowiedzią?
A czy Ty zadajesz pytanie tylko wtedy gdy doskonale znasz odpowiedź?

Jakbyś się zastanowił, to byś wiedział, że mogą być takie
języki, a tylko ja ich nie znam - zwykle dlatego się pyta :D

Nie wiem zupełnie co z językiem D, nie wiem czy umarł, czy się
rozwinął...

do góry

W dniu 2013-02-07 23:51, Andrzej Jarzabek pisze:
>
>
>> W językach wymagających jawnego podawania typu nie ma na to siły i
>> trzeba typ podawać.
>
> 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.
>

To że zawsze możesz użyć wszystko ma swoją drugą stronę: niczego nie
możesz zabronić. Przy statycznym typowaniu każda funkcja ma
zdefiniowane dla jakich typów i w jakim kontekście jest poprawna i w
innych jej nie użyjesz. A wraz ze wzrostem programu liczba kontekstów
niepoprawnych rośnie szybciej niż tych poprawnych.

>
>>> Wystarczy, żeby powodować niewygodę. Bo tak czy inaczej musisz w tym
>>> momencie zdefiniować odpowiednie typy.
>> Nie dociera do mnie dlaczego to jest problemem. Albo problem
>> jest nieistotny, albo coś ze mną nie tak :D
>
> Bo zajmuje czas, bo wprowadza szum do kodu, bo utrudnia refaktoryzację.
> Może nie zawsze, ale przynajmniej niekiedy.


Co zajmuje czas: wklepanie kodu? Przecież to jest czas pomijalny.
Refaktoryzacja: kompilator powie Ci gdzie NIE możesz użyć nowej
funkcji/struktury
>
>> Andrzej Jarzabek wrote:
>>> fun foo(p)
>>> {
>>> return (p.pole)/2
>>> }
>>
>> Idealne na hashmapę lub funkcję wirtualną.
>>
>> foo( hash_map ) {
>> return hash_map["pole"] / 2;
>> }
>>
>> foo( *object ) {
>> return object->value() / 2;
>> }
>
> Wprowadzasz duplikację. 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?

Tylko wtedy gdy to ma sens, mogę zawsze przekazywać nie obiekty a pole.
Po drugie to kompilator zabroni mi wywołać
foo(foo(c))

kwestia czy lepiej mieć większe ograniczenia i mniejsze zagrożenie
nieuprawnionego użycia, czy mniej ograniczeń , mniej kodu i większe
zagrożenie nieuprawnionego użycia?

Piszesz konwersję kopiującą wszystkie składowe do hashmapy?
> I tak dla każdego typu? I nie widzisz w tym nic niewygodnego?

W życiu też możesz używać wygodnego samochodu rodzinnego do którego
zapakujesz na dowolnym parkingu kilka osób, psa i śniadanie i dojedziesz
nad (prawie) dowolne jezioro. Z drugiej strony masz tiry, które
zapakujesz wyłącznie na rampie wyłącznie paletami wyłącznie mechanicznie
i można jeździć wyłącznie uprawnionymi drogami. Dlaczego tak skoro tak
niewygodnie i restrykcyjnie?



--
Darek

do góry

On Feb 8, 1:06 pm, "M.M." <m...@g...com> wrote:
>
> Trochę abstrahując od powyższego akapitu: jaki wybór ma dziś ktoś, kto
> szuka języka kompilowanego, wydajnego, z dużą ilością różnych bibliotek i
> narzędzi? Czym warto się zainteresować, kolejność ważna:
> 1) C++
> 2) C
> 3) Delphi
> Jakie języki następne?

Java? C#? Objective-C?

> Kiedyś mój entuzjazm wzbudzał język D, ponieważ miał być
> językiem C++ pozbawionym cech asemblerowych. Zdaje się że umarł?

Nigdy nie był popularny, ale chyba nie jest mniej popularny niż
kiedyś. Jeśli chodzi o twoje kryteria, to mała popularność raczej
niestety przekłada się na brak "dużej ilości bibliotek i narzędzi".

do góry

On Feb 8, 4:45 pm, darekm <d...@e...com> wrote:
> W dniu 2013-02-07 23:51, Andrzej Jarzabek pisze:
>
> > 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.
>
> To że zawsze możesz użyć wszystko ma swoją drugą stronę: niczego nie
> możesz zabronić.  Przy statycznym typowaniu każda funkcja ma
> zdefiniowane dla jakich typów i w jakim kontekście jest poprawna i w
> innych jej nie użyjesz. A wraz ze wzrostem  programu liczba kontekstów
> niepoprawnych rośnie szybciej niż tych poprawnych.

Można ograniczyć ten efekt odpowiednio projektując kod.

> > Bo zajmuje czas, bo wprowadza szum do kodu, bo utrudnia refaktoryzację.
> > Może nie zawsze, ale przynajmniej niekiedy.
>
> Co zajmuje czas: wklepanie kodu? Przecież to jest czas pomijalny.

Wymyślenie zestawu typów i relacji między nimi, odpowiadające
problemowi. Przerabianie tego zestawu w miarę jak problem się zmienia.

> Refaktoryzacja: kompilator powie Ci gdzie NIE możesz użyć nowej
> funkcji/struktury

W pewnych sytuacjach tak, ale czasem ci powie, że błąd, bo typ X nie
istnieje i faktycznie, po refaktoryzacji nie istnieje.

> > Wprowadzasz duplikację. 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?
>
> Tylko wtedy gdy to ma sens, mogę zawsze przekazywać nie obiekty a pole.

Przykład był przecież uproszczony, jeśli funkcja korzysta z siedmiu
pól, to przekażesz jej siedem argumentów?

> Po drugie to kompilator zabroni mi wywołać
>    foo(foo(c))

Nawet jeśli właśnie foo(foo(c)) jest dokładnie tym, co chcesz zrobić.

> > Piszesz konwersję kopiującą wszystkie składowe do hashmapy?
> > I tak dla każdego typu? I nie widzisz w tym nic niewygodnego?
>
> W życiu też możesz używać wygodnego samochodu rodzinnego do którego
> zapakujesz na dowolnym parkingu kilka osób, psa i śniadanie i dojedziesz
> nad (prawie) dowolne jezioro. Z drugiej strony masz tiry, które
> zapakujesz wyłącznie na rampie wyłącznie paletami wyłącznie mechanicznie
> i można jeździć wyłącznie uprawnionymi drogami. Dlaczego tak skoro tak
> niewygodnie i restrykcyjnie?

Nie bardzo rozumiem, jak to się ma do tematu dyskusji. Chcesz
powiedzieć, że samochody rodzinne są niepotrzebne, skoro można rodzinę
zapakować w dwa tiry i wybrac sobie takie jezioro, do którego prawie
dojeżdża uprawniona droga?

do góry

W dniu piątek, 8 lutego 2013 18:14:45 UTC+1 użytkownik Andrzej Jarzabek napisał:

> Wymyślenie zestawu typów i relacji między nimi, odpowiadające
> problemowi. Przerabianie tego zestawu w miarę jak problem się zmienia.
Moim zdaniem jest to kwestia szczęścia. Jeśli nie odgadniemy jak
projekt w przyszłości będzie się rozwijał, to w każdym języku
dogłębna (nie kłóćmy się o zmianę int na double - to niezauważalnie mały
nakład pracy) refaktoryzacja staje się koszmarem.
Przerabianie samochodu albo łodzi na amfibię zawsze jest trudniejszym
zadaniem niż produkcja amfibii od zera.

Znowu muszę zapytać jak zdarta płyta: jaki jest przykład takiej refaktoryzacji
która będzie trudna w C++, a łatwa w Pythonie, Rubym i reszcie. Mnie się
wydaje to bardzo pomocne gdy kompilator C++ krzyczy już w trakcie
kompilacji że się typy nie zgadzają.

Zdrowia!

do góry

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.

do góry

On Feb 8, 10:20 am, Maciej Sobczak <s...@g...com> wrote:
> W dniu czwartek, 7 lutego 2013 23:07:34 UTC+1 użytkownik Andrzej Jarzabek napisał:
>
> > Normalnie, reflektujesz, wypisujesz checkboxy, z refleksji wynika, że
> > biorąc pod uwagę wszystkich checkboxy A jest lepsze od B, ale A ma tylko
> > 5 checkboxów po swojej stronie, a B 15, więc z liczenia wychodzi, że B
> > jest lepsze.
>
> Przepraszam, ale tego kompletnie nie zrozumiałem. Mogę prosić np. o analogię
samochodową?

Nie znam się na samochodach, ale powiedzmy, że porównujesz do floty
Forda Mondeo i Bentleya. Przy Bentleyu jest piętnaście checkboxów, a
przy Fordzie Mondeo tylko jeden "jest tańszy od Bentleya". Liczysz
checkboxy i wychodzi, że powinieneś wybrać Bentleya.

> > > Nie! Nie da się. Nie można wprowadzić Springa czycotamjeszcze, bo...
> > > <tu wstaw wszystkie swoje argumenty, które do tej pory napisałeś>.
> > Jakie argumenty? Przecież ja nie twierdzę, że czegoś nie można czy się
> > nie da.
>
> To o czym tu dyskutujemy?

O tym, kto o tym decyduje i dlaczego nie programista.

> > > A skąd wiadomo, co jest dobre dla projektu?
> > Z doświadczenia, z analizy, z intuicji - nie jest to pewna wiedza, ale
> > jakaśtam jest.
>
> To miałem na myśli piszą o refleksji nad stanem obecnym. Czyli ustaliliśmy,
> że w ten sposób można określić, co jest dobre dla projektu. Tak? Bo nie
> wiem już, co ustaliliśmy.

Powiedzmy, że można. Ale jeśli pozostawiasz tę refleksję, a w
szczególności decyzje wynikające z refleksji osobie, której interes
może być sprzeczny z dobrem projektu, to ryzykujesz, że te decyzje
będą suboptymalne.

> > Zapewne, pytanie jednak na ile korzyści z entuzjazmu przekraczają lub
> > nie przekraczają strat wygenerowanych owym entuzjazmem.
>
> Jest całkiem dobra metoda, żeby to sprawdzić - zrobić to.

Jest to również dobra metoda na sprawdzenie, jak długo można trzymać
penisa we wrzątku.

> Jak już pisałem, są firmy gotowe na ryzyko, oraz niegotowe. Te gotowe
> są w stanie poddjąć decyzje, których te niegotowe nie podejmują, bo są...
niegotowe.

Skoro lubisz metafory samochodowe, to proszę bardzo: są kierowcy,
którzy po kilk głębszych czują się gotowi do jeżdżenia po górskich
serpentynach 180 km/h. Skoro się czują gotowi, to są w stanie podjąć
decyzję, których ci niegotowi nie podejmują.

> > Oczywiście ale rozmawiamy o krytyce opcji "o wyborze języka decydować
> > będzie ten, kto będzie go używał".
>
> Na pewno powinien mieć swoj input w tym procesie.

Z tym przecież nie dyskutuję.

> Skoro gdzieś zidentyfikowano ryzyko, to należy nim zarządzać.
> Niczym się to nie różni od jakiegokolwiek innego ryzyka, któro
> w biznesie jest zjawiskiem normalnym.

No więc otóż normalne zarządzanie ryzykiem w biznesie polega na tym,
że czasem się ryzyka nie podejmuje, a nie działa na zasadzie "jest to
ryzykowne, ale ryzyko zawsze jest w biznesie więc: Urrrrraaa!!!"

do góry

W dniu 2013-02-08 18:14, Andrzej Jarzabek pisze:
> On Feb 8, 4:45 pm, darekm <d...@e...com> wrote:
>> W dniu 2013-02-07 23:51, Andrzej Jarzabek pisze:
>>
>>> 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.
>>
>> To że zawsze możesz użyć wszystko ma swoją drugą stronę: niczego nie
>> możesz zabronić. Przy statycznym typowaniu każda funkcja ma
>> zdefiniowane dla jakich typów i w jakim kontekście jest poprawna i w
>> innych jej nie użyjesz. A wraz ze wzrostem programu liczba kontekstów
>> niepoprawnych rośnie szybciej niż tych poprawnych.
>
> Można ograniczyć ten efekt odpowiednio projektując kod.

Przy wsparciu języka to ograniczenie jest skuteczniejsze.

>
>>> Bo zajmuje czas, bo wprowadza szum do kodu, bo utrudnia refaktoryzację.
>>> Może nie zawsze, ale przynajmniej niekiedy.
>>
>> Co zajmuje czas: wklepanie kodu? Przecież to jest czas pomijalny.
>
> Wymyślenie zestawu typów i relacji między nimi, odpowiadające
> problemowi. Przerabianie tego zestawu w miarę jak problem się zmienia.
>

Co jest prostsze: "odpowiednio" projektować kod, czy tylko wprowadzać
więcej typów wraz z ewentualnie duplikowaniem kodu, szczególnie że to
ostatnie jest w mniejszym lub większym zakresie mechaniczne.
Poza tym struktury danych i relacje między nimi masz dane w
specyfikacji. Typy to mechanizm separacji, aby błędnie nie mieszać
niewłaściwych struktur i narzędzi.


>> Refaktoryzacja: kompilator powie Ci gdzie NIE możesz użyć nowej
>> funkcji/struktury
>
> W pewnych sytuacjach tak, ale czasem ci powie, że błąd, bo typ X nie
> istnieje i faktycznie, po refaktoryzacji nie istnieje.

czyli dobrze, nieprawdaż?

>
>>> Wprowadzasz duplikację. 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?
>>
>> Tylko wtedy gdy to ma sens, mogę zawsze przekazywać nie obiekty a pole.
>
> Przykład był przecież uproszczony, jeśli funkcja korzysta z siedmiu
> pól, to przekażesz jej siedem argumentów?
>

zacytuję:
"Można ograniczyć ten efekt odpowiednio projektując kod."


>> Po drugie to kompilator zabroni mi wywołać
>> foo(foo(c))
>
> Nawet jeśli właśnie foo(foo(c)) jest dokładnie tym, co chcesz zrobić.

Jeśli tak jest to będzie istniała odpowiednia definicja.
Jeśli nic nie zrobię to znaczy że nie chcę takiej konstrukcji.
Mam wybór.

>
>>> Piszesz konwersję kopiującą wszystkie składowe do hashmapy?
>>> I tak dla każdego typu? I nie widzisz w tym nic niewygodnego?
>>
>> W życiu też możesz używać wygodnego samochodu rodzinnego do którego
>> zapakujesz na dowolnym parkingu kilka osób, psa i śniadanie i dojedziesz
>> nad (prawie) dowolne jezioro. Z drugiej strony masz tiry, które
>> zapakujesz wyłącznie na rampie wyłącznie paletami wyłącznie mechanicznie
>> i można jeździć wyłącznie uprawnionymi drogami. Dlaczego tak skoro tak
>> niewygodnie i restrykcyjnie?
>
> Nie bardzo rozumiem, jak to się ma do tematu dyskusji. Chcesz
> powiedzieć, że samochody rodzinne są niepotrzebne, skoro można rodzinę
> zapakować w dwa tiry i wybrac sobie takie jezioro, do którego prawie
> dojeżdża uprawniona droga?

Zupełnie odwrotnie. Pytanie brzmi: dlaczego tiry są takie popularne
skoro mają tyle ograniczeń. W analogii do języków z typowaniem
statycznym, w których tyle się trzeba "napracować" aby cokolwiek działało.




--
Darek

do góry