On Thu, 19 Jun 2025 at 19:33, Mark Filipak <markfilipak.imdb-at-gmail....@ffmpeg.org> wrote: > > On 19/06/2025 13.42, Rob Hallam wrote: > > On Thu, 19 Jun 2025 at 17:04, Mark Filipak > > <markfilipak.imdb-at-gmail....@ffmpeg.org> wrote: > >> I apologize, Rob. I was going by the bodies, not the headers. The > >> intervening time was actually a > >> little less than 2 hours. I apologize for the error. > > > > I appreciate you taking the time to correct the mistake, thanks. > > You're very welcome. > > >> 2 hours... Hmmm... Your comment is still shameful. > > > > Yeah nah. We all had time to gab about how FOSS and proprietary > > software sucks over the course of six replies before someone said > > 'nice one' ? Pretty poor showing from the ML. > > Well, Rob, I can't read 'C' code, so I'm unqualified to know whether Paul's > patch is any good. We > will all see that when it's published and compiled and linked and > distributed, eh?
It is published. You can compile and distribute it to your heart's content- that's one of the great things about Free software. The work asked for has been acknowledged now though at least. > I have a story. I'm corresponding with a fellow who wrote a popular > subtitling program. He wrote it > in 2000, rewrote it in 2013, and is currently rewriting it, again. He seems > to have little idea > regarding what what makes a good user interface, good. He doesn't think > user-interface thoughts. He > thinks coding thoughts. To me, user interface is design, not coding. Like all > good design, good UI > design takes experience and lots of time and lots of thinking (and > compassion). Hard agree. > Do you write code, Rob? I've written a lot of code in my time, but always as > part of my hardware > projects -- of my 29 projects, I think maybe 2 or 3 included microprocessors > and assembly. The rest > had zero code, though I did have to write drivers and tests. > (part snipped that I will return to) > When I design hardware, I spend 75% to 80% of my time planning. > During my planning, I document every decision I make: why did I do 'this' and > why didn't 'that' > work. When the project is done, I have complete (or nearly complete) > documentation already done. I > think that works better than putting off documentation to the end. I know > that, for me, I don't have > the patience to write documentation at the end of a project, and I forget > what I wanted to document > if I leave it to be done at the end. Agreed on just about everything here. > I know that, when the code is done and I'm looking at it, it's too easy to > say, "Well, 'this' and > 'that' are obvious, so I don't need to mention 'this' and 'that'." Yup. I'd go a step further and say that once you're done writing something you can end up *too* familiar with parts of it and not even consciously think "I don't need to mention this"- eyes skip over it. > All my friends were codesmiths, usually 'C' codesmiths. They would spend > maybe 5% or 10% of their > time planning and the rest coding. There's a huge number of people writing code. Millions. They're a spectrum from meticulous planners with assiduous attention to documentation to 'vibe coders' who let ChatGPT generate code and go "hmm, looks about right". It sounds like you had experience with people who were "code first, think later"; I'd like to think most prefer the reverse, I know I do. Cheers, Rob _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
