Suggestion: Replace Perl with Lua in the OpenBSD Base System

classic Classic list List threaded Threaded
94 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)

Stuart Longland
On 1/1/20 9:08 pm, Marc Espie wrote:
> On Tue, Dec 31, 2019 at 10:36:15PM +0100, Anders Andersson wrote:
>> Of course its age is showing in some areas but in my experience, those
>> things are actually still worked on, and have been fixed without major
>> incompatibilities (python3 anyone?).
> The only thing that's really missing in perl is proper thread support.
> Don't know if that's going to happen.

To be fair, Python and NodeJS are pretty terrible at threading too.
Python has the Global Interpreter Lock.  NodeJS has worker threads, but
they're pretty limited in what they can do IIRC compared to the main thread.

Depending on what you're doing, this can matter a lot, or very little.
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

Reply | Threaded
Open this post in threaded view
|

Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)

Stuart Longland
In reply to this post by Marc Chantreux
On 2/1/20 12:30 am, Marc Chantreux wrote:
> * the python community was unfair comparing the langages (using ugly
>   perl code and nice python counterparts). instead of taking time to
>   explain all the biases, perl community repetedly asserted that the
>   authors of those article were incompetents and gone away.

Heh, I've heard Perl described as executable line noise, and for sure,
it will let you write code like that.

But so does C.  There's even a contest for doing exactly that.

I've seen some pretty ugly Python code too.

If you set out to write ugly code, you will get ugly code, doesn't
matter what the language is.  If you set out to write a thing of beauty,
it can be that thing of beauty.

It's more a factor of the programmer involved and their skill, rather
than any fault of the language in most cases.
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

Reply | Threaded
Open this post in threaded view
|

Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)

Marc Espie-2
On Thu, Jan 02, 2020 at 07:34:22PM +1000, Stuart Longland wrote:

> On 2/1/20 12:30 am, Marc Chantreux wrote:
> > * the python community was unfair comparing the langages (using ugly
> >   perl code and nice python counterparts). instead of taking time to
> >   explain all the biases, perl community repetedly asserted that the
> >   authors of those article were incompetents and gone away.
>
> Heh, I've heard Perl described as executable line noise, and for sure,
> it will let you write code like that.
>
> But so does C.  There's even a contest for doing exactly that.
>
> I've seen some pretty ugly Python code too.

Not to beat a dead horse, but most of the python configury stuff,
including scons, is pretty shitty.   Lots of really bad pseudo-OO stuf
(hey let's use that cool feature just because we can)

I hate when I have to fix python configure... it looks like a
bunch of complete beginners set up to reinvent a square wheel.

python is definitely my #1 most-hated language when fixing configure in
ports. Yes, it beats autoconf and libtool by a large margin.

Reply | Threaded
Open this post in threaded view
|

Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)

Marc Chantreux-2
In reply to this post by Frank Beuth
> Not sure about anyone else, but comparing the Python vs Perl example you
> gave above, I would still say Python is the nicer-looking language.

i was just saying that there is no need for yield in perl. now i can
show you tons of examples to demonstrate perl code is not only
more "unixish" but easier to:

* write
* read
* modularize (__init__.py always made me smile)

when you have to manipulate text files or large datastructures, python
is far behind perl. i won't try to convince you but to illustrate what
is said before.  see this code:

use v5.20;

while (<>) {
    chomp;
    # trim and print lines only when not empty
    say s/
        ^ \s+    # triml
        | \s+ $  # trimr
    //rx if /\S/;
}

this is *hell* for a unix newbie:

* regexps is a concept that windows programmers (so python ones too)
  try to avoid (pretending it's hard to understand and read)
* ARGV ... what is a "filter" anyway? i don't want to read about
  the unix litterature to write my code.

to be fair: if you just write a web application or a datascience script
were datasources are from binary formats or databases and libraries are
available, you just don't need those tools and run away is probably
the good strategy (python *is* indeed easier to learn when you have
simple things to code). if you believe in text streams and simple formats
in a unix land (which i do), or if you need to solve complex problems,
learn those concepts and be familiar with them is worth it.

another "line noise" bullshit comes from sigils and i have to admit
i though sigils made my script looks "not professional" when i was
younger (having a php background). But when you understand the way
sigils works, it appears that it is very informative and useful:

* they always give clues about the structures you're working with
* they permit some very useful shortcuts

as example: hash slices is something i always miss in python.

    use v5.20;
    my %user;
    my @names = qw( uid gecos home shell );
    my @cols  = qw( 0   3     5    6     );

    @user{@names} = map
        { chomp; (split /:/)[@cols] }
        `getent passwd mc`;

    printf '%s is the default shell for %s'
    , @user{qw( uid shell )};

sure, python is evolving in the good direction (see PEPs 448, 449, 572 ...)
but so many things are missing to be confortable comparing to perl
(sometimes little ones but so convenient). some examples that comes to
my mind:

the quoting system

    # qw( for a list of barewords )
    my %user = qw(
        login  mc
        shell  /bin/zsh
    );
    print $user{login};

    # q() and qq() to replace '' and "" when it's complicated
    my $comment = qq{
        with qq() you can choose your delimiter like in sed
        so you can't get it wrong or unreadable
        even if you have """""" in mind
    }

yada to spot an unimplemented section
(https://perldoc.perl.org/perlsyn.html#The-Ellipsis-Statement)),
the //g modifier with the \G anchor (so you can iterate in a string with regexp matching), ...

so many other ones. and python people don't get those are
very useful features. when i asked for fair help, the
anwsers were often flooded in tons of messages like:

* you don't need this
* you shouldn't program with this
* perl is dead

So even the community is anoying and i don't want
this logo++ to be unfairly compared to perl anymore
but as i said: i don't want to reboot a 2 decades sterile
feed:

* since 3.4 python became bearable (so much saner than php or js)
  and a good tool for teaching OO.
* both python and perl are langages from the last millenium with
  lot of issues that are fixed in raku. so that's the spot i switched to.

cheers
marc

Reply | Threaded
Open this post in threaded view
|

Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)

Marc Chantreux-2
In reply to this post by Stuart Longland
hello Stuart,

> Heh, I've heard Perl described as executable line noise, and for sure,
> it will let you write code like that.

arf ... i just tried to explain were this "linenoise" bullshit came from
just in the answer i gave to frank

regards
marc

Reply | Threaded
Open this post in threaded view
|

Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)

Marc Espie-2
In reply to this post by Marc Chantreux-2
On Thu, Jan 02, 2020 at 12:40:51PM +0100, Marc Chantreux wrote:
> the quoting system
>
>     # qw( for a list of barewords )
>     my %user = qw(
>         login  mc
>         shell  /bin/zsh
>     );
>     print $user{login};

I wouldn't write it that way

my %user = ( login => 'mc', shell => 'bin/zsh');

is way more readable in that case, I think,
and it does showcase what a *smart* quoting system can do.

Reply | Threaded
Open this post in threaded view
|

Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)

Marc Chantreux-2
hello,

> >     my %user = qw(
> >         login  mc
> >         shell  /bin/zsh
> >     );
> >     print $user{login};

> my %user = ( login => 'mc', shell => 'bin/zsh');
> is way more readable in that case, I think,
> and it does showcase what a *smart* quoting system can do.

well ... i prefer the way i wrote because i love to:

* remove useless symbols
* read columns

but yes: the drawback of perl is: there are so many ways to do
it so every project needs a clear coding style.

regards
marc

Reply | Threaded
Open this post in threaded view
|

Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)

danieljboyd
I don't understand why people say that perl's flexibility is a negative.
Bad code is a negative. You can have bad or inconsistent code even in a
language like python that has very rigid syntax.

As long as you know perl well, you should be able to read any
well-written perl code.

To me, both of those examples are equally readable, though, I'd lean
more towards a multiline approach with the second:

my %user = (
    login => 'mc',
    shell => 'bin/zsh',
);

On Thu, Jan 02, 2020 at 04:22:08PM +0100, Marc Chantreux wrote:

> hello,
>
> > >     my %user = qw(
> > >         login  mc
> > >         shell  /bin/zsh
> > >     );
> > >     print $user{login};
>
> > my %user = ( login => 'mc', shell => 'bin/zsh');
> > is way more readable in that case, I think,
> > and it does showcase what a *smart* quoting system can do.
>
> well ... i prefer the way i wrote because i love to:
>
> * remove useless symbols
> * read columns
>
> but yes: the drawback of perl is: there are so many ways to do
> it so every project needs a clear coding style.
>
> regards
> marc
>

Reply | Threaded
Open this post in threaded view
|

Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)

Marc Espie-2
In reply to this post by Marc Chantreux-2
On Thu, Jan 02, 2020 at 04:22:08PM +0100, Marc Chantreux wrote:

> hello,
>
> > >     my %user = qw(
> > >         login  mc
> > >         shell  /bin/zsh
> > >     );
> > >     print $user{login};
>
> > my %user = ( login => 'mc', shell => 'bin/zsh');
> > is way more readable in that case, I think,
> > and it does showcase what a *smart* quoting system can do.
>
> well ... i prefer the way i wrote because i love to:
>
> * remove useless symbols
> * read columns

Well, => and ,   allow to figure out errors in odd/even hashes easily.

I will always lean towards idiot-proofing the code.

Reply | Threaded
Open this post in threaded view
|

Re: Suggestion: Replace Perl with Lua in the OpenBSD Base System

Strahil Nikolov
In reply to this post by Frank Beuth
On January 1, 2020 2:14:03 PM GMT+02:00, Frank Beuth <[hidden email]> wrote:

>On Wed, Jan 01, 2020 at 10:29:53AM +0000, [hidden email] wrote:
>>> But I don't want deeper point to get missed -- which is that if eecd
>>> doesn't like the idea of regulating what the programmer can do, then
>the
>>> programmer has to have the skills to safely write unsafe code.
>>
>>no you're belying the point: the good programmer regulates himself
>>while you
>>want to police everything and everyone else to compensate for your own
>>shortcomings
>
>I don't think I suggested anywhere that I want to police anyone else. I
>largely agree with what you write with respect to self-regulation.
>However, I'm not sure that ranting about it on misc@ is the most
>effective way to make positive progress in the desired direction.

I have never imagined  the day when so much spam will cover this mailing list.

Don't we  have  '[hidden email]' for that purpose ? If not, now is the time to consider creating one.

Anyway, perl is not my favourite  - but at least it does the job in a predictable manner.

Best Regards,
Strahil Nikolov

Reply | Threaded
Open this post in threaded view
|

Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)

Marc Chantreux-2
In reply to this post by Marc Espie-2
> I will always lean towards idiot-proofing the code.

:))

fair enough.

regards

marc

Reply | Threaded
Open this post in threaded view
|

Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)

Marc Chantreux-2
In reply to this post by danieljboyd
On Thu, Jan 02, 2020 at 10:42:54AM -0600, [hidden email] wrote:
> I don't understand why people say that perl's flexibility is a negative.

because sometimes, flexibility permit some endless sterile debates about
the coding style.

marc

Reply | Threaded
Open this post in threaded view
|

Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)

Daniel Jakots-6
On Thu, 2 Jan 2020 19:49:28 +0100, Marc Chantreux <[hidden email]>
wrote:

> some endless sterile debates

Like this thread, or worse?

Reply | Threaded
Open this post in threaded view
|

Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)

Marc Espie-2
In reply to this post by Marc Chantreux-2
On Thu, Jan 02, 2020 at 07:49:28PM +0100, Marc Chantreux wrote:
> On Thu, Jan 02, 2020 at 10:42:54AM -0600, [hidden email] wrote:
> > I don't understand why people say that perl's flexibility is a negative.
>
> because sometimes, flexibility permit some endless sterile debates about
> the coding style.

Well, OpenBSD has got style(9). I have some specific adaptations for perl,
because a lot of the rules are for C.


Here are my current guidelines for OpenBSD perl tools.

In general, things are written following style(9) adapted for perl.

Specifically,
- named sub *are* functions.

So

sub f
{
        my ($arg1, $arg2) = @_;

        ... code

}

- three styles of parameter grab for methods:


sub m1
{
        my $self = shift;
}

No other parameter.

sub m2
{
        my ($self, $p1, $p2) = @_;
}

when getting all parameters (no check on the number usually)


sub m3
{
        my $self = shift;
        ...
        do_something_with(@_);
}

for functions with unlimited parameters after the first one

(dubious whether this changes anything for performance reasons)

- wantarray should *only* be used for optimization purposes (yes/no answer
instead of full list).   Doing otherwise utterly complicates matters.


- I almost never put extra parentheses, and use the "4 space indent" rule
for continuing statements.

- chained index lookups should ditch the extra ->  .
prefer $self->{a}{b}  to $self->{a}->{b}

- don't put quotes around indices unless absolutely necessary (keywords)
and don't use keywords for keys.


- anonymous subs are part of the code:
So:
        my $s = sub {
                my $self = shift;
                ...
                };


Note a full indent because the inside looks like code.

- modern perl prefered, so
    $value //= something;
prefered over
    $value = something  if !defined $value;

- autovivification welcome.

push @{$self->{list}}, value;
is perfectly fine without defining $self->{list} first.
Note that if (@{$self->{list} > 0)  *won't* autovivify list, so it can be
used for "does the list exist and is not empty" instead of
if (exists $self->{list}


- I should probably normalize towards banning implicit return ?

- should I prefer "always refs"  over explicit % / @ ?
There is a slight legibility problem:
my @l;  is more readable than
my $l;  (this is a list)
and
my $l = [];   takes slightly more memory.


- most things unless explicitly being debugged should set
$DB::inhibit_exit = 1  right afer a fork and before an exec.


And I have some further general rules, learnt from past mistakes.

The perl package tools follow some stylistic and practical guidelines
- all new development should be object-oriented.
Have a package under either OpenBSD or DPB, and pass operations
to a constructed object (generally name the constructor new unless
you have better options) if you need to keep state, or to the
class name proper.

Examples:

my $pkgpath = DPB::PkgPath->new('devel/quirks'):

say "Normalized version is ",  $pkgpath->fullpkgpath;

$state->errsay(OpenBSD::Temp->last_error);

older code sometimes does not respect that.
It hasn't been converted because it's currently not worth it.
But there have been many instances where I've actually regretted
not doing things that way sooner.

The object itself is usually called "$self" unless there are reasons
not to.

Since there are no access control restrictions in perl, most often
internal methods are just prefixed with _.

Stylistically, methods without parameters don't need parameters, so
I don't write them, prefer $object->foo  to $object->foo()

It makes it less cumbersome to chain methods, e.g., $object->foo->bar(whatever);

- in the interest of chaining methods, stuff that tweaks an object should
return the object itself, so that

    $self->set_foo(1)->set_bar(2)->run

will actually work

- a lot of code creates "unique" objects.
The pattern is to have a %cache hash in the package, and have the normal
constructor do things under the radar, calling create as needed.
create won't normally be used by client code.

- a lot of code creates "just in time objects".
Error.pm containt the OpenBSD::Auto class, that can be used to create
jit values, it contains one single construct, cache, that is used like so:
OpenBSD::Auto::cache(solver,
    sub {
    require OpenBSD::Dependencies;
        return OpenBSD::Dependencies->new(shift);
    });

so that the first call to $self->solver(x)
will instantiate $self->{solver} to the required object.
And that call and all subsequent calls will return the same object.


- there are way less files than classes. Things are organized in a
"put a whole set of related things together in the same file".
Full OO also means you don't need to use Foo; from the start, you can
require Foo; dynamically, thus loading it later.  This does speed up the
startup of tools significantly.

- in general, singletons are frowned upon. We still have a few (list ?),
mainly as cached values in specific packages.  There is some kind of global
state though, and that's generally handled through the $state object.


- DON'T USE MULTIPLE INHERITANCE unless absolutely necessary.
It's almost always a mess.  Grabbing some behavior from a class (mixin)
is best done on a per-method basis.
Know about &function;  (without the paren) which is a "goto that sub with
my @_ totally unchanged". So mix-ins can (and usually) do:

package B;

sub f
{
        &A::f; # delegate to A
}

Reply | Threaded
Open this post in threaded view
|

Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)

Chris Bennett-4
In reply to this post by Marc Chantreux-2
I don't speak Python, but from what I've read, it has some serious
encoding problems compared to Perl.
This is a real problem in today's world of multiple encodings.

Apparently the guy writing about this is pretty hated for bringing up
this serious flaw. If the problem is true, he has examples, then it
needs to get fixed.

Perl also has problems, but screwing up encodings is pretty fundamental.

mod_perl, from reading the mailing list, looks like it will die off
before long. Lack of developers and funding and interest given all the
newer replacements.

Remove Perl? No way.
Perl is very Unixy. Perl is full of automagically. C isn't.
I think they make for a good combo.

Think this way         -> use C
Think other way        -> use Perl
Think really screwball -> use both

OK, enough of my BS, but this is an interesting thread.
I do think discussing many languages that can be used is relevant to
both misc@ and ports@

Bye Y'all,
Chris Bennett


Reply | Threaded
Open this post in threaded view
|

Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)

Marc Espie-2
On Thu, Jan 02, 2020 at 03:24:41PM -0500, Chris Bennett wrote:
> mod_perl, from reading the mailing list, looks like it will die off
> before long. Lack of developers and funding and interest given all the
> newer replacements.

Don't even think about using mod_perl these days.

Fast-cgi is the way to go. Even if you use something else but Dancer,
I'd urge you to read the documentation, it has a whole fucking manpage
about Dancer::Deployment

Reply | Threaded
Open this post in threaded view
|

Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)

danieljboyd
In reply to this post by Marc Espie-2
What if you want named parameters? (i.e. sending a hash as your
argument)

sub m4
{
    my $self = shift;
    my %args = @_;

    # and then optionally
    my ($arg1, $arg2, $arg3) = @args{qw/arg1 arg2 arg3/};

    # or you can just use $args{arg1}, etc...
}


On Thu, Jan 02, 2020 at 09:12:42PM +0100, Marc Espie wrote:

> sub f
> {
> my ($arg1, $arg2) = @_;
>
> ... code
>
> }
>
> - three styles of parameter grab for methods:
>
>
> sub m1
> {
> my $self = shift;
> }
>
> No other parameter.
>
> sub m2
> {
> my ($self, $p1, $p2) = @_;
> }
>
> when getting all parameters (no check on the number usually)
>
>
> sub m3
> {
> my $self = shift;
> ...
> do_something_with(@_);
> }
>
> for functions with unlimited parameters after the first one

Reply | Threaded
Open this post in threaded view
|

Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)

Marc Espie-2
On Thu, Jan 02, 2020 at 02:40:25PM -0600, [hidden email] wrote:

> What if you want named parameters? (i.e. sending a hash as your
> argument)
>
> sub m4
> {
>     my $self = shift;
>     my %args = @_;
>
>     # and then optionally
>     my ($arg1, $arg2, $arg3) = @args{qw/arg1 arg2 arg3/};
>
>     # or you can just use $args{arg1}, etc...
> }

Such cases are a refactoring waiting to happen. If your parameters
get complicated enough that you want to name them, these's usually an
object hiding in there :)

Reply | Threaded
Open this post in threaded view
|

Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)

paul wisehart
In reply to this post by Marc Espie-2
On Thu, Jan 02, 2020 at 09:12:42PM +0100, Marc Espie wrote:
>
> Here are my current guidelines for OpenBSD perl tools.
>

Can you eleborate in greater detail?

Reply | Threaded
Open this post in threaded view
|

Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)

Marc Espie-2
On Thu, Jan 02, 2020 at 04:10:43PM -0500, Paul Wisehart wrote:
> On Thu, Jan 02, 2020 at 09:12:42PM +0100, Marc Espie wrote:
> >
> > Here are my current guidelines for OpenBSD perl tools.
> >
>
> Can you eleborate in greater detail?
>

Not really, just go read the code and ask questions.

You have something like 30000 lines of perl to play with ;)

12345