4 ms·

> 1. Until you hit facebook levels and have to write your own interpreter. Facebook levels of load would be a great problem to have. Until then, who cares? >

> 1. Until you hit facebook levels and have to write your own interpreter. Facebook levels of load would be a great problem to have. Until then, who cares? > 2. Sure, but your code will also suck and be hard to maintain. Doubtful, but this isn't even a good point. Working software is the important deliverable. > 3. Nonsense. You might as well say that everyone should use C because it was the first language with a TCP socket API. You missed the point. Writing a web app with a language that's basically tied to the web makes sense. It's not the most important point, but it isn't 'nonsense'. > 4. Nonsense. You can fuck up royally in any language. He said as much in that point. Did you bother reading and thinking about the article, or just trip over your own drool racing to the comments section? I'm just going to stop here. Color me unimpressed.

argv_empty 14y ago
Doubtful, but this isn't even a good point. Working software is the important deliverable. An unmaintainable codebase makes it hard to deliver working software in the future.
- slantyyz 14y ago
  So programming in PHP means that your code base will be unmaintainable?
  - argv_empty 14y ago
    You'll have to talk to tych0 about that. I'm just responding to the idea of setting aside maintainability in order to produce working code.
  - chc 14y ago
    No, deciding not to hire good programmers means that your codebase will be unmaintainable. Next time, maybe try reading the thread before commenting? Here's the discussion up to this point: OP: "If the event that my new ventures grow and I need to hire on more programmers I do not need the best and brightest to get the job done." tych0: "Sure, but your code will also suck and be hard to maintain." Domenic_S: "Doubtful, but this isn't even a good point. Working software is the important deliverable." argv_empty: "An unmaintainable codebase makes it hard to deliver working software in the future." You: "So programming in PHP means that your code base will be unmaintainable?"
    - slantyyz 14y ago
      I did read the thread, thank you. "An unmaintainable codebase makes it hard to deliver working software in the future." is a truism that I chose to respond with a question, because I am not of the opinion that Domenic_S was even remotely suggesting that anyone write unmaintainable code. Domenic_S's argument of "working software is the most important deliverable" isn't really a bad point, regardless of what language you're using. If you have maintainable code that doesn't address the application's requirements, how much does maintainability matter then? In the real world, there is hierarchy of priorities, and for most, working is at the top of the priority list.
      - deleted 14y ago
        [deleted]
eevee 14y ago
How can you argue that both "tied to the web" and "frameworks" are benefits, yet keep a straight face? Frameworks in any language plug the language into the web—that's what they exist to do. And if you're using the parts of PHP that are tied to the web, then you must not be using a framework, or those would surely be wrapped. ...but those parts of PHP must suck, or you wouldn't need to use a framework! So then... PHP is good because it solves the problems it causes? I don't get it.
tych0 14y ago
> Facebook levels of load would be a great problem to have. Until then, who cares? Good question, why did he bring it up? As others pointed out, it doesn't even make sense: your data store is where you have to scale, not the language itself. > Doubtful, but this isn't even a good point. Working software is the important deliverable. Hmm. I thought the goal was working and maintainable software? > You missed the point. Writing a web app with a language that's basically tied to the web makes sense. It's not the most important point, but it isn't 'nonsense'. No, it makes sense to choose the most powerful language. A language that's "basically tied to the web" means that you can't use it to do other things when your business needs change. > He said as much in that point. No, he said that php makes it less easy to screw up, which is simply not true. What if, late at night, I call mysql_escape_string (because, hey, the name makes sense!) instead of mysql_real_escape_string? Type systems make it harder to screw up. Poorly named escape functions, ridiculous type coercion, and a gigantic global namespace do not. > Did you bother reading and thinking about the article, or just trip over your own drool racing to the comments section? I'm just going to stop here. They see me trollin', they hatin'.
Sanddancer 14y ago
> Facebook levels of load would be a great problem to have. Until then, who cares? It shows up a lot faster than at Facebook levels of load. Because php throws everything out at the end of every request, you're going to need to buy a lot more servers a lot more often if your app does take off. Or you end up paying zend lots of money for things like caching that are built into nearly every other language. > Doubtful, but this isn't even a good point. Working software is the important deliverable. Until you're stymied next year because your current codebase is falling apart. > You missed the point. Writing a web app with a language that's basically tied to the web makes sense. It's not the most important point, but it isn't 'nonsense'. I'd much rather have a language isn't tied to any particular ideology. Yes, your clients are web-based at the moment, but your database isn't web-based, your mail server isn't web-based, etc. Driving everything by your presentation layer is a terrible, superficial way of looking at problems. > He said as much in that point. Did you bother reading and thinking about the article, or just trip over your own drool racing to the comments section? I'm just going to stop here. The original blog author posted this with an air of php exceptionalism. Other languages equally have no problem handling the issues that this author claims exist. This blog post, and your response, is a classic example of the php hammer syndrome. Yes, it kind of works, and seems neat at a superficial level, but once you start to use it, you start seeing all of the glaring flaws in the actual delivery of the product. Workarounds become dogma, and everyone suffers as a result.

argv_empty 14y ago

Doubtful, but this isn't even a good point. Working software is the important deliverable. An unmaintainable codebase makes it hard to deliver working software in the future.

slantyyz 14y ago
So programming in PHP means that your code base will be unmaintainable?
- argv_empty 14y ago
  You'll have to talk to tych0 about that. I'm just responding to the idea of setting aside maintainability in order to produce working code.
- chc 14y ago
  No, deciding not to hire good programmers means that your codebase will be unmaintainable. Next time, maybe try reading the thread before commenting? Here's the discussion up to this point: OP: "If the event that my new ventures grow and I need to hire on more programmers I do not need the best and brightest to get the job done." tych0: "Sure, but your code will also suck and be hard to maintain." Domenic_S: "Doubtful, but this isn't even a good point. Working software is the important deliverable." argv_empty: "An unmaintainable codebase makes it hard to deliver working software in the future." You: "So programming in PHP means that your code base will be unmaintainable?"
  - slantyyz 14y ago
    I did read the thread, thank you. "An unmaintainable codebase makes it hard to deliver working software in the future." is a truism that I chose to respond with a question, because I am not of the opinion that Domenic_S was even remotely suggesting that anyone write unmaintainable code. Domenic_S's argument of "working software is the most important deliverable" isn't really a bad point, regardless of what language you're using. If you have maintainable code that doesn't address the application's requirements, how much does maintainability matter then? In the real world, there is hierarchy of priorities, and for most, working is at the top of the priority list.
    - deleted 14y ago
      [deleted]

eevee 14y ago

How can you argue that both "tied to the web" and "frameworks" are benefits, yet keep a straight face? Frameworks in any language plug the language into the web—that's what they exist to do. And if you're using the parts of PHP that are tied to the web, then you must not be using a framework, or those would surely be wrapped. ...but those parts of PHP must suck, or you wouldn't need to use a framework! So then... PHP is good because it solves the problems it causes? I don't get it.

tych0 14y ago

> Facebook levels of load would be a great problem to have. Until then, who cares? Good question, why did he bring it up? As others pointed out, it doesn't even make sense: your data store is where you have to scale, not the language itself. > Doubtful, but this isn't even a good point. Working software is the important deliverable. Hmm. I thought the goal was working and maintainable software? > You missed the point. Writing a web app with a language that's basically tied to the web makes sense. It's not the most important point, but it isn't 'nonsense'. No, it makes sense to choose the most powerful language. A language that's "basically tied to the web" means that you can't use it to do other things when your business needs change. > He said as much in that point. No, he said that php makes it less easy to screw up, which is simply not true. What if, late at night, I call mysql_escape_string (because, hey, the name makes sense!) instead of mysql_real_escape_string? Type systems make it harder to screw up. Poorly named escape functions, ridiculous type coercion, and a gigantic global namespace do not. > Did you bother reading and thinking about the article, or just trip over your own drool racing to the comments section? I'm just going to stop here. They see me trollin', they hatin'.

Sanddancer 14y ago

> Facebook levels of load would be a great problem to have. Until then, who cares? It shows up a lot faster than at Facebook levels of load. Because php throws everything out at the end of every request, you're going to need to buy a lot more servers a lot more often if your app does take off. Or you end up paying zend lots of money for things like caching that are built into nearly every other language. > Doubtful, but this isn't even a good point. Working software is the important deliverable. Until you're stymied next year because your current codebase is falling apart. > You missed the point. Writing a web app with a language that's basically tied to the web makes sense. It's not the most important point, but it isn't 'nonsense'. I'd much rather have a language isn't tied to any particular ideology. Yes, your clients are web-based at the moment, but your database isn't web-based, your mail server isn't web-based, etc. Driving everything by your presentation layer is a terrible, superficial way of looking at problems. > He said as much in that point. Did you bother reading and thinking about the article, or just trip over your own drool racing to the comments section? I'm just going to stop here. The original blog author posted this with an air of php exceptionalism. Other languages equally have no problem handling the issues that this author claims exist. This blog post, and your response, is a classic example of the php hammer syndrome. Yes, it kind of works, and seems neat at a superficial level, but once you start to use it, you start seeing all of the glaring flaws in the actual delivery of the product. Workarounds become dogma, and everyone suffers as a result.