On the language wars

Disclamer: I don’t want to provoke another instance of something I’d be writing about, so I’m going to refer to languages as to meals.

We all like eating. Some of us prefer only one or two kinds of food, but most of us have experiences with many types, yet there are this few ones which we prefer. But more often than I’d like, we yell at each other that our types of food are better, instead of serving our favorite meals with happiness on our faces. Or we insult each other because of the type of food someone else prefers.

Isn’t it sick?

I’m not a professional cook, but I tend to wander there and around in the cooking community. Let me tell you a few stories I experienced in the recent time.

So there’s a cooking convention, and a two cooks are showing some stuff they cooked using Mushrooms. At the beginning, they start to exaplain, why Mushrooms? “Oh you know, we like Mushrooms, and would any of you like to cook these using Pasta? Are you willing to punch yourself in the face after cooking Pasta? And if you enjoy using the cookbooks about Pasta, you must be masochists!”. I’m glad I was watching it recorded rather than live, as I might have looked stupid standing up and leaving the room. But really, this were some serious cooks, why do they yell at other types of food instead of showing why their are nice? Seems not very professional, and shows Mushroom lovers in a bad light.

But the sad thing is, many of them are like this. On the cooking reddit (sometimes written as “cookit”), in every article or news headling about a new meal with Pasta, dozens of Mushroom lovers appear yelling how madly they hate Pasta. Really, comments are filled with this cretinism. They shout at how Pasta is old-fashioned, difficult to eat and how it looks bad. Then why do they need to tell this to everyone, while they see how they keep being downvoted? I asked one of the redditors, why so much hate against Pasta? “It’s not hate, it’s disgust”, he replied. Hey, stupid! No need to spoil somebody else’s taste, why don’t you cook something good with your beloved Mushrooms instead of shouting at how madly you hate Pasta? Sadly, they seem to attack Tomato lovers too, everytime telling everyone how Mushrooms are better for everything and everyone should quit cooking Pasta and Tomatoes and move to Mushrooms instead. I once even saw something horrifying on the Mushrooms mailing list, although I don’t usually read those. There was a quote: “and what defines a Mushroom activist anyway? Blowing up Pasta meals worldwide?” What on earth is wrong with you people?

Luckily, not everyone is like this. I tend to see friendly Mushroom lovers, which sometimes cook Pasta too, although I usually see them on Pasta related IRC channels. Good to know there are good people in this community. Good to know they’re cooperating with us, there are so many wonderful things we can cook together. For example, do you even know the awesome things you can cook with exotic animals, like Parrots?

Now, you may have alredy guessed what kind of food is which language in this story. But there’s a reason I didn’t write a cheatsheet anywhere. It could be related to any of you, probably to me also. Just try to think about from a wider perspective. Hating other people’s food does not make you a better cook. It’s not nice either, when someone jugdes you basing on the type of food you cook, or eat? Shoving your opinions down peoples’ throats is always bad.


So You want to write a Perl 6 module?

As the module database grows bigger and stronger, who wouldn’t like to see his/her work there? Here’s a bunch of notes to get You started. Please note it’s rather a piece of advice, not the standard of any sort. There is no standard about preparing modules, yet when it fullfils the below conventions it’ll have a bigger chance of working everywhere without problems. They’re based on the proto PIONEER document, but remember, there’s no standard. It’s just a convention, You can accept it or ignore it.

To create a Perl 6 module, collect the .pm files and put them all inside the lib/ directory of Your project.

“That’s all?” You’ll ask. “No metainfo files, no dist.ini, no Configure, Makefile, anything?”. No. They’re all optional. The simple lib/ directory is enough for Your module to be easily compiled and installed by a module management tool. From now on, everything is optional. Hell, even lib/ is optional, if You just want to install some executables.

But You’ll usually need more. Tests! Everyone likes tests. You definitely want to ensure that Your module actually works. You don’t? Come on, I know You do.

So here’s another simple thing: just put all the tests in a t/ directory, and they will all be checked before the module is installed. Again, no Makefile or anything is required.

Same goes for executables. If You actually write a complete application, or just want a helper script as a bonus, put it in the bin/ directory and it will also get automagically installed. Easy peasy.

So basically You’ll end up with something like this:

  • README – not going to be installed, but it’s good to have one
  • lib/Acme/Nothing.pm – an actual module to be compiled and installed
  • t/00-basic.t – tests to be run before installation
  • bin/do_nothing – will be compiled, installed and available as a ‘do_nothing’ executable

And You’re done! Go and upload Your new, shiny module to Github and poke one of the proto maintainers to put it on the modules list.

But what if You actually want that Makefile? Of course You can create one, and it will be used by a module installer to ‘make’, ‘make test’ and ‘make install’ Your module. You can also include Configure.pl script (Perl 6 is preffered here), and it will be run before compilation. If You don’t really want to write Your own makefile, that problem is also solved alredy. Ufo will automagically build a perfect Makefile for You, able to compile, test, even install. If You won’t ship any Makefile with Your project, a module installer is likely to generate it with ufo anyway, so it won’t have to do everything by itself.

One last thing. Dependencies. Hell and blessing at the same time. To ensure Your dependencies will be installed before Your module is, add the deps.proto (proto.deps is also used sometimes) file in a toplevel directory, with each required module name in a new line.

So, to sum it up:

  1. Dependencies listed in deps.proto will be installed if they aren’t
  2. Files in lib/ and bin/ will get compiled
  3. Tests in t/ will be run
  4. Everything from lib/ and bin/ will be installed

As a bonus, You can add a logotype/ directory with logo_32x32.png file. On http://modules.perl6.org/ You can see how it will appear in the modules database.

It’s nice to see how the existing modules look like. Math::Model and Yapsi are good examples.

Remember, these aren’t the rules, and there is no standard. It’s just nice to have it simple and not to overcomplicate too much.

That’s all for today. Happy hacking! Fun, fame, and ladies’ hearts await!

Perl 6 – ready enough for me

(Forgive me starting from the nerdy stuff. Give me some time to get comfortable and I may write about something interesting one day)

Rakudo Star, being “useful and usable”, brought not only hapiness and amazement, but also suprisingly many votes of disapproval, even from inside the Perl community. It’s slow, it’s not complete, it’s this and that, blah blah blah. I don’t know what these people were actually expecting, but I’m happy about what the Rakudo team has released. And here’s why.

I’m not a proffesional programmer of any sort (hell, I won’t even go so far to call myself a programmer at all). It’s my passion, not my job, and a die-hard production-ready Perl 6 is not what’s obligatory for me. As Perl 6, I’m also optimized for fun, so as long as I can do funny stuff with it, and I can, I’m glad, happy, dancing around and juggling ananases.

So I’m playing around. Writing modules, like File::Find, toying with module management (see neutro) and messing with other people’s repos. I’m having fun, gaining experience and I believe I’m doing something others will appreciate. What else do I need?


And so I’m blogging again.

Things that are likely to appear in here:

  • Slices of random thoughts
  • Everyday amazements (note: I’m sometimes amazed in a negative way)
  • Nerdy stuff (probably lots of Perl)
  • Things I forget to mention on this list

Things that are not likely to appear:

  • Elaborations on how cruel and sad life is
  • Pictures of cute kittens (that might change)
  • Links to YouTube videos
  • Day-by-day dull content

Hope You’ll have fun.