path: root/_posts/2018-08-15-the-perl-conference-in-glasgow.adoc

---
date: 2018-08-15
wip: true
feed: false
tags: Perl Conference
description: >
  My feedback and comments on some of the talks I attended during The Perl
  Conference in Glasgow, in 2018.
---
= The Perl Conference in Glasgow
:toc: preamble

This year the European Perl Conference was hosted in Glasgow, and of course
I've attended a number of presentations there. On some of these, I have some
feedback or comments. These talks, and the feedback I have for them, are
detailed in this blog post. For some talks, I'll detail it as a summary of the
presentation, because I feel the message is important.

== Discourse Without Drama

[NOTE]
====
There used to be comments here to show a different perspective to the speaker.
However, someone's lightning talk has been removed because
https://act.perlconference.org/tpc-2018-glasgow/news/1568[some people played
the "offended" card], and no specifics are being published about it. As such, I
cannot make any assertions on what is and what is not allowed, and have to
assume that criticism of harmful beliefs will be shut down. As such, I have
removed the comments which used to be here, in an attempt to keep it from
detracting from the rest of my post.
====

== European Perl Mongers Organiser's Forum 2018

The Perl community isn't big nowadays, which is sad. The Perl 6 language also
offers a lot of concepts which are very well suited for modern programming.
However, if no new users try out the language, it will be all for nothing. As
such, we need to bring new blood in to the community.

One of the ways of doing this, is by extending our promoting efforts outside of
the Perl community. Most people who like Perl are in a social bubble with other
people that are also familiar with the Perl programming language, be it 5 or 6.
But we need to reach new people as well, who will most likely be outside of
this social bubble. These people don't have to be techies either, they might
just as well be marketeers or designers.

I myself am part of the "techies", so I'll stick to this particular group for
now. And I know people like me can be found at meetups, so it would be
worthwhile to promote Perl at meetups which are not dedicated to Perl. Think of
more generic programming meetups, or GNU+Linux User Groups. We have to be
mindful not to be too pushy, though. Listen to others people, and try to
understand the problem they're facing. Most of them will not be open to use a
different language immediately, especially not Perl (which sadly has a
particularly bad standing amongst people unfamiliar with it). Try to assist
them with their issues, and slowly introduce them to Perl (6) if it helps to
showcase what you mean. It might also be interesting to show people examples on
how to solve certain issues before telling them the language's name, so they
don't have a negative preconception solely from the name.

Another thing to note is that Perl is more than just a programming language.
It's a community, and a large library of modules, known as CPAN. And CPAN
offers some nifty tools, such as the CPAN testers, which help ensure module
developers that their code runs on a massive set of platforms and Perl
versions.

This has led me to consider the creation of a new Perl 6 module:
`CPAN::Tester`, to make it easy for people to contribute to a large-scale
testing environment for Perl 6. The idea is that one can run `CPAN::Tester` on
their machine, which will keep track of new Perl 6 modules being uploaded to
CPAN. The results are to be sent to another server (or multiple servers), which
can aggregate the data and show a matrix of test results. This aggregating
server could also be built as a Perl 6 module, possibly named
`CPAN::Tester::ResultsServer`. This would make setting up an environment
similar to CPAN testers for Perl 5 quite easy for Perl 6.

== TPF Update

This talk gave some interesting information on the current state of The Perl
Foundation. And there have been some nice developments in the past year, mostly
the updated websites (https://perl.com and https://perlfoundation.org). Sadly,
some sites remain in a slightly outdated state, though there are plans to
update these too. Most notably, https://jobs.perl.org seems to require a
webmaster to bring the platform online and keep it in check. If this is
something you'd like to do, don't hesitate to contact The Perl Foundation about
it.

Furthermore, The Perl Foundation is looking for more sponsors, as always.
However, you don't need to be a massive corporation to be able to help them
out. They are looking for more smaller sponsors as well. The money of the
sponsorships will be used to support the Perl community. This means money will
be going towards organizing events, such as The Perl Conference, or grants for
both Perl 5 and Perl 6 development and promotion.

If you'd like to help the Perl community through The Perl Foundation by
volunteering, this is also greatly appreciated. The time commitment expected of
you will depend very much on the tasks you want to deal with, but about 10
hours a month is a good estimate.

== Perl 6 in Real Life $Work

The speaker shows the perfect use case for
https://docs.perl6.org/language/grammars[Perl 6 grammars], advanced yet
readable parsing of text and doing stuff with the results. It's an interesting
talk, showcasing some nifty grammar constructs. The best part of this is, that
it actually runs in production, where it parses over 700 files, consisting over
100,000 lines of code, in about 22 seconds (on his laptop). This goes to show
that Perl 6 is no longer "too slow to use in production".

It might be interesting to run this application of grammars on every Perl 6
release to gather more information on the speed improvements of Perl 6, much
like Tux's `Text::CSV` runs.

== Releasing a Perl 6 Module

Personally, I prefer GitLab over GitHub, as they have much better testing
functionality, and they actually release their own platform as an open source
package. I'd like more GitLab love from the community and speakers as well if
possible. This would also make the speakers CI configuration simpler, for which
he currently uses a `.travis.yml` file. This requires him to build Perl 6 from
source every test run, wasting quite a lot of time.

A number of directories were listed which are standard in Perl 6 module
skeletons. However, the `resources` directory was left out of it, which should
get its fair share of love as well. Files listed in here can be made accessible
through the `%?RESOURCES` variable in your program, allowing you to easily
bundle additional resources with your moule.

It was also noted that there's a module to help you set up this module
skeleton, `mi6`. The speaker also noted that it doesn't seem to add much once
you know how a Perl 6 module is organized, and I tend to agree with this.
Actually, I made a module precisely because I agree to him here, `App::Assixt`.
This module intends to smoothen the entire course of module development, not
just the creation of a skeleton file. It will take care of keeping your
`META6.json` up to date, and ease uploading your module to CPAN as well.

Lastly, the speaker says the `META6.json` documentation can be found in S22.
While this is technically correct, S22 is *not* the implementation's
documentation, this lives in the official Perl 6 documentation instead. S22
offers many additional information to be stored in the `META6.json`, but using
these fields will actually break installation of your module through `zef`,
rendering it unusable by others. I would strongly recommend people not to use
S22 when trying to figure out what they can or cannot do with their
`META6.json`.

== How to become CPAN contributor?

Submitting a pull request (or more correctly named, merge request) to a
repository is possibly the most straightforward way to help out other projects.
However, sometimes it will take a long time to get a response. The speaker
notes this can actually be on the scale of years. I have authored a number of
modules myself, and have been in the situation where I had not realized I got a
merge request from another person (same goes for issue reports). I would
recommend people who are not getting timely responses to their contributions to
contact the maintainer via other channels which are more suited for
communications. Think of email or irc, for instance. You'll generally have a
much better chance of getting a timely response from the author, and then you
can work out your contribution and see if you can get it merged into the main
project.

The speaker also lists a couple of ways to get started with contributing to
modules. One thing I missed in particular was the Squashatons for Perl 6. These
generally offer a good entry point to help out with the language's development
and the ecosystem's maintainance.

Near the end, it was pointed out that it is a good idea to have a thick skin.
Even when it's not intended, people can come accross as rude. This is in
opposition to the talking point of the speaker yesterday (_Discourse Without
Drama_), but he does raise a good point here. People oftentimes don't mean to
insult you, but context is easily lost in written communications. Try to stay
mature and professional, you can simply ask for clarification. If you feel the
person remains hostile towards you, walk away. There's plenty of other projects
that would love your contributions!

== Conference Organizers & European Perl Mongers Organiser's Forum 2018 BoF

Well, that's certainly a mouthful for a heading, and it even contains an
abbreviation! This event was not a presentation, but a platform to exchange
ideas together.

One of the items that were up for discussion was _A Conference Toolkit_, or ACT
for short.  This is the platform used to organize Perl events, such as this
conference and Perl workshops throughout the world. However, ACT is dated.
They enabled HTTPS a short while ago, but it's still not the default because
people don't want to risk breaking the platform. I think this is enough of
an indication that it might be time to make something new to replace it.

And I'm not alone in that sentiment, it seems. However, ACT is big and contains
a lot of data we don't want to lose. It's a massive undertaking to make a new
tool that works at least as well, and allows us to make use of the old data as
well. There is a Trello board available that lists all the features that would
be required to implement, so that's a good start already. I think now it needs
a dedicated product owner with people contributing code, so a start can be
made. This does seem like a touchy subject, since I'm far from the first person
to want this. Many before me have tried and failed already.

As such, I'd propose not making it a Perl centric tool. Make it a modular,
generic event organizing tool. Get a good database design that we can import
our old data into, so nothing is lost, but things can be converted to be more
useful for our current needs. This way, we can work in small steps, and maybe
even reach contributors from outside the regular Perl circles. This might even
bring in new partnerships (or sponsors) towards the Perl community.

Personally, I'd like to see something like this to be written in Perl 6. This
way, it could also be used as a showcase project for the Perl 6 programming
language.

== Writing a Perl 6 Module

Perl 6 has this very neat feature called
https://docs.perl6.org/language/typesystem#index-entry-subset-subset[subsets].
These can be used to make your own types with very little effort, which can
help tremendously to keep your code clean and consise. There are two arguments
I have in favour of subsets that the speaker did note touch upon.

First off, using a subset instead of a `where` clause in a sub or method
signature will bring much better error messages. If you use a `where` in your
signature, and the check fails, you'll get an error that there was no signature
that matched `where { ... }`.

Secondly, if you want to use abstract methods, you can't really use a where.
https://stackoverflow.com/questions/51570655/how-to-use-abstract-multi-methods-containing-a-where[I've
asked a question about this on Stack Overflow], which has the details as to why
this doesn't work the way you might expect.

Next, there's some cool things about operators in Perl 6. There are many of
these available by default, and it's _very_ easy to add new ones yourself as
well. In fact, the `Math::Matrix` module used throughout the presentation makes
some available as well. Thanks to the ease of adding operators in Perl 6, if
you have a `Math::Matrix $m` in Perl 6, you can get the norm by writing `|| $m
||`. This is the mathematically correct way to write this, making it easy to
understand for everyone using matrixes in their daily lives. If you're a
mathematician, small things like these are great to have.

I have some comments on the `Math::Matrix` module itself as well, based on
slides shown in the presentiation. The first thing I noticed is that there's a
`norm` method using a `where` clause when it's not needed:

[source,perl6]
----
method norm (Str $which where * eq 'row-sum')
----

This can be written instead as:

[source,perl6]
----
method norm ('row-sum')
----

This is shorter and clearer, and you'll get better feedback from the compiler
as well. I https://github.com/pierre-vigier/Perl6-Math-Matrix/pull/49[submitted
a pull request on the GitHub repository] in an attempt to improve this, which
got merged as well!

Additionally, the module contains a `gist`, as it should. However, the default
behaviour of `gist` in Pelr 6 limits the number of elements it returns. To work
around this without breaking the expected behaviour of `gist`, a `full` method
was added. I personally think it would be cleaner to instead add a `gist` multi
method that allows `:full` to be set, ie `$m.gist(:full)`. This allows people
to continue to use the `gist` method as expected, and simply add a single
argument to enable the large output, instead of calling a different method
altogether.