• aliceif (disco)

    PHP not being the WTF is TRWTF!

  • JBert (disco) in reply to aliceif

    Still, the WTF is strong in this one...

  • CoyneTheDup (disco)

    Looks to me like the main WTF component that need to be swapped out, was The Big Boss.

  • Luhmann (disco) in reply to CoyneTheDup
    CoyneTheDup:
    The Big Boss.

    That seems to be a common pattern in many articles ...

  • swt (disco) in reply to aliceif

    Using PHP to replace an existing system with something better is like getting out of the car, breaking both your legs and then running backwards while smashing a hammer against your forehead. After a while you might think it's working better now, but that's only you and due to the pain. And the hammer.

    Had to waste hundreds of hours in the last few months with this unholy mess. So looking forward to proper and half-sane development again...

  • Nprz (disco) in reply to swt

    I'd probably pick interpreted code that will run the same on all the servers over compiled code that has different source on each server because it won't compile or run the same.

    Whether I'd pick php is a different question. Glad to hear he didn't stay there for years and pick up stock options, etc.

  • Kal (disco)

    Any language can be badly use. To say PHP is the TRWTF is like saying you cant use a tool unless its the tool you love to use.

    Now the lesson from this article: bad boss -> quit as fast as you can -> if you stay longer than 3 months = its your fault and you deserve the pain

  • dkf (disco) in reply to swt

    It might be PHP, but it sounds like PHP is significantly better than the steaming pile it is replacing here. A dirty big pile of ill-defined never-really-maintained code is extremely unlikely to be better than PHP, which at least has the advantage of being a stinker that has had many people try to make it better.

  • aliceif (disco) in reply to Kal
    Kal:
    the TRWTF

    The way to the Department of Redundancy Department is this way: :arrow_upper_right: :arrows_counterclockwise: :arrow_right: :european_post_office:

  • Gaska (disco)

    Rewriting it all in C++ (in a sensible manner) would bring just as much improvement as rewriting in PHP, but would be even faster. Although rewrite would take a bit longer.

  • dkf (disco) in reply to Gaska
    Gaska:
    but would be even faster

    Yet if the all the application is really doing is shuffling data back and forth between the web and the database, using C++ is going to make very little difference to the speed perceived by users or sysadmins, as it will just get blocked on I/O a few nanoseconds sooner.

  • Gaska (disco) in reply to dkf

    I wouldn't be so trusting of PHP interpreter implementation.

  • martin (disco)

    So PHP is WAY superior to C++. Tested and Proved! It's smaller, faster, more stable.

    The Bigg Boss was right and he should get a raise.

  • Julia (disco)

    This seemed fishy to Andrei right from the start

    TRWTF is not trusting one's instincts and running out the door at this point.

    I made the same exact proposal, and it wasn’t just denied - it’s the reason I’m being let go in two weeks

    T2ndRWTF is not doing the same at this point. Seriously,what warning would have convinced Andrei he was heading for a world of interminable anguish?

  • martin (disco) in reply to CoyneTheDup

    Why? He made the right decision, he found the right man, he managed to get it done one month earlier, he saved the company!

    This should go to management hall of fame!

  • FragFrog (disco) in reply to Gaska

    Possibly. Possibly not. There are many things wrong with PHP, which I will be the first to admit after having worked with it for years. But one of its saving graces is that it lets you build applications fast, and if you're good, maintainable too. I know, it is hard to believe.

    If the story is true, a developer was able to take a fairly messy codebase, and recreate its functionality in a different language using much less code. That could either be due to the choice in language, or simply because he was a better programmer than the 'old' developers. At least in those terms, the Big Boss may accidentally have made the right decision in firing so many of those.

    In my experience, any developer that has stayed with a company for more than a few years will just not be fired, regardless of the quality of his code. Many of the Big Bosses simply do not grasp how much damage one rotten apple can do, and anyone who "build something that worked" is automatically a good programmer in their book. I have worked at companies with similar disregard for testing or version control, with a dozen programmers just trundling on "because that is how things are done". And it always started with one or two developers who could not be bothered to Do It Right.

  • Gaska (disco) in reply to FragFrog
    FragFrog:
    it lets you build applications fast, and if you're good, maintainable too.
    You can say that about 90% of programming languages out there - the last 10% is those you can't build apps fast in, but they'll still be very maintainable if you're good.

    Question is, how good you have to be.

  • FragFrog (disco) in reply to Gaska

    Ah, you're absolute right of course. What I mostly meant though with that statement, was that a lot of the bad rep PHP gets in terms of maintainability comes from the fact that so many novice programmers work with it due to its low skill floor. My point then, is that rewriting a C++ application in PHP for maintainability reasons is not necessarily an oxymoron.

    Personally, I find it easier to write maintainable code in PHP than C++ (and Perl), though not as easy as writing clean code in JAVA or C#. Of course, YMMV.

  • Gaska (disco) in reply to FragFrog
    FragFrog:
    Personally, I find it easier to write maintainable code in PHP than C++ (and Perl)
    Probably because the more experience with the language you have, the more readable a terrible code seems to be. How many junior programmers do you expect to know what a placement new is when they encounter it in codebase?
  • dkf (disco) in reply to Gaska
    Gaska:
    How many junior programmers do you expect to know what a placement new is when they encounter it in codebase?

    How many codebases need it?

  • ben_lubar (disco) in reply to Gaska

    Malbolge?

  • antiquarian (disco) in reply to FragFrog
    FragFrog:
    What I mostly meant though with that statement, was that a lot of the bad rep PHP gets in terms of maintainability comes from the fact that so many novice programmers work with it due to its low skill floor.

    I think there's more to it than that. Python also has a lot of novice programmers working with it, but doesn't have a bad rep.

  • DocMonster (disco)

    Ah yes, the standard "If you aren't typing, you aren't working" mentality. Because surely all that design and testing stuff is a load of crap, programmers should be programming!

    It really boggles my mind that people like this not only exist but often are wealthy and living the dream, while competent people struggle with their lives. Firing people for (gasp!) wanting to do things right? Preposterous!

  • Gaska (disco) in reply to dkf
    dkf:
    How many codebases need it?
    Not many, but when it's needed, it's the best tool available, although obscure. It was just an example - I could say template metaprogramming instead and it wouldn't change much in my post - both are terrible to read, until the point where you've been exposed to them enough and now the syntax is obvious and totally readable.
  • xaade (disco) in reply to antiquarian
    1. Inconsistency in the api.
    2. It's gotten better, but the bulk of programmers who determined that PHP should have bad rep, haven't used it since.

    Take a born-bred programmer who recently came into the field in C#, and introduce them to C++ and ask them how to rate the language. Now, do the reverse.

    This is why PHP has such a bipolar love-hate reputation.

    Also, consider that Web Apps are anything but apps, and that this bastardization of what it means to program applications has done nothing but muddy up the waters of quality programmer output.

  • monkeyArms (disco) in reply to FragFrog
    FragFrog:
    a lot of the bad rep PHP gets in terms of maintainability comes from the fact that so many novice programmers work with it due to its low skill floor.

    QFT.

    xaade:
    Inconsistency in the api. It's gotten better, but the bulk of programmers who determined that PHP should have bad rep, haven't used it since.

    Take a born-bred programmer who recently came into the field in C#, and introduce them to C++ and ask them how to rate the language. Now, do the reverse.

    This is why PHP has such a bipolar love-hate reputation.

    This too - a lot of people still remember versions <= 4.x, which were piles of crap that encouraged poor coding practices. I'm perfectly happy writing OO MVC appy-type things in PHP nowadays.

  • dkf (disco) in reply to Gaska
    Gaska:
    I could say template metaprogramming instead

    That happens to be an example where scripting languages do it too, and better. Evaluation of dynamically-created code is their specialist topic, and they tend to be extremely good at it.

  • Gaska (disco) in reply to dkf

    You missed the point for the second time now. If only there was non-joke whoosh badge...

  • accalia (disco) in reply to Gaska
    Gaska:
    If only there was non-joke whoosh badge...

    i have plenty of those to tell you that they are not exclusively joke wooshes.... and apparently they don't even have to be wooshes if the community gives enough votes....

    i wish there was an appeal process for these manual badges.

  • Gaska (disco) in reply to accalia

    Thanks, now I don't feel bad for flagging you!

  • accalia (disco) in reply to Gaska
    Gaska:
    Thanks, now I don't feel bad for flagging you!

    Either i need to start leaving teeth marks or..... no i think that's the only option.

    stand still for a moment. this will hurt you more than it will hurt me.

    ;-)

  • Gaska (disco) in reply to accalia

    Why all cute pets are so bitey? :confounded:

  • accalia (disco) in reply to Gaska

    because we don't like where discourse sticks those flags?

    ;-)

  • Groaner (disco)

    The schadenfreude from watching these "anything that isn't typing isn't programming" shops crash and burn is most satisfying.

  • Kian (disco)

    The original writers of the mess were a whole WTF on their own.

    There's no reason not to have a central repo server (meaning, a single place to store all the code, not necessarily all in a single repo) even if each machine was special (why are all the servers so different from each other in the first place that it matters to application code? The OS should abstract the hardware a bit, shouldn't it? Were they using c++ at the driver level for an application, or a different OS in each server?). You keep the code in one place, and then you build on each machine (better if you had cross compilers so you can keep the code and build on one machine). This isn't even a C++ issue, this is just basic organizational stuff they got wrong when they built the mess. It doesn't take more time to have the source properly stored and backed up.

    It's idiots like these that give C++ a bad name.

  • DocMonster (disco)

    Really though, at some point one has to think the place is insane and not worth dealing with. If they're firing people every 2-3 weeks for daring to want to put some thought in, it's clear that the place deserves to crash and burn. Sometimes a place like that will only learn if they lose all of their developers in one go, because they'll either have to shut down when nobody can fix the software, or anyone they try to hire will be smart enough to ask "Why don't you have any developers" knowing that it's a HUGE red flag.

    The real WTF is putting up with such a crazy place for more than a day.

  • iansltx (disco) in reply to monkeyArms

    Am a PHP dev who gets to work with the latest version of the runtime, can confirm that it's much less of a steaming pile now. And not that slow either.

    As an added bonus, the "screw threads and single-task concurrency, let's just load balance runtime processes so that concurrency issues are outside the realm of our code base" approach that standard PHP implementations take (Facebook's alternate implementation notwithstanding) solves a class of problems that this particular WTF was constantly running into. And if a request crashes, the next request has a fighting chance of completing successfully anyway. Those sorts of things have value, as long as you can live with the implications of sharing nothing except your code between HTTP requests (or you run your stuff as daemons, which in recent versions of PHP won't eat up all your RAM in short order).

  • Eldelshell (disco)

    Man, how much wrong you have to do to end up with something like this.

  • kupfernigk (disco) in reply to CoyneTheDup
    CoyneTheDup:
    Looks to me like the main WTF component that need to be swapped out, was The Big Boss.

    HP keep trying this. It does not seem to work as well as you would expect. This is because nobody has yet worked out how to implement a reliable Big Boss module that is not designed from the ground up to fit a company.

  • lightsoff (disco) in reply to iansltx
    iansltx:
    solves a class of problems
    No, it just makes the code unnecessarily slow and unable to *ever* get any faster.

    The computer you buy in a few years time will probably be capable of twice the performance, but it will do that by doubling the number of cores.

    If your software can't use the extra cores and isn't already primarily I/O bound, it's going to have the same performance as on the old hardware - and the buyer will be annoyed.

    • Spinny disk to SSD will provide a one-time boost and then you're CPU-bound again.

    Anybody writing software today must understand concurrent programming and be able to use it (when applicable)

  • PleegWat (disco) in reply to lightsoff

    Sorry, but that argument is all over the place.

  • iansltx (disco) in reply to lightsoff

    That's a bit of an oversimplification. I agree that concurrency is the path to making things faster, but there are easier/more difficult ways to do that.

    A braindead-easy way when you have a fair amount of traffic is to handle each request in its own process. If you've got 36 concurrent requests, you've just made good use of the beefiest box Amazon offers right now, with no big gotchas about managing concurrency within your application code. Easy win.

    Combine that with the fact that a bunch of web apps are either I/O bound...and the fact that increasing programmer productivity in general allows for more low-hanging-fruit refactoring (overwrought concurrent code may still run slower than simple single-threaded code...just ask the Node folks)...works in favor of languages were concurrency primitives are, well, more primitive (not counting non-blocking I/O as a concurrency primitive for purposes of this argument).

    Two more points: beyond a certain latency threshold, optimizing for throughput is more important than optimizing for the latency of an individual request. This plays nicely into the multi-core thing, and the model above.

    Last point: hardware is getting cheaper for the same speed, as well as faster for a given amount of money. You can get cloud compute instances with a single core, or two cores, for dirt cheap now, and those cores are plenty fast. Sometimes time is money, and other times money is money. It's odd that my dev environment has more concurrent thread capacity than any of my production servers, but I'm sure I'm not the only one in this situation.

    Okay, one more point: runtime performance still has a long way to go, depending on the language. Compiler performance, less so but still a factor. So your app could conceivably get faster (latency wise) over time even if your instructions per clock or clock speed don't go up.

  • CoyneTheDup (disco) in reply to martin
    martin:
    Why? He made the right decision, he found the right man, he managed to get it done one month earlier, he saved the company!

    This should go to management hall of fame!

    Yes, yes, I know.

    I knew a big boss of a previous employer who nearly ran the company into the ground. But just before it cratered, he moved on to another company. Now he's in the management hall of fame for the things he did that nearly destroyed the company. His successor is in the management hall of fame, too, for his accomplishments in rescuing a company from the rocks.

    It's lovely to be a manager: You're always hall of fame material, no matter how bad your performance.

  • CoyneTheDup (disco) in reply to kupfernigk
    kupfernigk:
    HP keep trying this. It does not seem to work as well as you would expect. This is because nobody has yet worked out how to implement a reliable Big Boss module that is not designed from the ground up to fit a company.

    I really can't agree. Based on some of the stories we've seen in here, it doesn't look like it works very well grow a boss from inside the company, either.

  • HardwareGeek (disco) in reply to CoyneTheDup

    Unfortunately, nobody has managed to develop a replacement for the Boss module, either. Lots of architectures (centralized, distributed, public, private) and development processes (in-house, outsourced), but the quality of individual implementations varies widely, from fantastic to utter rubbish. In the end, it seems to be only the individual implementation that really matters.

  • lucas (disco) in reply to Gaska

    Oh shut up MR "I hate all languages".

    Generally you tend to write code that matches that language better, but maybe more difficult for beginners to understand.

    The JavaScript, PHP and C# I wrote of yester-year are much different to that of today.

  • Gaska (disco) in reply to lucas

    That that that that that... I've got lost four times in that sentence before I could understand it, and I'm still not 100% sure I've got it right. Refactoring time?

  • lucas (disco) in reply to Gaska

    Corrected, it wasn't that difficult though.

  • HardwareGeek (disco) in reply to lucas
    lucas:
    Corrected

    Not completely. s/buy/but/

  • dkf (disco) in reply to Gaska
    Gaska:
    You missed the point for the second time now.

    Why do you think I'm interested in the points you're trying to make?

Leave a comment on “The Backend”

Log In or post as a guest

Replying to comment #:

« Return to Article