> Marc Olschok writes:
>
>> Aleksej Saushev
wrote:>>> Marc Olschok writes:
>>>
>>>> Aleksej Saushev
wrote:>>>>> Bruce McFarling
netscape.net> writes:>[...]
>>> I doubt it, even in the context of ASCII Forth isn't good at parsing,
>>> regular language isn't a problem, but even for that language you have
>>> to hardcode your parser, instead of reusing regular expressions.
>>> (Even Delphi programmers do it!)
>>
>> Most likely a Forth programmer will happily hardcode a special purpose
>> parser adapted to the structure of the data, in the same way as he
>> would build a special solution adapted to some other problem.
>
> In Forth land programmer does the job of lexer and parser.
>
> How does your statement align with "1x" and other Forth buzzwords?
_____________________________________^^^_
what does it mean?
Anyway, I hope that my statements are better than buzzwords.
We already agreed before that the preference for "writing from the ground up"
might be more popular with Forth programmers. Why should parsing and handling
of strings in general be an exception?
> Hardcoding is called so, because it is _hard_ to code (among others,
> it is hard to maintain too, if possible at all, which suits more
> "write-only" attribute of Forth).
The word-play on "hard coding" may have some thruth in it.
But as said before the decision wether to hand-craft a solution
to some specific task (which might not be easily reused for different
tasks) or to adapt some general solution to the current need is influenced
by many factors.
>
>> I cannot speak from experience here because I do not have any serious
>> parsing problems where code size is an issue (usually sed and awk are
>> good enough for me).
>
> And when your awk/sed scripts with sh glue code become too slow?
> What will you do?
I do not know yet, so far this has not happened.
I might try to learn enough about lex+bison in order to build a solution
with these. Or I might use some existing libraries. As long as I do not
have to program in it, I do not mind using C. Also I might rethink
my solution.
>[...]
>>>>>> Then add on top the lack of a de facto library management standard,
>>>>>> and on top of that the fact that for those who only need to do a
>>>>>> specific, people with a distinct set of concrete string tasks can
>>>>>> solve it from scratch with tools like those in TOOL2002. If that is
>>>>>> auxiliary to their main task, then once its solved, they may rarely
>>>>>> need to revisit it. So instead of investing the time and effort into
>>>>>> learning and importing a general purpose string handling toolkit and
>>>>>> than using 5%% of it, they build a much simpler special purpose
>>>>>> string handling toolkit and use 100%% of it.
>>>>>
>>>>> And thus reinventing the same wheel 100 times, instead of reusing
>>>>> the library written once years ago.
>>>>
>>>> Well, what if it is another wheel each time?
>>>
>>> It is even worse. Dealing with a dozen of non-standard kinds of
>>> screws is a nightmare, it causes only one and the single wish:
>>> to cram all these screws up those engineers' asses.
>>
>> Who surely will be glad that it is only software.
>>
>> But I was actually thinking not just of different implementations
>> of the same task (along different ways) but instead of implementation
>> of different (but specialized) tasks. For this, using some already
>> written general library might involve adapting it to the specific
>> requirements. The programmer will then try to guess, if this is more
>> work than writing a new implementation from scratch.
>
> Have you ever tried to support a collection of the code?
> Like that, that comes from various GNU and near-GNU sources.
> Many sloppy programmers don't use libraries, they prefer shipping
> their own versions. I.e. there're dozens of MD5 implementations,
> hundreds of base-64 and UU encoding-decoding routines around.
> Sometimes those developers just cut and paste the code.
I agree that this could be the worst of two worlds.
>
> Now what happens, if one innocent soul finds a bug in the
> library of one project, especially if it is design bug.
> This bug gets fixed in one or another projects, but stays in
> others. Just like broken gene. From now on you can't be sure,
> that that bug will never manifest itself.
This should be avoided by proper naming. Of course it should
rarely ever be necessary to literally incorporate e.g. package A
into package B. The obvious solution is to list package A as a
requirement for B, so that updates and corrections can be done
at the approriate place.
Marc
