On Sun, May 10, 2015 at 1:25 PM, Paul Sokolovsky <pmis...@gmail.com> wrote:

Brief response, and we've heard each other's opinion, and I'm not trying to
convince anyone or go into endless debates/flames.

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

And compare the engineer staffing of these projects to mc's.  Okay, I
should rephrase my question: in a project that hardly has resources to fix
even the most critical bugs (e.g. currently there's a segfault in 4.8.14
and no solution yet), what are the changes of successfully reimplementing
20 years of work from scratch?  I believe it's 0.  Not
zero-point-lots-of-zeros-one, but zero.


> Does that mean that you've got commit access?
>

No, I don't have. (Why is it relevant?)


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

IMHO not any more hilarious as writing application-level software in a
script language.  Anyway, once can e.g. do a C -> C++ transition in small
incremental steps, without starting over from scratch.  You can't do a C ->
python transition this way.


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

mc already does lots of things.  Some are important to you while others
never use them.  Some are intensively being used by others, yet you
wouldn't care about those.  If you reimplement "not too many things", for
most users it'll be a failure that lacks important features, and will stick
to the old version.


> Or frustrated users and quitting developers if development model's not
> right, as we discussed here (from your premise) end of last year.
>

Exactly.  I believe Mooffie's approach is a much nicer step in solving this
problem than a complete rewrite would be.


Nice speech, but can we please have simpler issues which waited in
> queue for years be tackled first?


Not sure what you mean by this.  I know that many bugs weren't addressed,
but in the mean time many others were.  Mooffie's work provides a better
ground for quicker development in the future.  He's not solving issues one
by one, but helps solving any subsequent ones more effectively.  Yet you
argue that instead we should focus on continuing fixing bugs one by one...


Anyway, Mooffie has shown us some code.  You don't quite like it, you'd
take a totally different approach.  Okay, your turn, convince us, show us
the code please ;)


cheers,
egmont
_______________________________________________
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Reply via email to