Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Did I Choose Perl When Building Crowdtilt?

dsog.info

Post reply on HN
Print view View original

131–140 of 143 posts

Re: Why Did I Choose Perl When Building Crowdtilt?

#131

Post by chromatic »

gdog wrote: post #127
chromatic wrote: post #125

Earlier quoted context omitted.

In Ruby can write `puts Object.new.inspect` to get something like `# `. Does that mean Ruby has pointers? If you can't do math on it to access other parts of memory, it's not a pointer in the C sense.

But you deference the addresses just C. I'd say it's more a like a pointer than not. And this is where I have I issue. You don't deference addresses in Ruby or Python. When you are writing data structures in Perl you have constantly have to deal with extra syntax (and mental work). I'd say about 10% or so of my syntax errors come from this and it's completely unnecessary. It's a huge pain (to me atleast).

I'd say it's more a like a pointer than not.

Are you familiar with the distinction between "pass by reference" and "pass by value"? If you call everything which behaves in the former way a pointer, I think you confuse an implementation strategy with a language construct and you lose an important feature of C pointers.

What you see in Perl (and Ruby) is a unique identifier that happens to be a memory address. It could be anything else, but the memory address is an identifier that's essentially free to generate. That's it. It's otherwise irrelevant. You have to write code in a language which has pointers to do anything with that information, and even then you have to cast it to a real pointer to do so.

We could discuss Perl 5's dereferencing syntax (it's ugly, no argument there) but that's a syntax issue and not an implementation concern.

Re: Why Did I Choose Perl When Building Crowdtilt?

#132

Post by gdog »

chromatic wrote: post #131
gdog wrote: post #127

Earlier quoted context omitted.

But you deference the addresses just C. I'd say it's more a like a pointer than not. And this is where I have I issue. You don't deference addresses in Ruby or Python. When you are writing data structures in Perl you have constantly have to deal with extra syntax (and mental work). I'd say about 10% or so of my syntax errors come from this and it's completely unnecessary. It's a huge pain (to me atleast).

I'd say it's more a like a pointer than not. Are you familiar with the distinction between "pass by reference" and "pass by value"? If you call everything which behaves in the former way a pointer, I think you confuse an implementation strategy with a language construct and you lose an important feature of C pointers. What you see in Perl (and Ruby) is a unique identifier that happens to be a memory address. It could…

I'm familiar with C and understand why pointers are there. I understand what you are saying and you make a fair point. I'll take back my statement Perl has pointers. Claiming Perl has pointers is very murky (although it has some truth to it). The heart of what bothers me is you have to deference addresses (similar to what happens with pointers in C) in Perl. This shouldn't exist in a scripting language syntax. It lots of unnecessary syntax, compile errors, and mental hoops you have to go through when coding. Ruby and Python don't have this serious (I think so at least) wart.

> Are you familiar with the distinction between "pass by reference" and "pass by value"? If you call everything which behaves in the former way a pointer, I think you confuse an implementation strategy with a language construct and you lose an important feature of C pointers.

Re: Why Did I Choose Perl When Building Crowdtilt?

#133

Post by gdog »

gdog wrote: post #127
chromatic wrote: post #125

Earlier quoted context omitted.

In Ruby can write `puts Object.new.inspect` to get something like `# `. Does that mean Ruby has pointers? If you can't do math on it to access other parts of memory, it's not a pointer in the C sense.

But you deference the addresses just C. I'd say it's more a like a pointer than not. And this is where I have I issue. You don't deference addresses in Ruby or Python. When you are writing data structures in Perl you have constantly have to deal with extra syntax (and mental work). I'd say about 10% or so of my syntax errors come from this and it's completely unnecessary. It's a huge pain (to me atleast).

I don't understand why this is getting down voted.

Re: Why Did I Choose Perl When Building Crowdtilt?

#134

Post by chromatic »

gdog wrote: post #132
chromatic wrote: post #131

Earlier quoted context omitted.

I'd say it's more a like a pointer than not. Are you familiar with the distinction between "pass by reference" and "pass by value"? If you call everything which behaves in the former way a pointer, I think you confuse an implementation strategy with a language construct and you lose an important feature of C pointers. What you see in Perl (and Ruby) is a unique identifier that happens to be a memory address. It could…

I'm familiar with C and understand why pointers are there. I understand what you are saying and you make a fair point. I'll take back my statement Perl has pointers. Claiming Perl has pointers is very murky (although it has some truth to it). The heart of what bothers me is you have to deference addresses (similar to what happens with pointers in C) in Perl. This shouldn't exist in a scripting language syntax. It lot…

The heart of what bothers me is you have to deference addresses...

I don't understand why you keep saying that. They're not addresses.

From the language side of things, they're first class scalar entities just like strings and numbers. From Perl 5 they have nothing to do with memory addresses. (You might as well suggest that a nested data structure in any language without pointers is "dereferencing addresses", or that accessing object attributes is "dereferencing addresses".)

You can't write in Perl something like:

    my $reference = 'ARRAY(0x1234abcd)';
... and expect to access the array at that point in memory even if you stringified an array reference and saw that its stringification included that hex address. References are not pointers. They don't dereference addresses.

From the internals side, they're SVs, just like all other scalars in Perl 5. An SV is a C structure. Yes, the internals use pointers, but so does any other virtual machine implementation.

(Okay, you can write code like I said above, but to make that work correctly, you have to write C to do it, because C allows direct access to memory by address.)

Re: Why Did I Choose Perl When Building Crowdtilt?

#135

Post by gdog »

chromatic wrote: post #134
gdog wrote: post #132

Earlier quoted context omitted.

I'm familiar with C and understand why pointers are there. I understand what you are saying and you make a fair point. I'll take back my statement Perl has pointers. Claiming Perl has pointers is very murky (although it has some truth to it). The heart of what bothers me is you have to deference addresses (similar to what happens with pointers in C) in Perl. This shouldn't exist in a scripting language syntax. It lot…

The heart of what bothers me is you have to deference addresses... I don't understand why you keep saying that. They're not addresses. From the language side of things, they're first class scalar entities just like strings and numbers. From Perl 5 they have nothing to do with memory addresses. (You might as well suggest that a nested data structure in any language without pointers is "dereferencing addresses", or tha…

I'm sorry. I'm actually a little dyslexic and if a wrong word slips by the spell check I can get myself in trouble. s/deference/dereference/.

Consider: my $x = [1,2,3]; print "@$x\n";

In the second line I consider "$" dereferencing the "address" that points to an array. I don't know anything about the internals of Perl virtual machine and what that "address" really means. But to the common programmer it seems like you have to do the same work you would have do in C dereferencing pointers. Python and Ruby have no such operator, right? This unnecessary work is what I'm complaining about (and all the associated extra syntax).

Re: Why Did I Choose Perl When Building Crowdtilt?

#136

Post by singingfish »

uvtc wrote: post #130
caycep wrote: post #60

Does anyone have a good handle on how good perl interpreters are, or whether there are perl "compilers" that do something fancy, i.e. turn it into bytecode? What with all the fancy compiler/interpreter technology going into things like V8, Nitro, pypy, cpy, etc, would be interesting to see how perl is keeping up in terms of speed.

Perl 5 has been around for a while and has seen quite a bit of optimization. It's fast.

And the regex engine is amazingly fast (there is one faster I believe). Try throwing a 20,000 item list at this little program, and then use the resulting regex to match another 20,000 items and see how long it runs (hint: not very, considering):

    #!/usr/bin/env perl
    use warnings;
    use strict;
    use Regexp::Assemble;
    my $ra = Regexp::Assemble->new;
    while () {
        chomp;
        $ra->add($_);
    }
    print $ra->re . "\n";

Re: Why Did I Choose Perl When Building Crowdtilt?

#137

Post by ralph »

ralph wrote: post #43
EvanKelly wrote: post #37

Earlier quoted context omitted.

"There are only two kinds of languages: the ones people complain about and the ones nobody uses" - Bjarne Stroustrup

He was very biased; it counts for little.

Not sure why it got all the down votes. Since Visual BASIC faded away there's been two mainstream languages that have come in for much complaint; C++ and PHP. All languages suffer some valid criticism as none are perfect but the weight of criticism for these two suggest much is deserved, it is in my opinion. Consequently, that the author/facilitator of C++ has a fun quote to dismiss the large-scale criticism is fun but "counts for little" as he's biased.

Re: Why Did I Choose Perl When Building Crowdtilt?

#138

Post by UncleOxidant »

chromatic wrote: post #41
UncleOxidant wrote: post #34

"As far as I know, Perl is one of the only languages that can evolve via 3rd party modules." Ummm... What?! There's a long tradition creating DSLs in the Ruby community. Lisp/Scheme/Clojure have macros. OCaml has campl4. I'm sure there are many others.

I'll give you macros, but if you define DSLs as "chained methods", many languages have DSL supports. The author's talking about Perl's support for mangling the language itself through third party modules.

Sure, but the intent of the author seems to be to say that the language can be molded in ways that make it easy to apply in specific domains. Whether that's with macros or with a DSL-ish approach you're pretty much achieving the same end result. Ruby's blocks make it fairly easy to create DSLs that look like you've actually changed the underlying language in some way - Rails makes heavy use of these features, for example.

Re: Why Did I Choose Perl When Building Crowdtilt?

#139

Post by singingfish »

singingfish wrote: post #136
uvtc wrote: post #130

Earlier quoted context omitted.

Perl 5 has been around for a while and has seen quite a bit of optimization. It's fast.

And the regex engine is amazingly fast (there is one faster I believe). Try throwing a 20,000 item list at this little program, and then use the resulting regex to match another 20,000 items and see how long it runs (hint: not very, considering): #!/usr/bin/env perl use warnings; use strict; use Regexp::Assemble; my $ra = Regexp::Assemble->new; while ( ) { chomp; $ra->add($_); } print $ra->re . "\n";

Well I'm told that newer versions of perl optimise alternations internally and this is redundant now:

   my $re = join "|", @list;
   my (@matches) = $txt =~ /$re/g;
Quicker and faster...

Re: Why Did I Choose Perl When Building Crowdtilt?

#140

Post by kbenson »

gdog wrote: post #133
gdog wrote: post #127

Earlier quoted context omitted.

But you deference the addresses just C. I'd say it's more a like a pointer than not. And this is where I have I issue. You don't deference addresses in Ruby or Python. When you are writing data structures in Perl you have constantly have to deal with extra syntax (and mental work). I'd say about 10% or so of my syntax errors come from this and it's completely unnecessary. It's a huge pain (to me atleast).

I don't understand why this is getting down voted.

Because some of your assertions are factually incorrect. That's a valid reason to downvote.
Post reply on HN