Comment by nnq | Hacker News Reader

Comment by nnq | Hacker News Reader

Parent Full thread

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!

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)

>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.

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.

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 :)

...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...

Most of the time (anecdata) a language is not used to solve programming problems, it's used to solve business problems.

Reply on news.ycombinator.com