Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 58 reacties
Bron: Builder UK

Microsoft zal aan het einde van deze maand de standaardondersteuning voor Visual Basic (VB) 6 stopzetten. Dit betekent dat er geen kritische updates voor de software zullen worden vrijgegeven en dat het niet langer mogelijk is om gratis ondersteuning te krijgen bij problemen. Beide diensten zal het softwarebedrijf nog drie jaar tegen betaling blijven aanbieden. Een groot aantal van Microsofts Most Valuable Professional (MVP)-ontwikkelaars zou het echter op prijs stellen als het bedrijf de standaardondersteuning op de huidige wijze zou blijven uitvoeren en de taal zou blijven ontwikkelen naast Visual Basic .NET, de taal die door Microsoft als opvolger is gepositioneerd. Om dit te bereiken, hebben de ontwikkelaars een petitie online gezet. De petitie is al ondertekend door meer dan 200 MVP's.

De ondertekenaars hopen dat Microsoft door de petitie zal besluiten een nieuwe versie van VB binnen de Visual Studio IDE te ontwikkelen. Deze versie zou, in tegenstelling tot VB.NET, volledig compatibel moeten zijn met VB 6 en heeft als mogelijke naam VB.COM meegekregen. Deze VB-versie moet compileren naar native code, wat zou betekenen dat binnen Visual Studio zowel een managed als unmanaged versie van VB aanwezig zal zijn, respectievelijk VB.NET en VB.COM. Dit is nu ook het geval voor unmanaged C++ en managed C#. Door ondersteuning voor beide talen toe te voegen aan de IDE en het .NET-framework zou interoperabiliteit tussen de talen eenvoudiger te bereiken moeten zijn, en ontwikkelaars zouden gemakkelijker kunnen overstappen naar een andere .NET-taal.

Microsoft heeft in 2000 VB.NET geïntroduceerd. Veel VB6-programmeurs zijn sindsdien overgestapt op andere talen, waaronder VB.NET en Java. Een van de bezwaren die de (voormalige) VB6-ontwikkelaars tegen VB.NET hebben, is de steile leercurve. VB.NET is in feite een compleet nieuwe taal, waardoor het vrijwel onmogelijk is om VB6-applicaties 1-op-1 over te zetten. Hier staat echter tegenover dat de idee van softwareontwikkeling in iedere programmeertaal gelijk is, waardoor het leren van een nieuwe taal over het algemeen niet zo moeilijk is als het doorgronden van programmeerconcepten. Daar komt bij dat VB.NET en andere .NET-talen technologisch gezien beter op de toekomst zijn voorbereid dan VB6, zo meent Jez Higgins, ontwikkelaar en tegenstander van de genoemde petitie.

Moderatie-faq Wijzig weergave

Reacties (58)

Als je dit soort verhalen leest kan je inderdaad maar beter met QT, Java of Python werken...

Sowieso ben je met een Open Source programmeer taal (dwz een taal met open source compiler / interpreter) beter af, omdat het voortbestaan ervan niet afhangt van 1 enkel bedrijf.
Of dat zo is durf ik niet te onderschrijven, kijk bijvoorbeeld eens naar PHP. Ook bij een major update van PHP gaan er dingen kapot, of ze werken niet meer. En PHP4 zal niet tot in den treuren onderhouden worden, dus ook daar zal je moeten migreren, ondanks dat PHP opensource is :)
Zelfs voor PHP3 worden er (door derden) nog steeds security fixes gedaan. Bij VB6 is dat onmogelijk. Dat is het verschil tussen open en closed source natuurlijk...
C# is een iso standaard dacht ik, wat toelaat dat jij, als je het kan, zelf een compiler maakt morgen (zie naar Mono)
Als je dit soort verhalen leest kan je inderdaad maar beter met QT, Java of Python werken...
Binnenkort zal Qt3 vervangen worden door Qt4, wat in zal houden dat iedereen zijn code zal moeten aanpassen aan de vernieuwde API. Ben wel met je eens dat Qt heel goed is (zelf zeer fan van, en zie ook niet op tegen Qt4), maar denken dat deze API's helemaal stabiel zijn is waanzin. ;)
Tja, Microsoft probeert natuurlijk zo veel mogelijk mensen naar het .NET platform te krijgen. Zo hoeven ze niet zo veel verschillende spullen te onderhouden.
Ergens vind ik dat VB6 ontwikkelaars niet zo moeten huilen. Als serieus ontwikkelaar moetje ook met je tijd meegaan en zorgen dat je tenminste op de hoogte bent van globale ontwikkelingen van andere/nieuwe talen. (Ik bedoel natuurlijk niet dat je dan meteen de sterren van de hemel moet kunnen programmeren.) En als je (goed) kunt programmeren, is het leren van een nieuwe taal niet zo heel moeilijk.
Mijn c++, java, javascript en basic (brr) code ziet er qua opbouw redelijk gelijk uit. Alleen de woordjes en puntkomma's verschillen. .NET dwingt je als ontwikkelaar ook netter te programmeren en dat (die dwang) is iets dat veel ontwikkelaars wel kunnen gebruiken...
Ergens vind ik dat VB6 ontwikkelaars niet zo moeten huilen. Als serieus ontwikkelaar...
Oxymoron mijns inziens :? :P
Ook met VB6 kon je serieuze dingen maken. Stelregel was vrij simpel: was iets veel rekenen of ingewikkelde datamodellen: cpp, ging het meer over presenteren en kleine wijzigingen: vb.

Het zijn mi altijd al twee talen geweest die elkaar aanvullen.
Dat is een flauwe en onvolwassen opmerking vind ik. Er zijn heel veel competente programmeurs die voor de volgende keuze staan : met VB6 blijven werken omdat het bedrijf zoveel VB6 software heeft draaien bij klanten, of een andere job zoeken. Iemand die met .Net werkt is niet per definitie een betere programmeur dan een VB6 programmeur.
Het is wellicht handiger om over te stappen op het .net platform, maar omdat er binnen bedrijven veel applicaties draaien die nog gebaseerd zijn op het 'oude' Visual Basic, en dit al jaren lang zo doen, migreer je niet zo 1-2-3 even naar een ander platform, omdat het allerlei narigheden zoals downtime met zich meebrengt.
Binnen de .net omgeving kun je je oude, vertrouwde com objecten nog gewoon aanroepen, dus als die oude VB6 code niet al te zeer spagethi code is, moet het vrolijk kunnen blijven werken.
Dat je door interop nog steeds oude objecten kunt gebruiken staat hier helemaal los van.

Het gaat erom dat je toch echt eerst die objecten met VB6 zal moeten compileren, en daar wordt nu juist de ondersteuning voor stopgezet. Dus als je een probleem hebt omdat er een probleem is met een VB6 runtime, dan kan je dat niet meer oplossen.
uhmm.. waarom zou iemand over moeten stappen op zo'n log buggy .Net junk.. De syntax van vb.net is behoorlijk gewijzigd. VB.Net is een stuk trager, tevens zijn er bij .NET genoeg problemen waar je je gebruikers niet mee wil opzadelen (of je eigen helpdesk), waarvan security het grootste probleem is.
VB6 kun je ook hardstikke gestructureerd werken. Het enige alternatief wat een vb6 programmeur zo ongeveer heeft is dan maar over te stappen op zoiets als RealBasic (wat ook weer een paar nadelen heeft)..
Ik noem iemand die om de haverklap over stapt op een nieuwere programmeertaal juist geen serieuze ontwikkelaar..
Tuurlijk zien jouw C++, Java en vb code er ongeveer hetzelfde uit op de syntax na dan, maar betekend dat dan dat je zomaar moet overschakelen op een andere taal? Ik vind persoonlijk Java en C++ juist maar rommelig, maar ik mis in vb6 wel enkele OOP dingen zoals inheritance, maar de overstap naar vb.NET is gewoon walgelijk, de taal is behoorlijk aangepast, en conversie programma's werken vaak genoeg niet goed (Hoe goed je ook gestructureerd hebt geprogrammeerd)..
Maar ieder heeft zo zijn eigen voorkeur (voordat ik met vb werkte was ik echt een vervente Turbo Pascal/ Delphi programmeur, maar nu na jaren in vb te hebben gewerkt en ook delphi moet ik zeggen dat voor veel dingen VB zeker mijn voorkeur heeft (al is het alleen al vanwege de beste IDE die ik ken..) Maar helaas kan dus niet alles met vb6 vanwege missende OOP dingen, als ze die nog zouden toevoegen (en die zou er intern schijnbaar wel zijn maar nooit gereleased vanwege vb.net) dan zou ik gewoon niet meer weg te meppen zijn uit vb.
Ik noem iemand die enkel in 1 taal kan ontwikkelen geen serieus ontwikkelaar. Ikzelf ben gespecialiseerd in Java, maar met een boek en een weekend oefenen zou ik goed in c# of VB kunnen ontwikkelen. Dit probleem heeft helemaal niks te maken met de ontwikkelaars. Profesionele ontwikkelaars hebben weinig moeite met overschakelen.

Het daadwerkelijke probleem hier zijn niet de ontwikkelaars, maar de programma's. Waneer je al een berg code hebt liggen stap je niet zomaar over op een nieuwe taal. Eigenlijk is het gewoon belachelijk dat je maar naar de pijpen van 1 bedrijfje moet dansen.

Mensen die hier lopen te brullen dat 'je het maar om moet zetten' zijn duidelijk nog nooit buiten hun eigen zolderkamer geweest. Veel banken draaien bijvoorbeeld nog op COBOL code van decenia terug. Ook daar wordt nog steeds onderhoud op gepleegd.
Ehrm... al mijn dotNet applicaties executen een stuk sneller dan hun VB6 variant. Een VB.Net applicatie zal net zo snel als een C# app starten en draaien, simpelweg omdat alles op hetzelfde platform functioneerd. Daarbij word alle code gecompileerd naar MSIL code en dan pas naar een executable dus dan maakt het nog geen meter uit.
En de programmeurs die net blij zijn een aardig regeltje Visual Basic te kunnen schrijven. En eigenlijk voorlopig nog niet over willen stappen omdat Visual Basic nog steeds een van de makkelijkste programmeertalen is om te leren. Ik ga pas andere programmeertalen leren op het moment dat ik Visual Basic goed onder de knie heb en dat schiet niet op als Microsoft deze niet meer ondersteund. Er is ook als zo\\\\\\\'n beta van Visual Basic 2005, maar volgens mij is dat ook op die .NET gebaseerd. Ik heb al een keer naar die beta gekeken, maar die code ziet er toch net weer ff anders uit.
Ik zou toch maar zo snel mogelijk naar VS2005 overstappen want daar kan je veel meer met de Designer zodat je alleen iets hoefd aan te klikken wat je voorheen in VB moest tikken.

Bij het oude VB kon je veel minder gestructureerd programmeren en kon je eigenlijk alleen opties aan of uitzetten.
<KEIHARDE OPMERKING>
Oude VB kloppers waren eigenlijk geen programmeurs, maar mierenneukende systeembeheerders met grootheidswaanzin.
</KEIHARDE OPMERKING>
Overgens wil ik daarmee niet zeggen dat VB geen bestaanrecht had. Je kon er super snel interfaces mee maken en dat is wat gevraagt werd door het bedrijfsleven. Van design was geen spraken, zelfs het HCI design schoot er vaak bij in. Wat een elende :'(
Er zijn ook bedrijven met enkele miljoenen regels aan legacy VB6 code. Dat overzetten naar VB.NET, alles opnieuw testen en terwijl ook nog nieuwe applicaties blijven maken (dat kan je niet zomaar even 5 jaar uitstellen hé), betekent dat je pakweg 2x zo veel geld moet spenderen aan IT-development dan zonder overstap.
Dat die VB6ers dan gewoon VB6 blijven gebruiken. Of leer een andere taal. Simple as that. Mensen die zeiken dat ze een nieuwe taal moeten leren zijn slechte ontwikkelaars. Die hebben gewoon niet door dat de bassisideeen achter iedere taal hetzelfde zijn of het nou C(++), C#, Java, VB, VB.NET, Pascal etc zijn.
Stel je voor, jij werkt binnen een serieus bedrijf aan een serieus softwareproject (pak-em-beet 5 miljoen regels effectieve code). Dat softwareproject is in VB6 geschreven.
Vervolgens zegt jouw leverancier: Ik ga het niet meer ondersteunen, als er een bug zit in mijn compiler waardoor jouw klant dat serieuze probleem heeft, dan zoek je het zelf maar uit. Maarehh, die broncode van de compiler, die houden we lekker zelf }>. Hoe je dan die fout gaat oplossen verzin je zelf maar :P Nou doedoei! gebruik maar VB.NET!
Als mijn leverancier dat zou doen zou ik helemaal gek worden. Je 5 miljoen regels code zijn ineens waardeloos geworden! Je kan wel zeggen: dat moet je alleen ff converteren. Dat werkt nooit voor 100%, en als 0,5% van 5 mln regels code verkeerd gaat, ben je zwaar de lul. Vooral als je daarvan maar van 99% van de fouten een compile-error krijgt :X (=2500 fouten over)
Begrijp me niet verkeerd, elke serieuze applicatie verdient een serieuze taal. Maar dit heeft niks te maken met willen leren, maar met legacy-stuff.
Ben ik nou de enige die denkt dat een applicatie van pak m beet 5 miljoen regels code nooit in VB geschreven had moet worden? En dan nog, support kan nog wel, maar tegen betaling.
Ik heb enige ervaring met VB en ook met het .Net platform, en ik vind dat het overstappen naar .Net zeker de moeite waard is voor iedere developer.

Ik snap wel dat veel bedrijven misschien niet zo gemakkelijk kunnen overstappen, vanwege fincianciele bezwaren, maar persoonlijk als developer ben ik erg blij met .net en C#.

En OO werkt gewoon heel prettig.
Het gaat er niet om dat het hele .net gebeuren een veel fijnere programmeeromgeving is (wat ik overigens onderschrijf), maar dat er nog veel legacy VB6 code is.

En ook al zijn er zat tools om je code van VB6 om te zetten in VB.net, is dat toch niet iets wat je zomaar even op een vrijdagmiddagje doet.

(Zelfde heb je ook van ASP naar ASP.net, is het ook een compleet nieuwe taal, stiekem, en het 1-op-1 overzetten gaat niet zo lukken)
Dat is het probleem niet; er is idd nog veel legacy VB6 code, maar die code kan toch nog altijd door de ontwikkelaars ondersteund worden?
Je hoeft helemaal je legacy code niet naar .NET om te zetten; die kan je gewoon nog blijven supporten.
MS gaat gewoon geen tijd en geld meer steken in de ontwikkeling; support van VB6, met als gevolg dat er ook geen patches etc... meer komen. Moet je daar rouwig om zijn ? IMHO nee.
Ik snap heel goed dat MS dat niet meer gaat doen, na x aantal jaar ondersteunen ze hun oudere versies van hun OS'en toch ook niet meer ?
Het is niet omdat MS VB6 niet meer verder ondersteunt, dat je daarom geen software meer kan schrijven of onderhouden in vb6.
Die legacy code is wel legacy VB code!!! :'(
Wat zoveel wil zeggen als in elkaar gehackte prut.
Dat was namelijk de kracht van VB snel en simpel (en een onderhoudsnachtmerie, dus job security. B-)

Omzetten van VB naar naar .NET is niet super makkelijk automatiseerbaar, maar wel heeeeel goed outsoucrebaar omdat er geen eindgebruikersinteractie voor nodig is.
Met andere woorden in Bangalore India zullen ze met dit bericht dolgelukkig zijn.
Met het 2K probleem hadden ze enorme Cobol straten en die zullen nu wel VB --> .Net omzetting gaan doen.
Thank god for globalisatie. Dat scheelt hier veel dom werk :Y)
Ik vraag me af hoeveel mensen zouden beginnen te zeuren als ze ineens de syntax/gebruik van C++ of Java zo danig zouden wijzigen als dat nu ook het verschil is tussen vb6 en vb.net.. dan zouden degene die nu zitten te mauwen dat vb programmeurs niet zo moeten zeiken ook ineens gaan zeiken..

Ik heb liever dat de kracht van mijn pc goed gebruikt wordt dan dat ik steeds een nieuwere pc moet komen om toch dezelfde snelheid van het nieuwere pakket te hebben in vergelijking met het oude pakket.
Dat noem ik geen vooruitgang, dat noem ik juist een achteruitgang.. Net zoals crossplatform, het is leuk, maar als dat betekend dat mijn computer dan niet tot het uiterste gebruikt wordt, laat dan maar hangen.. .Net is niet de oplossing.. een log framework waarvoor je een zware pc nodig hebt is zeker niet het antwoord..
Sta je dat hele performance verhaal wat betreft cross platform nou werkelijk op te hangen voor VB6? Ik hou mijn lach in hoor. ;)
Ik moet eerlijk zeggen dat toen ik aan Java begon eerst VB6 gedaan heb en die overstap was zwaar teleurstellend imho.
Nu van Java -> whatever gaat juist zeer eenvoudig.
Het gaat niet om de taal maar om de principes.
Een principe zoals OO zit in de meeste talen en is het dus puur een syntax verhaal. Leuke discussie trouwens :)
Juist, helemaal mee eens.
OO is toch wel het minste wat je van een programmeur mag verwachten. :(
Dat diegene vertrouwd is met Design patterns, Component Based Development, Generic Programming of Aspect Oriented Programming (AOP) of de Web Services hype is misscien teveel gevraagd maar OO is toch echt the bloody limit.
Er zijn genoeg ontwikkelaars die niks geven om cross platform...
C++ en Java veranderen ook nogsteeds, daarom word er ook weleens een jaartal achter zoeen taal gezet om aan te geven om welke versie het gaat.

Talen evolueren altijd omdat er steeds betere manieren worden gevonden om zich uit te drukken.
Dat daarbij het belangrijkste rede productieviteit/functionaliteit is en niet efficienty/snelheid komt omdat de rest van de wereld het volledig, hartgrondig, fundamenteel met je oneens is.
Enig idee waarom programmeurs iets in een taal schrijven en niet in assembly? }:O
Zelf de programmeurs waarvoor efficienty een groot probleem is, voor smal footprint devices zoals telefoons en TV's of driver schijvers gebruiken tegenwoordig OO (tot op zekere hoogte)

Je argument dat de kracht van je pc goed gebruikt wordt is echt onzin. Als je de nieuwe features van een pakket zo waardevol vind dan moet je die extra uitgave daar ook maar voor over hebben. PC worden toch over 2 a 3 jaar afgeschreven/als versleten beschoudt. Dat iets verslijt of onderhevig is aan inflatie is gewoon normaal en houd de economie op de rails. B-)

Crossplatform programmeren doen programmeurs ook niet voor jou, maar voor andere andere gebruikers. Het vergroot de markt van het pakket en hoefd helemaal geen performance te kosten.
dotNet of java is natuurlijk wel trager als een native app maar als de performance acceptabel is maakt het niet uit of het 20 of 80% van je processertijd opvreet.
Bovendien worden de meeste thuis PC's alleen in games maximaal gebruikt dus normaal gesproken hoef je je daar geen zorgen over te maken.

Ik moet toegeven dat de er een heleboel java applicaties zijn die onacceptabel traag zijn maar dat is gewoon een fout van de programmeurs niet van de taal. Ook de grote van .Net apps kan nogal snel oplopen, zoals de ATI drivers van 40Mb, maar ook daar ligt het bij de programmeurs. Snelheid en grote zijn zoals alle HCI eisen ondergeschikt aan
functionele eisen, maar dat is een questie van managment niet programmeren.
Een vraag die mss beetje offtopic is:
Is het mogelijk om met MS Visual Studio .NET programma's (windows executables) te maken waarvoor de gebruiker geen .NET framework nodig heeft?
Ja, met unmanaged C++, maar waarom zou je dat doen? Managed C++ draait straks met de ondersteuning van Mono windows.forms implementatie ook op Linux.
Dat zou je doen omdat unmanaged C++ code uiteindelijk in de toepassingen waar je elk beetje performance nodig hebt sneller is...persoonlijk ben ik dan zowieso snel geneigd om C te nemen ipv C++, maar soms kan het idd de moeite waard zijn om de extra's van C++ te gebruiken...maar in geen geval ga ik in C++ werken en dan alsnog met hulpjes als een garbage collector werken...

Verder zou ik me niet teveel voorstellen van de hoeveelheid gebruikers onder linux die met .NET gaat werken...zowieso is mono nog niet echt volwassen en ingeburgerd, maar ik (en veel meer linux mensen) rot niet voor niets op van het MS spul weg...qua programmeren zijn er onder *nix voldoende alternatieven voor .NET...
Overigens wil ik hiermee .NET niet afkraken, wat ik er tot nu toe van gezien heb is best gaaf...maar ik blijf zelf fijn de meer native omgevingen gebruiken, hoewel de ide van .NET wel verleidelijk is ;)
Er gaan zeker wel veel mensen met Mono werken.
Novel-Suse pushed het vet hard en het gaat fantastisch met Gtk en Gnome werken.

Als ik een app voor Gnome zou moeten maken. Zou C# met Mono en GTK# het allemaal een stuk makkelijk maken.
Is het mogelijk om met MS Visual Studio .NET programma's (windows executables) te maken waarvoor de gebruiker geen .NET framework nodig heeft?
Ja dit is mogelijk, maar dan moet je de applicatie wel in unmanaged C++ schrijven.
(zie bijvoorbeeld eMule, dit programma wordt ontwikkeld met Visual Studio .NET en heeft 't .net framework niet nodig)
Sorry maar dat vb was toch dat taaltje om in office en zo macro´s te schrijven. Wordt daar echt serieus in geprogrammeerd ?

EDIT: sanderev66 bedankt voor de info dit was niet als een flame ofzo bedoeld. Ik heb redelijk wat ervaring met REXX maar dat neemt ook (terecht) niemand meer serieus vanwege het beperkte toepassingsgebied
Dat is VBA (Visual Basic for Applications) VB is een normale en fatsoenlijke programmeer taal waarin al vele grote softwareprojecten gemaakt zijn...

Maar ff on-topic: Ik heb eerst VB6 geleerd, in het eerste jaar van mijn huidige school. In het tweede jaar stapten we over op het (naar mijn mening) betere VB.Net 2002 en sindsdien is het alleen nog maar beter geworden. Waarom zal je dan nog VB6 ondersteunen? :?
Er zijn afschuwelijk veel programma's in VB geschreven.

Zelf schrijf ik erg veel programma's in VB en kan er ook heel erg veel mee. C(++) is, indien goed geprogrammeerd, veel efficienter en de code is beter leesbaar. Maar een programma in elkaar steken in VB gaat veel sneller dan in C. Daarom begrijp ik de ondersteunings-vraag wel. Zo'n 10% van alle ontwikkelde software op dit moment wordt ontwikkeld in VB.

Zelf stap ik weldra over op Java. Kan ik ook goed, is cross-platform, momenteel snel genoeg en er zijn heel veel tools voor.
In het "Software Engineering" boek (SBN: 0-07-70109082)dat wij krijgen staat het heel mooi omschreven als een "Design Principle (8)":
"Anticipate Absolescence", een speciaal geval van flexibiliteit. Het houdt in er rekening mee gehouden moet worden dat de technologie/IDE/platform niet altijd zal blijven bestaan.

Enkele vuistregels om dit probleem te voorkomen:
1. Gebruik bij voorkeur geen vroege versies van een nieuwe taal/omgeving, de kans dat de fouten bevatten is groter als bij oudere (uitgekristalliseerde) talen/omgevingen.
2. Gebruik bij voorkeur geen features die alleen in 1 omgeving zitten, de kans dat ze vervallen is groter.
3. Gebruik geen "ungedocumenteerde" features.
4. Gebruik bij voorkeur geen herbruikbare software/speciale hardware van kleinere bedrijven, de kans dat ze het produkt later niet meer ondersteunen is groter.
5. Gebruik standaard talen en technologie die ondersteunt wordt door meerdere (onafhankelijke) leveranciers

---
Dit is een typisch voorbeeld van dit scenario en wel om punt 2 en (in mindere mate) 5.
Als punt om niet te kiezen voor VB.NET is punt 1 weer van toepassing, want de meeste talen zijn echt niet in 5 jaar volwassen....
Als advies om de schade te beperken stellen ze voor om het alvast in te plannen (wat ik zelf ook niet erg realistisch vindt)


My 2 cents.
Helemaal gelijk (goed boek trouwens).
Het is alleen spijtig dat dit soort dingen meestal helemaal in het begin van een project of eigenlijk in het begin van een onderneming/ afdeling niet bekend zijn.
Er word dus een taal/IDE/platform op basis van marketingblaat gekozen in plaats van kennis van waarvoor het geschikt is.
(En techneuten hebben een zwak voor nieuwe speeltjes)

En als het eenmaal een fundament gekozen is, is er geen weg meer terug.
Er wordt in het artikel gesteld dat in .NET C# een soort managed tegenhanger van de unmanaged c++ is. Ten eerste vind ik C# bijna meer op VB lijken en ten tweede heb ik een tijdje geleden een heel boek over dat C++ in .NET doorgewerkt en daaruit concludeerde ik dat je in het nieuwe C++ kan kiezen voor managed of unmanaged maar dat dit laatste niet veel gebruikt wordt o.a. omdat men in C++ gewend is aan de destructor.

Leuk hoor dat .NET. C# vind ik een betere vervanger voor VB6 dan VB.NET zelf. Als je dan toch voor .NET gaat neem dan gewoon C#. Verder weet iedereen dat M$ overal geld aan wil verdienen en dus ook aan de ondersteuning van oude progsels. Als ik nu naar de opticien ga dan wil hij ook liever een nieuw montuurtje verkopen dan een oude bril bij staan buigen als gratis service.
Iemand programmeerd C++ omdat het snel is,
Niet omdat het een destructor heeft.
In C++ word de destructor ook wel eens vergeten en das niet zo possitief :Y)

Bepaalde delen van een .Net app kun je in unmanaged C++ scrijven en dan gebruiken in managed code. Natuurlijk zijn dat net de delen die in je performance profiler als zwaar en veel gebruikt naar boven komen.

Dat dit werkt bewijst de nieuwe Reality Engine van Unreal Tournament. Op die manier kan het .Net supporten en toch supersnel kan zijn.

Enalaatste van onder Scripting & Programming
http://www.artificialstudios.com/features.php
Als je weet dat .net eigenlijk nog maar 3 jaar oud is ( http://www.tweakers.net/nieuws/20106 ), vind ik dit een serieuze steek in de rug van grote bedrijven en ontwikkelaars die "betrouwen" op de stabiliteit van een groot bedrijf zoals microsoft.

Natuurlijk kan kan je niet blijven stilstaan in de ICT wereld, maar dat wil toch niet zeggen dat je zomaar de support van zo'n belangrijk product opgeeft.

Microsoft heeft gezien dat OO populair werd en wordt daardoor gedwongen om ook in die richting een oplossing te bieden aan de klanten, maar dat wil toch niet zeggen dat je de rest in de kou laat staan.

Omschakeling naar een nieuwe taal vraagt veel tijd en veel geld, en als ben je de beste topprogrammeur, ook dan heb je veel tijd nodig om de limieten, de truuks en de kracht van een taal ten volle te benutten.

Het enige wat deze beslissing zou kunnen rechtvaardigen is vrijgave van de compiler broncode, want dan geef je bedrijven die ooit tot miljoenen investeerden in VB6 code nog een kans om oplossingen te vinden ipv van zomaar het licht uit te doen. Het gaat hier over meer dan vernieuwing, maar aan een minimum aan continuiteit en respect voor bedrijven die in VB geinvesteerd hebben ...
Van in de kou laten staan is geen sprake omdat de support niet wegvalt maar die alleen niet meer gratis is.
Met andere woorden, er word nu een financiele prikkel ingebouwd om nu toch eindelijk maar eens over te stappen. Niet minder, niet meer.
Als je echt zoveel code te supporten hebt, heb je dat er voor over.

Bovendien zal de behoefte aan support minimaal zijn, omdat VB6 programmeur logischerwijs al een tijdje bezig zijn en de bugs in VB6 zijn opgelost of bekend en een workaround hebben.

Vrijgave van de broncode is pas een optie als:
1 de support afdeling zo weinig aanvragen krijgt dat het geen recht van bestaan meer heeft
2 er geen strategisch belang meer is om het gesloten te houden. Een geupgrade VB6 zou immers een bedrijging voor VB.Net kunnen vormen.

Kortom, ik schat dat het een jaar of 6 gaat duren, maar als je bv naar Cobol kijkt kan het ook een stuk langer zijn.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True