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