Re: Ideas for next Eu
Well, I'll try to keep this brief for all concerned, but
we'll see how it goes...
Everett Williams wrote:
> 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.
Okay, I understand a desire for columns, but how does a lack
of a facility to get at them make the language incomplete? If
I recall correctly, C doesn't allow you to extract a column
from a 2D structure either...
(Please note that this question does NOT mean I'm trying to
say that the language is complete.)
>>>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.
[...]
>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.
Uh-uh... we're asking if only having indexes follows
Rob's minimalist bias. 
And since anything that can
be done with named elements can be done via indexing...
>>>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.
How does allowing assembler make it any different?
Cleaner looking, yes, but in my mind I really don't
see a difference between
poke (addr, value)
and
MOV #7F, ADDR
>>>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 
)
Well, I don't really have a problem with a constraint on
that. In other words, describing Euphoria as "a minimalist
language for Windows" as opposed to just "a minimalist
language." In which case some facility allowing for Windows
interaction is inherint in the definition.
>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, 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.
You seem to be implying some specific construct, but I
guess it's going over my head... how would you propose
allowing Windows to call one of your functions without
a command that has all of routine_id()'s functionality?
I can't think of any other alternative.
>>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
Oh, just stick around the list long enough. They'll make
themselves known (no offense to them...)
>My only interest in GUI's is
>that they are where most programming is done these days.
Mmmm, ummm, I'll admit, I don't have your broad work
experience in the programming realm, so I won't
venture to deny or support that, but I know a number
of similarly experienced people who would *vehemently*
oppose that statement. 
[...]
>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.
Well, I'll second that!
(Side-note to anyone involved with ACI and their 4D
IDE... get rid of the proportional font!!!)
>>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.
Well, concerning the "mud wrestling", I'll quickly
admit to that. But, personally, that's my concern.
That Euphoria, in the drive to become "market-savvy",
will get so dirty as to lose it's original shine.
I'd rather have it shiny and not-as-popular-or-even-
useful instead of the opposite. I can already use
languages like that.
Oh, and about the hooks, I'm not belitting them. If
you ask me, building a language around one principle
element that also acts as a hook is a great thing;
unfortunately, I don't see Euphoria as having anything
like that ("simplicity", while potent, just doesn't
seem to come across as an attention-grabber anymore.)
[...]
>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.
Understood. However, he might not be able to fully
answer that question himself. I'm not sure I'd be
able to in his situation.
[...]
>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.
Ugh... I really wish you wouldn't look at it that way.
I chose to use Euphoria because of what it currently is.
I want to work with it, even if that means I won't rake
in the cash, fame, or even "productivity" of C, Java,
etc. I'd rather spend my free time writing code for
myself in Euphoria than using C to make Mr. Gates' next
blockbuster app. Granted, if Euphoria didn't exist
I could use my free time writing for myself in C, but I
think I wouldn't like it as much.
I'm sure a lot of potentially brilliant engineers choose
to tinker with stuff in their garage rather than go the
accepted route. I don't consider such a decision a loss.
> 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.
Hmm... I think I'd be critical of any course that only
used one tutorial language in the first place. Although,
I'd wager a bet that a programmer "weaned" on just
Euphoria would probably hit C and wonder why on earth
anyone would use it if they didn't have to. (Yes, I
said "weaned"--I can't think of a more clear phrase
right now, so...)
>> 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.
I can understand that. But remember, newbies have
needs too.
>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.
Well, I'm not trying to put Rob on a pedastal, but I
really don't have a problem with the way he's doing
things now. And to be honest, I don't feel *entirely*
secure with Euphoria being in just his hands. However,
there are advantages to the situation, and hey--it's
HIS brainchild--so I'm not going to complain.
Rod Jackson
|
Not Categorized, Please Help
|
|
