Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

Re: Revealing difference in interpretation of 'number' between Perl and $other_language

by hangon (Deacon)
on Sep 17, 2008 at 15:37 UTC ( #712037=note: print w/replies, xml ) Need Help??

in reply to Revealing difference in interpretation of 'number' between Perl and $other_language

There was a time when people programmed in assembly when they wanted fast efficient code (burden the programmer). They used C/C++ in order to write code more efficiently (burden the computer). In my opinion dynamic languages such as Perl (and Python, Ruby & Lua) are just the next steps in the evolution of programming languages.

  • Comment on Re: Revealing difference in interpretation of 'number' between Perl and $other_language

Replies are listed 'Best First'.
Re^2: Revealing difference in interpretation of 'number' between Perl and $other_language
by mr_mischief (Monsignor) on Sep 17, 2008 at 16:09 UTC
    ++, but I think it's more a gradient. Even assembly puts more burden on the computer than twiddling the bits directly, but less on the programmer. C and C++ burden the computer a bit more than assembly, but still place a substantial burden on the programmer.

    Lisp and Forth both move certain burdens for the programmer out of the way in exchange for other burdens on the programmer. Lisp places additional burdens on the computer (recursion) for the benefit of the programmer while removing burdens from the computer (syntax parsing) by placing burden on the programmer. Forth lowers the barrier for the computer (postfix syntax) by placing it on the programmer (postifx syntax). ;-/ Forth's generic storage cells remove a burden on the computer (type checking), and can alternately be a boon or a headache for the programmer. Other languages make similar trades.

    Perl is a language for getting work done. As such, it puts more burden on the computer and less on the programmer than many other languages. Implementing an efficient algorithm and knowing a few things about the interior of perl can make a Perl program much faster than not knowing those things. In many cases, Perl can run as fast or nearly as fast as program in languages that are much more restrictive of the programmer. In some cases it can't, and that's the price we pay for more freedom and more power of expression.

    Languages can continue to evolve both above and below the level of Perl. The only reason evolution at the level of C and C++ has been so slow is because despite their warts they accomplish their tasks very well. Even CPU microprogramming, which is below assembly, continues to evolve. Even as programs are written in languages at levels higher than Perl, Perl continues to evolve. It will continue to evolve so long as people use it and see where it could fit its niche even better. There are already many languages at far higher levels than Perl, although most of them are domain-specific. Yet Perl is still the glue that holds many of those together. C is still the language, for now, that holds Perl together and that is used to write many of the libraries upon which Perl depends. It's not so much an evolution of a single species as new layers in the food chain or of superstructure being built on substructure.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://712037]
NodeReaper cracks his knuckles - loudly

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (11)
As of 2018-04-20 10:34 GMT
Find Nodes?
    Voting Booth?