Názory k článku Funkcionální programovací jazyk F#

> ale na krabici se to pěkně vyjímalo

“IBM Prolog had added a lot of OO extensions, when asked why he replied: ‘Our customers wanted OO Prolog so we made OO Prolog’.”

Tak tak, dokonce i na přebalu Turbo Assembleru se jednu dobu vyjímalo, že podporuje OO (ať již to tedy znamená cokoli, podle mě to TASM nikdy neuměl :-)

Ten Prolog taky nebyl zrovna druhý Smalltalk, ale asi to na manažery zabralo :)

no vida chlubi se tim i v manualu https://archive.org/details/bitsavers_borlandturemblerVersion5UsersGuide_13693550/page/n9/mode/2up

(ale ten box TASM 4 nebo 5 jsem nenasel)

OOP v TASM je popisane v manuali v kapitole 4 - zacina na strane 43ff
http://bitsavers.informatik.uni-stuttgart.de/pdf/borland/turbo_assembler/Turbo_Assembler_Version_5_Users_Guide.pdf

5. 9. 2023, 23:22 editováno autorem komentáře

Díval jsem se, díky.

Jinak kde píšou "object", tak myslí něco na rozhraní mezi objektem a třídou a kde píšou "object instance", tak myslí object. Jinak to vypadá, že se objekty konstruují v compile time (ale nezkoušel jsem, popravdě jsem TASM vždycky používal jen v základním režimu, tyto věci mi nikdy nepřišly v assembleru nutné.)

Vdaka, na serial o F# som sa velmi tesil.

Mam niekolko veci - k onrazku o .Net platforme, C# vychadza z C++ a nie z Javy (nevola sa java++). C# a Java mali vela spolocneho lebo sa snazili riesit ten isty problem, len C# prisiel trosku neskor a tak sa poucil z chyb, ktore spravili tvorcovia jazyka Java.

> Poznámka: pokud důvěřujete skriptům staženým z internetu a taktéž důvěřujete software firmy Microsoft, může být instalace triviální (jedná se o verzi 6.0.x a nikoli 7.0.x, instalace zabírá zhruba 0,5 GB):

Dotnet SDK sa instaluje normalne cez package manazer, na debiane si treba pridat repo, na Ubuntu je uz v standardnych distribucnych balickoch, takze staci `apt-get install dotnet-sdk-6.0`

Casove vychazi C# z J++, ktery M$ (bohudik!) musel zabit. A ja pouzival prvni verzi C# (DVD vychazela zdarma) a byla to tak z 95% Java, urcite ne C++. Uz jen takova jedna z veci, ktera je v C++ trosku unikatni, je vicenasobna dedicnost. V C# a Jave je namisto toho pouzit koncept rozhrani.

Ja chapem, ze sa to mnohhim ludom zdalo podobne, ale ja som od C# 2 robil z oboma a tie jazyky mali viac rozdielov ako spolocnych veci. Ano oba boli OOP, ano obe mali Main, ale to je tak asi vsetko. Do C# od 3/3.5 pribudlo plno funkcionalnych veci (trufol by som si povedat, ze viac ako ma javascript dnes) a ten styl praktickeho programovania nemal s Javou uz spolocne nic.

Ja taky delal v obou a C# proste byla Java obslehnuta do takove podoby, aby to jeste nebylo pravne napadnutelny (tedy nemohl to byt stejny jazyk, tak ok, udelali par vylepseni, ale zkopirovali z javy vsechny nesmysly, ktere se potom postupne opravovaly). Z C++ tam tezko neco najdeme, ale mozna se dam poddat.

Tak nějak. A Java zase byla do velké míry kopie OpenStepu rovněž od Sunu (jen to není na první pohled vidět kvůli syntaxi). Javu (tehdy se ještě jmenovala jinak) Sun původně vyvíjel pro embedded (pračky, televize…). Trochu se to pak zvrtlo.

Jistěže vychází C# z Javy, nejen koncepčně a syntakticky, i způsob překladu a běhu (VM, GC) byl na začátku na chlup stejný. Později pak přidali různé ptákoviny, jako podporu dynamických jazyků.

Ocapali to teda riadne. Vylepšovať to začali až po čase. Bohužiaľ sa do jazyka dostal Javacky public static void Main nezmysel. Funkcie nie sú first-class. A tieto počiatočné chyby sa už úplne odstrániť nedajú.

ale dají, public static void Main už psát nemusíte v C# 10 už stačí do helloworld.cs dát

Console.Write­Line("Hello World!");

a funguje :-). U funkcí netuším.

Ide to aj s funkciami. Avšak ste obmedzený na jeden súbor, typy musíte definovať na konci súboru. Ide v podstate o to, že kompilátor na pozadí z toho spraví sám triedu a sám vytvorí ten nešťastný public static void Main. Preto som aj hovoril, že sa to dnes už nedá úplne zrejme napraviť. Je to ako keď si zle navrhnete základy domu a potom sa už s tým veľa nedá spraviť.

Ja som tie top-level statements vrelo privítal, je to super vec. Hlavne na kratšie programy, tutoriály, ukážky, testy a pod. Autori C# sa naozaj snažia vylepšiť syntax jazyka. Ale stále tam narážajú na tie základy...

(Mimochodom, v nadchádzajúcej verzii Javy sa ide spraviť obdobná vec.)

Lenze C# je primarne OOP jazyk, nie funkcionalny, aj ked ma milion funkcionalnych prvkov. No osobne by som ani nechcel globalne funkcie.

Toľko sa píše o histórii jazyka F#, že nám tam vypadlo jeho stručné definovanie. F# sa zvykol definovať ako first-class funkcionálny programovací jazyk pre .NET. Avšak v poslednom čase autor Don Syme uprednostňuje nasledujúcu definíciu jazyka: F# je sucinktný programovací jazyk, ktorý umožňuje písať korektný, robustný a výkonný kód na platformách .NET a JS.

Čo sa týka kníh, tak v novembri by mala vyjsť kniha F# in Action vo vydavateľstve Manning.
https://www.manning.com/books/f-sharp-in-action

Čo sa týka skriptov, tak tam je vhodné si definovať nejaký alias.
Bash na Linuxe:

alias fx='_fsi(){ dotnet fsi "$@";}; _fsi'

Windows bat file fx.cmd

@echo of

dotnet fsi %*

A potom sa skripty spúšťajú fx first.fsx. (Skripty majú príponu fsx.) Skripty majú bohužiaľ počiatočné zdržanie, pokiaľ sa to všetko pochrúme. Nová verzia .NET 8 sľubuje JIT, tak som zvedavý, či sa to prejaví.

sucinktný? Tedy stručný?

Schválne som tam dal ten anglicizmus, pretože slovo stručný (brief) to nedostatočne vystihuje. Succinct je zhustený, jadrný, stručný a jasný. Čiže s minimálnym kódom dokážete jasne vyjadriť širokú škálu ideí, form.

"lakonický" ?

Jak s Filipem Makedonským: “If.” :)

To slovo neexistuje :) Nicméně F# je spíš Frankenstein, protože ho chtěli napasovat na .NET. MS (resp. MS Research) vyvinul několik mnohem lepších funkcionálních jazyků.

Tak dá se říct, že jednou z nejlepších vlastností F# je, že běží a dobře kooperuje s .NET. A jednou z nejhorších vlastností F# je, že běží a musí dobře kooperovat s .NET :-)

[ale stejně to má Scala nebo Clojure, prostě si zvolili ekosystém s mnoha skvělými vlastnostmi a mnoha programátorskými peklíčky]

Scala je IMHO funkcionálně hezčí, vyřešili to lépe, ale stejně je JVM koule na noze.

Pamatuji si na prezentaci Radka Mička, kde porovnával Scala a F#... nějak tak z hlavy: "F# jsou dva jazyky v jednom."

Jeho články zde https://www.root.cz/autori/radek-micek/

To sedí. Dva polovičaté. Ale občas to nemusí vadit, když někdo trvá mermomocí na .NET. Ovšem i MS se posunul, třeba jejich jazyk Koka je o dost vymakanější.

Když už tu je článek o F#, dám odkaz na zajímavou knížku o funkcionálním doménovém modelování, kde se používá F#: https://books.google.com/books/about/Domain_Modeling_Made_Functional.html?id=qA9QDwAAQBAJ

Ten jazyk je v této oblasti trochu zvláštní volba, protože zas až tak funkcionální není.

No ja neviem, F# má byť podľa dostupných zdrojov v prvom rade funkcionálny a až potom všetko ostatné. Prečo teda až tak funkcionálny nie je?

Čo sa týka modelovania domén, autor knihy v tom má očividne absolútne jasno. Má na tú tému veľa prednášok, myslím, aj nejaká séria na tú tému existuje a potom jeho stránky, kde to ešte rozvíja.

Využíva samozrejme typový systém a všetky tie vychytávky okolo, aby to bolo stručné, popisovalo to pre doménu platné dáta a stavy a protestovalo pri pokuse písať neplatné.

Ve srovnání se všemi ostatními rozšířenými funkcionálními jazyky má nejslabší typový systém, slabší i než OCaml a Scala (ale zase silnější než Rust). To není nutně nic špatného, je to prostě kompromis pro .NET. Ale k tomu modelování se hodí nejméně.

GADT?

Například. Nebo jen HKT, aspoň dříve, vývoj F# nijak podrobně nesleduju. Ale autor se k tomu určitě dostane.

Sila typového systému je podľa mňa charakteristika, ktorá neurčuje, či je jazyk funkcionálny alebo nie je. Aký typový systém majú napríklad Lisp, Scheme, Racket alebo Elixir? A sú to funkcionálne jazyky alebo nie sú?

Inak chápem. Pokiaľ sa ale bavíme o modelovaní domény, kde sa toho zúčastní aj odborník na doménu, tak je otázka, či jednoduchší typový systém nie je skôr výhoda ako nevýhoda. Zvlášť keď ide o podnikové aplikácie a nie o vedecké a keď odborník na doménu nie je matematik a nestretol sa s "kombináciou závislostných a lineárnych typov".

A nad rámec toho chápem aj snahu mať formálne overiteľný program napísaný v jednom jazyku, len je otázka, či to nie je za cenu výrazného zúženia okruhu ľudí, ktorí tomu budú rozumieť a či overenie bežnými formálnymi metódami nebude nakoniec prístupnejšie.

Ale to už je asi skôr iba filozofická úvaha...

Súhlas. Pokročilá práca s datovými typmi a funkcionálne programovanie sú dve rôzne veci.

Ešte by som doplnil, že je ošemetné hovoriť o jazyku, že je lepší alebo horší ako ten druhý. Je jazyk s prokročilými typmi lepší ako F#, hoci nemá prakticky žiadne knižnice? K jazyku patrí aj jeho tooling, dokumentácia a množina jeho knižníc.

Taký Golang má len zlomok možností, ktoré poskytujú funkcionálne jazyky, ale tie sa mu v jeho doméne (napr. terminálové aplikácie) nevyrovnajú.

Jo, jsou to dvě různé věci.

S tím mocným formálním aparátem to je pravda, čím sofistikovanější, tím méně lidí tomu rozumí.

P.S. Když už se tak hezky bavíme, psal někdo DDD v nějakém funk. jazyce? A pokud ano, jen entity, nebo i workflows? Občas to je totiž docela hukot, například absence heterogenních kolekcí občas bolí. Nebo když vzájemné závislosti nejdou DAG.

“Aký typový systém majú napríklad Lisp, Scheme, Racket alebo Elixir? A sú to funkcionálne jazyky alebo nie sú?” Elixír neznám, ale ty zbylé nejsou čistě funkcionální. Nicméně takto napsané to fakt nesouvisí a moje formulace byla neobratná. Jak už zaznělo, F# je kompromis mezi OOP a FP, a to celkem povedený z pohledu cílové skupiny. A jsem rád, že tu paralelně pojedou články o OCamlu, tento komparativní přístup by se mohl osvědčit.

Je nejaky racionalni duvod, proc nefunguje length s retezcem?

Racionální asi ne.

A neracionalni?

Že to neumí přetížení. Tyto jmenné “konflikty” jdou přitom efektivně řešit lokálními jmennými prostory.

Spojový seznam 'a list není string a OCaml nemá overloading. Například ani indexování není overloadnuté: indexování polí se provádí arr.(i) a indexování řetězců str.[i].

Racionální důvod je typová inference a rychlost kompilace.

A nejsou to dnes už spíš pseudodůvody, hlavně tedy ta rychlost kompilace?

ehm?

Potřebuješ něco vysvětlit?

Zrovna třeba Rust je příkladem jazyka s hodně pomalým překladačem, na to si stěžují i rustí fanatici. Ze Swiftu se v jeho začátcích odstraňovaly některé vlastnosti (zejména implicitní koerce), aby byl překlad rychlejší (ne že by tam byly potřeba, i když jsou jazyky, které bez nich dost trpí).