Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • My theory is that XML related technologies (XLST, SOAP, etc) are just more popular in projects which are using non-scripting languages (C/C++, C#, Java). There are many reasons why. For example: writing custom parsers in generally harder, cannot use languages itself to specify configuration. These languages are generally just more heavyweight and cannot be quickly adapted for many tasks which we kind of get for granted in scripting languages. So they "outsource" things like configuration, templating and RPC
    --

    Ilya Martynov (http://martynov.org/ [martynov.org])

    • Practically the only time I have to touch XML in Perl is when interfacing with somebody else system.

      True. That's the situation I routinely find myself in. We work with many outside groups and XML is the de facto data interchange format.

      With Bermuda, I would have found this much easier to handle if we had proper introspection. I could write a quick "stub" of a Bermuda island file like this pseudo Perl 6 code:

      print YAML <<"END";
      class: $class
      name: $class.key
      for: iPlayer   # allow different uses for the same class
      elements:
      END

      for $class.HOW.properties('public') -> {
          ne

      • Perhaps while you are waiting for Perl 6, you should look at MooseX::Storage [cpan.org], it doesn't have an XML backend, but thats mostly cause we haven't had the need for it (if you can choose a schema it would be trivial).

        - Stevan

        • That does look very interesting. I had also thought that in later stages of Bermuda, I'd want to have optional Moose hooks. They shouldn't be too hard to add :)

          • Actually it seems that Bermuda is somewhat redundant with MooseX::Storage (ignoring the fact MX::Storage only works with Moose classes for the moment). I wonder if pooling our efforts might not make sense? Interested?

            - Stevan

            • Not just yet. For one thing, I refuse to release this until I feel much more comfortable with the design. I've screwed up with this in the past and I'm not anxious to code myself into a corner. I also am being strongly driven to solve an immediate need at the BBC, so I do need to stay focused on that right now.

  • How much of that is the interface vs the language? I think your giving C# too much credit in and of itself, though in the end the C# developer is more agile because of it your right. Its a loss to Perl that we don't have the interface to do such things (or perhaps other things more worthwhile and fundamental). Not something that a half-baked eclipse setup or emacs mode fixes obviously. The Visual Studio setup is quite powerful for that side of the fence, even if at times they are abstracting users from t
    • I think a lot of it is in the language. Perl has grown up and unfortunately it's still in the clothes it wore as a teenager and they don't fit well. Many of the things the C# and Java communities can do work because the languages have a regular syntax and introspection.

      • Many of the things the C# and Java communities can do work because the languages have a regular syntax and introspection

        Honestly, this is where TIMTOWTDI failed us, it is a double edged sword of flexibility and inconsistency.

        - Stevan

      • Many of the things the C# and Java communities can do work because the languages have a regular syntax and introspection.

        Similarly, many of the things the C# and Java communities have to do (in particular, dependency injection governed by voluminous XML configuration files) is because the languages have other inflexibilities.

        • Oh, I certainly agree with that. Doesn't mean I don't want to steal the shiny bits :)

      • I think the obvious moral equivalent to static introspection in static languages is dynamic programming (open classes, closures, eval) in dynamic languages. Instead of clicking buttons in an IDE that generates code for you, you write code against an API that abstracts away a bunch of metaprogramming. The difference is that you are not limited by your tools in how far and fast you can go because you can always abstract out further from the basis you start with.

        Of course, the flipside is that it’s exp

  • In my opinion, it comes form the corporate backing.

    Even if Microsoft only wrote it for themselves, they'd want great XML support for their own purposes, all the way to the tool level, and we'd get decent stuff anyways.

    XML is the language of business to business conversations, and the foundation of current-buzzword-complient RPC (SOAP) and it underpins the entire industry-driven "Service-Oriented Architecture" business.

    So there's massive focus from those languages on doing XML right.

    Perl has seemed to lack a