On Feb 13, 9:10 am, Maciej Sobczak <s...@g...com> wrote:
> W dniu wtorek, 12 lutego 2013 20:14:34 UTC+1 użytkownik Andrzej Jarzabek napisał:
>
> > > > > 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.
>
> Bo ta, która miała miejsce, absolutnie nie dotyczyła dużych systemów,
> tylko systemów sztucznej inteligencji i symulacji? Bo, jak wszyscy wiedzą,
> sztuczna inteligencja i symulacje to malutkie programiki, i właśnie w takim
> kontekście wymyślono OO, żeby te malutkie programiki pisało się jeszcze fajniej?

Krótko: masz mniej więcej dwa etapy wymyślania OO, w uproszczeniu
Simula i Smalltalk. Simula została wymyślona pod kątem symulacji;
symulacje jako takie moga być różnej wielkości systemami,
niekoniecznie dużymi.

Drugi etap to wymyślanie ogólnego paradygmatu programowania na
zasadzie "jak pisać programy, żeby było dobrze" - bez szczególnego
skupiania się ani nad konkretnymi zastosowaniami, ani nad skalą.
Smalltalk był stosowany w biznesie, ale został wymyślony jako język do
celów edukacyjnych - czyli raczej do pisania małych programów.

> > > 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...
>
> Do jakich? Nie napisali a ja nie znam żadnej definicji, do której przykładowe dwa
argumenty by się odnosiły.

To się odnosi do tego, co pisałem powyżej: Simula wprowadziła pewne
cechy języka programowania, które dzisiaj są uważane za
charakterystyczne dla OO, ale nikt wtedy nie mówił o "object oriented
programming". Taka koncepcja została wymyślona później, biorąc to, co
było w Simuli-67 za podstawę i rozwijając to w ogólny paradygmat
programowania.

To, co natomiast jest w popularnym rozumieniu sprzedawane jako OO jest
jakąś tam, zazwyczaj mocno niepełną, adaptacją tej koncepcji. C++
nigdy nie był tworzony jako język OO, jest natomiast bezpośrednio
adaptacją koncepcji z Simuli na grunt języka C. Można w C++ pisać OO w
pierwotnym sensie, i na pewno klasy i dziedziczenie w tym pomagają.

Java pierwotnie miała być językiem w miarę wiernie realizującym tę
koncepcję OO, do której należy również zasada "everything is an
object", ale zdecydowano się złamać między innymi tę zasadę, bo było
"too slow".

Jeśli chodzi o takie OO jak jest w Javie czy C++, to oczywiście
nietrudno znaleźć problemy przeszkadzające w tworzeniu dużych
systemów, dla których "prawdziwe" OO ma dobre rozwiązanie. Na dzień
dobry - kiepskie wsparcie dla współbieżności i związane z tym wyścigi
i problemy z synchronizacją.

> > Technicznie nawet assembler nie posiada cech sprzecznych z dużymi
> > systemami,
>
> Ma, bo przez brak czytelnego wsparcia dla tworzenia abstrakcji nie sprzyja

Nie załapałeś. "Sprzeczne" nie znaczy "nie sprzyja", "sprzeczne"
znaczy obiektywnie uniemożliwia.

Ja rozumiem, że chodziło ci o cechy nie sprzyjające, ale tu właśnie
wychodzi kwestia subiektywności - sprzeczność można uznać za cechę
obiektywną (jeśli coś jest z czymś sprzeczne, to nikt nie da rady).
Sprzyjanie lub nie sprzyjanie jest subiektywne, ale można postulować
intersubiektywny konsensus: assembler nie sprzyja tak w ogóle, bo
prawie każdemu przeszkadza, a ci, którym sprzyja, i tak gorzej (mniej
wydajnie, z większą ilością błędów, z wadami typu brak przenośności)
tworzą w assemblerze niż inni w językach wyższych poziomów.

Podobny konsensus masz w sprawie goto czy nawet powiedzmy w kwestii OO
(choć ta ostatnia jest bardziej kontrowersyjna).

Natomiast w kwestii dynamicznego typowania nie ma takiego konsensusu.
Dynamiczne programowanie ma długą tradycję i przydatne dla wielu ludzi
techniki dla języków takich jak Lisp, Smalltalk, Erlang czy nawet
Python czy Ruby nie są łatwe ani tanie do odtworzenia w językach ze
statycznym systemem typów. Systemów w tych językach powstało i nadal
powstaje sporo i nie ma przekonywaujących dowodów empirycznych na to,
że mają znacząco większe problemy z niezawodnością niż systemy pisane
w C++ czy w Javie.

> > 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.
>
> Nie jest.
> Mogę jedynie ubolewać, że w kategorii "UI w przeglądarce" rynek nie wypracował
> safysfakcjonyjących rozwiązań.

Jest całkiem sporo ludzi, których wystarczająco satysfakcjonuje
Javascript.

> Niektórzy pokładają nadzieje w HTML5, ale to tylko czas pokaże, czy te nadzieje się
spełnią.

HTML5 nadal będzie programowany w Javascripcie.

[...]
> > postanowiłem zaimplementowac embedded DSL i wybrałem do tego język
> > Groovy,
> [...]
>
> Tak, też tego używamy.

No i popatrz, wcale nie musze cie przekonywać do używania języka
dynamicznie typowanego, bo już używacie.

> > 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".
>
> To bardzo dobry argument. Dlatego nie wprowadziłbym Scali dlatego że ma
> lambdy myśląc o mniejszej błędogenności.

No to immutable data czy cokolwiek. Problem oglnie taki, że bardzo
trudno udowodnić takie rzeczy inaczej niż "mnie się tak wydaje".
Dobrych danych empirycznych nie ma, więc nie wiadomo co innego miałoby
być dobrym argumentem. Jeśli można argumentować z autorytetu, to
przecież bez problemu znajdziesz wielu guru którzy twierdzą, że języki
dynamicznie typowane rządzą (i równie wielu, którzy twierdzą dokładnie
przeciwnie).