[Tutor] this group and one liners

[avi.e.gross at gmail.com]

The excuse for many one-liners is often that they are in some ways better as in use less memory or are faster in some sense.

Although that can be true, I think it is reasonable to say that often the exact opposite is true.

In order to make a compact piece of code, you often twist the problem around in a way that makes it possible to leave out some cases or not need to handle errors and so on. I did this a few days ago until I was reminded max(..., default=0) handled my need. Some of my attempts around it generated lots of empty strings which were all then evaluated as zero length and then max() processed a longer list with lots of zeroes.

I am not saying the above slowed things down seriously, but that other methods that could solve the problem, but not o one line, were ignored.

The pipelining methods I mentioned vary. Some languages have a variation using object-oriented techniques where you can chain calls by using methods or contents of objects as in:

a.b().c(arg).d 

and so on.

Some languages encourage writing that in a more obvious pipeline over multiple lines, where you may even be able to intersperse comments.

But is that more efficient than doing it line by line? Consider this code:

A = something
B = f(A)
C = g(B)
rm(B)
...

In many pipelines, there are lots of intermediate variables that are referenced once and meant to be deleted. In languages with garbage collection, that may happen eventually. But often the implementation of a pipeline may be such that only after all of it is completed, are the parts deleted on purpose or no longer held onto so garbage collection can see it as eligible.

I will end by mentioning a language like PERL where people that things to extremes and beyond. The language encourages you to be so compact that normal people reading it often get lost as they fail to see how it does anything.

Without giant details, the language maintains all sorts of variables with names like $_ that hold things like the last variable you set. Many of the verbs that accept arguments will default to using these automatic hidden ones as the target or source of something.

So you can read a line in with something like 

my $mystring = <STDIN>;
print "$mystring \n";
chomp($mystring);
$mystring =~ s/[hH]el+o/goodbye/g;
print $mystring;

The above (with possible errors on my part) is supposedly going to read in a line from Standard Input, remove any trailing newline and reassign it to the same variable without explicitly saying so, make a substitution from that string into another and replace every instance of "hello" with "goodbye" and print the result. But since everything is hidden in $_, you can write briefer and somewhat mysterious code like:

$mystring = <STDIN>;
chomp($mystring);
$mysub =~ s/hello/goodbye/g;
print $mysub;

The above prompts me for a line of text and I can enter something like "Hello my friends and hello Heloise." (without the quotes) and it spits out a result that matches "hello" with "h" either upper or lower case, and any numer of copies of the letter ell in a row:

$ perl -w prog.pl
Hello my friends and hello Heloise.
goodbye my friends and goodbye goodbyeise.

Well, yes, I deliberately used a regular expression that produced a bit more than is reasonable. BUT the same much shorter code below does the dame thing:

$_ = <STDIN>;
chomp;
s/[hH]el+o/goodbye/g;
print;

The lines like "chomp;" are interpreted as if I had written "$_ = chomp($_)" and the substitution as if I had written it a bit like the first version and the same for the print. 

And can it be a one liner? The semicolons are there to make something like this work fine:

$_ = <STDIN>; chomp; s/[hH]el+o/goodbye/g; print;

But WHY be so terse and cryptic?

As Alan points out, your code may be used and maintained by others. And the brevity above also comes with a cost of sorts. For every statement, the PERL interpreter must modify a slew of variables just in case you want them, many with cryptic names like $< and $0 but the other overhead is how many other function(alities) have to check the command line arguments and when missing, supply the hidden ones.

For beginning students, I think it wise to start with more standard methods and they can use more advanced techniques, or in my example perhaps more primitive techniques, after they have a firm understanding.

And my apologies if I bring in examples from other programming languages. Python has plenty of interesting usages that may seem equally mysterious to some.

- s/a.e.gross/Avi/


-----Original Message-----
From: Tutor <tutor-bounces+avi.e.gross=gmail.com at python.org> On Behalf Of Alan Gauld
Sent: Wednesday, July 6, 2022 4:22 AM
To: tutor at python.org
Subject: Re: [Tutor] this group and one liners

On 06/07/2022 03:31, avi.e.gross at gmail.com wrote:
> But for teaching a relatively beginner computer class, ...
> the goal often is to do things in a way that makes an algorithm clear,

Never mind a beginner. The goal should *always* be to make the algorithm clear!

As someone who spent many years leading a maintenance team we spent many hours disentangling "clever" one-liners. They almost never provided any benefit and just slowed down comprehension and made debugging nearly impossible.

The only thing one-liners do is make the code shorter. But the compiler doesn't care and there are no benefits for short code except a tiny bit of saved storage!

(I accept that some ancient interpreters did work slightly faster when interpreting a one liner but I doubt that any such beast is still in production use today!)

…
> I mean sure, there are lots of extra variables sitting around, maybe some if statement with an else and maybe some visible loops. But they show how the problem is being approached and perhaps allow some strategic debugging or testing with print statements and the like.

They also allow interspersed comments to explain what's being done

And make it easier to insert print statements etc.


> An interesting variation I appreciate in languages with some form of pipeline is to write the algorithm forwards rather than nested. Again, this is easier for some to comprehend. I mean using pseudcode, something like:

Smalltalk programmers do this all the time(in a slightly different way) and it makes code easy to read and debug. And in the Smalltalk case easier for the optimiser to speed up.

> The point I am making is whether when some of us do one-liners, are we
really helping or just enjoying solving our puzzles?

In my experience one-liners are nearly always the result of:

a) an ego-trip by the programmer (usually by an "expert")

b) a misguided assumption that short code is somehow better (usually by a beginner)

Very, very, occasionally they are an engineering choice becase they do in fact give a minor speed improvement inside a critical loop. But that's about 0.1% of the one-liners I've seen!


-- 

Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos

_______________________________________________
Tutor maillist  -  Tutor at python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor