How did PHP and Python take over such a huge market-share of Perl?


M

mentificium

Perl has a future in artificial intelligence.

CPAN needs to be populated with AI Mind-Modules.
 
Ad

Advertisements

R

Rainer Weikusat

Perl has a future in artificial intelligence.

CPAN needs to be populated with AI Mind-Modules.

'Artificial Intelligence' use bullshit: Computers are useful because
they're not intelligent, that is, capable of influencing circumstances/
situations for their own benefit and people who lust for 'inelligent
beings without civil rights' should consider getting professional help,
at least in the parts of the world where slavery has been abolished, so
that they eventually get over that.
 
R

Rainer Weikusat

Perl has a future in artificial intelligence.

CPAN needs to be populated with AI Mind-Modules.

'Artificial Intelligence' is bullshit: Computers are useful because
they're not intelligent, that is, capable of influencing circumstances/
situations for their own benefit, and people who lust for 'inelligent
beings without civil rights' should consider getting professional help,
at least in the parts of the world where slavery has been abolished, so
that they eventually get over that.
 
G

George Mpouras

Στις 12/3/2014 18:43, ο/η (e-mail address removed) έγÏαψε:
Perl has a future in artificial intelligence.

CPAN needs to be populated with AI Mind-Modules.




I could tell you many laughable situations where Perl tasks are finished
weeks before the relative of java ones, and Managers scratching their
heads of what is going on : )


Also about AI , from my point of view the "eval" function and the
ability of subroutines to return code brings Perl very close to lisp
 
K

Kaz Kylheku

Also about AI , from my point of view the "eval" function and the
ability of subroutines to return code brings Perl very close to lisp

Yes, in particular close to that Shell dialect of Lisp:

for_pat()
{
local var=$1
local pattern=$2
local action=$3

echo "for $var in $pattern ; do $action ; done"
}

eval $(for_pat x '*.pl' 'echo $x')

Now throw in M4 macros and you have wonderful AI, like GNU Autoconf.
 
R

Rainer Weikusat

[...]
Also about AI , from my point of view the "eval" function and the
ability of subroutines to return code brings Perl very close to lisp

One major drawback of Perl compared to Lisp is that there's no
structured representation of Perl code: The only way to generate new
code at run time is to build 'Perl source code strings' and run them
through eval. For the same reason, Perl doesn't have a powerful macro
factility like Lisp.
 
Ad

Advertisements

R

Rainer Weikusat

Kaz Kylheku said:
Yes, in particular close to that Shell dialect of Lisp:

for_pat()
{
local var=$1
local pattern=$2
local action=$3

echo "for $var in $pattern ; do $action ; done"
}

eval $(for_pat x '*.pl' 'echo $x')

Now throw in M4 macros and you have wonderful AI, like GNU Autoconf.

I suggest 'artifical, untoward moronity' as term for that: Cannot do
anything useful on its own but is sufficiently bizarre and complex that
it makes a naive observer think of a passively aggressive and seriously
stupid 'intelligent being' (certain popular operating system have
similar characteristics ...).
 
T

Ted Zlatanov

RW> One major drawback of Perl compared to Lisp is that there's no
RW> structured representation of Perl code: The only way to generate new
RW> code at run time is to build 'Perl source code strings' and run them
RW> through eval. For the same reason, Perl doesn't have a powerful macro
RW> factility like Lisp.

The term is "homoiconic." Perl has a structured representation, but
you can't turn it back into Perl, that's the missing piece.

Ted
 
K

Kaz Kylheku

RW> One major drawback of Perl compared to Lisp is that there's no
RW> structured representation of Perl code: The only way to generate new
RW> code at run time is to build 'Perl source code strings' and run them
RW> through eval. For the same reason, Perl doesn't have a powerful macro
RW> factility like Lisp.

The term is "homoiconic." Perl has a structured representation, but
you can't turn it back into Perl, that's the missing piece.

There are so many missing pieces, none of them is "the".

Anyway, a macro facility for Perl would be somewhat pointless because macros
are geared toward compiling.

Since Perl is basically uncompilable, you might as well go with what mainstream
Lisp discarded decades ago: "fexprs".

If macros are considered to be compilers, fexprs are their interpretive
counterpart: user-defined operator functions that, at run time (not
macro-expansion time) receive the unevaluated versions of their arguments,
along with the caller's environment. They do whatever is necessary to make
their construct happen, each time they are called.

For example, a fexpr version of the let operator would grok the variable
bindings, extend the handed-down environment with them, and then call eval
over the forms enclosed by let, with the extended environment.

Tcl implements a version of this obsolete approach.

With fexprs you need some reasonable API to be able to peer into the pieces of
program you have been handed down and parse out things, but you don't a way to
re-assemble a syntactically correct piece of code that can be visualized in the
original source language.
 
T

Ted Zlatanov

KK> Anyway, a macro facility for Perl would be somewhat pointless because macros
KK> are geared toward compiling.

KK> Since Perl is basically uncompilable, you might as well go with what mainstream
KK> Lisp discarded decades ago: "fexprs".

I agree, as far as is needed to stop the hypothesizing about Perl macros.
My main purpose was to specify the technical term so Rainer can Google
it and write a long argument in response.

Ted
 
Ad

Advertisements

P

Peter J. Holzer

Anyway, a macro facility for Perl would be somewhat pointless because macros
are geared toward compiling.

Since Perl is basically uncompilable,

Perl is compiled.

hp
 
R

Rainer Weikusat

Ted Zlatanov said:
RW> One major drawback of Perl compared to Lisp is that there's no
RW> structured representation of Perl code: The only way to generate new
RW> code at run time is to build 'Perl source code strings' and run them
RW> through eval. For the same reason, Perl doesn't have a powerful macro
RW> factility like Lisp.

The term is "homoiconic." Perl has a structured representation, but
you can't turn it back into Perl, that's the missing piece.

There's an internal representation of a Perl program which is used for
executing it but Perl code cannot easily access that (according to the
documentation, some sort of read-only access is available via B), let
alone manipulate it or create something like it (this would require
interpreting/ generating 'C pointers' valid for the current Perl
process).

Being able to turn the optree back into Perl wouldn't be terribly useful
for this as this would require an artifical perl-ness in order to make
sense of it.

Sideline joke: http://www.perlprojects.org (found via Google).

I knew there was more to it than just getting stuff done.
 
R

Rainer Weikusat

[...]
Perl
[...]

might as well go with what mainstream
Lisp discarded decades ago: "fexprs".

If macros are considered to be compilers, fexprs are their interpretive
counterpart: user-defined operator functions that, at run time (not
macro-expansion time) receive the unevaluated versions of their arguments,
along with the caller's environment. They do whatever is necessary to make
their construct happen, each time they are called.

Perl can sort-of do that (using the recently discussed loop extension as
an example):

-------------
use constant BODY => 1;
use constant ONREPEAT => 2;

sub body(&@)
{
return [BODY, shift], @_;
}

sub onrepeat(&@)
{
return [ONREPEAT, shift], @_;
}

sub loop_while(&@)
{
my ($cond, @body) = @_;
my ($body, $onrepeat);

for (@body) {
$_->[0] == BODY and do {
die("This is not a crowd!\n") if $body;
$body = $_->[1];

next;
};

$_->[0] == ONREPEAT and do {
die("Feeling repetitive, are we?\n") if $onrepeat;
$onrepeat = $_->[1];

next;
};

die("Falsch verbunden ...\n");
}

$body //= sub {};
$onrepeat //= sub {};

$cond->() and do {
{
$body->();
last unless $cond->();
$onrepeat->();
redo;
}
};
}

my $line;

loop_while { $line = <>, defined($line) }
body { print($line) }
onrepeat { print("---\n") };
 
Ad

Advertisements

R

Rainer Weikusat

Mladen Gogala said:
]
and people who lust for 'inelligent beings without civil rights'
should consider getting professional help, at least in the parts of
the world where slavery has been abolished, so that they eventually
get over that.

Well, such "lust" was displayed by Isaac Asimov, Arthur C. Clarke, Philip
K. Dick, Douglas Adams and many other pioneers of the science fiction.
I'm not quite sure whether the better part of the science fiction writers
can be summarily dismissed as people in need of professional help.

You shouldn't include Douglas Adams in here as he was somewhat apt at
ridiculing the idea of 'artificially constructed intelligent beings', eg
with a 'brain of the size of a planet' comes a depression of equal
proportions, rendering the 'superbeing' really 'super' in every respect:
By design incapable of partaking in what humans consider pleasurable,
fucking, eating and maybe sleeping, and additionally immortal, the
inevitable result are eons of brooding over one's inadequacies.
 
R

Rainer Weikusat

Mladen Gogala said:
Well, Douglas Adams was actually a satirist, not a science fiction
writer. His Marvin, the paranoid android, is really a funny creation.

Not so much when thinking a little about it: Marvin as a character is
really very much similar to a classic tragic hero whose life
ultimatively leads to a catastrophic failure because, considering the
situation and himself, that's the only possible outcome.

And there's something to learn here for the 19th-century fixated reverse
luddites who believes the solution to any conceivable problem must be
that some (heroic) engineer builds a more complicated machine: Computers
are already so complicated than controlling them in order to make them
do useful things is an engineering discipline in its own right in
everything but the name. Assuming that an even more complicated machine
can be built, chances are that it will be impossible for humans to
control it. It can then be said to be 'intelligent' but it won't
be useful as a machine anymore. Possibly because - as a side effect of
'intelligence', it gained all the human deficits enabling machines to
produce better results than humans in certain circumstances, eg, a
memory which - while capable of storing every piece of information a
human encounters during its lifetime, is heavily priorised towards
keeping "knowledge which is useful for the individual right now" easily
accessible at the expense of keeping the less important stuff in ever
more remote 'attic areas': That "intelligent design" by "bright minds"
can beat nature itself in this area is - at best - an unproven and
highly optimistic hypothesis.
 
J

johannes falcone


python is gateway drug to java and oracle which try and influence banks and money to flow into ventures which can easily be converted to oracle java once funded or bought out
 
Ad

Advertisements

J

johannes falcone

'Artificial Intelligence' is bullshit: Computers are useful because

they're not intelligent, that is, capable of influencing circumstances/

situations for their own benefit, and people who lust for 'inelligent

beings without civil rights' should consider getting professional help,

at least in the parts of the world where slavery has been abolished, so

that they eventually get over that.

the constitution gives you the right to persue hapiness in the usa

there are no other civil rights

all case law should be abolished

end public school

use atomic power

end foriegn wars

end regulation on factories

end unions

replace lawyers with software

fund defense on import tariffs alone
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top