summaryrefslogtreecommitdiff
path: root/_posts/2018-08-15-the-perl-conference-in-glasgow.adoc
blob: 6fd8f9053824c5aa01b26050cd8c065132d1e4e8 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
---
date: 2018-08-23
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.

== 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. Therefore,
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, however, the Perl 6 language also offers
a lot of concepts which are very well suited for modern programming.  Sadly, 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 other people, and try to
understand the problem they're facing. Most of them will not be open to using 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.

== 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 performing actions 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

The speaker starts off with detailing the platform which most Perl 6 modules
use to host their code repository, GitHub. He also touched upon automated
testing using Travis and AppVeyor. It was good to show how to make use of
these, as automated testing oftentimes stops unintended bugs from reaching end
users. But, I personally 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 speaker's 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.

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 with 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 Squashathons
footnote:[A Squashathon is like a hackathon, except everyone in the world is
invited, and you can help out over the Internet, staying in your own home. Of
course, you can still meet up with other developers and make it a social
gathering in the real world as well!] 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 concise. There are two arguments
I have in favour of subsets that the speaker did not 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! The speaker was not aware it could be done in this manner, so I'm
proud I got to teach him something right after he did his presentation.

== Winding down

I've had a great time at the Perl conference, spoke to many people with whom
I've had some great discussions. I got to meet and personally thank a number of
people who've helped me out over the past year as well.

A big thank you to all the people who made this conference possible, and I hope
to see you all again in Riga!