I feel that if the problem fits into the idiom of the language forget the problem space. Languages are made with a particular application in mind, so it seems foolish to disregard this. Doing so often means being counterintuitive in solving a problem, approaching the problem from the point of the language. Which can often gives positive results and gives you a better insight into the system that aping the existing system won't yield.

I am all for abstraction where it is practical, I baulk at "This frees you from the petty detail of the underlying -programming- language". I don't want to be freed from this very fundamental thing, I choose to code in a language that lends itself to the problem, be it Perl, Bash, C, Java, Javascript, VB or XML. Right Tools for the right Job etc. These days there is a blur as most languages are striving for complete coverage of applications.

splitStringByChar isn't that @foo=split//,$bar or a kingdom of alternatives to be used discerningly in situ?

--

Brother Frankus.

¤