On Mon, Apr 10, 2017 at 1:51 AM, Simon Lees <[email protected]> wrote: > > > On 04/10/2017 12:21 PM, Gustavo Sverzut Barbieri wrote: >> On Sun, Apr 9, 2017 at 9:38 PM, Simon Lees <[email protected]> wrote: >>> On 04/10/2017 12:39 AM, Gustavo Sverzut Barbieri wrote: >>>> Hi all, >>>> >>> >>> Enlightenment is using it in some places and some E widgets are no >>> longer used, however given that the plan is to rewrite the all the >>> configs anyway no one has bothered to replace them all with elementary, >>> once this is done then e widgets will likely be removed. >> >> yes, but my point below is when we do that, try to do in the highest >> possible way, like using lua, mvc whenever appropriated, etc. >> > > Well my personal experience from working on large scale software > projects suggests that for larger projects you don't want too high a > language as loosing your compile time type checking etc tends to lead > towards more bugs and less manageable software. That is why personally I > prefer C++ or maybe C for larger projects, I guess for some E modules > you could probably get away with it. As with smaller elementary based > applications although if I was going to write one I'd probably use python.
well, there are huge applications written in high level languages, even those without type-checking... which are replaced with tests and extensive coverage ;-) Type checking more often than not gets in the way more than it helps. At least I usually write my software, compile and have to fix many stupid type checking or errors resulting from useless typing (braces, type declarations, casts, manual reference counting)... as these things that do not aggregate any value are gone, software just works. > That however, just brings us to probably what is your bigger hurdle, > Enlightenment developers tend to be old and grumpy and still like to do > everything in C for reasons that escape me :-P "the way it was done, is done... just do it" >>>> - Could we eliminate all custom FS -> List/View code paths and use >>>> the MVC that gives you that? >>>> >>>> From IRC talks it's clear that our technology is not there yet, of >>>> course Eo needs to be declared stable, eolian_lua needs some work and >>>> MVC is still immature... but my bet is that unless we commit to the >>>> above these will never happen, >>>> >>> The reason the 1.19 release is now dragging out to 7 months is because >>> eo hasn't been declared stable and from what it seems like know one has >>> the time to put in to get this finished. As a result releases are harder >>> because some apps like eflete and enventor are using eo and whenever efl >>> is released we need to sync there release as well. >> >> Developers disagree on how to get Eo out... this is another issue. My >> personal take on this is we should sync everything for a while and >> force strict version dependency of all apps and EFL until it's fully >> done. >> > > Speaking with a distro maintainers hat on I will simply say that idea is > Madness and can't happen :-P (Being like that with 1-2 apps is hard > enough already). > > The only way we can move forward here is if we can get a api we are > willing to call stable then release it. then it's maybe better to call efl2 by that time, do as we did prior to 1.0 and everybody will need external repos or use the source to get anything useful :-/ >> If we try to provide "super stable, never breaks API/ABI" it will >> impact immensely the small development team we have and you can expect >> 1.19-like experience for all other releases. >> > I far prefer these experiences to releasing every 3 months then having > to update every piece of software using efl every 3 months. I don't get that, as we have few projects, basically you wait until a snapshot is released and apps work with it, then you package them all and build them all at once. -- Gustavo Sverzut Barbieri -------------------------------------- Mobile: +55 (16) 99354-9890 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
