It has been an interesting experience, and Dave has been a great host making me feel very comfortable during the whole process.
I talked about Open Source, archery, cats and PostgreSQL.
Here there is something more to read about, and for listening the interview just click on the image.
sub fmt { sprintf @_[0,1] }
# Your printf-style directives specify 1 argument, but no argument was supplied
sub fmt { sprintf $^a, $^b } # OK!
Oh, and this is Perl 6 (that I'm still learning!).
The idea is to have something like the following working:
use Fluca1978::Utils::PostgreSQL::PGVersion;
for <10.1 11beta1 11.1 9.6.5 6.11> {
my $v = PGVersion.new: :version-string( $_ );
say "PostgreSQL version is $v";
say "or for short { $v.gist }";
say "and if you want a detailed version:\n{ $v.Str( True ) }";
say "URL to download: { $v.http-download-url }";
say '~~~~' x 10;
}
The class allows you to check the info, get the URL for the download, compare two different versions to see which one is newer, see if it is a beta, and so on.
Read more on this blog post.
The book is a Quick Start Guide, that means it goes straight to the point, in this case, programming on the server-side of PostgreSQL.
Why is this related to Perl?
Well, one very cool feature of PostgreSQL is the capability to execute functions, and therefore triggers and procedures, in pretty much any programming language available out there. And this of course, means Perl!
In fact, Perl is very well supported in PostgreSQL to the point that the DO statement does allow you to use PL/Perl code instead of the PL/pgSQL one.
The other language I show, as a "foreign" language, in this book, is Java. My idea was to show to the readers the differences between using a language like Perl and one that requires a full compile-deploy cycle.
Hope the book can be useful.
]]>Well, while I find it very interesting to read Perl books, I have to remember and say that coding is the very way to fix concepts into your mind!
]]>- I tend to document everything. This could be seen as a fault of mine, but I tend to see it as an advantage. Of course you cannot (and really don't want) to comment on a single line script!
- one-liners are quite hard to test and to deploy. Because we all run tests against our program, especially before deploying them in production!
- I don't have enough room space in my brain to remember all magic variables! $., $, and friends...
- Often I want to change the result depending on other run-time contexts, and therefore I find more useful to have a program driven by parameters (or configuration) than having to slightly change my one-liners.
- Git history helps more than the shell one. Having a whole set of scripts and history about when, why and how they have been created and used helps me more than searching thru the shell history.
- I don't want to impress anyone. One reason some developers use one-liners is to impress colleagues. Quite frankly, I don't care about it.
Despite the above, I'm not against Perl one liners, and I see how powerful and useful they can be.
It's just I'm more comfortable with my text editor in front of me.
On the same line of thoughts, why is not "my" a default for variables?
Why not automatically using a predefined set of modules without having to specify "use"?
The language has been built and evolved in a specific way, so while we can change the future, we cannot destroy the past.
]]>