Hello, On Mon, 14 Jul 2014 22:16:03 +0200 Jo-Philipp Wich <[email protected]> wrote:
> Hi. > > > Yes, I heard from other replies, that's good news, hope it will be > > ready for prime time soon. > > > > Still, it would be nice to have good unbloated language for rapid > > app development in constrained environments, like most routers on > > which OpenWRT runs. I made initial proof of concept web > > microframework for MicroPython > > (https://github.com/pfalcon/picoweb), and a trivial webapp can run > > within 64K heap. > > I welcome your effort but that project on github is just a glorified > echo server as it stands now. You can easily do that with Lua too. Sure, you can easily (or so) do it in any language ;-). > I'd be interested in the performance once you implemented a proper > template engine/parser, a proper gettext like translation system, > wrapper libraries for POSIX functions, bindings to libuci and ubus, > plugin mechanisms and all the other little bits that make up the > current LuCI release. > > Don't get me wrong, but years ago when LuCI was started it was also > lean, fast and tiny. I somehow doubt that a smaller python interpreter > is going to solve the inherent bloat issues. I understand this problem. Actually, part of my motivation for working on MicroPython is research interest in whether all roads lead to bloat or people just give up somewhere ;-). I understand that in the end it may end up the same bloat as many other projects. I understand another risk too - that trying to perfectalize each small bit of efficiency may lead to small overall progress and project grind to a halt. My personal quest for usable unbloated scripting language is governed by awareness of these risks, and trying to avoid them ;-). (To clarify, I'm not an author of MicroPython, just a regular contributor - and that's part of the plan btw, I know that I don't have resources to carry out such project on my own, so smartly don't do that). > > a) You either start using python libraries which aren't exactly tiny > by nature either and highly interdependant > > b) You start writing your own library ecosystem at which point you're > in the same obscureness niche as Lua Yeah, so again, smartly both approaches are followed. That's why I gave up Squirrel - it doesn't have decent standard library. That means that one have opportunity to design the most perfect standard library - but one yet needs to do that, and at the end, it will be just yet another obscurity. Python, on the other hand, has vast and well-known standard library, with pretty good interface. The implementation can be bloaty, yeah, but it can be optimized if/when somebody likes. > Also given the fact that Python 2.x vs. 3.x already fragmented the > python landscape I'm not sure if introducing yet another not fully > compatible spin of it is going to make anything better in the long > run. Unlike other small Python implementations, MicroPython doesn't have aim to be a subset, vice versa, it strives to be a complete Python3 implementation. It's just being the optimal implementation has even higher priority. So, it's currently implements subset of Python3, but if someone will need some missing feature up to coding it up, it will be gladly accepted (as long as its configurable, so people who don't need such feature, won't suffer its bloat). So, MicroPython is going to stay compatible with Python (well, Python is a mature language with number of implementations, MicroPython is just one of them, with its distinctive design goals and requirements). I don't want to have a long thread here discussing non-technical sides of MicroPython (that's surely an offtopic), just hope that answers above clarify that there's some paradigm behind the project. One thing is clear - if more people won't use it, and contribute to it, it won't make it. I hope that MicroPython may be of interest (at least in FYI sense) to OpenWRT users/developers, that's why I posted about it, and if someone will like it - the better ;-). > > ~ Jow > -- Best regards, Paul mailto:[email protected] _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
