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

[Michael <EMAIL:PROTECTED>]

>So glad you noticed.  What I was objecting to (which you deleted) 
>was this statement:
>  
>
Sorry, I try to clip messages as best I can when responding. Can't 
promise to leave exactly what you find relevant in.

># 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.
>  
>
Project size matters with any language. In any language, the larger a 
project, the harder it is to manage the code. Readability and 
reusability I think are the main factors involved. Perl is great at code 
reusability (as shown by the large number of available modules) but 
readability is not good. Perl tends to pack a lot of punch into a small 
space. Great for a small script but not for large projects. Yes, you can 
write Perl that is less dense but it takes conscience effort. Dense code 
is easily munged through repeated minor bug fixes and feature additions. 
It breaks the rule of optimizing to soon. The density of Perl code is my 
primary problem with Perl. My second is that Perl does like to offer so 
many ways to do the same things. That's good for flexibility but tends 
to lead to confussion especially in large projects.. Of course a lot of 
that can be offset by good programming practices, such as commenting 
code, but it's still a concern of developing in Perl. So weather or not 
you agree with my view, that is the basis for my statement that Perl is 
bad for large projects. Obviously, Perl is a very popular language but 
I'm certainly not the only convert away from the Perl way of doing 
things. With each large project I do I look for a language a little 
better at code management. I moved  past Asm, C, C++, Lisp, Perl, PHP, 
and several other languages I've used over the years because they, IMO, 
just don't handle the strain of a large project well. I expect 
eventually to move past Python too.. but thus far, again IMO, it's the 
best language I've tried for cleanly managing large projects.

If you want to work with 50,000 lines of Perl then be my guest.

>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.
>  
>
Possibly. But then, IMO, I think you're confussing languages that can be 
made to handle large projects with languages that are well suited to 
large projects. Being able to force a language to do a job or a language 
being popular for a job doesn't make it good at the job.

>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.
>  
>
True, but it's also true that use of braces is easy to mess up. Most 
experienced programs follow strict whitespace guidelines to help them 
keep track of the braces that bound their blocks anyway. Thus you can 
remove the braces and keep the whitespace and the code can function just 
as well with fewer non-essential syntax elements. I'm not quite sure 
what you mean by using whitespace for both block structure and statement 
delimitation. Could you explain what you mean more clearly?

>I don't follow this.  Are you talking about some kind of spontaneous
>decay, about code getting quirked up through maintenance, bitrot, or
>what?
>
Just normal code maintenance. As a result of poor documentation and poor 
understanding of the code. IMO the more readable code is the easier it 
is to understand (either by someone new or after an absence) and thus 
the less likely it is to get screwed up by progressive 
misunderstandings. Good documentation, in any language, is essential but 
having the code easily readable makes a large difference too. Language 
features such as objects, functions, and namespaces make a large 
difference but so does the sparseness (and what I call fluffiness.. 
clear space around each token) of the code.

>  As far as "clean syntax" goes, the lack of VISIBLE block
>structuring does not give me that feeling.
>
The whitespace for block structures benefits the sparseness of code. I'm 
not entirely sold on this over braces but as I said I don't think it is 
any worse than braces.

>The problem being that those are just slogans.  And it just ain't 
>strictly true as far as Python goes. :-)
>
True, but they are the design criteria of the languages. Perl's is 
probably the easier criteria to meet and thus it meets it better.  I 
happen to like Python better because it's design criteria is closer to 
that I'm looking for. I do have a couple disagreements with Python 
though. Mostly A.) The lack of a switch statement and B.) The lack of a 
ternary operator.

>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.
>  
>
I haven't really looked at Ecmascript lately but I'll agree that 
Javascript feels wrong probably because it's design was rushed. Also 
because the battle between Netscape and IE left Javascript feeling 
almost as fragmented as HTML. I think Mozilla's opensource 
implementation of Javascript that is easily usable as it's own library 
(without Mozilla) could help improve Javascript as a whole.

>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.
>  
>
Not offended. More amussed. I had no reason not to make unsupported 
statements given this wasn't a formal posting. Just suggesting that 
learning Python as well as those other mentioned languages could be 
useful. Not interested in holding a real flame war over which language 
is best. Just expressing my opinion.
_______________________________________________
discussion mailing list
EMAIL:PROTECTED
http://mlug.missouri.edu/mailman/listinfo/discussion