A look at Parrot 1.0 [LWN.net]

A look at Parrot 1.0

Posted Mar 27, 2009 4:15 UTC (Fri) by Ze (guest, #54182)
In reply to: A look at Parrot 1.0 by Frej
Parent article: A look at Parrot 1.0

>>It's much easier to share the same VM, than runtime. A runtime always fits a particular style of programming and/or languge (JVM,.NET) better. (In this case OO).

>>But hasn't LLVM already partly delivered what parrot promised?
I would have preferred to see more work going into LLVM.

Parrot/Perl developers will argue that's it's for statically typed languages and not dynamically typed languages. I'd argue that type discovery (and particularly over the whole program) allows us to to infer the type in the vast majority of cases.

I'd also argue that dynamically typed languages are horrible hacks :p I'd much rather have a compiler automatically test for some errors than rely on them to be produced at runtime.

to post comments

Static vs. dynamic

Posted Mar 27, 2009 12:17 UTC (Fri) by pboddie (guest, #50784) [Link] (2 responses)

I'd argue that type discovery (and particularly over the whole program) allows us to to infer the type in the vast majority of cases.

It's possible to do whole-program inference, but it's expensive. I think many people see functional programming languages employing type inference and consider that dynamic languages are as suitable for the application of similar techniques, but the scale of dynamicity undermines these techniques: assumptions that hold for languages like ML are gone in languages like Python.

I'd also argue that dynamically typed languages are horrible hacks :p I'd much rather have a compiler automatically test for some errors than rely on them to be produced at runtime.

Tests based on type declarations only cover a certain class of errors, as almost everyone should know by now. Dynamic languages obviously save the programmer from having to specify apparently obvious boilerplate, potentially permitting behaviour that would be awkward to define in many statically typed languages. However, restricting the dynamicity of such languages can lead to useful inference about program characteristics and can reveal errors, too.

I'd be happy to see a variant of Python with some of the more blatant dynamicity removed. For example, dynamic definition of classes has never really been very useful for me, so if that went away and enabled better program analysis, I'd be quite pleased with the compromise.

Static vs. dynamic

Posted Mar 28, 2009 23:43 UTC (Sat) by sergey (guest, #31763) [Link]

> For example, dynamic definition of classes has never really been very useful for me, so if that went away and enabled better program analysis, I'd be quite pleased with the compromise.

I just had to go through the exercise of choosing a Python SOAP client library, and most deserving ones all use dynamically defined classes. The morale is, these dynamic features are there for a reason, please don't touch them.

Static vs. dynamic

Posted Mar 29, 2009 14:41 UTC (Sun) by Ze (guest, #54182) [Link]

>>It's possible to do whole-program inference, but it's expensive. I think many people see functional programming languages employing type inference and consider that dynamic languages are as suitable for the application of similar techniques, but the scale of dynamicity undermines these techniques: assumptions that hold for languages like ML are gone in languages like Python.

A mix of type inference littered with bits of type specification where applicable works quite well in properly designed languages.

There are always going to be languages where it's unsuitable and I'd argue that's a pretty good sign (not a conclusive one though) that the programming language is shit.

Yes whole program compilation is expensive... but so is repeatedly calling an interpreter or a JIT.

>>Tests based on type declarations only cover a certain class of errors, as almost everyone should know by now. Dynamic languages obviously save the programmer from having to specify apparently obvious boilerplate, potentially permitting behaviour that would be awkward to define in many statically typed languages. However, restricting the dynamicity of such languages can lead to useful inference about program characteristics and can reveal errors, too.

Yes tests based upon type declarations only reveal certain classes of errors but they are errors that I as a programmer don't need to worry about. The compiler tests give far better coverage when it comes to those errors than any manual testing strategy that programmers practically implement.

This is where type-inference comes in , when you combine that with selective typing you can get the benefits of both. When you add templates and inheritance to the mix than very few things are hard to implement that are easy in other languages.

People will undoubtedly bring up C++ typing here. The c++0x standard addresses problems with the language standard to a large degree with the 'auto' specifier. A lot of the other errors and the difficulty with them rest at poorly implemented compilers. I've got high hopes here for LLVM.