1. RE: Coming real soon!
This is a multi-part message in MIME format.
------=_NextPart_000_00DD_01C111C6.2D531160
charset="iso-8859-1"
This discussion clearly shows the main shortcoming of the Euphoria =
system. The lack of consistency.
The fact that everybody (and his dog) can extend the language with lib's =
of their own may, at first=20
glance, seems an advantage, in reality it is a big minus!
And that's why Euphoria will never replace Basic or any other language =
for that matter!
Fritz Deneken
------=_NextPart_000_00DD_01C111C6.2D531160
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>This discussion clearly shows the main =
shortcoming=20
of the Euphoria system. The lack of consistency.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>The fact that everybody (and his dog) =
can extend=20
the language with lib's of their own may, at first </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>glance, seems an advantage, in reality =
it is a big=20
minus!</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>And that's why Euphoria will never =
replace Basic or=20
any other language for that matter!</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Fritz =
------=_NextPart_000_00DD_01C111C6.2D531160--
2. RE: Coming real soon!
On 21 Jul 2001, at 9:19, j.f.deneken at hccnet.nl wrote:
>
> This discussion clearly shows the main shortcoming of the Euphoria system. The
> lack of consistency. The fact that everybody (and his dog) can extend the
> language with lib's of their own may, at first glance, seems an advantage, in
> reality it is a big minus!
A lib is just a collection of procedures and functions, why are you making it
out to be part of the native code?
> And that's why Euphoria will never replace Basic or any other language for
> that
> matter!
It's already replaced Basic and Pascal and C and etc for some of us.
Kat
3. RE: Coming real soon!
j.f.deneken at hccnet.nl wrote:
> The fact that everybody (and his dog) can extend the language with lib's
> of their own may, at first
> glance, seems an advantage, in reality it is a big minus!
so basically you're saying no language is worth using? :P
> And that's why Euphoria will never replace Basic or any other language
> for that matter!
i'd pretty much say BASIC has already been replaced. the big problem
with Eu is it's interpreted and slow, but we've got the Euphoria to C
translator to fix that, even though the code is almost completely
intelligible
4. RE: Coming real soon!
Kat wrote:
> It's already replaced Basic and Pascal and C and etc for some of us.
sure, it can replace C but only if you don't want speed, don't plan on
getting a programming job or if you want to give up on writing an OS
5. RE: Coming real soon!
On 21 Jul 2001, at 20:45, sephiroth _ wrote:
<advertising snip>
> Kat wrote:
> > It's already replaced Basic and Pascal and C and etc for some of us.
>
> sure, it can replace C but only if you don't want speed, don't plan on
> getting a programming job or if you want to give up on writing an OS
Thing is, once you add in things like sequences, the C will slow to the speed
of Eu. I once tried to optimize a garbage collector, so it would run only if the
program was idle, problem was that checking to see if the program was idle
made the program run slower than the garbage collection at the rate i was
playing with the strings. I imagine Rob has had this problem in Eu too. I'll
use Rob's solution,, it works fine, and i can concentrate on getting code
written to reach my objective.
If i am not mistaken, you can use the translator to make a command.com,
and you'll have an OS, just build around interrupts rather than C-calls. Much
like writing timer interrupts, if you do it right you can prioritize interrupt
execution to any granularity, and set permission flags like *nix. Lets see
windoze do that.
Kat
6. RE: Coming real soon!
Kat wrote:
> If i am not mistaken, you can use the translator to make a command.com,
> and you'll have an OS, just build around interrupts rather than C-calls.
> Much
> like writing timer interrupts, if you do it right you can prioritize
> interrupt
> execution to any granularity, and set permission flags like *nix. Lets
> see
> windoze do that.
a shell is not to be mistaken for an operating system. sure, you could
write an alternative CLI for DOS, but that doesn't hide DOS itself. it's
still there, supporting your CLI. if you want to write a real OS, you
can't depend on interrupts to back you up. you have to code everything
yourself: basic drivers, file system(unless you use one that already
exists), kernel(unless you borrow or modify someone else's), etc. I'm
not sure if it would be possible with DOS or Windows, but as long as you
don't use any of the OS' standard C functions and just write your own,
it works at least with ELF(go to www.gaztek.org and download the GazOS
source. it's not the best OS, considering the "commands" are built right
into the kernel :)
7. RE: Coming real soon!
On 21 Jul 2001, at 21:29, sephiroth _ wrote:
>
> Kat wrote:
> > If i am not mistaken, you can use the translator to make a command.com,
> > and you'll have an OS, just build around interrupts rather than C-calls.
> > Much
> > like writing timer interrupts, if you do it right you can prioritize
> > interrupt
> > execution to any granularity, and set permission flags like *nix. Lets see
> > windoze do that.
>
> a shell is not to be mistaken for an operating system. sure, you could
> write an alternative CLI for DOS, but that doesn't hide DOS itself. it's
> still there, supporting your CLI. if you want to write a real OS, you
> can't depend on interrupts to back you up. you have to code everything
> yourself: basic drivers, file system(unless you use one that already
> exists), kernel(unless you borrow or modify someone else's), etc. I'm
> not sure if it would be possible with DOS or Windows, but as long as you
> don't use any of the OS' standard C functions and just write your own,
> it works at least with ELF(go to www.gaztek.org and download the GazOS
> source. it's not the best OS, considering the "commands" are built right
> into the kernel :)
Didn't someone write an easy way to drop machine code into memory in
Eu?? I mentioned the command.com first only because it would be nice to
be able to grab one interrupt at a time out from under dos until you get your
OS working, rather than start from scratch. I suppose i should have
elaborated more? No OS = no easy screen display routines, no useable
keybd, no decent harddrive, etc,, altho you could use the BIOS ints for some
access. The BIOS itself nowadays has a microOS so you can change the
bios itself. Seems to me, unless you have a emulator, it's simply easier to
start with something that already exists, and make it better. Several people
here on the list have the skills to write a new programming language (David
has written several), but we need to start somewhere. Starting with the first
byte the cpu wakes up at is doing things the hard way, imho, since you can
always grab it later when you are done with your new OS.
When i started hacking on the C64, i began with new commands, and next
thing you know, i had new commands to run code in the background using
the cpu on the floppy drive (descrete hardware multitasking), and the puter
itself was time-slice multitasking. If someone had not introduced me to some
hand-me-down ibm clones, i was planning on hypercubes of 6502s with the
C64 acting as the human interface. Yeas, i know the C64 used a 6510, but
the 65xx family has several better cpus in it. Btw, did you know the C64,
with an extra video chip, could run different programs on two separate
monitors at the same time? And with another card, could "read" NTSC (and
prolly PAL too) video feeds? Support for multiple sound chips was fun too!
So i know a little about OSs.
Kat
8. RE: Coming real soon!
Kat wrote:
> elaborated more? No OS = no easy screen display routines, no
No pain = no gain
What i'm trying to say is that if what you want is a genuine, 100%
on-dependent-on-anything-else-except-the-BIOS-if-you-want-it-to-be-slow,
OS, Euphoria isn't the language for the job
9. RE: Coming real soon!
On 22 Jul 2001, at 0:22, sephiroth _ wrote:
>
> Kat wrote:
> > elaborated more? No OS = no easy screen display routines, no
>
> No pain = no gain
> What i'm trying to say is that if what you want is a genuine, 100%
> on-dependent-on-anything-else-except-the-BIOS-if-you-want-it-to-be-slow,
> OS, Euphoria isn't the language for the job
<picture>a kat looking at Robert for the "official" opinion</pic>