Re: Fwd: 3 Good Reasons...

[Steffen Schwigon]

"Michael Mathews" <[EMAIL PROTECTED]> writes:
> I'm glad you made that point. If I understand your statement, it's a
> common "gain" cited by Perl 6 (actually Parrot) advocates: you can mix
> languages. But a point I was trying to make was that while this is fun
> for us developers, managers hate it, with very good reason. Having one
> crucial part of a system written in, say Python, when the other 98%is
> in Perl, is actually considered a Bad Thing. It means having to have
> experts in two languages around at all times should anything go wrong.

I don't think it's about hacking a project with two or more languages
from scratch. I think it's about using strong libraries that emerged
in other language worlds.

In the Perl world it is common practice to find a wrapper on CPAN that
makes a foreign language module (mostly C) usable. It's that common
because of to the "gluey" nature of Perl and the mostly easy way to
use C code.

If that practice would expand to not mostly C libs, as it's usual
today, but practically to a general use of much more libs from the
outside world, that would be a Good Thing, because a lot of problems
would be solved not just "once per language" but even really "once per
universe".

And within the Perl5/Perl6 world I think we don't even have to set all
our money and propaganda on Parrot. Look at the Pugs project and read
Audreys blogs to see how they couple the Perl5 and Perl6 world with a
lot more tricks than only by bytecoding to Parrot. They do it right
now and in both directions. Not always without hazzle, but it's just
the beginning.

Summa summarum: So I don't think it's about hiring the same number of
language experts as the number of different languages you use. I think
it's about making programming more borderless, making the use of
libraries similar to todays typical use of whole programs,
independently of the language it's written in.


GreetinX
Steffen 
-- 
Steffen Schwigon <[EMAIL PROTECTED]>
Dresden Perl Mongers 

Re: 3 Good Reasons...

[David Cantrell]

On Fri, May 26, 2006 at 12:37:31PM +0100, Michael Mathews wrote:

> I use the expat and libxslt libraries (both in C) regularly via perl,
> so I guess I must agree that there is a distinction -- thank you for
> clarifying that. But I can't think of any examples where I was stuck
> because I couldn't use a "library" only available in, say Python, or
> JavaScript in my Perl. But then I'm seeking to learn here so can you
> give a nice juicy example of a non-C library that would be a big plus
> to be able to include in Perl?

Log4java, although it's now been cloned as Log4perl.

More importantly from a perl programmer's point of view, I'd really like
the benighted heathen pythonistas to be able to use my fabulous perl
code.

-- 
David Cantrell | Reality Engineer, Ministry of Information

It's my experience that neither users nor customers can articulate
what it is they want, nor can they evaluate it when they see it
-- Alan Cooper

Re: 3 Good Reasons...

[Chris Dolan]

On May 26, 2006, at 6:37 AM, Michael Mathews wrote:


I use the expat and libxslt libraries (both in C) regularly via perl,
so I guess I must agree that there is a distinction -- thank you for
clarifying that. But I can't think of any examples where I was stuck
because I couldn't use a "library" only available in, say Python, or
JavaScript in my Perl. But then I'm seeking to learn here so can you
give a nice juicy example of a non-C library that would be a big plus
to be able to include in Perl?


I have a real-world example from my work.  Perl lacked a library for  
parsing and editing Macromedia FLV files.  There was one in Ruby[1],  
but the rest of my code was written in Perl.  So, I created the FLV- 
Info library[2].  It's pretty nice for reading FLVs IMHO, but has no  
edit features due to my time constraints.  If I were working in the  
magic future where Perl and Ruby are bytecode compatible, perhaps I  
would have just interfaced with the Ruby library directly instead of  
having to reinvent it, saving a couple of days of coding and debugging.


 [1]  http://inlet-media.de/flvtool2
 [2]  http://search.cpan.org/dist/FLV-Info/

Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)

Re: 3 Good Reasons...

[A. Pagaltzis]

* Michael Mathews <[EMAIL PROTECTED]> [2006-05-26 13:40]:
> But then I'm seeking to learn here so can you give a nice juicy
> example of a non-C library that would be a big plus to be able
> to include in Perl?

There are several Python projects that I wish I could use without
having to reimplement their functionality in Perl, such as the
Kid templating engine and Demokritos, an implementation of the
Atom Publishing Protocol.

Note that the Parrot Native Call Interface will also make it much
easier to provide bindings to libraries at ABI level, eg. if you
wrote a single Gtk2-Parrot binding it would be available
instantly for all languages hosted on Parrot, and unlike XS
modules in Perl 5 it wouldn’t need a compiler to install,
massively increasing its reach.

In short, a whole lot of duplicated effort at the plumbing layers
could go away.

Regards,
-- 
Aristotle Pagaltzis // 

Re: 3 Good Reasons...

[Dr.Ruud]

"Gabor Szabo" schreef:

> {Cobol etc.]
> IMHO - and I really saw only a few such companies - these companies
> have 0 automatic tests so it would cost them a lot of time and money
> to test their application on the new and shiny Cobol compiler.

I once worked on tests for a national center of a bank, to monitor the
nightly runs of big money flowing. The Cobol programs ran on mainframes;
there were several IBM PCs, with character terminal emulation software,
connected to them.

On each PC there was a stack of C-programs, generated with yacc and lex.
When a fresh screen came up, a main program deducted the proper test for
it and ran it. When the test failed, the PC would start beeping and
flashing, to wake up the one operator that remained: this software
replaced a couple of people that once did the same tests with mental
arithmetic and a pocket calculator.

The terminal emulation software had a very raw INT-something-API (HLLAPI
IIRC), and IBM had updated the terminal emulation software but hadn't
updated the (never supported) linkable library layer for the API, so the
first thing I had to do was to create a replacement library. That took
only half a day, because the documentation of IBM was OK, and I could
generate much of the C-code with a few macros. I wondered why IBM hadn't
done that, it would have been a nice gesture.
http://www.webopedia.com/TERM/H/HLLAPI.html

Next I had to check the test programs, because they failed often. These
were full of strdups without frees and things like that, they were made
by a Pascal programmer. It took me two days to fix all those yacc/lex
sources, throwing away about 90% of them because there was a lot of
duplication. Basically such a program would check the layout of the
screen, copy a few numbers from it and do some calculations on them,
then store the result in a log. And of course it would bark when things
didn't add up.

Monitoring, regular expressions, character based: nothing much has
changed.


http://search.cpan.org/~grommel/Convert-IBM390/IBM390.pod

http://search.cpan.org/~ingy/Inline/Inline-API.pod
"The Inline community will decide if your implementation of COBOL will
be distributed as the official Inline::COBOL or should use an alternate
namespace." :)

-- 
Affijn, Ruud

"Gewoon is een tijger."

Re: 3 Good Reasons...

[Gabor Szabo]

[
  I am sorry this will not respond directly to the message in question as
  I have not seen it in my inbox. I hope the attribution is correct though.
]

On 5/26/06, Dr.Ruud <[EMAIL PROTECTED]> wrote:

>> Not really. Think about a Cobol-to-Parrot translator. You could for
>> example use Perl (glue) to add GUI stuff to old Cobol programs.


Ocassionally I have this dream of having a Cobol-to-Parrot compiler and being
able to go into these huge financial institutions with a solution on how to add
GUI to Cobol, or just how to make it a lot easier to add more features
but then I wake up.

One of the reasons these companies still use Cobol is that they are afraid
of anything new.
They want a reliable (read blame-able, sue-able) company to provide
for their hardware, OS and Cobol compiler. Unless they are forced (eg.
by SWIFT) they
won't leave their current setup.

Even if another reliable (read as above) supplier comes along IMHO their
sales people would have tough time to convince the company to switch.

IMHO - and I really saw only a few such companies - these companies have 0
automatic tests so it would cost them a lot of time and money to test their
application on the new and shiny Cobol compiler.

Gabor

Re: 3 Good Reasons...

[Dr.Ruud]

"Michael Mathews" schreef:
> [attribution repaired] Ruud:
>> [attribution repaired] Michael:

(Michael previously sent me an independent off-list reply; we're back on
the list now)

>>> As I gradually learn how Parrot works, I see that perhaps the idea
>>> of decompiling byte-code into language ___ is only a pipe-dream.
>>> But the point still remains--using the fact that one *could* mix
>>> languages X, Y, and P into your company's source tree is a very
>>> weak argument for Parrot/Perl6. I would say it is a non-argument.
>>
>> Not really. Think about a Cobol-to-Parrot translator. You could for
>> example use Perl (glue) to add GUI stuff to old Cobol programs.
>>
>> Just see it as a way to solve real problems. You don't have to use it
>> yourself.
>
> I'll try to be more clear. The original question was seeking opinions
> on what the big gains were for companies to switch to Parrot/Perl6
> (someday). My point was that saying it would allow a mixture of
> languages to be used in an application is, in my real-world
> experience, not something companies are currently seeking, plus you
> don't need to upgrade to do it, so it isn't really a selling point
> worth bringing up to your local IT Manager type person.

Then don't use this point to sell it to that manager.


>>> it also means she now has to keep a
>>> Java/PHP/Perl programmer around and happy whenever one of three
>>> different languages might throw a buggie.
>>
>> No, it is not limited by that.
>
> Huh? Let me give an actual example. A major broadcasting company I was
> contracted with needed to change part of their gigantic code base that
> dealt with a data source of live sports scores (which were
> automatically displayed on air). The code was all Perl :-) except for
> one chunk in Python--so guess where the problem was. This had to be
> fixed FAST and no one in the office knew Python well enough to do it,
> including me (the guy who wrote the Python was long gone to work at
> Google). In the end it was decided to rewrite that chunk in Perl. I
> can tell you, there definitely was cursing in the office that day, and
> I doubt anyone there would see it as a plus to have the ability to mix
> languages more easily. I just wouldn't put it that way if I were
> trying to sell Perl6 to a business manager.

I already knew from the start that you had a bad experience in this
area. ;)

Of course you don't want your car built partly with metric and partly
with English measured parts.
 But that is not what this is
about. The feature is not designed to crash a spacecraft, but of course
somebody will still use it for that.


> In my experience Perl has an (undeserved) bad reputation in regards to
> large, long-term projects because it allows "too much" flexibility.

That will not change.


> Really that means management has to do work to set and enforce
> standards, but those managers aren't going to be impressed by hearing
> Perl 6 makes it easy to mix lots of different languages together.
> Nevermind how cool/useful I personally think that is.

I like it that Perl5 and C go so well together. I dislike Java, so I
don't care for it.
Let's just make Perl6/Parrot the ultimate Cobol "shell" as well.

-- 
Affijn, Ruud

"Gewoon is een tijger."

Re: 3 Good Reasons...

[Michael Mathews]

On 26/05/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote:

* Michael Mathews <[EMAIL PROTECTED]> [2006-05-26 12:45]:
> In the end it was decided to rewrite that chunk in Perl. I can
> tell you, there definitely was cursing in the office that day,
> and I doubt anyone there would see it as a plus to have the
> ability to mix languages more easily. I just wouldn't put it
> that way if I were trying to sell Perl6 to a business manager.

Using libraries from other languages and writing code in multiple
languages are very different things. You will not be able to
argue with a straight face that being able to do the former is a
downside. Currently, "other languages" translates to C, so the
utility of this is limited; being able to bridge to more
languages would be a great boon.


I use the expat and libxslt libraries (both in C) regularly via perl,
so I guess I must agree that there is a distinction -- thank you for
clarifying that. But I can't think of any examples where I was stuck
because I couldn't use a "library" only available in, say Python, or
JavaScript in my Perl. But then I'm seeking to learn here so can you
give a nice juicy example of a non-C library that would be a big plus
to be able to include in Perl?

--michael

Re: 3 Good Reasons...

[A. Pagaltzis]

* Michael Mathews <[EMAIL PROTECTED]> [2006-05-26 12:45]:
> In the end it was decided to rewrite that chunk in Perl. I can
> tell you, there definitely was cursing in the office that day,
> and I doubt anyone there would see it as a plus to have the
> ability to mix languages more easily. I just wouldn't put it
> that way if I were trying to sell Perl6 to a business manager.

Using libraries from other languages and writing code in multiple
languages are very different things. You will not be able to
argue with a straight face that being able to do the former is a
downside. Currently, “other languages” translates to C, so the
utility of this is limited; being able to bridge to more
languages would be a great boon.

Regards,
-- 
Aristotle Pagaltzis // 

Re: 3 Good Reasons...

[Michael Mathews]

> As I gradually learn how Parrot works, I see that perhaps the idea of
> decompiling byte-code into language ___ is only a pipe-dream. But the
> point still remains--using the fact that one *could* mix languages X,
> Y, and P into your company's source tree is a very weak argument for
> Parrot/Perl6. I would say it is a non-argument.

Not really. Think about a Cobol-to-Parrot translator. You could for
example use Perl (glue) to add GUI stuff to old Cobol programs.

Just see it as a way to solve real problems. You don't have to use it
yourself.


I'll try to be more clear. The original question was seeking opinions
on what the big gains were for companies to switch to Parrot/Perl6
(someday). My point was that saying it would allow a mixture of
languages to be used in an application is, in my real-world
experience, not something companies are currently seeking, plus you
don't need to upgrade to do it, so it isn't really a selling point
worth bringing up to your local IT Manager type person.


> The reason this would make an IT Manager cry is not (promarily)
> because it is slow (etc, etc),

It isn't slow.


My comment was in reference to the immediately preceding example of
using backticks, which spawn extra processes and therefore IS slower
than not spawning extra processes. Sorry if that was confusing.


> it also means she now has to keep a
> Java/PHP/Perl programmer around and happy whenever one of three
> different languages might throw a buggie.

No, it is not limited by that.


Huh? Let me give an actual example. A major broadcasting company I was
contracted with needed to change part of their gigantic code base that
dealt with a data source of live sports scores (which were
automatically displayed on air). The code was all Perl :-) except for
one chunk in Python--so guess where the problem was. This had to be
fixed FAST and no one in the office knew Python well enough to do it,
including me (the guy who wrote the Python was long gone to work at
Google). In the end it was decided to rewrite that chunk in Perl. I
can tell you, there definitely was cursing in the office that day, and
I doubt anyone there would see it as a plus to have the ability to mix
languages more easily. I just wouldn't put it that way if I were
trying to sell Perl6 to a business manager.

In my experience Perl has an (undeserved) bad reputation in regards to
large, long-term projects because it allows "too much" flexibility.
Really that means management has to do work to set and enforce
standards, but those managers aren't going to be impressed by hearing
Perl 6 makes it easy to mix lots of different languages together.
Nevermind how cool/useful I personally think that is.

--michael

Fwd: 3 Good Reasons...

[Michael Mathews]

Hi Affijn,

As I gradually learn how Parrot works, I see that perhaps the idea of
decompiling byte-code into language ___ is only a pipe-dream. But the
point still remains--using the fact that one *could* mix languages X,
Y, and P into your company's source tree is a very weak argument for
Parrot/Perl6. I would say it is a non-argument.

As you point out, it can already be done with Inline.pm & friends. In
fact, it can be done even more blatantly with backticks. It has long
been possible to do stuff like this:
 #!perl5
 $a = `/usr/bin/java foo.class`;
 $b = `/usr/bin/php bar.php`;
 $c = $a + b;

The reason this would make an IT Manager cry is not (promarily)
because it is slow (etc, etc), it also means she now has to keep a
Java/PHP/Perl programmer around and happy whenever one of three
different languages might throw a buggie.

--michael


On 26/05/06, Dr.Ruud <[EMAIL PROTECTED]> wrote:

"Michael Mathews" schreef:

> [compile down to a *language independent* format]
> So does that mean I can write a module in Perl 6, deliver it to Mr.
> Customer as byte-code. Then Mr. Customer can "decompile"(?) it into
> Python (or JavaScript, or C, etc), edit it, and then compile it back
> into working byte-code again?

No, compiling to bytecode is like a one way street: you will probably
not remain recognizable when you drive it in the opposite way. It is
less hard to go from Perl6-code to Python-code or rather v.v.

But there is no need for all that. Think about the libraries compiled
from C-code that are now linked with Perl5. You can do something
similar with Parrot: create libraries that can be efficiently "linked"
with code written in other languages (that compile to Parrot).

Mixed language source code, even cleaner than the current Perl5 with
Inline.pm, is another feasibility.

--
Affijn, Ruud

"Gewoon is een tijger."

Re: 3 Good Reasons...

[Dr.Ruud]

"Michael Mathews" schreef:

> [compile down to a *language independent* format]
> So does that mean I can write a module in Perl 6, deliver it to Mr.
> Customer as byte-code. Then Mr. Customer can "decompile"(?) it into
> Python (or JavaScript, or C, etc), edit it, and then compile it back
> into working byte-code again?

No, compiling to bytecode is like a one way street: you will probably
not remain recognizable when you drive it in the opposite way. It is
less hard to go from Perl6-code to Python-code or rather v.v.

But there is no need for all that. Think about the libraries compiled
from C-code that are now linked with Perl5. You can do something
similar with Parrot: create libraries that can be efficiently "linked"
with code written in other languages (that compile to Parrot).

Mixed language source code, even cleaner than the current Perl5 with
Inline.pm, is another feasibility.

-- 
Affijn, Ruud

"Gewoon is een tijger."

Re: Logic Programming for Perl6 (Was Re: 3 Good Reasons... (typo alert!))

[A. Pagaltzis]

* Ovid <[EMAIL PROTECTED]> [2006-05-25 20:45]:
> The first hurdle would be the syntax.  The programmer just
> looking at the code would need to know when one section of code
> represents a snippet of logic programming.  Is the following a
> function call or a Prolog fact?
> 
>   loves( 'foo', 'bar' );
> 
> How would one assert facts and rules in Perl6?  How would one
> know that a variable is a logic variable and not a normal one?

Don’t forget that in Perl 6, the parser grammar is wide open for
modification. That is not an opportunity to be used lightly, but
I believe logic programming is a sufficiently “big” and distinct
extension that it justifies dedicated syntax.

Regards,
-- 
Aristotle Pagaltzis // 

Fwd: 3 Good Reasons...

[Michael Mathews]

Hi Steffen,

I'm glad you made that point. If I understand your statement, it's a
common "gain" cited by Perl 6 (actually Parrot) advocates: you can mix
languages. But a point I was trying to make was that while this is fun
for us developers, managers hate it, with very good reason. Having one
crucial part of a system written in, say Python, when the other 98%is
in Perl, is actually considered a Bad Thing. It means having to have
experts in two languages around at all times should anything go wrong.
Obviously this is more expensive and more effort than having to
maintain just one language.

I'm not trying to pick a fight with Parrot here, in fact I think the
best way to put it is more along the lines that Perl 5/6, on Parrot,
will compile down to a *language independent* format. At least I think
that's so. Someone correct me here, especially as that's what I think
Steffen was saying.

So does that mean I can write a module in Perl 6, deliver it to Mr.
Customer as byte-code. Then Mr. Customer can "decompile"(?) it into
Python (or JavaScript, or C, etc), edit it, and then compile it back
into working byte-code again?

'Cause if THAT were true then it would be revolutionary and businesses
would be fighting to get their hands on it (once it was stable and
proven). Much more inviting than saying Parrot will allow lots of
different languages to start sprouting up in unexpected areas of the
company's code base.

--michael

On 25/05/06, Steffen Schwigon <[EMAIL PROTECTED]> wrote:

"Michael Mathews" <[EMAIL PROTECTED]> writes:
> So my question to the list is, in simple terms even an IT manager
> could grasp, explain what problems Perl 5 has that Perl 6 fixes,
> such that they would want to undergo the pain of ever switching.

From a Perl point of view: there should be no pain.
At least that's a stated goal.

From a manager point of view: it's as use(ful|less) as ever to decide
for a language independently of the problem to solve. If Perl5 does
the job, stick with it. If Perl6 helps you somewhere, use it. If
Visual Basic solves your problem because it's already built into the
problem, just use it.

Perl5 is already gluey enough to not force you into a decicion for
*the only one* technology. Perl6 shouldn't change that.

Steffen
--
Steffen Schwigon <[EMAIL PROTECTED]>
Dresden Perl Mongers 

Re: 3 Good Reasons...

[Steffen Schwigon]

"Michael Mathews" <[EMAIL PROTECTED]> writes:
> So my question to the list is, in simple terms even an IT manager
> could grasp, explain what problems Perl 5 has that Perl 6 fixes,
> such that they would want to undergo the pain of ever switching.

>From a Perl point of view: there should be no pain.
At least that's a stated goal.

>From a manager point of view: it's as use(ful|less) as ever to decide
for a language independently of the problem to solve. If Perl5 does
the job, stick with it. If Perl6 helps you somewhere, use it. If
Visual Basic solves your problem because it's already built into the
problem, just use it.

Perl5 is already gluey enough to not force you into a decicion for
*the only one* technology. Perl6 shouldn't change that.

Steffen
-- 
Steffen Schwigon <[EMAIL PROTECTED]>
Dresden Perl Mongers 

Re: Logic Programming for Perl6 (Was Re: 3 Good Reasons... (typo alert!))

[Ovid]

- Original Message 
From: David Romano <[EMAIL PROTECTED]>

> > duplicate results and this is almost always wrong. (See 
> > http://use.perl.org/~Ovid/journal/28378 
> > for an SQL example of this problem).
> I re-read your journal entry and comments (I had read it back when you
> first had posted it), and I'm curious about what obstacles that you
> think need to be overcome for Perl6 to support logic programming.

If anyone wants to know what the heck this is about, you can read 
http://search.cpan.org/dist/AI-Prolog/lib/AI/Prolog/Article.pod

That's an article I originally had published in The Perl Review 
(http://www.theperlreview.com/) and it explains the basics of logic programming 
and how to do it in Perl5.  It also explains the append/3 predicate, something 
I mention below.

The first hurdle would be the syntax.  The programmer just looking at the code 
would need to know when one section of code represents a snippet of logic 
programming.  Is the following a function call or a Prolog fact?

  loves( 'foo', 'bar' );

How would one assert facts and rules in Perl6?  How would one know that a 
variable is a logic variable and not a normal one?  Assignment to a logic 
variable which is still subject to rebinding could break code.  On the other 
hand, using normal variables for logic variables could let us use objects for 
them and I think this might get us contraint programming (long story).

There's also the question of non-logical behavior in logic programming.  What 
happens if you try to use math in Perl6 logic programming?  Generally speaking, 
math is "non-logical" in the sense that it's used in Prolog (see the 
aforementioned article).  Opening and reading from a file is also non-logical 
(you can't backtrack over it). How are those issues to be handled?

My biggest concern, though, is a rule like the following:

  customer_cities(City) :-
700 <= credit_rating(Customer),
customer(Customer, City).

That's logically equivalent to the SQL I posted in a previous email and, like 
that SQL, will very likely return duplicates.  Prolog students are constantly 
faced wtih the "how do I get rid of duplicates?" problem.  This results in 
inefficient queries and a lot of time spent culling the duplicate answers when 
the person just wants to know the list of cities which meets their requirements.

Perl6 grammars may be able to assist with this, but grammars (as far as I can 
tell) are still based around strings and not data structures.  Admittedly, 
Prolog is essentially a fancy string rewriting system, but it's not clear how 
the grammars would be applied to this problem.

For anyone familiar with logic programming and the append/3 predicate, here's 
one way of representing it in Perl5:

  use re 'eval';
  my $string = "abc";
  my $length = length $string;
  my $regex = qr/(\G[$string]{0,$length}(?{print "# [$&][$'][$string]\n"}))/ x 
2;
  $string =~ $regex;

Can you say "yuck"?  However, that only represents a limited subset of 
append/3's functionality and trying to generalize it would be a very difficult 
task.  One approach might be to write a wrapper around 
http://www.perlmonks.org/?node_id=318350.  That's an approach I found to 
leverage Perl5's regex engine for logic programming, but I discovered that 
Perl5's regexen aren't re-entrant, killing that project.  Perl6 rules might be 
perfect for this.

In short, there are lots of questions which would need to be answered to get 
logic programming done correctly in Perl6.  I'm quite happy that @Larry decided 
not to answer those questions since things would have been delayed.  We can 
hack in logic programming later.

Cheers,
Ovid

-- If this message is a response to a question on a mailing list, please send 
follow up questions to the list.
 
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/

Re: Logic Programming for Perl6 (Was Re: 3 Good Reasons... (typo alert!))

[Larry Wall]

This topic may be better suited to perl6-language, unless you consider
its denizens to already be self-selected against logic programming. :)

Larry

Logic Programming for Perl6 (Was Re: 3 Good Reasons... (typo alert!))

[David Romano]

Hi Ovid,
On 5/24/06, Ovid <[EMAIL PROTECTED]> wrote:

As an aside for those who, like me, wanted to see support for logic 
programming:  the only significant disappoinment I have with Perl6 is also, 
oddly enough, accompanied by a sigh of relief.  Perl6 will easily support 
imperative, functional and OO syntax.  But what about logic programming?  Perl6 
rules might help, but there will be no support for things that Prolog and 
Mercury do naturally.

The "sigh of relief" stems from my realization that logic programming in Perl6 
would probably be implemented incorrectly because the easiest way to implement it is 
usually wrong, though this can be very tough to see at first.  It's my understanding that 
logic programming wasn't incorporated due to the desire to not delay the initial release 
of Perl6 (I could be wrong).  However, after having done a fair amount of work with logic 
programming, I realize that one of the greatest implementation mistakes with it is that 
results tend to be bags and not sets (SQL shares this problem).  Thus, when one naturally 
wants all of the answers to a query, one often gets duplicate results and this is almost 
always wrong. (See http://use.perl.org/~Ovid/journal/28378 for an SQL example of this 
problem).

I re-read your journal entry and comments (I had read it back when you
first had posted it), and I'm curious about what obstacles that you
think need to be overcome for Perl6 to support logic programming.

Just to let you know, I only used Prolog for a month during a course
called "Programming Languages: Principles and Paradigms", so I don't
have a strong background in it. From what I remember, everything is
about binding in Prolog: if the given data can bind to the predicate
(I think that's what it's called in Prolog) in some way, then the
predicate returns successfully. Why can't grammars (in the sense of
Perl6) be used for this kind of stuff (and here I'm asking about what
Mercury and Prolog can do naturally)? Is it that so much more needs to
be added to Perl6 grammars/rules for them to be as powerful and
versatile as predicates in logic programming, and that these additions
cannot be reconciled with the rest of the Perl6 language? I'm
interested in everyone's opinions.

David

Re: 3 Good Reasons...

[A. Pagaltzis]

* Michael Mathews <[EMAIL PROTECTED]> [2006-05-25 00:45]:
> Is there something in Perl 6 akin to a "use strict" switch that
> will apply the straightjacket some projects need, and thus
> force typing of all variables. (Then I could have a good
> comeback for those damned Java guys.)

It’s called Company Coding Style. Yes, the compiler doesn’t
enforce that, but you can check the source itself for type
declarations where Style says they should be; this is a different
situation from Perl 5, where you have to rely on much softer
metrics external to the source.

Regards,
-- 
Aristotle Pagaltzis // 

Re: 3 Good Reasons...

[Michael Mathews]

Thanks for that Ovid. I agree that any language must stand on it's
merits in the long-term, but there is an undeniable "hump" every new
language must get over to convince people it's worth trying in the
first place.


From your excellent summary I think speed, CLR and real OO should

definitely make the short list. I personally never had a problem with
Perl's speed. If I wanted speed I'd write it in C -- for what I do
Perl is already fast enough -- but manager-types have a natural
affinity to efficiency. Faster, better, easier? Yeah that's salable.
:-)

--michael

On 24/05/06, Ovid <[EMAIL PROTECTED]> wrote:

- Original Message 
From: Michael Mathews <[EMAIL PROTECTED]>

> So my question to the list is, in simple terms even an IT manager
> could grasp, explain what problems Perl 5 has that Perl 6 fixes, such
> that they would want to undergo the pain of ever switching.




Hi Michael,

Many companies eventually switch to new languages.  The switch is painful, but 
when they see their current technologies aren't working, they reach for 
something else.  The question is, why Perl6?

Perl6, for those who have been paying attention, is revolutionary.  Not only 
will the language run much faster, but programmers will be more productive, 
they'll be able to seamlessly interact with code written in other languages and 
they'll be able to easily do things that is hard to do in other languages.

That's the short answer, but it sounds like a marketroid.  Here's (some of) the 
beef, though I'd be happy for corrections on any misconceptions below.

Perl5 is a very powerful language, but it does have plenty of cruft and is 
showing its age.  Perl6 not only fixes a lot of that cruft but also adds new, 
powerful features which makes programmers more productive and thus can churn 
out apps quicker.  Further, because it will be running on top of Parrot, it 
will be far faster than Perl5.  So you gain both programmer and runtime 
performance.

The most serious problems I have with Perl5 tend to center around its flexible 
but limited OO model.  Right now there's not a clear distinction between class 
and instance data.  This means that it's very easy to create class data which 
makes subclassing difficult at times.  Further, Perl5's poor argument handling 
is a constant source of bugs:

  sub some_value {
  my ($self, $value) = @_;
  return $self->{value} unless $value; # whoops!  Is "0" OK?
  $self->{value} = $value;
  return $self;
  }

Also, Perl6 will offer much strong encapsulation than one can "naturally" do in 
Perl5 (without resorting to inside-out objects, but I tend to recommend that folks not 
use those).

Perl6 offers optional strong typing, meaning that you can declare the above 
argument to some_value to be an integer and have less worries that someone will 
pass a string.  The strong typing means you can also do this:

  my int @array;

That will allow optimizations that are currently not possible, but since it's 
optional, you can choose the flexibility of late binding or the comfort of 
early binding (a bit of hand waving there).

Multimethods are also very powerful, but difficult to do with Perl5 without 
extra (and slow) modules.  The can alleviate many bugs associated with methods 
(feel free to correct my syntax):

  method name () { return $.name }
  method name ( $name ) { $.name = $name; return $self }

Being able to overload methods and subroutines based on signatures is going to 
be a huge win.

Further, when other languages target Parrot, Perl6 will be able to comunicate 
with them *without* extra scaffolding code or you having to rewrite them!

Or how about the power of junctions?  Want to verify that none of the elements 
in one list are present in another?

  if all(@numbers) == none(@disallowed) {
 ...
  }

Ordinarily, writing code to do that is complicated and can be buggy and slow.  
This makes it much easier to read and can be run in parallel if your system 
supports it (is this correct?  I *think* it is).

And to multiple all items in an array by some value?

  @items = @items >>*<< 1.05; # add 5% sales tax

Anyone who's programmed OO code long enough knows the problems inherent in multiple 
inheritance.  These problems are so serious that some language simply forbid MI.  Java 
uses interfaces and Ruby uses mixins.  Both have problems limiting their use in 
large-scale code.  Perl6 will be the first mainstream language to incorporate traits 
(known as "roles" in Perl6) to eliminate these problems.  Traits are easy to 
use, very flexible and I found them more natural to use once I understood them (they've 
saved me major headaches in some of my code.  See Class::Traits for a fairly 
full-featured Perl5 implementation).

The list goes on and on.  Perl6 will run on Parrot and Parrot will the the CLR 
(common language runtime) for dynamic languages.  C# advocates *love* having 
the CLR available.  Now we'll have one too, but it will be geared towards 
dynamic langu

Re: 3 Good Reasons...

[Michael Mathews]

Ah, perfect example Daniel. I know people say things like "Java is
better for big projects because of the strictness of it's typing". I
respond that Perl isn't intrinsically sloppy if you practice good
coding, it just doesn't straightjacket you into that all the time.

So here's Perl 6 and it has lovely typing! Yay. I can now say "$foo is
Scalar;" but erm, that's optional. To get the benefit you must still
hope for developer self-discipline (my day-job is maintaining and
refactoring other people's Perl, so I may be a teensy bit bitter about
relying on developer self-discipline).

Is there something in Perl 6 akin to a "use strict" switch that will
apply the straightjacket some projects need, and thus force typing of
all variables. (Then I could have a good comeback for those damned
Java guys.)

--michael

On 24/05/06, Daniel Hulme <[EMAIL PROTECTED]> wrote:

> what problems Perl 5 has that Perl 6 fixes

A type system to die for.

I think that is enough of a win on its own that mentioning any of the
other features will only muddy the issue :->

--
"The fact that some geniuses were laughed at does not imply that all who
are laughed at are geniuses.  They laughed at Columbus,  they laughed at
Fulton,  they laughed  at the Wright brothers.  But they also laughed at
Bozo the Clown."   --  Carl Sagan  http://surreal.istic.org/

Re: 3 Good Reasons... (typo alert!)

[Ovid]

Sheesh.  I type things too fast and then I see the horrifying typos I've made 
(blush)

- Original Message 
From: Ovid <[EMAIL PROTECTED]>

> do things that is hard to do in other languages.

"do things that *are* hard to do in other languages"

> Perl6 not only fixes a lot of that cruft but also adds new, powerful features 
> which
> makes programmers more productive and thus can churn out apps quicker.
 
"which make"

> The can alleviate many bugs

"This can alleviate many bugs"

> And to multiple all items in an array by some value?

"multiply"

OK, I'll stop now even though there's more.  Wow.  What a terrible mess.

As an aside for those who, like me, wanted to see support for logic 
programming:  the only significant disappoinment I have with Perl6 is also, 
oddly enough, accompanied by a sigh of relief.  Perl6 will easily support 
imperative, functional and OO syntax.  But what about logic programming?  Perl6 
rules might help, but there will be no support for things that Prolog and 
Mercury do naturally.

The "sigh of relief" stems from my realization that logic programming in Perl6 
would probably be implemented incorrectly because the easiest way to implement 
it is usually wrong, though this can be very tough to see at first.  It's my 
understanding that logic programming wasn't incorporated due to the desire to 
not delay the initial release of Perl6 (I could be wrong).  However, after 
having done a fair amount of work with logic programming, I realize that one of 
the greatest implementation mistakes with it is that results tend to be bags 
and not sets (SQL shares this problem).  Thus, when one naturally wants all of 
the answers to a query, one often gets duplicate results and this is almost 
always wrong. (See http://use.perl.org/~Ovid/journal/28378 for an SQL example 
of this problem).

Cheers,
Ovid

Re: 3 Good Reasons...

[Ovid]

- Original Message 
From: Michael Mathews <[EMAIL PROTECTED]>

> So my question to the list is, in simple terms even an IT manager
> could grasp, explain what problems Perl 5 has that Perl 6 fixes, such
> that they would want to undergo the pain of ever switching.




Hi Michael,

Many companies eventually switch to new languages.  The switch is painful, but 
when they see their current technologies aren't working, they reach for 
something else.  The question is, why Perl6?

Perl6, for those who have been paying attention, is revolutionary.  Not only 
will the language run much faster, but programmers will be more productive, 
they'll be able to seamlessly interact with code written in other languages and 
they'll be able to easily do things that is hard to do in other languages.

That's the short answer, but it sounds like a marketroid.  Here's (some of) the 
beef, though I'd be happy for corrections on any misconceptions below.

Perl5 is a very powerful language, but it does have plenty of cruft and is 
showing its age.  Perl6 not only fixes a lot of that cruft but also adds new, 
powerful features which makes programmers more productive and thus can churn 
out apps quicker.  Further, because it will be running on top of Parrot, it 
will be far faster than Perl5.  So you gain both programmer and runtime 
performance.

The most serious problems I have with Perl5 tend to center around its flexible 
but limited OO model.  Right now there's not a clear distinction between class 
and instance data.  This means that it's very easy to create class data which 
makes subclassing difficult at times.  Further, Perl5's poor argument handling 
is a constant source of bugs:

  sub some_value {
  my ($self, $value) = @_;
  return $self->{value} unless $value; # whoops!  Is "0" OK?
  $self->{value} = $value;
  return $self;
  }

Also, Perl6 will offer much strong encapsulation than one can "naturally" do in 
Perl5 (without resorting to inside-out objects, but I tend to recommend that 
folks not use those).

Perl6 offers optional strong typing, meaning that you can declare the above 
argument to some_value to be an integer and have less worries that someone will 
pass a string.  The strong typing means you can also do this:

  my int @array;

That will allow optimizations that are currently not possible, but since it's 
optional, you can choose the flexibility of late binding or the comfort of 
early binding (a bit of hand waving there).  

Multimethods are also very powerful, but difficult to do with Perl5 without 
extra (and slow) modules.  The can alleviate many bugs associated with methods 
(feel free to correct my syntax):

  method name () { return $.name }
  method name ( $name ) { $.name = $name; return $self }
 
Being able to overload methods and subroutines based on signatures is going to 
be a huge win.

Further, when other languages target Parrot, Perl6 will be able to comunicate 
with them *without* extra scaffolding code or you having to rewrite them!

Or how about the power of junctions?  Want to verify that none of the elements 
in one list are present in another?

  if all(@numbers) == none(@disallowed) {
 ...
  }

Ordinarily, writing code to do that is complicated and can be buggy and slow.  
This makes it much easier to read and can be run in parallel if your system 
supports it (is this correct?  I *think* it is).

And to multiple all items in an array by some value?

  @items = @items >>*<< 1.05; # add 5% sales tax

Anyone who's programmed OO code long enough knows the problems inherent in 
multiple inheritance.  These problems are so serious that some language simply 
forbid MI.  Java uses interfaces and Ruby uses mixins.  Both have problems 
limiting their use in large-scale code.  Perl6 will be the first mainstream 
language to incorporate traits (known as "roles" in Perl6) to eliminate these 
problems.  Traits are easy to use, very flexible and I found them more natural 
to use once I understood them (they've saved me major headaches in some of my 
code.  See Class::Traits for a fairly full-featured Perl5 implementation).

The list goes on and on.  Perl6 will run on Parrot and Parrot will the the CLR 
(common language runtime) for dynamic languages.  C# advocates *love* having 
the CLR available.  Now we'll have one too, but it will be geared towards 
dynamic languages.

Oh, and did I mention Perl6 rules?  That's probably one of the single most 
important things about Perl6.  Regular expressions have needed updating for a 
long time and @Larry has had the guts to bite the bullet.

All of these things (and many more) mean a language that's more productive for 
the programmer, runs much faster and is more flexible.  Further, the easy 
things are even easier than Perl5.  All of this translates to more $$ for 
companies.

Personally, I want to thank Larry, Damian, Luke, chromatic, Allison, Audrey and 
many more for their fine work in designing and implementing Perl6 (gush

Re: 3 Good Reasons...

[Daniel Hulme]

> what problems Perl 5 has that Perl 6 fixes

A type system to die for.

I think that is enough of a win on its own that mentioning any of the
other features will only muddy the issue :->

-- 
"The fact that some geniuses were laughed at does not imply that all who
are laughed at are geniuses.  They laughed at Columbus,  they laughed at
Fulton,  they laughed  at the Wright brothers.  But they also laughed at
Bozo the Clown."   --  Carl Sagan  http://surreal.istic.org/


pgpKvsEgdmrX8.pgp
Description: PGP signature

3 Good Reasons...

[Michael Mathews]

Open Question:

I realise I haven't kept up with every detail since the Perl6 RFC I
submitted way back in August 2000, but boy was I surprised to find,
now that I can actually use Perl6, it isn't just an improvement to
Perl (5), it's actually a "different language" (I'm quoting Michael
Schwern there, I'm not the first to notice this).

Now personally, I like learning new languages. I'm studying Ruby now,
and will probably play with Haskell, as well as Perl6. It's fun for
me. But knowing the people who have to sign paycheques over to us
developers as I do, I can say with some certainty: 1) they aren't at
all interested in our fun, 2) they actually consider lots of new and
different languages in their production code base to be scary, and 3)
if it ain't broke they will not want to spend money or effort to fix
it.

So my question to the list is, in simple terms even an IT manager
could grasp, explain what problems Perl 5 has that Perl 6 fixes, such
that they would want to undergo the pain of ever switching.

--michael