Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

(Zigster) Map the language into the problem space

by zigster (Hermit)
on Jun 25, 2001 at 19:42 UTC ( #91312=note: print w/replies, xml ) Need Help??


in reply to To sub or not to sub, that is the question?

Ok, lots of good advice here however there is an important factor thus far not really covered.

I use subs to simplify complex code. I dont mean in the obvious manor where subs can offer logical partitioning but more on the conceptual level. I am a man with a small brain (damn but if pooh does not have a comment for all eventuallities) When dealing with a particularly thorny programming challenge I avoid mapping the problem into the language space as is often done, instead I map the language into the problem space. Consider the nature of the problem you are solving deduce the language of the problem. Code subs to allow you to talk that language; addVector, splitStringByChar. Many of these subs could often contain a single line of code. Then solve your problem using the language of those subs. This frees you from the petty detail of the underlying -programming- language. Once the problem is solved and working the depreciate redundant subs by moving the code from the sub into the main body of the code. This is an idea most often seen in OO programming and it is very powerful (most good programmers do it without meaning too), it is appropriate for application and algorithmic centric problems.

jplindstrom touched on this idea in his node in this thread, I agree COMPLETELY with what he said it is dangerous to fractionalise code into many small and useless subs. It is important to rationalise the need for each sub at the end and deprecate where required.
--

Zigster

  • Comment on (Zigster) Map the language into the problem space

Replies are listed 'Best First'.
Re: (Zigster) Map the language into the problem space
by frankus (Priest) on Oct 08, 2001 at 20:48 UTC
    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.

    ¤

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://91312]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (6)
As of 2020-01-20 23:42 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Notices?