- Roadmap
-
Pomysły
+10
Odrzucone
Scripting Support
There is a request elsewhere to implement AddOn support in CN, enabling techy users to create their own CN extensions. I'd like to complement that idea and suggest to put emphasis on user-level scripting. Not only is programming in a scripting language much more suited for end-users (compared to programming in C++, the language I assume CN is implemented in). It is also much easier to implement, given the variety of scripting engines readily available for embedding in a host application.
All in all, compared to a full-blown, native plugin support, a scripting feature will provide more value to more users sooner.
Of course, at some later point, a plugin system can follow, perhaps to allow for things that people can't do on script level.
As a scripting language, I'd suggest Python, because of it's particularly clean syntax and excellent support for all major programming styles (procedural, functional, object-oriented). It will suit both novice users and experts equally well. Downside: The run-time system, while just one DLL, is quite huge in size.
If you go for smaller run-time memory fingerprints, you may consider Lua, but Lua has a bias towards procedural programming style which might not scale well for bigger and more advanced endeavors.
JavaScript seems as an interesting choice, too, because it's so wide-spread. But then again, like Lua, it does not scale well for bigger and more advanced endeavors.
All in all, compared to a full-blown, native plugin support, a scripting feature will provide more value to more users sooner.
Of course, at some later point, a plugin system can follow, perhaps to allow for things that people can't do on script level.
As a scripting language, I'd suggest Python, because of it's particularly clean syntax and excellent support for all major programming styles (procedural, functional, object-oriented). It will suit both novice users and experts equally well. Downside: The run-time system, while just one DLL, is quite huge in size.
If you go for smaller run-time memory fingerprints, you may consider Lua, but Lua has a bias towards procedural programming style which might not scale well for bigger and more advanced endeavors.
JavaScript seems as an interesting choice, too, because it's so wide-spread. But then again, like Lua, it does not scale well for bigger and more advanced endeavors.
Odpowiedź
0
Odpowiedź
Odrzucone
Christof Deininger 9 lat temu
Closed due to inability to collect 10 votes for more than 2 years.
Thanks for your suggestion! It is really something to consider. I think that Python would be an excellent choice indeed. But I'm afraid that scripting support will bloat the program size more than a plugin system would. And I really want to keep CN small to stay away from the Evernote niche.
Well, how about providing a scripting engine in the form of a plugin then? I know a number of cool applications that do just that.
About your argument that scripting would bloat the app size: That is not really true. A Lua or JavaScript engine is generally leaner than a descent plugin system is. (Just look at Eclipse' plugin system, which is a "descent" one. ;-))
And if you count the size of plugins compared to the size of scripts, the scripts win hands down. This is a factor to consider, too. With an add-on system, the goal is to keep the core lightweight, but that also means that a real user would ultimately have to install a number of add-ons as well in order to gather up his desired functionality. (Again, look at Eclipse, or WordPress, or any other add-on-enabled application. They practically can't exist without their add-ons.) If the add-ons were scripts, each add-on would be only a fraction of the size of a plugin. The total program size a user has installed would be much less.
There is another aspect: PR!
If there was a scripting system in place right now, without the need to run (and probably install before) a full blown compiler suite / development environment, I would have already implemented the scripts for my most wanted extra functionality. And if there was an "add-on market", where I could upload those scripts, I would have done that, too. And I'm not an exception there for sure.
Reduce the hurdle to creating add-ons, make it easy to share them, and your code base and thus your application's value, as well as the buzz around it will explode. If you did that with C++-based plugins, you'd limit the user base who can contribute and slow down the whole process by a factor of at least 10. (In fact, I'm afraid it'd be more than 10, as I suspect the number of C++ developers is dramatically declining world-wide.)
How fast do you want your application to spread?
About your argument that scripting would bloat the app size: That is not really true. A Lua or JavaScript engine is generally leaner than a descent plugin system is. (Just look at Eclipse' plugin system, which is a "descent" one. ;-))
And if you count the size of plugins compared to the size of scripts, the scripts win hands down. This is a factor to consider, too. With an add-on system, the goal is to keep the core lightweight, but that also means that a real user would ultimately have to install a number of add-ons as well in order to gather up his desired functionality. (Again, look at Eclipse, or WordPress, or any other add-on-enabled application. They practically can't exist without their add-ons.) If the add-ons were scripts, each add-on would be only a fraction of the size of a plugin. The total program size a user has installed would be much less.
There is another aspect: PR!
If there was a scripting system in place right now, without the need to run (and probably install before) a full blown compiler suite / development environment, I would have already implemented the scripts for my most wanted extra functionality. And if there was an "add-on market", where I could upload those scripts, I would have done that, too. And I'm not an exception there for sure.
Reduce the hurdle to creating add-ons, make it easy to share them, and your code base and thus your application's value, as well as the buzz around it will explode. If you did that with C++-based plugins, you'd limit the user base who can contribute and slow down the whole process by a factor of at least 10. (In fact, I'm afraid it'd be more than 10, as I suspect the number of C++ developers is dramatically declining world-wide.)
How fast do you want your application to spread?
Sorry for the delayed reply. I agree with your arguments and will seriously consider adding some form of scripting support in the future, most probably as a plugin. But the problem is that there are lots of other tasks ahead in the pipeline ;)
Of course, it is totally up to you. But if I were in your shoes, I'd make scripting support TOP PRIORITY. That way, new features would be implemented *for* you, instead of *by* you. Not least, it's a position that will likely decrease the size of your task pipleline as well. ;-)
Odpowiedź
Odrzucone
Closed due to inability to collect 10 votes for more than 2 years.
Customer support service by UserEcho
