Is Perl open source?

[soup_or_power]

If much of perl is implemented in C, why should we prefer Perl over C
for performance critical projects?
Please don't get me wrong. I prefer Perl over C if performance is not
the issue.
Thank you.

 

[John Bokma]

wrote:

Don't use subjects that are have no relation to the body of your message.

If much of perl is implemented in C, why should we prefer Perl over C
for performance critical projects?

Who says "we" do?

 

[Tad McClellan]

Subject: Is Perl open source?

Please put the subject of your article in the Subject of your article.

Your article has nothing to do with open source.

If much of perl is implemented in C, why should we prefer Perl over C
for performance critical projects?

We shouldn't.

I would think that would be obvious.

Did someone say otherwise?

 

[xhoster]

If much of perl is implemented in C, why should we prefer Perl over C
for performance critical projects?

Because 1 plus 3 is less than 10 plus 1.

Time spent writing and righting the program is time during which the
program cannot be "performancing".

Please don't get me wrong. I prefer Perl over C if performance is not
the issue.

I prefer to wash my hair with shampoo rather than with Perl. It is
not something to be ashamed of.

Xho

 

[brian d foy]

If much of perl is implemented in C, why should we prefer Perl over C
for performance critical projects?

You really can't answer this question without knowing about the
particular project. No tool is going to be the best thing to use in
every situation.

Perl does have many ways to let you drop down to C if you decide that
you really need to do that.

 

[John]

Xho wrote:

I prefer to wash my hair with shampoo rather than with Perl. It is
not something to be ashamed of.

---

Or you could wash your hair with Prell. (Practical rinsing employs less
lather).


Yeah, yeah, off-topic.

 

[Josef Moellers]

Because 1 plus 3 is less than 10 plus 1.

Time spent writing and righting the program is time during which the
program cannot be "performancing".

A second spent optimizing a frequently used program is many seconds
saved during performance.

 

[Chris Mattern]

A second spent optimizing a frequently used program is many seconds
saved during performance.

Yet it is good to remember that often, that second of programmer's time
is more expensive than the many seconds of machine time that is saved.
--
Christopher Mattern

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

 

[Chris Mattern]

Chris Mattern ([email protected]) wrote on MMMMCCXLIV September
MCMXCIII in <URL)
)) Yet it is good to remember that often, that second of programmer's
time
)) is more expensive than the many seconds of machine time that is saved.


Keep remembering that when your airbag takes a few seconds to inflate.

Generalizing is seldomly correct.

I did say *often*, not *always*. Of course, anybody doing tasks
with hard real-time requirements in Perl is certifiable.

--
Christopher Mattern

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

 

[Wes Groleau]

A second spent optimizing a frequently used program is many seconds
saved during performance.

It used to be said, "A penny saved is a penny earned."

Now, it's more like, "A penny saved is .... ridiculous."

--
Wes Groleau

Guidelines for judging others:

1. Don't attribute to malice that which
can be adequately explained by stupidity.

2. Don't attribute to stupidity that which
can be adequately explained by ignorance.

3. Don't attribute to ignorance that which
can be adequately explained by misunderstanding.

 

[brian d foy]

I did say *often*, not *always*. Of course, anybody doing tasks
with hard real-time requirements in Perl is certifiable.

Certifiably what? I do things with hard real-time requirements
in Perl. Didn't Abigail just say that you shouldn't generalize?

 

[Tassilo v. Parseval]

Also sprach brian d foy:

Certifiably what? I do things with hard real-time requirements
in Perl.

I strongly doubt that. Perl is inherently unsuitable for those kind of
tasks. Most languages and environments in fact are.

The requirements of real-time computing are predictability in terms of
latency, timing and synchronicity. Note how this has nothing to do with
the actual speed of execution or the seemingly prompt responsiveness of
an application.

Tassilo

 

[brian d foy]

Also sprach brian d foy:

I strongly doubt that. Perl is inherently unsuitable for those kind of
tasks. Most languages and environments in fact are.

Maybe someone should define some terms then, because we haven't
talked about anything specific, but everyone seems to think we're
talking about something specific.

 

[Chris Mattern]

Also sprach brian d foy:

Maybe someone should define some terms then, because we haven't
talked about anything specific, but everyone seems to think we're
talking about something specific.

We are talking about something specific. Hard real time programming
is programming in an environment with exact and rigorous timing
requirements (like setting off an airbag). In such an environment,
you may have, for example, a requirement that action A happen 342
milliseconds after event B is detected, plus or minus 3 milliseconds.
Violating that requirement by letting action A happen 334 milliseconds
after, or 348 milliseconds, is not acceptable and will cause the device
you are programming to fail. You must program to ensure that that does
not happen. You cannot write such programs in Perl, nor can you write
them on a general use OS like standard Linux (there is a real-time
Linux kernel mod, though).

--
Christopher Mattern

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

 

[David H. Adler]

We are talking about something specific. Hard real time programming
is programming in an environment with exact and rigorous timing
requirements (like setting off an airbag).

And you can do that with perl under some circumstances. Your definition
does not contain the phrase "it must be fast" in it.

Now, since everyone here knows what the heck they're talking about, can
we stop picking nits? Or at least can we start paying attention when
people use smileys?

I should point out that I say this as someone who spends most of his
time picking nits. But I do it for fun, which this really isn't anymore.

dha

--
David H. Adler - <[email protected]> - http://www.panix.com/~dha/
Riding around on a horse while wearing a loincloth with one's gut
flapping in the breeze for a rock & roll video may lead viewers to
believe said rider to be, if not Indian, merely insane. That confusion
is understandable too. - Rip Thrillby

 

[Paul]

And you can do that with perl under some circumstances. Your definition
does not contain the phrase "it must be fast" in it.

Now, since everyone here knows what the heck they're talking about, can
we stop picking nits? Or at least can we start paying attention when
people use smileys?

I should point out that I say this as someone who spends most of his
time picking nits. But I do it for fun, which this really isn't anymore.

dha

The correct definition of real-time is "that the processing must be done
in time to affect its input".

A typical example ( used in most classrooms ) is that of a valve
controlling water flow to, say a turbine. If the measurement and
calculation of adjustrments is not made "in real time" the output could
cause the input to overshoot.

The term real-time is very badly used - I once heard a guy refer to a
network as "real-time" - a definite no-no.