Visuell programmering är en typ av programmeringsspråk där människor kan beskriva processer med hjälp av illustrationer. Medan ett typiskt textbaserat programmeringsspråk får programmeraren att tänka som en dator, låter ett visuellt programmeringsspråk programmeraren beskriva processen i termer som är begripliga för människor.
Hur stor klyftan är mellan visuell programmering och traditionell programmering beror på det visuella programmeringsverktyget. I en extrem situation skyddar verktyget programmeraren nästan helt och hållet från det gapande utrymmet mellan mänskligt tänkande och datorer som blandar bitar i minnet.
Här är ett exempel. För att skapa en att-göra-lista med ett visuellt programmeringsverktyg ritar programmeraren ut flödet i appen. Det resulterande flödesschemat beskriver skärmar, användarinteraktioner och vad som händer med data i varje steg. Verktyget omvandlar sedan detta till programvara.
Som utvecklare vet vi att textbaserade programmeringsspråk fokuserar helt och hållet på genomförandet: det handlar om de exakta steg som datorn måste ta för att skapa den upplevelse vi vill ge användaren. Visst, språk på högre nivå och moderna ramverk ger oss bekväma genvägar. Men utvecklarens uppgift är att översätta mänskliga behov till processer som passar datorns begränsade förmågor.
Andra visuella kodningsverktyg följer samma processer och paradigm som textbaserad programmering. Tänk dig att rita en klass och dess förhållande till de objekt du instansierar, i stället för att skriva in allt i en textredigerare.
Allt detta låter bra! Men, kan man fråga sig, var är alla visuella programmerare? Varför skriver vi fortfarande kod för hand? Betyder det att visuell programmering är en dålig idé?
Innan vi svarar på dessa frågor och dyker ner i läget för visuell programmering idag, måste vi förstå vad visuell programmering egentligen är: varifrån det kom, hur det har utvecklats och varför.
Upptäck nästa generation av visuella utvecklingsverktyg
En kort historik över visuell programmeringsprogramvara
Trots att historien tycks visa det är det inte rättvist att säga att visuell programmering på 1990-talet var begränsat till spelutvecklings-kit, multimedieverktyg och databaser. Rational Software (som förvärvades av IBM 2003) hade sedan mitten av 1980-talet byggt en Ada IDE utan grafisk gränssnitt. Dessutom vände de sig också till att definiera mjukvaruutvecklingsprocessen. Arbetet med deras Rational Unified Process och relaterade insatser ledde så småningom till Unified Modelling Language som hade potential att dokumentera varenda del av ett system utan att någonsin skriva en rad kod. Det såg ut som visuell programmering men utan att producera körbar programvara.
UML tillhandahöll ett standardiserat och omfattande språk för att beskriva objektorienterade system. UML-febern drabbade dock en del arkitekter. Medförfattaren till The Pragmatic Programmer, Andy Hunt, berättar om ett programvaruprojekt där en arkitekt tillbringade två år med att skapa UML-diagram innan ens en rad kod skrevs.
Just när det agila arbetssättet höll på att ta fart tycktes UML möjliggöra alla de värsta aspekterna av de gamla sätten att bygga programvara: för mycket planering och för lite genomförande. Executable UML var ett försök att lägga till den saknade delen – den exekverbara programvaran. Flera implementeringar dök upp, men utan att få något större genomslag i en värld som snabbt bytte fokus till PHP, Ruby on Rails och andra dynamiska skriptspråk.
Interessant nog kom en form av exekverbart UML som blev kvar också från Rational Software. Rational Rose är en uppsättning verktyg för att skapa programvara med hjälp av UML och generera körbar kod i ett målspråk, till exempel C++ eller Java.
Tillbaka till framtiden: Med tanke på vad historien visar oss kanske du undrar: Är visuell programmering död? Entusiaster av visuell programmering kommer att säga att den är långt ifrån död. Fråga dem ”vad är visuell programmering?” och först kommer de att nämna ett obskyrt domänspecifikt verktyg. Sedan kommer de att säga att det verktyget är ett bevis på att visuell programmering lever. Under tiden söker du frenetiskt efter det på Google. Som ett resultat lär du dig inte bara om verktyget som de har nämnt, utan också om den mycket specialiserade värld som det existerar i.
Omöjligen har visuell programmering sin roll, vare sig det handlar om att programmera synteser eller att ge UML-entusiaster en känsla av att ha åstadkommit något. För programvara för allmänna ändamål är världen dock helt enkelt för komplex för att modelleras rent visuellt. När din ”kod” ser ut som ett kretsschema för en CPU är det kanske dags att ompröva den visuella programmeringens lämplighet för uppgiften.
På samma sätt tenderar visuell programvara för programmering att begränsas av skaparens fantasi på ett sätt som inte hindrar textbaserade programmeringsspråk för allmänna ändamål.
Men ändå har verktyg som Visual Basic, Delphi och deras efterföljare visat oss att det kan vara enormt effektivt att bygga programvara visuellt; det är bara det att det finns en pragmatisk kompromiss där handskriven kod ibland är den rätta lösningen.
Superstjärnor vs. lag: Ett nytt liv för visuella programmeringsspråk?
De första dagarna av programmering var svåra, det är säkert. Men en person kunde förstå och vara expert på allt som var nödvändigt för att skapa programvaran. Om du är tillräckligt gammal kan du tänka tillbaka på programvarutitlar från 1980-talet. Det var vanligt att en enskild programmerare blev ett varumärke i sin egen rätt.
Sid Meier, Mitch Kapor och Jeff Minter fick en viss grad av berömmelse genom att skapa välkända program eller spel på egen hand eller, som mest, tillsammans med en annan medarbetare. På den tiden tog uppgraderingscyklerna för mjukvara och hårdvara flera år. I dag skämtar vi om att det kommer ett nytt JavaScript-bibliotek varje dag. Ändå finns det en viss sanning i tanken att den moderna programvaruutvecklingen rör sig i en takt som många av oss inte kan hålla jämna steg med.
I dag byggs programvara till stor del av grupper av specialister. Medan de tidiga utvecklarna gjorde allt själva kan ett modernt programvaruutvecklingsteam ha en person vars enda uppgift är att ta hand om CI-verktyget. Utvecklare ägnar hela karriärer åt att fokusera på ett ramverk eller en plattform. iOS-utvecklare är iOS-utvecklare, inte mobilutvecklare. En eller två gånger per årtionde kanske en webbutvecklare byter ramverk. Väldigt få människor skriver manuellt assemblerspråk professionellt.
Det är inte bara så att omfattningen av programvara har förändrats. I viss mån har även utvecklarna själva förändrats. Programvaruingenjör är bara en annan karriär nuförtiden. Under de senaste årtiondena var det en passion som innehades av ett fåtal personer som hade engagemanget att lära sig ett helt nytt system så att de till exempel kunde skriva Atari ST-anpassningen av sitt framgångsrika Amigaspel. Men det är förståeligt: databehandling är inte längre en nisch.
I dag har vi en värld där programvaruutveckling består av alltmer komplexa delar och där utvecklare är vanliga människor med extraordinära specialiseringar. Denna komplexitet och specialisering lämpar sig dåligt för den rent visuella programmeringen i dessa tidiga verktyg, men det gör det också allt svårare att bygga rundade mjukvaruutvecklingsteam.
Där renodlade visuella programmeringsmiljöer har misslyckats finns det en hel cache av liknande verktyg som tar det bästa av den visuella programmeringen och kombinerar det med textbaserad kodning. Medan visuell programmering var ”no-code” är dessa nya verktyg ”low-code”.
Verktyg som OutSystems låter utvecklare skapa programvara visuellt genom att rita interaktionsflöden, användargränssnitt och relationer mellan objekt, men kompletterar det med handskriven kod där det är bättre.
Denna pragmatiska blandning av visuell programmering och textbaserad programmering är väl anpassad till behoven i modern programvaruutveckling. Low-code-plattformar minskar komplexiteten i mjukvaruutvecklingen och för oss tillbaka till en värld där en enskild utvecklare kan skapa rika och komplexa system, utan att behöva lära sig alla underliggande tekniker.
Nästa generation av visuell programmering:
Visuell programmering lovade så mycket och de problem som den ville lösa har inte försvunnit. Faktum är att de är mer relevanta än någonsin.
Men verkliga problem kräver större flexibilitet än vad visuell programmering kunde erbjuda. Low-code tar detta löfte och tillämpar det för att minska den komplexitet vi finner i modern programvaruutveckling. Så fråga inte ”vad är visuell programmering?”. Fråga i stället ”vad är låg kod?”. Du kan också boka en online-demo eller till och med prova OutSystems (det är gratis).