Tørre tæsk til tekstprogrammering fra skaberen af det grafiske Labview

Skaberen af det grafiske programmeringsmiljø LabView, Jeff Kodosky, giver tekstbaseret programmering en røffel. Især med touch-skærme er det en fordel, mener han.

Texas: En af de centrale elementer i National Instruments (NI) produktportefølge er programmeringsmiljøet Labview, som gør det muligt at programmere visuelt med kasser og streger i stedet for med skrevne kodelinjer. Og selvom programmeringsmiljøet, der udkom i første udgave til Macintosh i 1986, i år har 25 års jubilæum, så spår Labviews skaber Jeff Kodosky en stor fremtid for sproget de næste 25 år.

Således brugte han en væsentlig del af sin tale foran de omkring 3.300 tilhørere, til fremhæve Labviews grafiske muligheder i forhold til kodning af alskens programmeringsopgaver.

»You live in a graphical world, why not program in one,« lød det fra Kodosky, mens ordene samtidigt stod printet bag ham på et gigantisk display.

Labview startede ud som et grafisk sprog til at opsætte diverse konfigurationer til at teste, hvordan eksempelvis et print opfører sig ved forskellige input. Men under Kodoskys keynote-tale ved NIWeek, som finder sted i disse dage i Austin, Texas, stod det ganske klart, at National Instruments har andre og langt større visioner for Labview, end den begrænsede målgruppe, programmeringsmiljøet oprindeligt var rettet mod.

Den pointe understregede Kodosky ved at vise en grafisk repræsentation af en madopskrift, hvor den traditionelle listeform, som sådan nogle opskrifter som regel bliver vist på, var erstattet med noget, der mest af alt lignede et dataflow-diagram for mad, som skulle læses fra venstre mod højre.

Kodosky påpegede, at på den måde er det lettere at se, hvilke dele af madlavningsprocessen skal foretages i forhold til andre dele. Af diagrammet fremgik det eksempelvis, at der skulle drikkes øl under hele processen ... til stor morskab for publikum.

Som eksempel på, hvordan Labview gennem årene har fået en udvidet målgruppe, så nævnte Kodosky Lego’s Mindstorm-systemer, som bygger på Labview, og, hvor børn og unge (og voksne) kan kode robotter via et grafisk miljø på en computerskærm - og altså uden at skulle skrive kodelinjer.

Kodosky nøjedes ikke med at fremhæve Labview, han havde flere kommentarer omkring tekstbaseret kodning, når det eksempelvis kommer til programmering af flerkernede systemer og kodning via touchskærme, hvor det, som flere nok vil vide, kan være en tur op ad bakke at skulle skrive længere tekster.

»Denne nye teknologi gør tekstland mere og mere irrelevant og uddateret,« sagde Kodosky.

Labviews håndtering af flerkernede processorer fungerer ved, at brugeren visuelt trækker linjer for de processor, der skal forløbe parallelt, så der eksempelvis er tre sideløbende linjer. Når programmet bliver kompileret, så sørger Labview eftersigende for, at processor, der visuelt ligger parallelt, bliver delt ud på forskellige kerner, alt afhængig af hardwarekonfigurationen.

Under den sidste præsentation i forbindelse med keynote-seancen optrådte forskningsdirektør for LabView ved NI David Fuller med et gigantisk touch-interface, som han behændigt trak linjer og bokse rundt på. Og budskabet i forhold til den øvelse var ganske klart, da David Fuller sagde med henvisning til Labview:

»... det mest touchscreen-klare sprog på planeten.«

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (7)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Steen Krøyer

Spm: Hvorfor skal vi ikke bare smide vores traditionelle tekstbaserede programmeringssprog ud og bruge Labview eller lignende? Svar: Af samme årsag som gør at vi ikke bare smider al tekstbaseret kommunikation ud og erstatter det med tegneserier. Tekst og grafik er to forskellige medier, hver med deres stærke og svage sider, og sjovt nok virker det mange gange bedst hvis de kombineres. Alle der har prøvet at bruge Labview i Lego-udgaven, ved at lige så snart man prøver at udtrykke bare lidt komplicerede løsninger, bliver resultatet hurtigt håbløst kompliceret, Hvorfor bruge 47 bokse, hver med deres tekstbaserede (!) attributter, forbundet med 27 forbindelser, når det hele kunne udtrykkes i 14-15 linier koncis kode.

  • 8
  • 0
#3 Anders Munch

»... det mest touchscreen-klare sprog på planeten.«

Jeg tror ikke på at man kan betjene LabView via en berøringsfølsom skærm: Grafisk programmering kræver en finkontrol som sådan en ikke har. Selv den simpleste funktion bliver jo til et mylder af kasser og streger, og det skal man kunne styre med en fed tommelfinger? No way.

"... optrådte forskningsdirektør for LabView ved NI David Fuller med et gigantisk touch-interface ..."

Nøgleord: Gigantisk. Et legetøjsproblem og en gigantisk skærm, så kan det sikkert godt lade sig gøre.

I øvrigt er kryds-compileren opfundet. Og bluetooth-tastaturet.

  • 0
  • 0
#5 Lars Tørnes Hansen

@Steen Krøyer

Som den forretningmand Jeff Kodosky er, prøver han naturligvis at få langet nogle LabView æsker over bordet - det er vel også ok.

Nu er bare sådan at du har har ret!

Det er ikke alt der egner sig at programmeres grafisk, mens andre ting måske var bedre lavet med bedre hjælp fra en mere avanceret grafisk brugergrænseflade, end bare en editor med/uden syntax opmærkning. De fleste ting klares dog fint i tekst, synes jeg.

Jeg vil mene at Jeff Kodosky snakker om er "Language Oriented Programming", som jeg har prøvet at lave til et robot projekt - og det virker ganske udmærket.

Language oriented programming (LOP) is a style of computer programming in which, rather than solving problems in general-purpose programming languages, the programmer creates one or more domain-specific languages for the problem first, and solves the problem in those languages

Concept The concept of Language Oriented Programming takes the approach to capture requirements in the user's terms, and then to try to create an implementation language as isomorphic as possible to the user's descriptions, so that the mapping between requirements and implementation is as direct as possible. A measure of the closeness of this isomorphism is the "redundancy" of the language, defined as the number of editing operations needed to implement a stand-alone change in requirements. It is not assumed a-priori what is the best language for implementing the new language. Rather, the developer can choose among options created by analysis of the information flows — what information is acquired, what its structure is, when it is acquired, from whom, and what is done with it.

fra: http://en.wikipedia.org/wiki/Language-oriented_programming

Fra overnævnte side er der 3 links jeg gerne vil fremhæve, og det er: "Martin Ward's original paper that coined the term": http://www.cse.dmu.ac.uk/~mward/martin/papers/middle-out-t.pdf "Sergey Dmitriev's paper that further explored the topic": http://www.onboard.jetbrains.com/articles/04/10/lop/ og "Martin Fowler's article describing both the concept and tools that support it": http://www.martinfowler.com/articles/languageWorkbench.html

Jeg har anvendt det i et robotsystem. Det er dog først senere at jeg opdagede at vi rent faktisk havde brugt LOP. Da vi besluttede at bruge LOP gik projektet meget hurtige end før.

At lave et programmeringssprog lyder meget svært, og noget som tager lang tid, men fakta er at det tog mig 3 dage at lave sproget til en robotstyring der sorterer ting.

Jeg lavede en grammatik beskrevet i EBNF (Extended Backus-Naur Form), der beskrev sproget, og fodrede den til Coco/R parser generatoren, som lavede en leksikalsk analysator (lexer) og en LL(1) syntax-drevet parser, tilbage var så at bygge en fortolker uden om lexeren og parseren, og lave de semantiske aktioner, der skal køres, når parseren har genkendt en sætning.

Det smarte i at have en fortolker kom fra at vi havde både et IDE, og at vi skal kunne afvikle programmer. I IDEet, kunne man trin for trin programmere robotten, og det var ikke, med tekst, men med animeret billede, knapper etc. Da inputvalidering foretages af den leksikalske analysator og parseren i fællesksab, lavede vi simpelthen bare en tekststreng, med uvalideret tekst som så blev fyret at til fortolkeren, når en funktion skulle køres via IDEet. Var der fejl kom der brok fra fortolkeren, og vi viste så en fejl i IDEet. Den kan også afvikle programmer, hvilket bare var en ren-tekst fil.

Med de to måde havde vi netop 2 isomoforiske repræsentationer af den samme ting.

CoCo/R http://en.wikipedia.org/wiki/Coco/R http://ssw.jku.at/Coco/ CoCo/R selv er GPL licenseret, men da den genererer kode på baggrund af en grammatik du har lavet, og som ikke kræver et runtime, er den genererede kode naturligvis ikke omfattet af GPL licensen.

  • 0
  • 0
#6 Torben Mogensen Blogger

Man kan generelt overføre mere information pr. minut med et tastatur end med en trykfølsom skærm eller med museklik, så alt andet lige er visuel programmering langsommere end programmering med tastatur. Derudover er det nemmere at søge i en tekstfil end i et stort diagram. Visuel programmering vil dog have sin plads som sprog for ikke-programmører, der skal lave små programmer i domænespecifikke sprog.

Men der er bestemt mulighed for at udnytte flere visuelle elementer end rå ASCII tekst uden at gå over til ren "kasser og pile" programmering. F.eks. kunne man med fordel bruge subscript og superscript og flere tegn end ASCII eller ISO 8859-1. Med tastegenveje behøver det ikke at være voldsomt tidskrævende.

  • 0
  • 0
#7 Lars Bengtsson

Joe, jeg / vi lever også i en duftende, biologisk og musikalsk verden, så hvorfor ikke programmere med el-guitar eller panfløjte eller gensplejsning? :-) Kodosky, argumentet holder ikke. Det lyder lidt som om at målgruppen for udtalelsen er ledelsen og ikke teknikkere.

@ Torben Mogensen Det lyder sandsynligt, det du siger om overførsel af information; men så simpelt er det vel heller ikke. Når jeg programmerer, så bruger jeg et IDE hvor det er en kombination af museklik i GUI elementer, scroll i teskt og markering af tekst med mus, som øger produktiviteten i forhold til ren tastur betjening. Man kunne jo godt forestille sig at mennesker vil kunne lære at producere mere kvalitetskode med andre medier end ren tekst.

Desuden så kan man argumentere for at nogle problemer og mennesker tænker mere effektivt hvis det er et grafisk "sprog". Både i matematik og datalogi undervisning bruger man jo også grafiske elementer, fx tegninger af mængder, træer og kurver (funktioner).

Men indtil videre så tror jeg at der er så meget at hente ved at forbedre de rene tekst baserede programmeringssprog at der vil gå en del tid inden alternative repræsentationer vil overhale dem.

  • 1
  • 0
Log ind eller Opret konto for at kommentere