I en række blogindlæg i sidste uge detaljerede Microsoft grundlæggende ændringer i, hvordan de udvikler sine .NET-sprog. Det var en god nyhed for C # og F # -udviklere, men mens Microsoft satte et positivt spin på, hvad ændringerne betød for Visual Basic, synes det ærværdige sprogs langsigtede fremtid mindre sikker.
Microsofts Visual Basic har længe været en af verdens, hvis ikke favoritter, så bestemt et af de mest anvendte sprog, og det satte virkelig Microsoft i centrum for virksomhedsfasen. Fra de første seks iterationer som sprog for klient-server applikationsudvikling til dets genfødsel som en del af .NET-platformen har Visual Basic været værktøjet til hurtig udvikling af virksomhedsapplikationer. Det skyldes til dels det enorme bibliotek af brugergrænsefladekomponenter sammen med stik til almindelige databaser og en komponentmodel, der giver tredjeparter mulighed for at bygge virksomheder på at levere yderligere funktionalitet.
Skiftet til .NET som grundlaget for Microsofts udviklingsstrategi gav mening for nye sprog som C #, men det betød ændringer i Visual Basic, hvor koden ikke let kunne migrere fra den gamle Visual Basic til den nye VB.NET.
Det var en udfordrende overgang for udviklere, og Visual Basic begyndte at miste andelen inden for forretningsudvikling - og inden i Microsoft. Alligevel lovede Microsoft at holde C # og VB.NET synkroniseret. Funktioner oprettet til C # bliver en del af Visual Basic, hvor de to sprog udvikler sig sammen. Årsagen var, at de ofte blev brugt til den samme opgave og havde den samme underliggende natur: begge stærkt typede, objektorienterede sprog, der arbejder med de samme værktøjer.
Visual Basic og C #: En ny divergens kommer
Med sidste uges meddelelse er denne co-evolution væk. Microsoft vil lade de to sprog gå forskellige måder, startende med den snart udgivne Visual Basic 15.
Det er ikke en overraskende skilsmisse. C # 's popularitet er vokset med stormskridt, mens Visual Basic langsomt er faldet ned på hitlisterne og næsten forsvundet fra radaren på populære programmeringsforespørgselssteder som Stack Overflow. Brugssager ændrer sig også: Visual Basic er stadig fokuseret på sit oprindelige klient-server paradigme, mens C # er blevet et værktøj til n-tier webbaserede applikationer, der arbejder i skyen og lokaler. Med flere og flere apps bygget til at arbejde med internettet og skyen er det ikke overraskende, at C # bliver det første valg for mange projekter.
Der er ændringer i, hvordan sprogene også udvikles. C # er skiftet til en åben designmodel, hvilket betyder, at brugerne sidder i førersædet for at prioritere nye funktioner takket være en aktiv mailingliste og et offentligt GitHub-lager. Microsoft har allerede taget nye funktioner uden for virksomheden - en stor ændring fra sine traditionelle sprogtekniske processer, der fokuserede på dets forskningsgrupper og interne produktstyringsteams.
Visual Basic har også en åben designmodel, men den har forskellige prioriteter end C #. Det understøtter allerede et undersæt af C # 's funktioner i dets nuværende builds som en del af frigivelseskandidaten til Visual Studio 2017.
Da C # fortsætter med at afvige fra Visual Basic, vil vi se de to sprog udvikles separat, selvom de skulle være i stand til at arbejde sammen. Begge skal stadig adressere de samme .NET API'er, og begge vil stadig være en del af Visual Studio-værktøjerne.
Hvad disse ændringer betyder for forretningsudviklere
I øjeblikket er der meget lidt for virksomhederne at gøre ved denne kommende divergens.
Men i fremtiden er der bestemt mulighed for tværplatformsarbejde i Visual Basic, da det bevæger sig til at understøtte .NET-standardsættet med baseklassebiblioteker sammen med det velkendte .NET Framework. Selvom nogle koder vil være bærbare, vil ikke alle Visual Basic-koder være i stand til at springe fra et sæt biblioteker til et andet mindre sæt. Det er sandsynligt, at eksisterende kode forbliver udelukkende på Windows og udelukkende i lokale applikationer.
Som udvikler bliver du nødt til at vælge mellem at bringe Visual Basic-kode til nyere platforme via .NET Standard eller flytte til sprog som C #, der tilbyder en bredere vifte af målrammer og enheder.
Da .NET Standard er beregnet til alle .NET-platforme, er det en vigtig equalizer. Det er dog ikke nødvendigt for alle .NET-sprog. Selvom Visual Basic har brug for det på systemer, der ikke har den fulde .NET Framework, vil C # være i stand til at adressere platforme som .NET Core direkte og få adgang til dets API'er. Det gør det også lettere for C #-derivater, som Unity, at understøtte deres egne specialiserede API'er.
C # med understøttelse af .NET Framework på Windows og open source. NET Core (kører på Nano Server og i containere) bliver det første valg til cloud og til mobilapplikationer, mens F # funktionel programmeringsmodel vil være ideel til finansielle tjenester og applikationer, der er afhængige af maskinlæring.
En klar driver for disse ændringer er Microsofts Xamarin-erhvervelse. Microsoft har brug for et værktøjssæt på tværs af platforme til at understøtte en bredere vifte af mobile enheder, hvor Windows Mobile ikke opnår virksomhedens markedsandel som håbet. Selv i Windows Mobile-venlige geografiske områder som Storbritannien har iOS og Android tilsammen mere end 80 procent af markedet. Microsoft-udviklere, der ønsker at bygge mobile frontendere til deres applikationer, skal bruge værktøjer som Xamarin til at målrette mod de dominerende mobile platforme.
Da Xamarin fokuserer på C #, skal Microsoft gøre det klart, at C # er det første klasses .NET-sprog fremadrettet. Selvom det ikke er eksplicit i Microsofts nylige sprogmeddelelser, er det stærkt underforstået.
Hvordan du skal styre din virksomheds sprogstrategi
Dette er ikke et farvel med Visual Basic, men det er tid til at gøre status over, hvor du er, og hvor du vil være. Eksisterende Visual Basic-applikationer kan fortsat udvikles, men efterhånden som den underliggende .NET-platform udvikler sig, bør du kun forvente, at et undersæt af. NET API'er er tilgængelige for dine Visual Basic-udviklere. Selvom det sandsynligvis ikke vil være et problem på kort sigt, skal du forberede dig på en længerevarende migration til C # eller F #, især hvis du planlægger at bruge mobile eller platforme-brugeroplevelser til dine applikationer.
Det synes klart, at den bedste mulighed for at undgå overhæng af teknisk gæld er at gøre C # din prioritet til nyudvikling. C # har førsteklasses support og en brugerdrevet designmodel. Det er også hjertet i Microsofts udvikling på tværs af platforme og dets Universal Windows Platform. Det betyder, at du kan skrive forretningslogik en gang og derefter levere brugerdefinerede brugeroplevelser til internettet, Windows 10, iOS, Android og MacOS. Der er også tilstrækkeligt sprogligt fælles, at udviklere skal være i stand til at foretage overgange relativt let og opfange nye funktioner efter den indledende træning.
