Zašto će nam uvijek biti potrebni novi programski jezici

Struktura i interpretacija računalnih programa Harolda Abelsona i Geralda Jaya Sussmana jedna je od najboljih knjiga o programiranju ikad napisanih. Bilo je ispred svog vremena dugi niz godina.

Prednosti funkcionalnog programiranja koje su istaknute i dalje su neprestani izvor nadahnuća za govornike, učitelje i druge pisce. Pokazao je snagu i mane objektno orijentiranog programiranja dok je još bio mlad. Moći se brzo oglašavaju zahvaljujući fanaticima objektno orijentiranog programiranja. S druge strane, trebale su godine da zajednica uvidi nedostatke.

Posljednje je poglavlje u potpunosti bilo posvećeno još jednom konceptu o kojem se još uvijek ne govori puno u popularnom dijalogu: potrebi za novim programskim jezicima. Iako je knjiga simpatizirala Lispa, očito je tvrdila da to nije konačni programski jezik. Nijedan jezik nikada neće biti.

Uvijek će nam trebati novi programski jezici kako bismo poboljšali našu izražajnost. Ovo nije trivijalna izjava, a da bismo razumjeli što stoji iza toga, moramo se spustiti dvije razine dolje.

Što je programski jezik?

Pogledajte sljedeću funkciju:

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

Što znači squaredefinirano?

S tehničkog gledišta, to je samo pojednostavljenje i tijelo može zamijeniti sve pozive:

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

S gledišta programera, squaremnogo je više. Činjenica da možemo definirati takvu funkciju nije samo jednostavniji način izvođenja operacije, već nam omogućuje i izražavanje koncepta kvadriranja. Ova je funkcija neka apstrakcija.

Da je složeniji, omogućio bi nam da sakrijemo svu tu složenost iza jednostavnog poziva funkcije. To je ono što je programiranje: različite značajke programskog jezika omogućuju nam da stvari izrazimo na različite načine.

Evolucija programskih jezika

Programska industrija se razvija, a tako se razvijaju i programski jezici. Razmislite o for-loop. U početku je postojala samo petlja kada.

Uskoro su programeri primijetili uobičajeni obrazac:

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

whileIzraz je i opet se koristi za prolazak kroz nešto - uglavnom brojeve, adrese ili iterators.

Tako smo uveli for-petlje:

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

Ubrzo je industrija primijetila da se for-loop uglavnom koristi za prevrtanje elemenata s popisa.

Zbog toga su jezici predstavili novu varijantu for-loop koja je dizajnirana za ponavljanje list:

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

Dakle, potrebne su nam nove značajke

Ali jezici se razvijaju, zašto se ne bi držali njih?

Istina je da se jezici razvijaju. U nekim je slučajevima doista impresivno kako stari jezici poput C ++, Java ili JavaScript mogu imati dobru podršku za funkcionalne programske elemente za koje nisu dizajnirani. Ali problem je što nove značajke ne zamjenjuju stare - već se dodaju.

Što se tiče značajki programskog jezika, više nije nužno i bolje. Zbunjujuće je kad isti koncept možemo izraziti na mnogo različitih načina.

Sjetite se Scale. Najveća zamjerka Scali jest što previše različitih značajki izuzetno otežava razumijevanje što se događa u kodu programera s malo previše kreativnosti.

Programski jezik Go svoju je popularnost gradio na jednostavnosti. Ne radi se o tome koliko značajki imaju neki jezici, već o tome da imaju savršen skup značajki.

Po mom mišljenju, zato svi toliko vole Kotlina. To je najbolje osmišljen programski jezik koji znam.

Postoje snažni razlozi za to:

  • Bio je u beta verziji 6 godina i razvijao se iterativno kroz cijelo to vrijeme
  • Dizajnirali su ga JetBrains koji već godinama savladavaju svoje razumijevanje programskih jezika i načina na koji ih ljudi koriste

Tijekom beta razdoblja, neke su važne značajke u potpunosti implementirane, a ipak su uklonjene prije 1.0. Među njima su i korice. Kotlin ih je u potpunosti podržao! Ipak, tim iz Kotlina uklonio je podršku za torte prije Kotlina 1.0 jer su njihove analize i eksperimenti pokazali da korice čine više štete nego koristi, a ljudi bi umjesto toga trebali koristiti klase podataka. To pokazuje da JetBrains razumije važnost dobrog dizajna.

Još jedan jezik koji je dobro dizajniran je Swift. Razvijen je puno brže, a programeri koji su ga dizajnirali napravili su puno pogrešaka. Ipak, Apple je upravo promijenio dizajn gotovo sa svim glavnim izdanjima. Njih zapravo nije briga za nasljeđe.

Programeri gunđaju, ali s gledišta dizajna to je sjajno. Iako to ne mogu dugo raditi. Što je više stvari u Swiftu, to su troškovi promjene dizajna veći. Također, mislim da nisu u stanju promijeniti glavne funkcionalnosti.

Pa ako imamo dobro osmišljene nove jezike, jesu li to konačni jezici?

Nikako. Industrije se razvijaju. Naše razmišljanje evoluira. I tako se moraju razvijati i programski jezici.

Jedno je što će se roditi ideje za nove značajke i načine razmišljanja, pa tako savršeno dizajnirani jezici više neće biti savršeni.

Druga stvar je da naučimo više o programiranju. Predavanja i metode otvorene su prema zadanim postavkama u Javi. Kotlin ih je oboje konačno učinio konačnima jer su programeri jako pretjerali s nasljeđivanjem kad nisu trebali.

Članovi Java klase prema zadanim su postavkama bili privatni u paketu. Ovaj modifikator gotovo nikada nije korišten. Kotlin to uopće ne dopušta, ali umjesto toga članovi razreda su prema zadanim postavkama javni, jer je ovo najčešći modifikator za njih. Mijenjamo navike i učimo, pa bi se i jezici trebali mijenjati s nama.

Treća stvar je da se paradigme mijenjaju. Vidim stagnaciju u smislu programskih paradigmi, ali još uvijek moramo neke uvesti u svakodnevnu praksu.

Gdje je nestalo logičko programiranje? Primijetite da možete koristiti ovu paradigmu i samo pružiti skup ograničenja za web mjesto i očekivati ​​da će se web mjesto automatski graditi na temelju njih. To je moguće provesti. Također, prije ili kasnije će se roditi nove paradigme. Ne može biti da smo sve istražili.

Konačno, rađaju se nove tehnologije i stari način razmišljanja koji predstavljaju prethodni jezici možda neće biti primjeren.

Razmislite o blockchainu. Kad razgovaram s ljudima koji razmišljaju o prebacivanju, žele koristiti svoje omiljene jezike poput Jave ili JavaScript-a. Iako kad razgovaram s programerima blockchaina, oni tvrde da blockchain treba razvijati na jezicima koji su za to dizajnirani.

Na primjer, ugovor je koncept koji nema ekvivalent u programiranju. Može se simulirati na nastavi, ali to je štetno za način na koji ljudi o tome razmišljaju. Štetno je kad nove stvari pokušavamo izraziti starim riječima. To je poput imenovanja automobila "čeličnim konjem" i pokušaja izrade mehanike od veterinara.

Zatvaranje

Razmislite o matematici. Ravnoteža se može izraziti opisnim putem:

Dva plus tri jednako je pet

Iako je to nešto potpuno drugačije od izražavanja matematičkim zapisom:

2 + 3 = 5

Nije jedina optimizacija za čitljivost i prostor. Te dvije oznake znače isto, ali predstavljaju potpuno različite koncepte. To je nešto što s računala nije važno - što opisni oblik može lako prevesti u matematički - ali nama kao ljudima je najvažnije.

Da nije važno, radili bismo na Assembleru umjesto Jave, JavaScript-a, Pythona ili Kotlina. Ali važno je. Zbog toga su nam potrebni sve bolji izrazi i novi programski jezici.

O autoru

Marcin Moskała (@marcinmoskala) trener je i savjetnik, trenutno se koncentrira na davanje Kotlina u Androidu i naprednim Kotlinovim radionicama (za više detalja prijavite se ovdje). Također je govornik, autor članaka i knjige o razvoju Androida u Kotlinu.