Re: [ANN] mc^2

[Egmont Koblinger <egmont gmail com>]

On Thu, May 7, 2015 at 11:53 PM, Paul Sokolovsky <pmiscml gmail com> wrote:

Hello,

On Thu, 7 May 2015 23:27:23 +0200
Egmont Koblinger <egmont gmail com> wrote:

> Hi,
>
> Did you... er... did you just rewrite half of mc... adding plugins and
> stuff...??

It would be indeed cool to remove all that gnome-ish bloat accumulated
by decades, but - what a disappointment - home page says "that to
accomplish such feat there is no need to modify MC’s main code.".

Generally one good approach to deal with the situation would be to
rewrite mc completely in a scripting language. Extra points for using
language in which array indexing starts with e or pi, or going straight
to Brainfuck. No, I'm ironic with the last sentence on Lua choice, but I
really think the way out of the maze is rewriting mc from scratch, and
then surely in a decent scripting language.

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.  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.  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!?  And then the rewrite would be missing tons of features because you were lazy to port them, would contain 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, rather than just hacking on something that's not used by anyone; 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.  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.

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.  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.

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.

cheers,

egmont