Betűkből akarok (32-es) számrendszert csinálni, de nem ismerek programnyelveket. Melyiket érdemes megtanulni?

A Pythont itt tudod megtanulni:

[link]

"Nem tudom, hogy hogyan fog működni, de nagyon erős megérzésem van ennek az eredményességét illetően."

Máskor is ilyen rosszak a megérzéseid?

Itt van ez megírva C++ nyelven:

[link]

Lehet ezen rugózni, de teljesen felesleges. Eleve a legtöbb adat esetén nem elégséges feltétel az, hogy a típusa megfelel a követelményeknek, hanem egy adott tartományba is kell esnie, csak adott formátumot vehet fel, stb., ezért így is-úgy is ellenőrizni kell. (Halkan teszem hozzá, csak abban az esetben van az, hogy "Átadja neki, aztán vagy elszáll majd tőle futás közben a kód, vagy nem.", ha nem ismered a dinamikus típusátalakításra vonatkozó, amúgy elég egyszerű szabályokat. Ha ismered, akkor sokkal kisebb eséllyel fog bármilyen meglepetés érni - ha pedig becsületesen teszteltél, akkor semmilyen meglepetés nem fog érni.)

Azt meg csak mellékesen, hogy több olyan nyelvi lehetőség van a modern statikus nyelvekben is, amelyek tpikusan dinamikus típuskezelésű nyelvekre jellemzők, pl. a függvénytúltöltés révén a függvényt különböző típusú argumentumokkal hívhatod meg - így meghívhatod stringgel akkor is, ha egyébként csak int-tel adna érvényes eredményt, és persze a fordító nem fog szólni.

Vagy az, hogy egy adott osztályból példányosított objektum helyén bármelyik másik származtatott osztály is átadható - arra viszont nincs garancia, hogy a fogadó függvény bármit is tud kezdeni a származtatott osztállyal.

De pl. float-ból is simán csinálok int-et, és nem szól a fordító (-Wall).

Vagy a klasszikus példa:

int n = atoi("asd");

Simán megcsinálok neked egy ilyet, és le is fordul, még warningot sem kaptam. Nem szól a fordító, mert nem szintaktikai típushiba. De attól még az a bemenet értéktartománya nem feleltethető meg az int valid értéktartományának, és az ilyeneken jó nagyokat lehet bukni.

Tehát most azzal akarod védeni a dinamikus típusozást, hogy bezzeg statikus nyelvekben is lehet csinálni hasonlót és az bizony milyen veszélyes?

Epic!

#27 Bár már az alapelképzelés is hiábavaló, miszerint azzal akarod védeni a dinamikus típusozást, hogy HA odafigyelsz, jól tesztelsz, betartod a szabályokat, akkor elkerülöd a hibát, ugyanakkor támadod a statikus típusozást azzal, hogy HA angyon figyelmetlen vagy, akkor ott is lehet hibákat okozni, azért reagálok az irományodra.

Kezdjük ott, hogy amit leírtál az úgy 60%-ban egyszerűen nem igaz.

"a függvénytúltöltés révén a függvényt különböző típusú argumentumokkal hívhatod meg - így meghívhatod stringgel akkor is, ha egyébként csak int-tel adna érvényes eredményt, és persze a fordító nem fog szólni"

Ha meg tudom hívni stringgel a függvényt, akkor stringre is értelmes eredményt ad. Hogy ez NEM az az eredmény, amit látni akarok, az egy teljesen más kérdés, ami nem tartozik a type safety témaköréhez. A fordító pedig igenis szólni fog, ha olyan paraméterezéssel hívok meg egy függvényt, ami egyszerűen nem létezik.

"Vagy az, hogy egy adott osztályból példányosított objektum helyén bármelyik másik származtatott osztály is átadható - arra viszont nincs garancia, hogy a fogadó függvény bármit is tud kezdeni a származtatott osztállyal."

Dehogynincs garancia. Ha a függvény az ősosztályt várja paraméterül, akkor az őszosztály interfészét látja, és azt tudjuk a függvényen belül elérni. És az öröklődésnek pont az az egyik non plus ultrája, hogy a származtatott osztályok ÖRÖKLIK az ősosztály interfészét, és ha nincs felüldefiniálva, akkor a függvénydefinícióit is. Az egyetlen hiba újfent az lehet, ha a származtatott osztály adott függvénye nem pont azt csinálja, amit az ősosztálytól várok. Újfent, nem type safety kategória.

"Vagy a klasszikus példa:

int n = atoi("asd");"

Nagyon rossz példát választottál, az atoi függvény failsafe, sosem dob hibát. Ameddig tudja konvertálni a stringet, emgteszi, ha nem tudja, akkor 0-t ad vissza. Hibaforrás újfent nincs.

"De attól még az a bemenet értéktartománya nem feleltethető meg az int valid értéktartományának"

Nem is kell, a bemenetnek karakterláncnak kell lennie. Az is. A kimenetnek meg int-nek. Az is. Az, hogy a karakterláncban egy konvertálható szám foglal helyet csak haba tortán, a program működését nem befolyásolja, legfeljebb a végeredmény nem tetszik majd nekünk. Viszont. Hiba. Nincs.

A fent említett dolgok egyébként dinamikus típusozású nyelvben is simán előfordulhatnak, csak ott a nyelv nem biztosítja a kimeneti érték típusát, ergo azon felül, hogy nem azt kapod eredményül amit vársz (ami önmagában még nem okoz runtime errort) még az is benne van a pakliba plusz óvintézkedés nélkül, hogy még nem is olyan típusú érték jön vissza, mint amire számítasz (ami viszont már igen könnyen vezet runtime errorhoz).

Eddig adtál a szarnak egy lengőset. Kívánod folytatni?

"Bár már az alapelképzelés is hiábavaló, miszerint azzal akarod védeni a dinamikus típusozást, hogy HA odafigyelsz, ..."

Félreérted.

Azt mondom, hogy a statikus típusozásnál támaszkodsz arra, hogy a nyelv megtalálja helyetted a hibát (hibák egy részét), dinamikus esetén meg eleve úgy indulsz neki a dolognak, hogy feltételezed, más típusú is lehet az adatod, mint amire számítasz, és tudod, hogy nem fogsz semmilyen hibát vagy warningot kapni emiatt. Emiatt nagyon odafigyelsz erre, és ahol szükséges, explicit castolsz, mindenhol máshol változó típusúként tekintesz az adatra (nem feltételezed róla, milyen típusú).

", az egy teljesen más kérdés, ami nem tartozik a type safety témaköréhez."

Ja, most nem ahhoz tartozik? De ha a dinamikus típusozásnál előjön tök ugyanez, akkor odatartozik? Akkor most el kéne dönteni, hogy oda tartozik, vagy sem. Akkor mi alapján rójuk fel pl. a Javascript-nek, hogy az "5" + 2 nem dob hibát? Hogy simán összeadhatok egy stringet meg egy intet? Hisz ""Hogy ez NEM az az eredmény, amit látni akarok, az egy teljesen más kérdés..."" Kettős mérce...

"Nagyon rossz példát választottál, az atoi függvény failsafe, sosem dob hibát. Ameddig tudja konvertálni a stringet, emgteszi, ha nem tudja, akkor 0-t ad vissza. Hibaforrás újfent nincs....

Nem is kell, a bemenetnek karakterláncnak kell lennie. Az is. A kimenetnek meg int-nek. Az is. Az, hogy a karakterláncban egy konvertálható szám foglal helyet csak haba tortán, a program működését nem befolyásolja, legfeljebb a végeredmény nem tetszik majd nekünk. Viszont. Hiba. Nincs. "

Pont ezért választottam ezt a példát.

Miért nem lehet bármely string-et int-té alakítani? Mert a string értéktartománya nem feleltethető meg 1:1-ben az int értéktartományának, és ez biztony hatalmas nagy type mismatch, és abszolút nem az a fontos, hogy ami bemegy, az string, vagy int, vagy double vagy akármi más, vagy hogy mi a visszatérési érték. A baj az, hogy ez szintaktikailag ugyan nem type mismatch, szemantikailag viszont történetesen az.

"A fent említett dolgok egyébként dinamikus típusozású nyelvben is simán előfordulhatnak"

Persze, csak minket dinamikus típusozású nyelvekben senki nem kényszerít arra, hogy ide-oda konvertálgassunk meg castoljunk mindent, ami a kezünk ügyébe kerül :D

Mire te végiggondolod, hogy (int)x vagy int(x) vagy reinterpret_cast vagy static_cast vagy atoi vagy mégis mi a fene kelle nekem, arra mi félig megírtuk a programot :)

Félreértés ne essék, nem akarom bántani a statikus típusú nyelveket, de a dinamikus típusú nyelvekkel nagyon sok esetben lényegesen kevesebb probléma van, és jóval gyorsabban lehet haladni (bár ez nem csak a típusosság miatt van így).

", csak ott a nyelv nem biztosítja a kimeneti érték típusát",

Honnan vetted ezt a sületlenséget? Ne mondj ilyen ökörséget, mert magamba fordulok. Úgy beszélsz a dinamikusan típusos nyelvekről, mint ha a változók típusa random módon váltakozna, és sosem lehetne tudni, hogy mi jön a fekete dobozból.

"még nem is olyan típusú érték jön vissza, mint amire számítasz"

Ezt megint honnan vetted??

Egy mysqli_stmt_execute bool-t fog visszaadni, nem mást. Egy iptcparse arrayt, hiba esetén bool-t ad vissza, nem mást. A saját függvényed is mindig olyan típust fog visszaadni, amilyenre megírtad, nem mást. Amit írsz, azzal azt állítod, hogy a dinamikusan típusos programnyelvek nem determinisztikusak...

Vagy csak még mindig az van, hogy csak felületesen látod át a dinamikus típusozást, és nem kicsit elfogult vagy a statikusan típusos nyelvek iránt.