Re: Eu vs perl
David Cuny wrote:
snip
>It seems the most effective way to get change to write code that pushes the
>boundaries of the existing system.
That would be an area that you are a better judge of than I. You certainly
have pushed the boundaries, and I mean that in the most complimentary way.
>Plenty of large C projects seem to get along just fine without namespace, by
>using naming conventions. I'd adding prefixes the my routine names and
>constants; for example:
>
> wmCreateWindow() -- function name
> WM_DialogWindow -- constant
The problem with programmer added prefixes is that they are static and do
not allow for multiple occurrences. If I have a structure that describes a
file, I may have three files with the same structure open at the same time.
Do I recode the structure three times with a different prefix every time.
Seems silly and wasteful to me as well as not really answering to the
problem. I may have a variable number of files open with the same structure.
How do I deal with that situation without variable prefixing...oops...probably
should ask for one thing at a time. If I get prefixing, I'll figure out the
rest...
though one could wish! Constants with or without manual or automatic
prefixes are an abomination when they are used for indexing. They are
barely tolerable when they directly represent meta-data such as:
constant five = 5
Umptee -Umpth repetition. Constants are not necessary in a "minimalist"
language.
>> You can rag on me all you want, but it is not going to
>> solve the problems that are extant.
>
>My intent isn't to 'rag' on you; I've been working with Euphoria for some
>time now, and I've yet to encounter the sort of problems you describe.
And I shouldn't accuse. I share some of Jiri's irritation with the "way" that
the libs you have written are headed, but I also recognize that this
language would be sitting virtually unused if it wasn't for that very work.
It irritates me to see such effort put into code that may not easily be
portable between major versions of the same operating system, much
less between OS's and machines. That is not your fault. It is the result of
the tools at hand. The portablility efforts you are making suffer from the
same problems for the same reasons, but certainly should require less
"trimming" than previous efforts.
I'm not quite as irritable as Jiri, but after the third demand for code I got a
little crotchety. I will say that I have looked at many of the things that you
have done and liked most, but I have not seen much generic string
handling done in your programs...and program editors don't count, since
they are completely structured by the grammar of the language and have
strict definitions of the set of possible strings to be handled. That could
be about a million miles wrong, since you obviously write a lot of code...but
it was an impression.
Try to do human language parsing to establish structure, much less meaning
and intent, and you will swiftly run into the type of paradoxes built into
human language. Having paradoxical constructs in the language that you
are trying to use to do the analysis is no help at all. Both libraries and some
native constructs would be helpful for tasks that deal with these complexities.
Streams of input data from places like the internet will also trigger these
kinds
of needs.
Everett L.(Rett) Williams
rett at gvtc.com
|
Not Categorized, Please Help
|
|
