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 ...)

Marc Chantreux-2
On Thu, Jan 02, 2020 at 02:16:52PM -0500, Daniel Jakots wrote:
> On Thu, 2 Jan 2020 19:49:28 +0100, Marc Chantreux <[hidden email]>
> > some endless sterile debates

> Like this thread, or worse?

* long doesn't mean endless
* sharing points of view is never sterile (yours is inspired by other
  ones, right?)

so i think this thread is neither sterile nor endless but maybe it's
not the good channel: please let us know if there is a better place than
misc@ for that.

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 Marc Espie-2
> You have something like 30000 lines of perl to play with ;)

is there a todo list somewhere ?

regards
marc

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-2
On 3/1/20 8:50 am, Marc Chantreux wrote:
>> Like this thread, or worse?
> * long doesn't mean endless
> * sharing points of view is never sterile (yours is inspired by other
>   ones, right?)

I would say it's been highly educational.

Granted, this did not get off to a good start with the "let's replace
Perl with Lua" debate, but it has piqued my interest in what the Raku
team are up to.

It's pointed out style(9) which I'm having a read of now.  Having gotten
familiar with the Linux kernel coding style and the coding style used in
OpenThread, it's helpful sometimes to look at how others do it, as
sometimes you can learn something that ultimately makes your life easier.

There's a valid point about whether this is the appropriate forum for
this.  Question is, if not here, then where?
--
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 Espie-2
On 2/1/20 8:48 pm, Marc Espie wrote:
>> 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)

Yeah, you won't get any disagreement from me on that front.

I prefer make (usually I use the GNU dialect, but that's just borne out
of what I normally have to support), and maybe CMake for more complex stuff.

scons, waf, and others… seem to cause more problems than they solve.
--
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 ...)

Edgar Pettijohn III-2
In reply to this post by Marc Chantreux-2

On 2020-01-02 16:52, Marc Chantreux wrote:
>> You have something like 30000 lines of perl to play with ;)
> is there a todo list somewhere ?


find /usr/src -name '*.pm' | xargs grep XXX

Shows some promising results.


Edgar

> regards
> marc
>

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-2
On 2/1/20 9:43 pm, Marc Chantreux wrote:
> arf ... i just tried to explain were this "linenoise" bullshit came from
> just in the answer i gave to frank

Yes well, my point is if you want to make a piece of code
incomprehensible, I don't think there is a language that will stop you.

I had a colleague who used to argue "that code was hard to write, it
should be hard to read too!" -- completely forgetting the poor sod that
had to come behind him and maintain his code.

It's a choice of the writer to write code that's hard to understand.
Perl is a very expressive language, and can be used to write very clean
and maintainable code.

I think the "there's no right way" mantra helps: it allows you the
latitude to choose the style that makes the most sense for the problem
being solved.
--
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
In reply to this post by Stuart Longland
On Fri, Jan 03, 2020 at 09:43:21AM +1000, Stuart Longland wrote:

> On 3/1/20 8:50 am, Marc Chantreux wrote:
> >> Like this thread, or worse?
> > * long doesn't mean endless
> > * sharing points of view is never sterile (yours is inspired by other
> >   ones, right?)
>
> I would say it's been highly educational.
>
> Granted, this did not get off to a good start with the "let's replace
> Perl with Lua" debate, but it has piqued my interest in what the Raku
> team are up to.
>
> It's pointed out style(9) which I'm having a read of now.  Having gotten
> familiar with the Linux kernel coding style and the coding style used in
> OpenThread, it's helpful sometimes to look at how others do it, as
> sometimes you can learn something that ultimately makes your life easier.
>
> There's a valid point about whether this is the appropriate forum for
> this.  Question is, if not here, then where?

Any modern mailreader can easily tag messages as thread, so it's trivial to
avoid a given thread, as long as people don't fuck around with the
In-Reply-To info.

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 11:52:03PM +0100, Marc Chantreux wrote:
> > You have something like 30000 lines of perl to play with ;)
>
> is there a todo list somewhere ?

More or less in my head, with lots of subprojects progressing at any given
time.

- I want to retire PackageLocator and have more correct packagerepository
lists... Update.pm is somewhat hackish;
- the virtual file system (Vstat.pm) is too simple and somewhat broken;
- there are still a few bugs in dependency handling;
- pkg_info should probably be cleaned up at some point
- there is some complicated work to speed up pkg addition by going through
a kind of "proxy", exactly like pkg_add-over-ssh works... this part is not
perl, though.
- pkg_create handling of dependencies completely misses @tag currently
- lib-depends-check is a complete mess and doesn't work with subdirectories

- the tests in regress/usr.sbin/pkg_add are woefully inadequate.

- dpb doesn't support running tests, and it's intended to take on portroach
capabilities at some point.
- it should have a "disconnected mode" with just ssh and no nfs. Quite possible
now that we have rsync in base.
- I'd like to integrate proot a bit more... the way proot is engineered to
prefer hardlinks over copy  was intended to make it possible to "quickly"
create a separate chroot for each build (it's somewhat linked to the previous
point, as both require precise accounting of packages).

there are more, but those are the ones coming up at the top of my head.

Reply | Threaded
Open this post in threaded view
|

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

Holger Glaess
In reply to this post by danieljboyd
hi


you can do by array

sub m4
{
     my ( $self,$args ) = @_;

# $args contains
# $args->{'bla'} = blub
# $args->['do'} = whatever
}


as call ( example )

$obj->m4 ({ bla => blub , do => whatever });

holger



Am 02.01.20 um 21:40 schrieb [hidden email]:

> 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 Chantreux
In reply to this post by Stuart Longland

> Yes well, my point is if you want to make a piece of code
> incomprehensible, I don't think there is a language that will stop you.

indeed. but i now realize the counterpart is not true because everyone
has something different in mind when it comes to readability.

last example was yesterday: i wrote this in raku:

    my %final_pairs = @*ARGFILES.words.hash

i asked for code review for the python counterpart and we got:

    import sys

    def words():
        for s in sys.argv[1:]:
            with open(s) as fh:
                for l in fh.readlines():
                    for w in l.split(): yield(w)

    w = words()
    final_pairs = { k : v for k,v in zip(w,w) }

i don't need the perl version but it would something like:

    my %final_pairs =
        grep length,
        map { split /\S+/ }
        map { chomp; $_ }
        <>;

for me, readability score is: raku, perl, python but someone gives
arguments:

    * there is no reason a list could be considered as a hash by order
      of appearance
    * there is nothing more unreadable than implicity (split on what?
      what is $_?, <> iters on what?)

i strongly disagree but this is a valid opinion. i know that many
people struggle with side effects for example so $x++ is convenience for
the one of us that are used to iteration but it's hell for lot of
newcommers.

> It's a choice of the writer to write code that's hard to understand.
> Perl is a very expressive language, and can be used to write very clean
> and maintainable code.

that's it. and some of us hate expressivity because it means: learn how
the langage behave when it's preferable to describe the same patterns
again and again ...

> I think the "there's no right way" mantra helps: it allows you the
> latitude to choose the style that makes the most sense for the problem
> being solved.

yes ... but "it could be a default way because experience shown its
convenience or ability to solve the most common problem" (which is what
perl and raku do, i guess), is something that can be loved or hated.

regards
marc

Reply | Threaded
Open this post in threaded view
|

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

Marc Chantreux
In reply to this post by Marc Espie-2
> Any modern mailreader can easily tag messages as thread, so it's trivial to
> avoid a given thread, as long as people don't fuck around with the
> In-Reply-To info.

i have to admit this isn't an argument: if most of the people don't read
it, we should have the ability to save bandwidth by setting up a temp
list or adding a + alias. i add this in my todolist.

regards
marc

Reply | Threaded
Open this post in threaded view
|

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

Stuart Longland
On 3/1/20 8:31 pm, Marc Chantreux wrote:
>> Any modern mailreader can easily tag messages as thread, so it's trivial to
>> avoid a given thread, as long as people don't fuck around with the
>> In-Reply-To info.
>
> i have to admit this isn't an argument: if most of the people don't read
> it, we should have the ability to save bandwidth by setting up a temp
> list or adding a + alias. i add this in my todolist.

No rush… + suffix sounds a cleaner solution than hash tags. (looking at
you groups.io!)
--
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 Chantreux
In reply to this post by Holger Glaess
> you can do by array

Both of them are borring once you used the signatures but they are still
experimental.

Also: if you don't mind a new dependency: Function::Paramaters is so
much convenient.

regards
marc

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 Holger Glaess
True, but I think it’s cleaner when you’re actually calling the function to not have to send a hashref. Small thing, of course, but I figure you write a function once, but call it many times. I’d rather the function call be cleaner/simpler than the function definition for that reason.

Sent from my iPhone

> On Jan 3, 2020, at 5:29 AM, Holger Glaess <[hidden email]> wrote:
>
> hi
>
>
> you can do by array
>
> sub m4
> {
>    my ( $self,$args ) = @_;
>
> # $args contains
> # $args->{'bla'} = blub
> # $args->['do'} = whatever
> }
>
>
> as call ( example )
>
> $obj->m4 ({ bla => blub , do => whatever });
>
> holger
>
>
>
>> Am 02.01.20 um 21:40 schrieb [hidden email]:
>> 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
>

12345