# 2016.05.12 DCRUG React.rb

I enjoyed presenting at DCRUG tonight on React.rb, which I've been playing with for the last few weeks. Good turnout too!

Resources:

# 2016.04.10 DCBPW, On Being Small

Welcome to the DC-Baltimore Perl Workshop!

This workshop started innocently enough. The year was 2010 -- October. We were at the Pittsburgh Perl Workshop when Brad Lhotsky said he wanted to host a similar workshop in the DC/Baltimore region. I told him no. But then he talked me and some others into it. During 2011 we worked out some details and at the 2011 Pittsburgh Perl Workshop we announced that the first DCBPW would be held April 14, 2012! We even made fliers!

Here we are six wonderful years later. We've had a few of the organizers step back over the years, mostly due to moving away, but we picked up a few others and have a core of dedicated volunteers that put this workshop together every year. We get support from The Perl Foundation and also get support from local businesses and communities. It has gone pretty well! And yet... sometimes I've felt unhappy.

You see, I started to get fantasies of grandeur.

I imagined a hundred people showing up! Two hundred! Each year this didn't happen I was a little sad. Perl dying? Community dying? What's going on that a region with probably a thousand perl developers only have 50 show up to a really awesome and cheap conference?

And then I realized -- This isn't a conference! It's a workshop.

What we have is a true "workshop". A set of people focused on learning new things, getting introduced to new ideas, and getting some hands-on time. We have organized pre-planned presentations, but we also have a lot of hallway time and variety. Then the second day is completely hands-on time. The signal-to-noise ratio is fantastic -- each attendee gets a chance to learn from their peers both formally and informally.

So yeah. It's small. That's not a bug, it's a feature :)

# 2016.03.05 Arlington RetroRuby 2016

Today I attended http://retroruby.org, a great un-conference in Arlington. I got my toehold in the local Ruby community at the Arlington meetup, and was happy to visit with lots of familiar people. I didn't meet any new people, though that was mostly because it was easy to spend time catching up.

Next time I want to jump in a bit stronger on the new-dev track, maybe walk through some hands-on exercises or do a group activity (Randori).

My favorite, besides talking to people, was the lightning talks. These have a bit more technical depth and include some code getting projected, which I love. I gave a quick this-thing-exists talk on http://reactrb.org.

In the hallway track I also got to preach a bit about Module Level Polyglot :)

# 2016.01.08 Perl 6 is Separate from All, Replacement for None

In response to the "Perl 5 and Perl 6 are mortal enemies" article.

We are definitely framing this whole thing wrong. We have two choices:

• Replacement: Perl 6 is, eventually, the replacement for Perl 5
• Separate: Perl 6 is an unfortunately named but completely separate language from Perl 5

Most people outside of Perl 5 and Perl 6 go with Replacement just by looking at the names. Various insiders switch at random between Replacement and Separate, and I think that is the core mistake. This article has a very important sentence:

"First, a postulate: given the language similarities, the people that will find it easiest to learn Perl 6 are today's Perl 5 developers."

In reality there are SO MANY differences between Perl 5 and Perl 6, it is NOT a good postulate!

This is it -- this is the mistake where we are getting both messages at once, and the rest of the article paints a dark picture of a world (unfortunately most likely the one we live in) in which crossing these messages happens. The mixed message is a net negative for both languages.

I suggest that if you take a random [Perl 5, Ruby, Python, PHP, Javascript, R] programmer, the Perl 5 programmer might actually have MORE trouble than others due to misleading overlap and jarring differences. A developer that uses a lot of Moose might have less issues... or again might end up with the differences shocking rather than enlightening. I actually think the Ruby developer will have the LEAST trouble learning Perl 6, building on tons of overlap (everything is an object!), a shared history (sure, /foo/ is a regex, drop it in. Couple sigils here and there never hurt anybody), and similar culture (TIMTOWTDI is a motto for both). But the Ruby developer won't expect things to be mostly the same between Perl 6 and Ruby, unlike a naive Perl 5 developer.

I recommend you each shape your language to do two things. First stick strongly with Separate, second focus on the Polyglot nature and audience:

Perl 6 is a new and interesting language. It happened to be created by the creator of Perl 5 and an overlapping community, and has an unfortunate name. It is a Practical Research Language, aiming to be both cutting edge and useful. It is of interest to all dynamic-language programmers, and is especially interesting for the polyglot: you'll see familiar bits from Haskell, Perl 5, Ruby, Python, CLOS, ... plus lots of original ideas. Things that you can use, or at the very least learn and take back to your work. You can use Perl 6 now to solve small tasks, and join at the ground floor to build up the ecosystem and culture towards solving larger and larger problems.

One of the cultural things that I think can set Perl 6 apart is in being Module Level Polyglot. From Perl 5 or Ruby you can invoke Python code (both have libraries to support this that I've used) -- but you'd be hard pressed to get that put into production at your work. But NOBODY should ever implement pyplot again! If we can make doing "use matplotlib::pyplot:from<Python>" a socially-acceptable thing in Perl 6, we might be able to convince other communities to do the same... and do something amazing: revolutionize sharing cross-language modules.

Perl 6 isn't the research language for Perl 5. It is a research language for ALL languages to learn from. Perl 6 is the Borg of Languages, pulling in concepts and features to create a glorious monster. Maybe the first assimilated was Perl 5, but it clearly didn't stop there. We need to let go of its roots. Embrace that Perl 6 is Separate from All, Replacement for None.

# 2015.10.18 My First Useful Perl6 Grammar

Tags: Perl6

In my recent talks about perl6, one thing that I keep neglecting is Grammars. Part of that is because I hadn't used them yet!

I was putting together a talk on some clojure code, and was getting mad at my slide software not syntax-highlighting with magical rainbow parenthesis. Clojure being a LISP-like, it lacks some visual clues for structure and is WAY easier to glance at (in my opinion) when parenthesis are highlighted. I have vim doing this for me... but no dice in my slides.

So! Slice up slides, run them through vim, stitch them back together, and presto!

Complete code is at https://github.com/awwaiid/pinpoint-code-color.

I use Pinpoint as my go-to slide software. Simple and easy both to develop a deck and to present it. Each slide is a header and a body done in some Pango markup (more or less simplified HTML). Here is a 3 slide deck:

#!/usr/bin/env pinpoint

# Defaults for all slides
[font=Sans 90]
[duration=50.00]
[fill]

--

Some other slide content.

-- [font=monospace 99] [code=sh]

\#!/bin/sh

\# A lovely cgi application

echo "Content-type: text/html"
echo
echo "Hello, world! Query:"
echo $QUERY_STRING -- [font=monospace 99] [code=python] \# Python WSGI def application(environ, start_response): start_response('200 OK', [('Content-Type', 'text/plain')]) yield 'Hello, world!'  We'll do this in two parts. ### Part 1: The Grammar #!/usr/bin/env perl6 grammar Pinpoint::Grammar { token TOP { <header> <slide>+ } token header { .*? <?before ^^ "--" > } token slide { <slide-header> <slide-content> } token slide-header { ^^ "--" (\s* <slide-setting>)*$$\n } token slide-setting { '[' .+? ']' } token slide-content { .*? <?before ^^ "--" > || .*$ }
};


Using 'grammar' is kinda like some funky cross between a regex and a class. That is -- everything is declared like a named regex, but the result is effectively a class that has a ".parse" method we can use. We're giving the whole grammar a name, and then declaring the file structure in the body.

'TOP' is the start of the parse, which will be an entire file for me. There is one special slide that is the header-slide, and then after that some content slides. Though each bit has a name, you do a lot of things just like other regexes -- so "<slide>+" means one-or-more slides.

After that it just gets broken down further and further. Probably the trickiest bit is the

<?before ^^ "--" >
pattern, which we see a few times. This says that if we see a "--" on the start of it's own line, then we've gone too far. Slide content has the "||" to say if we NEVER find the "--" then we should instead continue to the end of the file.

### Part 2: The Processor

Now that we have a handy dandy grammar, we'll just slurp in whatever file/stdin we are given, parse, and the traverse the parse tree. There is a way to do this with Action objects (another class with methods for each of these tokens), but I didn't do that.

my $match = Pinpoint::Grammar.parse(slurp()); print$match<header>;

for $match<slide>.flat ->$slide {
my $h = ~$slide<slide-header>;
$h ~~ s/\s*$code\=(.*?)$//; print$h;

if ~$slide<slide-header> ~~ /$code\=(.*?)$/ { my$cmd = "code-htmlize $0"; my$filter = shell $cmd, :in, :out;$filter.in.say(~$slide<slide-content>);$filter.in.close;
say $filter.out.slurp-rest; } else { print$slide<slide-content>;
}
}


To make this easy, I print out the bits of the parse tree as I go. the '$h' is a chopped up version of a slide-header, removing my new and magical [code=foo] slide setting. Now that I'm looking at this, I see that I didn't actually traverse into the slide-setting list for each slide... I guess that would be better than the search/replace I'm doing here. A specific thing to note is that "~" is forcing string-context here, so "~$slide<slide-header>" is taking the object for the slide-header node we are on and dumps it out as a string of the content. This makes sense, though I initially found the "~" usage a bit ugly.

Once we get down to a slide that has a "[code=foo]" style setting in the header, instead of printing the slide content like we do otherwise we'll run it through an external shell command. The "code-htmlize" command is some other script I wrote that takes in code and a language and outputs an HTML-colorized version using vim. Here we do the equivalent of Open2, getting a filehandle for the input and output of the external command, printing to it's input, reading from its output.

That's it! A pretty readable thing that parses and traverses my slide software file format, filtering the results as it goes.

More...

META INFORMATION: This is the technical blog and wiki of Brock Wilcox (awwaiid). Entries focus on my current projects, interests, and sometimes life events. If you'd like you can check out the list of All Entries or the RSS Feed. I also have a LiveJournal syndication feed for LJ friends.

2016-05-20

2016-05-10

2016-05-02

2016-05-23

2016-05-22

... more changes