[m-dev.] A not-very-polite rant about "grades" and the build system.

[Michael Richter]

Yes, this is a rant. No it isn't polite. And, frankly, I don't give a
shit. If your feelings get hurt by people using bad words to describe your
work you have two options: curl up in a little ball and pretend the bad man
isn't out there, or man up and FIX THE FUCKING RETARDED SHIT YOU'VE
WRITTEN! (Sadly, I know which of these two I expect.)

The current system for building Mercury is an utter fucking disaster. It
is quite possibly the single dumbest thing ever put down in code in the
past fifty years. Not only does it default to building 14 "grades"
(asm_fast.gc, asm_fast.gc.debug.stseg, asm_fast.gc.decldebug.stseg,
asm_fast.gc.memprof, asm_fast.gc.prof, asm_fast.gc.profdeep,
asm_fast.gc.trseg, asm_fast.gc.trseg.debug.stseg, asm_fast.par.gc.stseg,
csharp, hlc.gc, hlc.gc.pregen, hlc.gc.trseg, hlc.par.gc, java), which means
building the compiler by the conventional ./configure && make && sudo make
install approach takes anywhere from 2 hours to 2 *DAYS* depending on the
hardware, getting around this massive multiplicity of default grades
requires advanced degrees in decoding whatever was pulled out of the
documentation writers' asses the day the grades were "documented".

Look at the documentation you have on the grades. Look at it closely.
Look at it WITHOUT YOUR YEARS OF HARD-WON ESOTERIC LORE. Tell me, can you
see anywhere any slight HINT of which grades interact well with each
other? Any slight HINT of which grades are likely to interact with each
other by subtly fucking your end-users over with maddening heisenbugs?
Even a slight hint of which grades don't make any sense whatsoever?

For example, where can I find in the docs something that tells me that
hlc.gc.stseg doesn't make any sense? (Protip: you can't.) And for bonus
points, what happens if you tell the configure script that you want
hlc.gc.stseg? (Hint: it merrily accepts it, as does the build, which then
mysteriously fails with bizarre compiler errors.)

Do you really hate your prospective users so much you won't even DOCUMENT
your fucking "grades"!? Like with a simple chart that shows at
intersection points whether the combination makes sense or not? I mean,
I'm not even asking for code that does this fucking shit right: a
configuration script that knows which grade combinations are
legal/sensible/whatever, or a build system that doesn't expect to build the
entire fucking world dozens of times up-front instead of building on
demand. I'm asking for a few words that explain the grades and their
legal/sensible combinations. Is that REALLY too much to ask after
SEVENTEEN FUCKING YEARS of this language's existence!?

This rant brought to you by the disgusted giving up after trying to get
Mercury running on a slow, non-x86 system for the past two days. I'll
leave it so someone less furious and more diplomatic to explain why what
utter shit you have for a build process.

[Matt Giuca]

Wow. I'm not on the Mercury team and I share your frustrations regarding
the build system (in fact, pretty much all of what you're saying is true),
but I gotta step in here... *this shit is not cool*.

I've been on the receiving end of some pretty pissed off entitled users in
my time, but I've never seen a rant like this about a free software
product. If you were a paying customer, you might rightly be upset, but
this would still be an inexcusable way to raise a complaint. As it is,
you're presumably just some dude on the Internet who downloaded some
software for free, got annoyed, and then swore your balls off at the
developers. That makes you an entitled jerk.

Here's a tip: when you're working with free software, the developers are
generally not obligated to do any work to either a) fix issues, or b) help
you with your problems. However, many open source projects will do (b), if
not (a), if you are polite about it. I understand the catharsis of writing
an angry rant when some software is behaving badly, but might I suggest
writing the rant, hovering over the "Send" button, considering the people
who might have to read said rant, and then deciding to rewrite it in a
polite and constructive manner?

You probably could have saved yourself some effort and made some friends if
you wrote a polite mail to this list in the first place, before you spent
two days trying to debug it yourself.

If they do fix this or update the documentation, I hope you will realise it
is *in spite of you* and not *because of you*.

Matt

PS. Your main complaint is answered in the second question in the official
FAQ
<http://www.mercurylang.org/information/doc-release/mercury_faq/Installing.html>
.

Post by Michael Richter
Yes, this is a rant. No it isn't polite. And, frankly, I don't give a
shit. If your feelings get hurt by people using bad words to describe your
work you have two options: curl up in a little ball and pretend the bad man
isn't out there, or man up and FIX THE FUCKING RETARDED SHIT YOU'VE
WRITTEN! (Sadly, I know which of these two I expect.)
The current system for building Mercury is an utter fucking disaster. It
is quite possibly the single dumbest thing ever put down in code in the
past fifty years. Not only does it default to building 14 "grades"
(asm_fast.gc, asm_fast.gc.debug.stseg, asm_fast.gc.decldebug.stseg,
asm_fast.gc.memprof, asm_fast.gc.prof, asm_fast.gc.profdeep,
asm_fast.gc.trseg, asm_fast.gc.trseg.debug.stseg, asm_fast.par.gc.stseg,
csharp, hlc.gc, hlc.gc.pregen, hlc.gc.trseg, hlc.par.gc, java), which means
building the compiler by the conventional ./configure && make && sudo make
install approach takes anywhere from 2 hours to 2 *DAYS* depending on the
hardware, getting around this massive multiplicity of default grades
requires advanced degrees in decoding whatever was pulled out of the
documentation writers' asses the day the grades were "documented".
Look at the documentation you have on the grades. Look at it closely.
Look at it WITHOUT YOUR YEARS OF HARD-WON ESOTERIC LORE. Tell me, can you
see anywhere any slight HINT of which grades interact well with each
other? Any slight HINT of which grades are likely to interact with each
other by subtly fucking your end-users over with maddening heisenbugs?
Even a slight hint of which grades don't make any sense whatsoever?
For example, where can I find in the docs something that tells me that
hlc.gc.stseg doesn't make any sense? (Protip: you can't.) And for bonus
points, what happens if you tell the configure script that you want
hlc.gc.stseg? (Hint: it merrily accepts it, as does the build, which then
mysteriously fails with bizarre compiler errors.)
Do you really hate your prospective users so much you won't even DOCUMENT
your fucking "grades"!? Like with a simple chart that shows at
intersection points whether the combination makes sense or not? I mean,
I'm not even asking for code that does this fucking shit right: a
configuration script that knows which grade combinations are
legal/sensible/whatever, or a build system that doesn't expect to build the
entire fucking world dozens of times up-front instead of building on
demand. I'm asking for a few words that explain the grades and their
legal/sensible combinations. Is that REALLY too much to ask after
SEVENTEEN FUCKING YEARS of this language's existence!?
This rant brought to you by the disgusted giving up after trying to get
Mercury running on a slow, non-x86 system for the past two days. I'll
leave it so someone less furious and more diplomatic to explain why what
utter shit you have for a build process.
--
"Perhaps people don't believe this, but throughout all of the discussions
of entering China our focus has really been what's best for the Chinese
people. It's not been about our revenue or profit or whatnot."
--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
_______________________________________________
developers mailing list
https://www.mercurylang.org/lists/listinfo/developers

[Michael Richter]

Post by Matt Giuca
You probably could have saved yourself some effort and made some friends
if you wrote a polite mail to this list in the first place, before you
spent two days trying to debug it yourself.

I tried this before. On 2013-03-24 to be precise. I wrote a very polite
critique of the build system along with some proposed solutions for it and
for the troubles it causes. It was very politely bike-shedded, then
ignored.

Community leadership may find they get the behaviour they reward. If they
want courtesy they should respond positively to courtesy. This is very
basic motivational psychology. The kind of stuff you get in Psych 101
classes.

PS. Your main complaint is answered in the second question in the official

Post by Matt Giuca
FAQ
<http://www.mercurylang.org/information/doc-release/mercury_faq/Installing.html>
.

P.P.S. No, actually, it isn't. My main complaint is that the build system
is retarded and undocumented for all practical purposes. My main complaint
is that there are NO PROVIDED TOOLS for using that "LIBGRADES=<grades>"
(which, on top of everything else, isn't even the correct way to do this
any longer; the correct modern way to do it is with
--enable-libgrades=<grades>). Or can you find the place in the docs where
the correct selection of grades and their interactions is put? (Hint: no,
you can't.)

P.P.P.S. Before lecturing me, Sparky, you probably should check history
*and* check that the docs you so smugly point out are a) the actual answer
to the problem (they aren't), and b) even accurate (they're not).

I strongly recommend that you think carefully before responding. And if
that's too much work for you, don't bother responding. I'm not in the mood
for listening to the wilfully ignorant.

[Matt Giuca]

Apologies if I'm continuing to derail this thread (but I doubt there's any
use having a constructive discussion in reply to this; best to just start a
new thread if you want to actually talk about the build system).

Post by Michael Richter
I tried this before. On 2013-03-24 to be precise. I wrote a very polite
critique of the build system along with some proposed solutions for it and
for the troubles it causes. It was very politely bike-shedded, then
ignored.

And this exonerates you? You asked politely, and it was considered but not
acted on, so that gives you the right to throw a hurricane tantrum? Christ,
if everyone acted like that in society, we'd be in utter turmoil constantly.

I return to my point about open source communities. Nobody *owes* you
anything, especially not software maintenance on your whim at zero cost.
You may have demanded (politely) a change. You may be completely right
about what needs to be changed, and they may even agree with you. But that
does not mean they have the resources or desire to make the change. In open
source software, if you want something fixed, you have three options:
- ask nicely (and you may get it, or you may not),
- pay someone to do it*,
- do it yourself.

* and don't shout at them either.

Community leadership may find they get the behaviour they reward. If they

Post by Michael Richter
want courtesy they should respond positively to courtesy. This is very
basic motivational psychology. The kind of stuff you get in Psych 101
classes.

It sounds like they did "respond positively", in that they considered your
suggestion rather than ignoring it. Are you suggesting that they should now
reward your tantrum with fixing the issue? I'm pretty sure Psych 101 would
recommend against it, lest it validate your foul behaviour.

Post by Michael Richter
P.P.P.S. Before lecturing me, Sparky, you probably should check history
*and* check that the docs you so smugly point out are a) the actual
answer to the problem (they aren't), and b) even accurate (they're not).

I'm not going to go back two years to find that you asked a question that
one time before lecturing you about basic human decency.

I strongly recommend that you think carefully before responding.
lol

tl;dr: Regardless of any valid arguments you may have (and I agree you have
them), you will not convince anyone to help you for free if you shout and
swear, and insult them, and that is true on the Internet as it is in real
life.

[Paul Bone]

Post by Michael Richter
P.P.P.S. Before lecturing me, Sparky, you probably should check history
*and* check that the docs you so smugly point out are a) the actual answer
to the problem (they aren't), and b) even accurate (they're not).
I strongly recommend that you think carefully before responding. And if
that's too much work for you, don't bother responding. I'm not in the mood
for listening to the wilfully ignorant.

These are personal insults/attacks. Please don't make such personal
insults or attacks. Matt made a simple assumption, an assumption that
anyone could have made, he (nor anyone else) is deserving of these attacks.

Matt responded to your post by rejecting your tone while validating your
complaint with the software. In your original post you asked the reader to
tollerate your angry tone however you arn't tollerating Matt's rejection of
that tone. If you want to stir up things be ready to accept the response.

I will respond to the technical points that you made on the original post.

[Paul Bone]

Post by Michael Richter
Yes, this is a rant. No it isn't polite. And, frankly, I don't give a
shit. If your feelings get hurt by people using bad words to describe your
work you have two options: curl up in a little ball and pretend the bad man
isn't out there, or man up and FIX THE FUCKING RETARDED SHIT YOU'VE
WRITTEN! (Sadly, I know which of these two I expect.)

Your feelings have been noted. I will distill the technical points you made
below, please let me know if I misunderstand you:

+ Too many grades causes confusion generally.
+ Too many grades causes long build/install times.
+ "make install" step does building (I don't remember if your e-mail
actually mentioned this).
+ It is difficult to know which grades are useful.
+ It is difficult to know which grades make sense and are
supported/tested.
+ The documentation is sparse (where does it say hlc.gc.stseg doesn't
make sense?)
+ The documentation doesn't tell the user what they want to know (which
grades do I want/need?)
+ ./configure accepts some nonsensical grades (hlc.gc.stseg)

You make the suggestion:

+ A chart of valid grade combinations would be useful.

By and large I agree and have said so in the past when these issues
were raised:

Here:
http://www.mercurylang.org/list-archives/developers/2013-March/015825.html

Which refers to your article here:
http://yfl.bahmanm.com/Members/ttmrichter/yfl-blog/mercury-time-to-hello-world

In particular I think that the article is clear and well-reasoned. It
clearly explains the issue and provides some suggestions. I personally
agree with the points it raises.

This has also been a continuing topic of discussion since. I understand
that discussion isn't useful and actually fixing things is.

If I remember correctly that there has been a small amount of work done to
help with a long term solution. However I agree that it's unfortunate that
more work hasn't been done. However as Matt pointed out most of the effort
that goes into Mercury is volunteer work, by people who have lives outside
of this project. I think that new developers would be really helpful and
I'll to my best to support and encourage anyone who wants to contribute,
especially to fix issues like these.


One of your issues that you raised today is new to me. That is that it's
difficult to find out which grade combinations are useful or even make
sense. For example:

+ In what situation would someone want to use the "hlc" grade? (Note
there is no "gc" grade component here.)
+ What kind of developer needs a "tr" or "trseg" grade component (this
one is documented, but could be clearer).
+ Is "debug" compatible with "java"?
+ Do I need "asm_fast.gc.debug" if I have "asm_fast.gc.decldebug"?

Taking this onboard I agree with you that a chart is a good first step. My
other thoughts haven't changed, that is that building grades either at
install time or on demand is a good idea (administrators or package
maintainer's choice).