SitePoint Sponsor

User Tag List

Page 3 of 3 FirstFirst 123
Results 51 to 67 of 67

Thread: PHP Rant

  1. #51
    SitePoint Wizard Dangermouse's Avatar
    Join Date
    Oct 2003
    Posts
    1,024
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Two points:

    a) Youre mostly talking about new coders, bad coding habbits, and sloppy code
    b) PHP != C

    "Right tool for the right job". And hell, if you like C so much, and miss its features, write your projects in C with php extensions. And if you reply that it would take too long, well maybe you could use ..... PHP!

  2. #52
    SitePoint Wizard silver trophy someonewhois's Avatar
    Join Date
    Jan 2002
    Location
    Canada
    Posts
    6,364
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    What? Are you talking to me? I don't miss C's features... PHP has everything C has (sprintf, fprintf, fopen, printf.. with the exception of Windows libraries, but even then it has win32api and win32std... just not full Windows API's and WinInet etc. but that's for widespreadability [is that a word?]), and then some (string tokens, all the libraries for that matter). I can't add types to PHP even if I did code an extension for it.. I can't think of an extension I'd like to write for it (which is why I haven't)

  3. #53
    FreeBSD The Power to Serve silver trophy pippo's Avatar
    Join Date
    Jul 2001
    Location
    Italy
    Posts
    4,514
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selatos
    Andrew, in my C++ book that I have here, the author says that although widely used, that form of naming convention is being abandoned because you have a type already, no need to reinforce it for your own benefit. Its much better to give them a meaningful name without the type included as a prefix or postfix.
    Maybe this ?
    http://www.amazon.com/exec/obidos/tg...64932?v=glance

  4. #54
    SitePoint Zealot
    Join Date
    Aug 2003
    Location
    MN
    Posts
    178
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by someonewhois
    There's nothing wrong with doing queries in a loop? Ermmm... if that's the way you have to do it, you should change what your script does. Having more than 10 queries on a page (admin doesn't count, do whatever you want in there..), then you need to consider redoing your site... okay, 15-20 is accessible, but to have a dynamic count (ie. the more categories you have the more queries) is just plain idiocy. If you do that, your server will die. Rewrite your code.
    Yes, for pages that are accessed hundreds or thousands of times a day, then you should probably use caching. Note though, that PHP is not only used "on the web" I have plenty of scripts running at cron that are not written in PERL because I wanted to use my PHP libraries... These scripts often use queries in a loop because that is the MOST efficient thing to do. Just because your programming endeavors have not yet taken you to a place where you would need them, does not mean it is bad.

  5. #55
    Afraid I can't do that Dave Hal9k's Avatar
    Join Date
    Mar 2004
    Location
    East Anglia, England.
    Posts
    640
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Kev's PHP book doesn't contain much (if any?) things about functions, classes, etc... If we didn't make mistakes, we wouldn't be human. PHP is really designed exactly to include the purpose of allowing newbies to make quick interactive sites, that's its problem.

    If you choose one of those "hundreds of php books" the chances are that it will have a little "to make dynamic websites" and the like appended onto the end of the title. A lot of newbies don't head towards the learning php properly books, they want to focus on exactly what they will need. For instance, I picked up a c++ book and from the outset it made newbies grasp concepts like functions before moving onto actual code. Whereas task-based books would aim to give newbies workable code from the start.

    I think being able to make errors is a good thing. Sure some people wont code again in their life, but for people who have decided that they want to live by the programmer-ethic writing sloppy code is an important process to go through.

    I'm no php guru, but I remember the days when I was writing sloppy html code full of tables to structure design, it quickly became hell updating things. Now I use CSS(p) and HTML and everything conforms to W3C, I learnt from my mistakes. No doubt I would learn from having a sql injection too.

    What's this? DROP doing there? Nooo!

  6. #56
    SitePoint Evangelist Ian R. Gordon's Avatar
    Join Date
    Feb 2004
    Location
    New York
    Posts
    474
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think it is important to remember where PHP started. PHP wasn't originally created to do all these fancy things (by original I mean PHP/FI. PHP/FI was created by Rasmus Lerdorf in 1995, initially as a simple set of Perl scripts for tracking accesses to his online resume.)

    Gradually it evolved, however because it evolved from many different developers, I am sure each had their own ideas on how to name functions and creation of other features and such. However, I think the point is that PHP is FREE, its goal was create something that the community could freely use to make and build applications and accomplish tasks. It does that. If however, you feel PHP is in someone deminished because of this, I say you create your own programming language, then you can follow a set of rigid guidelines, program "properly" follow rules like some artistocrat. PHP is for the common folk, they will do with it as they will and they will program as they will, you don't like it...tough, suck it up and move on.
    Ian Gordon
    CSS / XHTML / PHP Programmer
    http://www.iangordon.us

  7. #57
    Free your mind Toly's Avatar
    Join Date
    Sep 2001
    Location
    Panama
    Posts
    2,182
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by someonewhois
    On my MSN list I have about 15 people who know PHP. Of that, my friend Gaheris (familiar name amongst PHP'ers?) is the only one that I feel is qualified enough for professional PHP.
    If I'm not mistaken, Gaheris wasn't into OOP when he started posting on this forum.
    Community Guidelines | Community FAQ

    "He that is kind is free, though he is a slave;
    he that is evil is a slave, though he be a king." - St. Augustine

  8. #58
    SitePoint Zealot bronze trophy
    Join Date
    Jun 2004
    Location
    Stockholm, Sweden
    Posts
    148
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    "It's all in how you code..."

    I do agree with much of what the original post said. A lot people write terrible, terrible code in PHP. It's not really something that's PHP's fault however.

    I started out with PHP by buying a book, called Easy Guide to PHP4 (free translation from Swedish), and it had terrible coding practices. It relied on register_globals being on (which really did my nut in until I found out what it was) and promoted sloppy coding.
    Does it come as a surprise that people write sloppy code if they are taught to write sloppy code?

    Is it PHP's fault, inherently, that people write sloppy code?
    I would say no. PHP exhibits a lot of the "There's more than one way to do it" traits of Perl, and I for one feels that all of those ways have their strengths and should be used when applicable.

    I say instead of advocating a change of PHP, advocate a change of PHP coders. Even C, which is quite strongly typed and has a rigid syntax, allows for sloppy coding, if the programmer is so inclined.
    If there is a way to overcome the suffering, there is no need to worry; if there is no way to overcome the suffering, there is no point to worry.
    - Shantideva

  9. #59
    SitePoint Wizard silver trophy someonewhois's Avatar
    Join Date
    Jan 2002
    Location
    Canada
    Posts
    6,364
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Toly
    If I'm not mistaken, Gaheris wasn't into OOP when he started posting on this forum.
    I'm pretty sure he was? He's always been hardcore for DaO's and what not. I know he's into OOP now. He wanted to use WACT etc. when we were developing something for fun... I managed to convince him not to bother.
    Edit: http://www.sitepoint.com/forums/showthread.php?t=153827 Managed to give an example here.
    And (my favourite): http://www.sitepoint.com/forums/showthread.php?t=155716

    Anyway, I think it's PHP's fault that it's so easy to code poorly. Meh. Just my perspective.

  10. #60
    Free your mind Toly's Avatar
    Join Date
    Sep 2001
    Location
    Panama
    Posts
    2,182
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by someonewhois
    I'm pretty sure he was?
    I think he wasn't or just started to get into it.

    But anyways, my point is that it is usually a transition for some people to migrate from procedual coding to OOP. It is much easier to start with procedual, especially if you haven't programmed before, and then move to OOP. There's no need to start shooting people if they don't do it, though.
    Community Guidelines | Community FAQ

    "He that is kind is free, though he is a slave;
    he that is evil is a slave, though he be a king." - St. Augustine

  11. #61
    SitePoint Wizard silver trophy someonewhois's Avatar
    Join Date
    Jan 2002
    Location
    Canada
    Posts
    6,364
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    While that's true, I was more directing at people who continuously write procedural applications. Like, sure, your first app is going to be pretty nasty - I'm fine with that. Everyone's like that. But by the time you're writing your 10th project/application, I think you should start trying to clean your code up, no?

  12. #62
    Free your mind Toly's Avatar
    Join Date
    Sep 2001
    Location
    Panama
    Posts
    2,182
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by someonewhois
    But by the time you're writing your 10th project/application, I think you should start trying to clean your code up, no?
    Yep, agree.
    Community Guidelines | Community FAQ

    "He that is kind is free, though he is a slave;
    he that is evil is a slave, though he be a king." - St. Augustine

  13. #63
    if($awake){code();} PHP John's Avatar
    Join Date
    Jul 2002
    Location
    Along the Wasatch Fault line.
    Posts
    1,771
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    OOOooooofff! There's a blow to the gut! :wink:

    I'm in the process now of trying to wrap my head around OOP, and wanting answers to questions about things in OOP that I know nothing about...

    ('There is no sPOOn...')

    I've got procedural stuffed so far up inside, it's difficult to root out and re-write.
    John

  14. #64
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    I couldn't be bothered to read the whole thread, but hey...it's a troll.

    Quote Originally Posted by someonewhois
    Okay, if you don't like listening to rants, or you feel I'm wrong, you can close this thread now
    I love rants, but only when the ranter is prepared to become more sophisticated in light of the responses. game?

    Quote Originally Posted by someonewhois
    I'd also reccomend knowing C before reading, or you might be utterly lost in what I'm saying.
    Ok, I'm OK on that one...

    Quote Originally Posted by someonewhois
    1. Proper type definitions
    Honestly, is it so hard to implement types? It's a LOT smarter.
    The smartest thing you can have is clean clear code. Type errors are rarely that hard to track down, especially with fine grain testing and only apply to primitive types anyway. The real sods are design errors and subtle deviations from the business domain.

    Type declarations involve clutter. Also C has a lousy type system as you have to drop down to void * to get polymorphsm. In C++ you expose types in methods taht don't need to know them simply so that you can declare temporary variables to pass them around. This leads to all sorts of more complex inventions such as Templates (now in Java too). This complexity leads to more bugs, not less.

    If you want to avoid errors, then have short methods, do unit tests and keep the code clear enough so that a colleague can read it too. The first and last of these are damaged by excessive type declaration. Declarations that further restrain you once you start refactoring, hence the popularity of the up and coming languages like Python, Ruby and...PHP.

    Anyway, we use polymorphism to deliberately avoid type constraints.

    Quote Originally Posted by someonewhois
    The fact that C is strict is a deterent to people - that's a GOOD thing though (see furthur down)
    char string[15][200];
    Uh? How much C coding have you done? One of the characteristics of large C programs is the type cracking macros, explicitely there to do the necessary type conversions. Preprocessor errors are no easier to track down than other type errors, harder if you are compiling different modules at different stages. A real laugh when your .dll or .so is out of date.

    I am so glad to be rid of all of that mess.

    C++ introduced classes as a means of introducing a controlled type system (hence why types and classes are the same). This is very restricting. Roll on template meta programming .

    Quote Originally Posted by someonewhois
    Where are the days where you had to preallocate your arrays, your strings, everything? The days where if you screwed up your allocations, your program crashed and you screwed your computer up. Instead, your proogram runs flawlessly, and your memory justt gets overwritten and nothing crashes - wonderful.
    I don't know what sort of programming language you are using, but allocated memory won't get overwritten in a dynamic langauge unless there is a langauge bug (a C problem). It will get overwritten in C. In fact buffer overrun security errors are almost all due to out of date bug prone C libraries where arrays were bounded, but unchecked.

    Quote Originally Posted by someonewhois
    I'm all for a string type, that's fine, but honestly, unlimited unallocated arrays?
    The real world contains plenty of instances where the correct formalism is a list with an unknown size. The Y2K problem is caused by imposing arbitrary limits as you would be forced to do.

    Quote Originally Posted by someonewhois
    We shouldn't be relying on an engine that figures types out for us. Wouldn't it be quicker if it didn't have to figure it out?
    I don't trust myself to do these calculations in my head. The machine is better at this.

    Quote Originally Posted by someonewhois
    2. Way too simple
    The fact that PHP is way too simple is considered a plus by most - I consider it a minus.
    Cough...

    Quote Originally Posted by someonewhois
    it's too easy to make your code sloppy.
    You can write code that is sloppy in any language and people have to start somewhere. The trouble is you are focused on low level coding errors. You are missing the wood for the trees.

    Coding errors can be fixed fairly easily and will be learned from in that fixing. You go through this in every langauge, although it's nice to do it in C or assembler so as to gain an understanding of the machine as you go.

    Programming is not software development. As a professional developer you write your code for people to communicate your design or just the plain business logic. Elegance and clarity count for everything in this process. If you can come up with clear designs you will shine a light on your coding errors. If you write shorter code, you will right less of them anyway.

    A seasoned developer writes one bug every 40 lines (with ad hoc. testing). This is independent of the programming language.

    Quote Originally Posted by someonewhois
    Ooooh, our table has 500 entries? That's okay! 500 queries doesn't matter, it's on our server, who cares?
    The error is readily apparent in PHP and so easily fixed (once you know you have aproblem). If you don't have a problem, then it's not an error. Place a long network call in that loop and it's actually good code, as you would be pushing the data out more quickly and so reducing the chances of transaction failures in other code.

    You can write that error in plenty of other languages. I would write it in C, but I cannot be bothered. It is a staggering 40 lines of code in that language.

    Quote Originally Posted by someonewhois
    Although your server may be more powerful than a client, it has feelings too. People who code (who don't know a client side language) generally forget about computer resources quite quickly. They lose all care, everything turns brutely inefficient, and nobody speaks of it again.
    It's an ROI calculation. If you actually measure the cost of developer time (you haven't have you - I can tell) you will find it swamps the costr of servers. Do it now and then show me your calculation. I would be happy to explain.

    Otherwise you have looked blindly at one side of the see-saw. You are coding by fear, fear of poor performance that you have never actually measured. Your fellow developers will suffer.

    Quote Originally Posted by someonewhois
    The sad thing is people develop like this professionally. A lot of PHP developers are hacks, and it's sad. The people who actually know how to develop PHP properly, and who actually care about the server, about the resources it uses are the people that should be coding it. Everybody else should pack up their bags and leave.
    It's all relative. Give me three things wrong with this...
    PHP Code:
    class Subscriber {
        function 
    setUsername() { ... }
        function 
    setPassword() { ... }
        function 
    login() { ... }

    Quote Originally Posted by someonewhois
    PHP is made so anyone can learn it, and it ends up that people don't learn it properly.
    It's a tool. People make a chair with screws and a drill. People can make perfect dovetails. Are the dovetail experts any better at making things to sit on? No. in this case you get aesthetics at the expense of difficulty of repair. It's a trade-off. there are plenty of businesses running on hacky code right now. Is it better to hack them and refactor, or to never get them up in the first place?

    Quote Originally Posted by someonewhois
    Then on the submit page:
    foreach($_POST['delete'] AS $key=>$value)
    {
    mysql_query('DELETE FROM messages WHERE id='.$key.'');
    }
    Security problems are resolved with code inspection and antagonistic testing. It doesn't take much of either to resolve this issue. I have also seen it done in JSP. The servlet does not have a telepathy module that can tell if it's nicely types variables are going to be fed directly into a DB.

    Quote Originally Posted by someonewhois
    Yet nobody does either of these 3
    I think you are insulting a very large number of developers out there. Also your reason one is bonkers. It would clutter the code needlessly and it may be a legitimate query. I wouldn't like to use an object that mysteriously refused to work beyond a certain number of entries.

    Security issues like this are not resolved by looking at database issues. They are completely separate layers of an app. It is worrying that you confuse them in your example, or if you are not then it is too highly contrived. You have no case without a decent example.

    Quote Originally Posted by someonewhois
    It's too easy to bedroom DoS a PHP script, because of people doing this.
    I wouldn't be defending against a DOS attack by twiddling with database level code. You usually need special defenses built into routers or gateway servers anyway, to properly safeguard against this threat. The problem you are describing doesn't remotely tie up with your code example.

    Quote Originally Posted by someonewhois
    People who don't want to use functions (for real applications that is)... What are they thinking? Copying and pasting is just easier? These people need t'o be shot.
    If it solves their problem and have no time to learn a better way then they have reached a local efficiency. It's either right for them, or they have insufficient experience doing things the other way. A few people are bloody minded, but I refuse to shoot people for lack of experience.

    As for being bloody minded, isn't that pretty close to ranting...

    Quote Originally Posted by someonewhois
    It's crazy how stupid a lot of people are, who just don't want to learn to use functions/OOP and just write strictly procedural code. It's the stupidest thing alive.
    OO is an extremely difficult subject. It's even harder in C. Remember C? I needed it for your examples, right? OO takes a real degree of mentoring and communication with other more expert developers. It took the OO community ten years to favour aggregation over inheritance. What chance do you have of travelling this road alone. For occasional developers I would never recommend OO.

    So are expertise in functional programming, logic programming and relational modelling also necessary to avoid the monicker "stupid".

    Quote Originally Posted by someonewhois
    If your index.php doesn't look something like this:
    require('classes/internal/mysql.php');
    require('classes/output/skin.php');
    require('classes/process/main.php');
    $m = new Main;
    $m->GetBlogEntries();
    $m->skin->Output;
    Eric Evans (of Domain Driven Design fame and co-author with Martin Fowler of several OO research papers) wrote a little wiki in PHP. Track it down and take a look. You are in for a shock.

    Quote Originally Posted by someonewhois
    It's hilarious to see 50 files in the main directory. People need to split their files up, split their classes up, use proper conventions, and actually use PHP like it's supposed to be
    We have 97. We also have some 50+ years experience spread among our four developers (three of which know C). Only categorise files if you need to. Greek classification is a card you can only play once, so you have to have a very exact technical requirement to do so.

    Quote Originally Posted by someonewhois
    2. Have a class that you initialize once at the top of your script, and use it throughout. You should just stop programming in any langauge.
    That's going to make the AbstractFactory (GOF) pattern rather tricky. The Aggregate pattern (Evans again) works from this too. In fact making any code flexible is going to be hard, because the alternative is to create all of these little instances with the new keyword. That exposes lot's of class names. That in turn will cripple polymorphism when it comes to construction. As construction happens a lot in PHP (more so that an app. server) this is going to be a crippling issue.

    I assume ou are ranting against something else (I hope so), but you have either explained this so badly or are very confused. What you have actually written is flat out wrong.

    Quote Originally Posted by someonewhois
    Objects are just like functions - they have 1 purpose
    A class can have multiple roles if it's job is to aggregate such roles. And multiple steriotypes too. The rule is flexibility. However, it's implementation should have only one role, using aggregation for the other mechanisms. See Roles, Resonsibilities and Collaborations by Rebecca Wirfs-Brock for in depth discussion of this. There are also lot's of exceptions to this and you have to bear in mind YAGNI, how well it represents the business domain and the fact that it might be mid-refactor.

    It's all rather complicated.

    Quote Originally Posted by someonewhois
    $DB = new MySQL($server, $user, $pass, $db);
    $DB->query('SELECT * FROM argh');
    .. different file ..
    $DB->query('SELECT * FROM otherargh');
    If the $DB was passed to a function there is no problem.

    Quote Originally Posted by someonewhois
    mind you, OOP doesn't make perfect sense in my mind anyway (for PHP)
    I'd like to disagree with this, but in it's literal form I cannot currently justify it. A fully OO app. is certainly possible in PHP, and actually highly desireable beyond a certain complexity.

    Quote Originally Posted by someonewhois
    ... You generally spawn new instances like you do new threads.
    I think you may have completely lost it at this point .

    Quote Originally Posted by someonewhois
    PHP on the other hand isn't live runtime, it's "execute once and display",
    This is wrong both ways. The PHP script can respond to the browser cancel button. In addition you can stream the page, with appropriate page headers. This means that you can have a two frame display where entering data in one frame and submitting will update the other. OK, this is an obscure point, but streaming slow pages is valid.

    The real problem is that there is a lot of software out there that is just as event driven. There are also plenty of batch programs and command line programs that behave the same way.

    Quote Originally Posted by someonewhois
    meaning spawning classes isn't that beneficial (you would spawn a class on user input generally, but in PHP's case once you get user input you spawn a new page).
    You don't spawn classes, you instantiate objects. They pretty much the same amount of machine real estate as the data inside them. Creating hashes is just the same process. You arguments in no way distinguish any advantage for or against OO.

    Also if you want to cache data then use shared memory or tools like Prevaylor.

    Quote Originally Posted by someonewhois
    You never have to pass, 1 query per instance. That's how internal class variables were meant to be used, not as a variable that gets changed every time you call it.
    You have managed to choose the very example that works in both procedural and OO code. You are trying to distinguish this...
    Code:
    thing.doStuff();   // C++
    ...and...
    Code:
    (thing->do_stuff)(thing);   // C
    ...or even...
    Code:
    thing_do_stuff(thing);   // Simpler C without polymorphism
    They are equivalent and that's how you make C object based (thing would be a struct pointer that contained other function pointers). The advantage of OO (how it is supposed to be used) is that it makes polymorphism and inheritance more natural within the language, and encapsulation possible.

    That's how they are supposed to be used.

    Quote Originally Posted by someonewhois
    "I don't use single quotes as doubles are easier.. it's a marginal speed difference". I say "What if you had 10 million people on your site?" and they go "I don't expect that" - so?! Yikes, considering it's so easy to use single quotes (despite preferenace), why would you use double quotes and why would you take away from the ability to write scalable code?
    I really think you should post a rant only after you have actually carried out a few experiments. Your thinking is so completely off base it's in amateur land, which given you were so harsh as to shoot ignorant people earlier I think I am allowed a certain harshness now. You are talking about load, which is a simple ROI calculation. Response time is dictated by browser rendering and network latencies, and are a different issue.

    1) Quoting issues are microscopic in percentage terms within a script. It takes a really contrived benchmark to even detect them.
    2) The page parsing time will swamp the execution time of a simple script. There are a lot of dumbass measurements out there that forgot to time this.
    3) Even a single DB query will swamp the execution time.
    4) A single network call will swamp the localhost DB call.
    5) If your server is not maxed out allof this is irrelevant because you have CPU to spare.

    Now the tricky bit. A developer costs about $50 an hour (for me anyway), but I'll go with your estimate of $5 plus $5 for office space. Let's say it takes a developer three hours to convert all the scripts to remove those double quotes and another hour to write it into a coding standard. Every new developer must read this as well as continually implement it, say once a year at 5$. That's $40 worse case (more like $200+) plus 5$ per year.

    You save 0.1msec per script (unlikely as most of these calls are microseconds) assuming every script has some. Each script takes about 50msec to run (without the DB calls) so that's a saving of a fifth of a percent of the script time. If you measure your server loads you will typically find about 15% load is Apache and about 60% DB if everything is on one server. So only a quarter is PHP, so we are at 1/20%. A server typically costs $1000 per month for a reasonable one, giving a saving of 50 cents per month, or $6 per year. That's 40 years to pay back your investment with the absolutely best possible calculation.

    It's even worse given that the same development time could have been spent adding business value. Software depreciation is typically measured in months, so you will have actually have cost your company money by your "optimisation".

    You might want to load your gun now.

    Quote Originally Posted by someonewhois
    I doubt very many people could write code that solid.
    Yahoo can. Wonder what they use...

    Quote Originally Posted by someonewhois
    It's so much easier and smarter to just get it right the first time.
    Yes, but you are confusing scalability with script execution time. Scaability is built around flexibility. Real performance gains are got from caching, lazy execution, code generation and comilation (precalculation), system component changes and algorithm changes. In other words, big chunks of stuff that have to be plugged in and out just so that they can be measured.

    Scalability is built from flexibility.

    Quote Originally Posted by someonewhois
    I don't even think anyone can come close to arguing with this last point. If you argue that writing scalable code is bad, then you my friend should blow up your modem and never buy a new one.
    I doubt you went to a great deal of trouble to upgrade your modem with the latest drivers everytime they come out. Why? Because you would be lucky to get a few percent improvement. Change the modem to a cable one and you get 1000% improvement. That's the benefit of modular software my friend. If you optimise on the micro scale, you will lose the performance gains that can be had from the macro scale (thanks to Jeff Moore for this witicism).

    Quote Originally Posted by someonewhois
    I wish people explained things a bit better, but I guess that's just a pet peeve about boards like these...
    But your own post has been seriously short of depth. It's all degrees. Frankly I am always pleased that anybody is trying to help. We were all beginners once and your post was not a rant against PHP (I wish it was), but a rant against programmers making an effort to become better.

    It's very rare that I find a long post where I disagree with every single point in the post! Amazing.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  15. #65
    SitePoint Wizard silver trophy someonewhois's Avatar
    Join Date
    Jan 2002
    Location
    Canada
    Posts
    6,364
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Oo, nice long post.

    Uh? How much C coding have you done? One of the characteristics of large C programs is the type cracking macros, explicitely there to do the necessary type conversions. Preprocessor errors are no easier to track down than other type errors, harder if you are compiling different modules at different stages. A real laugh when your .dll or .so is out of date.

    I am so glad to be rid of all of that mess.

    C++ introduced classes as a means of introducing a controlled type system (hence why types and classes are the same). This is very restricting. Roll on template meta programming .
    Preprocessing has nothing to do it with it, from what I can see - if you look at the post-processed pre-processed (if that makes sense) code, that's what matters. Not sure what you're getting at with "type cracking". Preprocessing errors are murderous.

    I don't know what sort of programming language you are using, but allocated memory won't get overwritten in a dynamic langauge unless there is a langauge bug (a C problem). It will get overwritten in C. In fact buffer overrun security errors are almost all due to out of date bug prone C libraries where arrays were bounded, but unchecked.
    What I'm saying is that when you had to pre-allocate your buffers it made for much more efficient memory. I'll admit I haven't sat down to look at PHP's memory allocation methods, but really, a dynamic language generally can't compare to static (IF the people are smart enough to allocate.. but see, if you aren't smart enough to allocate, it doesn't compile, so that's a whole other story)

    The real world contains plenty of instances where the correct formalism is a list with an unknown size. The Y2K problem is caused by imposing arbitrary limits as you would be forced to do.
    Yes, well, limits are always a case. Say I open a MySQL table with int(15) for time stamp - eventually that's going to run out.

    I don't trust myself to do these calculations in my head. The machine is better at this.
    While true, I still think it'd be faster for you to do it.

    Code:
    You can write code that is sloppy in any language and people have to start somewhere. The trouble is you are focused on low level coding errors. You are missing the wood for the trees.
    With a language like C you can't (most people can't) pick it up from bits and pieces. Most people that I know who know C read a book (a decent book too, it's been out long enough that people have learned it in universities and taught it etc. etc. etc.), as opposed to just going learning it as they go along.

    The error is readily apparent in PHP and so easily fixed (once you know you have aproblem). If you don't have a problem, then it's not an error. Place a long network call in that loop and it's actually good code, as you would be pushing the data out more quickly and so reducing the chances of transaction failures in other code.

    You can write that error in plenty of other languages. I would write it in C, but I cannot be bothered. It is a staggering 40 lines of code in that language.
    Not following you on the first point, and as for thee second - exactly my point.

    It's an ROI calculation. If you actually measure the cost of developer time (you haven't have you - I can tell) you will find it swamps the costr of servers. Do it now and then show me your calculation. I would be happy to explain.

    Otherwise you have looked blindly at one side of the see-saw. You are coding by fear, fear of poor performance that you have never actually measured. Your fellow developers will suffer.
    Uh, not following you at all there. Cost of developer time? I didn't bother because that's completely irrelivent to what I'm saying. All I'm saying is think about the server, don't go putting queries in loops. The load differences from servers to clients are:
    1. Servers have more than 1 person trying to do the same thing, clients only have 1 (themselves, generally that is..)
    2. Servers are normally mis-thought of. People don't think about server loads when developing (Read: *a lot* of people, not all.. there, cleared that one)



    Past that I'll answer later, I'm starving.

  16. #66
    SitePoint Addict silent's Avatar
    Join Date
    Jun 2004
    Location
    Roaming North America
    Posts
    220
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You smell that? Do you smell that? Flame, son. Nothing else in the world smells like that. I love the smell of flame in the morning.

  17. #67
    SitePoint Wizard silver trophy someonewhois's Avatar
    Join Date
    Jan 2002
    Location
    Canada
    Posts
    6,364
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It's 7:30 PM where I am..


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •