Blessed Teresa of Calcutta, friend of the poor, lover of that Heart which exploded with charity on the Cross, please pray for the repose of the soul of Christopher Hitchens, and for the salvation of us sinners on earth.
Comments with only humor and puns are discouraged here, but if the post you are replying to is so ridiculous that an adjective is yet to be formulated to describe it, I think it's all right.
Jesus Christ, King of Mercy and Justice, teach us how to love the cross and the poor, and to humbly build your Father's kingdom with faith, hope and charity.
O Christ crucified, present in the poor and suffering, save our souls!
O God, fill our hearts with your Divine Grace and open them to the example set by your servant, Mother Teresa of Calcutta. In your fathomless mercy, grant that the souls of Teresa and Christopher might endlessly rejoice together in eternal beatitude, beholding You face to face, without even an image in between.
The ebook/PDF edition is free! It's a great book for learning (modern) Perl basics if you're already familiar with programming concepts and another language like JavaScript (which is where I'm coming from).
Actually, I think the knowledge and best-practices gleaned from the book will help to make me a better programmer in a general sense (not just in terms of the Perl language). It's well written, a pleasure to read and I highly recommend it.
I'm really surprised no one has mentioned Higher Order Perl. It's not just an excellent Perl book - it's an excellent programming book. Even if you don't plan on coding in Perl, HOP may change how you write in Python, etc. Also, the pdf download is free: http://hop.perl.plover.com/
No previous Perl programming-experience. I've been consciously aware of Perl since at least 1998 and even poked at the source code of some scripts here and there, but didn't bother to really learn anything about it until recently.
A brief explanation; perhaps someone here will be inspired or is thinking along similar lines:
I've been using an "object system" for JavaScript named Joose:
http://joose.it/
Joose is amazing and is, roughly speaking, a port of the Moose object system for Perl to JavaScript. (Moose is mentioned in various comments below and many times in the "Modern Perl" book.)
The principal author/maintainer of Joose v3 (Nickolay Platonov) has developed an ecosystem of tools on top of Joose3 and for Joose-oriented distributions (github.com/SamuraiJack). Much of their design is inspired by popular distributions in Perl's CPAN (Nickolay has a strong background in Perl, obviously). And some of them are still tied into Perl libraries, not simply ports to JavaScript.
As node.js and its package manager NPM have evolved rapidly in the last 12 months, some of the Joose stuff is lagging behind and in need of an overhaul, e.g. Nickolay's "JSAN plugin" for Dist::Zilla.
I've been wanting to help, but it's difficult to hack on Perl code if you don't even know the syntax. Well, that's where chromatic's book has come to the rescue! To be honest, it's been a real eye-opener and, as I suggested earlier, I think this Perl learning-experience is actually going to be a big boon for me in the near term and into the future. It's already allowing me to view Joose and related libraries through new eyes.
Not sure if you'd have any thoughts on this matter...
The JavaScript community as a whole (seen especially in the direction of node.js + NPM) is moving away from global namespaces and toward the "module pattern" and dependency injection (note: I had no idea what those terms really meant 6 months ago).
Presently, Joose3 goes against that grain. For example, if in a node.js script you:
require('joose')
if (Joose) { console.log(true) } // prints true!
Basically, the global namespace gets auto-populated with "Joose" and a chain of namespaces below that. This is very Perl/Moose-like, of course.
When you define classes, roles, etc. you get similar behavior:
Joose.Class('MyClass', {...})
if (MyClass) { console.log('effectively stubbed in a global namespace!') }
// does log that text to console, as Joose.Class() behaves that way
And in fact, Joose3 encourages you to embrace that behavior (with `use:` builders and lots of discrete files) to arrive at a network of cross-referenced namespaces which altogether form a library, and API usually.
To go with the flow, and especially to take advantage of emerging module specs like AMD (commonjs thing), a redesigned Joose (i.e. Joose4) needs to eschew global namespaces entirely:
var myJuice = require('joose')
...
// There should be no tie to a "Joose" namespace as such
But how to do that, and elegantly?
Any wisdom from the Perl community in that regard? Maybe someone else has been trying to port Perl stuff to JavaScript/node.js and has found the perfect formalism for translating from global namespaces -> module pattern + dependency injection? Know any Moose wizards that would be willing to help explore this matter?
I haven't written a lot of Joose code, but I use anonymous classes and store their constructors as attributes of a lexically scoped object I inject where I need it, so as to avoid global pollution. So far it works nicely.
Personally, I've found knowing perl useful in some of the same ways that I've found C useful. Perl is still one of the most popular systems scripting languages and perl code always seems to show up somewhere important.
If I were into serious application development I would probably try a project with Clojure before perl, but there are a lot of situations where that might not be desireable (eg you don't want to use the JVM).
As someone who uses and develops open source software, communication via IRC (especially the Freenode network) is an important element of my day-to-day routine.
I'm very happy running weechat in tmux, on a Linux VPS hosted by Rackspace.
I can then connect via ssh to that VPS and tmux/weechat session from multiple machines. For about 2 years I used irssi, but I dumped it for weechat.
It would be interesting to find out if using Hans Montanus's non-canonical formulation of GR (which involves a Euclidean metric and perfectly flat space-time) would yield the same numerical predictions, just with different "book keeping".
That would put a different spin on the notion of Einstein "being right" as I think a lot of folks subconsciously equate GR with the "strangeness" of the Minkowski metric and non-Euclidean space-time manifold.
No, you are incorrect. Slicehost technology is Rackspace Cloud Servers technology. Cloud servers and Slicehost slices are running in the same racks on the same hardware using identical technology stacks -- always have been. The control panel for managing a Rackspace Cloud account and products (including servers) is distinct from the Slicehost customer control panel, and the support teams were distinct groups of people. Now these two corporate structures and logical pools of resources will simply be merged under the name Rackspace Cloud Servers.
Oh, forgot to point out the other big difference. Slicehost had (and still has) a monthly billing model with a monthly bandwidth allowance bundled into the cost. Rackspace Cloud Servers costs are calculated on two factors: how many hours the Cloud Server ran that month (from the day/time you instantiated it); AND then bandwidth usage is calculated separately, based on some $$/GB rate:
So, the real point is that even if this wasn't apparent to you the customer, the substantial differences between Cloud Servers and Slices was branding and different pricing models; the support teams were also separate (and the two front-line support teams have different "styles"). Otherwise, behind the scenes, they're literally the same thing -- in terms of data centers, hardware platforms and hypervisors, etc., etc.
This is what I was looking for in this thread, so thank you.
The email left me concerned of the transition and what it would mean for uptime of websites, but if it's literally just a change of billing, branding, and control panel, why are they waiting months and months to change this? If it doesn't affect my websites' uptimes or IPs, they should just rip off the bandaid now.
Also, CPS is not the only option for dumping callbacks in browsers / node.js. Another would be the Functional Reactive style. See Flapjax: http://www.flapjax-lang.org/
It's got Joose under the hood and I'm generalizing all the library functions for n-ary EventStreams and Behaviors (Reactive concepts). It's very much a work in progress and the test coverage is non-existant atm, but that's owing to the fact I'm working from an existing, working code base. As soon as I have all the core estream and behavior facilities in place, I'm planning to write some exhaustive tests that use JooseX.CPS together with the Joose3 author's Test.Run library: https://github.com/SamuraiJack/test.run
I had not really tinkered with flapjax on the client-side until tonight, but jsfiddle sparked my instincts to really fiddle with something I had been delaying fiddling (or "tinkering") with.
So, thank you, jsfiddle! I think you're going to make for a powerful creativity enhancer. :-D
