"If it cannot be read and completely understood in a month, it's broken beyond repair."
My new mantra in #FreeSoftware development.
@Shamar
Do you grant exceptions to enormous projects, or is considering them broken a feature? :>
No exception.
Enormous projects produce enormous risks (when not enormous threats).
It's time to move beyond the stone ages of #Informatics.
@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.
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.
@https://qoto.org/users/Shamar have you heard of oberon?
@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/
@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.
@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