More running something on something else and LINQ
It's rare that I see a useful and relevant example of .NET's language agnosticism. OpenForcecast is an exception -- it's a Java library that helps you do time series projects (aka forecasting), and was ported to J#.NET by the author of a book on reporting services.
I included the .NET version of OpenForecast in the source code, which comes with this article. I had to take care of only a few compilation errors inside the MultipleLinearRegression, as a result of the fact that several Java hashtable methods were not supported in J#, such as keySet(), entries(), and hashtable cloning.
And more Audrey Fanboyishness
As I mentioned before, LINQ is something I'm really excited about.
Being able to do SQL-like joins in the app layer, between XML and relational data sources, is the missing piece for making all those XML-enabled services trivially extensible. The nontrivial DOM traversal, XSLT, or RDBMS translation now required is something I'd be very happy to leave behind, and LINQ promises to do that.
Making this less ethereal, here's an example of Amazon's XML API wrapped up in XLINQ. IMHO, the power isn't in the wrapping up of one API, it's joining to your own private, enterprise-specific resources. The distributed/heterogenous join scenarios supported are currently the domain of EII platforms like Openlink's Virtuoso, but with LINQ it's all there embedded in the dotnet runtime. How cool is that?
Open source's low-road answer to LINQ seemed to me to imply embedding SQLite in dynamic language interpreters. As with v6.pm, Audrey proves that the
embedding is not necessary, but sqlite makes sense, as she's writing a LINQ workalike for her pure perl5 Jifty talk at OSCON talk.
She. is. unreal.
10:50:25 AM 
|
|
