1. A different proposal
- Posted by mountains at MINDSPRING.COM Jun 03, 1998
- 611 views
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
- Posted by Cameron Kaiser <spectre at WWW2.BUOY.COM> Jun 03, 1998
- 587 views
> 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
- 590 views
- 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
- Posted by David Cuny <dcuny at DSS.CA.GOV> Jun 03, 1998
- 590 views
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