X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-UW-Orig-Sender:	fpm AT homer03 DOT u DOT washington DOT edu
Date:	Wed, 8 Jul 2015 09:12:22 -0700 (PDT)
From:	"Frank Miles (fpm AT u DOT washington DOT edu) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	"Gabriel Paubert (paubert AT iram DOT es) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Subject:	Re: [geda-user] gEDA/gschem still alive?
In-Reply-To:	<20150708074915.GE13243@visitor2.iram.es>
Message-ID:	<alpine.LRH.2.01.1507080846260.8171@homer03.u.washington.edu>
References:	<20150706200609 DOT GD24178 AT localhost DOT localdomain> <CAC4O8c9f0pLsLu_dyuO5ggh7RmHY1vAA=UUhk9AE0JYZb4mhBQ AT mail DOT gmail DOT com> <CAM2RGhQfPO31-1Uyc3kC7w286r0VD7c41UZEZcyYquzknCxbsQ AT mail DOT gmail DOT com> <20150707060409 DOT GB14357 AT localhost DOT localdomain>
	<CAOP4iL2C_LU=RQy5FWYF-7RrHW6tqhqqyFJGjkwLQ2AD7FiYJA AT mail DOT gmail DOT com> <1436287952 DOT 678 DOT 26 DOT camel AT ssalewski DOT de> <559C0F7E DOT 7010009 AT neurotica DOT com> <20150707183339 DOT GA1817 AT alpha2> <201507071836 DOT t67Ia8s3014717 AT envy DOT delorie DOT com> <20150707185906 DOT GA2117 AT alpha2>
	<20150708074915 DOT GE13243 AT visitor2 DOT iram DOT es>
User-Agent:	Alpine 2.01 (LRH 1217 2009-02-23)
MIME-Version:	1.0
X-PMX-Version:	6.1.0.2415318, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.8.160315
X-PMX-Server:	mxout26.s.uw.edu
X-Uwash-Spam:	Gauge=X, Probability=10%, Report='
	TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, NO_URI_HTTPS 0, REFERENCES 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0'
Reply-To:	geda-user AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	geda-user AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Wed, 8 Jul 2015, Gabriel Paubert (paubert AT iram DOT es) [via geda-user AT delorie DOT com] wrote:

> Python is great for quick development. But experience here shows that it
> is a disaster for code which needs long term maintenance. Removing
> obsolete functionality is extremely hard, that's something for which
> nothing beats compiled languages.

My experience with python seems different.

What constitutes "long term maintenance"?  I have a sizeable app* (ok, it's
only a front-end for a database system) that has seen heavy (local) use for
over 10 years now.  It's had regular enhancements/alterations through this
time - soon the 250th minor version will be released.  (sure, some of this
is bugfixes.  But lots for little incremental enhancements).  And this is
_not_ my primary job; only something that I put together to make things
more manageable.  I'd certainly agree that its speed would be faster if
re-written in a compiled language.  But its fast enough, and it is SO
MUCH EASIER to modify or bugfix than the other languages I've used.  Maybe
your experience comes from the TkInter part?  I didn't use that.

> I once developed a moderately complex algorithm in Python, it was fairly
> slow but I would not have written it that fast in C (I learned both Python
> and TkInter at the same time so there was a lot to learn). This took one
> month, and then the translation of the code to C (without the GUI) took
> me 2-3 hours. It would have taken me more time to write it only in C.
>
>    Gabriel

I've written C since VAX11/780.  Recently used guile/scheme to create a 
new gnetlist backend for kicad (an interesting experience, but not very
enjoyable).  In the end I'm mostly satisfied with geda apps in C.  It seems
silly to convert to another language if the major reason is to attract
programmers with that language as their primary interest.  We would be
better off thinking more about improving the capabilities or user interface
of what we've got now.  Like dealing with the multiplicity of [manufacturer's
part] <-> [schematic symbol] <-> [board-layout footprint], for one.  {see
kicad's mapper for one approach to this hard problem}.

 	-F

* size ~ 100k lines, and has to interoperate with some special C functions
and some 10's of k-lines of SQL functions.  Not huge, but not trivial either.

- Raw text -