IMO the biggest problem is that it takes too much time to learn Leo. When I say Learn Leo, I don't mean Learn or understand the code, I mean learn what you can do with it. My true feeling is that Leo is like an infinite ground, where amazing things can be built. Some of Leo users are already doing incredible things with it. But when you are new to Leo, you first have to learn the physics of this new world (Leo Code), and then develop your own engineering (Useful outlines structures) for building your "information cities".
I consider myself being in the "develop engineering" phase, and I have been leaving bread crumbs all the way. I plan to do great things with those bread crumbs, and Im close to release that (around one month hopefully!) but thats another topic. Possibly, experienced leo users dont share this view since they learned Leo physics and engineering long time ago, but those look like a big wall when starting with Leo. So Leo files with samples would be like delivering this infinite ground with some pre-built "information cities" so people can begin using them right away. Ideally, those leo files should guide the user on how to build new structures, and in the end, be able to lead him to generate new structures. My (again, personal) feeling is that the current policy right now is: Let him read the code to understand how it works. So only the users willing to go through the (1) Learn the physics then (2) develop your own way to develop "information cities" can actually use leo and use its potential. Since most of the internet users are the ones who need the cities already built for them to use software, thats the chunk we are loosing. On the other hand, coming to why programmers (who have the skills to go through Leo learning process) dont come and use it, its the same story: Before coming into Leo, what I was doing was actually search for an IDE that I liked. I went through several, and in the ones I "liked" the most, it would take you around two hours learning for having a folder with your scripts and being able to edit them. With Leo, you first have to study and understand what are directives, how do they work, how everything interacts in the tree, etc. It takes more than two hours. I would say that it can be measured in weeks or months until you really know what you are doing. And here is where the "information cities" come again. If Leo were provided with an interactive Leo file, which would guide you into: - Importing your scripts to Leo - Clearly create folders and move/manage your files there - Suggest directives for those files. - Etc. That Leo file would save the new user many many hours and he would instantly start using leo, so we would help him skip the first wall and begin to get interested. So then again, this is why I still see that Leo default workbook should be dispatched with a Leo cheatsheet<https://docs.google.com/spreadsheet/ccc?key=0AuJMXJ1q6FRUdEdtVDVVRnZMYnBacGlZNmt5SkhETGc#gid=0>open by default, so new users begin to play with it as soon as they open Leo. On Tuesday, September 24, 2013 11:08:08 AM UTC+2, Edward K. Ream wrote: > > Imo, the answer is simple: resistance to change. Programmers have a lot > invested in their tools. To be worth serious consideration, Leo must offer > something much better. Furthermore, most programmers likely see moving to > Leo as risky. Using Emacs or vim will seem like a much safer choice. > > That's why @shadow, @auto and (eventually) compatibility mode are so > important. They offer ways for programmers to migrate to Leo gradually, > without affecting their programming team. > > 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 http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
