I also agree about Leo making me a more "sloppy" coder. I rely heavily on Leo to implement structure where a specific language simply isn't capable of what Leo can do. In fact Leo can turn pretty much any language into a highly structured language with arbitrary levels of organization, down to a single line of code.
What I've found most interesting is my ability to take somebody else's project and import it into Leo and I'm amazed that even in this case Leo creates amazing structure and then I can further refine the organization. In these cases I find that I'm able to more easily mimic the coding style of the original author and I don't have the "sloppy" coding problem. You're also right that convincing others to drop their tools is an uphill battle with very little chance of success. The only way somebody is going to switch is if they're looking over your shoulder while you do something and they're just like, "woah" at something you did. Your observations are probably similar to how a lot of long time Leo users operate on a day-to-day. On Friday, August 7, 2015 at 9:19:25 AM UTC-4, Phil wrote: > > I have been using Leo for many years now, and I love it. I use it for a > couple primary purposes. First, I use it as a PIM, both for > "administrative" information, as well as for "archival" information where I > keep virtually all the code I've ever written in the event I should need > something later (which happens surprisingly often). Second, I use it as a > code development tool. > > For both uses, I have been mostly a solo user, i.e., I have had very > little need to collaborate with others, and therefore no need to coordinate > my "Leo-nized" workflow with the non-Leo workflow of others. Until now, > that is. I am currently working in a team to develop code, where I use Leo, > and my team members do not. It's working pretty well, but it has led to > some realizations about how Leo has affected the way I like to work, and > how that subsequently affects my team's work. > > In short, Leo allows me to be a sloppy coder! Let me explain. > > 1) Leo greatly simplifies "trial and error" coding. I can implement > experimental code blocks and routines, try them, and if they don't work the > way I want or there's something I want to defer further work on until > later, Leo allows me to quickly and easily "park" the code by making a note > in the headline, commenting out the block with @ and @c, or moving the > offending code node somewhere else. That means that my team members can > sometimes find spurious code blocks with no obvious relationship to the > rest of the code. I see why it is the way it is, because I see the > structure, but they can't see that. > > 2) I tend to use fewer comments. This is because the outline structure of > my code contributes so significantly to my understanding of the code that I > don't need copious comments. And I like this, because, even though I know > better, I have difficulty keeping comments and code in sync. But my team > members don't see the structure, so it is not always obvious to them how > things are related or what they are intended to do. > > 3) I tend to use fewer helper functions, and use nodes instead. This is > great for me, because it provides better documentation, but for the poor > coder who is looking at the text, my code can sometimes look like long > run-on functions. > > 4) I use clones freely, including between files. This can conflict with > non-Leo coders, who don't realize that a piece of code is common between > several locations. If they make a change in a cloned section of a file, it > won't propagate to the other files. If I make the same change in a cloned > node, it affects all code using the clone. Maybe the common code should be > broken out into a separate file or library, but that's not always practical. > > > > I use Leo because it fits my thinking style. I would say it has even > helped me to be a more creative and innovative developer, because the > ability to capture structure allows me to envision the code in a larger > scope, and see relationships that I might otherwise miss. > > I am also convinced that my team members would find using Leo to be very > productive. But I am not in a position to force others to use it. And every > developer has his or her own favorite tools, so convincing them to adopt > Leo would be difficult if not impossible. > > So, I would be interested to hear the experiences of others who are in > similar environments. What workflow practices work best? What doesn't work? > How do you resolve workflow conflicts? > > Thanks, > Phil > -- 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 http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
