On 2013-02-07, Roman W <b...@g...pl> wrote:
> On Wed, 6 Feb 2013 15:57:09 +0000 (UTC), "Stachu 'Dozzie' K."
><d...@g...eat.some.screws.spammer.invalid> wrote:
>> Typy prymitywne są wyjątkiem w javowym systemie typów. Niewygodnym
> nie
>> jest niemożliwość dodania im metod, tylko w ogóle konieczność
> dodatkowej
>> obsługi tych wyjątkowych konstrukcji.
>
> No ale bez prymitywnego "double" nie istnialaby numeryka w Javie.

Naprawdę? Przecież dałoby się wskazać klasę (java.lang.Double?), której
metody byłyby wykonywane na rzecz ośmiobajtowej danej, co spokojnie by
zastąpiło wywoływanie metod statycznych. Tłumaczenie wywołania metody
dla typu prymitywnego na kod odpowiadający wywołaniu metody statycznej
spokojnie się może odbywać podczas kompilacji.

Gdzie tu widzisz spadek efektywności przetwarzania uniemożliwiający
istnienei numeryki w Javie?

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2013-02-07, Maciej Sobczak <s...@g...com> wrote:
> W dniu czwartek, 7 lutego 2013 08:53:45 UTC+1 użytkownik AK napisał:
>
>> PS: A tak w ogole to np. taki Python w ogole nie posiada zmiennych.
>
> http://docs.python.org/3/reference/datamodel.html
>
> Słowo "variable" występuje tam tylko 28 razy, więc faktycznie można to określić
jako wypadek przy pisaniu specyfikacji języka.

Jemu chodziło o http://docs.python.org/2/reference/datamodel.html, gdzie
"variable" i "variables" występuje 30 razy.

--
Secunia non olet.
Stanislaw Klekot

do góry

W dniu środa, 6 lutego 2013 23:18:56 UTC+1 użytkownik Andrzej Jarzabek napisał:

> >> Co jednak, jeśli z refleksji wychodzi co innego niż z liczenia
> >> checkboksów?
>
> > Z refleksji wynika lista checkboksów a z tej listy konkretne
> > rozwiązanie problemu.
>
> Więc liczenie wydaje mi się zbędnym etapem, bo jeśli z refleksji i z
> liczenia wynikają sprzeczne wnioski,

Nie zrozumiałeś. Nie mogą wyjść sprzeczne, bo to są różne etapy jednego procesu.
Refleksja prowadzi do określenia wymagań (checkboksów), natomiast ich liczenie odbywa
się później, przy wyborze konkretnego narzędzia. Nie rozumiem, gdzie tu może powstać
sprzeczność.

> > Jeżeli masz ludzi, którzy nie chcą się rozwijać, to nie będą. Pomyśl
> > o tym już w czasie ich zatrudniania.
>
> Ale też rozwijać można się w bardzo różnych kierunkach. Jako javowiec
> możesz spokojnie rozwijać się w kierunkach, w których zalety Scali nigdy
> nie wypłyną: TDD, refaktoryzacja, design patterns, Spring, CI, cotamjeszcze.

Nie! Nie da się. Nie można wprowadzić Springa czycotamjeszcze, bo... <tu wstaw
wszystkie swoje argumenty, które do tej pory napisałeś>.

> Konflikt przejawia się np. tym, że w twojej metodzie checkboksowej
> pracodawca wpisałby checkboska "trudniej będzie wymieniać programistów"
> po stronie wad, natomiast programista mógłby go wpisać po stronie zalet.

Pracodawca musi się zdecydować, jak widzi rolę swojego biznesu na rynku, np. czy chce
być twórcą rozwiązań, czy ich integratorem, liderem, czy w ogonie, czy chce
podejmować ryzyko inwestując i być może tracąc czy też odwrotnie, itp. Z tego wynika
też różne ryzyko podejmowanych działań a w tym są takie rozważania jak to, czy coś
jest trudno wymienić. Podobnie jak z samochodami - w tych lepszych też różne rzeczy
się trudniej wymienia.

> Dyskutujesz z moją dygresją, że może nie należy pozwolić programiście
> wybierać technologii, bo programista może wybrać to, co go osobiście
> interesuje (jest cool, modne), a nie to, co jest dobre dla projektu.

A skąd wiadomo, co jest dobre dla projektu? A może akurat w firmie, która chce być
liderem branży (albo nawet jakiejś niszy) i chce podejmować ryzyko techniczne,
właśnie większy entuzjazm programisty jest dobry? Kto o tym ma decydować? (hint:
znowu checkboksy, choć na innym poziomie)

> Natomiast
> zauważę, że w wielu instytucjach takie decyzje podejmuje się na
> jakichśtam stanowiskach kierowniczych typu "head of development" czy CTO.

I czy to sprawia, że nie mogą być podjęte? Nadal mogą.
W takim np. Google'u jakiś tam head of developmen nie tylko zdecydował, że można coś
wprowadzić, ale nawet że można w ogóle stworzyć coś nowego (np. Go). Czyli masz
przykład na to, że da się taką decyzję podjąć.
Z jakiegoś powodu ze słowem "lider" bardziej kojarzy mi się właśnie firma Google a
nie np. "Systemy Do Liczenia Kaloszy w Magazynach Sp. z o.o.".

> Cały czas jednak problem w konflikcie interesów - po refleksji dla
> pracownika dobre może być co innego niż dla pracodawcy.

Jak już napisałem, określenie docelowego wizerunku firmy i jej roli na rynku (lub w
jakiejś niszy) jest decyzją strategiczną i faktycznie należy do grupy trzymającej
władzę - ale właśnie od tej decyzji zależą losy np. oddolnych inicjatyw
programistycznych typu używać Scalę czy nie używać. Konflikt, o którym piszesz, nie
musi wystąpić a proces rekrutacji jest tym momentem, kiedy można się wzajemnie
rozpoznać - oczywiście w ograniczonym zakresie, ale jednak.
I tak, np. gdybyś chciał mnie zatrudnić, to oprócz pytania co miałbym robić
zapytałbym też o to, jaki miałbym wpływ na kierunek techniczny.

> > Tak. Wtedy będą robić mniej ciekawe rzeczy w mniej wartościowym
> > projekcie. Nie widzę problemu.
>
> Ale rekrutujesz, bo potrzebujesz programistów do tego akurat projektu.

Albo po to, żeby ogólnie rozwijać firmę. Nie muszę mieć na myśli żadnego konkretnego
projektu.

> Nie chodziło o wielkość projektu, tylko o skalę kumatości, której
> wymagasz. To, że lepiej zatrudniać kumatych nie znaczy, że nie możesz
> strzelić sobie w stopę stawiając poprzeczkę zbyt wysoko (bo np. nikogo
> aż tak kumatego nie uda ci się znaleźć).

Bez przesady. Na razie udaje nam się zatrudniać kumatych pracowników.

Ogólnie mam wrażenie, że kręcimy się w kółko w tej dyskusji, niczego nowego już do
niej nie dodając. Chyba mamy różne doświadczenia z projektów o różnych kulturach ich
prowadzenia.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

Roman W wrote:
> No ale bez prymitywnego "double" nie istnialaby numeryka w Javie.

firr kenobi wrote:
> Okupione jest (i to jest przynajmniej dla mnie najwazniejsze ;-)
> znacznie nizszą wydajnoscią - udostępnia z kolei pewną (przynajmniej
> ewentualną) prostotę

Z pewnością tak jest. Nie da sie stworzyć języka, który jest zarówno
ekstremalnie elegancki i jednocześnie wydajny. Przykładem tego jest
właśnie wyjątkowe traktowanie typów prostych w Javie. Ale nie
wolno przesadzać że to jest niewygodne, dopisanie do obiektu
valueOf czy toInt nie jest wielkim utrapieniem.

AK wrote:
> Ufff. Wreszcie ktos poruszyl jedna z waznych praktycznie korzysci "dynamicznego"
> typowania.
Nadal tego nie widzę. Na samym dole przykład dlaczego
HashMapy i funkcje wirtualne są równie dobre do tego
celu.


AK wrote:
> Ale musisz zrobic ten Variant, a variantow tysiace i maja sie do siebie nijak
> (w BCB++/Delphi inny, w MS inny, w COM inny itp itd).
> W przypadku jezykow z "first-class" masz to standardowo
> i w pelnej zgodzie z "klasycznym" definiowaniem typow.
Nic a nic nie tworzyłem, z niczym się nie męczyłem, zadziałało
od pierwszego razu, a robiłem to pierwszy raz w życiu - zero
doświadczenia - wpisałem return i działa:
if( index.column() == COL_OBRAZKI ) {
if( streak.size() > 0 && role == Qt::DecorationRole ) {
QPixmap pix( streak.size() * 22 , 22 );
// rysowanie po pixmapie
return pix;
}
if( role == Qt::SizeHintRole ) {
return QSize( streak.size() * 22 , 22 );
}
return QVariant();
}
if( index.column() == COL_KRAJ ) {
return mod_countries.getName( m.getCountry() ); // QString
}


AK wrote:
> Nie. Nie podobna.
> W Pythonie masz pelnoprawna klase/obiekt ktora zachowuje sie
> _dokladnie_ tak samo jakby byla zadeklarowana/zdefiniowana statycznie.
Wiem, ale nie wiem co z tego :)

> W zabawie z hashmapa masz sytuacje ktora musisz wszedzie specjalnie
> obsluzyc.
Biblioteka obsługuje za mnie, zgadzam się że to krecia robota, ale
taką krecią robotę trzeba zrobić raz, a jeśli bierze się dobrą
bibliotekę to zero razy.

> Poza tym w stosunku do "zwyklej"/statycznej klasy np
> nie zgadza ci sie sizeof,
Bo jest hash_map.size().


> serializacja ci sie idzie pasc, nie zapiszesz toto na dysku jakims fwritem itp :)
http://qt-project.org/doc/qt-4.8/qhash.html#operator
-lt-lt-11
http://qt-project.org/doc/qt-4.8/qdatastream.html


> Troche zartuje, ale jednak ta hasmmapa to zbbedna sztuczka/obejscie.
Może... ale na pewno niewiele. W zamian za nieznacznie bardziej
rozwlekłą składnie w C++ można na stosie położyć wektor o stałym
rozmiarze, indeksowany enumem i mamy wydajność jak w asemblerze.

Jednak często w tracie nadawania wartości, czy to składowym
klasy, czy to polom HashMapy, wykonujemy jakieś asercje. Te
asercje są specyficzne dla danego programu, żaden język, ani żadna
biblioteka tego nie załatwi. Więc relatywny narzut na rozwlekłą
składnie (tak samo jak relatywny narzut na czas wykonania) staje
się pomijalny. Panowie, nie widzę w tym nic szczególnie zbędnego,
ani uciążliwego.


Andrzej Jarzabek wrote:
> A więc nie moższ.
Nie mogę tak jak wielu innych rzeczy. Dlaczego ma mi być
smutno jeśli np. nie mogę utworzyć funkcji w C++ o nazwie
składającej się z 10tys znaków? Cecha musi być potrzebna w
statystycznym projekcie żeby cierpieć z jej braku.

Andrzej Jarzabek wrote:
> Variant policz_cene(Variant transakcja)
> {
> return transakcja.kwota * kurs_walut(transkacja.waluta,
> moja_waluta);
> }
>
> W tym momencie piszę algorytm liczący kwotę, jakimi typami są
> transakcje, kwoty i waluty jeszcze nie zdecydowałem, zresztą mogę to
> wiele razy refaktoryzować. Może transakcja będzie konstruowana z
> elementu XML, który ma podelementy 'kwota' i 'waluta'.
W językach wymagających jawnego podawania typu nie ma na to siły i
trzeba typ podawać. Ułatwiają życie szablony, makra, można
też wspomagać się definicjami nowych typów przy pomocy typedef.
Kiedyś nagminnie używałem właśnie typedef, albo makr, na wypadek
gdy się rozmyślę z jednego typu. Rozmyślenie zdarzało mi się tak
rzadko, że zaniechałem stosowania tej praktykę. W C++ można typ prymitywny
obudować klasą. Dla waluty ja bym obudował klasą typ long long.
Można dać:
typedef long long Tcurrency;
po rozmyśleniu można ten typ przedefiniować na klasę, można
jakoś specyficznie oprogramować zaokrąglenia... Więcej roboty,
ale potem większe możliwości zarówno refaktoryzacji jak i zmiany
kodu. Przykładowo w C++ można operator mnożenia kwot walutowych tak
przedefiniować, że w osobnym polu będzie spamiętywał błędy
zaokrągleń.

Andrzej Jarzabek wrote:
> 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


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;
}

Pozdrawiam

do góry

On 07/02/2013 09:34, Maciej Sobczak wrote:
> W dniu środa, 6 lutego 2013 23:18:56 UTC+1 użytkownik Andrzej
> Jarzabek napisał:
>
>> Więc liczenie wydaje mi się zbędnym etapem, bo jeśli z refleksji i
>> z liczenia wynikają sprzeczne wnioski,
>
> Nie zrozumiałeś. Nie mogą wyjść sprzeczne, bo to są różne etapy
> jednego procesu. Refleksja prowadzi do określenia wymagań
> (checkboksów), natomiast ich liczenie odbywa się później, przy
> wyborze konkretnego narzędzia. Nie rozumiem, gdzie tu może powstać
> sprzeczność.

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.

>> Ale też rozwijać można się w bardzo różnych kierunkach. Jako
>> javowiec możesz spokojnie rozwijać się w kierunkach, w których
>> zalety Scali nigdy nie wypłyną: TDD, refaktoryzacja, design
>> patterns, Spring, CI, cotamjeszcze.
>
> 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.

>> Konflikt przejawia się np. tym, że w twojej metodzie checkboksowej
>> pracodawca wpisałby checkboska "trudniej będzie wymieniać
>> programistów" po stronie wad, natomiast programista mógłby go
>> wpisać po stronie zalet.
>
> Pracodawca musi się zdecydować, jak widzi rolę swojego biznesu na
> rynku, np. czy chce być twórcą rozwiązań, czy ich integratorem,
> liderem, czy w ogonie, czy chce podejmować ryzyko inwestując i być
> może tracąc czy też odwrotnie, itp. Z tego wynika też różne ryzyko
> podejmowanych działań a w tym są takie rozważania jak to, czy coś
> jest trudno wymienić. Podobnie jak z samochodami - w tych lepszych
> też różne rzeczy się trudniej wymienia.

Nawet jeśli jest liderem itd. to konflikt interesu nadal istnieje.

>> Dyskutujesz z moją dygresją, że może nie należy pozwolić
>> programiście wybierać technologii, bo programista może wybrać to,
>> co go osobiście interesuje (jest cool, modne), a nie to, co jest
>> dobre dla projektu.
>
> 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.

> A może akurat w firmie,
> która chce być liderem branży (albo nawet jakiejś niszy) i chce
> podejmować ryzyko techniczne, właśnie większy entuzjazm programisty
> jest dobry?

Zapewne, pytanie jednak na ile korzyści z entuzjazmu przekraczają lub
nie przekraczają strat wygenerowanych owym entuzjazmem.

> Kto o tym ma decydować? (hint: znowu checkboksy, choć na
> innym poziomie)

Nie ma chyba uniwersalnej odpowiedzi na to pytanie, a ja na pewno jej
nie mam. W praktyce napisałem, kto może decydować, i cały czas piszę
dlaczego.

>> Natomiast zauważę, że w wielu instytucjach takie decyzje podejmuje
>> się na jakichśtam stanowiskach kierowniczych typu "head of
>> development" czy CTO.
>
> I czy to sprawia, że nie mogą być podjęte? Nadal mogą.

Oczywiście ale rozmawiamy o krytyce opcji "o wyborze języka decydować
będzie ten, kto będzie go używał".

>> Cały czas jednak problem w konflikcie interesów - po refleksji dla
>> pracownika dobre może być co innego niż dla pracodawcy.
[...]
> Scalę czy nie używać. Konflikt, o którym piszesz, nie musi wystąpić a

Musi. Znaczy niekoniecznie tak jest, że wybór akurat Scali jest dobry
dla pracownika a niedobry dla pracodawcy, ale konflikt jest immanentny w
stosunkach pracownika i pracodawcy.

>> Ale rekrutujesz, bo potrzebujesz programistów do tego akurat
>> projektu.
>
> Albo po to, żeby ogólnie rozwijać firmę. Nie muszę mieć na myśli
> żadnego konkretnego projektu.

Rozmawiamy o ryzyku stuacji, kiedy program dzięki zastosowania nowego
języka pięknie się rozwija, a tu nagle pracownik odchodzi i to, co
zyskałeś na Scali stracisz przez to, że przez długi czas nie możesz
znaleść nikogo nowego na to stanowisko. Zatrudnienie kogoś na innym
stanowisku nie rozwiąże problemu - twój program w Scali nadal radzi
sobie gorzej, niż gdyby pozostał przy Javie.

> Ogólnie mam wrażenie, że kręcimy się w kółko w tej dyskusji, niczego
> nowego już do niej nie dodając. Chyba mamy różne doświadczenia z
> projektów o różnych kulturach ich prowadzenia.

Jeśli jednak mi imputujesz, że twierdzę, że decyzji o adopcji
(metafotycznej) Scali nie da się podjąć, to przynajmniej to mogę sprostować.

do góry

On 07/02/2013 12:24, M.M. wrote:
>
> firr kenobi wrote:
>> Okupione jest (i to jest przynajmniej dla mnie najwazniejsze ;-)
>> znacznie nizszą wydajnoscią - udostępnia z kolei pewną (przynajmniej
>> ewentualną) prostotę
>
> Z pewnością tak jest. Nie da sie stworzyć języka, który jest zarówno
> ekstremalnie elegancki i jednocześnie wydajny. Przykładem tego jest

Podobno Ada jest takim językiem.

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ą. Jest dużo eleganckich
języów, które teoretcznie mogłyby być równie wydajne co C++, ale w
praktyce używa ich 5 osób, więc nie jest taki szybki.

>> W Pythonie masz pelnoprawna klase/obiekt ktora zachowuje sie
>> _dokladnie_ tak samo jakby byla zadeklarowana/zdefiniowana statycznie.
> Wiem, ale nie wiem co z tego :)

Np. że możesz napisać jeden kod, który obsłuży obydwa przypadki.

> Andrzej Jarzabek wrote:
>> A więc nie moższ.
> Nie mogę tak jak wielu innych rzeczy. Dlaczego ma mi być
> smutno jeśli np. nie mogę utworzyć funkcji w C++ o nazwie
> składającej się z 10tys znaków? Cecha musi być potrzebna w
> statystycznym projekcie żeby cierpieć z jej braku.

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. Co do tego, do
czego potrzebne jest przyjmowanie lub zwracanie wartości typu first
class function - nie widzę sensu tłumaczenia. Przeczytaj sobie SICP, to
będziesz wiedział.

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

> Ułatwiają życie szablony, makra,

O makrach i szablonach w C++ można wiele powiedzieć, ale na pewno nie
to, że są wygodne i proste w użyciu.

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

> 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? Piszesz konwersję kopiującą wszystkie składowe do hashmapy?
I tak dla każdego typu? I nie widzisz w tym nic niewygodnego?

do góry

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ć :)


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

> Jest dużo eleganckich
> języów, które teoretcznie mogłyby być równie wydajne co C++, ale w
> praktyce używa ich 5 osób, więc nie jest taki szybki.
Ciekawe zagadnienie, ja zawsze myślałem że to właśnie do takiego języka
jak C++ trudniej napisać dobry kompilator.


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

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


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


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


> Bo zajmuje czas, bo wprowadza szum do kodu, bo utrudnia refaktoryzację.
> Może nie zawsze, ale przynajmniej niekiedy.
Bym musiał zobaczyć przykłady w których widać jak w C++ coś robi się
trudno, a w innych językach łatwo, wygląda na to że nie zrozumiem o
czym mówicie.

> Wprowadzasz duplikację.
Jaką 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?
> 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;


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

Pozdrawiam

do góry

Na poziomie abstrakcyjnym mi program przypomina takie coś

x x x x x x x x x x x x x x

Gdzie x to albo id operacji albo danej, do tego jeszcze separatory, glownie nawiasy i
przecinki

Może jeszcze coś ale niekoniecznie -nie wiem. Typy wydają sie nie całkiem konieczne.
Nie próbowałem na razie dalej opracowywac takiego języka, ale można kiedys
pokombinowac.

do góry

tak wogole w tym typowaniu dynamicznym to zdaje sie ze typowanie nie jest likwidowane
tylko przenoszone (do srodka encji), co warto mz sobie uswiadomic, - jakby typ nie
byl trzymany w srodku to trzebaby go bylo trzymac na zewnatrz, np rzutowac albo
statycznie zarzadzac,
korzysci natomiast z tego wewnetrznego typowania raczej pewnie wystepuja bo to pewnie
pozwala klecic paradygmaty na troche lub zupelnie inne
sposoby - ale nie znam sie na tym za bardzo,
jakby mi sie chcialo to bede to opracowywac w swojej osobistej pracy naukowej :|
ostatnio mi sie troche nie chce

do góry

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! 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?

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

> > A może akurat w firmie,
> > która chce być liderem branży (albo nawet jakiejś niszy) i chce
> > podejmować ryzyko techniczne, właśnie większy entuzjazm programisty
> > jest dobry?
>
> 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.
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.

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

> Rozmawiamy o ryzyku stuacji, kiedy program dzięki zastosowania nowego
> języka pięknie się rozwija, a tu nagle pracownik odchodzi i to, co
> zyskałeś na Scali stracisz przez to, że przez długi czas nie możesz
> znaleść nikogo nowego na to stanowisko.

Znowu: firmy dzielimy na te, które są gotowe do podejmowania ryzyka i na te, które
nie są gotowe. Firmy dzielimy też na te, które zostają liderami swoich nisz i na te,
które nie zostają.

Ryzyko można tu regulować tak samo jak w każdym innym przypadku. Nie wkładać jajek do
jednego koszyka, nie wsadzać wszystkich VIPów do jednego samolotu, nie dawać
krytycznego kawałka jednemu człowiekowi, itd. Nowe rozwiązania wdrażać ostrożnie, a
nie na masę, itd. 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.

> > Ogólnie mam wrażenie, że kręcimy się w kółko w tej dyskusji, niczego
> > nowego już do niej nie dodając. Chyba mamy różne doświadczenia z
> > projektów o różnych kulturach ich prowadzenia.
>
> Jeśli jednak mi imputujesz, że twierdzę, że decyzji o adopcji
> (metafotycznej) Scali nie da się podjąć, to przynajmniej to mogę sprostować.

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.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry