3 ms·

I disagree. A link to documentation is at the start of the page. That's where I expect to see code samples and output which is all there

mdip 7y ago
Which covers, reasonably, people who have an idea of what the product is and enough motivation (i.e. working in the space, or a serious hobbyist) to click in more deeply. Myself -- little more than an enthusiast -- clicked the homepage link, the documentation link, the blog and ended up landing at the point where the line on my "interest in the product" part of the graph met my "time I'm willing to spend figuring out if I'm going to be more interested" before I ever got the answer to "would I want to use this?" That's fine -- the author is within his rights to target what s/he wants. Perhaps it's so Alpha that the author doesn't desire people other than "serious hobbyists" to dig in deeper (there's valid reasons to do this). But if the goal was to get larger traction (as posting to HN is likely to cause), that didn't happen, for me.
- brudgers 7y ago
  I posted it to HN. It's not my project. I found it interesting because I have some level of current interest in ffmpeg. I googled "ffmpeg racket" probably because I saw this or (something like it) at some point in the past several years. I went about as deep into the project as you did and concluded "it's not for me" too. It was still intellectually interesting, hence the submission. The reason I concluded "it's not for me" is I've realized that trying to avoid learning big heaps of pain like ffmpeg takes more energy than just climbing the steep learning curve of the original tool...and in theory writing my own abstractions over it. To put it another way, I can probably automate ffmpeg using Babel in emacs org-mode and get tooling that hews closely to what I am trying to do. FWIW I also posted a link to a Python repository wrapping ffmpeg. Similar reasons. Similar conclusion. But the Python tool is much more mature and would probably be a better engineering choice than an org-mode document in a team environment with a normal distribution of tool preferences among its members.
  - javajosh 7y ago
    >The reason I concluded "it's not for me" is I've realized that trying to avoid learning big heaps of pain like ffmpeg takes more energy than just climbing the steep learning curve of the original tool Well, then, a valuable lesson. I would suggest that writing a blog post about that experience and posting to HN about that would actually have been more interesting, for me.
    - brudgers 7y ago
      Even though I know that its better for me to just learn the base technology doesn't mean I don't try to avoid reading the manual. Knowing there are no silver bullets doesn't mean I don't want one. It's just that this time it only took me a few hours and a night's sleep to stop looking. Unfortunately, by that time, both articles were on the front page. Or fortunately to the degree my self worth is tied to my HN karma.
  - mdip 7y ago
    Ah, another person experiencing `ffmpeg fatigue`. Holy cow is that a language-in-a-command-line. I ended up using 11/17 graph paper to write out a mess of notes trying to understand how everything is put together. There are some solid wrappers, now, but in the past most of the libraries I've run into (at least on the C# side) exposed a limited feature set as a way of reducing the complexity. The features omitted, of course, were ones I needed. So I always ended up back using a ba/zsh script and the command-line. Based on my notes, I've always felt that it wouldn't take much to represent the command-line options in a more elegant way using a YAML definition (with more descriptive property names than the CLI options use). Inputs, Outputs, Filters and their Relationships between each. Seems like it'd be easy to validate outside of ffmpeg... I went down the path, briefly, but got side-tracked.
- derision 7y ago
  Language is in the title. If your course of evaluating a language does not include at least taking a glance at the documentation then you really aren't evaluating anything. I could put a pretty little demonstration on my homepage and you'd think it's all great and meanwhile have no documentation at all.
bscphil 7y ago
This link is hidden under a hamburger menu on Firefox for Android, and it's not even visible on the screen unless you scroll to the right. I didn't even realize it existed until you mentioned it because the page seems to be formatted deliberately to keep you from knowing it's there on mobile devices.

mdip 7y ago

Which covers, reasonably, people who have an idea of what the product is and enough motivation (i.e. working in the space, or a serious hobbyist) to click in more deeply. Myself -- little more than an enthusiast -- clicked the homepage link, the documentation link, the blog and ended up landing at the point where the line on my "interest in the product" part of the graph met my "time I'm willing to spend figuring out if I'm going to be more interested" before I ever got the answer to "would I want to use this?" That's fine -- the author is within his rights to target what s/he wants. Perhaps it's so Alpha that the author doesn't desire people other than "serious hobbyists" to dig in deeper (there's valid reasons to do this). But if the goal was to get larger traction (as posting to HN is likely to cause), that didn't happen, for me.

brudgers 7y ago
I posted it to HN. It's not my project. I found it interesting because I have some level of current interest in ffmpeg. I googled "ffmpeg racket" probably because I saw this or (something like it) at some point in the past several years. I went about as deep into the project as you did and concluded "it's not for me" too. It was still intellectually interesting, hence the submission. The reason I concluded "it's not for me" is I've realized that trying to avoid learning big heaps of pain like ffmpeg takes more energy than just climbing the steep learning curve of the original tool...and in theory writing my own abstractions over it. To put it another way, I can probably automate ffmpeg using Babel in emacs org-mode and get tooling that hews closely to what I am trying to do. FWIW I also posted a link to a Python repository wrapping ffmpeg. Similar reasons. Similar conclusion. But the Python tool is much more mature and would probably be a better engineering choice than an org-mode document in a team environment with a normal distribution of tool preferences among its members.
- javajosh 7y ago
  >The reason I concluded "it's not for me" is I've realized that trying to avoid learning big heaps of pain like ffmpeg takes more energy than just climbing the steep learning curve of the original tool Well, then, a valuable lesson. I would suggest that writing a blog post about that experience and posting to HN about that would actually have been more interesting, for me.
  - brudgers 7y ago
    Even though I know that its better for me to just learn the base technology doesn't mean I don't try to avoid reading the manual. Knowing there are no silver bullets doesn't mean I don't want one. It's just that this time it only took me a few hours and a night's sleep to stop looking. Unfortunately, by that time, both articles were on the front page. Or fortunately to the degree my self worth is tied to my HN karma.
- mdip 7y ago
  Ah, another person experiencing `ffmpeg fatigue`. Holy cow is that a language-in-a-command-line. I ended up using 11/17 graph paper to write out a mess of notes trying to understand how everything is put together. There are some solid wrappers, now, but in the past most of the libraries I've run into (at least on the C# side) exposed a limited feature set as a way of reducing the complexity. The features omitted, of course, were ones I needed. So I always ended up back using a ba/zsh script and the command-line. Based on my notes, I've always felt that it wouldn't take much to represent the command-line options in a more elegant way using a YAML definition (with more descriptive property names than the CLI options use). Inputs, Outputs, Filters and their Relationships between each. Seems like it'd be easy to validate outside of ffmpeg... I went down the path, briefly, but got side-tracked.
derision 7y ago
Language is in the title. If your course of evaluating a language does not include at least taking a glance at the documentation then you really aren't evaluating anything. I could put a pretty little demonstration on my homepage and you'd think it's all great and meanwhile have no documentation at all.

bscphil 7y ago

This link is hidden under a hamburger menu on Firefox for Android, and it's not even visible on the screen unless you scroll to the right. I didn't even realize it existed until you mentioned it because the page seems to be formatted deliberately to keep you from knowing it's there on mobile devices.