I'm a bit tempted to do something like this.

We have an old creaky app which I'm tempted to rewrite in ClojureScript in my own time and then show them it.

Worst case scenario they say it's great, now can we please rewrite it in JS. Best case scenario I get something in Clojure / CLJS into our system.

Either way I'd probably learn a lot just from the project. And I kinda need a new side project at the minute.

I would go for it. As you say, it will be a valuable learning experience. And writing anything the second time (even if switching languages) tends to be much easier than the first time since the problem is more known. So you lose not much time if you ultimately throw ClojureScript away in favor of something else.

> So you snuck it in

Linux did not win the server space because admins snuck it in. It won because it was free and worked well enough compared to signing up for tens of thousands of dollars worth of lengthy contracts with SCO/HP/IBM or even Microsoft.

> Sneak ClojureScript in

I don't see this ending well.

It's great to do your side projects in your favorite language but foisting it onto your employer so they they are forced to use it is a pretty bad violation of trust.

What happens if you quit and ClojureScript programmers are hard to find at the price the employer can afford without going out of business?

I would never try and pull this off.

Linux won because it got proven to be effective before any money had to be spent. The risk of trying it out was very low. And it ran well on old or low spec hardware, which Windows did not run (well) on. So we snuck Linux in by installing it on old puny PCs, setup some useful network services, and let it do its job well for months. Then we would casually mention to management what we did.

Many companies would not or because of SLAs _could not_ use free Linux. They would pay RedHat or Suse fees that included support/maintenance. Yes, it was still usually cheaper than Window licenses, but the price was not really the point.

Now about sneaking languages, platforms, and stacks in... Java was once too risky and unknown to be used in place of C/C++, but we snuck that in and proved it was up to task. Python... hah, Python was a toy "scripting language". No self-respecting CIO would approve of building company products in Python. Ruby? Rails? Surely not, those were also free, unknown, unproven technologies (which ironically were trying to supplant Java-based systems... that same Java which was once too risky).

PosgreSQL or MySQL? No way, that's not reliable for production. Of course it is, and it got snuck into companies whose engineers despised Oracle and SQL Server (not because MSSQL sucked, but because it only ran on Windows).

You can pick any modern best of breed tool, and I can point in history when that tool had to be snuck in to prove itself and gain acceptance.

> You can pick any modern best of breed tool, and I can point in history when that tool had to be snuck in to prove itself and gain acceptance.

I don't like the idea of "snuck in".

Working with management and having buy in that there's going to be a risk involved in taking something up that's new and unknown is OK.

That way we have a plan and action in place if things go other than expected.

That is exactly why I left a BIG5 firm and now work at startups because I can run these by the CEO and have a discussion.

The place where I work does not exist for my amusement.

Many people's livelihood including those of close friends and their families depend on the decisions I make.

If I am at a VC funded startup I am playing with the retirement of millions of people.

I owe it to them to be in the know of any risky decisions I take that I judge to be risky enough to affect them negatively.

Anything that's new and relatively unknown is risky.

That does not mean we don't try it.

It does mean we need to have a plan and action in place if things go other than expected.

Thats just good engineering and business because people depend on me.

Otherwise it's just a hobby and pastime.