I en serie blogginnlegg forrige uke detaljerte Microsoft grunnleggende endringer i hvordan de utvikler .NET-språkene. Det var gode nyheter for C # og F # -utviklere, men mens Microsoft satte en positiv vri på hva endringene betydde for Visual Basic, virker den ærverdige språkets langsiktige fremtid mindre sikker.
Microsofts Visual Basic har lenge vært en av verdens, om ikke favoritter, så absolutt et av de mest brukte språkene, og det satte Microsoft sentralt i virksomhetsscenen. Fra de første seks iterasjonene som et språk for utvikling av klientserverapplikasjoner til gjenfødelsen som en del av .NET-plattformen, har Visual Basic vært verktøyet for rask utvikling av bedriftsapplikasjoner. Det er delvis på grunn av det enorme biblioteket med brukergrensesnittkomponenter, sammen med kontakter til vanlige databaser og en komponentmodell som gjør det mulig for tredjeparter å bygge bedrifter på å tilby ekstra funksjonalitet.
Byttet til .NET som grunnlaget for Microsofts utviklingsstrategi var fornuftig for nye språk som C #, men det betydde endringer i Visual Basic der koden ikke lett kunne migrere fra den gamle Visual Basic til den nye VB.NET.
Det var en utfordrende overgang for utviklere, og Visual Basic begynte å miste andelen i bedriftsutviklingen — og i Microsoft. Likevel lovet Microsoft å holde C # og VB.NET synkronisert. Funksjoner opprettet for C # vil bli en del av Visual Basic, de to språkene utvikler seg sammen. Årsaken var at de ofte ble brukt til samme oppgave og hadde samme underliggende natur: begge sterkt typte, objektorienterte språk som arbeidet med de samme verktøyene.
Visual Basic og C #: En ny divergens kommer
Med kunngjøringen fra forrige uke er denne evolusjonen borte. Microsoft vil la de to språkene gå forskjellige måter, og starter med Visual Basic 15 som snart skal utgis.
Det er ikke en overraskende skilsmisse. C # 's popularitet har vokst med stormskritt, mens Visual Basic sakte har glidd nedover i tabellene, og nesten forsvunnet fra radaren til populære programmeringsspørsmål som Stack Overflow. Brukstilfeller endres også: Visual Basic er fortsatt fokusert på det opprinnelige klient-server-paradigmet, mens C # har blitt et verktøy for n-nivå nettbaserte applikasjoner, jobber i skyen og i lokalene. Med flere og flere apper bygget for å fungere med nettet og skyen, er det ikke overraskende at C # blir førstevalget for mange prosjekter.
Det er også endringer i hvordan språkene utvikles. C # har skiftet til en åpen designmodell, noe som betyr at brukerne er i førersetet for å prioritere nye funksjoner, takket være en aktiv adresseliste og et offentlig GitHub-lager. Microsoft har allerede tatt nye funksjoner fra utenfor selskapet - en stor endring fra sine tradisjonelle språktekniske prosesser som fokuserte på forskningsgruppene og interne produktledelsesteam.
Visual Basic har også en åpen designmodell, men den har andre prioriteringer enn C #. Den støtter allerede en delmengde av C #s funksjoner i sine nåværende bygg som en del av utgivelseskandidaten til Visual Studio 2017.
Når C # fortsetter å avvike fra Visual Basic, skal vi se at de to språkene utvikler seg hver for seg, selv om de burde være i stand til å samarbeide. Begge skal fortsatt adressere de samme .NET API-ene, og begge vil fortsatt være en del av Visual Studio-verktøyene.
Hva disse endringene betyr for bedriftsutviklere
For øyeblikket er det veldig lite for bedrifter å gjøre med denne kommende avviket.
Men i fremtiden er det absolutt rom for plattformarbeid i Visual Basic, ettersom det beveger seg til å støtte .NET Standard-settet med baseklassebiblioteker sammen med det kjente .NET Framework. Selv om noen koder vil være bærbare, vil ikke alle Visual Basic-koder kunne hoppe fra ett sett med biblioteker til et annet mindre sett. Det er sannsynlig at eksisterende kode vil forbli utelukkende på Windows og rent i lokale applikasjoner.
Som utvikler må du velge mellom å bringe Visual Basic-kode til nyere plattformer via .NET Standard eller flytte til språk som C # som tilbyr et bredere utvalg av målrammer og enheter.
Fordi .NET Standard er ment for alle .NET-plattformer, er det en viktig equalizer. Det er imidlertid ikke nødvendig for alle .NET-språk. Selv om Visual Basic trenger det på systemer som ikke har hele .NET Framework, vil C # kunne adressere plattformer som .NET Core direkte og få tilgang til API-ene. Det gjør det også lettere for C #-derivater, som Unity, å støtte sine egne spesialiserte API-er.
C # med støtte for .NET Framework på Windows og åpen kildekode. NET Core (som kjører på Nano Server og i containere) blir førstevalget for sky og for mobilapplikasjoner, mens F # funksjonell programmeringsmodell vil være ideell for finansielle tjenester. og applikasjoner som er avhengige av maskinlæring.
En tydelig driver for disse endringene er Microsofts Xamarin-oppkjøp. Microsoft trenger et verktøyverktøy på tvers av plattformer for å støtte et bredere spekter av mobile enheter, med Windows Mobile som ikke klarer å oppnå markedsandeler som håpet. Selv i Windows Mobile-vennlige geografiske områder som Storbritannia har iOS og Android tilsammen mer enn 80 prosent av markedet. Microsoft-utviklere som ønsker å bygge mobile frontender for applikasjonene deres, må bruke verktøy som Xamarin for å målrette mot de dominerende mobile plattformene.
Med Xamarin som fokuserer på C #, må Microsoft gjøre det klart at C # er førsteklasses .NET-språk fremover. Selv om det ikke er eksplisitt i Microsofts nylige språk kunngjøringer, er det sterkt underforstått.
Hvordan du skal administrere din bedrifts språkstrategi
Dette er ikke et farvel med Visual Basic, men det er på tide å gjøre status over hvor du er og hvor du vil være. Eksisterende Visual Basic-applikasjoner kan fortsette å utvikles, men etter hvert som den underliggende .NET-plattformen utvikler seg, bør du forvente at bare en delmengde .NET API-er skal være tilgjengelig for Visual Basic-utviklerne. Selv om det sannsynligvis ikke vil være et problem på kort sikt, bør du forberede deg på en langsiktig overføring til C # eller F #, spesielt hvis du planlegger å bruke mobilopplevelser eller plattformoverskridelser for applikasjonene dine.
Det virker klart at det beste alternativet for å unngå overheng av teknisk gjeld er å gjøre C # din prioritet for ny utvikling. C # har førsteklasses støtte og en brukerdrevet designmodell. Det er også hjertet av Microsofts plattformutvikling og Universal Windows-plattformen. Det betyr at du kan skrive forretningslogikk en gang, og deretter levere tilpassede brukeropplevelser for nettet, Windows 10, iOS, Android og MacOS. Det er også nok språkfelles for at utviklere skal være i stand til å gjøre overgangene relativt enkelt, og plukke opp nye funksjoner etter første opplæring.
