Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

Re^2: Perl as one's first programming language

by mr_mischief (Monsignor)
on Apr 07, 2008 at 18:45 UTC ( #678804=note: print w/replies, xml ) Need Help??


in reply to Re: Perl as one's first programming language
in thread Perl as one's first programming language

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.

  • Comment on Re^2: Perl as one's first programming language

Replies are listed 'Best First'.
Re^3: Perl as one's first programming language
by samizdat (Vicar) on Apr 08, 2008 at 12:56 UTC
    Agree with everything you've added, mr mischief. In fact, the ability to move from one level of abstraction to another is sorely lacking in today's world. Schools do not teach kids to think of associations and context, and so they're crippled when it comes to analyzing a situation or problem.

    There are some efforts to teach kids about patterns and sets, but they're so limited. The vast majority of 'education' is rote skill practice and regurgitation, and that's leaving our kids stuck in the muck.

    Don Wilde
    "There's more than one level to any answer."

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (7)
As of 2020-07-16 14:35 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?