On Mon, Jun 11, 2018 at 8:48 AM, vitalije <[email protected]> wrote:
> An ancient Greek philosopher Socrates said something like this: "Trying to > teach someone faster than he can learn is dangerous and unwise". To be a > good teacher one needs to be tremendously patient. > Patience is always a good idea ;-) > As a teacher I am very happy with the progress we made. About a year ago I > have studied Leo’s code base very thoroughly. I guess there are lots of > parts of Leo’s code that no one but Edward has seen or read. Theoretically > speaking Leo is open source project and everyone is allowed to look at the > code and read it. However, it rarely happens that someone takes the time to > read such a large code base. By doing this I have learned both about Leo’s > good parts and Leo’s weaknesses. About six or seven months ago I have tried > to share what I had learned about Leo’s weaknesses. I tried to teach Edward > to improve his coding style by avoiding some things that he usually does, > things that lead to unreadable and hard to maintain code. But he didn’t > accept any of my suggestions at first. > Since we are quoting the ancients, Aristotle said, "That which we learn we learn by doing". That's especially true for me. Pictures also help... > I decided to start a blog and for the first few posts I picked Leo import > code to write about. A year ago Edward has put lots of effort in improving > this part of code. He wrote about it in this forum; some great collapse of > complexity has happened,... But in my opinion code still could be much > simpler. > Yeah, code can always be improved. Simplicity is important, and so is code style. But design is much more important, and "vision" is most important of all. > When I picked the theme I didn’t know what will I find. What I did find > was that Leo’s importer for JavaScript was useless. It produced unusable > outline, taking way too much time and causing Leo to hang. However, Edward > didn’t accept new coding style at that time and even suggested that it is a > bad style. He has fixed JavaScript importer by avoiding section references. > That has solved the problem of Leo becoming unresponsive, but the shape of > the imported outline was still useless. No JavaScript programmer would want > to see his code displayed in such outline. However, Edward, declared that > importer is well designed and the result outline is as it should be – end > of story. This left me no option but to let it go and wait. After a while, > Edward himself, has opened an issue: we need a better importer for > JavaScript. When he tried himself to import JavaScript of leo-vue, he > realized himself that the present JavaScript importer was less than > satisfactory. Little bit later he started to adopt “lispy-style” himself. > He still feels a need to put a class somewhere even if it is not required, > but he has adopted a lot of the style that I was suggesting. > The new code base for importers is miles ahead of the old. But the javascript importer needs something besides better code. It needs real knowledge of javascript. I would be happy to have an improved javascript importer, even if it used none of the common importer code base. > Function that reads external files using so called fast-read algorithm has > been present in Leo since July 2017. I wrote both the read and write > function and had put them in leo-snippets repository. What I didn’t do at > that time was to test how long would it take to read all the external > files. I have made some comparisons on a single file and it was faster than > Leo’s original read code, but not so much faster. Perhaps the file I made > comparison on was not the best example. It turned out that the overall new > read algorithm is more than 27 times faster (*Edward has improved this even > more). However, it was not my initial goal. > I didn't know (or remember) any of this until last week. And until your email of yesterday, I didn't know that speed was not your initial/primary goal. > My goal was to make a new data model that would allow other parts of Leo > to be much simpler. But, I was so surprised by its speed that I couldn’t > resist the temptation to talk about it and somehow the discussion went in > the direction that I didn’t want it to go. It became discussion about speed > and profiling code and some shortcuts and not about the code structure. > Well, the speed is important, but I feel like all these talks about speed > caused main point to pass unnoticed. > Yesterday's email provided a picture that will stick, namely that Leo's DAG could be called a database without an index. > The one good thing, though, about Edward’s rushing into fast-read brunch > is that he himself realized that there are quite a few ancient options in > external file format that can and should be deprecated. If I made this > suggestion, I guess, Edward’s response would be that Leo must support all > those options indefinitely. But when he alone comes to this conclusion, > then it is a good idea. > Your *code* tipped the balance. My own code is impossible, now, for me to understand. In the process of modifying (editing) your code I saw what is essential. I also ran across comments saying the old file formats were *already *not being supported. > All in all, as a teacher I have tons of reasons to be very satisfied with > the progress we made. In time, Edward, will realize himself, other parts > that he still misses at the moment and then he will do almost exactly as I > wish him to do now. > As a student and project manager, I also am thrilled by our collaboration. > However, as a developer I am less happy. I feel like my code contribution > is not welcomed in this project. I am quite sure that it isn’t true, but > still I get this feeling. I tell to myself: Vitalije, if you wanted to have > some reward for your contributions then you shouldn’t contribute to the > open source project. If you wanted your name to be credited then you should > put the code into your own repository under your own license. > I think there is a simple procedural remedy for this dissatisfaction, namely doing your prototypes in git branches, or even in new leo repos. You can create a rep on this page <https://github.com/leo-editor>. I see there is a leo-model repo, but apparently I created it. It was created 11 days ago, but I had already forgotten all about it. > I really don’t care about credits, GitHub contribution counter and such. > But, OTOH, perhaps some other developers do care about these. Perhaps > someone’s career depends on GitHub contribution counter. Since March 2018, > when it was declared that only Edward should commit to the master brunch, > no contribution is counted for any other developer in leo-editor team. > This page <https://github.com/leo-editor/leo-editor/graphs/contributors> shows the commits from all contributors. You're on the list. In your case, though, your contributions go far beyond commits. > The prototype that I wrote, Edward has pushed to GitHub. Now, as far as > GitHub is concerned, the author of the prototype is 100% Edward. Again, I > really don’t mind it. I didn’t write it to earn some points or to impress > anybody. For me, it is perfectly OK for my contributions to remain counted > as Edward’s or someone’s else. But, it can be issue for people who actually > need to earn some points to advance in their career. For such people it > would be very unappealing to contribute to Leo. > I would be happy to delete the leo-model repo. It would be best if you created your own repo. If you want to get credit for your work, then you must publish it. > I can see that Edward is trying to attract and encourage more contributors > to Leo project. I believe he is doing a very good job in this area. He is > eager to accept every contribution but only to the some extent. If the > contribution is rather small it is going to be welcomed and accepted > without too much noise. However, I’ve got the impression that if the > contribution is above some limit, if it makes Leo much better in some area, > then it won’t be accepted as such. First, Edward must rewrite it from > scratch and only then he will accept it. > As project manager, I have to ensure that the new code is sound. I have enough experience with Terry's work that I am happy to trust what he has done. For grand changes, I first understand what the change is supposed to do. The "picture" of a db index is a start, but it's not nearly sufficient to allow me to evaluate the merits of a new data model. > Well, I still wouldn’t mind. I would be happy if he rewrite and use all of > the prototype I made. What bothers me is that if he can’t fully understand > some part of the contribution, he won’t ask for the explanation. Instead he > will usually put his boss hat on and then just declare that the > contribution is unacceptable and that the present code must remain as it is > – end of story. > I don’t think Edward is doing this on purpose. Most likely he is doing it > subconsciously. One way or the other, that is something that really bothers > me, and I believe it makes awful and non-inspiring atmosphere. I guess not > many developers would be ready to accept that kind of treatment. I am > writing all these with the hope that Edward will change this bad habits. I > am also writing this to set an example for other developers. If you ever > find yourself in this situation, be patient and keep contributing and > explaining your contribution. Eventually all your contributions will made > to the Leo’s core. > It's up to me, as the "boss" to preserve Leo's integrity. It's up to you, as a contributor, to convince me that a contribution is worthwhile. This means, at a minimum: a) I understand the general idea of the contribution and b) That I have a git branch to evaluate. At present, the new data model does neither. I am *not *rejecting the idea, but more work is needed. > It would be much nicer though if Edward were willing to accept all > contributions even when he can’t fully grasp them at once, or if at least > he were willing to ask for the explanation instead of just dismissing the > propositions he can’t understand at the moment. > I *will*, quite naturally, reject ideas that I don't understand. It's your job to convince me. Please do not take "I'm not convinced" as a rejection. It is not intended that way. It's supposed to be a request for clarification. > I really hope that I didn’t offend Edward (or anyone else) by writing > this. That certainly was not my intention. I just wish a better atmosphere > for all contributors. Many would agree that this forum has been a source of > inspiration for many people for a long time. Let it be even better for the > generations to come. > It's good that you expressed your frustrations. This letter will lead to better collaboration. *Summary* 1. If you want full credit for your work, do your work in a git repo or git branch. 2. The more important a proposed contribution, the more important it is for you to explain it and to provide a git branch that can be evaluated. 3. When I say "I don't understand", I am talking about my own understanding. Do *not* interpret those words as a judgement about the technical merits of a proposal. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
