[alg] wat is de beste programmeertaal

[wasigh]

Zet een aantal programmeurs bij elkaar en je weet bijna zeker dat ze het oneens zijn over welke programmeertaal het beste is.

Vaak worden in dergelijke discussies gehamerd op technische voordelen van een bepaalde taal. Zoals bijvoorbeeld de schoonheid van een taal. Het centrale idee erachter e.d. De betrouwbaarheid, leersbaarheid en schrijfbaarheid zijn vaak belangrijke criteria.

maar wat heel veel programmeurs volgens mij niet toe willen geven is dat de keuze voor een programmeertaal niet zozeer van de mogelijkheden van de taal afhangt maar bijvoorbeeld van de stoerheid van een taal. C++ wordt als een moeilijkere taal gezien als Pascal dus ben je stoerder als je C++ programmeerd dan dan je Pascal programmeert.

Ook het feit dat iedereen een bepaalde taal (of database) gebruikt kan volgens mij een belangrijke factor zijn bij de keuze van een taal. PHP is bijvoorbeeld een makkelijke schrijfbare taal, maar doordat het vrijwel geen type checking heeft, en niet gecompiled wordt is het lastiger te debuggen als een strictere taal. Wat de betrouwbaarheid niet ten goede komt. En er zijn zekere beter alternatieven op de markt alleen zijn deze niet zo populair. Zelfde als bijvoorbeeld MySQL.

Mijn vraag is dan ook: hoe vaak hangt de keuze van een programmeertaal echt af van technische zaken en hoe vaak is het gewoon nadoen wat de massa doet? Of kiezen wat het meest stoer staat? (ASP.NET is veel stoerder dan php! )

[Eskimootje]

Het hangt er gewoon nogal al vanaf wat je gaat maken. Dus echt een eenduidig antwoord krijg je nooit.

Ik vind het stoer als je een werkend programma hebt, of het dan in Pascal, C++, Java of Visual Basic is gemaakt is niet meer belangrijk. Enige probleem is als je het moet gaan uitbreiden. Dan zijn OO talen opeens toch wel erg makkelijk.

[ Voor 55% gewijzigd door Eskimootje op 03-11-2003 14:22 ]

[Alarmnummer]

Het ligt er idd nogal aan wat je gaat maken.

Maak je voornamelijk gebruik van een ms platform, dan is java een slechte keuze. Als je een expertsysteem gaat schrijven is c# een slechte keuze, maar prolog een veel betere. Ga je een website schrijven dan is prolog een slechte keuzen maar JSP/ASP een betere.

Het ligt er maar net aan wat je dus gaat maken, en wat voor eisen er verder zijn.

[GrimaceODespair]

Anders moet je deze programmeertaal eens proberen.

offtopic:
of ben ik nou heel flauw?

[ Voor 20% gewijzigd door GrimaceODespair op 03-11-2003 14:24 ]

[Brakkie]

Ik ben vooral geinterresseerd in programmeren voor het web. De dag dat ik niet meer genoeg had aan HTML en een database aan m'n iste wilde gaan koppelen moest ik vanachter mijn computertje thuis een script taal gaan kiezen. Ik keek een beetje rond op het internet en zag dat er over php online veel te vinden is en dat het volgens veel mensen makkelijk te leren is. Ik ben dr mee aan de slag gegaan en heb er een eigen stijl in ontwikkeld en vind het nu gewoon makkelijk en flexibel werken. Zeker na m'n stage heb ik een zekere routine ontwikkeld in het php'en.

Ik kan dus eigenlijk geen andere taal dan php. Overtuig me eens om ASP of JSP te gaan gebruiken

[Verwijderd]

wasigh schreef op 03 november 2003 @ 14:17:
Mijn vraag is dan ook: hoe vaak hangt de keuze van een programmeertaal echt af van technische zaken en hoe vaak is het gewoon nadoen wat de massa doet? Of kiezen wat het meest stoer staat? (ASP.NET is veel stoerder dan php! )

Het stoer zijn boeit mij echt helemaal niets. De technische achtergrond, des te meer. Als programmeur moet je volgens mij een taal kiezen, waarbij de compiler al het werk doet wat er van een compiler op dit moment valt te verwachten.

PHP valt hier dus totaal niet onder (ja, ik weet dat het geinterpreteerd wordt).
JAVA valt hier ook niet onder.

Het enige voordeel van bovenstaande talen is dat de "massa", zich hiermee bezighoudt, en er dus een hele hoop informatie valt te vinden.

[whoami]

Ik merk dat er blijkbaar mensen zijn die de startpost niet volledig hebben gelezen, en enkel afgaan op de topictitel.
Wasigh wil hier niet weten welke programmeertaal jullie het beste vinden; hij wil weten in hoeverre men de taal kiest op basis van de technische vereisten en of de 'stoerheid' van een taal bij de keuze van de taal geen te grote rol speelt.

[.oisyn]

C++ wordt als een moeilijkere taal gezien als Pascal dus ben je stoerder als je C++ programmeerd dan dan je Pascal programmeert

nou ja behalve dat C++ gewoonweg vele malen uitgebreider is

Voor mij persoonlijk komt het vooral neer op de efficienty van de taal, en hoe snel het mogelijk is om er iets mee te maken. Goed, C en C++ is staan erom bekend dat je er behoorlijk efficiente code mee kunt schrijven. Maar op zich geldt dat wel voor veel native talen.

Dan komen we op het volgende punt: het aantal mogelijkheden. Neem C++'s operator overloading en templates, en de mogelijkheden zijn in principe eindeloos, en dat is dan ook mijn voornaamste keuze boven C en talen als pascal/delphi. Pak daar dingen als de STL bij en externe libraries zoals boost, en je wilt gewoon niet meer anders

Laatst ging ik even snel een java applet in elkaar flansen, omdat ik een bepaald iets met een grafische interactie wilde prototypen. Java applets zijn daar uitermate geschikt voor, omdat je je even niet bezig hoeft te houden met het grafische framework (ik moet maar eens een C++/win32 framework voor dit soort dingen bouwen ). Ik heb me mateloos zitten ergen aan het feit dat ik niet even snel een vector van ints kon maken en daar doorheen kon lopen. Allereerst kun je er sowieso al geen primitieven in kwijt, en ten tweede moet je de hele tijd casten bij het aanspreken van entries. Ok, dat laatste lost java generics op voor zover ik weet, maar het blijft onhandig. Terwijl ik een std::vector in C++ gewoon kan benaderen alsof het een array is.

Nou vind ik sowieso al dat je, om een bepaald doel te bereiken, in java er met een gigantische omweg omheen moet. Objecten creëeren, classes maken die een bepaald interface hebben, allemaal erg onhandig. Het mag dan wel mooi OO zijn enzo, maar de usability voor deze C++ programmeur is toch wel zo goed als 0

[Woy]

De belangrijkste reden zou natuurlijk altijd de technische achtergrond moeten zijn. Dit is natuurlijk bijna nooit compleet het geval want de keuze zal ten eerste al beperkt worden door de kennis van de persoon die de taal kiest.

Bij thuis hobby projectjes en vooral voor een school ben je hier al minder aan gebonden. ( Behalve dat je voor school ook nog leraren moet hebben die de stof beheersen ).

Nu heb je bij veel mensen met hobby projectjes wel weer dat ze gewoon beginnen met wat aanklooien zonder ook maar enige technische kennis te hebben. Deze mensen komen vaak bij b.v. PHP of ASP uit. Dit is dan overduidelijk wel een keuze omdat "de massa" het ook doet.
Op zich is dit in eerste instantie nog niet zo'n slechte keuze want er is dan tenslotte ook veel documentatie en andere resources voor te vinden, hierbij is echter ook meteen weer het probleem dat er ook veel slechte resources voor bestaan waardoor je niet netjes leert ontwikkelen.

Ook ben je binnen bedrijven vaak gebonden aan de standaard. Stel een bedrijf maakt al zijn projecten in c++/java/php/c# dan zal er niet zo snel gekozen worden om een andere taal te kiezen terwijl het toch zeker een beter technische basis heeft voor een bepaald project.

[GrimaceODespair]

/me geeft dan maar gehoor aan oproep van whoami

Het lijkt mij dat de meeste mensen gewoon beginnen waar de laagste drempel ligt. Zal wel niet zelden VB zijn (hoewel hier dadelijk een regen van proggers zal komen beweren dat ze daar niet mee begonnen zijn). Vanaf daar denk ik dat het voornamelijk ligt aan de omgeving waarin je functioneert.

Ik kan me niet voorstellen dat er veel mensen Java zijn gaan programmeren, omdat ze zonodig een standalone applicatie wilden bouwen.

Nu kan je je op zijn beurt weer afvragen hoe dan die taal in die omgeving komt: hype of gewoonterecht van de über-progger.

Zelf ben ik een nieuwsgierig iemand, en probeer ik graag alles uit. Maar een taal gebruiken omdat ie hip is, doe ik persoonlijk niet. Ik zal eerder kijken welke taal het beste aansluit bij mijn taak. En in dat geval, zie mijn vorige post

offtopic:
waarmee ik eigenlijk, bij nalezen, nog niet veel bijgedragen heb aan het topic, waarvoor mijn oprechte excuses

[ Voor 7% gewijzigd door GrimaceODespair op 03-11-2003 14:40 ]

[Creepy]

Verwijderd schreef op 03 november 2003 @ 14:27:
[...]


Het stoer zijn boeit mij echt helemaal niets. De technische achtergrond, des te meer. Als programmeur moet je volgens mij een taal kiezen, waarbij de compiler al het werk doet wat er van een compiler op dit moment valt te verwachten.

PHP valt hier dus totaal niet onder (ja, ik weet dat het geinterpreteerd wordt).
JAVA valt hier ook niet onder.

Dus java en php vallen volgens jou voor elke programmeur of omdat de compiler niet al het werk doet wat we van een compiler op dit moment mogen verwachten? Kan je dit nader toelichten want ik snap je echt niet (het feit dat java en php geinterpreteerd zijn laat ik ff achterwege)

Trouwens.. een taal kiezen op grond van de compiler?? Ik denk eerder dat je een taal kiest afhankelijk van de (on)mogelijkheden maar ook de desbetreffende voorzieningen die er voor die taal zijn (IDE, standaard libs, docs etc)

Tja.... een programmeer taal kiezen. Iemand die zichzelf wil leren programmeren en weinig tot geen achtergrond heeft kiest denk ik de taal die het meest populair is.
Iemand met een bepaalde achtergrond zal zeer waarschijnlijk een taal kiezen waarvan de kennis is opgedaan gezien z'n achtergrond.
En iemand met een redelijk technische kennis die een nieuwe taal wil gaan leren zal die denk ik kiezen op basis wat voor hem (technisch?) het meest interresant is.

Ik ben bijv. goed bekend met Pascal en Delphi, en in mindere mate met C. Als ik iets moet gaan ontwikkelen doe ik dat 9 van de 10 keer met Delphi, want daarmee ben ik gewoon het snelst.

Ik ben een tijdje terug alweer begonnen met C++. Waarom? Ik wilde in Linux goed uit de voeten kunnen met een OO taal. Tevens wil ik graag .NET eens leren (C#), omdat ik het idee heb dat deze omgeving het helemaal gaat "maken", en omdat het qua opzet voor een deel op Delphi/VCL lijkt.

[GrimaceODespair]

Creepy schreef op 03 november 2003 @ 14:40:
Ik denk eerder dat je een taal kiest afhankelijk van [...] de desbetreffende voorzieningen die er voor die taal zijn (IDE, standaard libs, docs etc)

Da's vreemd om ineens op te merken. Het klinkt heel logisch, maar ik heb het zelf, denk ik, nog nooit gedaan.

Hmm... bedenk me ineens dat ik ooit wel C++ ben gaan proggen, omdat Visual Studio ter beschikking stond, maar dat valt denk ik onder een ander rijtje argumenten.

[Verwijderd]

Hangt ook (in mijn geval) in sterke mate af welke talen er al ingebruik zijn in het project. Niemand zit bij een zeer groot project er op te wachten als er nog een taal wordt geintroduceerd omdat Pietje dat zo leuk vind of goed kent. Veel te duur om (soms jaren later) te onderhouden.

Dus meestal C voor product en tools.
Shell voor (simpele) tools.
HTML/Javascript voor interfaces naar sommige tools.

[Varienaja]

Een programmeertaal wordt niet alleen 'goed' door uit mooie code te bestaan; niet goed door efficiente code op te leveren; niet goed doordat de code op allerlei HW-platforms compileert.

Het is (zoals altijd) een combinatie van die dingen.

Ik heb zelf de meeste ervaring met Delphi, ik ik huldig de F1-knop. Het is bij Delphi vre-se-lijk makkelijk om van allerlei typen eventjes op te zoeken hoe dit-of-dat ook alweer zat. Compileren gebeurt meestal binnen 1 seconde; heerlijk.

Soms zit ik achter C++ van Borland; dan duurt compileren opeens 20 minuten en daar wordt ik *nogal* chagrijnig van.

In de IDE van C++ van Microsoft kon je terwijl je door de code aan het steppen was nog variabelen van waarde veranderen. Ik vond dat ultiem debuggen, het bespaart je veel tijd doordat je bepaalde cases niet van tevoren in je programma hoeft op te nemen.

Als programmeur heb je altijd een bepaald doel voor ogen. Het stuk gereedschap waarbij dat doel gehaald wordt is bruikbaar. Afhankelijk van je eisen voor elegantie, efficientie, en zo nog wat eigenschappen maar ook je eigen lamheid om iets nieuws te leren is een bepaalde taal *voor jou* het beste.

De beste programmeertaal van de wereld is iets wat niet bestaat denk ik. Als je als maat neemt de hoeveelheid tegels code die ergens mee wordt geschreven, dan staat C++ nog steeds bovenaan denk ik. Java en .net zullen wel snel dichtbij komen; misschien zelfs C++ inhalen.

[Woy]

Creepy schreef op 03 november 2003 @ 14:40:
[...]
(het feit dat java en php geinterpreteerd zijn laat ik ff achterwege)

Ik zou java niet zosnel een geinterpreteerde taal noemen. Tuurlijk wordt de Code eerst naar ByteCode gecompileerd en daarna wordt bij het draaien van de applicatie nog verder gecompileerd ( Om het even heel kort te zeggen ).

Trouwens.. een taal kiezen op grond van de compiler?? Ik denk eerder dat je een taal kiest afhankelijk van de (on)mogelijkheden maar ook de desbetreffende voorzieningen die er voor die taal zijn (IDE, standaard libs, docs etc)

Maar ik vind inderdaad niet dat het wel of niet compileren van een taal de keuze moet beinvloeden. Dat je een aantal voordelen die ook met compileren meekomen wel belangrijk vindt kan ik me voorstellen. Hierbij bedoel ik natuurlijk onder andere performance/ syntax checking.

Voor de rest zijn inderdaad ook de library's en ontwikkel omgevingen erg belangrijk. De keuze van een programmeer taal zal in het geval van een bedrijf altijd uit moeten gaan van de best kosten/kwaliteit verhouding. En een ontwikkel omgeving kan nou eenmaal ontzettend veel ontwikkel tijd besparen en dus de kosten een stuk lager laten uitvallen.

[Freee!!]

Varienaja schreef op 03 november 2003 @ 14:44:
[...]
Als programmeur heb je altijd een bepaald doel voor ogen. Het stuk gereedschap waarbij dat doel gehaald wordt is bruikbaar. Afhankelijk van je eisen voor elegantie, efficientie, en zo nog wat eigenschappen maar ook je eigen lamheid om iets nieuws te leren is een bepaalde taal *voor jou* het beste.

Hier kan ik het wel mee eens zijn.

De beste programmeertaal van de wereld is iets wat niet bestaat denk ik. Als je als maat neemt de hoeveelheid tegels code die ergens mee wordt geschreven, dan staat C++ nog steeds bovenaan denk ik. Java en .net zullen wel snel dichtbij komen; misschien zelfs C++ inhalen.

Ik denk dat C++ een leuke derde is. Met stip op nummer één staat al sinds jaar en dag COBOL. Op nummer twee staat nog altijd assembly, hoewel dat gezien de grote verschillen door de verschillende hardware platformen niet direct één taal is en daarna komt (waarschijnlijk) C++.

NB.: Er zijn meer computers dan alleen PCs en Apples en de meeste grote systemen worden niet (uitsluitend) in C++ geprogrammeerd.

[Creepy]

rwb schreef op 03 november 2003 @ 14:49:
[...]

Ik zou java niet zosnel een geinterpreteerde taal noemen. Tuurlijk wordt de Code eerst naar ByteCode gecompileerd en daarna wordt bij het draaien van de applicatie nog verder gecompileerd ( Om het even heel kort te zeggen ).

My bad... ik had beter kunnen zeggen "niet native gecompileerd"

[Yoeri]

Zelf ben ik ooit begonnen met QBasic, aangezien dat de enige taal was waarvan ik wist dat die bestond. Dankzij Nibbles en Gorilla wou ik ook wel eens een spelletje maken.

Heb toen m'n eerste boek gekocht... Programmeren met Microsoft QBasic. Met de tijd groeide ook de interesse naar ècht programmeren, en een logische overstap was dus Visual Basic. Onder andere hierdoor werd ik een beetje een MS-adept, en ga ik momenteel nog steeds voor Visual Basic (natuurlijk is dat nu .NET geworden) en ASP (ook .NET).

Tijdens m'n opleiding werd ik natuurlijk verplicht met c++, java en RPG te werken, maar dankzij m'n 'jarenlange ervaring' was de drempel om die talen (c++ en java natuurlijk, ik zie me thuis nog geen AS/400 neerzetten ) ook privé te gaan gebruiken te hoog. Vooral in het geval van Java voelde ik me niet thuis in de omgeving.

Veel hangt af van hoe je begint denk ik. Als je eerste stapjes in het programmeren bestaan uit 'ik wil een website waar je kunt registreren', dan zul je al snel bij php terecht komen vanwege de gigantische resources die er zijn. Op die manier kom je in de c syntax terecht en stap je misschien makkelijker naar C++ en java dan iets anders.

'Stoerheid' zal daarbij zeker een rol spelen, alhoewel dit beperkt is denk ik. M'n website is geschreven in Sie Sjarp klinkt toch stoerder dan pee haa pee, niet? Maar toch kiezen beginners sneller voor php. Of is daar een andere reden voor?

[.oisyn]

Of is daar een andere reden voor?

wat dacht je van hosting?

[Yoeri]

.oisyn schreef op 03 november 2003 @ 15:45:
wat dacht je van hosting?

mag ik dat gemakkelijkheidshalve even bij resources rekenen?

al heb je natuurlijk wel gelijk in het geval van web-programmeren, maar dat gaat dan weer niet op in het geval van:
Mijn muziekdatabase-interface is geschreven in Sie Sjarp...

Alhoewel, waarmee gaan de meeste beginners van start voor niet-web-applicaties? VB waarschijnlijk toch?

[Verwijderd]

Creepy schreef op 03 november 2003 @ 14:40:
[...]

Dus java en php vallen volgens jou voor elke programmeur of omdat de compiler niet al het werk doet wat we van een compiler op dit moment mogen verwachten? Kan je dit nader toelichten want ik snap je echt niet (het feit dat java en php geinterpreteerd zijn laat ik ff achterwege)

Nee, ik zeg dat men dat zou moeten doen.

Als ik naar JAVA kijk, dan krijg je soms nullpointerexceptions. Goed, dat kan gebeuren, maar als de compileren dan even een handje helpt en zegt:"Nou, daar doe je iets onhandigs, het moet dit zijn" of "bedoel je dit niet?".

Je kunt soms wel een uur aan het zoeken zijn naar zo'n fout.

Trouwens.. een taal kiezen op grond van de compiler?? Ik denk eerder dat je een taal kiest afhankelijk van de (on)mogelijkheden maar ook de desbetreffende voorzieningen die er voor die taal zijn (IDE, standaard libs, docs etc)

Standaardlibs en dergelijke zijn natuurlijk wel handig, maar als je een beetje krachtige taal, hebt, kun je die ook wel laten genereren uit andere talen.

En een IDE?
Tja, ik ben er nog niet veel tegengekomen, die goed van structuur zijn en geen onzinnige code produceren. (bijv. C++ Builder 6(voor simpele applicaties nog wel te doen, maar als je meer wilt, dan wordt het toch een beetje lastig)).

Misschien dat NetBeans wat is, maar dat heb ik nog nooit echt geprobeerd.

Documentatie is iets wat elke zichzelf respecterende taal wel heeft, anders wordt het nl. niets.

Een IDE is niet altijd nodig (voor refactoring in JAVA is het wel handig), maar ik heb ook een hekel aan JAVA, omdat je dus moet refactoren.

IMHO is refactoren vanuit programmeeropzicht volstrekt onzinnig.

Daarmee bedoel ik dus dat in de beste programmeertaal het niet nodig zou moeten zijn om te refactoren.

[igmar]

Mr. Liu schreef op 03 november 2003 @ 14:55:
Ik denk dat C++ een leuke derde is. Met stip op nummer één staat al sinds jaar en dag COBOL. Op nummer twee staat nog altijd assembly, hoewel dat gezien de grote verschillen door de verschillende hardware platformen niet direct één taal is en daarna komt (waarschijnlijk) C++.

No way dat asm op #2 staat. D'r is geen fatsoenlijk bedrijf wat veel asm programmeert, niet op de standaard platformen iig.

NB.: Er zijn meer computers dan alleen PCs en Apples en de meeste grote systemen worden niet (uitsluitend) in C++ geprogrammeerd.

De meeste OS'en zijn in C geschreven, niet in C++. Dat geldt ook voor zaken zoals C libs, en wat dat betreft staat C met stip op #1. Ik denk zelfs dat C zowiezo op #1 staat, en niet Cobol.

[Freee!!]

igmar schreef op 03 november 2003 @ 16:07:
[...]
No way dat asm op #2 staat. D'r is geen fatsoenlijk bedrijf wat veel asm programmeert, niet op de standaard platformen iig.

Ik zeg niet dat het nog zo is, maar er zijn genoeg fatsoenlijke bedrijven geweest die heel fatsoenlijke programmatuur in assemby bouwden en dat verkochten (herinnert iemand zich WP nog ).

De meeste OS'en zijn in C geschreven, niet in C++. Dat geldt ook voor zaken zoals C libs, en wat dat betreft staat C met stip op #1.

Voor OS'en zou je met C gelijk kunnen hebben.

Ik denk zelfs dat C zowiezo op #1 staat, en niet Cobol.

Ik weet dat zo'n 90% van alle nu nog draaiende mainframe-programmatuur (niet OS) in COBOL is geschreven.

[whoami]

Misschien kunnen we terug on-topic gaan?
Dit topic gaat nl. niet over in welke taal het meeste lijnen code geschreven zijn... Dat is trouwens iets wat je nooit met zekerheid zult kunnen zeggen.

Om maar even on-topic te gaan:

Als je een applicatie gaat schrijven, ga je toch zowiezo eerst gaan kijken naar 'welke taal kan ik gebruiken om die applicatie zo goed mogelijk te schrijven'.
Als je een web-applicatie gaat maken, dan zal je normaal gezien niet overwegen om C++ te gaan gebruiken. Dan kom je al gauw uit op talen ala PHP, VB.NET, C# (icm ASP.NET).
Dan zullen er andere dingen bij komen kijken die je uiteindelijke keuze zullen gaan beinvloeden: heb ik al ervaring met de mogelijke talen? Wat zijn de voordelen van taal A tov taal B, werk ik liever in een strong-typed taal of liever in een weak-typed? etc....

Ik denk niet dat een serieuze developer zich zal gaan bezighouden met 'de stoerheid' van een taal.

[ Voor 66% gewijzigd door whoami op 03-11-2003 16:23 ]

[Freee!!]

whoami schreef op 03 november 2003 @ 16:16:
Misschien kunnen we terug on-topic gaan?
Dit topic gaat nl. niet over in welke taal het meeste lijnen code geschreven zijn... Dat is trouwens iets wat je nooit met zekerheid zult kunnen zeggen.

Goed plan, excuses.

[Woy]

Nou ik iets over hosting lees is dat inderdaad ook een belangrijke reden om voor een taal te kiezen. Heb zelfs laatst nog een simpel gastenboekje in Perl cgi-script geschreven omdat dat toevalig de enige serverside taal was wat bij dat hosting pakket aanwezig was.

De beschikbaarheid van een runtime een belangrijke reden om bijvoorbeeld niet voor C# of Java ( of andere progtaal met een runtime ) te kiezen voor een client side app. Je hebt er namelijk de .net of java runtime voor nodig is. Als je software op CD levert is dat natuurlijk geen probleem maar omdat er steeds vaker ook software via internet geleverd wordt zul je hier toch rekening mee moeten houden dat niet iedereen een runtime van 20MB wil downloaden. Je zult in dat geval toch moeten afvragen of jouw doelgroep dat wel doet.

[.oisyn]

Dat dat voor .net een probleem is is in principe maar tijdelijk. Er komen steeds meer en meer .net applicaties, en .net zit standaard ook bij de volgende windows OSen. En wordt het niet ook al geinstalleerd bij een windows update?

[Woy]

.oisyn schreef op 03 november 2003 @ 16:35:
Dat dat voor .net een probleem is is in principe maar tijdelijk. Er komen steeds meer en meer .net applicaties, en .net zit standaard ook bij de volgende windows OSen. En wordt het niet ook al geinstalleerd bij een windows update?

Ja dat is wel waar. Het wordt volgens mij met SP1 meegeinstalleerd en in volgende versies van windows ieder geval.
Dat is eigenlijk ook de reden dat ik erbij zette dat je je moet afvragen of het voor je doelgroep een probleem is. Er blijven altijd mensen met oude oss'en. Stel je hebt een doelgroep waar je van weet dat ze met oude apperatuur werken dan zullen ze niet snel windows xp of nieuwer geinstalleerd hebben en zullen dat in de nabije toekomst ook niet krijgen ook. Deze doelgroep zal dan ook zeker niet de snelste internet verbinding hebben. Heb je als doelgroep een bedrijf wat veel met computers werkt dan zal dit probleem zich natuurlijk binnen de kortste keren oplossen.

[Freee!!]

rwb schreef op 03 november 2003 @ 16:46:
[...]
Ja dat is wel waar. Het wordt volgens mij met SP1 meegeinstalleerd en in volgende versies van windows ieder geval.
Dat is eigenlijk ook de reden dat ik erbij zette dat je je moet afvragen of het voor je doelgroep een probleem is. Er blijven altijd mensen met oude oss'en.

En wat dacht je van allerlei, vaak ook nieuwe non-windows OS'en (Linux bijvoorbeeld)

Stel je hebt een doelgroep waar je van weet dat ze met oude apperatuur werken dan zullen ze niet snel windows xp of nieuwer geinstalleerd hebben en zullen dat in de nabije toekomst ook niet krijgen ook. Deze doelgroep zal dan ook zeker niet de snelste internet verbinding hebben. Heb je als doelgroep een bedrijf wat veel met computers werkt dan zal dit probleem zich natuurlijk binnen de kortste keren oplossen.

En wat als (het grootste deel van) je doelgroep een OS draait waar geen runtime van jouw programmeertaal voor is

[Woy]

Mr. Liu schreef op 03 november 2003 @ 16:52:
[...]

En wat dacht je van allerlei, vaak ook nieuwe non-windows OS'en (Linux bijvoorbeeld)

[...]

En wat als (het grootste deel van) je doelgroep een OS draait waar geen runtime van jouw programmeertaal voor is

Dat is precies hetgene wat ik aan wil geven. Een runtime voor een programmeer taal kan een reden zijn om er niet voor te kiezen. Je moet je eerst afvragen of je doelgroep problemen kan hebben met de runtime. In een aantal gevallen zal het totaal geen problemen opleveren, maar als je een programma wilt ontwikkelen wat ook onder linux draait dan is het niet slim om in VB of in .NET te ontwikkelen. In .net kan het trouwens wel in combinatie met MONO maar je moet je dan wel goed realiseren dat je aan een aantal beperkingen gebonden bent en dus niet gewoon standaar alle functionaliteit uit het .net framework kan gebruiken

[EfBe]

Mr. Liu schreef op 03 november 2003 @ 16:52:
[...]
En wat dacht je van allerlei, vaak ook nieuwe non-windows OS'en (Linux bijvoorbeeld)

So? Als je software voor windows ontwikkelt, wat boeit het bestaan van een ander os dan?

[...]
En wat als (het grootste deel van) je doelgroep een OS draait waar geen runtime van jouw programmeertaal voor is

Dan heb je de verkeerde taal gekozen. Wat is daar moeilijk aan?

[Apollo_Futurae]

.oisyn schreef op 03 november 2003 @ 14:35:
Voor mij persoonlijk komt het vooral neer op de efficienty van de taal, en hoe snel het mogelijk is om er iets mee te maken. Goed, C en C++ is staan erom bekend dat je er behoorlijk efficiente code mee kunt schrijven. Maar op zich geldt dat wel voor veel native talen.

Ik vraag me af bij hoeveel procent van alle huidige applicaties de snelheid van het gecompileerde nog erg belangrijk is (mits binnen redelijke grenzen). De tijd die je vroeger () stopte in low level optimalisaties, kun je tegenwoordig beter steken in abstract ontwerp en gebruiksvriendelijkheid (algemeen gesproken natuurlijk, er zijn altijd speciale gevallen waarin je je asm kennis mag opfrissen).

Creepy schreef op 03 november 2003 @ 14:40:
Trouwens.. een taal kiezen op grond van de compiler?? Ik denk eerder dat je een taal kiest afhankelijk van de (on)mogelijkheden maar ook de desbetreffende voorzieningen die er voor die taal zijn (IDE, standaard libs, docs etc)

Het lijkt me dat het de kwaliteit van de compiler toch zeker van belang is (als je tenminste een compiler gebruikt). Denk aan de kwaliteit van foutmeldingen, optimalisaties waar je je zelf niet meer druk over hoeft te maken, etc.

rwb schreef op 03 november 2003 @ 14:49:
Maar ik vind inderdaad niet dat het wel of niet compileren van een taal de keuze moet beinvloeden. Dat je een aantal voordelen die ook met compileren meekomen wel belangrijk vindt kan ik me voorstellen. Hierbij bedoel ik natuurlijk onder andere performance/ syntax checking.

In sommige situaties moet een programma nu eenmaal gecompileerd worden, bij voorbeeld als je een gebruiker na het downloaden van je client side progsel niet vele seconden/minuten/uren wilt laten wachten tot het geheel gebruiksklaar is.
Bij websites en server side programma's is het vaak prettiger om met een geïnterpreteerde taal te werken. Het mooie van een gecompileerde taal is echter, dat je zo een interpreter kunt bouwen voor een domeinspecifiek scripttaaltje of een gestructureerde verzameling (XML-)documenten. Het omgekeerde is niet mogelijk: geïnterpreteerd blijft geïnterpreteerd.

EfBe schreef op 03 november 2003 @ 17:21:
So? Als je software voor windows ontwikkelt, wat boeit het bestaan van een ander os dan?

Ik vind het erg raar om in deze tijd nog voor een specifiek OS te ontwikkelen. In sommige gevallen is dit natuurlijk noodzakelijk (drivers of syteem libraries ofzo), maar dat zijn uitzonderingen. Waarom zou je niet abstraheren over zoiets onbenulligs als het OS van de gebruiker?

[.oisyn]

Apollo_Futurae schreef op 03 november 2003 @ 18:15:
Ik vraag me af bij hoeveel procent van alle huidige applicaties de snelheid van het gecompileerde nog erg belangrijk is (mits binnen redelijke grenzen). De tijd die je vroeger () stopte in low level optimalisaties, kun je tegenwoordig beter steken in abstract ontwerp en gebruiksvriendelijkheid (algemeen gesproken natuurlijk, er zijn altijd speciale gevallen waarin je je asm kennis mag opfrissen).

Misschien is het nieuw voor je, maar er bestaan ook nog altijd mensen die dingen als games, drivers, lowlevel software en simulaties e.d. maken
(ikzelf houd me voornamelijk met de eerste en de laatste bezig, en daarom kies ik ook voor C++)

Ik vind het erg raar om in deze tijd nog voor een specifiek OS te ontwikkelen. In sommige gevallen is dit natuurlijk noodzakelijk (drivers of syteem libraries ofzo), maar dat zijn uitzonderingen. Waarom zou je niet abstraheren over zoiets onbenulligs als het OS van de gebruiker?

sorry, maar ik vind platformonafhankelijkheid nog steeds een idealistisch iets, en het gros van de commerciele software developers developt nog altijd voor een specifiek OS of superset van OSen. Ik weet niet hoe serieus jij met software development bezig bent, maar het is voor de meeste bedrijven totaal onaantrekkelijk om platform onafhankelijk te ontwikkelen. Allereerst kost die abstractie geld, je bent er immers langer mee bezig. Bovendien moet je voor verschillende OSen verschillende implementaties schrijven. Daar komt nog eens bij dat 90% (als het niet meer is) van de gebruikers gewoon windows draait, dus ook een linux applicatie erbij ontwikkelen is vrij nutteloos voor grote apps. Het kost dan meer geld dan dat je ermee verdient namelijk

Dingen als GUIs werken gewoon slecht als platformonafhankelijk systeem. Je wilt namelijk de look and feel van het OS behouden (ik heb persoonlijk bijvoorbeeld een hekel aan een applicatie die er totaal anders uit ziet en werkt dan de rest van mijn windows applicaties). De interfaces van verschillende OSen werken gewoon verschillend.

[ Voor 3% gewijzigd door .oisyn op 03-11-2003 18:28 ]

[ari3]

.oisyn schreef op 03 november 2003 @ 18:27:
[...]

sorry, maar ik vind platformonafhankelijkheid nog steeds een idealistisch iets, en het gros van de commerciele software developers developt nog altijd voor een specifiek OS of superset van OSen. Ik weet niet hoe serieus jij met software development bezig bent, maar het is voor de meeste bedrijven totaal onaantrekkelijk om platform onafhankelijk te ontwikkelen. Allereerst kost die abstractie geld, je bent er immers langer mee bezig. Bovendien moet je voor verschillende OSen verschillende implementaties schrijven. Daar komt nog eens bij dat 90% (als het niet meer is) van de gebruikers gewoon windows draait, dus ook een linux applicatie erbij ontwikkelen is vrij nutteloos voor grote apps. Het kost dan meer geld dan dat je ermee verdient namelijk

Mischien dat Windows op de desktop nog dominant is, maar in de markt voor server applicaties is het heel anders. Daar domineren *BSD, Solaris, VMS en Linux. Microsoft is daar zeker niet de grootste speler.

Platform-onafhankelijke abstractie kost niets als je in Java ontwikkeld. Sun heeft die abstractie op ieder denkbaar niveau al gemaakt voor je

Dingen als GUIs werken gewoon slecht als platformonafhankelijk systeem. Je wilt namelijk de look and feel van het OS behouden (ik heb persoonlijk bijvoorbeeld een hekel aan een applicatie die er totaal anders uit ziet en werkt dan de rest van mijn windows applicaties). De interfaces van verschillende OSen werken gewoon verschillend.

Juist dingen als GUIs werken perfect als platformonafhankelijk systeem. Java applicaties gebouwt met de SWING API houden gewoon hun look & feel van het host-OS.

[GrimaceODespair]

ari3 schreef op 03 november 2003 @ 19:19:
Platform-onafhankelijke abstractie kost niets als je in Java ontwikkeld. Sun heeft die abstractie op ieder denkbaar niveau al gemaakt voor je

Kan je nog mooier flamebait bedenken

[.oisyn]

ari3 schreef op 03 november 2003 @ 19:19:
Platform-onafhankelijke abstractie kost niets als je in Java ontwikkeld. Sun heeft die abstractie op ieder denkbaar niveau al gemaakt voor je

juist het GUI element van java vind ik vrij bagger

Juist dingen als GUIs werken perfect als platformonafhankelijk systeem. Java applicaties gebouwt met de SWING API houden gewoon hun look & feel van het host-OS.

oh, kun jij mij dan verklaren waarom het er dan altijd anders uitziet? Als ik een Swing app draai op mijn pc dan herken ik direct Java. Lijkt me toch niet zo fantastisch OS look & feel dan, of wel?

Bovendien draaien Swing apps ook heel erg traag. Nog een reden om geen Java te gebruiken voor GUI applicaties. Ik besteed mijn cpu cycles liever aan nuttigere dingen

[ Voor 4% gewijzigd door .oisyn op 03-11-2003 19:27 ]

[Rataplan]

Ik heb met C# het gevoel dat ik voor het laatst in 1985 met Turbo Pascal had: "wat móóóói! Wat lékker! Wat snél!"

Een taal die hyperlogisch inelkaar steekt, overzichtelijk is, en doet wat 'ie moet doen. Java zou me eerder in hebben kunnen pakken, denk ik, als er niet van die crappy runtimes waren geweest die mij ervan overtuigden dat het maar een brak projekt was. Als je twee getallen bij elkaar optelt moet je niet drie seconden geduld moeten hebben. Vandaar C++, en dat was afgelopen toen ik C# tegenkwam. Jammer dat de class library onder MONO nog huilen met de pet op is (en er dat gezeik tussen de Windows- en de Gnome-libs is, waardoor je straks weer fijn kan gaan porten); anders was ik meer dan happy.

* Rataplan is verliefd op C#. Telt dat ook als argument?

edit:

Over argumenten gesproken, overzichtelijke libs en een handig IDE zijn wel dingen die bij mij meetellen in de keuze voor een taal, maar de taal zelf mag daar in de beschouwing los van staan. Dat C# snel uitvoert heb ik tenslotte ook alleen nog maar op 2G+-machines mogen constateren

[ Voor 18% gewijzigd door Rataplan op 03-11-2003 19:30 ]

[Apollo_Futurae]

.oisyn schreef op 03 november 2003 @ 18:27:
Misschien is het nieuw voor je, maar er bestaan ook nog altijd mensen die dingen als games, drivers, lowlevel software en simulaties e.d. maken
(ikzelf houd me voornamelijk met de eerste en de laatste bezig, en daarom kies ik ook voor C++)

Bij het ontwikkelen van drivers en low level is het inderdaad noodzakelijk rekening te houden met het onderliggende OS. Dit lijkt me echter een gespecialiseerde en kleine sector. Wat betreft je andere twee voorbeelden: een goede compiler kan veel makkelijke maar ingewikkelde optimalisaties automatisch voor je uitvoeren en biedt je bovendien de mogelijkheid om, als dat nodig mocht zijn, specifieke onderdelen met de hand op een lager abstractieniveau te versnellen.

sorry, maar ik vind platformonafhankelijkheid nog steeds een idealistisch iets, en het gros van de commerciele software developers developt nog altijd voor een specifiek OS of superset van OSen. Ik weet niet hoe serieus jij met software development bezig bent, maar het is voor de meeste bedrijven totaal onaantrekkelijk om platform onafhankelijk te ontwikkelen.

"Hoe de meeste bedrijven het doen" vind ik geen goed argument: de meeste mensen gebruiken windows, de meeste mensen generaliseren .
Ik zal direct toegeven dat ik niet professioneel software schrijf, maar ik ben arrogant genoeg om te denken dat ik het wel zou kunnen. Het is een serieuze hobby en ik zou er graag (mede) mijn geld mee gaan verdienen.

Allereerst kost die abstractie geld, je bent er immers langer mee bezig. Bovendien moet je voor verschillende OSen verschillende implementaties schrijven. Daar komt nog eens bij dat 90% (als het niet meer is) van de gebruikers gewoon windows draait, dus ook een linux applicatie erbij ontwikkelen is vrij nutteloos voor grote apps. Het kost dan meer geld dan dat je ermee verdient namelijk

Dat zijn veel onjuiste zinnen in één alinea .
Dergelijke abstractie kost geen extra ontwikkeltijd, als je er meteen mee begint.
Daarnaast is het hele idee van de abstractie nu juist, dat je maar één versie schrijft, die op alle platformen compileert. Een implementatie op een nieuw OS is een kwestie van een bootstrap (eventueel) en compilatie.
Hoeveel procent van je gebruikers windows gebruikt hangt nogal af van je gebruikersgroep, zoals terecht opgemerkt door ari3.

Dingen als GUIs werken gewoon slecht als platformonafhankelijk systeem. Je wilt namelijk de look and feel van het OS behouden (ik heb persoonlijk bijvoorbeeld een hekel aan een applicatie die er totaal anders uit ziet en werkt dan de rest van mijn windows applicaties). De interfaces van verschillende OSen werken gewoon verschillend.

Er zijn GUI libs die platformonafhankelijkheid èn native look and feel nastreven, en daarin succes boeken (langzaam, zeker, want het is veel werk, maar gestaag). Voorbeeld: wxWindows.

[faabman]

Ik script nu zelf al enige tijd in asp (vbscript).

Toen ik 2 jaar geleden begon kon ik netaan in frontpage een website opbouwen, toen heb ik eens een klein asp tutorial en een klein php tutorial gekocht en gekeken wat voor mij het makkelijkste was, dat was dus vbscript. Kosten waren voor mij geen afweging, ik kon in mijn localhost gewoon asp pagina's ontwikkelen en er zijn op het internet hostingproviders die erg goedkope oplossingen bieden.

Het argument 'stoer' begint bij mij eigenlijk pas wanneer ik een webapp af heb die precies werkt zoals ik dat wil (ik vind eigenlijk elke app die goed in mekaar steekt 'stoer' en dan maakt het mij geen reet uit wat de achterliggende techniek is).

Om nog een punt toe te voegen; als ik opnieuw zou mogen kiezen was ik weer voor asp gegaan, voor mij is het gewoon een prettig leesbare taal. Daarnaast is naar ik verwacht de 'upgrade' naar asp.net(iets waar ik voorzichtig eens aan het snuffelen ben) vanuit asp een stukje makkelijker dan vanuit php.

[.oisyn]

Apollo_Futurae schreef op 03 november 2003 @ 19:45:
Wat betreft je andere twee voorbeelden: een goede compiler kan veel makkelijke maar ingewikkelde optimalisaties automatisch voor je uitvoeren en biedt je bovendien de mogelijkheid om, als dat nodig mocht zijn, specifieke onderdelen met de hand op een lager abstractieniveau te versnellen.

ik geef je gelijk, maar ik zie niet in wat dat van invloed is op de stelling die ik zojuist maakte
Bovendien zijn er meer dingen dan alleen compile-level optimalisaties. Een compiler kan hooguit een stukje code sneller maken, maar het kan niet een ander algoritme voor je probleem gebruiken. Maar vooral code optimalisatie zijn hedendaagse C++ compilers heel erg goed in. Verder hebben niet-native talen over het algemeen als nadeel dat dataaccess langzamer gaat, door de verschillende checks die uitgevoerd moeten worden. En voor games en simulaties is data-access een van de belangrijkste elementen.

"Hoe de meeste bedrijven het doen" vind ik geen goed argument: de meeste mensen gebruiken windows, de meeste mensen generaliseren .

Dat gaf ik ook niet als argument.

Dat zijn veel onjuiste zinnen in één alinea .

oh?

Dergelijke abstractie kost geen extra ontwikkeltijd, als je er meteen mee begint.
Daarnaast is het hele idee van de abstractie nu juist, dat je maar één versie schrijft, die op alle platformen compileert. Een implementatie op een nieuw OS is een kwestie van een bootstrap (eventueel) en compilatie.

uhm, iets abstraheren kost juist heel veel tijd, zeker als je het ook nog uitgebreid wil doen. Het ene OS kan zus, en het andere OS kan zo, en dat onderzoeken en analyseren is niet wat je in een paar dagen doet. Ik ga er hier dus vanuit dat je zelf je onderliggende systeem ontwerpt en ontwikkelt.

(langzaam, zeker, want het is veel werk, maar gestaag).

oh, en daarnet zei je nog dat het geen tijd kostte?

[Apollo_Futurae]

.oisyn schreef op 03 november 2003 @ 19:56:
ik geef je gelijk, maar ik zie niet in wat dat van invloed is op de stelling die ik zojuist maakte

Ik zal proberen dit kort samen te vatten: je begon over snelheid van gecompileerde programma's. Ik dacht dat die snelheid er tegenwoordig grosso modo er niet zo toe doet. Jij noemde (onder andere) spellen en simulaties als tegenvoorbeelden. Ik zei daarop dat de daarvoor benodigde snelheid ook met "hogere" talen bereikt kan worden. Misschien is het nu duidelijk?

Bovendien zijn er meer dingen dan alleen compile-level optimalisaties. Een compiler kan hooguit een stukje code sneller maken, maar het kan niet een ander algoritme voor je probleem gebruiken. Maar vooral code optimalisatie zijn hedendaagse C++ compilers heel erg goed in. Verder hebben niet-native talen over het algemeen als nadeel dat dataaccess langzamer gaat, door de verschillende checks die uitgevoerd moeten worden. En voor games en simulaties is data-access een van de belangrijkste elementen.

Het belang van algoritmes tegenover codeoptimalisatie is tegenwoordig zeker groot. Ik zie echter niet in waarom dit voor een bepaalde (soort) taal zou pleiten? Een kenmerkende eigenschap van algoritmes is hun taalonafhankelijkheid. (Alhoewel sommige talen prettiger zijn om algoritmes in te implementeren dan andere, maar dat is, eh, ontopic .)
Wat bedoel je precies met een niet-native taal? Ook cross-platform talen kunnen naar native machinecode compileren.

Dat gaf ik ook niet als argument.

Hoe moet ik dan deze zin lezen?
"sorry, maar ik vind platformonafhankelijkheid nog steeds een idealistisch iets, en het gros van de commerciele software developers developt nog altijd voor een specifiek OS of superset van OSen"

uhm, iets abstraheren kost juist heel veel tijd, zeker als je het ook nog uitgebreid wil doen. Het ene OS kan zus, en het andere OS kan zo, en dat onderzoeken en analyseren is niet wat je in een paar dagen doet. Ik ga er hier dus vanuit dat je zelf je onderliggende systeem ontwerpt en ontwikkelt.

Misschien hebben we het over verschillende dingen?
Mijn idee van een abstractie over het OS van de gebruiker is het volgende:
• Wij, de programmeur , schrijven een programma in een zekere taal. Eén versie dus.
• Een medeontwikkelaar, een vrijwilliger of een enthousiaste gebruiker compileert het programma voor zijn/haar OS.
• Gebruikers van dat OS gebruiken het programma .

oh, en daarnet zei je nog dat het geen tijd kostte?

Voor de programmeur niet nee .

[EfBe]

Apollo_Futurae schreef op 03 november 2003 @ 18:15:
[...]
Ik vind het erg raar om in deze tijd nog voor een specifiek OS te ontwikkelen. In sommige gevallen is dit natuurlijk noodzakelijk (drivers of syteem libraries ofzo), maar dat zijn uitzonderingen. Waarom zou je niet abstraheren over zoiets onbenulligs als het OS van de gebruiker?

Wat een onbenulligheid, sorry. Volgens mij heb je er niet zoveel van begrepen. Je moet ALTIJD een targetplatform kiezen. Dat platform is bepalend voor je programmeerwerk: java, .NET, win32, libc, whatever... Je kunt niet dat even 'wegabstraheren', het GAAT daar juist om.

verder gaat deze thread niet over programmeertalen maar over platformen / API sets die je gebruikt in een programmeertaal. Een taal leer je nl. in een dikke dag, een grote API als het meezit in een jaar. Je kunt nl. wel C++ leren maar dan kun je nog geen COM(+) objects maken voor win32 op een goede manier.

[EfBe]

Apollo_Futurae schreef op 03 november 2003 @ 20:23:
Mijn idee van een abstractie over het OS van de gebruiker is het volgende:
• Wij, de programmeur , schrijven een programma in een zekere taal. Eén versie dus.
• Een medeontwikkelaar, een vrijwilliger of een enthousiaste gebruiker compileert het programma voor zijn/haar OS.
• Gebruikers van dat OS gebruiken het programma .

Laat maar zien, zo'n programma dat wars van api's en platforms overal te compileren is en te draaien is. Java is ook platform afhankelijk: het java platform en dan ook nog bv een JavaVM van een bepaalde versie, en die zijn niet voor ieder platform te krijgen.

Ga maar eens portable C++ schrijven dat iets anders doet dan 2 getallen bijelkaar optellen. 10 tegen 1 dat je je het schompes tikt aan #ifdefs en typedefs.

[Apollo_Futurae]

EfBe schreef op 03 november 2003 @ 20:29:
Wat een onbenulligheid, sorry. Volgens mij heb je er niet zoveel van begrepen. Je moet ALTIJD een targetplatform kiezen. Dat platform is bepalend voor je programmeerwerk: java, .NET, win32, libc, whatever... Je kunt niet dat even 'wegabstraheren', het GAAT daar juist om.

Hoezo niet? Wat is de moeilijkheid?

verder gaat deze thread niet over programmeertalen maar over platformen / API sets die je gebruikt in een programmeertaal. Een taal leer je nl. in een dikke dag, een grote API als het meezit in een jaar. Je kunt nl. wel C++ leren maar dan kun je nog geen COM(+) objects maken voor win32 op een goede manier.

De topictitel luidt anders: nu ja dat kun je zelf lezen. Verder leer je niet elke taal in een dag: sommige talen gebruiken totaal andere uitgangspunten dan OO en SP talen, (logisch, functioneel, dataflow, etc.). Die vereisen een andere manier van denken die je niet in een dag leert.

Laat maar zien, zo'n programma dat wars van api's en platforms overal te compileren is en te draaien is. Java is ook platform afhankelijk: het java platform en dan ook nog bv een JavaVM van een bepaalde versie, en die zijn niet voor ieder platform te krijgen.

Ik moet bekennen dat ik nog geen programma's heb geschreven die functioneel genoeg zijn om hier als voorbeeld te kunnen dienen, maar ik wil wel onthullen dat die fantastische taal van me haskell heet. Ik zie geen enkele belemmering meer voor OS-onafhankelijke softareontwikkeling, maar open mijn ogen als ze er zijn .

Ga maar eens portable C++ schrijven dat iets anders doet dan 2 getallen bijelkaar optellen. 10 tegen 1 dat je je het schompes tikt aan #ifdefs en typedefs.

Ik beweer ook niet dat C++ portable is .

[.oisyn]

Apollo_Futurae schreef op 03 november 2003 @ 20:23:
Ik zal proberen dit kort samen te vatten: je begon over snelheid van gecompileerde programma's. Ik dacht dat die snelheid er tegenwoordig grosso modo er niet zo toe doet. Jij noemde (onder andere) spellen en simulaties als tegenvoorbeelden. Ik zei daarop dat de daarvoor benodigde snelheid ook met "hogere" talen bereikt kan worden. Misschien is het nu duidelijk?

aha
Maar dat is dus niet zo. De hogere platformen (Java, .Net) zijn nog altijd te langzaam om echt als serieus spelplatform te dienen. Dat komt met name door de data-access waar ik het eerder over had. Runtime checks mbt bijvoorbeeld array bounds zijn gewoon een doorn in het oog. Je werkt in games en simulaties over het algemeen met gigantische datasets, en daar wil je op een zo snel mogelijke manier doorheen. Elke keer een check is dan echt niet fijn, ook al komt het de veiligheid ten goede. Veiligheid en snelheid zijn toch een beetje concepten die haaks op elkaar staan

Het belang van algoritmes tegenover codeoptimalisatie is tegenwoordig zeker groot. Ik zie echter niet in waarom dit voor een bepaalde (soort) taal zou pleiten? Een kenmerkende eigenschap van algoritmes is hun taalonafhankelijkheid. (Alhoewel sommige talen prettiger zijn om algoritmes in te implementeren dan andere, maar dat is, eh, ontopic .)

zie boven

Wat bedoel je precies met een niet-native taal? Ook cross-platform talen kunnen naar native machinecode compileren.

dat is mierenneukerij. Als ik het over native hebt dan bedoel ik dus dat het native is op het moment dat het uitgevoerd wordt, en daar valt JIT zoals java en .net niet onder

Hoe moet ik dan deze zin lezen?
"sorry, maar ik vind platformonafhankelijkheid nog steeds een idealistisch iets, en het gros van de commerciele software developers developt nog altijd voor een specifiek OS of superset van OSen"

Dat het woordje "en" tussen mijn mening en dat wat bedrijven doen staat maakt dat wat bedrijven doen toch automatisch al geen argument voor mijn mening
Ik gaf dus geen argumenten, enkel mijn mening, en wat de meeste bedrijven doen

[q]Misschien hebben we het over verschillende dingen?
Mijn idee van een abstractie over het OS van de gebruiker is het volgende:
• Wij, de programmeur , schrijven een programma in een zekere taal. Eén versie dus.
• Een medeontwikkelaar, een vrijwilliger of een enthousiaste gebruiker compileert het programma voor zijn/haar OS.
• Gebruikers van dat OS gebruiken het programma .

ah ok, dan praatten we dus langs elkaar heen. Maar ik heb nog geen intermediate platform gezien dat het op een goede en snelle manier implementeert. Sure, java is leuk, maar het gros van de OS specifieke functionaliteit is nog altijd niet te gebruiken. En dat is vaak nou juist wel wat je wilt als je een wat complexere applicatie schrijft.
Alles abstraheren is gewoon niet te doen. Neem bijvoorbeeld de verschillen tussen het linux en het NTFS filesystem. Ga jij maar eens op een onafhankelijke manier de rechten van een bepaalde file opvragen. Dat kun je niet. Dat zit ook niet in java, om diezelfde reden.

En laten we het maar niet hebben over het maken van een game voor verschillende platformen. Sure, games worden geport, maar er gaat behoorlijk wat tijd in zitten voordat een X-Box game op de playstation 2 werkt

Voor de programmeur niet nee .

degene die het framework ontwikkelt is ook een programmeur

[.oisyn]

Apollo_Futurae schreef op 03 november 2003 @ 20:47:
De topictitel luidt anders: nu ja dat kun je zelf lezen. Verder leer je niet elke taal in een dag: sommige talen gebruiken totaal andere uitgangspunten dan OO en SP talen, (logisch, functioneel, dataflow, etc.). Die vereisen een andere manier van denken die je niet in een dag leert.

OO en SP zijn programmeerconcepten die weinig met een taal te maken hebben. En het lijkt me redelijk relevant om die concepten door te hebben voordat je een andere taal gaat leren. En als je ze wel doorhebt dan leer je zo'n andere taal redelijk snel ja

Ik moet bekennen dat ik nog geen programma's heb geschreven die functioneel genoeg zijn om hier als voorbeeld te kunnen dienen, maar ik wil wel onthullen dat die fantastische taal van me haskell heet. Ik zie geen enkele belemmering meer voor OS-onafhankelijke softareontwikkeling, maar open mijn ogen als ze er zijn .

mja, functionele talen zijn leuk, maar ze zijn nou niet echt bepaald... eh.. functioneel
Vooral het feit dat ze stateless zijn maakt ze vrij onbruikbaar

Ik beweer ook niet dat C++ portable is .

Dan mag je nog een keer de boeken in duiken, want C++ is dat nou juist wel. Het is het gebruik van OS API's dat C++ programma's niet portable maakt. Pure C++ is echter perfect portable

[ Voor 5% gewijzigd door .oisyn op 03-11-2003 20:55 ]

[Alarmnummer]

.oisyn schreef op 03 november 2003 @ 20:47:
[...]
Dat komt met name door de data-access waar ik het eerder over had. Runtime checks mbt bijvoorbeeld array bounds zijn gewoon een doorn in het oog.

Gelukkig kunnen er optimalisaties uitgevoerd worden waardoor je niet continue loopt te checken op array bounds.

[ Voor 3% gewijzigd door Alarmnummer op 03-11-2003 20:54 ]

[.oisyn]

Alarmnummer schreef op 03 november 2003 @ 20:54:
[...]

Gelukkig kunnen er optimalisaties uitgevoerd worden waardoor je niet continue loopt te checken op array bounds.

Ja, dat lees je vaak, maar ik heb nog altijd geen praktijk voorbeeld gezien waarbij een Java of .Net applicatie de snelheid van een in native geimplementeerde applicatie benaderde. Als die er wel zijn zal ik er graag naar kijken en evt. mijn mening hervormen. Heb je linkjes?

[Alarmnummer]

.oisyn schreef op 03 november 2003 @ 20:57:
[...]


Ja, dat lees je vaak, maar ik heb nog altijd geen praktijk voorbeeld gezien waarbij een Java of .Net applicatie de snelheid van een in native geimplementeerde applicatie benaderde. Als die er wel zijn zal ik er graag naar kijken en evt. mijn mening hervormen. Heb je linkjes?

Ik heb niet een link. Het stond vermeld in Moder Compiler Implementation in Java dat het mogelijk was om die optimalisaties uit te voeren zonder bang te zijn dat er iets fout gaat. Ik weet trouwens niet hoe het bij java is gedaan.

[ Voor 13% gewijzigd door Alarmnummer op 03-11-2003 21:00 ]

[Apollo_Futurae]

.oisyn schreef op 03 november 2003 @ 20:47:
aha
Maar dat is dus niet zo. De hogere platformen (Java, .Net) zijn nog altijd te langzaam om echt als serieus spelplatform te dienen. Dat komt met name door de data-access waar ik het eerder over had. Runtime checks mbt bijvoorbeeld array bounds zijn gewoon een doorn in het oog. Je werkt in games en simulaties over het algemeen met gigantische datasets, en daar wil je op een zo snel mogelijke manier doorheen. Elke keer een check is dan echt niet fijn, ook al komt het de veiligheid ten goede. Veiligheid en snelheid zijn toch een beetje concepten die haaks op elkaar staan

Ik heb ook zeker niet Java of .Net in gedachten, maar een platformonafhankelijke taal die naar bij voorbeeld C of naar machinecode compileert (geen bytecode, virtual machine of andere rommel (nofi)). Ik zou niet weten waarom die te langzaam zou zijn. Runtime array bound checking kan simpelweg een compilatieoptie zijn.
Veiligheid en snelheid houden inderdaad niet van elkaar, maar je moet m.i. de afweging op elk moment zelf kunnen maken zonder onnodige complicatie.

dat is mierenneukerij. Als ik het over native hebt dan bedoel ik dus dat het native is op het moment dat het uitgevoerd wordt, en daar valt JIT zoals java en .net niet onder

zie boven

Dat het woordje "en" tussen mijn mening en dat wat bedrijven doen staat maakt dat wat bedrijven doen toch automatisch al geen argument voor mijn mening
Ik gaf dus geen argumenten, enkel mijn mening, en wat de meeste bedrijven doen

Laten we niet te veel gaan scherpslijpen, maar (let op: ernstig geval van praeteritio) ik begrijp niet wat je opmerking over "wat de meeste bedrijven doen" toevoegt, als het geen argument ergens voor of tegen is: het is wel geen argument, maar "je begrijpt wel wat ik bedoel" .

ah ok, dan praatten we dus langs elkaar heen. Maar ik heb nog geen intermediate platform gezien dat het op een goede en snelle manier implementeert. Sure, java is leuk, maar het gros van de OS specifieke functionaliteit is nog altijd niet te gebruiken. En dat is vaak nou juist wel wat je wilt als je een wat complexere applicatie schrijft.
Alles abstraheren is gewoon niet te doen. Neem bijvoorbeeld de verschillen tussen het linux en het NTFS filesystem. Ga jij maar eens op een onafhankelijke manier de rechten van een bepaalde file opvragen. Dat kun je niet. Dat zit ook niet in java, om diezelfde reden.

Ik kan het niet laten, sorry: link
Let vooral ook op de opmerking rechtsbovenaan: "Portability: portable".

En laten we het maar niet hebben over het maken van een game voor verschillende platformen. Sure, games worden geport, maar er gaat behoorlijk wat tijd in zitten voordat een X-Box game op de playstation 2 werkt

Als jij een goede DSL/API voor games ontwikkelt in een platformonafhankelijke taal, moet het toch mogelijk te zijn om dit naar een console te porten (ik heb geen idee wat voor talen daar gebruikt worden, maar dat maakt eigenlijk niet eens zo veel uit).

[.oisyn]

Apollo_Futurae schreef op 03 november 2003 @ 21:06:
[...]

Ik heb ook zeker niet Java of .Net in gedachten, maar een platformonafhankelijke taal die naar bij voorbeeld C of naar machinecode compileert (geen bytecode, virtual machine of andere rommel (nofi)). Ik zou niet weten waarom die te langzaam zou zijn. Runtime array bound checking kan simpelweg een compilatieoptie zijn.
Veiligheid en snelheid houden inderdaad niet van elkaar, maar je moet m.i. de afweging op elk moment zelf kunnen maken zonder onnodige complicatie.

there's more to it dan alleen codegeneratie. Het gaat met name om de stdlibs

Laten we niet te veel gaan scherpslijpen, maar (let op: ernstig geval van praeteritio) ik begrijp niet wat je opmerking over "wat de meeste bedrijven doen" toevoegt, als het geen argument ergens voor of tegen is: het is wel geen argument, maar "je begrijpt wel wat ik bedoel" .

neuh, meer zoiets van: "en de meesten zijn het met me eens". Maar goed, dit gaat nergens meer over, laat maar varen.

Ik kan het niet laten, sorry: link
Let vooral ook op de opmerking rechtsbovenaan: "Portability: portable".

Kun je daarmee ook de owner opvragen? En de group waarin die owner zit? En kun je de permissies ook wijzigen? Ik vindt readable, writable, executable en searchable wel erg summier eigenlijk

Als jij een goede DSL/API voor games ontwikkelt in een platformonafhankelijke taal, moet het toch mogelijk te zijn om dit naar een console te porten (ik heb geen idee wat voor talen daar gebruikt worden, maar dat maakt eigenlijk niet eens zo veel uit).

Het gaat niet om de taal, het gaat om de hardware. Zoals ik al zei, C++ is uitstekend portable, maar het aanspreken van de hardware is echt compleet anders. Daar waar de X-Box een gemodificeerde DirectX library gebruikt, moet je voor de PS2 allerlei chips direct aanspreken. En als je zoiets abstraheert dan haal je automatisch al niet meer de volledige performance, omdat een bepaalde manier van optimaliseren voor de PS2 juist heel goed kan uitpakken, terwijl de gevolgen voor de X-Box versie negatief zijn (bijvoorbeeld). Overigens wordt er in 99.999% van de gevallen C en C++ gebruikt

.edit: en we gaan zo langzamerhand alleen maar richting theoretische gevallen, terwijl het topic over de praktijk ging. En aangezien jij jezelf steeds indekt door te zeggen dat jij niet dat soort apps schrijft is het misschien nuttig om je er eerst eens in te verdiepen voordat je allerlei leuke theorietjes verzint. De werkelijkheid leert namelijk anders, en de wereld is nu eenmaal niet idealistisch

[ Voor 23% gewijzigd door .oisyn op 03-11-2003 21:18 ]

[Rataplan]

Alarmnummer schreef op 03 november 2003 @ 20:54:
[...]

Gelukkig kunnen er optimalisaties uitgevoerd worden waardoor je niet continue loopt te checken op array bounds.

*denkt aan turbo pascal*

code:

{SK-}

Hoef je alleen maar zorgvuldig te programmeren

[CyberSnooP]

Kies je niet vaak gewoon de taal die je het beste kent, mits hij geschikt is? (je gaat in PHP geen flinke windows-apps bouwen).

Persoonlijk hack ik kleine tools (tot nu toe) altijd nog even in Visual Basic. Omdat het een geweldige programmeer taal is? Nee, maar ik kan de meeste constructies wel op een mooie manier implementeren en het GUI bouwen mij goed bevalt, vooral door ervaring.

In hoeverre zijn de features van een taal nou echt voor belang voor het resultaat? Bij wat grotere applicaties en met de wat betere programmeur kun je toch in elke taal een degelijke applicatie bouwen, ongeacht of hij nou wel of geen Generic Programming heeft bijv?

Of zit ik er even helemaal naast.