kotlin vs scala

Odpowiedz Nowy wątek
2017-05-21 16:02
0

swoje przeczucia na ten temat mam, choć pewnie kulawy bo kotlina nie znam za dobrze

szukałem, ale takiego tematu chyba nie było jeszcze

co sądzicie o tych dwóch językach? czy wg was kotlin pozostanie na androidzie i raczej poza niego nie wyjdzie, a scala zostanie tam gdzie jest teraz czy może coś się ruszy?
właściwie to temat flame.. :) gdybanie z nudów

Pozostało 580 znaków

2017-10-10 20:32
0
Brunatny Polityk napisał(a):

Koniec Javy na Androidzie jest już rychły.
https://www.dobreprogramy.pl/[...]a-na-Androida,News,83601.html

Co niby chcesz przez to powiedzieć? Kotlin kompiluje się do Javowego bajtkodu, tak samo jak Java. Mówienie, że Kotlin wyprze Javę jest jak mówienie, że TypeScript wyprze JavaScript. Dość podobna sytuacja.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.

Pozostało 580 znaków

2017-10-10 20:41
0
Wibowit napisał(a):

Co niby chcesz przez to powiedzieć? Kotlin kompiluje się do Javowego bajtkodu, tak samo jak Java. Mówienie, że Kotlin wyprze Javę jest jak mówienie, że TypeScript wyprze JavaScript. Dość podobna sytuacja.

Albo, że C/C++ wyprze assembler.


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.

Pozostało 580 znaków

2017-10-10 21:20
0

Chodziło mi o to, że Kotlin jest nastawiony na maksymalnie wygodną współpracę z językiem Java. C/ C++ raczej nie stawiają sobie za cel współpracy z kodem napisanym w czystym asemblerze - jest dokładnie odwrotnie.

Komentarze pod artykułem sugerują kompletne niezrozumienie tematu. Goście piszą, że Kotlin jest kompatybilny z Javą i umożliwia kompilację do natywnych binarek. Jest to owszem prawda, ale jednocześnie się tego nie osiągnie. Kotlin Native ZTCW nie jest w stanie przerobić typowych JARków do natywnych binarek.

Reasumując: nie sądzę by popularyzacja Kotlina na Androidzie miała w jakikolwiek sposób utrudnić pisanie na Androida w Javie.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.

Pozostało 580 znaków

2017-10-11 02:10
4
Wibowit napisał(a):

Reasumując: nie sądzę by popularyzacja Kotlina na Androidzie miała w jakikolwiek sposób utrudnić pisanie na Androida w Javie.

No to akurat pewne, bardziej się już przecież nie da.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."

Pozostało 580 znaków

2017-10-12 18:42
V-2
0
Wibowit napisał(a):

Kotlin kompiluje się do Javowego bajtkodu, tak samo jak Java. Mówienie, że Kotlin wyprze Javę jest jak mówienie, że TypeScript wyprze JavaScript.

Ale gdy mówi się o wyparciu, to nie ma się na myśli Javowego bajtkodu, tylko poziom kodu źródłowego.

Z drugiej strony nie napalałbym się na tego typu wyliczenia (cytując artykuł):

we wrześniu 2016 roku ok. 95% programistów wykorzystywało Javę i tylko około 5% Kotlin, natomiast rok później proporcje zmieniły się na niecałe 86% dla Javy i ponad 14% dla Kotlina. Gdyby ten trend się utrzymał, prognozuje się, że już pod koniec przyszłego roku Kotlin wyprzedzi popularnością Javę.

Prosta ekstrapolacja trendów tu nie działa. Projekt projektowi nierówny. Proporcje najpierw zmienią się szybko, bo dotyczą lekkich i nowych projektów. W ten sposób nabije się punkty za pomocą tzw. "nisko wiszących owoców" - szybki i tani przyrost wskaźnika.

Im dalej, tym bardziej zacznie to zwalniać. Choćby dlatego, że jest kupa starego kodu wymagającego utrzymania. Taki kod bywa i długożywotny, i duży (co wyklucza przepisanie).

Siła bezwładności w branży programistycznej bywa niedoceniana. To dlatego do dziś można złapać dobrą robotę w COBOL-u; niekoniecznie w Polsce, ale w USA owszem.


Nie ma najmniejszego powodu, aby w CV pisać "email" przed swoim adresem mailowym, "imię i nazwisko" przed imieniem i nazwiskiem" ani "zdjęcie mojej głowy od przedniej strony" obok ewentualnego zdjęcia.

Pozostało 580 znaków

2017-11-04 07:40
0

Siemka!

A jak by się to wszystko powyżej (kotlin, scala, hotspot-[java hotspot]) miało do systemów embedded, a tak właściwie RTOS i MCU stm32F7 lub wyższe?

Krytyczne zdarzenia i działanie RTOS (FreeRTOS dla przykładu) obsłużone przy użyciu właściwego języka programowania. Jednak chodzi mi o mniej krytyczne funkcjonalności dedykowanego systemu - chociażby: tryb pracy remontowej lub tryb "recovery", a także spójność rozwojowo-multiplatwormowa jako wsparcie kanału inżynierskiego.
O co mi chodzi? - Obsługa i serwis urządzenia (sterownika), jak najbardziej pełna integracja etapu rozwoju, wdrożenia i utrzymania systemu.

Wykorzystanie JSON byłoby miłe :)


P.S. Mam nadzieję że udało mi się dokładnie sprecyzować pytanie :)

edytowany 2x, ostatnio: Drauggul, 2017-11-04 08:03
RTOS i języki z GC? - Fedaykin 2017-11-04 10:51

Pozostało 580 znaków

2017-12-29 19:10
1
Mały Termit napisał(a):

Google posiada doskonały język Go, który został stworzony jednak w innym celu - dlatego wybór Kotlina - jest jasnym i jedynym krokiem na możliwość konkurowania z Apple. Bo jeżeli ta próba się nie powiedzie, to zgodnie pojawiającymi się plotkami, jedyną drogą dla Google będzie wykorzystanie Swift'a.

Google nigdy nie skorzysta ze Swifta. Domeną Swifta jest programowanie na Maca i iPhone. Golang to język do zastosowań sieciowych (wyjdajne, współbieżne aplikacje internetowe i streaming danych) i systemowych (pisanie programów do operacji na plikach). Swift nie jest Google do niczego potrzebny, a gdyby chcieli to zamiast Kotlina wykorzystaliby Scalę czy Groovy'ego. Kotlin to taka Scala z kilkoma ulepszeniami i nic poza tym. Ciągle trzeba się bawić w budowanie apki, Gradle działa wolniej niż pod Javą (o Mavenie i tonach XML'a nie wpominając). Sporą apkę w Golang zbudujesz bez Gradle czy Mavena w parę sekund a deployment to uruchomienie jednego pliku exe. Kotlina wybrano z jednego powodu - składnia mniej rozwlekła od Javy i pełna kompatybilność z Javą na poziomie bajtkodu (Scala nie jest kompatybilna z Javą - możesz korzystać z bibliotek Javy w Scali, ale odwrotnie już nie. Natomiast w Kotlinie można pisać biblioteki dla Javy bez potrzeby ingerowania w JVM. Dla Google to było zbawienne, bo chłopaki z JetBrains wykonali za ich krecią robotę. Mimo, że apki w Kotlinie pisane są przy użyciu mniejszej ilości kodu to finalnie ich rozmiar jest większy o kilka MB.


edytowany 1x, ostatnio: siloam, 2017-12-29 19:10

Pozostało 580 znaków

2017-12-29 19:23
2

Kotlin to taka Scala z kilkoma ulepszeniami i nic poza tym.

Wręcz przeciwnie. Kotlin to coś pomiędzy Javą i Scalą na skali trudności i ilości bajerów. Jednak głównym powodem dla stworzenia Kotlina była szybkość kompilacji, która w przypadku Scali nadal trochę kuleje (głównie za sprawą najbardziej rozpoznawalnej cechy Scali czyli implicitów).

Kotlina wybrano z jednego powodu - składnia mniej rozwlekła od Javy i pełna kompatybilność z Javą na poziomie bajtkodu (Scala nie jest kompatybilna z Javą - możesz korzystać z bibliotek Javy w Scali, ale odwrotnie już nie. Natomiast w Kotlinie można pisać biblioteki dla Javy bez potrzeby ingerowania w JVM.

Nieprawda. Biblioteki napisane w Scali można spokojnie używać z poziomu Javy o ile twórcy zadbają o wygodne Javowe API. Dla przykładu Javowe API mają:

Dla Google to było zbawienne, bo chłopaki z JetBrains wykonali za ich krecią robotę.

Krecią robotę? Przecież to negatywne określenie. Chłopaki z JetBrains odwalili kawał dobrej roboty!

Mimo, że apki w Kotlinie pisane są przy użyciu mniejszej ilości kodu to finalnie ich rozmiar jest większy o kilka MB.

Te kilka MB to biblioteka standardowa Kotlina, która zawiera przecież wiele przydatnych i wygodnych w użyciu funkcji. Kompromis jak przy użyciu każdej innej pomocniczej biblioteki.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.

Pozostało 580 znaków

2017-12-29 19:29
Czarny Lew
0

Wadą Kotlina i Scali jest to, że trzeba znać już Jave aby się ich uczyć. To ja wybieram jakiś inny język programowania.

Ojojoj, straszne. Ja też poznałem języki których nie lubię, np JavaScript czy składnię basha. - Wibowit 2017-12-29 19:44

Pozostało 580 znaków

2017-12-29 19:57
Lolekkk
0
Wibowit napisał(a):

Te kilka MB to biblioteka standardowa Kotlina, która zawiera przecież wiele przydatnych i wygodnych w użyciu funkcji. Kompromis jak przy użyciu każdej innej pomocniczej biblioteki.

Oczekuję jednak, że aplikacja w Kotlinie będzie generować taki sam kod wynikowy, jak aplikacja w Javie, a nie dorzucać jakieś swoje rzeczy.

Bo zaraz się okaże, że powstanie takie g**no jak Xamarin, który dorzuca do apk 25 MB bibliotek standardowych Mono. Widzę, że to w tym kierunku zmierza i średnio mnie to przekonuje.

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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