W dniu 2011-03-13 02:02, Andrzej Jarzabek pisze:
> On 12/03/2011 23:49, Wit Jakuczun wrote:
>> W dniu 2011-03-13 00:46, Andrzej Jarzabek pisze:
>>>> > To co w takiej sytuacji byłoby zgodne ze zdrowym
>>>> > rozsądkiem?
>>>> Oddać cesarzowi co cesarskie, czyli kawałek funkcyjny napisać
>>>> w języku funkcyjnym. Albo kawałek programowania
>>>> w logice w języku, który to wspiera, np. w prologu.
>>>
>>> To by było dopiero sprzeczne ze zdrowym rozsądkiem. Samo przeniesienie
>>> danych wymagałoby o wiele więcej wysiłku, niż zakodowanie tego w C++.
>> Zakodowanie czego?
>
> Kawałka funkcjonalności, który napisałem w stylu funkcyjnym, bo kaurat
> tak było najwygodniej/najbardziej elegancko/najbezpieczniej/najczytelniej.
Jak napisałem Sebastianowi, moje doświadczenia są zgoły inne.

Pozdrawiam,
Wit

do góry

Wit Jakuczun wrote:

> W dniu 2011-03-13 11:53, Sebastian Biały pisze:
>> On 2011-03-12 23:48, Wit Jakuczun wrote:
>>> Oddać cesarzowi co cesarskie, czyli kawałek funkcyjny napisać w języku
>>> funkcyjnym. Albo kawałek programowania w logice w języku, który to
>>> wspiera, np. w prologu.
>>
>> Jedyna nadzieja w .NET które ma pewną wartwę wspólną danych. Ale jesli
>> nie masz takiej gwarancji i musisz budować interfejsy komunikacyjne to
>> serdecznie współczuje wyboru, szczególnie ze problemy funkcyjne sa na
>> tyle małe że mozna je spokojnie embedowac w języku zamiast pisać 10x
>> większy kod do wymiany danych.
> Kod do wymiany jest bardzo prosty. Ale fakt, F# wydaje się ciekawy.
> Tylko, że mi kompletnie nieprzydatny by był.
>
> A kawałek pisałem w Prologu i napisanie go w .Net byłoby raczej mało
> sensowne. To nie był mały kawałek.
>
> Są też inne zalety takiego rozdzielenia. Na przykład koncepcyjnie od
> początku mam możliwość liczenia rozproszonego.

Czy projekt jako całość miał integratorów, czy może Ty jako (współ)twórca
systemu to integrowałeś?
Interesuje mnie to o tyle, bo ze swojego doświadczenia widzę, że ludzie nie
dostrzegają pracy, którą czasem trzeba włożyć w integrację. Ja jako że
zajmuję się zarówno programowaniem, jak i integracją, często "utrudniam"
sobie jako programista, aby ułatwić sobie jako integratorowi, dzięki czemu
suma pracy jest mniejsza. Programistów nie dotykających integracji nie
sposób do tego przekonać, bo dla nich problem przeniesiony z programisty na
integratora jest problemem rozwiązanym (nawet jeśli przez to przeniesienie
problem jest powiększony).

do góry

Sebastian Biały wrote:

>>> c) nieprzenosny
>> Tak samo jak i C/C++/C$ z VS jeśli odwołuje się do zasobów specyficznych
>> dla systemu operacyjnego. Nie rób tego w Delphi i też będzie przenosny.
>
> Delphi jest nieprzenośny z definicji. C/C++ z głupoty.

Co jest głupiego w stosowaniu funkcjonalności specyficznej dla systemu
operacyjnego? Po to są różne systemy operacyjne, aby korzystać z tego, który
w danym zastosowaniu jest użyteczny.
Przykładowo, znasz może metodę na przenośne napisanie "atomowego" zapisu do
pliku? Czegoś co na POSIX-owych systemach można zrealizować następująco:
zapisanie do plik.txt.new, rename("plik.txt.new", "plik.txt").

do góry

W dniu 2011-03-13 12:33, Wojciech Jaczewski pisze:
> Wit Jakuczun wrote:
>
>> W dniu 2011-03-13 11:53, Sebastian Biały pisze:
>>> On 2011-03-12 23:48, Wit Jakuczun wrote:
>>>> Oddać cesarzowi co cesarskie, czyli kawałek funkcyjny napisać w języku
>>>> funkcyjnym. Albo kawałek programowania w logice w języku, który to
>>>> wspiera, np. w prologu.
>>>
>>> Jedyna nadzieja w .NET które ma pewną wartwę wspólną danych. Ale jesli
>>> nie masz takiej gwarancji i musisz budować interfejsy komunikacyjne to
>>> serdecznie współczuje wyboru, szczególnie ze problemy funkcyjne sa na
>>> tyle małe że mozna je spokojnie embedowac w języku zamiast pisać 10x
>>> większy kod do wymiany danych.
>> Kod do wymiany jest bardzo prosty. Ale fakt, F# wydaje się ciekawy.
>> Tylko, że mi kompletnie nieprzydatny by był.
>>
>> A kawałek pisałem w Prologu i napisanie go w .Net byłoby raczej mało
>> sensowne. To nie był mały kawałek.
>>
>> Są też inne zalety takiego rozdzielenia. Na przykład koncepcyjnie od
>> początku mam możliwość liczenia rozproszonego.
>
> Czy projekt jako całość miał integratorów, czy może Ty jako (współ)twórca
> systemu to integrowałeś?
Interfejsy dla użytkowników są w postaci webservice (albo dll, albo
jar). W zależności od technologii. Część projektów była robiona współnie
z większym zespołem a w części dostarczaliśmy nasze moduły jako produkt
do użycia.

Wewnętrznie zrobiona integracja (między kodem w Prologu a kodem w
Javie/C#/C++) była trywialna.

Mam nadzieję, że wyjaśniłem wystarczająco jasno jak to robiliśmy. Jeśli
interesuje Cię to dokładniej to odezwij się na priv.

Pozdrawiam,
Wit

do góry

On 2011-03-13 12:09, Wit Jakuczun wrote:
>> tyle małe że mozna je spokojnie embedowac w języku zamiast pisać 10x
>> większy kod do wymiany danych.
> Kod do wymiany jest bardzo prosty.

Jeśli wymieniasz PODy.

> A kawałek pisałem w Prologu i napisanie go w .Net byłoby raczej mało
> sensowne. To nie był mały kawałek.

Pisanie kawalka kodu w Prologu jest na tyle specyficzne że nie wchodzi w
tematyke wątku. Ja raczej nie widzę potrzeby uzywania *osobnego* języka
do napisania funkcji komparującej do sortowania w C++. Na tyle osobnego
ze nalezy pisać interfejsy komunikacyjne, serializacje i kupę śmieci
zamiast użyć pokracznego ale ładnie działającego "emulatora fukcyjnego"
na boost::whatever.

Jeśli zaś mówisz o systemach rozproszonych to podejście projektowe jest
na tyle inne że nie ma jak dyskutowac o nim w kontekście dydaktyki
pierwszego roku programowania.

Na duzych systemach nie pozwoliłbym sobie na opinie o lepszości C++ nad
resztą świata z powodu jakiejś pierodły boost::phoenix bo to oczywista
bzdura.

> Są też inne zalety takiego rozdzielenia. Na przykład koncepcyjnie od
> początku mam możliwość liczenia rozproszonego.

Ona nie wynika tylko z takiego rozdzielenia.

do góry

On 2011-03-13 12:45, Wojciech Jaczewski wrote:
>>> Tak samo jak i C/C++/C$ z VS jeśli odwołuje się do zasobów specyficznych
>>> dla systemu operacyjnego. Nie rób tego w Delphi i też będzie przenosny.
>> Delphi jest nieprzenośny z definicji. C/C++ z głupoty.
> Co jest głupiego w stosowaniu funkcjonalności specyficznej dla systemu
> operacyjnego?

Nic. O ile mądrze to zaprojektujesz chowając je za abstrakcją. Jesli
natomiast jesteś głupi i powciskasz wszedzie np MFC w logikę biznesową
to nic nie uratuje takiej aplikacji. C++ można spieprzyć. Pascal jest
spieprzony z definicji, a darmowe kompilatory (przenosne) sa praktycznie
nie stosowane przemysłowo więc trudno mowić o przenoszeniu.

> Po to są różne systemy operacyjne, aby korzystać z tego, który
> w danym zastosowaniu jest użyteczny.

Co za piękna teoria ;) Sprawdza się niestety tylko dla aplikacji o
któtkim czasie życia.

> Przykładowo, znasz może metodę na przenośne napisanie "atomowego" zapisu do
> pliku? Czegoś co na POSIX-owych systemach można zrealizować następująco:
> zapisanie do plik.txt.new, rename("plik.txt.new", "plik.txt").

Po co potrzebujesz taki ficzer?

do góry

W dniu 2011-03-12 17:32, Sebastian Biały pisze:

>
> Nie. To wygląda inaczej: "Heniek, poszukaj na necie jakiegoś quick sorta
> do pascala". "ok". "O k.... nie działa, ale gówno, napiszmy bąbelkowo i
> h...". Algorytm był inny ale cytat autentyczny z całkiem sporej firmy
> robiącej całkiem spore rzeczy. I dotyczył kryptografii.

Ci sami programiści w c++. 'Heniek, ale to można zrobić
znacznie szybciej, trzeba tylko lekko wzbogacić drzewko.'
'... ale w STL nie widzę takiego gotowca.'
'trudno, googlać mi się nie chce, robimy jak było,
komputery szybkie są.'


:-)

pozdrawiam
bartekltg

do góry

On Sun, 13 Mar 2011 08:02:51 +0100, "Waldek M."
<w...@l...localdomain> wrote:

>Dnia Sat, 12 Mar 2011 18:53:22 +0100, Sebastian Biały napisał(a):
>
>> On 2011-03-12 18:02, slawek wrote:
>>>> To akurat katastrofa w rękach studenta ;)
>>> Nie pytałem o studenta. Pytałem: czy jest to w Delphi?
>>
>> Nie ma wielobazowego dziedziczenia. W Javie też. To raczej lepiej niż
>> gorzej. Dziedziczenie z definicji jest żadko potrzebne, a jeszcze
>> wielobazowe ...
>
>E? Dziedziczenie jest z definicji *rzadko* potrzebne?
>A co to za definicja?
>
>Waldek

Niektorzy programuja tylko przy pomocy interfejsos i nazywaja to
"obiektowoscia"

.L.

do góry

Sebastian Biały wrote:

>> Po to są różne systemy operacyjne, aby korzystać z tego, który
>> w danym zastosowaniu jest użyteczny.
>
> Co za piękna teoria ;) Sprawdza się niestety tylko dla aplikacji o
> któtkim czasie życia.

Albo o długim, ale po prostu uwiązanych do danej klasy systemów, gdyż
robienie tego przenośnie znacznie zwiększyłoby złożoność projektu.

>> Przykładowo, znasz może metodę na przenośne napisanie "atomowego" zapisu
>> do pliku? Czegoś co na POSIX-owych systemach można zrealizować
>> następująco: zapisanie do plik.txt.new, rename("plik.txt.new",
>> "plik.txt").
>
> Po co potrzebujesz taki ficzer?

Zapisuję stan programu X w pliku. W różnych okolicznościach program (lub
skrypt powłoki) Y potrzebuje odczytać ten stan. Nie przeszkadza mu, jeśli
jest on sprzed np. 10ms, natomiast przeszkadza mu jeśli w ogóle nie da się
go w danym momencie odczytać, bo akurat plik jest zapisany w połowie.
Oczywiście znam polecane przez większość programistów podejście: baza
danych. Tylko po co mam stosować rozwiązanie bardziej skomplikowane, skoro
mam prosty atomowy zapis do pliku i mogę z niego skorzystać.

do góry

On Sun, 13 Mar 2011 11:56:05 +0100, Sebastian Biały
<h...@p...onet.pl> wrote:

>On 2011-03-13 00:09, A.L. wrote:
>>>> Nie, drogi Kolego. Jakies 40 lat temu w dziedzinie makroporcesorow
>>>> robiono rzeczy takie o ktorych makrogeneratorowi C++ zwanemu
>>>> "templates" nawet sie nie sni.
>>> Generatory kodu we wszelakiej postaci mocno odbiegają od tematu wątku.
>>> Ale tak, stosuje sporadycznie. Zaryzykuje że sa słabo związane z
>>> konkretnym językiem.
>> Makro a generatory kodu to dwie zupelnei inne rzeczy
>
>Możesz wyjasnić różnice? Na jakimś prostym przykładzie.

Nie chce mi sie

A.L.

do góry