3 ms·

Magic is to Python as Java is to PHP

9 points by webology 17y ago

swolchok 17y ago
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 17y ago
  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...
- baddox 17y ago
  Yeah, there really needs to be quotes around Magic and Java, because it's talking about MENTIONING those to programmers of Python and PHP respectively.
dougp 17y ago
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 17y ago
  I'm not really sure what you're trying to say here. Are you saying both Java and Ruby require extensive configuration files?
  - maxtilford 17y ago
    I think he's saying that the Ruby community avoids extensive configuration files as a backlash against Java using them.
    - dougp 17y ago
      Yes, thank you.
jrockway 17y ago
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.
teilo 17y ago
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 17y ago
  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.
bobbyi 17y ago
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 17y ago
  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 17y ago
    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 17y ago
      Perl was a little too much. I like ruby a little better than python because I still need some magic in my life.
tvon 17y ago
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.

9 points by webology 17y ago

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 17y ago
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...
baddox 17y ago
Yeah, there really needs to be quotes around Magic and Java, because it's talking about MENTIONING those to programmers of Python and PHP respectively.

dougp 17y ago

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 17y ago
I'm not really sure what you're trying to say here. Are you saying both Java and Ruby require extensive configuration files?
- maxtilford 17y ago
  I think he's saying that the Ruby community avoids extensive configuration files as a backlash against Java using them.
  - dougp 17y ago
    Yes, thank you.

jrockway 17y ago

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.

teilo 17y ago

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 17y ago
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.

bobbyi 17y ago

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 17y ago
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 17y ago
  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 17y ago
    Perl was a little too much. I like ruby a little better than python because I still need some magic in my life.

tvon 17y ago

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.