On Sun, 2013-08-11 at 21:53 +0200, Sascha Ittner wrote: > >>> Note that once conversion is done there remains no code in task which has > >>> to > >>> be > >>> C++, as Python bindings for all moving parts will be available. I would > >>> have > >>> no > >>> parting pains with the task code, and if somebody would want to redo this > >>> in > >>> Python, it is time to start thinking to bring the - sorry, pathethic - > >>> implementation of the task state machine into a comprehensible and > >>> adaptable > >>> form, for instance by using the fysom.py state machine framework. > >> > >> I agree that a clean redesign of that part would be a big progress as I > >> experienced the pain caused by the attempt to understand the code. But I'm > >> not > >> sure if Python is adequate for such a integral component (I'm thinking > >> about > >> the > >> usage on resource limited systems). Why not try a clean implementation in > >> C? > >> > >> Sascha > > > >the current bloat is caused by a ton of repetitive low level operations, poor > >functional abstractions, tons of globals with no acessor methods (EMC_STAT > >being the mother of all globals) and a gazillion of ad-hack patches here and > >there; the insanity of operating the interpreter as a subroutine and trying > >to > >guess what it might need, instead of making it a process or thread and have > >it > >tell what it needs; and choosing a method to implement a humungous state > >machine which literally guarantees illegibility > > > >those are the reasons why very few people around here touch task, and if so, > >with a 10ft pole > > 100% ACK > > >so the issue on the table is a structural redesign, and for the first time we > >have the option not to use C++, which definitely is a deterrent in this > >community; just have a look how happily UI's are build these days with Python > >by non-gurus, there is just no way this would happen with C++ which is why > >Python would be my preference > > I think the main problem is not dedicated to the language but to a clean > design > before implementing something. But I agree that C++ requires a lot of > discipline > and experience to implement a good design in a proper way. An other option > might > be plain C with good coding rules. GTK is a good example that you can do a > "object orientated approch" even in C. On the other hand I have seen code > written in Python that lacks any prettiness. What might help are coding rules > together with a kind of review process. Tools like GitHub are excellent > candidates for such a review process. Relevant code fragmentes can be > discussed > until they are accepted. > > >the actual functionality of that clunker is moderate, and so are the > >performance requirements, so there's just no reason I could see to retain the > >C++ deterrent. > > That's right. It's not a high performance application. But I think latency > could > be a point if the controller core runs on a small embedded system and the gui > is > attached via network. But currently it's just a gut feeling without any hard > facts. > > >the one who tackles the task gets to choose the language, so here comes your > >chance > > I already thought about this option :-) > > Sascha
Have you EVER heard a programmer complaining about the code being too fast. ;-) D > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
