Re: gEDA-user: gEDA programming

[John Doty <jpd@xxxxxxxxx>]

On Apr 23, 2010, at 5:00 AM, Miguel Sánchez de León Peque wrote:

>   Hi all,
>   I'm a student interested in contributing to gEDA and learn some C ;-).
>   The biggest problem I find any time I start coding is "how should I
>   write this?". You're always talking about deprecated code, libraries
>   you're/you're not using, old style...
>   Could you tell me any book/reference you'd find necessary to learn
>   modern C programming?

In the opinion, the big problem in gEDA right now is to remove as much C as possible from libgeda/gschem/gnetlist. Of course, that's more immediately difficult and requires better mastery of C and Guile than simply adding more code. However, added code will cause more future difficulty.

> Or to learn how to use extended libraries as GTK
>   and glibc? Or any other library widely used in C programming...

C is basically a low level language primary suitable for pushing bits on the hardware and wrapping interfaces to fix compatibility problems. For higher level programming there are better alternatives, and in gEDA we use one: Guile. But the rub is that too much of gEDA is coded in C, often without Guile API's.

From where I sit, gEDA's singular advantage over the competition is the ease of writing a gnetlist back end: this allows gEDA to adapt to the needs of project flows that other tools cannot.  In this case, the relevant functionality is well exposed to Guile, so users like me can charge forward without involving the core developers.

However, the situation isn't perfect. The workings of gschem aren't so well exposed, so there are few Guile scripts for gschem, and the ones that exist have some serious limitations. Even for gnetlist, guile scripts cannot control hierarchy expansion and cannot access all attribute instances, because the decisions are made at the C code level.

> Maybe
>   there's no book for that, it's just programming experience... am I
>   right? (I hope not! xD)
>   Thanks in advance,
>   A student who is a bit confused about which is good modern C
>   programming style... :-)

I don't think there is any such thing. These days coders type first and avoid thinking in order to create as much code as possible (thus the perceived importance of "code completion"). But *good* programming style hasn't changed.

Think. This is painful for us barely intelligent creatures, and costs time up front, but saves time down the road.

Factor. Write *very short* independent functions. My old friend and colleague Jon Sachs, the programmer who wrote the classic "Lotus 1-2-3", liked to point out that capability of well-factored code increases exponentially with the size of the code: there's a "combinatoric explosion". But we see in the modern "code first, avoid thought as much as possible" approach that the code size increases exponentially with capability. Not good.

Use the upper level as much as practical. For gEDA, export your factors to Guile and put them together there. Coding by functional composition, natural in Guile, is often the best way to assemble such factors into higher level factors.

Refactor. Often you find that an initial choice of factors is forcing code bloat because the factors don't fit the problem space as well as anticipated. Rather than add more bloat, your priority should be to fix the cause.

Study. The experts on C remain the Bell Labs folks, Ritchie, Kernighan, Pike, et al. Read their stuff.

Learn from history. If you really want to see C used as designed by its greatest expert, get the famous "Lions textbook". It's not longer samizdat, hurray:
http://en.wikipedia.org/wiki/Lions%27_Commentary_on_UNIX_6th_Edition,_with_Source_Code

John Doty              Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd@xxxxxxxxx




_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user