Hello, On Fri, 8 May 2015 12:38:32 +0200 Egmont Koblinger <egm...@gmail.com> wrote:
[] > I was obviously exaggerating when I said Mooffie rewrote "half" of > mc's code. I haven't look at the changes to the C code yet, but as > some comments on the homepage suggest, it's probably only a very > small fraction of the C code he touched and mostly pretty lightweight > changes. > > Have you ever seen a complete rewrite of a project (that's bigger > than a few weeks of hacking) succeed? I have not. Trivia quiz or what? Ok, unix rewrote multics bloat, lives so far, multics dead for big decades. gcc "rewrote" a lot of older vendor compiler crap. llvm/clang "rewrote" gcc to let vendors do more compiler crap. Etc, etc. > This would > require at least 100x (but rather 1000x) the work Mooffie has > probably already spent. There are no engineering resources for > that. Recently I've spent about a week rewriting the viewer, > probably noone else would've done it if I hadn't. Does that mean that you've got commit access? > There's a ticket to > rewrite the vfs component, noone's working on that. Regex handling > should be carefully cleaned up, noone's working on that. Tty handling > is overly complicated, nobody's working on it. But you'd rewrite the > whole project from scratch!? Yup, it's so complicated because it's written in C. People write in C when target microcontrollers with 16K code size and 0.5K RAM size. It's hilarious to write application-level software in C. > And then the rewrite would be missing > tons of features because you were lazy to port them, would contain Less features is good. I consider mc a unix tool, it's not replacement for command line (or overbloated vendor IDEs), it should do not too many things, but do it right. > tons of brand new bugs or bugs that had been fixed long ago. It's > pretty much guaranteed to be a big failure -- and easily not just a > failure of the rewrite but also cause a(n even bigger) decline of the > main project, as many times you recah a point where the old project > is already considered obsolete and is unmaintained, in favor of the > new one which stands on better technical grounds, yet is totally > incomplete and lacks tons of things from the old one. > > Successful redesigns almost always happen in small steps, maintaining > the usability and quality of the project throughout the steps. You > might eventually replace nearly every component, and the road might > eventually become longer than if you had rewrote from scratch, but > it's viable because you get satisfied users and passionate developers > all the way through, Or frustrated users and quitting developers if development model's not right, as we discussed here (from your premise) end of last year. > rather than just hacking on something that's not > used by anyone; That wouldn't be so terrible if you yourself use it. > and it's viable because it's not risky: you can stop > working on it anytime and leave positive benefits behind rather just > having wasted tons of time. > > As for whether mc's core should be written in C or lua or whatever... > compiled or interpreted, strict or loose types, whatever... My > personal preference probably doesn't matter too much, yet I'd like to > quietly mention that my last python project (port someone else's app > against a new API) got stalled in a "mostly working" state where the > parts I've tested work, yet the parts I haven't (because I don't know > how to reach that code) probably still call the API using its old > method names, wrong order of parameters, and nobody tells me this. They either will eventually, or nobody cares. That's how open-source software works. And that's mirror of development process you described - people don't use all stuff at once, and don't hit all issues at once, so they can be handled gradually. > Had it been written in a compiled language, the compiler probably > would have helped me do a complete port in the same amount of time. But it was smartly not written in a "compiled" language (but which you certainly mean something low-level, right?). And here discussion would be more about well-written vs bad-written software, not compiled/interpreted or low/high. It's just high-level languages allow to achieve better result faster (oftentimes, achieve a result at all). And choice of particular language affects a result (the causation is opposite, like if you no longer have to write messy code, you no longer need to use e.g. Perl). > As for the plugin API: If you write the core of mc in whichever > scripting language and allow a plugin to hook up against _any_ of its > methods/variables then you discard the very basic principle that > caused all programming language to move at least slightly towards > object-oriented approach. If you allow a plugin to do anything, it > becomes a nightmare where you can no longer perform internal > refactorings because you don't know how many 3rd party plugins you'd > break, or by seeing breakages 3rd party plugin authors would back off > from the project. > > On the other hand, if you define a clear API that plugins code > against, then it's not really relevant anymore whether the core and > the plugins are written in the same programming language or not. Indeed, all this plugin stuff is obvious, old, and boring. FAR offered ability to write plugins in any scripting language supported by a particular Windoze technology for years. And for mc, I'm sure it's not the first patch to integrate some scripting. I myself more concerned about having a good usable core without obvious gaps and misfeatures, plugins are obvious after that. > Now, I don't know anything about lua, but allegedly it's really good > for this kind of plugin stuff, writing hooks to a C code. Lua is not "really good". It's pretty mediocre thing. But it's indeed was designed to be embeddable language and has history of such usage (in my list, a lot of people use Lua because of lack of better alternative, that's why I contribute to MicroPython project). > But let's put all this question aside. We might be arguing for years > what would be the best language for mc core and what would be the > best language for the plugins, and it'd take us nowhere. The most > important factor in the decision should be what we already have. We > can't reimplement 20 years of work in mc core. We might reimplement > Mooffie's lua code in python/ruby/whatever but apart from spending > weeks on it, would it make it any better? > > The biggest value is that we already do have a decent mc written in > C, and we do already have a nice initial plugin framework in lua. > Rather than going into hypothetical discussions about how to change > the world, Mooffie went ahead and wrote code that actually works. > It's definitely not be the best of all the hypothetical mc's it could > have developed to during 20 years, but it's what we do already have > and that's what matters. That's why I'm voting for continuing this > approach, rather than making giant steps backwards and choosing an > alternate route. Nice speech, but can we please have simpler issues which waited in queue for years be tackled first? My list of *lacking* (not nice to have, like plugins in scripting language) is simple and short: 1. Ability to work with real-world text files without fighting and swearing that real world. I did submit a dozen of tickets to various projects along the lines of "You have a file with broken line-endings in your codebase!", but the real problem is with mcedit, and the patch exists http://www.midnight-commander.org/ticket/1652 , and only held by exactly perfectionist attitudes and lack of more general response. 2. I miss indent/dedent in mcedit. I would go to implement it myself, but so far I contributed to the implementation of previous feature, and it 2+ years waiting for progress, which doesn't encourage any further work on mc. > > > cheers, > egmont -- Best regards, Paul mailto:pmis...@gmail.com _______________________________________________ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
