Kotlin nebo Scala pro backend?

Re:Kotlin nebo Scala pro backend?
« Odpověď #90 kdy: 07. 11. 2020, 20:28:28 »
Podľa mňa to vyplýva z toho, že Java je ako sa dnes hovorí opinionated jazyk; všetko musí byť objektovo.
Pre veľkú časť úloh objektové programovanie nie je potrebné a dokonca je zbytočné. Nemožnosť tvoriť
obyčajné funkcie zabrzdil rozvoj Javy ako jazyka a oproti moderným jazykom pôsobí zastaralo. Nuž, keď
sa raz základy zle postavia, tak už stavbu neprerobíme.
Podívejte se na funkce v JavaScriptu. Jsou to obyčejné funkce a zároveň objekty.
mi
JS je z hlediska designu extrémně primitivní.


jano6

Re:Kotlin nebo Scala pro backend?
« Odpověď #91 kdy: 07. 11. 2020, 23:15:10 »
Citace
V čem byl Python revoluce? Beru třeba Lisp nebo Smalltalk, ale proč Python?

No zrejme nie vo features, ktoré má, ale možno je Python revolúciou preto, že sa doslova
masovo rozšíril. Je to jazyk aj pre nie programátorov. Pre veľa ľudí, pre ktorých sú
excelové funkcie už nedostatočné. To sa v histórii nepodarilo žiadnemu jazyku.

Citace
Když si v aplikaci uděláš jednu statickou Common třídu (nebo klidně víc podle zaměření, když by jich bylo moc),
tak její metody můžeš používat úplně stejně jako obyčejné funkce - nebo ne?

Stále tam musíme napísať tú Common triedu, ďalej je tam statický kontext, ktorý všetko len zamotáva.
A takéto statické  metódy nemožno použiť všade, kde by sa dala použiť bežná funkcia; viď tzv higher-order funkcie.

Citace
Podívejte se na funkce v JavaScriptu. Jsou to obyčejné funkce a zároveň objekty.

No to áno, to je v pohode, takto to majú aj Python či Ruby. Problém je, že v Jave či C#  metódy
nie sú ani jedno.

Re:Kotlin nebo Scala pro backend?
« Odpověď #92 kdy: 08. 11. 2020, 14:46:31 »

A takéto statické  metódy nemožno použiť všade, kde by sa dala použiť bežná funkcia; viď tzv higher-order funkcie.


Co presne tam je za problem?

Re:Kotlin nebo Scala pro backend?
« Odpověď #93 kdy: 09. 11. 2020, 00:00:23 »
Pokud by se Java naučila brát za arugmenty funkce/metody (lambdy se nepočítají)

Re:Kotlin nebo Scala pro backend?
« Odpověď #94 kdy: 09. 11. 2020, 06:24:54 »
Pokud by se Java naučila brát za arugmenty funkce/metody (lambdy se nepočítají)

A to neumi?


Re:Kotlin nebo Scala pro backend?
« Odpověď #95 kdy: 09. 11. 2020, 08:02:17 »
Pokud by se Java naučila brát za arugmenty funkce/metody (lambdy se nepočítají)

A to neumi?

Pravda, co se dívám tak Java 8 to umí.
someMethod (this::anotherOne);

Re:Kotlin nebo Scala pro backend?
« Odpověď #96 kdy: 09. 11. 2020, 10:44:23 »
Pokud by se Java naučila brát za arugmenty funkce/metody (lambdy se nepočítají)
Co znamená „lambdy se nepočítají“? Lambda je přece anonymní funkce. Jediné, co byste mohl chtít navíc, je možnost reflexí zkoumat předanou funkci, to opravdu Java neumí.

jano6

Re:Kotlin nebo Scala pro backend?
« Odpověď #97 kdy: 09. 11. 2020, 12:22:26 »
Citace
Co presne tam je za problem?

Reagoval som na použitie statických metód; tie neexistenciu obyčajných funkcií nevyriešia, ale
pridávajú vlastné problémy (statická metóda môže volať len statickú metódu a pracovať so statickými
atribútmi.)

Citace
Co znamená „lambdy se nepočítají“? Lambda je přece anonymní funkce.
Jediné, co byste mohl chtít navíc, je možnost reflexí zkoumat předanou funkci, to opravdu Java neumí.

Opravte ma ak sa mýlim, ale lambda sa len tvári ako anonymná funkcia. Je to len syntaktický
konštrukt, z ktorého kompiler spraví objekt. Java bohužiaľ nemá bežné funkcie, len metódy.
A tie nie sú first-class.

Čo bolo pridané v Java 8 je vohejbák. Java stále nemá obyčajné funkcie, len cez funkcionálne rozhrania
sa okľukou vytvárajú objekty a volajú potom metódy.

Kód: [Vybrat]
public class Example {
 
    public static void main(String args[]) {
 
        Function <Integer, Integer> inc = e -> e + 1;
        doSum(5, inc);
 
    }
 
    public static void doSum(int value, Function <Integer, Integer> func) {
        System.out.println(func.apply(value));
    }
}

Ono to vyzerá ako funkcia, ale nie je.
Je to celé komplikované. Java pridala do jazyka celý rad preddefinovaných rozhraní
kvôli uľahčeniu práce, ale faktom je, že nemáme funkcie, len objekty a ich metódy.
Každú "funkcia" potrebuje mať vlastné rozhranie napr:

Kód: [Vybrat]
@FunctionalInterface
public interface Consumer<T> {
    void accept(T t);
}

Porovnajme si to s JavaScript kódom:

Kód: [Vybrat]
function inc(val) {
    return val + 1;
}

function dec(val) {

    return val - 1;
}

function double(val) {

    return val * 2;
}

function halve(val) {

    return val / 2;
}

let pipeline = [inc, halve, dec, double];

let res = pipeline.reduce((total, fn) => {
   
  return fn(total);
}, 9);

console.log(res);

Je to elegantný, jednoduchý, ale veľmi expresívny kód. Žiadne statické metódy, žiadne
funkcia musí byť v classe, žiadne vohejbáky ako @FunctionalInterface alebo delegáty (C#).
Jednoduchý priamočiary kód.

Váčšina moderných programovacích jazykov má obyčajné funkcie, vrátane jazykov Python, PHP, JavaScript, Rust,
Go, Ruby, C++, F#, ...

Preto som napísal, že podľa mňa to je neexistencia obyčajných funkcií najväčšia chyba v dizajne Javy.

Re:Kotlin nebo Scala pro backend?
« Odpověď #98 kdy: 09. 11. 2020, 13:13:46 »
Citace
Co presne tam je za problem?

Reagoval som na použitie statických metód; tie neexistenciu obyčajných funkcií nevyriešia, ale
pridávajú vlastné problémy (statická metóda môže volať len statickú metódu a pracovať so statickými
atribútmi.)


A ja reagoval na tohle:
Citace
A takéto statické  metódy nemožno použiť všade, kde by sa dala použiť bežná funkcia; viď tzv higher-order funkcie.

A zajima me jakej problem s pouzitim statickych metod v souvislosti s higher-order funkcemi.


a ted me teda jeste zajima tohle:
Citace
statická metóda môže volať len statickú metódu a pracovať so statickými atribútmi.

Prijde mi to jako trochu absurdni si na tohle stezovat kdyz si zacal diskuzi tim, ze jave chybi obycejne funkce.
Funkce prece nemuze sama od sebe sahat na instancni promenne nejakeho objektu pokud na nej nema referenci.
A pokud staticke metode predam jako parametr referenci na nejaky objekt tak muze bez problemu volat instanci metody a pracovat s jeho promennyma.

Re:Kotlin nebo Scala pro backend?
« Odpověď #99 kdy: 09. 11. 2020, 13:14:25 »
Opravte ma ak sa mýlim, ale lambda sa len tvári ako anonymná funkcia. Je to len syntaktický
konštrukt, z ktorého kompiler spraví objekt.
Na tom přece nezáleží, co s tím udělá kompilátor. To bychom tu jinak neměli žádné objektové ani funkcionální jazyky – kompilátor to nakonec stejně vždy přeloží do imperativního kódu, protože dnešní procesory nic jiného neumí.

Java bohužiaľ nemá bežné funkcie, len metódy.
A tie nie sú first-class.
JVM nemá běžné funkce, jen metody, které nejsou first-class. Java jako jazyk má lambdy, které jsou first-class a metody jsou na ně převoditelné.

Čo bolo pridané v Java 8 je vohejbák. Java stále nemá obyčajné funkcie, len cez funkcionálne rozhrania
sa okľukou vytvárajú objekty a volajú potom metódy.
Nenazýval bych to vohejbákem, lambdy se nakonec podařilo do Javy integrovat hezky. Java byla navržena jako plně objektový jazyk (až na ty nešťastné primitivní typy), takže to, že jsou lambdy objekty, je v Javě správně.

Preto som napísal, že podľa mňa to je neexistencia obyčajných funkcií najväčšia chyba v dizajne Javy.
Java je záměrně navržená tak, že má malou základní sadu vlastností. Jsem silně přesvědčený o tom, že díky tomu se Java tak rozšířila. Takže to, co vy označujete za největší chybu dizajnu Javy, je podle mne naopak velká výhoda a příčina takového rozšíření. Že se Java nehodí na vše? Ano, to je samozřejmě pravda, jsou věci, pro které je JavaScript vhodnější než Java. Ale tak už tu máme GraalVM, kde můžete spouštět Javu i JavaScript.

Re:Kotlin nebo Scala pro backend?
« Odpověď #100 kdy: 09. 11. 2020, 16:47:21 »
Citace
Preto som napísal, že podľa mňa to je neexistencia obyčajných funkcií najväčšia chyba v dizajne Javy.

No to je argument stylu „největší chyba javy je, že to není javascript“.

Na skriptování v java ekosystému použijte třeba Groovy, Beanshell, jshell.

Re:Kotlin nebo Scala pro backend?
« Odpověď #101 kdy: 10. 11. 2020, 10:32:24 »
Asi se budu muset naučit oba a využívat dle situace ;)

Re:Kotlin nebo Scala pro backend?
« Odpověď #102 kdy: 10. 11. 2020, 10:39:23 »
Citace
Preto som napísal, že podľa mňa to je neexistencia obyčajných funkcií najväčšia chyba v dizajne Javy.

No to je argument stylu „největší chyba javy je, že to není javascript“.

Na skriptování v java ekosystému použijte třeba Groovy, Beanshell, jshell.

jak souvisi obycejne funkce se skriptovanim?

Re:Kotlin nebo Scala pro backend?
« Odpověď #103 kdy: 10. 11. 2020, 10:53:10 »
Citace
Preto som napísal, že podľa mňa to je neexistencia obyčajných funkcií najväčšia chyba v dizajne Javy.

No to je argument stylu „největší chyba javy je, že to není javascript“.

Na skriptování v java ekosystému použijte třeba Groovy, Beanshell, jshell.

jak souvisi obycejne funkce se skriptovanim?

To zalezi na tom co je to "obycejna funkce". Na to bysme potrebovali definici od autora terminu - Jano6.
Ja si to z toho ,co zatim rekl vykladam tak, ze mu vadi ze v jave tam musi napsat navic slovo static a ze to musi byt definovane uvnitr nejake tridy a pak uz to teda neni dost obycejne.

A pak souvislost se skriptovanim vidim v tom, ze script (typicky mensi velikost) je zahlcen nadbytecnym balastem.
U vetsiho programu to "tolik" nevadi, protoze procento balastu vuci uzitecnemu kodu byde vyznamne mensi.

Re:Kotlin nebo Scala pro backend?
« Odpověď #104 kdy: 10. 11. 2020, 16:49:03 »
Citace
Preto som napísal, že podľa mňa to je neexistencia obyčajných funkcií najväčšia chyba v dizajne Javy.

No to je argument stylu „největší chyba javy je, že to není javascript“.

Na skriptování v java ekosystému použijte třeba Groovy, Beanshell, jshell.

jak souvisi obycejne funkce se skriptovanim?

To zalezi na tom co je to "obycejna funkce". Na to bysme potrebovali definici od autora terminu - Jano6.
Ja si to z toho ,co zatim rekl vykladam tak, ze mu vadi ze v jave tam musi napsat navic slovo static a ze to musi byt definovane uvnitr nejake tridy a pak uz to teda neni dost obycejne.

A pak souvislost se skriptovanim vidim v tom, ze script (typicky mensi velikost) je zahlcen nadbytecnym balastem.
U vetsiho programu to "tolik" nevadi, protoze procento balastu vuci uzitecnemu kodu byde vyznamne mensi.

Vidím to podobně. V reálném programu je potřeba balast na organizaci kódu, takže se ta režie ve výsledku vyplatí.

Rozvolnění kódu, duck-typing a podobně by se mi v javě taky občas hodilo, nicméně na to můžu použít celkem bezbolestně třeba to Groovy a to i v existujícím java projektu. Nebo použít jiný jvm jazyk.