Re: Problem with processing XML

On 23 Jan, 12:03, Stefan Behnel <stefan.behnel-n05...@xxxxxx> wrote:

I had a discussion with Java people lately and they were all for Ruby, Groovy
and similar languages, "because they have curly braces and are easy to learn
when you know Java".

My take on that is: Python is easy to learn, full-stop.

Well, that may be so, but it's somewhat beside the point in question.

It's the same for DOM: when you know DOM from (usually) the Java world, having
a DOM-API in Python keeps you from having to learn too many new things. But
when you get your nose kicked into ElementTree, having to learn new things
will actually help you in understanding that what you knew before did not
support your way of thinking.

I'm not disputing the benefits of the ElementTree approach, but one
has to recall that the DOM is probably the most widely used XML API
out there (being the one most client-side developers are using) and
together with the other standards (XPath and so on) isn't as bad as
most people like to make out. Furthermore, I don't think it does
Python much good to have people "acting all Ruby on Rails" and telling
people to throw out everything they ever did in order to suck up the
benefits, regardless of the magnitude of those benefits; it comes
across as saying that "your experience counts for nothing compared to
our superior skills". Not exactly the best way to keep people around.

As I noted in my chronology, the kind of attitude projected by various
people in the Python community at various times (and probably still
perpetuated in the Ruby community) is that stuff originating from the
W3C is bad like, for example, XSLT because "it's like Lisp but all in
XML (yuck!)", and yet for many tasks the most elegant solution is
actually XSLT because it's specifically designed for those very tasks.
Fortunately or unfortunately, XSLT didn't make it into the standard
library and thus isn't provided in a way which may or may not seem
broken but, like the DOM stuff, if the support for standardised/
recognised technologies is perceived as deficient, and given the point
above about glossing over what people themselves bring with them to
solve a particular problem, then people are quite likely to gloss over
Python than hear anyone's sermon about how great Python's other XML
technologies are.

http://www.python.org/about/success/esr/

So, there is a learning curve, but it's much shorter than what you already
invested to learn 'the wrong thing'. It's what people on this list tend to
call their "unlearning curve".

Well, maybe if someone helped the inquirer with his namespace problem
he'd be getting along quite nicely with his "unlearning curve".

Paul
.

Relevant Pages

  • Re: Java -> ActionScript?
    ... Lage sein Java zu verdrängen? ... In Ruby geht das ja, ... Andere Sprachen wie Python oder auch Ruby sind eh ... Die Syntax sollte jedoch das Programm nicht begraben. ...
    (de.comp.lang.java)
  • Re: iniziare a programmare
    ... studiare python o ruby (anche se ora vorrei leggere qualcosa su python, ... javascript(ma quest ultimi non sono utili al fine del post) ... Ruby si accorge immediatamente di cosa intendo quando voglio dire che ... Java è macchinoso. ...
    (it.comp.macintosh)
  • Re: Why Ruby over Python?
    ... Someone there said that Python is more like Java ... and Ruby is more like Smalltalk. ... I have learned many programming languages in the last two years ...
    (comp.lang.ruby)
  • Re: Why Ruby over Python?
    ... >> why you might prefer ruby. ... Someone there said that Python is more like Java ... I have learned many programming languages in the last two years ...
    (comp.lang.ruby)
  • Re: Why would I learn Python over other languages?
    ... >> languages, I also came across a language called Ruby. ... comparing Python to Ruby from those of you who have ... Ruby's documentation of its libraries is much worse. ...
    (comp.lang.python)