Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Mark Leighton Fisher (4252)

Mark Leighton Fisher
  (email not shown publicly)

I am a Systems Engineer at Regenstrief Institute []. I also own Fisher's Creek Consulting [].
Friday June 22, 2007
11:57 AM

LINQ and map()/grep() in Perl

[ #33579 ]

I was initially excited about LINQ, the C#/VB.NET/etc. extensions for "language-integrated query, set, and transform". Then I realized that map() and grep() (and the easy extensions to these found in Higher-Order Perl) work the same as LINQ, with the advantage that they are not tied to a particular implemention of the lists or sets that you are operating on. Since map() and grep() work with CODEREFs in the list (or could be made to work easily I'm too lazy to look this up right now), then map() and grep() could work with any list/set source, whether it is XML, DBI, a sensor array, or whatever.

So why doesn't Microsoft just go ahead, break down and add true functional-programming constructs to .NET? They finally added a fairly reasonable implementation of regexes to .NET. (I think an earlier comment I made about requiring capture access through a group is an unnecessary step may have been prompted by .NET 1.1, as the .NET Match class has a direct Captures property, as well as a Groups property). (Comments about "because they're Microsoft" will be duly ignored.)

Microsoft has had a number of smart people working for it over the years (J. Allard, for whom we Windows users can thank for Winsock, is one example). Nowadays Microsoft has upped the ante by adding researchers who did not "grow up" in Microsoft, but were brought into the fold (Rick Rashid and the (hopefully not late) Jim Gray are a couple of examples). Functional programming, applied appropriately, makes programming easier (and not by just a small amount). Let's face it, sometimes you just want to process a bunch of stuff without regard to its order, which is when functional programming techniques to me really shine. Adding general functional programming constructs to .NET would let Microsoft get ahead of the curve for a change (the last time I thought they really got ahead of the curve was going with GUI environments with Windows when many PC developers were mired in DOS land).

Now that closures and anonymous functions (lambdas) will be added to .NET, adding the functional programming operations would give a nice boost to .NET (as well as a speed-up to the (if it ever happens) Perl6 -> DLR -> CLR implementation). It has been said that programmers write the same number of lines of code per day, no matter what the language (references, anyone?) Functional programming gives us developers a way to write fewer lines of code for the same operation, thereby freeing us to write more lines elsewhere in the same amount of time. We don't usually program in assembly language anymore (even embedded programming often uses compiled languages these days), so why not use functional programming's expressive power to let us do more work in less time?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Actually MS is doing lots of functional goodness on the .NET platform, the SML.NET [] compiler has been around for a while now, and F# [] is a pretty nice addition to the ML family of languages (Standard ML, Ocaml, etc).

    In addition to all this stuff, they have Simon Peyton Jones [] (one of the main guys behind GHC [] (the Haskell compiler)) on their research staff as well as some other really cool FP guys.

    As for the other .NET languages, looks like there might be lambdas in C# 3.0 []. Of course they already have de

    • I knew that Microsoft had functional languages for .NET, but I still have hopes that they move more functional goodness into the major languages (esp. VB.NET and C#). With .NET, they have a pretty good handle on object-oriented and procedural programming paradigms (disregarding the method-call bias of their object-oriented programming implementation (see Smalltalk for one example of message-passing object-oriented programming)). Adding functional programming constructs to their major languages helps them ge