On 2013-02-06, M.M. <m...@g...com> wrote:
> W dniu środa, 6 lutego 2013 16:57:09 UTC+1 użytkownik Stachu 'Dozzie' K. napisał:
>> WTF is uchwyt otwartego procesu? Czy chodzi może o filehandle?
> Otwieramy dwa procesy do czytania i pisania. Tę samą funkcję
> wywołujemy raz:
> foo( proces_a , proces_b )
> drugi raz
> foo( proces_b , proces_a )

I co to są proces_a i proces_b? Do czego służą? Bo o "uchwycie procesu"
pierwszy raz słyszę w kontekście Perla.

>> Ale zdajesz sobie sprawę z tego, że *własnie na tym* polega nauka? Że
>> się początkowo rozwiązuje wolniej te rzeczy, które innymi narzędziami
>> się robiło szybciej? Bo po nabraniu wprawy może się okazać, że jednak
>> nowe narzędzie jest szybsze w użyciu w pewnych sytuacjach.
> Uznałem, że jeśli powyższego zadania nie mogę opanować w Perlu w
> jedną-dwie godziny, to czas poświęcony na naukę nie zwróci się.

Wiesz, jak się zaczyna od interakcji z systemem operacyjnym zamiast
pracy z podstawowymi typami i konstrukcjami, to nie można się potem
dziwić, że się szuka przez kilka godzin.

>> 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.
> Jakiś przykład tej niewygodny?

Jakiś przykład javowego kontenera (haszmapy, treemapy, arraylisty),
który potrafi trzymać inty?

>> > Przecież mogę sobie zadeklarować
>> > drugą zmienną i mam nawet czytelniej, a jak zmienne tymczasowe się
>> > pałętają to mogę je objąć klamrami albo napisać osobną funkcję...
>>
>> Brzmi trochę jak stanowisko starego Pascalowca, który na oczy nie
>> widział niczego innego: "w Pascalu do wszystkiego są funkcje, a jeśli
>> nie ma, to łatwo można sobie taką napisać". Ale to takie tylko odległe
>> skojarzenie.
> Starzy Pascalowcy używali tego w dowolnie pracochłonnym kontekście: nie
> ma okienkowego GUI - to możesz sobie napisać.

O widzisz, cieszę się, że rozumiesz, co mam na myśli mówiąc "syndrom
sezonowanego Pascalowca". To rozumiesz też, że twoje "można objąć
klamrami albo napisać osobną funkcję" skojarzyło mi się z syndromem
starego Pascalowca (nawet jeśli nie zobaczysz dlaczego akurat mi się tak
skojarzyło).

--
Secunia non olet.
Stanislaw Klekot

do góry

W dniu środa, 6 lutego 2013 18:10:54 UTC+1 użytkownik Stachu 'Dozzie' K. napisał:
> I co to są proces_a i proces_b? Do czego służą? Bo o "uchwycie procesu"
> pierwszy raz słyszę w kontekście Perla.
Tak jak pisałem: "otwieramy proces do czytania i pisania". Uchwyt to
zupełnie cokolwiek i pozyskane jakkolwiek, byleby umożliwiało
identyfikację procesów w powyższym celu.


> Wiesz, jak się zaczyna od interakcji z systemem operacyjnym zamiast
> pracy z podstawowymi typami i konstrukcjami, to nie można się potem
> dziwić, że się szuka przez kilka godzin.
Moim zdaniem to proste zadanie. Gdy czegoś nie wiem o QT to wpisuję
w google i wielokrotnie kopiuję gotowca do swojego programu, nawet
bez przeczytania. Tutaj mi się nie udało.


> Jakiś przykład javowego kontenera (haszmapy, treemapy, arraylisty),
> który potrafi trzymać inty?
Nadal nie kumam, co nie tak z tymi kontenerami? Jaka to cecha
tych kontenerów powoduje, ze w innych językach są lepsze, a w Java i C++
są gorsze?


> O widzisz, cieszę się, że rozumiesz, co mam na myśli mówiąc "syndrom
> sezonowanego Pascalowca". To rozumiesz też, że twoje "można objąć
> klamrami albo napisać osobną funkcję" skojarzyło mi się z syndromem
> starego Pascalowca (nawet jeśli nie zobaczysz dlaczego akurat mi się tak
> skojarzyło).
Porównanie jest na wyrost. Z rozpoznawaniem typu w trakcie wykonania jeszcze
wiąże się narzut. Jeśli uznam w C/C++ że chcę mieć taki mechanizm, to
sobie napiszę. W PHP nie mogę z niego zrezygnować. Naprawdę nie porównywał
bym.

Pozdrawiam

do góry

On 2013-02-06, M.M. <m...@g...com> wrote:
> W dniu środa, 6 lutego 2013 18:10:54 UTC+1 użytkownik Stachu 'Dozzie' K. napisał:
>> I co to są proces_a i proces_b? Do czego służą? Bo o "uchwycie procesu"
>> pierwszy raz słyszę w kontekście Perla.
> Tak jak pisałem: "otwieramy proces do czytania i pisania". Uchwyt to
> zupełnie cokolwiek i pozyskane jakkolwiek, byleby umożliwiało
> identyfikację procesów w powyższym celu.

Ej, nie wprowadzaj pseudoterminów na własną rękę. To powoduje, że twoja
wypowiedź przestaje być zrozumiała, zwłaszcza dla osoby orientującej się
w temacie, o którym ty się dopiero uczysz.

Czyli nie "uchwyt procesu", tylko uchwyt pliku (filehandle), który jest
potokiem albo gniazdem do innego procesu.

Potrzebna ci była referencja do filehandle.

>> Wiesz, jak się zaczyna od interakcji z systemem operacyjnym zamiast
>> pracy z podstawowymi typami i konstrukcjami, to nie można się potem
>> dziwić, że się szuka przez kilka godzin.
> Moim zdaniem to proste zadanie. Gdy czegoś nie wiem o QT to wpisuję
> w google i wielokrotnie kopiuję gotowca do swojego programu, nawet
> bez przeczytania. Tutaj mi się nie udało.

Jak rozumiem, głównie dlatego że nie znalazłeś gotowca. Wniosek moim
zdaniem jest jeden: nie wiedziałeś o co pytać. Przepraszam, ale bez
znajomości podstawowej terminologii raczej ci się nie uda nauczyć
czegokolwiek.

>> Jakiś przykład javowego kontenera (haszmapy, treemapy, arraylisty),
>> który potrafi trzymać inty?
> Nadal nie kumam, co nie tak z tymi kontenerami? Jaka to cecha
> tych kontenerów powoduje, ze w innych językach są lepsze, a w Java i C++
> są gorsze?

Bo nie ma kontenera na zmienne typu int. Trzeba upakowywać te inty
dodatkowo -- specjalnie, inaczej niż dowolne obiekty -- w klasę Integer.

I dlaczego właściwie wrzucasz do jednego wora kontenery javowe, które
w rzeczywistości składują Objecty (generyki to tylko taki cukier
składniowy) z kontenerami biblioteki standardowej C++? Mówiliśmy o tym,
że w Javie typy prymitywne są wyjątkiem w języku, który to wyjątek jest
uciążliwy.

>> O widzisz, cieszę się, że rozumiesz, co mam na myśli mówiąc "syndrom
>> sezonowanego Pascalowca". To rozumiesz też, że twoje "można objąć
>> klamrami albo napisać osobną funkcję" skojarzyło mi się z syndromem
>> starego Pascalowca (nawet jeśli nie zobaczysz dlaczego akurat mi się tak
>> skojarzyło).
> Porównanie jest na wyrost. Z rozpoznawaniem typu w trakcie wykonania jeszcze
> wiąże się narzut. [blah-blah-blah]

A RTTI już absolutnie nie ma nic wspólnego z tym, że skojarzyłeś mi się
ze starym, sezonowanym Pascalowcem. Non sequitur, można by rzec.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 05/02/2013 16:28, Sebastian Kaliszewski wrote:
> On 02/05/2013 12:12 AM, Andrzej Jarzabek wrote:
> [...]
>> * Kandydaci owszem, chętnie się nauczą Scali, ale póki co jej nie
>> znają. Zanim się zapoznają minie ileś tam czasu, w którym to czasie będą
>> mniej produktywni.
>
> Tak czy siak będą mniej produktywni, chyba że firma zajmuje się
> "trzaskaniem stronek w PeHaPe"

A tak to będą jeszcze mniej produktywni przez jeszcze więcej czasu.

[...]
> Tak czy siak jakiś tam procent nie będzie rokował nadziei.

Tak jak z produktywnością, nie jest istotne czy jakiś procent będzie czy
nie będzie (bo zawsze jakiś będzie), tylko czy ten procent będzie
mniejszy czy większy. Adoptując Scalę bierzesz na siebie to, że ludzie,
którzy dobrze by sobie radzili w Javie, nie poradzą sobie w twoim projekcie.

>> Zaostrzając kryteria
>> rekrutacji, nawet nie konkretnie w tę stronę, ale nawet w celu
>> zatrudnienia po prostu najbardziej kumatych, obniżysz ten procent, ale
>> podwyższysz koszty wyjściowe - będziesz musiał dłużej szukać albo
>> zaoferować lepsze wynagrodzenie.
>
> Z tym się nie mogę zgodzić. Przy łagodniejszych kryteriach rekrutacji
> będziesz musiał się przebić przez (a więc ponieść koszty):
> a) większej liczby kandydatów do przesłuchania, sprawdzenia, itd..
> b) więszej liczby ludzi przepuszczanych przez "próbną maszynkę"

Problem polega na tym, że pracownik, którego przyjęcie byłoby dobrym
wyborem gdybyś używał tylko Javy, może być niewystarczająco dobry jeśli
używasz Scali.

> To nie jest za darmo. Oczywiście możesz z 500 nadesłanych ofert wziąć
> pierwsze 50 z brzegu a resztę wyrzucić do kosza stwierdzając "mają
> pecha, a my nie chcemy zatrudniać pechowców"...

Jeśli masz taki problem, to powinieneś raczej pomyśleć gdzie ogłaszać
się ze swoją ofertą pracy.

>> ciebie na rozmowę. Ale to nie znaczy, że twój szef się zgodzi, że warto
>> zapłacić te 30 tysięcy, i nie znaczy, że nie będzie miał w tym racji.
>
> Tylko po co to sprowadzenie do skrajności? Jakość programistów zwykle ma
> znaczny rozrzut. Zwykle wzięcie tych powyżej mediany już sporo daje.

Tylko że mediana to może być za mało.

> No chyba że firma owe przysłowiowe nieszczęsne streonki w PeHaPe trzaska
> i na jakości ani na zatrzymaniu ludzi na dłużej im nie zależy.

Pewnie zależy im na zarabianiu pieniędzy. Jest spektrum rzeczy, na
których można zarabiać, od metaforycznych stronek w pehapie do
metaforycznego rocket science.

>> - im większe firma będzie musiała dawać podwyżki ich podwładnym, i im
>> trudniej będzie im zastąpić, tym mniejsze (ceteris paribus) będą ich
>> własne podwyżki i premie i tym większa szansa na, jeśli nie utratę
>> pracy, to przynajmniej utratę stanowiska kierowniczego.
>
> Jeśli ich te niby droższe zespoły będą dawac istotnie lepsze wyniki to
> nie ma obawy --

Obawa bierze się z tego, że nie wiadomo o ile lepsze te wyniki będą.

> chyba że firnma jest debilnie zarządzana -- ale wtedy
> dobry kierownik może znaleść pracę w innej, lepszej.

No chyba że doprowadzenie doprowadzenie projektu do strat przez
nietrafną decyzję pozwolenia programistom na wybieranie sobie języków -
nie jest czymś, co robi dobry kierownik.

do góry

W dniu środa, 6 lutego 2013 20:40:53 UTC+1 użytkownik Stachu 'Dozzie' K. napisał:

> Ej, nie wprowadzaj pseudoterminów na własną rękę. To powoduje, że twoja
> wypowiedź przestaje być zrozumiała, zwłaszcza dla osoby orientującej się
> w temacie, o którym ty się dopiero uczysz.
Ej, osoba nie znająca zagadnienia zrozumiałaby lepiej?


> Czyli nie "uchwyt procesu", tylko uchwyt pliku (filehandle), który jest
> potokiem albo gniazdem do innego procesu.
> Potrzebna ci była referencja do filehandle.
Generalnie ten programik zrobiłem, nie mogłem tylko przekazać tych
uchwytów jako parametry funkcji i musiałem przekopiować dwa razy
ten sam kod.


> Jak rozumiem, głównie dlatego że nie znalazłeś gotowca. Wniosek moim
> zdaniem jest jeden: nie wiedziałeś o co pytać. Przepraszam, ale bez
> znajomości podstawowej terminologii raczej ci się nie uda nauczyć
> czegokolwiek.
Nie chciałem się dowiedzieć wielkiej rzeczy, a tylko jak przekazać
owe uchwyty jako argumenty do funkcji. Ty musiałeś skończyć specjalne
studia żeby umieć o to pytać?


> Bo nie ma kontenera na zmienne typu int. Trzeba upakowywać te inty
> dodatkowo -- specjalnie, inaczej niż dowolne obiekty -- w klasę Integer.
> I dlaczego właściwie wrzucasz do jednego wora kontenery javowe, które
> w rzeczywistości składują Objecty (generyki to tylko taki cukier
> składniowy) z kontenerami biblioteki standardowej C++? Mówiliśmy o tym,
> że w Javie typy prymitywne są wyjątkiem w języku, który to wyjątek jest
> uciążliwy.
Nadal nie rozumiem o jaką uciążliwość chodzi. Wolno działa? Długo się
kompiluje? Sprzyja powstawaniu jakiś błędów? Niewygodnie kod się
wklepuje? Komplikują kod, a może projekt? Rozwlekły kod? Gdy programowałem
w Javie, to było dla mnie całkiem przyjemne zajęcie, przyjemniejsze niż
w C++. Gdy miałem długą przerwę i nagle musiałem wklepać w Javie średniej wielkości
program, to pomimo braków w wiedzy jakoś poradziłem sobie. Nigdy nic
szczególnie uciążliwego w związku z typami podstawowymi nic mnie nie
spotkało ze strony Javy. Było wręcz przeciwnie, czułem jakby Java nie
pozwalała mi skręcić w złą uliczkę.


> A RTTI już absolutnie nie ma nic wspólnego z tym, że skojarzyłeś mi się
> ze starym, sezonowanym Pascalowcem. Non sequitur, można by rzec.
Niektóre języki mają bardziej rozwlekłą składnię niż inne. W tych
rozwlekłych, trzeba więcej napisać - nie powinno to nikogo
specjalnie dziwić, ani wywoływać skojarzeń z Pascalem, gdzie się
rzeźbiło ręcznie GUI, bo nie było ani biblioteki, ani Internetu żeby
jej poszukać.

Typowanie dynamiczne zapewnia bardziej zwartą składnię z jednej strony, a
okupione jest... w końcu nie wiem czym. Większą podatnością na błędy?
Czy odwrotnie, większą odpornością na nie? W PHP nie trzeba podawać
typu zmiennej i można ją wykorzystać do przechowania danych innego
typu. Czy ja w PHP robiłem więcej błędów czy mniej niż w innych językach?
Nie wiem... chyba podobnie. Trudno powiedzieć, bo inne projekty realizowałem w
innych językach. Trudno porównywać. Pythona, Rubiego i całej reszty nie
sam znam, a z tej dyskusji jak na razie (chyba) nic nie wynikło. Kłócimy
się tylko o to, czy wygodne jest słowo def i rzutowanie na Integera - a
to raczej odpowiedzi nie przyniesie.

Pozdrawiam

do góry

On 2013-02-06, M.M. <m...@g...com> wrote:
> W dniu środa, 6 lutego 2013 20:40:53 UTC+1 użytkownik Stachu 'Dozzie' K. napisał:
>
>> Ej, nie wprowadzaj pseudoterminów na własną rękę. To powoduje, że twoja
>> wypowiedź przestaje być zrozumiała, zwłaszcza dla osoby orientującej się
>> w temacie, o którym ty się dopiero uczysz.
> Ej, osoba nie znająca zagadnienia zrozumiałaby lepiej?

Jest taka szansa. Laik nie próbowałby wpasować źle użytych terminów
zakładając, że były użyte prawidłowo. Jeśli ktoś używa specjalistycznej
terminologii, to zakładam, że to ja jestem głupi i nie rozumiem, a nie
że ktoś jest niedouczony z dziedziny, o której mówi.

>> Jak rozumiem, głównie dlatego że nie znalazłeś gotowca. Wniosek moim
>> zdaniem jest jeden: nie wiedziałeś o co pytać. Przepraszam, ale bez
>> znajomości podstawowej terminologii raczej ci się nie uda nauczyć
>> czegokolwiek.
> Nie chciałem się dowiedzieć wielkiej rzeczy, a tylko jak przekazać
> owe uchwyty jako argumenty do funkcji. Ty musiałeś skończyć specjalne
> studia żeby umieć o to pytać?

Nie, wystarczyło mi poznanie podstawowych typów danych danego języka.

>> Bo nie ma kontenera na zmienne typu int. Trzeba upakowywać te inty
>> dodatkowo -- specjalnie, inaczej niż dowolne obiekty -- w klasę Integer.
>> I dlaczego właściwie wrzucasz do jednego wora kontenery javowe, które
>> w rzeczywistości składują Objecty (generyki to tylko taki cukier
>> składniowy) z kontenerami biblioteki standardowej C++? Mówiliśmy o tym,
>> że w Javie typy prymitywne są wyjątkiem w języku, który to wyjątek jest
>> uciążliwy.
> Nadal nie rozumiem o jaką uciążliwość chodzi. Wolno działa? Długo się
> kompiluje? Sprzyja powstawaniu jakiś błędów? Niewygodnie kod się
> wklepuje?

NIE DA SIĘ ZROBIĆ, TO JEST TEN PRZESZKADZAJĄCY ELEMENT.
Wystarczająco wyraźnie napisałem? Nie da się i dupa. Musisz owijać
w Integera, który zresztą jest immutable.

> Komplikują kod, a może projekt? Rozwlekły kod? Gdy programowałem
> w Javie, to było dla mnie całkiem przyjemne zajęcie, przyjemniejsze niż
> w C++. Gdy miałem długą przerwę i nagle musiałem wklepać w Javie średniej wielkości
> program, to pomimo braków w wiedzy jakoś poradziłem sobie. Nigdy nic
> szczególnie uciążliwego w związku z typami podstawowymi nic mnie nie
> spotkało ze strony Javy.

Bo nie widziałeś innych języków, oto dlaczego. Nie masz porównania.

>> A RTTI już absolutnie nie ma nic wspólnego z tym, że skojarzyłeś mi się
>> ze starym, sezonowanym Pascalowcem. Non sequitur, można by rzec.
> Niektóre języki mają bardziej rozwlekłą składnię niż inne.

Co nadal nie ma związku z tym, że mi się *skojarzyłeś*. Nie rozumiesz po
polsku czy jak?

> W tych
> rozwlekłych, trzeba więcej napisać - nie powinno to nikogo
> specjalnie dziwić, ani wywoływać skojarzeń z Pascalem,

Ale mnie się nie język skojarzył z Pascalem, tylko twoja wypowiedź
z wypowiedziami starych Pascalowców. Rozumiesz tę subtelną różnicę?

--
Secunia non olet.
Stanislaw Klekot

do góry

W dniu środa, 6 lutego 2013 22:22:57 UTC+1 użytkownik Stachu 'Dozzie' K. napisał:

> NIE DA SIĘ ZROBIĆ, TO JEST TEN PRZESZKADZAJĄCY ELEMENT.
> Wystarczająco wyraźnie napisałem? Nie da się i dupa. Musisz owijać
> w Integera, który zresztą jest immutable.
No ale da się, jak sam piszesz, na klasie Integer, więc nadal nie
wiem w czym problem.

Pozdrawiam

do góry

On 05/02/2013 10:12, Maciej Sobczak wrote:
> W dniu wtorek, 5 lutego 2013 00:12:12 UTC+1 użytkownik Andrzej
> Jarzabek napisał:
>
>> Pytanie nie jaki zbiór można ogarnąć, tylko jakim kosztem. Każdy
>> dodatkowy język wiąże się z dodatkowymi kosztami.
>
> Jest też komplementarne pytanie, jakie są koszty nie-ogarnięcia.

Oczywiście, przecież to jest punkt wyjścia do dyskusji.

>> 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, to słusznym wnioskiem będzie ten z
refleksji.

>> W praktyce w skali zespołu zawsze będziesz miał ograniczenie
>> polegające na tym, że rekrutowani byli ludzie z określonymi
>> umiejętnościami.
>
> "Oczekujemy gotowości do zdobywania nowych umiejętności i poszerzania
> swoich kwalifikacji."
>
> 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.

>>> Konflikt wygląda tak:
>>> "Panowie, no weźcie zróbcie coś, żeby tych bugów tyle nie było."
>> U was w firmie programiści chcą, żeby bugi były?
>
> Nie chcą.

No to nie w tym jest konflikt.

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.

>>> "Oferujemy możliwość pracy z najnowszymi technologiami."
>> Być może, ale to przecież nie znaczy, że każdy dobór najnowszej
>> czy dobrej technologii ma sens w każdym projekcie.
>
> Niczego takiego nie pisałem.

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.

>> Tak więc teoretycznie może zaistnieć sytuacja, kiedy programista,
>> któremu pozostawiono w tej kwestii wolną rękę,
>
> To kto ma mieć wolną rękę? Sprzątaczka?

Nie wiem, kto ma mieć, raczej jest to złożony problem, na który trudno
dać odpowiedź abstrahując od konkretnego projektu i firmy. Natomiast
zauważę, że w wielu instytucjach takie decyzje podejmuje się na
jakichśtam stanowiskach kierowniczych typu "head of development" czy CTO.

>>> Tak. Dobry wybór technologii nie stoi w sprzeczności z tym
>>> celem.
>> Zależy jak rozumie się "dobry".
>
> Tak, żeby było "lepiej". Celem refleksji jest określenie, co to
> oznacza. Dla różnych branż, firm i projektów to mogą być różne
> rzeczy.

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

>> * Kandydaci owszem, chętnie się nauczą Scali, ale póki co jej nie
>> znają. Zanim się zapoznają minie ileś tam czasu, w którym to czasie
>> będą mniej produktywni.
>
> Kandydaci i tak nie są produktywni przez początkowy okres czasu.

Ale im dłużej nie są praduktywni, tym gorzej. Koniczeność nauki nowych
języków, czy co gorsza całych paradygmatów programowania, sprawę tylko
pogarsza.

>> * Jeśli zdecydujesz się zatrudnić ludzi, którzy nie znają ani
>> Scali, ani odpowiednich technik, to ryzykujesz, że się ich nie będą
>> w stanie nauczyć.
>
> 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.

>> Możesz powiedzieć, że tak czy inaczej starasz się zatrudnić tych
>> kumatych, ale wszystko jest kwestią skali (no pun intended).
>
> Tak. Ale zależnie od skali inaczej będę też podchodził do rekrutacji.
> Masowy projekt zwykle prowadzi do masowej rekrutacji - i masowych
> efektów.

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

do góry

On 05/02/2013 15:16, M.M. wrote:
> W dniu wtorek, 5 lutego 2013 16:03:12 UTC+1 użytkownik Stachu 'Dozzie' K. napisał:
>
>> Ale tam się tak jakby deklaruje typ zwracany. To "uporanie się" polegało
>> na obciążeniu składni przewidzianej dla systemu typów dodatkowym
>> obowiązkiem wykrywania deklaracji i/lub definicji funkcji.
> Nie znam na wszystkich językach, ale najwyraźniej tutaj
> też się deklaruje typ zwracany:
> [
> def hello2(msg: String): String = {
> ]

Ale w wielu przypadkach można tę deklarację pominąć i napisać

def hello2(msg: String) = {

do góry

On 2013-02-06, M.M. <m...@g...com> wrote:
> W dniu środa, 6 lutego 2013 22:22:57 UTC+1 użytkownik Stachu 'Dozzie' K. napisał:
>
>> NIE DA SIĘ ZROBIĆ, TO JEST TEN PRZESZKADZAJĄCY ELEMENT.
>> Wystarczająco wyraźnie napisałem? Nie da się i dupa. Musisz owijać
>> w Integera, który zresztą jest immutable.
> No ale da się, jak sam piszesz, na klasie Integer, więc nadal nie
> wiem w czym problem.

No właśnie się nie da. Nie da się mieć haszmapy intów, trzeba robić
haszmapę Integerów. Rozumiesz tę subtelną różnicę? Te inty to ja już
mam, a Integery dopiero muszę zrobić.

--
Secunia non olet.
Stanislaw Klekot

do góry