Marc Olschok <nobody@[EMAIL PROTECTED]
> writes:
> Aleksej Saushev <asau@[EMAIL PROTECTED]
> wrote:
>> Marc Olschok <nobody@[EMAIL PROTECTED]
> writes:
>>
>> > Aleksej Saushev <asau@[EMAIL PROTECTED]
> wrote:
>> >> Marc Olschok <nobody@[EMAIL PROTECTED]
> writes:
>> >>
>> >> > Aleksej Saushev <asau@[EMAIL PROTECTED]
> wrote:
>> >> >> Bruce McFarling <agila61@[EMAIL PROTECTED]
> 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?
Ever heard of "1x Programming"?
> Anyway, I hope that my statements are better than buzzwords.
What makes you think so? Have you ever tried to align your words
with practice around you? Or do you assume, that being ignorant
of life around you protects you from making the same mistakes?
> 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?
Togda pochemu ty pisheshj po-anglijski, prichjom dovoljno gramotno?
Why do you write in grammatically correct English then, rather
than inventing your own way? Isn't it strange? You solve regular
life problems in common English, but you don't solve programming
tasks in common Forth, you tend to invent your _own_ domain language
rather.
>> 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.
Right. But the domain of those problems stabilized long ago. In C, which
started _later_ you have basic string primitives (string.h, strings.h),
not-so-basic string parsing tools (regex.h), even more complex tools
(LEX, YACC), all for long time now. In Forth, which entered same area
in 1980s-90s, you hardly have analogue of string.h/strings.h in common
use.
I don't take embedded area, though the presence of HTTP server in
electronic
teapot isn't uncommon these days.
>> > 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.
How are you going to work with LEX and YACC (bison is just GNU version of
it)
without programming in C? Are you going to do that in Java or SML/OCaml
with their versions of respective tools?
>> >> >> > 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.
Please, if you say "should be", provide examples in support.
I assure you, that seeking for examples and protecting from
counter-examples brings up more issues, that prevent you from
saying such an easy "should."
How are you going to label library that provides calculation of MD5
digests? Why should I call my "libmd5" a "lib_all_my_names_here_md5"?
Why should I install it under /usr/local/lib/my-project rather than
/usr/local/lib, or even more simple /usr/lib or /lib? Am I not going
to reuse it in other my packages?
Or are you going to rename functions? It may provide bug-to-bug
compatibility, but how do you know which one does what?
Do you propose adding version numbers to it?
How does it align with simple "md5(string)" and "md5_2(acc, string)"?
> 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.
"Should?" Must!
--
BECHA...
CKOPO CE3OH...
|
