Archief - [PROG]/ een gamekkelijke programmeer taal?
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
messiah´
Legacy Member
NWN2 is al uit ofwa?killgore zei:De devtools in nwn2 zijn btw ook c# coded.
Ik zou sowieso voor Java of .NET gaan, afhankelijk van je wilt bereiken, misschien C++.
Dan is er het verschil in leercurve, waar talen als Java of C# een steile leercurve hebben, is VB.Net makkelijker aan te leren. Dit nadeel vervalt eens je goed weg bent met een taal. Je hersenen wennen aan de iets abstractere opmaak.
Maar leer zeker een managed taal voor gewone applicaties. Tenzij je écht device drivers en 3d-applicaties wil programmeren, dan opteer je toch best voor C++.
Zowel .Net als Java hebben schit-terende IDE's. Kijk maar eens naar Microsoft's Visual Studio Express voor .Net. Voor Java veronderstel dat Eclipse nog altijd dé referentie is.
En als je ambitie hebt om Linux kernel devver te worden kan je je maar beter verdiepen in C. Object is evil, remember.
S3cT0r
Legacy Member
Persoonlijk denk ik dat de opinies van de futuristen hier een beetje te voorbarig zijn. C# nu al gaan bestempelen als de wonder-oplossing voor het ontwikkelen van monster-applicaties die tevens makkelijk te debuggen zijn en alles wat je wil, terwijl C(++) hier totaal ongeschikt voor zou zijn, is naïef.
Ik denk heus niet C# of Java de oudgedienden gaan overnemen, ook niet in de toekomst. Iemand haalde bijvoorbeeld aan dat WinAPI niet portable was, maar Winforms zijn dat ook niet hoor. Net zoals WINE de WinAPI "emuleert" doet Mono dat voor de .NET runtime (voorlopig nog geen winforms). De implementaties daarvan gaan altijd achterlopen, je kan hier niet van een directe portabiliteit spreken. Zeker niet als je weet dat C(++) toolkits als GTK+, QT en wxWidgets wel perfect cross-platform zijn.
Over Singularity, ik heb de benchmarks gezien, en al de punten waar Singularity wint tegenover andere kernels zijn zo omdat er een radicale nieuwe weg is ingeslagen over het beheren van bijvoorbeeld processen, dit is niet beperkt tot C# of Sing#. (Sing# is een soort unsafe C#, met pointers en al die andere duivelse, oude, low-level dingen, directe memory acces zonder garbage collection voor bepaalde segmenten). Op de punten waar de performance slechter is, valt er volgens hen niet zo veel aan te doen doordat de taal interpreted is. Wat daar ook nog over te zeggen valt is dat Singularity nog lang niet zoveel toeters en bellen heeft als conventionele kernels, het is overduidelijk dat een vergelijking niet opgaat.
Om effe in het voordeel van Singularity te pleiten, het is voorlopig super stabiel! Wat heeft men nu het meest nodig? Dat zijn afwegingen... (then again, FreeBSD crashed hier toch ooit ni echt veel, kheb het nog ni zien crashen in ieder geval, spijtig wel dat het geschreven is in die taal C die we liever zo snel mogelijk wegwerpen)
Ik denk heus niet C# of Java de oudgedienden gaan overnemen, ook niet in de toekomst. Iemand haalde bijvoorbeeld aan dat WinAPI niet portable was, maar Winforms zijn dat ook niet hoor. Net zoals WINE de WinAPI "emuleert" doet Mono dat voor de .NET runtime (voorlopig nog geen winforms). De implementaties daarvan gaan altijd achterlopen, je kan hier niet van een directe portabiliteit spreken. Zeker niet als je weet dat C(++) toolkits als GTK+, QT en wxWidgets wel perfect cross-platform zijn.
Over Singularity, ik heb de benchmarks gezien, en al de punten waar Singularity wint tegenover andere kernels zijn zo omdat er een radicale nieuwe weg is ingeslagen over het beheren van bijvoorbeeld processen, dit is niet beperkt tot C# of Sing#. (Sing# is een soort unsafe C#, met pointers en al die andere duivelse, oude, low-level dingen, directe memory acces zonder garbage collection voor bepaalde segmenten). Op de punten waar de performance slechter is, valt er volgens hen niet zo veel aan te doen doordat de taal interpreted is. Wat daar ook nog over te zeggen valt is dat Singularity nog lang niet zoveel toeters en bellen heeft als conventionele kernels, het is overduidelijk dat een vergelijking niet opgaat.
Om effe in het voordeel van Singularity te pleiten, het is voorlopig super stabiel! Wat heeft men nu het meest nodig? Dat zijn afwegingen... (then again, FreeBSD crashed hier toch ooit ni echt veel, kheb het nog ni zien crashen in ieder geval, spijtig wel dat het geschreven is in die taal C die we liever zo snel mogelijk wegwerpen)
The Crazy Frog
Legacy Member
@Hasdrubal: Volgens mij ist beste dat je kan doen 2 verschillende talen leren:
C#/java en c++.
Met C#/Java zal je rap een programma in elkaar kunnen steken en door c++ zal je leren wat er onder de motorkap van windows gebeurt (een absolute must als je het mij vraagt).
C#/java en c++.
Met C#/Java zal je rap een programma in elkaar kunnen steken en door c++ zal je leren wat er onder de motorkap van windows gebeurt (een absolute must als je het mij vraagt).
den Acid Burn
Legacy Member
dude ....The Crazy Frog zei:
denk ens ff logisch na.
stap voor stap.
wat is een programmeertaal?
een "taal" die je gebruikt om een apparaat bepaalde acties te laten uitvoeren.
zover zijn we al.
waarommaakt men het onderscheid tussen "echte programmeertalen" en "scripting talen"?
echte programmeertalen moeten worden gecompileerd (dus omgezet naar machinecode) voor ze kunnen uitgevoerd worden.
scriptingtalen daarentegen worden op het moment zelf geinterpreteerd.
dus maakt men een ondersched tussen echte programmeertalen en scriptingtalen.
hopelijk was dit duidelijk genoeg
en jij mixt hier a volonte "scriptingtalen" en "programeertalen"
in weze zijn het allemaal programmeertalen, maar men maakt een onderscheid naar hun functie
wlibaers
Legacy Member
Het onderscheid tussen scriptingtaal en programmeertaal is nogal moeilijk te maken. Dat onderscheid maken op basis van het al dan niet compileren van de taal is absurd. Ter illustratie:
Lisp: voor deze taal bestaan interpreters, bytecode compilers, en machinetaal compilers.
C: vooral bekend als gecompileerde taal, maar er bestaat een interpreter.
Tcl: waarschijnlijk de ultieme scriptingtaal (uitvoering was traditioneel zuiver op strings gebaseerd), heeft nu ook een bytecode compiler.
Tcl is trouwens nog een mooi voorbeeld van een goede manier om in dergelijke debatten te denken. De taal was niet ontworpen als op zichzelf staand systeem om programma's te maken, maar als een manier om verschillende in C geschreven programma's makkelijk te kunnen verbinden tot een groter geheel. Het idee was dat code die heel snel moest zijn, of om andere redenen low-level was, in C geschreven zou worden, terwijl de Tcl scripts die code zouden aanroepen en als een soort gebruikersinterface dienen. Tegenwoordig worden soms hele programma's in Tcl geschreven, kunnen meer talen dan C alleen gebruikt worden voor de low-level code, en is de Tcl runtime relatief makkelijk te integreren in andere programma's om zo voor een ingebouwde scriptingtaal te zorgen. Bovendien kwam er ook nog Tk, en de combinatie Tcl/Tk werd een van de eerste cross-platform GUI toolkits, die bovendien heel snel en eenvoudig resultaten geeft.
Je moet een taal gewoon gebruiken voor dingen waar ze goed toepasbaar is. C is een taal voor systeemprogrammatie. Low-level dingen, waar het echt snel moet gaan, of directe manipulatie van geheugen nodig is, pointers,... Het is niet de bedoeling C te gebruiken om een database-frontend te maken (daarvoor neem je bijvoorbeeld Tcl/Tk), maar wel om de datastructuren en zoekalgoritmen van die database te maken. Ik denk dat veel van de kritiek op bepaalde talen afkomstig is van mensen die een ongeschikte taal kozen voor een project, en dan de taal de schuld geven van hun verkeerde keuze.
Er zijn natuurlijk wel talen die je echt niet wil gebruiken (Cobol, Intercal,...) maar de meesten overwegen het zelfs niet om die in zo'n debat te bespreken dus dat is het probleem niet.
Lisp: voor deze taal bestaan interpreters, bytecode compilers, en machinetaal compilers.
C: vooral bekend als gecompileerde taal, maar er bestaat een interpreter.
Tcl: waarschijnlijk de ultieme scriptingtaal (uitvoering was traditioneel zuiver op strings gebaseerd), heeft nu ook een bytecode compiler.
Tcl is trouwens nog een mooi voorbeeld van een goede manier om in dergelijke debatten te denken. De taal was niet ontworpen als op zichzelf staand systeem om programma's te maken, maar als een manier om verschillende in C geschreven programma's makkelijk te kunnen verbinden tot een groter geheel. Het idee was dat code die heel snel moest zijn, of om andere redenen low-level was, in C geschreven zou worden, terwijl de Tcl scripts die code zouden aanroepen en als een soort gebruikersinterface dienen. Tegenwoordig worden soms hele programma's in Tcl geschreven, kunnen meer talen dan C alleen gebruikt worden voor de low-level code, en is de Tcl runtime relatief makkelijk te integreren in andere programma's om zo voor een ingebouwde scriptingtaal te zorgen. Bovendien kwam er ook nog Tk, en de combinatie Tcl/Tk werd een van de eerste cross-platform GUI toolkits, die bovendien heel snel en eenvoudig resultaten geeft.
Je moet een taal gewoon gebruiken voor dingen waar ze goed toepasbaar is. C is een taal voor systeemprogrammatie. Low-level dingen, waar het echt snel moet gaan, of directe manipulatie van geheugen nodig is, pointers,... Het is niet de bedoeling C te gebruiken om een database-frontend te maken (daarvoor neem je bijvoorbeeld Tcl/Tk), maar wel om de datastructuren en zoekalgoritmen van die database te maken. Ik denk dat veel van de kritiek op bepaalde talen afkomstig is van mensen die een ongeschikte taal kozen voor een project, en dan de taal de schuld geven van hun verkeerde keuze.
Er zijn natuurlijk wel talen die je echt niet wil gebruiken (Cobol, Intercal,...) maar de meesten overwegen het zelfs niet om die in zo'n debat te bespreken dus dat is het probleem niet.
Emerxill
Legacy Member
Hangt der vanaf of der veel gecustomized moet worden of niet. Als ge echt moet gaan customizen is C# ambetanter dan bijv Java. Nu spreek ik over grote applicaties waar er veel in gecustomized moet worden...M0rpheus zei:
Als ge enkel gebruik gaat maken van bestaande dingen gaat ge in C# veel sneller vooruit gaan om iets te ontwikkelen dan bijv. Java.
Als ge als hobby een beetje wilt programmeren maakt et geen botten uit of ge nu Java of iets uit .net gebruikt.
Wanneer der iets nieuw ontwikkeld moet worden van scratch weten zelfs IT-managers tegenwoordig nog niemeer tegoei welk framework ze gaan gebruiken....
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.