[HK] A Peri programnyelvről nagy vonalakban

Írom a Peri programnyelvemhez a dokumentációt, és épp végeztem egy fejezettel, amiben választ kívántam adni a szintaxisával kapcsolatban felhozott kifogásokra. Ezt a fejezetet teszem most közzé itt. Kíváncsi vagyok a reakciókra. (Bár alig-alig reménykedem a pozitív fogadtatásban, de hátha... Ugye, amíg élünk, remélünk, a remény elvégre mindig ingyen van, stb).

A Peri programnyelvről nagy vonalakban

A Peri nyelv az első pillanatban amikor ránéz egy laikus egy Peri nyelven írt programra, iszonyatosan nehéznek tűnik, egymerő katyvasznak, tele megjegyezhetetlennek tűnő, bonyolult szimbólumokkal, és mindenkinek az az első gondolata ekkor, hogy „ezt lehetetlen megtanulni”!

Holott ez csappet sincs így. Annyi igaz, a Peri nyelv szimbólumrendszere eléggé extravagáns és drámaian eltér több ponton is az ismertebb programnyelvek jelölésrendszerétől; mindazonáltal cseppet se nehéz ezt megtanulni, és amiatt nem nehéz, mert SAJÁT BELSŐ LOGIKÁVAL RENDELKEZIK. Aki e belső logikát átlátja, megismeri, az pillanatok alatt megtanulja e szimbólumokat, sőt, még ha később egy olyan szimbólumba is fut bele amit még nem ismer, még erről az ismeretlen szimbólumról is tudni fogja ha nem is pontosan de legalább körülbelül, hogy NAGYJÁBÓL mire vonatkozik!

E fejezet célja a szimbólumrendszer e belső logikájának bemutatása.

A Peri kulcsszavai két fő összetevőre oszthatók. Az egyik az a rész ami egy angol szó vagy szótöredék, vagy valami olyan matematikai jel illetve szimbólum, ami más programnyelvekben is (elsősorban a C nyelvben) is előfordul, így Olvasóm vélhetőleg ismeri már - ilyesmikre gondolok hogy:

argc ++ / != - <=

Ezek megtanulása tehát semmi esetre se okozhat nagy nehézséget, mert kezdjük azzal, legtöbb Olvasómnak meg se kell ezeket tanulnia, mert úgyis tudja már mi ezeknek a jelentése - legfeljebb azzal kell megbarátkoznia, hogy ezen operátorok a paramétereiket a stackból veszik elő, s az eredmény is oda lesz pakolva.

A kulcsszavak és operátorok azonban tartalmazhatnak más elemeket is a fentieken kívül, ezen fenti elemeket kiegészítendő. Gyakran ezen kiegészítő elemek nem is kulcsszavak előtt vagy után állnak (vagy közrefogják a kulcsszót...), hanem egy változó nevéhez tapadnak hozzá egyik vagy másik (vagy mindkét...) oldalon. Nos ekkor sincs baj, mert könnyű megjegyezni, mi a jelentésük. Tételezzük fel, hogy az alábbi példákban a "myvar" egy változó neve. A Peri nyelvben egy változó neve, ha csak úgy önmagában leírjuk - s ha e változónév egynél több karakterből áll! - mindig a változó pointerét jelenti.

Leírhatjuk azonban a változó nevét így is:

@myvar

Ekkor már a változó tartalmáról van szó, mert a @ szimbólum a Peri nyelvben a dereferenciaképző feladatát látja el!

Ha ezt látjuk:

[[myvar]]

Akkor egészen biztosak lehetünk benne, hogy a myvar egy stringtömb. Teljesen mindegy, mi áll e szimbólum előtt vagy mögött:

@[[myvar]]

[[myvar]]~

[[myvar]]~~

[[myvar]]~~~

[[myvar]]--

[[myvar]]++

[[myvar]]=

[[myvar]][]

[[myvar]][^]

(és még számos más akármi lehetséges...), de EGY dolog biztos: ha a változó neve - jelen esetben a myvar - dupla szegletes zárójelek közé van téve, akkor az a változó egy stringtömb!

Ha a mnemonik jobb oldalán hullámvonal áll, mindegy hány darab, akkor abban lehetünk biztosak, hogy az a mnemonik egy stringgel van valamiféle kapcsolatban, ráadásul a string hosszával van konkrét kapcsolatban, azzal csinál valamit: lekérdezi, beállítja, csökkenti, stb. Ha pontosan 1 darab hullámvonal áll ott, akkor a string aktuális hosszáról van szó, ha 2 hullámvonalról, akkor a string maximális hosszáról, tehát arról amekkora terület le van foglalva a stringobjektum részére.

Ebből máris következik, hogy a

[[myvar]]~

szimbólum valami olyasmit fejez ki, hogy itt a myvar változó egy stringtömböt tartalmaz, és e stringtömb valamelyik stringjének az aktuális hosszával van kapcsolatban ez a mnemonik. Szóval lehet hogy konkrétan nem tudjuk még, pontosan MIT jelent e szimbólum, hol vannak a paraméterei, illetve hova teszi az eredményét (akármi is legyen az), lehet hogy sok mindent nem tudunk e konkrét utasításról, de azért már legalább kapisgáljuk hogy körülbelül miről is lehet szó itt!

Lássuk tovább! A [] szimbólum egy tömb indexelésére utal. (ezt pláne nem nehéz megjegyeznie annak, aki ismerős a C/C++ nyelvben...). Ennek megfelelően a

[[myvar]][]

szimbólum bár rém elszörnyesztően néz ki első pillantásra a rengeteg zárójel miatt, mégis, jelentése - nagy vonalakban - NYILVÁNVALÓ: itt valami stringtömböt indexelünk, vagy legalábbis a stringtömb egy bizonyos stringjét indexeljük! Szóval: itt egy stringtömb, amin valamiféle indexelést végzünk!

Ha tudjuk, hogy a Peri nyelvben az inv kulcsszó azt jelenti, hogy az utána következő mnemonik funkcióját valamiféle értelemben az eredeti funkció ELLENTÉTÉRE, azaz INVERZÉRE változtatja, akkor nem lehet meglepő, hogy ez a mnemonik is:

inv [[myvar]][]

egy stringtömb indexelését jelenti, de míg az előző (az inv nélküli) változat KIOLVAS a tömb indexelt pozciójáról valamit, addig ez az inv-es változat BERAK abba az indexelt pozícióba valamit! A Peri nyelvben ugyanis általános szabály, hogy az inv nélküli utasítások - amennyiben adatmozgató utasítások - mindig KIOLVASNAK, míg az inv-es változatok BEÍRNAK valamit az adott változóba!

Vagy íme egy másik példa az inv-re. Ha tudjuk hogy a sub utasítás egy string egy adott darabját adja vissza substringként, akkor az is teljesen logikus hogy az

inv sub

utasítás azt adja vissza stringként ami az eredeti stringből e kivágás után megmarad, azaz ez felel meg a más nyelvekben ismert dissect utasításnak...

Kulcsszavak után jobboldalon közvetlenül állhat kerek zárójelpár is. Például ennek az utasításnak:

++

van ilyen párja is:

++()

A Peri nyelvben alapértelmezetten minden utasítás a stackból várja a paraméterét, ebből már Olvasóm könnyen kitalálhatja ha amúgy ismeri a C nyelvet, hogy a sima ++ mnemonik a stack tetején levő értéket inkrementálja eggyel. Na de mi a fene lehet akkor a zárójeles változat?

Nos, a Peri nyelvben ez a fajta zárójelezés arra utal, hogy az utasítás paramétere - vagy legalábbis egyik paramétere, többoperandusú utasítás esetén - mégsem a stackban keresendő, hanem az adott utasítás utáni mnemonik határozza azt meg! Vagyis, ez az utasításpár:

++() myvar

azt jelenti, hogy a myvar változó tartalmát inkrementáljuk eggyel...

Sőt, van ilyen variáció is, na ez vajon mit jelenthet?

++() @myvar

A magyarázat az eddigiekből nyilvánvaló: minthogy a @ szimbólum dereferenciaképző, ez arra utal, hogy a myvar változóban egy másik változóra mutató pointer csücsül, és ezen változó tartalmát inkrementáljuk eggyel! Azaz, itt indirekt címzésről van szó. Nézzünk is meg erre egy rövid példaprogramot (plusplusindirekt.upu):

###sysinclude standard.uh

#g

10 sto another

another sto myvar

++() @myvar

@another printnl

end

{ „myvar” }

{ „another” }

 

Outputja:

 

11

Ennek a jelentését se nehéz kitalálni az eddigiek alapján:

myvar~--

Mert elemezzük csak ki mit látunk itt: string aktuális hossza, dekrementálás - vagyis, ez nyilván azt jelenti hogy a string aktuális hosszát eggyel csökkentjük! Ez meg:

@myvar~--

csakis azt jelentheti, hogy a myvar változóban egy másik változóra mutató pointer van, az a változó egy stringet tartalmaz, s ezen string aktuális hosszát csökkentjük eggyel!

Ez a szimbólum meg:

@myvar+/-

semmi mást nem jelenthet, mint hogy itt valaminek az előjelét az ellenkezőjére változtatjuk...

Olvasóm minden bizonnyal ismeri már a then és else kulcsszavakat, a Basic nyelvből, vagy valamely más nyelvből. Amennyiben tudja, hogy a Peri nyelvben a címkéket azon a helyen ahol hivatkozunk rájuk, a paragrafus előtétkarakterrel kell prefixálni, akkor máris nyilvánvaló előtte, hogy a

then §mylabel

egy feltételes ugróutasítás. Azaz, itt esetleg elugrik egy másik helyre a program, bizonyos feltétel teljesülése esetén. Az

else §mylabel

meg nyilván akkor ugrik, ha a feltétel eredménye hamis volt...

Minthogy aki e könyvet olvassa, arról nehéz feltételezni hogy ne tudná, a programnyelvekben a print utasítás valamiféle kiiratást jelent, ezért elég könnyű kitalálni ebből és az eddig írtakból, hogy a

[[print]]

utasítás valami olyasmit jelent, hogy ki kell írni egy stringtömb minden stringjét! S minthogy a Peri nyelvben az utasítások paraméterei általában a stackban kell legyenek, így mi másról is lehetne itt szó, mint hogy a stack tetején egy stringtömbre mutató pointer kell legyen, s az ezen pointer által azonosított stringtömb minden sorát kiírja nekünk a [[print]] utasítás...

Ha egy mnemonik alakja nagyon szimmetrikus, és ráadásul még az is igaz rá hogy kapcsos zárójellel kezdődik és azzal is végződik, akkor holtbiztosak lehetünk benne, hogy az a mnemonik egy ciklussal van valamilyen összefüggésben! Efféle szimbólumokra gondolok:

{{}}

{{-}}

{{+}}

{{--}}

{{|}}

{{>}}

{{<}}

{~?~}

Akad még ezekből jónéhány... Általában véve már önmagában az is hogy egy szimbólumban nagyon sok a kapcsos zárójel, jogos gyanakvást eredményezhet a Peri nyelvet használni kénytelen szerencsétlen, jobb sorsra érdemes halandóban, hogy az a szimbólum valamiképp egy ciklussal függ össze... Sőt, hogy a dolog még könnyebben megjegyezhető legyen, a Peri nyelvben minden ciklusszerűségre jellemző, hogy a ciklus fejrészének a mnemonikja a pontos tükörképe a ciklus végét jelző (a ciklust lezáró) mnemoniknak! Nézzük csak meg ezeket a párokat:

Blokkutasítás kezdete: {

Blokkutasítás vége: }

Finite loop kezdete: {{

Finite loop vége: }}

Stringbejáró kezdete: {~

Stringbejáró vége: ~}

Végtelenciklus kezdete: {..

Végtelenciklus vége: ..}

 

A Peri nyelvben minden memóriafoglalás (a dinamikusan allokált memóriakezelésre gondolok) a mem kulcsszóval történi, ezt se nehéz MEMorizálni ugye hiszen memory..

Ha ezt tudjuk, nem lepődünk meg azon, hogy stringtömbnek memóriát a

[[mem]]

kulcsszóval foglalhatunk...

De azon se, hogy a lefoglalt memóriát az

inv mem

kulcsszóval szabadíthatjuk fel...

Ha emellé még azt is tudjuk, hogy a shared memoryval összefüggő dolgokra a Peri nyelvben a három pont utal, akkor abszolút logikusnak érezzük, hogy ha egy stringtömbnek akarunk memóriát lefoglalni a shared memory területen, hát annak a kulcsszava csakis és kizárólag ez lehet:

[[mem...]]

A Peri nyelvben ha egy kulcsszó előtt és/vagy után felkiáltójel áll, az nagyon sok mindent jelenthet az adott kulcsszótól függően, e felkiáltójeleknek tehát nincs oly szigorúan megszabott jelentése mint az eddig ismertetett szimbólumtöredékeknek, de az biztos, hogy az eredeti kulcsszó jelentését módosítják, ám nem nagyon, csak PICIT. Nézzük csak e kulcsszót:

trim

Olvasómat nyilván nem lepi meg ha azt mondom, ennek már az angol jelentéséből is kiviláglik, hogy ez a kulcsszó egy stringgel csinál valamit, méghozzá azt hogy abból levág valamit. Nos igen: eltünteti róla a felesleges whitespace karaktereket. Na de honnan: az elejéről vagy a végéről? A válasz ez:

!trim levágja a string bal oldaláról őket.

trim! levágja a string jobb oldaláról azokat.

!trim! pedig levágja őket mindkét oldalról...

Térjünk vissza még egy pillanatra az inv mnemonikhoz! Mint említettem, ez az utána következő mnemonik hatását fordítja valamilyen értelemben „ellenkezőjére”. Na és itt meg kell említenem, ha efféle dolgokkal tisztában van az ember, máris sok mindent megsejthet a Peri program titkaiból akkor is, ha amúgy még soha az életében nem látott Peri kódot. Mert mi van a Periben a blokkokkal? Nos aki a C nyelvet ismeri, az ha lát egyetlen nyitott kapcsos zárójelet majd sok utasítással később egy csukó kapcsos zárójelet, azonnal arra gondol, hogy ez egy blokk. És TÉNYLEG az a Periben is! Igenám, de mi van ha a blokk így kezdődik:

inv {

Azaz van a blokkot nyitó kapcsos zárójel előtt egy inv is? Ugyan MIFÉLE ÉRTELEMBEN lehet egy blokkutasítást vagy annak legalábbis az elejét, a „fejrészét” az „ellenkezőjére” fordítani?!

Nos, némi fantázia segítségével ezt igenis kitalálhatja Olvasóm is! De nem bízom rá, hanem segítek: A blokkok a Peri nyelvben kissé másmilyenek mint a C nyelv esetén. A Peri blokkok NEM alkotnak önálló névteret, ellenben FELTÉTELES UTASÍTÁSOKNAK minősülnek! Azaz egy blokkba akkor lép be a vezérlés, ha a stack legtetején álló érték logikai értelemben igaz, ellenkező esetben a vezérlés a blokk végére ugrik. Ha ellenben a blokk az inv { utasítással kezdődik, akkor a helyzet ennek az ellenkezője: a blokkba akkor lép be a vezérlés ha a stack tetején levő érték logikai értelemben hamis, ha ellenben igaz akkor a vezérlés a blokk végére ugrik... (van amúgy még pár trükk, de itt nem célom mindent leírni a blokkutasításokról, az nem e fejezet tárgya).

Ha tudjuk hogy a [] az indexelésre utal, akkor logikus hogy a

myvar[0]

azt jelentse hogy egy string nulladik karaktere; valamint, ezesetben a

myvar[0]--

nyilván azt jelenti, hogy a stringből kitöröljük ezt a nulladik karaktert, aképpen, hogy a string minden karakterét eggyel balra toljuk, a stringhosszat pedig eggyel kisebbre állítjuk...

Ehhez hasonlóan, ha tudjuk hogy a [$] szimbólum olyan indexelést jelent ami az indexelt valami utolsó elemére vonatkozik, akkor már sejthető hogy a

myvar[$]--

azt jelenti, hogy a string utolsó karakterét hagyjuk le...

Ezekre egy kis példaprogram (strdelfirstlast.upu):

 

###sysinclude standard.uh

"abcdefgh" sto mystr

@mystr sprintnl

mystr[0]-- @mystr sprintnl

mystr[$]-- @mystr sprintnl

end

{ „mystr” }

 

Outputja:

 

abcdefgh

bcdefgh

bcdefg

 

Van aztán olyan kulcsszó is a Peri nyelvben, hogy

arc

Amennyiben tudjuk hogy a

sin

kulcsszó színuszfüggvényt számol (márpedig ez adja magát a kulcsszóból rögvest...) akkor nem nehéz rájönnünk hogy az

arc sin

arcus színuszt számol. Van persze olyan is hogy arc cos stb. Ezt meg még könnyebb is megjegyezni szerintem a matematikához picit is konyítóknak mint a „hagyományos” programnyelvekben elterjedt asin, acos stb mnemonikokat.

Szóval miért is lenne a Peri annyira "unfathomably difficult", hm?! Egyszerűen van egy belső logikája mint minden másnak is az informatikában. E logikát kell átlátni és kész.

Hozzászólások

ez a káros nem a cigi bakker

 

ua ez peribe:

@!=~b+

[új] - No rainbow, no sugar - [új]

Nem a "köznek" irja, hanem saját magának. Nézd úgy ezeket a posztokat mint egy áldokumentumfilmet, vagy egy stand up előadást, esetleg egy bohóc műsorát. Onnantól egész vicces, ha felfogod, hogy nem komoly.

Hivatásos pitiáner
neut @

Legjobban az R tömbkezelése tetszik: ott 1-től indul, és ha pl. tomb[-2]-t írsz, azt jelzi, hogy a 2. elemet törlöd (és persze a tömbindexekhez tömböt is írhatsz, így gyorsan kivehetsz néhány elemet).

Ezekre egy kis példaprogram (strdelfirstlast.upu):

Nem Peri? Miért "upu" kiterjesztés?

Azért upu a kiterjesztése, mert mint azt korábban már említettem valahol (de a doksiban is benne szerepel, bár nem a most beidézett fejezetben hanem a legelején) e nyelv alapvetően a regénysorozatomhoz kell, és ott az UPU csillagbirodalom „szabványos”, „állami” programnyelve. Az UPU amúgy annak a rövidítése, hogy

United Planets of Universe

A nyelv neve ettől még Peri. Bár nem kétlem, a kiterjesztés miatt sokan fogják UPU-nak is hívni. Semmi baj, én azt se bánom.

Legjobban az R tömbkezelése tetszik: ott 1-től indul, és ha pl. tomb[-2]-t írsz, azt jelzi, hogy a 2. elemet törlöd (és persze a tömbindexekhez tömböt is írhatsz, így gyorsan kivehetsz néhány elemet).

Ez tetszik, és vonzódom is az ilyen komplex utasításokhoz, de a Periben ezt (egyelőre legalábbis még...) nem lehet megtenni, mert itt nincs kifejezéskiértékelő függvény, azaz ami beolvassa és kiértékeli a következő aritmetikai kifejezést (hogy aztán annak értékét mondjuk tömbindexként használhassuk). Nem mintha egy kifejezéskiértékelő megírása olyan szédületesen extrabonyolult volna mint azt a pelenkás kezdők hiszik (írtam már ilyet valamelyik korábbi nyelvemhez...), hiszen mindössze a rekurzió lényegével kell tisztában lenni. Ám az ilyesmi főként az infix notationt használó nyelvek sajátja, és a Peri nem olyan. Azért nem olyan, mert egy infix notationt használó nyelv - legalábbis ha interpreter és nem használ valami JIT trükköt - mindig lassabb mint egy stackorientált, mindössze azért mert a kifejeéskiértékelő minden meghívásánál el kell mentse a visszatérési címet és az addigi részeredményeket is a stackba, s implementációtól függően valószínűleg még egyéb dolgokat is. S akkor még nem is említettem az operátor-precedenciát.

A Perinél efféle nincs. Ennek lehetnek hátrányai, de cserébe legalább villámgyors.

De, azért elültetted a bogarat a fülembe ezzel, és ezt nagyon szépen köszönöm, e sorokat ugyanis most a munkából ellógva írom, mindjárt loholnom kell vissza, de legalább így meg van oldva, meló közben min töröm a fejemet... az ilyesminek örülök mert megkönnyíti a munkanap elviselését...

Szerkesztve: 2020. 11. 26., cs - 18:07

<spoiler>
A regény arról fog szólni, hogy Poliverzumban a két fő programnyelv (Furor, Peri) fanatikusai összevesznek és mindent elsöprő kiberháborúba kezdenek. Végül jön Harold Király, és rendet tesz.
</spoiler>

Nem, ilyen művet nem tervezek.

De ha már spoilerezünk, elárulom, tervezek egy olyan regényt írni - ha nem is mostanában - ami arról szól (többek közt...) hogy van egy világszimuláció, Peri nyelven írva természetesen, s e szimuláció egyik polgára rájön hogy ő szimulációban él. sikerül rálelnie a szimuláció forráskódjára (most mindegy hogyan), és abban talál egy bugot. Pontosabban, nem a forráskódban magában, hanem a Peri programnyelvben amiben a szimuláció írva van... Ennek az illetőnek akad segítője „kint”, az „igazi” világban, neki ezt a bugot a tusomására hozza a megfelelő exploittal, ami, mit tesz isten (akarommondani mit tesz a programozó...) még működik is...

Ez persze csak rém nagy vonalakban lett itt eldarálva, de a többi részletet úgyse értenétek a sorozatom ismerete nélkül.

Szóval látjátok, nekem IGENIS szükségem van egy programnyelvre a sorozatomhoz...

Majd ha tudsz mondani bármi ötletet amit nem írtak meg már legalább egy tucatszor, akkor szólj!

Sőt, a legtöbb ötletet már az ókori görögök is ledrámázták...

Tudod, a művészet nem okvetlenül az ötlet eredetiségét jelenti, van ám olysmi is hogy egyéni stílus, meg új kontextusba helyezés, meg hogy a téma melyik részére esik nagyobb hangsúly a műben, és sok minden egyéb is... Ha ezt nem tudod vagy nem ismered el, az csak azt bizonyítja hogy te magad nem vagy művész.

Minden tiszteletem azelőtt, hogy saját programnyelvet írtál. De ez valóban egy katyvasz. Jópár másik témában kifejtetted az ALKOTÁS-ról a véleményed, ill. kifejezted abbéli nemtetszésedet, hogy egyes emberek, akik játszanak pl. menniyre értelmetlenül teszik ezt. Merthogy alkothatnának is helyette. Na ennek itt, kb. ugyanannyi értelme van. Ha már ennyi energiát belefeccölsz, miért nem alkotsz valami olyat, ami mások számára is hasznos? Ugye erre is van példa az oldalon. Nem reklámozom, de a híres videómegosztó oldalhoz készített programnak valóban van haszna. Az általad alkotott programokról ez egyáltalán nem mondható el. Mi a célod ezekkel az egyestés bejegyzésekkel? Meg akarod mutatni, hogy mit ALKOTTÁL, de aztán mégsem, mert nem elérhető másoknak. Ezzel valóban csak nemtetszést és ellenszenvet fogsz kivívni.

És mégegyszer mondom, respekt, hogy írtál nem egy, hanem két programnyelvet is!

hogy írtál nem egy, hanem két programnyelvet is!

Igazából nem egy és nem két, hanem fél tucat programnyelvet írtam, kivéve ha nem, mert lehet hogy többet is, csak néhányról már magam is megfeledkeztem...

Épp csak a többi programnyelvemet nem harangoztam be itt a HUP-on. Jópár másikat igen, a Linuxempire oldalon, de még ott se mindet.

A programnyelvem meg igenis alkotás. Soha nem mondtam hogy az ÖNCÉLÚ alkotás ne lenne alkotás, sőt mindigis fennen bizonygattam hogy igenis az is az!

De megnyugtatlak: a nyelvem hasznos lesz másoknak is, amennyiben (ahogy fentebb leírtam) ez a regénysorozatomhoz kell. Annak művészi értékét növeli, ezért ilyen értelemben nagyonis hasznos.

De ez valóban egy katyvasz.

Annak tűnik első pillantásra. Nem először írom azonban, ugyanaz a helyzet vele mint a VIM-mel. Szokni kell. Vedd észre, a mélyén meghúzódó logika végülis ugyanaz ebben is: amint a VIM parancsai is kisebb részekből tevődnek össze, úgy igaz ez a Peri parancsainak többségére is!

Emacs? Az egy bloatware... bloatware... izé... nem tudom mi... Ja, megvan! Már emlékszem! Bloatware az igaz, de ettől még tulajdonképpen egy egész jó operációs rendszer lenne... Az egyetlen baj vele, hogy még ennyi év után is hiányzik belőle egy használható text editor...

> hogy írtál nem egy, hanem két programnyelvet is!

Fiatal lehetsz errefelé, HK gyakrabban talál fel új programnyelveket, mint más alsóneműt vált. Gyanítom az ok az lehet, hogy a bonyolult syntax miatt nem tudja elolvasni a tegnapi kódjait és inkább újraírja őket.

Annyira azért nem, csak egy fél évvel vagyok lemaradva tőled ;-) Én nem ekézni akartam a "művész" urat, csak próbálom megérteni, hogy mi a célja. Azon kívül, mint ahogy megtudtuk, a regényhez kell. Viszont, ennyi energiát biztos nem fektetnék bele, hacsak a regény nem ezen a nyelven fog íródni. De akkor meg valamit publikálni kellene belőle, hogy egyáltalán mi földi halandók megérthessük majd.

1. Maga a tény hogy a művész szót "idézőjelek" közt írtad, már egyfajta ekézés.

2. A regény publikálva lesz, amint le lesz fordítva angoilra. Ez nem tudom mikor lesz, de vélhető hogy NAGYON sokára. Magyarul már kész van, de úgy perpillanat nincs ingerenciám publikálni, especially not for free. Általában véve különben, egy írón az múlik mikor készül el a művel és mit ír, az NEM, hogy mikor jelenik meg. Az ilyesmi a kiadókon múlik. Kiadót találni meg nem is olyan egyszerű, pláne magyar nyelven. Nota bene, magyar nyelven már rég nem is keresek kiadót mert minek, óriási energia lenne keresni ahhoz képest ami pici üzletet jelent...

3. A programnyelvem közzé lesz téve, BSD licenc alatt, amint elkészül annak is az angol fordítása. Mármint a dokumentációé. E pillanatban azt magyarul írom. Nem tudom mikor lesz kész a fordítása, de elég biztos vagyok benne hogy sokkal előbb mint a regényé.

Mi a bajod azzal, hogy önmagadon kívül senki nem tart művésznek? Melyik akkreditált művészképzőt is végezted el?

Az életút miatt? Ha egy ingyenes online könyvtárban megjelenik néhány mű, attól még az nem művészet. Beszéltem az oldal működtetőivel egyszer: tartalmilag ne vizsgálják az ott publikált írásokat.

Olyan programnyelvet mikor fogsz írni, ami hasznos is lesz: értsd olyan programot fognak valakik írni rajta, ami elterjed, mert olyan faja?

Itt többen is kinőttek még a 80-as években 10-en évesen abból, hogy saját programnyelvet írjanak. (A C64 interpretere átírható volt.)

Szerintem akkor fikázd a programnyelvemet, ha írtál már egy legalább olyan színvonalút. De te olyan segghülye vagy popókám, hogy még ahhoz se értesz miként definiáld át a billentyűket a klaviatúrádon. És amikor valaki (én...) mutat neked rá egy megoldást, akkor olyan kibaszottul lusta vagy még elolvasni is, hogy inkább FELADOD, és veszel drága pénzem egy másik billentyűzetet, ezzel pocsékolva a pénzedet és növelve az elektronikus hulladék okozta környezetszennyezést a világban.

Ráadásul el kell keserítselek. Nem igazán izgat, a MAGYAR emberek engem művésznek tartanak-e. Én annak tartom magamat, aztán hogy más annak tart-e nem sokat számít, de hogy a __magyar__ emberek minek tartanak, na az kiváltképp nem. Réges-rég bevallottam, nem csinálván titkot belőle, hogy én már az ANGOL kiadásra hajtok! Érted?!

Ahogy a költő írta régen: A MINDENSÉGGEL MÉRD MAGAD!

Mi nekem ez a mikroszkopikus kis ország itt Európában, a Balkán legészakibb bugyra, ami különben is „puha-diktatúrába” süppedt már megint, sokadszorra?! Engem ennél sokkal szélesebb perspektívák vonzanak!

Magyarország érdekes módon egy olyan helye a világnak, ami gonoszabb még a Bermuda-háromszögnél is, mert Magyarországról évszázadok óta rendszeresen ki kell vándorolnia, emigrálnia kell épp a legtehetségesebb embereknek ahhoz, hogy aztán valamiképp érvényesülni tudjanak! Ez egyaránt igaz a művészekre is, tudósokra is, feltalálókra is!

Milyen ország az ami épp a legkiválóbb gyermekeit nem becsüli meg, s üldözi el?!

Ezek után engem izgasson az, majd épp a magyarok méltóztatnak-e nagy kegyesen művésznek tartani engem?! Röhejes lenne, na. Messze többre tartom magamat annál, hogy az efféle véleményre adjak. Nyilván valamiféle elvont értelemben jobban esne ha annak tartanának, de a különbség oly mikroszkopikus, hogy ha nem, hát akkor nem, elintézem egy vállrándítással és kész!

Különben is, ez úgy szokott lenni, hogy évtizedekkel a tehetséges illető (tudós, művész, akárki) halála után hirtelen „felfedezik”, kikiáltják a magyarság legnagyobb géniuszának, és mindenki büszke rá, miközben sajnálkoznak hogy „nem értette meg őt az a kor, mert ő korát meghaladó zseni volt”... röhejes és szánalmas, de ilyenek a magyarok, na.

A 2020-as év nekem különben abszolút sikerév volt. Elkészült a programnyelvem végleges változata, elkészült hozzá a dokumentáció is teljesen (igaz, egyelőre csak magyarul), elkészült a legislegszuperebb regényem tökéletes angol műfordítása, rátaláltam a Carnivore diétára, ráadásul még Trump is megbukott!

Örömömet a te kicsinyes gáncsoskodásod semmi esetre se tudja elrontani, hiába is erőlködöl te szerencsétlen nyomorult, te kis szellemi nímand! Még csak nem is haragszom rád, csupán megvetlek, s annál is inkább sajnállak!

És ha most azt írod erre hogy tl; dr és nem olvastad el, az se izgat, mert tudom hogy úgyis elolvastad. Nem bírja ki a hiúságod hogy ne tudd, mit írtak neked és rólad.

Szóval miért is lenne a Peri annyira "unfathomably difficult", hm?! Egyszerűen van egy belső logikája mint minden másnak is az informatikában. E logikát kell átlátni és kész.

A megértés attól lesz irgalmatlanul nehéz, hogy ez a belső logika nagyon sokszor szándékosan obscure, sokszor pedig köszönőviszonyban sincs a józan ésszel.

  1. Szintaktikailag megkülönböztetni a tömböket adattípus szerint? ([[stringtömb]]) Minek? Akkor mi az integer tömb? Midegyiké másmilyen, vagy csak a string vs többiek a különböző?
  2. Törekedni kellene arra, hogy minél kevesebb működés legyen "valamiféle értelemben". Az, hogy minek mi az inverze, az rohadtul többértelmű. A tömb első elemének kiolvasásának az inverze nemcsak az lehet, hogy a tömb első elemét írod, hanem az is, hogy a tömb utolsó elemét olvasod ki. Vagy az, hogy mindent kiolvasol, csak az elsőt nem. Vagy akármi. Ez nem derül ki a kódot olvasva és a logikát átlátva, hanem tudnod kell konkrétan, hogy a stringtömb esetében mit jelent az inverz. Mert másnál meg mást jelent, fasza.
  3. Olyan szintaxist használsz, ami kb. sehol máshol nem létezik, tök feleslegesen. Van olyan nyelv, amiben működik a doSomething argument, van olyan, amiben ugyanez doSomething(argument), de olyan, hogy doSomething() argument, az nekem felesleges bonyolításnak tűnik. Mi van akkor, ha több paraméter van? doSomething()() arg1 arg2, vagy doSomething() arg1 arg2?
  4. Több olyan syntactic sugar van nálad, ami egy ritkán használt és/vagy triviális funkciót valósít meg, teljesen értelmetlenül. Ott van pl. a @myvar+/-, ami megváltoztatja az előjelet. Az is megváltoztatja, hogy megszorzol valami -1-gyel, cserébe megint van egy szimbólumod, amit meg kell tanulni. Nem, itt sincs egyértelmű logika, akár csak az inverznél: ha én ránézek, nekem az jut eszembe, hogy ez vagy egy körülbelüli érték (mondjuk a myvar változód a 10+-5 tartományban van-e), vagy az, hogy megmondja egy számról, hogy >=0 vagy sem.
  5. Ciklusok: ha többet ágyazol egymásba, baromi áttekinthetetlen lesz így. Nagyobb ciklusnál néha a záró }-hez is odakommentelem, hogy (pl. //while(valami1 != valami2)) az melyik ciklust zárja. Vagy az IDE megcsinálja ezt újabban.
  6. Miért ennyire kiemelt szerepű nálad a string? Ha megpróbálok gyakorlati példákat találni, stringet használok kb. a legritkábban programozáskor, pláne stringtömböt. Amennyire csak az ésszerűség határain belül lehet, igyekszem minél később stringesíteni az outputot, és minél hamarabb deszerializálni az inputot, ha az stringként jön.
  7. Nem nagyon jut eszembe jó példa arra, amit (valódi) végtelen ciklussal lenne optimális megcsinálni, más nyelvi forma helyett. Minek neki külön syntactic sugar? (Lásd 1., 4. pont)
  8. Eddig a [[myvar]] jelentette a stringtömböt. Utána [[mem]]-mel foglalsz neki memóriát. Miért ugyanúgy néznek ki? Ez plusz egy kétértelműség, aminek nem látom a hasznát.
  9. "e felkiáltójeleknek tehát nincs oly szigorúan megszabott jelentése mint az eddig ismertetett szimbólumtöredékeknek" Sajnos az eddigieknek sem volt sokszor, és ez egy baromi nagy probléma. :) Miért kell több teljesen unrelated viselkedést ugyanazzal jelölni? Mintha C-ben int-tel jelölnéd a számokat és a stringeket is. Meg lehetne oldani, hogy kontextusból kitaláld, de mi a fenének?
  10. "Nos, némi fantázia segítségével ezt igenis kitalálhatja Olvasóm is!" Lásd 2-es pont, jó eséllyel kitalálhatja az olvasó, de szintén jó eséllyel nem azt fogja kitalálni, amit te. :) Nekem pl. erről egész más jutott eszembe.
  11. "ezesetben a myvar[0]-- nyilván azt jelenti, hogy a stringből kitöröljük ezt a nulladik karaktert" Nem nyilván, mert fentebb a ++ azt jelentette, hogy inkrementálunk eggyel, itt meg a -- azt jelenti, hogy törlünk valamit. Miért ugyanaz az operátor csinálja mindkettőt? Mi van akkor, ha egy int tömb egyik elemére hívod meg a -- operátort? Akkor csökken eggyel az adott elem értéke, vagy kiveszed a tömbből az adott elemet?
  12. "@mystr sprintnl" Fentebb amikor függvényt hívsz meg valamire, az úgy nézett ki, hogy sprintnl() @mystr - ez miben más? Miért jó, hogy ez más?
  13. "arc sin" Milyen logika szerint van ez külön? Fentebb ilyen szabály nem volt, hogy egy függvény állhat két szóból, nem? Ez miért kivétel?

Rengeteg dolgot említettél, ha kimerítően akarnék válaszolni rá úgyis megkapnám a kiosztásomat hogy tl;dr...

Szóval igyekszem általánosabban hozzáállni a kifogásaidhoz.

—Nyilván bele lehet kötni abba a logikába amit a topiknyitóban felvázoltam. Rengeteg kifogást lehetne emelni ellene azokon felül is namiket írtál, magam is tudom. Ennek ellenére, a helyzet akkor is az hogy látható már remélem, ez nem egy „katyvasz”, hanem igenis VAN benne logika! LEHETNE BENNE MÁS LOGIKA IS, igen. Lássuk be azonban, úgyse lehet olyan jelentésmegfeleltetéseket találni a szimbólumoknak (vagy olyan szimbólumrendszert kitalálni) ami rögtön világos mindenki számára, vagy akárcsak olyat legalább, ami ha nem is világos, de miután megtanulta valaki, az lesz a véleménye hogy e szimbólumok tényleg annyira logikusak hogy nem lehetne másképp értelmezni őket. Ez ugyanaz a helyzet mint ami az emberi nyelveknél van. A magyar nyelvben van (például) egy olyan szó, hogy „asztal”. Mindent nevezhetünk asztalnak ami nagyjából vízszintes felületű, rá lehet tenni valamit, teljesen mindegy hogy ezen most kajálunk vagy levelet irkálunk. Mindegyik „asztal”. Logikus? IGEN.

Ezzel szemben az angol nyelvben két szó is van erre, funkciótól függően. Table és desk. Logikus? IGEN, ez is logikus a maga módján. Most beleköthetünk hogy miért ilyen hülye az angol, hiszen látható a magyar nyelvből, tök jól meg lehetne spórolni egy szót, mert lehetne használni a desk helyett is a table szót az angolban is, biztos megértenék. De ugyanúgy a magyar nyelvbe is bele lehetne kötni hogy „szegényes” és „primitív” nyelv, mert nem képes olyan frappánsan kifejezni már a szóválasztással is ilyen apró stilisztikai különbségeket...

Mindez ízlés kérdése. Egyik se jobb a másiknál, csak MÁS.

A Peri ugyanilyen aspektusból nézve, nyilvánvalóan jelentősen MÁSABB mint a megszokottabb nyelvek. Tény hogy szokni kell. A mlogikáját is, igen. Ettől azonban még van benne logika. Te hosszasan kifejtetted, hogy a felvázolt logika lehetne más is. Valóban lehetne más. Akkor az egy másik nyelv lenne... EGY programnyelv csak EGY fajta szimbólumlogikát képes implementálni.

Másik kifogásod ha jól értettelek, hogy a „szintaktikai sugár” szerinted túl kicsi egyes esetekben. Igen, akadhatnak ilyen esetek valóban. Most mit csináljak, a szintaktikai sugár minél nagyobb érvényessége bár fontos szempont, készségesen elismerem, ám nem az EGYETLEN szempont. Rengeteg különböző szempont és követelmény létezik egy programnyelvvel kapcsolatban, és sajnos ezek olykor egymásnak drámaian ellentmondóak. A programnyelvtervező dolga többek közt épp az, hogy ezek közt finom összhangot teremtsen. Én megtettem a tőlem tellő legjobbat. Neked ez nem tetszik, te másféle összhang mellett döntöttél volna ha te tervezel nyelvet, más szempontoknak nagyobb előnyt biztosítottál volna, egyéb szempontok rovására. Most mit csináljak, megint csak azt mondhatom, ízlés kérdése ez is...

Miért ennyire kiemelt szerepű nálad a string?

Egyszerűen nálam mindennek az az alapja. Egy univerzális objektum. Ezt vélhetően azért nem érted, mert a string szó hallatán te okvetlenül és kizárólag olyan izémizére gondolsz, ami olvasható karaktereket tárol. Az én stringem azonban ennél jóval általánosabb valami. Eleve nem is bájtok az egységei, de még csak nem is UNICODE értékek, hanem egy unionok, mely unionok 8 bájtból állnak. Nyilván, ez őrületes pocséklás ha csak ASCII szöveget tárolunk ilyen stringben, ugyanakkor azonban magasan megéri több szempont miatt. Egy ilyen string amikor szöveget tárol, az alsó 4 bájton tárolja az UNICODE értéket, a felső 4 bájt kihasználatlan. Viszont épp emiatt mert 8 bájtos egységekből áll, tetszőleges adatot képes tárolni, bármit, még pointert is... ÉS EZ A LÉNYEG!

Így ugyanis megtehetem hogy nálam minden memóriafoglalás VÉGSŐ SORON egy stringet ad vissza. (mármint a stringre mutató pointert). A lefoglalt terület elején amúgy egy elég bonyolult struktúra található, a stringleíró, a string belső adminisztrációs céljaira...

A stringtömbjeim maguk is tök közönséges stringek, épp csak ekkor nem karakterek vannak bennük hanem pointerek: mindegyik pointer egy „igazi” stringre mutat, olyan stringre amiben már valóban karakterek találhatóak... Egy stringtömbben tehát amiben van mondjuk 10 string, abban igazából csak 10 pointer van nálam... De ettől még TECHNIKAI ÉRTELEMBEN ez a stringtömb nálam egy kutyaközönséges string: épp csak nem karaktereket tárol. De lekérdezhetem a hosszát, mint bármely más közönséges stringét, ezesetben természetesen azt kapom meg hány pointer van benne, ami ugyanazt a számot jelenti, hány sora van a stringtömbömnek...

Tudod, rájöttem, igazából egyetlen adatstruktúra létezik csak a számítástechnikában, s ez a TÖMB. Minden más ennek a csicsázása, s kisebb-nagyobb variálása csupán.

Nálam még a veremtár is stringből van megalkotva. A stringjeim tárolják nemcsak az aktuális hosszukat, de a maximális hosszukat is, azaz hogy épp mennyi memória van nekik lefoglalva. Ez nagyon jó, gyorsítja a futást, mert ha a stringnek új tartalmat adok, ami hosszabb mint a régi tartalom, akkor se feltétlenül kell reallokálni abban az esetben ha az új terület amit igényel e maximális hossznál kisebb...

Ez teszi lehetővé azt is hogy a stringjeim veremtárként viselkedjenek. Az a belső változó ami az aktuális hosszat jelzi, kiválóan használható stackpointernek. Hiszen mindig arra az elemre mutat ami a következő szabad elem a stringben, annak a végén...A közvetlenül ez alatti elem meg - nyugodtan mondhatjuk - „a stack tetején” van...

Szóval temérdek előnye van e stringjeimnek, egyetlen hátrányuk hogy memóriazabálóak, mert minden elemre elpocsékolnak 8 bájtot, akkor is ha az érték maga csak 1 bájtot igényelne. De a RAM manapság már olcsó...

Nálam tehát, a Periben, MINDEN e stringekre épül. Minden, kivétel nélkül. Szerves része a nyelvemnek, annyira mint a Perlben a reguláris kifejezések. Sőt még sokkal inkább.

Félig érted jól csak. Minden ami belefér 8 bájtba, egy ilyen 8 bájtos elemen tárolódik. A boolean is, igen.

Ami nem fér be 8 bájtba, az máshol tárolódik, s a pointere van eltárolva e nyolc bájton. Ez csak logikus!

Ami elfér 8 bájton, annak tehát nem kell külön pointer, ezokból nem 16 hanem csak 8 bájt kell a tárolására.

Ennek ellenére, a helyzet akkor is az hogy látható már remélem, ez nem egy „katyvasz”, hanem igenis VAN benne logika!

Logika van benne, csak nagyon nehéz különösebb előismeretek nélkül ráérezni, mert a szimbólumok nem hordoznak önmagukban jelentést. Más programnyelvekben igyekeznek minél kevesebb kétértelmű szimbólumot használni (inb4 mindfuck, whitespace, stb.). Ahelyett, hogy meg kéne jegyezni mint egyes szimbólumra, hogy a ! milyen viselkedést okoz, ehelyett érthetően, angolul vannak leírna a dolgok. Melyik kifejezőbb? A trim! myArray, vagy a myArray.TrimEnd? Bitre ugyan hosszabb a második, de nem egyszerűbb laikusként rájönni, hogy mit csinál?

Nem arról van szó, hogy valamelyik változat objektíven jobb (bár... :)), hanem hogy ha leültetsz valakit a kód elé, akkor melyiket érti meg gyorsabban, illetve melyikhez kell kevesebbet biflázni, hogy bele tudjon nyúlni.

Másik kifogásod ha jól értettelek, hogy a „szintaktikai sugár” szerinted túl kicsi egyes esetekben.

Nem, csak rossz helyen van. "syntactic sugar is syntax within a programming language that is designed to make things easier to read or to express" Nálad sokszor nem segíti az olvasást, hanem nehezíti. Ha megfigyeled a létező programnyelveket, mondjuk a C-t, amit te is jól ismersz, nagyon véges számú dolog van, amit egyedi szimbólumokkal fejezhetsz ki. Ez azért van, mert a print(valami) sokkal kifejezőbb, mint mondjuk a valami --> [>_] (a kocka egy monitor, benne a >_ a prompt :)) Hiába jópofa az utóbbi, az +1 dolog, amit meg kell tanulni.

Nézd úgy, mint a nyelvtanulást. Van a szókincs, meg a nyelvtan. Te ezek mellé behozol egy új ábécét is, ami nem baj, mert a kínaiak sem latin betűket használnak, mégis elvannak. Viszont felmerül a kérdés, hogy mit ad hozzá az új ábécé a nyelvedhez?

Egyszerűen nálam mindennek az az alapja. Egy univerzális objektum. [...]

Ez mondjuk elég furcsa, nem értem az okát, úgyhogy nem is annyira kötnék bele. Ha viszont ilyesmiben gondolkozol, a valamiféle de-/szerializáció nem lenne jobb, hogy elkerüld az olyan eseteket, mint a fentebbi kommentben a sokbájtos bitmátrix. Ha jól értem, lényegében egy gyengén típusos nyelvet akarsz csinálni, csak körülményesebbnek tűnik így. De fixme, ezt nem értem.

Tudod, rájöttem, igazából egyetlen adatstruktúra létezik csak a számítástechnikában, s ez a TÖMB. Minden más ennek a csicsázása, s kisebb-nagyobb variálása csupán.

Ez azért nagyon nem igaz. :)

Kb. ennyit is akart és ért el ezzel a programnyelvvel: egy valaki legalább írt róla 13 pontban reakciót.
Gelei, miért eteted ennyire? Aztán még a végén operációs rendszer írásába is belekezd, vagy a leptonok és társai mellett új szubatomi részecskét fedez fel Kharrám vagy mi a szösz néven, amit rajta kívül senki nem képes látni szabad szemmel, de ő igen.

Na, ma VÉGRE eljutottam oda a doksiírásban, hogy befejeztem a Core funkcióinak dokumentálását! Huh, ez jó mulatság s férfimunka volt ahogy a költő (nem én!) mondja... Bár, nem is volt olyan jó mulatság, inkább unalmas és lélekölő rabszolgamunka... de muszáj, sajnos.

Belekezdtem egy még nagyobb feladatba, a „standard” library dokumentálásába... az a legnagyobb mind között... :(

De legalább a Core készen van már. Szegény ember apró örömei...

Ja ha az örömöknél tartunk: Ma disznónyelvet főztem, de alig tudtam enni belőle valamit, mert úgy jóllaktam előtte nyers agyvelővel, meg annál is inkább nyers májjal... Sóvárogva néztem a rengeteg főtt nyelvet, de csak a szemem kívánta, enni alig tudtam belőlük...

Lehet hogy holnap halat eszem. Majd meglátjuk.

Semmit nem írtál arról, hogy mi van a nem string típusú változókkal. Meg kell bütykölni egy stringbe, hogy "2.718281828E-0" (szép, C-s, null terminált string), és ilyenekkel műveleteket végezni (ez esetben a supercomputing témában biztos nem fog elterjedni, egy mai gépet egy IBM 1401 szintjére lassítanál) vagy a "string" a nyelvedben a "void *" megfelelője (simán memóriaterület, igazából típus nélkül, azt dobálok bele, amit akarok; ez esetben olyan vicces lesz hibát keresni, mint egy EQUIVALENCE-ekkel teletömött spagettifortranban)?

vagy a "string" a nyelvedben a "void *" megfelelője (simán memóriaterület, igazából típus nélkül, azt dobálok bele, amit akarok;

Nagy vonalakban erről van szó, hiszen írtam is fentebb, a string nálam lényegében egy univerzális objektum, mert az elemei 8 bájtos egységek. Azaz bármit „beledobálhatsz” ezen elemekbe, számokat is, mely számok így nem kaarakterenként hanem rendesen bináris értékekként vannak kódolva. Hiszen 8 bájtba simán belefér egy signed vagy unsigned long long érték is, vagy egy double is...

A stringjeimnek természetesen van egy rakás metódusa, ezek nagy része simán működik akkor is ha nem karakterek hanem ilyen számok vannak eltárolva bennük. Más metódusok alkalmazásának nyilván csak akkor van értelme ha a string karaktereket tartalmaz, ilyen például a kiiratás. Azt hogy konkrétan MI van tárolva a string által lefoglalt memóriaterületen, a string nem tartja nyilván. Számára az mind csak ilyen 8 bájtos egységek sorozata.

Azt tehát hogy egy memóriaterületen, sőt, egy tetszőleges változóban épp milyen típusú adat van, azt nálam egyáltalán semmi se tárolja! Pontosabban, csak nagyon speciális esetekben van tárolva és rém kevés információ róla - nagyjából csak két ilyen dolog tárolt:

1. A stringem azt képes tárolni magában hogy ő egy stringtömb-e igazából, azaz hoghy az elemei más stringekre mutató pointerek-e.

2. Az is tárolva van egy ilyen stringtömbben, hogy „közönséges” módon történt-e a memóriafoglalása vagy a shared memory területén. Ez szükséges hogy tárolva legyen, mert ugye a memória felszabadítása mindegyik esetben másképp történik.

De az NINCS tárolva, hogy a stringben most épp karakterek vannak tárolva, vagy double számértékek vagy akármi más. Akár vegyes mindenfélék is lehetnek benne tárolva, az első bájton egy unsigned int, aztán egy double, aztán karakterek, vagy bármi amit akarsz. A stringnek mindegy.

Miután nagyon megkritizálnátok e módszert, sietve közlöm, nem is titkolom hogy a nyelvem jelentős ihleteket merített a FORTH-ból, s ott is az a helyzet hogy a stackban tárolt adatnak nincs valamiféle rögzített típusa! Nem kell külön castolni, stb. Az csak egy bájt vagy bájtok sorozata, a programozón múlik, mit kezd vele.

A Peri esetén a helyzet dettó ugyanez. Természetesen vannak mindenféle műveletek a különböző típusú elemi adatok megfelelő kezelésére, de nincs nyilvántartva a gép által, az az adat milyen típusú „igazából”. Minden a programozó felelőssége.

A Peri nem véd meg téged attól, hogy hülyeséget kövess el. A Peri nem uralkodni akar rajtad hanem kiszolgálni. A Peri készítésekor a filozófia az volt hogy 2 dolog fontos:

1. A nyelv legyen a lehető leggyorsabb, legalábbis interpreterekhez képest.

1. A nyelv legyen minél könnyebben bővíthető is, utólag, amikor már nagyjából „elkészült”, külső, C/C++ nyelven írható libekkel, hogy ahol mégis lassú lenne ott kisegítsük őt a natív kód sebességével, meg hogy új funkciókkal is felruházhassuk. Utóbbi érdekében a Peri direkt úgy lett konstruálva, hogy a külső libekben tárolt funkciókhoz könnyedén lehessen tetszőleges kulcsszavakat hozzárendelni, s ezek aztán a Peri kódban éppoly könnyen használhatóak legyenek mint ami a Core-ban van implementálva, pontosan ugyanolyan szintaxissal is ráadásul.

E két szempontnak lett alárendelve minden. Vagyis ami nem igazán volt szempont:

—memóriaspórolás (a RAM olcsó manapság)

—folyamatos aggódás az interpreter részéről hogy „kedves programozó, biztos ezt akarod-e, ez veszélyes”

—infix notation (lelassítaná az interpretert)

—Tulajdonképpen még a kód olvashatósága se volt igazán szempont. Azért nem, mert fentebb említettem hogy a Peri könnyedén bővíthető libek által új utasításokkal. Ezen utasításoknak tetszőleges nevet lehet adni, sőt még a szintaxisukat is meghatározhatod. A már elkészült libekben található függvényeknél is meghatározhatod ha neked úgy tetszik hogy ezentúl más néven hívd őket a Peri kódban, s ehhez még csak bele se kell nyúlnod abba a már elkészült libbe, mindössze egy headerfájlt kell szerkesztened, egy tök egyszerű szöveges fájlt! Íme egy példa erre:

{ „__alsalib__” }
{ „__ALSAflag__” }
@__ALSAflag__  inv { one __ALSAflag__
::: __alsalib__ "/Inanelib/libinanelib_alsa.so.1.0.1" // Load the external library
:getvolume __alsalib__ "getvolume"
:setvolume __alsalib__ "setvolume"
:mute      __alsalib__ "mute"
:unmute    __alsalib__ "unmute"
:getmute   __alsalib__ "getmute"
}

 

A fenti az alsa.uh headerfájlja. Kevés funkció van még benne perpillanat de ez most mindegy. A lényeg hogy a 3 darab kettősponttal kezdődő sor betölti a libet, az 1 darab kettősponttal kezdődő kulcsszavakba meg aztán betöltjük a megfelelő függvényt. Akinek tehát tegyük fel nem tetszik az unmute kulcsszó, annak elég e fájlt szerkesztenie úgy, hogy e sort:

:unmute    __alsalib__ "unmute"

kicseréli erre:

:némítás_feloldása    __alsalib__ "unmute"
 

és ezentúl a Peri programok mindegyikében ahova e headerfájlt includeolja be, ő használhatja a

némítás_feloldása

kulcsszót ha neki ez úgy tetszik!

Mindez gyakorlatilag minden olyan krikszkrakszra is vonatkozik, amit láthattok a programjaimban, s amit olvashatatlannak ítéltek. Akinek tehát ez nem tetszik, megváltoztathatja.

Van ugyan néhány szabály a tokenizáláskor, amit a tokenizáló figyel, például hogy a kulcsszavak elején vagy végén van-e felkiáltójel meg sok más ilyesmi, ezeknek megfelelően beállít bizonyos flageket, de szerencsére ez úgy működik hogy egy utasítás megírásakor nem kötelező figyelembe venni minden variációt. Végeredményben minden nkulcsszó a Periben annyi sokféle toldalékkal meg prefixummal ellátható, hogy több mint tizenhatezer variációban létezhet ha jól számolom... Nyilvánvaló, hogy képtelenség lekezelni minden lehetőséget egy függvény megírásakor! DE EZ NEM IS SZÜKSÉGES. Ott van például a fent említett unmute kulcsszó. Ez az egyetlen variációja amihez jelentést rendeltem hozzá az ALSA libben. Ez azt jelenti hogy hiába írjuk e variációkban:

unmute!

!unmute

!unmute!

?!unmute[]()

unmute[3]

unmute§label

inv arc ?!unmute@()[]?!#g[37]§label§

(igen, még e legutóbbi is lehetséges ELVILEG. Gyakorlatilag azonban nincs ilyesmi a nyelvemben, megnyugodhattok!)

szóval hiába írjuk le a fenti formák bármelyikében az unmute kulcsszót: minthogy ezen variációk nincsenek lekezelve a libraryban implementált függvényben, ez azt jelenti automatikusan, hogy MINDEGYIK variáció esetén pontosan ugyanaz történik mintha a legközönségesebb szimpla módon egyszerűen az

unmute

kulcsszót használnánk...

Ez tehát mind csak LEHETŐSÉG, amivel nem muszáj élni...

Akadnak dolgok, amik nem ilyen könnyen megváltoztathatóak, például a ciklusokkal kapcsolatos szimbólumok, de még azok is megváltoztathatóak, csak icipicit nehezebb azokkal a helyzet. Ott is egyetlen állományba kell belenyúlni, de ahhoz már aztán újra kell fordítani a Perit. De pofonegyszerű az is, egy stringtömbben kell átírni fordítás előptt a megfelelő kulcsszót és kész.

A Peri esetén tehát messzemenő gondot fordítottam arra, hogy mindenki személyre szabhassa a tetszése szerint! Nem érdemes tehát itt a HUP-on vérre menő vitákat folytatni a kulcsszavak felett. NEM ÉRDEMES. Amint közzéteszem, úgyis mindenki könnyedén kicserélheti őket a neki tetszőekre. Elárulom, a Peri annyira szélsőséges mértékben customizable, hogy mindössze külső library által még az egyesek által annyira óhajtott infix notation is beleerőltethető - nyilván persze ennek sebességlassulás lesz az ára. De megoldható.

A Peri ugyanis szándéka szerint egy meglehetősen „üres” nyelv, ami alig csinál többet mint a paramélterátadást biztosítja a minimális core és a libek közt. Ez az üresség egyfajta jelképe is a Perinek, ezért van az hogy e sorban a fenti példa esetén:

::: __alsalib__ "/Inanelib/libinanelib_alsa.so.1.0.1" // Load the external library

az a szó szerepel hogy "Inanelib" és nem "Perilib". Inane van ott, ami angolul ugye olyasmit jelent hogy „üres”. Mert arra utal, a libek nélkül a Peri „üres”, alig van benne valami.

Elég sok helyen azzal indokoltad a Furor/Peri furcsaságait, hogy "így gyorsabb". Miért nem csinálod meg, hogy natív vagy bytekódra forduljon? Innentől kezdve a nyelv szintaxisát nem kéne a sebességhez igazítani, mivel az általad kihagyott dolgok (infix notation pl) legfeljebb a fordítási időt növelhetnék.

Psszt, elárulom az IP-címemet: 192.168.0.14

Ahhoz hogy natív kódra forduljon, nekem kéne megtanulnom nagyon alaposan az adott architektúra assemblerét, amihez nincs kedvem. Ahhoz pláne nem hogy minden létező architektúrát megismerjek annyira hogy el tudjam készíteni a fordítóprogramot.

A másik lehetőség az lenne hogy keresztfordítót írok, azaz C forráskódot állítok elő, s majd a C lefordítja natív kódra. ILYET MÁR CSINÁLTAM. A baj ezzel az, tapasztaltam, hogy nem tudok mindent megvalósítani vele amit szeretnék. A C nyelv jellemzően statikusan típusos nyelv, az én nyelveim pedig sokkal közelebb állnak a dinamikusan típusos nyelvekhez. Mert bár a stringjeimben tárolt adatok, változók stb alapvetően típus nélküliek, amennyiben nem jegyzik meg a típusukat, de a típus fogalmát azért ismeri ám a nyelvem, de annyira hogy bizonyos értelemben akár erősen típusosnak is lehet nevezni! Ugyanis az az egység ami nagyonis ismeri a típus fogalmát, az a Peri nyelvben a FÜGGVÉNY. Vagy ha úgy tetszik a névtér, mert a két fogalom a Periben azonos.

Egy függvényben mindig van egy speciális flag, ami egy kóddal tárolja hogy ő, a függvény most milyen típus szerint kell dolgozzék MINDEN ADATON, MINDEN MŰVELET ESETÉN amit végrehajt, egészen addig amíg e flag értékét át nem állítjuk valami másra...

Van néhány utasítás ami e flaget nem veszi figyelembe, egyszerűen mert ezen utasítások úgyis csak egyetlen típus szerint értelmezhetőek. De az utasítások többsége - így írom a könyvemben - TYPE-flag érzékeny.

Arra is van lehetőség hogy az utasításokat force-oljuk azaz azt mondjuk hogy a TYPE aktuális beállításától függetlenül az a konkrét művelet most a megadott típus szerint hajtódjék végre. Például a

sum

utasítás TYPE-érzékeny. De megadhatom így is:

sum#d

ami a TYPE aktuális beállításától függetlenül mindenképp double típus szerint fog dolgozni.

Szóval a Periben VAN típus, kifejezetten erősen típusos nyelv, csakhogy a típus nincs az egyes adatokra külön-külön meghatározva, pláne nem dől ez el a fordítás pillanatában, hanem a típus egyrészt a függvény hatókörében van meghatározva, ott dől el, másrészt bármikor megváltoztatható runtime.

Na és ilyen nyelvet piszkosul nehéz compilerként megírni. Nyilván persze simán lehetne hozzá compilert vagy keresztfordítót írni, de igazából nem sokkal lenne gyorsabb mint egy interpreter, mert mindenféleképp úgyis azzal kéne szöszölnie minden művelet végrehajtásának kezdetén hogy eldöntse, épp most milyen típus szerint kell dolgozzék, mert hátha az utolsó alkalom óta hogy e művelet lezajlott, megváltozott a névtér TYPE flagja...

Szóval a compiler csak a nevében lenne compiler, igazából majdnem ugyanúgy dolgozna mint most az interpreterem. Nem sokat nyernék vele. Ezért vetettem el ezt az ötletet. Pedig mondom, kísérleteztem már vele, ha nem is compilerrel de keresztfordítóval.

Szerintem is jó a perl, meg is kéne már tanulnom, de a "Hello world" nem hoz lázba.

Ezt nézem én is, hogy miért kell i-re cserélni az l-t.

Annyi betűsorozatot lehetne összerakni egy új, sőt kitalált világban használt névhez. Ubu, upu, pupu, hupu, ezek legalább tényleg idegenűl hangzanak, de aztán a furán meg a perl... 

Normális ember már nem kommentel sehol.

Lehet szánalmasnak tartod, de attól még a nyelv neve nagyon is hasolnít a PERL-re, kisbetűvel írva perl -> peri nem sok különbséget látni.

Az elmélet az, amikor mindent ismerünk, de semmi nem működik. A gyakorlat az, amikor minden működik, de senki nem tudja, miért.

És akkor mi van ha hasonló hozzá? Ki nem szarja le? Miért fontos ez?

Írd cirill betűkkel, s máris nem lesz annyira hasonló vizuálisan, ha téged ez zavar...

Azért választotam, mert:

1. A kiejtése magyarul is és angolul is szinte ugyanaz, márpedig elég kevés az olyan hangsorok száma ami megfelel e kritériumnak.

2. Rövid.

3. A jelentése pozitív, hiszen „jó szellemet” jelent.

Aztán ennyi, kész. Nem izgat hogy mennyire hasonló valami máshoz. Nem ugyanaz, ez a lényeg.

Teljesen mindegy mi mást választottam volna, úgyis belekötnétek abba is. A Furor nevébe is belekötöttetek anno.

Ennek amit írtál, kurvára semmi köze a témához. A topikhoz. Kezdjük azzal, nem is Emesének hívnak, sőt ez még csak nem is a nickem. Nem is az írói álnevem. És nem nő vagyok, még csak nőimitátor sem, hanem férfi.

Elárulnád mivel lőtted be magadat? Jó anyag lehet...

Mai fejlemények:

—Készen van a dokumentációból a Core rész, a standard library és az str library.

—Új funkciók:

1. vízszintes és függőleges progressbar rajzolására alkalmas string készítése CLI képernyőre a megfelelő ASCII karakterekkel, természetesen automatikusan, azaz a függvénynek csak a számtartományt kell megadni, az aktuális értéket és a kívánt stringhosszat, minden mást ő kiszámol.

2. String középre igazítása adott hosszra.

—Átdolgoztam (refaktoráltam) az egész memóriakezelő alrendszert, beleértve a memóriafoglalást és felszabadítást a shared memory területen is. Minden sokkal logikusabb lett. És robusztusabb. A Peri szintaxisa ettől még nem változott meg.

Szóval látjátok, dolgozom szorgalmasan, a mindenféle szapulások és ellendrukkereskedések, piszkálódások ellenére is...

Mert ugye, „A kutya ugat, a karaván halad”.

Szabad kíváncsiskodnom és kérdeznem?

Arra vagyok kíváncsi, hogy mit dolgozol az Amerika független szövetségi köztársaságban? Az nyilvánvaló, hogy szeretsz írni pl. regényeket na meg programozási nyelveket. Valamiért azt érzem, hogy nem programozóként dolgozol: Ha ez így van, akkor az is érdekelne, hogy miért nem dolgozol programozóként? Abszolút kinézem belőled, hogy megbirkóznál a feladattal, és ha eddig nem is volt tapasztalatod pl. webes szerveroldalon kódolni, belejönnél.

Biztos, hogy nem én gonoszoltam le!

Tényleg nem számítástechnikai munkakörben dolgozom, de ezt már korábban bevallottam. Mondjuk olyan minimális értelemben igen, hogy ha van valami rafkósabb informatikai feladat, akkor azt azért tőlem várja el a főnököm hogy megoldjam... de ilyen ritkán adódik. És mondtam is neki, hogy ezeket is csak akkor vállalom ha egyrészt Linux-related mert a Windowshoz nemcsak nem értek de gyűlölöm is és nekem elveim vannak, másrészt, webprogramozást még linuxszal összefüggésben se vállalok... De ez utóbbiról könnyű volt őt lebeszélnem, mert volt itt a lemezemen egy korábbi, sok év előtti weboldal amit még anno a regényeimhez készítettem, megmutattam neki... Abban a pillanatban hevesen kezdte bizonygatni hogy ő maga se óhajtaná rám bízni a webes dolgokat, elvégre egy ilyen magasan képzett szakemberhez mint én, az nem méltó... Persze ez kizárólag azt bizonyítja hogy az amerikaiak nagyon udvariasak. Ugyanis nyilvánvaló hogy egyszerűen rájött, gyökeresen eltér az ő „szépségideálja” az enyémtől. Szóval a web már emiatt se való nekem, mert nagy eséllyel amit én az Aspie tartok szépnek (vagy akár csak ergonomikusnak) az olyasmi hogy a „normális”, azaz neurotipikus emberek számára finoman fogalmazva se optimális vagy szép...

De amúgy tényleg utálom is a webes dolgokat, a programozásukat is, szóval ezt magam se kívánom.

Én maximum olyan helyen érezném jól magam programozóként ami valami embedded rendszerrel kapcsolatos, vagy kernelmodulok írása, meg más ilyesmik. Szóval valami „alacsony szintű” programozási feladatnál. Ami ahhoz hasonlít ahogy régen a C-64 -et kellett programoznom annak assemblyjében. Azok voltak a szép idők...

Látjátok, még a Peri is olyan nyelv lett ami sok szempontból az alacsony szintű nyelvekre hasonlít, mert bár nem assembly, annál azért magasabb szintű, de igazából talán még a sima C-nél is „alacsonyabb szintű”. Oké, van néhány funkciója amiben annál egy picit többet tud. De összességében semmi esetre se.

Általában véve azonban én nem akarok hivatásos programozó lenni. Valamikor tinédzser koromban akartam, kis ideig dolgoztam is úgy, de rájöttem, nem nekem való, mert a fenének sincs kedve a MÁR ELKÉSZÜLT programokat aztán hosszú ideig supportálni...

Én az új kihívásokat szeretem.

De meg ha a supporttól eltekintünk is, ott nem a magam örömére programozom, hanem mások mondanák meg milyen feladatot kell megoldanom, és még néha azt is, hoigyan. Milyen nyelven! És jól tudom tapasztalatból, amikor már a program majdnem kész van, gyakran jön a megrendelő hogy „van egy kis változtatás amit szeretne”, de ne ijedjek meg, csak egészen kis dologról van szó, tényleg, tíz perc alatt elkészülök vele biztos... Ilyenkor kezd izzadni a hátam mert tudom hogy az esetek 89 százalékában ez azt jelenti hogy teljesen újra kell írni a programot a legelejétől, és még meg se tudom magyarázni majd a megrendelőnek (vagy főnöknek, tökmindegy) hogy miért kell ennyi idő a módosításra, mert NEM ÉRTI MAJD MEG. Hiányzanak hozzá az ismeretei...

Kell a halálnak ez.

Egy hivatásos programozónak aztán meg még szabadideje, magánélete is alig van, mert elvárják tőle hogy minden idejében a munkával törődjön. És én szeretek programozni tényleg, látjátok a programnyelveimből is, de AZT szeretem programozni ami feladatot ÉN tűzök ki magam elé! De erre nem volna időm ha hivatásos programozó lennék, akkor minden időmben a hivatalos feladatokon kéne járjon az agyam, még otthon is. Akkor is ha nem kötelező. Amíg meg nem oldom, nem tudnék arra koncentrálni ami a hobbym lenne.

Ismétlem: kell ez a halálnak...

Egy idő után aztán én is elkurvulnék. Ami azt jelenti, nem érdekelne a minőség csak hogy kész legyen a feladat minél előbb valahogy. Mindenféle keretrendszereket meg „köztes rétegeket” használnék hogy gyorsuljon a programfejlesztés, ami azzal járna hogy bloatware és lassú szarok kerülnének ki a kezem alól. Méltatlan lenne hozzám. De ezt tenném, mert most hogy a magam örömére programozom, a programozást művészetnek tartom, a szememben igenis a művészetek egyik ága, de akkor hivatásos programozóként csak MUNKA lenne a szememben, izzadtságszagú munka, elvesztené a varázsát... Csak túl akarnék lenni rajta minél előbb...

Ahogy most vagyok, sokkal megfelelőbb. Ha vége a munkának azt csinálok amit akarok, élhetek a hobbymnak. De gyakran még munka közben is járhat az eszem akármin, mert ritka esetektől eltekintve szellemileg nem olyan rém kimerítő a munkám. Akadnak stresszes időszakok, főleg amikor a főnök elutazik hosszabb időkre és olyankor lényegében én vagyok a cégvezető... (igen, a jobbkeze vagyok úgy általában is már, rég...) és utálom ezen alkalmakat a stressz miatt... de, mondom, ez nem gyakori. Többnyire tehát ez nekem most nagyon megfelel úgy, ahogy vagyok.

Ha az irigység fájna, hangosan üvöltenél.

Azzal az erővel amit az ellenem való fenekedésbe fektetsz, a trollkodásba, sikerült volna már rég megoldanod a billentyűzetproblémádat, és nem kellett volna sok pénzt kiadnod egy újra. De hát van aki az alkotáshoz ért, van aki meg csak a trollkodáshoz.

Ne törődj velük, segghülyék hozzád képest, arra sem emlékeznek hogy tegnap mit írtak. Az igaz hogy te is egy troll vagy, de te legalább ahhoz értesz, a trollkodáshoz. Ezek azonban még ahhoz se, szellemi nímandok veled összehasonlítva.

Ha trollkodni akarsz, ne állj be a csapatukba, trollkodj egyedül ellenem, a magad képességeire alapozva, mert egyrészt más nem méltó hozzád, másrészt nem is szorulsz rájuk, harmadrészt pedig ha velük csapatban próbálod akkor az ő ügyetlenségük csak lerontja a te trollkodásod hatását, tudod, felhígítja a gonoszságodat, s akkor az már nem is annyira maró. Ez olyan hogy a citromsav is mar, meg a sósav is, de a sósav nem lesz hatékonyabb ha felhígítják citromsavval, sőt, az csak ront a hatásán.

Most hogy vége a Karácsonyi tűzszünetnek...

 

Egyre több jelét mutatod a skizofréniának. A múltkor még én voltam az ultimate trollod, most meg már kisbetű az? Vagy ezeket a hozzászólásokat "bemindenezve" tolod ki magadból és csak simán elfelejted kinek írtál korábban?

Hivatásos pitiáner
neut @

Te mostanában többet trollkodol mint kisbetu (bár Pepo is szépen jön fel hozzád tegnap óta..) így a mennyiséget tekintve valóban nagyobb troll vagy mint ő, mondjuk a hétnapos mozgóátlagot tekintve. Mégis, az egy pillanatig se vitás hogy ami a trollkodás okozta fájdalmat és bosszúságot illeti, kisbetu messze hatékonyabb. Te inkább csak durván meg alpári módon hülyéskedel, gúnyolódol. Kisbetu azonban tudatosan figyel és elemez, azért, hogy kitalálja, miként tudja a másiknak a legnagyobb fájdalmat okozni. Miként tudja őt a legmélyebben megalázni. Te csak mondod ami épp eszedbe jut, de ő komoly energiát fektet bele. Tervez. Gondolkodik.

És mert még esze is sokkal több van mint neked, sőt mint neked meg sok más trollnak összesen, ezért az ő trollkodása hatékonyabb is. Mert műveltebb nálad. Tanultabb. Kár hogy a tehetségét ilyen megvetendő dologra pazarolja alkotás helyett, de legalább az nem tagadható hogy ebben tényleg hatékony, ehhez ért, szóval VAN tehetsége. Neked azonban nincs.

Ha hasonlatot keresek rátok, azt mondhatom, te meg pepo olyanok vagytok mint a Star Wars-ban a birodalmi rohamosztagosok: pufogtattok erre meg arra, néha találtok is, de inkább csak véletlenül, azaz a hatékonyságotok csekély, és teljesen mindegy melyiktek műveli mert arc nélküli senkik vagytok akikből tizenkettő egy tucat.

Ezzel szemben "kisbetu", ő lenne e hasonlatban a Darth Vader...

Nos, egész jól eltaláltad, e hasonlatban talán valóban a hercegnőnek felelek meg, hiszen azt próbálják bántani (megölni, kínozni stb) mind a rohamosztagosok, mind a Darth Vader. Plusz, ugye olyan "érzékeny" vagyok mint egy (széltől is óvott...) hercegnő. Vagy legalábbis arisztokrata, még ha nincs is hercegi rangja.

Ennek ellenére, bármily találó legyen is e hasonlat, én szívesebben gondolok magamra úgy, hogy én vagyok (e hasonlatot tovább víve) a "Luke". S amiatt az, mert ő az aki végül az utolsó pillanatban "megjavítja" a Darth Vadert, azaz visszahozza a Sötét Oldalról... Biztos tudod melyik jelenetről beszélek.

(Bocs, magas labda volt.)

Nincs harag miatta. Ez még nem volt trollkodás.

Komolyan érdekelne, hogy még ha úgy volna is hogy egy egyszerű kocsitologató vagy akár a legigazibb vécépucoló lennék is a Wallmart-ban, vagy akárhol másutt; vagy egyszerűen egy házicseléd lennék valami gazdagabb családnál, vagy disznók alól pucolnám a szart egy farmernél, na akkor is, MI VOLNA EBBEN A MEGVETENDŐ?!

Mert szerintem abszolúte semmi.

Tudniillik ezen munkák elvégzése is SZÜKSÉGES, azaz, ha valaki megcsinálja, az becsületes munkát végez. (Azaz mindenképp tisztességesebb időtöltés mint a trollkodás a fórumokon...).

Nem mellékesen amúgy, az egy tökéletes tévhit a részetekről hogy csak az az értékes ember aki úgymond „sokra viszi”, olyan értelemben hogy „karriert épít”, azaz mindenféle ügyeskedéssel rengeteg pénzt szerez (kicsal másoktól...), szükségtelenül nagy házban lakik, és azért vesz drága pénzért yachtot, hogy évente egyszer 5 napig használja.

Én messze többre becsülöm az Alkotókat, márpedig az alkotáshoz az a munka a megfelelőbb ami kevesebb stresszel jár. Azaz KÖNNYEDÉN el tudom képzelni, hogy az említett levélszedegetés az ereszcsatornákból sokkal megfelelőbb lenne nekem, mint mondjuk egy multinacionális vállalat vezérigazgatójának lenni. Utóbbi mellett ugyanis semmit se írhatnék...

És tényleg hívtak már New Yorkba, középvezetőnek, de épp emiatt nem fogadtam el. Említettem már.

Mégvalami. Izrael egyik leghíresebb írója például önként vállalta el a kibucban a buditakarítást, ÉPP AZÉRT, hogy több ideje maradjon ÍRNI, azaz alkotni, és kevesebb legyen számára a stressz! Nem írom le kiről van szó, keresse meg aki akarja.

Annyit elárulok nektek hogy legyen min csámcsognotok, hogy egy egészen apró kis lyukban lakom (na, külön fürdőszoba azért van hozzá mert tiszta ember vagyok...), ez ugyanis olcsó, és nekem ez is megfelel, sőt jó is: kevesebb idő megy el a rendrakással, így több időm marad megintcsak írni...

Tehát, mi lenne a baj ezekkel az említett munkákkal? Miért is volna az szégyellni való, ha ezeket végezném?

Észrevehettétek volna már hogy én rég nem a napi munka által akarok „valaki” lenni, hanem azzal amit azon felül alkotok...

Ismétlem, én abban se találnék semmi kivetnivalót. Egyelőre azonban a dolog nem aktuális mert a barátaim az USA-ban élnek.

Hanem, ebben a pillanatban rádöbbentem, lehet hogy hálás kell legyek neked. E postod nyomán beugrott, hogy hiszen WC-pucolóról jóeséllyel még senki nem írt sci-fit... na megvan min töröm majd a fejemet! Lehet hogy én írok róluk. Még nem tudom mit, de így első blikkre nagyon tetszik az ötlet.

Sajnos, író vagyok és nem feltaláló...

Ez azonban hogy vécépucolóról írni, ez nem is áll olyan távol a „klasszikus” irodalmi alkotásoktól, mint ahogy első hangzásra tűnik. Már amennyiben a meséket klasszikus műfajnak tekintjük. Akárhogyis, elég régi műfaj. És emlékezz rá, a mesékben is mindig a kondás megy el szerencsét próbálni. Épp a kondás, akiről a műveltebb emberek tudják, hogy akkoriban (a mesék keletkezésének idején) a falu legmegvetettebb és legszegényebb embere volt!

És aztán mégis őbelőle lesz a mesében a tündérek királya, s tündérlány lesz a felesége. Vagy legalábbis valami közönséges, emberi országban lesz király. Az aztán tényleg az abszolút minimum!

A mai társadalomban efféle megvetett foglalkozás épp a vécépucolóké, emiatt akartok ti is épp ezzel gúnyolódni rajtam. Arra célozgattok hátha az vagyok, így remélitek hogy inkább elárulom a tényleges munkakörömet. Hát ez nem fog összejönni nektek, bár ismételten kihangsúlyozom, semmi gondom nem lenne azzal se ha vécéket pucolnék. Ezennel írásba adom, messze becsületesebb és tiszteletre méltóbb dolognak tartom a vécéket pucolni az USA-ban, mint akár miniszternek is lenni Orbán Viktor kormányában!

De a lényeg tehát, hogy a mai kor „kondása” ilyen értelemben a vécépucoló. Amennyiben arról akarok írni, hogy egy teljesen megvetett, semmire se becsült szegény ipse miként csinál káprázatos karriert/szerencsét, akkor keresve se találhatnék alkalmasabb főhőst mint egy vécépucolót!

Látod, kisbetu, a bölcset a bolondtól az különbözteti meg, hogy a bölcs mindenkitől képes tanulni, még a bolondtól is, a bolond azonban a bölcstől se!

Én képes voltam „tanulni” most Pepotól, aki ha talán nem is bolond, de legalábbis troll. Oké, nem volt igazi „tanulás” ez, de észrevettem mégis a hasznosat a postjában: az ötletet amit felhasználhatok majd!

Emiatt is lenne jó ha ti trollok is figyelnétek rám a trollkodás helyett. Én elismerem hogy fura fickó vagyok, de ettől még simán tanulhatnátok néha ezt-azt tőlem, még ha csak apróbb dolgokat is tán, amennyiben olyan bölcsek és okosak lennétek mint amilyennek képzelitek magatokat.

Észrevehettétek volna már hogy én rég nem a napi munka által akarok „valaki” lenni, hanem azzal amit azon felül alkotok...

Eddig nem sikerült, try again. Te vagy korunk meg nem értett géniusza? Ezért kellett Amerikába migrálni, hogy ott legyél "életművész"? Itthon is lakhatsz egy lukban, olcsón is. Miért kellett kitántorgóvá válni?

Hivatásos pitiáner
neut @

Hát persze. Csak nem ugyanolyanok a nehézségi feltételek.

Vedd már észre hogy lyukra futottál ezzel a trollkodással! Nem én vagyok az első aki elhagyja azt az országot. Ez már szinte szabály a tehetséges embereknél, lassan évszázadok óta. Sőt, az utóbbi években a helyzet olyan szar lett hogy még tehetségesnek se kell lenni ahhoz hogy valaki elmenjen: egy egyszerű tucatember is ha van valami középfokú végzettsége, nagy eséllyel kimegy!

És még ez se elég, mert már a semmiféle végzettséggel se rendelkező közönséges háziasszonyok is gyakran kimennek, cselédnek vagy idősgondozónak, mert már akkor is jobban élnek, úgy vélik. És igazuk van.

Szóval nagyon kérlek, ezt a vonalat hagyd. Ezzel úgy égeted magadat hogy már én pirulok helyetted. Ez még trollkodásnak is szánalmas, tényleg. Értem én hogy irigy vagy, de akkor is valami mást kéne kitalálnod.

Értem én hogy irigy vagy

 

Mire is?

-saját bevallásod szerint is egy lyukban laksz (de van légkondi!!!!)

-a sikert a "megjelent" könyveid alapján méred, nem pedig azok forgalmával

-a kiterjedt szociális hálódra, temérdek barátodra?

-az n+1 "programozási" nyelvedre, amit rajtad kívül a sarki kutya sem használ?

 

Annyi kérdés, nem is tudok dönteni...

Hivatásos pitiáner
neut @

Én se értem miért kell irigykedned rám, de tény hogy egyfolytában azt teszed mert láthatóan a mániáddá váltam, állandóan velem foglalkozol, nekem postolsz, engem igyekszel szapulni. Ez mind olyan tünet ami az irigyekre jellemző. És hiába tagdod le, mert az irigyek mindig letagadják hogy irigyek.

"Ez mind olyan tünet ami az irigyekre jellemző. "

Ez csak a te diagnózisod.

Azt meg sose fogod megérteni, hogy a stílusod az, ami a bicskát nyitogatja. Aki meg szóvá meri tenni, az irigy és troll. Mert más nem lehet.

Ja, dehogynem: GONOSZ. :Đ

Normális ember már nem kommentel sehol.

 

Azt meg sose fogod megérteni, hogy a stílusod az, ami a bicskát nyitogatja.

Nem tudom mi lenne a baj a stílusommal, én senkit nem szoktam sértegetni, mármint, nem szoktam ELSŐKÉNT. De különben is, ahogy mondják, „a stílus maga az ember”, azaz ha akarnám se tudnék változtatni rajta, és tökéletesen naív elképzelés a részedről vagy bárki más részéről hogy majd hirtelen megváltozik a stílusom pusztán csak mjert trollkodtok velem.

Ja, dehogynem: GONOSZ. :Đ

Úgy tűnik nekem e bejegyzésedből hogy minapi szép reményeim nem válnak be. Hát, most le vagyok targiázva. Igazán rémségesen szomorú hogy ekkora a gonoszság hatalma feletted, ilyen mélyen beléd rágta magát. :( Attól tartok azonban, ennél többet igazán nem tehetek érted. Nem születtem varázslónak, csodát tenni nem tudok. Ha mégis meggondolnád magadat, tudod már, miként érhetsz el.

Nem tudom mi lenne a baj a stílusommal, én senkit nem szoktam sértegetni, mármint, nem szoktam ELSŐKÉNT. De különben is, ahogy mondják, „a stílus maga az ember”, azaz ha akarnám se tudnék változtatni rajta, és tökéletesen naív elképzelés a részedről vagy bárki más részéről hogy majd hirtelen megváltozik a stílusom pusztán csak mjert trollkodtok velem.

Ezekkel a csodás többszörösen bővített mondatokkal.

 

Úgy tűnik nekem e bejegyzésedből hogy minapi szép reményeim nem válnak be.

Nem jött be a szerelmes levél? Try again.

Hivatásos pitiáner
neut @

Ezekkel a csodás többszörösen bővített mondatokkal.

Ja, szóval hogy te bunkó vagy, ha egy mondat 3 szónál hosszabb az már megfekszi az értelmedet. Hát édes öregem én író vagyok, azaz műveltebb nálad eszerint. De legalább már értem hogy nem csak az elért sikereimre vagy irigy, de a műveltségemre is ami sokszorosan felülmúlja a tiedét.

Az ugye megvan, hogy nem kötelező olvasnod a hozzászólásaimat? És a topikjaimra kattintani pláne nem kötelező? És pontosan tudhatod melyek a topikjaim mert meg vannak jelölve mind [HK] előtaggal?

Szóval ne sírj nekem. Szabad akaratodból olvasod amit írok. Az lehet hogy szenvedsz közben, de mert ez tényleg nem kötelező,e z csak annyit jelent hogy akkor mazochista vagy. Azon meg nem segíthetek, keress fel egy pszichiátert.

Egyet nem értek csak. Mi a FASZÉRT olvassátok? Azt megfigyeltem, hogy van egy csoport, amelyik szándékosan kínozza magát ezeken a tartalmakon. Én meglátom a szerzőt, a negyed oldalnyi kommentjét és már ugrik is el a szemem. Worksforme.

Szerintem ti élvezitek.

trey @ gépház

Most abszolút egyetértek veled! Tényleg élvezik, más nem lehet a magyarázat. Pedig ez így van jól ahogy te csinálod Trey: ha nem érdekel, nem olvasod! És ugye hogy SOHA semmi baj vagy veszekedés nem volt köztünk amiatt hogy nem olvasod az írásaimat, soha nem panaszkodtam emiatt! Rengeteg mindennel lehet engem vádolni, de azzal az eggyel soha hogy valaha is belekötöttem volna bárkibe is azért, mert nem olvassa az írásaimat! Ami blogot nyitok az meg direkt meg van jelölve [HK]-val hogy még kattintani se legyen muszáj rá annak akit én cakpakk nem érdeklek!

A stílusod a tl;dr. Azzal sértesz meg bennünket, hogy így írsz, pedig láthatod, mindenki berzenkedik ellen.

" ha akarnám se tudnék változtatni rajta" Látszik. Írási kényszered van. De miért nem lehet ezt az időt a regényeidre fordítani? Azt írtad, azokra jöttek pozitív reakciók.

"Attól tartok azonban, ennél többet igazán nem tehetek érted. Nem születtem varázslónak, csodát tenni nem tudok. " Pedig pici önuralommal sokat elérnél. Csak nem akarsz változtatni.

Normális ember már nem kommentel sehol.

Önuralomra neked volna szükséged, hogy harcolj a téged emésztő GONOSZSÁGGAL szemben.

Az lehet hogy nekem íráskényszerem van, ellenben neked tényleg nem kötelező a [HK] kezdetű címekre kattintani. Miért tőlem vársz „önuralmat” hogy ne blogoljak, amikor TE arra se vagy képes hogy ne kattints ezekre?!

Mert még ha a mások topikjaihoz írt hozzászólásaimon trollkodnál, valahogy megérteném: ott vagy abban a topikban, mindent elolvasol, azt is amit én írok, oké. De ami [HK]-val kezdődik arról előre pontosan tudod hogy én írtam, mégis rákattintasz. Miért?

Megmondom: MERT GONOSZ VAGY.

A másik elehtőség hogy mazochista, de ekkor megint nem bennem van a hiba. Különben meg egyszerre is lehetsz mindkettő: egy gonosz mazochista,

Amikor ezt írtam neked:

Attól tartok azonban, ennél többet igazán nem tehetek érted.

azt pedig úgy értettem, hogy azért nem tehetek többet hogy kigyógyítsalak a Gonoszság nevű lelkibetegségből. Kár hogy még ezt se voltál képes felfogni. Biztos épp a gonoszság nem engedte benned ennek megértését se. Tudod, amolyan pszichológiai elhárító mechanizmus.

Szerkesztve: 2020. 12. 01., k - 06:16

Na drága gyermekeim az Úrban s az Űrben, most végre elégedetten hajtom nyugovóra a fejemet a mai nap folyamán (illetve már holnap mert éjfél után 10 perc van itt): Ugyanis befejeztem végre-valahára a Peri nyelv dokumentációját, igaz, még csak magyar nyelven!

De legalább ez készen van.

Mondjuk apró változtatások még lehetségesek, stilizálás, stb, az se kizárt hogy a Peri maga is bővül pár apró funkcióval... Ez már nem számít. 99.999 százalékban kész, elmondhatom.

Most a programozást illetően HOSSZÚ-HOSSZÚ pihenés következik számomra! A következő munkám ugyanis teljesen más jellegű. A regényes önéletrajzomat kell lefordítani angolra, legalább valami használható nyersfordítás szintjén, mert a lektorom Ausztráliában már nagyon követeli, és igen mérges hogy ennyi időt „elpocsékoltam” a programozásra, amikor írhattam is volna helyette.,..

Na de legalább ez az életfeladatom befejezve.

Hogy mikor lesz közzétéve, nem tudom, előbb el kell ennek is készíteni az angol fordítását... Majd meglátom. Mindenesetre ha az elkészül, közzéteszem, és BSD licenc alatt lesz, ezt már tudom előre.

Aztán ugye, ha az önéletrajzomat lefordítom még akkorsenem a Peri jön hanem a Lidércgyermekek című regényem lesz lefordítva... Ajaj, van itt munka bőven, egy rahedli!

Na szép álmokat drágaságaim.

Reszkessetek! Elkezdtem kibővíteni a Peri nyelvet infix notation képességgel!

És ehhez semmit se kellett belenyúlni a Core-ba, megoldható egy libraryval, hehehe...

Már működik pozitív egész számokra, számkonstansokkal. Most már csak játék innen hogy mindent tudjon így is.

És ezek után az a kifogás se lehet a nyelvem ellen, hogy mert a RPN szintaxis „nehéz”. Nem tudom, mi a tököm lenne nehéz azon... de aki akarja, ezek után használhat majd helyette infixet is, sőt a kettőt vegyesen is!

Hányszor kell még leírnom neked ahhoz hogy felfogd végre: abban a pillanatban közzéteszem, amint készen lesz az ANGOL FORDÍTÁSA?!

Mit nem tudsz ezen megérteni? Nem ismered a magyar nyelvet, nyelvtannácikám?

Nem, a nyelvem nem publikus. MOST MÉG NEM. De tettem egy ígéretet hogy az LESZ, s azt is megírtam mikor: amint készen lesz a doksi angol fordítása! Még azt is előre leírtam, BSD licenc alatt lesz publikálva! Ennyire szabad lesz!

Mit keresel egy magyar fórumon ha még egy ilyen egyszerű magyar mondatot se tudsz megérteni?

Ígéretekkel tele a fiók.

Sőt, az előző fiókot meg is semmisítetted.

 

"Mit keresel egy magyar fórumon ha még egy ilyen egyszerű magyar mondatot se tudsz megérteni?"

Szeretnék tanulni egyik legnagyobb magyar írónktól. Én tettem volna egy vesszőt a ha elé, de ezek szerint ezt az egyszerű dolgot sem tudom jól magyarul.

Normális ember már nem kommentel sehol.

Sőt, az előző fiókot meg is semmisítetted.

Többek közt miattad is, mert te voltál az egyik fő troll, azaz köszönd magadnak.

Nota bene, a hülye trollkodásaitok rengeteg időmet elrabolták. Ha nem teszitek, egészen biztosan előbb lett volna készen a programnyelvem, így az angol fordítás is előbb lenne kész, és előbb élvezhetnétek a publikussá tett végterméket. Vedd észre amúgy hogy most is trollkodsz, azaz lopod az időmet. Azaz te magad vagy az aki késlelteted a publikussá tételt.

Megbocsáss, de minden hozzászólásodból az süt, hogy csak az az igaz, amit te írsz, a többiek nyilvánvalóan tévedésben vannak.

De hogy ezt nem érzed, azt betudjuk a betegségednek. Nem értünk egyet vele, de együtt élünk vele. 

Normális ember már nem kommentel sehol.

Ha meggyőződésed hogy beteg vagyok, akkor minek szekálsz állandóan a trollkodásaiddal? Vagy bármivel még ha te nem is tartod trollkodásnak, de hát látod hogy én annak tartom? Szerinted szép dolog direkt bosszantani és szapulni egy BETEGET?

Pedig eszerint te azt teszed. Na látod, ugye hogy GONOSZ vagy!

Valaki kötelezi őt, hogy trollkodjék?

Nem mellesleg, ha nem is válaszolok, nyilván elolvasom a kommentet, s már az is időveszteség, azaz akkor is lopja az időmet.

Emellett, a troll komment ugyebár bosszant, függetlenül attól válaszolok-e rá, emiatt egy darabig azon jár az eszem, s nem a programnyelvem további fejlesztésén és/vagy a doksi fordításán, azaz megintcsak időveszteség.

Ellenkezőleg, épp arra van számos bizonyíték hogy nagyonis véghez viszem a projectjeimet.

Meg akartam tanulni Eszperantóul: megtanultam. (még nyelvvizsgám is van belőle).

Meg akartam tanulni németül: azt is megtettem, még ha csak alapszinten is.

Író akartam lenni: lettem. Nem is egy könyvvel.

Ango író akartam lenni: íme, van már angolul is készen művem, nem is egy!

Le akartam fordítani a GoboLinux honlapját: megtettem.

Könyvet akartam írni a VIM-ről: megtettem. (Elérhető a MEK-ből ingyen ha érdekel téged).

Saját disztrót akartam: elértem. Mert megtanultam az LFS-t, sőt már azt se kell szolgaian másolnom, mert módosítottam a filesystem-rendszert benne, gobolinux-szerűre.

Programnyelvet akartam írni: nem is egyet írtam. Sőt egyre jobbakat.

Le akartam fogyni: SIKERÜLT.

Mennyi bizonyíték kéne még arra, hogy a projectjeimet véghez viszem?!

Boldog lehetnél ha tizedannyi dolgot véghez vittél volna életedben, mint én...

"Boldog lehetnél ha tizedannyi dolgot véghez vittél volna életedben, mint én..."

Tudod, van akinél nem az a jellemző, hogy mindig kérkedik a teljesítményével, eredményeivel.

 

Most pedig sorold fel azokat a projectjeidet, amikre valós igény volt.

Hivatásos pitiáner
neut @

Most pedig sorold fel azokat a projectjeidet, amikre valós igény volt.

Ha olyanra gondolsz aminek készítésére előre felkértek, ilyen egy se volt.

Akadt azonban nem is egy, amiért utólag kaptam elismerést, például:

—A VIM -ről írt könyvem,

—A "Nagy Ateista Könyv"

—Számos egyéb könyvem, azaz kalandregényeim - bár elismerem, nem mindegyik. De SOK.

Továbbá, ne terelj! Az előbb még szó se volt olyasmiről a trollkodásodban hogy „valós igény”. Arról volt csak szó, befejeztem-e valamelyik projectemet. Befejeztem, látod. Ez válasz volt a kérdésedre. Abban a kérdésben nem volt szó „valós igényről” még.

Különben is: sejthetnéd rólam, rég leszarom mások „valós” vagy valótlan igényeit. Amit csinálok, elsősorban magamnak csinálom, még akkor is, ha nyilván örülök neki ha később kiderül, más is használja. Mindazonáltal a számomra ez akkor is egy huszonhatodrangú jelentéktelen részletkérdés.

Többféleképpen is lehet filterezni a hupukat, asszem a közelmúltban is írt valaki blogot róla, hogyan kell. Javaslom, próbáld ki.

Igaz, e módszer hátránya az általad felvetett önkéntesrendőri moderátorjoghoz képest, hogy nem lehet arra maszturbálni, hogy ki tudod törölni mások hozzászólásait. 

Megmondom őszintén, halvány gőzöm sincs róla mi az a privoxy. Sejtem hogy valami hálózatos izé lehet, de a hálózatokhoz teljesen síkhülye vagyok.

Ez van. Én se érthetek mindenhez... Nyilván meg tudnám tanulni azt is ha annyi energiát fektetnék bele mint a programnyelvírásba, de az a helyzet hogy nem érdekel ez a téma.

Ennyit nekem nem ér meg a dolog.

// ==UserScript==
// @name         HUP blocklist userscript
// @version      03-jan-2021
// @description  hides the messages of given users
// @author       bohocmasni
// @match        https://hup.hu/node/*
// @grant        none
// @require      http://code.jquery.com/jquery-3.4.1.min.js
// @run-at       document-idle
// ==/UserScript==

(function() {
    'use strict';

var partial_hide = true
var allow_peek = false

var $ = window.jQuery

var kisbetu_id = 5097
var neutrino_id = 17851

$(' article[data-comment-user-id="' + kisbetu_id
  +'"], article[data-comment-user-id="' + neutrino_id
  +'"]' )
  .each(function( index ) {

    if (partial_hide) {
      $( this ).children().eq(1).hide()
    } else {
      $( this ).hide()
    }

    if (allow_peek) {
      $( this ).click(function(){
        $( this ).children().eq(1).toggle();
      });
    }

});

})();

Próbáld meg ezt, grízlimajommal, nálam működik. 3 módja van, a tetején lehet állítgatni (4-et enged, de 2 egybeesik). Ha több felhasználót akarsz, akkor értelemszerűen a mintaillesztésben a középső sort megsokszorozod. 

Nagyon szépen köszönöm a kedvességedet, de mi az a "grizlimajom"? Tippelem valami olyasmi aminek eredetileg "monkey" a vége, de így se tudom mire gondoljak.

Kérlek értsd meg, én soha életemben nem foglalkoztam:

—webprogramozással

—böngészők pluginezésével

—javascripttel

stb. Tehát én azt se tudom ezt a szkriptedet hova kéne betennem a Palemoon böngészőmbe! Egyszerűen síkhülye vagyok az efféléhez és még azt se tudom hogyan induljak el, desőt még azt se egyáltalán mit kéne beleírnom a gugliba ahhoz hogy legalább elindulni tudjak.

Ha ez egy C kód volna amivel valamelyik forrásfájlt kéne módosítani a Palemoon kódjában, nem jönnék zavarba, tudnám mit kell tenni, meg újrafordítani, stb. Még azt is meg tudnám oldani jóeséllyel ha nem az én verziómhoz készült volna; tudnám hogyan nézzem át, miként módosítsam, stb. De ez itt egy teljesen más eset, ez totál kívül van azon a területen amit valaha is tanulmányoztam. Megkérlek tehát rá, légy oly kedves és adj részletes instrukciót lépésről lépésre, miként használhatom ezt a cél érdekében! Olyan részleteset tényleg mintha egy Windowsról Linuxra most áttérő r=0 usernek magyaráznál, mert ilyen téren hogy web, én majdnem azon a szinten állok! Hova másoljam ezt a fájlt, stb...

Palemoon verzióm: 28.9.2, 64 bites

Köszönöm szépen előre is!

userscript ezeknek a programoknak a neve: https://en.wikipedia.org/wiki/Userscript

Nálam a következő működik palemoonnal:

  1. letöltöd a palemoon Add-ons áruházában a guerilla scripting nevű kiegészítőt, újraindítod a böngészőt
  2. elvileg megjelenik a böngészőhöz tartozó profil mappádban ( .moonchild productions/pale moon/[RANDOM].default/  vagy ilyesmi ) egy guerillajs nevű mappa
  3. ennek a scripts almappájában létrehozol egy HUPBLOCK.js fájlt és egy HUPBLOCK mappát, fontos, hogy a nevek megegyezzenek
  4. a HUPBLOCK mappába letöltöd a https://code.jquery.com/jquery-3.4.1.min.js oldalról ezt a javascript file-t, és elmented jquery-3.4.1.min.js néven
  5. a HUPBLOCK.js fájlba bemásolod amit a scriptet amit írtam, azzal a módosítással, hogy a 8-ik,
    // @require      http://code.jquery.com/jquery-3.4.1.min.js

    sort inkább

    // @requirelib   jquery-3.4.1.min.js

    -re cseréled. (( A guirella scripting leírása szerint ennek úgy kéne működnie, hogy ha csak @require szerepel, de úgy meg nem működik, elég béna ))

  6. Nem kell semmit leokézni, ha megnyitod a HUP-ot, akkor működik.

Ez REMEK!

Nagyon de nagyon szépen köszönöm neked kedves "bohocmasni"! Így már tudtam telepíteni a leírásod alapján. És REMEKÜL MŰKÖDIK!

Ajánlom másoknak is a figyelmébe, mindenkinek akit zavarnak a trollok, de AZOKNAK IS AKIKET ÉN ZAVAROK!

Tényleg nem fogok megsértődni ha valaki közli hogy felvett engem erre a listára...

Csodálatos szkript tényleg. Igaz hogy nem „törli ki” a teljes szálat de ez talán nem is baj, hiszen abban azért lehetnek olyan kommentek más userektől, amiket látni szeretnél.

A trollnak megjelölt illető hozzászólásából csak annak a „fejrésze” látszik vagy hogy nevezzem... ez még nem olyan zavaró, tudom hogy az illető odaszörtyögött valamit, semmi gond, úgyse vagyok rá kiváncsi hogy az mi... Ha mégis fontosat akar közölni nekem, írjon pirivit...

A következőket tettem most troll-listára de erről majd írok külön is blogbejegyzést mindjárt mert illik hogy tudjanak róla:

—kisbetu

—neutrino

—pepo

—NagyZ

—evone

Mégegyszer nagyon szépen köszönöm "bohocmasni" segítőkészségét, ez rendkívül nemes tett volt a részéről! Bár mindenki ilyen lenne mint ő!

Haroldgen.exe

Azt hallottam, hogy még 0-val osztást is engedi.

Most azt hiszed vicceset mondottál. Pedig még a CARNEVÁL diétát követő ŐSEMBER is képes volt nullával osztani! Meg mi az már, hogy legostobább programnyelv? Attól, hogy te kételkedel a működőképességében még ez egy igazán innovatív fejlesztés, javaslom próbáld ki mielőtt ítéletet mondasz eme remek szerkezet felett! Amúgy ajánlom, hogy próbáld ki a sült gilisztát, nagyon finom! Igaz, hogy kicsit föld íze van, de mivel szeretnék közelebb kerülni Gaia-hoz, ezért megyek is meditálni, hogy ki tudjam zárni a magadfajta trollokat az elmémből. Végtelenül GONOSZ vagy, egy igazi romboló, de ha gondolod írok neked egy kisregényt mailben, hogy megadjam neked is az esélyt a JÓSÁG elérésére. Kérlek emeld fel a message size limitet 100 megabájtra.

Auuuummmm.... Auuuummmm.... Auuuummmm....

Hivatásos pitiáner
neut @

Másik lehetőség, hogy ha megbízol ennek https://github.com/janekptacijarabaci/greasemonkey/releases/tag/3.31.4F… az írójában, akkor letöltöd az egyik .xpi kiterjesztésű file-ot, a palemoon felajánlja hogy telepíti, telepíted, újraindítod a böngészőt. Ekkor megjelenik a böngészőben jobb felül egy kis majmocska.

Kijelölöd az userscriptemet, és rárakod a vágólapra. Majd a majmocka melletti kis nyilacskára kattintasz, majd arra hogy new userscript. Itt lesz egy olyan gomb, hogy use script from clipboard (amely gomb csak akkor jelenik meg, ha egy script van a vágólapodon, egyébként nem), arra rákattintasz, és ctrl+s, elmented.

(Az áruházas kiegészítők sem megbízhatóbbak, de azt legalább el tudják távolítani a gépedről, ha kiderül hogy hibás/rosszindulatú.)

Ha az allow_peek változót true-ra átírod, akkor kattintásra kinyitható a szövegdoboz. Ha meg a partial_hide változót false-ra állítod, akkor meg nem látszik az elrejtett hozzászólás fejléce sem.

Mindenhogy valahogyan kényelmetlen, de azért, mert a helyzet maga megoldhatatlan: valakiket nem kéne látni, de mégis jó lenne tudni, hogy miről van szó.

Minden jó érzésű magyar véresre kaparja az arcát a hejesírása láttán. :-D

Egyébként, ne tanítsd, mert magára veszi. Látom lelki szemeim előtt az új regényében, amiben két múmia egymásba szeret, és kéz a kézben kacarászva sétálnak egy függőhíd alatt:

"- ,Ha-,ha-,ha. - nevetett fel a halott nő.
- Igen, ,ha-,ha-,ha. - válaszolta a másik hulla lágyan, ahogyan egy gyolcsdarabka a nemlétező gigájára tekeredett. S mélyen belenézett a másik szemgödrébe - A ,halálig szeretlek..."

Szóval, ne téveszd meg, jobb, ha inkább elhagyja.

Peri .... a következő mi lesz? HaskeII ?

Tekintettel arra hogy Carnivore diétát követek, amivel sikeresen le is fogytam, így - ezt a tényt figyelembe véve - szerintem következő programnyelvemhez sokkal inkább illene az a név, hogy:

HasNEMkell

Hiszen aki diétázik, az meg akar szabadulni a (nagy) hasától...

Bár még nincs teljesen kész az infixnotation modul a Peri nyelvhez, de előrehaladtam már benne annyira hogy el tudtam készíteni a Pí számító tesztemet ezzel a szintaxissal is. Az lett amire számítottam is: Az infix notationt alkalmazó jelölésrendszernek „hála” a számítás sebessége nagyjából húsz százalékot lassult...

Nem véletlenül ődzkodtam mindigis ettől a megoldástól.

Még tiszta szerencse (dehogy szerencse! Hála nekem, azaz Magasztaltassék a Programozó, s az Ő Alkotása!) így már egészen más a helyzet hogy nem kötelező használni e szintaxist, csak ezt is LEHET, annak aki olyan perverz hogy ehhez van kedve...

Az előző nyelveimnél vagy az volt hogy nem volt ilyen szintaxis és gyors volt, vagy ilyen infixesre csináltam meg, de akkor lassú volt. (szkriptnyelvhez képest akkor se volt lassú, csak nem olyan gyors mint lehetett volna...)

A Perinél ez nem így van. Simán lehet mindkettőt használni. Emiatt szeretem a Perit. Hozsánna néked, Peri, Powerful Lady!

Az interpretálással vesztesz egy pár nagyságrendet a fordításhoz képest (a pi teszted rendes infix operátorokkal _sokkal_ gyorsabb lenne Fortranban), de a kényelem oltárán ezt az áldozatot meghozod. Akkor már mi az a 20 százalék az olvashatóság érdekében. Szerintem simán megéri.

Végülis igazad van. Tulajdonképpen épp emiatt is álltam neki hogy megcsinálom az infix modult is beléje nekije, a Drágaszágnak... hozzáteszem azért, eredetileg nem akartam. De aztán rájöttem, miért is ne, hiszen a Peri legnagyobb előnye ÉPP AZ, hogy tulajdonképpen nem számít mennyire lassú (és még csak nem is lassú, simán ráver épp kb 20 százalékot a JIT nélküli Pythonra, néha sokkal többet is...), ugyanis direkt úgy van megírva hogy talán épp ez az a szkriptnyelv ami a legmesszebbmenőkig támogatja a bővíthetőséget külső C/C++ nyelven írt libekkel! Ez a peri egyik legislegnagyopbb előnye!

Vagyis ha valahol van egy „bottleneck” a sebességben, egy szűk keresztmetszet, azt egyszerűen meg kell írni C-ben, besúvasztani egy külső libbe, és kész, a többit lehet nyugodtan Periben írni tovább...

Akkor meg tényleg, lehet akár infix is. És különben se kötelező az infix jelölésrendszer, pláne hisz írtam, még vegyesen is használható...

A bosszúságom az, egy ilyen infixes modullal temérdek babramunka van. Gyakorlatilag külön meg kello írnom újra az egész nyelvet (legalábbis a 80 százalékát), külön kezelgetve az egyes típusok esetét (és a Peri egyelőre 13 típust támogat built-in...), szóval irtó pepecselős. Nem a kifejezéskiértékelés algoritmusának leprogramozása a nehéz, azt csak a pelenkás kezdők hiszik. Ott egyszerűen tisztában kell lenni vele mit jelent az a fogalom hogy „rekurzió”, aztán kész ennyi, programozástechnikailag nem egy nagy durranás. De minden operátort le kell programozni, minden típusra külön, plusz figelembe venni az egyes specialitásokat mint például amikor a változókat postfix operátorokkal módosítjuk hogy teszemazt

variable++

és hasonlók. Rém macerás na. Lassan megy, mert mindent alaposan át kell nézni, és rengeteg unit-tesztet írni.

Egyelőre a következő típusokkal vagyok meg:

unsigned long long

signed long long

double

De mondom, van még tíz... És a stringtípustól már előre rettegek mert az a legkomplexebb. Ja és ezen említett három sincs kész azért teljesen, mert az még egyikben sincs benne, mit kezd akkor ha egy stringkonstans jön közbe a kifejezéskiértékelés közepén nekije. Nem tudom ugyanis eldönteni, ilyenkor mit csináljon mondjuk az unsigned long long típus kiértékelője. A lehetséges megközelítések:

1. A stringkonstans pointere legyen a stringkonstans „értéke” ezesetben, egész számként. Ez logikusan illene is a nyelvem eddigi filozófiájához, mert sehol nincs nálam megkülönböztetve egymástól a pointer és az egész szám.

2. Próbálja castolni a stringkonstans tartalmát előjel nélküli egész számra. A maga módján ez is logikus, csak életszerűtlen - ki az a hülye aki egy egész számokkal műveletet végző kifejezésbe egy számot stringként ír bele?! Aztán meg mi van ha a stringkonstans nem értelmezhető egész számként - ekkor jelezzen hibát, vagy tekintse az értékét nullának, vagy...?

3. Semmit se csinál vele, úgy tekinti itt vége van az aritmetikai kifejezésnek, a stringkonstans már nem tartozik hozzá. Jelen pillanatban ez a szitu.

Hasonló problémákba ütközöm majd, előre látom, a stringkifejezések kiértékelőjénél. Mi van ha egy ilyen kiértékelő egy egész számba ütközik bele? Számkonstansba mondjuk? Tekintse úgy, hogy az már nem része a kifejezésnek? Vagy castolja stringgé? Ha igen, milyen hosszú stringláccá, és legyen-e benne előjel az elején? Stb.

Szóval a számomra RÉG nem az a gond, meg tudok-e írni egy programnyelvet, hanem döntenem kell a nyelv „milyenségéről”, ami a maga módján persze jó szórakozás, de ugyanakkor gyakran cseppet se egyértelmű, melyik döntéssel járok jobban. Mármint, melyik döntéssel lesz jobb a nyelv végül.

Nyilván nem nagy ügy megírni egy szkriptnyelvet úgy, hogy támogassa külső libek használatát. Semmi kételyem afelől sem, számos szkriptnyelv képes erre.

A Peri előnye abban van, hogy erre ő nemcsak képes, de a külső libekben megvalósított funkciókhoz tetszőleges kulcsszavakat hozzárendelhetünk (függetlenül e függvények azon nevétől melyek abban a libraryban vannak), és e kulcsszavak (mnemonikok) azután a Periben teljesen ugyanúgy használhatóak (olyan szintaktikai szabályok szerint például) mintha a Core részei volnának. Semmit se vesz belőle tehát észre a felhasználó/programozó, hogy e mnemonikok nem a nyelv „szerves” részei (a core-ben), hanem külső libben implementáltak.

Ez olyan mértékig így van, hogy a Core-ban alig is van valami. Már a print utasítás is - ami nélkül elég nehéz használni egy nyelvet, hiszen csak ki kell írjon néha valamit, eredményt mondjuk - is külső libben implementált, de még az olyan szokásos operátorok is mint:

= + - * /

stb.

a külső libekben megvalósított funkciókhoz tetszőleges kulcsszavakat hozzárendelhetünk

Ez nekem megint ilyen obfuscation-szagú dolog, amit már emlegettem egy másik posztban. Ez a feature a gyakorlatban mire jó? Én még azt is fenntartással kezelném, hogy osztályhoz/objektumhoz rendeljünk aliast, nemhogy függvényekhez. Lehet, hogy valami hasznos mellékhatásra most nem gondoltam, de ebből borzalmas keveredés lesz, ha mondjuk többen dolgoznak a kódon. 

szerk: egyetlen dolog jut eszembe, hogy teszt/éles build között le tudod cserélni a library-t egy IFDEF-jellegű elágazással, de még akkor sem függvényszinten oldanám ezt meg, hanem az egész library-t cserélném ki alatta. 

Semmit se vesz belőle tehát észre a felhasználó/programozó, hogy e mnemonikok nem a nyelv „szerves” részei (a core-ben), hanem külső libben implementáltak.

Ez szinte az összes általam ismert nyelvben így van. Olyannyira, hogy egy projektben két évig használtam párhuzamosítással kapcsolatos feature-t, és csak egy hobbifeladatnál esett le nekem, hogy az nem a nyelv része, hanem a projektünk egy library-jéből jön. De ez szerintem inkább hátrány, mint előny. 

Fogd fel úgy, hogy a Peri nem is "igazi" programnyelv, hanem egy keretrendszer, ami lehetőséget nyújt rá hogy (külső libraryk által) könnyen definiálj/írj egy programnyelvet, akkor is ha nem akarsz sokat szöszmögni azzal hogy magad írd meg a preprocesszort/tokenizálót/whatever. És azt hogy e keretrendszer erre tényleg képes, azzal bizonyítottam be, hogy rögtön írtam is „benne” egy nyelvet. De mert a definiált nyelv (néhány nagyon alapdologtól eltekintve) nem része a keretrendszernek, így annak természetesen (majdnem) bármely eleme kicserélhető, nyilvánvalóan a megfelelő lib kicserélésével, vagy legalábbis annak valamelyik függvényét kell átírni. Nem kell azonban belenyúlni hozzá magába a keretrendszerbe.

Szerkesztve: 2020. 12. 06., v - 08:25

--

El ne siessem a vélekedést (ha babonás lennék, lekopognám, de nem tehetem mert nem vagyok babonás...) ám úgy néz ki, kész vagyok az infix notation összes kifejezéskiértékelőjével, minden típusra, a stringeket kivéve! Ez „jó mulatság s férfimunka volt” a mai napra.

Szerkesztve: 2020. 12. 07., h - 05:04

Na, csak megcsináltam ma a strintípusra is a kiértékelőt... Bár természetesen lehet hogy bővül majd még ezzel-azzal, de legalább az értékadás megvan, és lehet stringeket összeadni is. Ritkán van más egy stringkifejezésben, mint összeadás, azaz konkatenálás. Ezzel szemben az én kiértékelőm stringet szorozni is tud számmal, ami természetesen multiplikációt jelent, és ki is tud belőle vonni számot, ami azt jelenti hogy ennyivel csökkenti a hosszát, lehagyva valahány karaktert jobb oldalról.

Íme egy kis példaprogram (semmi értelmeset nem művel de unit tesztnek jó):

 

###sysinclude standard.uh
###sysinclude infix.uh
#s
100 mem sto ss
100 mem sto mystr
mystr === "abcdef" @mystr printnl
ss    === "12345"  @ss    printnl
mystr += "CENTRE" + @ss @mystr printnl
mystr -= 4 + 2 @mystr printnl
mystr += ( ss * 2 ) + "*" @mystr printnl
mystr *= 3 @mystr printnl

@mystr inv mem
@ss    inv mem
end
{ „mystr” }
{ „ss” }

Outputja:

abcdef
12345
abcdefCENTRE12345
abcdefCENTR
abcdefCENTR1234512345*
abcdefCENTR1234512345*abcdefCENTR1234512345*abcdefCENTR1234512345*

Látható, még a zárójeleket is tudja kezelni a kifejezésen belül. (Naná! Rekurzió rulez!)

Egyedül a === operátor szorul magyarázatra. Nos ez a közönséges = operátornak felel meg, AKKOR, ha infix módon van értelmezve. Hm, ez így lehet hogy zavarosan hangzik... Szóval, attól hogy az infix.uh fájlt beinclude-oljuk, még SEHOL SEM változik meg a Peri szokásos szintaktikája! Ami ugye RPN típusú. Egyszerűen a periben általában nincs használva a +=, -=, *=, /= és más hasonló operátorok, mert minek, RPN nyelvben tulajdonképpen nincs olyan hogy „balérték”. Jó, rá lehet fogni nyakatekerten erre-arra, de tulajdonképpen minden a stackon keresztül értelmeződik.

E += stb mnemonikokat tehát nyugodtan felruházhattam infix jelentéssel. Ha az infix.uh fájl be lett includeolva, akkor e mnemonikokat infix operátoroknak tekinti a nyelvem, s ettől kezdve mindaddig amíg az utána következő mnemonikokat értelmezni tudja az infix notation szabályai szerint, azokat annak megfelelően is kezeli.

Az = jelnél azonban bajba kerültem, mert azt az RPN szintaxisban is használom. És nem akartam lemondani arról, hogy a két fajta notationt vegyesen is lehessen használni. Így egyszerűen kitaláltam az === mnemonikot, ami nem más mint egy "infix =" operátor. Mint látható a fenti példaprogramból, ez az egyetlen extravagáns jelölés tulajdonképpen az infix notation esetén, minden más teljesen megszokott.

Az is látható amúgy, nem szükséges kitenni a kifejezések végére a pontosvesszőt (vagy bármi annak megfelelő jelet). A Peri okos, tudja hol van vége egy kifejezésnek: természetesen mindig ott, ahol már valami olyasmi jön ami nem tartozik a kifejezéshez, azért, mert nem értelmezhető a kifejezés addig végrehajtott részével kontextusban. De ettől még amúgy létezik a nyelvemben a pontosvessző, aki akarja kiteheti bárhova, semmi gond: ekkor üres utasításként funkcionál. Szóval aki akarja, javíthatja vele a kód olvashatóságát, csak nincs megkövetelve a használata.

Szerintem így már kezd egész olvasható lenni a Peri. De ha valakinek más erről a véleménye, csak szóljon nyugodtan! (úgyis eleresztem a fülem mellett... virtuális vállveregetésre, „buksisimogatásra” vágyom hogy itt valamelyik troll korábbi szavait idézzem, nem kritikára. Minek is, a kritikáknak úgysincs sok értelme ha felém fogalmazzák meg...)

Jópofa amúgy egy effélét leprogramozni. Az elemi (skalár) típusokkal nem volt semmi baj, azok mind beférnek egy 8 bájt hosszú unionba. A string azonban nálam értelemszerűen egy "rather complex" objektum. Van leírórésze meg a satöbbi és a minden. Ő nem fér be 8 bájtba, csak a pointere. Azaz, egy ilyen stringkifejezés-kiértékelő leprogramozása közben nem csak arra kell figyelni hogy a kiértékelő önmagát rekurzívan hívogatja (legalábbis megteheti, alkalomadtán) hanem mert stingről azaz bonyolult objektumról van szó, okvetlenül meg kell hívni közben mindenféle konstruktorokat, destruktorokat, másolókonstruktorokat stb, már ha megengeditek hogy e függvényeket így nevezzem, a C++ nyelv nomenklatúrája szerint, még akkor is ha én sima C nyelven programoztam le a Perit. Mégis, egy ilyen bonyolult objektumnál ezt az egész mindenséget „emulálnom” kellett.

Ha valaha még visszatérnék a C++ programozásához, tuti hogy annak a logikáját is jobban ismerném/érteném ezek után.

Én még a sztringek hatványozását is mindenképpen belefejleszteném. Hiánypótló lenne. Hány, de hány alkalommal volt már rá szükség, pl. amikor le kellett írni 100,000,000-szor, hogy "Hülyegyerekekkel nem foglalkozom":

mystr === "Hülyegyerekekkel nem foglalkozom" @mystr printnl
mystr *= 100 @mystr printnl
mystr ^= 4 @mystr printnl

Örömmel közölhetem veled, hogy a *= metódus már réges-rég értelmezve van a nyelvemben stringekre! Azaz íme az általad felvetett probléma megoldása korrektül (a te kódod ugyanis több szempontból is hibás, sajnos... de értékelem az igyekezetedet):

###sysinclude standard.uh
###sysinclude infix.uh
#s
"Hülyegyerekekkel nem foglalkozom\n" sto hülye
hülye *= 100
@hülye sprintnl
end
{ „hülye” }

A fenti kód százszor írja ki egymás alá az említett szöveget. Mindazonáltal ez mégis egyetlen string, mert mint látod az első string végén ott az újsor escape szekvenciája.

És amint látod, direkt a kedvedért a string szorzása a 100 numerikus értékkel az infix notation szerint lett a kódba téve, hogy áttekinthetőbb legyen neked, meg azoknak akik idegenkednek az RPN szintaxistól. (De azzal is simán meg lehetne oldani).

Szóval ne csüggedj, öregfiú! Jó ez a nyelv!

Note: a fenti kódban az sprintnl helyett írhattam volna szimplán printnl kulcsszót is, mert a #s runtime típusdeklaráció és a printnl kulcsszó közt a globális TYPE flag értéke nem lett egyszer se átállítva. Mindazonáltal a kód így olvashatóbb, és különben is mindegy mert nem változott volna meg a futás sebessége tőle.

Nem is olyan rossz dolog, hogy úgy döntöttem, nem publikálom a nyelvet amíg kész nincs a doksi fordítása...

Mert ezzel is láthatóan úgy vagyok mint a regényeimmel: mikor már azt mondom: "kész", egy idő után kiderül hogy még ezt-azt beleírhatok.

Most itt a programnyelvemnél például, nem hazudtam, tényleg kész van, nem kezdtem újra... de ettől még KIEGÉSZÍTETTEM egy remek feature-vel, ami NEM töri meg a kompatibilitást. Egyszerűen arról van szó, hogy alapesetben amikor indexelek egy stringet (vagy akármit...) akkor a nyelvem nem végez indexhatárellenőrzést. Az lassítaná a futást ugye, és a legtöbbször felesleges is. Különben is itt a „filozófia” az, hogy vigyázzon a programozó, a programnyelv (interpreter) dolga a progi minél gyorsabb lefuttatása és nem az okoskodás.

Igenám, de aztán eszembe jutott valami. Néha az index ellenőrzése mégiscsak szükséges, és bár ez eddig is megoldható volt a nyelvemben, de ha az eddig rendelkezésre álló eszközökkel végzem, az lassú. Mármint a natív kódhoz képest lassú...

Szóval belevettem a safe kulcsszót. Minden utasítást ami indexeléssel kapcsolatos (vagy legalábbis majdnem mindet) ki lehet bővíteni ezzel. Ekkor ellenőrzi az indexhatárt... De, és itt jön a nagy poén, ekkor nem az történik hogy túllépésnél abortál, hanem inkább olyasmi történik ami a „kivételdobás”-nak felel meg leginkább, ha hasonlatot keresek rá!

Tehát:

mystring[@myindex]

a string megfelelő elemét a stack tetejére helyezi. Nem vizsgálja, a myindex értéke túllépi-e a string aktuális hosszát.

safe mystring[@myindex] §safelabel

Ez ugyanúgy a stack tetejére helyezi a string megfelelő elemét, DE előtte megvizsgálja az indexet. Ha úgy találja az index értéke invalid, akkor mégse helyez a stack tetejére semmit, hanem elugrik a §safelabel címkére.

Azaz erre a helyre ami így van megjelölve:

safelabel:

Természetesen a címke neve nem muszáj hogy safelabel legyen, lehet akármi. A paragrafusjel szerepe csak annyi hogy a Peri nyelvben minden címke amikor nem megjelöl egy helyet hanem hivatkozunk rá, e prefixummal kell bevezettessék.

Rengeteg helyen használható a safe kulcsszó a nyelvemben, de nem untatlak benneteket a többi lehetőség ismertetésével. Csak azt akartam leírni, hogy szóval VAN lehetőség a biztonságos programozásra (is) a nyelvemben immár! És ez a safe megoldás messze gyorsabb mint ha a Peri alapeszközeivel vizsgálgatnánk az ilyesmit, hiszen natív sebességgel fut az indexellenőrzés, a kód is áttekinthetőbb... Szóval mélységesen és szupermagasan elégedett vagyok most magammal!

Komolyan, lehet hogy 2020 a Covid miatt sokaknak egy szörnyű év volt, de számomra a legpompásabb sikerévek egyike, rengeteg szempontból!

Mintha ez a cucc két dolgot csinálna kombinálva: egyrészt, a [ ] operátorban bekapcsolja a túlindexelés-ellenőrzést (amúgy nem emlékszem, hogy indexelsz, fixen 1-től (Fortran), 0-tól (C), vagy megadható (Algol)), és elvégez egy kivételkezelést, mintha C++-ban csinálnál egy array class-t

template<typename T> struct array{
  T* data;
  size_t n;
...
  T& operator[](size_t k, bool safe=false){
    if(safe && k > n-1 ) throw(...);
    return data[n];
  }
..
}
  

és ezen kívül kezelnéd a főprogramban a kivételt,

array<char> anArray(127);

try{
  ... anArray[m] ...;
} catch(...) goto safelabel;
...

A kérdésem csak az, hogy nem érdemes-e a két funkciót különválasztani? Kivételkezelésre máskor is szükség lehet (pl. file-műveleteknél, memóriafoglalásnál).

Az indexek nálam is nullától számítódnak.

Na most a "kivételkezelés" szót hasonlatként alkalmaztam az előbb. Nincs itt afféle globális kivételkezelő mechanizmus mint a C++ esetén, amit amúgy nem is igazán komálok. Technikailag ez úgy működik, hogy amikor a forráskód tokenizálása történik, akkor a progi felderíti, mely utasítások előtt szerepel a safe kulcsszó, s azon utasításoknál beállít egy speciális flaget. E flag létét aztán az utasítás detektálja amikor végrehajtás adódik rá, s ettől kezdve kicsit másképp működik mint tenné amúgy: azaz, mielőtt megcsinálná ami amúgy is a dolga lenne, előbb ellenőrzi azt, valid-e az index értéke. Ha nem, elugrik a megfelelő címkére.

De még ez az elugrás se mondható olyasminek hogy ez igazi „kivétel” volna: ez teljesen normális viselkedés (legalábbis én annak tartom). Mert miért is induljunk ki abból, hogy indexhatárátlépés csak valami tévedés vagy hiba következtében történhetett? Simán lehet például olyasmi is, hogy van egy ciklus aminél azonban nem lehet tudni előre, meddig fog lefutni, ugyanakkor mégis minden iterációnál növelni kell egy számlálót, mely számlálóval aztán indexelünk valamit.

Szóval formailag nézve ez hasonló a kivételkezeléshez (legalábbis nekem úgy tűnik) de tulajdonképpen nem az. Csak távoli analógiaként használtam ezt a szót rá.

Egyszerűen úgy találtam, az indexhatárellenőrzés majdnem mindig felesleges, s mert amúgyis sebességmániás vagyok, úgy csináltam meg a nyelvet hogy alapból ne végezzen ilyesmit. De mert számot kellett vessek azzal hogy néha mégis szükséges az indexhatárellenőrzés, ki kellett találnom valamit rá ami opcionális, mert bár ez korábban is megoldható volt, de az eddigi példaprogramjaim alapján az is nyilvánvalóvá vált, hogy a „szokásos” módszerek a kód áttekinthetőségét rontják, továbbá, a sebességük is olyan teknősbékaszerű ahhoz képest mintha natív sebességen történnének.

Volt olyan korábbi nyelvem amúgy, amiben valóban létezett igazi kivételkezelés, ott se pont olyan mint a C++ esetén szintaktikailag, de technikailag tényleg hasonlított ahhoz. Még saját kivételeket is lehetett „dobni” a programban. De minél többet törtem a fejemet rajta, annál inkább oda lyukadtam ki, hogy igazából semmi normális dologra nem lehet használni egy effélét. Zavarossá teszi még a kódot is. Többnyre úgyis az van hogy a kivételkezelő függvény azzal kell kezdje, ellenőrzi a kivételt hogy most miért is került ide a vezérlés. Szóval az ellenőrzés nem megspórolható. Hacsak nem készítünk külön kivételkezelőt minden egyes helyhez ahol kivétel adódhat, na de ha azt tesszük akkor lényegében ugyanott vagyunk mint most ahogy megcsináltam: minden ilyen „kivételnek” van egy saját címkéje amire ugorhat!

Annak sincs akadálya a Periben hogy ez a címke mindenütt ugyanaz legyen, amennyiben egyes „kivételeket” ugyanúgy akarunk lekezelni, például csak kiírni egy hibaüzenetet aztán abortálni.

Nem zárom ki amúgy, hogy van előnye a C++ kivételkezelésének is ezzel a módszerrel szemben, de az az előny igen ritkán érvényesülhet mert olvastam már róla hogy nem sokan használják és szeretik e kivételkezelést ott, sőt van arról is vita a modernebb nyelvekben hogy legyen-e egyáltalán kivételkezelés azokban, mert súlyosan elbonyolít mindent. Az biztos ha a C++ kivételkezelése tényleg olyan tuti volna, erről nem lehetne vita mert mindenhová azt építenék be vagy valami ahhoz nagyon hasonlót.

Ezt a Periben egyszerű volt megcsinálnom, s ennek örülök, mert igyekszem a kód komplexitását csökkenteni ahol csak lehet, a későbbi bővíthetőség illetve karbantarthatóság meg áttekinthetőség érdekében.

Nagyon sok programnyelvben van kivételkezelés (C++, C#, Lisp, Ada, Java, PL/I, ...), és ahol nincs, ott is lehet utánozni, pl. úgy, hogy

  memóriafoglalás
  ha nem sikerült, goto 100
  ...
  file megnyitás
  ha nem sikerült, goto 110
  ...
  file beolvasása, értelmezése
  ha nem sikerült, goto 120
  ...



...
120 file bezárása
110 memóriafelszabaditás
100 ha volt hiba, abort
  return
  end

Szerintem elég hasznos dolog (bár van róla vita), sok olyan lépés van, ahol lehet hiba (felhasználó rosszul ad be valamit, betelik a memória, a file-rendszer, ...). Az, hogy kifejezetten hiba kezelésére való, vagy a normális működés részeként is javasolt használni a programozási nyelvtől függ (c++-ban tényleg nem szokás a normális működés részeként használni). A kivételkezelést utánzó kód szerintem nehezebben olvasható, mint a kivételkezeléssel, és ha ragaszkodsz hozzá, hogy goto nélkül írd meg, még hosszabb lesz.

A Peri olyan nyelv, ahol a goto használata teljesen elfogadott. Mármint, szándékaim szerint... Én eleve hajlandó se lennék megtanulni olyan programnyelvet, amiből direkt kihagyták a goto-t. Tudom, manapság nagy divat a goto démonizálása. És magam is elismerem, csúnyán vissza lehet vele élni. Ez azonban nem indok arra, hogy eleve kihagyjuk mint lehetőséget. A villával is vissza lehet élni, mert bizonyára előfordult már hogy villával szúrtak szíven valakit, de ez nem indok a villák betiltására.

Az egyik legelső vezérlési szerkezet amit a Periben megvalósítottam, a goto volt. Mert nekem elvem hogy adjunk meg minden lehetőséget a programozónak, bízzunk benne... mármint, a nyelv bízzon benne.

A második pedig amit megvalósítottam, a szubrutinhívás volt. A "gosub", bár a Periben nem így nevezik hanem ez a mnemonikja: sbr

(ez rövidebb, és ismerős is nekem a Ti-58 korszakából. Kis nosztalgia ugye).

Máig nem értem, miért nincs valami hasonló a C nyelvben, ezt mindigis ótvar nagy hiányosságnak tartottam. Rém nehézkes, hogy minden függvény, és nincs lehetőség szubrutinhívásokra. (jó, tudom, valamiképp biztos össze lehetne hozni mindenféle furmányos kerülőutakon). A szubrutinnak épp az a nagy előnye hogy az egyes hívások során NEM különülnek el egymástól a változók, hanem ugyanazzal a változókészlettel dolgoznak a szubrutinjaink. Ez igenis előny rengetegszer.

Na most ha belegondolsz, a szubrutin se más mint egy goto, épp csak nelőtte elmenti a visszatérési címet valahová. (praktikusan valamelyik veremtárba). Tehát igazából ő is goto. A goto tehát nagyon hasznos.

Sőt ha tovább bogarásszuk a dolgot, végülis a C/C++ switch szerkezete ugyan mi más mint egy rakás goto, álcázva?

Ami példákat fentebb felsoroltál a kivételkezelésre, azokat a Periben is lehet természetesen, épp csak szerintem ez nem klasszikus értelemben vett kivételkezelés, hanem bizonyos visszatérési értékek ellenőrzése. Ilyen a C nyelvben is van.

A Perit amúgy sosem szántam „magas szintű” nyelvnek. Ezt teljesen őszintén bevallom és elismerem. Amikor készítettem, inkább olyasmi járt az eszemben hogy nekem egy olyan szkriptnyelv kéne ami valamiképp a FORTH és a C ötvözete. Igen, e kettő keveréke, de szkriptnyelvként. Nos, azt hiszem ezt sikerült elérnem.

Máig nem értem, miért nincs valami hasonló a C nyelvben

Imho (ha jól értem, amiről beszélsz - és ez most egy elég nagy "ha") azért, mert ennek csak káosz lenne a vége. Egy hello worldnél kicsit is bonyolultabb alkalmazás már rettenetes spagettikód lesz, ha egy kódblokk (nevezzük bárhogy) hozzáfér a call stack összes változójához, ne adj' Isten át is írhatná a tartalmukat. Eleve honnan tudod, hogy amikor a szubrutin lefut, akkor milyen változók léteznek a hívó függvényben? Mi van, ha több helyről hívod ugyanazt a szubrutint? Mi van, ha a szubrutint (vagy éppen azt, ami meghívja) nem is te írod?

Sőt ha tovább bogarásszuk a dolgot, végülis a C/C++ switch szerkezete ugyan mi más mint egy rakás goto, álcázva?

Hát azért van különbség, pl. hogy switch-csel nem tudod elhagyni a scope-ot, mert nem lehet vele ilyen arbitrary (mi erre a magyar szó?) ugrásokat csinálni hasraütésre.

Attól még a switch ágak végén a break semmi más mint egy-egy goto, technikailag. És ezt amiatt hangsúlyozom, mert ez arra bizonyíték hogy a goto - helyesen használva - igenis lehet hasznos, sőt, elkerülhetetlen is!

Ami meg a szubrutinokat illeti, bevallom őszintén nem egészen fogom fel miről beszélsz. Lehet hogy te nem vagy biztos abban, én mit írtam fentebb, de én meg abban nem, te miről beszélsz. Úgy értem, felfogtam a szavaid jelentését, de azt nem értem, ezek miért lennének ellenérvek a szubrutin ellen. Gondolj csak bele a Basic nyelv(ek)be. Egészen biztos te is ismered valamelyik Basic nyelvjárást, ha máshonnan nem hát gyerekkorodból. Ott van szubrutinhívás. Vagy legalábbis én még nem találkoztam olyan Basiccel amiben ne lenne. Na most, van ebből bármi gond is? NINCS. Oké, nyilván lehet írni HIBÁS KÓDOT, ahol a hiba természete olyan hogy valamiképp kötődik a szubrutinhíváshoz. De hibás kódot minden nyelvben lehet írni, és minden feature alkalmas hiba elkövetésére, kellő találékonyság esetén. És némelyik user rém találékony ha arról van szó miként követhet el hülyeséget... ez amúgy rám is igaz, teljesen őszintén bevallom, én magam is a nyelvemet a készítésével párhuzamosan tanultam, s jópárszor megesett hogy elszántan kerestem a bugot a C kódban, végül kiderült hogy nem volt abban hiba egy szál se csak a Peri kódot írtam le hibásan. És az interpreterem nem is jelzett hibát, mert szintaktikailag helyes volt, csak épp nem azt csinálta amit akartam. Mert az interpreter az utasításainkat, és nem a vágyainkat hajtja végre...

Amennyiben az a cél, hogy a meghívott alprogram ne férjen hozzá a hívó program változóihoz, akkor tényleg nem jó ötlet hogy ez az alprogram szubrutin legyen. Ekkor függvényhívást kell eszközölni. Természetesen VAN lehetőség függvényhívásra a Peri nyelvben is, naná, még szép hogy van!

Én csak azt állítom, AKADNAK esetek, amikor ez az eset nem áll fenn, amikor épp az a jó ha hozzáfér a hízott alprogram a hívó változóihoz. Ekkor a szubrutinhívás megfelelő eszköz lehet.

Ilyen eset lehet például, ha nagyon sok paramétert kéne átadni a hívottnak. Ennek jelentős időszükséglete lehet, vagy ha egyetlen pointerrel akarjuk elintézni, akkor bonyolultan szervezett struktúrákat kéne kialakítani a cél érdekében, és nem mindig érdemes atombombávcal lőni verébre.

Olyasmi is lehetséges, hogy bár a szubrutint sok helyről hívjuk, de valójában csak alig néhány sorból áll, így nem tűnik ésszerűnek hogy emiatt egy külön függvénybe helyezzük. Szóval, ha a szubrutin pici, és csak egy-két változót használ, ugyanakkor ha pici is de nem jó ötlet külön beleírni a kódba minden helyre ahol szükség van rá mert az mégis jelentős kódduplikációt okozna, és rontaná úgy az áttekinthetőséget mind a kód későbbi karbantartását mert a módosításokat minden helyen meg kéne csinálni ezesetben. Ilyenkor - véleményem szerint - a szubrutin a jó döntés.

Kiemelném még, ettől még a Peri nem primitív nyelv! Illetve ha az is, de nem emiatt. Van olyan tulajdonsága például, amiben szerintem veri nemcsak a C de a C++ nyelvet is: A Periben például a függvények matrjoskaszerűen egymásba ágyazhatóak! Azaz lehet a főprogramban mondjuk egy A meg egy B meg egy C függvény, s ezen függvények mindegyikében lehetnek más, újabb függvények, akár ugyanilyen néven is, mert ugye minden függvény egy külön névtér... szóval, itt a névterek egymásbaskatulyázhatóak.

És egyik névtérből nem lehet hozzáférni a másik névtérben található dolgokhoz. (Kivéve természetesen ha egy pointert adunk át az adott függvényre vagy akármire, paraméterátadásnál, de az már teljesen más kérdés, hiszen az szándékosan történik).

Ennek lehetőségét nagyon hiányoltam a C nyelvben, ahol minden függvény egyenrangú.

Amennyiben minden eddigi érvem ellenére is rossz ötletnek tartod hogy van a Periben szubrutinra lehetőség, akkor cserébe azzal vigasztalhatlak, hogy de legalább NINCS a Periben olyasmi, hogy „globális változó”! Ennek még a fogalmát se ismeri a Peri, technikailag is lehetetlen megoldani. Illetve ha nagyon precíz akarok lenni, akkor van 2 globális változó, az ARGV és az ARGC, de ezek is csak olvashatóak. Mármint, ha lekérdezzük őket, a másolatuk kerül be a függvény veremtárjába. Az argv valahányadik eleme esetén nem a pointer, hanem a string maga másolódik, teljesen. Azaz nem lehet felülírni e „globális változókat”.

És azt tudod ugye, a globális változók használata mennyi gondot okoz néha. Na a Perinél nem, mert ott ilyesmi egyszerűen nem létezik.

Azért elég kevés olyan nyelvet láttam eddig, amiben a szubrutinhívás úgy működik, mint amit leírsz; talán csak a BASIC (és már ott is nagy hibának tartottam). Fortranban is van  függvény és szubrutin, de csak annyiban különböznek, hogy a szubrutinnak nincs visszatérési értéke. Változót átadni az argumentumlistájukkal tudsz, ugyanúgy mint a C-ben, annyi eltéréssel, hogy név szerint adod át (a függvény/szubrutin módosíthatja mellékhatásként), és már ez is okozhat nehezen debugolható hibákat, pl. az aliasing

c x-et kiírja, y-ba beírja sin(x)-et
      subroutine foo(x, y)
        y=sin(x)
        write (*,*) x
      end

c foo dokumentációja alapján arra számítasz, hogy először
c 0.7 jelenik meg, majd sin(0.7), de meglepetés ér
      program alias
        x = 0.7
        call foo(x,x)
        write (*,*) x
      end

a kimenet:

./alias 
  0.644217670    
  0.644217670

Lehet, hogy bizonyos esetekben a gosub-szerű hívással kevesebb gépeléssel megírsz valamit, de egy bonyolult programnál könnyebb hibázni. Az lehet, hogy neked mindegy (nem írsz nagy programokat, vagy nem bánod a hibakeresést, mert nem határidőre dolgozol, vagy minden programot előre megtervezel papíron, fejben végrehajtod lépésről lépésre egyszer, vagy csak baromira koncentrálsz a programírásra), de a gyakorlat azt mutatja, hogy a többségnek jó, ha a compiler/interpreter segít.

A nested function kérdésköre: Fortran-ban Fortran 90 óta van (de csak egy szint, a belső függvényben már nem lehet még egy), C++-ban lambdákkal megoldható (és akkor még gosub-szerű szubrutinhívás is megoldható, egy [&] lambdával).

Hogy mi az a lambda, bevallom fogalmam sincs róla. Hallottam már róla, hogy van valami ilyen izé, egyszer megpróbáltam utánanézni de ami leírást találtam róla az olyan extramagas mértékben elvont izémizé volt hogy hamar elment a kedvem tőle hogy kibogarásszam, s úgy döntöttem nagy eséllyel olyasmi ami nekem nem kell, mert minek kéne, a funkcionális nyelveket is annyit dicsérik de én azok nélkül is oly prímán elvagyok... Bevallom, nem szeretem a túlzottan elvont dolgokat.

Ami a Perit illeti, a "nested function" ahogy te nevezted, e nyelvben akárhány mélységben is lehetséges. Őszintén, én most a kommentedet olvasva rémségesen ledöbbentem - nem azon, hogy a Fortranban végül mégiscsak van ilyen, hanem azon hogy ha már beletették, miért ilyen szarul, hogy csak 1 szint mélységig? Végülis mi AKADÁLYA lett volna megcsinálni úgy mint a Periben, hogy akárhány mélységbe is lehetséges legyen, hiszen még csak nem is nehéz, más se kell hozzá mint hogy a tokenizáló vagy mindegy minek nevezzem, szóval ami előállítja a kódot, képes legyen rekurzívan meghívni önmagát?! (Legalábbis a Periben ez így van. Jó, van néhány trükk még benne, de igazán semmi szörnyen bonyolult).

Visszatérve azonban a szubrutinhívásra, én attól félek te meg én elbeszélünk egymás mellett. Te azt hajtogatod, a szubrutin milyen szörnyen veszélyes lehet ezért meg azért. Elkerüli a figyelmedet az, hogy én ezt ELISMEREM!

Épp csak azt nem értem, hogy ha ugyanakkor te meg azt ismered el, hogy azért alkalmanként tényleg lehet jó is egy szubrutin erre-arra, még ha csak kisebb programok esetén is, akkor miért baj az hogy erre van lehetőség?

Mert az én kiindulópontom - világnézetem ha úgy tetszik - NEM az, hogy most majd akkor a Periben épp a szubrutinokat használjuk orrba-szájba és únos-untalan, hanem csak az, hogy erre legyen lehetőség, amivel azonban NEM MUSZÁJ ÉLNI.

Én úgy érzem, a kritikád akkor volna jogos, ha „alprogramok” hívására a Periben a szubrutin volna az EGYETLEN lehetőség. Akkor igen, akkor megállná a kritikád a helyét, ez nem is vitás! De mert van más lehetőség is rá - a függvényhívás - emiatt egyszerűen nem értem, miért baj az ha ott van még a szubrutin is, alternatív lehetőségként, annak aki igényli, vagy mondjuk hogy a speciális esetekre!

Tehát úgy a maga teljes általánosságában: Miért baj az, ha létezik valami olyan feature amit nem is muszáj használni?

Még a kódbázist se növeli meg kicsit is érdemleges mértékben, mert a szintaxisa:

sbr §label

Na most labelek (címkék) úgyis vannak a nyelvben rengeteg más ok miatt, ami pedig az sbr mnemonik által hívott kódot illeti, az kevesebb mint egy fél képernyősor, annyira rövid, alig áll másból mint hogy meghívjon egy C nyelvű függvényt, mely függvény azonban mindenféleképp kell nekem a Peri kódbázisába amúgyis, szóval itt talán ha húsz-harminc bájtot spórolhatnék csak meg talán ha e lehetőséget kiirtom a Periből.

Akkor pedig miért baj hogy benne van?

Nem kritizáltam a szubrutinhívást, csak a terminológiát; amit te szubrutinhívásnak nevezel az a BASIC gosubja, de pl. a Fortran call-ja nem ilyen. Az, amit te csinálsz, emulálható, a goto-val

      ...
      x=12.07
      assign 1 to k
      goto 1200
1     continue
...
...
c program vége
      goto 1000
c HK-típ. szubrutinok
...
c példa szubrutin, kiír
1200  write (*,"(F14.5)") x
      goto k
c szubrutin vége
...
1000  continue
      end

A BASIC gosub-jához hasonlóan nincsenek a szubrutinnak argumentumai, hanem a főprogram (vagy beágyazó Fortran szubrutin, függvény) változóit használja. A különbség csak annyi, hogy az assign-nal bele kell tenni egy változóba a labelt, ahova vissza menjen (a BASIC gosub-ja ezt megcsinálja neked automatikusan). A C-ben szabvány szerint nincs ilyen goto, de kiterjesztésként implementálható egy compilerben (pl. gcc-ben le lehet kérni egy label címét az && operátorral, és a goto-nak lehet egy címet (void* pointert) adni, ahova ugorjon.

Hogy miért nincs a Fortranban többszinten embedded function? Nem tudom, de még soha nem volt rá szükségem.

A lambda pedig nem olyan bonyolult dolog, csak az elnevezés vacak (történeti okai vannak), egyszerűen még egy fajta függvény. Amikor létrehozod:

auto myLambda = [](double x){return cos(x)*cosh(x);};

csak annyit mondasz, hogy legyen myLambda egy olyan függvény, ami azt csinálja, ami a {...} között van. A [] csak egy jelölés (ez volt még szabad), de lehet közé írni, pl. ha hozzá kell férni a főprogram változóihoz, de nem kell módosítani őket, akkor

auto myLambda2 = [k](double x){ return cos(k*x); }; // k a főprogramban van

ha módosítani akarod, akkor meg

auto myLambda3 = [&k](double x){ auto rv = cos(k*x); k=0.9*k; return rv;} // k a főprogramban van

a []-be azt is írhatod, hogy =, akkor a főprogram minden változóját megkapod másolatban (nem megy vissza a változás), vagy hogy &, akkor mindet módosíthatod is (referenciát kapsz). Csinálhatsz generic lambdákat is (ha meg kellene írnod pl. ugyanazt a cuccot double-re is és complex<double>-re, de csak egyszer akarod).

Nézd, én időtlen időkkel ezelőtt a programozást még a Ti-58 programozható zsebszámológépen kezdtem, általános iskolás koromban. Igen, én ilyen öreg vagyok... Ott is volt már szubrutinhívás. Nagyon hasonló ahhoz ami most a Periben van, sőt, talán mondhatom teljesen azonosnak is, legfeljebb a Peri-féle picit többet tud mert a szubrutin nemcsak címkével adható meg de indirekt módon is, stb... (Bár igazából a Ti-58 esetén is volt lehetőség indirekt szubrutinhívásra ha így belegondolok, bár e lehetőségét sosem használtam...) Épp emiatt sbr a neve mert ez volt a neve a Ti-58 gépen is. Tehát azon gép készítői szerint ez igenis szubrutin. Hasonlóképp amikor később Basicben programozgattam, ott is szubrutin volt ennek a vezérlési szerkezetnek a neve. Én ebben a „nevezéktanban” nőttem fel, tehát NEKEM emiatt __ez__ a szubrutin. Amint látható nemcsak nekem, hanem sokan másoknak is.

Én elhiszem neked hogy manapság már EGYES KÖRÖKBEN nem ezt nevezik szubrutinnak, sőt, magam is olvastam hogy NÉMELYEK szerint (de nem MINDENKI szerint!) az a „szubrutin” ha egy FÜGGVÉNY nem ad vissza értéket a hívónak. Ez a szememben egy rém logikátlan álláspont, mert ebből az következne hogy a szubrutin a függvények egy részhalmaza. De akkor mi annak a neve amit én nevezek szubrutinnak, meg a Ti-58 egykori készítői, stb?!

Az én definícióm szerint (amibe illeszkedik a Ti-58 -as, a Basic és a Peri szubrutinja is) vannak „alprogramok”. Az alprogramoknak 2 csoportja van:

1. Aminek van saját névtere. Ezeket függvényeknek nevezzük.

2. Aminek nincs saját névtere. Ezeket szubrutinoknak nevezzük.

Amennyiben a név a visszatérési értékek számától függne (nulla vagy annál több) abból az következne hogy ha megírok valamit, ami nem ad vissza semmit, így szubrutin a neve, majd később meggondolom magamat hogy mégis jó lenne visszaadnia legalább egy hibakódot hogy jól lefutott-e vagy sem, akkor pusztán ezen apró különbség miatt máris függvény lenne az egykori szubrutinból, holott igazából alig változott valamit. Elég logikátlan nézőpontnak tűnik a szememben.

Ezzel szemben az hogy van-e névtere vagy sem, teljesen egyértelmű és sokkal állandóbb tulajdonsága is.

Továbbá, igazán nem akarlak megsérteni vele de ahogy te emuláltad a szubrutint, az szerintem még csak nem is oké. Jó, lehet hogy tévedek, réges-rég volt hogy Fortranban programoztam, akkor is csak nagyon keveset... De nekem úgy tűnik, a visszatérési cím tárolására egy (globális) változót használ. Na és ez amiatt nem okéságos, mert így a szubrutin nem képes önmagát meghívni, rekurzívan...

A Peri szubrutinjai természetesen képesek erre. A régi Ti-58 szubrutinjai is képesek voltak erre, sőt a Basic szubrutinjai is. Ugyanis mindegyikre az a jellemző, hogy a visszatérési címet egy veremtárban tárolják. És amikor „visszatérnek”, mindig azon címre térnek vissza ami azon veremtár tetején csücsül. Ez a Periben így van, létezik ugyanis egy globális veremtár (nyilván nem vagyok olyan hülye hogy az oprendszer saját vermét barmoljam szét e célra...), ráadásul a Periben nem is egy hanem TÖBB verem is létezik, és ezen verem amiről most beszélek csak és kizárólag erre az egyetlen célra van fenntartva, a szubrutinok visszatérési értékének, és abszolút lehetetlen hozzáférni másképp mint a direkt e célra létrehozott speciális utasításokkal. Azaz például paraméterátadásra egészen más verem szolgál a nyelvben.

Más: Bevallom a lambdát még mindig nem igazán értem. Különben is, amit én olvastam (kezdtem olvasni...) róla, az valami rém elvont matematikai izé volt, „lambda kalkulus”, és nem látom mi köze lenne ehhez amit leírtál. Félreértés ne essék, azzal teljesen tisztában vagyok hogy ez nem a te hanem az én hibám. ITT most abszolút világos hogy én vagyok a hülye.

Esetleg ha egy sima C nyelvű példán be tudnád mutatni, mi ez az izé és milyen körülmények közt lehet hasznos?

Ami a PL/I nyelvet illeti, réges-rég amikor még ESZR gépes környezetben mozogtam, az volt a kedvenc nyelvem... De ma már alig emlékszem belőle valamire. Ami a C++ nyelvet illeti, az nem olyan rossz, a programnyelveimet eredetileg abban kezdtem fejleszteni, de aztán „lefokoztam” magamat a sima C nyelvre, mert a C++ túl lassú volt, meg mert sok esetben nagyon bekorlátozta a szabadságomat. Elismerem, akadnak előnyös oldalai is, amiket sajnáltam feladni, de úgy ítéltem meg, összességében jobban járok ha a sima C nyelvre váltok. Egyelőre úgy látom, jó döntést hoztam.

Akkor pedig miért baj hogy benne van?

Erre elfelejtettem reagálni, pedig akartam, de jobb is külön. Általában, ha van valami egy nyelvben, az nem baj, ha egyedül kódolsz (legfeljebb nem használod, ha neked nem kell), de csoportmunka esetén már baj, mert meg kell az egészet tanulni, mert lesz valaki a csapatban, aki használja.

A PL/I volt egy olyan nyelv, amibe igyekeztek mindent belelapátolni, ami volt a FORTRAN-ban, Algol-ban vagy a COBOL-ban, meg még ami közben eszükbe jutott, és nem lett népszerű. A C++ is olyan (eredetileg a C imperatív, azt kiegészítették objektum-orientálttá, de ügyesen használva funkcionális programozás is lehetséges benne), és népszerű lett. Talán a fő különbség az, hogy ma már hozzá vannak szokva az emberek a nagy és bonyolult (és lassú) fordítóprogramokhoz. Egy kisebb Fortran program (amiben a Fortran saját, elég jó, tömbkezelését használom) ma is sokkal gyorsabban lefordítható, mint ha ugyanazt megírom C++-ban (és a template-kkel megírt std::vector-t használom). Ennek ellenére, egy nagyobb programot inkább írok C++-ban.

El se tudom képzelni, hogy ennek a rém egyszerű valaminek, a szubrutinnak a megtanulása oly nehéz volna egy csoportmunka résztvevőinek, pláne hogy emlékeznek is rá biztos gyermekkori Basic kalandjaikból.

Ha azonban egy feature túl bonyolult vagy szükségtelennek látszik, csoportmunka esetén kell legyen valaki aki összehangolja a tevékenységet, a fejlesztést, s az akkor olyan policyt kell hozzon hogy azt a feature-t ebben a projectben nem szabad használni senkinek és kész.

Itt inkább az a baj, hogy ha a szubrutinnak valami változókat kell átadni, akkor azokat a neveket nem szabad a főprogramban másra használni. Főleg, ha a szubrutin még belül is csinál valami érdemlegeset, pl. egy olyan szubrutin, hogy

45 rem "szubrutin"
50 let pi = 0.0
55 let s = 1.0
60 for i = 0 to 1000
65 let pi = pi + s/(2.0*i+1.0)
70 let s = -s/3.0
75 next i
80 let pi = sqr(12.0)*pi
85 return

egész jól működik, ha a főprogram

10 rem "főprogram"
20 gosub 45
30 print pi
40 quit

de elég rosszul, ha az i változót valaki használja valamire, és ezt mind fejben kell tartani, hogy melyik szubrutin milyen változóneveket használ.

Na itt máris kiviláglik a Peri egyik roppant előnye: a felvetett probléma egyszerűen nem fordulhat elő, tekintettel arra a roppant jóságra, hogy a Periben a ciklusoknak saját külön automatikusan generált ciklusváltozójuk van, ami egyszerűen el se érhető a cikluson kívülről, semmiféle módon se! (Még csak nem is olvasható). Azaz, íme a te programod Peri megfelelője, megcsináltam a tisztletedre:

###sysinclude standard.uh
###sysinclude math.uh
#d
sbr §mypi
@mypi printnl
end
mypi:
zero#d mypi
one#d ss
1000 {{
@ss 2. {{}} #g !(#d) * 1. + / sum mypi
-3. inv prd ss
}}
12. sqr prd mypi
rts
{ „mypi” }
{ „ss” }

A fenti Peri kódban a ciklusváltozó értékét a {{}} szimbólummal kérdezzük le, azaz ez felel meg a te kódod "i" ciklusváltozójának, de ez csak és kizárólag a cikluson belül valid, ha e szimbólumot cikluson kívül alkalmazzuk, a kódunk le se fordul, hanem hibajelzést kapunk... Eképp elő se fordulhat hogy a ciklusváltozó miatt bajba kerülnénk a szubrutinban. A főprogram nyugodtan hívogathatja ha akarja a szubrutinunkat akár ciklusból is, ahol ő is használja a {{}} szimbólumot, semmi baj, mert olyankor e szimbólum a főprogram ciklusváltozójának értékét jelenti majd a főprogram számára...

Ez olyan, mintha a ciklusoknak a Peri nyelvben saját névterük lenne, ami azonban egyetlen változót tartalma, a ciklusváltozót. Pontosabban, mintha a ciklusokon belül az épp aktuális névtér mindig kibővülne az épp futó ciklus ciklusváltozójával. Természetesen ez a {{}} readonly a cikluson belül.

Minthogy a ciklusváltozó amikor lekérdezzük, mindig egy unsigned long long értéket ad vissza, ezt double értékké kell konvertálni, ezt végzi el az utánna álló #g !(#d) utasítássorozat. A #g azt mondja hogy a stack tetején álló érték most épp unsigned long long típusú, a (#d) azt hogy double-vá kell konvertálni, a felkiáltójel meg a zárójel előtt azért kell mert az azt mondja hogy a castolás után maradjon az interpreter ebben a „double” üzemmódban, azaz amíg mást nem mondunk neki minden műveletet double-ként hajtson végre.

Note: A math.uh fájl behúzása elhagyható lenne, ha a 12. lebegőpontos szám négyzetgyökét nem runtime számolnánk ki a

12. sqr

utasítással, hanem konstansként írnánk bele a kódba.

És nézd csak meg a Peri másik előnyét: amit te ilyen bonyolultan írtál:

70 let s = -s/3.0

Az a Periben ennyi:

-3. inv prd ss

Note2: Ettől még értem a problémádat. Ilyen komplexitású feladatot azért már én is inkább függvénybe szerveznék ki, nem szubrutinba, szóval béke van remélem! :)

Jellemzően én akkor használok szubrutinokat, ha azoknak nincs is semmi belső változóigényük, vagy maximum (mint ebben az esetben bemutattam) ciklusváltozóra van igényük, ez ugyanis mint látod a Peri sajátosságai miatt teljesen biztonságos mert úgyis minden ciklusnak külön ciklusváltozója van, fizikailag teljesen elszeparálva minden mástól. És el se érhetőek a cikluson kívülről, de még cikluson belül is csak olvashatóak.

Egymásba ágyazott ciklusokkal mit csinálsz? Pl. a trace AB kiszámítása, ami fortranban

c trace AB
      tr=0
      do i = 1,n
        do j = 1,n
          s = s+a(i,j)*b(j,i)
        end do
      end do

(Persze, kiszámolhatnám külön a szorzatmátrixot, vagy végigmehetnék k=1,n*n, és i=k/n, j=mod(k,n), de az azért lassabb is, meg nem is olyan olvasható.)

Amúgy az a sor szerintem csak azért olyan "bonyolult", mert a BASIC-ben a LET-tel oldották meg az egyenlő és a legyen egyenlő megkülönböztetését, hogy ne zavarják össze azokat, akik a számítástechnikát teljesen most kezdik, de matekot már tanultak, és abból, hogy A=A+2 arra következtetnének, hogy A=0. Ugyanaz Fortranban

      s=-s/3

(Vagy ugyanez lenne C-ben, a Fortran-t csak azért mondom, mert a BASIC-et szerintem az befolyásolta a leginkább.)

Nincs gond egymásba ágyazott ciklusok esetén se. Ekkor a külső ciklus(oka)t címkével kell ellátni a fejrésznél, s máris könnyedén hivatkozhatunk a változójára (persze továbbra is csak azon külső ciklus fizikai határain belül). Íme egy ezt demonstráló progi ami az első néhány számot szorozza össze szorzótáblaszerűen, szerintem könnyen megérted az eddigiek alapján a működését:

###sysinclude standard.uh
#g
4 külső: {{
3        {{
{{}}§külső print ." * " {{}} print ." = "
{{}}§külső {{}} * printnl
}} }}
end

Outputja:

0 * 0 = 0
0 * 1 = 0
0 * 2 = 0
1 * 0 = 0
1 * 1 = 1
1 * 2 = 2
2 * 0 = 0
2 * 1 = 2
2 * 2 = 4
3 * 0 = 0
3 * 1 = 3
3 * 2 = 6

Hiába röhögsz, én egyáltalán nem tartom nevetségesnek azt hogy a /* ... */ típusú megjegyzések egymásba ágyazhatóak. Cseppet se felesleges feature, igenis sok alkalommal jól jött volna már nekem a C nyelvben. De az nem tudta. A Peri tudja. És még csak nem is volt nehéz megcsinálni, nem növelte meg szignifikánsan a kódbázist.

Tökéletesen tisztában vagyok azzal, hogy sokan ilyen értelemben használják a "No comment" kifejezést.

A gond az hogy én nem vagyok hajlandó elfogadni ilyen értelemben, mert ÉRTELMETLEN. Tudniillik ELLENTMONDÁS.

Mert gondolj csak bele: a puszta tény hogy odaírta: "No comment" - az máris egy comment, nemdebár? Az ő kommentje az hogy "No comment". Odaírt valamit, tehát kommentelt. Na most van annak valami értelme, hogy azt kommenteli hogy nem kommentel, amikor pedig máris kommentelt?

Szóval ez így hülyeség a köbön.

Értettem én pontosan hogy erre gondolt, de én még közönséges trollkodásra se szívesen reagálok, arra azonban pláne nem ami ilyen káprázatos logikai baromságból áll (belső ellentmondásból). Így aztán inkább a beírt KOMMENTJE másik lehetséges értelmezését vettem alapul, ennyi az egész.

Kár hogy legalább te nem fedezted fel, mennyire ellentmondó hülyeség amit ő idepostolt. Na de mindegy, legalább ennyivel is szebben világlik ki az ÉN vesébelátó bölcsességem mely minden logikátlanságot sas-szeműen felfedez!

xD

 

Ez csak azt bizonyítja, hogy a többségi társadalom működését, szokásait te nem tudod felfogni, értelmezni, alkalmazni. Innentől csak magadból csinálsz hülyét. Ha egy ajtóra az van írva hogy "Pull" és "Closed", akkor mit csinálsz? Meddig húzod?

Hivatásos pitiáner
neut @

Nem vagyok hajlandó könyvet (vagy bármi mást) írni. A szócséplést rühellem.

Nálam az az alkotás, ha kitalálok valamit, megépítem, felprogramozom (ha azt éppen fel kell), és működik.

És nem nevezem ALKOTÁSnak, meg MŰVÉSZETnek. És egyáltalán: alkotás az, amit egy del paranccsal el lehet tüntetni? Az csak skicc.

Normális ember már nem kommentel sehol.

Erről amit most ideírtál, ez jut eszembe, biztos felismered:

„Én nem írok, nem olvasok, én magyar nemes vagyok!”

És nem nevezem ALKOTÁSnak, meg MŰVÉSZETnek. És egyáltalán: alkotás az, amit egy del paranccsal el lehet tüntetni?

Ez az érved szánalmas. Ezzel az erővel azt is kérdezhetem: Alkotás az amit egy robbanólövedékkel meg lehet semmisíteni?

Élet az, amit egy késsel ki lehet oltani?

Mondd, szerinted egy zenedarab eljátszása a zenekar által nem alkotás? Holott abban a pillanatban megsemmisül, hogy az utolsó akkordot messzire fújta a szél.

Egy festmény, az alkotás? Holott egyetlen gyufaszál elég a megsemmisítéséhez. Vagy csak dobd vízbe, máris vége.

Vedd észre, megint valami ELLEN harcolsz és nem valamiÉRT! El akarod érni hogy ne tartsam alkotásnak és művészetnek azt amit csinálok, és ellenpropagandát folytatsz, remélve hogy más is így érez majd. De miért az én alkotásaim ELLEN harcolsz, miért nem a tieidÉRT?

Még ha be is bizonyítanád hogy amit teszek nem alkotás és nem művészet, TE MAGAD akkor se lennél ettől még kiválóbb, nemesebb, műveltebb vagy tiszteltebb!

Kisbetu, kérlek, nagyon kérlek, nyíljék fel végre a szemed és ÖNMAGAD ÉRTÉKÉT NE MÁSOKBAN KERESD, pláne nem mások megalázásában, ne az ebben való igyekezetben! Ez még soha senkit nem tett naggyá, neked se fog sikerülni!

Mondd, miért nem a saját igazi értékeidet kutatod, miért nem próbálsz meg kisbetu helyett végre NAGYBETU lenni?

Nem annak szántam. Ha számodra vidámság kutyát enni, akkor tényleg nagy bajaid vannak. Tegyél rá egy lapáttal: te ne a füled, a fejed vágd le! Előre megígérem, hogy híres leszel. Talán még a Poloska nedv és a fantasztikus ízlelőbimbóim c. memoárodat is elolvassák vagy tízen.

Hé, hiszen ez még az előzőnél is jobb!!!

Tényleg meg fogom nézni (inkább hallgatni...) a többit is tőle.

A handpan amúgy egyik kedvenc hangszerem. Már egy ideje töröm a fejemet rajta hogy veszek magamnak egyet, a didgeridoo-m mellé, de rohadtul drága, aztán meg a handpanon nincs is rajta minden hang és nem tudom melyik hangolású lenne nekem a legmegfelelőbb.

Hanem figyelj csak, mi annak a ruhának (köpenyféleségnek) a neve amiben az előadó (a szerzetes, gondolom...) volt? És hol lehetne egy ilyet beszereznem? (Amazon vagy ebay megfelelne. Ne feledd kérlek hogy az USA-ban élek).

Kasaya (clothing) - Wikipedia

Buddhist Robe & Kasaya in Tibetan Culture (greattibettour.com)

Ahogy nézem a 'Kasaya' szó, amit keresünk, de hogy ne legyen ennyire egyértelmű:

Various types of monastic robes

In Tibetan Buddhism, people follow the Mulasarvastivada Vinaya. Tibetan Buddhism has its characteristics, where people wear a red robe. There are various types of robes, capes, and hats that Lamas, Tibetan nuns, and mons wear. Some of the basic pieces are:

  • Shemdap: It is a maroon skirt that is made using a patched piece of cloth.
  • Dhonka: Dhonka is this wrap shirt that has cape sleeves.
  • Chogyu: It is yellow, and it is just like sanghati as it is worn on the outer body.
  • Namjar: It is larger when compared with chogyu. Namjar is made for the formal ceremonial occasion, and it has more patches.
  • Zhen: It is used for daily wear and just like chogyu. Also, it is maroon in color.

Handpannél meg fogod Magad, keresel egy USA gyártót (van belőle bőven), elmész, kipróbálod, amelyiket magadénak érzed, azt hazaviszed, ha megvan rá a keret. :) De ha előtájékozódni szeretnél, akkor YT-n rákeresve az 'OHM Hand Drum' csatornára (Ők is azt hiszem USA gyártók), ott rengeteg skálát megtalálsz, ha választani nem is tudsz, egy irányt ez is adhat.

És a végére

Sam Maher - New York Handpan 01 - YouTube

:)

 

Szerintem.

Persze, hogy szuper, csak múltkor kifejtetted a 'modern zenével' kapcsolatos véleményedet. :D Ezért indítottam inkább a handpannel. :)

A ruha hivatalos nevét sajnos nem tudom, a nyilvánvaló keresőszavak használatával ilyesmik jöttek elő, hátha segít elindulni valamerre.

buddhist monk robe | eBay

Szerintem.

Tényleg és igazán örömet okozott neked e bejegyzés beírása? Ha nem, akkor miért csináltad?

Miért nem próbálod meg felvenni a harcot a lelkedben élő Sötétséggel szemben? Tudom, az első lépések nehezek, de utána egyre könnyebb lesz!

Ráadásul amit beírtál, még csak nem is volt se új, se humoros. Hiszen sose titkoltam hogy elsősorban magamnak csinálom e nyelvet, s hogy magam se hiszek a széles körű elterjedésében. Szóval akkor mi volt a célod ezzel a beírással, komolyan érdekelne! Csak hogy segíthessek rajtad!

És valóban tényszerű volt, ezt elismerem magam is, épp csak akkor is feleslegesen írtad be mert többször elismertem már magam is önként hogy nem hiszek a széles körű elterjedésében, DE NEM IS EZ A CÉLOM.

Szóval mélyen hiszem hogy bántási céllal írtad, csak tényleg nem értem még azt se hogy annak minek, hisz épp mert korábban magam is elismertem ezt, mikroszkopikus esélye se volt annak hogy megbánthatnál ÉPP EZZEL.

De akkor miért tetted? Neked is íráskényszered van mint nekem? Pontosabban kommentelési kényszered van? Vagy mi?

Vedd már észre kisbetu hogy súlyosan beteg vagy! Megfertőzte jobb sorsra érdemes elmédet a Gonoszság!

" mikroszkopikus esélye se volt annak hogy megbánthatnál ÉPP EZZEL."

TE MEG AZT VEDD ÉSZRE, HOGY NEM NEKED ÍRTAM.

A polgártárs tett egy feltételezést, én meg felhívtam a figyelmét elmélete bekövetkeztének infinitezimálisan kicsiny valószínűségére.

Tudnám, miért veszel mindent magadra, amit írok. Üldözési mániád van? Talán neked kéne kezeltetned magad.

Normális ember már nem kommentel sehol.

Gondolod hogy elhiszem hogy neki írtad? Hivatalosan ő volt a címzettje, de akkor is nekem szántad. Ugyanis te is tisztában kellett legyél azzal, hogy ő is tudja hogy én mindezt más rég elismertem a nyelvemről. De te úgy vélted ennek újra meg újra való emlegetésével meg tudsz engem bántani. Na ez nem jött össze. Megbánthatsz mert nagyon tehetséges gonoszkodó vagy, de semmi esetre se EZZEL tudsz megbántani.

De még ha netántán úgy is volna hogy ezúttal kivételesen nem ez volt a célod, köszönd a félreértést magadnak: mindenütt ahol lehet megpróbálsz belém kötni, szemlátomást a mániáddá váltam, így ne csodálkozz azon hogy ha valami velem vagy az alkotásaimmal kapcsolatban írsz, pláne ha az valamiféle értelemben negatívum említése vagy lesajnáló megjegyzés, azt magamra veszem. Ezt hosszas, sok éves állhatatos erőfeszítéssel érted el.

A múltad megbélyegez téged, kisbetu! Ideje volna tenned ezellen!

te is tisztában kellett legyél azzal, hogy ő is tudja hogy én mindezt más rég elismertem a nyelvemről

Miből gondolod, hogy random emberek tisztában vannak más random emberek napi ténykedésével? Én a reggeli standupon sokszor arra nem emlékszem, mit csináltam pontosan előző nap a sok feladat között, nemhogy mit kommentelt valaki egy netes fórumon hetekkel ezelőtt.

Ne keress kibúvót. Te nem aspergeres vagy hanem Gonosz.

A gonoszság és aspergeresség egymást kölcsönösen kizáró fogalmak. Egy Aspie is bánthat másokat, de csak akkor ha neki abból haszna származik. Haszon nélkül azonban, csak a bántás öröméért ahogy azt TE teszed, úgy NEM.

Az hogy te aspergeres lennél, egyszerűen nem igaz, csak mentséget keres a tetteidre a benned élő Gonoszság, és eleve ő maga is az ami ezt a szánalmas kibúvót próbálja elhitetni veled.

Az igaz hogy te ()elki)beteg vagy, de a betegséged neve nem asperger-szindróma hanem ez: Gonoszság!

De ha betegség, akkor meg lehet belőle gyógyulni... Mi lenne ha megpróbálkoznál vele, hm?

A gonoszság és aspergeresség egymást kölcsönösen kizáró fogalmak. Egy Aspie is bánthat másokat, de csak akkor ha neki abból haszna származik.

Nem teljesen értem, hogy az érdekből elkövetett gonoszság miért lenne jobb. 

Jogrendszerünkben például az ilyesmi minősített esete lehet bűncselekménynek. 

Vannak a rossztettek, ezek egy részhalmaza a gonoszság, ezeket szoktam Gonoszságnak nevezni vagy akár csupa nagybetűvel is, megkülönböztetésképpen, mert a legtöbb ember mint te is minden rossz, helyteleníthető tettet simán gonosztettnek nevez.

Ha valaki azért csinál valamit hogy neki abból haszna származzék, az természetesen valóban lehet adott esetben akár erkölcstelen is, helyteleníthető, illegális, törvényellenes, büntetendő, meg talán nagyon sok más egyéb is. Igen, lehet hogy simán börtönbe kerül miatta. Ha azonban még csak haszna se származik belőle, na az már egy egészen más kategória, sokkal „sötétebb”.

És e disztinkció jogosságát az igazolja, hogy a fajunk evolúciósan fejlődött ki „hitem” szerint, eképp cseppet se idegen tőle (se...) az, hogy egyedei harcoljanak egymással a különböző „erőforrásokért”, mint például a lakhely, a nőstény (néha a nőstények a hímekért...), a táplálék, a vadászterület, stb. A versengés tehát természetes ösztönünk, az önmagában véve nem gonoszság. Nyilván persze itt is túl lehet lépni az „egészséges” mértéket, az például már nem normális ha húsz forintért agyonversz valakit. Az okozott kár ugyanis messze nincs arányban a neked produkált haszonnal.

Abban az esetben azonban mit is mondhatnánk ha még csak hasznod se származik abból hogy kárt okozol a másiknak?! Amikor kizárólag amiatt bántod mert megteheted és kész? Mert CSAK?!

Ilyen viselkedés nem alakulhatott ki evolúciósan, mert normális egyed nem kezd bántani senkit akkor ha neki az nem hasznos. Azért nem, mert nem volt evolúciósan kifizetődő ez a viselkedés. Ugyanis az egészen nyilvánvaló, hogy a megtámadott egyed védekezni fog. Ha a megtámadott egyed sokkal gyengébb mint a támadó, akkor a védekezése ugyan nem lesz sikeres, a támadó biztosan győzni fog ez nyilvánvaló, de még ebben az esetben is védekezni fog akit megtámadtak, hiszen mást nem tehet, ez az egyetlen esélye, például történhet a harc során valami számára kedvező nagy véletlen, stb, tehát védekezni fog, és így ha gyengébb is, de előfordulhat hogy bár legyőzik, de a harc során bizonyos sérüléseket okoz a támadójának. A támadónak ez kár, veszteség. Még ha a sérülések nem halálosak sőt jelentéktelenek is, akkor is lehetnek fájdalmasak, de még ha nem is fájdalmasak akkor is elfertőződhetnek, stb. Ez mind kockázat. Na és evolúciós értelemben nem kifizetődő kockázatokat vállalni SEMMIÉRT. Sőt nemcsak akkior nem ha a haszon semmi, de még akkor se ha aránytalanul kicsi a befektetett energiához és kockázathoz képest.

EZ TEHÁT NEM NORMÁLIS.

Ha nem normális, akkor BETEGSÉG.

E betegséget nevezem tehát Gonoszságnak.

Azt nem tartom kizártnak persze hogy e betegség valamely olyan ösztönünk kóros elfajulása, mely a maga eredeti mértékében még normális volt. Például lehet valami köze az aggresszivitáshoz, a harciassághoz, talán a dicsekvéshez is hogy megmutassa ki a legény ha nem ő, és így tovább, sok minden lehet. De ebben az esetben se normális, mert semmi se normális ha olyan szintet ér el ami evolúciósan nem igazolható.

Abba ne köss bele hogy ez nem okoz kárt kisbetunek vagy más trollnak hiszen nincs valódi harc. Egyrészt, rengeteg tevékenységünk került át az internetre amit korábban valóságosan műveltünk és nem virtuálisan, szóval ha valódi kárt nem is okoz neki de attól még ez a késztetés mint ösztön igenis beteges, igenis Gonoszság. Nyilvánvaló ugyanis hogy az eltelt alig két vagy három évtizedhez amióta van internet, nem tudtunk még evolúciósan alkalmazkodni. Aki itt trollkodik, annak ez a jelleméből fakad, a BETEGES, a Gonosz jelleméből, a Gonosz késztetéseiből.

Másrészt igenis kárt okoz neki még e virtuális gonoszkodás is, mert ezzel POCSÉKOLJA az idejét, amit nem fordít így valami másra amiből esetleg keletkezhetne valami haszna. Vagy ha nem neki hát a családjának, azoknak akikkel genetikailag részben rokon.

Ez az egész tehát hogy trollkodás, tágabb értelemben hogy bántani valakit akkor is ha ebből a trollnak illetve a támadónak nem származik haszna, ez egy beteg, perverz dolog, teljesen nyilvánvalóan kiérdemli a Gonoszság nevet.

Megjegyzem ezen okfejtés megállja a helyét evolúció nélkül is, amennyiben simán levezethető vallási alapelvekből is, és nemcsak a kereszténységből de más vallásból is de ebbe most nem megyek bele, vélelmezve hogy nem sokan lehetnek itt akik különösebben vallásosok volnának. Csak jelezni óhajtom, e ténykedést a korábbi századok minden moralistája is mélyen elítélte volna.

Abban az esetben azonban mit is mondhatnánk ha még csak hasznod se származik abból hogy kárt okozol a másiknak?! Amikor kizárólag amiatt bántod mert megteheted és kész? Mert CSAK?!

Úgy gondolom, hogy

  • nem feltétlenül ismered a másik indítékát - azért, mert nem látod, még létezhet 
  • a "haszon" relatív 
  • a "kár" relatív 
  • a kommunikáció célját a befogadó (is) határozza meg

Ugyan már, ez mind nyilvánvalóan csak kibúvókeresés. Ez olyan mint amikor a beteg szemrehányást tesz az orvosának, miért mondta hogy semmi baja, nagyon jó az állapota, amikor pedig később kiderült hogy két hónapja se volt hátra és napokon belül meg fog halni. S ekkor az orvos azzal védekezik hogy hát az abszolút igazságot úgyse tudhatjuk, minden relatív, AKÁR meg is gyógyulhatott volna a beteg, és az állapota igenis remek volt, ezt ő úgy értette hogy ahhoz képest volt remek hogy ebben a betegségben szenved...

És megy a szócséplés és terelés ezerrel.

Én elég világosan kifejtettem nemegyszer nektek trolloknak hogy nem szeretem amit műveltek, hogy az fáj nekem, stb. Még azt is leírtam a visszatértemkor, hogy Trey jóeséllyel az életemet mentette meg amikor annó bannolt engem mert épp azt terveztem hogy beírom a HUP-ra hogy ez az utolsó postom mert miután elküldtem öngyilkos leszek. De nem tudtam beírni mert épp ekkor vettem észre hogy bannolva vagyok...

Ezt leírtam nektek. ENNEK ELLENÉRE nem hagytátok abba a trollkodást. Szerinted az nem Gonoszság, ha valaki ennyire nyilvánvalóvá teszi hogy neki valami FÁJ, s ti továbbra is művelitek azt? Mert CSAK?

Miféle haszon lenne az amit nektek a trollkodás okoz, mely összemérhető azzal hogy valakit esetleg a halálba üldöztök?!

És még ha védekezhettek is azzal hogy ezt eleinte nem tudtátok, legkésőbb tavasszal amikor visszatértem már tudtátok mert LEÍRTAM. Talán még meg is van itt valahol a HUP-on mert úgy emlékszem nem a később törölt saját topikjaimba írtam be, bár erre nem esküszöm meg. Akárhogyis, sokan olvasták.

Ennek ellenére, eszetekbe se volt abbahagyni. És biztos is hogy csak az mentett meg most hogy a Carnivore diétám miatt most jobb szellemi/érzelmi állapotban vagyok. De ez NEM A TI ÉRDEMETEK.

Még ezt se tartjátok Gonoszságnak?!

És akárki mással is lehet ez így. Nem tudhatjátok ki hogy viseli, még akkor se ha látszólag minden okénak tűnik, ha egy árva szót se szól, nem tiltakozik.

De ti csináljátok csakazértis mert csak. Mert virtulisan senki se vonhat benneteket felelősségre, maximum bannolva lesztek, ennek is kevés az esélye de ha mégis annyi baj legyen...

És akkor most itt te képes vagy azon igyekezni hogy ezen tettedet relativizáld?! Amikor pedig minden jóérzésű embernek teljesen nyilvánvaló hogy miről beszélek?!

Ugyan mondj már példát, miféle hasznot hozhat a trollkodás annak aki trollkodik, mely haszon szerinted összemérhető azzal, hogy esetleg a HALÁLÁT okozod valakinek a sok bántással!

És ezt nemcsak én mondom így. Tele van az Internet olyan esetekkel, amikor az efféle bullying miatt igenis öngyilkosak lettek emberek. Oké, többségükben gyerekek. De simán lehet egy felnőtt is ennyire érzékeny (pláne ha művész.,..) de meg abban se lehetsz biztos aki ide jár okvetlenül mind felnőtt-e. És egyáltalán, pláne akkor ha az illető többször kifejezetten jelzi hogy őt ez érzékenyen érinti! Ha kér benneteket! És ha oly könnyű is volna abbahagyni, mert legfeljebb nem látogatjátok a topikjait.

Na mondj példát arra, miféle haszon ér fel azzal a troll oldalán, hogy a tettével valaki más - akár többek - életét kockáztatja!

És mondd meg, mi szerinted a Gonoszság, ha nem ez!

Közmondás is van arra amúgy, hogy az ember nyelve éles mint a kés. Azaz sebezni tud vele. Ti meg csak jópofáskodásnak tartjátok, versenynek hogy ki tudja elmésebben bántani a másikat. Perverz dolog.

És ez még nem is okvetlenül lenne baj, ha azzal csinálnátok akit érdekel. De ha valaki jelzi hogy ő ezt nem tartja mókának, s mégis RÁKÉNYSZERÍTITEK, azzal hogy összerondítjátok a topikjait?!

Figyelj ezt nem haragból írom. De gondolkozz már el ezen kérlek. Nem veszed észre hogy az álláspontod erkölcsileg több sebből is vérzik?!

Ezt leírtam nektek. ENNEK ELLENÉRE nem hagytátok abba a trollkodást. Szerinted az nem Gonoszság, ha valaki ennyire nyilvánvalóvá teszi hogy neki valami FÁJ, s ti továbbra is művelitek azt? Mert CSAK?

Ahogy írtam, a kommunikáció szándékát részben a befogadó fél határozza meg. A kitörölt posztjaidban számtalan példa volt arra, hogy zajlott egy szakmai beszélgetés, amit te személyes sértésként éltél meg. Engem pl. baromira zavar, hogy ott véget vetettél egy érdekes beszélgetésnek, csak mert valami nem tetszett. 

Ha te indítasz egy threadet, akkor emberek hozzá fognak szólni. Adott esetben olyat is, amivel nem értesz egyet. Ez miért baj? Bizonyára te sem értesz mindennel egyet, ami elhangzik valahol a világban. 

Ezért tiltottam le őket...

Bár egészen őszintén, van némi lelkifurdalásom emiatt. Hiszen így kevésbé segíthetek nekik MEGJAVULNI...

De most mit csináljak, ha belebocsátkozom egy olyan küzdelembe amiben magam is elvérzek, attól nekik nem lesz jobb, csak nekem rosszabb. De még az se okvetlenül előnyös ha rengeteg energiát pocsékolok el így miközben a siker bekövetkezése legalábbis kérdéses, mely energiát amúgy az alkotásaimra is fordíthatnám. Például egy n+1 -edik regényre.

elsősorban magamnak csinálom e nyelvet

 

Mi lenne ha inkább naplót írnál posztolás helyett? Tudod, kézzel, papíron. Aztán majd ha eltávozol az örök programozó mezőkre, akkor majd a landlord aki kitakarítja a lyukat, megtalálja és kiadhatja a memoárjaidat.

Hivatásos pitiáner
neut @

Nem is érzi mekkora igaza van, hagyd. Színvonaltalan - önjelölt - alkotóként a semmijét kritizáló véleményeket nevezi semminek.
Nyilván ő is tudja, hogy a minőségi észrevételt képtelen generálni, ahhoz értéket kellene produkálni.
Inkább örvendezne, amíg egy szót is szól róla valaki. A hálátlan kontár.

Azért jár ide mert magányos, egyedül van. Ezért él a saját kis álomvilágában, ahol ő a király / művész / alkotó / tudós. Csak amikor idekint "pofán legyintik", akkor elindul egy ilyen végtelen ciklus, hogy "gonosz vagy / romboló vagy / sötét a lelked".

Hivatásos pitiáner
neut @

Na végre egy jó kérdés!

Az alkotásról mindenekelőtt azt kell tudni, hogy nem egy bináris fogalom hogy "ez alkotás, az meg nem". Nyilván, akadnak olyan tevékenységek amikről egyértelműen eldönthető hogy alkotás, másokról meg az hogy tutira nem azok. Mégis, ez egy skála inkább.

Talán azt mondhatnám, annál inkább NEM alkotás valami, minél inkább csak használ valamit amit mások alkottak, miközben ő maga (a tevékenység) nem nyújt lehetőséget másoknak újabb alkotásokra.

Ennek ellentéte az alkotás: minél kevesebb dolgot használsz fel mások korábbi alkotásaiból, s amit te csinálsz az minél jobban elősegíti mások (jövőbeli) alkotásait, annál inkább mondható a te tevékenységed alkotásnak.

Nyilván a relativitáselmélet megalkotása alkotás volt, hiszen rengeteg további felfedezéshez azaz Alkotáshoz nyitott utat. Hasonlóképp mondjuk a vérkeringés felfedezése is.

Ez azonban csak egy nyers definíció, az alkotásoknak ugyanis csak egyik fajtáját írja le szemléletesen. Mert alkotás az is, ha olyasmit csinálsz ami egyszerűen megnöveli az emberek örömét, legalábbis erre potenciálisan képes. Tipikusan ide tartoznak például a művészetek. A regényeim elsősorban ilyen értelemben alkotások, mert amíg olvassa őket valaki, csökken benne a stressz, elmenekül a gondjai elől, örömet érez, szórakozik...

Nyilván az a regény ami nemcsak erre képes hanem van benne valami „tanítás” is, komoly mondanivaló, az értékesebb. Számos regényem ilyen, bár elismerem hogy nem mindegyik.

Ilyen értelemben lehet alkotás egy szép festmény is amiben gyönyörködni lehet. Hiba lenne tehát az alkotás fogalmát csak a tudományos felfedezésekre leszűkíteni.

Alkotás azonban az is, ami egyszerűen csak valamiféle értelemben megnöveli az emberek szabadságát. Itt nem okvetlenül arra gondolok hogy kiszabadítani valakit egy kínai átnevelő táborból, bár valami speciális értelemben ez is nevezhető talán alkotásnak. Bár én inkább a „hőstett” névvel illetném. Hanem én inkább olyasmire gondolok, hogy mondjuk jó törvények hozásával szabadabb életet biztosítani egy országban úgy általában. Vagy felhívni a figyelmet a civilizációs betegségek és a helytelen táplálkozás kapcsolatára, hiszen akivel ezt közöljük annak nő a döntési szabadsága: ezek után tudatosan választhat az egészséges és egészségtelen életmód között, tudja melyiknek mi lesz a következménye! Tehát amikor én itt a carnivore diétát ajánlgatom a fórumon, az is alkotás, csak más jellegű mint mondjuk a regényírás. Ez olyasféle alkotás mint a tanítás. Egy jól felkészült, a szakmájához értő tanító a szememben méltó lehet az Alkotó névre: ő tulajdonképpen "világnézetet alkot" a tanítványai fejében. Igaz hogy az alkotása nem „kézzel fogható”, de ettől még alkotás.

Most szólítottál mesternek. Akkor mi jogon döntenéd el te aki nem vagy mester, hogy "hivatalos kiadás játszik csak”?

Van különben olyanom is, igen. De ebbe a játékodba akkor se megyek be, elvből, mert megaláznám az Alkotás nemes szellemét vele. Annak ugyanis hogy mi alkotás és mi nem, semmi köze holmi „hivatalos” dolgokhoz meg „kiadásokhoz”. Annak ugyanis mi „hivatalos” és mi nem, annak a HATALOMHOZ van köze, a kiadásnak meg a PÉNZHEZ.

Az alkotás lényege pedig nem ezen múlik, egyiken se, de pláne nem a kettőn együtt azaz a pénzügyi hatalmon.

Abban a pillanatban hogy elfogadnám, az alkotás attól függ mennyi hasznot produkál, vagy mások mennyi hasznot vélelmeznek belőle és így hajlandóak-e kiadni, abban a pillanatban prostituálnám a művészetemet, s vele úgy általában az Alkotás eszméjét is.

Egyáltalán semmi köze a kérdésednek a TE esetleges alkotásaidhoz és ezt te is tudod.

Te abban reménykedtél hogy nincs „hivatalos” kiadásom, ezt kénytelen leszek beismerni s akkor kezdhetsz majd gúnyolódni hogy nem is vagyok igazi művész, író, semmit se érnek az alkotásaim, sőt azok így nem is igazi alkotások (szerinted ugye).

Meg esetleg jöttél volna azzal is hogy nem érnek semmit azért mert nem kerestem velük sok pénzt meg ilyesmi.

Holott ez nem jött neked össze mert igenis van ISBN-es kiadásom (igazából még csak nem is csupán egyetlen...), másrészt, ennél is fontosabb hogy amint írtam fentebb, ez semennyire se mércéje annak, valami Alkotás-e. E véleményemet akkor is fennen hangoztatnám ha minden egyes művem ki lenne már adva „hivatalosan” és milliárdokat kerestem volna rajtuk. A kettőnek ugyanis semmi köze egymáshoz.

Megjegyzem, teljesen tudatlan vagy a témában amiatt is mert ISBN számot (vagy akár ISSN számot) POFONEGYSZERŰ SZEREZNI, még csak az se kell hozzá hogy legyen BÁRMI alkotásod amire megkéred!

Szóval már itt elvérzik még a te saját definíciód is arról, mi a „hivatalos”. Simán kiadhatnék akármikor ISBN számmal egy olyan könyvet is „hivatalosan”, ami csak a két borítólapból áll, közte meg még egyetlen árva üres papírlap sincs, nemhogy értékelhető szöveg, Alkotás! És még csak sokba se kerülne!

Ez tehát egyáltalán nem mércéje az alkotásnak.

Különben is, ha alkotni akarsz, KEZDJ NEKI, ne velem kötekedj. Ha segítséget akarsz, de tényleg és igazán, írj nekem privit, tedd fel a kérdéseidet (már ha netántán írni akarnál) s akkor válaszolok neked. Ha tisztességesen kérdezel. Segíteni hajlandó vagyok, igen, de arra nem, hogy hülye, kötekedő troll-játékokba menjek bele.

Nem olvastam végig.

A "terv" az volt, hogy kinyögöd, hogy 36,5 évesen adták ki az első ISBN-es könyvedet, ekkor pedig megnyugodtam volna, hogy még van időm.

Honnan tudod, hogy nem egy manualhoz gyűjtök alapanyagot éppen? Vagy egy játékhoz, hmmm?

Hivatásos pitiáner
neut @

Most hogy angolul tanulok, töltögetek le egy rakás angol filmet... jobbára természetfilmet, mert azt valahogy jobban megértem. A filmek egy belső SSD egységre mennek, ami 2 TB nagyságú, de mert ugye illik biztonsági másolatot készíteni, időnként archiválom is őket 2 külső merevlemezre, amik egyenként 3 terabájtosak. (Tehát két külön biztonsági másolatot is készítek).

Ezt a mentést az utóbbi időkben elhanyagoltam, sok mentenivaló gyűlt össze. Tegnap nekifogtam, és hát úgy találtam bizony rém macerás a rengeteg tartalomjegyzéket nekem személyesen ellenőrizni a merevlemezeken, melyik fájl nincs még oda átmásolva az SSD egységről...

Gondoltam, biztos van erre valami tool már, ami szinkronizálja a két tartalomjegyzék-struktúrát, de bevallom lusta voltam rákeresni, mert ugye aztán azt telepítenem kéne, ki tudja milyen függőségei vannak, meg kéne tanulni a kezelését is, tuti tele van egy rakás olyan feature-val is ami nekem nem kéne...

Szóval végigcsináltam inkább az egészet kézzel. manuálisan. Hát jó nagy szopás volt.

És egyre az járt a fejemben hogy ez azért mégis szégyen! Oké, most megcsináltam, de legközelebb is meg azután is?!

Végül persze azt a megoldást választottam amit biztos minden kedves Olvasóm kitalált eddigre: Írtam egy saját programot e feladatra, természetesen Peri nyelven! Íme a psync program:

###sysinclude standard.uh
###sysinclude args.uh
###sysinclude io.uh
###sysinclude str.uh

#g argc 4 < { #s ."Usage:\n" 0 argv print SPACE 1 argv print ." inputdir outputdir\n" end
}
2 argv sto idirpath @idirpath 'd inv istrue { ."The given input directory doesn't exist! Exited.\n"  end }
3 argv sto odirpath @odirpath 'd inv istrue { ."The given output directory doesn't exist! Exited.\n" end }
#g @aktpath 100 mem sto aktpath
#g @aktpath 100 mem sto opath
#g @aktpath 100 mem sto scommand
@idirpath getdir { ."Cannot load the input  dir! Aborted.\n" end } sto idir
@odirpath getdir { ."Cannot load the output dir! Aborted.\n" end } sto odir
@idir ~r { //."Regular files:\n"
@idir ~r  {{ #s
@idir 'r {{}} getfilename sto fname
opath  @odirpath = opath per
@fname sum opath
@opath 'r inv istrue { // The input file must be copied
aktpath @idirpath = aktpath per
@fname sum aktpath
scommand "cp " =
@aktpath sum scommand
" " sum scommand
@opath sum scommand
@scommand printnl
@scommand shell
}
@fname inv mem
}}
}
// Create the nonexistent directories if necessary:
@idir ~d { //."Directories:\n"
@idir ~d  {{ #s
@idir 'd {{}} getfilename sto fname
opath  @odirpath = opath per
@fname sum opath
@opath 'd inv istrue { // The dir must be created:
scommand "mkdir " =
@opath sum scommand
."Create output dir: " @scommand printnl
@scommand shell
}
@fname inv mem
}}
}
// ...................................
@idir ~d { //."Directories:\n"
@idir ~d  {{ #s
@idir 'd {{}} getfilename sto fname
scommand "peri psync.upu " =
@idirpath sum scommand
scommand per
@fname sum scommand
" " sum scommand
@odirpath sum scommand
scommand per
@fname sum scommand
@fname inv mem
@scommand shell
}}
}
@idir inv mem
@odir inv mem
@aktpath inv mem
@opath inv mem
end
// =============================================
{ „scommand” }
{ „aktpath” }
{ „opath” }
{ „fname” }
{ „idirpath” }
{ „odirpath” }
{ „idir” }
{ „odir” }

Gyönyörűen működik! Igaz, faék-egyszerűségű (de legalább SEMMIFÉLE függősége nincs is!), azt hogy kell-e egy fájlt másolni egyszerűen úgy dönti el, létezik-e olyan nevű fájl az adott directoryban vagy sem. Nem figyel méretet, létrehozási dátumot meg hasonlókat. Bele lehetne építeni ezt is simán, a Perihez írt directorykezelő libem képes efféle huncutságokat lekérdezni, de nekem felesleges most.

Szóval ez úgy működik, hogy megadjuk az input és output directorykat neki, ekkor az inputból minden hiányzó fájlt átmásol az outputba. Aztán megnézi az output dirből melyik alkönyvtárak hiányoznak amik az inputban benne vannak, ezeket is létrehozza, majd az input dir minden alkönyvtárára meghívja önmagát rekurzívan, a shellen át, megfelelőképpen felparaméterezve a parancssort, azaz megadva az új input és output könyvtárakat paraméterként...

A fájlok másolása, a könyvtárak létrehozása is shell paranccsal történik.

Nyilván ennek van bizonyos overloadja, de szerintem ez simán tolerálható, egyrészt mert ritkán kell használnom, másrészt, ilyen feladatnál az igazán jelentős időszükséglet nem az hogy a shellt hívjuk, a vele járó forkolás meg ilyesmi, hanem maga a másolás az ami jelentős ideig tart, még akkor is ha a cél egy SSD egység, hát még mint nálam amikor merevlemezre archiválok gigabájtos méretű fájlokat...

A Peri maga is képes rá hogy benne rekurzív programokat írjunk meg, shell nélkül, de nem akartam agyonbonyolítani. Verébre se lövünk atombombával.

Szerintem egy igazán remek, hasznos kis program született most a kezem alatt, az biztos hogy nagyon megkönnyíti majd a dolgomat a jövőben. Nagyon ritkán kell majd, de akkor aranyat ér!