IronPython brengt eerste 'stabiele' versie uit

De ontwikkelaars van het IronPython-project hebben versie 1.0 van de Python-implementatie voor het .Net-framework vrijgegeven. Samen met de release van deze eerste 'stabiele' versie van de ontwikkeltaal, heeft de hoofdontwikkelaar Jim Hugunin de ontstaangeschiedenis van het project beschreven en zijn visie op de Common Language Runtime (CLR) die door .Net wordt gebruikt.

Toen de ontwikkeling van IronPython begon, was dit de enige scripttaal die beschikbaar was voor het .Net-framework. De andere talen, zoals C# en Visual Basic maken gebruik van een compiler om de programmacode om te zetten in code die kan worden uitgevoerd door de CLR. Scripttalen zoals IronPython vereisen geen compilatie waardoor de ontwikkeling van programma's sneller kan door het overslaan van de compileerstap. Bovendien biedt een geïnterpreteerde scripttaal mogelijkheden om tijdens het uitvoeren van de code optimalisaties door te voeren.

Jim Hugunin begon de ontwikkeling van IronPython als een prototype van een Python-implementatie in .Net. De ervaringen die tijdens de ontwikkeling werden opgedaan zouden gebruikt worden voor een artikel waarin gebreken van de CLR werden beschreven. Er waren namelijk diverse artikelen verschenen waarin werd betoogd dat de CLR ongeschikt was voor dynamische talen zoals Python. Eerder had Hugunin al Python geïmplementeerd voor de Java Runtime Engine, wat resulteerde in het Jython-project. In de JRE bleek dat de prestaties van Jython behoorlijk goed waren in vergelijking met de originele versie van Python die in C is ontwikkeld. Hij was daarom benieuwd hoe Microsoft het voor elkaar had gekregen om de CLR zodanig te ontwikkelen dat de prestaties zo slecht waren als werd beweerd. Tijdens de ontwikkeling van zijn prototype kwam hij echter tot ontdekking dat de CLR helemaal niet zo slecht was voor dynamische talen en dat IronPython zelfs beter presteerde dan het originele Python. Inmiddels is Hugunin in dienst van Microsoft waarvoor hij werkt aan de CLR en ook helpt bij het Phalanger-project dat werkt aan PHP-ondersteuning in het .Net-framework. Inmiddels zijn er ook andere .Net-scripttalen beschikbaar, waaronder het van Python afgeleide Boo.

Reacties (25)

[Skit3000]

Scripttalen zoals IronPython vereisen geen compilatie waardoor de ontwikkeling van programma's sneller kan door het overslaan van de compileerstap. Bovendien biedt een geïnterpreteerde scripttaal mogelijkheden om tijdens het uitvoeren van de code optimalisaties door te voeren.

Het ontwikkelen gaat misschien wel sneller omdat je minder lang hoeft te wachten tijdens het debuggen, maar tegelijkertijd is de uitvoersnelheid een stuk lager dan gecompileerde code. Voor kleine programma's kan je het dus prima gebruiken, maar ik zou er niet een of ander geavanceerde serverapplicatie mee durven maken als er enkele tientallen tot honderden mensen van afhankelijk zijn.

[Johnny]

Voor serverapplicaties is de bottleneck vaak de I/O dus de snelheid die je verliest is in de meeste gevallen niet zo heel erg, en anders is een processor-upgrade vaak goedkoper dan vele uren besteden aan het optimaliseren van het programma in een low-level taal met bijkomende problemen van threading en geheugenscheiding wat daar veel lastiger en foutgevoeliger is dan met high-level programmeertalen.

Het is daarom ook dat je op servers vaak een taal zoals Java tegenkomt omdat het met een just in time compiler het beste van beide werelden heeft.

[H!GHGuY]

ik ontwikkel atm in python en ik vind dat'k nog nooit zo contraproductief geweest ben. Telkens om een idiote typfout etc helemaal opnieuw moeten starten (wat wel even duurt).

[Verwijderd]

Hoezo opnieuw starten? Werk je direct in de interpreter? Het is de bedoeling dat je gewoon opgeslagen scripts uitvoert. De interpreter kan je gebruiken om wat kleine dingetjes te testen.

Voor mij is Python juist de taal waarin ik het meest productief ben. Het komt regelmatig voor dat ik een programma of file in typ waarin ik helemaal geen typ-, denk- of programmeerfouten heb gemaakt. Dat gebeurt me in andere talen nooit.

[Verwijderd]

Ik weet niet wat je bedoelt met 'helemaal opnieuw moeten starten'. Starten met het programma schrijven? Je kan Python programma's ook opslaan hoor.

Bovendien vraag ik me af welke taal je gewend bent, want ik ken zo snel geen taal waar 'idiote typfouten' geaccepteerd worden.

[killercow]

en waarom niet?

Een taal die minder performed hoeft niet per definitie minder robuust te zijn oid hoor.

Juist omdat even iets testen nu minder tijd kost, zal de programmeur misschien her en der wat extra dingen op kunnen lossen of bugs eerder opmerken.

dat jij alleen op gecompileerde talen berust is echt complete nonsense.

[edit]
Je hele argument slaat eigenlijk nergens op. maar ik neem aan dat je dat zelf ook wel begrijpt.

[Skit3000]

Vergelijk jij eens een taal als Visual Basic met C++? Ik zeg niet dat geinterpreteerde talen minder robuust zijn, maar wel langzamer dan gecompileerde applicaties.

Juist omdat even iets testen nu minder tijd kost, zal de programmeur misschien her en der wat extra dingen op kunnen lossen of bugs eerder opmerken.

Eerder opmerken lijkt me niet, je merkt bugs pas op als iets fout gaat en daarbij maakt het dus niet uit op wat voor manier je programma draait.

[Verwijderd]

Wat een programmeur het minst doet, is code schrijven/compileren. De meeste tijd gaat zitten in het opsporen van fouten en het ontwerpen van het programma.

[nhimf]

@killercow

Het is duidelijk dat je fan bent van geintrepeteerde talen, maar je reactie slaat echt nergens op.
Hij (skit3000) heeft het nergens over dat geintrepeteerde talen minder robuust zijn, alleen dat ze in principe langzamer zijn.
En daar is weinig tegen te zeggen. De cpu moet nou eenmaal meer doen bij het uitvoeren van geintrepeteerde talen dan bij gecompileerde talen.

Dat geintrepeteerde talen robuust kunnen zijn, dat is misschien waar, maar voor (zware) server apps zou ik ze niet gebruiken. Teveel overhead en dat is zonde van je (dure) server capaciteit.
Om die reden zou ik persoonlijk ook niet gaan voor java/.net voor een server app.

[killercow]

vb is inderdaad een stuk minder robuust dan c++
(maar dat is met wel meer MS uitvindingen zo)

Dat een scripttaal per definitie minder robuust is dan een gecompileerde taal is gewoon 100% onzin.

Python is een erg sterke en robuuste taal, en kan zich zonder problemen meten met allerlei gecompileerde talen, Of er nu 1 of 1 miljoen mensen gebruik van de app maken, hij wordt er niet onstabieler van als het een script taal is.
Hij heeft hoogstens wat meer resources nodig.

Talen met features als garbage collection, en Strikte OO zijn vaak een stuk stabieler dan pure c of c++, juist omdat de programmeur geholpen wordt, en niet zo vreselijk veel dingen aan zijn hoofd heeft tijdens het coden.
Daarnaast is het ontwikkelen in een snel te testen taal beter voor de kwaliteit omdat je als programmeur wel degelijk in kleinere stapjes gaat werken, en dus ieder stapje beter kunt testen.

Als je in een ruk een heel groot stuk code toevoegt, heb je geowonweg meer kans op problemen (die verborgen blijven) dan als je stapje voor stapje je code toevoegt, en doorloopt.
Al was het alleen al omdat je wellicht een stuk iet wat inefficiente code (en als z'n bindings) sneller vervangt door een nieuw en beter stuk omdat het testen enzo niet zo lang duurt.

Als in:
Vervang onderdeel A, zet B ervoor in de plaats.
runnen, A onderdeel C crasht,
Ok, onderdeel c aangepast.
runnen onderdeel D crasht,
onderdeel d aangepast, enz

Tegen:
Vervang onderdeel A, zet B ervoor in de plaats.
Compilen (Wachten)
runnen -> Crash.
strace , crash, A onderdeel C is stuk
aanpassen, etc

Dat laatste duurt te lang, en dus zal het stukje inefficiente code langer blijven zitten waar het zit.

ps, python kun je ook prima compilen (tot java executable, of tot echte platform specifieke bin)

[Reinstein]

Voor kleine programma's kan je het dus prima gebruiken, maar ik zou er niet een of ander geavanceerde serverapplicatie mee durven maken als er enkele tientallen tot honderden mensen van afhankelijk zijn.

T.net leunt sterk op PHP, een daar zijn zelfs 100.000++ mensen/tweakers van afhangkelijk. Ik zie het probleem niet. Een goed geschreven script is net zo stabiel als goedgeschreven C code, het hangt gewoon af van de programmeur(s).

[SuperDre]

stabiel en snel zijn 2 verschillende dingen.. een goed geschreven interpreted script kan nooit zo snel zijn als een goed geschreven gecompileerd programma..

[mxcreep]

En zelfs dat is niet perse waar...

Kijk eens naar cgi, erg veel software die van cgi gebruik maakt is geschreven in C. Als je puur kijkt naar de uitvoering van het stuk code in C dan zal dit sneller uitgevoerd worden dan bijvoorbeeld een stuk PHP code.
Echter wanneer je de tijd erbij betrekt die de cgi interface nodig heeft om het stuk C code op te starten dan is vaak ineens de PHP variant sneller, ervan uitgaande dat PHP als apache module wordt gebruikt.
Uiteraard is hierbij wel weer een omslagpunt aanwezig, wanneer de uitvoer van de code langer gaat worden dan zal de kortere uitvoertijd van de C code uiteindelijk het verlies wat de cgi wrapper oplevert wel weer opheffen en een en ander in het voordeel van de C code uitvallen.

Bottomline is, je zult moeten kijken naar het totaal en niet alleen naar de uitvoertijd van code.

[jealma]

Hoe zit het dan met het zien van de source? Stel voor dat je een applicatie schrijft in python, en dat niet compileert, dan kun je het toch niet verkopen, mocht je dat willen?

[PrisonerOfPain]

Waarom niet? Unix is groot geworden door het verkopen van het product in combinatie met de broncode.

[SirBlade]

Unix is groot geworden doordat het werd meegeleverd met bepaalde (hele dure) hardware (net zoals apple). Jij kocht een mainframe/mini en daar stond Unix op. En zonder die computer had je toch niets aan de software dus fabrikanten gaven gewoon de broncode mee. Uiteindelijk is dit juist de doodsteek geworden voor Unix want door die meegeleverde broncode waren Linux en BSD te maken die uiteindelijk de "echte" Unices verdreven. (Bijna dan).

[YaPP]

Uiteindelijk is dit juist de doodsteek geworden voor Unix want door die meegeleverde broncode waren Linux en BSD te maken die uiteindelijk de "echte" Unices verdreven.

De doorsteek was juist de:
- fragmentatie, een UNIX van een andere leverancier was niet compatible.
- de prijs van de machines i.t.t. de opkomst van goedkope PC's met Microsoft software.

[TheekAzzaBreek]

Neuh.
Je kocht een Unix machine omdat een mainframe te duur en te zwaar was, en PC-achtigen of Novell servers te licht of te instabiel. Unix/Linux op mainframes is nog niet zo lang populair, voor zover ik gezien heb pas sinds IBM daar serieus op ingezet heeft.

En doodsteek voor Unix? Ik doe mijn ding nog altijd op Unix servers, op een enkele Windows-only klant na.

[Brupje]

source code blijft jou eigendom, tenzij anders bepaald. Niemand mag dat zomaar aanpassen of kopieren. Je geeft alleen de koper het recht om de code in te zien en uit te voeren

[Verwijderd]

maar tegelijkertijd is de uitvoersnelheid een stuk lager dan gecompileerde code. Voor kleine programma's kan je het dus prima gebruiken, maar ik zou er niet een of ander geavanceerde serverapplicatie mee durven maken als er enkele tientallen tot honderden mensen van afhankelijk zijn.

De code wordt gecompileerd at runtime. Dat betekent dat wanneer je een applicatie opent hij het compileert naar machinetaal. Bij serverapplicaties (die je dus een keer start) heb je feitelijk geen verlies (behalve die kwart seconde die hij aan het compileren is).

Het eerder genoemde optimalisatieprobleem is ook opgelost in .net, omdat de taal zelf er voor zorgt dat wanneer processen (bijvoorbeeld UI) over meerdere processoren kan lopen, het dat ook doet. Dat is een voordeel van een CLR.

Een voorbeeld: het bedrijf T-Mobile draait intern alle medewerker-applicaties in ASP.net (ook CLR dus) en daar werken dagelijks tienduizenden mensen mee.

edit: ASP.net wordt niet gecompileerd, tenzij je dat specifiek aangeeft. Alles blijft zelfs broncode, en die tussenstap naar de CLR wordt zelfs pas op runtime gemaakt!

[DieDubbelJoe]

ASP.net wordt normaal gezien wél gecompileerd! Dus ik snap het nut van je voorbeeld niet goed!

[Snake]

Mooie ontwikkeling, als Phalanger nu nog wat beter wordt ( vooral de integratie in VS.net is kut ), schakel ik daarvoor over

[Sc0tTy]

Tijdens de ontwikkeling van zijn prototype kwam hij echter tot ontdekking dat de CLR helemaal niet zo slecht was voor dynamische talen en dat IronPython zelfs beter presteerde dan het originele Python.

Ik wil python gaan leren maar kan ik dan niet beter aan IronPython beginnen ? en ik neem aan dat het scripten 100% hetzelfde is

[Verwijderd]

Ik zou aanraden om met CPython te beginnen, die is nog steeds de enige echt portable versie die de volledige taal en standaardbibliotheek ondersteunt, en ook de enige waar de vele uitbreidingen en wrappers rond bekende C-bibliotheken mee werken (NumPy, PIL, PyGame, ...).

Alleen als je echt voor en/of met het .NET platform wil werken is IronPython waarschijnlijk geschikter, maar dat lijkt me pas iets wat je beslist als je wat op weg bent met Python en aan een "echte" applicatie begint.

[jurriaan]

Het scripten is mogelijk 100% hetzelfe, maar met .NET maak je natuurlijk gebruik van het .NET framework, en dus zal code zeker niet overdraagbaar zijn tussen de 2