On 06/02/2013 15:50, M.M. wrote:
> W dniu środa, 6 lutego 2013 15:46:17 UTC+1 użytkownik Sebastian Kaliszewski
napisał:
>>
>> Dynamiczny system typów. W językach dynamicznych (Lisp, Python, Ruby,
>> Perl, Scheme, Lua, Smalltalk, Dylan, Erlang, itd...) typy są określane w
>> czasie wykonania (dynamicznie) a nie w czasie
>> kompliacji/parsowania/linkowania.
> Dobra, ale w C i w C++ też jest to możliwe. W C jest wskaźnik, może on
> wskazywać na strukturę której pierwszy int mówi nam o tym co jest w dalszej
> części struktury.

Ale język nie potrafi ci tego obsłużyć. Nie możesz na takim wkaźniku
napisać (p->foo), co by znaczyło "popatrz na tego inta i w zależności od
tego, co nam mówi o tym, co jest w dalszej części struktury albo daj mi
składową o nazwie foo, albo zgłoś błąd".

> W C++ pod offsetem od danych na które wskazuje wskaźnik
> może być adres metody wirtualnej, która wie co zrobić z danym typem.

Ale musisz statycznie zzdefiniować typ bazowy i zbiór wszystkich
operacji dostępnych przez ten typ. No i wtedy nie możesz przypisać
żadnych innych typów do zmiennej/referencji twojego typu. W językach z
dynamicznym systemem typów typ zmiennej może się zmieniać w trakcie
wykonania programu.

> W QT, w
> VCL i zapewne w wielu innych jest klasa Variant...

I można sensownie przypisać wartość dowolnego typu do zmiennej klasy
Variant?

>> Refleksja to jest czytanie szczegółów już istniejących typów. System
>> typów to nadawanie typów.
> Rzadko używam javy, a refleksji to już w ogóle rzadko, ale z tego co
> pamiętam można do klasy dodać dowolne pole o dowolnym typie, a nawet
> metodę można dodać. Jeśli się mylę, to poprawcie mnie.

Źle pamiętasz.

> Jedyna różnica
> jest taka, że do zmiennej typu int nie mogę bez bólu przypisać zmiennej
> typu tablicowego, czy referencji na obiekt. Czy to jest aż tak
> potrzebne, wygodne, czy nie wiem co? 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ę...

Wygodne bywa to, że zmienne w ogóle nie mają żadnego typu, a mogą
trzymać wartości typu dowolnego. To samo z funkcjami - nie mają
zadeklarowanego typu, a mogą zwrócić wartość dowolnego typu.

Dodatkowo języki dynamiczne często mają możliwość konstruowania typów w
locie, można sobie np. wczytać XML i skonstruować obiekt odpowiadający
węzłowi z właściwościami odpowiadającymi podelementom czy atrybutom. W
Javie żeby to zrobić musisz dostarczyć schema, z której jest generowany
kod, który sobie kompilujesz.

do góry

On 06/02/2013 17:43, M.M. 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.

Jeśli jest to zupełne cokolwiek, to czemu nie możesz po prostu trzmać w
zmiennej typu skalarnego?

Czy chodzi ci o to, że masz je w Perlu jako filehandles? Filehandles są
specjalnym typem danych i mają specjalne traktowanie w Perlu. Jak
przekazywać je jako argumenty do podprogramu jest w dokumentacji języka,
a wyguglanie zajęło mi całe 5 minut:
http://perldoc.perl.org/perldata.html#Typeglobs-and-
Filehandles

do góry

W dniu środa, 6 lutego 2013 23:32:08 UTC+1 użytkownik Stachu 'Dozzie' K. napisał:
> 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ć.
Różnicę zrozumiałe już dawno, ale nie mogę pojąć, dlaczego to jest
problemem.
Pozdrawiam

do góry

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

> Ale język nie potrafi ci tego obsłużyć. Nie możesz na takim wkaźniku
> napisać (p->foo), co by znaczyło "popatrz na tego inta i w zależności od
> tego, co nam mówi o tym, co jest w dalszej części struktury albo daj mi
> składową o nazwie foo, albo zgłoś błąd".
Język oczywiście nie, można taką funkcjonalność uzyskać przez użycie
biblioteki. Można użyć jakiejś HashMapy na stringu i klasie abstrakcyjnej,
albo na typie Variant. Nie wydaje się to gorsze od pola dodanego do
obiektu w trakcie wykonania programu.


> I można sensownie przypisać wartość dowolnego typu do zmiennej klasy
> Variant?
Nie wiem co znaczy sensownie. Wczoraj do Variant przypisywałem
Pixmapę z obrazkiem. Jak na razie nie narzekam na brak funkcjonalności.


> Źle pamiętasz.
Faktycznie nie da się tego łatwo osiągnąć. Ale jakieś ClassLoadery na
podstawie XMLa albo tabeli w bazie danych to chyba są do Javy?


> Wygodne bywa to, że zmienne w ogóle nie mają żadnego typu, a mogą
> trzymać wartości typu dowolnego. To samo z funkcjami - nie mają
> zadeklarowanego typu, a mogą zwrócić wartość dowolnego typu.
No właśnie bardzo podobną wygodę obserwuję w C++ gdy używam
typu Variant albo funkcji wirtualnych.


> Dodatkowo języki dynamiczne często mają możliwość konstruowania typów w
> locie, można sobie np. wczytać XML i skonstruować obiekt odpowiadający
> węzłowi z właściwościami odpowiadającymi podelementom czy atrybutom. W
> Javie żeby to zrobić musisz dostarczyć schema, z której jest generowany
> kod, który sobie kompilujesz.
Tutaj znowu ten argument z HashMapą indeksowaną stringiem. Chyba podobna
wygoda? W PHP mam obiekt->pole, w C++ mam obiekt['pole'].

Pozdrawiam

do góry

On 06/02/2013 08:57, Maciej Sobczak wrote:
> W dniu wtorek, 5 lutego 2013 00:12:12 UTC+1 użytkownik Andrzej
> Jarzabek napisał:
>
>> Wręcz przeciwnie - im większe firma będzie musiała dawać podwyżki
>> ich podwładnym,
>
> Jeszcze mnie męczy temat tych podwyżek (że jak zdecyduję się na
> Scalę, to będę musiał dawać większe podwyżki programistom).
>
> Niby dlaczego mieliby dostawać większe? Bo jak nie dostaną, to
> odejdą?

Tak właśnie.

> Gdzie odejdą, skoro żadna inna firma nie używa Scali a im to
> sprawia frajdę?

Gdzieś, gdzie im więcej zapłacą.

> Zostaną na miejscu właśnie ze względu na tą frajdę.
> Bo w przypadku, gdy żadna inna firma nie używa Scali, to jedyny
> argument za przejściem do konkurencji to wyższe wynagrodzenie. Ale
> skoro konkurencja używająca Javy może dać moim ludziom wyższe pensje,
> to użycie bądź nieużycie Scali jest tu kompletnie nieistotne - nawet
> jeśli nie użyję Scali w swoim projekcie, to nadal mam tą samą
> konkurencję, która używa Javy i lepiej płaci. Wychodzi więc, że
> użycie Scali w ogóle nie wpływa na temat przyszłych podwyżek dla
> programistów,

Przecież to nie działa tak, że jeśli ty płacisz 15 tysięcy, a ktoś płaci
16, to na drugi dzień wszyscy twoi programiści pracują u tego kogoś. To
jest proces stochastyczny: im mniej płacisz tym częściej twoi
programiści odchodzą, i tym dłużej zajmuje ci znalezienie następnych na
ich miejsce (spełniających twoje wymagania). Każda sytuacja, kiedy
musisz zastąpić pracownika, który odszedł, kosztuje, bo:
* minie jakiś czas zanim kogoś zatrudnisz,
* sama rekrutacja kosztuje,
* minie jakiś czas zanim nowy pracownik osiągnie produktywność tego,
który odszedł (początkowo zapewne nawet obniży całkowitą produktywność
zespołu).

Użycie Scali powoduje, że ten koszt wzrasta, bo:
* musisz podnieść poprzeczkę, co może wydłużyć czas rekrutacji,
* wydłuża się czas do osiągnięcia produktywności.

Mi przecież nie o to chodzi, że jak wprowadzisz Scalę, a nie dasz
podwyżek (większych, niż byś dał bez tego), to pracownicy będą częściej
odchodzić. Może będą odchodzić tak samo często, może nawet, jak
twierdzisz, rzadziej. Ale za każdym razem, jak któryś odejdzie, to
ciebie jako pracodawcę będzie kosztować to więcej - więc bardziej będzie
ci się opłacało dać im podwyżki, żeby odchodzili rzadziej.

> których zatrudnię i to niezależnie od tego, czy w
> momencie rekrutacji oni Scalę znają czy też nie znają. Natomiast
> jeśli konkurencja również zdedycuje się na użycie Scali (ale dlaczego
> mieliby to zrobić, biorąc pod uwagę wszystkie Twoje argumenty
> przeciw?),

Dlatego że, co jest punktem wyjścia do całej tej dyskusji, pewne języki
mają w odpowiednich warunkach przewagę nad innymi w postaci zwiększania
niezawodności programów czy produktywności programistów.

> to po prostu mamy mały rynek, gdzie mały popyt zgadza się
> z małą podażą i dalej nie widzę powodu, żeby ktokolwiek miał zarabiać
> kokosy tylko dlatego, że używa języka X a nie Y.

Powód jest taki, że trudniej (drożej) go zastąpić. To jest bardzo
powszechny powód do zarabiania więkzej kasy.

do góry

On 2013-02-06, M.M. <m...@g...com> wrote:
> W dniu środa, 6 lutego 2013 23:32:08 UTC+1 użytkownik Stachu 'Dozzie' K. napisał:
>> 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ć.
> Różnicę zrozumiałe już dawno, ale nie mogę pojąć, dlaczego to jest
> problemem.

Bo dopiero muszę te Integery wytworzyć, choć wszystkie potrzebne dane
już dawno mam. A gdybym miał użyć, dajmy na to, BigIntegera czy
czegokolwiek innego, to nie muszę tworzyć nowego. Sytuacja wyjątkowa
w przypadku typów wbudowanych.

To samo z czymkolwiek innym: obiekty można obsługiwać w sposób
jednolity, ale do typów wbudowanych trzeba specjalnie tworzyć dodatkowe
elementy.

To jak młotek z zębami do wyciągania gwoździ po obu stronach obucha.
Nadal się da wbijać gwoździe (obuchem ustawionym płasko), ale jakoś
dziwnie się człowiek przy tym czuje. Oczywiście ktoś, kto nie
widział nigdy innego, nie będzie rozumiał, czemu taka konstrukcja jest
w ogóle problemem.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 06/02/2013 23:47, M.M. wrote:
> W dniu środa, 6 lutego 2013 23:57:44 UTC+1 użytkownik Andrzej Jarzabek napisał:
>
>> Ale język nie potrafi ci tego obsłużyć. Nie możesz na takim wkaźniku
>> napisać (p->foo), co by znaczyło "popatrz na tego inta i w zależności od
>> tego, co nam mówi o tym, co jest w dalszej części struktury albo daj mi
>> składową o nazwie foo, albo zgłoś błąd".
> Język oczywiście nie, można taką funkcjonalność uzyskać przez użycie
> biblioteki. Można użyć jakiejś HashMapy na stringu i klasie abstrakcyjnej,
> albo na typie Variant. Nie wydaje się to gorsze od pola dodanego do
> obiektu w trakcie wykonania programu.

No ale nie możesz w ten sposób wstawić dowolnej struktury czy mapy.

>> I można sensownie przypisać wartość dowolnego typu do zmiennej klasy
>> Variant?
> Nie wiem co znaczy sensownie. Wczoraj do Variant przypisywałem
> Pixmapę z obrazkiem. Jak na razie nie narzekam na brak funkcjonalności.

Możesz przypisać boost::function<int(int)>?

>> Źle pamiętasz.
> Faktycznie nie da się tego łatwo osiągnąć. Ale jakieś ClassLoadery na
> podstawie XMLa albo tabeli w bazie danych to chyba są do Javy?

Nigdy się nie spotkałem, zresztą byłoby to mało wygodne, bo byś się
musiał dziubdziać przez refleksję właśnie zamiast normalnie używać metod
i pól przy użyciu składni języka.

>> Wygodne bywa to, że zmienne w ogóle nie mają żadnego typu, a mogą
>> trzymać wartości typu dowolnego. To samo z funkcjami - nie mają
>> zadeklarowanego typu, a mogą zwrócić wartość dowolnego typu.
> No właśnie bardzo podobną wygodę obserwuję w C++ gdy używam
> typu Variant albo funkcji wirtualnych.

Nie ma tej wygody, bo na zmiennej typu Variant możesz wywoływać tylko
mettody typu Variant - czyli żadnych użytecznych dla danych, na których
faktycznie chcesz wykonywać jakieś operacje. Żeby zrobić coś więcej
musisz sobie przerzutować, a żeby przerzutować musisz dokładnie
wiedzieć, na co chcesz rzutować.

> Tutaj znowu ten argument z HashMapą indeksowaną stringiem. Chyba podobna
> wygoda? W PHP mam obiekt->pole, w C++ mam obiekt['pole'].

Nie możesz mieć tego samego kodu, który zadziała zarówno na hashmapie z
elementem o nazwie 'pole' jak i na obiekcie typu (klasy) mającego pole o
nazwie 'pole'.

do góry

On 07/02/2013 00:10, Stachu 'Dozzie' K. wrote:
>
> Bo dopiero muszę te Integery wytworzyć, choć wszystkie potrzebne dane
> już dawno mam. A gdybym miał użyć, dajmy na to, BigIntegera czy
> czegokolwiek innego, to nie muszę tworzyć nowego. Sytuacja wyjątkowa
> w przypadku typów wbudowanych.
>
> To samo z czymkolwiek innym: obiekty można obsługiwać w sposób
> jednolity, ale do typów wbudowanych trzeba specjalnie tworzyć dodatkowe
> elementy.

Tylko tak przy okazji, nie ma to żadnego związku ze statycznym czy
dynamicznym systemem typów. Może być język ze statycznym systemem typów
w którym "everything is an object" - w Javie początkowo tak miało być,
ale wprowadzili typy wbudowane ze wględów wydajnościowych.

do góry

W dniu czwartek, 7 lutego 2013 01:10:12 UTC+1 użytkownik Stachu 'Dozzie' K. napisał:
> Bo dopiero muszę te Integery wytworzyć, choć wszystkie potrzebne dane
> już dawno mam. A gdybym miał użyć, dajmy na to, BigIntegera czy
> czegokolwiek innego, to nie muszę tworzyć nowego. Sytuacja wyjątkowa
> w przypadku typów wbudowanych.
> To samo z czymkolwiek innym: obiekty można obsługiwać w sposób
> jednolity, ale do typów wbudowanych trzeba specjalnie tworzyć dodatkowe
> elementy.
> To jak młotek z zębami do wyciągania gwoździ po obu stronach obucha.
> Nadal się da wbijać gwoździe (obuchem ustawionym płasko), ale jakoś
> dziwnie się człowiek przy tym czuje. Oczywiście ktoś, kto nie
> widział nigdy innego, nie będzie rozumiał, czemu taka konstrukcja jest
> w ogóle problemem.

Skojarzenie z młotkiem jest (znowu) daleko chybione. Takim młotkiem można
sobie prędzej krzywdę zrobić, natomiast rzutowanie na Integer jest tak
minimalną niewygodą, że nie było warto wspominać.

Pozdrawiam

do góry

W dniu czwartek, 7 lutego 2013 01:12:47 UTC+1 użytkownik Andrzej Jarzabek napisał:
> No ale nie możesz w ten sposób wstawić dowolnej struktury czy mapy.
Jak na razie wstawiam dowolne potrzebne.

> Możesz przypisać boost::function<int(int)>?
Czy to na pewno jest potrzebne, albo chociaż zapewnia w jakimś
przypadku wygodę?

> Nigdy się nie spotkałem, zresztą byłoby to mało wygodne, bo byś się
> musiał dziubdziać przez refleksję właśnie zamiast normalnie używać metod
> i pól przy użyciu składni języka.
Też tak myślę.

> Nie ma tej wygody, bo na zmiennej typu Variant możesz wywoływać tylko
> mettody typu Variant - czyli żadnych użytecznych dla danych, na których
> faktycznie chcesz wykonywać jakieś operacje.
Nie wiem o jaką użyteczność chodzi, ale może to by załatwiała metoda
wirtualna?

> Żeby zrobić coś więcej
> musisz sobie przerzutować, a żeby przerzutować musisz dokładnie
> wiedzieć, na co chcesz rzutować.
Nie trzeba wiedzieć aż tak dokładnie, wystarczy rzutować na klasę z
czystą metodą wirtualną, zwykle na tą najwyższą w hierarchii dziedziczenia.


> Nie możesz mieć tego samego kodu, który zadziała zarówno na hashmapie z
> elementem o nazwie 'pole' jak i na obiekcie typu (klasy) mającego pole o
> nazwie 'pole'.
O jakie różnice chodzi?

Pozdrawiam

do góry