The Problem with Perl

[Arndt Jonasson]

??? They are the same?

int foo(int x) {
return (x*2);
}

char foo() {
return "A";
}

float foo() {
return 100.99;
}

All completely different functions in C. The name 'foo' may be the same
but as far as the compiler is concerned, they are different functions.
Are you saying these three functions above are the same? I believe you
are suffering from learning an interpreted language before learning a
true language like C or C++.

Since someone might actually believe this lie... Here is what two C
compilers have to say about your code above:

t1.c:5: conflicting types for `foo'
t1.c:1: previous declaration of `foo'
t1.c: In function `foo':
t1.c:6: warning: return makes integer from pointer without a cast
t1.c: At top level:
t1.c:9: conflicting types for `foo'
t1.c:5: previous declaration of `foo'

cc: "t1.c", line 5: error 1584: Inconsistent type declaration: "foo".
cc: "t1.c", line 5: error 1711: Inconsistent parameter list declaration for "foo".
cc: "t1.c", line 6: warning 526: Pointer implicitly converted to integral value in assignment.
cc: "t1.c", line 9: error 1584: Inconsistent type declaration: "foo".
cc: "t1.c", line 9: error 1711: Inconsistent parameter list declaration for "foo".

It may be C++, but it's not C.

 

[Ted Zlatanov]

I believe you are suffering from learning an interpreted language
before learning a true language like C or C++.

I believe you are suffering from learning a compiled language before
learning a true language like assembler.

Ted

 

[Jussi Jumppanen]

The question here is not whether you'd choose a small team of
good programmers or a large team of mediocre ones.

IHMO this question is well answered by book "The Mythical Man Month".

If I remember correctly, it basically says it is not possible to
just throw bodies at task in the hope of get the work done more
quickly. The common misconception is that as you add bodies a
project, the work load can be shared, thus the task gets done
faster.

The book shows that adding an extra body always comes at some
cost. The cost refers to things like management, planning,
co-ordination communication etc etc.

Thus there comes a point where this extra cost outweighs the
gain or the extra body. Once this point is reached adding
extra bodies actually hinders the project.

Jussi Jumppanen
Author of: Zeus for Windows (New version 3.94 out now)
"The C/C++, Cobol, Java, HTML, Python, PHP, Perl programmer's editor"
Home Page: http://www.zeusedit.com

 

[Jussi Jumppanen]

It may be [true] C++, but it's not [true] C.

This is a bit harsh. It is true that the C compiler might
well compile the code, but it does so only under duress.

As any good C programmer knowns it is dangerous to ignore
or cast away warnings, as they are a strong indication that
something is not quite right with the code.

IMHO the original poster is correct.

The C++ compiler gets it right and refuses to compile the code
because they are functions are different, while the C compiler
the compiles the code "saying I hope you know what you are doing,
because I certainly don't, but here is your compile code anyway".

Jussi Jumppanen
Author of: Zeus for Windows (New version 3.94 out now)
"The C/C++, Cobol, Java, HTML, Python, PHP, Perl programmer's editor"
Home Page: http://www.zeusedit.com

 

[Jussi Jumppanen]

It may be C++, but it's not C.

This is a bit harsh.

It is true that the C compiler might not produce any errors for
the code but it only compilers the code under duress.

As any good C programmer will tell you it is very dangerous to
ignore or cast away warnings, as they are a good indication
that something is very wrong with the code.

IMHO the original poster is correct.

The C++ compiler gets it right and refuses to compile the code
because they are different, while the C compiler the compiles
the code "saying I hope you know what you are doing, because I
certainly don't, but here it is compile code anyway".

Jussi Jumppanen
Author of: Zeus for Windows (New version 3.94 out now)
"The C/C++, Cobol, Java, HTML, Python, PHP, Perl programmer's editor"
Home Page: http://www.zeusedit.com

 

[A. Sinan Unur]

??? They are the same?

int foo(int x) {
return (x*2);
}

char foo() {
return "A";
}

float foo() {
return 100.99;
}

All completely different functions in C. The name 'foo' may be the
same but as far as the compiler is concerned, they are different
functions. Are you saying these three functions above are the same? I
believe you are suffering from learning an interpreted language before
learning a true language like C or C++.

You have now certified yourself as an ignorant troll who does not know
anything about C:

D:\Dload> gcc -Wall -c t.c
t.c:5: error: conflicting types for `foo'
t.c:1: error: previous declaration of `foo'
t.c: In function `foo':
t.c:6: warning: return makes integer from pointer without a cast
t.c: At top level:
t.c:9: error: conflicting types for `foo'
t.c:5: error: previous declaration of `foo'

*PLONK*

Sinan.

 

[A. Sinan Unur]

char foo() {
return "A";
}

Here you declare foo as returning a char, but instead you return a pointer
to const char. Hmmm ...

....

I believe you are suffering from learning an interpreted language
before learning a true language like C or C++.

The definition of foo above is not legal in C or C++.

I think you are suffering from not having learned C or C++.

Sinan.

 

[Charlton Wilbur]

JJ> This is a bit harsh.

JJ> It is true that the C compiler might not produce any errors
JJ> for the code but it only compilers the code under duress.

JJ> As any good C programmer will tell you it is very dangerous to
JJ> ignore or cast away warnings, as they are a good indication
JJ> that something is very wrong with the code.

JJ> IMHO the original poster is correct.

No, the original poster is *wrong*. The code he offers as an example
is not valid C. Valid C is defined not by "what a compiler will
accept without complaining" but by a fairly detailed specification.

JJ> The C++ compiler gets it right and refuses to compile the code
JJ> because they are different, while the C compiler the compiles
JJ> the code "saying I hope you know what you are doing, because I
JJ> certainly don't, but here it is compile code anyway".

In C++, functions with the same name but with different argument lists
are different functions. foo (int, float) and foo (int) are different
functions in C++. I don't recall whether having a different return
type is sufficient to differentiate two otherwise identical functions,
and I can see reasonable arguments either way. If it is sufficient,
then the code the OP posted was valid C++ and not valid C, which is
exactly what Mr Jonasson claimed. The original poster does not seem
to distinguish between C and C++, which is a warning sign in itself,
and offers as an example of valid C something that is in fact *not*
valid C. I don't think the word "correct" can be successfully
redefined to apply to that.

There *are* clear specifications for what is valid C and valid C++,
after all, and they're different.

Charlton

 

[Chris Mattern]

I'm wondering why progamers don't have portfolos. That is why your
not asked to include on CD a source from a project or two so people
can see your style and how good your coding is.

Historically, that's been because programmers have done all their
serious coding under contract. Their code belongs to their employers and
it's not legal for them to cart around a copy of it for their
personal purposes. This is one reason why Open Source works;
it gives a good programmer a chance to write working, professional
code that he can carry around to show prospective employers: "See,
I wrote *this*. Thousands of people use it regularly, and if
you can appreciate good source code, you can see I have good
style."
--
Christopher Mattern

"Which one you figure tracked us?"
"The ugly one, sir."
"...Could you be more specific?"

 

[Charlton Wilbur]

?> Ok the best place that explians this is "The Mythical Man
?> Month" however Paul Graham has a number of excelent essays on
?> the subject.

Yes, I've read "The Mythical Man-Month." I don't believe it addresses
the issue of programmer skill as definitively as you think it does.

If you have brilliant, productive, self-disciplined programmers, you
can do a great deal with three of them. But in the real world, you
can't guarantee a steady supply of brilliant, productive,
self-disciplined programmers, and you can't even reliably tell whether
a programmer is *truly* briliant, productive, and self-disciplined, or
just good at faking it in the interview, until you hire him and put
him to work. As a result, any approach to software development that
assumes you can start out with brilliant, productive, self-disciplined
programmers is doomed to failure unless it allows for a lot of
replacement and turnover among employees until you manage to assemble
a set of brilliant, productive, self-disciplined programmers.

As a result, development processes and development tools need to work
for mediocre programmers as well as brilliant ones. You'll never get
the same quality of work from a mediocre programmer as you will from a
brilliant one -- that's why one is mediocre and the other is
brilliant. The problem is, if you use tools that require one to be
brilliant or exceptionally self-disciplined to use them to their
utmost -- and freeform languages are *definitely* in that category --
then you set yourself up for disaster if you don't manage to find
brilliant and self-disciplined programmers.

?> If the software project is getting so big that its infeasable
?> to assign a team of 2 to 3 people to it (I think that 5 is a
?> rather large team for a software project) then it should be
?> split up into sections that are large enought for 2-3 people to
?> work on. (And the interfaces between these sections should be
?> precisely defined and supported with test sweets).

Which is a beautiful notion -- but the tasks of partitioning and
defining interfaces are the hard part of the job. Once you've got the
problem nicely broken down, the interfaces between sections of the
problem defined, and the test suites written, the rest of the
programming is pretty trivial. You're solving the problem by assuming
that the hardest part of it will be easy to do up-front, and that just
ain't the way it works out. (Maybe in the universe where you can get
users to completely and accurately specify the program they want....)

Beyond that, in the real world many software projects require more
than 5 people. Your examples of small software projects - Unix and
Perl - are both currently developed by teams of *many* more than five
people. (How many people have contributed patches to the Linux
kernel? How many people are on the core development teams for the
BSDs? How many people are on the p5p mailing list?) And that's
*before* the issue of testers, maintainers, and technical writers gets
raised.

Charlton

 

[Wes Groleau]

My best understanding of what they think the problem is that Perl is
"context sensitive". That is it behaves differently when data
changes, if lists slip in where scalars were intended the results may
be wildly different than expected. This wouldn't be true in strongly
typed languages like C or lisp.

C is _not_ a strongly typed language. Sure, a newbie might
be surprised by @LIST being a list sometimes and the size of
the list other times. But C programmers--even experts--are
often surprised by the results of C's implicit automatic casts,
or it's ability to add two positive numbers and get a negative
without complaint.

 

[Wes Groleau]

To me this makes perl a very sloppy language and I certainly wouldnt
use it to process any mission critical data, just leaves to much to

But for a lot of non-"mission-critical" purposes, perl is great.
Heck when it comes to mission-critical, I am highly unlikely to
consider C, either.

 

[Wes Groleau]

Do "Java, Python"... really "hold your hand" to an extent that bad
programming is diminished. If so, that's a good thing. I would still

Sometimes--not always--people who speak of "hand-holding"
with contempt are those that most need their hands held.

(Preferably held a safe distance from the keyboard.)

One question I've heard before: "What do you want to catch
your errors--the compiler or the core dump?"

 

[Wes Groleau]

It can't. C requires that functions be called with the same number of
parameters they're declared with, and that can't be expressed in a CFG.

However, is it still true (I haven't done C in ages)
that in C you can compile a function call without first
compiling the declaration? In which case the compiler
will assume the result is int, and stack as many parameters
as you give it. If it turns out to actually return a float,
"that's life."

If it turns out to pop from the stack more params than
it was called with, that's death.

 

[Tassilo v. Parseval]

Also sprach Wes Groleau:

However, is it still true (I haven't done C in ages)
that in C you can compile a function call without first
compiling the declaration? In which case the compiler
will assume the result is int, and stack as many parameters
as you give it. If it turns out to actually return a float,
"that's life."

This is what happens, yes.

However, there are context-sensitive things in C which cannot be
circumvented. For example, you have to declare variables prior to first
usage.

If it turns out to pop from the stack more params than
it was called with, that's death.

Not necessarily. The only thing guaranteed is that those additional
arguments contain garbage. The following will most likely not segfault.
It even compiles silently (unless additional compiler warnings are
explicitly switched on):

#include <stdio.h>
#include <string.h>

int main (int argc, char **argv) {
bla("string");

}

bla (int i, char *string) {
printf("%s\n", string);
string++;
printf("%s\n", string);
(*string)++;
printf("%s\n", string);
return strlen(string);
}
__END__
dùÿ¿
ùÿ¿
úÿ¿

Tassilo

 

[William Goedicke]

Dear Wes -


Wes> C is _not_ a strongly typed language. Sure, a newbie might
Wes> be surprised by @LIST being a list sometimes and the size of
Wes> the list other times. But C programmers--even experts--are
Wes> often surprised by the results of C's implicit automatic
Wes> casts, or it's ability to add two positive numbers and get a
Wes> negative without complaint.

I often found myself surprised as a newbie C programmer. Regularly it
resulted from my poor use of (loosely typed) pointers in C; my bad as
a programmer.

One difference I've noticed between Perl and C (my two most used
languages) is that one had typing in the scalars and the other has typing
in the pointers. (Sorry for the C terminology. One types locations in
memory and the other types in (ummm) scalars.)

I find that distinction interesting.

- Billy

============================================================
William Goedicke (e-mail address removed)
Cell 617-510-7244 Office 781-736-4657
AIM goedsole
============================================================

Lest we forget:

"ff0000" (html for bright red) turns out to be as good
an indicator of spam as any pornographic term.

- Paul Graham