bloghoved rene løhde

VB 9 - mit nye programmeringssprog

I uge 39 tog jeg til Århus for at deltage i JAOO. Søndag havde jeg en super middag bl.a sammen med V2 co-bloggers Therese, Anne-Sofie og Tommy...og det blev lidt sent i Lenios fede lokaler...

Nå, men JAOO startede så rigtigt mandag og jeg skal ikke fortælle om de sessioner jeg var til ' det har flere allerede gjort bedre under arrangementet blandt andet på V2 bloggen. Jeg er lidt ærgerlig over at jeg ikke var til Gilad Brachas præsentation som flere fortæller mig var 'the-thing-to-watch' på dette års JAOO ' heldigvis var Charles fra det Scoble profilerede Channel9 tilstede på JAOO og fik et interview.

Der dog andre ting under JAOO, som fik min fulde opmærksonmhed f.eks Erik Meijers 'Linq to Xml' snak. Den er allerede omtalt på V2 JAOO bloggen af Kåre Kjellstrøm fra Silverbullet ' Kåre er tydeligvis skræmt af sammenblandingen af kode og XML ' måske med god grund - jeg fik dog straks fik den indskydelse at det måtte jeg simpelthen prøve, det der!

VB9 og LINQ2XML

Så her følger min første Visual Basic 9 øvelse ' stærkt inspireret af Erik præsentation under JAOO. Han har en præsentation på Channel9, som ligner det han viste på JAOO.

For at prøve de muligheder VB9 og Linq to XML giver mig vil jeg sætte mig for at lave en transformation mellem to dokumenter. Ikke noget revolutionerende i det. Nogle vil sige at et sådan process i virkeligheden er det en webservice er sat i verden til at gøre ' 1 stykke xml går ind og et andet xml dokument kommer ud. Traditionelt er det noget om udviklere kigger mod forskellige DOM implementeringer til at få løst ' eller hvis man er rigtig cool ? XSLT.

Jeg har aldrig været rigtig gode venner med XSLT ' jeg har dog været så heldig at have haft super kollegaer i forskellige virksomheder, som har været super til XSLT og har givet mig en så gelinde indførelse at jeg mener at kunne skrive XSLT til husbehov. Jeg ender dog for det meste med at skulle lave et DOM objekt og lave en transformation via et 'navigationsobjekt? til et resulterende DOM objekt. Det er meget besværligt. Jeg ved ikke om Java, PHP, Ruby udviklere har det nemmere end .Net udviklere, men tror at det generelt er besværlig at lave XML transformation hvis ikke man er nogenlunde habil i XSLT.

Alternativt findes der med .Net 3.5 en mulighed med VB 9 og Linq to XML, som samtidigt lige skraber i overfladen af nogle af de muligheder som Linq bidrager med og jeg vil forsøge at illustrere dette i følgende lille øvelse.

Først laver jeg den datastruktur jeg vil transformere fra ? denne er repræsenteret i et Xml Schema:

Illustration: Privatfoto

Figur 1

Hvis man ikke har mod på at skrive sit schema i hånden findes der et utal af værktøjer som kan udarbejde et Xml Schema fra en Xml instans ' dvs. hvis man har et xml dokument og gerne vil have det tilsvarende schema som skal kunne validere xml dokumentet kan en række værktøjer 'reverse engineer' dokumentet ' dette gælder også for Visual Studio 2008 som jeg bruger nedenfor.

Umiddelbart virker det som lidt unødigt overhead at skulle bruge et schema til en simpel transformation, men bær over med mig ? der er mening med galskaben. På figur 2 ses et uddrag af noget kode i tekst editoren i Visual Studio 2008.

Der er tale om et Visual Basic project hvor der udover noget VB kode
er tilknyttet ovenstående Xml Schema. I den ses en 'import' ? noget som typisk er kunne være .Net namespace, men i dette tilfælde er der tale om et xml namespace. Faktisk det namespace som bruges i figur 1.

Figur 2

Som følge af denne import bliver mit IDE nu bekendt med de typer som er erklæret i 'renesns'-namespace og heraf kan mit IDE nu tilbyde mig intellisense. Dette kan ses af det LINQ udtryk, som skal returnere til 'mineKontakter'.

Med min nye intellisense på xml i LINQ udtryk får jeg mulighed for at lave min simple transformation. Jeg laver først det dokument ' 'Adressent? - som jeg skal transformere. Jeg kunne have indlæst det fra en fil, men for at være en smule pædagogisk og for at skabe lidt overblik laver jeg det hele inline.

Dernæst instantieres den 'collection' som det resulterende transformerede dokument skal skrives til ' 'mineKontakter'. Herefter vælges data fra det originale dokument ud og skrives ind i et nyt xml dokument via et LINQ udtryk. ...og ja, jeg ved godt hvad du kære læser tænker ' 'hvad er det med de tre prikker'?.

Jeg kiggede også noget første gang jeg så det. Erik Meijers forklaring' ' de som er bekendt med .Net (og andre platforme og sprog) ved at '.' er taget til noget andet (properties, metoder etc.), mens to prikker '..' typisk er noget man forbinder med directory navigering på et filsystem/drev ' så tre prikker blev altså syntax'en i VB9, for at få fat på enten et xml element eller attribut.

Her min VB9 kode for den simple transformation i en konsol applikation: 

Figur 3

Den resulterende konsol output for koden kan ses på figur 4.

Figur 4

Jeg er sikker på at andre udviklere, ligesom Kåre, kan se problemer i at binde et sprog så tæt til et andet, men for nu kan jeg kun se en kæmpe produktivitetsforøgelse ved at kombinere VB 9 og Linq to XML. Men hvad med mit fortrukne sprog ' C#' For de fleste sprog skrevet til Common Language Infrastructure (CLI) i .net vil man typisk forvente at hvis en feature er til stede i et sprog vil den samme feature typisk enten samtidigt eller hurtigt efter finde vej til andre sprog ' specielt hvis sprogene begge udsprang af samme virksomhed ' som det er tilfældet med C# og VB.

Betyder det så at denne direkte manipulering af xml i VB også vil finde vej til C#' Til det svarede Erik Meijer at Anders Hejlsberg ikke på nuværende tidspunkt ville have Xml bygget ind som en intergreret af 'sit? sprog. Meijers tolkning af Hjelsbergs begrundelse var blandt andet at C# specificationen ville blive sårbar med en direkte afhængighed af XML og XMLs følgeteknologier.

Se iøvrigt http://www.tiobe.com/tpci.htm for oktober 2007 - jeg er åbenbart ikke den eneste, som har kastet min kærlighed på VB på det seneste :-)

Kommentarer (13)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#2 Rune Juhl-Petersen

Jeg har aldrig helt forstået eksistens berettigelsen for VB.Net. Eller sagt på en anden måde, berettigelsen ligger i salgs øjemed. Hvorfor er det vi skal have to sprog der i princippet kan det samme? Hvorfor er det at vi skal have kæmpe tykke bøger, fordi der er eksempler i flere forskellige sprog. Er VB.Net ikke den dødfødte tvilling vi alle venter på bliver bortopereret.

Nå :) Flere muligheder for at gøre det nøjagtigt samme øger kompleksiteten, men tilfører ikke mere funktionalitet. Hvem vil have det? Hvis der kun var et sprog MS skulle koncentrere sig om kunne det også være at VS.Net ville komme lidt op på beatet i forhold til Java IDE’er

  • 0
  • 0
#3 Mikkel Meyer Andersen

Måske er det fordi, at Bill Gates og Paul Allen lavede en BASIC-fortolker som det første produkt i deres nystartede firma, Micro-Soft? (Det hed det rent faktisk i starten.)

Derudover er der den forskel, at C# er lavet decideret til .NET, hvor VB er blevet "tilpasset" det, så at sige. Hvis man er interesseret, kan man læse: http://en.wikipedia.org/wiki/Comparison_of_C_sharp_and_Visual_Basic_.NET... og http://support.microsoft.com/kb/308470

  • 0
  • 0
#4 Lars Wive Marcussen

Jeg læste at XSL var svært forståeligt. Min erfaring er at det er typisk for folk der aldrig har lært funktions-sprog, som XSL tilhører. Men når jeg ser på den ovenstående kode begynder jeg allerede nu at frygte når jeg om to år bliver sat til at rette noget en tidligere konsulent/ansat har lavet, hvor at data er blandet ind i koden så jeg skal søge efter mange staeder at rette lidt, fordi man nu vil skrive adresser lidt anderledes. Denne funktionalitet lægger op til en god gammel anti-pattern med ikke at holde logik og data klart adskilt.

  • 0
  • 0
#5 Kåre Kjelstrøm

Hehe. Der skal mere til at skræmme mig end en smule oversukret Visual Basic syntaks, men jeg må indrømme at det krævede en hel del kaffe at skylle den sukkerbombe ned og jeg har ikke siden haft trang til mere.

Jeg er helt enig med Anders Hejlsberg. Man bør forvalte et programmeringssprog med en vis forsigtighed så det ikke får akut feature-creep hver gang en ny trend skyller ind over branchen. I min optik er der stor forskel på den form for sprog-mix, xml.net'ish vi ser her og beslutningen om at introducere generics i .NET 2.0. Sidstnævnte var en relevant konstruktion, der gør koden mere elegant.

Måske Microsoft skulle nedsætte et sprognævn?

  • 0
  • 0
#6 René Løhde

...og jeg har det også svært med funktionelle sprog, men det må jeg jo bare se at få lavet om på når nu F# kommer.

Lars, jeg mener ikke at der er noget i denne funktionalitet som rammer det anti pattern du skriver om. Jeg kan sagtens trække data ud af min kode. Jeg har kun sat den derind for at vise koden/data inline.

Jeg håber at mange kan lave den abstraktion.

Hr. Kjelstrøm,

Er vi ikke bare i en situation hvor du ikke ved hvad der er godt for dig! Jeg tror at du er forsmået af alle dine konsulentopgaver og ikke får nok sprogligt sukker.

Nå, spøg til side...

Hvis jeg skal gætte mig til hvad Meijer ville sige til din bemærkning om "...hver gang en ny trend skyller ind over branchen" så ville det være at xml nu er 10+ år på bagen ikke kan betegnes som ny - eller hvad!??

  • 0
  • 0
#9 Mikkel Høgh

Jeg tror det Dennis refererer til er den praksis at man er begyndt at bruge XML indadtil i sine programmer hvor man ellers ville bruge noget simplere. Af en eller anden årsag er det blevet vildt populært at sovse alting ind i XML, specielt bland Java-programmører.

"Some people, when confronted with a problem, think "I know, I'll use XML." Now they have two problems." - Phillip J. Eby

  • 0
  • 0
#11 Dennis Krøger

Hehe, hvis du er sød ved dig selv, lader du være ;)

Nej, Flex er sådan set ok, og XML kan bruges til lynhurtigt at fortælle komponenterne om indhold (Adobe har en sample, med en Flex RSS reader på ganske få linier), men lige så snart man skal lave noget lidt mere end simpelt, bliver det fuldstændigt sindsygt at arbejde med, hvis man ikke får lagt XML'en af ved døren.

Problemer er, at man nærmest får at vide at det er best practice at lade alle sine interne datastrukturer være tæt knyttet til XMLen, og så varer det ikke længe før man vader rundt i tjære til halsen, fordi hele ens system er så afhængigt af at eksterne data ikke ændrer sig.

Jeg ved ikke om scenariet er det samme i MS verdenen, men grunden til at jeg "råbte op", er at det meget ligner Adobe's egne 'Woohooo, se vi kan lege med XML overalt', og så kan jeg mærke hovedpinen komme snigende lige så stille... ;)

  • 0
  • 0
#13 Kåre Kjelstrøm

Nu er jeg jo konsulent og ikke evangelist og vi tager vores kaffe sort, no cream, no sugar ... ;-)

XML repræsenterer jo bare ét modelsprog som LINQ kan foretage forespørgsler i. Følger man den trend der er udstukket med at tillade XML direkte i VB koden bliver det næste vel en CSV binding ... How nice would that be!

Jeg skal ikke udelukke at der kan findes andre end dig der synes det er nyttigt, René, men jeg vil personligt hellere arbejde med et sprog hvor den slags udvidelser foretages via SPI/API abstraktioner.

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