De, filozofaljon csak. Semmi gond nincs a filozofalassal, legfeljebb mas programozok mas eredmenyre jutnak vele.
Pl. ott van Knuth, aki a 'literary code' nevu dologgal (is) nyomul. Az eppen arr epit erosen, hogy a programban hasznalt mnemonikok (tobbek kozott valtozonevek) magukert beszelnek, es egy-egy betu ugye nem sokat mond.
elhelyezessel, szinekkel, szagokkal sok mindent lehet csinalni, de az egyik legjobb infohordozo azert szerintem tovabbra is a szoveg. Es mivel a gepeles kvazi ingyen van, en nem latom miert kellene pont ezzel sporolni. Az olvaso szem ugyis patterneket lat, az altalanos iskolat elhagyva legalabbis nem betuket silabizalunk a szovegben, hanem egybol szavakat, sot, jobb esetben kifejezeseket, mondatokat latunk.
Ez olyan dolog, amit az ember ugyis megtanul, es magatol mukodik -- mindenfele kodolasi kiserlet csak zavarja a mehanizmus mukodeset. Persze barmilyen kodot meg lehet tanulni megfelelo munkaval, aki sokat dolgozott hex koddal, ascii, ebcdic meg minednfele egyb kodokkal, varazsszamokkal, peekekkel es poke-okkal, regiszterekkel egy ido utan termeszetes modon olvassa es irja ezeket.
De a sima szoveg sokkal takarekosabban hasznalhato, plane ha sok embert erint a tema, es/vagy ezen emberek kore valtozik.
Olyat is el tudok kepzelni, hogy el sem nevezzuk a valtozokat, hanem ahol szerepeline keellene, nos azokat a pontokat osszekotnenk vezetekekkel.
A fuggvenyhivas helyen is lehetne egy vezetek amely a fuggvenydefiniciohoz vezet.
Ha tul kuszak a vezetekek, jelzi, hogy rossz a program; at kell strukturalni...
Szerintem nem olyan nagy hulyeseg ez a tema, mint aminek latszik.:)
>a csik meg kozben tolja a repulot... ;-))
a repulo kapcsolasi rajzat megerthetjuk ugy is, hogy az IC-ket nevezzuk el csak, a tobbit meg (szines) vezetekekkel kotjuk ossze.
Az IC-k olyanok mint az objektumok. Az egykarakteres valtozok meg olyanok, mint (szines) vezetekek. A valtozo ugyanis nem mas mint vezetek azon programreszek kozott amelyik ir bele, es amelyik olvas belole.
Mechanikai rendszerek leirasanal vizualis informaciokra tamaszkodunk.
Torvenyszeru, hogy szoftverrendszerek leirasa erosen nyelvi alapu, vagy esetlegesen alakult ki igy?
Nem tudom. De a kiserletezo kedvet hajlamosak az emberek elbol elitelni. Vagy egy programozo nem filozofaljon?
Pedig lehet, hogy neha a latszolag befott eszi meg a latszolag nagymamat.
Szerintem az egykarakteres nevek hasznalata es a strukturalt programozas teljesen ortogonalis fogalmak, de javits ki ha tevedek.
Az egykarakteres valtozoneveknek nem feltetlenul rosszak, ha eleg kicsi scope alatt vannak. (Pl. kis for ciklusok indexvaltozojat altalaban i-nek nevezem.) Mint ahogy az egyik hozzaszolasomban emlitettem, az egykarakteres valtozonevek osztonoznek a kis scopeok hasznalatara: modularitasra.
Az ujrafelhasznalhatosag valoban fontos dolog, ezert gondoltam, hogy a nyelv ne csak strukturalt, de objektum orientalt is legyen.
En 20 eve programoztam igy Basicben (marmint egy karakteres valtozonevek), de kb. 15 eve atszoktam a strukturalt programozasra. Azt valahogy jobban at tudtam tekinteni, es kesobb is felhasznalhatonak gondoltam.
Jé egy igazi programozó. Már azt hittem csak én vagyok úgy ezzel, hogy papíron és más médiákon agyalgatok, tesztadatokat csinálok, stb. És amikor editor elé ülök, akkor sem a programnyelv izgat, hanem a határidő, a sör hőmérséklete és a pizzafutár késése :D
Arra próbáltam célozni, hogy a programozás alapvetően a programozó fejében (jegyzetfüzetében stb) történik, az hogy azt milyen programnyelven implementáljuk, az már másodlagos kérdés kell legyen...
Azert amiota egy kicsit tulkinalat van programozokbol, nemigen vesznek fel ilyeneket cegekhez dolgozni. Ha igen, akkor ott a vizsgaztatoval is gond van:)
Margit neni nem tartozik a celkozonsegbe, en inkabb programozokra gondoltam:)
Azt hiszem, hogy a szemleletesseg a programozok eseten is elony lehet: minel szemleletesebb egy programozasi nyelv, annal bonyolultabb szerkezeteket tud atlatni a programozo gond nelkul.
Persze nem allitom, hogy az altalam felvazolt otlet egyertelmuen szemleletes, ez csak egy otlet, amely lila kodben szuletett.:)
(Miért már ma is sok olyan ember van, aki szerint a programozói munka azt a folyamatot jelenti, amikor a vezérlőelemeket feldobáljuk az dialógus-dobozba)
A kodra csak ranez az ember, mint a 'Beautiful Mind' cimu filmben Nash a kodtablakra, kozben az egeret ramozditja nehany komment ikonra, es nehany perc utan megerti a programot.:)
Te most tényleg azt hiszed, ha Margit néninek az üzemi konyháról megmutatsz egy ilyet, az majd jól megérti ?! :DDDDDDDDDDDD
Azért ez sem kutya:
#!/usr/bin/perl -w
# 531-byte qrpff-fast, Keith Winstein and Marc Horowitz # # MPEG 2 PS VOB file on stdin -> descrambled output on stdout
# arguments: title key bytes in least to most-significant order
$_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map{$_%16or$t^=$c^=(
$m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;$t^=(72,@z=(64,72,$a^=12*($_%16
-2?0:$m&17)),$b^=$_%64?12:0,@z)[$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h
=5;$_=unxb24,join"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$
d=unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d>>12^$d>>4^
$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*8^$q<<6))<<9,$_=$t[$_]^
(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}print+x"C*",@a}';s/x/pack+/g;eval
Ha nem a sima ASCII-t vesszük alapul, hanem a korszerűbb Unicode-ot, akkor abban rengeteg jel, jelölés van ami tovább tömöríthetné a nyelvet. De pl. a sokféle ékezetet is felhasználhatnánk valaminek a jelölésére. A kínai, koreai, stb. hieroglifák pedig szinte hiheetlen gazdagsággal látná el ezt a nyelvet.
Ám szerintem nem itt van a megoldás. Van értelme olyan nyelvet csinálni, amelyet hónapokig kell tanulni, hogy aztán mindíg pillanatok alatt átlássuk? A tömörség valóban növelheti az átláthatóságot (bár a hibalehetőséget is a redundancia hiánya miatt), de a megtanulhatóságban inkább időt veszítünk, ami a mai embernek már nincs. Így inkább az elsőre érthetőt tanulják meg, nem pedig azt, amelyre hetekig kell kondícionálniuk magukat.
A megoldás, igaz még csak gyerekcipőben, a jelenlegi vizuális fejlesztőeszközökben van. Ezekben a kód nagy része vizuális strukturákba van eldugva, és csak egy töredék jelenik meg igazi programnyelvként (pl. Delphi-ben a .PAS állományokhoz még a .DFM is "kódot" tartamaz, csak sohasem nézünk bele, de hozzá lesz fordítva).
Rengeteg dolgot lehet a programkódból még vizualizálni úgy, hogy még áttekinthetőbb legyen, és a felesleges részek el legyenek rejtve. Utóbbiakat rákattintással, vagy "kibontással" láthatóvá lehet tenni, ha akarjuk.
Ugyanakkor én azt tartom, hogy egy programnyelv csupán egy jelölési rendszer az algoritmus leírására. Ez lehet jobb-rosszabb, ám ez erősen szubjektív. Megfigyelhetjük ezt az egyes nyelvek közötti "melyik a jobb?" vitákban.
Szerintem legyen mindenkinek saját jelölésrendszere (testreszabott!), amely mögött egy láthatatlan, de egységes belső kód van. Ezt a belső kódot minden programozó úgy láthatja a képernyőn, ahogyan magának testreszabta. Akár C, akár Pascal, akár más - egyéni - stílusban. Akár színes és tömör betűhalmazok alakjában. Nem ez az érdekes. Ez csak egy szubjektív oldal. A lényeg az egységes belső kód, ami lefordítható. És persze a kód tetszőleges része testreszabottan vizuálisan is megjelenhet.
Ezt a fajta rugalmas nyelvet persze valamikor valakinek meg kellene már csinálni.
Igen gondolkodtam a kommenteken is.
Erre azt a kompromisszumos otletet talaltam ki, hogy az editorban a kommentek helyen egy kis 'comment' ikon jelenik meg, es amikor fele viszed az egeret, akkor egy kis 'tool tip' jellegu sarga ablak jon fel, mint a Windowsban, ahol a kommentet olvashatod.
(Persze opcionalisan lehetne olyan uzemmod is az editorban, hogy a kommentek megjelenjenek a forrasban.)
Namost szamitasaim szerint egy kisebb osztaly egy soros lesz, nagyobb osztalyok kis fuggvenyei es memberei egy kozos sorban, nagyobb fuggvenyek sajat sorban jelennek meg. (persze lehetnek tobb sorosak is).
A kodra csak ranez az ember, mint a 'Beautiful Mind' cimu filmben Nash a kodtablakra, kozben az egeret ramozditja nehany komment ikonra, es nehany perc utan megerti a programot.:)
Nincs ezzel gond: az assembly forrásokban is 9:1 az állás a kommentek javára.* Legfeljebb mégsem volna ennyira tömör, és nem férne el egy oldalon az egész program, de hát úgyis ritka az olyan nyelv, amit pontosan úgy és arra használunk, ahogyan és amire eredetileg tervezték. :)
*Mondjuk, egy popot még mindig könnyebben meg tudnék emészteni, mint egy zöldnormálnagypét. :)
én a saját, többé-kevésbé "beszélő" változónevekkel megírt progijaimat is qrva nehezen értem meg pár hónap/év múlva... szal soxerencsét a dologhoz, de én biztos nem fogom használni
:-) p
>tetszoleges karakter bevitele max 2 gomb lenyomasa
Elnezest pontositanek: a szintelen-formatlan esethez kepest max 1 plusz billenytyu lenyomas karakterenkent.
Nem hiszem, hogy lesz idom megcsinalni ezt a nyelvet (valamibol meg is kell elni), bar csak eloforditot akarnek irni ami C++-ra fordit.
Mindenesetre rajottem, hogy ezt a nyelvet colibri-nek kell nevezni.
>Viszont amit a gépelésről írtam, az még mindig >áll. Lehetnek benne az algoritmusok tömörek, de >hogy szerkeszteni és írni a kódot nem egyszerű, >azt én biztosra veszem.
Egyreszt az ember az ido nagy reszeben nezi a forrast, es csak ritkan ir.
Masreszt:
Leultem, lefektettem az alapokat, es arra is rajottem, hogy osszesen 4 szint (fekete, piros, zold, kek) es 3 betuformat (normal, bold, italic) fogok hasznalni (feher alapon). Ennel tobb szin vagy forma mar esetleg felreertheto lehet.
Ez tizenket kombinacio. A billentyuzetemen pontosan 12 funkciobillentyu van. Ugyhogy tetszoleges karakter bevitele max 2 gomb lenyomasa. Hozzaveve azt, hogy nehany karakterrel komplett algoritmust irhatsz le, nem a gepeles lesz a szuk keresztmetszet.:)
Lehet hogy csak azért ragaszkodom annyira ehhez mert ezt szoktam meg. (amúgy nem ragaszkodom hozzá, meg szeretem a Python-t is bár nem sokat használom)
Viszont amit a gépelésről írtam, az még mindig áll. Lehetnek benne az algoritmusok tömörek, de hogy szerkeszteni és írni a kódot nem egyszerű, azt én biztosra veszem.
Egy szintén a hagyományos programozás kereteiből kitörni kívánó "nyelv" itt.
Érdekes lehet még a szimbólum behelyettesítés is, ez valahol a te elképzelésed és a fent említett projekt határterületén lehet.
Toma
