Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Re^2: Interesting read: "Why I use perl and still hate dynamic language weenies too"

by dewey (Pilgrim)
on Apr 17, 2007 at 15:32 UTC ( [id://610557]=note: print w/replies, xml ) Need Help??


in reply to Re: Interesting read: "Why I use perl and still hate dynamic language weenies too"
in thread Interesting read: "Why I use perl and still hate dynamic language weenies too"

I upvoted you for the time and thought you've put into this, but I'm not sure I agree with your post.

I don't think the example you gave is a good one to debunk his argument against dynamic typing reducing code volume. First and foremost, what do the two code blocks you gave have to do with the "dynamic" nature of Perl and the "static" nature of Java? It seems to me that the gain has more to do with other aspects of the languages.

First off: it seems unfair to have the "import" line in the Java program; surely it isn't because Perl is dynamic that file operations are primitive. Likewise, what does automatic file closing have to do with static vs. dynamic languages? I'll let Java absorb that feature as well. And surely it is in the nature of a scripting language (Perl) to allow programs with no explicit modular structure, while Java (as an OO language) requires class definitions. Nothing about class definition seems to highlight the static-ness or dynamism of a language. I've also sugared this up a bit by eliminating the extra file output stream variable. I haven't Java'd for a while, but I think I got it right.
Here is my modified Java from your example:
PrintStream pStream; try{ pStream = new PrintStream( new FileOutputStream("somefile.txt")); pStream.println("This is written to a file"); catch (Exception e) { System.err.println ("Error writing to file " e); }
To me, this seems a lot more reasonable for comparison. Perl no longer holds an obvious upper hand on code length, especially considering that we can drop the Java example from eight lines to five with some whitespace manipulation.

As far as maintainability goes, I don't see how the Perl code is much more maintainable than the Java. Enlighten me?

Overall, I agree with you that slinging mud at one side or the other isn't productive; both "sides" want the same thing and can learn from each other. I just didn't think your example was very convincing.

~dewey
  • Comment on Re^2: Interesting read: "Why I use perl and still hate dynamic language weenies too"
  • Download Code

Replies are listed 'Best First'.
Re^3: Interesting read: "Why I use perl and still hate dynamic language weenies too"
by grinder (Bishop) on Apr 17, 2007 at 20:13 UTC
    Perl no longer holds an obvious upper hand on code length, especially considering that we can drop the Java example from eight lines to five with some whitespace manipulation.

    I quite agree. As I was reading your deconstruction of the Perl/Java comparison, I thought about some code I wrote the other day.

    I'm dealing with a big system at the moment, and in one place I have some database queries that return a dozen records or so of a thousand or more columns. I wanted to look at the result sets in Excel to trace a bug. So I extracted the query and recorded the results as a tab-delimited file. Load it into Excel.

    Boom.

    Turns out Excel has some really feeble limit on the number of columns a spreadsheet may contain. So I scratched my head for a moment, and thought... hmm, just have to transpose the rows and columns in the file, and I can load the transposed data in Excel and get on with the job.

    I was going to paste the code here, but then I realised that it's sitting on a Windows server at work, so I'd have to log in through a VPN and dick around to get it out.

    And then it occurred to me that if it took me about two minutes to write the code then, I could rewrite it again from memory. Here's the code, or something close to what I wrote. I typed this in, and compiled it, and it ran the very first time. I had to ponder the push statement for about 10 seconds, but that's it. And here it is:

    use strict; use warnings; my @trans; while (<DATA>) { chomp; my @row = split /\t/; push @{$trans[$_]}, $row[$_] for 0..$#row; } print join( "\t", @$_ ), "\n" for @trans; __DATA__ A B C D E F G H 1 1 2 3 8 0 7 9 3 5 3 3 5 5 3 3

    So there you have it. I imagine something like that is not going to come out at even 20 lines of Java, but if you want to take a stab at it, I'd be very interested at seeing even a rough sketch.

    I'm not saying that my code is particularly clever or efficient, but it solved a specific problem in about as much time as it took me to write the code (although to be fair I did have a couple of off-by-one errors the first time around).

    That's why I program in Perl.

    • another intruder with the mooring in the heart of the Perl

      I think I see what you mean. I'm going to look at Java stuff, but I really don't know exactly how I would go about it... probably load up the file and use a foreach or something along those lines. I'll take a crack at it sometime later (I have a lot of homework and I should really stop monking around!)

      ~dewey
      You probably haven't realized that likely thousands of Excel users have tried to figure out how to do this using VBA and spent hours beating their heads on the desk. I'm taking your code and putting it in the top of my code toolbox.++
Re^3: Interesting read: "Why I use perl and still hate dynamic language weenies too"
by ikegami (Patriarch) on Apr 17, 2007 at 15:43 UTC

    That code example was a very poor pick. The only data involved are constant string literals arguments. How can one show a typed language requires more code than an untyped language using code without using any data structures?

      I agree 100%. I'd like to see a comparison of code that doesn't rely so heavily on intrinsic functions. How about retrieving a web page, parsing out a field from it, and updating a record in a database?

      A word spoken in Mind will reach its own level, in the objective world, by its own weight

        (I meant to include this in my previous post.)

        One big difference is the ability to create heterogeneous lists with ease in untyped language. That allows us to create powerful general purpose functions. For example, compare

        # "pack" in an untyped language. my $packed = pack('c N c/a*', $c, $i, $s); # "unpack" in an untyped language. my ($c, $i, $s) = unpack('c N c/a*', $packed);

        vs

        # "pack" in an typed language. Array<Object> unpacked; unpacked.push(c); unpacked.push(i); unpacked.push(s); String packed; pack(packed, "c N c/a*", unpacked); # "unpack" in a typed language. Array<Object> unpacked; unpack(packed, "c N c/a*", unpacked); char c = unpacked[0]; int i = unpacked[1]; String s = unpacked[2];

        I don't care so much about the difference in *code size*. The size is not that much different. (80% seems ridiculous.) In fact, the code is not that much different. The real difference is in the amount of *hassle*. Almost all of the extra code needed in a typed language is very repetitive.

        In order to hide the extra code and avoid more hassle, you end up creating (repetitive) special-purpose functions as shown below. Of course, this is a hassle as well.

        # "pack" in a typed language. Func pack_my_format(String& packed, char c, int i, String s) { Array<Object> unpacked; unpacked.push(c); unpacked.push(i); unpacked.push(s); pack(packed, "c N c/a*", unpacked); } pack_my_format(String packed, c, i, s); # "unpack" in a typed language. Func unpack_my_format(String packed, char& c, int& i, String& s) { Array<Object> unpacked; unpack(packed, "c N c/a*", unpacked); c = unpacked[0]; i = unpacked[1]; s = unpacked[2]; } unpack_my_format(packed, char c, int i, String s);

        Note: For the typed language, I used a mixture of C, C++, Java, Pascal and Perl that keeps the code as small as possible. Features include implicit type conversion, autoboxing, object allocation without "new", no separation of variable declarations and code, templates or generics, a Variant type, etc.

Re^3: Interesting read: "Why I use perl and still hate dynamic language weenies too"
by hardburn (Abbot) on Apr 17, 2007 at 19:20 UTC

    IMHO, the real savings for dynamic vs. static languages is in how it changes your thinking patterns. For instance, when confronted with a problem that involves filtering out duplicate strings, programmers for dynamic languages reflexively reach for an associated array (a hash in Perl, but not necessarily implemented with a hash algorithm in other languages). Users of static languages tend to create their own solutions, even if they have something like an associated array readily at hand (like java.util.Hash). This nearly always results in the dynamic language implementations being smaller, clearer, and more robust.

    Of note, I don't think users of true strongly-typed languages have the same problems.


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

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://610557]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others meditating upon the Monastery: (4)
As of 2024-03-29 15:38 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found