GPU programming definitely is not beginner friendly. There's a much higher learning curve than most open source projects. To learn basic Python you need to know about definitions and loops and variables, but to learn CUDA kernels you need to know maybe an order of magnitude more concepts to write anything useful. It's just not worth the time to cater to people who don't RTFM, the README would be twice as long and be redundant to the target audience of the library.
It's kind of like if the Django README explained how SQL works, the structure of HTTP requests, best practices for HTML, and so on. If you don't know what MLIR is, you might not be the target audience for this library. Nvidia in general doesn't prioritize developer experience as much as companies like Meta do for open source projects like React.
HTTP and HTML are very common acronyms; nobody should be getting out of high school these days without knowing them, and if they somehow managed to do so, they're darned sure not reading HN. Even SQL is pretty hard to avoid if you've been in an IT-adjacent industry for a while.
However, MLIR is a highly-specialized term. The problem with failing to define a term like that is that I don't know up front if I'm the target audience for the article. I had to Google it, and when I did that, all I found at first were yet more articles that failed to define it.
Wikipedia gets the job done, but these days, Wikipedia is often a long way down the Google search results list. I think they downranked it when they started force-feeding AI answers (which also didn't help).
I did it in three. I selected it in your comment, and then had to hit "more" to get to the menu to ask Google about it, which brought me to https://www.google.com/search?q=MLIR which says: MLIR is an open-source compiler infrastructure project developed as a sub-project of the LLVM project. Hopefully
Get better at computers and stop needing to be spoon-fed information, people!
In this day and age, asking questions about what something is is a minefield of “just ask AI” and “You should know this”. Let’s stop putting down people who ask questions and root out those that have shitty answers.
I get why it feels frustrating when someone snaps "just google it." Nobody likes feeling dumb. That said, there’s a meaningful difference between asking a genuine question and demanding that every discussion be padded to accommodate readers who won’t even type four letters into a search bar. Expecting complete spoon-feeding in technical threads isn’t curiosity; it’s a refusal to engage. Learning requires participation.
I won't argue, but there is a middle ground between articles consisting of pure JAFAs and this:
accommodate readers who won’t even type four letters into a search bar
I think it helps if acronyms are expanded at least once or in a footnote so that the potential new reader can follow along and does not need to guess what ACMV^ means.
^: Awesome Combobulating Method by VTimofeenko, patent pending.
Asking "what is this?" is fine. Treating "I was unfamiliar with this" as evidence that the post is deficient is not.
HN already assumes a baseline of technical literacy. When something falls outside that baseline, the usual move is to ask for context or links, not to reframe personal unfamiliarity as an author failure.
So please, don’t normalize treating "I don’t know this yet" as a failure of the post.
But not defining acronyms on first use is a failure of etiquette. Its your prerogative to not hold this to be true, but many of us do. There is little value in eliding the on-first-use definition.
I agree but if someone asks “What is this?” and it’s not covered by the article, what we shouldn’t do is put that person down by telling them to “just google it”.
If that is your answer, please just don’t comment.
You cannot explain everything to everyone all the time. Besides, this is not even a paper.
Sometimes you are not the target audience and have to put some words into Google.
Because I think the norm we reinforce here actually matters.
When confusion gets framed as "this is substandard writing", it rewards showing up and performing a lack of context rather than engaging with the substance or asking clarifying questions. Over time that creates pressure to write to the lowest common denominator, instead of the audience the author is clearly aiming at.
HN already operates on an implicit baseline (CUDA, open source, LLVM, etc.) and mostly lets comments fill in gaps. That usually produces better discussions than treating every unfamiliar term as an author failure, especially when someone is just trying to share or explain something they care about.
So yeah, I am genuinely curious why you see personal unfamiliarity as something the entire discussion should reorganize itself around.
When confusion gets framed as "this is substandard writing", it rewards showing up and performing a lack of context rather than engaging with the substance or asking clarifying questions. Over time that creates pressure to write to the lowest common denominator, instead of the audience the author is clearly aiming at. ... So yeah, I am genuinely curious why you see personal unfamiliarity as something the entire discussion should reorganize itself around.
(Shrug) The fact is that all major style guides -- APA, MLA, AP, Chicago, probably some others -- call for potentially-unfamiliar acronyms to be defined on first use, and it's common enough to do so. For some reason, though, essentially nobody who writes about this particular topic agrees with that.
Which is cool -- it's not my field, so I don't really GAF. I'm mostly just remarking on how unusually difficult it was to drill down on this particular term. I'll avoid derailing the topic further than I already have.
From Wikipedia: The name "Multi-Level Intermediate Representation" reflects the system’s ability to model computations at various abstraction levels and progressively lower them toward machine code.
And yet you didn’t tell us what it stands for, just what it is. The person you’re responding to was specifically talking about finding out what it stands for
Comments
Fun game: see how many clicks it takes you to learn what MLIR stands for.
I lost count at five or six. Define your acronyms on first use, people.
GPU programming definitely is not beginner friendly. There's a much higher learning curve than most open source projects. To learn basic Python you need to know about definitions and loops and variables, but to learn CUDA kernels you need to know maybe an order of magnitude more concepts to write anything useful. It's just not worth the time to cater to people who don't RTFM, the README would be twice as long and be redundant to the target audience of the library.
That's the whole problem. I had to "R" multiple "FMs" before one of them bothered to define the acronym.
Stop carrying water for poor documentation practice.
It's kind of like if the Django README explained how SQL works, the structure of HTTP requests, best practices for HTML, and so on. If you don't know what MLIR is, you might not be the target audience for this library. Nvidia in general doesn't prioritize developer experience as much as companies like Meta do for open source projects like React.
HTTP and HTML are very common acronyms; nobody should be getting out of high school these days without knowing them, and if they somehow managed to do so, they're darned sure not reading HN. Even SQL is pretty hard to avoid if you've been in an IT-adjacent industry for a while.
However, MLIR is a highly-specialized term. The problem with failing to define a term like that is that I don't know up front if I'm the target audience for the article. I had to Google it, and when I did that, all I found at first were yet more articles that failed to define it.
Wikipedia gets the job done, but these days, Wikipedia is often a long way down the Google search results list. I think they downranked it when they started force-feeding AI answers (which also didn't help).
Use the AI prompt to pinprick learn.
Just say to the AI, "Explain THIS".
HN: "Learning is good"
Just say to the AI, "Explain THIS".
Also HN: "Not like that"
ChatGPT Told me MLIR stands for "Modern Life Is Rubbish"
YMMV
This is a GitHub repo for compiler engineers.
Cool. This is a site for hackers of all stripes.
I don't give "finance hackers" or "growth hackers" the time of day. Many hackers are held in utter contempt, and often for a very good reason.
I'm afraid I have some really bad news about your humble hosts here at Hacker News, then.
Yes, so given that you clearly had trouble figuring out what it was, maybe you could have shared with the class?
I did it in three. I selected it in your comment, and then had to hit "more" to get to the menu to ask Google about it, which brought me to https://www.google.com/search?q=MLIR which says: MLIR is an open-source compiler infrastructure project developed as a sub-project of the LLVM project. Hopefully
Get better at computers and stop needing to be spoon-fed information, people!
In this day and age, asking questions about what something is is a minefield of “just ask AI” and “You should know this”. Let’s stop putting down people who ask questions and root out those that have shitty answers.
Google is nearly 30 years old
And we are not counting Yahoo, Altavista, Ask Jeeves, MSN,...
I get why it feels frustrating when someone snaps "just google it." Nobody likes feeling dumb. That said, there’s a meaningful difference between asking a genuine question and demanding that every discussion be padded to accommodate readers who won’t even type four letters into a search bar. Expecting complete spoon-feeding in technical threads isn’t curiosity; it’s a refusal to engage. Learning requires participation.
I won't argue, but there is a middle ground between articles consisting of pure JAFAs and this:
I think it helps if acronyms are expanded at least once or in a footnote so that the potential new reader can follow along and does not need to guess what ACMV^ means.
^: Awesome Combobulating Method by VTimofeenko, patent pending.
Easy, if that’s how you feel, skip the comment and don’t engage.
Telling people who want to have that participation and discussion to “RTFM” is not a good response.
Often you’ll come across the authors on these posts that can shed direct, 1st person evidence, of what we’re talking about.
So please, when someone asks “what is that?” Don’t respond with “RTFM”.
Asking "what is this?" is fine. Treating "I was unfamiliar with this" as evidence that the post is deficient is not.
HN already assumes a baseline of technical literacy. When something falls outside that baseline, the usual move is to ask for context or links, not to reframe personal unfamiliarity as an author failure.
So please, don’t normalize treating "I don’t know this yet" as a failure of the post.
But not defining acronyms on first use is a failure of etiquette. Its your prerogative to not hold this to be true, but many of us do. There is little value in eliding the on-first-use definition.
I agree but if someone asks “What is this?” and it’s not covered by the article, what we shouldn’t do is put that person down by telling them to “just google it”.
If that is your answer, please just don’t comment.
You're posting a spirited defense of substandard technical writing. Just curious -- why is that?
You cannot explain everything to everyone all the time. Besides, this is not even a paper. Sometimes you are not the target audience and have to put some words into Google.
Because I think the norm we reinforce here actually matters.
When confusion gets framed as "this is substandard writing", it rewards showing up and performing a lack of context rather than engaging with the substance or asking clarifying questions. Over time that creates pressure to write to the lowest common denominator, instead of the audience the author is clearly aiming at.
HN already operates on an implicit baseline (CUDA, open source, LLVM, etc.) and mostly lets comments fill in gaps. That usually produces better discussions than treating every unfamiliar term as an author failure, especially when someone is just trying to share or explain something they care about.
So yeah, I am genuinely curious why you see personal unfamiliarity as something the entire discussion should reorganize itself around.
When confusion gets framed as "this is substandard writing", it rewards showing up and performing a lack of context rather than engaging with the substance or asking clarifying questions. Over time that creates pressure to write to the lowest common denominator, instead of the audience the author is clearly aiming at. ... So yeah, I am genuinely curious why you see personal unfamiliarity as something the entire discussion should reorganize itself around.
(Shrug) The fact is that all major style guides -- APA, MLA, AP, Chicago, probably some others -- call for potentially-unfamiliar acronyms to be defined on first use, and it's common enough to do so. For some reason, though, essentially nobody who writes about this particular topic agrees with that.
Which is cool -- it's not my field, so I don't really GAF. I'm mostly just remarking on how unusually difficult it was to drill down on this particular term. I'll avoid derailing the topic further than I already have.
From Wikipedia: The name "Multi-Level Intermediate Representation" reflects the system’s ability to model computations at various abstraction levels and progressively lower them toward machine code.
And yet you didn’t tell us what it stands for, just what it is. The person you’re responding to was specifically talking about finding out what it stands for
Based on the use of LLVM I guessed "Machine Learning Intermediate Representation"?
How close was I?
The ol’ TMA problem.
If only there was a chat-based app that you could ask questions to.