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

> One tym bardziej nie działają, bo w ogóle nie mają mechanizmów zapewniania
spójności.

Bardzo prosze nie pie^Hsać totalnych głupot !.
Jezyki dynamiczne maja takie mechanizmy.
O wiele bardziej rozbudowane niż badziewne pod tym względem C++
i o wiele ogolniejsze.

AK

do góry

On 15/02/2013 15:46, Maciej Sobczak wrote:
> W dniu piątek, 15 lutego 2013 12:29:02 UTC+1 użytkownik Andrzej
> Jarzabek napisał:
>
>> Na Adzie się nie znam, ale czy nie jest przypadkiem tak, że do
>> wielu aplikacji biznesowych byłaby słabym wyborem ze względu na
>> brak bibliotek i narzędzi właśnie?
>
> Ja znam ludzi, którzy tego używają w systemach bankowych, więc może
> nie jest tak źle.

Nie mam pojęcia jak jest naprawdę, ale niekoniecznie z tego, że takich
znasz, coś wynika. Może po prostu użytkownicy Ady są nadreprezentowani
wśród twoich znajomych? Ja mam jakiś przekrój czego sie używa w
instytucjach finansowych i firmach produkujących oprogramowanie dla
nich i wiem, czego się mniej więcej używa. Java, C++, C#, Python, Tcl,
nawet spotkałem się z F# i Fortranem, ale z Adą nigdy. Oczywiście nie
wykluczam, że gdzieśtam jakiś system napisany w Adzie jest, ale to też
nie wyklucza możliwości, że mimo wszystkich swoich zalet Ada jest złym
wyborem dla 99.99% zastosowań, gorszym np. od Pythona.

>> Ale jeśli przez to, że wybiorę inny język może nie być zepsute, to
>> po co w ogóle mam naprawiać?
>
> Co nie jest zepsute? ClassDefNotFound i NoSuchFunction nie są
> zepsute?

Nie jest zepsuty system który w takiej sytuacji po prostu działa tak,
jak powinien, mimo że jeden z jego komponentów został wymieniony bez
zmieniania pozostałych.

>>> I bardzo dobrze. To jest zaleta statycznego systemu.
>> Że się program wywali?
>
> Że się nie skompiluje przy normalnym wykorzystaniu.

Z mojej praktyki z C++ wynika, że korzystanie z bibliotek, które były
kompilowane oddzielnie od głównego programu, w tym dynamiczne
linkowanie, jest czymś całkowicie normalnym.

>>> Jeżeli dynamiczne techniki nie działają a statyczne działają, to
>>> jaki z tego wniosek w kontekście tytułu tego wątku?
>>
>> Skoro programy komputerowe często nie działają, to może zamiast
>> komputerów lepiej używać znacznie bardziej niezawodnych
>> pięściaków?
>
> Możesz tak zrobić. Ja natomiast spróbuję wybrać taki język, który
> działa lepiej, niż gorzej.

No ale pięściak działa jeszcze lepiej.

>> Akurat rozmawiamy o tym, czy Java jest językiem statycznie czy
>> dynamicznie typowanym. Umówmy sie może w takim razie, że
>> konstrukcja pozwalająca na niebezpieczne rzutowania nie
>> dyskwalifikuje języka z bycia statycznie typowanym.
>
> Dobrze, umówmy się tak.
>
> 1. Pytanie było o wybór między językami statycznymi a dynamicznymi.
> 2. Zauważyłeś, że jak się używa dynamicznych ficzerów, to program
> może nie działać.
>
> Mój wniosek z tej dyskusji (jak też przed nią) jest taki, że im mniej
> dynamicznych elementów w programie, tym łatwiej o poprawny program.

Program napisany w języku dynamicznym w takiej samej sytuacji może działać.

>>> Tak. Jeżeli dynamiczne ficzery prowadzą do programów, które nie
>>> działają, to est to argument przeciwko dynamicznym ficzerom.
>> Każdy język, który jest Turing-complete ma dynamiczne ficzery,
>> które nie działają.
>
> Więc ich nie używajmy. Ja napisałem parę programów bez używania tych
> ficzerów.

A ja napisałem program "Hello World", który działał. Tylko że nie radzę
nikomu, żeby zamiast pisać swoje programy, które czasem nie działają,
pisali Hello World, który zadziała na pewno.

> Czy może chcesz napisać, że im bardziej jakiś języki jest dynamiczny,
> tym bardziej jest "Turing-complete"? Coś jakby synonim na "cool" dla
> geeków?

Powinieneś wiedzieć, że Turing-complete się nie stopniuje.

>>> UB. Język wyraźnie mówi, że nie wolno tego static cast zrobić.
>>> Kompilator nie nadąża, więc może język jest za mało statyczny?
>>
>> Jak napisałem, chodziło o sytuację, kiedy B dziedziczy po A.
>
> A ja nadal będę pisał, że to jest UB i standard to wyraźnie określa.

Ale nie da się tego statycznie sprawdzić.

> Nie wolno takiego rzutu zrobić, nawet jeśli język nie określa tego
> jako błąd statyczny. Coś jak dzielenie przez 0.

No i luzik, przecież języki dynamiczne też mają różne sytuacje, gdzie
specyfikacja mówi, że operacja nie zadziała i np. rzuci wyjątkiem.

> I wniosek mam konsekwentny: weźmy język, który będzie jeszcze
> bardziej statyczny. Bo język, który będzie jeszcze bardziej
> dynamiczny sprawi nam jeszcze więcej problemów.

Lepiej wziąć język, w którym co prawda jakichś tam błędów unikniesz, ale
programu robiącego to, co ma robić też nie napiszesz?

> W tym momencie muszę przeprosić: wyjeżdżam na parę dni i nie będę
> miał dostępu do sieci. Nie będę mógł więc kontynuować tej dyskusji,
> chociaż jestem pewny, że ona powróci, bo na tej grupie jest
> zjawiskiem powtarzalnym.

Życzę miłego wyjazdu w takim razie, na pewno wątek będzie dalej wisiał
na serwerze jak wrócisz :)

do góry

Dnia Fri, 15 Feb 2013 00:08:08 +0000, Andrzej Jarzabek wyszeptal:

>> Ja nadal nie widzę w OO niczego, co by miało mieć problem ze
>> współbieżnością.
>
> No przecież właśnie cały model, gdzie możesz mieć równolegle działający
> kod który ma dostęp do tego samego zmiennego stanu jest tym problemem.
> No chyba że powiesz, że w rzeczywistości w dużych systemach napisanych w
> językach wspierających OO błędy polegające na data races, deadlocks,
> livelocks i tym podobnych atrakcjach nie są poważnym problemem, bo
> zdarzają się niezmiernie rzadko, a jak już się zdarzą, to są łatwe do
> zdiagnozowania, znalezienia i poprawienia.

Dzięki za link na c2.com. Nigdy nie wpadłem wcześniej na taki pomysł,
żeby czytać tam o czymś takim podstawowym jak OO, a jednak warto.

Ja powiem:
> w rzeczywistości w dużych systemach napisanych w
> językach wspierających OO błędy polegające na data races, deadlocks,
> livelocks i tym podobnych atrakcjach nie są poważnym problemem, bo
> zdarzają się niezmiernie rzadko, a jak już się zdarzą, to są łatwe do
> zdiagnozowania, znalezienia i poprawienia.

W tej dyskusji padło wiele ciekawych twierdzeń, m.in. o typach w Javie.
Główną różnicą pomiędzy definicjami teoretycznymi (Java: taki a taki
system typów) i "OO ma problemy z współbieżnością" a praktyką jest
dokładnie to, co opisane jest na c2.com: teoria języka to jedno, praktyka
używania języka to drugie. Po kolei.

Ani Java ani taki Go nic nie wnoszą do teorii języków programowania.
Nie taki jest ich cel. Mają zmienić praktykę. Ja nawet nie widzę
sensu w zastanawianiu się, czy Java ma statyczny silny system typów - ok,
może, nie dotyczy kolekcji, kto dzisiaj używa kolekcji? - bo liczy się
praktyka pisania w tym języku. Mówiąc "OO is too slow" nikt nie ma
na myśli faktycznie że OO is too slow, tylko że taki bywa argument
przeciwko OO - praktycznie pojawia się tylko wtedy, gdy liczą się
pojedyncze procenty wydajności. Znowu argument taki że "OO is too slow"
na podstawie Javy ma jedną wadę: to nie wina OO tylko Javy, która
wiele zasad łamie po to, żeby była użyteczna. Podobnie w Javie było
z współbieżnością: do czasu Memory Model (jsr-133 chyba) NIE DAŁÓ
SIĘ pisać programów współbieżnych w Javie, które używałyby większość
cech języka i mogły być poprawne. Jednak programy współbieżne w Javie
okazały się praktycznie istotne i zmienił się Memory Model - kolejna
zmiana złamanych zasad w Javie podyktowana praktyką. Praktyką,
która wskazała na to, że chociaż większość programistów nawet
nie słyszało o Memory Model a pisze w Javie, to jednocześnie są
tacy, którzy potrzebują rozwiązania podstawowych trywialnych problemów
ze współbieżnością, a język tego nie umożliwia.

OO ma problemy z współbieżnością w tym sensie, że problemy ze
współbieżnością istnieją w programach OO, plus kilka argumentów
o związkach pomiędzy współbieżnością a praktyką OO (na c2.com),
m.in. takim,
że stos ywołań w obiektach połączony z więcej niż jednym lockiem
bywa trudny do analizy. Taka jest praktyka OO (Java, C++), że
wielu programistów źle projektuje programy współbieżne. Natomiast
jest znacząca różnica pomiędzy "w X nie da się Y" i "praktycznie
w X często jest źle z Y". "OO powoduje problemy z współbieżnością"
= false, "Java przed memory model nie pozwalała pisać poprawnych
współbieżnych" = true (chyba że ktoś potrafił omijać problemy
starego modelu pamięci, albo akceptował sporadyczne błędy).

Wracając do cytatu o systemach i ich problemach ze współbieżnością
oraz do linka do c2.com: przyczyny problemów ze współbieżnością
są głównie kognitywne (na ArgumentsAgainstOop wymieniona jest
cała lista kognitywnych argumentów, m.in. to, że mapowanie domeny
na typy jest strukturą poznawczą z wstępnych książek, która
ułatwia zrozumienie OO, ale prawdziwa to ona nie jest poza
relacyjnym mapowaniem - a w OO pisze się wiele innych rzeczy też.
Jak ktoś zna kraj, gdzie rośnie sobie AVLTree, rozważę wycieczkę.
Chciałbym zobaczyć, jak to drzewko wygląda ;).

Problemy ze współbieżnością biorą się najczęściej stąd, że
programiści mają wyrobiony (w nature-vs-nurture byłoby to nurture)
mechanizm, że kod wykonuje się linijka po linijce. Dodatkowo
często brakuje po prostu wiedzy na ten temat. Stąd pojęcie
o tym że w drugiej linijce zmienna i może mieć wartość 1 LUB 2 bywa
trudny do ogarnięcia:
i = 1
print i # jak to: nie 1 ?!
... a tak bywa w programach współbieżnych, piszący kod lub
szukający błędu często tego nie widzi - z przyczyn kognitywnych,
konkretnie zwykłego przyzwyczajenia.

Wracając do dużych systemów i problemów ze współbieżnością:
po pierwsze się DA, po drugie jest to szukanie błędów takie jak
każde inne (inne techniki, zasada ta sama) - jeżeli program jest usiany
błędami, to faktycznie poprawienie "buga" (czyli sterty bugów
i złego projektu) zajmuje trochę czasu. Znalezie źródła zwykłego
pojedynczego problemu zajmuje z grubsza tyle co każdego innego.
Pisanie dużych systemów bez większych problemów ze współbieżnością
to też żadna kosmiczna technologia.

No to się rozpisałem. Mi się nóż otwiera w kieszeni czasami
jak słyszę dyskusję o typach w Javie czy takie demonizowanie
współbieżności, i to przy okazji całkiem rozsądnego cytatu ze strony,
gdzie analizuje się "czy i ewentualnie dlaczego". Ale nie przerywam
dyskusji.

--
Edek

do góry

Dnia Fri, 15 Feb 2013 06:34:58 -0800 (PST), firr kenobi napisał(a):

>> szczerze mowiac nie mam wiekszego poojecia
>> ak to by mialo wygladac w wykonaniu obiektowym

W ten desen:

http://docs.oracle.com/cd/E21764_01/doc.1111/e15866/
img/design_uml11.gif

>> zakladanie i pilnowane tej siatki jest meczace itd

Niekoniecznie, mozna ja na noc zwinac i schowac.

ps. o siatke to wiecej pogadasz na grupie pl.rec.sport.siatkowka

--
pozdro
R.e.m.e.K

do góry

On 2013-02-13 14:56, Piotr Chamera wrote:
> W dniu 2013-02-13 14:00, Michal Kleczek pisze:
>> On 2013-02-10 22:36, Maciej Sobczak wrote:
>>>
>>> Jak do tej pory jedyny code reuse między różnymi typami widywałem w
>>> kontenerach i ten reuse polegał na tym, że można coś skopiować albo
>>> porównać albo wyliczyć hash, itd. Do tego niepotrzebne są języki
>>> dynamiczne. Innym przykładem może być np. serializacja, ale ponieważ
>>> temat serializacji pojawia się w systemach rozproszonych, które
>>> zwykle są heterogeniczne, to i tutaj mało mnie interesuje, co mi ma
>>> do zaoferowania jakiś jeden język, bo zwykle co by nie miał, to i tak
>>> nie rozwiązuje to problemu heterogeniczności.
>>
>> W tym mysleniu jest pulapka, bo nie da sie zintegrowac (pod)systemow bez
>> _jednego_ wspolnego jezyka.
> To chyba nie jest prawda, wystarczy odpowiedni protokół komunikacyjny
> (to też jest rodzaj języka, ale nie o takim kontekście chyba mówimy).

No ja wlasnie mowie o tym kontekscie, bo protokol musisz opisac
formalnie, zeby sensownie dalo sie go uzywac w roznych jezykach.

--
Michal

do góry

W dniu 2013-02-17 19:06, Michal Kleczek pisze:
> On 2013-02-13 14:56, Piotr Chamera wrote:
>> W dniu 2013-02-13 14:00, Michal Kleczek pisze:
>>> On 2013-02-10 22:36, Maciej Sobczak wrote:
>>>>
>>>> Jak do tej pory jedyny code reuse między różnymi typami widywałem w
>>>> kontenerach i ten reuse polegał na tym, że można coś skopiować albo
>>>> porównać albo wyliczyć hash, itd. Do tego niepotrzebne są języki
>>>> dynamiczne. Innym przykładem może być np. serializacja, ale ponieważ
>>>> temat serializacji pojawia się w systemach rozproszonych, które
>>>> zwykle są heterogeniczne, to i tutaj mało mnie interesuje, co mi ma
>>>> do zaoferowania jakiś jeden język, bo zwykle co by nie miał, to i tak
>>>> nie rozwiązuje to problemu heterogeniczności.
>>>
>>> W tym mysleniu jest pulapka, bo nie da sie zintegrowac (pod)systemow bez
>>> _jednego_ wspolnego jezyka.
>> To chyba nie jest prawda, wystarczy odpowiedni protokół komunikacyjny
>> (to też jest rodzaj języka, ale nie o takim kontekście chyba mówimy).
>
> No ja wlasnie mowie o tym kontekscie, bo protokol musisz opisac
> formalnie, zeby sensownie dalo sie go uzywac w roznych jezykach.

OK. Więc między każdą parą podsystemów musimy mieć protokół (język),
który jest rozumiany przez oba podsystemy, ale nie znaczy to, że
wszystkie podsystemy w systemie muszą się komunikować w ten sam sposób...

do góry

On 2013-02-17 22:00, Piotr Chamera wrote:
> W dniu 2013-02-17 19:06, Michal Kleczek pisze:
>> On 2013-02-13 14:56, Piotr Chamera wrote:
>>> W dniu 2013-02-13 14:00, Michal Kleczek pisze:
>>>>
>>>> W tym mysleniu jest pulapka, bo nie da sie zintegrowac (pod)systemow
>>>> bez
>>>> _jednego_ wspolnego jezyka.
>>> To chyba nie jest prawda, wystarczy odpowiedni protokół komunikacyjny
>>> (to też jest rodzaj języka, ale nie o takim kontekście chyba mówimy).
>>
>> No ja wlasnie mowie o tym kontekscie, bo protokol musisz opisac
>> formalnie, zeby sensownie dalo sie go uzywac w roznych jezykach.
>
> OK. Więc między każdą parą podsystemów musimy mieć protokół (język),
> który jest rozumiany przez oba podsystemy, ale nie znaczy to, że
> wszystkie podsystemy w systemie muszą się komunikować w ten sam sposób...
>

To teoria... W praktyce za chwile jest juz taki mlyn (czy bardziej
fachowo "spagetti"), ze pojawia sie inicjatywa "EAI" albo "SOA/ESB". I
wracamy do punktu wyjscia: mamy jeden jezyk - tym razem to jezyk ESB.

--
Michal

do góry

Użytkownik "Michal Kleczek" <m...@k...org> napisał:

> To teoria... W praktyce za chwile jest juz taki mlyn (czy bardziej fachowo
"spagetti"),

Jaki mlyn ? Jakie spagetti ?
Na palcach zaledwie jednej reki mozna policzyc dojrzale
wieloplatformowo/wielojezykowe
komponentowe technologie softwareowe.
1. CORBA (dosc ulomna w sesnie wielojezykowosci/latwosci uzytowania, b.dobra
w sensie wydajnosci).
2. COM/DCOM/ActiveX - bardzo dojrzala
3. .NET - jeszcze bardziej dojrzala

AK

do góry

On 2013-02-19 10:44, AK wrote:
> Użytkownik "Michal Kleczek" <m...@k...org> napisał:
>
>> To teoria... W praktyce za chwile jest juz taki mlyn (czy bardziej
>> fachowo "spagetti"),
>
> Jaki mlyn ? Jakie spagetti ?
> Na palcach zaledwie jednej reki mozna policzyc dojrzale
> wieloplatformowo/wielojezykowe
> komponentowe technologie softwareowe.
> 1. CORBA (dosc ulomna w sesnie wielojezykowosci/latwosci uzytowania,
> b.dobra
> w sensie wydajnosci).
> 2. COM/DCOM/ActiveX - bardzo dojrzala
> 3. .NET - jeszcze bardziej dojrzala
>

Kazda z powyzszych wprowadza ten jeden wspolny jezyk, o ktorym wlasnie
pisalem.

--
Michal

do góry

W dniu 2013-02-19 09:39, Michal Kleczek pisze:
> On 2013-02-17 22:00, Piotr Chamera wrote:
>> W dniu 2013-02-17 19:06, Michal Kleczek pisze:
>>> On 2013-02-13 14:56, Piotr Chamera wrote:
>>>> W dniu 2013-02-13 14:00, Michal Kleczek pisze:
>>>>>
>>>>> W tym mysleniu jest pulapka, bo nie da sie zintegrowac (pod)systemow
>>>>> bez
>>>>> _jednego_ wspolnego jezyka.
>>>> To chyba nie jest prawda, wystarczy odpowiedni protokół komunikacyjny
>>>> (to też jest rodzaj języka, ale nie o takim kontekście chyba mówimy).
>>>
>>> No ja wlasnie mowie o tym kontekscie, bo protokol musisz opisac
>>> formalnie, zeby sensownie dalo sie go uzywac w roznych jezykach.
>>
>> OK. Więc między każdą parą podsystemów musimy mieć protokół (język),
>> który jest rozumiany przez oba podsystemy, ale nie znaczy to, że
>> wszystkie podsystemy w systemie muszą się komunikować w ten sam sposób...
>>
>
> To teoria... W praktyce za chwile jest juz taki mlyn (czy bardziej
> fachowo "spagetti"), ze pojawia sie inicjatywa "EAI" albo "SOA/ESB". I
> wracamy do punktu wyjscia: mamy jeden jezyk - tym razem to jezyk ESB.

Pisałeś: "nie da sie zintegrowac (pod)systemow bez _jednego_ wspolnego
języka", teraz piszesz, że w teorii się da, ale praktyka jest inna...
Ciekaw jestem z jakimi systemami (w jakiej dziedzinie zastosowań)
pracujesz, że tak to widzisz? Czy taka integracja rzeczywiście coś daje,
czy to tylko dobrze brzmiący marketing?

Ja odnoszę wrażenie, że jest wręcz odwrotnie - chciałoby się stworzyć
coś, co obsłuży całą komunikację w złożonym systemie, ale w praktyce
nie bardzo wychodzi...

Weźmy za przykład jakiś serwis internetowy: interfejs użytkownika [IU]
(w przeglądarce) gada z aplikacją [AP] po stronie serwera przez HTML,
JSON itp, aplikacja z bazami danych [BD] przez SQL, ODBC itp., bazy
danych replikują dane między sobą za pomocą własnych protokołów,
aplikacje zarządzające treścią [AZT] łączą się z [AP] np. przez SOAP
itd.

A teraz jak by to wyglądało z ESB (gdybam, bo się nie znam, jestem
tylko po pobieżnej lekturze strony na wikipedii
http://en.wikipedia.org/wiki/Enterprise_service_bus)
:
[IU] gada z ESB przez HTML i JSON, warstwa ESB konwertuje to np.
na .NET i przekazuje do [AP], [AP] śle zapytanie do ESB, które
konwertuje je do ODBC lub SQL i przekazuje do [BD], itd...
Mamy warstwę pośrednią, dzięki której komponent nie musi znać języka,
w którym komunikuje się jego rozmówca po drugiej stronie ESB, ale nadal
każdy gada do ESB w takim języku, jaki mu najlepiej pasuje, bo nie da
się użyć tego samego protokołu do komunikacji z przeglądarką
internetową, monitorowania dostępności aplikacji, replikacji bazy
danych...

do góry