Miért lesz mindig szükségünk új programozási nyelvekre?

Harold Abelson és Gerald Jay Sussman számítógépes programok felépítése és értelmezése az egyik legjobb programozással foglalkozó könyv, amit valaha írtak. Hosszú évekig megelőzte korát.

A funkcionális programozás előnyei, amelyekre rávilágítottak, továbbra is állandó inspirációs forrást jelentenek az előadók, a tanárok és más írók számára. Megmutatta az objektum-orientált programozás erejét és hibáit, amikor még fiatal volt. Az erők az objektumorientált programozási fanatikusoknak köszönhetően gyorsan hirdetettek. Másrészt évekbe telt, mire a közösség meglátta a hibákat.

Az utolsó fejezetet teljes egészében egy másik koncepciónak szentelték, amelyet a népi párbeszédben még mindig nem nagyon tárgyalnak: az új programozási nyelvek szükségességére. Annak ellenére, hogy a könyv szimpatizált Lisppel, egyértelműen azt állította, hogy ez nem a végső programnyelv. Soha nem lesz nyelv.

Mindig új programozási nyelvekre lesz szükségünk kifejezőképességünk javításához. Ez nem triviális kijelentés, és ahhoz, hogy megértsük, mi áll mögötte, két szinttel lejjebb kell mennünk.

Mi a programozási nyelv?

Lásd a következő funkciót:

fun square(a: Int) = a * a
// Usageprint(square(10) + square(20))

Mit jelent, hogy squaremeghatározzák?

Műszaki szempontból ez csak egyszerűsítés, és a test minden hívást helyettesíthet:

// Kotlinprint(10 * 10 + 20 * 20)

A programozó szempontjából squaresokkal több. Az a tény, hogy definiálhatunk egy ilyen függvényt, nemcsak egy művelet végrehajtásának egyszerűbb módja, hanem lehetővé teszi számunkra a négyzet fogalmának kifejezését is. Ez a funkció némi absztrakció.

Ha összetettebb lenne, lehetővé tenné számunkra, hogy ezt a bonyolultságot egy egyszerű függvényhívás mögé rejtsük. Ez az, ami a programozás: A különböző programozási nyelvi jellemzők lehetővé teszik számunkra a dolgok különböző módon történő kifejezését.

A programozási nyelvek alakulása

A programozási ipar fejlődik, és így a programozási nyelvek is. Gondoljon a for-loop-ra. Kezdetben csak mikor-hurok volt.

Hamarosan a programozók észrevettek egy közös mintát:

// Cint i = 0;while(i < n) { i++; // ...} 

A whilekifejezést újra és újra alkalmazták valamin - többnyire számokon, címeken vagy iterátorokon - történő ismétléshez.

Tehát bevezettük a for-ciklusokat:

// C++for (int i = 0; i < n; i++) { // ...}

Hamarosan az ipar felfigyelt arra, hogy a for-ciklust főleg a listán szereplő elemek ismétlésére használják.

Ezért a nyelvek a for-loop új változatát vezették be, amelynek célja az ismétlés list:

// Kotlinfor(e in list) { // ...}

Tehát új funkciókra van szükségünk

De a nyelvek fejlődnek, miért nem ragaszkodnak hozzájuk?

Igaz, hogy a nyelvek fejlődnek. Bizonyos esetekben igazán lenyűgöző, hogy az olyan régi nyelvek, mint a C ++, a Java vagy a JavaScript, képesek-e jó támogatást nyújtani azokhoz a funkcionális programozási elemekhez, amelyekhez nem készültek. De a probléma az, hogy az új funkciók nem helyettesítik a régieket, hanem kiegészítik őket.

A programozási nyelv tulajdonságait tekintve a több nem feltétlenül jobb. Zavaró, amikor ugyanazt a koncepciót sokféleképpen tudjuk kifejezni.

Gondoljunk csak Scalára. A Scala legnagyobb kifogása az, hogy a túl sok különféle funkció miatt rendkívül nehéz megérteni, mi folyik egy kicsit túl sok kreativitással rendelkező fejlesztő kódjában.

A Go programozási nyelv az egyszerűségre építette népszerűségét. Nem arról van szó, hogy egyes nyelvek hány funkcióval rendelkeznek, hanem arról, hogy tökéletes tulajdonságokkal rendelkeznek.

Véleményem szerint ezért szereti mindenki annyira Kotlint. Ez a legjobban megtervezett programozási nyelv, amit ismerek.

Ennek komoly okai vannak:

  • 6 évig volt bétaverzióban, és iteratívan fejlődött az egész idő alatt
  • JetBrains tervezte, akik évek óta elsajátítják a programozási nyelvek megértését és az emberek használatát

A béta periódus alatt néhány fontos funkció teljesen megvalósult, és mégis eltávolították őket az 1.0 előtt. Közöttük vannak tincsek. Kotlin teljes mértékben támogatta őket! Mégis, a Kotlin csapata eltávolította a tinták támogatását a Kotlin 1.0 előtt, mert elemzésük és kísérleteik azt mutatták, hogy a tincs több kárt okoz, mint hasznot, és az embereknek inkább adatosztályokat kell használniuk. Ez azt mutatja, hogy a JetBrains megérti a jó tervezés fontosságát.

Egy másik jól megtervezett nyelv a Swift. Sokkal gyorsabban fejlesztették, és az azt tervező fejlesztők sok hibát követtek el. Mégis, az Apple csaknem minden nagyobb verzió kiadásával megváltoztatta a dizájnt. Az örökség nem igazán érdekli őket.

A fejlesztők morognak, de tervezési szempontból nagyon jó. Bár ezt sokáig nem folytathatják. Minél több dolog van a Swiftben, annál nagyobb a tervezés változásának költsége. Ezenkívül nem hiszem, hogy képesek megváltoztatni a főbb funkciókat.

Tehát, ha jól megtervezett új nyelveink vannak, akkor ezek a végső nyelvek?

Egyáltalán nem. Az iparágak fejlődnek. Gondolkodásunk fejlődik. Ezért a programozási nyelveknek is fejlődniük kell.

Egy dolog az, hogy új funkciókra és gondolkodásmódra vonatkozó ötletek születnek, és így a tökéletesen megtervezett nyelvek már nem lesznek tökéletesek.

A második dolog az, hogy többet megtudunk a programozásról. Az osztályok és módszerek alapértelmezés szerint nyitottak a Java-ban. Kotlin alapértelmezés szerint véglegessé tette mindkettőt, mert a fejlesztők túlzottan túlhasználták az öröklést, amikor nem kellett volna.

A Java osztály tagjai alapértelmezés szerint csomag-magának voltak. Ezt a módosítót szinte soha nem használták. Kotlin egyáltalán nem engedélyezi, de az osztály tagjai alapértelmezés szerint nyilvánosak, mert ez a leggyakoribb módosító számukra. Megváltoztatjuk szokásainkat és tanulunk, így a nyelveknek is változnia kell velünk.

A harmadik dolog az, hogy a paradigmák változnak. Stagnálást látok a programozási paradigmák szempontjából, de van még néhány, amit be kell vezetnünk a mindennapi gyakorlatba.

Hová lett a logikai programozás? Figyelje meg, hogy használhatja ezt a paradigmát, és csak korlátozásokat adhat meg egy webhely számára, és elvárhatja, hogy a webhely automatikusan ezek alapján épüljön fel. Ennek megvalósítása lehetséges. Emellett előbb-utóbb új paradigmák születnek. Nem lehet, hogy mindent felderítettünk.

Végül új technológiák születnek, és a régi gondolkodásmód, amelyet az előző nyelvek képviselnek, nem biztos, hogy megfelelő.

Gondolj a blokkláncra. Amikor olyan emberekkel beszélek, akik fontolóra veszik a váltást, kedvenc nyelvüket akarják használni, például a Java-t vagy a JavaScript-et. Bár amikor blokklánc-fejlesztőkkel beszélgetek, azt állítják, hogy a blokkláncot olyan nyelveken kell fejleszteni, amelyeket erre terveztek.

Például a szerződés olyan fogalom, amelynek nincs megfelelője a programozásban. Szimulálható osztályonként, de ez káros az emberek gondolkodásmódjára. Káros, amikor új dolgokat próbálunk kifejezni régi szavakkal. Olyan ez, mint ha egy autót „acéllónak” nevezünk, és állatorvosokból próbálunk mechanikát készíteni.

Záró

Gondoljunk a matematikára. Az egyensúly leírható módon fejezhető ki:

Kettő plusz három egyenlő öt

Bár ez valami egészen más, mint a matematikai jelöléssel történő kifejezése:

2 + 3 = 5

Nem ez az egyetlen optimalizálás az olvashatóság és a tér számára. Ez a két jelölés ugyanazt jelenti, de teljesen különböző fogalmakat képviselnek. Ez egy olyan dolog, ami a számítógép szempontjából nem fontos - ami könnyen le tudja alakítani a leíró formát matematikává -, de nekünk, embereknek ez a legfontosabb.

Ha ez nem lenne fontos, akkor Java, JavaScript, Python vagy Kotlin helyett az Assemblert üzemeltetnénk. De fontos. Ezért van szükségünk egyre jobb kifejezésre, és új programozási nyelvekre van szükségünk.

A szerzőről

Marcin Moskała (@marcinmoskala) tréner és tanácsadó, jelenleg arra koncentrál, hogy Kotlin-t adjon Android és fejlett Kotlin műhelyekben (további részletekért itt jelentkezhet). Beszélő, cikkek és egy könyv az Android fejlesztéséről Kotlinban.