Skip to main content


Watching some of the vids coming out of this year's Perl and Raku Conference. Ingy döt؜؜ Net­'s talk on his work on Lingy and YAMLScript was pretty amazing.

Lingy is a #clojure hosted on #perl - Perl code can call Lingy code can call Perl code. The idea of having a Lingy VM with JIT is very appealing.

YAMLScript is a YAML-style dialect of Lingy (or any Clojure implementation), for those who don't like LISP style.

Check the talk out here: https://youtu.be/9OcFh-HaCyI

This entry was edited (1 year ago)

Mark Gardner reshared this.

in reply to fuzzix

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)

in reply to fuzzix

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

#perl

Mark Gardner reshared this.

in reply to fuzzix

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.

#perl

reshared this

in reply to fuzzix

that's basically missing the whole point. Type checks need to happen at compile time to have any value. isa is not type checking.
in reply to fuzzix

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

in reply to fuzzix

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

This entry was edited (1 year ago)

Mark Gardner reshared this.

in reply to fuzzix

In the talk, I failed to mention that there are no "hard and fast" rules in music - like using the pentatonic in the bass can be dull. ...Next year, in Vegas. 😅
in reply to Gene Boggs

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

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

in reply to fuzzix

I always like to note that #YAML was designed by #Perl and #XML hackers in the middle of the dot-com crash of the early 2000s. People either think that explains much or look at me funny for bringing up such “ancient” history
This entry was edited (9 months ago)
in reply to Mark Gardner

@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!)
in reply to 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

in reply to Mark Gardner

@mjgardner I think YAML is over-engineered. I like TOML more, but miss YAML's sequence syntax.
in reply to Profoundly Nerdy

@profoundlynerdy “Over-engineered” is code for “I’m glad I haven’t met that corner case yet”
in reply to Mark Gardner

@mjgardner 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

in reply to Profoundly Nerdy

@profoundlynerdy 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.

in reply to Mark Gardner

@mjgardner @profoundlynerdy 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.
in reply to Bolo Lacertus

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
in reply to Mark Gardner

@mjgardner @bololacertus @profoundlynerdy checkbashisms exists because Debian's default /bin/sh is `dash`, the Debian Almquist Shell, a port of NetBSD's ash. Both of which are pretty strict, minimalist POSIX shells. They do this to speed up things like booting and package install (particularly during system installation). Bash is 10x bigger just by file size.

(I'm in the camp that abandoned perl for shell and python, and I tend to use [d]ash not bash for scripts 😀

in reply to Jeff

@overeducatedredneck @mjgardner @profoundlynerdy 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.
in reply to Bolo Lacertus

@bololacertus @overeducatedredneck @profoundlynerdy 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.

in reply to Gene Boggs

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.
This entry was edited (9 months ago)
in reply to Mark Gardner

@mjgardner
I use plenv so I can have lots of different perl versions available to shake out test failures. https://github.com/tokuhirom/plenv
@ology @profoundlynerdy @bololacertus @overeducatedredneck @fuzzix
in reply to Andrew Hewus Fresh

@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

in reply to Profoundly Nerdy

@profoundlynerdy @bololacertus @overeducatedredneck It’s not necessary for most because the #Perl culture gives a damn about not wasting users’ time while still moving the language forward: https://fosstodon.org/@leonerd/111856552091954510

Some more @leonerd posts from the same thread:
https://fosstodon.org/@leonerd/111852567952393719
https://fosstodon.org/@leonerd/111855908131666259
https://fosstodon.org/@leonerd/111856356366461768

If you must have multiple Perls, #perlbrew is simple and common: https://perlbrew.pl


@dalias @pjakobs Sure but that's still "language culture". The entire culture around Perl is that back-compat is important and breaking things like that is just not on.

I'm not saying it's universally respected, but you'll find that most authors most of the time do that that kind of thing seriously. It's not *just* the core language, it's the entire ecosystem.


Unknown parent

Mark Gardner

@Rog @profoundlynerdy “Standard #Linux tools” vary as you move to #macOS and other #BSD variants.

That’s the portability headache I alluded to.

But if your world is circumscribed by #Linux, #bash, and #GNU userland, more power to you

Unknown parent

Mark Gardner

@anubhav @profoundlynerdy @bololacertus https://social.sdf.org/@mjgardner/110707555587542242


@Rog @profoundlynerdy “Standard #Linux tools” vary as you move to #macOS and other #BSD variants.

That’s the portability headache I alluded to.

But if your world is circumscribed by #Linux, #bash, and #GNU userland, more power to you