1. Re[2]: Unicode support in Eu 3.0 + rants
- Posted by akusaya at gmx.net
Jun 28, 2006
> Oooh, can I have a million dollars please, because I use a lot of those a lot.
> Generally I agree, euphoria should evolve, but I think losing those commands
> would be a big mistake.
> If you don't wish to use them,don't, I suspect that for modern
> machines there is little overhead in keeping them, but I also
> suspect for older machines, that use dos, their loss would be sorely noted.
> Loss of, for instance, the position command, would mean on Linux
> console programs, a loss of functionality at the most fundamental
> level. Binding the ncurses library would be a necesity.
What I was thinking is remove them from stdlib or builtin routines,
not completely remove it. So my suggestion is to move those routines
outside the standard distribution of Eu, and leave it as a community
project.
That way, RDS can concentrate more on developing modern techniques
(threads, unicode, network, etc) rather than finding position() bugs,
making text_color() compatible on various machines, etc.
> UTF-8 and 16 would be most welcome in Linux.
Yes, I agree. And on Windows, of course. It's a disappointment that
ability to store characters as 31-bit value is not used for unicode
handling.
> No, IMHO, the way forward for Euphoria is not to remove
> functionality, but to add to it in the form of extendable modules,
> even making a simple way to add C++ library interfaces (if anyone
> can do that now, SIMPLY, then let me know) (Matt, your libs are
> anything BUT simple, and way way way over my head!)
The reason of outdated functionality is to make Rob develop faster. If
RDS were a company of several people working, no problem with keeping
old routines. But . . .
2. Re[2]: Unicode support in Eu 3.0 + rants
- Posted by akusaya at gmx.net
Jun 28, 2006
>> Do you think routines to set color palette are more important than
>> routines to, for example, manipulate XML files? In 1999 maybe the
>> answer is "yes", but in 2006?
>>
>> Do you think routines to change console text color are more important
>> than routines to, for example, create network connections/sockets? In
>> 1999 maybe the answer is "yes", but in 2006?
>>
>> I think Euphoria needs to evolve.
> Why remove them? They're not doing ay harm. Also, I don't know of
> any well-known languages that have builtin support for XML and not
> that many have builtin support for network sockets. Plus, we have
> libraries for both those things already just like the other languages.
Yes, it's no harm except:
1. polluting namespace (such as pixel(), position() are a very common
name :()
2. slowing programs a little bit since more name lookups are performed
or bigger symbol hash table
3. slowing other parts of development!
(I hope 'slowing' is a word, I mean 'making it slower')
PHP has built in XML and network sockets.
Java has built in XML and very sophisticated network sockets libraries.
OK, XML is not really necessary, but sockets are important, right?
There are libraries for that but most of them are buggy (really! I
have tried most of them!)
3. Re: Re[2]: Unicode support in Eu 3.0 + rants
- Posted by Bill Reed <rpfproeu at netscape.net>
Jun 28, 2006
-
Last edited Jun 29, 2006
akusaya wrote:
>
> > Oooh, can I have a million dollars please, because I use a lot of those a
> > lot.
>
> > Generally I agree, euphoria should evolve, but I think losing those commands
> would be a big mistake.</font></i>
>
> > If you don't wish to use them,don't, I suspect that for modern
> > machines there is little overhead in keeping them, but I also
> > suspect for older machines, that use dos, their loss would be sorely noted.
>
> > Loss of, for instance, the position command, would mean on Linux
> > console programs, a loss of functionality at the most fundamental
> > level. Binding the ncurses library would be a necesity.
>
> What I was thinking is remove them from stdlib or builtin routines,
> not completely remove it. So my suggestion is to move those routines
> outside the standard distribution of Eu, and leave it as a community
> project.
>
> That way, RDS can concentrate more on developing modern techniques
> (threads, unicode, network, etc) rather than finding position() bugs,
> making text_color() compatible on various machines, etc.
>
>
> > UTF-8 and 16 would be most welcome in Linux.
>
> Yes, I agree. And on Windows, of course. It's a disappointment that
> ability to store characters as 31-bit value is not used for unicode
> handling.
>
> > No, IMHO, the way forward for Euphoria is not to remove
> > functionality, but to add to it in the form of extendable modules,
> > even making a simple way to add C++ library interfaces (if anyone
> > can do that now, SIMPLY, then let me know) (Matt, your libs are
> > anything BUT simple, and way way way over my head!)
>
> The reason of outdated functionality is to make Rob develop faster. If
> RDS were a company of several people working, no problem with keeping
> old routines. But . . .
>
>
Ok, if you're going to pick and choose which of the "old" DOS commands
you're going to keep or get rid of, I want to put in my $.02 for keeping:
get_mouse, mouse_events, clear_screen, position, get_position,
graphics_mode, scroll, text_color, bk_color, sound, cursor,
text_rows, get_screen_char, put_screen_char, save_text_image,
display_text_image, save_screen,
I use these on a fairly regular basis, and it would cramp my coding BIG TIME
if I couldn't use these commands. I am one of the so called "dinosaur"
programmers that still use DOS. I don't see the advantages of using EXW
for my programs. I go for substance, not style. I like to have a program
that works, not just because it "looks good", and has lots of nifty buttons
and drop-downs and radio buttons and scroll bars on it.
Have you ever noticed some grocery store checkouts where you can see your
grocery items on the screen as it is scanned? That is a DOS screen, and
I haven't seen any "windows" screens there. DOS programs are still around
quite a bit.
Bill Reed
4. Re: Re[2]: Unicode support in Eu 3.0 + rants
- Posted by ChrisBurch2 <crylex at freeuk.co.uk>
Jun 28, 2006
-
Last edited Jun 29, 2006
Bill Reed wrote:
>
> Have you ever noticed some grocery store checkouts where you can see your
> grocery items on the screen as it is scanned? That is a DOS screen, and
> I haven't seen any "windows" screens there. DOS programs are still around
> quite a bit.
>
> Bill Reed
I was going to put that! Then I realised that a lot of them also are proprietary
graphic screens. Which look like they running on dos / unix consoles. There's
even some running on what looks like win95 (osr1 of course!)
Heh, yes, just keep them, how much difference will it make?
Chris
