aaaaTrzeba żyć, a nie tylko istnieć.aaaa
jarekr wrote:
A jak "wyśwy" i języki funkcyjne .. bo żadnego, który znam nie widze
(nie kojarze RTR, BMQ i SMID).
Były wymienione: Ocaml, List, Scheme, Kogut, Nemerle.
Do listy można dołożyć Haskella, Scale i F#.
(Tak pytam bo imho człowiek, który za dobrze wgryzie się w C/C++ i
przechodzi na javę powinien spędzić tak z miesiąc/ dwa na odwyku
funkcyjnym i wtedy (jego i kolegów) życie staje się prostsze (nie
dlatego, że java ma coś wspólnego z jezykami funkcyjnymi - ma nawet
mniej niż C++) .
Mógłbyś rozwinąć?
Pozdrawiam
KK
Tomasz Zielonka wrote:
Michal Przybylek wrote:
| b) jezyki funkcyjne nie sprawdzaja sie w "programming in the large".
Moglbys to rozwinac? Nie bardzo mi sie to zgadza z moim doswiadczeniem.
Moze dlatego, ze myslimy o innych rzeczach.
Moze chodzi o to, ze ja po prostu uzywam Haskella jako narzedzia,
pisze czysto-funkcyjnie tam, gdzie warto, ale czasem uzywam tez
imperatywnosci. Czyli bez fanatyzmu, podejscie pragmatyczne.
Ale z drugiej strony program nad ktorym ostatnio pracuje i z ktorego
jestem bardzo zadowolony sklada sie w jakichs 95% z kodu czysto
funkcyjnego. Tez ze wzgledow praktycznych.
Best regards
Tomasz
W dniu Fri, 05 Nov 2004 09:59:44 +0100, osoba określana zwykle jako
Maciej Sobczak pozwoliła sobie popełnić co następuje:
| e) "ładnego" językowo (najlepiej całkowicie obiektowego, jak ST)
Może inaczej: mógłbyś rozwinąć e)? Ale tak konkretnie.
No właśnie ciężko mi to jakoś zwerbalizować.
Mogę podać dwa przykłady języków ładnych (z tych, które w życiu
widziałem) - SmallTalk i Haskell. Jednolita spójna koncepcja.
Jeden całkowicie obiektowy, drugi całkowicie funkcyjny. Wysokopoziomowo,
bez żadnych wskaźników ani podobnych tworów.
Jak już pisałem - najlepszy byłby SmallTalk (bo tego już jednak troszku znam)
gdyby ta cała reszta była spełniona ;-)
Pozdrawiam
Codename < azbest
Briefing:
[...]
Z tego co mi wiadomo to perla lacza ludzie z php ? a pythona ?
Co z czym?
Geeez, aż chciałem posłać to na prhn :P
W skrócie :
perl to taki rąbnięty, elastyczny język, w którym można zrobić wszystko
na dziesięc sposobów (i jeszcze kilka innych o których się nie wie,
na które by się w życiu nie wpadło a ich zapisanie przypomina
wyjście z preprocesora który ma czkawkę i alergię na nawiasy),
do którego jest mnóstwo gotowych modułów do robienia znowuż
wszystkiego, który jest prekompilowany do bajtcodu, dzięki czemu
jest całkiem szybki, który doskonale się nadaje do obróbki plików
tekstowych (co jednak nie przeszkodziło mi w napisaniu w nim programu
do wyklikiwania selectów SQLowych z gui opartym na Tk) i przez którego
napisałem najdłuższe (od bardzo bardzo dawna) zdanie... :)
PS
Chcialbym sie rozwinac i nie wiem ktoryby wybrac
perla oczywiście.
python ma dziwną nazwę i jeszcze dziwniejsze formatowanie ;)
PS2
Adv Basha,php juz znam :)
To jeszcze haskell, brainfuck i whitespace przed tobą ;)
Sławek (a poważniej, perla jak najbardziej. mój ulubiony język... :)
On 30 Apr 2001 18:36:51 GMT, Marcin 'Qrczak' Kowalczyk wrote:
* C i C++ - niskopoziomowe języki imperatywne; przeciwieństwo Haskella.
Do niezbyt skomplikowanych programów, które muszą działać bardzo
szybko, a my jesteśmy skłonni poświęcić im bardzo dużo czasu. Pod
Linuxem C jest konieczonścią, 99% bibliotek jest w C; pod Windowsami
AFAIK to ma mniejsze znaczenie,
moglbys rozwinac?
30 Apr 2001 22:52:50 GMT, trashcan man <tr@military.milnet.plpisze:
| * C i C++ - niskopoziomowe języki imperatywne; przeciwieństwo Haskella.
| Do niezbyt skomplikowanych programów, które muszą działać bardzo
| szybko, a my jesteśmy skłonni poświęcić im bardzo dużo czasu. Pod
| Linuxem C jest konieczonścią, 99% bibliotek jest w C; pod Windowsami
| AFAIK to ma mniejsze znaczenie,
moglbys rozwinac?
Które zdanie? Wszystkie?
On 30 Apr 2001 23:14:21 GMT, Marcin 'Qrczak' Kowalczyk wrote:
| * C i C++ - niskopoziomowe języki imperatywne; przeciwieństwo Haskella.
| Do niezbyt skomplikowanych programów, które muszą działać bardzo
| szybko, a my jesteśmy skłonni poświęcić im bardzo dużo czasu. Pod
| Linuxem C jest konieczonścią, 99% bibliotek jest w C; pod Windowsami
| AFAIK to ma mniejsze znaczenie,
| moglbys rozwinac?
Które zdanie? Wszystkie?
ostatnie ('Pod Linuxem C jest konieczonścią, 99% bibliotek jest w C;
pod Windowsami AFAIK to ma mniejsze znaczenie'). po prostu nie bardzo
rozumiem dlaczego windows ma byc na lepszej pozycji i dlaczego fakt
niezgodnosci abi ma byc powodem do niemoznosci korzystania z biblioteki,
skoro wystarczy prosty wrapper.
Sebastian Kaliszewski napisał(a):
Królowania funkcyjnych nie zauważyłem. Ale też z drugiej strony to
często są one całkiem szybkie (najnowsze kompilatory OCamla, SML-NJ, czy
inszego Haskella generują kod całkiem wydajny).
Możesz to rozwinąć "całkiem wydajny" ?
r
ris <ri@gazeta.plwrites:
| Królowania funkcyjnych nie zauważyłem. Ale też z drugiej strony to
| często są one całkiem szybkie (najnowsze kompilatory OCamla, SML-NJ,
| czy inszego Haskella generują kod całkiem wydajny).
Możesz to rozwinąć "całkiem wydajny" ?
http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=all
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
ris wrote:
Sebastian Kaliszewski napisał(a):
| Królowania funkcyjnych nie zauważyłem. Ale też z drugiej strony to
| często są one całkiem szybkie (najnowsze kompilatory OCamla, SML-NJ,
| czy inszego Haskella generują kod całkiem wydajny).
Możesz to rozwinąć "całkiem wydajny" ?
Praktycznie taki jak C++
pzdr
Sektor van Skijlen napisał:
Marcin 'Qrczak' Kowalczyk <qrc@knm.org.plwrote:
| fafulski wrote:
| Masz jakieś dobre doświadczenia z automatycznym odśmiecaniem pamięci?
| Tak (Haskell, Python, Ruby, PHP, Perl, OCaml).
Wymienione przez ciebie jezyki mozna podzielic na dokladnie dwie grupy.
Jezyki skryptowe, ktore maja swoje specjalne przeznaczenia (dla ktorych
czesto nie oplaca sie stosowac innych), w tym PHP o juz naprawde bardzo
waskiej dziedzinie zastosowan, oraz jezyki funkcjonalne (w tym jeden bardzo
spychajacy na margines elementy imperatywne).
Mógłbyś rozwinąć to o spychaniu na margines bo coś mi się nie zgadza?
| Ja trochę poczytałem o tym jak to wygląda w Javie i się strasznie
| zniechęciłem.
| Java ma akurat kiepskie implementacje (nie wiem, czy w związku
| z odśmiecaniem). OCaml, GHC, różne Lispy, Erlang - są odśmiecane i szybkie.
Poza drobnym szczegolem, ze na sile utrudniaja rozwiazywanie zadan w maszynie
stanow czastkowych, zmuszajac uzytkownika do pracy w maszynie funkcjonalnej
(tak, OCaml tez!).
Ale Ty lubisz wszystko gmatwać :) Czymże jest ta maszyna funkcjonalna?
Stany cząstkowe kojarzą mi się z fizyką kwantową, ale może wiem o co Ci
chodzi.
Wszystkie zreszta zmuszaja do przestawienia sie na odpowiedni sposob
myslenia, w ktorym wykonywanie instrukcji jest bardzo zle widziane.
Zmuszają? Dla mnie to ukojenie.
To, ze minimalizuja uzycie stanow czastkowych, to jeszcze mozna
zniesc, w koncu to ma bardzo duzo zalet (tylko chcialbym zobaczyc
program tworzacy GUI, ktory nie korzysta ze stanow czastkowych :).
Nie możesz znieść to nie używaj. Dobrze by też było gdybyś nie
wypowiadał się tak stanowczo i ze "znawstwem" o rzeczach, których
nie używasz i nie znasz (co udowodniłeś parę razy).
Pozdrawiam,
Tomek
| Wszystko jest względne, więc powiedz nam mędrcze co jest
| językiem nowoczesnym, o wyskim poziomie abstrakcji i wspierającym
| programowanie obiektowe, bo bardzo jestem ciekaw?
Przykłady języków nowoczesnych (czyli zawierających albo dających łatwo
wyrazić ważniejsze, pochodzące z różnych paradygmatów konstrukcje
programistyczne): OCaml, Haskell, Dylan, SML, Python, Ruby, Icon,
Erlang, Rebol (?), Mercury, Scheme.
O wysokim poziomie abstrakcji (czyli pozwalających ubrać skomplikowaną
funkcjonalność w pojedyncze pojęcie języka i równocześnie pozwalające
zapomnieć o wielu technicznych szczegółach): OCaml, Haskell, Dylan,
SML, Python, Ruby, Icon, Erlang, Rebol, Mercury, Scheme.
Wspierających programowanie obiektowe: Python, Ruby, Eiffel, Smalltalk,
Java, C#, Self, Cecil, Sather.
Często sprawa jest dyskusyjna - to trudno ściśle ocenić.
Chodziło mi o język który by spełniał te wymagania które postawiłeś C++,
dla każdej cechy wymieniłeś grupe języków, z czego wynika, że żaden z nich
nie jest jednocześnie nowoczesny, o wysokim poziomie abstrakcji, i wspie-
rającym programowanie obiektowe.
Możliwe, że któryś z nich bedzie miał jedna cechę lepiej rozwiniętą ale pod
innymi względami będzie do niczego. C++ jest dobry pod każdym względem
coś może być dla jakiegoś konkretnego rozwiązania bardzo dobre, ale to chyba
za mało.
Jezeli ktoś nie potrafi wyrazić czegoś za pomocą konstrukcji w C++ to raczej
nie jest to wina języka i jego poziomu abstrakcji, tylko jego samego, tak ja
uważam. Znam ludzi którzy potrafią zadowalający ich poziom abstrakcji
uzyskać
w jakimś tam Power Builderze, wszystko zależy od wyobraźni.
Jeżeli chodzi o wspieranie obiektowe to się zgodze, że Smaltakl może ma to
lepiej rozwinięte, ale Java, C#, Python itp. To chyba lekkie
nieporozumienie.
Albo zbyt mała znajomość problemu.
Pozdrawiam Arek G.
Rob Wolfe wrote:
| To, że krotki w przeciwieństwie do większości innych konstrukcji są
| niemutowalne; to, że jest coś takiego, jak krotka jednoelementowa - to
| już woła o pomstę do nieba ;)
Zaintrygowałeś mnie. Mógłbyś nieco rozwinąć tę myśl o krotkach
jednoelementowych. Do tej pory myślałem, że krotki są to poprostu
*dowolnej długości* listy obiektów, czy też referencji do
obiektów.
Dla mnie krotka to element produktu kartezjańskiego - i trudno wyobrazić
sobie inny background dla tego pojęcia - w związku z czym mały sens ma
mówienie o 1- czy 0- (aargh!) elementowych krotkach. Z drugiej strony
może definicje 1/0-elt nie są zupełnie bezsensowne, ale zachowanie się
systemu typów Pythona już trochę jest, bo z pktu widzenia logicznego
powinno np być tak, że (x,) jest tego samego typu, co x.
Co zdaje się potwierdzać ta definicja [1].
Czy javową jednoelementową ArrayList też uważasz za coś
niestosownego?
Ale ArrayList to chyba coś bardziej jak normalna lista, co?
Niemutowalne krotki powstały z powodów wydajnościowych
i mają swój mutowalny odpowiednik - listę. Co jest w tym
niespójnego?
Dla mnie listy pochodzą ze świata typów regularnych, a więc algebr
wolnych - konstrukcja ma trochę inne podłoże.
Nie wiem, może się czepiam, może mam zbyt sformalizowane myślenie o tym
wszystkim - wszakże rozwiązania ad-hoc się sprawdzają w praktyce chyba
częściej, niż doszlifowane teoretycznie. Aczkolwiek w Linspire ostatnio
przeszli na Haskella [1] :)
[1] http://lambda-the-ultimate.org/node/1506
zanotowane.pldoc.pisz.plpdf.pisz.plbrytfanna.keep.pl