On 2013-02-05, M.M. <m...@g...com> wrote:
> W dniu wtorek, 5 lutego 2013 13:14:22 UTC+1 użytkownik Stachu 'Dozzie' K. napisał:
>>
>> Na przykład Python (`def foo()'), Ruby (`def foo()'), Perl (sub foo {}),
>> Erlang (foo() ->), SML (fun foo x y).
>> Jak to było z tym "potworkiem składniowym"?
>
> W C/C++/Javie udało się usunąć ten element języka, a jeśli się
> udało i języki funkcjonują dobrze, to znaczy, że ten element jest
> zbędny.

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 jestem
przekonany, czy aby na pewno to eleganckie rozwiązanie, a już na pewno
nie da się tego transplantować do języków o dynamicznym systemie typów.

Innych pomysłów na usunięcie jawnego wskazywania deklaracji/definicji
funkcji sobie nie przypominam.

--
Secunia non olet.
Stanislaw Klekot

do góry

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 = {
]


> Nie jestem przekonany, czy aby na pewno to eleganckie rozwiązanie, a
> już na pewno nie da się tego transplantować do języków o dynamicznym
> systemie typów.
Co to jest dynamiczny system typów? Java-reflection podlega pod
dynamiczny system typów czy nie?

Pozdrawiam

do góry

On Feb 5, 3:03 pm, "Stachu 'Dozzie' K."
<d...@g...eat.some.screws.spammer.invalid> wrote:
> On 2013-02-05, M.M. <m...@g...com> wrote:
>
> > W C/C++/Javie udało się usunąć ten element języka, a jeśli się
> > udało i języki funkcjonują dobrze, to znaczy, że ten element jest
> > zbędny.
>
> 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 jestem
> przekonany, czy aby na pewno to eleganckie rozwiązanie, a już na pewno

Powiedzmy sobie szczerze, że jest ohydne.

> nie da się tego transplantować do języków o dynamicznym systemie typów.

Scala ma statyczny system typów, ale tam akurat deklaracje typów
funkcji i argumentów są zbędne.

> Innych pomysłów na usunięcie jawnego wskazywania deklaracji/definicji
> funkcji sobie nie przypominam.

Proszę bardzo:
diag a b = sqrt(a*a+b*b)

do góry

Użytkownik "Stachu 'Dozzie' K." <d...@g...eat.some.screws.spammer.invalid> napisał:

> a już na pewno nie da się tego transplantować do języków o dynamicznym
> systemie typów.

Otóz "da sie" i oczywiście tak się robi.

PS: Poza tym caly ten "problem" to w 80% "lukier skladniowy"
a w 20% wynika z niedoskonalosci narzedzi "parsingowych".

AK


--- news://freenews.netfront.net/ - complaints: n...@n...net ---

do góry

On 02/05/2013 04:16 PM, 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 = {
> ]
>
>
>> Nie jestem przekonany, czy aby na pewno to eleganckie rozwiązanie, a
>> już na pewno nie da się tego transplantować do języków o dynamicznym
>> systemie typów.
> Co to jest dynamiczny system typów?

Np to co jest w Pythonie.

> Java-reflection podlega pod
> dynamiczny system typów czy nie?

W zasadzie Nie. Reflekscja działa w keirunku odwrontym do systemu typów.

pzdr
\SK

do góry

On 02/05/2013 04:25 PM, AK wrote:
> Użytkownik "Stachu 'Dozzie' K."
> <d...@g...eat.some.screws.spammer.invalid> napisał:
>
>> a już na pewno nie da się tego transplantować do języków o dynamicznym
>> systemie typów.
>
> Otóz "da sie" i oczywiście tak się robi.

Że co?

Rozpoznaje składnie funkcji na podstawie podania typu (bo o tym mowa) w
języku w którym typu nie podaje się? Ciekawe :)


Bo poza tym to oczywiście da się uniknąć słowa kluczowego zastępując je
np. znakiem specjalnym, ot np:

a = {
ple(bulbul) + ble(bulbul)
}(bulbul)

może tworzyć funkcję. :)



\SK

do góry

On 02/05/2013 12:12 AM, Andrzej Jarzabek wrote:
[...]
> Oj, nie twierdzę przecież, że problem (metaforycznej) Scali jest taki,
> że kandydaci nie będą chętni. Problem jest taki, że:
> * 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"

> * Jeśli chcesz zatrudnić kandydatów już znających Scalę, to możesz
> długo szukać. Jeśli nie chcesz długoo szukać, to musisz wystawić bardzo
> atrakcyjną ofertę.
> * Jeśli dajmy na to nie wymagasz znajomości Scali, ale w celu
> skrócenia czasu nauki i zapewnienia dobrego wykorzystania zalet języka
> szukasz ludzi, którzy wiedzą coś np. o programowaniu funkcyjnym. To też
> utrudnia ci znalezienie kandydata i powoduje konieczność wystawienia
> lepszej oferty (niż gdybyś tego nie wymagał) w celu pryciągnięcia
> odpowiednich ludzi.
> * 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ć. Dasz im, powiedzmy, pół roku okresu próbnego, to musisz się
> liczyć, że po pół roku jakiś tam procent nie będzie rokował nadziei i
> trzeba będzie szukać kolejnych - koszty.

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

> 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ę"

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

>
> Możesz powiedzieć, że tak czy inaczej starasz się zatrudnić tych
> kumatych, ale wszystko jest kwestią skali (no pun intended). Zawsze
> możesz starać się zatrudnić jeszcze bardziej kumatych, a jeśli ogłosisz,
> że płacisz 30 tysięcy na rękę, to na pewno wielu kumatych przyjdzie do
> 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.

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.

>
>> Tak więc nie przyjmuję argumentu, że jest to wbrew oczekiwaniom
>> pracodawcy. Wydaje się, że przy odpowiedniej organizacji można
>> stworzyć układ, w którym wszystkim będzie po drodze.
>
> Nie wszystko, co można jest dobre dla "bottom line".
>
>>> Dlatego też nie jest w ogóle oczywiste, czy dla właściciela w ogóle
>>> dobrym posunięciem jest pozostawienie tej decyzji wyłącznie w
>>> gestii programistów.
>>
>> "No chyba powinniście wiedzieć, co zrobić, żeby było dobrze."
>
> Niekiedy jest tak, że między programistą a pointy haired bossem niekiedy
> jest jeden lub więcej szczebli menedżerów technicznych, którzy mają na
> tyle pojęcia o technologii, żeby móc podejmować takie decyzje, ale
> którzy z drugiej strony nie mają motywacji, że dzięki użyciu Scali będą
> mieli większe podwyżki i mniejszą szansę na zwolnienie. Wręcz przeciwnie
> - 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 -- chyba że firnma jest debilnie zarządzana -- ale wtedy
dobry kierownik może znaleść pracę w innej, lepszej.

\SK

do góry

W dniu wtorek, 5 lutego 2013 17:05:30 UTC+1 użytkownik Sebastian Kaliszewski napisał:
> Np to co jest w Pythonie.
> W zasadzie Nie. Reflekscja działa w keirunku odwrontym do systemu typów.
Nie rozumiem, nie znam pythona. Co jest w pythonie czego nie umożliwia
java-reflection? O jakim kierunku mowa?
Pozdrawiam

do góry

Użytkownik "Sebastian Kaliszewski" <S...@n...softax.com.pl>
napisał:

>>> a już na pewno nie da się tego transplantować do języków o dynamicznym
>>> systemie typów.
>>
>> Otóz "da sie" i oczywiście tak się robi.
>
> Że co?

Przestan glupolu sie czepiac, bo jesli chodzi o znajomosc jezykow programowania
to "mozesz mi klawiature czyscic" :)

> Rozpoznaje składnie funkcji na podstawie podania typu (bo o tym mowa) w języku w
którym typu nie
> podaje się? Ciekawe :)

Mowilem zes glupol i znow sie sprawdza.
Slowem: bredzisz.
Nie o zadne rozpoznawanie funkcji chodzi.
"Rozpoznawanie funkcji" (czyli czy to funkcja itp) ma sie tak do
"typologii" jak (...)

> Bo poza tym to oczywiście da się uniknąć słowa kluczowego

Jakie znow slowo kluczowe ? Co ty stulasz ?
Mowimy o _systemie typow_ i jego "pilnowaniu", a nie o parsingu, synktatyce
"rozpoznawaniu funkcji" itp.

PS: Przeprszam wszytskich (lacznie z interlokutorem) za "bezposredniosc" ale
tolerancja
dla siemionowstwa usenetowego wyraznie mi sie zmniejszyla na starosc :(

AK


--- news://freenews.netfront.net/ - complaints: n...@n...net ---

do góry

Gdyby tak było (co do niepotrzebnosci def bo gdzieś mi tekst zniknął na fonie) to
znaczyłoby że wogóle trzeba stripnac c do jak najprostszej składni a wcale nie jest
jasne czy to jest priorytet, (mnie def nie razi )

Fir (ciągle na wakacjach, że zdrowiem kiepsko)

do góry