Kotlin ma szanse zaistniec?

0

To się przydaje w typowym programowaniu. Do haskella są biblioteki do REST, Websocket, DeepLearning etc. (see at https://hackage.haskell.org).
Sam nie programuje w Haskellu, to nadal język dość niszowy - więc trudno mi coś powiedzieć.

0

Ja bym spróbował coś porobić w jakimś języku typowo funkcyjnym tylko nie wiem jeszcze jakim - clojure czy haskell. Za clojure przemawia fakt bycia językiem JVMowym

0

W Haskellu masz Frege (czyli Haskell na JVM - https://github.com/Frege/frege)

1
scibi92 napisał(a):

Ja bym spróbował coś porobić w jakimś języku typowo funkcyjnym tylko nie wiem jeszcze jakim - clojure czy haskell. Za clojure przemawia fakt bycia językiem JVMowym

To głównie zależy czy cenisz bezpieczeństwo (Haskell) czy prostotę (Clojure). Poza faktem bycia funkcyjnymi te języki dzieli niemal wszystko. Haskell jest bezkompromisowy, a Clojure pragmatyczny - jest od podstaw zaprojektowany z myślą o pracy w prawdziwych projektach, zwłaszcza tam gdzie współbieżność jest konieczna. Pod względem toolingu bije Haskella, który nadal nie ma porządnego IDE, na głowę. No i można go używać w przeglądarce, a wszystko co pozwala uniknąć JavaScriptu jest dobre. Natomiast nie ma co się oszukiwać że jest to język w którym można po prostu nauczyć się składni i zacząć coś klepać, w przeciwieństwie do Scali (simple vs easy). Świetne wprowadzenie do języka od jego twórcy:

3

W zasadzie to trochę nie rozumiem dlaczego temat wątku zmienił się z Kotlina na "języki funkcyjne vs reszta świata".
Tak jak OOP można robić w ASM, tak samo FP można robić w C++, PHP, Javie (Manning, Packt) czy Kotlinie.

@caer:

Ja chętnie usłyszę w jakich przypadkach imperatywizm sprawdza się lepiej, może po prostu trafiłem do beznadziejnych projektów ale z tego co słyszałem te problemy są dość powszechne.

Przede wszystkim w benchmarkach językowych (czyli też w HPC).
Spójrz na ten wykres "How many times slower?":
http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html
Widać wyraźnie sekcję języków natywnie kompilowanych (imperatywnych), języków z maszyną wirtualną i sekcję języków funkcyjnych.
Jedynie OCaml jako tako wygląda, no ale nie jest czysto funkcyjny, więc passe.

Tu inne zestawienie:
https://benchmarksgame.alioth.debian.org/u64q/nbody.html
(Haskell / Fortran = 3x, przed Haskellem jest Ada, Free Pascal i ... Swift)

Niestety w tych statystykach są pewne przekłamania (C/C++ używają intrinsics), ale reszta języków wygląda całkiem natywnie.

Gwoli wyjaśnienia: nie jestem przeciwnikiem FP (nawet jestem całkiem za - w ograniczonym zakresie), tyle że nie rozumiem dlaczego mam wybierać między FP i programowaniem imperatywnym (z tego co wiem Haskell oczekuje takiego "poświęcenia").

2
caer napisał(a):

Przeważnie ci ludzie mają o wiele większe doświadczenie w używaniu języków imperatywnych. Nie rozumiem jak ktoś może uważać że kod na górze jest czytelniejszy od tego na dole, pod warunkiem że zna składnię obu języków: https://gist.github.com/borkdude/533beb1b833828092c35

w haskellu jest jeszcze krocej i czytelniej allBlanks = all isSpace i co z tego, takie porownania sa bez sensu. zgadzam sie ze skladnia javy jest rozwlekla a biblioteka standardowa jest kijowa no ale co to ma do paradygmatu

@caer:

Ja chętnie usłyszę w jakich przypadkach imperatywizm sprawdza się lepiej, może po prostu trafiłem do beznadziejnych projektów ale z tego co słyszałem te problemy są dość powszechne.

za skopane projekty obwinialabym ich autorow i polityke firmy a nie technologie w ktorej byly pisane.
znam 3 duze organizacje ktore zgodzily sie napisac czesc kluczowych projektow w takich jezykach jak haskell, scala i ocaml i kazda z tych organizacji sie chwali jakie to super i jacy oni innowacyjni etc a w praktyce projekty sa jakie sa - jedyne co to ze przyciagaja pasjonatow :)

podejscie czysto funkcyjne kiepsko nadaje sie do pisania wiekszosci algorytmow i struktur danych w optymalny sposob, nie twierdze ze tuning nie jest mozliwy, mozna obejsc wiele problemow poprzez np. uzywanie nieboxowanych typow czy bezposredni dostep do pamieci, oczywiscie jest to fajna zabawa ale w praktyce nikt nie bedzie placil za walke z jezykiem/paradygmatem zamiast z wlasciwymi problemami.
najbardziej rozsmieszaja mnie przyklady w stylu 'quicksort w 2 linijkach' albo rekurencyjne definicje algorytmow ktore w jezykach imperatywnych sa O(1) bo cachowanie stanu jest trywialne :)
uwazam ze programowanie funkcyjne jest ok i kazdy dev powinien cos tam liznac w ramach samorozwoju ale w praktyce jest to bardziej dodatek do innych narzedzi

0
katelx napisał(a):

w haskellu jest jeszcze krocej i czytelniej allBlanks = all isSpace i co z tego, takie porownania sa bez sensu. zgadzam sie ze skladnia javy jest rozwlekla a biblioteka standardowa jest kijowa no ale co to ma do paradygmatu

Przecież Twój przykład jeszcze lepiej ilustruje to że możliwość używania higher order functions prowadzi do czytelniejszego, bardziej deklaratywnego kodu

za skopane projekty obwinialabym ich autorow i polityke firmy a nie technologie w ktorej byly pisane.
znam 3 duze organizacje ktore zgodzily sie napisac czesc kluczowych projektow w takich jezykach jak haskell, scala i ocaml i kazda z tych organizacji sie chwali jakie to super i jacy oni innowacyjni etc a w praktyce projekty sa jakie sa - jedyne co to ze przyciagaja pasjonatow :)

podejscie czysto funkcyjne kiepsko nadaje sie do pisania wiekszosci algorytmow i struktur danych w optymalny sposob, nie twierdze ze tuning nie jest mozliwy, mozna obejsc wiele problemow poprzez np. uzywanie nieboxowanych typow czy bezposredni dostep do pamieci, oczywiscie jest to fajna zabawa ale w praktyce nikt nie bedzie placil za walke z jezykiem/paradygmatem zamiast z wlasciwymi problemami.
najbardziej rozsmieszaja mnie przyklady w stylu 'quicksort w 2 linijkach' albo rekurencyjne definicje algorytmow ktore w jezykach imperatywnych sa O(1) bo cachowanie stanu jest trywialne :)
uwazam ze programowanie funkcyjne jest ok i kazdy dev powinien cos tam liznac w ramach samorozwoju ale w praktyce jest to bardziej dodatek do innych narzedzi

Strasznie mi to śmierdzi przedwczesną optymalizacją, ale nigdzie nie twierdziłem że Haskell jest jakiś zabójczo wydajny.

0
caer napisał(a):

Przecież Twój przykład jeszcze lepiej ilustruje to że możliwość używania higher order functions prowadzi do czytelniejszego, bardziej deklaratywnego kodu

w starej javie tez sobie moge porobic abstrakcje i potem pisac w stylu Folds.any(CharPredicates.isBlank, "string")

Strasznie mi to śmierdzi przedwczesną optymalizacją, ale nigdzie nie twierdziłem że Haskell jest jakiś zabójczo wydajny.

przykladowo - napisy w haskellu sa linkedlistami znakow co zajmuje duzo wiecej pamieci niz tablice a algorytmy operujace na takich napisach sa wolniejsze od naiwnego pythona czy ruby. oczywiscie jest pierdyliard innych typow i rozwiazan ktore beda lepsze no ale api przestaje juz byc takie piekne i wygodne.
to nie jest przedwczesna optymalizacja tylko zdrowy rozsadek, jesli moge uniknac boxingu albo dopisac pare linijek i zrobic klase immutable i uzywac wszedzie jednej instancji to to robie mimo ze system nie ma na razie problemow z wydajnoscia

zeby az tak nie offtopowac - mysle ze kotlin ma szanse zaistniec bo nie ma w nim tak duzo magii i krzakow jak w popularnych jezykach funkcyjnych a jednoczesnie pozwala na ominiecie topornosci javy bez rezygnowania z jej runtime.
prawda jest taka ze malo kto bedzie sie chcial doktoryzowac z teorii kategorii, malo komu potrzebne jest 98134801 operatorow zamiast ludzkich nazw, malo jest praktycznych zastosowan w ktorych prostsze jest zrobienie funkcji przyjmujacej funkcje i zwracajacej funkcje zamiast obiektow gadajacych ze soba :)

0

Powinienem właściwie napisać zieeew.
Zawsze jak się przenosiłem na nowszą platformę to słyszałem od znajomych jak to strasznie wolne i żadnej wydajności nie będzie. Koniec świata.
Z asm na C: ale wydajnooość!
Z C na C++: ale to obiektowe przecież wolne !!!
Z C++ na Jave: chyba śmieszny jesteś - w interpretowanym (!) języku, ale to woooolne bedzie!
Z Javy na Scale: ale te kolekcje Scalowe wolne!
Teraz myśle, żeby następne projekty może robić w Haskellu i słysze, że wolne... czyli chyba warto.

Technicznie dużo zajmuje się problemami utrzymania produkcji na jakim takim poziomie wydajności od lat (około 15 tu - głównie w JVM, ale też okazyjnie C++)
Ile razy problem był spowodowany kiepskim algorytmem lub błędem... nie dam rady policzyć - pewnie setki.
Ile razy wybranym językiem / platformą - prawie raz.

0
scibi92 napisał(a):

Ja bym spróbował coś porobić w jakimś języku typowo funkcyjnym tylko nie wiem jeszcze jakim - clojure czy haskell. Za clojure przemawia fakt bycia językiem JVMowym

Odpal sobie Go i patrz jak to śmiga bez narzutu wirtualnej maszynki ;)

2

w starej javie tez sobie moge porobic abstrakcje i potem pisac w stylu Folds.any(CharPredicates.isBlank, "string")

W każdym języku można porobić jakieś tam abstrakcje, tylko jakim kosztem? Optymalnie byłoby mieć język zorientowany na zwięzłą kompozycję funkcjonalności oraz bibliotekę standardową z zestawem często używanych metod, które pozwalają skrócić zapis.

Moim zdaniem takim językiem jest np Scala. Porównując hipotetyczny kod ze starej Javy:

Folds.any(CharPredicates.isBlank, "string")

z kodem Scalowym

"string".forall(_.isBlank)

widać zasadniczą różnicę - w kodzie Scalowym nie trzeba specjalistycznego obiektu CharPredicates.isBlank. Używamy metody .isBlank dostępnej dla obiektu typu Char (w Scali prymitywy mają metody).

Zamiast tworzyć rozbudowaną infrastrukturę by zmniejszyć trochę ilość kodu w innym miejscu stosuję zwięzły zapis i mocno ogólne komponowalne funkcje. Dzięki temu ucząc się składni Scali oraz jej biblioteki standardowej (a ta to głównie kolekcje) mogę pisać zwięzły kod w każdym zastosowaniu i nie potrzebuję pisania i uczenia się obsługi setek obiektów typu CharPredicates.isBlank.

Zawsze jest pewien kompromis między złożonością języka i biblioteki standardowej, a ekspresywnością języka. Prosty język zwykle wymaga naklepania większej ilości kodu, by stworzyć daną funkcjonalność. Nie chodzi mi tu nawet o końcową formę, bo często można poskracać nawet kod w C i wyjdzie może z 2 czy 3 razy więcej kodu niż w Javie. Chodzi mi także o prototypowanie rozwiązania, dochodzenie do niego metodą TDD, itd podczas których kod jest refaktorowany wielokrotnie, więc w końcowym wyniku nie widać ile kodu naklepano zanim się do niego doszło.

To co czyni Scalę Scalą to głównie parametry (i konwersje) implicit. To jest coś co dramatycznie zwiększa możliwości języka (bardzo dużo rzeczy można przenieść do etapu kompilacji, mając przy tym sprawdzanie typów itd) ale z drugiej strony wymaga dobrego wsparcia od IDE, które pokaże nam co się dzieje i sprawi że w momencie parametry i konwersje implicit staną się explicit (w IntelliJ w pluginie do Scali mamy skróty Ctrl+Alt+P dla implicit parametrów oraz Ctrl+Alt+Q dla konwersji implicit). Implicity dla wielu są zbyt magiczne by się to pchać no ale coś za coś - implicity pozwalają często znacznie skrócić kod i przyspieszyć prototypowanie.

Wracając do Kotlina to Kotlin jest dość bliski Javie. Paradygmat dalej mocno imperatywny, bo kolekcje zostają te same, więc nieprzystosowane do programowania funkcyjnego (które w zasadzie wymaga obecności niemutowalnych struktur danych z wydajnym structural sharing). Przeskok z Kotlina na Javę powinien więc być dość bezproblemowy, w przeciwieństwie do przeskoku z Javy do Scali, gdzie dość dużo się zmienia. Integracja kodu Kotlinowego z Javowym kodem powinna też być w praktyce znacznie lepsza niż w przypadku parowania Javy i Scali, a to za sprawą tego, że Kotlin nie wprowadza niekompatybilnego zestawu kolekcji. Integrowanie kodu Scalowego z kodem Javowym wielokrotnie wymaga użycia konwerterów między kolekcjami - w przypadku Kotlina i Javy ten problem nie wystąpi.

Kotlin nie jest powolny jak Groovy. Powinien mieć prędkość mocno zbliżoną do Javy - nie dość że system typów jest mniej więcej tak samo mocny jak Javowy to jeszcze Kotlin nie wprowadza nowych kolekcji. Sam sposób pisania kodu w Kotlinie powinien też być podobny do sposobu pisania kodu Javowego - kolejny argument za tym, że wydajność będzie mocno podobna.

Podsumowując:
Chociaż ciężko mi stwierdzić czy Kotlin zdobędzie dużą popularność (chociaż już teraz ma niemałą) to jednak moim zdaniem łatwo jest przenieść doświadczenie z Kotlina do Javy (pod warunkiem, że w Kotlinie będziesz używał głównie Javowych bibliotek np Springa) i to jest spory argument za tym by pokodzić w Kotlinie. W Kotlinie będziesz klepał funkcjonalności zauważalnie szybciej niż w Javie, a więc tym samym będziesz nabierał szybciej doświadczenia, a ewentualny przeskok z Kotlina na Javę powinien być szybki i bezproblemowy. Inwestycja powinna się zwrócić, a samo kodzenie będzie przyjemniejsze.

0

@Wibowit: generalnie to sie zgadzam, moim przykladem w javie chcialam jedynie odeprzec argument o czytelnosci gdzie bylo 20 linijek w javie vs jedna linijka w clojure itp
szkoda ze rozwoj javy (jesli chodzi o FP features) nie poszla w kierunku takim jak C# (ktoremu imo blizej do scali niz javy).

@jarekr000000 nie strasze brakiem wydajnosci haskella bo bym zwyczajnie klamala. odpowiadalam tylko na pytanie @caer w czym haskell mi sie nie sprawdzil. jestem przekonana ze w wiekszosci projektow, dla wiekszosci zespolow haskell bylby problematyczny glownie ze wzgledu na swoja akademickosc.

1 użytkowników online, w tym zalogowanych: 0, gości: 1