VB6 vs vb.net

[anoniem]

zit te denken aan de overstap van vb 6 naar vb.net.. wat zijn de voordelen hier van? en: hoorde/las dat de code anders is dan in vb 6.. is dit waar?

[anoniem]

Zoek eens op google.

[anoniem]

Voordelen? Laten we beginnen met de nadelen... Ten eerste krijg je de gehele .NET Framework library over je heen. En in principe moet je deze ook uitleveren aan de gebruikers van je software omdat je er niet van uit kunt gaan dat ze deze al hebben. Dit betekent dat je je programma niet meer op twee floppies kunt versturen. Ten tweede is de taal qua syntax erg veel veranderd. Zo erg zelfs dat er speciale conversie-tools zijn ontwikkeld. Maar al kun je je oude sourcecode converteren, je zult ook nog moeten leren omgaan met die nieuwe syntax. Ten derde de framework zelf. Ik heb zelf de 7-delige boekenserie betreffende de .NET Framework Class Library Reference. (Die krijg je ook online, overigens.) Deze boeken nemen 65 centimeter van mijn boekenplank in beslag en daarbij is ook nog een klein lettertype gebruikt. Kortom, dat framewerkje is enorm uitgebreid qua functionaliteit. Heb je dus nog heel wat te leren. Ten vierde is .NET niet echt platform-onafhankelijk. Windows 95 wordt niet ondersteund en 98/ME hebben niet de volledige functionaliteit. (De afdeling beveiliging is deels afwezig in 98/ME.) En hoewel er Mono is voor onder Unix moet ik helaas vaststellen dat er nog veel aan Mono aangepast dient te worden. Ten slotte verwacht ik dat er binnenkort versie-conflicten kunnen ontstaan. Nu al heb ik versies 1.0 en 1.1 van het framework op mijn PC staan en ik heb helaas beiden nodig... Maar straks komen er meer nieuwe versies en dan is het maar afwachten in hoeverre mijn oude code blijft werken binnen de nieuwe omgevingen. Maar goed, genoeg negatief gelul. De positieve zaken nu... Wel, wat je krijgt is een compiler voor het .NET platform met daarbij een enorm uitgebreide bibliotheek vol bruikbare functies. (Hoewel je misschien niet altijd vindt wat je nodig hebt...) In principe kun je in .NET programmeren in iedere gewenste taal die .NET ondersteunt en kunnen deze talen ook vrij goed worden gecombineerd. Zo kun je VB.NET gebruiken voor een fraaie grafische interface terwijl C++.NET gebruikt wordt voor de business logic. Het voordeel hierbij is dat een grafische designer in een simpele taal als Basic aan de layout kan werken terwijl een ervaren C++ programmeur zich met de complexere business logic bezig houdt. Daarnaast is .NET ideaal voor het maken van websites, waarbij je ASP.NET combineert met een of andere taal op de achtergrond om leuke webpagina's te maken. ASP.NET is daarbij ook nog eens behoorlijk snel. En je hebt de mogelijkheid om die ASP pagina's gewoon in de IDE te ontwerpen en te bekijken. Verder zijn .NET programma's in het algemeen erg klein vergeleken met WIN32 programma's. Programma's van tussen de 25 en de 100 kilobytes zijn dan meer standaard dan uitzonderingen. Met VB kon je dit waarschijnlijk ook al, mits je daarbij de VB runtime library als aparte DLL meeleverde. In dit geval is .NET als geheel je runtime library. Erg interessant is overigens het .NET remoting. In principe de opvolger van COM+. Wat dit betekent is dat je je applicatie in meerdere modules op kunt splitsen en iedere module op een ander systeem kunt laten draaien. Zo kun je de grafische interface laten draaien op PC-X terwijl de business logic draait op PC-Y en er misschien nog wel een speciale webinterface is op PC-Z voor gebruikers die via een webbrowser contact willen maken. Distributed computing heet dat. En verder kent VB.NET geen datatypes meer zonder type. Geen varants of zo. Nee, alles is afgeleid van het type Object. Kan soms erg grappige effecten opleveren zoals:[code:1:bd0d1f749d]Text = 31415926535.ToString.IndexOf("9").ToString[/code:1:bd0d1f749d]Ziet er natuurlijk wel raar uit maar ja, wat het doet is simpel. Er is een getal en dit wordt geconverteerd naar een string. Ook constantes zijn objecten binnen VB dus kun je dit nummer gewoon als een object beschouwen. Binnen die string wordt gevraagd om de positie van het teken "9". Deze positie wordt vervolgens weer omgezet naar een string. Het resultaat? Text = 5 Ik vind dit een van de grappige voorbeelden van wat je in .NET allemaal kunt doen. Verder, zoals de naam al een beetje duidelijk maakt, is .NET vooral bedoeld om beter te kunnen communiceren over netwerken heen. Je moet dus wel wverder denken dan je eigen desktop. Mijn persoonlijke conclusie is vrij simpel. Als je alleen maar desktop-applicaties wilt schrijven, blijf dan gewoon bij VB. Als je meer wilt leren over .NET of in een netwerk-omgeving aan het ontwikkelen bent dan is .NET een goed begin.

[anoniem]

Versieconflicten? Juist omdat je meerdere versies van het framework naast elkaar kunt hebben zul je daar geen last van hebben. Vreet natuurlijk wel ruimte. Maar in tegenstelling tot bijv. java kun je aangeven met welke versie de betreffende app werkt en die zal hij dan gebruiken. M.a.w. Het installeren van een app die een oudere versie van het framework gebruikt zal dan niet leiden tot het niet meer lopen van de overige applicaties. Platformonafhankelijkheid, het toverwoord van de laatste jaren. Net als bij java is dit afhankelijk van voor welk platform er een vm gebouwd wordt en hoe goed deze is. Is nu nog bij lange na niet perfect en zal dat volgens mij 100% worden. Het gebruik van .NET voor desktop applicaties is imho een onderbelicht aspect van dit platform. De nadruk ligt steeds op de web-applicaties en web-services maar met name in grote bedrijven is het feit dat je bij .NET applicaties van assemblies (zo heten die dingen toch) gebruik maakt een ware zegen. Geen gedonder meer met complexe installaties, gewoon een copy naar een directory en presto. Geen dll-hel meer. Je wilt niet weten hoeveel ge-emmer wij hier de laatste jaren daarmee gehad hebben. Werd er weer iets binnengereden dat net weer een andere versie van een of ander lullig dll-tje gebruikte.......... De enorm uitbreide class library zal inderdaad een langdurig leertraject opleveren. Datzelfde vond ik trouwens toen ik met JAVA begon. Mijn hemel, wat een lading classes. Vind dan maar eens die ene die bevat wat jij nodig hebt. Als je ermee begint zie je door de bomen het bos niet meer, maar alles went. 65 centimeter in je boekenkast zeg je? Dat is niet mis, da's nog erger dan de foundation classes indertijd. Met het door elkaar gebruiken van verschillende .NET talen heb ik geen ervaring, maar levert het gebruik van bijv. C# performancewinst op tov van VB.NET? En is de laatste inderdaad meer geschikt voor het bouwen van interfaces? Dat is toch eigenlijk één pot nat? Ze maken toch gebruik van exact hetzelfde framework? Ze maken toch op exact dezelfde manier gebruik van dezelfde classes? Voor de grafische designer maakt het toch geen bal uit welke taal er onder zijn ontworpen interface ligt? Dat codeert hij/zij toch niet met het handje maar (als hij of zij het al direct in de ontwikkelomgeving ontwerpt, wat volgens mij niet erg waarschijnlijk is) gewoon met sleur en pleur in een IDE?

[anoniem]

bedankt voor de racties! wat een goede uitleg, ik denk voordelen - nadelen door jouw gesteld tegen elkaar afgewogen dat ik maar bij vb 6 blijf, veel programma's voor netwerken maak ik niet, afgezien van een LAN-chat programma. erg verhelderend, dank!

[anoniem]

[quote:ec069adafa="Laurens"]Met het door elkaar gebruiken van verschillende .NET talen heb ik geen ervaring, maar levert het gebruik van bijv. C# performancewinst op tov van VB.NET?[/quote:ec069adafa]Dat lijkt me niet echt waarschijnlijk, ze "compilen" beide naar min of meer dezelfde tussentaal die vervolgens wordt uitgevoerd. Dus als er al verschil is, zal deze echt erg klein zijn... [quote:ec069adafa="Laurens"]En is de laatste inderdaad meer geschikt voor het bouwen van interfaces? Dat is toch eigenlijk één pot nat? Ze maken toch gebruik van exact hetzelfde framework? Ze maken toch op exact dezelfde manier gebruik van dezelfde classes?[/quote:ec069adafa]Nee, dat maakt geen verschil, je maakt je grafische user interface (noem dat nooit een interface, dat is een heel ander ding ;)) met de IDE en die genereerd de code voor je. Vroeger was het natuurlijk een ENORM verschil of je VB of C gebruikte, voor het .NET framework is het om het even...

[anoniem]

[quote:f28857d2fa="Bill Gates"]je maakt je grafische user interface (noem dat nooit een interface, dat is een heel ander ding[/quote:f28857d2fa] Feitelijk niet, als je de mens ziet als een deel van het proces vervult de GUI dezelfde funktie als iedere andere interface, nl. het op elkaar laten aansluiten van deelsystemen. :wink:

[anoniem]

[quote:9aa80b5f18]Ten eerste krijg je de gehele .NET Framework library over je heen. En in principe moet je deze ook uitleveren aan de gebruikers van je software omdat je er niet van uit kunt gaan dat ze deze al hebben. Dit betekent dat je je programma niet meer op twee floppies kunt versturen. [/quote:9aa80b5f18] Gebruikt er iemand nog floppies dan? :lol: Besides, standaard wordt het .NET framework al meegeleverd in de toekomstige versies (Longhorn). [quote:9aa80b5f18] Ten tweede is de taal qua syntax erg veel veranderd. Zo erg zelfs dat er speciale conversie-tools zijn ontwikkeld. Maar al kun je je oude sourcecode converteren, je zult ook nog moeten leren omgaan met die nieuwe syntax. [/quote:9aa80b5f18] nieuwe syntax? dat klopt, maar ik heb nooit geweten dat VB een syntax bevatte. :-? Het is de taal met de meest ranzige syntax: het gebrek aan syntax [quote:9aa80b5f18] Ten derde de framework zelf. Ik heb zelf de 7-delige boekenserie betreffende de .NET Framework Class Library Reference. (Die krijg je ook online, overigens.) Deze boeken nemen 65 centimeter van mijn boekenplank in beslag en daarbij is ook nog een klein lettertype gebruikt. Kortom, dat framewerkje is enorm uitgebreid qua functionaliteit. Heb je dus nog heel wat te leren. [/quote:9aa80b5f18] Hoeft ook niet, er is niemand die die Class reference uit zijn kop gaat leren. Het is ook niet voor niets een [b:9aa80b5f18]reference[/b:9aa80b5f18] en geen studieboek. Het gaat erom dat je logisch kunt zoeken in het framework, binnen een maandje ken je de meeste namespaces al en die zijn het belangrijkst.... [quote:9aa80b5f18] Ten vierde is .NET niet echt platform-onafhankelijk. Windows 95 wordt niet ondersteund en 98/ME hebben niet de volledige functionaliteit. (De afdeling beveiliging is deels afwezig in 98/ME.) En hoewel er Mono is voor onder Unix moet ik helaas vaststellen dat er nog veel aan Mono aangepast dient te worden. [/quote:9aa80b5f18] Vind je het gek? Hoe wil je gebruik maken van Windows Authenticatie (kerberos) als je OS het niet ondersteund? Van Mono hoef je nog niet zoveel te verwachten en ga er maar vanuit dat geen enkele techniek van MS ooit platformonafhankelijk zal worden. [quote:9aa80b5f18] Ten slotte verwacht ik dat er binnenkort versie-conflicten kunnen ontstaan. Nu al heb ik versies 1.0 en 1.1 van het framework op mijn PC staan en ik heb helaas beiden nodig... Maar straks komen er meer nieuwe versies en dan is het maar afwachten in hoeverre mijn oude code blijft werken binnen de nieuwe omgevingen. [/quote:9aa80b5f18] is ALTIJD backwards compatible, door de assembly (cache) structuur. Ooit van dll's gehoord? VB6 icm COM? Dat is pas de ramp, assembly's zijn een zegen (heb ik eerder gehoord :lol: )

[anoniem]

Versie-conflicten kunnen wel degelijk ontstaan als een gebruiker nog steeds een oude .NET versie in gebruik heeft. En in principe hebben gebruikers van alle Windows 2000 en oudere systemen natuurlijk nog helemaal geen .NET geinstalleerd. Het probleem is dan ook dat je naast het uitleveren van je software altijd de juiste versie van de .NET framework moet uitleveren zodat de gebruiker de mogelijkheid heeft om deze te installeren. Oftewel, je proggie van 100 kb moet uitgeleverd worden op een CD vanwege de extra .NET framework componenten... Daarnaast is het maar de vraag in hoeverre de .NET componenten van Mono (Unix) compatible blijven met de Microsoft componenten. Immers, qua ontwikkeling zal Mono altijd ver achter blijven omdat men pas kan beginnen met aanpassen nadat MS de nieuwe .NET componenten heeft uitgebracht. Maar voor andere compiler-fabrikanten zoals b.v. Borland is .NET juist een handig middel om weer een betere grip op de compiler-markt te krijgen. Immers, ze hoeven geen specifieke wrappers om nieuwe .NET componenten te maken omdat deze gewoon rechtstreeks vanuit hun eigen producten ook al bruikbaar zijn. Het enige wat alternatieve compiler-fabrikanten hoeven te doen is het leveren van [b:ae6e44cb8e]betere[/b:ae6e44cb8e] en snellere compilers en daarnaast meer functionaliteit dan wat VS biedt. En ja, natuurlijk kun je heel eenvoudig desktop applicaties maken met .NET maar die DLL hell? Ik werk al jaren met Delphi en heb daar zelf niet veel last van gehad. De XCopy deployment werkt ook prima met Delphi. Het wordt alleen lastig als je gebruik maakt van 3rd-party componenten (Of de BDE in Delphi) omdat je deze ook mee moet installeren. En in het algemeen werden dit soort DLL's meestal in C:\Windows\System32 of zo gedumpt waardoor de DLL hell ontstaat. (Gelukkig installeert de BDE in een eigen folder.) Maar ja, als je de benodigde DLL's gewoon bij je applicatie dumpt is hier ook weinig meer mee mis en kun je ook met WIN32 applicaties gewoon installeren via XCopy... Een andere oorzaak van de DLL hell is overigens afkomstig uit de afdeling COM/DCOM en COM+. Immers, deze componenten dienen te worden geregistreerd binnen Windows en versie-verschillen kunnen hierbij enorm bijdragen aan vervelende situaties. Zo zouden twee applicaties dezelfde OCX kunnen gebruiken maar de ene wil versie 4.0 en de andere versie 5.0 en helaas, op het systeem kan maar 1 van beiden worden geinstalleerd... Foutje van de maker van deze control, overigens. Maar helaas wel een veel voorkomende fout. En of er performance-winst zit tussen het gebruik van C# en VB.NET? Tja, de verschillen zullen kleiner zijn dan bij WIN32 applicaties. Maar ook VB6 maakt echte executables en compileert dus naar machine-code, ondanks het feit dat veel mensen nog steeds denken dat VB met pseudocode werkt. Maar VB haalt vaak een slechtere performance vanwege de manier waarop VB met data omgaat. En dan vooral string-manipulaties. Maar nu alle datatypes zijn gestandaardiseerd door .NET en een C# string dus identiek is aan een VB.NET string, zul je hier dus een identieke performance bij zien. Nee, de performance verschillen zullen voornamelijk komen door de manier waarop je de programma-code schrijft en de compiler-opties die je instelt. Naarnaast kan het zijn dat de ene compiler code net iets beter optimaliseert dan de andere compiler. Zo zou Borland's C#Builder misschien wel snellere programma's kunnen produceren dan MS C#. Maar ja, dat wordt lastig om te bewijzen. In ieder geval zijn de performance verschillen tussen diverse talen een stuk kleiner dan voorheen. Nog even over GUI's... Natuurlijk kun je iedere taal gebruiken voor het maken van fraaie GUI's, zeker binnen .NET. Maar het probleem zit hem niet in de taal maar bij de gebruiker. Iedere gebruiker heeft een voorkeur voor een bepaald gebied van programmeren. De een vind het maken van GUI's leuk, de ander richt zich meer op database connecties. De derde houdt zich meer bezig met complexe algorithmes en nummer 4 meer met communicatie tussen programma's en computers. Kortom, iedere programmeur heeft een neiging om een specialist te worden in een bepaald vakgebied. En dus kiest iedere programmeur ook een favoriete tool om mee te werken. Nu heeft .NET dan wel alle libraries netjes plat geslagen opdat iedereen deze simpel kan gebruiken in hun geliefde ontwikkel-omgeving maar dat neemt niet weg dat iedereen toch kiest voor wat zij eenvoudig kunnen gebruiken. GUI ontwerpers hoeven zich in het algemeen niet bezig te houden met erg complexe programmeer-constructies. Zij houden zich meer bezig met layout. In het algemeen wordt hiervoor dan ook een simpele taal voor gekozen met een eenvoudige syntax. Basic, bijvoorbeeld. Database programmeurs hebben vaak de behoefte om het een en ander aan rekenwerk te verrichten naast het gebruik van SQL. VB zou nog kunnen maar C# is al iets favorieter. (En op dit moment is ook Delphi een optie) Wanneer je meer met lastige algorithmes gaat werken dan is Basic al gauw te eenvoudig. Voor het berekenen van fractals en het uitwerken van complexe grafieken wordt vaak een meer rekenkundige taal gebruikt. En C++ is hierbij erg populair. En ook als het gaat over communicatie dan is C++ nog steeds de grote favoriet, hoewel onder .NET zelfs VB dit prima aan zou kunnen. Het probleem is momenteel dat deze programmeer-specialisten gaan ontstaan maar dat ze al bestaan! Er zijn veel mensen die zich met VB en VBA hebben bezig gehouden voor eenvoudige programmeertaken. Meestal een mooie GUI met daarnaast eenvoudige verwerking van gegevens. Vaak ook geliefd voor het maken van snelle oplossingen. Daarnaast zijn er bedrijven die juist gespecialiseerd zijn in een taal als C++ omdat zij software schrijven die complexe algorithmes bevatten. Denk bijvoorbeeld aan een product als Paint Shop Pro waarmee je plaatjes op diverse manieren kunt bewerken. In Basic zou zo'n programma al gauw veel te complex worden. Het probleem is gewoon dat er al specialisten zijn en die willen dan ook gewoon hun eigen taal blijven gebruiken binnen .NET. Dit is ook de reden dat de Java VM niet al te populair was, simpelweg omdat men niet een andere taal wilde leren. Nu, een decennium later, zijn er al diverse Java specialisten en heeft Java zich vooral bewezen op de server-markt in de vorm van Java-servlets. Bij .NET is nog steeds verwarring bij toekomstige gebruikers over welke taal ze dienen te gebruiken. Overigens is MS ook daadwerkelijk van plan om verschillen in functionaliteit aan te brengen tussen VB, C# en C++. MS wil juist dat VB meer voor GUI design wordt gebruikt en C++ voor de complexe algorithmes. En c# zit daar ergens tussen, zoals Pascal ook altijd een beetje tussen Basic en C zat. Of MS deze plannen ook werkelijk uitvoert is afwachten, maar het zou best kunnen dat C++ en C# extra functionaliteit gaan krijgen die niet bij VB zit.

[anoniem]

[quote:204edae9fd]Versie-conflicten kunnen wel degelijk ontstaan als een gebruiker nog steeds een oude .NET versie in gebruik heeft. En in principe hebben gebruikers van alle Windows 2000 en oudere systemen natuurlijk nog helemaal geen .NET geinstalleerd. Het probleem is dan ook dat je naast het uitleveren van je software altijd de juiste versie van de .NET framework moet uitleveren zodat de gebruiker de mogelijkheid heeft om deze te installeren. Oftewel, je proggie van 100 kb moet uitgeleverd worden op een CD vanwege de extra .NET framework componenten... Daarnaast is het maar de vraag in hoeverre de .NET componenten van Mono (Unix) compatible blijven met de Microsoft componenten. Immers, qua ontwikkeling zal Mono altijd ver achter blijven omdat men pas kan beginnen met aanpassen nadat MS de nieuwe .NET componenten heeft uitgebracht. [/quote:204edae9fd] Ik zeg ook niet dat iedereen opeens in .NET moet programmeren, maar als je een beetje onderlegd bent (lees: algemene OO concepten snapt) dan mag dat geen probleem zijn. Dan is die omslag echt niet zo groot. Een aantal problemen (COM, dll hell) worden gewoon goed ondervangen en daarom is .NET naar mijn mening het meest geschikt voor geavanceerde desktop- en gedistrubieerde applicaties, tenzij je uiteraard low-level wil (maar daar ging het even niet om).

[anoniem]

Plaats ik een "kort" berichtje, is er nog iemand die wat aan de discussie toevoegt zonder dat ik het opmerk. :D [quote:cad3f8213b]Gebruikt er iemand nog floppies dan? Besides, standaard wordt het .NET framework al meegeleverd in de toekomstige versies (Longhorn).[/quote:cad3f8213b] Natuurlijk. Maar je vergeet dat er nog steeds heel veel gebruik wordt gemaakt van Windows 98, Windows NT en Windows 2000. En MS mag dan wel iedere twee jaar een nieuwe Windows versie op de markt brengen, de meeste bedrijven nemen pas afstand van hun oude systemen als de hardware kapot gaat. Je houdt het niet voor mogelijk hoeveel bedrijven nog steeds vertrouwen op al die oude Windows versies. Floppies beginnen tegenwoordig al te verdwijnen maar ook alleen maar omdat je tegenwoordig kunt booten vanaf CD-Rom. Nieuwe PC's worden tegenwoordig al regelmatig zonder floppydrive uitgeleverd en inderdaad, floppies zijn al flink aan het verdwijnen. (Maar ze worden nog wel steeds gebruikt! Vooral binnen bedrijven waar de meeste PC's niet met een CD-writer worden uitgerust.) [quote:cad3f8213b]Hoeft ook niet, er is niemand die die Class reference uit zijn kop gaat leren. Het is ook niet voor niets een reference en geen studieboek. Het gaat erom dat je logisch kunt zoeken in het framework, binnen een maandje ken je de meeste namespaces al en die zijn het belangrijkst.... [/quote:cad3f8213b] Nou ja, je moet in ieder geval weten wat je nodig denkt te hebben. En als je maar 10% van het gehele framewerk wil kennen moet je dus 6.5 CM aan boekwerk bestuderen. :wink: En 65 millimeter voor 1%... En dat is toch nog wel een hoop kennis... [quote:cad3f8213b]Ooit van dll's gehoord? VB6 icm COM? Dat is pas de ramp, assembly's zijn een zegen[/quote:cad3f8213b] Tja, COM/DCOM, COM+ en de DLL hell. Een bekend probleem. Gelukkig heb ik zelf nooit veel met COM hoeven te werken en heb ik als Delphi programmeur ook weinig behoefte gehad voor het gebruik van COM. En tja, normale DLL's worden gewoon meegekopieerd met je applicatie dus dat is ook geen probleem.

[anoniem]

En ik zeg ook niet dat .NET ongeschikt is voor het schrijven van desktop applicaties. Maar qua functionaiteit heeft .NET niet echt veel meer te bieden dan VB6. Natuurlijk kun je overstappen maar als je toch al afhankelijk bent van veel OCX controls dan verandert daar weinig aan. Je blijft die krengen dan nog steeds nodig hebben binnen .NET totdat er een alternatieve assembly komt met identieke functionaliteit. Nu is mijn ervaring meer gericht op de overstap van Delphi 7 naar Delphi 8 (for .NET) waarbij ik al snel merkte dat ik een groot deel van mijn oude code maar erg moeizaam onder .NET werkende kreeg, vooral omdat ik enkele 3rd-party componenten gebruikte. Borland heeft fantastich werk gemaakt met hun conversie dan de VCL naar .NET maar dat neemt niet weg dat veel oude code van mij de nodige dagen werk nodig hebben om te worden herschreven. Vandaar dus dat ik voor oude projecten nog steeds D7 blijf gebruiken. Deze overgangs-problemen zitten ook bij de stap van VB6 naar VB.NET want ook hier zal de code de nodige aanpassingen dienen te krijgen. Veel werk dus om over te schakelen. Maar goed, nieuwe projecten dan? Tja, met D7 had ik al een mooie, grote library opgebouwd met allerlei fraaie componenten en die zal ik missen in D8... Eerst maar eens wat meer bekendheid opbouwen met .NET en maar zien of er interessante assemblies zullen verschijnen die gebruikt kunnen worden. Dat zal zeker interessant zijn omdat ik nu ook eenvoudig assemblies kan gebruiken die in andere programmeertalen zijn ontwikkeld. Kan erg interessante combinaties opleveren zoals b.v. een COBOL.NET assembly die gegevens uitwisselt met een database waarbij Forth.NET enkele formules loslaat op deze data om mooie eindcijfers te genereren die dan vervolgens via een Perl.NET SOAP server naar een C# SOAP client worden verstuurd waarna een VB.NET GUI dit eindresultaat aan de gebruiker presenteert... :D

[anoniem]

Tis maar wat je denkt nodig te hebben. Voorlopig vind ik .NET prachtig werken. Maar ik blijf van mening dat het allemaal nog veel beter kan. De meeste talen zijn mij lang niet intelligent genoeg. Laatst een uitleg over Longhorn en .NET bekeken. Nou, ik word er zeker niet vrolijk van. Het zal nog wel 20 jaar duren voordat ontwerpers van programmeertalen doen wat ik wil, maar ja, dan lopen ze vast weer 20 jaar achter met wat ik dan wil. :lol: Maar ach, ik red me er wel mee. :o

[anoniem]

[quote:42652c6462="Wiep Corbier"]Het zal nog wel 20 jaar duren voordat ontwerpers van programmeertalen doen wat ik wil, maar ja, dan lopen ze vast weer 20 jaar achter met wat ik dan wil.[/quote:42652c6462]Dit vind ik interessant, wat voor dingen mis je dan nu?

[anoniem]

Tja, hoe intelligent zouden die talen eigenlijk moeten zijn, he? Het mooiste zou natuurlijk gewoon de normale spreektaal zijn, waarbij je a la Star Trek gewoon mondelinge commando's aan de computer geeft en de computer gewoon begrijpt wat je bedoelt. Maar ja, zo ver is men nog lang niet. Bovendien, een compiler voor normale spreektaal is lang niet eenvoudig wegens al sie duizenden manieren waarop je een taak kunt verwoorden. Toch wordt hier wel aan gewerkt, alleen zijn de vereiste algoritmes hiervoor nog veel te complex. En nee, ik bedoel niet spraak-herkenning maar letterlijk dat de computer begrijpt wat je bedoelt en dus niet reageert op vooraf ingevoerde opdrachten. Voorlopig zullen we het dus maar bij de bestaande programmeertalen moeten houden. En daar zijn driev favoriete smaken in. Eerst de BASIC varianten die qua taal en syntax voor iedereen vrij eenvoudig te begrijpen is. Dan alle C varianten (en Java is eigenlijk ook een soort C variant) met hun complexere syntax en het gebruik van symbolen in plaats van taal voor diverse functies. { voor begin, } voor end, de ::, &, *, +=, -=, == die voor een ervaren programmeur wel duidelijk zijn maar waar heel veel beginners flink mee in de fout kunnen gaan. En dan de Pascal-achtige talen. En Pascal is qua complexiteit ergens tussen BASIC en C in. Maar het feit is dat als je een taal wilt leren die het dichtste bij de spreektaal ligt, dan zou je eigenlijk voor COBOL moeten kiezen. Maar de praktijk toont dat de meeste mensen juist deze taal als erg lastig ervaren. Ik denk dat er over 20 jaar nog steeds enkele tientallen programmeertalen zullen bestaan. Of .NET tegen die tijd een standaard is geworden is overigens te betwijfelen want indien niemand zich flink inspant om dit framework ook op andere platformen draaiende te krijgen dan zal .NET beperkt blijven tot Windows. En of Windows over 20 jaar nog zo populair is valt ook te betwijfelen omdat steeds meer mensen zich ergeren aan de licentiekosten van het besturings-systeem terwijl het OS ze daarnaast ook nog eens enkele beperkingen (Palladium) gaat opleggen. De kans bestaat dat over 20 jaar de meeste gebruikers overstappen op een stabiele Linux-kernel en daar hun eigen systemen omheen ontwikkelen. Zoals MS een marktaandeel probeert te veroveren in de server-markt, zo proberen diverse Linux/Unix varianten de desktop markt te veroveren. Maar ja, de strijd Linux/Microsoft is op dit moment nog te vaag om een duidelijke winnaar aan te kunnen wijzen. En over 20 jaar zal dat nog steeds niet veranderd zijn...

[anoniem]

ik vraag me echt af of dat nou veel makkeliojker zou zijn, in spreektaal programmeren bedoel ik.. ik heb soms zelfs moeite met iemand iets uit te leggen, laat staan de computer.. die zal je alles op een bepaalde manier uit moeten leggen om iets voor de pc begrijpelijk te maken.. zijn er trouwens 'universele' talen? dacht dat c zoiets was (kan je ook op linux gebruiken.. toch?) en asm natuurlijk maar heb je niet een taal waarme je voor alle os'en een programma kan maken en ze er ook op werken zonder emulator?

[anoniem]

Voor de mens is spreektaal gewoon de meest eenvoudige taal. En als je kijkt naar een taal als COBOL dan zie je dat bij deze antieke taal de ontwerpers ook geprobeerd hebben de spreektaal deels te benaderen. Maar helaas is spreektaal enorm lastig te vertalen voor een computer. Betreffende universele talen... In principe zijn de meeste talen opgezet als universele talen. Zeker talen als Pascal, Basic en C. En Basic is eigenlijk de meest universele taal tot nog toe, aangezien deze taal zo'n twintig jaar geleden zowat de standaard taal was van iedere home computer en de PC. (Denk aan de P2000, ZX-Spectrum, Sinclair QL, MSX, etc.) Het enige probleem is dat een taal dan wel universeel kan zijn, maar ieder platform heeft gewoon zijn eigen specifieke eigenaardigheden. Vooral als je met machine-specifieke zaken gaat bezig houden. Gelukkig beginnen er al vrij algemene libraries te komen die redelijk platform-onafhankelijk zijn, maar zelfs iets simpels als een venster tekenen op het scherm kan per platform enorm verschillen. Net als zaken als geheugen-beheer, threading en inter-process communicatie. Het maakt niet uit hoe universeel de taal is maar er zijn wel voor ieder platform speciale libraries nodig.