GNOME.org
 

Re: [ANN] mc^2

Hello,

On Fri, 8 May 2015 12:38:32 +0200
Egmont Koblinger <egmont 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:pmiscml gmail com
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]