[DISC] Programmeertalen: is de keuze niet reuze?

[mbravenboer]

Via Slashdot kwam ik net op een artikeltje op ZD-Net. Ik vond het wel grappig om te lezen (ondanks zijn sterk verkorte en versimpelde weegave) en daarnaast verkondigt het een mening die ik zelf ook al tijden tracht uit te dragen. Koren op m'n molen noemen ze dat geloof ik .

Het artikel behandelt in niet al te technische bewoordingen het probleem dat er eigenlijk voor een programmeur maar verrot weinig te kiezen valt als het om programmeertalen gaat. De kern van het verhaal is de stelling dat alle talen in .NET en het Java Platform in essentie hetzelfde zijn (zelfs de skin vergelijk, die we hier besproken hebben: [topic=403753/1/25] komt weer naar voren).

De auteur meldt (IMHO terecht) dat alle talen die op dit moment op .NET draaien zwaar aangepast zijn om ook in de CLR te kunnen draaien. De meest treffende voorbeelden hiervan zijn uiteraard Java en VB die respectievelijk getransformeerd zijn in J# en VB .NET. Ondanks dat je graag zou willen geloven dat dit gedaan is om de taal te verbeteren, zit er simpelweg een noodzaak achter. Zonder deze aanpassingen zijn Java en VB praktisch onbruikbaar in .NET.

Uiteindelijk komt het er op neer dat alles een variant is van C#. C# is namelijk de 'versyntaxing' van het object-model van .NET. Je zou daarom in feite kunnen zeggen dat alle talen die op .NET moeten draaien naar C# gecompileerd moeten kunnen worden. .NET is en blijft een object-georienteerde runtime.

Bij het Java Platform geldt hetzelfde: Java is vrijwel een 1 op 1 vertaling van het object-model van de Java Virtual Machine.

Nu ben je waarschijnlijk bang dat ik weer opnieuw het multi-language aspect door wil gaan zagen, maar nee: dat valt mee .

Wat wil je dan wel?

De kern van de huidige ontwikkeling is imho dat er in de komende jaren twee hoofdplatformen zullen zijn voor professionele en moderne ontwikkeling: .NET en J2EE. Deze omgevingen worden echter allebei beheerst door object-georienteerde talen: Java en C#. Talen die niet object-georienteerd zijn en toch willen draaien in .NET of J2EE zullen zichzelf moeten kunnen indrukken in OO-termen. De kern van de zaak is dat nog steeds de hoofd-ontwikkeling beheert zal worden door in feite maar 1 taal/paradigma: JavaC#.

Er zijn al tijden andere paradigma's in ontwikkeling die wel gebruikt worden, maar dan toch voornamelijk in niche omgevingen en de onderzoekswereld. Mijn vraag is: wanneer denk jij dat deze andere paradigma's een serieuze keuze zullen worden en naar aanleiding van welke ontwikkelingen?

De introductie van andere paradigma's in 'normale'-ontwikkeling zou naast een grotere keuze de onder andere de productiviteit kunnen verhogen, leiden tot minder bugs, maar wellicht ook een groot probleem voor het onderwijs.

Show * mbravenboer the future .

[mbravenboer]

Kleine toevoeging wat ik nog wilde vertellen in m'n topic: XSLT vindt ik op dit moment 1 van de positieve ontwikkelingen. Ondanks zijn vele negatieve kanten is dit toch een (simpele) toepassing van een volstrekt ander paradigma wat weet door te dringen tot de massa.

Welk paradigma/taal volgt? .

[Verwijderd]

Mooi stuk inderdaad.
Maar ik weet 't ook niet zo goed. Als je terugkijkt zie je dat dingen vaak anders lopen dan van tevoren gedacht werd.
Gewoon afwachten maar denk ik

[mbravenboer]

Klaas: Gewoon afwachten maar denk ik

Afwachten doe je maar als je 80 bent .

Ik wil speculaties! visies! meningen! flames!

[Orphix]

Ik heb het stukje even gelezen. Ik vind het persoonlijk niet erg dat de imperatieve talen naar een OO omgeving gaan. Ik denk zolangzamerhand dat in veel gevallen OO zich heeft bewezen t.o.v. procedurele talen. Er kunnen meerdere 'skins' gebruikt worden zolang er maar een OO paradigma in voorkomt. so far so good.

Nu begrijp ik dat er straks behoefte komt aan andere paradigma's, die een betere oplossing voor een bepaald probleem bieden. Nu vraag ik mij af, is het niet mogelijk om deze andere talen naar de CLR te 'compilen'? Ik zie niet in waarom dat niet kan?

[edit]ik zie nu dat ik mezelf een beetje tegenspreek anders zouden procedurele talen ook vast wel naar CLR omgezet kunnen worden
Kan iemand mij uitleggen waarom dit niet mogelijk is

[mbravenboer]

Orphix: Nu begrijp ik dat er straks behoefte komt aan andere paradigma's, die een betere oplossing voor een bepaald probleem bieden.

Mwah, dat beweer ik. Dat hoef je niet te begrijpen of te accepteren uiteraard .

Nu vraag ik mij af, is het niet mogelijk om deze andere talen naar de CLR te 'compilen'? Ik zie niet in waarom dat niet kan?

Zeker is dat wel mogelijk, maar ze moeten zich dan dus wel uitdrukken in OO-termen. Dat kan wel wat behoorlijke problemen opleveren, met name voor de performance van de zaak.

Daarnaast is het helaas een feite dat .NET een OO omgeving aanbiedt. Daarom zullen alternatieve paradigma's altijd minder goed aanvoelen en zal er dus wellicht nog minder snel voor deze paradigma's worden gekozen. Moet je je eens voorstellen dat je vanuit een functionele taal een procedure ( = methode zonder resultaat ) aan moet gaan roepen! Om te gillen .

Het gaat mij dus niet zozeer om mogelijkheden maar om de ontwikkelingen die jullie verwachten of zien. Zal de keuze ook voor normale projecten eindelijk breder worden en zullen andere paradigma's een serieuze optie worden?

anders zouden procedurele talen ook vast wel naar CLR omgezet kunnen worden . Kan iemand mij uitleggen waarom dit niet mogelijk is

Dat is best mogelijk denk ik. Je kunt vrijwel alles wel naar een OO-design compileren (zelfs functionele talen). Er zijn alleen grote praktische bezwaren: performance en de vraag of het wel binnen het platform biedt. Het gaat helaas niet zozeer om de vraag of het theoretisch mogelijk is om bijvoorbeeld Pascal of C naar IL te compileren, maar om de vraag of dat ook zinvol en bruikbaar zou zijn omdat .NET tenslotte een OO-omgeving presenteert.

[Nielsz]

Niet echt een paradigma, maar ik denk dat de aphpache ( ) groep de komende jaren erg groot zal blijven. Ik denk niet dat jsp snel die taak over zal nemen.
Het feit dat het gratis is, een 'makkelijke/vrije' taal (wat ook een nadeel is), de grote ondersteuning, de vele tutorials en dingen, het feit dat je buurman het ook doet.

Die dingen zorgen er allemaal voor dat je php gaat programmeren. En niet VB.NET

Een 'nadeel', php wordt ook OO. Het bestaat nu al, en het is bagger, maar bij de aankomende versies zal de nadruk er steeds meer op komen te liggen.
Wat aan de ene kant goed is (mooi programmeren), aan de andere kant slecht (hoge drempel).

Ik denk dat de huidige situatie zeer goed is. PHP is een mooi opstapje voor andere programmeertalen.


(maar of dit is wat je vraagt )


[ik zal nu nog ff wat adden, dus nog niet reageren :)]

[Orphix]

Moeten we bang zijn voor de performance. Wat is nou in feite het verschil tussen verschillende talen, je wilt hetzelfde zeggen, maar het anders uitdrukken.
In perl kan je bv $text =~ s/verander/dit; doen om een regexp replace te doen, in C++ is dit een stuk uitgebreidere moeilijker om te doen, maar je komt op hetzelfde neer.
Het voordeel van Perl is dat een paar slimme koppen voor jou die replace uitermate efficient hebben gemaakt zodat je je daar niet druk over hoeft te maken. Dat is het voordeel van verschillende talen, het dient een ander doel (perl in dit geval flexibele tekst mutatie).

Maar okay, we nemen nu een compleet andere taal, SQL, ik weet niet of ik die hier zo mag noemen, maar deze gebruikt een heel ander paradigma. Toch wordt dit altijd geinterpreteerd door een ander programma die de syntax begrijpt en hier snelle code voor maakt.
Wat ik dus bedoel is dat de 'basis' imo best de CLR kan zijn, net als in dit geval assembly de 'basis' vormt voor alle talen.

[Verwijderd]

Ik zou het gewoon bij .NET houden, Delphi is ook grappig, wel OO, maar volgens mij nog niet op het .NET platform aangesloten, alle programmeertalen die niet OO zijn halen het volgens mij op de lange termijn niet.

Ik denk dat je .NET ( dus alles dat via de CLR gaat ), als hoofd programmeertaal kan gebruiken, en dat je dan nog XML/XSL, SOAP, SQL en alle andere technieken kan gebruiken om die .NET applicatie te versterken. Maar ik denk niet dat er een vervanger gaat komen.

De in mijn mening grootste en sterkste software fabrikant heeft gewoon voor deze richting gekozen ( in mijn mening een hele goeie ), en het is inderdaad waar dat alle talen op .NET goed zijn bijgeschaaft om compatible hiermee te worden ( in veel gevallen erg goed, -1 als true wordt nu eindelijk de 1, etc ).

Met een beetje bijscholen kan iedereen met hun vertrouwde omgeving lekker .NET programmeren ( bij ons nu zelfs Cobol programmeurs ). Maar ik denk dat in de toekomst alles wel naar C# over zou gaan... ( ik in elk geval wel ).

Leuk topic trouwens.

[Alarmnummer]

*had een heel verhaal geschreven maar heeft met een slaperige kop zijn pc vanmorgen uitgedrukt die hij aan had laten staan omdat got eruit lag*

Maar ik denk dat we niet bang hoeven te zijn dat alles c# of Java gaat worden. Er zijn misschien wijzigingen nodig in andere talen om het op .NET of op java te draaien. Maar het wil niet zeggen dat een haskell of prolog of iets anders helemaal verloren gaat. Ik hoop dat er wat meer toekomst gaat komen voor deze talen door er bruikbare api`s voor te maken. Sommige dingen moet je nu eenmaal niet imperatief doen

Het is misschien ook wel een leuk idee om die bytecode daarvan terug naar java of c# te decompileren Of gewoon rechtstreeks naar java/c#

Je maakt in een volledig niet oo taal een groot deel van je programma en voegt daar een kruidenboulion blokje aan toe van Java

Heb je trouwens het stuk(je) gelezen over Visual Java van Bea?? Ik moest eigelijk wel een beetje lachen, maar ik denk dat dit in de toekomst blijft gebeuren. Software is duur en zo kan er veel meer software gemaakt worden omdat er minder geschoold personeel voor nodig is. Uit financieel oogpunt gezien een uitstekende zet denk ik. (Van uit technisch oogpunt moet ik eigelijk wel om lachen). Deadlock?? wasda?? concurrency ohhh.. currency bedoel je?

Maar voorlopig blijft oo denk ik de markleider omdat oo denk ik redelijk het menselijk denken benaderd. En ik heb de indruk dat oo nu eindelijk volwassen begint te worden als je kunt naar wat voor meesterlijke dingen er zijn bedacht. Ik vind bv design patterns en unit testing geweldig omdat je niet alleen meer zekerheid krijgt over je code maar een nieuw abstractie nivo met bijbehoorende algemene kreten erbij krijgt. En vooral in het laatste denk ik dat in de toekomst veel te ontdekken valt: hogere abstractie nivo`s.

[TheDane]

Op woensdag 27 februari 2002 00:05 schreef mbravenboer het volgende:

[..]

Afwachten doe je maar als je 80 bent .

Ik wil speculaties! visies! meningen! flames!

[kan het niet laten]

wat heb jij de laatste tijd toch prozaische titels & teksten

[/kan het niet laten]

[Johannes]

In every case, those languages have had to lose something important that made them different to fit the common dominator offered by the CLR.

Koele woordspeling.

Op dinsdag 26 februari 2002 23:58 schreef mbravenboer het volgende:
Er zijn al tijden andere paradigma's in ontwikkeling die wel gebruikt worden, maar dan toch voornamelijk in niche omgevingen en de onderzoekswereld. Mijn vraag is: wanneer denk jij dat deze andere paradigma's een serieuze keuze zullen worden en naar aanleiding van welke ontwikkelingen?

Ik ben eigenlijk niet zo enorm positief over de snelheid waarmee zij de markt zullen veroveren. Als je kijkt naar hoelang OOP er over heeft gedaan om de markt te veroveren(vanaf begin jaren 60), dan lijkt het mij onwaarschijnlijk dat bijv. FP(van begin jaren 80 toch?) heel snel de markt zal overnemen.
Ik denk eerder dat OO talen elementen van andere paradigma's in zich op nemen. Dat kan natuurlijk lang niet met alle paradigma's(XSLT in een OO-taal?), maar delen van FP zijn wel te gebruiken in OO talen.

[Creepy]

Op woensdag 27 februari 2002 09:28 schreef Mammaplank het volgende:
Ik zou het gewoon bij .NET houden, Delphi is ook grappig, wel OO, maar volgens mij nog niet op het .NET platform aangesloten, alle programmeertalen die niet OO zijn halen het volgens mij op de lange termijn niet.

Borland heeft aangekondigt .NET te ondersteunen in nieuwe versies van Delphi en C+++ Builder.

Ook gaat dit topic niet 100% in op alle aspecten van programeren.

Een compiler maken is ook programeren. Een OS maken is ook programmeren. Een driver schrijven is ook programmeren. Ik denk niet dat de mensen die zich hier mee bezig houden .NET of J2EE gebruiken.

Ok.. de meeste mensen doen dit soort dingen niet, en programeren applicaties (of zelfs IN applicaties... VB in Word/Excel/Access etc.)... maar een OS moet ook worden gemaakt, evenals drivers etc. etc. etc.

Processoren zijn NIET object georienteerd. Under the hood voeren ze gewoon instructie na instructie uit. Het complete OO gebeuren wordt weer domweg vertaald naar niet OO (door de compiler, VM, runtime functies etc.).

En sterk verouderde systemen worden nog steeds gebruikt, en zullen ook nog wel eens een poos gebruikt kunnen gaan worden. Waarom iets vervangen dat werkt? Ja er zijn nog bedrijven die met systemen werken die in (bijv.) Fortran geschreven zijn. Deze systemen moeten ook onderhouden worden.

Naar de toekomst kijken ok.. maar waarom ALLEEN naar de toekomst kijken en het heden en verleden vergeten? Systemen die gisteren geschreven zijn, moeten morgen wel onderhouden worden. Systemen die vandaag geschreven zijn, moeten ook onderhouden worden.

En dan heb ik het nog niet eens gehad over embedded systems. Tuurlijk is er windows CE.. maar is er al een .NET voor CE? En er is meer dan windows CE alleen. Kent iemand de z80 nog? Die wordt stiekum nog vaak gebruik in embedded systemen. Probeer daar maar eens een .net of j2ee omgeving voor te vinden.

(disclaimer: nee ik ben geen OO hater )

[Verwijderd]

Ik denk dat andere paradigma's zoals FP, logic programming ed en wat er in de toekomst ook moge komen alleen een kans maken als ze de juiste balans vinden tussen enerzijds leesbaarheid en "aanleerbaarheid" en hergebruik van onderdelen.

OO is zo populair geworden omdat de denk-stijl redelijk makkelijk aan te leren is, het niet echt ver van procedureel programmeren afligt en toch duidelijke voordelen biedt tenopzichte van procedureel programmeren mbt hergebruik.

FP is dan in potentie de "Koning van hergebruik" maar is helaas "te" moeilijk aan te leren en vooral te lezen. Dit geldt in zekere zin ook voor logic programming.

Dus: wie vindt er de juiste balans?

(Nog even buiten beschouwing gelaten dat commercieele belangen totaal worden ignored )

[Alarmnummer]

Ik gebruik niet niet oo voor applicaties omdat je in imperatief oo meer controle hebt. Maar sommige dingen die zou je beter fp kunnen doen. Daarom zou het juist zo fijn zijn als je haskell of prolog api bij java kon gebruiken (of andersom).

code:

Prolog p = new Prolog("../monkeyAndTheBanana.pl");
p.addHook(this);
p.execute();

Nu kun je de kracht van zo`n taal combineren met java (of c#) . Tenslotte ga je ook geen quake schrijven in SQL maar je gebruikt het omdat het eenvoudig is te gebruiken vanuit Java en het probleem domein van sql is logica over verzamelingen van gestructureerde gegevens. Zij blijft iedere taal zijn eigen probleem domein houden en je moet je juiste language gebruiken voor het juiste probleem.

[Verwijderd]

Een taal is een tool, voor het implementeren van de te bouwen functionaliteit. Er zijn talen genoeg die zeer divers zijn, buiten de .NET talen om bv, dus uitdrukkingskracht te over op verschillende manieren. Dat talen steeds meer op elkaar gaan lijken, vind ik zo'n onzin. Het is hetzelfde als dat Nederlanders steeds meer op Amerikanen gaan lijken. Ja, ik grote lijnen en in sommige opzichten wel ja. Maar de details maken het verschil, en dat verschil is juist de scherprechter of je de juiste taal (== tool) voor de job hebt gekozen of niet.

In veel talen kun je alle mogelijke applicaties bouwen (je kunt zelfs OpenGL programmeren in APL ), het is de vraag of de details van die taal, de kleine karakteristieke eigenschappen, het leven van de developer in een specifieke situatie makkelijker maken danwel moeilijker: in de embedded wereld, die steeds groter wordt, praat men niet over .net (alhoewel er wel een .net voor embedded systemen komt) en VB, maar over asm en C. In de wereld van de business systemen (verreweg de grootste) praat men niet over assembler of over C, maar over VB, Java, COBOL, en een serie 4GL talen.

[Verwijderd]

het gaat IMHO nog wel een flinke tijd duren voordat er andere paradigma's ontstaan. Om drie redenen:
- veel bedrijven/instellingen draaien systemen in 'ouderwetse' omgevingen, zoals COBOL. Deze systemen zijn echter niet zomaar vervangbaar, omdat het bedrijfskritische systemen betreft. Met als gevolg dat er eindeloos aan doorontwikkeld wordt.
- mensen zijn gewoontegetrouw. Veel VB programmeurs begonnen te steigeren toen VB.NET bekend werd omdat deze een andere benadering kent dan het oude, vertrouwde VB. Dit betekende dat ze opnieuw moesten leren werken en daar hebben veel mensen geen zin in, of tijd voor. Hetzelfde geldt voor veelgebruikte talen als C, C++ en Java: daar moet niet teveel aan veranderen. En wat moeten de mensen die in Delphi werken?
- in de automatiseringgids stond laatst dat één of andere guru had geroepen dat in de toekomst "programmeurs overbodig zullen worden omdat alle code al beschikbaar is in libraries. Programma's worden gemaakt door ontwerpers die in ontwikkelingomgevingen werken waarin een model kan worden omgezet naar bruikbare code en systemen". Nou zal dat zo'n vaart niet lopen, maar het is niet ondenkbaar dat áls er dan veranderingen komen, ze deze kant opgaan. Immers, per 100 regels nieuw geschreven code introduceer je 1 bug (gemiddeld).

[Creepy]

Op woensdag 27 februari 2002 10:07 schreef Shivo het volgende:En wat moeten de mensen die in Delphi werken?

De beloofdde .NET ondersteuning van Borland gebruiken

Immers, per 100 regels nieuw geschreven code introduceer
je 1 bug (gemiddeld).

Was dat niet duizend, en voor "bug vrije" software?

[Verwijderd]

Dat alle .net "bytecode"(om maar even met java te vergelijken) het zelfde is welke .net ondersteunde taal dan ook is gebruikt is op zich zeer logisch. Het is zelfs de enigste mogelijkheid omdat anders het veel te gecompliceerd zou worden. De voordelen zijn dat er maar 1 soort beveiligings systeem nodig is om de rechten die de programma hebben in de gaten te houden, en dat .net snel voor vele platformen beschikbaar zal zijn.
Maar het grote nadeel is dat veel programmeertalen moeten worden aangepast of zelfs helemaal niet op het volledig object georienteerde .net kunnen werken.

Ik denk dat in de toekomst het OO paradigma zal verschuiven naar paradigma's waarin het verwerken van data het belangrijkst is. En ik vraag me af of dat wel goed in het .net gedoe in te passen is. En omdat de toekomstige processoren allemaal hardwarematig meerdere threads aankunnen zou het wel handig zijn om dat op een of andere manier in te bakken in de nieuwe programmeertalen.

[mbravenboer]

Johannes: Ik ben eigenlijk niet zo enorm positief over de snelheid waarmee zij de markt zullen veroveren. Als je kijkt naar hoelang OOP er over heeft gedaan om de markt te veroveren(vanaf begin jaren 60), dan lijkt het mij onwaarschijnlijk dat bijv. FP(van begin jaren 80 toch?) heel snel de markt zal overnemen.

Inderdaad. Helaas is dat denk ik toch wel een feit ja. Het grote probleem van FP is volgens mij dat het moet opboxen tegen imperatieve programmeertalen: er is geen niche markt waar FP een must-use is (zoals bijvoorbeeld XSLT). Daarnaast is OO uiteraard slechts een uitbreiding van het procedurele programmeren, wat dus nog wel relatief makkelijk aan te leren is. FP is een volledig andere denkwijze die zeker voor ervaren imperatieve programmeurs in het begin een volledige ontluistering kan zijn .

Ik denk eerder dat OO talen elementen van andere paradigma's in zich op nemen. Dat kan natuurlijk lang niet met alle paradigma's(XSLT in een OO-taal?), maar delen van FP zijn wel te gebruiken in OO talen.

Inderdaad, in die richting neig ik ook. Helaas zal de puurheid van het paradigma hiermee wel grote schade oplopen. Je ziet nu in feite al een aantal FP-achtige zaken in Python terug. Heel aardig, maar eigenlijk vanuit het FP-kamp bekeken volkomen zinloos voor het FP paradigma...

[mbravenboer]

XKB: FP is dan in potentie de "Koning van hergebruik" maar is helaas "te" moeilijk aan te leren en vooral te lezen. Dit geldt in zekere zin ook voor logic programming.

Ik denk dat dat voor een groot deel ook veroorzaakt wordt doordat iedereen begint met imperatief programmeren. Hierdoor bouw je voor jezelf een voorstelling op van het begrip programmeren die je weer vrijwel volledig aan de kant kunt zetten als je met FP begint. Zie het eens als het hexidecimale stelstel: rekenen daarin valt in het begin niet echt mee. Terwijl we wel perfect kunnen rekenen in het tien-tallig stelsel...

[mbravenboer]

Otis: Dat talen steeds meer op elkaar gaan lijken, vind ik zo'n onzin.

Tja, helaas is het denk ik toch een feit dat de markt de komende tijd steeds sterker richting Java en C# acthigen zal gaan neigen. In principe is dit niet echt een trend richting minder diversiteit, maar het past volledig in de trend die we altijd al hebben gevolgd:

Het gaat mij erom dat we in de komende periode waarschijnlijk zullen zien dat het landschap volledig gedomineerd gaat worden door Java/C# en look-a-likes daarvan. Uiteraard geen uitzonderlijke situatie omdat we bijvoorbeeld ook tijden hebben gehad waarin het landschap gedomineerd werd door procedure-talen.

Het punt is dat we van grof gezien van paradigma naar paradigma hoppen en er per moment vrij weinig variatie is in de normale programmeer-wereld.

Deze trend schijnt nog steeds niet doorbroken te kunnen worden voor normale programmeertalen. De enige talen die wel doorbreken zijn expressie-talen zoals SQL, XPath en dergelijke. General-purpose talen zijn echter nog steeds vrijwel allemaal imperatief en voor een groot deel OO.

Maar de details maken het verschil

Mwah, dat vind ik wel meevallen eigenlijk.... Bijzondere toepassingen zoals OSsen, drivers en dergelijke daar gelaten is er eigenlijk niet echt een zeer goede reden waarom je voor taal a, b of c zou moeten kiezen. Tussen de talen Delphi, VB .NET, Java, PHP, Python, C#, C++, J# zijn er eigenlijk in grote lijnen bekeken slechts detail-verschillen. De keuze hiertussen baseer je voornamelijk op beschikbare libraries, professionaliteit van de ontwikkelomgeving en de runtime-mogelijkheden. Het is simpelweg 1 pot nat zonder een echt alternatieve keuze. Die alternatieven zijn er overigens wel, maar weten nog steeds niet door te breken.

het is de vraag of de details van die taal, de kleine karakteristieke eigenschappen, het leven van de developer in een specifieke situatie makkelijker maken danwel moeilijker

Tja, dat lijkt inderdaad zo, maar de keuze is hier toch echt te beperkt imho. Het staat eigenlijk bij voorbaad al vast dat men voor het imperatieve paradigma kiest. Na deze keuze kan je je heel druk gaan maken om een keuze te maken op basis van details in allerlei talen, maar daarbij moet je niet de illusie hebben dat je ook daadwerkelijk aan het kiezen bent: je kiest slechts de beste auto uit een wagenpark.

[mbravenboer]

borganism: En omdat de toekomstige processoren allemaal hardwarematig meerdere threads aankunnen zou het wel handig zijn om dat op een of andere manier in te bakken in de nieuwe programmeertalen.

Dat lijkt mij niet nodig.... Voor een programmeertaal is het een irrelevant detail dat threads nu ook hardware-matig georganiseerd kunnen worden. Vrijwel alle talen ondersteunen conurrent programming door multi-threading en als je deze faciliteiten gebruikt, profiteer je automatisch al van deze verplaatsing van OS naar processor...

[dusty]

Op woensdag 27 februari 2002 00:05 schreef mbravenboer het volgende:
[..]
Afwachten doe je maar als je 80 bent .

Ik wil speculaties! visies! meningen! flames!

Het zal nog wel een tijd duren voordat het echt doorbreekt.

Bovendien geef je ook meteen de mensen een mogelijkheid om meer gecompileerde code van andere mensen te gaan gebruiken, Dus fijn gaan vertrouwen op iemand anders zijn programmeer kunsten zonder zelfs te kunnen controleren of de code wel 100% veilig is, of de bugs eruit te kunnen halen mocht er opeens een bug zijn. (maar dat is eigenlijk weer niet specifiek .NET, das meer het algemeen, echter geeft .NET een nog grotere mogelijkheid)

Betekent dus dat alle bedrijven die zichzelf een beetje respecteren alles zoveel mogelijk zelf maken en hun eigen libraries opbouwen, waardoor de mogelijkheid om in verschillende talen weer een beetje overkill wordt, tenzij je natuurlijk een bedrijf bent die elke programmeur (welke taal ze ook kunnen) aanneemt die men kan krijgen, maarja of je dan nog kan zeggen dat het bedrijf zichzelf respecteerd is weer een tweede.

[Verwijderd]

Ik denk dat in de toekomst het moduleren van systemen veel belangerijker wordt dan het daadwerkelijk programmeren ervan. Op dit moment staat dit nog in de kinderschoenen maar pakketten als Rational Rose schetsen wel al een realistisch toekomstbeeld.

Web-based ontwikkelen gaat volgens mij, nog meer dan nu, de markt beheersen. Waarmee Sun met zijn web-services, op dit moment iedergeval, volgens mij een voorsprong heeft op .Net.

RAD is ook een methodiek die steeds meer toegepast zal worden waardoor de looptijd van projecten steeds korter zal worden. Ondersteuning vanuit de verschillende talen voor deze manier van development is daarom ook essentieel.

Ten slotte: procedureel programmeren blijft volgens mij nog jaren bestaan aangezien bestaande programmatuur onderhouden moet worden en het een methodiek is die voor sommige systemen gewoon beter geschikt is (bijvoorbeeld embedded systems).

[Alarmnummer]

Op woensdag 27 februari 2002 11:38 schreef dusty het volgende:

[..]

Het zal nog wel een tijd duren voordat het echt doorbreekt.

Bovendien geef je ook meteen de mensen een mogelijkheid om meer gecompileerde code van andere mensen te gaan gebruiken, Dus fijn gaan vertrouwen op iemand anders zijn programmeer kunsten zonder zelfs te kunnen controleren of de code wel 100% veilig is, of de bugs eruit te kunnen halen mocht er opeens een bug zijn. (maar dat is eigenlijk weer niet specifiek .NET, das meer het algemeen, echter geeft .NET een nog grotere mogelijkheid)

Betekent dus dat alle bedrijven die zichzelf een beetje respecteren alles zoveel mogelijk zelf maken en hun eigen libraries opbouwen, waardoor de mogelijkheid om in verschillende talen weer een beetje overkill wordt, tenzij je natuurlijk een bedrijf bent die elke programmeur (welke taal ze ook kunnen) aanneemt die men kan krijgen, maarja of je dan nog kan zeggen dat het bedrijf zichzelf respecteerd is weer een tweede.

Ik denk dat door mbv unit testing veel fouten eruit gehaald kunnen worden. En door design by contract (dus pre/post en invariant condities) kan er hogere kwaliteit software afgeleverd worden.

Het is gewoon een onmogelijke zaak (als je wilt meekomen met de rest) als bedrijf zijnde om zelf alles te gaan implementeren. En bedrijven doen het nu toch ook? Code van anderen gebruiken?

[Johannes]

Op woensdag 27 februari 2002 10:55 schreef mbravenboer het volgende:
Inderdaad, in die richting neig ik ook. Helaas zal de puurheid van het paradigma hiermee wel grote schade oplopen. Je ziet nu in feite al een aantal FP-achtige zaken in Python terug. Heel aardig, maar eigenlijk vanuit het FP-kamp bekeken volkomen zinloos voor het FP paradigma...

Maar is dat erg voor de programmeurs? Ik ben het met Tim Peters eens: 'practicality beats purity'. Maar ja, ik ben daan ook een Python-fan.
Ik moet zeggen dat ik FP wel interessant vindt, maar ik denk dat een mix altijd het beste is, zoals bij Python of OCaml(ook al is dat veel meer FP dan bij Python).

[drm]

_{<offtopic>
mbravenboer> Over purity gesproken, hoe staat het met je puristische website?
</offtopic>}

[mbravenboer]

drm: Over purity gesproken, hoe staat het met je puristische website?

Hum ja, moet nodig weer eens aan de slag . Komt nog .

[mbravenboer]

Johannes: Ik moet zeggen dat ik FP wel interessant vindt, maar ik denk dat een mix altijd het beste is, zoals bij Python of OCaml(ook al is dat veel meer FP dan bij Python).

Tja, ik zou toch eigenlijk lazy-evaluation en echte hogere-orde functies niet willen missen denk ik . Zonder dit komt het vaak meer neer op een extreem compacte syntax dan dat het paradigma zelf ook grote voordelen biedt.

[stylee]

[ot] noem me onwetend, maar wat is nou het verschil tussen imperatief programmeren en functioneel programmeren? Links zijn ook welkom.

[mbravenboer]

stylee: noem me onwetend, maar wat is nou het verschil tussen imperatief programmeren en functioneel programmeren? Links zijn ook welkom.

Hum.... ik weet zo geen ultiem document, maar kan wel kort het fundamentele verschil uitleggen.

In een functionele programmeertaal is alles (ja alles) een functie . Functies hebben altijd een resultaat en parameters (eigenlijk zijn er alleen maar functies met 1 parameter, maar dat is even niet relevant ).

Een echte functionele taal kent geen 'state': je kunt een variabele geen nieuwe waarde geven. Er zijn dus eigenlijk helemaal geen variabelen (variabelen zijn immers variabel ).

Hierdoor heeft een functie-aanroep altijd hetzelfde resultaat: het resultaat kan niet afhangen van een 'state'. Hierdoor ontstaan er aardige mogelijkheden zoals lazy-evaluation. Een functie aanroep wordt hierbij alleen uitgevoerd als het resultaat ervan ook daadwerkelijk nodig is voor een eindresultaat. Dit is mogelijk omdat een functie nooit side-effects kan hebben: er is immers geen state.

In een hogere order functionele taal kan je functies meegeven als parameters aan andere functies of een functie opleveren als resultaat van een functie. Ook hebben hogere orde functionele talen lexical-scope: variabelen uit een omringende functie kunnen worden gebruikt in een geneste functie.

Ik besef volledig dat dit allemaal erg creepy klinkt, maar dat valt best wel mee . Een introductie in functioneel programmeren moet eigenlijk ook niet beginnen met een uitleg van de fundamentele verschillen met imperatief programmeren. Je ziet de voordelen dan absoluut niet in.

Als je meer wilt weten kan je eens naar http://www.haskell.org gaan. Dit is een van de meeste populaire hogere orde functionele talen .

Overigens heb ik op GoT ook eens een heel verhaal verteld over currying... zal ff zoeken... .

[Alarmnummer]

en anders moet je even kijken naar clean (schone versie van haskell) zit een hele ide bij is wel lachen.

http://www.cs.kun.nl/~clean/

[mbravenboer]

Alarmnummer: schone versie van haskell

Ga jij eens even heel snel je mond spoelen! . Schone versie van Haskell.... grrrr... . Clean lost een aantal fundamentele problemen anders op dan Haskell. Dit betekent niet dat het een schonere versie is, het volgt simpelweg een andere aanpak. Haskell vies noemen is niet bepaald terecht, want het barst van de formele achtergrond .

Over de oplossing van Clean versus Haskell hebben we (althans, voornamelijk ik ) weleens gehad in P&W. Mensen beweerden toen ook dat Clean beter is, waarna ik dus getracht heb een discussie daarover op te starten. Helaas nogal mislukt .

Zie hier:
[topic=344737/2/25]

stylee: Over dat currying staat hier trouwens een leuk verhaal (onderaan). Je ziet hier ook gelijk wat voordelen van FP (let niet op de topic-titel ).

[topic=384620/1/25]

[whoami]

Ik ben het niet eens dat het in de toekomst allemaal .NET en J2EE zal zijn wat de klok slaat.

Alleen al het feit dat bestaande programma's moeten onderhouden worden enz. (dit werd reeds vermeld in het topic).

En wat met mainframes? handhelds? embedded systemen?

In C/S omgevingen zullen .NET en J2EE wel overheersen, (dat zie je nu al met de melding van Borland dat ze hun Delphi .NET compliant gaan maken; ik denk zelfs dat C++ Builder het al is).