in reply to Ansi Perl

I once had friend who avoided perl because 'there's no such thing as ANSI perl'

This is an oversimplistic way to look at things, and it rather misses the point. Perl5 is significantly more standardised than ANSI C, in terms of behaving the same way on different platforms (assuming you avoid constructs that the Camel specifically warns are inherently unportable).

Sure, there are some differences from one version to another, but if you restrict yourself to what is documented in the 2nd edition Camel (and avoid the aforementioned inherently-unportable things, such as backticks and link, and hardcoded filenames and paths), it will pretty much run unmodified and with the same semantics on any version from 5.003 forward, on any operating system that has Perl5 (except that fork, as documented, won't work on single-tasking OSes).

The same thing is not true for ANSI C.

"In adjectives, with the addition of inflectional endings, a changeable long vowel (Qamets or Tsere) in an open, propretonic syllable will reduce to Vocal Shewa. This type of change occurs when the open, pretonic syllable of the masculine singular adjective becomes propretonic with the addition of inflectional endings."  — Pratico & Van Pelt, BBHG, p68

Replies are listed 'Best First'.
Re^2: Ansi Perl
by Anonymous Monk on Dec 24, 2004 at 11:04 UTC
    Ansi C is portable to different platforms without problems if you avoid the things that are specified as implementation defined as well.

    That, after all, is the point of having a standard.

    The problem with unportable C code isn't because every coder is following the standard. The problem is coders targetting their compiler, and (ab)using its extensions. And then of course, there are the different libraries.

    Sure, there are some differences from one version to another, but if you restrict yourself to what is documented in the 2nd edition Camel (and avoid the aforementioned inherently-unportable things, such as backticks and link, and hardcoded filenames and paths), it will pretty much run unmodified and with the same semantics on any version from 5.003 forward, on any operating system that has Perl5.
    I've yet to write a C program that broke because I upgraded my compiler, or that I had to modify because it needed to be compiled on an older version of the compiler (although I've had to rewrite large portions of C programs because of kernel upgrades). OTOH, every upgrade of perl has broken some program of mine, somewhere.
[reply]
      I've yet to write a C program that broke because I upgraded my compiler

      Which doesn't explain why I have to downgrade my gcc from 3.2 to 2.9 in order to compile Oracle. It's just an upgrade, right?

      Being right, does not endow the right to be rude; politeness costs nothing.
      Being unknowing, is not the same as being stupid.
      Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
      Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

[reply]
        That just says the other AM didn't write Oracle. And without knowing why you needed to downgrade your compiler (source not ANSI compliant? Compiler bug? Library issue? ...?), nothing at all can be deduced from that statement.
[reply]

In Section Seekers of Perl Wisdom