On 11/02/2013 00:31, Roman W wrote:
>
> Dla mnie jako współautora kilku juz bibliotek do wyceny tych nieslawnych
> derywatow bardzo duza zaletą statycznego systemu typow jest możliwość
> precyzyjnego zdefiniowania API biblioteki, w szczególności zaś
> blokowanie "podpisania" do biblioteki rzeczy, które nie miały byc przez
> nia obrabiane.

BTW kiedyś zdaje się wspominałeś, że jakąś sporą część oprogramowania do
liczenia różnych rzeczy w bankach pisze się jako makra w VBA. Miałem
ostatnio "przyjemność" dłubać coś w VBA i on ma raczej taki mieszany
system typów.

Oczywiście nie żebym podawał VBA jako jakiś pozytywny przykład
użyteczności dynamicznego typowania. Raczej przykład na to, że jakiś
język może być popularny w jakichś zastosowaniach i niekoniecznie ma to
związek z tym, czy system typów czy jakiekolwiek inne ficzery mają
związek z przydatnością tego języka do tych zastosowań.

do góry

W dniu wtorek, 12 lutego 2013 00:23:54 UTC+1 użytkownik Andrzej Jarzabek napisał:
> On 11/02/2013 16:24, M.M. wrote:
>
> [...]
>
> > o użyciu takiego lubi innego typowania. Wygląda na to że różnica w
>
> > korzyściach pomiędzy jednym typowaniem a drugim nie jest taka duża, jak
>
> > pomiędzy asemblerem a językiem wysokiego poziomu.
>
>
>
> A ktoś twierdził, że jest?
Było porównanie do że jak ktoś używa kart dziurkowanych to mu
nawet kod maszynowy niepotrzebny. Zgodzę się, że typowanie
dynamiczne być może ma zalety (a tylko ja ich nie zauważam), a nie
zgodzę się że te zalety są tak ogromne jak w przypadku
przechodzenia z kart do kodu maszynowego, z kodu maszynowego do
asemblera lub z asemblera do języków wysokiego poziomu. Być
może typowanie dynamiczne daje jakieś niewielkie korzyści -
oczywiście mówię w ogólnym bilansie.


> On działa w obydwie strony, bo jeśli logika jest OK, tylko hierarchia
> typów błędnie mapuje dziedzinę, to też masz błędy kompilatora.
Za duże skróty myślowe, nie rozumiem.


Chodziło mi o mnie/więcej o to, że
logika pracowała na specyficznej strukturze danych. A więc warstwa
prezentacyjna przed pobieraniem danych musiała przygotować typy dla
warstwy obliczeniowej. Po zoptymalizowaniu logika działała już na
innym formacie danych. Logika działała i można ją było przetestować
pod kątem wydajności. Jednak program nie dał się uruchomić bez zmian
w warstwie prezentacyjnej. Trzeba było albo pisać konwersje, albo
warstwę prezentacyjną dostosować do nowego API w logice. W języku
z dynamicznymi typami bym logikę uruchomił bez poprawek w prezentacji.



Pozdrawiam

do góry

On 12/02/2013 00:15, M.M. wrote:
> W dniu wtorek, 12 lutego 2013 00:23:54 UTC+1 użytkownik Andrzej Jarzabek napisał:
>> On 11/02/2013 16:24, M.M. wrote:
>
>>> o użyciu takiego lubi innego typowania. Wygląda na to że różnica w
>>> korzyściach pomiędzy jednym typowaniem a drugim nie jest taka duża, jak
>>> pomiędzy asemblerem a językiem wysokiego poziomu.
>> A ktoś twierdził, że jest?
> Było porównanie do że jak ktoś używa kart dziurkowanych to mu
> nawet kod maszynowy niepotrzebny.

Mniemoniki asemblerowe przecież. Poza tym chodziło o first class
functions, a nie o dynamiczne typowanie. Poza tym się nie zrozumieliśmy
- nie chodziło mi, że różnica między czymśtam a czymśtam jest jak między
dziurkowaniem kart a czymśtam, tylko o sensowność argumentu "ja nie
potrzebuję, więc jest to bezużyteczne".

>> On działa w obydwie strony, bo jeśli logika jest OK, tylko hierarchia
>> typów błędnie mapuje dziedzinę, to też masz błędy kompilatora.
> Za duże skróty myślowe, nie rozumiem.

Dziedzina to jest to, czego dotyczy program - sterowanie samolotem,
spedycja międzynarodowa, strzelanka FPS, co tam jeszcze. Mapowanie
dziedziny na system typów - stworzenie typów dla pojęć z dziedziny
(kontrahent, transakcja, statecznik poziomy, przeciwnik) i uwzględnienie
relacji - IsA, HasA, 1 do 1, 1 do wielu itd. Mając prawidłową logikę
programu (algorytmy) i błędnie zamapowane typy możesz mieć błędy
kompilacji. Powiedzmy, prawidłowy algorytm ustawia i odczytuje walutę
transakcji i twój program właśnie to robi, ale ponieważ masz błednie
zdefiniowany typ transakcji, to kod się nie kompiluje, bo typ nie ma
takiej właściwości.

do góry

Andrzej Jarzabek <a...@g...com> wrote:

> BTW kiedyś zdaje się wspominałeś, że jakąś sporą część oprogramowania do
> liczenia różnych rzeczy w bankach pisze się jako makra w VBA.

Czasem przez security. Nie jest łatwo przeforsować możliwość uruchomienia
exeka w niektórych bankach.

--
Gof
http://www.chmurka.net/

do góry

Użytkownik "Maciej Sobczak" <s...@g...com> napisał:

> Poza tym, że obiektowość powstała z myślą o dużych systemach

:) nie ma to jak urojenia Ayatollahow C++ :)

AK

do góry

W dniu wtorek, 12 lutego 2013 00:19:46 UTC+1 użytkownik Andrzej Jarzabek napisał:

> No to odpowiem: ty nie dałbyś, ale kto inny dał. Tajemnica wyjaśniona?

Nie bardzo. Kiedyś pewien akwizytor do mnie zapukał i chciał mi coś sprzedać
powołując się na fakt, że mój sąsiad też kupił. Zgadnij, jaki osiągnął sukces.

> > Poza tym, że obiektowość powstała z myślą o dużych systemach
>
> W którym momencie?

W takim, że w małych nie było powodów, żeby powstała.

> > i sama w sobie nie ma cech, który by były z nimi sprzeczne.
>
> http://c2.com/cgi/wiki?ArgumentsAgainstOop

Przewinąłem losowo i trafiłem na argument "OO runs too slow", z którym nawet autor
tej strony się nie zgadza, ale ponieważ gdzieś to usłyszał, to napisał.

Przyznaję, że rzuciłem też okiem na inne argumenty na tej liście, ale one też mnie
nie porwały.

> http://folk.uio.no/andersmo/oo.html

Przewinąłem losowo i trafiłem na argument "Everything has to be an object".
Sorry, ale dzisiaj mam też trochę pracy do zrobienia.

Jeżeli chciałem pokazać, że na absolutnie każdy temat można znaleźć w necie stronę
zatytułowaną "Why XYZ sucks", to wiem, że można.

> > Jeśli coś ma być inaczej, to ma być po coś i ma się opłacać.
>
> A dlaczego akurat to dynamiczny, a nie statyczny system typów to jest
> "inaczej"?

Bo rozmawialiśmy o możliwości wprowadzenia nowego języka w miejscu, gdzie używa się
czegoś mainstreamowego - w domyśle Javy lub C++. Taki był mniej więcej klimat w tym
wątku i generalnie takie są realia na rynku.

> > Możliwe, ale nie czuję się tym pokrzywdzony a skoro tak, to
> > najwyraźniej nic nie straciłem, że nie widziałem. Poproszę o lepszy
> > argument, niż "niewiele widziałeś".
>
> Poproszę o lepszy argument, niż "nie widziałem".

Ale to nie jest zły argument. Skoro nie widziałem i moi koledzy/koleżanki nie
widzieli w obecnej firmie i w poprzedniej/poprzednich, to przypuszczalnie obserwuję
jakąs regułę albo chociaż coś, co jest obserwacyjnie uzasadnione.

> > Statyczne typowanie ma swój koszt. Pytanie, jaki jest końcowy
> > bilans.
>
> I uważasz, że potrafisz ten bilans policzyć?

Nie, ale oczekuję tego od kogoś, kto mi reklamuje nowe rozwiązanie.

> Poza tym pozostańmy nawet przy heterogeniczności. Dość popularnym
> rozwiązaniem z językami dynamicznymi jest Javascript w przeglądarce i
> jakiś Python czy inny Ruby na serwerze. W celu serializacji obiektów i
> przesyłania ich przez sieć wymyślono format JSON - dzięki niemu można z
> łatwością serializować dane w Pythonie i przesyłać do javascriptowego
> klienta lub odwrotnie. Można to spokojnie robić bez potrzeby
> uzgadaniania definicji typów pomiędzy serwerem a klientem - każda strona
> korzysta z tych właściwości, jakich potrzebuje, i każda jest w stanie
> wziąć odserializowany obiekt i zserializować go z powrotem razem ze
> wszystkimi polami/właściwościami, nawet jeśli nie były one jeszcze
> zdefiniowane w momencie pisania tego kodu.

Tak. Nie mam większych problemów z użyciem C++ w takim systemie, choć zależnie od
użytego rozwiązania w tym jednym konkretnym miejscu składnia dostępu do pola może być
dłuższa.

> BTW można się zastanowić nad faktem, że dynamicznie typowany Erlang jest
> przeznaczony do, i używany w systemach wysokiej niezawodności.

Można. Jak również nad innym faktem, że w wielu systemach wysokiej niezawodności
Erlang nie jest używany.

> Nie jest. Prosty przykład - w C++ nawet niewielka zmiana definicji typu
> danych między biblioteką a programem z niej korzystającym może
> spowodować spektakularne wylecenie wszystkiego w powietrze.

Na moim komputerze kompilator pokaże, gdzie nastąpiła niezgodność.

> > A czy ja gdzieś w tej dyskusji napisałem, że Java jest dla mnie
> > statycznym językiem?
>
> W myśl powszechnie rozumianego podziału na dynamiczne i statyczne
> systemy typów, Java jest językiem o typowaniu statycznym.

class CannotCompare {}

TreeSet<CannotCompare> s = new TreeSet<CannotCompare>(); // 1
s.add(new CannotCompare()); // 2
s.add(new CannotCompare()); // 3

(mniejsza o dokładne nazwy, nie chce mi się tego sprawdzać)

W języku statycznym powyższe nie ma prawa się skompilować. W Adzie wyleci na 1., w
C++ na 2. W Javie kompiluje się radośnie i wylatuje z wyjątkiem dopiero na 3.
Można nawet zrobić unit test, który wykona linijki 1 i 2 i zrobi raport, że jest
dobrze...

W tym przykładzie Java zachowuje się dokładnie jak skryptowy język dynamiczny.
Dodając do tego kulturę, która kieruje programistów w stronę dynamicznego ładowania
klas, opisu ich związków w XML, itd., mamy język, w którym istotnymi elementami są
wyjątki ClassDefNotFound oraz NoSuchFunction.

Jak dla mnie - jeśli coś kwacze jak kaczka, to jest to kaczka.

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

do góry

On Feb 12, 9:19 am, Maciej Sobczak <s...@g...com> wrote:
> W dniu wtorek, 12 lutego 2013 00:19:46 UTC+1 użytkownik Andrzej Jarzabek napisał:
>
> > No to odpowiem: ty nie dałbyś, ale kto inny dał. Tajemnica wyjaśniona?
>
> Nie bardzo. Kiedyś pewien akwizytor do mnie zapukał i chciał mi coś sprzedać
> powołując się na fakt, że mój sąsiad też kupił. Zgadnij, jaki osiągnął sukces.

Jak będę kiedyś chciał ci coś sprzedać, to może się zainteresuję.

> > > Poza tym, że obiektowość powstała z myślą o dużych systemach
> > W którym momencie?
>
> W takim, że w małych nie było powodów, żeby powstała.

Kto konkretnie, kiedy i co takiego zrobił z myślą o dużych systemach?

Bo mi wygląda na to, że opowiadasz o wymyślonej przez siebie historii
OO, a nie tej, która faktycznie miała miejsce.

> > > i sama w sobie nie ma cech, który by były z nimi sprzeczne.
> >http://c2.com/cgi/wiki?ArgumentsAgainstOop
>
> Przewinąłem losowo i trafiłem na argument "OO runs too slow",
[...]
> Przewinąłem losowo i trafiłem na argument "Everything has to be an object".

Poszczególne argumenty odnoszą się do różnych definicji
obiektowości...

> Jeżeli chciałem pokazać, że na absolutnie każdy temat można znaleźć
> w necie stronę zatytułowaną "Why XYZ sucks", to wiem, że można.

Chodzi o to, że różnie można interpretować "cechy sprzeczne".
Technicznie nawet assembler nie posiada cech sprzecznych z dużymi
systemami, skoro istnieją duże systemy napisane w assemblerze.

To czy owo może posiadać cechy przeszkadzające albo pomocne w pisaniu
dużych systemów, ale to kategorie subiektywne - cechy przeszkadzające
komuś lub pomocne dla kogoś.

> > > Jeśli coś ma być inaczej, to ma być po coś i ma się opłacać.
>
> > A dlaczego akurat to dynamiczny, a nie statyczny system typów to jest
> > "inaczej"?
>
> Bo rozmawialiśmy o możliwości wprowadzenia nowego języka w miejscu,
> gdzie używa się czegoś mainstreamowego - w domyśle Javy lub C++.

To nie ta odnoga dyskusji :)

Przy takim pytaniu nie da się przecież odpowiedzieć abstrakcyjnie:
zarówno C++ jak i Java mają swoje ograniczenia, każdy projekt ma swoje
okoliczności. Jeśli np. chcesz mieć UI w przeglądarce, to możesz
zaimplementować go:
* w dynamicznym Javascript
* jako aplikacja flashowa w dynamicznym actionScript czy jak to się
tam nazywa
* jako applet Javowy
* w C++ jako komponent ActiveX

Nie powiesz chyba, że skoro używasz już C++ albo Javy, to rozwiązanie
z tym właśnie językiem jest oczywistym wyborem.

Inny przykład, tym razem z osobistego doświadczenia: miałem rozbudować
możliwości programowania narzędzia testowego napisanego w Javie.
Zdecydowałem się zrobić to przez dodanie DSL-a. Żeby zrobić to szybko,
postanowiłem zaimplementowac embedded DSL i wybrałem do tego język
Groovy, który ma dynamiczny system typów. Z różnych względów Groovy
nadaje się świetnie do osadzania DSL-i w programach Javovwych -
wystarczy zlinkować program z jednym JAR-em, który jest dostępny w
standardowych repozytoriach (my używamy Mavena), poza tym jest
interpretowany i użytkownik może sobie program w DSL-u napisac w pliku
i uruchomić go tym narzędziem testowym - żadna faza kompilacji nie
jest potrzebna. Poza tym ma dynamiczny meta-object protocol jako część
owego dynamicznego systemu typów, przez co świetnie się nadaje do
pisania DSL-i. Pewnie dałoby się mieć język statycznie typowany,
który się równie dobrze, a może nawet lepiej nadaje do pisania DSL-i -
ja wiem o Haskellu, ale nie znam Haskella, a Groovy trochę znam i
nawet mam (kupioną w tym celu) książkę o pisaniu DSL-i w Groovym, poza
tym Haskell nie jest na JVM więc musiałbym wszystko posklejać i
dołączyć kompilator Haskella do projektu. W statycznie typowanej Javie
ani nawet w statycznie typowanej Scali nie dałoby sie zrobić równie
dobrego i wygodnego w użyciu DSL-a.

Czy w takiej sytuacji byś uznał, że wprowadzenie języka dynamicznie
typowanego do projektu w mainstreamowej Javie ma sens?

> Taki był mniej więcej klimat w tym wątku i generalnie takie są realia na rynku.

No bo Pythona czy Ruby to się w ogóle na rynku nie spotyka.

> > > Statyczne typowanie ma swój koszt. Pytanie, jaki jest końcowy
> > > bilans.
> > I uważasz, że potrafisz ten bilans policzyć?
>
> Nie, ale oczekuję tego od kogoś, kto mi reklamuje nowe rozwiązanie.

Na ten temat musisz porozmawiać z tym, co ci reklamuje.

Nawiasem mówiąc, w nawiązaniu do odnogi dyskusji o wprowadzaniu
języków programowania przez programistę, najlepszy sposób uwalenia
dowolnej inicjatywy innowacyjnej to zażądanie przedstawienia bilansu.
Na zasadzie: "postawiliśmy checkboxa dla Scali bo ma lambdy? Proszę o
konkretny dowód na to, że języki z lambdami są mniej błedogenne niż
języki bez lambd".

Wagi przy checkboxach dają dodatkową zabawę "prosze mi pokazać
metodologię, z której wyliczyłeś, że pattern matching ma relatywną
wagę 2.7".

Bo bilans wyciągnięty z odbytu to każdy potrafi pokazać.

do góry

On 12/02/2013 09:19, Maciej Sobczak wrote:
> W dniu wtorek, 12 lutego 2013 00:19:46 UTC+1 użytkownik Andrzej
> Jarzabek napisał:
>
>>> Statyczne typowanie ma swój koszt. Pytanie, jaki jest końcowy
>>> bilans.
>>
>> I uważasz, że potrafisz ten bilans policzyć?
>
> Nie, ale oczekuję tego od kogoś, kto mi reklamuje nowe rozwiązanie.

BTW:
http://www.tcl.tk/doc/scripting.html

do góry

W dniu wtorek, 12 lutego 2013 10:10:02 UTC+1 użytkownik AK napisał:
> Użytkownik "Maciej Sobczak" <s...@g...com> napisał:
> > Poza tym, że obiektowość powstała z myślą o dużych systemach
> :) nie ma to jak urojenia Ayatollahow C++ :)

Kilka lat temu w moich programach ilość klas/obiektów znacząco
zmalała. Gdy jest jakaś wyraźna struktura danych i gdy są
algorytmy które z dużym prawdopodobieństwem będą przydatne tylko
dla tej struktury - to wydzielenie klasy jest jedynie słuszną
drogą.

Jednak w sytuacji gdy mamy wiele klas, np. klasy o nazwach od A do E,
i gdy niektóre algorytmy na wejście biorą kilka z tych klas, to
mam w kodzie golutkie funkcje.

Jakoś mnie wkurzają potem rozterki czy pisać
A.akcja( B , C , D , E)

czy może lepiej:
B.akcja( A , C , D , E)

Zamiast powyższego, zwykle mam w kodzie masę funkcji:
akcja( A , B , C , D , E )

Poza kodem naprawdę zarezerwowanym na potrzeby klas,
wolę styl proceduralny. Jakoś nie lubię robić ze
wszystkiego klasy/obiektu. Czy takie... "pół-proceduralne
programowanie" stanowi dobre podejście do większych
systemów? Dla mnie taki kod jest łatwiejszy w utrzymaniu
od kodu w którym ze wszystkiego zrobiono klasę.


Pozdrawiam

do góry

Użytkownik "M.M." <m...@g...com> napisał:

> > Poza tym, że obiektowość powstała z myślą o dużych systemach
> :) nie ma to jak urojenia Ayatollahow C++ :)

> Kilka lat temu w moich programach ilość klas/obiektów znacząco zmalała.

Alez nie o to chodzi !:).
Chodzi o to, ze OO powstalo w/dla takiej niszy jak "algorytmy sumulacyjne".
To naprawde nie byly duze systemy, a raczej dosc specyficzna dziedzina
na skraju "zwyklej" numeruki i statystyki.
Dla niej (symulacji) tez powstaly tez jedne z pierwszych prob "ustadaryzowania"
wspolbieznosci (czy jak tam nazwac ogolnie pojety "multitasking").
(Mowie oczywiscie o matce OOP czyli Simuli67).

PS: No ale coz.. jesli obecne tu "tuzy C++" twierdza, ze Python ma normalne zmienne,
to coz... (Moze jeszcze w Pythonie __init__() to jest konstruktor, albo
.copy.deepcopy() czy [:] zawsze tworzy nowy obiekt ? mimo ze dokumentacja
tak twierdzi :)

AK

do góry