Halvem on parem

See kirjutis tõmbab (mõneks ajaks) joone alla seiklustele Unixi ja C-ga.

On võimalik (never say never), et seiklus jätkub, sel juhul väga tõenäoliselt C++ kujul.

On aga võimalik, et kogu C kogemustepagasist saan ma mõne noore õppinud selli käest mühatuse -

C on reaalsete meeste jaoks, s.t. selliste vanade peerude värk... - kui ta on viisakas ja kui ta ei ole, ei tule sedagi.

Ja seda, mida C puhul hinnatakse, tuleks veel kõvasti harjutada - kirjutada mõni kompilaator valmis näiteks.

Teine rakendus, mida ehk võiks vaja minna, on mõne teise programmeerimise keele jaoks kirjutada mingi jupp koodi, mis midagi teeks väga kiiresti. Tavaliselt on see töö juba ära tehtud ja sellise töö tegijaid ka väga ei vajata.

Kolmas võimalik rakendus oleks robotid ja muu säärane värk. Viimati näiteks uurisin mingit käepaela programmi - see oli tehtud väga algelises C-s. Oskasin isegi probleemi ära lahendada.
Laiale rahvale tarbeprogrammide kirjutamine C-s ilma suure vajaduseta (lihtsalt on antud ette seade X ja temal jookseb keel C) on täielik mõttetus.
C on samasugune relikt, nagu ladina keel. (Teine samasugune relikt olevat Lisp ja neid mõlemat olevat vaja teada tõelise (reaalse) kompuutrihariduse saavutamiseks. Lisp minu lootustes võib olla

ikkagi päris mõistlik keel, kuigi FP keeli on pärast Lispi ohjeldamatult juurde tehtud, üks ikka parem kui teine ...)

Aga C-s võiks selline mõnus masinaläheduse tunne tekkida. Ikkagi viidad (pointerid). Ikkagi käsitsi mäluhaldus. Veel on teada, et C-s on tehtud

Linuxi tuum ja Linuxi muud jupid. Ja see müütiline C kiirus.
Reaalse numbrite jahvatamise jaoks millegipärast aga endiselt kasutatakse FOTRANI. Nii et see ka on vist müüt.
Minu jaoks on C kõige suurem tüütus mäluhaldus. Pead väga täpselt teadma, kuhu mälu eraldatakse, milline asi on staatiline ja milline dünaamiline (nõuab vabastust). Jumala eest ära vabasta staatilist mälujuppi (undefined käitumine, üks hullemaid turvaõudusi turvaspetside jaoks).
Otse uskumatult paljude ilmselgete vigade korral kompilaator on C -s kõigega rahul ja paljude asjade puhul lihtsalt spämmib. Kui siia veel mingid automaatvahendid lisada, siis saab otsatu hulga mõttetut kisa ja mõne teate, mis jällegi on VÄGA TÄHTIS (selle peale programm jookseb pange).

näide (siin ma taplen html tagidega ja lihtsustasin oma mure väiksema märgi ärajätmisega...)
for(int i; i on väiksem kui 10; i++) mingi kood;  

Kompilaatori jaoks ei ole siin miskit viga, kõik on hästi ja nii 75% juhtudel ongi kõik OK. Avastad selle trükivea aga sellest (i= 0 on puudu), et mõnikord jälle see programmi jupike ei tee midagi (endal kogetud nähtumus) ja enamasti teeb täpselt seda, mida vaja.

Kultuslik ++ operaator on tegelikult paljude vigade allikas ja seda tuleks mingi teise tegevusega KOOS tehes igal juhul vältida. Kõik sellised imelikud asjad, nagu i = v[i++] ongi imelikud.

ja veel vähem on vaja raisata aega selle peale, kas kasutada ++i; või i++.

Ei ole try-d ja väga sageli veateate asemel sülitatakse sulle välja segmentation fault, kui ei ole idiootsuseni järjekindel igasuguste NULL-ide (nullviit) käsitlemisel.

Ei soovita mingil juhul algajatele ja edasijõudnutele ka ikkagi siis, kui paistab mingi vajadus.

(robotid, IOT etc...).

C fännid teevad sageli kõike vastupidi Pythoni Zen-is öeldule ja on selle üle isegi uhked.

Näiteks seesama ++ on sünnitanud haiglase maania kõiki asju ühele reale sur(a)uda. Siis on kõik super hästi, kui ühe reaga hakkama saab.

Kahe vana dinosauruse LISP ja C vahel olevat kunagi ammu, nii täna 25 ja enam aastat tagasi käinud kõva lahing. Ja seda lahingut, umbes nagu Maratoni väljal toimunut, on nooremal põlvkonnal ehk vaja siiski teada.

Sellest selle jutu pealkiri, sest see peegeldab väga hästi C-st tulnud (ja võitnud) suhtumist, mis on meile pärandunud ja millest vähemalt selle kõige räigemates variantides on vaja lõpuks vabaneda.

Vähemasti võiks ajalugu korduda ja anda LISP-le või sellest pärandunud suhtumisele uue võimaluse.

Pealkirja või meemi tekitas aga Richard P. Gabriel,
vt. http://dreamsongs.com/RiseOfWorseIsBetter.html, kus on ka tema järgnevatele kirjutistele viited. Aga esialgne meem on kirjas http://dreamsongs.com/WIB.html

Siin on kirjas rohkemgi, mitte ainult arvutiasjanduse ajaloolasele, vaid ka praegusele fännile oleks tegelikult huvitav uurida, kuhu kadus LISP -i „hea seis”, millele Richard Gabriel viitas originaalartiklis aastast 1991, kusjuures see ei puudutanud ärilist edu - see paraku vist jäigi unistuseks? Ja juba siis kuulutas Gabriel LISP-le kadu, ühtlasi tuues esile C/ C++ ... tollal tulevase / praegu olemasoleva võidu põhjused. C/C++ all tähistan kõik järgnenud OO keeli, mitte ainult konkreetselt neid keeli.

Gabriel ristis kahe koolkonna hoiakud järgmiselt:

I hoiaku kandjad olid-elasid MIT / Stanford ülikoolides ja nende ühisnimetajaks sai

„Tee õiget asja!” („The Right Thing”)

II hoiak sai Gabrielilit märgise „Halvem on parem” „Worse is Better”.

ja nende pesitsupaigaks oli New Jersey...

See silt oli erakordselt hästi õnnestunud ja on tänaseni Unixi lipukirjaks, umbes samamoodi nagu „goto kuulutatud kahjulikuks ...mdx mitte ainult Unixi ... ka kõik agiilsed arendajad lehvitavad agaralt seda lippu...Kui mingi asi väga sügavalt pange läheb, siis ilmuvad välja arendajad, kes ütlevad, et kogu viga oli selles, et ei olevat oldud piisavalt agiilne. Aga siin ma lihtsalt teritan hambaid, ma ei ole agiilse ega mitteagiilse arenduse mitte väga suur ekspert.

Artiklis käsitleti programmide erinevaid häid omadusi vaid VEIDI (veidi!) erinevate rõhuasetustega. Hoolimata sellest sai sellest veelahe, mis, nagu ma arvan, tuleb ühel ilusal päeval jälle ületada.

I Tee õiget asja programmeerijad lähtuvad (väidetavalt, sest tegemist on siiski vaid idealisatsiooniga) järgmistest headest omadustest:
Lihtsus -- programmi arhitektuur peab olema lhtne, nii teostuselt kui ka liidestuselt. (implementation, interface). Selle juures on TÄHTSAM liidese lihtsus, mitte teostuse lihtsus. (minu rõhutus ja eelistus, sest seda näeb kasutaja!).

Korrektsus - programm peab olema korrektne KÕIKIDES jälgitavates aspektides. // märkus - ilmselge võimatus ja võimatu on ka tõestada seda, et programm on korrektne. Sellest hoolimata on see ilus põhimõte, eks.

Konsistentsus - programm ei tohi olla mittekonsistentne. Programmil on lubatud olla natukene vähem lihtne (minu rõhutus) ja natukene vähem täielik, et vältida mittekonsistentsust. // aga see on ka kõige hämaram punkt, kõigest hoolimata meeldib mulle näiteks mõte, et mõnikord mõni asi ei peagi nii lihtne olema.

Täielikkus - Programm peab käsitlema nõnda palju olulisi olukordi, kui on praktiline. Kõik eeldatatavad juhud (mõistuse piires) peaksid olema kaetud. LIHTSUS EI OLE LUBATUD (jälle minu rõhutus) liigselt täielikkust kahjustades.

Need kõik on väga ilusad põhimõtted muidugi, mida kahjuks on sageli peaaegu võimatu jälgida. Kuid ma tikun endiselt kalduma „Õige asja” jüngriks, sest mingi ideaal peab selles sõnnikulaotamise töös ometi olema? Aga lähme edasi, sest

Richard Gabrielil õnnestus VÄIKESTE (need natukene väikesed järeleandmised!) järeleandmiste kaudu iseloomustada väga hästi ka C/C++/ Unix (ja praegu prevaleeritat tarkvara tegemise filosoofiat). Ok, ta ehitas jah õlgmehikest, aga väga osavalt.

Isegi nii osavalt, et paljud seda artiklit lugenuna tänase päevani ei saa aru, et Richard Gabriel oli tegelikult „Õige asja” jünger. (aga mine sa ikka tea).

II „Halvem on parem” koolkonna (mida Gabriel kutsus New Jersey koolkonnaks - miks - uurige ? ja kommenteerige ...) vaated erinevad ainult NATUKENE ...

Lihtsus - programm peab olema lihtne nii teostuselt kui liideselt. KUID teostuse lihtsus on TÄHTSAM (kõik on minu rõhutused) KUI liidese lihtsus. Lihtsus on programmi kavandamise kõige tähtsam kaalutlus.
Korrektsus - Programm peab olema korrektne kõikides jälgitavates aspektides.
AGA: Pisut parem on olla lihtne, kui korrektne.

[ see siin on minu targutus: Näiteks kui programm mingitel väga erilistel tingimustel jookseb pange, aga neid erilisi tingimusi väga ei teki, siis on lihtsam parem]

Konsistentsus - programm ei tohi olla MITTE LIIGA mittekonsistentne. Konsistentsuse võib mõnikord ohverdada lihtsuse nimel mõningatel juhtudel, aga veel parem on heita kavandist kõrvale vähem ettetulevad vajadused, kui lisada teostusele keerukust või liidesele mittekonsistentsust.

[ Siin ma natuke nõustun. Ju siis on tarkvaraga askeldamine mõne aastaga mind natukene kainestanud ... aga alati on ... põrgutee sillutatud heade kavatsustega, seda nii „ÕIGE ASJA” kui ka „HALVEM ON PAREM” leeris]

Täielikkus [siin on eriklausleid eriti palju välja toodud.]

Programm peab käsitlema nii palju olulisi olukordi, kui on PRAKTILINE.

Kõik mõistlikult eeldatavad juhud võiksid olla kaetud.
AGA: täielikkuse võib ohverdada iga teise kvaliteedi kasuks. Alati tuleb täielikkus ohverdada, kui lihtsus satub löögi alla. Konsistentsuse võib aga ohverdada täielikkuse nimel [??? ei saa aru, ilmselt on mingid manuaalid lugemata]
Aga: eriti mõttetu on LIIDESE konsistentsus.

Ok, jätame 1991 konstrueeritud New Jersey õlgmehikese detailsed vaated programmide kavandamisele veidikeseks kõrvale, sest Gabriel suutis üllatavalt hästi välja tuua põhjused, miks natukene üle jala laastes saab natukene edukama programmi kirjutada. ...

C ja Unix levisid hästi, sest C kompilaatoreid oli lihtne kirjutada. Unix jooksis (ja jookseb) hästi igasuguste asjade (just asjade, incl. pesumasin) peal. Ta täidab 50-80% kasutajate ootusi.

C ja Unix levisid kui viirused ja harjutasid kasutajad üllatavalt kiiresti mõttega, et paremini ei olegi võimalik. / DOS läks siit veel sammukese kaugemale. Apple vahest ehk suutis mingil hetkel üritada „Õiget asja teha”...

Aga alguses ei olegi vaja kõike õieti teha. Kui „viirus” on kirjutatud siiski hästi, saab viirusele kirjutada uusi versioone ja varsti täidab tarkvara 90%-liselt kasutaja ootusi.

Rohkemat aga kasutajad ei saa iialgi. / aga ka „õige asja” tegijad ei saa kunagi valmis üle 90% -list asja.

Kui õlgmehikene C/C++ on veel kujutatud natukene paksudes värvides, siis „õige asja” tegijad hm.

Gabrieli järgi ei saa mitte iialgi mitte ühtegi asja valmis. Või lihvivad kroonijuveeli lõputult.
Ei saa jätta torkimata - näiteks programmeermiskeskkonda nimega Haskell (kuhu lõpuks saadi külge igasugused huvitavad asjad, ok, aga ohverdati LISP, mis võib-olla oleks 90-ndatel suutnud läbi lüüa õigemini „õiget asja” tehes....
Mdx, vahepeal andis lootusi ju Scala ja ühel ilusal päeval tuleb tuli tuha alt jälle välja ja vana LISP C võitluse elavneb uutes kuubedes kujul mingi eriline funktsionaalkeel / mingi ülimoodne uuskeel

25 aastat hiljem on programmeerimise paradigmades aga siiski toimumas muutused.

„Halvem on parem” stiilis saadi valmis Internet ja see osutus väga edukaks projektiks. Sellest hoolimata on „halvem on parem” alustus tinginud Internetis väga paljude asjade põhjaliku ümberkirjutuse ja sageli on esialgset disaini teadmata väga raske aru saada, miks selles internetis asjad ikkagi nii keeruliselt / ja ümber nurga käivad ...

Kasutajad on hakanud programmidelt rohkem nõudma. Enam ei olda rahul sellega, et mõnikord on võimalik korrektsuses nii natukene ohverdada - turvanõuded ei lase seda teha.

Seetõttu on puugiste programmide juurde tekkinud testijad, google on pannud kodeerijad ise oma koodi testima ja tõstnud TESTIJAD kõrgemale tavakodeerijast (tavakodeerijat testiteenuse kavandamise juurde ei lastagi, aga musta töö, automaatestimise, teeb iga kodeerija ise), igasuguste veidrate programmerimiskeelte juurde on siginenud igat sorti veel veidramad töövahendid, mis püüavad xxx saia teha, näiteks C-s lisades igasuguseid const -märgendeid (mille peale Pythoni sellid ütlevad, et kui mingi asi on const, siis las ta olla konstant ja FP fännid ütlevad, et neil ongi iga asi const ja milleks sellega programmi koodi risustada) või mõõta

testimisel McCabe indeksit ja ajada see alla 10.

Kasutajal ei ole sellest sooja ega külma, küll meeldib kasutajatele JUST LIIDESE konsistentsus ja programmi konsistenstused ja muud hädad jätavad ta täiesti ükskõikseks.

Aga üldine mõte võiks olla ebaturvalised ja vanad keeled ühel hetkel ehk kõrvale lükata ja hakata

kasutama selliseid, kust puugiseid probleeme ei ole nii palju.

Ja veel üldisem mõte võiks olla „Õige asja” põhimõtted jälle vähemalt kusagile käsulaudadele üles kirjutada ja vähemalt mingis ideaalis püüda neid jälle järgida.

Mis on saanud 25 aasta jooksul „halvem on parem” põhimõtetest?

viitan siin https://spin.atomicobject.com/2015/01/12/worse-is-better-vs-right-thing/

toodule. kipaka maja pilt pärineb ka sealt.

halvem on paremast on saanud „halvem ja halvem”.

Terve põlvkond programmeerijad (incl me, 25 aastat tagasi olin puhastverd füüsik, episooodilised kodeerimisepuhangud on vaheldunud arvutite administreerimisega) on üles kasvanud nii, et nad isegi ei aima, mis asi on IDEAAL. Nad lihtsalt ei tea, mis asi on „ÕIGE”.

Ma ei ole siin väga nõus küll sellega, et suurfirmad on „Õige” asjaga oma „Halvem on parem” asja asendanud, aga õigemaks on aetud asja küll. DOS (ja eriti BAT!) oli katastroof. Selles sai mõistlikum WindowsNt ja edasi uuemad windows-id, kus kogu aeg pendel „halvem on parem” ja „õigema” vahet käib ... Niisiis on „Õiget” asja hakatud siiski siin ja seal ajama.

Aga laiatarbetarkvara suhtes ... on „halvem on parem” seltskond asendanud

lihtsalt „laisa” (lazy, see on lööksõna programmeerijatele ja kohutavalt HEA ASI)

lähenemisega. Ja ei olegi võimalik teisiti, kui ei ole selge, mis asi on see

„halvem on parem” ja misasi „õige” ja millest üldse jutt käib, kui räägitakse konsistentsusest ...

Minu arvates on üks päris õnnestunud teema, milles on senini tegelikult tehtud Õiget asja.

Selliseks „õigeks” asjaks on olnud SQL ja lõpuks on see asi saanud ka isegi päris valmis - seda kasutatakse, see toimib ja ime küll, sellest on üllatavalt raske lahti saada.

Aga praegune Mongode ja sarnaste pealetung otsustab selle „õige asja” saatuse.

Kui siin „halvem on parem” lähenemine jälle võidab, lendab see umbes 40 aasta jooksul valmisnikerdatud „õige asi” nelja tuule poole ja mitmes kohas tuleb äkki jälle otsast alustada?

Samas on maailm astunud edasi. AI on lõpuks hakanud mingeid vilju kandma ja äkki enam

häkkerite variant nii sujuvalt ei õnnestu. SQL on suutnud rünnaku sujuvalt suunata õigele teele - lõpuks on need NoSQL andmebaasid hakanud tunnistama SQLi, õigustused - suured andmemahud

vaikselt ka hääbuvad enamikel juhtudel, sest SQL laagris pingutatakse kõvasti, et nendega toime saada (vaid üle planeedi toimetavatel hiiglastel on niisuured andmemahud, et SQL enam ei käibi ehk) ja kõige selle kõrval saab SQL ka kõvasti paremaks ... ja mõeldakse midagi uut ehk ka välja.

Nii et ma olen selle ühe „õige saare”, „õige asja” suhtes pigem optimist, kuigi see optimism võib põhineda pigem mittekompetentsusel ...

Kui nüüd aga kodeerimise juurest laia maailma pöörduda, siis rämspskapitalism veel ei ole saavutanud oma apogeed. Pigem läheb veel mõni aeg, kui sihikindla rämpsu tootmise asemel hakkab taastekkima normaalse kauba tootmise mõte. Seetõttu on ka pole ka kodeerimises mingeid kiireid muudatusi loota. Ehk nii 15 aasta jooksul jõutakse tasapisi tagasi tarkvara kvaliteedi juurde.
Tõsi on ka küll see, et seda kvaliteeti oli 25 aastat tagasi võimalik palju lihtsamini taga ajada, sest projektid olid palju väiksemad ...

Niipalju siis tarkvara targutust tänasel päeval.