Ask HN: How do you sell in a new programming language?

arguing beforehand for the language itself never worked for me. for me it's always been easier to get the other developers interested, and then deploy a working project with it.

asking beforehand for me always led to a wide variety of different arguments of why we can't use a different language. the most common two being the following ones.

* we can't find new developers with that experience

* our developers don't know it

It may sound ridiculously obvious, but I think it's often a matter of being able to empathise with whoever you need to convince. Most organisations are in it to make money, and different people are different pieces of the puzzle of achieving that. If you can express the upside of the technology shift in terms relevant to, say, business developers or managers, things get easier. Whether you have closures or not doesn't matter, but time to market, time spent on bug fix releases instead of feature releases, etc do. Also, it will probably serve you best to thoroughly and honestly present both pros and cons. There's almost always cons (training, toolchain or workflow changes, building competence, talent availability, unclear longevity of technology being switched to) so if you're not upfront with the cons, people will wonder what they are and not knowing is scary, risking a higher susceptibility to scepticism. Also, if it's possible to use the new tech for a small project and you can show the upside with clear metrics, actions speak louder than words. My two cents.

Build something useful with it, prior to getting widespread buy-in. Build this thing more efficiently than you could have using the existing tools. Make sure the end product is more efficient, reliable, and robust than an equivalent built using the existing technologies. Make sure these differences are very, very significant and obvious.

Implement something useful. Be useful. Better to ask for forgiveness than ask for permission. Only way it works.

While Ruby was growing in popularity prior to Rails, it took Rails to really convince a lot of developers (including me) to switch from existing solutions. I think there's a lot to learn from how that happened. (See SciPy or IPython and Python for smaller scale examples of this story.)

Timing for the argument is very crucial. Your arguments for adopting a new language will only work when other employees and your BOSS see your solution run, and that at the correct time, when most of the people are not satisfied with the current solution. If you are successful in demonstrating the pros and importantly cons and other people support your decision, then there is 1% chance that your boss will try!

I don't remember what happened clearly but I am able to recount one instant..

My father is a pro C# guru. His organization was having hard time investing in a proprietary library. High costs had him thinking. I suggested him to use a python based open source library. He asked me to mind my own business and not to meddle in his affairs. That night when I came to his room to good night, he was sitting reading the python documentation!

(We haven't actually switched yet, and there isn't significant progress on doing so, but the attitude change was decent)

We use PHP for most of our web stack at work. This includes long-running consumers that are part of our growing service-oriented architecture. PHP all over. It's hard to say "no" when everyone is familiar with it.

We've dealt with pretty crappy performance, compared to other solutions, using this setup. It puts a lot of backpressure on our publishers (we use RabbitMQ as our messaging layer) and it causes queue build-up, which requires manual intervention, etc etc.

I had mentioned how we should switch to a better language: didn't go that well. We have a lot of code written already: nothing insurmountable to rewrite, definitely <10k lines of good code, excluding boilerplate-y stuff. It's nearly impossible to get people to drop other priorities to try something new. It has to be a more sure shot.

One of our developers, though, wrote a test application in Java to show how much faster we could be consuming and processing messages. He actually replicated one of our simpler services, which isn't much more than turning the messages into rows in a MySQL database. I believe the Java consumer had a ten-fold performance increase over the PHP one.

So, now, we have a few internal working groups for various tracks of improvement to our product, and one of those groups is exploring Java as a possible language to switch to for this area of our infrastructure. We have people dedicated to actually vetting it, not just talking about it at the bar or something.

Long story short, and to echo everyone else: you can't just tell people there's something better, you have to show them something better.

A lot of this depends on the organization, its perceived needs and the personalities involved. No doubt some of the answers you get here will be helpful, but I would focus on the particulars. The first question is whether the organization actually needs a new language or whether you just want to use a new language.

Depending on the environment, the change will bring its own set of difficulties and those will need to be addressed. Sometimes, it's a matter of the people involved. For instance, you are the only one passionate about a new language and others are not or is willing to learn and others are not, etc, then you suddenly have a new problem that may not have existed before, including having to support your colleagues through the transition.

As for arguments, etc, those should arise from your situation. If the current system is not working, make that clear. You may have to repeat yourself to get the point across. But do your homework first. Know what's broken and how your suggestion will fix it. Know the advantages of the current system and the distadvantages of the new one. "Trying something new" does not seem like a good reason; surely there's a reason why you use language X?

What makes you sure that your implicit assumption 'new == better' is correct?

I worked for a place that used a dying language. The argument I used was simple: If you stick this technology, your employees will worry about their careers and leave, AND you will find it harder and harder to recruit new people who are interested in this language. Good developers will want to work in exciting and living languages to further their careers and keep their skills up to date. So the only developers you will find are the ones who will "settle" if they can't find another job, or use it as a stepping stone until they find a different job, or demand a high premium to do it.

There seemed to be some openness to studying the alternatives, but ultimately it was hard to convince the powers that be that it was worth the effort to adopt a new language/technology.

So I quit. The only regret I have now is I didn't do it sooner. I wasted a lot of valuable time.

One 'argument' that people don't often think of is recruiting and hiring. I recruit for many companies, and the level of applicants I receive for jobs in the more emerging language communities is well above the applicants I usually get for more traditional languages. My evidence is anecdotal, but when I posted Clojure or Scala jobs (and recently Go) I received fewer applicants! but almost all of them were highly qualified engineers with very impressive track records. The applicants also come from all over, because of the novelty of the jobs. Java jobs tend to get local candidates, but a Clojure job gets applicants worldwide.

Most of this is with startups, but I've even seen serial startup engineers go to work for large companies who use an emerging language.

Obviously this is a side effect that depends on the language chosen, and it doesn't justify that the code or product will improve, but if you are making the argument this could be a consideration.

Of course, the counter is that experienced talent in the emerging language may be more scarce.

Well, I personally know one high-level technical individual who almost got fired for daring to use Spring in a heavy J2EE shop. He survived and Spring makes the product so much better (for those who don't know - Spring is basically what J2EE should have been - lightweight and high performance framework)

You basically have to appeal to emotions (they won't understand the technical argument or even care). But if it makes the product more stable, more easily extensible/customizable - that could work.

Good luck!

A contractor and I successfully convinced our large enterprise that node.js was the best choice for a new project and we were able to use it. I dont want to make this a conversation about whether node is good or not, but it did hit the sweet spot as our goal was basically a RESTful API as a facade to some legacy tech, which is in my opinion where node shined - and this was back in early 2011.

The convincing arguments are:

1) the technology fits the problem - I would not use C++ for a web api, and I would not use node for a rendering engine.

2) the team is (mostly) ready to use it - a couple weeks to read a book and make a prototype should be enough. There is no need for lengthy and expensive training sessions or a gigantic shift in technical knowledge

3) if it doesnt work out, you can double back quickly and cheaply

4) the new technology won't cost an arm and a leg - no need to find budget for expensive licensing for software/tooling

5) you are not proposing this alone - get backing from other senior level programmers/architects.

If you can hit most of those, then you probably have a decent chance!

The same way you sell a business anything else: it will raise our revenues and/or decrease our costs.

Rather than saying "We should reimplement our core products in $FOO" you can often achieve the result of using $FOO while hitting less resistance by implementing one-off projects or support systems in $FOO instead.

e.g. I worked at a Japanese megacorp and, despite us being a Java shop, one of the sales guys sold a customer on "We're certainly the right people to write documentation for your Perl program." This contract only required a bunch of HTML files as a deliverable, rather than getting a team of programmers to speed on something which would be maintained for 30 years, so I successfully convinced my boss that I'd jump on the Perl grenade if he let me use any means necessary to create the HTMLed documentation. I ended up doing it in Ruby. Then I had a "Hey boss remember that time I delivered a $X0,000 project in 1/4th the budget and made you look like an effing hero? I want to use that tech again" case study.

Though for the amount of time I spent on evangelizing Ruby and modern Javascript-heavy UIs at my previous company I could have launched my own. Eventually I did. It turned out to be a much better use of my time.

Managers only understand about resources: time, money and human.

And percentages.

Are you respected? Because I’d say don’t even bother trying if they don’t respect you

Does your new language improves productivity, maintainability, code reusability, performance, etc?. Does it allow new crazy esoteric tricks with one line of code?. Does it bring a paradigm shift?.

Otherwise if its a new syntax for the same old thing - specially regarding imperative programming which to me already reached a dead end - it will be hard to sell. If you're thinking of a market strategy then your language is lacking enough innovative features that make it sell itself.

So, to begin, this is really hard to do, and it can lead to the end of your career at a place. Managers might think of you as That Guy, the one who is always coming out with disruptive ideas. ("Disrupt" ain't a positive term, here.) That Guy makes the manager's job harder because the manager wants a unified front, not debate.

1. It helps if the language interoperates well with the existing platform. If you're at a Java shop, consider Scala and Clojure. Don't bother trying to sell it on Haskell; that'll never happen. But, for Scala or Clojure, the top 25% of Java developers are probably headed that way already.

2. Don't ask permission of nontechnical management. (Grace Hopper: it is better to ask for forgiveness than permission.) Just deliver something cool in it that the rest of the organization can use. In the JVM ecosystem, no one needs to know that the JAR actually contains Clojure code. Get enough momentum behind the project that management actively wants you to demo it to the rest of the company. Then mention the "secret weapon".

3. After (2), get a job ad posted in the new language. The quality of applicants will be a lot better. Post a Java job ad, and you'll get more responses, but your phone-screen-to-hire rate will be about 2-5%. For a Clojure job, it'll be closer to 30%-- and 60% of those who actually know Clojure (those who don't will fail-fast on the phone screen). Not only can you reduce time wasted with unqualified candidates, but you're more likely to get a 10X hire. Now you can make the argument that it's worth hiring more people in the newer, better language.

You're not going to turn a large Java shop into a Clojure company. It just won't happen. But if you do the above and have a bit of luck, you might carve out a CoE (Center of Excellence, also known as an "honor's college", which tends to be an elite suborganization that has an R&D flavor) in the organization that uses it.

That above only works if your company has generally good management. (They don't need to be programming language specialists, but they need to be good at their jobs.) If not, you're not going to get anywhere no matter what you do and it's not your fault. Then, the best bet is to move on.

There once was a company called Digital Research (DRI). They had a successful language called CBasic. A friend that worked there tried to convince them to develop a compiler for another language called "C". They refused. He insisted. The result: "they fired my ass!" Later, DRI wrote a C compiler. Was it too late? Would they have been successful if they had written it sooner? Maybe. But, then that would have been a different company. Perhaps, another way of looking at it is that my friend was giving his company a job interview and, in his case, they failed.

If I were in your shoes, I would spend some time trying to research why your company is actually resistant to change.

Some managers are extremely resistant to change because they work in organizations with extremely vertical power structures. Consequently, they know that even if they think it is a good idea, they are going to have to sell it to 15 different people and get each to sign off on it. In some organizations (government is an excellent example), a manager would have to write a report to get permission to write a report investigating a new technology. In organizations like this, experienced people (aka - management) generally have horror stories about the time they spent three years getting permission to upgrade all the computers to Windows ME...

That brings up another reason that some organizations are resistant to change. When the kinds of people who read Hacker News think of a new tool, they're usually excited. People like us equate change with learning and improving. Consequently, change is an adventure. Unfortunately, end users don't always feel the same. For these types of users, "IT change" is synonymous with "pain and torture". Consequently, getting permission to use a different tool is usually only the first step. When you actually implement the project, you get to deal with six weeks of whining, followed by another four weeks of training extremely resistant people. And then, for the next several months, every problem on earth is 'the new system's fault'...

And then, there are the sales people. Many managers have horror stories where a sales person convinced them that this great new system would do A, B, C, D, E, and F. Unfortunately, once the system is implemented, lo and behold, the system barely does A and B. If you've ever been through a situation like this, you'll be extraordinarily resistant to any new solution.

Once you know a little more about why your company is resistant to change, you'll be in a better place to make a decision. Maybe you work for a giant, monolithic entity that changes about as fast as granite erodes. In this case, you might have to decide whether you feel comfortable in a company like that. Or, maybe your direct manager got burned by a new tool and is forever paranoid. In a situation like that, you'd be better off implementing a one-off project with the new tool and proving that your solution actually works.

The general advice in situations like this is to show that a new tool will have a positive return on investment. That advice isn't wrong, but unfortunately, when people write about the ROI of a new tool, they usually focus on developer hours saved. While that is a good metric, in most cases, developer hours are just one component of a system's true cost. If you start your analysis earlier, you'll have a better sense of all the other costs involved and be able to speak to the real objections you will face.

Have a plan for how it will integrate with your existing ecosystem such as tools, version control, continuous integration, data sources, etc if your org requires these things. I once worked as a principal at a .NET shop and had a smart engineer come to me wanting to use nodejs for part of a project and had to gently turn him down. I love to see enthusiasm for using new tools and personally like node/javascript, but his plan to use node didn't address important process concerns like hooking into our existing deployment, CI, and unit tests. Those concerns could have been addressed, but would have required significantly more effort than the actual project itself. Every org is different, but for us adding something without proper automation/tooling was a sin.

I convinced the company I work at to use Haskell for REST services.

The technical leadership team was already interested improving the reliability and rigor of our web backend, but weren't thinking about exploring other programming languages. (we primarily use PHP)

I knew Haskell would be hard to sell, but I also had concerns about it myself, so I ran a live-fire test:

In my spare time, I wrote an interface-compatible Haskell implementation of a particular service that drove a lot of load, but was noncritical. I load-tested this service by flipping an nginx switch to divert traffic to the Haskell implementation. Leadership was ok with this because we could just flip the switch back if there were any issues: The risk of customer impact was miniscule. After some initial tests, we left it to run for a few months without manual intervention.

Over the course of this side-project, I got a few curious coworkers to learn Haskell to help out.

When the right project came along, leadership still had concerns, but I had lot of hard evidence to show that Haskell superbly fit our technical requirements and that the nontechnical problems (like hiring and training) were probably surmountable.

Depends on who you're selling to. Here are few categories out of top of my head.

- Make website very fancy with videos and do many useless benchmarks showing that it's faster then everything, especially Nodejs

- Create VM language and show that it's just as good as Java but with much more syntactic sugar. Also note that C# runs only on Windows and yours run on everything.

- Do a static compiled-to-bytecode language that will be just as fast as C++. This is very hard so you can forget about this.

- Create another "language" that will compile to Javascript.

Show that it decreases LOC while improving/maintaining readability with performance at par with current ones OR great performance without too much compromise on LOC count and readability.

So in essence, how it makes an average joe like me more productive/powerful.

Stop arguing. I'm a programmer, not a salesperson. $FOO (a new programming language) needs to sell itself.

Cost. What is it going to cost?

Benefit. What are the benefits of using $FOO?

The answer is: it's going to bring in revenue.

$FOO needs to be adopted because it is popular, it is an industry and open standard.

> Do we need to convert everything to $FOO?

The answer is: no.

> Do all of the programmers need to learn $FOO?

The answer is: everyone already knows how to programs in $FOO.

I'd be curious to know what the "entrenched" programming lanaguage is, and what the "new programming language" is.