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

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

Ale z Toba napewno warto dyskutowac (tylko k.. czas nie pozwala:(.
Wyczywam pewna szczerosc (czyli zmieniam poprzednio wyrazone zdanie/przypuszczenie)
w ogolnie pojetych "poszukiwaniach", a to duzy i rzadki atut.

AK

do góry

W dniu wtorek, 12 lutego 2013 23:32:17 UTC+1 użytkownik AK napisał:
> Ale z Toba napewno warto dyskutowac (tylko k.. czas nie pozwala:(.
Mam to samo.


> Wyczywam pewna szczerosc (czyli zmieniam poprzednio wyrazone
> zdanie/przypuszczenie)
> w ogolnie pojetych "poszukiwaniach", a to duzy i rzadki atut.
Generalnie gdy wklepuję dużo kodu, który to kod w 95% przypadków
jest kodem trywialnym, to szczerze poszukuję wszystkiego coby
mogło mi ułatwić życie. Może właśnie czas na jakiś język
z typowaniem dynamicznym...

Pozdrawiam

do góry

On Mon, 11 Feb 2013 23:36:38 +0000, 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.
Miałem
> ostatnio "przyjemność" dłubać coś w VBA i on ma raczej taki
mieszany
> system typów.

Nie pisze sie w "VBA" tylko w "VB for Excel". I to jest kluczowa
roznica - te makra sa tak popularne nie ze względu na system typów,
tylko ze względu na ścisłą integrację z Excelem. Sam popełniłem taki
arkusz dla tradera, ale numeryka byla napisana w C++ i ladowana jako
addin.

RW

do góry

On Tue, 12 Feb 2013 07:41:12 +0000 (UTC), g...@s...invalid (Adam
Wysocki) wrote:
> Czasem przez security. Nie jest łatwo przeforsować możliwość
uruchomienia
> exeka w niektórych bankach.

Ale za to mozna arkusz z makrami? ;-)

RW

do góry

On 13/02/2013 00:02, Roman W wrote:
>
> Nie pisze sie w "VBA" tylko w "VB for Excel".

O to mi chodziło.

> I to jest kluczowa roznica
> - te makra sa tak popularne nie ze względu na system typów, tylko ze
> względu na ścisłą integrację z Excelem.

Chodziło mi o to: może C++ i Java też nie są popularne ze względu na
system typów.

> Sam popełniłem taki arkusz dla
> tradera, ale numeryka byla napisana w C++ i ladowana jako addin.

BTW może się mylę bo to nie moja działka zupełnie, ale wydaje mi się, że
się też niekiedy używa Matlaba do numeryki?

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ł:
>
>> 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,
[...]
> 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.

Chodzi o to, że użyjesz kontenerów asocjacyjnych? Większe problemy masz
takie:
* używasz dwóch konstrukcji językowych (struct/class lub hashtable) do
tego samego celu - musisz za każdym razem wybrać.
* jeśli wybierzesz struct/class bo myślisz, że nie będziesz musiał
serializować/deserializować, to masz problem
* dla hashtable jako obiektów nie masz dobrego wsparcia w języku:
konstrukcja, wołanie metod (w tym wirtualnych), w przypadku kiedy
elementem hashtable jest wskaźnik na inny hashtable ownership semantics
są niejasne itd.
* jeśli konsekwentnie stosujesz hashtable zamiast struct/class, to
właśnie implementujesz dynamiczne typowanie w języku statycznie
typowanym - tracisz type safety, a ze względu na poprzedni punkt jest to
zakładanie prawego buta na lewą nogę.

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

Bym powiedział, że to raczej niewiele wnosi.

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

Naprawdę? Jak nowa wersja execa spróbuje załadować starą DLL-kę? Czy
może statycznie wykryje możliwość takiego wydarzenia i napisze "WARNING:
za tydzieeń twój użytkownik w Pernambuco spróbuje użyć programu, który
właśnie skompilowałeś ze starą DLL-ką. Skontaktuj się z nim pod numerem ..."

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

Bzdura. Język statycznie typowany może w ogóle nie mieć generyków. W
języku statycznie typowanym możesz mieć nawet:

TreeSet s = new TreeSet();
s.add(new CannotCompare());
[...]

Jeśli do tak statycznie typowanego języka dodasz składnię
TreeSet<CostamCostam> s, gdzie 'CostamCostam' ma rolę wyłącznie
dekoracyjną, powiedzmy jest rodzajem komentarza, to nadal jest to język
statycznie typowany. Jeśli w kolejnych krokach dajesz dodatkowe
obostrzenia na tego tokena sprawdzane w czasie kompilacji (1: musi być
to nazwa klasy, 2: ...), to w którym momencie ze statycznego typowania
przechodzisz w dynamiczne?

> W tym przykładzie Java zachowuje się dokładnie jak skryptowy język
> dynamiczny.

int i=3;
i=5;

W tym momencie C++ zachowuje się dokładnie jak skryptowy język
dynamiczny. Zatem jest językiem dynamicznym.

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

Kaczka kwakałaby tak:
Object s = new TreeSet();
s.add(new Whatever());

Dodatkowo od dynamicznego języka wymagałbym możliwości stworzenia
obiektu, który nie należy do żadnej klasy i którego zestaw metod
rozstrzygany jest w runtime - np. łączysz się z bazą danych, bierzesz
tabelę o danej nazwie, sprawdzasz jakie ma kolumny i tworzysz obiekt
reprezentujący rekord z getterami i setterami dla każdej kolumny.

do góry

On Wed, 13 Feb 2013 04:37:07 +0000, Andrzej Jarzabek
<a...@g...com> wrote:
> BTW może się mylę bo to nie moja działka zupełnie, ale wydaje mi
się, że
> się też niekiedy używa Matlaba do numeryki?

Rzadziej.

RW

do góry

Roman W <b...@g...pl> wrote:

>> Czasem przez security. Nie jest łatwo przeforsować możliwość
>> uruchomienia exeka w niektórych bankach.
>
> Ale za to mozna arkusz z makrami? ;-)

Można. Nie pytaj dlaczego :) Przesłanki, którymi kierują się działy
IT w takich bankach, są często niejasne :)

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

do góry

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?

W sumie - znowu nie rozwijamy dyskusji, więc nie będę się sprzeczał.

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

Do jakich? Nie napisali a ja nie znam żadnej definicji, do której przykładowe dwa
argumenty by się odnosiły.

> Technicznie nawet assembler nie posiada cech sprzecznych z dużymi
> systemami,

Ma, bo przez brak czytelnego wsparcia dla tworzenia abstrakcji nie sprzyja tworzeniu
projektów, które można łatwo rozwijać w długiej perspektywie a oprócz abstrakcji w
długiej perspektywie i przy dużych rozmiarach pojawia się też temat przenośności, w
czym asembler nie błyszczy. To są powody techniczne.

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

Niech będzie, że wszystko co napisałem, jest subiektywne.

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

Nie jest.
Mogę jedynie ubolewać, że w kategorii "UI w przeglądarce" rynek nie wypracował
safysfakcjonyjących rozwiązań. Niektórzy pokładają nadzieje w HTML5, ale to tylko
czas pokaże, czy te nadzieje się spełnią.

> 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,
[...]

Tak, też tego używamy.

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

Może mieć sens. Podobnie jak w samym kontekście mógłby mieć sens np. JPython. Albo co
tam komu lepiej leży w ręku.

Przecież nie napisałem, że języki dynamiczne powinny być zakazane.

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

To bardzo dobry argument. Dlatego nie wprowadziłbym Scali dlatego że ma lambdy myśląc
o mniejszej błędogenności.

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

Owszem. Ale ja naprawdę chcę wiedzieć, dlaczego będzie lepiej.
Bo jeśli nie wiem, to będzie to na zasadzie "spróbujmy" - i to też jest bardzo dobra
zasada, podobna np. do kupowania na pałę akcji losowych firm na giełdzie. Są tacy, co
tak robią i bywa nawet, że na tym zyskują. Kluczowym hasłem jest to zarządzanie
ryzykiem - im więcej wiem, tym łatwiej jest tym ryzykiem zarządzać.

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

do góry

W dniu środa, 13 lutego 2013 06:31:15 UTC+1 użytkownik Andrzej Jarzabek napisał:

> Chodzi o to, że użyjesz kontenerów asocjacyjnych?

Będzie to jakiś słownik.

> Większe problemy masz
> takie:
>
> * używasz dwóch konstrukcji językowych (struct/class lub hashtable) do
> tego samego celu

To nie jest ten sam cel - obiekty istniejące na granicy modułów (podobnie na granicy
z DB) to inne cele i w tych miejscach jestem gotowy na inne konwencje.

> >> 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ść.
>
> Naprawdę? Jak nowa wersja execa spróbuje załadować starą DLL-kę?

Nie wierzę, że sobie takiego gola strzelasz.
DLL-ki nie są częścią C++ a ich wsparcie to trick ze strony systemu operacyjnego.
Jeżeli wychodzisz poza język po to, żeby nie korzystać z jego zalet, to nie miej
pretensji, że coś nie działa.
DLL-ki to właśnie metoda na dynamiczność w programie. Czy sugerujesz, że języki
statyczne są do dupy, bo jak się je omija i używa dynamicznych tricków, to nie
działają dobrze?
No, nie działają.

> > class CannotCompare {}
>
> > TreeSet s = new TreeSet(); // 1
> > s.add(new CannotCompare()); // 2 s.add(new CannotCompare()); // 3
>
> > W języku statycznym powyższe nie ma prawa się skompilować. W Adzie
>
> Bzdura. Język statycznie typowany może w ogóle nie mieć generyków.

Tym bardziej się nie skompiluje... :-p

> W
> języku statycznie typowanym możesz mieć nawet:
>
> TreeSet s = new TreeSet();
> s.add(new CannotCompare());
>
> [...]

To nie jest język statycznie typowany, nawet jeśli tak ma napisane na pudełku.

> > W tym przykładzie Java zachowuje się dokładnie jak skryptowy język
> > dynamiczny.
>
> int i=3;
> i=5;
>
> W tym momencie C++ zachowuje się dokładnie jak skryptowy język
> dynamiczny. Zatem jest językiem dynamicznym.

Nie. Nie mógłbyś zrobić i="x"; Zatem słaby argument.

> Dodatkowo od dynamicznego języka wymagałbym

Ale ja nie twierdzę, że Java ma wszystkie cechy takich języków.
Natomiast od języka statycznego wymagam, żeby kod, który nie może się poprawnie
wykonać ze względu na *nieistnienie jakiejś funkcji*, która na pewno będzie zawołana,
się nie kompilował. Java tego wymagania nie spełnia.

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

do góry