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:
> >> >> 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"?
No.
>
> > 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?
I might be ignorant about life around _you_, but I am quite aware
of life around me. So far I am happy with solving those problems
I have instead of those I do not have.
>
> > 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?
Because the disadvantage of being less widely understood would
outweigh the advantage of any personal grammar of English.
Also the established grammar is usually sufficient for what I
want to express.
> 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.
Not strange at all. Common language is good enough for common problems.
But extension of language and building of special domain languages happens
all the time. Also, the invention of a special domain language does not
mean that the grammar of the base language is rebuild from scratch.
>
> >> 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 agree with you. The need for consolidation and unification of
different (incompatible) language extensions is only felt when the
particular domain is im****tant enough to the user base. Without this
pressure, it does not happen and the different variant coexist.
It happens in natural languages too, see e.g.
<http://www.philhist.uni-augsburg.de/lehrstuehle/germanistik/\
sprachwissenschaft/medien/umfrage_regionalersprachgebrauch/Broetchen.jpg>
>[...]
> >> > 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 without programming in C?
> Are you going to do that in Java or SML/OCaml
> with their versions of respective tools?
This would depend on how involved the work is. Given my preferences, I
would most likely prefer tools from SML or Prolog. But I do not know
yet, as I said before, so far all my parsing tasks have been trivial.
>[...]
> >> > 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 sup****t 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 ****pping
> >> 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 sup****t.
> 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)"?
It depends on the situation. Suppose that I have some project where
for some reason I use a foreign library.
(a) if I did not change anything then I might even use the original name.
But as not bug repair may not result in a change of version number in the
original library, I would perhaps attach a time stamp, e.g. rename
libmd5 to libmd5-20080512 or similar.
(b) if I changed anything, then I would use a different name, e.g. change
libmd5 to libmd5_whatever and also make it quite clear that my version
is different from the original one and do***ent the changes.
It is vital that the prospective user is never in the dark about
what he is acually using.
Anyway, the best solution is to avoid the problem altogether by
referencing to the foreign library instead of including it.
>
> > Of course it should
> > rarely ever be necessary to literally incor****ate 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!
The phrase "Of course it must rarely ever be necessary to ..." is
not in my bag of English. Anyway, I know what you mean and sympathize
with it.
Marc
|
