Haskell napisał(a):
Wybór jest tylko jeden!
Dla tych co preferują lightweight solutions:
1
4
Jeśli koniecznie chcesz wybierać między Kotlinem, a Java pod kątem pracy zawodowej, to warto wybierać w oparciu o fakty, a nie o opinie czy sympatie.
Spójrz na historyczne dane np. z
- http://pypl.github.io/PYPL.html - jak historycznie języki zyskują/tracą popularność.
- http://githut.info/ - w czym faktycznie ludzie piszą
- https://www.itjobswatch.co.uk - ile jest ogłoszeń o pracę
Jak nie zależy Ci na pracy w danej technologii, a chcesz przy czymś podłubać, to zacznij tworzyć własny wymarzony język :)
1
Nowak napisał(a):
hmm... Google zapowiedziało premierę Fuchsia OS na 2019 rok. Jeśli Samsung przeniesie się na Fuchsia to Android stanie się przeszłością
Pamiętaj że rdzeń systemu FuschiaOS jest napisany w C/C++ reszta otoczki w Rust, Go, Python, Dart. A co jest do wszystkiego to jest do niczego. Taki zlepek języków programowania przypomina mi mikroserwisy na zachodzie. Co innego RedoxOS który jest pisany tylko w samym Rust. Jeżeli FuschiaOS nie będzie wspierać Javy to i Kotlina. Więc developerzy będą pisać w czym w Golang?
Ja obecnie wybrałem do nauki Kotlin, jest prostszy od Javy i dodaje wiele ułatwień, jest zwięzły i ma fajną składnie. Do pisania aplikacji na Androidzie to jest najlepszy wybór. Być może Java 7 utkwiła na Androidzie, ponieważ nowy system google FuschiaOS pozbędzie się Javy.
0
Fuchsia OS
Przecież to dziwadło jest. Przez nikogo nie używane języki Dart, Go gdzie to użyjesz.
0
Ale Kotlin i Swift to już używalne języki a w nie zainwestowało Google i Apple.
0
Witam, zaczynam tworzyć ebook Od zera do Kotlin kodera. Zauważyłem na blogach ogromne zapotrzebowanie na naukę Kotlina od podstaw nie znając Javy. Używam do tego programu Open Source SIGIL. Ebook będzie wzorowany na popularnym darmowym ebooku Od zera do gier kodera. Wykorzystam najnowszy standard języka Kotlin, oraz kompilator beta Kotlin.
http ://xion.org.pl/productions/texts/coding/megatutorial/
https ://www .dobreprogramy.pl/DjLeo/Tworzymy-ebooka-w-formacie-EPUB-czyli-zrob-sobie-eksiazke-poradnik-programu-Sigil,38570.html
Co o tym myślicie, czy ktoś chce się przyłączyć?
1
Moim zdaniem warto się uczyć obu języków. Ciężko jest mi sobie wyobrazić, że ktoś sprawnie posługuje się Kotlinem bez znajomości Javy, zwłaszcza, że prędzej czy później będziesz musiał z poziomu Kotlina wywołać kod Javy lub na odwrót ;)
Jeżeli chodzi typowo o programowanie pod Androida to Kotlin powoli staje się standardem w branży(moim zdaniem) więc im szybciej go poznamy tym lepiej dla nas.
0
Slepiec napisał(a):
powiedz mi szczerze co by było gdy ktoś stworzył nowy, ekstra wyrąbany w kosmos język dla .Net (nazwijmy go dla zabawy Horseradish, czy też H#) ? Nie sądzisz że dużo podobnych tematów pojawiało by się w sprawię nauki C# czy H# ?
@Slepiec: trudno stwierdzić, bo nie jestem wróżką, ale myślę, że nie. Onet i WP piszą tylko o zarabiających 15k programistów Javy, skutkiem czego prawie nikt się w .NET nie pcha. :(
jarekr000000 napisał(a):
Jest F# i jest całkiem chwalony (w porównaniu ze Scalą). Ale jakos dyksusji (vs C#) burzliwych nie rodzi.
@jarekr000000: wiesz czemu? Bo Java ssie. ;)
A tak na serio - Java ssie i ssała od początku. Dlatego trzeba było tworzyć protezy - najpierw hipokrytyczna patologia zwana Lombokiem. (Hipokryzja, bo javowcy zawsze twierdzą, że jak jakiś język ma ficzer X, to to jest tylko lukier składniowy i jest do niczego niepotrzebny. Czemu zatem stworzyli coś, co dodaje ten patologiczny lukier składniowy do Javy?)
Potem zaczęły powstawać kolejne języki naprawiające ograniczenia Javy, każdy na swój sposób, z różnymi progami wejścia. Ponieważ nadal piszą w nich javowcy z charakteru, to siła i potrzeba racjonalizacji własnych wyborów jest w nich silna, więc toczą zażarte boje słowne o to, który język lepszy.
W .NET nie ma takiego problemu, bo F# jest mało popularnym językiem do specyficznych zastosowań i relatywnie dużym progiem wejścia. A z drugiej strony jest C#, który jest językiem ogólnego przeznaczenia, podstawy mają niski próg wejścia, a z drugiej strony nieustannie się rozwija od samego początku (czego nie można powiedzieć o niektórych innych, konkurencyjnych językach) i ma np. coraz więcej cech funkcyjnych.
Reasumując - typowy programista Javy przechodząc na Kotlina czy Scalę może przestać przegrywać życie. Programista C# nie ma żadnego interesu w przechodzeniu na F#, bo zanim się go nauczy, to wszystkie fajne ficzery będzie już miał w C#.
0
A tak na serio - Java ssie i ssała od początku. Dlatego trzeba było tworzyć protezy - najpierw hipokrytyczna patologia zwana Lombokiem. (Hipokryzja, bo javowcy zawsze twierdzą, że jak jakiś język ma ficzer X, to to jest tylko lukier składniowy i jest do niczego niepotrzebny. Czemu zatem stworzyli coś, co dodaje ten patologiczny lukier składniowy do Javy?)
Lombok jednak robi robotę i to bardzo dobrze. Nie sprawia, że Java staje się bardziej elegancka (bo nie ingeruje w język), ale wycina sporą część boilerplate'u.
Reasumując - typowy programista Javy przechodząc na Kotlina czy Scalę może przestać przegrywać życie. Programista C# nie ma żadnego interesu w przechodzeniu na F#, bo zanim się go nauczy, to wszystkie fajne ficzery będzie już miał w C#.
F# jest dość ubogim językiem jak na język funkcyjny. Nie ma typów wyższych rzędów, nie ma też typeclass ani implicitów ( https://github.com/fsharp/fslang-suggestions/issues/243 ) - typeclassy są nawet w Ruście czy Swifcie. Pattern matching wchodzi powoli w C# (ZTCW to już jakaś uproszczona wersja jest w C#), async/ await już dawno wszedł. Podstawą oczywiście zostają funkcyjne kolekcje istniejące w F# bez których nie da się wydajnie programować funkcyjnie, ale do tego nie trzeba nowego języka. W Javce też są funkcyjne kolekcje w projekcie http://www.vavr.io/
Potem zaczęły powstawać kolejne języki naprawiające ograniczenia Javy, każdy na swój sposób, z różnymi progami wejścia. Ponieważ nadal piszą w nich javowcy z charakteru, to siła i potrzeba racjonalizacji własnych wyborów jest w nich silna, więc toczą zażarte boje słowne o to, który język lepszy.
Zacytowana wypowiedź to oczywiście nie jest hejt jak rozumiem?
Próg wejścia w Scalę jest sprawą względną, bo można w niej stosować skrajne style programowania. Skrajność z jednej strony to Jala, czy Java bez średników. Skrajność z drugiej strony to emulowanie Haskella na siłę. Większość ludzi wybiera jednak rozwiązanie pośrednie, czyli OOP + FP - wszak Scala zaczynała eksperyment mający pokazać, że OOP i FP mogą dobrze współdziałać razem i celu tego nie zarzucono. Same możliwości języka Scala są bardzo duże. Do dyspozycji są (oprócz rzeczy znanych z Javy): implicit parameters, implicit conversions, makra, type members (coś innego niż type parameters, czyli klasyczne generyki), typy wyższych rzędów, wielodziedziczenie, for-comprehensions, itp itd (cała lista na https://docs.scala-lang.org/tour/tour-of-scala.html ). W Scali 3 ( http://dotty.epfl.ch/ ) dojdą jeszcze między innymi przecięcia i sumy typów oraz (duży ficzer) implicit function types. Ogarnięcie wszystkiego zajmuje dużo czasu, ale z drugiej strony daje bardzo duże pole manewru. F# przy Scali wydaje się prosty.
.NETowy backend dla Scali kiedyś istniał, ale go zarzucono m.in. z powodu problemów z pożenieniem systemu typów ze Scali z systemem typów z CLRa. Różnica w możliwościach języków C# i Scala nadal jest bardzo duża, więc byłby sens utrzymywania .NETowego backendu dla Scali, ale jak widać zabrakło mocy przerobowych. Zamiast tego jest Scala.js, czyli JavaScriptowy backend dla Scali.
0
najwazniejsze to nie siedz wylacznie w javie bo to psuje mozg ;)
co do kotlina to nie jestem przekonana, po napisaniu malego projektu na kilkadziesiat klas (apka sieciowa ale bez frontu, bazy itp) odechcialo mi sie, sa fajniejsze jezyki do zabawy, imo pod jvm juz lepiej pobawic sie w clojure, groovy czy nawet scali, bardziej przydatne i rozwojowe.
0
somekind napisał(a):
[Slepiec napisał(a)](
jarekr000000 napisał(a):
A tak na serio - Java ssie i ssała od początku. Dlatego trzeba było tworzyć protezy - najpierw hipokrytyczna patologia zwana Lombokiem. (Hipokryzja, bo javowcy zawsze twierdzą, że jak jakiś język ma ficzer X, to to jest tylko lukier składniowy i jest do niczego niepotrzebny. Czemu zatem stworzyli coś, co dodaje ten patologiczny lukier składniowy do Javy?)
Potem zaczęły powstawać kolejne języki naprawiające ograniczenia Javy, każdy na swój sposób, z różnymi progami wejścia. Ponieważ nadal piszą w nich javowcy z charakteru, to siła i potrzeba racjonalizacji własnych wyborów jest w nich silna, więc toczą zażarte boje słowne o to, który język lepszy.
Trochę dziwna argumentacja.
- Java powstała wieki temu w czasach gdy składnia PL/1 była uznawana za elegancką - czyli nie była jakoś specjalnie składniowo brzydka w porównaniu do innych języków.
- To, że coś jest lukrem składniowym nie znaczy że nie jest przydatne.
0
To, że coś jest lukrem składniowym nie znaczy że nie jest przydatne.
Tylko czysty bajtkod nie jest lukrem :P
Java powstała wieki temu w czasach gdy składnia PL/1 była uznawana za elegancką - czyli nie była jakoś specjalnie składniowo brzydka w porównaniu do innych języków.
Dodam jeszcze, że sam James Gosling (twórca Javy) w którymś z wywiadów stwierdził, że gdyby miał całkowicie wolną rękę to Java wyglądałaby trochę jak dzisiejsza Scala, ale z powodów marketingowych przypomina bardziej C/ C++ (Java miała za zadanie przejąć programistów C++ i jej się to udało). Guglowałem trochę, ale niestety nie udało mi się znaleźć dokładnie tego wywiadu.
Podam jednak kilka cytatów, które przewijają się przez Internet:
James Gosling, creator of Java
“If I were to pick a language to use today other than Java, it would be Scala.”
.
Charles Nutter, creator of JRuby
“Scala, it must be stated, is the current heir apparent to the Java throne. No other language on the JVM seems as capable of being a "replacement for Java" as Scala, and the momentum behind Scala is now unquestionable. While Scala is not a dynamic language, it has many of the characteristics of popular dynamic languages, through its rich and flexible type system, its sparse and clean syntax, and its marriage of functional and object paradigms.”
.
James Strachan, creator of Groovy
“I can honestly say if someone had shown me the Programming in Scala book by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy.”
0
Wibowit napisał(a):
Lombok jednak robi robotę i to bardzo dobrze. Nie sprawia, że Java staje się bardziej elegancka (bo nie ingeruje w język), ale wycina sporą część boilerplate'u.
Nie mówię, że nie robi, tylko że hipokryzją jest używanie go i jednocześnie dissowanie innych języków za lukier. Bo lukier przecież jest po to, żeby zmniejszać ilość boilerplate.
F# jest dość ubogim językiem jak na język funkcyjny. Nie ma typów wyższych rzędów, nie ma też typeclass ani implicitów ( https://github.com/fsharp/fslang-suggestions/issues/243 )
No tak, bo o funkcyjności języka nie decydują funkcje jako elementy pierwszego rzędu, wyrażenia zamiast instrukcji, rekursja zamiast iteracji i forsowanie niezmienności danych tylko te parę mechanizmów, które akurat ma ten język, w którym WIbowit zarabia na chleb z frytkami.
Ja nie wiem w ogóle za co twórca ML dostał nagrodę Turinga, skoro on nawet wystarczająco funkcyjnego języka zrobić nie umiał. :(
Potem zaczęły powstawać kolejne języki naprawiające ograniczenia Javy, każdy na swój sposób, z różnymi progami wejścia. Ponieważ nadal piszą w nich javowcy z charakteru, to siła i potrzeba racjonalizacji własnych wyborów jest w nich silna, więc toczą zażarte boje słowne o to, który język lepszy.
Zacytowana wypowiedź to oczywiście nie jest hejt jak rozumiem?
To złośliwe i cyniczne określenie nieracjonalnych postaw reprezentowanych przez pewnych ludzi. Ale ok, niech będzie, że to hejt. Wszak jednosylabowe wyrazy są prostsze dla pewnych ludzi reprezentujących wspomniane postawy.
wszak Scala zaczynała eksperyment mający pokazać, że OOP i FP mogą dobrze współdziałać razem i celu tego nie zarzucono.
No właśnie - Scala to z założenia miks dwóch paradygmatów. F# to język funkcyjny, w którym możesz też pisać obiektowo. Niby to samo, a jednak co innego.
F# przy Scali wydaje się prosty.
Dziwne, przecież mają tyle samo sylab!
0
Trochę mam wrażenie, że obie strony stworzyły sobie chochoły, które teraz zawzięcie atakują
0
No tak, bo o funkcyjności języka nie decydują funkcje jako elementy pierwszego rzędu, wyrażenia zamiast instrukcji, rekursja zamiast iteracji i forsowanie niezmienności danych tylko te parę mechanizmów, które akurat ma ten język, w którym WIbowit zarabia na chleb z frytkami.
Ja nie wiem w ogóle za co twórca ML dostał nagrodę Turinga, skoro on nawet wystarczająco funkcyjnego języka zrobić nie umiał. :(
Scala ma wszystko co wymieniłeś. Wsparcie dla TCO jest jednak uproszczone, bo działa tylko dla bezpośredniej rekurencji ogonowej: https://www.scala-lang.org/api/current/scala/annotation/tailrec.html
Przy czym ani Scala ani F# nie wymuszają funkcyjności tak bardzo jak Haskell. W Scali możesz zrobić var, w F# możesz zrobić let mutable, a w Haskellu ZTCW i tak cały stan pakuje się w monady tak zminimalizować obserwowanie mutowalnego stanu.
0
Problem z Kotlinem jest taki, że ucząc się go trzeba wpierw nauczyć się Javy. Co innego jest ze Swift, tam Objective-C już nie jest potrzebny. Możesz się uczyć od razu Swift.
1
Bogaty Polityk napisał(a):
Problem z Kotlinem jest taki, że ucząc się go trzeba wpierw nauczyć się Javy. Co innego jest ze Swift, tam Objective-C już nie jest potrzebny. Możesz się uczyć od razu Swift.
Nie rozumiem tego wywodu w ogóle. Ucząc się Kotlina nie musisz znać Javy, ale dużo daje jak znasz standardowe biblioteki Javy, nie powiesz mi że z Swiftem i Obj-C nie jest podobnie.
Zresztą porównanie trudności nauki Javy i Obj-C jest bez sensu, składni Javy jest dużo łatwiej się nauczyć i jest bliższa wszystkiemu innemu obecnie w użyciu.