[IronPython] IronPython / DLR Direction

Hank Fay hank at prosysplus.com
Mon Aug 9 23:34:26 CEST 2010

Hi Tony,

I have to agree about the barrier being lower if IPy is Microsoft-supported
(as all the Iron* languages were announced to be).  I had a discussion in
January with a market-leader in another country, and their project manager
could accept IronPython, barely.  His take was: I want to be able to easily
hire programmers for customization and/or sourcecode escrow clause
necessity.  Customization wasn't really an issue (the program uses hooks for
customization), as he could hire his bevy of C# developers to do that, but
if he had to maintain sourcecode that would be a different story.

Having come from a very productive dynamic language (Visual FoxPro) that MS
first said could not be ported to .Net, and then when it obviously was
possible (in 2005) made no attempt to do so, I'm having a deja vu experience
all over again.  I'll try not to be as cynical and sarcastic as last time,
but I'm having to hold my arm down (shades of Dr. Strangelove) and hold my
tongue to prevent shouting out "Middle Management Uber Alles!" (referencing
Jimmy's blog post).

And so it goes...


On Mon, Aug 9, 2010 at 12:43 AM, Tony Meyer <tony.meyer at gmail.com> wrote:

> On Sun, Aug 8, 2010 at 6:19 AM, Jeff Hardy <jdhardy at gmail.com> wrote:
> > if [Iron*] die, doesn't that mean MS made the right choice after all?
> I don't think that's true.  .NET isn't just another platform - it's
> Microsoft's own platform.  Some thoughts:
> Like it or not, and whether it *should* be the case or not, in many
> organisations (or even teams) if a technology is from Microsoft then
> it's automatically approved, or at least much easier to approve.  The
> barrier to using Iron* is much lower because they are Microsoft
> products - this is even more the case with Visual Studio integration.
> Although Iron* are open-source (which is great, obviously), they
> aren't typical open-source communities, because of the (somewhat
> understandable) restriction about accepting code, and the leadership
> all (AFAIK) being within Microsoft.  Microsoft have created this
> environment (which has worked fairly well so far), and it's not clear
> how easily that can transition to something that's lead by someone (or
> ones) outside of Microsoft.
> Leadership (or at least involvement) within Microsoft opens
> opportunities for Iron* development to influence .NET.  I'm not overly
> familiar with the details, but I gather than the DLR approach is
> significantly superior to the IPy 1 CLR approach, and that some of the
> new dynamic features of C# have benefited from this.  It's hard to see
> how a community IronPython could have developed the DLR, and it seems
> unlikely that Microsoft would make changes to the CLR to assist it.
> (Does the latest Microsoft Javascript engine use the DLR (Managed
> JScript?) - if so, then there's hope, I guess).
> Projects often need 'angels', especially in the early stages (and I
> would argue that Iron* are still in early stages).  Working on a
> project of this size takes a lot of resources, and having corporate
> sponsors makes that a lot easier.  Would Python have succeeded if CWI,
> CNRI, and BeOpen hadn't supported Guido (and others)'s work in the
> early days?  These days the PSF takes this role, but projects need
> time to build to that sort of size.
> [Iron]Python (I don't really know much about [Iron]Ruby) is a great
> language for beginners (students, kids, hobbyists, etc).  The Iron
> variants provide a very smooth path into other .NET development (e.g.
> C# - which I would say is not at all a great beginner's language).
> You could argue that Visual Basic provides this functionality as well
> - I personally find Python much superior to Visual Basic, and since
> nearly all other BASIC variants are dead now, it doesn't provide an
> easy road into the .NET world (you have to start there with an
> unfamiliar language).
> This last point is the most relevant to me.  Over the last few years,
> NorthTec have switched to using CPython as the first-course
> programming language, and IronPython as the second-course language.
> The students *need* to end up with some .NET and Visual Studio
> experience, because realistically that's what they are most likely to
> come across in the real world.  Many of the students are not capable
> of starting with C#.  If IronPython wasn't a Microsoft project, it
> would have been considerably more difficult to adopt it - that would
> likely have meant using Visual Basic (possibly in both courses,
> because these students struggle learning two languages in their first
> year).  Although this is my unique case, I suspect that there are
> similar ones, where being a Microsoft product is a deciding factor in
> whether Iron* can be used (which then impacts the adoption of the
> language, and therefore whether the language survives).
> > I think Microsoft is throwing their weight behind JavaScript as their
> > dynamic language of choice, and I can't really blame them.
> My hope is that Microsoft realises they have enough weight to throw it
> in more than once place.
> (My longer hope, which I know is quite unlikely, is that Windows 8 or
> 9 includes some version of Iron* out of the box, like OS X includes
> Python/Perl/PHP/Ruby/etc.  Being able to distribute .py[co] files
> rather than .exes would significantly help Iron* adoption IMO (and
> this is something completely impossible for a non-Microsoft Iron*).  I
> know some people must like PowerShell and similar things could be done
> with it, but it's not the same as having a language with the power and
> cross-platform nature of Python).
> Cheers,
> Tony
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20100809/1e77e08a/attachment.html>

More information about the Ironpython-users mailing list