[Dailydave] Languages that are not mandarin

[Matt Hargett]

On Thursday 31 August 06 14:42, Dave Aitel wrote:
> Computer languages, imho, being more abstract, are much much harder.
> For example, I've spent a long time trying to understand closures in
> Ruby. I don't know why, but since everyone says they're the bomb, then
> I figured it might be worth some time to see what I'm missing.
>
> I still don't understand them. I think they're something that you
> really only need for someone more complex than I ever do. I have the
> exact same problem with decorators, which are a Python feature for
> making your code look really ugly, as far as I can tell.

Closers and decorators are very handy tools for simplifying interfaces and  
thereby avoiding duplication and inappropriate intimacy. I skipped the Python 
craze, so I don't know how people implement them in Python, but they look 
okay to me in Ruby and C#. C# 2.0 also has lexical closures and 
semi-continuations, btw. I haven't seen a need for them yet, but maybe Luis 
and the other programmers will in the next bugreport iteration.


> The other language research I've been meaning to play with is the
> CLR's support for Python. I've always felt that the CLR wouldn't be
> able to support Python nicely, and from what I can read on the
> IronPython lists/documentation (current downloads are a 404)
> http://www.codeplex.com/WorkItem/View.aspx?ProjectName=IronPython&WorkItemI
>d=2702 I'm probably wrong.

.NET 2.0 has some specific changes in the structure to deal with dynamic 
languages, with IronPython's speed being a benchmark.


> If you can write Python in Java (jpython) then you can write it in C#,
> but the tricky thing is going backwards and letting Python classes use
> C# classes cleanly. I'm not sure this is going to really happen
> without lots of wrappers. GTK# versus pyGTK will be very interesting.

It's a matter of if you want the library consumable from *all* .NET languages 
and therefore be CLS-compliant, or if you just want to interoperate with C#. 
Choosing the later might screw you out of interoperating with 100%, say, boo. 
Then again, 100% interoperability might not be important depending on what 
your exposed API actually does.

I haven't used GTK#, but mono's WinForms implementation is coming along quite 
nicely. I can use Reflector and nunit-gui, which is about all I need :) 
MonoDevelop was still unusable the last time I checked. I really wish their 
dick-fight with SharpDevelop would end and they would just work from the same 
underlying codebase.