Fwd: Hello

[I'd just posted the following to fontforge-users when I realised it should
probably have gone to fontforge-devel. Please reply here!]

Hi!

My primary interest in working on Fontforge has been to make it simpler and
more productive for other developers to work on; aside from fixing a couple
of minor bugs I found, I have not been working on any particular bugs or
features that interest me specifically.

So far, I have removed over 12,000 lines of code. The bulk of this has come
from using the BDW garbage collector, which resulted in about 8,000 lines
of free()s and associated memory management being removed. No more
double-free bugs, no more memory leaks, no more need to keep track of
memory! This is a technique I've used before (on GNU Zile, a small Emacs
clone), with similarly good results.

I have also removed a lot of dead code, and made a lot of previously
optional dependencies mandatory, thereby removing a lot of #ifdeffery.
Mature, portable libraries like libxml, libjpeg and libpng need not be
optional; nor need important, portable libraries like libspiro.

I have identified further candidates for code removal: aside from the
obvious big one (replace gdraw with gtk, which is already underway but will
take a long time and a lot of work), there are some smaller but also
sizable blocks of custom code we can remove: Fontforge's scripting
language: https://github.com/fontforge/fontforge/issues/1248 (~10kLOC) and
the custom image reading/writing code:
https://github.com/fontforge/fontforge/issues/1252 (~2.5kLOC).

Why all the code removal? Because Fontforge is huge, and its size makes it
hard to maintain. It totals about 500,000 lines of code, and it's growing.
I want to be able to use Fontforge for decades to come, and I want it to
continue to add functionality and support for new font technologies as they
come along. This is hard to do as it stands: the current codebase is an
incredible accomplishment by George Williams, but it's also hugely verbose
and hard to maintain. This is evidenced by the fact that most of the dozen
or so bugs I've fixed in my wandering over the codebase were introduced in
the relatively short time since development was opened up to other
contributors, by developers other than the original author.

I believe Fontforge could be at most 100kLOC with its current
functionality, but realistically that would be a huge amount of work, and
unlikely to be achieved. I have already picked much of the low-hanging
fruit, and as you can see, I've managed to remove less than 3% of the code,
or about 3% of what I think should be possible. Much of the code simply
needs rewriting, and that's unlikely to happen quickly.

However, we can do a lot to make Fontforge easier to hack on without
rewriting it all. Here are some ideas:

1. Fix warnings: I've added the option --enable-gcc-warnings to
./configure. Use it! Fix all the warnings in a file or two. I've already
done about 10% of them, and found 3 or 4 bugs in the process. It's well
worth it: not only are there probably several more bugs buried in the
remaining warnings, but GCC is good at catching errors, and they're only
"visible" once the code is clean.

2. When you do significant work on a module, look for ways to reduce the
code count: if you can make improvements without increasing the overall
code count, that's great. Some other contributors have already done some
excellent work simplifying certain sorts of code across the codebase;
doubtless there's more scope for this.

3. Work on the various areas I've mentioned above. GDraw is a fine
achievement, but it's had its day. Let's get cracking on moving to gtk.
Getting rid of GDraw altogether would remove 50kLOC, or about 10% of the
total. Similarly, Fontforge doesn't need a custom scripting language (*pace*,
those who love it!) but we *do* need a converter to turn Fontforge scripts
into Python.

4. Write in Python, not C: rather than writing more C, we should be writing
Python: if the plugin system needs extending and deepening to assist this
fine. Python is easier, faster and safer to write and debug than C.
Something that shouldn't need saying these days, but still does: it's also
faster to write fast code in Python than in C! The bits that need to run
fast can use C, of course.

5. Keep things clean: no more #ifdeffery; write plugins rather than new
core functions, and rewrite existing functionality into plugins; no more
platform-specific code. Above all, let's make sure we use the tools we now
have, such as package managers to deal with dependencies, automated tests &
builds &c. Fontforge solves a lot of platform problems (I'm looking at you,
Windows); it shouldn't. Those should be the platform's problem. When a
generic solution is not available, it should be upstreamed to the relevant
helper tool (gnulib, a library), and if, in the last resort,
Fontforge-specific code is needed, it should be separated in the build
system, not buried in the Fontforge code. As developers we should be able
to move much closer to the speed of developing only for modern systems with
modern tools

Without all this and more, Fontforge will quickly become unmaintainable, a
huge problem for a specialised piece of code with, at present, few serious
competitors. With discipline and effort, it could be a vibrant and stable
project for decades to come (as a user, that's what I want!).

Thanks for reading this far.

As of Wednesday, I'll be giving up coding for Lent (i.e. until 27th April);
however, I'll make an exception for fixing bugs in the commits I've made so
far; unsurprisingly, the introduction of garbage collection is taking a
while to settle down.

My thanks to everyone who's working on Fontforge to keep such a great piece
of machinery in order and moving smoothly forwards; as we say at work, *tantus
labor non sit cassus*.

-- 
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