Why not migrate Portage to C language?

[Ant P.]

I'd say "patches welcome" but we both know that's a hilarious fiction after seven years of hot air in this thread alone. Payment welcome.

[arnvidr]

Quite. It's hilarious calling the language 'unstable' because of an opinion on the way it is packaged in gentoo.

[Tony0945]

It is unstable if a new incompatible version comes out every two months, requiring the rebuild of hundreds of packages for no other reason. It is a maintenance nightmare that consumes resources that could be better applied to fixing bugs and improving code.

[xahodo]

Perhaps it's an idea to upgrade python less often, i.e. only when an upgrade is absolutely required?

[Hu]

Those rebuilds are usually because the version is part of the installed path. Yes, it's annoying that it changes without a specific benefit or good need, but how often do the new versions actually consume development resources that would otherwise be applied to improving the upstream project?

[Anon-E-moose]

You always have the option of a local overlay and locking the python version until you decide to upgrade.
Just because devs want to cycle every so often, it doesn't mean you (end user) has to.

It's a choice.

For me, I keep one python3 version, at a time. I also check the new stuff to see if I really need to upgrade at this time. It's not hard.

[figueroa]

Updates these days aren't much of a bother. If there are many or they take a log time, I don't watch the emerge window. I just go about my business. Even on low resource machines, I've not had a situation where I could not continue to work.

The only problem is when the update breaks things, and that's been infrequent, and least when running stable, and I do run stable.

[psycho]

Hardware will continue to get faster and faster...meanwhile difficult-to-follow code will still take ages for human beings to decipher...so the principle of keeping things in nice easily hacked formats (preferring readability over execution speed unless execution speed's vitally important) just makes more and more sense over time, as faster processors make shorter and shorter work of inefficient code. I'd prefer it if portage were faster, but I don't think it needs to be, and I certainly don't think it's worth making it a bit faster if that means making it a lot harder for people to maintain.

[Ant P.]

So python is "unstable" because it updates uneventfully on a regular schedule, and… portage should be written in C which is allegedly "stable" in comparison?

Like I said, oh, how many years ago? We have that. It's called Paludis. It's slower than portage, harder to work on, prone to segfaulting while updating *itself* and it got last-rited for a reason. But fish it out of the git history and knock yourself out, I don't have the patience to listen to this ridiculous ignorance any longer.

[Hu]

C is in an interesting position. As a standard, the language is very stable - perhaps too much so. I recall seeing somewhere some discussion about how some language improvement was rejected on the basis that it would have added new warnings to existing code. The standards committee is generally reticent to break existing programs, which leads to weird situations where new features must be opted in, just in case. (See, for example, C99 bool. The formal type name is _Bool to avoid stepping on anything, with a standardized header that can #define bool _Bool for people who want to opt in to using the easy name.)

As an implementation matter, many C compilers allow without warning constructs that an ideal developer (unlimited time, perfect expertise, etc.) would not use. Later iterations of the compiler often become stricter, rejecting constructs that were never legal, or changing how they are built because the language standard did not guarantee that the construct must produce the result that the earlier compiler happened to produce. Programmers are then surprised when their "working" code suddenly stops working, because it was never right, but older compilers happened to produce the result the programmer wanted.

Further complicating matters, there are enough quirks to the language that even people who spend a long time studying it and working with it can still get caught by obscure rules. Developers who can truthfully claim "perfect expertise" are rare.

[Tony0945]

Hu,
Does that apply squared and cubed to python?

[Hu]

I don't know. Most of the recent Python features that I can recall being added were made with some attempt to avoid invalidating existing programs, by not claiming for use as keywords any tokens that users were likely to have used as variable/function names. I think generally the Python language developers are less cautious about adding new functionality than the C standards committee is.

The Python2 -> Python3 transition was planned to have incompatibilities - and the specifics of those incompatibilities ultimately caused a huge mess, because it was so hard for people to convert over and have confidence they had done it right. This is part of why Python2.7 remained in service for so long. Converting large libraries to Python3 required a review in great detail by people intimately familiar with the library and the language, and many projects could not or would not afford the resources for that.

[Tony0945]

The Python2 -> Python3 transition was planned to have incompatibilities - and the specifics of those incompatibilities ultimately caused a huge mess, because it was so hard for people to convert over and have confidence they had done it right. This is part of why Python2.7 remained in service for so long. Converting large libraries to Python3 required a review in great detail by people intimately familiar with the library and the language, and many projects could not or would not afford the resources for that.

That is understandable and should have been a one time thing. what is irksome, so irksome that many of us are considering never updating is the whole mess is repeated with each minor python 3 version.

I'm getting the impression that actual useful packages are being deleted because all developer effort is on this damn python merry0go-round.

When tinkerng with the package manager consumes more effort than actually maintaining the packages, something is wrong!

[pjp]

(A) LISP it is then. Glad that's finally been settled.

[Hu]

(A) LISP it is then. Glad that's finally been settled.

Settled or thettled?

[GDH-gentoo]

Programmers are then surprised when their "working" code suddenly stops working, because it was never right, but older compilers happened to produce the result the programmer wanted.

And since GCC 10 has been mentioned, most programs that compile with -fcommon, but don't with -fno-common, fall in that category. To the best of my knowledge, it has always been stated that the language constructs that they contain (multiple external definitions of identifiers with external linkage) result in undefined behaviour. The number of such packages is frankly appalling.

[pjp]

(A) LISP it is then. Glad that's finally been settled.

Settled or thettled?

:)

[xahodo]

I have another... feasable... alternative. How about brainfuck? That would certainly lead to an improvement in stability and clarity.

Every programmer can code in brainfuck... right?

[xahodo]

If portage was written in C, with just the dependency on libc and maybe some crypto library (openssl?), there are quite a bunch of advantages over python:

• If python breaks, the package manager is not affected;
• Its total memory footprint would be a lot lower, allowing it to run on even a toaster;
• C is statically typed, so if the wrong type of value is assigned to a variable, that means a compile time error; as opposed to a runtime error, which could mean all kinds of harms;
• The C language and libc API are extremely stable, so code written today will probably be valid in 20 years;
• Python doesn't support as many architectures as C (gcc) does (at least, according to this, or am I using the incorrect source?).

[YetiBarBar]

• C is statically typed, so if the wrong type of value is assigned to a variable, that means a compile time error; as opposed to a runtime error, which could mean all kinds of harms;

I agree with "Having a compilation time error is better than "Runtime error". However, "Statically typed" doesn't mean "Type safe".

C is not a type safe langage. For example, a code like this one only produce a Warning with gcc.

Code: Select all

int main(int argc, char **argv)
{
	char my_str[] = "123456";
	int *wrong_type_ptr = my_str;
}

Furthermore, no langage will prevent coders to produce code with logic bug.

If I had pointer casting to the previous cast, no warning is longer raised but pointer computation could lead to funny bugs.

Code: Select all

int main(int argc, char **argv)
{
	char my_str[] = "123456";
	int *wrong_type_ptr = (int *)my_str;
}

[Tony0945]

Furthermore, no langage will prevent coders to produce code with logic bug.

If I had pointer casting to the previous cast, no warning is longer raised but pointer computation could lead to funny bugs.

Code: Select all

int main(int argc, char **argv)
{
	char my_str[] = "123456";
	int *wrong_type_ptr = (int *)my_str;
}

I can think of applications where you might want to do that. A pointer cast tells the compiler "I know what I'm doing." because the pointers are all exactly the same at the machine level, at least on i?86 machines and also on PowerPC. In fact, on the PowerPC, IIRC, unsigned integers and addresses look exactly the same.

If one doesn't know what one is doing, they shouldn't be working with sharp knives. But it's best to have a sharp knife when whittling, doing scrimshaw or grafting plants. Probably best for surgery too. Blunt scissors are for kindergarten.

[GFCCAE6xF]

Probably not worth the effort, doubt anyone wants to waste their time doing it (at least, not doing it unpaid).

[kske]

Out of curiosity, what standard of C would be suitable for this task?

C89 would be a safe choice as it is supported on almost every architecture. C99 brings a bunch of neat improvements to the table, both in terms of ease of use but also for optimization (restrict pointers and inline functions). Is it fully supported on all platforms targeted by Gentoo?

[GDH-gentoo]

Out of curiosity, what standard of C would be suitable for this task?

If (huge "if") this got done, latest version (ISO/IEC IS 9899:2018 a.k.a. "C17") would be fine, since it is the default mode for all current stable versions of GCC in all currently supported architectures that have stable profiles (and a stable version of GCC).

[pun_guin]

Like I said, oh, how many years ago? We have that. It's called Paludis.

* had

(A) LISP it is then. Glad that's finally been settled.

Yes, please!
Common Lisp can outperform C, the standard is proven to be stable (and matured rather well), and writing software in it is quite a nice experience.