Scala 3 / Dotty izelito

Az APL jelöléseit szokni kell a kívülállónak, mert bár matematikából eredt, de a régimódi nyomtatók (több betűt leütni ugyanarra a helyre: pl.  O + /, amit mátrixtranszponálásra  szokás használni, míg a O + | -t pedig tükrözésre) korlátai miatt lett az, ami. Másrészt különféle nyelvjárások terjedtek el más és más jelölésrendszerrel, és elég problémás volt köztük átmenet, így a kódok publikálása is.

A J már redukálta a jelölést az ASCII-re, emiatt szimpla karakter helyett gyakran kettőt kell használni egy fogalomra. A k még nekem is fekete ló, a bankszektor viszont szereti, főleg a hozzá kapcsolt adatbázisokat (kdb) és lekérdező nyelvet (q). Az általános vélemény szerint ez egy write-only nyelv, ami persze csak sarkítása a dolgoknak. Elvileg kevés fejlesztővel igen hatékonyan lehet dolgozni. Legyen azért valami konkrétum is: az aktuális Advent of Code  k nyelvű megoldásai: https://bitbucket.org/ngn/k/src/master/aoc19/a.k

Azért ezekben a megoldásokban is elég sok függvény lett definiálva, ami szerintem  az absztrakció egy adott formája. Az pedig elég általános, hogy két-három függvény összekapcsolása már új (esetleg érthető) elnevezést kap. Persze a precedencia mentesség, és a jobbról-balra haladás sokak számára már túl van az elviselhetőség határán, bár a műszaki dolgok iránt érdeklődő, de nem a hagyományos programozói iskolákon nevelkedettek elég sikeresek benne.

Nagyon kellemetlen, amikor egy probléma megoldása kapcsán nem a feladattal foglalkozol, hanem elveszi a fókuszt a fejlesztői felület bonyolultsága, vagy az adott nyelv fennkölt absztrakciója, amely elhiszem, hogy egyeseknek - elsősorban ezen nyelvek és eszközök megvalósítóinak - maga az önmegvalósítás, de én látni szeretném, mi az, amit csinálok, s nem szeretnék azon gondolkodni, hogy az amúgy látszólag egyszerű jelölés pont ott, abban a kontextusban mit jelent. Jó, ebben már a C-nek is van sara, amikor típust „szorzunk” változóval. :)

Az is szörnyű, amikor egy felület annyira az ember keze alá dolgozik, hogy ugyanarra a dologra kontextusfüggően más történik. Azért, mert az emberi agynak kényelmesebb a statikus gondolkodás, a rögzített célpontra lövés, minta dinamikusan változó környezethez alkalmazkodás. Így aztán jobb, hatékonyabb az a fapados felület, amely kevésbé szolgál ki, de nem változik, mint az, amelyik megpróbálja kitalálni a gondolataidat. Ez utóbbi azért sem jó, mert lehet, hogy nem azt akarod, amire ő gondol, s ekkor egyenesen küzdeni kell ellene. Mint a szövegszerkesztőkben az automatikus formázás ellen.

Konkrét példát ne kérj, egyszer magamnak csináltam olyan felületet, ami a legvalószínűbb választ tette alapértelmezetté, de hamar rájöttem, ez nagyon fárasztó agyban. Az sokkal jobb, ha a default statikusan ugyanaz, aztán majd kitalálom, akarok-e változtatni rajta.

teljesen komolyan gondoltam, amit irtam. amig az egyetemen tanitottam is, lattam sok hasonlo PhDs "kutatot" akik epp akkor F#-ra vertek, hogy dejo, azota pedig tobb kollegam is a haskellre onanizal. aztan?

ismerek tobb startupt is aki elindult hogy "na majd mi megmutatjuk", szoptak haskellban, aztan mi lett belole? semmi. vagy hamvaba halt a startup, vagy atvaltottak masra, mint a rust pl.

a szoftverfejleszto az bantuneger, akinek az a dolga, hogy a funkciot megvalositsa, SENKIT nem erdekel, hogy miylen szep a kodod. SENKIT.

(egy startupban raadasul vegkepp nem arra kene idot pazarolni hogy "ahhhh monad ahhhhh pure function ahahahhahahahhhhhhhh" hanem az uzleti logikat implementalni hogy legyen $$$$)

HTH

Nem a TypeScriptről beszéltünk és nem is az ECMAScriptről, hanem a JavaScriptről. Irreleváns, hogy a nyelv mennyire konzisztens, ha az implementáció nem az. Azonfelül maga a nyelv is agyrém.

var kecske = document.getElementById("ilyen_nincs");
alert(typeof kecske); // will alert "object"
alert(Math.pow(Math.random(), kecske)); // will alert "1"

(Rosszul feltételezed: sosem írok bash-only kódot. Amúgy is, mi az, hogy a "de-facto standard *nix shell script nyelv"? A bash nem a nyelv, hanem az interpreter; a nyelv, az a UNIX shell script, a bash-only nyelvi elemek, azok kiterjesztések, amik az interpreterben vannak. Azonfelül a POSIX leírja, hogy mi az igazi standard, tehát nincs szükség de-facto standardekre.)
Látod, erre mondtam, hogy rosszul használják és rosszra. Shellben nem "programozunk", shellben automatizálunk valamit; a shellt arra találták ki, hogy a különféle programok/(non-shell )scriptek ki és bemeneteit összekötögethesd, hogy automatizálhass bizonyos folyamatokat és ezzel megspórold azt a csomó munkát, amíg ezeket begépelted volna a terminálba.
És itt jön képbe, hogy az, hogy shellben minden string, az nem probléma, hanem szükségszerű, mert egy terminálban nem is lehet más egy változó, mint string, azaz bytestream, hiszen a programok a terminállal az stdin/stdout/stderr descriptorokon keresztül kommunikálnak, egy descriptor számára meg nem létezik semmi más, csak byteok sorozata. Azonfelül shellben tkp. nem nagyon létezik olyan változókkal kapcsolatos művelet (hangsúlyozom változókkal való operálásról beszélek, nem a csövek ide-oda kötögetéséről) ami nyelvi elem és nem egy parancs, vagy annak argumentuma. (Úgy egész konkrétan a stringek konkatenációját leszámítva hirtelen nem is jut eszembe semmi.) Ennek megfelelően a típusoknak sincsen az ég egy adta világon semmi értelme, hiszen a műveletet végző parancsprogram is stringként kapja meg a bemenetet és stringként is adja vissza a kimenetet; ha lennének típusok az csak hóttfelesleges typejugglinghoz - és overheadhez - vezetne. Az if-nek is, amit beadsz feltételnek, azt nem a shell vizsgálja, hanem a test parancs, vagy a [ parancs. Aritmetikai műveletet is az expr (és tsai.) segítségével végzel. És ezek a parancsok mind stringekkel operálnak. Nincs értelme más "típusnak".
Nagyon sokan azt hiszik, hogy a shell az Yet Another Scripting Language, ami orbitális tévedés. A shellscripting egy teljesen más műfaj, mint a "normál" scripting.

A Go-t annó megnéztem, azon kívül hogy automatikus memóriafoglalása van, meg néhány modern dolog alapból való támogatása, nyelvileg nem láttam semmi egetrengető újdonságot a C++ vonalhoz képest. Rust esetén a borrowing, lifetime, alapból safe megoldások, a makacs típusosság ahol például az f32 és f64 is csak explicit konverzió után hozható össze, a "force UTF8", ... Szóval sok dolog, ami megkerülhetetlenül*** fegyelmet teremt az "okosban megoldjuk" kísértés letörésére.

*** megkerülhetetlenül: unsafe { ... } kulcsszóval jelzett rész az egyetlen (forráskódban így könnyen megtalálható) megkerülési lehetőség, amire vannak esetek hogy szükség van. Viszont ekkor ez a kulcsszó látványosan ott van, amit illendő kizárólag olyan esetben használni, ahol tényleg indokolható.

Persze innentől nem az "átlag indiai" nyelve, ezt a nyelvet tényleg szokni kell. Ha a megszokás sikerül, onnantól megszereted.