"Rust: egy programozási nyelv anatómiája"

Programozás

Már a programozós sorozatom elején elhatároztam, hogy a sok közül valamelyik programnyelvet részletesen is ismertetem majd. Már akkor említettem azt a programozási nyelvet, amelyik szerintem a legalkalmasabb akár a középhaladó programozás-tanulásra is, de akár a legprofibb rendszerprogramozás igényeihez is. A kezdők számára az a legvonzóbb vonása, hogy a programjaink feldolgozása (fordítása) során a lehető legtöbb lehetséges hibaforrást felismeri, és nagyon világosan elmagyarázza, hogy mit és hol rontottunk el.

A teljes cikk itt olvasható.

( szemet | 2019. 01. 15., k – 09:41 )

Képtelen vagyok eldönteni ki lehet ennek a cikknek a célközönsége. Egyrészt a fórum alapján ahol megjelent: random netes újság olvasó - és a nyelvezet is ennek megfelelően próbál egyszerű lenni.

DE akármennyire is próbálkozik, ha egy cikkben olyan szavak vannak mint: memóriacím, adatstruktúra, paraméterek - akinek ezeknek a jelentése dereng azoknak már korrektebb/mélyebb/technikaibb leírásra van szüksége amit más fórumon fog keresni, akiknek meg nem, azok szintén nem tudom mit nyernek - nekik jobb lenne erre egy sokkal felszínesebb újságírós beszámoló kb ezen a szinten:

új nyelv / Mozilla kezde és Firefoxot egyes részeit írják benne (meg a Fuchsia egyes részeit, meg még kitudja mit - de olyasmi kell ami érdekelheti az átlagolvasót), könnyebb többmagos processzorra programozni benne nagy teljesítményű kódot, szigorúbb memóriahasználati szabályai vannak mint a többi hasonló célra használt nyelvnek ezzel véd bizonyos biztonsági rések ellen stb stb...

Szóval nekik abszolút a végfelhasználói előnyök szempontjából is elég lenne bemutatni.

Igen, de ez nem nekik szól mert nem annyira mélyen technikai (a kódpéldák ellenére), akkor benne lennének olyanok amik minden programozóknak szánt Rust ismertetőben benne vannak, mert értik a kontextust: gépi kódra fordul (látod még ez az alapinfo is hiányzik: azt írja hogy, lefordul de abba nem megy bele hogy mire), nincs runtimeja (C-t libraryt 0 overheaddel hív), nincs benne GC - ezt helyettesíti az ownership , a C/C++ területére kíván betörni, nincs data race

Szerintem ezekbe azért nem megy bele mert ennek a kontextusoknak az ismeretét nem akarja feltételezni (lásd megint a fórum ahol megjelent), de akkor meg minek megy kódpélda mélységig?

( kmARC v | 2019. 01. 15., k – 10:38 )

Ez a vidékiközépiskolástanárbácsis, körmondatos, terjengős-kedveskedős szómaszlag aláaknázza a cikk hitelességét szerintem; nem kelt professzionális hatást.

A szerző lehet, hogy ért hozzá, de akkor komolyabb stílusban is írhatna róla. Kár érte.

Igen ezek nálam is pengeélen táncolnak, de csak akkor esnek le ha tárgyi baromság is belekerül mellé: azt első olvasatra nem vettem észre benne (leszámítva hogy én a Rustot nem nevezném funkcionális nyelvnek de ez csak definíciós kérdés...)

Nem ugrik be pontosan de az annyira általános hogy már nevesítették is mint egyfajta ismeretelméleti/tájékozódási/újságolvasói paradoxont:

elolvasol egy cikket a saját szakterületedről és a plafonon vagy: hogy lehet egy beszámoló ennyire szakszerűtlen ne adj isten hibáktól hemzsegő - majd rátérsz a következő cikkre (ami nem a szakterületed) és simán benyeled relatíve hitelesnek ;)

szerk, megvan: https://en.wikipedia.org/wiki/Gell-Mann_amnesia_effect

( persicsb | 2019. 01. 15., k – 10:45 )

Nagyon-nagyon gáz ez a cikk. Kálmán László nyelvész jobb, ha a nyelvészetnél maradna.

"A Rust is funkcionális nyelv, vagyis az eljárások függvényszerűek: a paramétereiket úgy fogják fel, mint a függvények argumentumait, amikre alkalmazzuk őket (bár nem kell minden eljárásnak értéket „visszaadnia”)."
LOOOOOL. Kálmán László nem tudja, mi az az FP.

A problema ezzel az, hogy a hupon majdnem mindenki tud magyarul (idealis esetben anyanyelvi, rosszabb esetben harmincot+otvenketto szinten), esetleg meg 1-2 idegen nyelven is, szoval legalabb valamennyire ert a nyelvekhez.

Talan ilyen "funkcionalis nyelv" szintu baromsagot nem mondunk.

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Ok. De ez definíciós kérdés, szakmai (a mi szakmai) szemszögünkből rosszul használt egy definíciót, ha azt írja helyette hogy funkcionális nyelvi elemeket is támogat akkor már szavunk se lehetne.

Persze az egyértelműen látszik, hogy nem kéne neki ezt tanítani - de a humán területen mindig akkora a zavar a reáltudományokkal kapcsolatban, hogy én már mindenkinek aki képes alapvetően helyesen látni dolgokat örülök ;)

Pl. amikor elolvastam az "Elemi részecskék"-et tök örültem amikor ezt a szakaszt olvastam:

"Ettől kezdve a tudósok két elmélet közül választhattak. Vagy a részecskék viselkedését meghatározó rejtett tulajdonságok nem voltak helyhez köthetőek, ami azt jelenti, hogy egy részecske tetszés szerinti távolságból pillanatnyi hatást gyakorolhat egy másik részecskére, vagy le kellett mondani arról az elméletről, mely szerint az elemi részecskéknek megfigyelhető belső tulajdonságai vannak. Ebben az esetben a kutatók mélységes ontológiai űr előtt találták magukat, amelytől csak a radikális pozitivizmus alkalmazásával szabadulhattak, vagyis ha megelégedtek azzal, hogy olyan matematikai formalizmust fejlesztenek ki, amely előre megjövendöli azt, ami vizsgálható, és ezáltal végleg lemond a valóság alatti tartományról. Természetesen a kutatók többsége ezt az opciót választotta."

Egyszerűen nem is vártam (és nem is vártam EL) a Bell egyenlőtlenség filozófiai következményeinek tárgyilag helyes összefoglalását egy regényeben. A legtöbb humán műveltségű ember addig jut el a területen: "a tudósok is bebizonyították minden mindennel összefügg". Ettől persze még írhatnak jó regényt! Ez csak egy értékelendő plusz.

Olyan rossz ez a magyarázat (nem definíció) rá?

Bár nem "funkcionális nyelvről" (azmiaz?) csak funkcionális programozásról, de itt a wiki bevezető szövege:

In computer science, functional programming is a programming paradigm—a style of building the structure and elements of computer programs—that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. It is a declarative programming paradigm, which means programming is done with expressions or declarations[1] instead of statements. In functional code, the output value of a function depends only on the arguments that are passed to the function, so calling a function f twice with the same value for an argument x produces the same result f(x) each time; this is in contrast to procedures depending on a local or global state, which may produce different results at different times when called with the same arguments but a different program state. Eliminating side effects, i.e., changes in state that do not depend on the function inputs, can make it much easier to understand and predict the behavior of a program, which is one of the key motivations for the development of functional programming.

https://en.wikipedia.org/wiki/Functional_programming
A rust nem lisp vagy haskell, de az, hogy függvényeket írunk benne, szvsz bőven teljesíti amit a wiki ír a paradigmáról. Amúgy meg

It depends on what qualifies as a “functional programming language.” If by “functional” we mean purely functional, then no, but neither by that definition are OCaml, SML, or the various lisps. If by functional we mean supporting higher-order programming, then yes, but then so are Java, C#, and C++.

https://www.quora.com/Is-Rust-a-functional-programming-language

Ház ez az, a Rust a wikis definíció nagy részét alapvetően nem teljesíti.

Rustban pl. pont a nem mutáló (perzisztens) adatstruktúrák (amik implemetálása amúgy GC nélkül PhD szintű kérdés - Rustban is Refcountal (RC<>) van a legtöbb próbálkozás) helyett van a kontrollált mutáció (ownership) hasonló előnyökkel:pl. biztonságos párhuzamos programozás - divatba is jött a koncepció visszafelé irányba is lásd: haskell linear types)

A második rész viszont igaz: vannak (és bátorítva vannak) a magasabbrendű függvények. (map, fold, filter és barátaik)

Szerintem sem sikerult jora az iras, de azert a 444 "mellekletenek" a cikkei valoszinuleg nem szakmabelieknek szolnak...

Valoszinuleg nem nagyon nezi at senki ezeket szakmai szemmel, ami kar, mert akar mar par hivatkozassal is javithatnanak egyebkent az osszkepen.
(Ha mar Rust es funkcionalis nyelvek: https://www.fpcomplete.com/blog/2018/10/is-rust-functional, illetve a cargo, mint hatrany... hat akkor ahol meg nem hasznalhatod a non-lexical lifetime-t, azt minek lehet nevezni? ld: lifetimehttps://rust-lang-nursery.github.io/edition-guide/rust-2018/ownership-a…).

Viszont en nem banom, ha nyelvesz ir ilyen cikket, csak a lektoralas, hivatkozas... az azert elferne.

( sz332 v | 2019. 01. 15., k – 10:55 )

Nem tudom értékelni. Inkább maradjon a nyelvészkedésnél.

( gee v | 2019. 01. 15., k – 14:07 )

Én úgy szoktam meg, hogy member function, már a method kifejezést se szeretem.
Erre a cikkben: módszerek

Nyugtassatok meg, hogy ez csak azért van, mert nagyon magyarítani akartunk, de valójában senki nem használja így. Ugye nem?

( gee v | 2019. 01. 15., k – 14:19 )

Illetve plusz egy kérdés merült fel bennem, ezt valaki, aki ért a nyelvhez, megválaszolhatná:

OOP-ban az öröklődésnek az az értelme, hogy egy helyen legyen leírva olyan tevékenység, amit aztán minden leszármazott használhat. Ha változtatni kell, akkor egy helyen változtatjuk meg.

Szóval ha a példát nézem, akkor mondjuk van egy kerület függvény, ami visszaadja a síkidom összes oldalának a hosszának az összegét. Ha van valami trükkös síkidom, mondjuk kör, aminek nem szakaszok alkotják az oldalát, vagy a cikkben említett egy két oldalával és a közöttük levő szöggel megadott háromszög, akkor ezekben vagy implementálja az ember az adott síkidomhoz való kerület számolást (pl. a kör esetében), vagy olyan függvényeket implementál, ami ha a határoló szakaszokat lekérdezi valaki, akkor kiszámolja, hogy OK, a megadott szög és oldalak alapján a három oldal, amit kérdeztél, a, b és c hosszú, aztán ezt az eredményt már az örökölt kerület számoló függvény fel tudja használni.

Úgy tűnik a cikk alapján, hogy ez pont fordítva van a Rust nyelven: minden egyes síkidom esetén, ahol a Trait-ben benne van a kerület, a kerület kiszámítást implementálni kell. Annyiszor, ahány féle síkidomunk van (és a kétféle módon megadott háromszög két különbözőnek fog számítani). És várhatóan a négyzetnek, a téglalapnak, a rombusznak és minden más négyszögnek ugyanaz lesz az implementációja. Szóval ugyanazt a függvény törzset kell leírni sokszor.

Ha ez tényleg így van, akkor ez nem tetszik.

Trait metódusoknak lehet alapértelmezett implementációja (ami egy szűkebb tartományát használja a metódusoknak), ugyanúgy mint Haskell typeclassoknál. (Sőt manapság asszem már Java interfaceknél is)

Egy példa: https://doc.rust-lang.org/std/cmp/trait.Ord.html
Van 1 darab "required" metódus a a többi "provided" az alapértelmezett implementációval ami mind az 1 db kötelezően implementálandó metódust használja.

Mondjuk a Java interfészek esetén ez csak egy mellékhatása a streamezésnek. A streamek bevezetésével ki akarták terjeszteni a java.io-ban és a java.util-ban meglévő interfészeket a streamek támogatására, ez viszont azt jelentené, hogy az összes meglévő kódbázis, ami ezen interfészeket implementálja, eltörik. Így azt találták ki, hogy interfészben lehet default implementáció, hogy mégis legyen modernebb java.util.List stream támogatással, de ne törjön el sok-sok java.util.List implementáció.

Az öröklés értelme nem a kódújrafelhasználás, hanem a polimorfizmus és kódújrafelhasználás együtt. Bizonyos OOP-s körök ezért mondják, hogy még egyszeres öröklést sem illik használni.
a) Ha kódújrafelhasználás kell, akkor kompozíciót használjunk.
b) Ha polimorfizmus kell, akkor interfészimplementálást. Rustban ugye az interfészt trait-nek, a polimorf objektumot trait objektumnak hívják. Ez kicsit több gépeléssel jár, mintha öröklést használnánk, de azt nem jelenti, hogy ugyanazokat a metódusokat többször le kellene írni (amúgy a Rustot egyáltalán nem bőbeszédű nyelvnek ismertem meg), működik a DRY (vagy a nekem szimpatikusabb WET) stratégia.

Korlátozott öröklés van Rustban: a trait-ben lehet függvénydefiníció is (tehát nem csak deklaráció), de az nem érhet el adattagot (mert a trait-ben ugye nincs olyan).

A class különírása struct- és impl-blokkokba senkit ne tévesszen meg, ez nyelvtani különbség, eddigi meglátásom szerint a szemantika ugyanaz, mint a class esetén. Egészen odáig, hogy az összetartozó struct-ot és impl-blokkot nem írhatjuk különböző modulokba. Az interfészimplementálás pedig „class ...: public ...” és „class ... extends ...” helyett „struct ..., impl ... for ...”. Öröklés sem emiatt nincs, lehetne pl. struct-ot örökölni, aztán azokat implementálni.

Ez nem egyedi dolog egyébként, ha jól rémlik, a Smalltalk ennek a gyakorlatnak az őse, de pl. a Nim is átvette.

Végül egy technikai részletkérdés, hogy máshol a virtuális metódustábla általában a class-en belül van, Rust-ban a struct-tól külön, fat pointerrel mutatunk rájuk. Ezzel kicsit spórolunk, amikor polimorfizmusra képes objektumot használunk nem polimorf módon. Szemantikailag megintcsak nem sok vizet zavar.

A geometriás példára:

> a három oldal, amit kérdeztél, a, b és c hosszú, aztán ezt az eredményt már az örökölt kerület számoló függvény fel tudja használni.

Ez tipikusan nem tűnik örökléses példának még „megengedő” nyelvben sem, mert az (a, b, c) hármas nem adattag, hanem számolt adat. Free függvényt, vagy statikus metódust javasolnék. Ha ilyen formában kell eltárolni, az más. Akkor pedig egy objektum legyen, annak legyen egy „new_from_angle()” konstruktorfélesége is arra az esetre, ha úgy akarják megadni.

Lényeg:

  • akármelyik nyelvben is, ha más módon kell kiszámolni a kerületet, arra más metódust kell írni, pl. a különböző módon megadott háromszögeknél, vagy a körnél. És szükség van implementációnként eltérő adatszerkezetre is. Ekkor semmit nem kell örökölni, ezek különböző dolgok.
  • Ha valamit ugyanúgy kell kiszámolni, az pedig egységesíthető. Máshol mehet örökléssel, itt csak kompozícióval.

> És várhatóan a négyzetnek, a téglalapnak, a rombusznak és minden más négyszögnek ugyanaz lesz az implementációja.

Szuper példa. Arra, hogy miért jó a Rust.

Öröklésre az „is-a” relációt szokták mondani, de ez nem mindig intuitív. Lásd innentől a fejezet végéig:
https://isocpp.org/wiki/faq/proper-inheritance#circle-ellipse

Szóval egyáltalán nem biztos, hogy
a) egy síkidom - egy „objektumosztály” kell legyen
b) síkidomok örökölhetik egymást, még akkor sem, ha matemtikailag fennáll az „az egy” reláció.

OOP-ben elég sokáig tudunk kezdőnek számítani, előnyös, ha a nyelv több korlátot állít (ha azok a korlátok ésszerűek).

> a három oldal, amit kérdeztél, a, b és c hosszú, aztán ezt az eredményt már az örökölt kerület számoló függvény fel tudja használni.

Ez tipikusan nem tűnik örökléses példának még „megengedő” nyelvben sem, mert az (a, b, c) hármas nem adattag, hanem számolt adat.

Lehet, hogy egy kicsit túlgondoltam. Ugye a cikkben azt írta az ember, hogy pl. kétféle háromszög "osztály" lesz, egy, amit három ponttal adunk meg és egy másik, amit két ponttal, egy szöggel és egy szakasz hosszal. És erre írta, hogy minden ilyen osztályban külön külön le kell implementálni a kerület kiszámolását.
Nekem erre az jutott eszembe, hogy én inkább úgy közelíteném meg, hogy a kerület kiszámítása az legyen az összes oldal hosszának az összege. És igen, az adott osztályokban meg implementálnék olyan függvényt, hogy add vissza az oldalaid számát, add vissza az oldalaid hosszát, stb.

Na, nem beszélek bele többet, évtizedek óta nem programoztam semmit, azóta a világ sokat változott, én meg csak felejtettem.

( prion | 2019. 01. 16., sze – 09:33 )

Nyilván tud programozni. Egyetemen is tanított ilyesmit. Asszem számítógép les nyelvészet volt a kurzus. A formális nyelvek téma mentén össze ér a kettő.

Amúgy szerintem is lehetne pedagógusabb, de ő legalább csinálja.

( Kiskübi v | 2019. 01. 22., k – 14:41 )

... Egyébként kíváncsi vagyok, ki találná ki, hogy a „nem tisztán funkcionális” Rust melyik jellemzője miatt közelíti meg a funkcionális paradigmát jobban, mint a többi „nem tisztán funkcionális” nyelv. Elsőre nem gondoltam volna, de egy idő után meg lehet sejteni. :)

( bucko | 2019. 01. 23., sze – 09:20 )

fp = tizedestört
Tetszik.

Számomra roppant tanulságos volt a leírás és a hozzászólások is.
Ha eddig nem tudtam volna, végképp meggyőzött az assembler előnyeiről - hátrányairól.

A fixpontos ábrázolás is tizedestört, a lebegőpontos is. Épp ezért pontatlan megfogalmazás, és nem is jó, félrevezethet.
Például sokan azt hiszik, hogy mivel a 64 bites lebegőpontos egészen 10^308-ig tud ábrázolni számokat, ezért a 64 bites egészek elférnek benne, de sajnos ez nem igaz.

A fixpontos kettedestort, a floating point meg a "tudomanyos alak" binaris megfeleloje.

Egyebkent ha a Kiskegyedbol tajekozodsz informatikai temaban, meg is erdemled!

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin