Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The MicroPHP Manifesto

funkatron.com

Post reply on HN
Print view View original

51–60 of 78 posts

Re: The MicroPHP Manifesto

#51

Post by OstiaAntica »

hullo wrote: post #25
sequoia wrote: post #17

Earlier quoted context omitted.

"I say that, beautiful or not, these two options are the best way to write unmaintainable code that doesn't ever work." I agree that for big jobs, you can't prioritize pretty over featureful, but, respectfully, I think you are overstating your point here: "doesn't ever work." That's simply not true. Have you really never written a working program without a full featured framework? I think one of the points that isn't…

symfony2 (which the OP picks on a little bit) has taken exactly this approach, there's much more emphasis on the components than the framework as a whole.

Even better, other PHP projects, like Drupal, are planning to use Symfony2 components. Symfony2, with its "bundle" concept, holds huge promise for the PHP community and eco-system.

Re: The MicroPHP Manifesto

#52

Post by stesch »

lux wrote: post #9

Amen! I've been railing against this as well for some time (with a minimalist project of my own - elefantcms.com), and wow is there ever resistance in certain parts of the PHP community to ideas like this. Reading "quick" start tutorials like this ( http://packages.zendframework.com/docs/latest/manual/en/zend... ) is just depressing, and it's a big reason why droves of developer continue the exodus to other languages…

PHP itself tries to emulate Java. Should have stopped at PHP4.

Re: The MicroPHP Manifesto

#53

Post by seanp2k2 »

OstiaAntica wrote: post #51
hullo wrote: post #25

Earlier quoted context omitted.

symfony2 (which the OP picks on a little bit) has taken exactly this approach, there's much more emphasis on the components than the framework as a whole.

Even better, other PHP projects, like Drupal, are planning to use Symfony2 components. Symfony2, with its "bundle" concept, holds huge promise for the PHP community and eco-system.

The problem I see with this is that it only has benefits for huge apps. If you're just getting something off the ground, debugging a 100-line stack trace for every little issue starts to kill your flow real fast.

Re: The MicroPHP Manifesto

#54

Post by seanp2k2 »

OstiaAntica wrote: post #51
hullo wrote: post #25

Earlier quoted context omitted.

symfony2 (which the OP picks on a little bit) has taken exactly this approach, there's much more emphasis on the components than the framework as a whole.

Even better, other PHP projects, like Drupal, are planning to use Symfony2 components. Symfony2, with its "bundle" concept, holds huge promise for the PHP community and eco-system.

The problem I see with this is that it only has benefits for huge apps. If you're just getting something off the ground, debugging a 100-line stack trace for every little issue starts to kill your flow real fast.

Re: The MicroPHP Manifesto

#55

Post by lux »

stesch wrote: post #52
lux wrote: post #9

Amen! I've been railing against this as well for some time (with a minimalist project of my own - elefantcms.com), and wow is there ever resistance in certain parts of the PHP community to ideas like this. Reading "quick" start tutorials like this ( http://packages.zendframework.com/docs/latest/manual/en/zend... ) is just depressing, and it's a big reason why droves of developer continue the exodus to other languages…

PHP itself tries to emulate Java. Should have stopped at PHP4.

And badly at that.

Re: The MicroPHP Manifesto

#56

Post by eropple »

enygmadae wrote: post #3

Agreed...this is a breath of fresh air that, imho, the community needs right now. Clear, concise, well-written code can do wonders for a project...don't jump to a framework just because it's the trend.

The assumption that "use a framework" and "clear, concise, well-written code" are incompatible is the problem.

His "punk movement" is more of a "I don't want to use things I have to learn" complaint. I defy any PHP developer to assert that the majority of development is made faster by spending your days bolting together that which already exists.

Re: The MicroPHP Manifesto

#57

Post by OstiaAntica »

sequoia wrote: post #5

I am glad this is being discussed. Due at least in part to the to the fact PHP is constantly trashed (rightly or wrongly) in the "hip programmer" community, there is a lot of defensiveness in the PHP community. I understand why: one can only take so much trash talking especially when much of it is overblown or inaccurate, but it's caused many people to become so touchy that even valid, constructive criticism from com…

Check out Symfony2. The developers adopt some of the best elements of RoR (gems/bundles) and Python (templates) among other things.

Re: The MicroPHP Manifesto

#58

Post by gambler »

jrockway wrote: post #7

Real-world applications are complicated. There are three ways to handle this problem. The first is to not handle the problem. Implement something "simple" that doesn't work in uncommon cases. This seems nice because there isn't much code and there isn't much complexity. But that's because your program doesn't actually work, which is usually considered a bad thing. (This program right here -> "" The second way is to "…

Real-world applications are complicated.

Often, it's because people make them so. Often, it's because people recycle broken solutions instead of really thinking about what they're trying to do. Most code out there solves trivial problems, but is insanely complex. Web frameworks are especially bad at that.

Re: The MicroPHP Manifesto

#59

Post by threedaymonk »

OstiaAntica wrote: post #57
sequoia wrote: post #5

I am glad this is being discussed. Due at least in part to the to the fact PHP is constantly trashed (rightly or wrongly) in the "hip programmer" community, there is a lot of defensiveness in the PHP community. I understand why: one can only take so much trash talking especially when much of it is overblown or inaccurate, but it's caused many people to become so touchy that even valid, constructive criticism from com…

Check out Symfony2. The developers adopt some of the best elements of RoR (gems/bundles) and Python (templates) among other things.

    some of the best elements of RoR (gems/bundles)
I program in Ruby a lot, have done for a long time, and love it, but I've also lost weeks (months?) of my life to fighting gem interdependency problems and watching 'bundle install'. It's almost certainly my least favourite part of the job.

That's not to denigrate the efforts that go into RubyGems, Bundler, etc. - they're doing a good job, and they make life much easier than it would be without them, but in some ways they're playing with a lousy hand for historical reasons that are too late to change now.

I'm largely ignorant of Symfony2, but I hope it's learning from the flaws of the RubyGems ecosystem as well as its strengths.

Re: The MicroPHP Manifesto

#60

Post by jacques_chester »

gambler wrote: post #58
jrockway wrote: post #7

Real-world applications are complicated. There are three ways to handle this problem. The first is to not handle the problem. Implement something "simple" that doesn't work in uncommon cases. This seems nice because there isn't much code and there isn't much complexity. But that's because your program doesn't actually work, which is usually considered a bad thing. (This program right here -> "" The second way is to "…

Real-world applications are complicated. Often, it's because people make them so. Often, it's because people recycle broken solutions instead of really thinking about what they're trying to do. Most code out there solves trivial problems, but is insanely complex. Web frameworks are especially bad at that.

Often, it's because the real world is complex.

"Deliveries are not made on Tuesdays, unless it falls on the 9th day of the month, but not in June for tax purposes in 2013, 2014 and 1998. Our Nowheresville office is excluded from the above rule."

You get rules like this. And there's reasons for most of them. Sometimes very good reasons.

Often, what simplifies a business process on the surface actually doubles (or worse) the underlying code. Because managers don't want you to throw away old data because it doesn't fit the new schema.

The "happy path" is always simple. And it tends to wind up being a fraction of the actual, evolved production code.

Unless you work in large organisations with long-lived systems, this will never be part of your worldview.

Post reply on HN