Re: AW: [PHP] Re: Re: Re: Design Patterns
At 3:09 PM -0500 8/13/09, Shawn McKenzie wrote: Ralph Deffke wrote: for those of u not being a physician semiconductors are of pretty big atoms, but this is not the main problem, the problem is that u have to cut out structures off these semiconductors in order to build faster computers this matters. -snip- My physician had best never mention cutting structures off my semiconductor. -Shawn Me too! I haven't much to spare. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: AW: [PHP] Re: Re: Re: Design Patterns
tedd wrote: At 3:09 PM -0500 8/13/09, Shawn McKenzie wrote: Ralph Deffke wrote: for those of u not being a physician semiconductors are of pretty big atoms, but this is not the main problem, the problem is that u have to cut out structures off these semiconductors in order to build faster computers this matters. -snip- My physician had best never mention cutting structures off my semiconductor. -Shawn Me too! I haven't much to spare. I've got a baby toe that keeps smashing into various floor level obstacles. I don't think it does much other than cause me pain :) Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Re: Re: Design Patterns
Hi Ralph. If u want to understand the Martin's job u need to read about design patterns. A good place to start? Wikipedia ( http://en.wikipedia.org/wiki/Design_Patterns). The use of Design patterns is an advanced programming method. It helps us to improve our object oriented programation. I hope this helps you, Jaime
[PHP] Re: Re: Re: Design Patterns
Thanks Jaime, very nice, but I'm a programmer since 1982 and into OOP since 1988 with the outcome if IBM's C++ compiler on the OS2 platform. Don't u think it could be reasonable to ask if such an overhead IN PHP is necessary? does anybody agree that PHP might be the wrong language to accomplish such a designpattern. Specialy if I find classes about interpreting things. Don't u think to blow up a servers memonry just to have a nice little framework could be ask? Don't u think it makes sence to remember that PHP is just to output a simple text file? Has inbedween all the OOP ability everybody forgotten that this is the simple purpose? Are there anybody who understands that PHP is an INTERPRETING language and has anybody an idear what is the amount of code running to do a simple $something = new object(); versus echo $something Design pattern are very good, standarizing even better. but would u agree that, out of Martins presented work, u can not see the how AND how fast the code is created to output the header the head and body and all other tags. What I can see, the result will be a lot of code, lots of includes for a view bytes. For me, wrong language with unneccesary overhead. as i can see there must be some more folks out there thinking a bit similar, or why is the feetback so relatively poor. and at least u create design pattern for a PURPOSE. so again for what pupose are this overhead in PHP As long as nobody tells me for what benefit this work is done I would say the design pattern should be done in other packages ready made for that with an PHP output. this would not affect any server resources. now after more then 25 years behind the keyboard I got possibly a bit thumb. lets open the discussion. ralph_def...@yahoo.de Jaime Jose Perera Merino jaimejper...@gmail.com wrote in message news:62f65ec80908130320t70078242y65308d2ef0288...@mail.gmail.com... Hi Ralph. If u want to understand the Martin's job u need to read about design patterns. A good place to start? Wikipedia ( http://en.wikipedia.org/wiki/Design_Patterns). The use of Design patterns is an advanced programming method. It helps us to improve our object oriented programation. I hope this helps you, Jaime -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Re: Re: Design Patterns
On Thu, Aug 13, 2009 at 8:09 AM, Ralph Deffke ralph_def...@yahoo.de wrote: Thanks Jaime, very nice, but I'm a programmer since 1982 and into OOP since 1988 with the outcome if IBM's C++ compiler on the OS2 platform. Don't u think it could be reasonable to ask if such an overhead IN PHP is necessary? does anybody agree that PHP might be the wrong language to accomplish such a designpattern. Specialy if I find classes about interpreting things. Don't u think to blow up a servers memonry just to have a nice little framework could be ask? Don't u think it makes sence to remember that PHP is just to output a simple text file? Has inbedween all the OOP ability everybody forgotten that this is the simple purpose? Are there anybody who understands that PHP is an INTERPRETING language and has anybody an idear what is the amount of code running to do a simple $something = new object(); versus echo $something Design pattern are very good, standarizing even better. but would u agree that, out of Martins presented work, u can not see the how AND how fast the code is created to output the header the head and body and all other tags. What I can see, the result will be a lot of code, lots of includes for a view bytes. For me, wrong language with unneccesary overhead. as i can see there must be some more folks out there thinking a bit similar, or why is the feetback so relatively poor. and at least u create design pattern for a PURPOSE. so again for what pupose are this overhead in PHP As long as nobody tells me for what benefit this work is done I would say the design pattern should be done in other packages ready made for that with an PHP output. this would not affect any server resources. now after more then 25 years behind the keyboard I got possibly a bit thumb. lets open the discussion. since the 1980's, another advent has come about, called cheap memory, and fast cpu's. so the answer is no, nobody cares about how many cycles it takes to instantiate a new class in php. for those who do, they can go off and code apps based on sets of global functions or straight proceedural code, as php supports them all. if you're writing an app in todays world of fast cheap hardware, where you're concerned about the number of cycles it takes to instantiate an object being too high; i suppose you should be considering something like C++ for said app. also, it stands to reason that since nobody cares about the object creation overhead, that the very next thing the community will do after getting classes in their language is reach out to design patterns. just as GoF and you did back in the day, w/ the advent of objc/C++ coming out after having lived through years of C. -nathan
Re: [PHP] Re: Re: Re: Design Patterns
Hi Ralph, Sorry, I haven't understand your question. Do you think OOP isn't usefull for PHP? The PHP task is just to output a text file but the process might involve a lot of work: database access, communication with web services, etc. Do you think duplicate code is better than use more memory? What is your proposal? I'm very interested in more opinions. 2009/8/13 Ralph Deffke ralph_def...@yahoo.de Thanks Jaime, very nice, but I'm a programmer since 1982 and into OOP since 1988 with the outcome if IBM's C++ compiler on the OS2 platform. Don't u think it could be reasonable to ask if such an overhead IN PHP is necessary? does anybody agree that PHP might be the wrong language to accomplish such a designpattern. Specialy if I find classes about interpreting things. Don't u think to blow up a servers memonry just to have a nice little framework could be ask? Don't u think it makes sence to remember that PHP is just to output a simple text file? Has inbedween all the OOP ability everybody forgotten that this is the simple purpose? Are there anybody who understands that PHP is an INTERPRETING language and has anybody an idear what is the amount of code running to do a simple $something = new object(); versus echo $something Design pattern are very good, standarizing even better. but would u agree that, out of Martins presented work, u can not see the how AND how fast the code is created to output the header the head and body and all other tags. What I can see, the result will be a lot of code, lots of includes for a view bytes. For me, wrong language with unneccesary overhead. as i can see there must be some more folks out there thinking a bit similar, or why is the feetback so relatively poor. and at least u create design pattern for a PURPOSE. so again for what pupose are this overhead in PHP As long as nobody tells me for what benefit this work is done I would say the design pattern should be done in other packages ready made for that with an PHP output. this would not affect any server resources. now after more then 25 years behind the keyboard I got possibly a bit thumb. lets open the discussion. ralph_def...@yahoo.de Jaime Jose Perera Merino jaimejper...@gmail.com wrote in message news:62f65ec80908130320t70078242y65308d2ef0288...@mail.gmail.com... Hi Ralph. If u want to understand the Martin's job u need to read about design patterns. A good place to start? Wikipedia ( http://en.wikipedia.org/wiki/Design_Patterns). The use of Design patterns is an advanced programming method. It helps us to improve our object oriented programation. I hope this helps you, Jaime -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- Jaime J. Perera Merino Aplicaciones Informáticas. Desarrollo y Formación jaimejper...@gmail.com - 655460979
Re: [PHP] Re: Re: Re: Design Patterns
funny then that I see here serious people discussing the benefit of shortening code and cutting out commends. maby thats a general problem of our society that everybody think higher cheaper faster. this will have a limit guys !!! u can not go smaler then an atom. funny as well that I make my main money in optimizing code to speed and low server resources. Im one of the old guys who can do both hardware and software and I'm telling u this is suspect to me. I still can build a computer from board and powersupply upward. looks like that u joung guys got a little dream implementet by ur profs. Did u know that the industry is complaining that the engeneers coming from the universities are useless for business? a big complain! the real world is different. Hosting companies will always try to keep a server machine as long as they can, because a paid server DOES MAKE MONEY. so where is then the cheap and fast server. how many servers out there still running on PHP4? have u thouhgt about? again, design pattern make sence, but on a companies policy base or on a medium upwards sized project. but there will be more languages be involved in one company it would be much better to use a language independent tool. again this is chasing mice with an elephant ralph_def...@yahoo.de Nathan Nobbe quickshif...@gmail.com wrote in message news:7dd2dc0b0908130809p456de5e7g35641de69af14...@mail.gmail.com... On Thu, Aug 13, 2009 at 8:09 AM, Ralph Deffke ralph_def...@yahoo.de wrote: Thanks Jaime, very nice, but I'm a programmer since 1982 and into OOP since 1988 with the outcome if IBM's C++ compiler on the OS2 platform. Don't u think it could be reasonable to ask if such an overhead IN PHP is necessary? does anybody agree that PHP might be the wrong language to accomplish such a designpattern. Specialy if I find classes about interpreting things. Don't u think to blow up a servers memonry just to have a nice little framework could be ask? Don't u think it makes sence to remember that PHP is just to output a simple text file? Has inbedween all the OOP ability everybody forgotten that this is the simple purpose? Are there anybody who understands that PHP is an INTERPRETING language and has anybody an idear what is the amount of code running to do a simple $something = new object(); versus echo $something Design pattern are very good, standarizing even better. but would u agree that, out of Martins presented work, u can not see the how AND how fast the code is created to output the header the head and body and all other tags. What I can see, the result will be a lot of code, lots of includes for a view bytes. For me, wrong language with unneccesary overhead. as i can see there must be some more folks out there thinking a bit similar, or why is the feetback so relatively poor. and at least u create design pattern for a PURPOSE. so again for what pupose are this overhead in PHP As long as nobody tells me for what benefit this work is done I would say the design pattern should be done in other packages ready made for that with an PHP output. this would not affect any server resources. now after more then 25 years behind the keyboard I got possibly a bit thumb. lets open the discussion. since the 1980's, another advent has come about, called cheap memory, and fast cpu's. so the answer is no, nobody cares about how many cycles it takes to instantiate a new class in php. for those who do, they can go off and code apps based on sets of global functions or straight proceedural code, as php supports them all. if you're writing an app in todays world of fast cheap hardware, where you're concerned about the number of cycles it takes to instantiate an object being too high; i suppose you should be considering something like C++ for said app. also, it stands to reason that since nobody cares about the object creation overhead, that the very next thing the community will do after getting classes in their language is reach out to design patterns. just as GoF and you did back in the day, w/ the advent of objc/C++ coming out after having lived through years of C. -nathan -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Re: Re: Design Patterns
I use a combination of procedural and OOP for my scripts. Mainly because I have a lot of old code I wrote before I understood OOP. Now that I do it makes my life so much easier because of the organizational and reusability benefits. In today's world I will gladly trade a little overhead for fasting coding. At work we have a quad processor IBM server with 4GB of RAM - no speed problems there. At home I use a 1.25GHz Mac Mini and no speed problems there either. Take care, Floyd On Aug 13, 2009, at 11:17 AM, Jaime Jose Perera Merino wrote: Hi Ralph, Sorry, I haven't understand your question. Do you think OOP isn't usefull for PHP? The PHP task is just to output a text file but the process might involve a lot of work: database access, communication with web services, etc. Do you think duplicate code is better than use more memory? What is your proposal? I'm very interested in more opinions. 2009/8/13 Ralph Deffke ralph_def...@yahoo.de Thanks Jaime, very nice, but I'm a programmer since 1982 and into OOP since 1988 with the outcome if IBM's C++ compiler on the OS2 platform. Don't u think it could be reasonable to ask if such an overhead IN PHP is necessary? does anybody agree that PHP might be the wrong language to accomplish such a designpattern. Specialy if I find classes about interpreting things. Don't u think to blow up a servers memonry just to have a nice little framework could be ask? Don't u think it makes sence to remember that PHP is just to output a simple text file? Has inbedween all the OOP ability everybody forgotten that this is the simple purpose? Are there anybody who understands that PHP is an INTERPRETING language and has anybody an idear what is the amount of code running to do a simple $something = new object(); versus echo $something Design pattern are very good, standarizing even better. but would u agree that, out of Martins presented work, u can not see the how AND how fast the code is created to output the header the head and body and all other tags. What I can see, the result will be a lot of code, lots of includes for a view bytes. For me, wrong language with unneccesary overhead. as i can see there must be some more folks out there thinking a bit similar, or why is the feetback so relatively poor. and at least u create design pattern for a PURPOSE. so again for what pupose are this overhead in PHP As long as nobody tells me for what benefit this work is done I would say the design pattern should be done in other packages ready made for that with an PHP output. this would not affect any server resources. now after more then 25 years behind the keyboard I got possibly a bit thumb. lets open the discussion. ralph_def...@yahoo.de Jaime Jose Perera Merino jaimejper...@gmail.com wrote in message news:62f65ec80908130320t70078242y65308d2ef0288...@mail.gmail.com... Hi Ralph. If u want to understand the Martin's job u need to read about design patterns. A good place to start? Wikipedia ( http://en.wikipedia.org/wiki/Design_Patterns). The use of Design patterns is an advanced programming method. It helps us to improve our object oriented programation. I hope this helps you, Jaime -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- Jaime J. Perera Merino Aplicaciones Informáticas. Desarrollo y Formación jaimejper...@gmail.com - 655460979 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Re: Re: Design Patterns
NO NO NO OOP is the best ever inventet ! see my comments on this list, I will also come up with an pure oop opensource OMS very soon. I just think a dam big pattern catalog like this one is like an elephant chacing mice. I mean I can think of customers asking for a documentation of course of the page u created for them calling the next day asking wher the hell are the code for the page are documented in the 1000 pages of documentation u had to give them. I can think of two of my largest customers with their intranet application with 23000 members and more then 5 hits during working hours where I startet sweating while figting for every 1ms. I'm thinking of people with even more hits a day, they even dont start using PHP so I dont know if thats the right way to blow up with includes and thousands of classes. Im complaining on the deepnes and breakdown of the single pattern I miss the orientation on the real problem - outputting marup text cheers ralph_def...@yahoo.de Jaime Jose Perera Merino jaimejper...@gmail.com wrote in message news:62f65ec80908130817x3edc8ffav4153b7c1a44a2...@mail.gmail.com... Hi Ralph, Sorry, I haven't understand your question. Do you think OOP isn't usefull for PHP? The PHP task is just to output a text file but the process might involve a lot of work: database access, communication with web services, etc. Do you think duplicate code is better than use more memory? What is your proposal? I'm very interested in more opinions. 2009/8/13 Ralph Deffke ralph_def...@yahoo.de Thanks Jaime, very nice, but I'm a programmer since 1982 and into OOP since 1988 with the outcome if IBM's C++ compiler on the OS2 platform. Don't u think it could be reasonable to ask if such an overhead IN PHP is necessary? does anybody agree that PHP might be the wrong language to accomplish such a designpattern. Specialy if I find classes about interpreting things. Don't u think to blow up a servers memonry just to have a nice little framework could be ask? Don't u think it makes sence to remember that PHP is just to output a simple text file? Has inbedween all the OOP ability everybody forgotten that this is the simple purpose? Are there anybody who understands that PHP is an INTERPRETING language and has anybody an idear what is the amount of code running to do a simple $something = new object(); versus echo $something Design pattern are very good, standarizing even better. but would u agree that, out of Martins presented work, u can not see the how AND how fast the code is created to output the header the head and body and all other tags. What I can see, the result will be a lot of code, lots of includes for a view bytes. For me, wrong language with unneccesary overhead. as i can see there must be some more folks out there thinking a bit similar, or why is the feetback so relatively poor. and at least u create design pattern for a PURPOSE. so again for what pupose are this overhead in PHP As long as nobody tells me for what benefit this work is done I would say the design pattern should be done in other packages ready made for that with an PHP output. this would not affect any server resources. now after more then 25 years behind the keyboard I got possibly a bit thumb. lets open the discussion. ralph_def...@yahoo.de Jaime Jose Perera Merino jaimejper...@gmail.com wrote in message news:62f65ec80908130320t70078242y65308d2ef0288...@mail.gmail.com... Hi Ralph. If u want to understand the Martin's job u need to read about design patterns. A good place to start? Wikipedia ( http://en.wikipedia.org/wiki/Design_Patterns). The use of Design patterns is an advanced programming method. It helps us to improve our object oriented programation. I hope this helps you, Jaime -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- Jaime J. Perera Merino Aplicaciones Informáticas. Desarrollo y Formación jaimejper...@gmail.com - 655460979 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Re: Re: Design Patterns
Ralph Deffke napsal(a): NO NO NO OOP is the best ever inventet ! see my comments on this list, I will also come up with an pure oop opensource OMS very soon. I just think a dam big pattern catalog like this one is like an elephant chacing mice. I mean I can think of customers asking for a documentation of course of the page u created for them calling the next day asking wher the hell are the code for the page are documented in the 1000 pages of documentation u had to give them. I can think of two of my largest customers with their intranet application with 23000 members and more then 5 hits during working hours where I startet sweating while figting for every 1ms. I'm thinking of people with even more hits a day, they even dont start using PHP so I dont know if thats the right way to blow up with includes and thousands of classes. I deeply and completely agree. Martin -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Re: Re: Design Patterns
Ralph Deffke wrote: funny then that I see here serious people discussing the benefit of shortening code and cutting out commends. maby thats a general problem of our society that everybody think higher cheaper faster. this will have a limit guys !!! u can not go smaler then an atom. funny as well that I make my main money in optimizing code to speed and low server resources. Im one of the old guys who can do both hardware and software and I'm telling u this is suspect to me. I still can build a computer from board and powersupply upward. looks like that u joung guys got a little dream implementet by ur profs. Did u know that the industry is complaining that the engeneers coming from the universities are useless for business? a big complain! the real world is different. Hosting companies will always try to keep a server machine as long as they can, because a paid server DOES MAKE MONEY. so where is then the cheap and fast server. how many servers out there still running on PHP4? have u thouhgt about? again, design pattern make sence, but on a companies policy base or on a medium upwards sized project. but there will be more languages be involved in one company it would be much better to use a language independent tool. again this is chasing mice with an elephant Except for incompetent algorithms, it is almost always cheaper to throw money at a new server than to have a coder micro optimize his/her code. Similarly, it is usually cheaper to throw more hardware at a well programmed solution that uses modern programming concepts than to have a programmer use the most rudimentary of programming techniques to save on cycles. With respect to why you see shortening of code and cutting out comments, perhaps you are referring to the recent Calendar thread, where a bunch of us were just having some good old optimization fun. I for one enjoy the occasional diversion of optimizing some code just for the sake of optimizing it. Sometimes even, the optimization is even the cleanest/most readable solution. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Re: Re: Design Patterns
Martin Zvarík wrote: Ralph Deffke napsal(a): NO NO NO OOP is the best ever inventet ! see my comments on this list, I will also come up with an pure oop opensource OMS very soon. I just think a dam big pattern catalog like this one is like an elephant chacing mice. I mean I can think of customers asking for a documentation of course of the page u created for them calling the next day asking wher the hell are the code for the page are documented in the 1000 pages of documentation u had to give them. I can think of two of my largest customers with their intranet application with 23000 members and more then 5 hits during working hours where I startet sweating while figting for every 1ms. I'm thinking of people with even more hits a day, they even dont start using PHP so I dont know if thats the right way to blow up with includes and thousands of classes. I deeply and completely agree. Yes, certainly optimize on an as-needed basis. But well written PHP code should certainly scale quite well horizontally. Extremely traffic laden websites are quite likely to see a bottleneck at the database before a bottleneck in the code. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Re: Re: Design Patterns
Robert Cummings wrote: Martin Zvarík wrote: Ralph Deffke napsal(a): NO NO NO OOP is the best ever inventet ! see my comments on this list, I will also come up with an pure oop opensource OMS very soon. I just think a dam big pattern catalog like this one is like an elephant chacing mice. I mean I can think of customers asking for a documentation of course of the page u created for them calling the next day asking wher the hell are the code for the page are documented in the 1000 pages of documentation u had to give them. I can think of two of my largest customers with their intranet application with 23000 members and more then 5 hits during working hours where I startet sweating while figting for every 1ms. I'm thinking of people with even more hits a day, they even dont start using PHP so I dont know if thats the right way to blow up with includes and thousands of classes. I deeply and completely agree. Yes, certainly optimize on an as-needed basis. But well written PHP code should certainly scale quite well horizontally. Extremely traffic laden websites are quite likely to see a bottleneck at the database before a bottleneck in the code. Hi, You all should understand that on high traffic sites, C or C++ is far more frequently used and called PHP because they use a whole lot of custom extensions to speed things up. In addition, memcached speeds up database access so much that the speed of PHP starts to matter. This is why PHP 5.3.0 is somewhere around 30% faster than any previous PHP version when running common applications, because the core developers realized that the base efficiency begins to matter and spent considerable effort improving basic language performance. There are a lot of ways to improve PHP's efficiency, and arguing over whether to use design patterns is not a particularly effective one. Profiling early and often to understand the slowest portions of your code is an effective method. There are many, many talks/videos/etc. that can be found via google.com which discuss these principles, but suffice to say that xdebug, APC, and most importantly siege and apache benchmark are your friends in this endeavor. For Ralph: it might help you to know that facebook.com improved their performance by splitting up things into lots and lots of classes, and using autoload. I don't have specific details because I don't work there, but the programmer who coded this solution was telling me the generalities at php|tek 2 years ago. The pages that saw improvement were ones with a large number of possible execution branches in different requests. autoload simply reduced the number of needed files to the bare minimum from a wide variety of choices. This surprised me, because the prevailing opinion at the time was that autoload always reduces performance. The point to take from this story is that what you think to be true doesn't matter, the only thing is really understanding where your bottlenecks are by profiling aggressively, and even more important, why its slow, so you can fix it. Greg -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Re: Re: Design Patterns
but what Im asking is that the reality? go and talk to accountant and tell them after spending soansomuch for the new site hes has to buy a new server ! what will acountant say, what u think. another more important point is in reality u take a project on on a specific hardware base. lets say it a pretty new server fast a mercedes 500 but not a ferrari V1. because of ur great reusable code u do an extra ordinary competitive price bacause u are ready made that fast, u put it on the server and ? womm because of thausand of includes and stuff the customer is not happy with the speed. what u think who is going to pay the new hardware? or better who is going to cut down the code. well its me, because as senior consultant i'm taking over the projects from young programmers who went out of business because the postulations of the closed contract put them bankrupt. THATS THE REALITY so guys tell me on a design pattern frame work what requirements the server should fullfill that I can astimate if the customers situation will not put me out of business? Robert Cummings rob...@interjinn.com wrote in message news:4a84400a.9090...@interjinn.com... Ralph Deffke wrote: funny then that I see here serious people discussing the benefit of shortening code and cutting out commends. maby thats a general problem of our society that everybody think higher cheaper faster. this will have a limit guys !!! u can not go smaler then an atom. funny as well that I make my main money in optimizing code to speed and low server resources. Im one of the old guys who can do both hardware and software and I'm telling u this is suspect to me. I still can build a computer from board and powersupply upward. looks like that u joung guys got a little dream implementet by ur profs. Did u know that the industry is complaining that the engeneers coming from the universities are useless for business? a big complain! the real world is different. Hosting companies will always try to keep a server machine as long as they can, because a paid server DOES MAKE MONEY. so where is then the cheap and fast server. how many servers out there still running on PHP4? have u thouhgt about? again, design pattern make sence, but on a companies policy base or on a medium upwards sized project. but there will be more languages be involved in one company it would be much better to use a language independent tool. again this is chasing mice with an elephant Except for incompetent algorithms, it is almost always cheaper to throw money at a new server than to have a coder micro optimize his/her code. Similarly, it is usually cheaper to throw more hardware at a well programmed solution that uses modern programming concepts than to have a programmer use the most rudimentary of programming techniques to save on cycles. With respect to why you see shortening of code and cutting out comments, perhaps you are referring to the recent Calendar thread, where a bunch of us were just having some good old optimization fun. I for one enjoy the occasional diversion of optimizing some code just for the sake of optimizing it. Sometimes even, the optimization is even the cleanest/most readable solution. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Re: Re: Design Patterns
Greg I completly aggree, but dont miss the point that I'M adigted to OOP
WHY NOT A FRAMEWORK CLOSER TO THE REAL POINT CALLED DOM
design pattern for HTML XHTML XML SVG Database conection and retrieving.
WHY CLASSES FOR CALLERS AND RECEIVERS AND INTERPRETERS.
a div is it a caller? a receiver?
why there a only dom classes? why not forgetting about the tag shit and a
bunch of classes for it?
well wait I will come up with it if I find ever the time and stop learning
from this list.
I also believe that u can force a good design patter by supplying a some
good very well design base classes. I mean talk to an JAVA freak, I dont
think they will come up with that type of framework.
as we just talking about that when can we expect PHP to extend unlimited
classes in one class.
for the newbies following the bullheaded experts fight:
something like this
class wow extents database, users, accessright implements HTML {
}
WHEN
Greg Beaver g...@chiaraquartet.net wrote in message
news:4a84460d.3080...@chiaraquartet.net...
Robert Cummings wrote:
Martin Zvarík wrote:
Ralph Deffke napsal(a):
NO NO NO
OOP is the best ever inventet !
see my comments on this list, I will also come up with an pure oop
opensource OMS very soon.
I just think a dam big pattern catalog like this one is like an
elephant
chacing mice. I mean I can think of customers asking for a
documentation of
course of the page u created for them calling the next day asking
wher the
hell are the code for the page are documented in the 1000 pages of
documentation u had to give them.
I can think of two of my largest customers with their intranet
application
with 23000 members and more then 5 hits during working hours where
I
startet sweating while figting for every 1ms.
I'm thinking of people with even more hits a day, they even dont
start using
PHP
so I dont know if thats the right way to blow up with includes and
thousands of classes.
I deeply and completely agree.
Yes, certainly optimize on an as-needed basis. But well written PHP code
should certainly scale quite well horizontally. Extremely traffic laden
websites are quite likely to see a bottleneck at the database before a
bottleneck in the code.
Hi,
You all should understand that on high traffic sites, C or C++ is far
more frequently used and called PHP because they use a whole lot of
custom extensions to speed things up. In addition, memcached speeds up
database access so much that the speed of PHP starts to matter. This is
why PHP 5.3.0 is somewhere around 30% faster than any previous PHP
version when running common applications, because the core developers
realized that the base efficiency begins to matter and spent
considerable effort improving basic language performance.
There are a lot of ways to improve PHP's efficiency, and arguing over
whether to use design patterns is not a particularly effective one.
Profiling early and often to understand the slowest portions of your
code is an effective method. There are many, many talks/videos/etc.
that can be found via google.com which discuss these principles, but
suffice to say that xdebug, APC, and most importantly siege and apache
benchmark are your friends in this endeavor.
For Ralph: it might help you to know that facebook.com improved their
performance by splitting up things into lots and lots of classes, and
using autoload. I don't have specific details because I don't work
there, but the programmer who coded this solution was telling me the
generalities at php|tek 2 years ago. The pages that saw improvement
were ones with a large number of possible execution branches in
different requests. autoload simply reduced the number of needed files
to the bare minimum from a wide variety of choices.
This surprised me, because the prevailing opinion at the time was that
autoload always reduces performance. The point to take from this story
is that what you think to be true doesn't matter, the only thing is
really understanding where your bottlenecks are by profiling
aggressively, and even more important, why its slow, so you can fix it.
Greg
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: Re: Re: Design Patterns
[snip] u can not go smaler then an atom. [/snip] Neutrons, electrons, gluons, protons particles all smaller than an atom. There are others if you want to get into a discussion of quantum physics and mechanics, but we should probably take that discussion offline. Many folks here are building enterprise capable applications with PHP, its OOP capabilities and the afore mentioned design patterns. This level of application, especially when combined with other technologies (like the bits that make up AJAX), are much better served by using design patterns so that consistency, readability and code-ability are enhanced. You're correct in that the end result is just a text file...but look at the format of that file output! When those files are handled by the proper container, such as a web browser or relational database system they become powerful tools and information. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Re: Re: Design Patterns
Ralph Deffke wrote: but what Im asking is that the reality? go and talk to accountant and tell them after spending soansomuch for the new site hes has to buy a new server ! what will acountant say, what u think. another more important point is in reality u take a project on on a specific hardware base. lets say it a pretty new server fast a mercedes 500 but not a ferrari V1. because of ur great reusable code u do an extra ordinary competitive price bacause u are ready made that fast, u put it on the server and ? womm because of thausand of includes and stuff the customer is not happy with the speed. what u think who is going to pay the new hardware? or better who is going to cut down the code. well its me, because as senior consultant i'm taking over the projects from young programmers who went out of business because the postulations of the closed contract put them bankrupt. THATS THE REALITY so guys tell me on a design pattern frame work what requirements the server should fullfill that I can astimate if the customers situation will not put me out of business? You could do well to read up on accelerators then since they will save you a large portion of the inclusion/compilation overhead. As a senior consultant you should know that. Everything you've mentioned so far is YOUR reality... possibly shared by others, but so far I'm not seeing too many coming in with the same problem. As a matter of my own discipline, I tend towards shallow class hierarchies and lazy loading of libraries. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Re: Re: Design Patterns
At 12:32 PM -0400 8/13/09, Robert Cummings wrote: With respect to why you see shortening of code and cutting out comments, perhaps you are referring to the recent Calendar thread, where a bunch of us were just having some good old optimization fun. I for one enjoy the occasional diversion of optimizing some code just for the sake of optimizing it. Sometimes even, the optimization is even the cleanest/most readable solution. Cheers, Rob. I agree with Rob. I would even venture to say that optimization, such as in our calendar exercise, has nothing to do with the speed of the code but rather the cleanest/most readable solution. One can certainly say This one runs faster but what does that matter when we are dealing with a one time operation that takes milliseconds, or less, to run? The real savings here is seen in maintainability. How well can the next programmer (who might be you) figure out what the code is doing? The time I spend reviewing code is billable. You want to save money, then hire programmers who write clean and easy to understand code. Cryptic crap does not mean that you're a clever programmer, it only shows that you don't know any better. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP] Re: Re: Re: Design Patterns
for those of u not being a physician semiconductors are of pretty big atoms, but this is not the main problem, the problem is that u have to cut out structures off these semiconductors in order to build faster computers this matters. many physicians believe that we are pretty close to a ultimate limit if we dont procees with the *biological* chips we facing a limit soon. the other point is the cost, faster chips wount be any cheaper in the future due to very expencive production processes. So we should start thinking in optimization realy. at least some bewareness it will not be endless ralph_def...@yahoo.de Von: Jay Blanchard jblanch...@pocket.com An: Ralph Deffke ralph_def...@yahoo.de; php-general@lists.php.net Gesendet: Donnerstag, den 13. August 2009, 20:15:31 Uhr Betreff: RE: [PHP] Re: Re: Re: Design Patterns [snip] u can not go smaler then an atom. [/snip] Neutrons, electrons, gluons, protons particles all smaller than an atom. There are others if you want to get into a discussion of quantum physics and mechanics, but we should probably take that discussion offline. Many folks here are building enterprise capable applications with PHP, its OOP capabilities and the afore mentioned design patterns.. This level of application, especially when combined with other technologies (like the bits that make up AJAX), are much better served by using design patterns so that consistency, readability and code-ability are enhanced. You're correct in that the end result is just a text file...but look at the format of that file output! When those files are handled by the proper container, such as a web browser or relational database system they become powerful tools and information.
Re: [PHP] Re: Re: Re: Design Patterns
On Thu, Aug 13, 2009 at 1:00 PM, Ralph Deffke ralph_def...@yahoo.de wrote: for those of u not being a physician semiconductors are of pretty big atoms, but this is not the main problem, the problem is that u have to cut out structures off these semiconductors in order to build faster computers this matters. many physicians believe that we are pretty close to a ultimate limit if we dont procees with the *biological* chips we facing a limit soon. the other point is the cost, faster chips wount be any cheaper in the future due to very expencive production processes. So we should start thinking in optimization realy. at least some bewareness it will not be endless ralph_def...@yahoo.de i for one have decided to start off my next server platform for the web, entirely in assembly ;) -nathan
Re: AW: [PHP] Re: Re: Re: Design Patterns
Ralph Deffke wrote: for those of u not being a physician semiconductors are of pretty big atoms, but this is not the main problem, the problem is that u have to cut out structures off these semiconductors in order to build faster computers this matters. many physicians believe that we are pretty close to a ultimate limit if we dont procees with the *biological* chips we facing a limit soon. the other point is the cost, faster chips wount be any cheaper in the future due to very expencive production processes. So we should start thinking in optimization realy. at least some bewareness it will not be endless ralph_def...@yahoo.de My physician had best never mention cutting structures off my semiconductor. -- Thanks! -Shawn http://www.spidean.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Re: Re: Design Patterns
[snip]. Cryptic crap does not mean that you're a clever programmer, it only shows that you don't know any better. [/snip] I know people like this -- Bastien Cat, the other other white meat -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
