Re: Rewriting pkglint in a portable language

[Roy Marples <roy%marples.name@localhost>]

Hi

On 23/03/2016 20:33, Roland Illig wrote:
> due to ongoing problems with the portability of the Go programming
> language, I have considered to rewrite pkglint in another programming
> language.

Yay

> My currently preferred language is Vala/Genie from the GNOME project,
> which I don't yet speak fluently, but from what I have done in it, it
> seems to be very easy.
> 
> * It has garbage collection.
> * It has memory protection.
> * It has a built-in string datatype (unlike C).
> * It has concise syntax.
> * It compiles to C, using the glib object model, which I guess is
> portable to all platforms pkgsrc will ever run on.
> * It compiles to reasonably fast code.
> * Performance-critical parts could be written directly in C.

I don't see any bullet points there I would consider critical for pkg_lint.

Here is my bullet point:
Why should pkg_lint be the sole consumer of yet another language on my
laptop?
Having it install Go the last time I synced was quite a surprise!

If Vala/Genie can compile to C

> For benchmarking the speed, I wrote a recursive grep in Go, Vala, Genie
> and Nim, and compared that to the native grep. I chose this simple task
> because pkglint heavily depends on IO and parsing text files. The Vala
> version was about 50 percent slower than the Go version, which in turn
> had half the speed of the native grep.

Speed has never been an issue for me.
Correctness, portability and a lack of suprises (like needing Go) are
the main things.

> If someone can convince me that C++ or even C is better suited, please
> do so. I just fear the undefined behavior too much.
> 
> Or if you prefer it to be written in a scripting languages like Perl,
> Python, Ruby, Lua, please provide some hints that it won't execute as
> slowly as the old Perl version. And, by the way, I like statically typed
> languages with explicit variable name checking, since they catch many
> errors at compile time.

To avoid intalling yet another language, I think your choices are
limited to these:

C
C++
POSIX Shell
Python
Perl

I'm relucant to add Lua because although it's in NetBSD it might not be
anywhere else by default.

I even listed them in order of preference (mine of course).
Time is also not an issue - we're not going anywhere and we don't need
it yesterday. If it were me, I would retire pkglint-go, restore
pkglint-old to pkglint and take the time you need to Do It Right.

Roy