[ANN] mc^2

Egmont Koblinger egmont at gmail.com
Fri May 8 10:38:32 UTC 2015


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

> Hello,
>
> On Thu, 7 May 2015 23:27:23 +0200
> Egmont Koblinger <egmont at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.midnight-commander.org/pipermail/mc-devel/attachments/20150508/9ada8f25/attachment.html>


More information about the mc-devel mailing list