Re: Ideas for next Eu
Mr. Jackson,
Points very well taken. I appreciate your manner and your concerns. I don't
happen to agree entirely with you, but I like your style. Please read on.
> Roderick Jackson wrote:
>>
>>Slices are wonderful, but they
>>only run one way. How strange, how incomplete.
>
>??? I don't understand this. Run what way?
Rather than say run what way, say how do I describe a column or a
range of columns in a two-dimensional structure without a chiropracter
to realign my spine when I get through.
>
>>I must refer to
>>everything in them by subscript...almost as error prone as assembler.
>>That is, unless I am willing to use a conflict prone and dangerous
>>method of constants that eats up namespace and memory to little
>>practical purpose. What is minimalist about that?
>
>Surely you're not suggesting that all index accesses
>be forced to be named? That wouldn't fit well with the
>concept of a structure of arbitrary size. Allowing just
>numeric indexing certainly seems more minimalist (and
>'cleaner') than allowing both indexing AND record-like
>naming at the same time.
Absolutely not, indexes are useful and sometimes absolutely
necessary in ill-defined data. We don't have just numeric indexing,
we already have a redefinition or a naming of a datum called a constant.
In a minimalist language, constants are not necessary. They are a
subset of and can be emulated with variables. If we are going to have
descriptive naming (most useful in fixed structures, but somewhat
applicable in variable structures also), why don't we do it right?
Constants occupy real memory and namespace and are inherently
deceptive, when used as indexes. They seem to say that they are
picking out whatever item that their name indicates, when in
reality, they are just place holders for a number which logically
would vary across different sequences with the same "content" in
different locations or pointed to by different indexes to be correct.
Indexes are no different from and no more informative than offsets
in assembler. They are needed, but do we really want to look at them
in a high level language any more than is absolutely necessary. If
you look at most modern assemblers that use named offsets you
will have the answer to your question.
>>And what is
>>minimalist or clean and simple about peek and poke, two very blunt
>>instruments that bring out everything that is worst in programming
>>style.
>
>Well, I can easily see them as being minimalist. Any
>language that has a prayer at achieving low-level access
>needs them. Granted, they are messy, but considering we
>live in a C-oriented world (for the most part) and that
>much Euphoria programming involves Windows, there's a
>clear requirement there as well.
I absolutely deny that peek and poke are the only way to accomplish
what you are speaking of here. Even C allows access to variables in
inline assembler rather than force the type of machine code level
programming that peek and poke generate.
>
>>Then, we have routine_id(), that broke the simple declare before
>>use rule in the ugliest possible manner. In my world, those are not
>>clean, minimalist additions to a clean and minimalist language.
>
>Well, c'mon, a minimalist attitude must be constrained
>by needed features (which I'm sure is your point, but
>read on.) I'm sure routine_id will be a point of
>controversy for a long time, but apparently, for
>Windows programming, it's absolutely *essential*. I.e.,
>any minimalist language that is intended to be used
>with Windows MUST have it, or it can not be used with
>Windows. I don't see most proposed changes to the
>language, or proposed points of focus, having that
>level of absolute need.
You're cheating again...switching boats..er..arguments in mid-discussion.
Minimalist does not mean small or even simple. It means the minimum
necessary to effiiently accomplish the goal(in the dictionary according to
Everett Williams 
) I am a strong believer in Occam's razor, that says
when presented with two EQUAL(emphasis mine) solutions to a problem
the simpler one is normally the better choice. Now if the simpler solution
is already superior by some fairly complete set of criteria, then Occam's
razor is unnecessary. When the simpler solution is weaker, the going
gets tough. Decisions, decisions...then the problem must be altered to
allow a less than optimum solution. Usually the problem is altered by
non-technical factors such as time, money, etc.
Now, back to your switched argument. I'm not ready to admit that
routine_id() is the only or even the optimal solution to the problem
of Windows programming. Something that accomplishes what
routine_id() does is necessary. If I want to kill a mouse in my house,
I use poison, or a trap, or at most a .22 with ratshot in it. If I go get
an army tank, I really trash the house in the process. Enough! System
routines that request the same facilities that are provided by peek, poke,
routine_id, call_C, and their ilk can be written and optimized in the
interpreter. Then, if we have real data structures that address real
world data(not designed or provided by another Euphoria program) and
these system routines, we can code ordinary looking Euphoria code
to accomplish these ends. I grant that available time and effort limits
may have prompted the creation of these ugly ducklings, but I
would suggest that they have created and will create a lot of ugly
code that will truly injure the clean, minimal nature of Euphoria before
they are excised.
>
>>When a language does not have standard facities for the most basic
>>functions that a language must perform, it forces the programmers
>>into complex, forced, non-minimalist solutions to ordinary, everyday
>>problems. Clean variable usage, modular development, and standard
>>facilities for handling external data of arbitrary(read that as produced
>>by languages and facilities other than Euphoria) format are not minor
>>conveniences. Without these facilities, Euphoria is the perfect language
>>for writing crystalline clear algorithms suitable for teaching or
>>learning. With them it becomes a full fledged, commercial language
>>capable of tackling any task that falls within it's performance
>>parameters.
>
>>Really cool, in my mind, means things like GUI's and IDE's and Games.
>
>Just for the record, really cool could mean something
>else entirely to other people. Many on this list would
>love to see Euphoria fully ready to tackle the business
>programming environment.
I don't ordinarily like to insert comments in the middle of a paragraph,
but this time I must. Having Euphoria ready to and capable of
handling the business programming environment is my most
fervent wish. IDE's and similar items are just tools to effect that end.
I'm not into "really cool" of any kind. I'm into getting work done. I just
borrowed somebody else's phrase.
>Others still the database
>realm. You'd be surprised how many people could care
>less about Windows-like environments at all (and probably
>secretly dislike all of the effort being put into such.)
>I think demanding that GUIs and IDEs or even games be the
>primary focus of development for the language is a bit
>narrow.
That must have been my evil twin My only interest in GUI's is
that they are where most programming is done these days. If
Windows had a true character environment that did not invoke a
DOS window, I would love it. Proportional text makes messy pudding
out of source code. I do, however, believe that an IDE is a practical
necessity in a modern programming environment. The text environment
of the IBM TSO/SPF or VM/CMS environment in it's later incarnations
with REXX as a macro language were/are truly powerful programming
environments. In VM, you could even immediately route the program
test to another virtual machine running whatever platform was your target
environment, switch to that window, observe, and switch back to fix
whatever errors that you had. I'll take and use all the GUI facilities for
the tools and the output, but source code in any other than fixed format
is a positive pain in the tush.
>>In any case, I see little active, commercial use of
>>the product. Most of the action I see is by hobbyists and gamers and
>>concerns addressing the language's needs in the development area...
>>libraries, IDE's, GUI's, etc.
>
>Which would likely be true of any young language that
>1) hasn't received a lot of media hype, 2) isn't a spin-
>off a currently hot language, and 3) doesn't use one
>principle "hook" (like complete cross-platforming, or
>Internet suitability) to sell to people.
I wouldn't denigrate those "hooks" that you refer to above. Euphoria
can get to several of them IMO. And, getting to one of them would
make it a currently hot language. Computing in the modern environment
isn't the "crystal palaces" of "Kublai Khan". Mr.'s Gates and Grove have
shown that it is a lot more like mud wrestling. Anything that
survives in this environment will get a little dirt on it. Doing things
like peek, poke, and routine_id() is like throwing a fight before the
opening round bell has rung.
>>No responsible decision maker could allow usage of the language in
>>it's current state with that kind of ringing commitment to progress. It
>>may not be laziness, but the effect on the language is the same.
>
>This is going too far. Rob's lack of structures,
>function indexing, etc. doesn't make him irresponsible.
>He's under NO obligation whatsoever to provide a Swiss-
>army-knife product along the lines of Visual Basic,
Who would want that? Adding practical programming tools to
Euphoria will not make a sow's ear out of this silk purse unless
the tools are implemented in a thoughtless fashion.
>capable of writing practically any heavy-duty commercial
>project desired.
I desire, I desire.
> Frankly, there's really no reason to
>expect him to want such. (It's to his credit that he
>hasn't already just gotten fed up with our continual
>demands and stepped out of the picture entirely.
>Especially considering that the very layout of the
>language implies the route he wants to take with it,
>and a lot of the suggestions try to pull it onto a
>different route.)
>
>If Rob DOES want to see major commercial use of his
>language, at the expense of everything else, then yes,
>there are things the language still needs, things that
>have been mentioned before on the list, including--as
>you mentioned--a need for planning. But apparently,
>he has limits as to the what he's willing to sacrifice
>for that commercial use. And to criticize him for not
>immediately implementing specific tools/features/etc.
>that would lead to such utility,
In the accelerated world that we live in, 3 1/2(it could be longer,
I am just going by the date of the beginning of the list) years is not
immediately. It isn't even "andante". It's more the pace of
Sancho Panza's burro. The big "IF" is "DOES Rob want to see
major commercial use of his language", period. I WOULD DEARLY
LOVE TO HAVE AN ANSWER TO THAT QUESTION. Most of the
"expenses" that you and I have mentioned will make the language
more "complete" or "symmetric" or "orthogonal". They will leave
the language orders of magnitude less complex than the nearest
competition and will allow the commercial use we are speaking of.
If there is no intent to get to that goal, then Euphoria is just a really
elegant hobby tool that has sucked up a great deal of time and
effort by a group of really talented people that could have been using
their efforts towards some productive goal. It's only utility would then
be as a training or learning tool(not an ignoble goal by any means).
Of course, anyone who learns on Euphoria is really going to hate
the "real" world of C, etc. and wonder why Euphoria never grew up.
> or for going about
>developing the language in a way that doesn't suit your
>particular needs (or for that matter, anyone else's
>particular needs) is unwarranted. Progress, like what
>would make the language "cool", can mean entirely
>different things to different folks.
Thirty-three years of experience with dozens of languages and
many different programming environments makes my
understanding of "needs" a little different than the understanding
of the average newbie. The fact that the core needs that I refer
to are echoed in large part by what I perceive as a majority(if with varying
methods) of the experienced types that I note on this forum, makes me
think that my requests are neither narrow nor too specific. I have
acquired and helped write software tools for engineering, corporate, and
software development environments. I have been a senior systems
programmer responsible for the software, security, stability, and
performance, not to mention troubleshooting of every problem that no
one else could figure out, of the mainframes of a multi-billion dollar
corporation in the late 70s when b meant a big number and didn't make
anybody think of Bill Gates.
>>Insult was no part of my intent.
>>Progress is.
>
>Likewise with my comments.
>
>Rod Jackson
If the answer to the above critical question is YES, then I guess I will
try to pipe down and wait to see what Rob's next move is. I am not into
guru's or other such theocracies, no matter how God-like or capable,
so being dependent on the whim of a single person gives me gas.
Impatiently yours,
Everett L.(Rett) Williams
rett at gvtc.com
|
Not Categorized, Please Help
|
|
