Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

(Completely OT) - Hero(i)n programming language on Slashdot

by dragonchild (Archbishop)
on Dec 14, 2004 at 14:35 UTC ( #414713=perlnews: print w/replies, xml ) Need Help??

Now, a new programming language is usually completely irrelevant to most of us ... except when Perl is mentioned in comparison. I give you a slashdotter's comment:
Let me just say that the last thing you want is to emulate is the styl +e of C++! Perhaps next you'll tell me it has the speed of Python and the type-sa +fety of perl....

Yep - Perl has type-safety! *grins*

You'll want to

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.

Replies are listed 'Best First'.
Re: (Completely OT) - Hero(i)n programming language on Slashdot
by Arunbear (Prior) on Dec 14, 2004 at 15:19 UTC

    Grandmother, what a big signature you have!

    Sorry, I couldn't resist. Thanks for the link ;o)
Re: (Completely OT) - Hero(i)n programming language on Slashdot
by gaal (Parson) on Dec 14, 2004 at 15:40 UTC
        Here's some more typing goodness from MJD.

        -- All code is 100% tested and functional unless otherwise noted.
      Strong typing loses most of its meaning when most everything is automatically coerced into a new type...
      #!/usr/bin/perl -w use strict; #try to catch as many type errors as possible #setup a few initial things $\="\n"; my $a=4; my $ref_a=\$a; my @b=("b",5); my $ref_b=\@b; my %c=("c",6); my $ref_c=\%c; print $a+@b; #coerce array into number print $a+$ref_b; #coerce reference into number my $d=eval %c; #coerce hash into string print "d=$d"; #amusing result my @e=%c;print "@e"; #hashes and arrays are different types. Oh wait +... print "c=$_" for %c; my @t=12; #coerce number into array print @t; print 0+@t; print "\\4 = ".(\4->{"what???"}); #??? sub test{ return ("a",123) }; #sub returns a list my $scalar_list=test(); #coerce into scalar my @array_list=test(); #coerce into array my %hash_list=test(); #coerce into hash print "\$scalar_list=$scalar_list\n\@array_list=@array_list"; no warnings; my %i=$ref_a; print %i; #apparently hashes can be scalar refs... no strict; $$ref_a->[88]=7; print $$ref_a->[88]

      -- All code is 100% tested and functional unless otherwise noted.
        print $a+@b; #coerce array into number

        This is exactly the same as array.length() in Java. It's not a type conversion.

        print $a+$ref_b; #coerce reference into number

        Those are both scalars. Not a type conversion.

        my $d=eval %c; #coerce hash into string

        This one is tricky. What the eval actually gets is certain internal information concerning the hash, which happens to be output as a valid perl expression (a division operation). You've lost all real information about the hash, and therefore is not a type conversion.

        my @e=%c;print "@e"; #hashes and arrays are different types. Oh wait

        My own view on this is that hashes and arrays are both subtypes of lists. So it's not so much a conversion between different types than between different subtypes. There are those that disagree, though.

        my @t=12; #coerce number into array

        This simply makes a scalar containing 12 that is placed as the first element of the list, and the list is then assigned to an array. The scalar is still there, so it's not a type conversion.

        I think I've established a pattern here. None of these are really type conversions.

        "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.


        There's a whole bunch of misdirection in them thar comments...

        use strict;  #try to catch as many type errors as possibleWrong... The strict pragma is meant to "restrict unsafe constructs", according to its POD. This is not the same thing as "catching type errors". See below for applications...

        print $a+@b; #coerce array into number
        Misleading... This isn't "type coercion". This is "evaluation in a scalar context".
        print $a+$ref_b; #coerce reference into number
        A reference is a species of scalar that numifies to the memory address of its referent. No coercion here. It's still a scalar.
        my $d=eval %c; #coerce hash into string print "d=$d"; #amusing result
        Misleading again. This is "evaluation of a hash in a scalar context". I'm not sure what is actually amusing about the result. It's all there in the documentation.
        my @e=%c;print "@e"; #hashes and arrays are different types. Oh wait +... print "c=$_" for %c;
        They are both collections, so one could group them as the same meta-type, but they have different characteristics that warrant treating them as different types. The assignment is simply "evaluation of a hash in a list context". 'for %c' produces the same situation. As usage goes, it's value is limited.
        my @t=12; #coerce number into array print @t; print 0+@t;
        The assignment sets up a list context, in which there is only one item, the "12". I don't see "type coercion" here either. The two 'print' statements are unremarkable demonstrations of evaluating an array in list and scalar contexts.
        print "\\4 = ".(\4->{"what???"}); #???
        The output of this line lies. \4 produces a different value than does \4->{"what???"}. In the debugger, 'p \4' prints a ref to a scalar; 'x \4' shows that '4' is the referent. The numeric part of the ref is different from that printed by this line, which is, in fact, a scalar reference to an undefined value. What was this supposed to demonstrate?

        Further fun with perl -MO=Deparse finds that this print is parsed as

        print '\\4 = ' . \$4{'what???'};
        How interesting...
        sub test{ return ("a",123) }; #sub returns a list my $scalar_list=test(); #coerce into scalar my @array_list=test(); #coerce into array my %hash_list=test(); #coerce into hash print "\$scalar_list=$scalar_list\n\@array_list=@array_list";
        $scalar_list demonstrates the comma operator in action. What are you trying to demonstrate here? What did you intend to demonstrate with %hash_list? Where does "coercion" come into play here?
        no warnings; my %i=$ref_a; print %i; #apparently hashes can be scalar refs...
        Oh? How do you demonstrate that? I note that you "cleverly" turn warnings off so the casual observer won't see "Odd number of elements in hash assignment" pop up from the assignment, nor "Use of uninitialized value in print" from the print. What do you think is actually stored in %i? Iterate over the keys and dereference them, if you dare. Hint: it won't work. Spectacularly.

        Further investigation with Deparse show that this is parsed as

        my (%i) = $ref_a;
        creating the list context from which it expects to get an even number of items. The same condition applies above at 'my @t=12;'
        no strict; $$ref_a->[88]=7; print $$ref_a->[88]
        Why turn strict off here? Which facet of strictures were you hoping to sneak by here? Pray explain.

        Deparse reports a triple dollar sign, not a double.

        So, to get to the bottom: bad troll; no biscuit.


        Consider the difference between value typing and container typing. Then consider that you've told perl not to check for type violations. Why would you expect it to complain about type system violations?

        One other thing: note that even the most strongly typed langauge will let you define a function that takes one type and returns another:

        $ ocaml Objective Caml version 3.08.1 # let rec sum = function [] -> 0 | i :: l -> i + sum l;; val sum : int list -> int = <fun> # let list = 1 :: 2 :: 3 :: [];; val list : int list = [1; 2; 3] # sum list;; - : int = 6

        (If you're not familer with OCaml, the above makes a function that takes a list of integers and sums them, returning a single integer. In OCaml, "int list" and "int" are totally seperate types.)

        Indeed, a language that didn't allow you to do this would be very limited. All Many of the examples you presented essentially do this, although the actual function call is hidden away by Perl.

        "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

Re: (Completely OT) - Hero(i)n programming language on Slashdot
by BrowserUk (Pope) on Dec 15, 2004 at 16:19 UTC

    I've following along on this thread waiting for the punchline, but it seems to be missing :)

    Arguing about whether Perl is or is not strongly typed --and by which of the myriad (conflicting) definitions of that phrase it is or is not so--seems a little like arguing whether Lamborghinis or Ferraris are 'true sports cars'. Everyone has their of understanding of the term and places their own level of importance upon it.

    A better discussion might be whether Perl's type system is useful or not. One of the things missing and sorely needed by most languages that have static typing is a generic or polymorphic type, that allows generic collection libraries to be written without wholesale cut&paste (automated or not), to support each different containable type.

    After C++ first started gaining popularity, the absence of polymorphic container classes, and the near impossibility of writing them became apparent very rapidly.

    The proposed and adopted answer was Templates. These are a mess, especially the early variants. They are essentially nothing more than (slightly) sophisticated C-style source-code macros. Create a template Bag class and then instantiate a Class for each of chars, ints, longs, floats, doubles, strings, Dogs and Widgets, and you end up with 8 copies of the 90% of the code that is common. Cut&Paste under a different name.

    Newer veriants of Templates may be more sophisticated than this. I haven't touched C++ for years--and fervantly hope I never have to again.

    Anyone who's done anything remotely complicated in Java will also know this problem, of a lack of a generic type. And the problems it creates when dealing with any external data source where the type of the data can only be determined after you've read it. Example, communications protocols. The lack of C/C++ unions makes for very clumbsy handling of datastreams where you cannot predetermine whether the next few bytes are a string, an int, a float etc.

    There are now moves afoot to correct this limitation in Java. I can't comment on it, beyond that the fact that as the home page is not on a Sun site, it makes me a little wary. But it does highlight that people are seeking to address this limitation.

    Here we are with Perl's 'roll-your-own' OO and 3 1/2 types, and yet we have two, simple, powerful, infinitely flexible polymorphic container types: Hashes of scalars; and arrays of scalars; from which it is possible to construct any number of easily usable containers with specific behaviours, that have a common syntax, and can be efficiently operated on (iterated over, tested for existance, compared, deleted etc.), using many of the built-in language features and functions*.

    In addition, we have the tie mechanism that allows us to use our 3 1/2 types to encapsulate a whole raft of other types, behaviours and complexities behind those same, 3 1/2 simple interfaces.

    We should be laughing ourselves silly at all those pundits that think that calling Perl "not strongly typed" is an insult.

    Whilst they continue to to try and devise a polymorphic container mechanism, that they obviously need, and fighting their compiler over who knows best about what the program should and should not needs to do--we can just get on with the business of writing code, easily and quickly, that does what we need it to do.

    *Why people ignore the simplicity and usability of Perl's hashes and arrays as polymorphic containers and instead opt for using the so-called "Factory Pattern" to achieve the same thing with a much less usable and much less efficient interface puzzles me greatly.

    Examine what is said, not who speaks.        The end of an era!
    "But you should never overestimate the ingenuity of the sceptics to come up with a counter-argument." -Myles Allen
    "Think for yourself!" - Abigail        "Time is a poor substitute for thought"--theorbtwo         "Efficiency is intelligent laziness." -David Dunham
    "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon
Re: (Completely OT) - Hero(i)n programming language on Slashdot
by jdporter (Canon) on Dec 14, 2004 at 17:36 UTC
Re: (Completely OT) - Hero(i)n programming language on Slashdot
by gmpassos (Priest) on Dec 14, 2004 at 23:31 UTC
    A programing language has only one purpose, help us to develop a system using a group of resources that makes abstraction of the OS, Hardware, data structure, IO, modularity, etc...

    But I think that this Heron language just uses the worst parts of the syntax of Object-Pascal (Delphi) and C++!

    On C/C++ and Delhpi a lot of things could be done automatically by the compiler, and they are missing this again with Heron.

    Graciliano M. P.
    "Creativity is the expression of liberty".

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (5)
As of 2020-07-09 18:22 GMT
Find Nodes?
    Voting Booth?

    No recent polls found