First off - Puppet is not a build system. It's also not *really* much of a deployment system (though it can be made to be one if you need). It's certainly not an orchestration system, and yes I know about marionette and foreman, and I haven't yet used them, but those aren't puppet so they're out of scope for this comment :)
So...
* Installing your own perl
* It's as easy or difficult as you want to make it. I suggest one of these options:
1. Write a shell script that does it for you and call that using the "exec" resource. Use the "creates" parameter with the directory where you're putting the installed perl. Note that each time perl needs to be installed or upgraded, you're gonna have to wait for it to finish.
2. Create or obtain an RPM or Deb or whatever of the desired Perl that's either relocatable or installs under someplace like /opt or /usr/local and have puppet install that for you with the "package" resource. This is my preference. (see here: http://j.mp/1kqxDCq )
* Static linking a custom-built perl, at least on a RedHat-based system, is just asking for a *world* of pain when you need to install XS-based deps that link against libraries like libnetsnmp or imagemagick or ($deity forbid) Wx!
Per is no harder to distribute than any other piece of software - you just have to package it for the target platform, or provide a simple wrapper script to download/unpack/configure/make/install as you see fit. However, Puppet isn't suited for that kind of "distribution".
Puppet's forte is to take your manifest, a description of what files, packages, and configuration parameters you want on your system, and manipulate the system to make it match what you asked for.
Now, I'm not exactly in love with puppet. It has a *lot* of weaknesses, but if you use it just for its strengths, it's a great, useful tool. Also, learning some ruby to create your own facter plugins and custom resources and functions is invaluable. You'll get a *lot* more out of puppet that way.
1 && q{this statement is true};
, where the stuff in the quotes is usually something random.
For example, at the end of Set::CartesianProduct::Lazy
is the line, 1 && q{a set in time saves nine};
. Date::Extract::Surprise
has q{life without coffee isn't worth living}
and another module ends with q{this is a terrible kludge}
I don't remember exactly why I use the 1 && ...
, but it was either to suppress a warning I would get when using just a bare string there, or perhaps it was to satisfy a Perl::Critic
policy, or maybe it was to satisfy a co-worker who felt the purpose of the bare string was confusing...
The NULL != NULL semantics in SQL make sense to me, except for the name, "null". From a general "meaning of words" standpoint, I think "unknown" would have been a much better name than NULL in SQL. Generally, when I read the word "null" I think of it as referring to something specific, representing the absence of a value. If that were the case, I would think it makes sense for two variables holding "null" to be considered equal.
Thinking about it now, I wonder if that interpretation of "null" would be better named "nil" or even "void", but I'm now going on a tangent...
I wonder if in addition to having "unknown", it would be useful to have a true "null" (or maybe some other name) representing the absence of any value, with the semantics...
Of course, IANALinguist, YMMV. Ovid++ :)
]]>As I mentioned above - the stack-trace from Clojure are near-lovecraftian (at least at Clojure 1.2 they were). They're a pretty good indication that there's some *really* complicated things going on under-the-hood. There's a whole lot of code-generation (not java, bytecode) going on, and that's tricky stuff - but tractable.
And the fact that it's already been done, several times (some folks tell me Scala and Groovy are both fast and dynamic JVM languages), seems to be pretty solid evidence that it could happen again.
Still, like I said on your blog - they have a mountain range to cross for Moe to succeed.
I hope it will!
]]>Overall, I think chromatic's points are very good, and I agree with many of them, especially in the "What Moe Could Produce" section.
But I disagree with one point, in that the JVM has (at least to me) proven that it is an excellent platform for hosting dynamic languages. Well, at least one dynamic language.
Doing it this way allowed for some good comparisons to be made between the languages. For example, the Clojure code, overall, wasn't really any more or less readable than it was in Perl, nor was it much easier or harder to "grok". Changing the language and VM while keeping the same overall design didn't make the product any more scalable, and not a *whole* lot more robust, but one thing stood out for me - it was faster.
a lot faster
And yet, IMO, we didn't lose much at all in the way of flexibility, as the Clojure language, despite being Yet Another Lisp Dialect(tm), is actually quite pleasant to work in. Syntax aside, I felt it had a lot in common with Perl, and found that just about any technique or trick I might want in Perl 5 was either available to me or was unnecessary due to the availability of alternatives. Built-in anonymous lists, arrays, and hashes with a concise syntax to use and define them? Check. (in fact, it's '() [] and {}, respectively, with the contents inside the delimiters). Mutability of atoms, data-structures, and objects? Not by default, but you can make them. Even the "object system" has a lot in common with Perl 5. Introspection of *everything*? Symbol-table hacking galore? All that and much more. A very nice toolchain that automates nearly all the drudgery and headaches? Check. Full compatibility and integration with code written in other languages running on the JVM? Wonderfully done. We even added a macro so that regexes felt more like a built-in feature rather than a library.
Only thing missing is an analogue to the CPAN. And I heard that's being worked on...
Compared to Perl, I might complain that Clojure is completely unsuitable for command-line programs. Of course, that's not what Clojure is currently used for (I love leiningen as a build and dependency tool. I *hate* waiting for it to start up...)
Bottom line, I believe that the JVM can handle just about any dynamic language or language construct you throw at it, it's just not suitable for "scripts".
(unless you keep a persistent JVM instance or use something like drip and even then, that seems to me to be a lot of overhead just for scripting)
Anyhow, while I don't agree that Perl is "dead", both Stevan and chromatic make excellent points in their recent talks and posts, and I heartily support any effort that might produce a usable variant of Perl 5 on another VM. I especially think that targeting the JVM is an excellent choice. I've seen a little Scala code, and I think this may just be what I need to start really learning it. That and the fact that some people at my current $work are beginning to use it. I think Moe is feasible. Whether or not it has a shot will depend partially on the community that forms around it, partially on how good and easy whatever "CPAN" might arise is, and partially on how long it takes to get to "production-ready" status.
But that's a topic for another post, and all I have are opinions with nothing real to back them up, which are the kind I tend to keep to myself.
As an aside, a notable issue with Clojure is the density and near-uselessness of the the stack-traces. Nearly as dense as C++ compiler errors with a dozen nested templates and almost as useless as Python stack traces in a Twisted application. Clojure's exception dumps make Moose's dumps look sane. I suspect this is because of Clojure's dynamic nature combined with the backflips needed to make it all work on the JVM, but regardless, it still works wonderfully.
Since cpanminus, one of the few reasons I still use CPAN.pm at all is to send test reports for dists that unexpectedly fail.
Have you checked with miyagawa on getting this functionality into cpanm? Perhaps as a plugin? (I remember that cpanm was going to support plugins at one point but it looks like those plans were put aside some time ago)
]]>push @array, keys %{$this->{'someobject'}->get_some_hash_ref()};
won't work?
]]>Or it would be totally idiotic :)
]]>I just realized that in my new role as the curator of a fairly large website's data analytics based primarily on Hive, (a SQL-like layer on top of Hadoop), I still need to be watching for potential SQL-injection attacks, even though my systems are several steps insulated from the servers that receive and log this data!
]]>The more examples I see of how to use Marpa, the more I want to use it!
]]>