Future directions

In issue #1248, JoesCat wrote:

> From what I've seen, I think both the python scripting and native
> scripting need re-writes to be fault tolerant, so if you tackle one, you
> should tackle the other in parallel, but the problem is a lot of code that
> both of these call could also use a bit of fault toleration and recovery as
> well, otherwise, we just tackle the problem at the surface and skip the
> problems lower down.
>
> It's 10x easier to simply remove something than to add something new.
> It doesn't take much thought to take something out - and therefore, many
> newcomers want to make an immediate visible impact, so, repeatedly, I see
> they quickly begin removing stuff - not wanted! not needed! take it out!
>
> Going from 20120731-b to 20140101 FF had some stuff disabled, and in some
> instances, completely removed - take GTK for example, it's not working in
> 20140101, but in a recent email, you mention it's possibly worth bringing
> back to life again.
> Would it be easier to start GTK coding from scratch? or does the existing
> (dead) code appear to be useful to serve as some sort of template you can
> build-on and improve?
>
> What I'm saying is, rather than simply going-about removing stuff because
> you don't see need for it, just leave it "parked", and do nothing yourself
> with it ...eventually, someone else may/will come around and start picking
> at it and make good use of it. For example, @blipvert<https://github.com/blipvert>is adding to and improving various bits of FF scripting, and as you read
> (above), there are still users that make use of it too.
>
> With Open source development, you may need to think of development
> happening in months/years when someone interested in a particular section
> comes along and sees-fit to improve that particular chunk of code.
>
> I'm glad we didn't simply toss-away GTK many months ago, and you have an
> interest in looking at it now.
>
 You're right to sound a note of caution.

My removals have been aimed at purely unnecessary code (memory management,
dead code, reimplementations of APIs available from gnulib) and reducing
unnecessary flexibility (optional dependencies). There's certainly an
argument to be made for removing functionality, but I'm not sufficiently
expert in the application domain to make it; rather, my primary interest is
in making it easier to improve FF without making it harder to maintain, and
to plot a route to further reducing effort in future. "Parked" code is a
maintenance burden while it's still in the tree, and with git it can be
safely retired: interested coders can browse the history in future.

Removing stuff is technically easier than adding it, but it's much easier
to get agreement about adding than about removal, and in the end that leads
to projects suffocating under their own weight; and in my experience,
removal is much less common.

I think FF scripting will probably be the hardest to agree, and I agree
that the Python binding/embedding is ugly; but I also think it's the best
thing to focus on, because as well as a big internal cleanup, sorting it
out also provides a route to writing new code and rewriting old in Python,
which would be a big win over C. I've done this before: I translated GNU
Zile from C to Lua in its entirety. The result did not justify the effort
(~25% code size reduction; I'd've felt ~50-60% would have been reasonable),
but it was a huge improvement on the original, and I'm not suggesting a
total rewrite for FF.

-- 
http://rrt.sc3d.org

------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk

_______________________________________________
Fontforge-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fontforge-devel