Re^7: I want you to convince me to learn Perl

[BrowserUk]

Don't good friends deserve a name?

Sorry. I see your smiley face, but I'm going to answer the question seriously: Absolutely frikkin' not :)

Why contrive a name for something that will never be called anywhere else?

Why contrive a name for a block of code that only makes sense in one place in the source?

That will often will only work in one place in the source because it needs access to lexical variables in scope at that position (closures). If you make the blocks named subroutines, then they have to be declared out-of-line of where they are used, which means you now need to pass (what would be) closures via arguments; and that means making up more names for the formals.

Take a look at this, and tell me, what would you name the two map blocks?

And if you're going to go that route, how about naming the blocks for your while loops; and for loops; and if & elsif & else bodies; and ...

[davido]

"Why contrive a name for something that will never be called anywhere else? Why contrive a name for a block of code that only makes sense in one place in the source?"

This is one of the compelling arguments for favoring C++11 over C++98(03): In older flavors of C++ the standard algorithms often required that a functor class be passed in, for example, as a comparator. Believe it or not (I'm sure you already know this, though), people had to go to all the trouble of creating a named class with an overloaded operator(), and then pass that named class to a standard algorithm just to do simple things like calling a sort routine, or a binary search routine on non-POD types. And even then it might be necessary to overload operator< as well. C++11 finally provided lambda functions, which allowed users to stop going through all the silly work just to create a comparator that would be used in only one place. In other words, in this regard, C++11 finally gained the ability to make something that should be simple, relatively easy as well, and this is one of the things that has made C++ fun, finally. Perl has had anonymous functions for...well, I don't know how long, but at least dating back to when sort and map made it into the language.

So what I don't get is, after all these years, and after so much work has gone into making older languages like C++ adopt the approach, why people still say, "now why would you want that?"

[BrowserUk]

Perl has had anonymous functions for...well, I don't know how long,

From the index in perlfunc: "* - sub was a keyword in perl4, but in perl5 it is an operator, which can be used in expressions.".

That said, map/grep/sort have the ability to take bare blocks and even 'bare expressions', which are pretty unique to Perl, and (I guess, but don't know) might have been possible prior to perl5.

So what I don't get is, after all these years, and after so much work has gone into making older languages like C++ adopt the approach, why people still say, "now why would you want that?"

It comes as no real surprise to me. They are the same people that eshew map & grep and ?: and a whole bunch of similarly 'non-traditional' programming constructs and concepts as 'unclear' or 'too complicated'. The only thing that really surprises me is how widespread the notion is that all such HLL constructs are somehow 'clever hacks' or 'obfuscation'.

With regard to C++11. I think the only real problem with it is that in order to make best use of the power and conciseness of the new constructs and libraries, you basically have to relearn the language from scratch and unlearn your dependencies upon libraries like Boost.

With so much legacy C++ around, not to mention those C++ programmers that will never make the transition to the new ways of thinking that are enabled by +11 and will be required to fully realise the benefits from it, it'll take another 10 or more years before the new generations of programmers coming through -- for whom it will all be natural and normal and obvious -- will usurp the reins of project control sufficiently to legitimise the new ways of working and finally consign the old-school patterns to the bit-bucket.

Perhaps the single, most exiting thing about C++11, is that for the first time the standards body have accepted and adopted the concept that less is more into the language design. The idea that programmers are actually quite adept at getting to grips with and utilising higher levels of abstraction and that not everything has to be verbosely and laboriously laid out and stated explicitly.

Of course, it will take another 20 years of deprecation cycles, new minds and retirements for the full affects and true potential to become fully realised, but if this were any other industry the same levels of change and turn around would require 50 or even 100 years, so I guess its not so bad if you consider it the light of history. Still, it's one of the few things that make me wish I could go into stasis for 20 years and then pick up programming from that point going forward.

Once Moore's Law has plateaued as it will, and concurrency is both ubiquitous (as it is) and *must* be utilised (as it will have to be), and architects and managers can no longer throw hardware at problem s to achieve scale because of the energy costs, the current way of program development -- and I mean the entire way of working as exemplified by TDD and agile -- will need to replaced by methods that don't require programmers to write 3 lines of code for every one that actually gets used, and don't require every low-level operation -- like reading a line of data from a file -- to use 3 or 5 lines of code and be re-written for every new program.

Programmers will have start using the very machines, tools and techniques that they currently apply to speed up and economise everyone else's jobs, to their own work. And once we stop hand-fettling every line of code and test and operation; and start using our skills to turn programming into the programming equivalent of CAD/CAM manufacturing and maybe even additive manufacturing.

Only then will we stop tendering out entire projects to the black hole development processes that we currently use, that mean we don't discovered the flaws and overruns until 18 months down the road when we've spent millions and nothing works. Instead, software projects will be designed like any other large scale assembly project; with small components bought in from specialist development companies by competitive tender. And probably multi-sourced; with interchangable components being purchased from several suppliers who not only write the code to spec. but are charged with both maintaining and improving those code components going forward as a part of the purchase price.

Sorry. Now I'm just imagining and rambling. But still, its a world I wish I could be a part of.

[soonix]

I see your arguments and they are true. But - there are no comments in the sample code. Although it is more or less obvious what it does (even without the surrounding node), wouldn't

sub discard_sortkey { unpack 'x[nn]A*' };
sub prepend_yearmonth {
    my( $alpha, $num ) = m[^(\S+?)\s*(\d+)$];
    $num += 2000 if $num <= 49;
    $num += 1900 if $num <= 99;
    pack 'nnA*', $num, $months{ $alpha }, $_;
}
print for map{ discard_sortkey } sort map { prepend_yearmonth } <DATA>
+;

be evenly obvious, although there is still no comment?

My field of operations was mainly CRM/ERP systems. At my first job, we used AWK to generate COBOL program source for the different target systems. At my previous job I still generated (and sometimes programmed) COBOL - in this very century. Of course, when Perl became known, I liked it at first sight, especially because I knew the patchwork tools it aimed to replace.

OTOH, most of the languages I had worked with before, had variable declarations and no "contexts", hence no need for sigils. Thus, when I later saw Python, I liked it, too. I think this is what the OP called "cleaner".

I see virtues in both approaches.

(Update: Originally posted under a different node in this thread)

[BrowserUk]

e evenly obvious, although there is still no comment?

First, almost a side-issue here, but an important one. My personal take on comments is expressed at length here and here; but can be summarised by saying that I think that for the most part comments in source code are a counter-productive waste of time, energy, resources and therefore, money.

That said, in the isolated form, I find your self-documenting code a highly readable, fine attempt at the art.

But ... it only works because it is in isolation of a context.

For example, prepend_yearmonth() requires to close over %months. In a short script, the hash might be a package global and declared above the declaration of the subroutines; the actual sort is part of the package level code and everything's hunky-dory.

But now put the sort inside a subroutine -- say, part of the logic of an object's method call. And the hash being referenced by the sort is a part of that object's instance data. Now there is simply no way to define those utility subs to close over the required reference hash.

And that's the crux of the problem that anonymous lambda's address. They allow the programmer to define callback code in the context of its use, thus availing it of access to everything that is in scope at that point. Named-subroutines cannot do this -- in Perl at least -- because any closures used by subs declared in a nested context will result in the infamous:

sub x{ my $y; sub z{ say $y; } };;
Variable "$y" will not stay shared at ...

If you feel it is necessary to (self)document the use pattern of the GRT -- and I can make a strong case that it is better for programmers to learn the pattern than to have it hidden from them -- then I would perhaps suggest something along the lines of:

#! perl -slw
use strict;
use GRT; # contains:
#sub GRT::prefix(&@)  { my $code = shift; map &$code, @_ }
#sub GRT::discard(&@) { my $code = shift; map &$code, @_ }

my %months = (
    FY => 0,
    Jan => 1, Feb => 2, Mar => 3, Apr => 4, May => 5, Jun => 6,
    Jul => 7, Aug => 8, Sep => 9, Oct => 10, Nov => 11, Dec => 12,
);

print for GRT::discard{
    unpack 'x[nn]A*'
} sort{
    $b cmp $a
} GRT::prefix{
     my( $alpha, $num ) = m[^(\S+?)\s*(\d+)$];
     $num += 2000 if $num <= 49;
     $num += 1900 if $num <= 99;
     pack 'nnA*', $num, $months{ $alpha }, $_;
} <DATA>;

__DATA__
Apr 2006
FY05
FY98
FY04
Dec 2007
Jan 1997
Jan 1998
Dec 1998

The key points of this are:

1. The GRTsubs can be imported from a module.
2. That module can document the GRT and the use of the helper functions.
3. The purely implementation elements, the maps, are hidden.
4. The sort comparator block can be specified to invert the order of the sort.
5. It can be constructed at any scope and make full use of the context.

Of course, it is also substantially slower and little more than a pair of 'active comments'; which leaves me believing that the simple addition of a couple of comments achieves the same thing:

print for map{
     ## remove them once sorted
     unpack 'x[nn]A*', $_
 } sort map {
     ## prefix year & month in binary form
     my( $alpha, $num ) = m[^(\S+?)\s*(\d+)$];
     $num += 2000 if $num <= 49;
     $num += 1900 if $num <= 99;
     pack 'nnA*', $num, $months{ $alpha }, $_;
 } <DATA>;