I actually think it's very useful to think in different levels of abstraction for different problems. I also think it's good to abstract the code in a way that helps the problem domain at hand.

When doing list processing or handling code as data, Lisp offers both a good level and a good model of abstraction. When handling storing and retrieving large datasets according to basic rules, SQL is a good interface to an RDBMS. Representing the nesting and the relations of data between one part of a collection of data and another, XML, Lisp, Perl's data structures, and JSON are all pretty good.

When the problem domain is interfacing to the hardware more compactly or more specifically to a particular machine's strengths, then that's where assembly languages (and such) shine. It's rare, though, that assembly models the problem of the overall application very well.

That's why there's always the advice thrown about to write in a higher-level language that lets you rewrite portions in a lower-level language later. A person who knows Lisp, Perl, C, C++, Forth, or any number of other higher-level languages and who can handle the overall problem can code a working solution. Then, a person who knows C, Forth, or assembly can tune the critical sections. This can be one person at different times, or it can be two people.

It probably shouldn't be one person trying to solve both problems at once. That messes up both levels of abstraction. The assembly programmer's probably going to pay attention to microoptimizations and miss the algorithmic win. The higher-level programmer's probably not going to care until tests pass how fast that inner loop is.

The wisdom is often, I think attributable to Kernighan and Pike, worded similarly to: Make it work. Make it right. Make it fast.

There's simply no reason to think of a huge system in tiny little pieces. People have enough trouble picking the right class or subroutine lines to draw, let alone trying to get a 300kloc C++ project written an op at a time. If we can break things down on multiple levels and stop breaking down the parts that are sufficiently decomposed, then we can worry about performance on an easily isolated portion of a project. That helps not just the ratio of runtime improvement to time spent programming it, but also the encapsulation of the problem's parts along the lines set by the higher-level language of your choice.

In reply to Re^2: Perl as one's first programming language by mr_mischief
in thread Perl as one's first programming language by amarquis

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.