Re: [ANN] mc^2
On Thu, May 7, 2015 at 11:53 PM, Paul Sokolovsky pmis...@gmail.com wrote: Hello, On Thu, 7 May 2015 23:27:23 +0200 Egmont Koblinger egm...@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
Re: [ANN] mc^2
Hi, How much work would it be to port your branch to 4.8.14 or git head (they're pretty much the same now)? I'd really like to use your version for daily work (and maybe even start writing plugins) to gather feedback. On the other hand, mc-4.8.14 contains some of my work that I really wouldn't want to live without. And of course I wouldn't want to switch back-n-forth between two versions either. Thanks a lot, egmont On Thu, May 7, 2015 at 10:23 PM, Mooffie moof...@gmail.com wrote: Hi guys! I've just published a branch of MC with Lua support: http://www.typo.co.il/~mooffie/mc-lua/docs/html/ See the screenshots link. Also see the other documents link for background (especially HISTORY). Many, many tickets can be solved with mc^2, but I don't want to spam the ticket queue with my posts, so I've prepared a list of some such tickets (see other documents - TICKETS). (But in a few tickets I *will* comment: in tickets I believe a constructive discussion could ensue, or where I feel people are truly in need of a solution.) == Now, I guess I'll be attacked for one reason or another. Let me save your time by attacking myself for you: == Q: Is this a 'fork' of MC? Are you trying to split the community? A: No, this is not a fork (as per Wikipedia's definition). It's intended to be food for thought for the MC community. My hope is that eventually the principle behind mc^2 will be adopted by MC. == Q: Is seems that you've invested a lot of time in this. Gosh, why waste human resources?! Especially on something that nobody's going to use? A: The time I waste here is negligible in comparison to the time and efforts wasted by tens of people who have tried to contribute code to MC over the years. The principle behind mc^2, if adopted by MC, is going to put an end to this waste of human resources. == Q: But why use Lua?!?! Why not pick the language that starts with 'P'?! Why not make it work with any language?!??! A: Let's not talk about languages/VMs *right now*. Please, as much as it's tempting. Right now, the language is not the issue. The issue is the principle, of having some extension language. The language/VM is obviously something everybody will have something to say about. You will. But not now. If every passerby here will now emit his 2 cents opinion/rant, it will kill the vision/project. It will start a Holy War. It will derail the discussion from the mainroad to the gutters. It's the least constructive thing that could happen. It means death. In the future, when we know the principle will be regarded favorably by MC's maintainers, we could open this issue and discuss things. One thing's for sure: You can't give an opinion about the subject without considering it for at least a week (or a month, I'd say). There are various facets to consider. There are threads of thoughts to be picked and discarded. There are insights to be acquired. You can't just barge in with use Python!!, use Parrot!, use GObject!. As the Chinese saying goes, Opinions are like belly buttons: everybody has one. It should take more, much more, than an opinion to affect the discussion. So, again: let's not talk about languages now. (For the record: I recorded my reasons for choosing Lua in other documents - HISTORY.) ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
On Fri, 8 May 2015 15:05:33 +0300 Mooffie wrote: On 5/8/15, Egmont Koblinger wrote: How much work would it be to port your branch to 4.8.14 or git head (they're pretty much the same now)? Probably very little work. I'll do that sometime soon, I hope. It would be great if you split first huge commit of branch in several small commits. It will make the review easier. Thanks! -- A. ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
On 5/8/15, Egmont Koblinger egm...@gmail.com wrote: [...] a complete rewrite [...] would require at least 100x (but rather 1000x) the work Mooffie has probably already spent. There are no engineering resources for that. [...] Successful redesigns almost always happen in small steps, maintaining the usability and quality of the project throughout the steps. [...] Egmont, Thanks for composing this excellent reply. I actually composed one myself (a much, much shorter one) before going on-line. I combed it to see what I could salvage out of it but I see that you've got all the main points. Now, mc^2 isn't perfect. API in a scripting language poses many challenges (which you mentioned, and Szabó Gergely too). These are certainly issues we'll have to think about. It's certainly possible that people will conclude that mc^2 in its present form is garbage, but at least it provides us with a path we can work on. did you just rewrite half of mc No, it's not a rewrite. (That's the short answer. The sources (under the 'src/lua' tree) seem big at first glance, but that's mainly because they have documentation embedded in them. There are files with just 10% of actual code.) ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
On 5/8/15, Egmont Koblinger wrote: How much work would it be to port your branch to 4.8.14 or git head (they're pretty much the same now)? Probably very little work. I'll do that sometime soon, I hope. ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
