50 HÉT, 50 NYELV

A fejlesztés 2015-ben Andrew Kelley kezdeményezésére indult el, hivatalosan pedig 2016-ban mutatkozott be. A cél egy olyan alacsony szintű rendszernyelv megteremtése volt, amely a C pragmatizmusát megőrizve képes felszámolni annak fél évszázados strukturális és biztonsági hiányosságait.A Zig kifejezett célja a C programozási nyelv kiváltása a modern rendszerszoftverek területén. Ahelyett azonban, hogy a többi nyelvhez hasonlóan komplex absztrakciós rétegeket vezetne be, a Zig a radikális átláthatóságra és a kognitív terhelés csökkentésére törekszik.

Alacsony memórialábnyomának, kiszámítható végrehajtásának és a C ABI-val való közvetlen integrációjának köszönhetően a Zig rendkívül sokrétűen alkalmazható a hardverközeli környezetektől a nagyvállalati infrastruktúráig. Ideális operációsrendszer-kernelek, mikrokontrollerek, beágyazott eszközök, valós idejű játékmotorok, valamint nagy adatátviteli sebességű hálózati és szerveroldali rendszerek fejlesztésére.A nyilvánvaló technológiai előnyök mellett a Zig használata jelenleg több mérnöki és szervezeti kompromisszummal is jár:

• A legmeghatározóbb korlát a nyelv állapota, mert még elég gyorsan fejlődik, változik. Ez azt jelenti, hogy a fordító egyes alverziói között rendszeresek a "kompatibilitástörő" változtatások. Ez komoly karbantartási költséget ró azokra a csapatokra, amelyek aktívan követik a nyelv fejlődését.
• Az ökoszisztéma érettsége szintén kihívást jelent. Noha a beépített csomagkezelő (zig build) funkcionális, a rendelkezésre álló külső könyvtárak, keretrendszerek és segédeszközök választéka jóval szűkebb, mint a több évtizedes C/C++ vagy a kiforrott Rust környezetben. Ezzel összefügg a dokumentáció állapota is: a nyelv gyors ütemű átalakulása miatt az online oktatóanyagok, példakódok és fórumbejegyzések egy része gyorsan elavul, ami megnehezíti a betanulást.

A Zig a modern rendszerszoftver-fejlesztés egyik legérdekesebb kísérlete a hardverközeli programozás megújítására. Ahelyett, hogy nyelvi absztrakciókkal elfedné a számítógép felépítését, tiszta, explicit és determinisztikus eszköztárat kínál a fejlesztőknek. Bár a végleges 1.0-s verzióig hátralévő időszakban az API-változások és a még formálódó könyvtári ökoszisztéma körültekintést igényelnek, a TigerBeetle, a Ghostty és az Uber sikeres ipari projektjei igazolják, hogy a Zig a jövő alacsony szintű infrastruktúrájának meghatározó építőkövévé válhat.

A PowerShell, bár nagyon hasonlít a cmd-re, nem annak továbbfejlesztése, hanem egy attól teljesen független, tiszta lapról tervezett, objektumorientált parancssori környezet és scriptnyelv. A cmd még az MS-DOS-féle COMMAND.COM szövegalapú öröksége, a PowerShell azonban a .NET keretrendszerre épül. Jeffrey Snover, a Microsoft elismert vezető mérnöke, tervezte és vezette a fejlesztést. 2002-ben jelent meg a koncepciót lefektető híres Monad Manifesto dokumentum. Az első hivatalos verzió, a PowerShell 1.0, 2006 novemberében jelent meg.

Megint egy új valami, miért nem volt jó nekik a cmd? 3 fő okot emelnék ki, miért jó, hogy van PowerShell:

• A cmd és a hagyományos Unix shell-ek (pl. Bash) nyers karakterláncokkal dolgoznak. A cmd-ben egy rendszeradat kinyeréséhez törékeny string-vágásokat (regex, findstr) kellett végezni.
• A Windows belső működése (WMI, COM, Registry, .NET) objektumorientált, nem pedig "minden egy szöveges fájl" elvű, mint a Linux. A cmd képtelen volt hatékonyan kezelni ezeket az objektumokat.
• A csővezeték (Pipeline) forradalma: A PowerShell "csővezetékében" (|) nem szöveg, hanem élő .NET objektumok áramlanak a parancsok (cmdlet-ek) között, megőrizve az adatok típusát, tulajdonságait és metódusait.

A PowerShell rengeteg mindenre jó.

• Rendszer- és infrastruktúrabeli automatizációkra, mint pl.: Windows Server, Active Directory, Exchange, IIS, Hyper-V teljes körű felügyelete.
• Használhatjuk a manapság oly menő felhős dolgokra: Az Azure és AWS infrastruktúrák natív modulokkal vezérelhetőek.
• Cross-platform feladatokra is tökéletes, mert a PowerShell 7+ már fut Linuxon és macOS-en is.
• Közvetlenül meghívhatók .NET osztályok, dll-ek, sőt, akár C# kód is fordítható és futtatható menet közben.
• És vannak natív parancsok a JSON, XML, CSV be- és kimenetek struktúrált feldolgozására (ConvertFrom-Json, Invoke-RestMethod).

Természetesen megvannak a maga korlátai is, mint a lassabb indulás, vagy a magasabb erőforrásigény. Mivel rendkívül erős hozzáférése van a rendszer mélyebb rétegeihez, ezért a kibertámadások egyik kedvelt eszköze. Ez azonban nem állíthatja meg, 2008 óta minden Windows rendszer részét képzi. Népszerűsége töretlen a DevOps, SecOps, admin és automatizációs területeken.

Érdekesség:

Amikor Snover előállt a Monad (ez volt a PowerShell kódneve) ötletével, a Microsoft vezetősége a GUI-orientált stratégia miatt visszaléptette őt a vállalati ranglétrán. Később maga a PowerShell mentette meg a Windows Server-t (Server Core kiadás), és Snover elnyerte a legmagasabb mérnöki címet (Distinguished Engineer), majd a legmagasabb tech címet is (Technical Fellow).

A Solidity egy magas szintű, statikusan tipizált, objektum- és szerződés-orientált (contract-oriented) programozási nyelv, amelyet kifejezetten az EVM (Ethereum Virtual Machine) alapú blokkláncokon futó okosszerződések (Smart Contracts) megírására hoztak létre.

Szoftverarchitektúra szempontjából a blokklánc egy olyan adatszerkezet, ahol az adatokat tranzakciókból álló blokkokba (Blocks) szervezzük. Minden egyes blokk tartalmazza az előző blokk egyedi kriptográfiai lenyomatát (Hash-ét). Ha valaki megpróbálna utólag módosítani egy 3 évvel ezelőtti adatot, megváltozna annak a blokknak a hash-e, ami érvénytelenítené az összes utána következő blokkot a láncban.

A blokklánc adatai egyidejűleg jelen vannak a hálózatban részt vevő összes úgynevezett "teljes csomópont" háttértárán, a világ minden táján. Ha a hálózat 99%-a leállna vagy megsemmisülne, a blokklánc a maradék 1%-ból is veszteség nélkül, 100%-osan helyreállítható és fut tovább, mert minden teljes csomópont birtokában van a teljes adatbázis-történetnek az első blokktól a legfrissebbig.

A blokklánc nem egyetlen processzoron fut, hanem a hálózatot alkotó számítógépek gépein párhuzamosan. A számítógépek egy ún. Node Client-et futtatnak, pl. Ethereum esetén a Geth-et vagy Besu-t, Bitcoin esetén a Bitcoin Core-t.

De mire jó ez az egész?

Az okosszerződés egy specifikus pénzügyi és protokoll-szintű eszköz olyan rendszerekhez, ahol a felek nem bíznak meg egymásban, és nem akarnak drága harmadik felet (bankot, letétkezelőt, elszámolóházat, stb.) fizetni.

A rendszer hatékonysága abban rejlik, hogy remekül skálázható, mert több millióan is használhatják ugyanazt a szerződést. Persze, ez így önmagában nagyon szépen hangzik, ugyanakkor nem feledkezhetünk meg az egyéb költségekről sem, pl.: auditálni is kell, és a kezdeti fejlesztés is elég sokba kerül, még ha a fajlagos költségünk felhasználóként sokkal alacsonyabb is.

A Solidity használata akkor válik valóban "okossá", ha felismerjük a határait: nem a jól működő webes infrastruktúrák kiváltására való, hanem arra, hogy egy átlátható, manipulálhatatlan és automatizált bizalmi réteget biztosítson ott, ahol a harmadik felek jelenléte túl drága vagy kockázatos lenne.

A létradiagram (LAD) a gyártás és a folyamatautomatizálás legelterjedtebb grafikus programozási nyelve. Hosszú távú sikerét a villamos kapcsolási rajzokhoz és a fizikai valósághoz fűződő szoros kapcsolatának köszönheti. A modern elektronika térnyerése ellenére továbbra is a különféle vezérlések, a gépbiztonsági architektúrák és az üzemi diagnosztika egyik kulcseleme.

A 60'-as évek végéig a gépsorok logikai vezérlését huzalozott relék, számlálók és léptetők látták el. Ez főként az autóiparban jelentett gondot, mert a modellváltások a vezérlő szekrények teljes újrahuzalozását igényelték, ami rendszerint több hetes leállást jelentett. Ráadásul a folyamatos terhelésnek kitett elemek gyakran cserére szorultak.

1968-ban a General Motors Hydramatic divíziója ezen problémák felszámolására írt ki műszaki pályázatot, egy szilárdtest-elektronikájú, programozható ipari vezérlő kifejlesztésére. A Richard Morley vezette Bedford Associates megalkotta a Modicon 084 (Modular Digital Controller) berendezést, amelyet 1969-ben helyeztek üzembe a GM-nél.

A tervezők felismerték, hogy az ipari környezetben dolgozó villamos szakemberek és karbantartók elutasítanák a hagyományos kódot, és a tisztán Boole-algebrás leírást. Ezért a belső logikát egy olyan grafikus rendszer mögé rejtették, amely közvetlenül leképezte a megszokott villamos huzalozási rajzokat: a két függőleges feszültségsín közötti párhuzamos és soros utakat. A program létraszerű megjelenése nyomán kialakult a „létradiagram” elnevezés, amely lehetővé tette az üzemek számára, hogy anélkül térjenek át a digitális vezérlésre, hogy a teljes karbantartó személyzetet át kellett volna képezni.

A kezdeti időkben komoly gyártói függőségek alakultak ki, mert a piac uralkodó szereplői mind-mind saját utasításkészleteket és grafikus dialektusokat dolgoztak ki. Ezt a zárt környezetet számolta fel az IEC, a 61131-3 számú szabvány kibocsájtásával: ez közös adat- és változókezelési modellt, valamint szabványosított programnyelveket fektetett le a PLC-k számára.

A Ladder Logic programok egymás alá illesztett "szárak", ún. Rung-ok sorozatából állnak. Rengeteg dologra képes, nem csak ki-be lehet kapcsolgatni dolgokat, de használhatunk időzítőket, számlálókat és összetett funkcióblokkokat is.

Technológiai "tartósságát" mutatja, hogy hidat képez a villamos kapcsolások és a digitális mikroprocesszorok világa között. Bár a különféle Ipar 4.0-s megoldások és az ipari IoT terjedésével a strukturált szöveg (ST) és a magas szintű nyelvek alkalmazása megkerülhetetlenné vált a felsőbb vezérlési szinteken, a gépközeli rétegben a létradiagram megőrizte pozícióját.

Kipróbáltam, de tőlem valamiért annyira létidegen az egész, hogy egy egyszerű feladaton is elég sok ideig elszöszmötöltem.
Ha valakinek kedve lenne hozzá, rengeteg oldal van, ahol különféle kis programokat építhetünk a Ladder Logic-al.

A VBScript-ről az derült ki, hogy egy zárt, egyetlen platformra korlátozott, mára kihalt nyelv lett, az Elixir ennek szinte a tökéletes ellentéte.

José Valim készítette 2012-ben — ő korábban a Ruby on Rails core csapatában dolgozott, és két dolgot akart összehozni: a Ruby kellemes, olvasható szintaxisát, és az Erlang virtuális gépének (a BEAM-nek) a megbízhatóságát.

Itt érdemes megállni egy pillanatra: az Erlangot 1986-ban az Ericsson fejlesztette. Na nem webalkalmazásokhoz, hanem telefonközpontok vezérléséhez, ahol az elvárás gyakorlatilag a nulla leállás volt (ún. öt kilences rendelkezésre állás, vagyis évi pár perc kiesés a megengedett). Az Elixir tehát egy harminc-egynéhány éve, telekommunikációs környezetben harcban edzett virtuális gépre épül, csak épp modern, barátságos külsővel.

Ez az örökség nem csak történelmi érdekesség, hanem a nyelv egyik legnagyobb erőssége is: az Elixir programok könnyű, egyidejűleg futó "folyamatok" millióit tudják kezelni, és ha egy folyamat elszáll, a rendszer nem omlik össze, egyszerűen újraindítják, a többi zavartalanul fut tovább.

A leggyakrabban emlegetett bizonyíték erre a Discord: emberek millióinak valós idejű üzenetküldését és hangját ezzel a páros technológiával (Elixir + Erlang/BEAM) szolgálják ki.

Ez már rengetegszer bebizonyosodott: nem kell újra feltalálni a meleg vizet. Nem mindig a legújabb alapokra épített dolog a legmegbízhatóbb, néha az a jó megoldás, ha egy évtizedek óta bizonyított, kőkemény alapra építesz valami modern, kényelmes réteget.

A Microsoft 1996-ban dobta piacra, az Internet Explorer 3.0 (!) részeként. A cél egyszerű volt: egy könnyű, Visual Basic-alapú szkriptnyelvet adni a fejlesztők kezébe, amivel böngészőben és Windows-automatizálásban (Windows Script Host, később a klasszikus ASP szerveroldali szkriptelés) is lehet dolgozni. Gyakorlatilag a JavaScript riválisaként gondoltak rá akkoriban.

Ez a rivalizálás lett a veszte: a VBScript csak az Internet Explorerben futott, a Netscape és a többi böngésző soha nem támogatta, míg a JavaScript minden böngészőben elindult.

De a legismertebb fejezete nem is ez, hanem úgy kb. 2000 májusa. Egy Fülöp-szigeteki egyetemista írt egy féregvírust VBScript-ben, "LOVE-LETTER-FOR-YOU.TXT.vbs" néven — ez volt az ILOVEYOU vírus, az egyik legpusztítóbb számítógépes incidens a történelemben. Órák alatt tízmillió számítógépet fertőzött meg világszerte, több milliárd dolláros károkat okozva. A VBScript ekkor vált a levélmellékletben terjedő kártevők egyik kedvenc eszközévé.

Ez a hírnév évekig rátapadt a nyelvre, és végül ez (és az elavultsága) lett az is, ami miatt ma már nem futtatható: a Microsoft kivezeti a Windowsból, az Internet Explorer pedig 2022-ben végleg megszűnt, ezzel a VBScript fő futtatókörnyezete is eltűnt.

Egy technológia sorsát nem csak az dönti el, mennyire jó, hanem az is, mire használják tömegesen. A VBScript-et pont az tette bizalmatlanná, amiért egyszer megkönnyítette a dolgokat: hogy egyszerű volt automatizálni vele bármit, jó és rossz célokra egyaránt.

Akit mélyebben érdekel az ILOVEYOU vírus, itt elolvashatjátok a Nemzeti Kiberbiztonsági Intézet jelentését.

A nyelv-sorozat mai állomása a PL/SQL, és közben kiderült valami, amit korábban nem gondoltam volna: az Oracle nem úttörőként hozta létre 1991-ben, hanem lemaradásból.

A történet 1984-ig nyúlik vissza, a Sybase akkor vezette be a saját procedurális SQL-kiegészítését (ennek az egyenes ági leszármazottja a mai T-SQL, amit SQL Serverben ismerünk). Ez óriási előnyt adott nekik: az ügyfelek az üzleti logikát közvetlenül a szerveren tudták futtatni: tárolt eljárásokban, triggerekben. Nem kellett minden lépésnél az adatot ide-oda küldeni a hálózaton a kliens és a szerver között, és ez akkoriban, nem apróság volt, hanem versenyelőny.

Az Oracle ekkor már évek óta versenyben volt a Sybase-szel. 7 év kellett hozzá, de sikerült, mert 1991-ben jött a válasz: a PL/SQL.

Az érdekes az, hogy az Oracle nem csak lemásolta a receptet. A PL/SQL tervezésénél erősen az Ada nyelvből merítettek (!), ez volt akkoriban az amerikai hadsereg által preferált, szigorúan strukturált nyelv. Olyan dolgokat tettek bele, amik a korai T-SQL-ben még nem voltak meg: csomagokba (packages) rendezhető, újrafelhasználható logika, valódi kivételkezelés, és a SQL utasítások szoros, fordítási időben ellenőrzött beágyazása a procedurális kódba.

Vagyis a "második helyezettünk" ebből csinált erényt: mivel 7 évvel később kezdték, volt idejük jobban átgondolni és megtervezni, amit a Sybase már bizonyított: mi az amit a piac akar.

Van ebben egy tanulság, ami szerintem túlmutat az adatbázisokon: nem mindig az nyer hosszú távon, aki elsőnek ér be egy piacra, hanem aki a kialakult igényeket jobban teljesíti.

Amikor nagyvállalati szoftverarchitektúráról beszélünk, a legtöbben a legújabb divatos keretrendszerekre gondolnak. Eközben a globális gazdaság tranzakcióinak jelentős része csendben egy 40 éves múlttal rendelkező nyelven fut.

Az ABAP 1980-ban indult, még az SAP R/2-vel, de az áttörést a 90-es évek hozták, az R/3-al együtt, immáron az ABAP lett a teljes üzleti logika, az adatbázis kezelés és a tranzakcióvezérlés elsődleges nyelve.

Azonban az, hogy az SAP-n belül használjuk, még nem jelenti azt, hogy korlátos lenne. Az ABAP rendelkezik modern eszközökkel, amikkel API-kat, webes szolgáltatásokat érhetünk el, sőt, akár JSON formátumú adatokat is fel tudunk dolgozni, noha nem ez az elsődleges típusa.

Az üzleti logikán túl az adatok szerelmeseinek is könnybe lábad a szeme, hiszen nem csak a klasszikus AVL rácsokat tudjuk használni, mert a modern SAP felületeken könnyedén hozhatunk létre interaktív dashboardokat is, ahol az adatok és a grafikonok is gyönyörűen megmutathatják magukat.

A VFP-t a Microsoft fejlesztette. Ez egy DBF-re (adatbázis file-ra) alapozó nyelv. Bár 2007-ben leállt a fejlesztése, sok alkalmazás íródott ezen a nyelven anno. Hatalmas előnye, hogy egy helyen van minden, és natívan kezeli az adatbázist, tehát nincs szükség semmi másra, csak a jó öreg SQL parancsokra. A felületet pedig a VB-ből jól ismert control elemekkel pakolhatjuk össze.

Most, hogy kellően körbedícsértem, azért meg kell jegyeznem, hogy sajnos nem véletlenül halt el a fejlesztése. Nem a felhős technológiákra, de még csak nem is a modern, 64 bites architektúrára tervezték, ezért ma már nem készülnek új alkalmazások benne. 2015-ben a támogatása is leállt teljesen, ezért ezeknek a szoftvereknek a használata sem biztonságos minden esetben. Persze megvan a módja, de sokszor jobb elkészíteni az adott szoftver modernebb, pl.: C#-ra átírt verzióját.

Érdekes, hogy egyes nyelvek, bár külső szemmel nézve nagyon hasonlóak, mégsem maradt fenn mind. Mert ugye a VB is már .Net-el lett párosítva, és a winforms eltűnőben van. Jött a WPF, majd a különféle HTML + CSS felülettel kombinált nyelvek. Talán a Delphi az, ami még úgy-ahogy egyben van, nem sokat ingott meg, de az is igaz, hogy a RAD elég erős hátteret biztosít neki.

Martin Odersky 2004-ben alkotta meg a nyelvet, mégpedig azzal a céllal, hogy ötvözze az objektum-orientált és funkcionális részeket.

A Scala Java bájtkódra (bytecode) fordít, így 100%-ban kompatibilis a Java ökoszisztémával. Micro-szolgáltatásokban és hatalmas rendszerekben egyaránt megtalálhatjuk. Ezt használja többek között a Netflix vagy a Spotify, de ugyanakkor az Apache Spark és Kafka is.

Érdkesség: a Kafka magját 3 LinkedIn mérnök készítette, mert kellett egy nagyon erős csatorna a rengeteg esemény-adat mozgatásához. Az egész egy Scala/Java hibrid volt. Merthogy mára teljesen kivezették belőle a Scala-t.

Miért? Mert amikor a Kafka készült, még a Scala volt előnyben, de idővel a Java "felzárkózott", és a szintaktikai hátránya megszűnt.

A Scala időközben visszaszorult, de továbbra is keresett az olyan területeken, mint a Fintech és a Big Data.

A TypeScriptet Anders Hejlsberg (a Turbo Pascal, a Delphi és a C# vezető architektje) hozta létre a Microsoftnál, és nyilvánosan 2012 októberében jelentették be a 0.8-as verziót.
Egy skálázható JavaScriptet szerettek volna alkotni, ami könnyebben karbantartható. A JavaScript eredetileg kisebb webes szkriptekre lett tervezve, de a kódbázisok mérete drasztikusan megnőtt.

A TypeScript úgy lett megtervezve, hogy minden érvényes JavaScript kód egyben érvényes TypeScript kód is. Nem egy teljesen új nyelvet hoztak létre, hanem a meglévő JS-t egészítették ki.
De most jön a csavar: a TS kódot transzpilálják, vagyis JS kóddá alakítják. Ergo eldobnak egy csomó jó dolgot. Akkor mi értelme van ennek, ugye?

Nos, a TS valójában a fejlesztést könnyíti meg, mert az esetleges hibák hamarabb kijönnek, és nem a user képernyőjén találkozunk vele először. Az IDE már a gépelés közben tud segíteni és támogatni minket.
De nem lett volna jobb a JS-t átalakítani?
Elméletben igen, de gyakorlatilag ez több okból is veszett ügy volt:
- Ha megváltozik a JS, a régi kódok összeomlottak volna, a weben azonban törhetetlennek kell lennie a visszafelé-kompatibilitásnak
- A futásidejű ellenőrzések (típusok, interface-ek, generikusok, etc.) miatt olyan lassú lenne az egész, mint egy szabadnapos lajhár.
- És persze ott a TC39-es bizottság, ebben ülnek a "nagyok" (Google, Apple, Mozilla, Microsoft, etc.), és minden változtatáshoz teljes egyetértés szükséges.

Összességében örülhetünk, hiszen kaptunk egy nyelvet, hogy nekünk jobb legyen, és a web sem omlott össze.

Az 1980-as évek végén a Haskell azért jött létre, hogy egységesítse a funkcionális nyelvek kutatását. Közel négy évtizeddel később, bár a nyelv ipari elterjedtsége elenyésző maradt (a fejlesztői felmérések alapján ~0,1%), a szoftverfejlesztésre gyakorolt hatása tagadhatatlan.

Miközben a modern nyelvek (mint a TypeScript vagy a Rust) ma már előszeretettel integrálják a Haskell által úttörőként bevezetett funkcionális elemeket, maga az "eredeti" nyelv egyedi utat járt be.

A tiszta funkcionális paradigma, a side-effect-ek (nem hangzik jól a mellékhatás magyarul, bocsi) elkerülése és a kiértékelések "lusta" módszere rendkívüli előnyöket biztosítanak a zéró hibatűrésű iparágakban.

A kihívások:
A magas absztrakciós szint miatt meredek a tanulási görbe. A "lusta" kiértékelés – bár elméletben zseniális – a gyakorlatban sokszor nehezen felderíthető memóriaszivárgásokhoz vezethet. Ráadásul a több száz GHC nyelvi kiterjesztés komoly kódalap-töredezettséget okozott, ami megnehezíti a közösségi könyvtárak hordozhatóságát.

Ahol viszont pótolhatatlan:
Amikor a tranzakciók és az üzleti logika helyessége matematikai szigorral bizonyítandó, ott a Haskell remekel. Fintech: A Mercury banki háttérrendszere több millió sornyi Haskell kódból áll, amellyel 248 milliárd dolláros volument dolgoznak fel.
Blokklánc: A Cardano teljes infrastruktúrája és a Plutus okosszerződés-nyelv is erre épül a formális verifikálhatóság miatt.

Bár a modern szoftveriparban a pragmatikusabb és memóriabiztos Rust sok esetben átveszi a helyét, a Haskell továbbra is a típusbiztonság és az elméleti szoftverarchitektúra egyik csúcsa marad.

Sokkal nehezebb nyelvnek tartom, mint eddig bármi mást (na jó, az Assembly-t se kell félteni). A monádokat megszokni, ciklusok helyett rekurzió. Még a változók is másképp viselkednek, mindent paraméterekként kell továbbadni. Vannak remek dolgok is benne, ám mindezek ellenére úgy érzem, korántsem lett a kedvencem.

Van egy programozási nyelv, ami valószínűleg most is fut a háttérben a kedvenc játékodban, a webes infrastruktúrádban vagy akár az okosotthonodban, de mégsem szerepel a legtöbb hype-vonaton.

1993-ban, a brazíliai PUC-Rio egyetemen született a Lua (portugálul: Hold). Több mint 30 éve a szoftverfejlesztés egyik legjobban őrzött "titka".
Az erőssége 3 dologban rejlik: teljesítmény, beágyazhatóság, egyszerűség.

Könnyű és gyors: A teljes interpreter ANSI C-ben van megírva, a lefordított bináris mérete pedig mindössze pár száz kilobájt. Nincsenek oltári nagy függőségek. Ha pedig a LuaJIT-et használjuk, a futás a natív C teljesítményét súrolja.

Beágyazható: A Lua nem arra született, hogy egyedül uralja a világot. Kifejezetten arra tervezték, hogy tökéletesen integrálódjon C/C++ alapú rendszerekbe. Ezáltal lesz szuper kis "ragasztó", amivel rugalmas lehetőségeket adhatunk a statikus kódokhoz.

Táblák: Tiszta minimalizmus, komolyan mondom. Nincs ezerféle adatszerkezet, van a table, és mindenki legyen boldog vele. Egyetlen asszociatív tömb, amit használhatunk listaként, szótárként, objektumként, sőt, a metatáblák (metatables) segítségével akár a komplex OOP paradigmákat és az öröklődést is gyönyörűen, egyedi módon lehet vele modellezni.

Néhány érdekesség:
A World of Warcraft testreszabható UI-ja, a Roblox milliárdos ökoszisztémája (Luau), az Angry Birds, vagy a Garry's Mod - gyakorlatilag a Lua a játékipar de facto szkriptnyelve lett.

Backend és infrastruktúra: Ha API gateway kell Nginx (OpenResty) vagy Apache APISIX alapokon, a Lua ebben is segíthet.

A Cloudflare is Lua-ra építette az edge-hálózati logikájának jelentős részét a sebesség és az izoláció (sandboxing) miatt.

IoT rendszerek: Minimális memóriaigénye miatt a mikrokontrollereken is otthon érzi magát (pl. NodeMCU / ESP8266).

A Lua nem akarja leváltani a Python-t a gépi tanulásban, sem a TypeScript-et a frontend fejlesztésben. Viszont ha egy gyors, biztonságosan szeparálható és ultrakönnyű szkriptnyelvre van szükséged egy nagyobb architektúrán belül, a Lua évtizedek óta verhetetlen.

Szerintem mindenki tudja, hogy az Apple cuccok kicsit... mások. Az elsődleges programozási nyelvük volt az Objective-C, amivel az első iPhone-ok működtek, és szerintem iszonyat fura egy nyelv.

Sohasem fejlesztettem benne, most kipróbáltam, és hát... vannak fenntartásaim. Mínusz és plusz jelek a kód közepén, az egész olyan "idegen" nekem. Minden funkció "NS" betűkkel kezdődik, mintha valami titkos kód lenne (mondjuk ez a NextStep öröksége, a Facebook az FBX, a Google pedig a GGL prefixumot használta).

Egy faék egyszerű todo cli appot raktam össze, de ennyi elég is volt. Nem sok nyelvre mondom ezt, de az Objective-C nem lett a kedvencem. Ráadásul a Swift megjelenése óta kevésbé használatos már új projekteknél. Az egész SmallTalk-féle dolog nekem valahogy nem jött be. Pedig más nyelveknél is fellelhető, pl.: Ruby-ban is.

Az Objective-C nekem tipikusan az a nyelv, amire azt mondom: köszönöm szépen, ennyi elég is volt.

Kipróbáltam a Julia nyelvet, és azt kell mondjam, kellemesen csalódtam benne. A fellelhető információk szerint a C gyorsaságát kínálja a Python kényelmével. Nos, a gyorsaságról nem sokat tudok mondani, ilyen pici kódoknál ez nem számottevő, viszont az tény, hogy elég kényelmesen lehet használni.

A projekt: egy script, ami a mappában lévő képekből ASCII artot generál – tehát a fotókat karakterekké (@, %, #, ., szóköz stb.) alakítja a fényerejük alapján, és .txt fájlba menti az eredményt.

Amit megszerettem benne:
• JIT fordítás – első futtatáskor lefordítja a kódot, utána viszont villámgyors
• Broadcasting (a "pöttyös" szintaxis, pl. Gray.()) – egy sorban lehet egy függvényt végigfuttatni egy egész mátrixon, for ciklus nélkül
• Enum típus – típusbiztos módon lehet vele előre definiált elemeket kezelni
• do-block – a fájlkezelés pont olyan biztonságos és olvasható, mint egy Python "with" vagy C# "using"

Gyorsasága és rugalmassága miatt sok területen használják, a NASA például előszeretettel írja újra a Fortran kódokat Julia-ban. Úgy is mondhatjuk, hogy a Fortran "trónkövetelője" lett, a szimulációk terén.

Egyetlen aprócska dolog van, ami nem kifejezetten tetszik: ha futtatható állományt szeretnénk készíteni belőle, az bizony elég sokáig tart. Nekem kb 3x15 perc volt, talán picit kevesebb. Persze, hiszen be kell csomagolni a teljes környezetet, csak úgy, mint egy Python esetében, hogy azokon a gépeken is fusson, ahol nincs előre telepítve a Julia. Így viszont a fileméret is megnő, na de valamit valamiért, nem?

A Lisp képes arra, hogy futás közben kódot generáljon, vagy akár a saját kódján változtasson. Ezt más nyelvekben is megtehetjük, de sokkal több macerával jár (parser-ek, interpreter-ek írása), míg a Lisp ezt teljesen természetesen kezeli.

Csak egy egyszerű html generátort csináltam benne, de megizzasztott rendesen. Nincs bajom a zárójelekkel, sőt, kifejezetten jónak tartom, szépen rendezi a kódot. Azonban a Lisp esetében ez más. Mire végeztem azzal amit akartam, mindenhol "(" és ")" volt, még a fejem is megfájdul tőle.

Bár valószínű, hogy ezen a rövid kis ismerkedésen túl nem fogom elmélyíteni a kapcsolatomat a Lisp-el, de pont ez a fajta „ez most tényleg máshogy működik” élmény miatt éri meg ilyen nyelveket is kipróbálni: más gondolkodásmódra kényszerít, és ez már önmagában jó tanulság.

Ezen a héten egy igazi nagyágyút, az SAS-t (Statistical Analysis System) vettem kezelésbe. Ez a világ egyik legdrágább, zárt vállalati szoftvere, én is csak az ingyenes, felhős, SAS OnDemand for Academics-et (ODA) használtam a tesztelésre.
Míg más nyelvekben egy komplex elemzéshez rengeteg külső könyvtárat kell importálni (azért elég menő, hogy pl. mennyi Python könyvtár van ezekre, te jó ég!), és jó hosszú kódot kell írni, az SAS-ben gyakorlatilag konyhakész motorokat paraméterezel.

Az egész kód két részre épül:
DATA: Itt készíted elő és tisztítod az adatokat; itt meg kellett küzdenem egy vicces, régi "8 karakteres szabállyal" is, ami csonkította a szavaimat.
PROC: Mindössze 3-4 sornyi kód, és a rendszer a háttérben elvégzi a kőkemény matematikát. Olyan jelentéseket, ROC görbéket és túlélési modelleket generál másodpercek alatt, amikkel azonnal be lehet sétálni bármelyik management meetingre.

Miért az "óriások" (gyógyszeripar, banki szektor) játékszere az SAS? Miért fizetnek érte ekkora összegeket?
1. Memóriakezelés: Az SAS nem próbálja az összes adatot a RAM-ba zsúfolni. Lemez-alapú (Out-of-Core) feldolgozást használ, így a gigantikus fájloktól sem omlik össze, csak stabilan, lépésről lépésre ledarálja azokat.
2. A hatósági arany standard: Az FDA vagy a nemzetközi bankfelügyeletek bizalommal fogadják a SAS által generált statisztikákat. Évtizedek óta auditált, tévedhetetlen matematikai eljárásokra épül.
3. Örök életű kódok: Egy 1995-ben megírt szkript ma is pont ugyanúgy, ugyanazt az eredményt hozva fut le.
4. Jogi felelősség: A nyílt forráskódú projektekkel ellentétben itt van egy konkrét cég, aki prémium támogatást ad, és jogi felelősséget vállal a szoftveréért.

Nagyon tetszetős, és ebben kifejezetten látom azt, hogy miért kellett ez a nyelv. A sok beépített függvénye megkönnyíti a programkódok írását. Sokkal könnyebb benne dolgozni, ugyanakkor szerintem sokkal nagyobb matematikai és analitikai háttértudás kell hozzá.
Ez az első olyan nyelv, amire kétség nélkül azt tudom mondani, hogy egy igazán jó matekos, aki még életében nem nyúlt soha semmilyen programnyelvhez, AI segítséggel könnyen meg tudja tanulni, és igazán jó dolgokat csinálhat vele.

A Dart szintaxisa elsőre teljesen más világ a megszokott Python vagy a C logikája után. A Flutter keretrendszerrel párosítva viszont hihetetlenül erős eszközt ad a kezünkbe. Egyetlen kódbázisból építhetünk gyors és natív alkalmazásokat.

Arra voltam kíváncsi, miként lehetne egy 100%-ban offline működő, helyszíni jegyzőkönyv-generáló appot összerakni. Aki terepen dolgozik, ott előfordulhat, hogy nincs stabil internet. Nekikezdtem, és egy nagyon masszív alappal zártam a hetet:
• dinamikus sablonrendszer (bármilyen meglévő .docx fájl betallózható)
• az applikáció automatikusan legenerálja a kitöltő űrlapot a helyőrzők alapján
• saját exportáló motor végzi a közvetlen DOCX XML manipulációt a háttérben
• felhőszolgáltatás nélküli, teljesen helyi adattárolás

A Ducky Reporter stabilan teszi a dolgát, és rengeteg időt spórolhat meg a monoton terepi papírozás kiváltásával.

Kód: https://github.com/Duckydevhu/ducky_reporter

A Ruby-t kifejezetten arra tervezték, hogy egyszerű és könnyen olvasható legyen. Itt gyakorlatilag minden egy objektumnak felel meg, ezáltal hihetetlen rugalmasság kerül a kezünkbe. Rengeteg "Gem" (előre megírt funkciók) készül hozzá, szerencsére nem kell újra és újra feltalálni a spanyolviaszt.

Tökéletes választás webalkalmazásokhoz, remekül használható minden standardizált elemmel (json, xml és társaik).

Arra voltam kíváncsi, vajon lehetséges lenne-e egy statikus oldal generátort készíteni benne (mint a Hugo). Szóval nekikezdtem, és egész szép eredményekkel zártam a hetet:
• van egy generátor
• blogokat is tud kezelni (TinyMCE-vel)
• webszerkesztő is van benne (GrapesJS)
• flat-file az egész, adatbázis nélkül
Az egész projekt stabil, gyors és könnyen kezelhető lett, felesleges sallangok és funkciók nélkül.

Ezen a héten egy nagyon különleges, már-már "földönkívüli" nyelvvel találkoztam. Ez a Prolog, a logikai programozás nagy öregje!

A legtöbb nyelvben (mint a Python vagy a C) lépésről lépésre meg kell mondanom a gépnek, hogy hogyan oldjon meg egy problémát. Na, a Prolog nagyon nem ilyen: itt csak tényeket és szabályokat adok meg neki, aztán felteszek egy kérdést, a gép pedig magától összerakja a mozaikokat!

Hogy ezt teszteljem, készítettem benne egy klasszikus detektív játékot, hasonlót, mint a Cluedo. Betápláltam a nyomokat: "Mustár ezredes a könyvtárban volt", "A gyilkos fegyver a méreg", és lefektettem a gyanúsítottak szabályait. A végén csak annyit kérdeztem a kódtól: "Ki a tettes?". A Prolog pedig a tiszta logika alapján levezeti és megmondta az eredményt!

Illetve van egy random mód is, amikor nekünk kell megtalálni a gyilkost (nyilván ez az érdekesebb). Nyomokat is kapunk, és a tippeknél számolja, hányszor tippeltünk.

Ezen a héten egy igazi "dinoszaurusszal" találkoztam. A COBOL nem mai darab, de 1959 óta a világ banki tranzakcióinak és kártyás fizetéseinek jelentős része a mai napig ezen a nyelven fut!

Egy pici ATM szimulációt készítettem, pont úgy működik, mint a valóságban: számlaszám és PIN kód párossal lehet bejelentkezni, majd jöhet az egyenleglekérdezés, a készpénzfelvétel, a befizetés, de még egy másik számlára is lehet utalni.

Nyilván az éles rendszerek nem ennyire egyszerűek, rengeteg dolog kimaradt nálam (pl.: security), de egyszerűen nincs mindenre időm.

A banki és állami szektor tökéletesen megmutatja: ami stabilan és megbízhatóan működik, azt nem kell lecserélni csak azért, mert nem tegnap találták ki. Ha egy IT rendszer tökéletesen, hiba nélkül kiszolgálja a cégedet, az egy igazi kincs, amit érdemes megbecsülni.

Ma, amikor hajlamosak vagyunk mindent túlbonyolítani, az ember könnyes szemmel gondol vissza a '90-es évekre.
Akkoriban a "fejlesztés" így nézett ki:
• Fogtál egy szürke CommandButton-t a bal oldali palettáról
• Ráhúztad a Form-ra
• Dupla klikk
• Beírtad a szerkesztőbe: MsgBox "Szia Világ!"
Bumm. Kész is volt a grafikus asztali alkalmazás. Lehetett menni kávézni.

A Classic VB persze nem volt tökéletes. Virágzott a "spagetti kód", és mindenki ismerte az On Error Resume Next-et (ha hiba van, csukd be a szemed és menjünk tovább). De ez az eszköz hozta el a Rapid Application Development (RAD) igazi aranykorát!

Egy lelkes kezdő egyetlen esős hétvége alatt képes volt összekattintgatni benne egy komplett videotéka-kölcsönző szoftvert, vagy egy raktárkészlet-nyilvántartót. És tudjátok mi a legszebb az egészben? Nagyon sok ilyen "gyorsan összedobott" VB6 program a mai napig ott fut valamelyik KKV hátsó irodájában egy porosodó gépen!

Bár ma már a Kotlin, a Swift, a Python vagy a C# az uralkodók, a VB6 mutatta meg egy egész generációnak, hogy a programozás nem csak fekete terminálablakokból áll, hanem azonnali, vizuális alkotás is lehet.

Az első programomat Basic v2-ben írtam, C64-en, így talán kicsit jobban megérint, ha visszagondolok ezekre az időkre, amikor még nem volt kismillió library, meg framework, és a könyvtárból kölcsönzött könyvekből tanulgattam, hogy mit hogyan is kellene csinálni.

Az Apple 2014-ben mutatta be a Swiftet, egy évvel később pedig a legkedveltebb nyelv lett a StackOverflow felmérése szerint.
Elsősorban Apple rendszerekre (iOS, macOS, watchOS, etc.) való fejlesztéshez ajánlják, de nem csak ezekre korlátozódik. Éppúgy készíthetünk vele Windows vagy akár Android alkalmazásokat is.
Nincs semmilyen Apple termékem (és nem akarok még több VE-t), így egy sima win CLI appal marháskodtam. A legjobban az érdekelt, hogy hogyan néznek ki az alap OOP dolgok (osztályok, konstruktorok, szülő-gyermek kapcsolat, polimorfizmus) a Swiften belül. Szerencsére nincs túlbonyolítva semmi, jól olvasható, barátságos nyelv.
iOS-en és macOS-en létezik egy Swift Playground nevű alkalmazás, ami játékos módon mutatja be a nyelvet. Szeretem az ilyen kezdeményezéseket, mert általában jól szoktak sikerülni, ez is kifejezetten szórakoztató és szép lett.

A Java "kisöccse", amit a Google is ajánl az Android appok fejlesztéséhez.
Android Studio-ban nem csak könnyen el lehet készíteni az alkalmazást, de szerencsére még tesztelni is tudjuk.
Ezen a héten egy nagyon apró kis appot készítettem, ami nem szép, de cserébe hasznos (a helye már megvan, igaz, egy kis upgrade lesz még rajta). Minimalista riportokat tudunk készíteni, minden sallang nélkül: csak szöveg, és max 10 kép. A képeket szépen tömöríti, hogy kisebb legyen a pdf file mérete.
A küldés gombbal feltölthetjük a Google Drive-ba, vagy elküldhetjük emailben is.

Sok-sok évvel ezelőtt használtam utoljára az Assembly-t, bár akkor egészen más célokra, mint most. Arra gondoltam, készítek egy számológépet, hiszen mi mást, ha nincs más ötletem?

Itt nincsenek kényelmi funkciók, sőt, még Windows vagy más operációs rendszer sem kell a futtatásához. A kód közvetlenül a processzorral beszélget. Nekem kellett lépésről lépésre megmondanom, melyik memóriarekeszbe (AX, BX) kerüljön az első szám, hova tegyük a műveleti jelet, és hogyan kezeljük, ha valaki véletlenül nullával akar osztani.

Olyan volt, mintha felhőkarcolót építenék, de előtte én készítek el mindent: a betonkeverőt, az acél gerendákat, sőt, még az ezek előállításához szükséges gépeket is!

Ezen a héten kivételesen kicsit újra gyerek lehettem, bár az én időmben még a Comenius Logo-val csábították a diákokat a programozás útjára. Ezt a rendszert kifejezetten oktatási céllal fejlesztették, elsősorban azért, hogy a gyerekeknek kedvezzenek vele. A zsenialitása abban rejlik, hogy gépelés helyett vizuális építőblokkokat használunk. Tisztára olyan az egész, mintha legóznánk. Csak egymáshoz pattintjuk az utasításokat, és máris kész az algoritmus. Hatalmas piros pont, hogy a magyar nyelv is teljesen támogatott (meg sok más is).

Nagyon könnyen kezelhető, és a legjobb benne, hogy az eredmény azonnal látszik és kézzelfogható. Nem egy unalmas fekete ablakban futnak a számok, hanem színes figurákat mozgathatunk a képernyőn: labdát, repülőt, kiscicát. A közösség már rengeteg jópofa dolgot készített vele: interaktív játékok, vicces animációk, és komplett kis mesék keltek életre a platformon.

Nem gondoltam volna, de a Comenius Logo-t is "újragondolták", Imagine Logo néven. Muszáj voltam kipróbálni, rajzolni pár marhaságot benne. Néha jó, csak úgy, céltalanul alkotni mindenfélét, van benne valami megnyugtató.

A 17. heti nyelv a Rust. Évek óta a fejlesztők leginkább imádott nyelve, és nem véletlenül! Ezen a héten egy pillekönnyű fájlkeresőt és dokumentumkezelőt építettem.

A Mozilla fejlesztői 2006-ban valami olyat akartak alkotni, ami leszámol a szoftverfejlesztés egyik legnagyobb rákfenéjével, a memóriahibákkal, anélkül, hogy a teljesítményből engednének:

• Gyors, mint a C++ – Nincs a háttérben lassító garbage collector, így a programok sebessége maximális és kiszámítható.
• Betonbiztos a memóriakezelése – A beépített "borrow checker" egyszerűen nem engedi, hogy hibás memóriahivatkozásokat írj. A kód le sem fordul, ha baj van!
• Modern korra tervezték – Zseniálisan és biztonságosan kezeli a párhuzamos feldolgozást, így a többmagos processzorok ereje hiba nélkül kiaknázható.

A héten egy asztali fájlkeresőt és dokumentumkezelőt építettem, tömeges címkézési funkcióval. A backendet teljesen a Rustra és a Tauri keretrendszerre bíztam, a frontend pedig egy egyszerű HTML/CSS/JS kombó. A Rust erejét az erőforrás-kezelésben élveztem igazán: a program az óra mellett a háttérben automatikusan scanneli az adatokat.

A PHP-t gyakran kinevetik, leszólják, és lassan 20 éve temetik. "A PHP halott" - szokták mondani. Ugyanakkor tény, hogy a világ weboldalainak kb. 80%-át ez a nyelv hajtja. A PHP nem tökéletes, de stabilan hozza, amit kell, és végső soron ez számít igazán.

A héten csaltam kicsit, mert már elégszer volt dolgom a PHP-vel. Építettem már nagyobb webes QA rendszert is, adatbázissal és komplex authentikációval, de most valami könnyedebbet akartam csinálni.

Mivel a képekkel kapcsolatos dolgokat eddig hanyagoltam, most meg akartam nézni, hogy ezt hogyan kezeli a PHP. Egy paletta generátor jutott eszembe, ahol képeket is fel tudunk dolgozni, hogy kinyerjük a benne lévő színeket.

A Go nem csak egy újabb programozási nyelv a sorban. Robert Griesemer, Rob Pike és Ken Thompson 2007-ben valami olyat akartak alkotni, ami egyesíti a különböző világok előnyeit:

Gyors, mint a C – Statikusan gépelt és fordított, így a teljesítményre nem lehet panasz.
Egyszerű, mint a Python – A szintaxisa letisztult és olvasható, ami drasztikusan növeli a fejlesztői produktivitást.
Modern korra tervezve – Beépített megoldásai vannak a többmagos processzorok és a hálózati rendszerek hatékony kihasználására (CSP-stílusú konkurens programozás).

Mi teszi igazán különlegessé?
•Míg más nyelvek csak a szintaxisra fókuszálnak, a Go a teljes szoftverfejlesztési folyamatot szem előtt tartja:
•Villámgyors build idő: Nincs több kávészünet a kód fordítása alatt.
•Standard Library: Egy hatalmas alapkönyvtár, ami szinte minden gyakori feladatra kínál megoldást.
•GopherJS: Akár JavaScriptet is generálhatsz belőle front-end fejlesztéshez!

Egy mini raktárkezelőt készítettem benne, a backendet teljesen a Go-ra bíztam, a frontend pedig egy egyszerű HTML/CSS/JS kombó. A Go erejét a backendben élveztem igazán: a REST API gyors és megbízható. A frontend is jól működött, bár itt nem használtam semmilyen keretrendszert, csak sima JavaScriptet, hogy ne bonyolítsam túl a dolgokat.

A 14. heti nyelvem az Ada. Ezt a rendszert a légiközlekedésben és az űrprogramokban használják. Ha egy weboldal (JavaScript) lefagy, frissítesz. Ha a robotpilóta (Ada) fagy le, abból katasztrófa van.

Az Ada elképesztően szigorú. Minden változót, minden értéket ezerszer leellenőriz a háttérben. Üzleti szempontból ez a kockázatkezelés csúcsa.

Egy egyszerű kis lift szimulációt készítettem benne, ami egy 10 emeletes épületben működik. A liftet a számokkal hívhatjuk, és egy kijelzőn látjuk, hogy épp melyik emeleten van.

A kis kísérletem elsősorban a többszálas programozásra fókuszált, ami az Ada egyik erőssége. A lift szimulációban a különböző emeleten várakozó utasok külön szálakon futnak, és a lift vezérlője is egy külön szálon működik. Ez lehetővé teszi, hogy a rendszer hatékonyan kezelje a párhuzamos eseményeket, mint például az utasok érkezése és a lift mozgása.

Az első MATLAB 1970-ben készült, kereskedelmi formáját pedig 1984-ben nyerte el. Neve a MATrix LABoratory rövidítése, ami egyben a lényegét is elárulja: minden adatot mátrixként kezel.

Algoritmusfejlesztésre, szimulációra, és adatvizualizációra találták ki, többnyire tudományos és mérnöki területeken alkalmazzák. Meglepően jól kezelhető, átlátható nyelv, igazság szerint sokkal rosszabbra számítottam.

Egy kedves ismerősömnek hála megnézhettem pár "igazi" számítást is, amik a gyakorlatban remekül működnek, és igaz, hogy néha várni kell pár másodpercet, de az eredmények mindenért kárpótolnak minket.

Nem mélyültem el a nyelvben, egy egyszerű Mandelbrot-halmazt ábrázoltam vele. Egy apró csavart vittem azért a dologba: dinamikussá tettem, hogy lehessen benne zoomolni is.

Nem nekem való nyelv, az biztos, de őszintén meglepődtem, hogy mennyi mindent meg lehet vele oldalni.

A nyelvet 1957-ben alkották meg az IBM-nél, kifejezetten azzal a céllal, hogy a matematikai számításokat a lehető leggyorsabban el tudják végezni. Ez volt az a nyelv, ami segített a NASA-nak a rakéták pályáinak kiszámításában az Apollo projekt során.
A legnagyobb előnye az oszlopfolytonos memóriakezelés. Ez ugyanis a legtöbb matematikai algoritmusnak igencsak kedvező elrendezés (más nyelvek sorfolytonos rendezésével szemben). Nagy mátrixok esetében pedig drasztikus sebességnövekedés érhető el.

Például.:
Oszlopfolytonos: a művelet 0,5 s, 50.000 alkalommal, ez kb. 7 óra
Sorfolytonos: a művelet 15 s, 50.000 alkalommal, ez kb. 8,5 nap (!)

Nincs szuperszámítógépem, és nem dolgozom több milliós mátrixokkal sem, csak egy egyenletmegoldót barkácsoltam Gauss eliminációval. Ennek ellenére élveztem az alkotást ebben a nyelvben is. Tetszik, hogy átlátható, jól strukturált, bár a formátumok jelölése elsőre furcsának tűnt, de meg lehet szokni.

És ha már kipróbáltam az újabb (f90) Fortrant is, nem hagyhattam ki a fix oszlopszélességűt (f77) sem. Anno a lyukkártyák miatt volt a fix szélesség, ezért muszáj volt keresnem valamit erre is. Szerencsére elég sok szimulátort/emulátort lehet találni a neten, egyszerűen elképesztő, hogy némelyik modell még csörög, kerreg, kattog is, a műveletek elvégzése során.
Ha belegondolunk, képernyő nélkül, kezükben 50-100-150 kártyával, a mérnökök akár órákat is vártak az eredményekre; ami lehet, hogy rossz volt, vagy épp begyűrte a kártyát a gép, és lehetett szépen újra lyukasztani.

Emlékszem még a jó öreg Turbo Pascal-ra. Nagyon szerettem, mert könnyen tanulható volt, nagyon sok jópofa dolgot írtunk benne a haverokkal. Aztán jött a Delphi, ami az Object Pascal-ra épített, és volt hozzá egy nagyon jó RAD (Rapid Application Development) környezet is.

Ezen a héten egy gyorsindító sávot készítettem. Az alkalmazásokat 12 slotba rendezhetjük, és F1-F12-ig lehet indítani őket a billentyűzet segítségével. Kezdett tele lenni a tálca mindenféle appal, így a fontosabbakat áttettem ide. A sávot az ALT+SPACE kombóval tudom előhívni, aztán nyomok egy F6-ot, és elindul a beállított alkamazás. Igyekeztem modernebb külsőt adni az egésznek, így kapott némi áttetszőséget és kerekített sarkokat is.

Az a baj ezekkel a segédprogramokkal, hogy nagyon könnyű rászokni a használatukra, mert roppant kényelmesek tudnak lenni.

Alapvetően szeretem, ha rögtön láthatom a kódolás eredményét, mint egy desktop app esetében: gombok, beviteli mezők, etc.
Az R kicsit más, hiszen nem szoftverfejlesztésre készült, hanem iszonyatos sebességű számításokhoz, mint pl.: gyógyszeripar, pénzügyi szektor, akadémiai kutatás. Nem írnak benne operációs rendszert, vagy gépek vezérlését, és nem is ez mozgatja a weboldalak hátterét.

A múlt héten is használt log filet néztem meg:
• Mérete: 2.5 GB
• Sorok száma: 22 694 356

Az adatok elemzése grafikonnal és interaktív html készítésével együtt: 4.36 sec (!) alatt lefutott.

A második tesztem egy (az előzőhöz képest pici) 5000 soros adathalmaz, kitalált gyártási adatokkal, mint pl.: hőmérséklet, nyomás, etc. Kollerációs analízist, lineáris regressziót teszteltem, és egy javaslatokat tartalmazó riportot is készítettem.

Az elmúlt 3 hétben csak adatokkal foglalkoztam: SQL, Perl, végül az R. Az igaz, hogy itt nem készültek appok, de ezek a nyelvek is roppant érdekesek. Számomra lenyűgöző, hogy ha az adott nyelveket a megfelelő feladatokra használjuk, mennyire jól kiegészítik egymást.

Egy adatbeviteli alkalmazás készülhet C#-ban, az információt SQL szerveren tároljuk, Perl-el tisztíthatjuk meg, végül az elemzést elvégezheti az R. Persze, ez így, ebben a formában ritka, de az biztos, hogy egy adott vállalat által használt alkamazások (legyen az desktop, mobil vagy akár webes) nem mind ugyanazon a nyelven készültek.

A Perl kiérdemelte az "internet ragasztószalagja" címet, szinte bármit össze lehet vele tartani, ha gyors javítás kell, még ha nem is ez a legjobb és legelegánsabb megoldás.

Amiben igazán verhetetlen, az a szövegfeldolgozás:
• Log elemzés: szerver naplók, hibaüzenetek, biztonsági logok
• ETL (Extract, Transform, Load): adatok kinyerése, átalakítás, betöltés adatbázisba
• Beépített regex: továbbra sem szeretem, de piszkosul gyors és tömör

A héten egy log filet elemeztem vele, kíváncsi voltam, mennyi idő alatt lesz kész. Íme a számok:
• A log file mérete 2.5 GB
• Több, mint 22.000.000 sor van benne
• Az elemzés során 3 adatot néztem
• A teljes feldolgozás 2:14, azaz 134 sec!
• Tehát másodpercenként 164.000 sort nézett meg

Bár a Perl szintaxisa... nos, néha olyan, mintha egy macska sétált volna át a billentyűzeten, de a teljesítménye elképesztő!

Az SQL (vagy másképpen SeQueL) nem egy szokásos programozási nyelv, a nevének jelentése: Structured Query Language, tehát ez egy ún. lekérdező nyelv. Ezzel beszélgetünk az adatokkal teli óriási táblázatokkal.

A SQL segítségével létrehozhatunk adatbázisokat, táblákat, és természetesen lekérdezhetjük, módosíthatjuk vagy törölhetjük az adatokat. Az SQL szabványosított nyelv, de különböző adatbázis-kezelő rendszerek (pl. MySQL, PostgreSQL, Microsoft SQL Server) saját kiterjesztéseket is hozzáadhatnak.

A heti kód a kezdők számára lehet érdekes: kulcs-érték párokból képzünk táblát, dinamikusan, futás közben. Ez akkor hasznos, ha pl.: JSON adatokat kell feldolgozni, és nem tudjuk előre, hogy milyen mezők lesznek benne.

A héten csalok egy picit: eredetileg a VB.NET lett volna terítéken, de korábban már foglalkoztam a C#-al, ami hasonló, de modernebb eszközöket kínál, így úgy döntöttem, hogy inkább a VBA-t veszem elő. A Visual Basic for Applications a Microsoft Office alkalmazások beépített programozási nyelve, amely lehetővé teszi az automatizálást és a testreszabást. Bár a VB-hez hasonló szintaxissal rendelkezik, a VBA kifejezetten az Office környezetére van optimalizálva.

Annak ellenére, hogy egy elég régi, és korlátolt nyelvről van szó, még mindig nagyon hasznos lehet, különösen azok számára, akik gyakran dolgoznak Excel, Word vagy Access dokumentumokkal. A VBA segítségével automatizálhatjuk a monoton feladatokat, létrehozhatunk egyedi funkciókat és makrókat, amelyek növelik a hatékonyságot.

Azt akartam megmutatni, hogy egy egyszerű dokumentumkezelő rendszert is össze lehet dobni vele, ami képes kezelni a fájlokat, kategóriákba sorolni őket, és keresni közöttük. Ez különösen hasznos lehet kisebb vállalkozások vagy egyéni vállalkozók számára, akik nem akarnak bonyolult szoftvereket használni a dokumentumaik kezelésére.

A JavaScript a modern web lelke, szinte minden weboldal használja. Nem véletlenül, hiszen remekül alkalmas a site manipulására. Kliens oldali nyelv, ami a böngészőben fut, tehát a fejlesztéshez nem kell telepíteni semmit, és azonnal láthatóak az eredmények.

A Node.js segítségével akár szerver oldalon is futhat a kód, így elérhetővé válnak olyan műveletek, amiket a klienseken biztonsági okokból nem engedélyeznek, mint pl.: fileműveletek (másolás, törlés, létrehozás, módosítás). Az Electron keretrendszerrel pedig asztali alkalmazásokat is készíthetünk.

Sokszor láttam már, hogy a felhasználó megnyitja a különféle táblázatokat, dokumentumokat, prezentációkat, egyszerre akár 10-15 ablakot is. Arra gondoltam, biztos hasznos lenne egy olyan app, ami figyelmeztet, hogy "xy" process már régóta fut, mégsem dolgoztunk vele az elmúlt 1 órában (ez szabadon beállítható).

A C# lett a Microsoft válasza a Java-ra, és sokáig a "Windows-os nyelvnek" csúfolták. Egyfajta hibrid, mert egyesíti a C++ erejét a Java egyszerűségével. Ráadásul ott van mögötte a .NET keretrendszer: mindenre van benne kész megoldás, legyen szó adatbáziskezelésről, titkosításról, vagy akár webes kommunikációról.

Készíthetünk vele modern vállalati alkalmazásokat is, WPF (vagy régebbi rendszerek esetében WinForms) technológiával. Az ASP.NET az egyik leggyorsabb megoldás API-k és weboldalak kiszolgálására. Ráadásul, mivel Microsoft termék, így az Azure felhőben mindent "első kézből" támogat.

Most egy BOM építő alkalmazást készítettem vele, a UI-t a WPF adja. Azoknak lehet ez jó, akik elemekből építenek fel termékeket, vagy szolgáltatásokat. Könnyen látható az egész fa struktúra, és mellette a költségeket is remekül kezeli.

A Java mottója: "Írd meg egyszer, futtasd bárhol". A platformfüggetlenség sokak kedvencévé tette a nyelvet, hiszen a kód változtatás nélkül futtatható más gépeken és operációs rendszereken is, hála a JVM-nek, azaz a Java Virtual Machine-nek.

Rengeteg vállalati szoftver készül Java-ban, hiszen egyidejűleg akár több ezer tranzakciót is képes kezelni. A Google mára a Kotlint preferálja, de az Android alapjai és a Play Áruházban lévő alkalmazások jelentős része Java-ban készült (vagy Java alapú).

Én egy pici kölcsönző rendszert készítettem vele, ahol lehetőségünk van az eszközök, ügyfelek és természetesen a kölcsönzések rögzítésére. Azoknak lehet hasznos, akik nagyobb értékű gépeket, berendezéseket adnak bérbe.

A C++ elhozta azt, ami a legtöbb modern nyelv alapját képzi: az objektumokat. Olyan, mint egy versenyautó, amire robotkarokat és gépágyúkat szereltek. Bár nem a legkönnyebb nyelvek közé tartozik, mégis megéri foglalkozni vele. Az objektumok megfelelő használata elképesztően hasznos az üzleti életben, a folyamatok szervezésénél is.

Sebességének és a hardverközeli kontrollnak köszönhetően máig népszerű maradt. A közvetlen memóriakezelés és GPU/CPU optimalizálás lehetővé tette, hogy az egyik legnépszerűbb játékmotor, az Unreal Engine is C++-ban készült.

A snake nevű játékot szinte mindenki ismeri, a legtöbben talán a Nokia telefonoknak köszönhetően. Gondoltam jó buli lesz egy ilyet elkészíteni, még ha nem is használom ki feltétlen a C++ összes előnyét. A készítés során jól szórakoztam, élvezetes látni, ahogy blokkról blokkra épül fel a program.

A TIOBE index szerint még mindig a C a 2. legnépszerűbb nyelv a világon, annak ellenére, hogy a szintaxisa jóval szigorúbb, mint a Pythoné. Nincsenek kényelmes megoldások, ellenben sokkal többet megtudhatunk a memóriakezelésről, az erőforrásokkal való gazdálkodásról.

A C olyan helyeken szükséges, ahol a teljesítmény kritikus, mert kevés a rendelkezésre álló erőforrás, pl.: beágyazott rendszerek vagy a játékmotorok.

A XOR titkosítás nem túl bonyolult, de kellően hatékony lehet. A feladat egyszerű: a 0-kat 1-re, az 1-ket 0-ra cseréljük a titkosítókulcs segítségével.

A Python kiváló kezdés mindenki számára, aki a programozás világával imserkedik. Egyszerű szintaxisa és széles körű alkalmazási területe miatt ideális választás volt az első hétre. Ebben a projektben egy Sentiment Analysis appot készítettem, amely képes megmondani egy szövegről, hogy az pozitív, negatív vagy semleges hangvételű-e.

Ismerem a nyelvet, oktatom is, de eddig inkább az adatfeldolgozás és gépi tanulás területén használtam. Azt kell, hogy mondjam, most sem csalódtam benne, a csomagok teleptésekor sem volt semmi gond, és a felhasznált textblob is éppolyan jól használható, mint más könyvtárak.

Hogy mire jó ez? Ahol pusztán csak a szöveges értékelés áll rendlkezésre, és nincs számszerűsített értékelés, szerintem ez a legjobb megoldás az elemzésre. Ugyanakkor a számok és csillagok mellé, kiegészítésként is remekül funkcionálhat. A Sentiment Analysis alkalmazások széles körben használatosak az üzleti életben és a közösségi médiában. Segíthetnek a vállalatoknak megérteni ügyfeleik véleményét, javítani a termékeket és szolgáltatásokat, valamint hatékonyabb marketingstratégiákat kidolgozni.