Dnia Tue, 14 Dec 2010 21:37:51 +0100, Yarael Poof napisał(a):

> Szukam teraz czegoś, co by spełniało następujące wymagania.
> a) było w miarę tanie
> b) nie jest to główny cel ale licencja pozwalała na ewentualną sprzedaż
> c) tworzyło aplikacje pod windows XP/vista/7 bez jakiś gigantycznych
> runtimeów (.NET niewskazany, no ale w ostateczności...).
> d) najważniejsze - pozwalało na łatwą obsługę multimediów, z naciskiem
> na strumień wideo, DirectShow (webcamy i inne takie) lub stosowanie
> gotowych VLC.

Moze Real Basic?

http://www.realsoftware.com/realstudio/compare.php

Niedrogi, basic - wiec powinien byc dosc latwy, klikany interfejs,
multiplatformowy - kompilat dziala na Windows, Linux i MacOS!, nowoczesny
wyglad i stale rozwijany, pozwala budowac aplikacje webowe.
Nie wiem jak z multimediami, bo nie znam tego srodowiska z autopsji, ale
warto sprawdzic, bo moze byc ciekawie.

Looknij: http://www.realsoftware.com/movies/intro_video_full.
php
--
pozdrawiam
Norbert

do góry

On Dec 16, 3:45 pm, Mariusz Kruk <M...@e...eu.org> wrote:

> >Nie popadajmy w skrajność. Można być przyjaznym dla maszyny nie będąc
> >jednocześnie aż tak niskopoziomowym.
>
> Nie można. Każda forma niebędąca kodem maszynowym jest nieprzyjazna
> i musi być tłumaczona na postać wynikową.

Przyjazność dla maszyny to właśnie miara łatwości tego tłumaczenia.
Niektóre języki są wysokopoziomowe zachowując jednocześnie prostotę i
intuicyjność translacji. Zwłaszcza te imperatywne. Niestety o językach
funkcjonalnych nie można tego powiedzieć.

Kiedyś widziałem dość krótki artykuł, w którym autor zastanawiał się
nad Haskellem. Była tam funkcja sortująca, bodajże quicksort w dwóch
(!) linijkach. Zapis ścinał z nóg. Gorzej z wydajnością. Okazało się,
że ten zajefajny zapis ma się nijak to tego, co się dzieje w pamięci i
co robi CPU.

> Funkcjonalna może być kurtka z pierdyliardem kieszeni.

Czyli tak jak w każdym innym języku. Nie widzę powodu, dla którego
polski ma się tu wyróżniać i wytyczać jakieś nowe szlaki.

> Nie róbmy na siłę kalki z angielskiego.

Nie rób se jaj. Po pierwsze, w tej branży kalki to najlepsze co można
zrobić, przynajmniej jest zgodnie ze wszystkimi innymi kalkami. Po
drugie, "funkcyjny", jak rozumiem, absolutnie żadną kalką nie jest,
tak? Niby w czym kalka "funkcyjny" jest lepsza od kalki
"funkcjonalny"?

> >> Funkcjonalne języki, w przeciwieństwie do języków niefunkcjonalnych
> >> (Brainf*ck anyone?) dają jednak jakieś możliwości.
> >Jakie?
>
> Skoro niektóre są funkcjonalne, to inne muszą być niefunkcjonalne.

No sam widzisz, że nie bardzo jest co wymieniać. I właśnie dlatego
jestem sceptykiem - po obdarciu tego tematu z histerii i trendu,
niewiele zostaje.

> >Ponownie to samo pytanie: dlaczego nie wygrały tych zawodów o T1000?
> >Może jednak nie dają tych możliwości, co wszyscy myślą, że dają?
>
> Odpowiem pytaniem na pytanie - dlaczego w tym roku w F1 wygrał człowiek
> z nazwiskiem zaczynającym się na "V"? Może jednak inne litery nie dają
> takich możliwości?

Słabe.

Powtórzę: języki funkcjonalne nie wnoszą niczego (w szczególności
żadnego "paradygmatu"), co fundamentalnie przyczyniłoby się do
efektywności w systemach współbieżnych, względem istniejących technik.
A przynajmniej ja niczego takiego nie widzę.

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

do góry

On Dec 16, 12:40 pm, Andrzej Jarzabek <a...@g...com>
wrote:

> > > Żaden język programowania nie odzwierciedla tego, jak myśli człowiek.
>
> > Zgadza się. Ale wtedy dobrze by było, żeby był chociaż przyjazdy dla
> > maszyny.

> Nie zgadzam się. SQL jest mainstreamowy na ten przykład.

Bo będąc 4GL jest bardziej zrozumiały dla człowieka (widziałem kiedyś
tutorial dla sekretarek, zresztą MS Access swoją popularność skądś
wziął). C++ i Java są mainstreamowe, bo odzwierciedlają sposób
działania komputera. Co najmniej jeden z tych dwóch warunków musi być
spełniony, żeby był mainstream.

> >http://www.adaic.org/news/perfcont.html
>
> > Pytanie: dlaczego?

> Bo w tym przypadku dłubane rozwiązanie było na bardzo konkretna
> maszynę z konkretnym systemem operacyjnym, gdzie wszystkie
> charakterystyki są dokładnie znane, [...]

Zgadza się.

> W przypadku znacznie większych programów komercyjnych, [...]

No właśnie - teraz pojawia się pytanie, czy języki funkcjonalne, ze
swoją specyficzną idiomatyką są odpowiednie do takich systemów.

Zauważ też, że obecnie w takich systemach współbieżność jest zwykle
zarządzana nie przez programistę, tylko przez jakiś framework. Czy to
centralny broker, czy to serwer aplikacyjny, czy jeszcze coś -
wszystko jedno. To znaczy, że zarządzanie wielowątkowością, przydział
zadań, itd. są robione niejawnie i poza głównym kodem. I bardzo
dobrze, ale jednocześnie jest to cecha, którą niby chcemy uzyskać w
nowych językach. Tylko że to żaden postęp, bo to już dawno jest.

> Problem jest w tej chwili taki, i to jest druga połowa odpowiedzi na
> Twoje pytanie, że ten język jeszcze nie istnieje. Ale pracuje się nad
> tym i wiadomo, że takie wymagania znacznie łatwiej mozna spełnić
> językiem funkcyjnym lub zbliżonym, niż językiem imperatywnym.

Dlaczego?

Hint: są języki imperatywne, które współbieżność mają wbudowaną w
swoją konstrukcję. Pytanie jest o to, czego ciekawego nie można nimi
uzyskać a co przyniosą nam nowe języki.

> Wnoszą tyle, że można napisać jeden program i patrzeć jak się skaluje.
> Imperatywnie i na jawnych wątkaach można teoretycznie zrobić tak samo
> albo nawet lepiej, ale będzie to oznaczało kupę pracy programistów,
> wielokrotne przepisywanie kodu, trudne do namierzenia bugi itd.

To spory skok myślowy. Nie widzę powodu, dla którego miałoby tak być.
Automatycznie skalujące się pule wątków to nawet w Javie są - a to
jest język imperatywny.

> > Fajny ten Wasz management. Naprawdę. :-)
>
> To jest doświadczenie z kilku różnych managementów, plus w różny
> sposób zdobywana wiedza jakie się stosuje rozwiązania również tam,
> gdzie osobiście nie pracowałem. Na ile się orientuję, nie jest to
> jakieś bardzo niezwykłe.

Ja niestety mam inne doświadczenia. Częściej byłem świadkiem
wyrównywania walcem. Chyba niektórzy wierzą, że łatwiej się zarządza,
gdy wszyscy pracownicy umieją i robią to samo.

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

do góry

On Dec 16, 1:17 pm, A.L. <l...@a...com> wrote:

> A jak idzie o jezyk Ada i jego wsparcie dla wspolbieznosci, to keidys
> zdarzylo mi sie wspolpracowac z firma 8888 gdzie uzywano Ady, ale tak
> zwanego "bezpiecznego podzbioru". Ten podzbior wykluczal Adowe "taski"
> ze wzgledu na niepzrewidywalnosc ich wykonywania pod wzgledem
> czasowym.

To musiało być bardzo "kiedyś". Bo dzisiaj te "taski" wykorzystuje się
właśnie dzięki ich przewidywalności.

http://en.wikipedia.org/wiki/Ravenscar_profile

> Gdy procesory beda mialy 64 jadra, nie da sie ich programwoac w C++
> czy Jave. Ani nawet w Adzie. Potzrebny jest nowy paradygmat.

To bardzo odważne twierdzenie. Michoo już odpisał, jak to wygląda, nie
będę powtarzał.

> >Takie przykładowo współbieżne systemy bazodanowe istniały od tzw.
> >"zawsze", więc to nie jest tak, żę języki funkcjonalne otwierają
> >jakieś nowe nieznane wcześniej możliwości.
>
> Ales Kolego, nikt i nigdzie nie mowi ze jezyki funkcyjne maja byc
> zastosowane w bazach danych

No właśnie. Skoro nie były a działa, to najwyraźniej nie muszą. A
ponieważ serwer baz danych to dość wszechstronny i rozbudowany
wewnętrznie system, to nie widzę, dlaczego te języki mają nagle
opanować świat. Skoro nie są potrzebne w serwerach baz danych, to być
może nigdzie nie są.
To też odważne twierdzenie, ale przynajmniej oparte na istniejącej
praktyce.

> Jak idzie o zastosowania haskela, to lista jest tutaj:
>
> http://www.haskell.org/haskellwiki/Haskell_in_indust
ry
>
> Troche dluzsza niz ta od Ady

Do dupy ta lista, bo sama narzuca się z kontrargumentami.
Np. jest wpis dla Google'a:

"Haskell is used on a small number of internal projects in Google, for
internal IT infrastructure support."

Jednocześnie wiadomo, że Google *NIE* użył Haskella do swojego
algorytmu MapReduce, który to algorytm jest dla nich absolutnie
fundamentalny i który zdobył dla nich ten rynek dzięki wydajności.
Uważaj: MapReduce został napisany w C++. Oops.
Google w ogóle nie użył Haskella w żadnym swoim serwisie.

I teraz pytanie rozrywkowe: ponieważ Google jest uważany za autorytet
w branży, to które zdanie jest ciekawsze:

1. Google użył Haskella.
2. Google *NIE* użył Haskella.

?

> Zas wracajac do meritum: Jakie jest doswiadczenie Kolego z jezykamu
> funkcyjnymi ze wydaje takie stanowcze opinie?... Czy to na podstawie
> "hands on" czy tez teoretycznej wszechwiedzy?...

To nie jest meritum, bo to jest Twoja kolejna proba zdyskredytowania
kogoś na forum. Meritum byłoby gdybyś zapytał jakie jest moje
doświadczenie w tworzeniu złożonych i wydajnych systemów *BEZ* użycia
języków funkcjonalnych. Wbrew pozorom te dwa pytania nie są
równoważne, analogicznie do powyższych o Google'u.

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

do góry

> Ale pytanie czy potrzebujesz aż czegoś takiego? Może prościej jest
> zainwestować w Flash'a lub SilverLight'a?

do flash/flex są też darmowe narzędzia

> Do flash'a masz tanie np. Swish MAX. Funkcjonalnie jest toto zbliżone do
> MMB.

http://sourceforge.net/projects/silex/ - wygląda na bardziej uniwersalny
wyklikiwacz stron/aplikacji

FlashDevelop to darmowe IDE współpracujące z darmowym kompilatorem

na pewno nie będzie problemu z kamerą, mikrofonem itp., do tego
desktopowe środowisko AIR

do góry

W dniu 15-12-2010 19:04, Przemysław Osmański pisze:

> Ale pytanie czy potrzebujesz aż czegoś takiego? Może prościej jest
> zainwestować w Flash'a lub SilverLight'a?
> Do flash'a masz tanie np. Swish MAX. Funkcjonalnie jest toto zbliżone do
> MMB.
>
> Wszystko zależy do czego te MMB używałeś.
>
> Weź pod uwagę to, że ani Delphi ani VB VC# nie mają łatwej i
> bezproblemowej obsługi multimediów, webcamów itd itp.
>

Mam SwishMaxa, ostatnio zupgradowałem się do wersji 4. Gdyby chodziło
tylko o jakieś animacje i mrygadełka to bym w ogóle nie zawracał głowy,
ale nie ma tak lekko.
Muszę mieć obsługę strumienia wideo. Jak mówiłem, mam specyficzne hobby
i kiedyś w Multimedia Builderze zrobiłem sobie takie coś:
http://efix.pl/efixmo/geneza-i-cechy.html

Oczywiście sam MMB nie ma takich możliwości i ktoś napisał mi po prostu
bibliotekę które robiła prawie wszystko to, co chciałem.
Niestety programista wymiękł, MMB przestał istnieć a ja bym chciał
udoskonalić swoją zabawkę.
Gdyby się przemógł do jakiegoś expressa i zdoła to opanować, to może
korzystając wprost z SDK od DirectShow (w co wątpię...) albo z gotowych
rozwiązań takich jak to: http://www.mitov.com/html/videolab.html

Ale zobaczę jeszcze RealBasic i Dark.

Maciek

do góry

epsilon$ while read LINE; do echo \>"$LINE"; done < "Maciej Sobczak"
>> >Nie popadajmy w skrajność. Można być przyjaznym dla maszyny nie będąc
>> >jednocześnie aż tak niskopoziomowym.
>> Nie można. Każda forma niebędąca kodem maszynowym jest nieprzyjazna
>> i musi być tłumaczona na postać wynikową.
>Przyjazność dla maszyny to właśnie miara łatwości tego tłumaczenia.
>Niektóre języki są wysokopoziomowe zachowując jednocześnie prostotę i
>intuicyjność translacji. Zwłaszcza te imperatywne. Niestety o językach
>funkcjonalnych nie można tego powiedzieć.

OK. Każdy język jest nieprzyjazny. Jeden może bardziej, inny mniej, ale
to średnio dobry argument. Kwestia "dobroci" kompilatora.

>Kiedyś widziałem dość krótki artykuł, w którym autor zastanawiał się
>nad Haskellem. Była tam funkcja sortująca, bodajże quicksort w dwóch
>(!) linijkach. Zapis ścinał z nóg. Gorzej z wydajnością. Okazało się,
>że ten zajefajny zapis ma się nijak to tego, co się dzieje w pamięci i
>co robi CPU.

Trochę mi się przypomina argumentacja przeciwko programowaniu
obiektowemu podpierana tym, jak to pięknie można w asemblerze
przyoszczędzić kilkanaście bajtów.
W pewnych warunkach to faktycznie może mieć znaczenie. Ale w wielu
innych nie będzie miało takiego, jak to, że piszemy szybko i w miarę
bezbłędnie.

>> Nie róbmy na siłę kalki z angielskiego.
>Nie rób se jaj.

Nie robię sobie jaj. Lóknij przez łindoł na korner czy kar jeszcze stoi.

>Po pierwsze, w tej branży kalki to najlepsze co można
>zrobić, przynajmniej jest zgodnie ze wszystkimi innymi kalkami.

No właśnie niekoniecznie i nie zawsze.

>Po
>drugie, "funkcyjny", jak rozumiem, absolutnie żadną kalką nie jest,
>tak?

Owszem, nie jest.

>Niby w czym kalka "funkcyjny" jest lepsza od kalki
>"funkcjonalny"?

http://sjp.pwn.pl/slownik/2460400/funkcyjny_I
http://sjp.pwn.pl/slownik/2558726/funkcjonalny

>> >> Funkcjonalne języki, w przeciwieństwie do języków niefunkcjonalnych
>> >> (Brainf*ck anyone?) dają jednak jakieś możliwości.
>> >Jakie?
>> Skoro niektóre są funkcjonalne, to inne muszą być niefunkcjonalne.
>No sam widzisz, że nie bardzo jest co wymieniać.

Oczywiście, że jest. Choćby większość (wszystkie?) ezoteryczne są
niefunkcjonalne. Bo i nie po to były tworzone.

>> >Ponownie to samo pytanie: dlaczego nie wygrały tych zawodów o T1000?
>> >Może jednak nie dają tych możliwości, co wszyscy myślą, że dają?
>> Odpowiem pytaniem na pytanie - dlaczego w tym roku w F1 wygrał człowiek
>> z nazwiskiem zaczynającym się na "V"? Może jednak inne litery nie dają
>> takich możliwości?
>Słabe.

Owszem. Twoje pytanie było słabe. Nie dość, że usiłowałeś generalizować
z pojedynczego przypadku, to jeszcze usiłujesz przekształcić korelację
w implikację. Większe błędy logiczne ciężko byłoby popełnić.

>Powtórzę: języki funkcjonalne nie wnoszą niczego (w szczególności
>żadnego "paradygmatu"), co fundamentalnie przyczyniłoby się do
>efektywności w systemach współbieżnych, względem istniejących technik.

Ę? Jak nie, jak tak? Weźmy w szczególności ten haskell i quicksort
(i nie przypierniczaj mi się do wydajności konretnego kompilatora,
bo to rzecz wtórna).
#v+
quicksort [] = []
quicksort (s:xs) = quicksort [x|x <- xs,x < s] ++ [s] ++ quicksort [x|x <- xs,x >= s]

#v-
W sposób oczywisty widać, że kolejne wywołania rekurencyjne mają szansę w sposób
naturalny zostać zrównoleglone. Napisz to teraz w C pilnując ręcznie
wszystkiego, czego trzeba pilnować.

--
Kruk@ -\ |
}-> epsilon.eu.org |
http:// -/ |
|

do góry

W dniu 2010-12-17 00:15, Yarael Poof pisze:

> Muszę mieć obsługę strumienia wideo. Jak mówiłem, mam specyficzne hobby
> i kiedyś w Multimedia Builderze zrobiłem sobie takie coś:
> http://efix.pl/efixmo/geneza-i-cechy.html

Bardzo ciekawe :)

> Gdyby się przemógł do jakiegoś expressa i zdoła to opanować, to może
> korzystając wprost z SDK od DirectShow (w co wątpię...) albo z gotowych
> rozwiązań takich jak to: http://www.mitov.com/html/videolab.html

IMHO jak najdalej od .NETa przy takich zastosowaniach. Tutaj potrzeba
prędkości na nie pseudokompilowanych interpreterów :P



--
pozdrawiam,
Przemek O.
SoftSYSTEM www.soft-system.pl
coś o jedzeniu www.kochamjedzenie.pl

do góry

On Dec 17, 8:28 am, Mariusz Kruk <M...@e...eu.org> wrote:

BTW - Tak totalnie rozpieprzonych literek jeszcze nie widziałem. Czego
używasz do pisania?

> OK. Ka�dy j�zyk jest nieprzyjazny. Jeden mo�e bardziej, inny mniej, ale
> to �rednio dobry argument. Kwestia "dobroci" kompilatora.

Doświadczenia ostatnich 50 lat pokazują, że "dobroć kompilatora"
łatwiej uzyskać przy językach imperatywnych.

> >Kiedy� widzia�em do�� kr�tki artyku�, w kt�rym autor zastanawia�
siďż˝
> >nad Haskellem. By�a tam funkcja sortuj�ca, bodaj�e quicksort w dw�ch
> >(!) linijkach. Zapis �cina� z n�g. Gorzej z wydajno�ci�. Okaza�o
siďż˝,
> >�e ten zajefajny zapis ma si� nijak to tego, co si� dzieje w pami�ci i
> >co robi CPU.
>
> Trochďż˝ mi siďż˝ przypomina argumentacja przeciwko programowaniu
> obiektowemu podpierana tym, jak to pi�knie mo�na w asemblerze
> przyoszcz�dzi� kilkana�cie bajt�w.

Tu nie chodziło o kilkanaście bajtów, tylko w ogóle o sens stosowania
tego w praktyce. O kilkanaście bajtów nikt by się nie spinał.
Komputery mają swoją fizyczność i idące z nią ograniczenia. Jeśli je
zignorujesz, to ograniczysz się do eksploracyjnej niszy.

> >> Nie r�bmy na si�� kalki z angielskiego.
> >Nie r�b se jaj.
>
> Nie robi� sobie jaj. L�knij przez �indo� na korner czy kar jeszcze stoi.

Słabe.

komputer, kompilator, programowanie, procedura, funkcja, ...

Mamy jeszcze kalki z francuskiego, np. klawiatura.

To są słowa, których używasz na codzień i które są stosowane w
literaturze fachowej, czyli są powszechnie uznane w środowisku
profesjonalnym.
Twój przykład z karem na kornerze tu nie pasuje i pokazuje tylko, że
nie masz się czego złapać.

> >Po pierwsze, w tej bran�y kalki to najlepsze co mo�na
> >zrobiďż˝, przynajmniej jest zgodnie ze wszystkimi innymi kalkami.
>
> No w�a�nie niekoniecznie i nie zawsze.

Ale masz problem z uzasadnieniem tej tezy.

> >Po
> >drugie, "funkcyjny", jak rozumiem, absolutnie �adn� kalk� nie jest,
> >tak?
>
> Owszem, nie jest.

Bo jest to stare, rdzennie polskie słowo?

> >Niby w czym kalka "funkcyjny" jest lepsza od kalki
> >"funkcjonalny"?
>
> http://sjp.pwn.pl/slownik/2460400/funkcyjny_I
> http://sjp.pwn.pl/slownik/2558726/funkcjonalny

Słabe. To jest słownik PWN, któro to wydawnictwo równocześnie wydaje
książki mające "analiza funkcjonalna" w tytule. Znaczy - PWN ma
*niekompletny* słownik. Niekompletny do tego stopnia, że nawet
własnych tytułów książek nie obejmują.

Znajdź coś lepszego.

(hint: jak poszukasz na grupach, to zobaczysz, że tą dyskusję już
przerabiałem z dokładnie tymi samymi słabymi argumentami (nawet
argument o PWN był) - spróbuj znaleźć coś, czego jeszcze nie było, bo
trochę szkoda wszystko powtarzać; w każdym razie poprzednie dyskusje
nie doprowadziły do żadnego wniosku, więc ta też nie doprowadzi)

> >> >Ponownie to samo pytanie: dlaczego nie wygra�y tych zawod�w o T1000?
> >> >Mo�e jednak nie daj��tych mo�liwo�ci, co wszyscy my�l�, �e
dajďż˝?
> >> Odpowiem pytaniem na pytanie - dlaczego w tym roku w F1 wygra� cz�owiek
> >> z nazwiskiem zaczynaj�cym si� na "V"? Mo�e jednak inne litery nie daj�
> >> takich mo�liwo�ci?
> >S�abe.
>
> Owszem. Twoje pytanie by�o s�abe. Nie do��, �e usi�owa�e�
generalizowaďż˝
> z pojedynczego przypadku, to jeszcze usi�ujesz przekszta�ci� korelacj�
> w implikacj�. Wi�ksze b��dy logiczne ci�ko by�oby pope�ni�.

Podałem jakiś data point. Możesz argumentować, że ten jeden data point
jest statystycznie nieistotny, ale jak wtedy nazwać całkowity brak
jakichkolwiek przykładów z Twojej strony?

> #v+
> quicksort [] = []
> quicksort (s:xs) = quicksort [x|x <- xs,x < s] ++ [s] ++ quicksort [x|x <- xs,x >=
s]
> #v-
> W spos�b oczywisty wida�, �e kolejne wywo�ania rekurencyjne maj� szans�
w spos�b
> naturalny zosta� zr�wnoleglone.

Tak. Ale jest jeszcze przekazywanie i składanie wyników. Co
konkretnie, czyli na poziomie implementacyjnym, robi ten "++"? To jest
właśnie problem wynikający z zignorowania tego co się dzieje w pamięci
i właśnie o tym był ten artykuł. Nie da się pisać wydajnych programów
skupiając się wyłącznie na jednym aspekcie takim jak równoległość.

Nie pokazuj mi teoretycznych dwulinijkowych przykładów, na których "w
sposób oczywisty widać". Pokaż mi *realny* system, który dzięki temu
był szybszy.

Ja pokazałem *realny* system, który był szybszy w języku imperatywnym.

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

do góry

On 2010-12-17, Maciej Sobczak <s...@g...com> wrote:
> On Dec 17, 8:28 am, Mariusz Kruk <M...@e...eu.org> wrote:
>
> BTW - Tak totalnie rozpieprzonych literek jeszcze nie widziałem. Czego
> używasz do pisania?

slrn, jak widzę. Ino post Mariusza u mnie jest OK, a w twoim cytacie się
rozpieprza. Stawiam że to błąd w czytniku Google (co zresztą nie byłoby
pierwszym w nim babolem), który to Google miał ponoć zatrudniać
najlepszych programistów.

--
Secunia non olet.
Stanislaw Klekot

do góry