Re^2: Perl as one's first programming languageby mr_mischief (Monsignor)
|on Apr 07, 2008 at 18:45 UTC||Need Help??|
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.