5 ms·

Do people realize the huge hidden cost of this "polyglot programming" thing? Imho, we have two huge "blackholes" these days that suck resources form everything

by nnq 14y ago

Do people realize the huge hidden cost of this "polyglot programming" thing? Imho, we have two huge "blackholes" these days that suck resources form everything that matters: the "social everything, center around advertising, give stuff for free" black hole at the business level, and the "uberpolyglot everything", from languages to OSs at the technical level. > We have had to become polyglots to develop almost any current application. ...in my experience, by working in 2 languages instead of one, the time it takes to deliver something grows 3-4 times (!!), and there's still all the "lost" training time: instead of learning new paradigms, patterns and way to solve problems, people spend inordinate amounts of time learning the details of new languages. I used to love the polyglot way, but now I see language proliferation more as part of the problem than the solution. There was and advantage of all this, but now most paradigms of concurrency and everything are cross-language, and even if some languages like Clojure or Haskell injected new or better refined ideas into the mainstream, these ideas are nor longer tied to a particular language. I think we should invest as much as we can in unifying languages and technologies, like: - using one language by making a traditional client side language work server side: the Node way - cross-compiling: the X to Javascript compilers (like Clojure-script and Python to Js or Ruby to Js techs) - make languages use libraries from other languages: not to much exciting things happening here yet :( ...but I'd love having a way to, for example, mix C, Python and Ruby libraries inside a Clojure program, regardless of the performance or security issues ...they all seem like "boring plumbing work", I know. They are neither "exciting big problems to solve" nor "amazing business ideas" and you'll most likely neither change the world nor get rich by working on such things, but you can probably make a huge difference by working on such plumbing an let the really smart guys free to invent really new things!

thisone 14y ago
My reply is that you may be able to drive a nail with a brick, but a hammer works much better. Same for programming. The more you are aware of, the better able you are to chose the better way of proceeding on a project. I'm probably scarred though, I work with people who believe that c# and sql server can solve all the world's programming problems. (I like c# and sql server, but they aren't always the best solution for a given problem)
- hackinthebochs 14y ago
  >The more you are aware of, the better able you are to chose the better way of proceeding on a project. This is a part of the problem. "The right tool for the job" has become an end in itself, rather than a means to an end. People spend so much time trying to develop more than a superficial understanding of a vast array of languages and frameworks, simply so they can say they are using the "right" tool for the job (perhaps so their future "show HN" post can be sexy). The right tool should always be understood as successfully executing your project as the goal. Sometimes the right tool is simply the one that you or your team has expertise with, or has a deep body of experience built up on StackOverflow. The "right" tool in absolute terms is completely meaningless. Often times it seems like people forget this.
  - thisone 14y ago
    I didn't mention a "right" tool, I actually made sure to use the term "better", because "right" has those negative connotations. For our purposes, there are "better" tools available than those that were chosen. A pain that we're feeling now, a couple of years on, as we start to migrate a live application to those other platforms. That's a big loss of productivity for us because choices were made to use tools that were familiar instead of figuring out if they actual made the most sense.
    - deleted 14y ago
      [deleted]
    - hackinthebochs 14y ago
      Heh you're right. It's interesting how one's expectations can totally change how you read a statement. I see the "right tool for the job" tripe repeated so much that I start to see it everywhere :)
  - deleted 14y ago
    [deleted]
- nnq 14y ago
  ...but there's essentially no learning curve for both the brick and the hammer! If it takes you one month to learn how to use the hammer, you'd better use the brick. Now, if your "hammer" is actually more of a general purpose tool than the "brick", it's the other way around, but if it's a hammer specially designed to work only at pounding nails in wood...

by nnq 14y ago

thisone 14y ago

My reply is that you may be able to drive a nail with a brick, but a hammer works much better. Same for programming. The more you are aware of, the better able you are to chose the better way of proceeding on a project. I'm probably scarred though, I work with people who believe that c# and sql server can solve all the world's programming problems. (I like c# and sql server, but they aren't always the best solution for a given problem)

hackinthebochs 14y ago
>The more you are aware of, the better able you are to chose the better way of proceeding on a project. This is a part of the problem. "The right tool for the job" has become an end in itself, rather than a means to an end. People spend so much time trying to develop more than a superficial understanding of a vast array of languages and frameworks, simply so they can say they are using the "right" tool for the job (perhaps so their future "show HN" post can be sexy). The right tool should always be understood as successfully executing your project as the goal. Sometimes the right tool is simply the one that you or your team has expertise with, or has a deep body of experience built up on StackOverflow. The "right" tool in absolute terms is completely meaningless. Often times it seems like people forget this.
- thisone 14y ago
  I didn't mention a "right" tool, I actually made sure to use the term "better", because "right" has those negative connotations. For our purposes, there are "better" tools available than those that were chosen. A pain that we're feeling now, a couple of years on, as we start to migrate a live application to those other platforms. That's a big loss of productivity for us because choices were made to use tools that were familiar instead of figuring out if they actual made the most sense.
  - deleted 14y ago
    [deleted]
  - hackinthebochs 14y ago
    Heh you're right. It's interesting how one's expectations can totally change how you read a statement. I see the "right tool for the job" tripe repeated so much that I start to see it everywhere :)
- deleted 14y ago
  [deleted]
nnq 14y ago
...but there's essentially no learning curve for both the brick and the hammer! If it takes you one month to learn how to use the hammer, you'd better use the brick. Now, if your "hammer" is actually more of a general purpose tool than the "brick", it's the other way around, but if it's a hammer specially designed to work only at pounding nails in wood...