[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: another take on hackers and painters

At 4:25 PM -0400 5/23/03, Anton van Straaten wrote:
>Dan Sugalski wrote:
>>  You forgot the fact that we're responsible for global warming,
>That one's a given, given all the CPU cycles Perl programs have burned.  In
>fact, running Perl programs on multi-GHz machines should probably have been
>banned by the Kyoto Treaty!  :oP

Heh, but I think Lisp still has us beat, even now--I remember what 
those old 11/780s burned for power. And neither of us can hold a 
blowtorch to Doom... :-P

>  > imperialism, the decline in the moral fibre of today's youth, and
>>  dadaism. Oh, and pop art is our fault too. Sorry about that one.
>>  Seriously, this isn't our (or, rather, perl's) concern. Perl isn't a
>>  teaching language, it doesn't much care what anyone's pet theories
>>  are, and we're a cranky lot anyway.
>Most languages, including Perl, are teaching languages, whether their
>authors want them to be or not.  Languages shape the way people think,
>especially for people who primarily use a single language.  Perl has
>certainly had a strong effect on the way many people think about

The second part of that paragraph is dead-on--language does affect 
how people think. It's the power and the limit of language, or of 
people. (Or both. Hard to say)

The first part of the paragraph, though, is nonsense. Perl is no more 
a teaching language than APL, Japanese, or Klingon. It's a language 
in which you learn things, but that's *not* the same. The point of 
perl is not to teach anyone anything, any more than the point of 
James Joyce's "Ulysses" was to teach people something. It's a 
language designed to let those of us comfortable with it to use it to 
solve our problems while getting out of the way. No language is 
perfect, and all languages annoy someone. Perl is *not* a good fit 
for everyone--people try it and decide not all the time, just the 
same as they do with C, Python, Lisp, Ruby, COBOL, or Forth. (Well, 
maybe not all the time for some of those, but still)

Most languages aren't teaching languages. Most languages *shouldn't* 
be teaching languages. IMNSHO, at least.

>  > If you don't like what we're doing or how we're doing it, that's
>>  fine. Do it better so people do it your way instead. Heck, if you do
>>  it better then *we'll* do it your way too. (That whole 'practical'
>>  thing)
>We (for some definition of we) *are* doing it better, we just haven't
>convinced you of that, yet.

You don't need to convince me. My opinion, bluntly, isn't that 
important, completely putting aside the fact that I'm generally just 
an implementor. I make the semantics work, I don't decide what they 

What you need to do is convince enough people who actually write 
code, or the few people who create languages. Tag Larry, or Guido, or 
Matz, or Guy, or the C# folks, or write a language that does what 
people need well enough that folks use it. (The only place you need 
to talk to me is if you want it to run on parrot, but those 
conversations are usually "I need Parrot to do X" "Sure, no problem")

>  But since you've been lusting after
>continuations, I'd say the transformation process hasn't got long to go -
>any day now, you'll be wishing you could do away with those pesky mutable
>>  Perl lexically scopes the warnings and/or errors for conversion
>>  error checking, which works nicely for us.
>IOW, you can lexically change the meaning of your operators.  Hmm...  I
>think that makes perfect sense for controlling warnings for things like
>deprecated features, but makes less sense as a way to modify the semantics
>of your program & language.

It makes *more* sense modifying the semantics of your language, for 
two reasons.

First, it means that you can add in a new language element relatively 
easy. (Compared to messing with the yacc grammar and compiler, at 
least, as well as usually making distribution easier to folks to 
test) A feature not to be underestimated.

Second, it means you can use a completely different language, inline 
with other code. To wit:

    my $foo = START LISP {
      (foo 1 (bar baz 12)
	    (+ 5 cron_interval)
             (sqrt $bar)

or something not unlike that. I don't often want to drop to another 
language mid-stream, but there are times when it's useful.

Minor tweaks just generally don't happen. It's a lot easier to modify 
the behaviour of individual things through other mechanisms, such as 
operator overloading. (Which you could argue is a bad thing too, but 
once again it's a feature so great it can only be used for good or 

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk