Hi! On Sat, Mar 16, 2024 at 11:41 AM Elliott Mitchell <ehem+open...@m5p.com> wrote: > > > The biggest difference between the two isn't the language choice, but > > > the overall designs. Your shell script is essentially replicating the > > > actions a human at a shell might take to perform the task (more or less > > > precisely the actions suggested by the original source). As such you > > > likely recognize all the commands used in the script. > > > > And that is exactly the point. Human's have to read the script, humans > > have to understand the script. Readability (in this case, more on this > > later) is the biggest and most crucial part, as readability (by humans) > > goes nearly hand-in-hand with maintainability. > > Whereas due to better design, mine will likely last rather longer before > needing maintenance. > > > > The real reason everyone was having a hard time understanding my script > > > was not that it was written in Perl. > > > Yes it was :p perl syntax is godawful :) and adds a layer of complexity > > around, what in the end are, shell commands. And that's the partial also > > a problem in my opinion. Many people do not know perl, readability > > becomes an issue, and thus also maintainability. Yes, someone can argue > > the same for shell scripts and its tricky syntax hacks. Though I pride > > myself (and thank shellcheck a lot) for attempting to write as readabile > > scripts as possible. > > Perl heavily copies features and capabilities from shell scripting, but > Perl itself is not a shell-scripting language. If you're thinking of it > as shell-scripting then, yes it will be confusing. Further it really > does have some major quirks. At least it didn't fundamentally change > the language and library between v2 and v3... > > > > Since `git fast-import` is a direct interface to Git's back-end, the > > > working tree doesn't need to be modified to operate. This also means > > > mine is *much* faster and can create precisely tailored commits. > > > Ah, but! ... here I go drudging about maintainabiility again. Others in > > the future will also look at it and go like 'hmm, what is this for, and > > why the complexity' ... > > Anyone needing to figure out how the scripts work will need a fair bit > of familiarity with Git. Being able to get good results really does need > some deep familiarity with Git's structures, at which point > `git fast-import` isn't a big step further.
And more comments on the perl thing: A maintainer needs to be familiar with perl to review or take your patches. I could probably vaguely understand what a perl script is doing by quickly learning the syntax, but I can't decide whether the script is good or not. Nobody is explicitly NACKing your patch or saying it's worse than the bash version just because it's written in perl. Maintainers who don't understand perl simply don't have the knowledge to judge the script, so the patch is left for others. If such a maintainer doesn't show up, your patch won't be taken. It doesn't matter if your script is superior or not. -- Regards, Chuanhong Guo _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
