4 ms·

Step 1: Solve the problem with the most mature technology that is commonly used for that problem Step 2: Fight the urge to use something newer

by ynniv 9y ago

root_axis 9y ago
Better to just evaluate the tools in context of the problem, that way you're always open to the best tool for the job regardless of how old it is.
- ynniv 9y ago
  Nope. New tools have a lower expected lifespan (due to survivor bias) and less proven value. I love new tech, but a LAMP website will last forever.
  - root_axis 9y ago
    > New tools have a lower expected lifespan That doesn't have anything to do with whether or not that tool is the best one for the job. Further, this logic is clearly fallacious because I could just as easily say PHP is too new and you should use C and CGI. Clearly, there are qualities that make one tool better than another for a certain type of problem, so making an evaluation of the available tools per problem is the best way to go. > I love new tech, but a LAMP website will last forever. But LAMP is not always the best solution to the problem. For example, if one of your application requirements demanded streaming live data to the browser via websockets, PHP would be a bad choice compared to something like Go or node. Another example might be a webservice that takes some input and has to do computation-heavy work like image processing or rendering, it'd be a big mistake to implement something like that in PHP rather than than, say, a JVM based language.
    - meesterdude 9y ago
      > if one of your application requirements demanded streaming live data to the browser via websockets, PHP would be a bad choice compared to something like Go or node. Another example might be a webservice that takes some input and has to do computation-heavy work like image processing or rendering, it'd be a big mistake to implement something like that in PHP rather than than, say, a JVM based language. A nontrivial problem with this line of thinking you employ, is that it expect you'll be proficent/efficent in all of these languages & toolings, when in reality you may just be a really good PHP dev. It can be beneficial, for sure, to have an idea of where something would do well; doing calculations in SQL vs in server code, for example. But jumping right to it can be foolish if there is a cheaper / "faster" way to do it first. Part of tool evaluation needs to evaluate your own proficiencies, and the ability to delay optimizations. Maybe PHP is crap for websockets, but maybe you can spin up lots of machines to handle the load and that's good enough; or maybe (in some ways more likely) the project goes nowhere, and that optimization that could have been, was never needed.
      - root_axis 9y ago
        > in reality you may just be a really good PHP dev. If your only tool is a hammer... > Maybe PHP is crap for websockets, but maybe you can spin up lots of machines to handle the load and that's good enough Well sure, you could treat every problem like a nail by going to whatever lengths necessary to solve the problem with a hammer, but that is a waste of time and effort since a more appropriate tool could magnify your productivity instead of frustrate it.
        meesterdude 9y ago
        you can do a lot with a hammer. It is my view that it's better to bang out what you can with the tools you've got, and later reach for better tooling when the need or pain point truly arises; instead of trying to optimize from the start with tooling you don't know for perceived potential future productivity. And I consider this not to be a waste of time and energy, but an optimization of available resources. Often, building with what you know is more important than hacking together with something you don't. Especially if you're trying to build a product on it. Of course, building something like a web app in excel would be entirely the wrong approach; your tools have to at least be in the ballpark of applicability.
    - deleted 9y ago
      [deleted]
    - deleted 9y ago
      [deleted]

Step 1: Solve the problem with the most mature technology that is commonly used for that problem Step 2: Fight the urge to use something newer

by ynniv 9y ago

Step 1: Solve the problem with the most mature technology that is commonly used for that problem Step 2: Fight the urge to use something newer

root_axis 9y ago

Better to just evaluate the tools in context of the problem, that way you're always open to the best tool for the job regardless of how old it is.

ynniv 9y ago
Nope. New tools have a lower expected lifespan (due to survivor bias) and less proven value. I love new tech, but a LAMP website will last forever.
- root_axis 9y ago
  > New tools have a lower expected lifespan That doesn't have anything to do with whether or not that tool is the best one for the job. Further, this logic is clearly fallacious because I could just as easily say PHP is too new and you should use C and CGI. Clearly, there are qualities that make one tool better than another for a certain type of problem, so making an evaluation of the available tools per problem is the best way to go. > I love new tech, but a LAMP website will last forever. But LAMP is not always the best solution to the problem. For example, if one of your application requirements demanded streaming live data to the browser via websockets, PHP would be a bad choice compared to something like Go or node. Another example might be a webservice that takes some input and has to do computation-heavy work like image processing or rendering, it'd be a big mistake to implement something like that in PHP rather than than, say, a JVM based language.
  - meesterdude 9y ago
    > if one of your application requirements demanded streaming live data to the browser via websockets, PHP would be a bad choice compared to something like Go or node. Another example might be a webservice that takes some input and has to do computation-heavy work like image processing or rendering, it'd be a big mistake to implement something like that in PHP rather than than, say, a JVM based language. A nontrivial problem with this line of thinking you employ, is that it expect you'll be proficent/efficent in all of these languages & toolings, when in reality you may just be a really good PHP dev. It can be beneficial, for sure, to have an idea of where something would do well; doing calculations in SQL vs in server code, for example. But jumping right to it can be foolish if there is a cheaper / "faster" way to do it first. Part of tool evaluation needs to evaluate your own proficiencies, and the ability to delay optimizations. Maybe PHP is crap for websockets, but maybe you can spin up lots of machines to handle the load and that's good enough; or maybe (in some ways more likely) the project goes nowhere, and that optimization that could have been, was never needed.
    - root_axis 9y ago
      > in reality you may just be a really good PHP dev. If your only tool is a hammer... > Maybe PHP is crap for websockets, but maybe you can spin up lots of machines to handle the load and that's good enough Well sure, you could treat every problem like a nail by going to whatever lengths necessary to solve the problem with a hammer, but that is a waste of time and effort since a more appropriate tool could magnify your productivity instead of frustrate it.
      - meesterdude 9y ago
        you can do a lot with a hammer. It is my view that it's better to bang out what you can with the tools you've got, and later reach for better tooling when the need or pain point truly arises; instead of trying to optimize from the start with tooling you don't know for perceived potential future productivity. And I consider this not to be a waste of time and energy, but an optimization of available resources. Often, building with what you know is more important than hacking together with something you don't. Especially if you're trying to build a product on it. Of course, building something like a web app in excel would be entirely the wrong approach; your tools have to at least be in the ballpark of applicability.
  - deleted 9y ago
    [deleted]
  - deleted 9y ago
    [deleted]