[PD] symbolatom: why does it not allow to type spaces?
reduzierer at yahoo.de
Sat Dec 15 06:10:55 CET 2007
On Wed, 2007-12-12 at 19:39 -0500, Mathieu Bouchard wrote:
> On Wed, 12 Dec 2007, Hans-Christoph Steiner wrote:
> > It's nice to add those features, but by adding them to the pd-vanilla
> > objects, that means patches written in desiredata are not compatible with
> > pd-vanilla.
> No, pd-vanilla loads them fine, the patches are compatible. It's just
> about bugs that you don't consider to be bugs. A bug is a bug is a bug,
> and I consider the compatibility issue with bugs to be moot, because the
> bug is the fault of the software that has the bug in it, it's not the
> fault of the rest of the planet.
when i learned pd, i didn't know any other progamming language, thus i
just accepted the little 'inconveniences' of pd. i just assumed, there
is a real reason for not having spaces in symbols, that i might not
know. after having constructed symbols with spaces ten thousand times
using [32(-[makefilename %c]-[list-l2s] constructs, i start to think
about if there might be a good reason, that i have to do so. and i
couldn't find one. i personally think, it is the wrong way to workaround
such issues by - for example - allowing the 'label' message for iemguis
to carry lists instead of symbols. why doing all that effort, for a
solution, that is just an ugly hack, doesn't solve the original problem
and, for me the most important point, doesn't stop people from asking,
why symbolatom cannot create spaces.
in this respect i might have a 180° different opinion from yours, hans.
i'd rather keep a silly thing like lacking space in symbolbox obvious,
until it is fixed once forever, so that people stay aware of this bug,
rather than workaround it. the workaround is a) more work (i assume) and
hides the real problem. i didn't follow the psql very closely, but if i
am not totally mistaken a lot of the discussion was about how to create
proper sql syntax with pd's limited character set. iirc, this was not
first discussion about this kind of issue in this list, and it won't be
the last one. whenever someone writes an externals, that deals with a
syntax that doesn't match pd's character set, a new solution has to be
found -> a lot of discussion -> a lot of programmig effort to overcome
the problem -> a lot of work to maintain the code -> similar code is
written several times instead of only once -> probably different
strategies are used to workaround the problem -> consistency problems,
etc..... why not just simply fix it in pd? by 'simply' i don't want to
say, that fix is a simple one (i actually don't have a clue about its
level of difficulty), but it's the only and the one and logical
solution. lets face the reality: people do not just use pd anymore to
load some soundfiles with a symbol, they use also symbols and lists of
symbols to talk http, displaying telugu characters with gem, sending
blobs to a database etc. i highly doubt, that you (hans)
fixing/workaround problems that are not solved in the first place (by
miller) is the way to go. in the name of the church of consistency i
claim the practice of fixing problems at the most low level stage as
possible as the only meaningful one.
yo, that said, i'll go writing a bug report.
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
More information about the Pd-list