Comment by m1n1 | Hacker News Reader

Comment by m1n1 | Hacker News Reader

We had to build and launch something by a deadline in order to avoid renewing a contract that would have cost $x mil. But we discovered we weren't going to finish in time with the resources and the approach that was planned.

So I got approval to hack out a temporary impartial suboptimal version and we were able to take off in time.

This has allowed us to fly for a bit while others finish building out the permanent proper version of that part of the wing.

In fact, during our flight we discovered missed requirements in the original design. This has delayed that proper version's release to prod. But I've been able to add that quickly to my hack and keep us flying.

My hack doubles as a production support tool. And as an alternate route if the permanent version needs to be paused because of a bug. Yes it's a partial imperfect hack but it has benefits.

Someone has complained about the language I used since it is less common. But remember, we weren't going to be able to take flight with the existing resources and approach.

We would have needed more and/or faster developers in the favored language to meet the deadline.

If any present employee (including me) had bandwidth and was able to be as productive in the favored language as I was building my hack in the uncommon language, that employee would have been tasked to build the permanent solution on time. That option was not available.

Anyways, if you have an existing production support tool, it's also a place where prototype features can live for a while.

What was the language?

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.

It was clear that the language was Clojure by the middle of the third paragraph.

Rust and Clojure are the only languages that always come with unsolicited sales pitches. Not knocking the languages, just observing.

I was half expecting this comment to end without actually naming the language.

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)

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.

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

For what it's worth, I enjoyed your tale, and I like Clojure

Reply on news.ycombinator.com