It refers to the Weakly typed languages article, and looks interesting in that it gives the language typing debate a much practical value, through a real world example.
The only caveat is that it is written in Swedish and only the abstract is in English; so if anybody finds it interesting and knows Swedish then I would much appreciate a translated overview!
What I found is that it's not that easy to categorize languages based on their type systems, as they adapt a mix of each system's characteristics to their own needs,(C# makes use of duck typing for example,although categorized as a static language), something that gets summarized in this chunk of the conclusion :
"Strong,weak,static,dynamic what is it all about?
Labeling a language as of a certain type is apparently not that easy since it can incorporate a mixture of type systems; furthermore such a labeling would not offer anything significant.
But knowing the underlying concepts, quirks, weaknesses and strong points of each type system helps in avoiding potential pitfalls (Quoting the Camel book "You will be miserable until you learn the difference between scalar and list context"), leads to less buggy code and allows maximum exploitation of each system's unique features as to increase productivity, flexibility and agility."
There is much more it, so I attach the links to the parts in case you'd be interested :
part one : Type systems demystified
part two : Weakly typed languages
part three and conclusion : Strong typing
]]>Of course dynamic languages could use the CLR, like the first version of IronPython was,but required more effort by the designer because of CLR's design and orientation. As a matter of fact Jim Hugunin creator of IronPython initially started his research on the JVM where he had made Jython
In 8.2. Dynamic Language Runtime Principles
the CLR's shortcomings as far as dynamic languages go are explained and how the DLR became a game changer(which was also designed with enabling scripting capabilities in mind)
With the DLR you don't need a compiler to turn your source into bytecode.
Before the DLR the IronPython engine compiled Python code into IL, but on the other side, IronJS, the port of Javascript to .NET parses the source into its own AST and then transforms it to an Expression Tree or DLR AST. Once this is done, the DLR takes care of compiling it to IL.
The Expression Tree also acts a common language denominator hence making language interop on the platform feasible.
However,performance wise the static languages are still much faster than their dynamic counterparts.
Maybe Perl 5 could look at that direction ?
(of course I don't know if it is a drawback to be tied in a Microsoft platform ?)
Some pointers :
Dynamic Language Runtime Overview
InfoQ- Inside A DLR Language – IronJS
IronPyton
It adopts a "hybrid" approach; sharing by default but also using TLS slots for storing globals with thread scope
This reminded me that the last .NET version has an option like that
"New in .NET 4.5: ThreadLocal.Values"
as well as the "It's Not Always Nice To Share" article which concludes that it is better to share nothing by default but share explicitly
Now, I know that Perl's threading model takes TLS one step further down and that it has been heavily criticized as being "not true threading"
but all this makes me think that it is not that bad after all, but rather simplifies things and mirrors Perl's philosophy of "just getting things done"
So what's after that ? The next .NET version or C++ standard fully embracing Perl's threading model in a "back to the future" fashion ? (active since version 5.8)
Would love to see that !
What I also find great is that the book encourages the "if you have good basic skills, you can learn the rest on the job" way of thinking since you really cannot know everything ahead.
Saying that,I don't think that the title accurately depicts what the book is about.Starting a title with "Beginning..." is too contrived. In my humble opinion a title like "Real World Perl" and a subtitle of "Learn Perl from within the Industry", something along those lines, would be more on target.
Looking forward to its release
]]>