Back

I'm still grappling with the possible implications of this work. Lingy, as I understand it, is being designed to be somewhat portable ... Imagine Clojure as a lingua franca alongside C with JIT-level performance to match.

Ingy also demoed a wrapper for YAML parsers which could read configs as YAMLScript. Imagining my config files becoming config middleware - This machine has 'test' in the hostname, return the test database credentials...

(Not sure how I feel about something like that just yet)

Also enjoyed Ovid's Corinna / feature 'class' update (go install 5.38!), which also featured a reveal of Oshun - a type *checking* system for #perl applications, intended to be deployed at the borders of your application to aid your data integrity endeavours.

This builds on the TYPE attribute parameter to `my` which has been in the Perl docs since 5.8.0 and has been, erm, "evolving" since then.

Check out the talk here: https://youtu.be/uT0S-jfO1mE

Check out Oshun here: https://github.com/Ovid/oshun

Type checking systems are nothing new in #perl. Moo* users will probably be familiar with `isa` which is an extensible type check for object member's values.

These aren't just the int or char* you might expect when talking about types, but can be used to assert the instance type of an object, whether or not a string looks like a URL or a UUID or a postal code, and so on.

Couple of short, fun TPRC vids. The first is The PerlayStation Games Console where Saif Ahmed presents his console-based GUI library built from braille and block quadrant Unicode characters.

Saif built this to facilitate instrument control and data analysis tasks in his research, but a number of demos are shown here including games. With clear inspiration taken from the #zxspectrum, this is a fun #perl project.

Check it out here: https://youtu.be/wUKcfQwHmR8

The second is Creating Algorithmic Music with #Perl where Gene Boggs gives an overview of some of the algorithmic and generative music #MIDI modules he has been developing.

There is a whole suite of these on CPAN*. Demos go from simple scales, melodies and lead phrases to a web app which can generate Jazz/Rock accompaniment audio for you to practice with. Check it out here: https://youtu.be/TCPK9j-Uo9s

* https://metacpan.org/search?q=author%3AGENE&q=MIDI

Another cool presentation from TPRC. Ingy talks about a #coffeescript style destructuring syntax for #perl which he hopes to introduce as a core language feature: https://youtu.be/ifoYsubNRj4

Destructuring allows you to dereference and assign elements of a data structure in one go. Rather than have multiple assignment statements, you can reference key names and apply names to array elements by appropriately structuring the LHS clause of a single assignment statement.

WIP: https://metacpan.org/dist/assign/view/lib/assign.pod

@fuzzix Also: More explanation of music theory terms, and more line by line code walk-throughs.

@mjgardner I like the image you evoke of the entire online and software economy physically collapsing, a small but determined team taking shelter within, planting a seed for the future so that we do not repeat the mistakes of the past (Looking at you, SOAP!)

@fuzzix I have bad news for you: #SOAP came out of that same era. It was an over-engineered adaptation by #Microsoft and @w3c of @davew’s #XMLRPC

Mind you, the entire #XML-based #WebServices stack of standards is being re-accreted on top of #JSON with efforts like #OpenAPI and JSON Schema. The final and once-again neglected piece is automated service discovery à la #UDDI

@profoundlynerdy @fuzzix “Over-engineered” is code for “I’m glad I haven’t met that corner case yet”

@mjgardner @fuzzix There is a certain elegance to simplicity. Simple things are easier to debug than complex things. Some simple things can scale in ways no other structues can, which is what fractals are, basically.

Sometimes "edge-case" is code for "I'm using the wrong tool for the job." XD

@profoundlynerdy @fuzzix It’s a tradeoff. If we leaned too far towards small simplicity we’d still be gluing together grep, sed, and awk with #shell scripts (and dealing with different versions and variants’ portability headaches) instead of writing #Perl.

And as Perl’s star has fallen, so-called “#DevOps” are still doing the former or have turned to #Python or other languages whose vanguard didn’t Osborne away their lead.

@mjgardner @profoundlynerdy @fuzzix Doing Python (not my favorite but is the standard for the company) and trying to get the team to learn it, being fashionable works. Oddly enough, shell is attractive to some precisely because it is bulky and "limits" what can be done, good excuse I guess.

@bololacertus @profoundlynerdy @fuzzix The fact that:
• https://manpages.debian.org/devscripts/checkbashisms.1.en.html exists
• is written in #Perl
• and is used by the #Debian #Linux project (as part of #Lintian) to automatically reject any packages that assume every #shell acts like #bash
…tells me all I need to know about the supportability of shell scripts

@mjgardner @bololacertus @fuzzix That's a very solid argument.

@overeducatedredneck @mjgardner @profoundlynerdy @fuzzix It pains me to say it, but I also have abandoned perl in favor of python. Not really by choice though, but by corporate choice.

@bololacertus @overeducatedredneck @profoundlynerdy @fuzzix Put another way, `checkbashisms` exists because the only way to get #shell scripters to stick to strict #POSIX syntax and userland programs is to automatically reject deviations with extreme prejudice.

And please don’t get me started on #Python portability. Y’all can’t even settle on how to manage the virtual environments that every individual Python-based tool requires.

@mjgardner @bololacertus @overeducatedredneck @fuzzix What is the most common #Perl virtual environment solution?

@profoundlynerdy @mjgardner @bololacertus @overeducatedredneck @fuzzix perlbrew? Certainly not the only one, but it's been around. So maybe it is "most common."

@ology @profoundlynerdy @bololacertus @overeducatedredneck @fuzzix I’ve found most people use #perlbrew because they explicitly want a repeatable #Perl environment with a contained installation and modules. They don't need it just to get any random Perl application to work.

@AFresh1 Yes, because you care about distributing code that others *don’t* need a separate virtual #Perl environment to run.

Nearly every set of end-user installation instructions for #Python-based applications begins with steps to give the app its own virtual environment with separate interpreter and dependencies.

/cc @ology @profoundlynerdy @bololacertus @overeducatedredneck @fuzzix

@profoundlynerdy @bololacertus @fuzzix Note that `set -o pipefail` is #bash-specific