Vizuální programování je typ programovacího jazyka, který umožňuje lidem popisovat procesy pomocí ilustrací. Zatímco typický textový programovací jazyk nutí programátora myslet jako počítač, vizuální programovací jazyk umožňuje programátorovi popsat proces v termínech, které dávají člověku smysl.
Jak velký je rozdíl mezi vizuálním programováním a tradičním programováním, závisí na nástroji vizuálního programování. Na jedné straně nástroj téměř zcela chrání programátora před propastným prostorem mezi lidským myšlením a počítači, které míchají bity v paměti.
Uveďme si příklad. Při vytváření seznamu úkolů pomocí vizuálního programovacího nástroje programátor nakreslí tok aplikace. Výsledný vývojový diagram popisuje obrazovky, interakce uživatele a to, co se děje s daty v každé fázi. Nástroj to pak převede do softwaru.
Jako vývojáři víme, že textové programovací jazyky se zaměřují výhradně na implementaci: jde o přesné kroky, které musí počítač provést, aby vytvořil zážitek, který chceme uživateli poskytnout. Jistě, jazyky vyšší úrovně a moderní frameworky nám poskytují pohodlné zkratky. Ale úkolem vývojáře je převést lidské potřeby do postupů, které odpovídají omezeným schopnostem počítače.
Další vizuální kódovací nástroje se řídí stejnými postupy a paradigmaty jako textové programování. Představte si, že nakreslíte třídu a její vztah k objektům, které instancujete, místo abyste vše vypisovali do textového editoru.
Všechno to zní skvěle! Ale možná se ptáte, kde jsou všichni vizuální programátoři? Proč stále píšeme kód ručně? Znamená to, že vizuální programování je špatný nápad?
Než si na tyto otázky odpovíme a ponoříme se do dnešního stavu vizuálního programování, musíme pochopit, co to vlastně vizuální programování je: kde se vzalo, jak se vyvíjelo a proč.
Objevte novou generaci vizuálních vývojových nástrojů
Krátká historie softwaru pro vizuální programování
Ačkoli se to z historie zdá, není spravedlivé tvrdit, že se vizuální programování v 90. letech omezovalo na sady pro tvorbu her, multimediální nástroje a databáze. Společnost Rational Software (kterou v roce 2003 koupila firma IBM) vytvářela již od poloviny osmdesátých let IDE Ada bez grafického rozhraní. Kromě toho se věnovala také definování procesu vývoje softwaru. Práce na jejich Rational Unified Process a související snahy nakonec vyústily v Unified Modelling Language, který měl potenciál zdokumentovat každou část systému, aniž by bylo nutné napsat řádek kódu. Vypadalo to jako vizuální programování, ale bez vytváření spustitelného softwaru.
UML poskytl standardizovaný a komplexní jazyk pro popis objektově orientovaných systémů. Některé architekty však postihla horečka UML. Spoluautor knihy The Pragmatic Programmer Andy Hunt vypráví příběh o softwarovém projektu, kde architekt strávil dva roky vytvářením diagramů UML, než byl napsán byť jen řádek kódu.
Zrovna když agilita nabírala na síle, zdálo se, že UML umožňuje všechny nejhorší aspekty starých způsobů tvorby softwaru: příliš mnoho plánování a příliš málo implementace. Spustitelný UML byl pokusem přidat tento chybějící kousek – spustitelný software. Objevilo se několik implementací, ale bez většího dopadu na svět, který se rychle přeorientoval na PHP, Ruby on Rails a další dynamické skriptovací jazyky.
Zajímavé je, že jedna z forem spustitelného UML, která se udržela, vyšla také ze společnosti Rational Software. Rational Rose je sada nástrojů pro vytváření softwaru pomocí jazyka UML a generování spustitelného kódu v cílovém jazyce, jako je C++ nebo Java.
Zpět do budoucnosti: Na základě toho, co nám ukazuje historie, se možná ptáte: Je vizuální programování mrtvé? Nadšenci do vizuálního programování vám řeknou, že zdaleka není mrtvé. Zeptejte se jich „co je vizuální programování?“ a nejprve jmenují nějaký obskurní doménový nástroj. Pak vám řeknou, že tento nástroj je důkazem, že je živé a funguje. Vy ho mezitím budete horečně hledat na Googlu. Výsledkem bude, že se dozvíte nejen o nástroji, který zmínili, ale také o vysoce specializovaném světě, ve kterém existuje.
Vizuální programování má bezpochyby svou roli, ať už jde o programování syntetizátorů nebo o to, aby nadšenci UML měli pocit úspěchu. Pro software pro obecné účely je však svět příliš složitý na to, aby se dal modelovat čistě vizuálně. Když váš „kód“ vypadá jako schéma zapojení procesoru, je možná na čase přehodnotit vhodnost vizuálního programování pro daný úkol.
Podobně bývá vizuální programovací software omezen představivostí tvůrce způsobem, který nebrání textovým programovacím jazykům pro obecné účely.
A přesto nám nástroje jako Visual Basic, Delphi a jejich potomci ukázaly, že tvorba softwaru vizuální cestou může být nesmírně efektivní; jde jen o pragmatický kompromis, kdy je někdy správným řešením ručně psaný kód.
Superhvězdy vs. týmy: Nový život pro vizuální programovací jazyky?
Ty začátky programování byly těžké, to je jisté. Ale jeden člověk mohl rozumět a být odborníkem na vše, co bylo k vytvoření daného softwaru potřeba. Pokud jste dostatečně staří, vzpomeňte si na softwarové tituly z 80. let. Bylo běžné, že se jeden programátor stal samostatnou značkou.
Sid Meier, Mitch Kapor a Jeff Minter získali určitou úroveň slávy tím, že vytvořili známé aplikace nebo hry sami nebo maximálně s jedním dalším spolupracovníkem. Tehdy cykly aktualizace softwaru a hardwaru trvaly roky. Dnes žertujeme, že každý den se objeví nová knihovna JavaScriptu. Přesto je něco pravdy na tom, že vývoj moderního softwaru probíhá tempem, kterému mnozí z nás nedokážou stačit.
Dnes je software z velké části vytvářen týmy specialistů. Zatímco dřívější vývojáři dělali všechno sami, moderní tým vyvíjející software může mít jednoho člověka, jehož jediným úkolem je starat se o nástroj CI. Vývojáři tráví celé kariéry zaměřené na jeden framework nebo platformu. iOS vývojáři jsou iOS vývojáři, ne mobilní vývojáři. Webový vývojář může jednou nebo dvakrát za deset let změnit svůj preferovaný framework. Jen velmi málo lidí se profesionálně věnuje ručnímu psaní v assembleru.
Nejde jen o to, že se změnil rozsah softwaru. Do jisté míry se změnili i samotní vývojáři. Softwarový inženýr je dnes jen další profesí. V minulých desetiletích to byla vášeň, které se věnovalo pár lidí, kteří měli odhodlání naučit se úplně nový systém, aby mohli napsat například port své úspěšné hry pro Amigu na Atari ST. Ale to je pochopitelné: výpočetní technika už není výklenková.
Dnes máme svět, kde se vývoj softwaru skládá ze stále složitějších částí a kde jsou vývojáři obyčejní lidé s neobyčejnou specializací. Tato složitost a specializace se špatně hodí k čistě vizuálnímu programování těchto prvních nástrojů, ale také stále více ztěžuje budování zaoblených týmů softwarových inženýrů.
Kde selhala čistě vizuální programovací prostředí, existuje celá zásobárna podobných nástrojů, které si berou to nejlepší z vizuálního programování a kombinují to s textovým kódováním. Zatímco vizuální programování bylo „no-code“, tyto nové nástroje jsou low-code.
Nástroje jako OutSystems umožňují vývojářům vytvářet software vizuálně kreslením interakčních toků, uživatelských rozhraní a vztahů mezi objekty, ale doplňují je ručně psaným kódem tam, kde je to lepší.
Tato pragmatická kombinace vizuálního programování a textového programování dobře vyhovuje potřebám moderního vývoje softwaru. Nízkokódové platformy snižují složitost vývoje softwaru a vracejí nás do světa, kde jediný vývojář může vytvářet bohaté a složité systémy, aniž by se musel učit všechny základní technologie.
Nová generace vizuálního programování: Vizuální programování bylo velkým příslibem a problémy, které chtělo řešit, nezmizely. Ve skutečnosti jsou aktuálnější než kdy dříve.
Problémy reálného světa však vyžadují větší flexibilitu, než jakou mohlo vizuální programování nabídnout. Low-code využívá tento příslib a aplikuje jej na snížení složitosti, kterou nacházíme při vývoji moderního softwaru. Neptejte se tedy „co je vizuální programování?“. Místo toho se ptejte „co je low-code?“. Můžete si také naplánovat online ukázku nebo dokonce vyzkoušet OutSystems (je zdarma).