3 ms·

This is insecurity masquerading as insight. One does not need to invoke mental frailty in order to defend the use of a particular language. Nor is there a dic

This is insecurity masquerading as insight. One does not need to invoke mental frailty in order to defend the use of a particular language. Nor is there a dichotomy between "a focus on getting things done quickly" and beauty or elegance. In short, this is lazy writing capturing a lazy thought process. Nothing to see here.

zwischenzug 14y ago
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.
- AnthonyMouse 14y ago
  >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.
  - zwischenzug 14y ago
    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.
sentiental 14y ago
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.

zwischenzug 14y ago

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.

AnthonyMouse 14y ago
>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.
- zwischenzug 14y ago
  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.

sentiental 14y ago

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.