

Magic is to Python as Java is to PHP - webology
http://www.travisswicegood.com/index.php/2009/05/13/magic-is-to-python-as-java-is-to-php

======
swolchok
Am I in the minority in being unable to guess what this article is about from
its title? I thought maybe "Magic" was some new programming language, and I
didn't know that the PHP community (such as it is) hates Java.

~~~
Batsu
Definitely not alone. I read the majority of the article just to find out what
it had to do with PHP at all.

Apparently, in "PHP circles" they don't like object oriented design because
PHP isn't Java. I'll go inform the Zend Framework and PEAR communities that
they're doing it wrong...

------
teilo
Having been living in the Django world for a while now, I knew what the title
was referring to.

I disagree with the author, however. I think that magic is a bad thing, but
this is really an in-house debate. Django and Zope are on the extreme ends of
the spectrum of Magic to non-Magic, and I have worked in both frameworks.

Magic does not necessarily mean "poorly defined" as some people presume. Zope
does an excellent job at defining the magic that it does. I just do not like
the concept of a framework that changes the essential nature of the language
in which it is written.

I think of a framework as a way to avoid writing the 80% of the code that any
given web application needs. One could say, well, that 80% is magic, because
it just happens, but there is a fundamental difference between a framework
that changes the nature of your code, adding behavior that you would never
suspect from the language itself, and a framework that provides functionality
that you either invoke, or add to.

Magic is great for some people, but a real PITA when you don't want the magic
to happen in the way it does. Suddenly you find yourself delving deep in to
the guts of the framework, reverse engineering the decisions made by the
developers, finding workarounds. Suddenly the magic becomes an impediment -
you are now expending much time and effort working through a system whose
entire point was to save you time and effort. The framework is no longer the
elegant helper taking away a lot of work that you would otherwise have to do.
It IS the work you have to do.

Again - this is an in-house debate, and no doubt a die-hard Rails developer
will disagree, as is their right. But for me, I much prefer as little magic as
possible.

~~~
pcc
With reference to Zope: it should be noted that the Zope 2 of old and the
modern Zope 3 are themselves on opposite ends of the magic/non-magic spectrum.

The Zope community learnt many lessons from the magic used in Zope 2, and
radically altered the fundamental patterns for Zope 3 _away_ from magic.

These days people who live in Zope 2 environments (eg Plone) make extensive
use of Zope 3 technologies and patterns via the Five (2+3) bridging mechanism.

Ie, in the Zope world at large, "non-magic" is now considered best practice;
its not fair anymore to consider today's Zope a framework that changes the
essential nature of the language.

Its been interesting to see the initial Rails elation getting tempered later
by grumblings about the pricetag of such magic; the Zope world had gone
through the same thing but a few years earlier. Today's Zope has already
learnt from this and moved on.

In fact the community has even been able to combine some of the philosophies
of Rails (eg avoiding XML sit ups) with the Zope 3 paradigms, to create the
Grok framework which remains wholly Zope 3 compatible. This really has the
potential to strike a good balance.

------
tvon
This is silly.

First off, an IRC channel does not speak for a whole community of users, and
an IRC channel that covers a topic that a subset of a community is interested
in certainly doesn't cover whole community of users. I mean, Python isn't PHP,
it has a lot of uses outside of web development and they don't know or care
about the feelings of the #django and they probably don't know what this
"magic" thing is either.

Even so, nobody in the world should ever say "Wow" to anything anyone ever
does on IRC. It's all happend before, it will all happen again, it's filthy,
it's nasty, it's IRC.

Or to paraphrase a great character:

    
    
        IRC.  You will never find a more wretched hive of scum and villainy.
    
    

At any rate, so far as I can tell the author doesn't know Django very well,
which is fine, I don't know it that well either, but rejecting "simple
solution #1" that requires writing:

    
    
        login_required(some_view)
    

Instead of

    
    
        login_required('some_view')
    

Because you want to specify _all_ your views by module path strings instead of
actually importing one... that's just silly. What is wrong with importing a
view to pass it to a method? Nothing, as a fan of Python for the past ~8
years, nothing is wrong with that, it's simple, it works, do it. If it offends
your sensibilities, well, your sensibilities are silly.

Never mind the "simple solution #2" (in the comments by ez, but someone on IRC
should have thought of it):

    
    
        @login_required
        def limited_object_list(*args, **kwargs):
            return object_list(*args, **kwargs)
    
    

Yes, crazy simple, a tiny, itsy-bitsy wrapper that does exactly what you need
it to do and lets you keep your urls.py looking how you want it to. That would
have been my route (although once you have to write actual view code you might
as well write your own view, after all the generic views are just there to
solve common use cases and they are called "generic" views instead of
"customizable and flexible" views for a reason.. besides, they are easy to
reproduce if you need more complex view logic).

So, instead of the _existing_ , _simple_ and _working_ solutions the author
wants to add a login_required argument to every generic view, instead of just
using the _existing_ , _simple_ and _working_ solutions?

Yeah, that makes sense.

------
bobbyi
Magic often means a minor increase in convenience now in exchange for an
increased risk of a confusing debugging nightmare at an indeterminate point
down the road.

Once you've been burned by it a couple of times, you become very wary.

I think python is somewhat of a refuge for people who have learned the dangers
of magic the hard way and decided it should be avoided when it isn't
necessary.

~~~
teilo
As much as Rails seems to define the Ruby world, I think that we should be
careful to distinguish between the two. Despite its syntactical ambiguity,
Ruby is no more intrinsically magic than Python.

~~~
bobbyi
I didn't want to mention it by name, but I was actually talking about perl.

What originally attracted me to python was that I wanted a non-magical perl.

That may not be such a big factor anymore, but it shaped the language and
culture.

"In the face of ambiguity, refuse the temptation to guess. There should be
one-- and preferably only one --obvious way to do it."

~~~
menloparkbum
Perl was a little too much. I like ruby a little better than python because I
still need some magic in my life.

------
dougp
I would say the big no no in ruby is requiring extensive configuration files.
Which I think is also because of Java and its heavy reliance on XML to set
things up. If the hello world code cant be done on one line then we won't
bother with it.

~~~
cubicle67
I'm not really sure what you're trying to say here. Are you saying both Java
and Ruby require extensive configuration files?

~~~
maxtilford
I think he's saying that the Ruby community avoids extensive configuration
files as a backlash against Java using them.

~~~
dougp
Yes, thank you.

------
jrockway
Decorators to pass an initarg to a class? I don't think so.

This guy wants dependency injection, which would solve his problem, and is as
non-magical as it gets.

