Twórca Javy – James Gosling opuszcza Oracle

Ale to społeczność Java tworzy takie narzędzia jak Spring, Hibernate, czy nawet JUnit. LINQ, czy lambdy mogę mieć w innych językach JVM.

if(króliki.FirstOrDefault(krolik => !krolik.IsIgnorat) != null){
sprawdzZanimNapiszesz();
}

LINQ to nie interfejs dostępu do baz danych tylko jakby standardowy sposób prztwarzania danych w kolekcjach. Jak zobaczę coś podobnego w javie (tak łatwo używalne) to chętnie powiem, że nie jest innowacyjne.

Tu kilka przykładów:
http://msdn.microsoft.com/en-us/vcsharp/aa336746….

prawie, gdyby tylko było silnie typowane (siła LINQ to między innymi intellisense w tych zapytaniach)

To jest poważne ograniczenie. Nie mówiąc o tym, że nie jest zgodne z ogólnie przyjętym działaniem wyrażeń lambda w programowaniu funkcyjnym.

czy ja gdzieś pisałem że w javie nie ma wyrażń lambda rozumianych w sensie "ogólnie przyjętym działaniem wyrażeń lambda w programowaniu funkcyjnym"? Ja pisałem że w javie nie ma nawet odpowiednika tej 'prymitywnej' formy wyrażeń lambda która jest w C#.

Zmieniasz definicje pojęć w trakcie dyskusji tak jak Ci wygodnie. Też mogę powiedzieć że w javie nie ma generics takich jak są C# więc java 'a to poważne ograniczenie'

@j23tom: ależ w Javie jest prymitywna forma wyrażeń lambda – klasy anonimowe. I to od Javy 1.1. Poza tym Java 7 będzie mieć wyrażenia lambda conajmniej na poziomie tych, które są w C#. A wyrażenia lambda "done right" oraz zylion innych ważnych rzeczy, których nie ma w C# ani F# i raczej nie będzie, są w Scali. Nie widzę powodu, dla którego ktoś kto umie sensownie używać wyrażeń lambda miałby używać Javy zamiast Scali.

@Królik

ależ w Javie jest prymitywna forma wyrażeń lambda – klasy anonimowe.

cieszę się, że wreszcie zauważyłeś, że java jest uboższa od C#.

Co do Scali i F# itp. to żaden język funkcyjny do mainstreamu póki co się nie przebił, choć jest tendencja żeby z nich podbierać różne "features"

Problem jest taki, że jak napotkasz na return, to nie jest łatwe stwierdzenie, co on takiego robi. Musisz przeanalizować cały kod na zewnątrz i zobaczyć, czy aby nie jest przekazywany jako metoda anonimowa. Podobnie jak opakowujesz kawałek kodu w metodę anonimową, musisz uważać na return.

Przykład:
def f() {
using(new Resource()) { z =>
// …
if (error)
return;
}
// more code…
}

Natomiast zgadzam się, że generalnie, non-local return to zła praktyka. Dokładnie tak samo jak poleganie na typach w runtime. Więc można powiedzieć, że C# ma podobnie skopane lambdy jak Java genericsy (erasure). Jedno i drugie tak bardzo nie przeszkadza, jak się umie programować, ale jedno i drugie wprowadza "niespójność". Dlatego wolę język, gdzie jedno i drugie działa zgodnie z oczekiwaniami.

A co do popularności, to Scala ma spokojnie potencjał znaleźć się o tam gdzie Python lub Ruby (a C# nie jest wcale popularniejszy). Na razie jednak za krótko istnieje, aby powiedzieć coś pewnego.

@Królik:

Problem jest taki, że jak napotkasz na return, to nie jest łatwe stwierdzenie, co on takiego robi.

z punktu widzenia czlowieka ze specjalizacja w logice stosowanej (teoria typow) – return nie jest elementem rachunku lambda i jako taki nie ma zastosowania w programowaniu funkcyjnym. to imperatywny element kontroli przeplywu… 😉

z punktu widzenia praktyka, uzywajacego 'pragmatycznych' jezykow programowania pozwalajacych na swobodne mieszanie paradygmatow i stylow – lambda wyrazenie tworzy domkniecie leksykalne. moja intuicja podpowiada, ze 'return' powinien opuscic najbardziej 'wewnetrzne' domkniecie leksykalne, w ktorym ten 'return' sie znajduje. wiec powinien sprawic, ze ewaluacja takiego wyrazenia powinna dac wartosc wskazana jako argument 'return'.

tak sie zachowuja wyrazenia lambda w c#, javascripcie, czy rubym (w przeciwienstwie do Proc.new, ktore nie tworzy domkniecia leksykanego). takie zachowanie jest dla mnie normalne, naturalne, oczekiwane i 'logiczne'. non-local return w kontekscie programowania funkcyjnego ma tyle samo sensu, co iteracyjny quicksort in situ.

A co do popularności, to Scala ma spokojnie potencjał znaleźć się o tam gdzie Python lub Ruby (a C# nie jest wcale popularniejszy).

chyba kpisz:
1. popatrz ile jest ogłoszeń o pracę związanych C# a ile ze Scala.
2. http://langpop.com/

"C# nie jest wcale popularniejszy" odnosiło się do Pythona.
W TIOBE są bardzo blisko siebie.

Scala jest nowa. Ma jeszcze dobrych kilkanaście lat przed sobą, zanim osiągnie wiek, jaki obecnie ma C#. C# jak na swój wiek i kasę jaką MS ładuje w jego promocję (zwłaszcza na uczelniach technicznych) i tak trzyma się… przeciętnie. Javy nie przebił i raczej nieprędko to nastąpi.

Poza firmami, które zainwestowały mocno w systemy od MS, praktycznie nie istnieje (no dobra, wiem, jest kilka fajnych aplikacji w mono i parę banków zrobiło na tym swoją bankowość internetową i aplikacje wewnętrzne – ale czy to jest powód do dumy?).

@Królik:

to pierwsze oczywiscie nie tworzy domkniecia leksykalnego, jedynie nowy zakres leksykalny.

co do drugiego – nie wiem, nie znam scali, nie znam jej semantyki. nie podoba mi sie kierunek, w ktorym rozwinely sie zainteresowania martina oderskiego… system typow i skladnia sa dla mnie na tyle obrzydliwe, ze mnie ten jezyk po prostu nie interesuje.

Czym się w takim razie wg Ciebie różni domknięcie leksykalne od zakresu leksykalnego?

Obie konstrukcje, które podałem mają identyczną semantykę. Jedna jest realizowana przez "język", druga jest konstrukcją czysto biblioteczną używającą właśnie domknięcia leksykalnego.

system typow i skladnia sa dla mnie na tyle obrzydliwe, ze mnie ten jezyk po prostu nie interesuje.

Nie ma to jak merytoryczny argument.

Niestety zmartwię Cię: C# idzie dokładnie w tym samym kierunku (patrz nowość: "var" i inferencja typów – szczególnie to var to jest baaardzo udana i elegancka składniowo konstrukcja, lol).

domkniecie leksykalne to funkcja, wraz ze srodowiskiem (zasiegiem leksykalnym), w ktorym zostala zdefiniowana, ktorej zmienne wolne sa zwiazane w tym srodowisku. nie wiem jak zachowuje sie funkcja biblioteczna w scali, bo jej nie znam 🙂 wiem, ze blok synchronized w javie nie jest wartoscia funkcyjna, nie moze byc wiec domknieciem. jak wiekszosc innych klamerek w tym jezyku tworzy jedynie nowe srodowisko (lexical scope).

Nie ma to jak merytoryczny argument.

to nie argument. to jedynie uzasadnienie-wymowka dlaczego nie znam scali. i dlaczego nie potrafie odpowiedziec na pytanie czy/czym rozni sie javowy blok synchronized, od jego bibliotecznego odpowiednika w scali.

C# idzie dokładnie w tym samym kierunku

ok. przyjalem do wiadomosci 🙂 c# jest dla mnie rownie interesujacy co scala. czyli wcale.

domkniecie leksykalne to funkcja, wraz ze srodowiskiem (zasiegiem leksykalnym), w ktorym zostala zdefiniowana, ktorej zmienne wolne sa zwiazane w tym srodowisku

Każdy blok oznaczony klamerkami w języku imperatywnym takim jak Java/C++ można podciągnąć pod tę definicję. Zasięg leksykalny jest dobrze zdefiniowany, dziedzina jest zdefiniowana poprzez dostęp do zmiennych na zewnątrz bloku, przeciwdziedziną w Java/C++ będzie po prostu zawsze void, a w Scali dowolny typ. Proste i spójne. Każde klamerki to jeden i ten sam byt.

Ale jeśli pójdziemy Twoim tokiem rozumowania, to mamy w języku 2 rodzaje bytów oznaczonych klamerkami: domknięcia leksykalne i "zwykłe bloki". Zwykły blok to takie niedorobione domknięcie, które określa tylko zasięg i zmienne wejściowe, ale nie ma określonej przeciwdziedziny (żeby nie stać się funkcją). Ponieważ jedne i drugie czasem bardzo trudno odróżnić wizualnie, to które rozwiązanie jest lepsze i prostsze? No, i co zrobić z tym fantem, że możemy chcieć mieć domknięcia leksykalne nie zwracające żadnej wartości (tj. void)?

Gdyby nie niewielkie rozróżnienie składniowe, bylibyśmy w cz****ej d***ie. Ale tak ratujemy się, komplikując składnię i wprowadzając sztuczny podział na "zwykłe bloki" i "domknięcia". Paskudztwo.

No na 17-stym miejscu. Rozbłyśnie zaraz po n apisaniu worda w Lispie który jest na 9. Argument, że może się rozwinąć jest wzięty z czapki.

BTW: Zapomniałeś dodać, że C# jest na 7. miejscu. A ponieważ jest obecny znacznie dłużej i znacznie bardziej promowany, to argument o tym, że to jest język przyszłości jest jeszcze bardziej z czapki 😛