Without being quite as harsh, I generally agree. I have generally found new or inexperienced developers become scarred by projects that fall behind more than projects that grow out of control, and bias more towards getting something done, fast. Totally agree that the best advice for OP is to not underestimate his own ability to perform well in a better language. I think it is folly to assume you need a less structured language to get up and running faster.

This very much reminds me of the Worse Is Better line of thinking.

It's a pointless article without knowing what the project is.

I wouldn't use perl for my multi-threaded enterprise messaging solution, but I might use it for a useful text analysis tool.

>It's a pointless article without knowing what the project is.

Exactly. I recall being assigned a small project years ago to print a route list in a particular way. I'm sure it could have been done with maybe a hundred lines of Go or Python or whatever language du jour. But it came down to a two line shell script. Which one is supposed to be the elegant one again?

Also, there is a reason that a C compiler is written in C but a Java virtual machine is not written in Java.

And anything with substantially more than a thousand lines of code that isn't written in a strongly typed language is all but guaranteed to be a maintenance catastrophe full of security vulnerabilities. (Or a pile of slow, hideous fail as a result of all the manual runtime type validation you have to do to prevent that from happening.)

Elegance is a function of adaptability to purpose. A screw driver is an elegant tool to screw in a screw but an inelegant tool to hammer a nail.

I manage the maintainance of millions of lines of scripting code that's not type safe. Type safety is definitely not a significant problem, nor is speed.