http://www.perlmonks.org?node_id=678794


in reply to Perl as one's first programming language

I think we have two basic paths in programming these days, and I have to say that there are legitimate reasons for choosing each path.

The first path is the one most of us grew up with, that of needing to understand the underlying hardware. As an embedded systems programmer, I'm typical of this breed. I grew up on bit-banging assembly language and Peter Norton's inside tips.

Today, there's a second path. Actually, there always has been, starting with COBOL and FORTRAN and, yes, LISP. The holy grail of programming has always been to abstract away all hardware dependencies, and we're now getting to the point where forty or fifty levels of object aggregation do not produce an application that appears to be stuck in gooey mud, thanks to Moore and Noyce et al.

The nice thing about Perl (and Ruby and even BASIC) is that you can play without needing to learn too many rules and arcane incantations (not to deny that EVERY programming language is an arcane piece of syntactic crap). The key to all of these interpreted languages is experimentation. That's a feature of LISP as well, and hardburn's correct to include it as a potential first language. The downside of all of them (except for LISP) is that there is an arcane syntax to be learned. Perl's best at being able to handle lots of different DWIM's that all the others will not. Ruby is more fragile than Perl, but it must be said that its syntax, once learned, makes a lot more sense. I think MHO that BASIC should remain buried will be shared by all present. (!)

Contrast these with the so-called production languages in today's usage, C/C++ and Java. Both C and Java require reams of extra verbiage surrounding the logic of programming, and none of it is intuitively obvious. Moreso, there's lots of crap to be learned even before you get to issues surrounding hardware or memory management. As the OP stated, even 'Hello, World!' takes a bunch of compiler incantations and definitions that must be understood.

I do think we in programming are going to run aground in the near future in much the same way that today's kids are getting spoiled by the Internet. Contrary to popular belief, the history of the world began before 1990, and there is indeed hardware underneath Bill Gates' toy. There always will be hardware to be understood, and those who understand it will always be in high demand.

Our kids do indeed need Perl (or something equally potent) so that they can explore in all directions. Not every kid (or curious adult) will explore every nook and cranny, but some kid somewhere will, and that's a good thing. It does take a special breed to be a craftsman in any endeavor, and those who have the aptitude should be given tools that encourage exploration.

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

Replies are listed 'Best First'.
Re^2: Perl as one's first programming language
by mr_mischief (Monsignor) on Apr 07, 2008 at 18:45 UTC
    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.

      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."