1. A different proposal
After trying to follow the discussion of OOP, but getting lost,
I'd like to say:
1. The one thing that makes Euphoria stand out from other
similar languages is _simplicity_.*
2. Sometimes adding stuff to a language can actually make it
_simpler_.
3. OOP, if implemented correctly, would make programming
in Euphoria _simpler_.
4. A GUI, if implemented correctly, would make programming
and using Euphoria _simpler_.
An explanation is in order:
Let's say I want to make a program to ask a user to enter
her/his/its name,(we're nothing if not politically correct),
and make a choice to save or not to save:
I want to be able to write my program more or less as:
-- add a name to my database:
msg = ("Please enter your name and address below",
NAME,STREET,CITY,STATE,ZIP,
{OK,CANCEL})
if msg(ok) then SaveToDatabase(msg[data])
end if
Now, this could be on a plain black screen, or it could be in
a colorful window. Ideally, that shouldn't matter to the workings
of the program. The programmer should be able to add a line, say
"include mac_gui.e" at the top, and the appearance would change,
but the functionality would not.
Is this do-able?
- Yes.
Would it slow Euphoria down too much?
- I don't think so, if it was implemented properly.
Does it require OOP?
- Maybe not, but OOPishness would sure make the job easier.
Does it require GUI libraries?
- Yes, but not in the form we have written them so far.
Is it worth doing?
- Only if Rob would like a few hundred thousand new Euphoria
registrations;)
What I'm saying is: we're trying to play by someone else's rules;
Euphoria is different, maybe we should try to come
up with a fresh approach to enhancements as well.
Thoughts?
Irv
*Note: I didn't forget safety. That's just another form
of simplicity - it's simpler not to _have_ to track down
runaway pointers, uninit. variables, etc.
2. Re: A different proposal
> I want to be able to write my program more or less as:
>
> -- add a name to my database:
> msg = ("Please enter your name and address below",
> NAME,STREET,CITY,STATE,ZIP,
> {OK,CANCEL})
> if msg(ok) then SaveToDatabase(msg[data])
> end if
This is exactly what I would want: some sort of function that, given a general
set of templates, could construct windows for you. Like X-Windows packers,
for example. Just say
msg = BuildBox("Prompt",
"Please enter your name and address.",
... etc ...
response = showbox(msg)
etc.
And, if you want your own control, build it yourself and hand it to showbox
or whatever the function is. Now that is good programming. Heck, make it so
you can redefine the templates, too. I think Irv spoke a little about that.
--
Cameron Kaiser * spectre at sserv.com * http://www.sserv.com/
--
Visit the leading Internet starting point today!
http://www.sserv.com/
--
3. Re: A different proposal
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
Jun 03, 1998
-
Last edited Jun 04, 1998
> 1. The one thing that makes Euphoria stand out from other
> similar languages is _simplicity_.*
TRUE, simplicity because its very consequent. No exceptions. No *hacks*
> 3. OOP, if implemented correctly, would make programming
> in Euphoria _simpler_.
It works as an balancer.
Small programs will be more complex.
Complex programs will be less complex.
> 4. A GUI, if implemented correctly, would make programming
> and using Euphoria _simpler_.
100% Agreed, GUI is a tool. Graphic routines belong to the GUI.
>I want to be able to write my program more or less as:
>
>-- add a name to my database:
> msg = ("Please enter your name and address below",
> NAME,STREET,CITY,STATE,ZIP,
> {OK,CANCEL})
> if msg(ok) then SaveToDatabase(msg[data])
> end if
Well, this can already be done through includes actually.
msg = some_routine (............................, NAME, STREET.......)
if msg[ok] then SaveToDatabase(msg[data])
end if
Maybe not 100%, but you don't need to change the language to accomplish
this.
>Now, this could be on a plain black screen, or it could be in
>a colorful window. Ideally, that shouldn't matter to the workings
>of the program. The programmer should be able to add a line, say
>"include mac_gui.e" at the top, and the appearance would change,
>but the functionality would not.
That is what classes do.
>Is this do-able?
>- Yes.
>Would it slow Euphoria down too much?
>- I don't think so, if it was implemented properly.
Precizely, and pure oop is thus not the way to go. It would slow it down and
add stuff that is simply not compatible to the Euphoria ideology. It would
work, but it would make Euphoria very inconsistent.
>Does it require OOP?
>- Maybe not, but OOPishness would sure make the job easier.
Some parts of it.
>What I'm saying is: we're trying to play by someone else's rules;
>Euphoria is different, maybe we should try to come
>up with a fresh approach to enhancements as well.
You have some strong points Irv. We're all here because we did *not* like
the other languages. Why convert Euphoria to one of them.
>Thoughts?
Well, I've noticed we all, and I in particulary have been using the
constants for stuff it was not ment to be. Constants are variables that are
not allowed to change their value.
We're constantly using constants (eh...) in a way inappropiate for their
scope.
We either have to avoid the need to use them. Or change the way they work so
they *are* appropiate for their scope.
Still I think the only real enhancement Euphoria needs is a bit of macro
scipting.
Consider this statement from a developping team of MS (yeah, they have them
too):
A programming language is a tool to express an algoritmic idea, and therefor
any language forces us to either translate an algoritmic idea or to think in
that language, thereby restricting your view.
In other words, language grammer and ideology is context based on what the
programmer needs. Thus different object have a different grammer. A scaring,
but interesting idea.
I mean, Euphoria is the only language were you can model *any* data
structure.
Its one of the few languages were you can express any idea.
But are we really able to express any algoritmic idea in the context we want
?
Can we also express any way of expression. Be free to choose the method of
expression. Because that is the key to program order and usefullnes.
An GUI usually needs to work OO, but it has to talk functional because
Euphoria's expression-method is functional, only in such way we have the
freedom to simulate anything. In theory, OO also enables to simulate any
functional approach. Yet, this would seem much harder to use, and would
result in the most ugly programs ever.
A way of expression is simple for one task, but hard for another. Euphoria
seems to be a good compromize. A functional language were we actually dare
to simule an OO language. That alone tells something about Euphoria. On the
other hand, it also tells us Euphoria is not yet perfect, we just haven't
found the solution yet.
With different methods of expression I mean, that programming languages
should be a bit more liberal. Even, if we have ex.exe do stuff in an OO way,
we have to put it in an functional context for him. You have to explain OO
programming to him in comparisation/relation to functional programming.
Functional programming is much more critical for a good program than object
oriented is. Take a look at Java. Pure OO, my ass. It also has most of the
'functional' behaviour. Functional programming simply stands above OO. Only
OO is very complex from the functional point of view. It is because of
Euphoria's great syntax and efficient grammer that we could express OO
without the need of an preproccesor. I mean, it can also be done C. But it
would require much much and more complex code.
Still, the human brain comes up with algoritms that are sometimes quit hard
to explain in a functional- or oo-language. How come our brain *is* able to
overlook such ideas? And how come it does have grip on them? I could come up
with only one reason. People are able to put everything in relation to each
other, while all computer languages put everything in relation to either a
program flow, datatype or event. (respectively resulting in an functional
language, an OO language and an event-based language. I've left paralellism
out, I really don't know much about this way of expression.)
It is true, think about it. You can not explain any programming term used
without mentioning another term. That is what abstract means. Stuff that is
nothing on itself, but stands in relation to something else. That is why I
said, programming languages should become more liberal. A liberal
perspective means puttin things wihin their context. Because the facts are
simply different looking from somebody elses point of view. When seeing that
a certain idea is in relation to another idea, which is related to another
idea and eventually in relation to the original idea.
And then again, we are talking about context sensitive programming. Where
everything is in relation to each other. An expression is interpreted
differently within some context. And that is not just knowing that the
neighbour at place A is somebody different then the neibour at place B. I
mean context sensive, not only for which values to use, but also which
action to perform. Context sensitive programming, interpreting stuff the way
it was ment to be, and thus you can express yourself the way you want to.
Ralf Nieuwenhuijsen
nieuwen at xs4all.nl
PS Don't get scared if you didn't understand anything I said, it will be
because English is not my natural language and I really have a hard time
translating abstract ideas I have to *any* language. (including programming
languages... why don't they try to see it from my point of view.. i always
have to explain stuff from the programming's language point of view 
A
statement you will understand, if you understand what I said above.. )
PS Sorry for mail trashing, most people can just hit <del>, but for those
that use the digest this might be a disaster.. sorry 'bout that.
4. Re: A different proposal
Cameron Kaiser wrote:
>This is exactly what I would want: some sort of function that, given a =
general
>set of templates, could construct windows for you. Like X-Windows =
packers,
>for example. Just say
>
> msg =3D BuildBox("Prompt",
> "Please enter your name and address.",
> ... etc ...
> response =3D showbox(msg)
>
>etc.
That was one of the features that makes Tcl/Tk look attractive.
I intend to add packers to WinMan, mainly because it makes the code much =
more portable. In theory, you could add packers to Win32Lib, but WinMan =
is intended to be cross-platform, while Win32Lib is obviously not. I'm =
not sure how well the programs will port to a palmtop environment, =
though.
Coming from the PC world, I get a little nervous about widgets =
re-arranging themselves when the window is resized. Oh, well - I can =
always lock the size of the window frame to prevent resizing.
-- David Cuny
