Miért éppen az E?
Java, Perl, Python, C++, TCL, és még sorolhatnánk. Nincs még elég programozási nyelv? Mivel indokoljuk mégis egy másik nyelv életre keltését?
Valójában még mindig van számos ok jobb programozási nyelvekre: egyre bonyolultabb programokat írunk. És ami mégrosszabb, egyre bonyolultabb rendszerektől függő programok ezek.
Aki rakott már össze bonyolultabb rendszert Web szerverek, Java, JSP, SQL, CI, COBRA, RML, XML és Perl összevisszaságából, tudja, hogy nem lehet ez az eszköz, amit még 20 év múlva is használni fogunk. Minél gyorsabban váltunk új eszközökre annál jobb lesz. Ebből az okból mutatjuk be az E nylevet:
- Az E-nek alapvető előnye a többi nyelvvel szemben az osztott rendszerekben rejlik. Egy gyors példa a hatékonyságára, E-ben lévő promise-adatcsatorna nem teszi lehetővé a holtpont kialakulását.
- Osztott rendszerek terén az E drámai előnyökkel rendelkezik. Minden kommunikáció erősen titkosított az E-ben, ami azonban a programozónak látható. A felhasználói interfész kód kivételével egy egyszerű, azonban effektív peer-to-peer biztonságos chat rendszert meg lehet írni kevesebb, mint 30 soros kódban. Egyetlen sorral sincs többre szükség egy egyszerű digitális banki szerver létrehozásához sem, annak ellenére, hogy sulyos biztonsági hiányosságai lesznek. Az E-vel egyszerűen létrehozhatunk olyan az interneten keresztül kommunikáló rendszereket, amik olyan biztonságban működnek, mintha csak saját számítógépünkön futna, otthon a pincében. Mint ahogy a Smalltalk egyik fejlesztője megjegyezte az E biztonságával kapcsolatban: "ha nem kell használnod, észre sem veszed"
- Az E-vel lehetőségünk nyílik a hatékony többfelhasználós korlátozottan megbízható mobil kódok használatára. "Mobil kód"-nak nevezünk akármi végrehajthatót a számítógépünkön, amit valahonnan máshonnan szereztünk. Minden alkalommam, mikor elindítunk egy Word-öt, játszunk a Passziánsszal, vagy duplán kattintunk egy e-mail csatolmányra, lefuttatunk egy mobil kódot, amit valaki olyan írt, akit nem ismerünk, és nem kéne megbíznunk benne. Ennek ellenére még mindig teljes olvasási jogot adunk akár a Passzánsznak, és a Christmas ElfBowling-nak legszemélyesebb dokumentumainkhoz. Az unokáink valószínűleg egy jót mosolyognak majd ezen, hogy nem volt más lehetőség. Ha a Microsoft E-t használt volna Visual Basic helyett, a Word, az Excel nem lehetett volna "vírusgazda" az eredeti Love Letter vírus számára. Hogyha minden szoftver E-ben készült volna, Klez és BackOrifice sosem léteztek volna. Valójában a sajtó által annyira kedvelt "vírus" kifejezés, amely a gyógyíthatatlanságra utal, nem terjedt volna el a számítástechnikában.
Ezek a tulajdonságok nem valósíthatók meg megszokott biztonsági megközelítésekkel. Ne gondoljuk, hogy a Java, Windows, vagy akár a Linux következő verziói megoldják a problémákat: a probléma az alapokban rejlik, javíthatatlanul anélkül, hogy a feljebbmenő kompatibilitást megtörnénk. Természetesen semmi sem akadályozza meg, hogy reklámozzák a felfelé kompatibils "teljesen biztonságos" új verziókat. Csak ne ugorjunk a Dunába, hogy megszerezzük őket.
Ezeket az erősségeket az E c/java syntaxisba burkolja így gyorsan kényelmes lehet meglehetősen sok szoftver mérnöknek. Alapjaiban objektumokra épül, ezért egyszerű benne moduláris, olvasható, fenntartható szoftvert írni a Javaban megszokott stratégiák felhasználásával. Az egyszerű és hatékony stringhasználat ismerős lehet a Perl programozók számára. Az E dinamikusan típusos nyelv, annak előnyeivel és hátrányaival, akárcsak a Smalltalk, nem ugy mint a Java, mely ugyebár statikusan típusos. Perlt és Pythont használók ezt előnyként fogják fel, míg a Java és C++ programozók nem biztos. A legmegbízhatóbb, legkomplexebb rendszerek közül sok dinamikusan tipusos nyelvben készült. Ha statikus tipusosság helyességében felettébb meggyőzött Java programozók vagyunk, ajánlatos az E-t mielőbb kiprobálni, és a következtetéseket azután levonni. Valószínűleg kellemes és eredményes tapasztalatokat szereznénk, ahogyan a történelem során számos Smalltalk, Perl vagy Python programozó.
Miért ne az E?
Az E azonban nem csodaszer. Az E jelenlegi implementálása java virtuális gép fölött fut. Mint olyan, nem egy tökéletes nyelv alacsony szintű gép manipulációra. Ezért ne próbáljunk E-ben eszköz illesztőprogramot készíteni. Az E a C-vel szemben gyengébb teljesítményű, ezért ne használjuk rakétavezérlő rendszer kernelének fejlesztésére.
Valójában, a legtöbb érv figyelmen kívül hagyja a szoftverfejlesztés legfotosabb szempontját. Általános álláspont: "Először működjön, aztán gyorsan működjön" Az E egy kiváló nyelv ahhoz, hogy működjön a program. Ha egyszer működik a rendszer, megvizsgálva a kódot megállapitjuk, hogy melyik kodrészlet hat a teljesítményre, és ezeket (az általában kis) részleteket átírhatjuk Java-ban, C-ben attol függ, hogy mik az elvárásaink. Igazábol számos sok számítást igénylő műveletnél az E ugyanolyan hatékony, mint bármely másik nyelv.
Valójában tehát az E majdnem csodaszer, de nem teljesen.