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

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Friday January 25, 2008
05:10 AM

C# Kicks Our Ass

[ #35483 ]

When I first started here, our project manager commented to me that when she programs in C#, she can just "click a box on a page" to make the sort of XML changes we often find laborious. Last night, my soon to be erstwhile housemate also commented that when he does C#, he just needs to specify a set of mappings in a config file. Schemas, XML, JSON and anything else he wants just happens. It's magic!

Now I know a lot of people sneer at this "magic" attitude, but those people would be wrong and my project manager and housemate are right. This is such a common problem that it deserves its own abstraction layer. If you're generating XML by hand, you're doing it wrong. If you're using libraries like XML::LibXML, there's still a good chance you're doing it wrong. As an analogy, if you're developing on an MVC codebase, you know your database handles don't belong in your controller or view. They belong in your model. In MVC, XML generators probably don't belong in your controller or model, they belong in your view and you shouldn't have to write them.

Why is it that other languages have had Bermuda-like functionality built-in to their toolsets for years and we don't? Perl doesn't earn many bragging rights here.


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

C# Kicks Our Ass 14 Comments More | Login | Reply /

 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
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.