Irányító filozófia
1. Programozási nyelvek az emberek számára
A programozási nyelvek az eszközök, amelyeken az emberek a számítógépekkel kommunikálnak. A számítógép örömmel fog beszélni bármilyen nyelven, amely nem kétséges. Azért van szükségünk magas szintű nyelvekre, mert az emberek nem tudják kezelni a gépi nyelvet. A programozási nyelvek lényege, hogy megakadályozzák az emberi agyat a részletek tömegének túlterhelésében.
Az építészek tudják, hogy egyes tervezési problémák földhözragadtabbak, mint mások. Az egyik legismertebb és legabstraktabb tervezési probléma a hidak tervezése. Ebben az esetben az Ön feladata, hogy a lehető legkevesebb anyaggal hidalja át a szükséges távolságot. A spektrum másik végén a székek tervezése áll. A széktervezőknek időt kell tölteniük azzal, hogy az emberi test formáira gondoljanak.
A szoftverfejlesztés hasonló eltérésekkel bír. Az algoritmusok tervezése az adatok hálózaton való irányítására egy jó, absztrakt probléma, vagyis mint a hidak tervezése. Míg a programozási nyelvek tervezése inkább a székek tervezéséhez hasonló: foglalkoznia kell az emberi gyengeségekkel.
Sokunknak nehéz ezt felismerni. Az elegáns matematikai rendszerek tervezése sokkal vonzóbbnak tűnik a legtöbben számára, mint az emberi gyengeségek figyelembevétele. A matematikai elegancia szerepe az, hogy egy kis fokú elegancia megkönnyíti a programok megértését. De az elegancia nem minden.
Amikor azt mondom, hogy a nyelveket úgy kell megtervezni, hogy figyelembe vegyék az emberi gyengeségeket, nem arra gondolok, hogy a nyelveket a gyenge programozók számára kell tervezni. Valójában úgy kell terveznie a szoftvert, hogy a legjobb programozókra is figyelemmel legyen, de még a legjobb programozók is rendelkeznek határokkal. Nem hiszem, hogy bárkinek is tetszene programozni egy olyan nyelven, ahol minden változó az 'x' betűvel és egész számú indexekkel lenne megjelölve.
2. Tervezzen saját magának és a barátainak
Ha megvizsgáljuk a programozási nyelvek történelmét, a legjobb nyelvek többségét saját szerzőik terveztek, míg a legrosszabbakat mások számára készítették.
Amikor a nyelveket mások számára tervezik, az mindig egy konkrét embercsoport: az emberek nem olyan okosak, mint a nyelv létrehozói. Így olyan nyelvet kapunk, amely leereszkedően beszél veled. A Cobol a legszembetűnőbb példa, de a legtöbb nyelv tele van ezzel a szellemmel.
Ennek semmi köze ahhoz, hogy mennyire magas szintű a nyelv. A C egy meglehetősen alacsony szintű nyelv, de azért hozták létre, hogy a szerzői használják, ezért szeretik nagyon a hackerek.
Az érvet arra, hogy olyan nyelveket tervezzünk, amelyek rossz programozók számára készültek, általában azzal támogatják, hogy a rossz programozókból több van, mint a jókból. Talán ez igaz. De ez a kis számú jó programozó aránytalanul több szoftvert ír.
Engem az a kérdés érdekel, hogyan lehet olyan nyelvet alkotni, amely a legjobb hackereknek tetszik? Ez a kérdés úgy tűnik, mint a „Hogyan lehet jó programozási nyelvet létrehozni?” kérdésével azonos lenne, de még ha nem is, érdekes kérdés mindenképpen.
3. Adj a programozónak annyi ellenőrzést, amennyit csak lehet.
Sok nyelv (különösen azok, amelyeket mások számára terveztek) úgy viselkedik, mint a dada: próbálnak figyelmeztetni téged olyan dolgokra, amelyek szerintük nem hasznosak számodra. Ezzel szemben én azt vallom: adj a programozónak annyi kontrollt, amennyit csak tudsz.
Amikor először tanultam meg a Lispet, leginkább azt szerettem, hogy egyenrangú félként beszélgettünk. Más nyelvek, amelyeket eddig tanultam, volt egy nyelv, és volt egy programom azon a nyelven, és ezek meglehetősen külön léteztek. De a Lispen a funkcióim és makróim pontosan olyanok voltak, mint amiken maga a nyelv is futott. Ha akartam volna, újra létrehozhattam volna magát a nyelvet. Ugyanolyan vonzó volt, mint a nyílt forráskódú szoftverek.
4. Az egyszerűség a tehetség testvére.
A tömörség alulértékelt és még meg is vetett. De ha a hackerek szívébe nézel, meglátod, hogy ők nagyon értékelik a tömörséget. Hányszor hallottál hackereket arról beszélni, hogy az APL-ben milyen csodálatos dolgokat tudnak művelni mindössze néhány sor kóddal? Úgy hiszem, hogy az igazán okos emberek valójában szeretik felhívni a figyelmet erre.
Azt hiszem, hogy szinte minden, ami a programokat rövidebbé teszi — jó. Biztosan kell, hogy legyen sok könyvtári függvény, minden, ami implicit — annak kell lennie; a szintaxisnak sokkal inkább tömörnek kell lennie; még az entitások neveinek is rövideknek kell lenniük.
És nemcsak a programoknak kell rövidek lenniük. A kézikönyveknek is rövideknek kell lenniük. A kézikönyvek jelentős része telis-tele van magyarázatokkal, kitételekkel, figyelmeztetésekkel és különleges esetekkel. Ha le kell rövidítened egy kézikönyvet, a legjobb megoldás az, hogy javítod a nyelvezetet, amely annyi magyarázatot igényel.
5. Ismerd el, mi a hackelés
Sokan szeretnék, ha a hackelés matematika lenne, vagy legalábbis valami, ami hasonlít a természettudományokra. Úgy gondolom, hogy a hackelés inkább hasonlít az építészetre. Az építészet kapcsolódik a fizikához, abban az értelemben, hogy az építésznek olyan épületet kell terveznie, ami nem omlik össze, de az építész valódi célja egy nagyszerű épület létrehozása, nem pedig a statika felfedezése.
Amit a hackerek szeretnek, az nagy programok létrehozása. És úgy gondolom, hogy legalábbis a saját gondolatainkban emlékeznünk kell arra, hogy nagyszerű programokat írni csodálatos, még akkor is, ha ez a munka nem könnyen átváltható a tudományos munkák szokásos szellemi valuta formájára. Intellektuális szempontból éppen olyan fontos egy programozók által szeretett nyelvet kidolgozni, mint egy olyan szörnyű, az ötletet megtestesítő programot létrehozni, amelyről cikket publikálhatsz.
Nyitott problémák
1. Hogyan lehet nagy könyvtárakat megszervezni?
A könyvtárak a programozási nyelvek fontos részévé válnak. Olyan nagyokká nőhetnek, hogy ez veszélyessé válik. Ha több időt vesz igénybe egy olyan funkció megtalálása a könyvtárban, amely azt csinálja, amit szükséges, mint megírni ezt a funkciót magunknak, akkor az egész kód nem csinál mást, csak vastagítja a kézikönyvet. (A Symbolics kézikönyvek jó példák erre.) Tehát meg kell oldanunk a könyvtárak szervezésének problémáját. Ideálisan úgy kellene őket megtervezni, hogy a programozó kitalálhassa, melyik könyvtár funkció passzol.
2. Valóban megijedtek az emberek a prefix szintaxistól?
Ez egy nyitott kérdés abban az értelemben, hogy évek óta gondolkodom rajta, és még mindig nem tudom a választ. A prefix szintaxis számomra teljesen természetesnek tűnik, talán a matematikai alkalmazását kivéve. De lehet, hogy a Lisp-ek népszerűtlensége nagyrészt az ismeretlen szintaxisból fakad… Érdemes ezzel foglalkozni, ha ez igaz, ez egy másik kérdés.
3. Mire van szüksége a szerver szoftvernek?
Azt gondolom, hogy a következő húsz évben írt legtöbb alkalmazás webalkalmazás lesz, abban az értelemben, hogy a programok a szerveren helyezkednek el, és a webböngészőn keresztül kommunikálnak veled. Ahhoz, hogy ilyen alkalmazásokat írjunk, új dolgokra lesz szükség.
Egy ilyen dolog a szerver alkalmazások kiadásának új módjának támogatása. Ahelyett, hogy évente egy vagy két nagy kiadást tennénk közzé, mint a desktop szoftverek esetében, a szerver szoftver egy sor apró változtatással fog megjelenni. Lehet öt vagy tíz kiadás naponta. És mindenkinek mindig a legújabb verziója lesz.
Tudod, hogyan kell úgy tervezni a programokat, hogy azok karbantarthatók legyenek? A szerver szoftvernek úgy kellene tervezve lennie, hogy képes legyen a változásokra. Képességednek kell lennie könnyen módosítani, vagy legalább tudnod, hogy mit jelent egy apró változtatás és mi számít fontosnak.
Még egy dolog, ami hasznos lehet a szerver szoftverben, az a hirtelen megjelenő folyamatos szállítás. Webalkalmazásban használhatsz valami ilyesmit, mint , hogy a stateless web session világában alprogramok hatását elérd. Lehet, hogy a folyamatos szállítás megéri, ha ez a lehetőség nem túl drága.
4. Milyen új absztrakciók várnak még felfedezésre?
Nem vagyok biztos benne, hogy ez a remény mennyire ésszerű, de személy szerint nagyon szeretném felfedezni egy új elvont fogalmat — valami olyat, ami olyan fontos lehet, mint az első osztályú funkciók vagy a rekurzió, vagy legalább a default paraméterek. Lehet, hogy ez egy megvalósíthatatlan álom. Az ilyen dolgok gyakran nem tárulnak fel. De nem veszítem el a reményem.
Keveset tudott titkok
1. Bármely nyelvet használhatsz, amit szeretnél
Korábban az alkalmazások létrehozása a desktop szoftver fejlesztését jelentette. A desktop szoftverek esetében nagy hajlandóság van arra, hogy az alkalmazásokat ugyanabban a nyelven írják, mint amilyen az operációs rendszer. Tíz éve a szoftverek létrehozása gyakorlatilag a C nyelven való programozást jelentette. Az idő múlásával a hagyomány fejlődött: az alkalmazásoknak nem kell szokatlan nyelveken készülniük. Ez a hagyomány annyira fejlődött, hogy a nem műszaki emberek, mint a menedzserek és a kockázati tőkebefektetők is elsajátították.
A szerver szoftver teljesen lerombolja ezt a modellt. A szerver szoftverrel bármely nyelvet választhatsz. Majdnem senki nem érti még ezt (különösen a menedzserek és a kockázati tőkebefektetők). De néhány hacker ezt érti, ezért hallottunk olyan indie nyelvekről, mint a Perl és a Python. Nem hallunk a Perl és a Python nyelvekről, mert az emberek ezeket Windows alkalmazások készítésére használják.
Mit jelent ez számunkra, akik érdeklődünk a programozási nyelvek tervezése iránt, hogy potenciális közönség van a munkánk számára.
2. A sebesség a profilerből származik
A nyelv fejlesztői vagy legalábbis a megvalósítói szeretik azokat a fordítókat írni, amelyek gyors kódot generálnak. De úgy gondolom, hogy nem ez teszi a nyelveket gyorssá a felhasználók számára. Knuth régóta észrevette, hogy a sebesség mindössze néhány szűk keresztmetszettől függ. És bárki, aki megpróbált felgyorsítani egy programot, tudja, hogy nem tudja megjósolni, hol található a szűk keresztmetszet. A profiler a válasz.
A nyelv fejlesztői nem a megfelelő problémát oldják meg. A felhasználóknak nincs szükségük arra, hogy a benchmarkok gyorsan működjenek. Olyan nyelvre van szükségük, amely meg tudja mutatni, hogy a programjuk mely részeit kellene átírni. Ezen a ponton a sebesség már a gyakorlatban szükséges. Talán jobb lenne, ha a nyelv megvalósítói az idő felét, amit a fordító optimalizálására fordítanak, inkább jó profiler írására költenék.
3. Olyan alkalmazásra van szüksége, amely elősegíti a nyelvének fejlődését
Lehet, hogy ez nem végső igazság, de úgy tűnik, hogy a legjobb nyelvek azok voltak, amelyek együtt fejlődtek azokkal az alkalmazásokkal, amelyekben használták őket. A C nyelvet olyan emberek írták, akiknek szükségük volt rendszerszintű programozásra. A Lisp-et részben szimbolikus differenciálásra fejlesztették ki, McCarthy annyira sietett, hogy már az első Lisp dokumentumban 1960-ban elkezdett differenciálási programokat írni.
Ez különösen jó, ha az alkalmazása új problémákat old meg. Ez arra ösztönzi a nyelvet, hogy rendelkezzen új funkciókkal, amelyekre a programozóknak szükségük van. Személy szerint engem érdekelne egy nyelv megírása, amely jó lenne szerveralkalmazásokhoz.
[A vitában Guy Steele is felvetette ezt a gondolatot, hozzátéve, hogy az alkalmazásnak nem kell a nyelvének fordítója írásából állnia, hacsak a nyelve nem programozók számára készült.]
4. A nyelvnek alkalmasnak kell lennie egyszeri programok írására.
Tudja, mit jelent az egyszeri program: amikor gyorsan kell megoldania egy korlátozott feladatot. Úgy gondolom, ha körülnéz, rengeteg komoly programot talál, amelyek egyszeri programokként indultak. Nem lepődnék meg, ha a legtöbb program egyszeri programként indult. Tehát, ha olyan nyelvet szeretne létrehozni, amely alkalmas szoftverírásra általánosan, akkor alkalmasnak kell lennie egyszeri programok írására is, mert ez sok program kezdeti stádiuma.
5. A szintaxis kapcsolódik a szemantikához
Hagyományosan azt tartják, hogy a szintaxis és a szemantika nagyon eltérő dolgok. Lehetséges, hogy meglepően hangzik, de nem így van. Úgy gondolom, hogy az, amit a programjában el szeretne érni, összefügg azzal, ahogyan ezt kifejezi.
Nemrég beszéltem Robert Morris-szal, és megemlítette, hogy az operátorok túlterhelése nagy előny a infix szintaxisú nyelvek győzelméhez. A prefix szintaxisú nyelvekben bármely funkció, amelyet definiálsz, tulajdonképpen operátor. Ha szeretnél létrehozni egy új szám típust, amelyet kitaláltál, egyszerűen definiálhatsz egy új funkciót az összegzésére. Ha ezt infix szintaxisú nyelven teszed, akkor nagy különbséget látsz az túlterhelt operátor használata és a funkció hívása között.
Ideák, amelyek idővel visszatérnek
1. Új programozási nyelvek
A 1970-es évekre visszatekintve népszerű volt új programozási nyelvek fejlesztése. Ma már nem így van. De azt hiszem, hogy a szerveroldali szoftverek ismét divatba hozhatják az új nyelvek létrehozását. A szerveroldali szoftverrel bármilyen nyelvet használhatsz, amit csak szeretnél, tehát ha valaki létrehoz egy nyelvet, amely jobbnak tűnik a többinél, lesznek emberek, akik elhatározzák, hogy használják azt.
2. Időmegosztás
Richard Kelsey ezt az ötletet vetette fel, amelynek ideje ismét elérkezett, és én teljes mértékben támogatom. Feltételezésem (és a Microsoft véleménye is), hogy sok számítás átkerül a számítógépekről a távoli szerverekre. Más szóval, az időmegosztás visszatért. Úgy gondolom, hogy ennek a támogatása nyelvi szinten szükséges lesz. Például Richard és Jonathan Reeve sok munkát fektetett a folyamatütemezés bevezetésébe a Scheme 48-ban.
3. Hatékonyság
Nemrég úgy tűnt, hogy a számítógépek már elég gyorsak. Egyre többet hallunk a bájt-kódokról, ami legalábbis számomra azt jelenti, hogy van kapacitásunk tartalékként. De azt hiszem, hogy a szerveroldali szoftverek esetében ez nem így van. Valakinek meg kell fizetnie a szerverek, amelyeken a szoftver működik, és a felhasználók száma, akiket egy szerver el tud látni egy gépre számítva, a tőkeköltségeik osztója lesz.
Azt gondolom, hogy a hatékonyság fontos lesz, legalábbis a számítások szűk keresztmetszeteinél. Különösen fontos ez a bemeneti-kimeneti műveletek esetében, mivel a szerveralkalmazások sok ilyen műveletet végeznek.
Végül kiderülhet, hogy a bájt-kód nem megoldás. A Sun és a Microsoft jelenleg úgy tűnik, hogy szemtől szembe harcolnak a bájt-kód területén. De ezt azért teszik, mert a bájt-kód kényelmes hely a maguk beágyazására a folyamatba, nem pedig azért, mert a bájt-kód önmagában jó ötlet. Lehet, hogy ez az egész harc észrevétlen marad. Ez vicces lenne.
Csapdák és buktatók
1. Ügyfelek
Ez csak egy feltételezés, de abban rejlik, hogy csak azok az alkalmazások fognak győzni, amelyek teljesen szerveroldaliak lesznek. Olyan szoftvert tervezni, amely a feltételezésre épít, hogy mindenkinek lesz a ti kliensük, olyan, mintha olyan társadalmat építenénk, amely arra a feltételezésre épít, hogy mindenki becsületes. Ez határozottan kényelmes lenne, de el kell fogadnunk, hogy ez sohasem fog megtörténni.
Azt hiszem, fogyni fog a web hozzáférhető eszközök száma, és feltételezhetjük, hogy támogatni fogják az alap HTML-t és űrlapokat. Van böngésző a telefonodon? Lesz telefon a PalmPilotodon? A blackberry-dnek nagyobb képernyője lesz? Lesz lehetőséged internetezni a gameboy-odon? Az óráidon? Nem tudom. És nem kell ezt tudnom, ha arra fogadok, hogy minden a szerveren lesz. Sokkal megbízhatóbb, ha az összes agy a szerveren van.
2. Objektum-orientált programozás
Megértem, hogy ez egy ellentmondásos állítás, de nem tartom fontosnak az OOP-t. Szerintem ez egy megfelelő paradigma bizonyos alkalmazások számára, amelyek specifikus adatstruktúrákat igényelnek, mint például az ablakkezelő rendszerek, szimulációk, CAD rendszerek. De nem értem, miért lenne megfelelő minden program számára.
Azt hiszem, hogy a nagy vállalatok emberei azért szeretik az OOP-t, mert részben sok mindent úgy mutat be, mintha munka lenne. Az, ami természetesen megjeleníthető, mondjuk, egy egész számok listájaként, most már osztályként jelenik meg mindenféle építkezési állványokkal, zajjal és zsivajjal.
Az OOP másik vonzó jellemzője, hogy a metódusok valamilyen első osztályú függvényként működnek. De ez nem újdonság a Lisp programozók számára. Amikor valódi első osztályú függvényeid vannak, egyszerűen felhasználhatod őket bármilyen módon, ami megfelel a feladathoz, ahelyett, hogy mindent bele kellene nyomni egy osztály- és metódusmintába.
Azt gondolom, hogy a nyelvi tervezés szempontjából nem szabad túlságosan mélyen beágyazni az OOP-t. Talán a válasz az lenne, hogy általánosabb, alapvetőbb dolgokat javasoljunk, és hagyjuk, hogy az emberek bármilyen objektumrendszert könyvtárak formájában tervezzenek meg.
3. Bizottsági tervezés
Ha a nyelvét bizottság tervezi, akkor csapdában van, és nemcsak a közismert okok miatt. Közismert, hogy a bizottságok hajlamosak darabos, következetlen nyelvi dizájnt létrehozni. De azt hiszem, hogy a legnagyobb veszély abban rejlik, hogy nem vállalják a kockázatokat. Amikor egy személy áll a vezetés mögött, ő kockázatokat vállal, amelyeket a bizottság soha nem fogadna el.
Szükséges riskálni a jó nyelv létrehozásához? Sokan gyanakodhatnak arra, hogy a nyelvtervezés az a terület, ahol viszonylag közel kell maradni a hagyományos bölcsességhez. Merem állítani, hogy ez nem így van. Az emberek által végzett egyéb tevékenységeknél a jutalom arányos a kockázattal. Szóval miért lenne más a nyelvtervezés?
Forrás: habr.com
