Ohjaava filosofia
1. Ohjelmointikielet ihmisille
Ohjelmointikielet ovat tapa, jolla ihmiset puhuvat tietokoneille. Tietokone puhuu mielellään mitä tahansa kieltä, joka ei ole moniselitteinen. Syy, miksi meillä on korkeatasoisia kieliä, johtuu siitä, että ihmiset eivät osaa käsitellä konekieltä. Ohjelmointikielten tarkoitus on estää köyhiä, hauraita ihmisaivojamme hukkumasta liian moniin yksityiskohtiin.
Arkkitehdit tietävät, että jotkut suunnitteluongelmat ovat arkipäiväisempiä kuin toiset. Jotkut selkeimmistä ja abstrakteimmista suunnitteluongelmista ovat siltojen suunnittelu. Tässä tapauksessa sinun tehtäväsi on kattaa vaadittu matka mahdollisimman pienellä materiaalimäärällä. Toisessa päässä on tuolien suunnittelu. Tuolien suunnittelijoiden tulisi käyttää aikansa ihmisten peppujen miettimiseen.
Ohjelmistokehityksessä on sama ero. Algoritmien suunnittelu tiedon reitittämiseksi verkon läpi on mukava, abstrakti ongelma, kuten siltojen suunnittelu. Ohjelmointikielten suunnittelu on kuin tuolien suunnittelua: inhimillisten heikkouksien kanssa on kohdattava.
Tätä on useimpien meistä vaikea ymmärtää. Tyylikkäiden matemaattisten järjestelmien suunnitteleminen kuulostaa useimmille meistä paljon houkuttelevammalta kuin inhimillisten heikkouksien parsiminen. Matemaattisen eleganssin rooli on, että jonkinasteinen eleganssi tekee ohjelmista helpompia ymmärtää. Mutta kaikki ei ole kiinni eleganssista.
Ja kun sanon, että kielet pitäisi suunnitella mukautumaan inhimillisiin heikkouksiin, en tarkoita, että kielet pitäisi suunnitella huonoille ohjelmoijille. Todellisuudessa sinun pitäisi suunnitella ohjelmistoja parhaille ohjelmoijille, mutta parhaillakin ohjelmoijilla on rajansa. En usko, että kukaan nauttisi ohjelmoinnista kielellä, jossa kaikki muuttujat on merkitty kirjaimella "x" ja kokonaislukujen alaindeksit.
2. Suunnittele itsellesi ja ystävillesi
Jos tarkastellaan ohjelmointikielten historiaa, suurin osa parhaista kielistä on suunniteltu omien kirjoittajiensa käyttöön ja suurin osa huonoimmista on suunniteltu muiden ihmisten käyttöön.
Kun kielet on suunniteltu muille ihmisille, se on aina tietty ryhmä ihmisiä: ihmiset eivät ole yhtä älykkäitä kuin kielen luojat. Näin saat kielen, joka puhuu sinulle. Cobol on näkyvin esimerkki, mutta useimmat kielet ovat täynnä tätä henkeä.
Sillä ei ole mitään tekemistä sen kanssa, kuinka korkea kieli on. C on melko alhainen taso, mutta se on luotu sen tekijöiden käyttöön, minkä vuoksi hakkerit rakastavat sitä.
Argumentti kielten suunnittelulle huonoille ohjelmoijille on se, että huonoja ohjelmoijia on enemmän kuin hyviä. Ehkä näin on. Mutta tämä pieni joukko hyviä ohjelmoijia kirjoittaa suhteettoman paljon ohjelmistoja.
Kysymykseni kuuluu, kuinka voit luoda kielen, joka vetoaa parhaisiin hakkereihin? Minusta näyttää siltä, että tämä kysymys on identtinen kysymyksen kanssa siitä, kuinka luoda hyvä ohjelmointikieli?, mutta vaikka se ei olisikaan, se on ainakin mielenkiintoinen kysymys.
3. Anna ohjelmoijalle mahdollisimman paljon hallintaa
Monet kielet (etenkin muille ihmisille tarkoitetut) toimivat kuin lastenhoitajat: he yrittävät varoittaa sinua sellaisista asioista, joista he eivät usko ole sinulle hyödyllisiä. Olen päinvastainen: anna ohjelmoijalle niin paljon hallintaa kuin voit.
Kun opin Lispin ensimmäisen kerran, pidin eniten siitä, että puhuimme tasavertaisina. Muissa kielissä, jotka olin oppinut siihen mennessä, oli kieli, ja siellä oli minun ohjelmani sillä kielellä, ja ne olivat olemassa aivan erikseen. Mutta Lispissä kirjoittamani funktiot ja makrot olivat samoja, joilla itse kieli kirjoitettiin. Voisin kirjoittaa itse kielen uudelleen, jos haluaisin. Sillä oli sama vetovoima kuin avoimen lähdekoodin ohjelmistoilla.
4. Lyhytisyys on lahjakkuuden sisar
Lyhyys on aliarvostettua ja jopa halveksittavaa. Mutta jos katsot hakkerien sydämiin, huomaat, että he todella pitävät lyhyydestä. Kuinka monta kertaa olet kuullut hakkereiden puhuvan hellästi siitä, kuinka esimerkiksi APL:ssä he voivat tehdä hämmästyttäviä asioita vain parilla koodirivillä? Luulen, että todella älykkäät ihmiset haluavat kiinnittää tähän huomiota.
Uskon, että melkein kaikki mikä lyhentää ohjelmia on hyvä asia. Kirjastotoimintoja pitäisi olla paljon, kaiken, mikä voi olla implisiittistä, pitäisi olla niin; syntaksin tulisi olla tiiviimpi; jopa entiteettien nimien tulee olla lyhyitä.
Eikä vain ohjelmien pitäisi olla lyhyitä. Myös käyttöohjeiden tulee olla lyhyitä. Suuri osa oppaista on täynnä selityksiä, vastuuvapauslausekkeita, varoituksia ja erikoistapauksia. Jos sinun on lyhennettävä käsikirjaa, paras vaihtoehto on korjata kieli, joka vaatii niin paljon selitystä.
5. Tunnista, mitä hakkerointi on
Monet ihmiset haluaisivat hakkeroinnin olevan matematiikkaa tai ainakin jotain tieteen kaltaista. Mielestäni hakkerointi on enemmän kuin arkkitehtuuria. Arkkitehtuurissa on kyse fysiikasta siinä mielessä, että arkkitehdin on suunniteltava rakennus, joka ei kaadu, mutta arkkitehdin todellinen tavoite on luoda hieno rakennus, ei tehdä löytöjä staattisen kentän alalla.
Hakkerit rakastavat loistavien ohjelmien luomista. Ja mielestäni meidän pitäisi ainakin omissa ajatuksissamme muistaa, että mahtavien ohjelmien kirjoittaminen on hieno asia, vaikka se työ ei helposti muunnukaan tieteellisten julkaisujen tavanomaiseksi älykkääksi valuutaksi. Älyllisestä näkökulmasta on yhtä tärkeää suunnitella kieli, josta ohjelmoijat pitävät, kuin kauhea kieli, joka ilmentää ajatusta, josta voit julkaista artikkelin.
Avoimet ongelmat
1. Kuinka järjestää suuret kirjastot?
Kirjastoista on tulossa tärkeä osa ohjelmointikieliä. Ne kasvavat niin suuriksi, että ne voivat olla vaarallisia. Jos kestää kauemmin löytää kirjastosta funktio, joka tekee sen, mitä tarvitset, kuin että kirjoitat funktion itse, kaikki koodi ei tee muuta kuin tekee käsikirjasta paksumman. (Symbolics-käsikirjat olivat esimerkki tästä.) Joten meidän on ratkaistava kirjaston organisointiongelma. Ihannetapauksessa ne suunnitellaan niin, että ohjelmoija voi arvata, mikä kirjastotoiminto sopii.
2. Pelkäävätkö ihmiset todella etuliitteen syntaksia?
Tämä on avoin ongelma siinä mielessä, että olen ajatellut sitä useita vuosia enkä vieläkään tiedä vastausta. Etuliitesyntaksi vaikuttaa minusta täysin luonnolliselta, paitsi ehkä sen käyttö matematiikassa. Mutta voi olla, että suuri osa Lispin epäsuosiosta johtuu yksinkertaisesti tuntemattomasta syntaksista... Kannattaako asialle tehdä mitään, jos se on totta, on toinen asia.
3. Mitä tarvitset palvelinohjelmistoon?
Luulen, että useimmat seuraavan kahdenkymmenen vuoden aikana kirjoitettavat sovellukset ovat verkkosovelluksia siinä mielessä, että ohjelmat sijaitsevat palvelimella ja kommunikoivat kanssasi verkkoselaimen kautta. Ja tällaisten sovellusten kirjoittamiseen tarvitsemme uusia asioita.
Yksi niistä on tuki uudelle tavalle julkaista palvelinsovelluksia. Yhden tai kahden suuren julkaisun sijasta vuodessa, kuten työpöytäohjelmistot, palvelinohjelmistot julkaistaan sarjassa pieniä muutoksia. Saatat julkaista viisi tai kymmenen julkaisua päivässä. Ja kaikilla on aina uusin versio.
Tiedätkö miten ohjelmia suunnitellaan ylläpidettäviksi? Palvelinohjelmisto on suunniteltava muutettavaksi. Sinun pitäisi pystyä muuttamaan sitä helposti tai ainakin tietää, mitä pieni muutos tarkoittaa ja mikä on tärkeää.
Toinen asia, josta voi olla hyötyä palvelinohjelmistoissa, on yhtäkkiä toimituksen jatkuvuus. Verkkosovelluksessa voit käyttää jotain sellaista saadaksesi rutiinien vaikutuksen verkkoistuntojen valtiottomassa maailmassa. Toiminnan jatkuvuus voi olla sen arvoista, jos ominaisuus ei ole liian kallis.
4. Mitä uusia abstraktioita on vielä löydettävä?
En ole varma, kuinka järkevä tuo toivo on, mutta henkilökohtaisesti haluaisin todella löytää uuden abstraktion - jotain, joka voisi olla yhtä merkityksellinen kuin ensiluokkaiset funktiot tai rekursio tai ainakin oletusparametrit. Ehkä tämä on mahdoton unelma. Tällaisia asioita ei usein havaita. Mutta en menetä toivoani.
Vähän tunnettuja salaisuuksia
1. Voit käyttää mitä tahansa kieltä
Aikaisemmin sovellusten luominen merkitsi työpöytäohjelmistojen luomista. Ja työpöytäohjelmistoissa on suuri painoarvo sovellusten kirjoittamiseen samalla kielellä kuin käyttöjärjestelmä. Joten kymmenen vuotta sitten ohjelmistojen kirjoittaminen tarkoitti yleensä ohjelmistojen kirjoittamista C-kielellä. Lopulta perinne kehittyi: sovelluksia ei pitäisi kirjoittaa epätavallisilla kielillä. Ja tämä perinne on kehittynyt niin kauan, että myös ei-tekniset ihmiset, kuten johtajat ja pääomasijoittajat, ovat oppineet sen.
Palvelinohjelmisto tuhoaa tämän mallin kokonaan. Palvelinohjelmistolla voit käyttää mitä tahansa kieltä. Lähes kukaan ei vielä ymmärrä tätä (etenkään johtajat ja pääomasijoittajat). Mutta jotkut hakkerit ymmärtävät tämän, minkä vuoksi kuulemme indy-kielistä, kuten Perl ja Python. Emme kuule Perlistä ja Pythonista, koska ihmiset käyttävät niitä Windows-sovellusten kirjoittamiseen.
Mitä tämä meille, ohjelmointikielisuunnittelusta kiinnostuneille, merkitsee, että työllämme on potentiaalista yleisöä.
2. Nopeus tulee profiloijilta
Kielten kehittäjät tai ainakin kielten toteuttajat kirjoittavat mielellään kääntäjiä, jotka luovat nopeaa koodia. Mutta mielestäni se ei tee kielistä nopeita käyttäjille. Knuth totesi kauan sitten, että nopeus riippuu vain muutamista pullonkauloista. Ja jokainen, joka on yrittänyt nopeuttaa ohjelmaa, tietää, että et voi arvata, missä pullonkaula on. Profiler on vastaus.
Kielten kehittäjät ratkaisevat väärän ongelman. Käyttäjät eivät tarvitse vertailuarvoja toimiakseen nopeasti. He tarvitsevat kielen, joka voi näyttää, mitkä heidän ohjelmansa osat on kirjoitettava uudelleen. Tässä vaiheessa käytännössä tarvitaan nopeutta. Joten ehkä olisi parempi, jos kielen toteuttajat käyttäisivät puolet ajastaan kääntäjän optimointiin ja käyttäisivät sen hyvän profiloijan kirjoittamiseen.
3. Tarvitset sovelluksen, joka saa kielesi kehittymään
Tämä ei ehkä ole lopullinen totuus, mutta näyttää siltä, että parhaat kielet kehittyivät yhdessä sovellusten kanssa, joissa niitä käytettiin. C:n kirjoittivat ihmiset, jotka tarvitsivat järjestelmäohjelmointia. Lisp suunniteltiin osittain symbolista eriyttämistä varten, ja McCarthy oli niin innokas aloittamaan, että hän jopa alkoi kirjoittaa eriyttämisohjelmia ensimmäisessä Lisp-paperissa vuonna 1960.
Tämä on erityisen hyvä, jos sovelluksesi ratkaisee uusia ongelmia. Tämä pakottaa kielesi saamaan uusia ominaisuuksia, joita ohjelmoijat haluavat. Henkilökohtaisesti olen kiinnostunut kirjoittamaan kielen, joka on hyvä palvelinsovelluksille.
[Keskustelun aikana Guy Steele toi myös tämän huomion ja lisäsi, että sovelluksen ei pitäisi koostua kääntäjän kirjoittamisesta omalle kielelle, ellei kieli ole suunniteltu kääntäjien kirjoittamiseen.]4. Kielen tulee soveltua kertaluontoisten ohjelmien kirjoittamiseen.
Tiedät, mitä yksikertainen ohjelma tarkoittaa: silloin sinun on ratkaistava nopeasti jokin rajoitettu ongelma. Uskon, että jos katsot ympärillesi, löydät monia vakavia ohjelmia, jotka alkoivat kertaluonteisina. En olisi yllättynyt, jos suurin osa ohjelmista alkaisi kertaluonteisina. Jos siis haluat luoda kielen, joka soveltuu ohjelmistojen kirjoittamiseen yleisesti, niin sen pitäisi sopia myös yksittäisten ohjelmien kirjoittamiseen, koska tämä on monien ohjelmien alkuvaihe.
5. Syntaksi liittyy semantiikkaan
Perinteisesti uskotaan, että syntaksi ja semantiikka ovat hyvin erilaisia asioita. Tämä saattaa kuulostaa järkyttävältä, mutta sitä se ei ole. Mielestäni se, mitä haluat saavuttaa ohjelmassasi, liittyy siihen, miten ilmaiset sen.
Puhuin äskettäin Robert Morrisin kanssa, ja hän huomautti, että operaattorin ylikuormitus on iso plussa infix-syntaksin kielten voitolle. Kielessä, jossa on etuliitesyntaksi, mikä tahansa määrittämäsi funktio on itse asiassa operaattori. Jos haluat lisätä uudentyyppisen numeron, jonka olet keksinyt, voit yksinkertaisesti määrittää uuden funktion sen lisäämiseksi. Jos teet tämän kielellä, jossa on infix-syntaksi, huomaat, että ylikuormitetun operaattorin käytön ja funktion kutsumisen välillä on suuri ero.
Ideoita, jotka palaavat ajan myötä
1. Uudet ohjelmointikielet
1970-luvulla oli muotia kehittää uusia ohjelmointikieliä. Näin ei nyt ole. Mutta uskon, että palvelinohjelmistot tuovat jälleen muotia uusien kielten luomiseen. Palvelinohjelmistolla voit käyttää mitä tahansa kieltä, joten jos joku luo kielen, joka näyttää paremmalta kuin muut, on ihmisiä, jotka päättävät käyttää sitä.
2. Ajan jakaminen
Richard Kelsey keksi tämän idean, jonka aika on jälleen koittanut, ja kannatan sitä täysin. Oma veikkaukseni (ja myös Microsoftin) on, että suuri osa tietojenkäsittelystä siirtyy työpöydältä etäpalvelimille. Toisin sanoen ajan jakaminen on palannut. Mielestäni tämä tarvitsee tukea kielitasolla. Esimerkiksi Richard ja Jonathan Reeves ovat tehneet paljon työtä prosessien ajoituksen toteuttamiseksi kaaviossa 48.
3. Tehokkuus
Äskettäin näytti siltä, että tietokoneet olivat jo tarpeeksi nopeita. Kuulemme yhä enemmän tavukoodista, mikä ainakin minulle tarkoittaa, että meillä on jonkin verran tehoa varassa. Mutta mielestäni palvelinohjelmistolla meillä ei ole sitä. Jonkun on maksettava ohjelmistoa käyttävistä palvelimista, ja palvelimen tukemien käyttäjien määrä konetta kohden on heidän pääomakustannusten jakaja.
Uskon, että tehokkuudella on merkitystä, ainakin laskennan pullonkauloissa. Tämä on erityisen tärkeää I/O-toiminnoissa, koska palvelinsovellukset suorittavat paljon tällaisia toimintoja.
Lopulta voi käydä ilmi, että tavukoodi ei ole vastaus. Sun ja Microsoft näyttävät menevän vastakkain tavukoodikentässä tällä hetkellä. Mutta he tekevät tämän, koska tavukoodi on kätevä paikka upottaa itsensä prosessiin, ei siksi, että tavukoodi itsessään olisi hyvä idea. Saattaa käydä niin, että koko tämä taistelu jää huomaamatta. Se olisi hauskaa.
Ansoja ja ansoja
1. Asiakkaat
Tämä on vain arvaus, mutta ainoat sovellukset, jotka hyötyvät, ovat ne, jotka ovat täysin palvelinpuolella. Ohjelmiston suunnittelu, joka toimii sillä oletuksella, että jokaisella on asiakas, on kuin yhteiskunnan suunnittelua, joka perustuu olettamukseen, että kaikki ovat rehellisiä. Se olisi varmasti kätevää, mutta sinun on oletettava, että sitä ei koskaan tapahdu.
Uskon, että web-yhteensopivien laitteiden määrä tulee lisääntymään nopeasti, ja voimme olettaa, että ne tukevat perus-html:ää ja lomakkeita. Onko puhelimessasi selain? Onko PalmPilotillasi puhelin? Onko Blackberryssäsi isompi näyttö? Pääsetkö käyttämään Internetiä pelipojaltasi? Kellostasi? Minä en tiedä. Ja minun ei tarvitse ottaa selvää, lyönkö vetoa, että kaikki on palvelimella. On vain paljon luotettavampaa, jos kaikki aivot ovat palvelimella. .
2. Olio-ohjelmointi
Ymmärrän, että tämä on kiistanalainen lausunto, mutta en usko, että OOP on niin tärkeä. Mielestäni tämä on sopiva paradigma tietyille sovelluksille, jotka tarvitsevat tiettyjä tietorakenteita, kuten ikkunointijärjestelmät, simulaatiot, CAD-järjestelmät. Mutta en ymmärrä miksi sen pitäisi sopia kaikille ohjelmille.
Luulen, että suurten yritysten ihmiset rakastavat OOP:ta osittain, koska se tekee monista asioista, jotka näyttävät työltä. Se, mikä voidaan luonnollisesti esittää vaikkapa kokonaislukuluettelona, voidaan nyt esittää luokkahuoneena, jossa on kaikenlaisia telineitä, hälinää ja hälinää.
Toinen OOP:n houkutteleva ominaisuus on, että menetelmät antavat sinulle osan ensiluokkaisten funktioiden vaikutuksesta. Mutta tämä ei ole uutinen Lisp-ohjelmoijille. Kun sinulla on todellisia ensiluokkaisia toimintoja, voit käyttää niitä millä tahansa käsillä olevaan tehtävään sopivalla tavalla sen sijaan, että työntäisit kaiken luokkien ja menetelmien kattilaan.
Mielestäni tämä tarkoittaa kielisuunnittelun kannalta, että sinun ei pitäisi upottaa OOP:ta liian syvälle siihen. Ehkä vastaus on tarjota yleisempiä, perustavaa laatua olevia asioita ja antaa ihmisten suunnitella mitä tahansa objektijärjestelmiä kirjastoiksi.
3. Toimikunnan suunnittelema
Jos kielesi on komitean suunnittelema, olet loukussa, etkä vain syistä, jotka kaikki tietävät. Kaikki tietävät, että komiteoilla on tapana luoda möykkyisiä, epäjohdonmukaisia kielisuunnitelmia. Mutta mielestäni suuri vaara on, että he eivät ota riskejä. Kun yksi henkilö on vastuussa, hän ottaa riskejä, joita komitea ei koskaan suostuisi ottamaan.
Pitääkö sinun ottaa riskejä hyvän kielen luomiseksi? Monet saattavat epäillä, että kielisuunnittelussa on pysyttävä melko lähellä perinteistä viisautta. Lyön vetoa, että näin ei ole. Kaikessa muussa, mitä ihmiset tekevät, palkkio on verrannollinen riskiin. Joten miksi kielisuunnittelun pitäisi olla erilaista?
Lähde: will.com