Dnia Wed, 15 May 2013 11:08:41 -0700 po głębokim namyśle boryspower rzekł:

> Witam,
>
> "Programuję" (raczej bawię się) od około 15 lat w różnych językach, lecz
> wciąż nie mogę się odnaleźć... Tak wiem - głupie to strasznie...
> Chciałbym w końcu zakorzenić się przy jednej technologii i zacząć
> realizować moje pomysły, których mam wiele. Mam nadzieję, iż z Waszym
> doświadczeniem moglibyście mi coś poradzić - pchnąć w odpowiednim
> kierunku.
>
> Zaczynałem od BASICa na Spectrumie, później Pascal, Turbo Pascal, C,
> C++, assembler, Java, Delphi, VHDL, HTML, PHP, Ruby, Free Pascal,
> Python, C#, ostatnio znów trochę Java... [...]
> Co Wy byście mi polecili?

A co chciałbyś w tych językach pisać?

> Ps. Tylko proszę nie mieszajcie mnie z błotem za pytanie na które
> teoretycznie mógłbym odpowiedź wygooglować - uwierzcie mi, że
> szukałem... długo i bezskutecznie szukam a teraz liczę na Was, że pod
> mój konkretny przypadek coś mi doradzicie :)

Myślę, że znając tyle języków z tego kilka dobrze z dowolnym sobie
poradzisz. Ale co z tym odnalezieniem się to nie wiem, może
przestań robić GUI (taka byłaby moja intuicja), albo przynajmniej
spróbuj.

--
Edek

do góry

W dniu piątek, 17 maja 2013 02:37:50 UTC+2 użytkownik A. L. napisał:

> Akurat niekoniecznie. Zalezy do sterowania czego. Jest w koncu
> standard Real Time Java i jakies implementacje...

Tak, to bardzo częsta teoretyczna odpowiedź. Jest *standard* RTJ. Nawet jakieś
implementacje.

A czy ktoś tego użył *w praktyce*? Poważnie pytam. Różne rzeczy do sterowania
widziałem, ale systemu w RTJ jeszcze nie, więc chętnie poznam, zwłaszcza wnioski -
czy platforma spełniła stawiane jej oczekiwania, czy warto było, czy zespół zrobiłby
to jeszcze raz mając wolny wybór, itd.

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

do góry

On 17/05/2013 11:26, Edek wrote:
>
> Nie, nie "to samo". Przykład pierwszy z brzegu:
> mutex1.lock();
> mutex2.lock();
> mutex1.unlock(); // jak to zrobić blokami "synchronized"?

Chodzi o to, że synchronized broni cię przed niektórymi głupotami? To
prawda, myślałem w porównaniu o czymś takim jak scoped locks w C++.

do góry

On 5/17/2013 12:26 PM, Edek wrote:
> Dnia Fri, 17 May 2013 07:33:00 +0100 po głębokim namyśle Andrzej Jarzabek
> rzekł:
>
>> On 17/05/2013 01:46, A.L. wrote:
>>> On Thu, 16 May 2013 06:47:09 +0100, Andrzej Jarzabek
>>> <a...@g...com> wrote:
>>>
>>>> variables. Teoretycznie wbudowane w język synchronized i notify trochę
>>>> upraszaczają pisanie programów,
>>>
>>> Dlaczego "teoretycznie"?...
>>
>> Może nie najszczęśliwiej dobrane słowo. Chodzi o to, że to to samo, co
>> mutex i condition variable. Główny problem z użyciem tych konstruktów
>> jest poprawny projekt, a w tym temacie synchronized/notify nie pomaga.
>
> Nie, nie "to samo". Przykład pierwszy z brzegu:
> mutex1.lock();
> mutex2.lock();
> mutex1.unlock(); // jak to zrobić blokami "synchronized"?
>
Idealny przyklad kodu ktory jest kandydatem do deadlocku.


Pozdrawiam

Marek

do góry

On Fri, 17 May 2013 07:33:00 +0100, Andrzej Jarzabek
<a...@g...com> wrote:

>On 17/05/2013 01:46, A.L. wrote:
>> On Thu, 16 May 2013 06:47:09 +0100, Andrzej Jarzabek
>> <a...@g...com> wrote:
>>
>>> variables. Teoretycznie wbudowane w język synchronized i notify trochę
>>> upraszaczają pisanie programów,
>>
>> Dlaczego "teoretycznie"?...
>
>Może nie najszczęśliwiej dobrane słowo. Chodzi o to, że to to samo, co
>mutex i condition variable. Główny problem z użyciem tych konstruktów
>jest poprawny projekt, a w tym temacie synchronized/notify nie pomaga.

Niestety, nie rozumiem.

Mozna prosic o szczegoly?...

A.L.

do góry

Dnia Fri, 17 May 2013 23:38:32 +0200 po głębokim namyśle Marek Borowski
rzekł:

> On 5/17/2013 12:26 PM, Edek wrote:
>> Dnia Fri, 17 May 2013 07:33:00 +0100 po głębokim namyśle Andrzej
>> Jarzabek rzekł:

>>> Może nie najszczęśliwiej dobrane słowo. Chodzi o to, że to to samo, co
>>> mutex i condition variable. Główny problem z użyciem tych konstruktów
>>> jest poprawny projekt, a w tym temacie synchronized/notify nie pomaga.
>>
>> Nie, nie "to samo". Przykład pierwszy z brzegu:
>> mutex1.lock();
>> mutex2.lock();
>> mutex1.unlock(); // jak to zrobić blokami "synchronized"?
>>
> Idealny przyklad kodu ktory jest kandydatem do deadlocku.

Tak samo, jak używanie new jest kandydatem do wycieku pamięci.

Powyższe to zwykły Pattern - używa się go wtedy, kiedy dla przykładu
pierwszy mutex chroni zmiany strukturalne kolekcji a drugi element
kolekcji. Często nie można trzymać locka na całej kolekcji podczas
operacji tylko na jednym elemencie, a jednocześnie mieć możliwość
usuwania i dodawania elementów co się robi trzymając pierwszy lock
(i przy każdej operacji pobierającej element).

Jak unikać tego typu deadlocków wymyślił już Dijsktra (i znam
parę osób w tym siebie, które same na to wpadły), rozwiązanie
jest trywialnie proste.

Tak przy okazji - nie wiem co jest w programie studiów dzisiaj.
Rozumiem, że są drzewka, sortowania itd., a powyższego nie ma?

--
Edek

do góry

Dnia Fri, 17 May 2013 22:13:53 +0100 po głębokim namyśle Andrzej Jarzabek
rzekł:

> On 17/05/2013 11:26, Edek wrote:
>>
>> Nie, nie "to samo". Przykład pierwszy z brzegu: mutex1.lock();
>> mutex2.lock();
>> mutex1.unlock(); // jak to zrobić blokami "synchronized"?
>
> Chodzi o to, że synchronized broni cię przed niektórymi głupotami? To
> prawda, myślałem w porównaniu o czymś takim jak scoped locks w C++.

Jakimi głupotami? Tu "chroni" przed zupełnie naturalnym użyciem. Fakt,
że przy dowolnym wyjściu z bloku (wyjątek?) działa jak scoped lock,
to nawet fajnie - ktoś kto nie zna podstaw pisania kodu wątkowego
zrobi mniej błędów. Co nie znaczy, że w Javie się nie potnie paroma
innymi cechami, przed którymi język już nie chroni.

--
Edek

do góry

W dniu piątek, 17 maja 2013 02:35:50 UTC+2 użytkownik A. L. napisał:
> On Wed, 15 May 2013 23:29:02 -0700 (PDT), boryspower
>
> boryspower wrote:
>
>
>
> Troche zaczynasz "od konca". Na ogol jest tak ze sie chce cos zrobic i
>
> szukasz najlepszego narzedzia. Ty studiujesz narzedzia dla narzedzi,
>
> nie majac jasnej koncepcji co chcesz zrobic.
>
>

Wiem co chcę robić... Myślałem, że widać po moich "wymaganiach", iż nastawiam się
raczej na tworzenie aplikacji GUI niż np pisanie gier...


> Jezyki programowania to narzedzie i "lepszosc" jednych wzgledem
>
> drugich da sie ocenic tylko w kontekscie problemu do ktorego sa
>
> uzywane.

Oczywiście - dlatego starałem się opisać na czym mi konkretnie zależy a nie pytałem w
stylu "który lepszy". W dodatku myślę, że moje dotychczasowe doświadczenie może
również mieć wpływ na Wasze rady, więc w skrócie opisałem co dotychczas robiłem...

>
> Przy okazji: nasz miszmasz terminologiczny. JEZYK PROGRAMOWANIA to
>
> jesyk. Do tego dochodzi kompilator. Programy oisze sie w odpowiednim
>
> srodowisku wspierajacym edytowanie tekstu programu i korzysta z
>
> bibliotek. Ty zas wrzucasz wszystko do jednego worka, twierdzac ze
>
> "kolorowanie sytnaksu" jest czescia "jezyka programowania".

W żadnym wypadku nie wrzucam wszystkiego do jednego worka - pisałem o języku
programowania/technologii, gdzie przez "technologię" rozumiem również wszelkie
narzędzia/edytory/biblioteki umożliwiające/ułatwiające programowanie w danym języku.
Tak naprawdę sam język programowania, bez całej tej "narzędziowej" otoczki byłby
użyteczny jak łyżka zamiast wiosła - coś tam by się dało zrobić, ale nie tyle ile
przy użyciu odpowiednich narzędzi.


>
> Wiec nei jest jasne czego szukasz. Jezyka, kompilatoar, edytora,
>
> bibliotek czy czegos innego. Bo to moga byc zupelnie osobne
>
> poszukiwania
>

Wszystkiego razem.... nie obrażę się, jeśli ktoś przedstawi swoje argumenty bym zajął
się C++'em korzystając z QT, a ktoś inny przekonywałby mnie do C++'a z wykorzystaniem
.NETa i VS.

>
> P.S> Jakbys naciskal klawisz ENTER od czasu do czasu to twoje posty
>
> byloby latwiej czytac.

Ps. Przydałaby Ci się jakiś edytor z podkreślaniem błędów - strasznie wiele ich
robisz :)

--
Pozdrawiam!
Przemek

do góry

W dniu 2013-05-16 10:38, wloochacz pisze:
> W dniu 2013-05-16 10:14, boryspower pisze:
>> Hmm... Delphi wygląda/zapowiada się interesująco... tylko jedną z
>> rzeczy o których zapomniałem wspomnieć jest, że przydałaby się
>> technologia nie wymagająca dużych nakładów finansowych... takie Delphi
>> to jednak 4200 EURO...
> http://www.embarcadero.com/products/delphi/starter
> Cena to 199 EUR z licencją komercyjną.

4. Prosta obsługa baz danych (minimum MySQL i jakieś bazy lokalne a'la
SQLite)

Delphi Starter Edition is a great way to get started building
high-performance applications for Windows without database connectivity.

Czy to ja czegoś nie zrozumiałem?

Pozdrawiam
Piotr

do góry

On 18/05/2013 02:34, A.L. wrote:
> On Fri, 17 May 2013 07:33:00 +0100, Andrzej Jarzabek
>>
>> Może nie najszczęśliwiej dobrane słowo. Chodzi o to, że to to samo, co
>> mutex i condition variable. Główny problem z użyciem tych konstruktów
>> jest poprawny projekt, a w tym temacie synchronized/notify nie pomaga.
>
> Niestety, nie rozumiem.
> Mozna prosic o szczegoly?...

Po pierwsze, fakt istnienia w Javie synchronized i notify nie chroni
przed problemami z wątkami. I tak trzeba wiedzieć, które obiekty są
dostępne z wielu wątków i trzeba sobie zaprojektować co ma być
synchronized, w jaki sposób wątki się powiadamiają i tak dalej.

Ponadto - co prawda użycie synchronized i notify eliminuje część
możliwych kombinacji z mutexami i condition variables (ale nadal beez
gwarancji, że takie nie wystąpią, bo jawne mutexy też przecież w Jaie
są), to wiedząc jak działają, ten sam efekt można w innych językach
łatwo (przynajmniej w C++ łatwo) uzyskać przy pomocy mutex i condition
variable. Szczegółowo mam opisać jakbym taki odpowiednik zaimplementował
w C++, czy nie ma takiej potrzeby?

Z tego co przeczytałem zresztą, to wygląda jakby C# oferował tę samą
funkcjonalność przez klasę Monitor, polecenie lock i anotację
[MethodImpl(MethodImplOptions.Synchronized)]. Mimo to OP przy wymaganiu
o łatwej obsłudzę wątków wymienia swoje problemy z C# właśnie.

do góry