Megbénítja a programozási nyelveket az ASCII öröksége?

Megbénítja a programozási nyelveket az ASCII öröksége?
2010-11-02T12:23:20+01:00
2011-11-14T15:16:23+01:00
2022-10-25T19:35:34+02:00
  • #123465 RGB
    Mutasd a teljes hozzászólást!
  • Azóta? Valaki leküzdötte már az ASCII-bénulatot, vagy még mindig tart?
    Mutasd a teljes hozzászólást!
  • A színtévesztők aránya orvosi kimutatások szerint meghaladja a 8%-ot a férfiak között, míg a nők kb fél százalékát érinti. Ez nem feltétlenül jelent teljes színvakságot, mert ide tartozik pl. az egyes színárnyalatok összetévestése is. Villanyszerelő nem lehet az illető, mert nem tudja megkülönböztetni a vezetékek színét, de bizonyos típusú színtévesztések kizáró, vagy korlátozó tényezők a gépjárművezetésben is. Nem véletlenül ellenjavallott a GUI dizájnban a csak színeken alapuló szemantikus tartalom.

    A színeken alapuló forráskódszerkesztés tehát kizárja, vagy jelentősen megnehezíti az emberiség közel egy tizede számára a programozói munkát.

    Az olyan technológia nehézségekről már nem is beszélve, hogy ki szabványosítja a színek jelentését? Ha az Eclipse szerint a zöld az string literál, de a VS szerint meg a lila, viszont a notepad+++ kéket haszál erre, akkor a kód máris olvashatatlan, értelmezhetetlen, vagy a feldolgozáshoz meg kell adni, hogy milyen eszközzel készül. Ha nem csak 7 féle jelentéshez kell szín A szívárvány alapszínei), akkor tovább nehezedik az olvasás, mert a monitor színhűségén is múlik, hogy az #123456 színt meg tudod-e különböztetni a #123465 RGB színtől.

    Egzotikus karakterek helyett meg kellene tanulni gépelni, annál gyorsabb szövegbevitelt még nem sikerült megalkotni, ígéretes jelöltek sincsenek jelenleg. Vagy legyen a forráskód valamilyen mátrix vonalkód, végül is azt is lehet kézzel szerkeszteni, csak pöttyöket kell rakosgatni egy négyzetbe.
    Mutasd a teljes hozzászólást!
  • Azért a rebol natívabban kezeli az URL-eket:

    print read http://prog.hu

    A http:// kezdetű stringeket eleve URL-nek értelmezi. Nem is kell idézőjelbe rakni.

    De lehet benne
    %Akarmit
    -is írni olyan string helyre amiben nincsen space.
    Mutasd a teljes hozzászólást!
  • Jó. Már nekem is leesett.
    Mutasd a teljes hozzászólást!
  • Nem vágtam ezt a méltatlanul hanyagolt featuret. Egy ideig bámulásztam is a kódot, de rájöttem mi a trükk
    Aztán Mate rákérdezett, és akkor muszáj volt kipróbálnom, hogy tényleg jól gondoltam-e.
    Mutasd a teljes hozzászólást!
  • Valóban, nagyon hasznos feature
    (csak az a kár, hogy blokkonként csak egy lehet belőle (duplicate label))
    Mutasd a teljes hozzászólást!
  • Kipróbáltad?
    Mutasd a teljes hozzászólást!
  • Valóban lehet, max nem fordul le a kód.
    Mutasd a teljes hozzászólást!
  • Ez pont ugyanannyira jó lenne BASIC-ben is
    Mutasd a teljes hozzászólást!
  • A C++ azért is jó, mert minden függvényben lehet url!

    pl.:

    int Foo() { http://akrarmi.hu/asfsd/sdf/sdf return 0; }
    Mutasd a teljes hozzászólást!
  • Mármint arra gondolsz, hogy van olyan programozási nyelv, ahol a kommentben nem lehet URL?
    Mutasd a teljes hozzászólást!
  • Mire gondolsz?

    Ha doksit generálsz, akkor doxygen meg minden ilyen cucc tudja.
    Az IDE meg tudja, a jump to definiton stb.
    Mutasd a teljes hozzászólást!
  • Amit én mostanában hiányolok, jó dolgonak tartanám, és könnyen illeszthető lenne, az a hiperlinkelhető komment.

    Más nem gondolt még erre?
    Mutasd a teljes hozzászólást!
  • Talán a jó öreg CapsLock-ot lehetne a string szinező funkcióra átváltani, a jelenlegi funkciójának úgysincs sok értelme.

    Ha le van nyomva a szövegszerkesztőben, akkor stringet írsz, ha nem akkor normálisan a szöveg többi részét. Így akár space-ekkel is kezdődhetne a szöveg.

    Ha egy ilyen szövegbe bemenne az ember akkor azt bővíthetné. Akkor már nem kellene a CapsLock-al játszania. De ha mégis megnyomná, akkor kikerülne a szöveg végére. Illetve ha a végén járna akkor befejezné.

    Persze ez a színezés és idézőjel eltüntetés csak a szövegszerkesztő opciója lenne. Magában a forráskódban szerepelne az idézőjel, csak a programozó nem látná (opcionálisan kapcsolható funkció). Így már egészen használható lenne az elképzelés.

    Kinek lenne kedve energiája és tudása mindezt eclipse alá kifejleszteni?
    Mutasd a teljes hozzászólást!
  • A plain text forráson túllépés zsákutca.

    Jó példa erre a szövegszerkesztő formátumok.
    Ha most a kezed ügyébe kerül pl. egy ChiWriter formátumú szöveg vért ízzadhatsz mire kinyered a tartalmát, a formátum konverzió meg még egy külön tortúra lenne.

    Nem véletlen, hogy előre tört az xml, mert plain text!
    Minden hibája mellett, ez az ami sikerre segítette.

    A mai gui-k már nagyszerű extrákat adhatnak a szimpla forráshoz, ha némi metaadatot adunk hozzá, de eközben a forrás plain text volta évtizedekre biztosítja a felhasználhatóságát.
    Mutasd a teljes hozzászólást!
  • De én azt is elviselném, ha mikor rámutatok egy változóra a szövegszerkesztőben, akkor kiírja a típusát, hogy hol deklaráltam és esetleg háttérszín változtatásával megmutatná, hogy hol látható, használható.


    szvsz az Eclipse az a szövegszerkesztő amit keresel. Igaz, hogy egy kicsit ágyúval verébre, de cserébe ... mindent tud amit szem-szájnak ingere. Csak egy kicsit túl nagy. Ellenben Linux, Windows és OSX alatt is megy. Valamint szinte minden nyelvhez van hozzá plugin.
    Mutasd a teljes hozzászólást!
  • Grafikus környezet: én szeretek parancssorban fordítani, tetszőleges szövegszerkesztővel kódot írni.
    Biztos lesznek "tunningolt" programnyelvek, lehet ez a jövő, de engem ez nem izgat.

    Amit hasznosnak vélek, az jelenleg is megvalósítható. Például a színek használata. De én azt is elviselném, ha mikor rámutatok egy változóra a szövegszerkesztőben, akkor kiírja a típusát, hogy hol deklaráltam és esetleg háttérszín változtatásával megmutatná, hogy hol látható, használható. E mellett színekkel jelölheti a típusát. Hosszabb kódból esetleg eljárásokat ki lehetne emelni, másokat elrejteni (szerkesztés idejére).

    Hasonló funkciók amik érdekelnének, és ezekhez semmilyen módosítás nem kell a forráskódban. Lehet hogy vannak esetek amikor jó lenne még 100 speciális karakter, vagy más nyelven programozók lehet szívesebben írnának saját nyelvükön (mondjuk nekünk ilyen gond nincs).

    De nekem speciális karakterek sem nagyon hiányoznak, a klasszikus AND, OR, NOT stb. logikai vagy bitműveleteket is szívesebben írnám ki szöveggel, ugyanígy ki lehet írni a többit is. És könnyebb ezt megjegyezni, olvasni, mint azt, hogy ha a felsővessző 4 pixel vastag és jobbra kacsint kicsit ferdén akkor az az AND, de ha véknyabb, vagy nem ferde, vagy 2 pixellel lejebb csúszik, vagy nem sárga hanem kék akkor már teljesen más.
    (Nem beszélve arról, hogy másolás közben is elveszhetnek ezek a spéci karakterek, vagy más fontkészletet használva megint másként nézhetnek ki.)

    De legegyszerűbb olyan nyelvet készíteni, hogy az ember ezeket átdefiniálhassa, és mindenki azt használja ami neki tetszik. Gond akkor lesz, ha beszúrod a kódot egy fórumba.
    Mutasd a teljes hozzászólást!
  • Note: Én is gondoltam rá, hogy fel lehetne hozni, hogy ha ez az elmélet igaz lenne, akkor például a kínai irodalom (szóírás) sokkal fejlettebb kellene legyen, mint az európai (betűírás).
    Mutasd a teljes hozzászólást!
  • "Megbénítja a programozási nyelveket az ASCII öröksége" Kicsit ahhoz hasonlít számomra, hogy "Megbénítja a magyar nyelvet, hogy csak 44 betű használható benne". Szerintem az ASCII több, mint elég ahhoz, hogy jól érthető, átlátható forráskódot lehessen benne gyártani. Szép dolog, hogy esetleg mindeféle szummákat, meg színeket lehetne használni, de igen furcsán nézne ki például egy szumma, ami alatt, vagy fölött valami tíztagú kifejezés áll. A színekkel meg úgy vagyok, hogy akkor lehetne kidobni az összes szintaksziskiemelőt, egyetlen önkényes színkiválasztáshoz kellene igazodni mindenkinek, ha meg túl sok a szín, lehet, hogy nem volna egyértelmű ránézésre egy új gépen, hogy ez most bézs, vagy keki (lásd még). Feltehetőleg kötelezően fehér háttered kellene legyen esetleg sötét desktop beállításoknál. Nem beszélve például a keresés/csere műveletekről, vagy verziókezelésnél a változások megjelenítéséről, amire nem maradna eszköz. Általános programnyelvnél talán arra sem lehet számítani, hogy mindenhol ugyanolyan betűtípusok vannak. Megugrana a forráskódok nyomtatásának költsége is, csak színes könyveket lehetne róluk írni. Lehet, hogy csak én gondolom, hogy léteznek olyanok, akik pl. PHP forrást ma is ssh kapcsolaton keresztül módosítanak? Én azt hiszem, hogy aki szép kódot akar írni, az tud jegyzettömbbel is, aki meg gányolni akar, az csak még durvábbakat tudna elkövetni színes-szagos szerkesztővel.
    Mutasd a teljes hozzászólást!
  • Hm...
    - Manapság hány olyan hely lehet, ahol nincs grafikus felület, relative nagy sebességű hálózattal? Szóval a fapados környezet kisése(szerintem) ma már nem lehet akadály. Kicsit olyan ez mapaság, mint harminc éve a "mi lesz a lyukszalagon tárolt programjaimmal?" volt... Nem?
    A fordítás egy része akár bevitel közben is megtörténhet, tehát jó eséllyel inkább gyorsítaná a fordítást (lásd a korábban már emlegetett ZX Spectrum beviteli rendszere) - pl. a szintaktikai elemzést, a logikai elemzések egy részét már a beviteli rendszer intézheti. (ahogy meg is teszi azt, mondjuk az Eclipse)
    -----
    Ez az egész egyre inkább kezd emlékeztetni egy Magic nevű "4GL" szörnyűségre.
    Vajon mi lett belőle?
    Mutasd a teljes hozzászólást!
  • A "formázást" leíró információkat is el kellene helyezni a dokumentumban, esetleg új dokumentum típus kellene. Ami miatt "fapados" környezetben eléggé nehezen olvasható lenne a kód, a kód mérete is nőne, esetleg a fordítás is lassabb lenne. De lehet a kódolás is, mert most villámgyorsan beírod/törlöd az idézőjel közötti szöveget, de ha még külön a színezéssel is szórakozni kéne (egérrel kattintani, menüből választani stb.) akkor az csak lassítana. Legalábbis minket "öregeket", az új generáció lehet hogy vevő lenne rá.
    Bár szerintem ennél "okosabb" dolgokkal is lehet gyorsítani a kód írását -ha cél ez egyáltalán.

    Hogy az IDE (illetve szövegszerkesztő) színekkel megjelöl dolgokat, az ma is megvalósítható gond nélkül.

    Hogy a billentyűzet gombjait átdefiniáljuk az csak az oprendszeren múlik, szerintem a Windows alatt is van erre lehetőség, sőt még DOS alatt is.

    Mondjuk engem zavar, ha olyan speciális karaktereket kell írnom programozás közben, amikről azt sem tudtam, hogy létezik, nem hogy hol van a helye a billetnyűzeten. Főleg zavar, ha nem is felismerhető egyértelműen, külalakra összetéveszthető más karakterekkel.
    Mutasd a teljes hozzászólást!
  • "a stringeket nem idézőjelbe tennénk és nem is kellene escapelni, hanem egyszerűen pirossal írnánk őket"

    és ha be akarom tenni a kódot egy fórumra, vagy csak gyorsan elküldeném magamnak a user gépéről egy textben (emailben) akkor szopó van.
    Mutasd a teljes hozzászólást!
  • Meg a tömege...
    (4000g, ha hihetünk az oldalnak. )
    Mutasd a teljes hozzászólást!
  • Az ujj és karmozgás érzékelő szerkezet jó elképzelés, de szerintem hasonló nehézségekbe fog ütközni, mint a szöveg felismerés. Valahogy el kell döntenie a gépnek, hogy karmozgás mikor szól neki, és mikor csinálunk valami mást.

    Az érintő képernyős megoldások az iPhone vonalnak köszönhetően viszont már egyre hétköznapibb lesz. A wacom új bamboo táblája elég jó eszköz lehet, mert nem csak mint tábla működik, hanem multitouch-os érintős felületként is funkcionál ... kár, hogy tavaly vettem egy intuos táblát ( bár az is szuper, csak az érintő megoldás hiányzik belőle. )

    Ezeknek az új beviteli eszközöknek az a buktatója, hogy az egyes operációs rendszerek mennyire támogatják ezeket a beviteli módokat. A tabletPC megoldás is ezen bukott meg.
    Mutasd a teljes hozzászólást!
  • Nem is lenne rossz: mondjuk a piros tintaszín jelentené a string-literált, de ha egy fehér háttéren piros tintaszínű szóköz nem lenne jól látható, akkor egy fehér háttéren sárga tintaszínű szóközt is használhatunk helyette

    Látom nem sikerült értelmezni a leírtakat. Talán olvasd el még egyszer amit írtam!
    Mutasd a teljes hozzászólást!
  • úgy képzelem el, hogy szabadon beállítható lesz, hogy milyen karaktereket rajzoljon ki


    Van már ilyen egy ideje: Optimus Maximus. Csak kicsit az ára húzós
    Mutasd a teljes hozzászólást!
  • Az viszont egy más kérdés, hogy szerintem a billentyűzet is a kibővített ASCII-hoz lett igazítva. Nem nagyon van hely több karakternek és ha pl. Alt+kód-dal kell szórakozni akkor megette a fene az egészet.

    Ez a billentyűzet téma szerintem rövidesen elavult lesz, áttérnek helyette az érintős dolgokra, vagy ha marad is a billentyűzet, akkor is úgy képzelem el, hogy szabadon beállítható lesz, hogy milyen karaktereket rajzoljon ki.
    Én mondjuk ujj és karmozgást érzékelő kesztyűt használnék szívesen egér meg billentyűzet helyett.
    Mutasd a teljes hozzászólást!
  • A válasz pedig az, hogy nyilván az ilyen speciális jelentéssel bíró ill. ábrázolhatatlan karakterek bevitelére valami speciális escape-elés kell. Ez nyilván egy színkód-alapú nyelvnél is megoldható lenne.

    Nem is lenne rossz: mondjuk a piros tintaszín jelentené a string-literált, de ha egy fehér háttéren piros tintaszínű szóköz nem lenne jól látható, akkor egy fehér háttéren sárga tintaszínű szóközt is használhatunk helyette
    Mutasd a teljes hozzászólást!
  • Rengeteget tud segíteni, ha az IDE színezi a kommenteket, stringeket, kulcsszavakat, stb... A kérdés csak az, hogy van-e annak értelme, hogy a stringet pusztán színezéssel jelöljem és ne kelljen kiraknom az aposztófot?

    Ez nem lehet kérdés, hiszen a színezés mellett gyakorlatilag tök felesleges az aposztróf. Hiszen a színezés megmondja neked, hogy egy sztringliterális van ott. Más kérdés, hogy ugye jelenleg a színezés a nyelvi elemeket jelölő speciális karakterszekvenciákból (mint például az aposztróf) van eredeztetve, és önmagában nem, ill. csak redundáns jelentéssel bír. De egy olyan nyelvnél, ahol a színezés jelölné a típust, nyilván tök felesleges lenne az aposztróf, és egy mai modern szintaxiskiemeléses IDE-hez képest csak egyszerűbbé válna a kód olvasása, azon keresztül, hogy nem lenne ott az aposztróf vagy más a színezés mellett redundáns jelölőelem, hanem csak maga a szín.

    A kérdés sokkal inkább az, hogy amikor írod a programot, akkor vajon effektívebben tudnád -e színezni azt a mostani elválasztójelek és kiemelő szekvenciák bevitele helyett. Vagy, hogy az IDE hogyan tudna ebben segíteni neked, munkát spórolni. Ehhez nyilván valami másfajta beviteli paradigma kellene, mint amit most használunk, mert pl. úgy ahogy a Word-ben vagy akármelyik más WYSIWYG szerkesztőben színezzük a szöveget, az nyilván nem túl effektív módja a színkódolásnak - legalábbis az aposztrófok beviteléhez képest biztosan nem.

    Pl. nekem jó ötletnek tűnik egyes billentyűket szín- ill. ezen keresztül típusváltónak definiálni. Ugye ez úgy működne, hogy ha amelyik típusváltozó gombot lenyomod (és itt tök mindegy, hogy ez mondjuk az F-gombokra, vagy akárhova máshova van definiálva) akkor a kódszerkesztő átvált az adott típusra, és a továbbiakban beírt alfanumerikus információt az adott típusként, vizuálisan pedig az adott típus jelölő színnel ábrázolja a forrásban. És pl. az aktuális típustól függően az 1234 beírása jelenhet egészt, sztringliterálist vagy változónevet, azonosítót is. Tehát ha mondjuk az 1234-et sztring-literálisként akarod bevinni, akkor F1-1-2-3-4 (5 darab) billentyűket kell megnyomnod, ha ugyanezt numerikus literálisként, akkor F2-1-2-3-4 (ugyanúgy 5 darab billentyű), ha meg változóazonosítóként, akkor F3-1-2-3-4 gombokat lenyomva tudnád bevinni. Ez persze csak egy nagyon egyszerű és kézenfekvő példá - nyilván lehetne optimalizálni a bevitelt, vagy lehet van jobb mód is. Igazából csak az alapkoncepciót szerettem volna szemléltetni, hogyan oldható ez meg.

    Ez a példa egyébként mindjárt jól szemlélteti, hogy pl. az 1234 sztringliterálisként történő bevitelnél a mostani módszerhez képest (ti. aposztróf-1-2-3-4-aposztróf billentyűsorozat) spórolnánk egy billentyűlenyomást, a numerikus literálisként történő bevitelnél meg pluszban kellene egy gombot nyomnunk (hiszen a legtöbb nyelvben önmagában az 1234 szekvencia ugye az ezerkétszázharmincnégy egész numerikus literálist jelenti, ami azokban most mindössze négy billentyű lenyomásával betudunk vinni, a fenti példában szereplő öthöz képest). Ugyanakkor lehetnének viszont számmal kezdődő és számból álló változóneveink is (ami a mostani nyelvekben pont a fenti alapértelmezés miatt nem lehet, és lehet jó lenne, ha lehetne), valamint nem lennének fordítási hibáink abból adódóan, hogy pl. elfelejtettük lezárni a sztringliterálist, és ezért az 1234-et sztringként értelmezi a fordító, miközben már numerikusként kellene neki. Ez is jó példa arra, hogy egy ilyen nyelv azért nagyon más lenne sok ponton, amik között előnyök és hátrányok is lennének a mostani nyelvekhez képest, nyilván a benne írt programok és az alkalmazott beviteli és struktúrálási paradigmák függvényében.

    Az egyedüli előnyt a picit tömörebb kódban látom, hátránya viszont több van. Hogyan írsz új karaktereket a szringbe?

    Ez nyilván az alkalmazott beviteli paradigmától függne. Nem az a kérdés, hogy meg tudod -e csinálni, hanem az, hogy miként mondod meg a kódszerkesztődnek, hogy amikor mondjuk bemész egy utasítás vagy kifejezéssor közepébe, és beírod oda, hogy ABCD, akkor egy változóhivatkozást kell -e értenie alatta, vagy sztringliterálist, esetleg típusazonosítót, vagy urambocsá nyelvi kulcsszót, vagy operátort (műveleti jelet). De itt megint az előbbi bekezdésben tárgyaltakhoz lyukadunk ki.

    Mit kezdesz a csak szóközöket tartalmazó, azzal kezdődő vagy azzal végződő stringgel?

    Erre a kérdésre a válasz ugyanaz, mint arra a kérdésre, hogy mit kezdesz a mai nyelvekben az ASCII 0 karakterrel vagy az aposztróffal a sztringliterálisokban (feltételezve, hogy a sztringdelimiter az aposztróf). Ez a válasz pedig az, hogy nyilván az ilyen speciális jelentéssel bíró ill. ábrázolhatatlan karakterek bevitelére valami speciális escape-elés kell. Ez nyilván egy színkód-alapú nyelvnél is megoldható lenne.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd