Re: [ANN] mc^2

[Egmont Koblinger <egmont gmail com>]

On Sun, May 10, 2015 at 1:25 PM, Paul Sokolovsky <pmiscml 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