Kādā programmēšanas valodā MI programmēs rītdien?

Ikvienam programmētājam, kas pārvērtis savu MI asistentu par aģentu komandu, kas nenogurstoši būvē kodu, radies jautājums – ja es nebūtu pateicis, ka tas jāveido Node JS vai PHP.. ko MI būtu izvēlējies? Kā efektīvāko veidu, lai risinātu problēmu? Ātrāko veidu? Savietojamāko? Kas ir kritēriji, ja jāizvēlas valoda, kas nav domāta cilvēkam, kur viens no programmēšanas valodas estētiskuma pamatiem ir “lasāmība”?

Vēl tālāk domājot – ja mākslīgais intelekts rakstīs kodu bez tavas līdzdalības, kā veidosies rītdienas programmēšanas valodas? Es nedomāju, ka mums ierastais Python, Rust vai PHP būtu MI izvēle. Intelekts radītu ko savu.. kaut ko kas būtu tam ērts un saderīgs (ar ko?). Fundamentāli cita pieeja, ja vairs nav svarīgi ka tavs kods ir jāspēj lasīt un saprast kādam citam.

Vispirms, ieskats vēsturē

Jā, mums patīk vēsture, jo tikai tā mēs varam salīdzināt zāli zaļāku.

Vēsturiski programmēšanas valodas tika attīstītas lai risinātu to rakstītāju problēmas – cilvēku problēmas.

Piemēram:

• C – efektīva, dzelžiem pielāgota valoda
• Java – Liela mēroga risinājumu (mērogojama) un pārvaldāma valoda (nejaukt ar JavaScript)
• Python – Salasāma, saprotama, zinātniekiem sausiņiem perfekcionistiem domāta, taču izrādījās derīga arī webam – Django, Flask.. nekompilējama, lēna.
• JavaScript – Interaktīvs kods, fragmentāriem iespraudumiem mājaslapās, kas izauga līdz serveru puses bibliotēkām un platformām. Iedvesmas avots visiem Taipskriptiem, Swiftiem..
• Haskell – Matemātiķu prefekcionisma, abstrakcijas un mākslas forma, principā avangards
• Rust – Atmiņas drošs, performējošs risinājums noslogotām serveru aplikācijām. Rets gadījums, kad tirgus diktēja prasības.
• Lisp – Metaprogrammēšanas meistardarbs, kas ir funkcionāls, sarežģīti lasāms un jūs jau nojaušat, mans iedvesmas avots rītdienas valodai.

Ja nu kāds lasot šo sarakstu pamanīja, praktiski visas valodas ir radītas ap izstrādātāju un atbild uz jautājumu, kā piemēram, cik ērti rakstīt un saprast kodu, cik ātri vai eleganti to var uzrakstīt, vai šo kodu varēs apkalpot un saprast arī pēc 10 gadiem? Iedomājamies mašīnu sarakstītu kodu, ko mums pēc 10 gadiem jāsaprot. Un jau pēc gada mašīnas rakstīs, iespējams, 99% no visa koda.

Kā izskatīsies mašīnu veidota programmēšanas valoda?

Pēc sarunām ar MI un zināmu piespiešanu pārrakstīt lietas piecas reizes, ietaupot pa rindiņai, varu pieņemt, ka rītdienas programmēšanas valodu ietekmēs sekojoši faktori:

1. Konteksts un nozīme pāri instrukcijai

Šodien vēl aizvien daļa no mums promptē, jeb saka datoram kā tieši lietas ir jāizdara. Piemērs ar Python:

def calculate_discount(price, discount):
    return price * (1 - discount)

Šī vietā mašīna izvēlētos ko savādāku:

function calculate_discount:
    input: price, discount
    output: price after applying discount

    constraints:
        0 <= discount <= 1
        result >= 0

    guarantee:
        result = price * (1 - discount)

Ievērojāt atšķirību? Netiek aprakstīts funkcijas iznākums, bet gan sagaidāmais rezultāts un ierobežojumi. Šis noteikti uzlabotu koda drošību un sistēmas stabilitāti.

2. Datu tipi kas saprot to nozīmi

Esam pieraduši definēt mainīgo ar datu tipu vai arī pa slinko uzreiz ar vērtību. Šodien klasiski pazīstam “Integer”, “String”, “Boolean”, “Array”, “Object” un līdzīgus, kā nu kurā valodā apzīmētus datu tipus. Taču rītdienas programmēšanas valodā mākslīgais intelekts neaprobežosies ar sausu definējumu.

type Email = String where valid_email(value)

type Money = Decimal {
    currency: ISO4217
}

type UserAge = Integer where 0 <= value <= 150

Jūs jau paredzat laimīgo kompilatoru, kas uzreiz pamanīs ne tikai datu tipa neatbilstību, bet arī formātu, robežas un biznesa loģikas neatbilstību. Lietas būtu pamatīgākas.

3. Pareizība ir svarīgāka par sintaksi

Te droši vien jāpaskaidro, ko domāju ar “pareizība”. Šī varētu būt viena no lielākajām izmaiņām, jo šobrīd programmētāji raksta kodu un tad laiž testus, lai pārbaudītu vai viss strādā, ko “izmet”. Jau rakstot funkciju un paredzot tās saņemamos parametrus – mainīgos, mēs varam novērtēt to “pareizību”, piemēram:

function transfer_money(
    from: Account,
    to: Account,
    amount: Money
)
requires:
    amount > 0
    from.balance >= amount

ensures:
    from.balance' = from.balance - amount
    to.balance' = to.balance + amount
    total_balance' = total_balance

Šis kods savā “pareizībā” ir tuvāks specenei, nekā funkcijai. Veidojot kodu jau tiek iebūvēta satura parametru pārbaude, atbilstība prasībām. Protams, mēs zinām, ka “ārējā pasaule” un “lietotāji” pamanās “iebarot” lietas, kas mums sapņos nerādās, taču šis tāpat ir solis pretī stabilām viegli nenograujamām lietām.

4. Kontrolēts pašmodificējošs kods

Jā, šis virsraksts nāca grūti. Tāpēc tā arī skan. Te mēs nonākam pie manis pieminētā Lisp. Lisp valoda (zinu, sena, bet tu pastudē to zvēru intereses pēc) atļauj programmām ģenerēt un mainīt kodu. Mākslīgais intelekts kā minimums radīs transformējošu kodu.

Iedomājies MI sistēmu, kas:

• Analizē savu performanci
• Identificē neefektīvas komponentes – lēnas, atmiņu, vietu ēdošas
• Reālā laikā veido alternatīvas komponentes un salīdzina tās
• Testē ar reāliem datiem tuviem datiem nepieciešamā apjomā
• Publicē uzlabotas komponentes, kamēr visa sistēma ir bezversiju

Šāda programmatūra ir “dzīva”. Rīt būs labāka, nekā šodien. Ar visu to ir jānodrošina kaut kāda versionēšana un cilvēka vai MI iniciēti rollbeki. Taču visa tā koda evolūcijas padarīšana ir autonoma. Pilnībā.

5. Visbeidzot, mērķa vide

Es ticu, ka rītdienas programmēšanas valoda un kodētie risinājumi būs tādi, kas vienīdz labi skries uz CPU, uz GPU, mākonī vai lokālā datorā, pārlūkā datorā vai mobilajā tālrunī. Tas varētu būt visai unikāls kompilators, kuram mēs vismazāk saprastu, kas notiek lācītim vēderā. Tam visam pāri datu tipi, permisijas, privilēģijas, autonoma un cilvēku saskarne. Viss viss vienā.

Pēc kā tad tā izskatītos?

Amizanti, bet dažām no mūslaiku programmēšanas valodām ir iedīgļi – elementi, kas var būt par pamatu:

• Lisp – pati ideja, ka kods ir dati. Nenovērtētas metaprogrammēšanas iespējas.
• Rust – lieliska datu tipu sistēma un resursa, atmiņas kontrole. Inženierprodukts.
• Swift – Optional. Saņemta mainīgā vērtība, kas var būt un var nebūt derīga izmantošanai.
• Haskell – Funkcionālā tīrība, abstrakcijas. Jo vairāk MI būs ne vien ģenerējošs, bet matemātisks, jo precīzāk un matemātiskāk aprakstāma vide, pasaule un dabas parādības.
• Lean – Integrēti formāli pierādījumi. Meistarklase precīzu risinājumu radīšanā.

Izaicinājums nav jaunas valodas izveide, lai mēs cilvēki vēl pēdējiem spēkiem noturētu kontroli pār koda evolūciju. Mēs varam noteikt likumus mijiedarbībai starp programmatūru un tās uzdevumu, saderības pamatus, mēramu rezultātu.

Šodien mēs strādājam šādi:

Prasības → Izstrādātājs → Kods → Testēšana → Ilgtermiņā uzturēta programmatūra

Rītdien tas varētu būt šādi:

Nolūks → MI → Formāla specifikācija → Novērtēta implementācija → Ilgstoši uzturēta programmatūra

Jebkurā gadījumā mēs no koderiem saprotama prieka par jaunu “elegantu” programmu ejam uz ko citu – valodu, kas tiks optimizēta, lai saturētu nolūku un sargātu (“guard” Swift valodā) sagaidāmo rezultātu tā vietā lai būtu vienkārši funkciju saraksts un kā atceramies onkuli Bobu sakām katrai funkcijai ir jādara tikai viena lieta. Transformējošs dzīvs kods saglabātas versijas vietā – tā ir īsta revolūcija.

p.s. raksta tapšanā ir izmantots mākslīgais intelekts; loģiski.