I think it's not uncommon for a dev to be faster with one language than another. And for another dev to know the same two languages but be more productive in the opposite direction. (And I am mindful that the bar was much lower for me -- being a temporary hack, my stuff didn't have to integrate fully or have the same level of production manners)
But here are two factors that make me faster in the uncommon language.
You know the usual debugger experience where if you keep stepping or you set a breakpoint and then later realize the interesting part is actually behind you? Which means you have to start your scenario again?
Well, the uncommon language has a recording debugger so you can visit any points in front of or behind you, and see what any variable or return value was. You're not limited by the current stack because the recorder captured every package you told it to from the beginning
Even a third party package...
This means I only have to debug once to find the bug, not n times.
And the language is expressive and pliable enough that this debugger was implemented in the language itself...
And mostly by one guy -- not me of course -- it didn't take a whole company to implement it.
And you know how in some languages like Java if your car (program) starts acting up in LA, you have to update the blueprint, send it to the car factory, build the new car, drive it back to LA, and try the same left turn to see it it still ferks?
With the uncommon language, I can stay in LA and change the car while the engine is still running, n times before the 2nd Java car arrives. The language is Clojure.
I have a friend who told me two separate times without promoting about how great a particular brand of guitar strings are... Both times I reminded him I don't know how to play any instrument.
Sorry. I almost resisted naming the language. But what got to me was my co-worker's complaint was about the very tech that made it possible to launch + save $x mil + save some nights and weekends and holidays for a handful of other devs.
And that the complaint was: the language choice makes it less maintainable (hiring pool is smaller) -- but the two factors I mentioned above actually contribute greatly to maintainability.
My original comment could have just been: "a production support tool can be a place to prototype new features."
And _other_ teams could have used other tech to solve the problem. But for the team that had the context and the responsibility, this was the highest probability shot. After hitting the target, a complaint was not the expectation.
Down votes are interesting when applied to a comment that's an answer to a direct question. (this isn't directed at sd9)
> Down votes are interesting when applied to a comment that's an answer to a direct question.
I suspect it's because your answer was indirect and had a fairly proselytizing tone. I found the information interesting, but it was a somewhat irritating read because it was inverted to demand attention, like a story, rather than being upfront. A better-received comment might have read more like:
"I used Clojure. This was mainly because it's my favorite language, so I could work faster in it, and because it has certain features which make debugging extremely fast. et cetera."
The downvotes I'm assuming are because you replied 303 words to a simple question, with the actual answer at the very end which is frustrating to readers. Not saying what you mentioned wasn't interesting though.
But here are two factors that make me faster in the uncommon language.
You know the usual debugger experience where if you keep stepping or you set a breakpoint and then later realize the interesting part is actually behind you? Which means you have to start your scenario again?
Well, the uncommon language has a recording debugger so you can visit any points in front of or behind you, and see what any variable or return value was. You're not limited by the current stack because the recorder captured every package you told it to from the beginning
Even a third party package...
This means I only have to debug once to find the bug, not n times.
And the language is expressive and pliable enough that this debugger was implemented in the language itself...
And mostly by one guy -- not me of course -- it didn't take a whole company to implement it.
And you know how in some languages like Java if your car (program) starts acting up in LA, you have to update the blueprint, send it to the car factory, build the new car, drive it back to LA, and try the same left turn to see it it still ferks?
With the uncommon language, I can stay in LA and change the car while the engine is still running, n times before the 2nd Java car arrives. The language is Clojure.