Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien

[discussie] IronMonkey - de ultieme webscript interpreter?

Pagina: 1
Acties:

  • BikkelZ
  • Registratie: Januari 2000
  • Laatst online: 24-11 23:24
Naar aanleiding van dit artikel:

http://arstechnica.com/jo...h-ironpython-and-ironruby

Denken jullie dat het mogelijk is dat MS dit ook gaat ondersteunen? Het leven van een front-ender gaat opeens over rozen als het zo is. Persoonlijk vind ik JavaScript niet de meest prettige taal om in te programmeren, zeker niet als het wat groter wordt. Aangezien je heir mee dus niet meer gebonden bent aan JS(2) alleen, gaat dit heel veel wensen aangaande dynamische webapplicaties oplossen.

iOS developer


  • HawVer
  • Registratie: Februari 2002
  • Laatst online: 29-11 23:30
Ik ben persoonlijk ook niet zo een held in het javascripten. Waar mogelijk los ik dingen server side op en echt dynamische zaken in flash o.i.d.

Toch vraag ik me af of een, bestaande taal als scripttaal, iets oplost tov het gebruikersgemak. Ook deze taal moet je leren en ook deze taal zal zijn nukkigheden hebben. Voor javascript bestaan er ide's en interpreters, dus is het de vraag wat deze nieuwe script omgeving oplevert tov van javascript.

http://hawvie.deviantart.com/


  • BikkelZ
  • Registratie: Januari 2000
  • Laatst online: 24-11 23:24
[b][message=28467304,noline]Toch vraag ik me af of een, bestaande taal als scripttaal, iets oplost tov het gebruikersgemak. Ook deze taal moet je leren en ook deze taal zal zijn nukkigheden hebben. Voor javascript bestaan er ide's en interpreters, dus is het de vraag wat deze nieuwe script omgeving oplevert tov van javascript.
Nou als je server-side script cq. progt dan heb je de keuze uit een shitload aan frameworks en platforms om mee te werken, en je kunt kiezen wat je wilt gebruiken naargelang wat je prettig vindt en voor je doel het beste werkt. Front-end scripting is beperkt tot JavaScript en Visual Basic.

Dat werkt gewoon niet goed meer als je echt hele complexe dingen wilt gaan doen. Niet voor niets dat Google via een Java achtige interface JS web applicaties bouwt, dat is nou eenmaal een taal die zich beter lijkt te lenen voor dat soort dingen.

Ik snap ook wel dat er mensen zijn die JS fijn vinden werken, maar ik zou wat anders gebruiken als ik de kans kreeg.

iOS developer


  • Blaise
  • Registratie: Juni 2001
  • Niet online
Het is me niet helemaal duidelijk wat IronMonkey nou is. Het zet IronPython- of IronRubycode om in Javascript? Of zet het niets om, maar is het een toevoeging aan de ECMAscript engine zodat meerdere clientside talen worden ondersteund?

Ik heb nog nooit erg grote projecten gedaan in Javascript, maar in Javascript kan je een vorm van object oriented code gebruiken. Dan kan je toch ook grote projecten in Javascript doen?

Verwijderd

Blaise schreef op vrijdag 27 juli 2007 @ 18:57:
Het is me niet helemaal duidelijk wat IronMonkey nou is. Het zet IronPython- of IronRubycode om in Javascript? Of zet het niets om, maar is het een toevoeging aan de ECMAscript engine zodat meerdere clientside talen worden ondersteund?

Ik heb nog nooit erg grote projecten gedaan in Javascript, maar in Javascript kan je een vorm van object oriented code gebruiken. Dan kan je toch ook grote projecten in Javascript doen?
Dat kan. Maar de manier van werken is iets anders dan bij het typische OO programmeren. Javascript is niet zozeer object oriented, maar het simuleert dat een beetje. Javascript 2 is ook weer een hele andere benadering dan 1.x.

In JS2 heb je een type system, voor zover ik weet is dit optioneel. Er komen packages en namespaces, om handig te kunnen groeperen/naamgeven, zonder kans op naming collisions. Er komt een bytecode compiler bij kijken. Er komen heuse classes en interfaces. Het scoping systeem verandert, er komen dus block scopes, waarschijnlijk vergelijkbaar met de implementaties in JS 1.7 en 1.8.

Voor zover ik begrijp zal Ruby noch Python exact Javascript 2.0 of eigenlijk ECMA 4 compliant kunnen werken. Maar waarschijnlijk is het gewoon de bedoeling om een bytecode compiler te schrijven voor deze talen.

  • BikkelZ
  • Registratie: Januari 2000
  • Laatst online: 24-11 23:24
Voor mijn gevoel is het net zoiets als .net - je hebt een x aantal talen die uiteindelijk allemaal op hun eigen manier precies het zelfde ding aansturen. Wil je een C++/Java achtige syntax, pak je C#, wil je Python, pak je IronPython, maar uiteindelijk draait het allemaal op het .net platform.

iOS developer


  • Little Penguin
  • Registratie: September 2000
  • Laatst online: 08-06 20:43
Als je wat verder klikt vanaf het artikel, dan kom je ook de diverse blog en wiki postings tegen die IronMonkey en haar relatie wat verder uitleggen - ik denk dat je dan ook gelijk gezien zou hebben dat dit specifiek is voor Gecko (2.0).

Als je namelijk doorgeklikt zou hebben naar de omschrijving van IronMonkey op de Mozilla Wiki, dan had je gelezen dat het IronMonkey project tot doel heeft om het mogelijk te maken om de IronPython en IronRuby talen onder Tamarin te laten werken.

Als je dan ook nog eens verder klikt naar de beschrijving van Tamarin op diezelfde Wiki dan lees je gelijk dat 't een Virtual Machine is....

De Tamarin VM is in staat om iedere taal die naar ABC compileert te verwerken, dat ActionScript/JavaScript zelf volgens de ECMAScript definities werken, betekent nog niet dat het niet mogelijk is om andere talen naar ABC te laten compileren.
The goal of the "Tamarin" project is to implement a high-performance, open source implementation of the ECMAScript 4th edition (ES4) language specification. The Tamarin virtual machine will be used by Mozilla within SpiderMonkey, the core JavaScript engine embedded in Firefox®, and other products based on Mozilla technology
Het is dus geen project om Ruby of Python eerst om te zetten naar JavaScript en daarna door de JavaScript interpreter te laten verwerken - dat betekent dus dat alleen Gecko (2.0) in staat zal zijn om de talen uit te voeren en dan ook nog alleen maar als men de compilers voor de IronMonkey talen meelevert.

Overigens ben ik het niet met de opmerkingen eens van de mensen die JavaScript maar niks vinden, het is wel degelijk een krachtige taal waar je leuke dingen mee kunt doen. Alleen moet je dan natuurlijk wel regels opstellen en je daar aan houden, het is inderdaad mogelijk om een bende te maken van je JavaScript code.

Maar de taal C is toch ook geen slechte taal omdat je er onleesbare code mee kunt maken?

Verwijderd

Ik weet wat Tamarin is, en Gecko is niet Tamarin. Tamarin zal een deel uitmaken van Gecko, net zoals Spidermonkey nu deel uitmaakt van Gecko. Tamarin zal Spidermonkey vervangen (of wellicht ernaast gaan bestaan).

Daarom denk ik dus dat IronMonkey misschien het best vergelijkbaar is met bijvoorbeeld Visual Basic .NET, aangezien je met VB geen gebruik kunt maken van de volledige kracht van het .NET framework. Met C# kan dat wel. De basis van Tamarin zal dus een ECMA 4 compliant taal zijn, lijkt mij. En Ruby of Python zal nooit op eenzelfde manier werken als Javascript 2.0.

Wat dat betreft denk ik eigenlijk dat we op hetzelfde spoor zitten, maar dat we het net even anders zeggen. Ik zie zeker potentieel in Javascript, voor de hobby ben ik zelfs bezig met een Javascript engine gebaseerd op Spidermonkey. Als Tamarin verder is ga ik dat gebruiken, maar dat terzijde.

Met Javascript kun je zeker krachtige applicaties schrijven, alleen is de manier van ontwikkelen anders dan bij Java of C#. Javascript 2.0 probeert dat dan ook niet te zijn. En ik denk dat Ruby en Python ook niet moeten proberen om de taak die Javascript nu heeft over te nemen. Dat zal ook niet de bedoeling zijn. Het zal de bedoeling zijn om Ruby en Python (en andere talen) programmeurs de mogelijkheid te geven om iets client-side met die talen te laten doen. Maar op dit moment geloof ik niet dat zij dan in staat zullen zijn om het volledige potentieel van Tamarin te gebruiken.

  • BikkelZ
  • Registratie: Januari 2000
  • Laatst online: 24-11 23:24
Er zijn in theorie mensen die betere FORTRAN code schrijven dan de gemiddelde GoTter Java. Maar het is makkelijker om goede Java code te schrijven.

Maar dan nog is het mogelijk dat zeer übercorrect geschreven Framework A in combinatie met überüibercorrect geschreven Framework B rare effecten kan hebben - volgens mij is dat niet af te vangen zonder namespaces of andere aanpassingen binnen de taal.

Waar het ene framework bij Array.pop() op het einde een null terug geeft, geeft de andere misschien wel false terug. Je kan niet zeggen van neeeee ik bedoel eigenlijk die Array.pop() van Prototype, niet die van dat andere framework dat ik er toevallig na geladen heb.

Ik wil ook gewoon normale primitieven en objecten hebben, ik wil niet de hele tijd met een integer getal bezig zijn, en dan toch case '1': moeten tikken om mijn code draaiend te krijgen. Loose typed, als jij dat wil, prima, maar geef mij in ieder geval de mogelijkheid om mijn fixatie met exacte types bot te vieren.

iOS developer

Pagina: 1