6 ms·

> Sometimes there’s a technology that solves a problem really well in your particular project, but which is really hard to understand or learn. I have seen thi

> Sometimes there’s a technology that solves a problem really well in your particular project, but which is really hard to understand or learn. I have seen this problem too many times. Some team find a framework/language combination that makes their lives slightly easier in the short term and want to go for the new technology. But, they do not think about how we will scale that knowledge or what will happen if the code is moved to another team. A couple of times I have been in the situation to have to re-write an application to the company common language (in one case Java, the other Javascript) because the receiving teams did not liked the technology and did not wanted to spend personal time learning something that was not valuable to them. When a new framework is adopted, it is a commitment that we will train the developers and let them experiment, fail and learn until they take hold of the technology. It takes tame and the decision cannot be taken lightly.

simonw 7y ago
One of my favourite observations about Python is that it's the second best language for basically everything - which makes it a fantastic default for an organization.
- bsder 7y ago
  Never thought about it that way, but it's an interesting observation. My biggest problem though isn't which scripting language someone should use for some task. It's getting them to the idea that they should use a scripting language for some task. People forget that HN is not the norm.
  - m463 7y ago
    > the idea that they should use a scripting language for some task People like to do premature optimization, and choosing the language is one way.
    - bcrosby95 7y ago
      Language choice isn't a premature optimization. People love to take that quote that was talking about a very specific thing and use it to justify not thinking about performance at all.
      - kbutler 7y ago
        It kinda is. Because algorithm improvements can dramatically exceed execution time improvements, working in a language that facilitates rapid development and iteration is a path to better final performance than early optimization for execution speed, which is then difficult to modify. That said, premature coding is also a negative - it pays to evaluate and refine the algorithm before coding - but sometimes executable pseudocode helps in that process.
    - bsder 7y ago
      I guess I was unclear. It's not about language choice. Far too many programmers simply don't know ANY scripting languages. So the concept that they might want to write a quick script to do some task is simply not in scope AT ALL.
  - toolslive 7y ago
    Yes, you quite often see facepalm solutions. For example, In the java world, they cooked up something called 'ant' which was a description in xml that would be parsed and interpreted by a java program to do all kinds of shell stuff (like creating directories, moving files, compiling files, ....). Obviously, this is a poor man's interpreter, and python would have been a better choice, or probably something like make, or scons, or whatever. I'm not doing java anymore, but I'm pretty sure some people still use it. Anyway, I've seen people opening sockets in Prolog, and I've seen people doing artificial intelligence in C. It's not about optimization, but it's surely possible to pick the wrong language for a task.
    - sorokod 7y ago
      Ant (and yeah the ecosystem has moved moved on since you left) is obviously not an interpreter and was never intended to be one. Neither are the more currently popular build tools. Nothing prevents anyone from writing their Java builds in, say, Python (shelling out to javac when needed) but no one does and with a good reason.
      - toolslive 7y ago
        > but no one does and with a good reason. What's the reason?
- gowld 7y ago
  For small teams and small projects, sure. But you'd do well to have a settlers team behind your pioneers, rewriting in something more scalable.
  - simonw 7y ago
    Well designed Python scales just fine - ask Instagram or Pinterest.
    - shandor 7y ago
      Any good pointers to some of their technical blogs about this? It's quite astounding that architectures their size are implemented with the "slowest language around". It would be very interesting to read in-depth how they manage to sidestep the performance problems (that are brought up almost always when someone mentions Python).
    - deleted 7y ago
      [deleted]
  - TheSpiceIsLife 7y ago
    If the observation holds true, Python would be the second best at scaling.

simonw 7y ago

One of my favourite observations about Python is that it's the second best language for basically everything - which makes it a fantastic default for an organization.

bsder 7y ago
Never thought about it that way, but it's an interesting observation. My biggest problem though isn't which scripting language someone should use for some task. It's getting them to the idea that they should use a scripting language for some task. People forget that HN is not the norm.
- m463 7y ago
  > the idea that they should use a scripting language for some task People like to do premature optimization, and choosing the language is one way.
  - bcrosby95 7y ago
    Language choice isn't a premature optimization. People love to take that quote that was talking about a very specific thing and use it to justify not thinking about performance at all.
    - kbutler 7y ago
      It kinda is. Because algorithm improvements can dramatically exceed execution time improvements, working in a language that facilitates rapid development and iteration is a path to better final performance than early optimization for execution speed, which is then difficult to modify. That said, premature coding is also a negative - it pays to evaluate and refine the algorithm before coding - but sometimes executable pseudocode helps in that process.
  - bsder 7y ago
    I guess I was unclear. It's not about language choice. Far too many programmers simply don't know ANY scripting languages. So the concept that they might want to write a quick script to do some task is simply not in scope AT ALL.
- toolslive 7y ago
  Yes, you quite often see facepalm solutions. For example, In the java world, they cooked up something called 'ant' which was a description in xml that would be parsed and interpreted by a java program to do all kinds of shell stuff (like creating directories, moving files, compiling files, ....). Obviously, this is a poor man's interpreter, and python would have been a better choice, or probably something like make, or scons, or whatever. I'm not doing java anymore, but I'm pretty sure some people still use it. Anyway, I've seen people opening sockets in Prolog, and I've seen people doing artificial intelligence in C. It's not about optimization, but it's surely possible to pick the wrong language for a task.
  - sorokod 7y ago
    Ant (and yeah the ecosystem has moved moved on since you left) is obviously not an interpreter and was never intended to be one. Neither are the more currently popular build tools. Nothing prevents anyone from writing their Java builds in, say, Python (shelling out to javac when needed) but no one does and with a good reason.
    - toolslive 7y ago
      > but no one does and with a good reason. What's the reason?
gowld 7y ago
For small teams and small projects, sure. But you'd do well to have a settlers team behind your pioneers, rewriting in something more scalable.
- simonw 7y ago
  Well designed Python scales just fine - ask Instagram or Pinterest.
  - shandor 7y ago
    Any good pointers to some of their technical blogs about this? It's quite astounding that architectures their size are implemented with the "slowest language around". It would be very interesting to read in-depth how they manage to sidestep the performance problems (that are brought up almost always when someone mentions Python).
  - deleted 7y ago
    [deleted]
- TheSpiceIsLife 7y ago
  If the observation holds true, Python would be the second best at scaling.