[MLUG - DISCUSSION] Re: [MLUG] guess what

[Jonathan King <EMAIL:PROTECTED>]

[I moved this to discussion.]

On Thu, 1 Apr 2004, Michael wrote:

> >Michael, if you don't know what you're talking about, just go back
> >to playing with your two notebooks.
> >
> Wow, that's kind of a mean tone to take. 

So glad you noticed.  What I was objecting to (which you deleted) 
was this statement:

# A lot of large projects written in Perl should be rewritten in
# Python but those things should never have been written in Perl to
# begin with. Perl just isn't well suited to large complex projects.

Sorry, but this is just wrong.  You don't support the statement, and 
lots of people can toss so many counterexamples back at you that 
it's just silly.  Not every project is a great fit for perl, but 
project size really doesn't have that much to do with it.

> I've been coding most of my life. If there is one thing I do know
> about it's coding. No reason to be so defensive.

I didn't say you didn't know coding.  I did say you don't know as 
much about what languages are suitable for large projects as you 
think you do.

Now on an unrelated topic:

> The other point I remember you raising was whitespace. This one is
> sort of weird and definately throws most experienced programmers
> into "that's just wrong"  mode but when you try it it really works
> quite well.

It doesn't fail to work as spectacularly as some might suppose, but, 
man, there is a *reason* why experienced programmers are suspicious.  
As a cognitive psychologist, I guess I would phrase this as the
principle that "things that are meaningful should be visible" and 
"thing that mean different things should not look the same".  
Whitespace is a dubious choice to have for both block structure and 
statement delimitation if you follow these heuristics.

[Snip; now about how code gets sucky.]

> The problem isn't sucky programmers that write crappy code. The
> problem is good programmers that write good code that over time
> degrades into crap. Python forces a much cleaner syntax and thus
> degrades less than most other languages. You can still write
> crappy Python but good Python is easier to maintain.

I don't follow this.  Are you talking about some kind of spontaneous
decay, about code getting quirked up through maintenance, bitrot, or
what?  As far as "clean syntax" goes, the lack of VISIBLE block
structuring does not give me that feeling.  Again, the really bad
features of perl in this regard are:

  1) $var syntax is quaint at best.
  2) function definition syntax without named formal parameters is
     a really, Really, REALLY bad idea.
  3) Indirect object syntax (print foo $bar) was a mistake.

The second one hasn't been fixed yet due to hubris and the fact that 
some people (but not me) thought Perl6 (which fixes (2)) would be 
out Any Day Now.  Interestingly, I think (2) is also fixed by a Perl 
module somewhere...ah here it is:

  Perl6::Parameters

My guess is that this becomes standard, the new class syntax becomes
standard, maybe $alway_needed goes away and most of the other
pie-in-the-sky Perl6 stuff never gets anywhere.
 
> The syntax is much less dense than Perl and the language takes an 
> entirely different approach. Perl likes to say that there are many ways 
> to do something. Python likes to say that there is only one way to 
> something.

The problem being that those are just slogans.  And it just ain't 
strictly true as far as Python goes. :-)  

[more patient snippage]

> Ruby is Perl for people that want to be a little more like Python. 

Not exactly.  Ruby doesn't have problems 1-3 above, but it really 
does have some *very* different features from both Perl and Python.  
Alas, it doesn't have CPAN, and that is kind of a big deal.

> Javascript sucks. It's popular but it's a pain in the ass to write
> real programs in. I can't really say exactly why but Javascript
> just doesn't feel like a well designed language.

It was put together in a rush during the height of the dot-com boom.  
Also, there's no question that prototype-based languages can take
some getting used-to. The "real" Javascript that might have been is
Ecmascript 4, and that might actually happen now.  Probably before 
Perl6 comes down the pike.

So I'm done now.  Sorry to offend you too much, but I have a low
threshold for unsupported statements today since I'm grading
undergrad papers.

jking




> 
> >The opposite is also supported by Perl modules.
> >  
> >
> True, but why would you want to embed a language good for large 
> structural programs into a language good for small parsing programs? You 
> can embed Python into an HTML rendering engine for inline Python 
> processing (mod_python actually allows something like this) but IMO that 
> doesn't make any sense either.
> _______________________________________________
> members mailing list
> EMAIL:PROTECTED
> http://mlug.missouri.edu/mailman/listinfo/members
> 

_______________________________________________
discussion mailing list
EMAIL:PROTECTED
http://mlug.missouri.edu/mailman/listinfo/discussion