"If it cannot be read and completely understood in a month, it's broken beyond repair."
My new mantra in #FreeSoftware development.
No exception.
Enormous projects produce enormous risks (when not enormous threats).
It's time to move beyond the stone ages of #Informatics.
I used to trust #GCC.
I spent a huge amount of my free time over the last 2 years to port it to my operating system (a Plan 9 fork).
In fact, Jehanne has been the first Plan 9 fork to run a modern GCC (9.2.0) and compile C++ programs correctly.
Then, with the removal of #RMS by the GCC Steering Committee, I realized they cannot be trusted: https://gcc.gnu.org/pipermail/gcc/2021-April/235285.html
Indeed they are discussing to leave #GNU in these days.
Now I'm exploring the alternatives.
So far, #TinyCC looks promising: https://bellard.org/tcc/
Other alternatives are listed here http://suckless.org/rocks/ but some requires either linker or assembler.
And while I obviously ported GNU binutils too, I prefer to avoid this toolchain since they are all showing they do not give a shit about free software, but about "#IBM, #Google, #Facebook, #ARM, or other big supporters" https://gcc.gnu.org/pipermail/gcc/2021-April/235367.html
A serious alternative could be the 9front compiler suite that I dismissed years ago because I was still naive (dumb).
Also, it's urgent to design better programming languages, and for "better" I mean simpler both for humans and for compilers/interpreters. So that all people will be able to read the software they use.
But the point remains: if it cannot be completely read and understood in at most a month by a single professional programmer, it's broken beyond repair and need to be replaced.
@Shamar I was mostly interested in the simplicity aspect, I think most compilers I know would not satisfy the "one month" requirement. Politics aside, do you think gcc can be understood within a month?
Strong agree on better programming languages being needed, but the ones I consider good for creating programs that follow the simplicity ideology are not that simple themselves, and definitely don't have simple compilers. I expect there might be some very hard to resolve conflict between these requirements.
GCC does not satisfy the "one month" requirement: that's why we need better compilers (and languages)
But this IS a political issue!
If you cap complexity, you reduce costs and this way you reduce the power corporation can extort to users.
If you can rewrite anything you run in a month, no company is going to betray your trust.
As for the "simplicity ideology with complex compilers" you are talking about, I think you are confusing simplicity and easiness.
Simplicity is very different from easiness: simplicity provides freedom, easiness produce lock-in. But more often than not, simple tools requires more mental effort than easy one.
IMHO simplicity should always be preferred in Free Software.
That makes sense, I was worried there for a moment that I was vastly overestimating how complicated gcc is.
I know that Free Software is inherently political, I only wanted to skip over the personal politics surrounding RMS right now, and couldn't think of a better word for that.
I haven't heard this argument about the political implications of simplicity, I usually value it for its directly practical results of avoiding bugs. The argument sounds correct and quite interesting.
Oh, I'm pretty sure I'm not confusing these two. In my experience the languages which are best for writing simple programs are, among other properties, quite strongly typed. These languages are arguably more complex than weakly typed ones, and their compilers are _definitely_ more complex, type checking is a provably (heh) hard problem. So I understand the simplicity/easiness distinction, although I guess I might have a slightly different view on which languages are best for writing programs with a simple design.
@Shamar
The great majority of the #SoftwareLibero I use are too complex to be rewritable in one month, even given infinite resources: Linux, Firefox, GCC, LibreOffice, GNOME, Gimp.how could you possible rewrite them in such a brief time?
@timorl
Just like it was writen in the first time.
With "olio di gomito". 😉
("olio di gomito" is an Italian way to say "with a lot of hard and valuable work")
But beware: you can't build the SAME software system from scratch AND make it simple.
No matter how good and simple are your tools (language, compilers, operating systems...) if you want to build #GCC, #Linux, #Chromium, #Firefox and so on, you are just going to fail and waste huge amount of time.
You are addicted to primitive tools (mis)designed to lock everybody in and keep powerful élites in control of your computing.
The next generation of #FreeSoftware that I envision will be very different.
Designed to empower.
@https://qoto.org/users/Shamar have you heard of oberon?
@https://qoto.org/users/Shamar @https://qoto.org/users/Shamar omg! did you check https://github.com/vishaps/voc?
also there is modula-3 compiler, and it got a new release recently.
@tanakian@ծմակուտ.հայ
No, I didn't new Vishaps's #Oberon compiler. Pretty interesting!
Maybe they should add it to http://oberon07.com/compilers.xhtml
My favourite one is #OBNC https://miasap.se/obnc/
@https://qoto.org/users/Shamar i am the author of vishap. i think the page mantainer doesn't think voc is worth puting there, or may be because it's not o-07 compiler. i hope voc can be used, it shows itself very good in tests.
look here: https://github.com/vgratian/CosineBenchmark
@tanakian@ծմակուտ.հայ
Out of curiosity, in your opinion and experience, what are the advantages of Oberon-2 over Oberon-07?
(I don't think it's a matter of worth: that page explicitly states that "It does not document variants, e.g. Component Pascal, Oberon-2, unless those are treated as extensions", that in fact looks reasonable to reduce confusion, given the site name...)
@https://qoto.org/users/Shamar hello, hard to answer after a hard work day.
well, i don't know, i think they are comparable. oberon-07 is the simplest oberon compiler ever written. i actually have my implementation, that's the earliest port of wirth's compiler made in 2008. since then wirth changed his compiler a lot. i like my o7 implementation because it doesn't depend on libc, generates very compact code. but works only under 32bit linux. but because i wasn't sure i can distribute it, i started working on oberon-2 compiler by using op2 and ofront.
i recently figured out, it is not a problem so i published it, but i don't think it is very useful, compared to voc, because voc is ported to many platforms, and has a lot of libraries. i like in my o7c implementation that i have zero dependency on C code. the only deps are just GNU assembler and linker. i am thinking of writing a completely new compiler with the new parser, which won't be based on op2 or latest po13 wirth's compiler. i am thinking of supporting both o-07 and o-2 dialects in it.
so oberon-2 introduced so called 'type bound procedures' - the type of oop people tend to like.
i myself, however, whenever possible use just oberon-1 or oberon-07 style oop.
however i like that oberon-2 has syntax that explicitly mentions that a dynamic array is actually a 'POINTER TO ARRAY OF CHAR' but i know that wirth doesn't like that notation.
yes, btw, oberon-2 has dynamic arrays, oberon-07 doesn't, according to report. i think if i remember correctly, wirth's implementation has dynamic arrays that work with 'ARRAY OF CHAR' declaration.
i think overall oberon-2 and po2 based compilers are pretty mature, and a lot of code have been compiled with oberon-2, and it shown its strengths both in Oberon V4 and S3. also component pascal is basically an extension of oberon-2.
while i have an impression that wirth's latest compiler, though is a masterpiece of compiler design, and as i said, it's a simplest oberon compiler ever written, but i think it's not as mature, and it was not used as much, and therefore, debugged as much.
i like some features of oberon-07, such as read only global variable export. i also like the string assignment syntactic sugar of oberon-07, btw voc has it as well.
voc today is very practical. it works on linux/windows/macos, i used it on arm, on arm64, on many different platforms. its code is very fast, it has very low memory footprint. it is very easy to prepare wrappers to c libraries.
i wrote my irc bot with voc, it serves in several irc rooms today, including oberon room.
it's not a compiler of my dream, but it's practical.
i myself have mixed feelings, i like oberon-07, and i like oberon-2. i think it won't complicate my new compiler a lot if i support both languages in one, and have a commandline switch for the syntax check. let's see if i write it. (: i hope i'll find time. recently i am too busy at work, work under pressure, and have not much time for other activities.
@Shamar
Do you have any compilers you like? They seem to be kind of big and complicated by necessity, and I am wondering whether there are some simple ones that are still useful.