1. Are You Guys Serious?

I have a really hard time believing that anybody could seriously support
some of the complaints I saw posted yesterday. I feel an iresistable
urge to comment on them.

"case sensitivity"

Euphoria does one thing that so many other langauges don't: it makes you
be a good programmer. Writing function and variable names in different
cases makes your program harder for others to read. This is bad: EU is
good.

"unnecessarily long words and redundant brackets"

Again, readability. So many people shrug off this issue as if it didn't
matter. The only people who think readability isn't an issue are A)
people who have never had to debug or alter somebody else's code, and B)
people who have never had to debug or edit their own code 3 months after
they write it. Short, illegible syntax is bad: EU is good.

"constants"

It boggles my mind that anybody could really consider constants to be a
bad thing. At this point I wonder if Jiri is just being silly.

"comma separator"

Maybe I have gone too far, because this is really going out on a limb.
Jiri: You are kidding, right?

"curly brackets"

This improves readability. The concept of a sequence it totally foreign
to anything except Euphoria, it needs its own syntax.

"types, type checking"

I'm going mad! Please, somebody that knows Jiri, tell me he is just
kidding!

"variable declaration"

I can't go on. Nobody can question the wisdom of undeclared variable
errors. RDS has come so close to creating the perfect programming
language... this must be a joke.

"error handling"

The idea that a program shouldn't halt when the code tries to access an
non-existing object it insane. This must be a joke. To save face I'll
throw my hat into the ring...

MY BIGGEST PET PEEVE ABOUT EUPHORIA IS . . .

Memory Management. I long for the days of C when I could adress memory
however I wanted, wherever I wanted. That crummy Causeway DOS Extender
is alway ruining my fun when I try to poke some bytes in some random
spot of memory. BOO! HISS!

John.

new topic     » topic index » view message » categorize

2. Re: Are You Guys Serious?

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BDDC53.1D24F700
        charset="iso-8859-1"

John DeHope subtly wrote:

>> "unnecessarily long words and redundant brackets"
>
> ... Short, illegible syntax is bad: EU is good.

Yet you chose to write 'EU' instead of 'Euphoria'.


>> "comma separator"
>
> Maybe I have gone too far, because this is really going out
> on a limb.

There are no compelling reasons for commas in sequences. The parser
certainly doesn't require them.


>> "types, type checking"
>
> I'm going mad! Please, somebody that knows Jiri, tell me he is
> just kidding!

Why is this kidding? I've yet to define my own data type. The main reason
for types seems to be to allow the compiler to optimize an expression. Since
when is doing the work of a compiler considered a good thing?


>>"error handling"
>
> The idea that a program shouldn't halt when the code tries to access
> an non-existing object is insane. This must be a joke.

Why is this insane? Euphoria could issue a visual warning, such as a message
box with the contents:

        Warning: Boundary Error!
        Abort or Ignore?

If you choose to ignore it, Euphoria would attempt to recover from the
error, taking different actions depending on what the error was.

If the interpreter can recognize an instruction as (1) bad, and (2) as
*potentially* correctable, why is better to crash and lose all the data than
to attempt to recover?

Consider this scenario: it's 3:00 in the morning, and John Composer is using
a Euphoria program to write a string quartet. He's just finished an
especially tricky counterpoint that he's spent the last couple of hours on.

But the program's logic is about to make the *fatal* error of positioning a
bitmap graphic a bit too far to the left of the screen. This causes
get_image to choke, the Euphoria shut the program down.

I'm sure that John wouldn't be unhappy about losing hours of unrecoverable
work. After all, he's got the immense satisfaction of knowing that Euphoria
was prevented from possibly making an error, as well as a dump from EX.ERR.

Uh, huh.

And foolish of me not to write a program that makes a backup every five
minutes...

Under my scenario, instead of crashing, a message box pops up:

        Warning: Boundary Error!
        Abort or Ignore?

John Composer decides that the risks of choosing 'Ignore' far outweigh those
associated with 'Abort' (losing all his work), and selects 'Ignore'.
Fortunately for John, the program is able to continue happily along.

Given the options:

        1. Crash and burn.
        2. Attempt to recover.

I'm "insane" to opt for the second?

-- David Cuny

------_=_NextPart_001_01BDDC53.1D24F700
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>RE: Are You Guys Serious?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>John DeHope subtly wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&gt; &quot;unnecessarily long words and redundant =
brackets&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; ... Short, illegible syntax is bad: EU is =
good.</FONT>
</P>

<P><FONT SIZE=3D2>Yet you chose to write 'EU' instead of =
'Euphoria'.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;&gt; &quot;comma separator&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Maybe I have gone too far, because this is =
really going out </FONT>
<BR><FONT SIZE=3D2>&gt; on a limb.</FONT>
</P>

<P><FONT SIZE=3D2>There are no compelling reasons for commas in =
sequences. The parser certainly doesn't require them.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;&gt; &quot;types, type checking&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; I'm going mad! Please, somebody that knows =
Jiri, tell me he is </FONT>
<BR><FONT SIZE=3D2>&gt; just kidding!</FONT>
</P>

<P><FONT SIZE=3D2>Why is this kidding? I've yet to define my own data =
type. The main reason for types seems to be to allow the compiler to =
optimize an expression. Since when is doing the work of a compiler =
considered a good thing?</FONT></P>
<BR>

<P><FONT SIZE=3D2>&gt;&gt;&quot;error handling&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; The idea that a program shouldn't halt when the =
code tries to access </FONT>
<BR><FONT SIZE=3D2>&gt; an non-existing object is insane. This must be =
a joke.</FONT>
</P>

<P><FONT SIZE=3D2>Why is this insane? Euphoria could issue a visual =
warning, such as a message box with the contents:</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>Warning: =
Boundary Error!</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>Abort or =
Ignore?</FONT>
</P>

<P><FONT SIZE=3D2>If you choose to ignore it, Euphoria would attempt to =
recover from the error, taking different actions depending on what the =
error was.</FONT></P>

<P><FONT SIZE=3D2>If the interpreter can recognize an instruction as =
(1) bad, and (2) as *potentially* correctable, why is better to crash =
and lose all the data than to attempt to recover?</FONT></P>

<P><FONT SIZE=3D2>Consider this scenario: it's 3:00 in the morning, and =
John Composer is using a Euphoria program to write a string quartet. =
He's just finished an especially tricky counterpoint that he's spent =
the last couple of hours on.</FONT></P>

<P><FONT SIZE=3D2>But the program's logic is about to make the *fatal* =
error of positioning a bitmap graphic a bit too far to the left of the =
screen. This causes get_image to choke, the Euphoria shut the program =
down.</FONT></P>

<P><FONT SIZE=3D2>I'm sure that John wouldn't be unhappy about losing =
hours of unrecoverable work. After all, he's got the immense =
satisfaction of knowing that Euphoria was prevented from possibly =
making an error, as well as a dump from EX.ERR.</FONT></P>

<P><FONT SIZE=3D2>Uh, huh.</FONT>
</P>

<P><FONT SIZE=3D2>And foolish of me not to write a program that makes a =
backup every five minutes...</FONT>
</P>

<P><FONT SIZE=3D2>Under my scenario, instead of crashing, a message box =
pops up:</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>Warning: =
Boundary Error!</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>Abort or =
Ignore?</FONT>
</P>

<P><FONT SIZE=3D2>John Composer decides that the risks of choosing =
'Ignore' far outweigh those associated with 'Abort' (losing all his =
work), and selects 'Ignore'. Fortunately for John, the program is able =
to continue happily along.</FONT></P>

<P><FONT SIZE=3D2>Given the options:</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>1. Crash =
and burn.</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>2. =
Attempt to recover.</FONT>
</P>

<P><FONT SIZE=3D2>I'm &quot;insane&quot; to opt for the second?</FONT>
</P>

<P><FONT SIZE=3D2>-- David Cuny</FONT>
</P>

</HTML>
------_=_NextPart_001_01BDDC53.1D24F700--

new topic     » goto parent     » topic index » view message » categorize

3. Re: Are You Guys Serious?

>> "unnecessarily long words and redundant brackets"
    >
    > ... Short, illegible syntax is bad: EU is good.

    [David]>Yet you chose to write 'EU' instead of 'Euphoria'.


    Why not allow a 2-way: proc works, but so does procedure.
    func works, but so does function. I must admit, its annoying that half
of the routines I write, have an argument to many and dont fit on the 80
width line (78 in ee.ex)

    >> "comma separator"
    >
    > Maybe I have gone too far, because this is really going out
    > on a limb.

    [David]> There are no compelling reasons for commas in sequences. The
parser
certainly doesn't require them.


    atom d
    constant a = 5 b = "hallo" c = my_func () d = 23.2

    -- No compelling reason ? After the first constant declaration any
assignment to an unknown variable type is seen as a new constant:

    atom d
    constant a=5, b = "hallo", c = my_func ()        -- No comma here: end
of constant list
    d = 32.2

    >> "types, type checking"
    >
    > I'm going mad! Please, somebody that knows Jiri, tell me he is
    > just kidding!

    [David]>Why is this kidding? I've yet to define my own data type. The
main
reason for types seems to be to allow the compiler to optimize an
expression. Since when is doing the work of a compiler considered a good
thing?

    Ive often made my own data type. Reason: safety
    Its not just helping the compiler, it makes your code much more readable
for others. They understand the use, scope and order of variables.

    >>"error handling"
    >
    > The idea that a program shouldn't halt when the code tries to access
    > an non-existing object is insane. This must be a joke.

    [David] Why is this insane? Euphoria could issue a visual warning, such
as a
message box with the contents:

    I must admit, we should at least be able to specify an quit () routine,
called just before the program is closed by an abort () (maybe some library
jumps out) or just before the program is stopped due to a crash.
    I know how mad it made me to loose a bunch of code when David's blink
editor crashed when I tabbed a bit too much in the Save As dialog.

    But on all other points, I kind of disagree, David, as Jiri had
predicted.

Ralf N.
nieuwen at xs4all.nl

new topic     » goto parent     » topic index » view message » categorize

4. Re: Are You Guys Serious?

Hi John:
Yes, without getting into all the specifics and needlessly offending anyone,
I will just say that, as a novice, beginning programmer,  I *generally*
agree with your suggestion that readability ought to remain one of the goals
of a programmer--both for editing/debugging someone else's code, as well as
for one's own some months or years later.  The concept is very similar to
writing comments along with one's code.  Strictly speaking, comments are
totally unnecessary for the proper running of a code, but I don't know any
good, proper and meticulous programmer who doesn't comment the code.
Regards to all,
Frank

John DeHope wrote:

> I have a really hard time believing that anybody could seriously support
> some of the complaints I saw posted yesterday. I feel an iresistable
> urge to comment on them.
>
> "case sensitivity"
>
> Euphoria does one thing that so many other langauges don't: it makes you
> be a good programmer. Writing function and variable names in different
> cases makes your program harder for others to read. This is bad: EU is
> good.
>
> "unnecessarily long words and redundant brackets"
>
> Again, readability. So many people shrug off this issue as if it didn't
> matter. The only people who think readability isn't an issue are A)
> people who have never had to debug or alter somebody else's code, and B)
> people who have never had to debug or edit their own code 3 months after
> they write it. Short, illegible syntax is bad: EU is good.
>
> "constants"
>
> It boggles my mind that anybody could really consider constants to be a
> bad thing. At this point I wonder if Jiri is just being silly.
>
> "comma separator"
>
> Maybe I have gone too far, because this is really going out on a limb.
> Jiri: You are kidding, right?
>
> "curly brackets"
>
> This improves readability. The concept of a sequence it totally foreign
> to anything except Euphoria, it needs its own syntax.
>
> "types, type checking"
>
> I'm going mad! Please, somebody that knows Jiri, tell me he is just
> kidding!
>
> "variable declaration"
>
> I can't go on. Nobody can question the wisdom of undeclared variable
> errors. RDS has come so close to creating the perfect programming
> language... this must be a joke.
>
> "error handling"
>
> The idea that a program shouldn't halt when the code tries to access an
> non-existing object it insane. This must be a joke. To save face I'll
> throw my hat into the ring...
>
> MY BIGGEST PET PEEVE ABOUT EUPHORIA IS . . .
>
> Memory Management. I long for the days of C when I could adress memory
> however I wanted, wherever I wanted. That crummy Causeway DOS Extender
> is alway ruining my fun when I try to poke some bytes in some random
> spot of memory. BOO! HISS!
>
> John.

new topic     » goto parent     » topic index » view message » categorize

5. Re: Are You Guys Serious?

I am not sure exactly what was meant by the comments regarding..
 > "comma separator" in sequences. Did someone mean that instead of:

sequence test
test="12, 34, 56, 67+89"

 we could have..

sequence test
test="12  34  56  67+89"

well, what happens with

sequence test
test="12  34  56  67 +89" --oops


Yours Truly
Michael Palffy

michael at igrin.co.nz

new topic     » goto parent     » topic index » view message » categorize

6. Re: Are You Guys Serious?

> Cuny, David wrote:
> >> "types, type checking"
> >
> > I'm going mad! Please, somebody that knows Jiri, tell me he is
> > just kidding!
>
> Why is this kidding? I've yet to define my own data type. The main
> reason for types seems to be to allow the compiler to optimize an
> expression. Since when is doing the work of a compiler considered a
> good thing?

I've been *really* hesitant about joining this thread...
for this one I gotta...
I hate to bring this up, but unless you define every expression,
be it numeric or string in nature, as an object, not as an integer,
or sequence or even constant...
unless you use 'object foo, bar...etc' for every single value
that you want the interpreter to remember, well, your doing
the work of the compiler, in your words. You are using
'type'.  I have seen your code dave, and this isn't a personal
attack either, but you mentioned that you have yet to define
your own data type when in reality, and in effect, you have.
Ever use integer? I've seen you use integer.  When you did
that, you 'created' your 'own data type' for that particular
value you wanted to have the interpreter remember, and helped
the interpreter optimize an expression and evaluation thereof.

Doing some of the interpreters work *is* a good thing. We all
do it at one point or another.  Programs are things we create,
for computers to execute, with users getting the benefit of
the output created.  Users like things to run smoothly, unless
they are masochists (or wierder?).  If we as programmers can
help along the program so that the computer can execute it
in a more efficient and stable manner, the user gets more
benefits from the enhanced output created due to our assisting
the interpreter.  No one has unlimited ram, and this is why we
choose integer when we can.  No one has unlimited time, and
this is why we try to choose sequence over object when we can.
The moment you do that, you are creating data types.
*shrug*

--take care all
--Hawke'

new topic     » goto parent     » topic index » view message » categorize

7. Re: Are You Guys Serious?

>>> "comma separator"
>>
>> Maybe I have gone too far, because this is really going out
>> on a limb.
>
>There are no compelling reasons for commas in sequences. The parser
>certainly doesn't require them.

This was pointed out already, but I'll just clarify... Just to be sure
there aren't any counter-arguments... blink

sequence s


s = {10 43 38 +30 32 -1}

What would the parser see this as?

s = {10, 43, 38, +30, 32, -1}

But maybe that's not wanted. Maybe I wanted:

s = {10, 43, 38 + 30, 32 - 1}

Or it could be

s = {10, 43, 38+30, 32, -1}

Remember, Euphoria doesn't care about white space, for the most part, so
we don't want to force white space rules inside of sequences. (ie trying
to say that I should have 38+30 close together if I wanted them to add
themselves together.)

As for that most part exception (I know SOMEBODY would point me out wrong
if I didn't do this... See? I'm getting paranoid thanks to you guys! blink


The only rule about whitespace is that between letter and numbers, it's
needed, but between symbols and letters/numbers/more symbols, it's not
needed. (Which makes a lot of sense.)


_____________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]

new topic     » goto parent     » topic index » view message » categorize

8. Re: Are You Guys Serious?

Hawke observed:

> I have seen your code dave, and this isn't a personal
>attack either ...

No personal attack taken, Hawke, because none were issued. My complaint
about 'personal attacks' was based on the adjectives that were being used
about the suggestions ("This is going out on a limb", "This is just silly",
"This must be a joke", etc.).

> but you mentioned that you have yet to define
>your own data type when in reality, and in effect, you have.
>Ever use integer? I've seen you use integer.  When you did
>that, you 'created' your 'own data type' for that particular
>value you wanted to have the interpreter remember...

Using 'integer' is using a built-in data type, not 'my own data type'. By
'my own data type', I refer to the ability in Euphoria to define new types
using the 'type' keyword.

> ... and helped
>the interpreter optimize an expression and evaluation thereof.

I agree. More than just using types in argument lists, you will see stuff
like this in my code:

    procedure drawLine( integer color, sequence point1, sequence point2 )

        integer x1, y1, x2, y2

        x1 = point1[X1]
        y1 = point1[Y1]
        x2 = point2[X1]
        y2 = point2[Y2]

        -- etc...

    end procedure

I make these assignments because I know my code will be *faster* if I make
repeated references to 'x1' than point1[X1]. I don't do it for readability.
In essence, I'm doing the compiler's work for it.

How do I know these optimizations will be faster? Only because Robert has
said so. It would be nicer if I didn't have to spoon-feed the interpreter
like this, but it's a concession I'm willing to make for the increase in
speed.

>Doing some of the interpreters work *is* a good thing. We all
>do it at one point or another.

I don't argue that optimizing code isn't a good thing. As you point out, I
use native types to do it all the time.

But it would be nicer if we didn't have to concern ourselves with
implementation details. It's a hardware-dependant kind of thing - on a cpu
where floating math is as fast as integer math, I wouldn't have to make such
optimizations.

With each new generation of languages taking care of details, we are moving
further and further away from the hardware. We're only drawn back (kicking
and screaming) to make optimizations when the compiler is unable to do the
work for us.

-- David Cuny

new topic     » goto parent     » topic index » view message » categorize

9. Re: Are You Guys Serious?

Robert pointed out:

>s = {10 43 38 +30 32 -1}

is ambigious.

D'oh!

Of course, you could write it as:

>s = {10 43 (38+30) (32 -1) }

and do without the commas.

But you are correct, I was wrong - commas *do* have syntactic value.

-- David Cuny

new topic     » goto parent     » topic index » view message » categorize

10. Re: Are You Guys Serious?

David Cuny wrote:
> D'oh!
you just GOTTA love that word :)

> But you are correct, I was wrong - commas *do* have syntactic value.
actually, you were correct in the first place, and almost
wrong now. heh.
commas *currently* have syntactic value, but you were
right in saying that they aren't needed by the parser,
and as such, euphoria *doesn't* need them.
your example
s = {10 43 (38+30) (32 -1) }
is a valid and viable alternative.
might even be clearer, more elegant, and more efficient
to code with (potentially less typos) and even execute
(the parsers' overhead is reduced as it doesn't have
to parse all those commas, and can instead rely on
generic whitespace routines whilst simply looking for
the '}' to end/delimit sequences).
i'm assuming that (32 -1) would indeed be interpreted
as 31 since it's within the ()'s.
--l8tr Hawke'

new topic     » goto parent     » topic index » view message » categorize

11. Re: Are You Guys Serious?

David Cuny wrote:
> Hawke observed:
> > but you mentioned that you have yet to define
> >your own data type when in reality, and in effect, you have.
> >Ever use integer? I've seen you use integer.  When you did
> >that, you 'created' your 'own data type' for that particular
> >value you wanted to have the interpreter remember...
>
>Using 'integer' is using a built-in data type, not
>'my own data type'. By 'my own data type', I refer to
>the ability in Euphoria to define new types
>using the 'type' keyword.
ummm i need to try this again.
I understand what you meant, but my meaning got lost.
I understand that you were referring to EU built-in
'type' keyword... I wasn't.  I was attempting to note,
that unless you use 'object foobar' and you instead
use 'sequence foobar' or 'integer foobar', that you
*indeed* are using 'type'(not the keyword, the principle)
As soon as something is not generic, it is specific.
You were stipulating that you never needed 'type',
and I am saying that maybe true, but you cannot get
away with never needing to 'type' a variable.  You
saying you never needed your own data type is in
effect, not quite true.
Builtin or not, type is type, and the argument
centered on *never* *ever* needing to type a variable.
I cannot see that you actually adhere to that genre
of programming style, whether using builtin or not.

as far as the keyword 'type' is concerned...
heh... if you noted my other post asking about
byte LittleNumber, well, if LittleNumber *aint*
a 'true byte' then IM!(HO) ;)  'type' is a keyword
only usefull to debugging.  if it does make
LittleNumber a true byte, then euphoria actually
met it's goal of being a "functional, strongly-typed,
FAST interpreted language, suitable for Rapid Development
programming." (or some such propaganda) and that
keyword becomes simplistically powerfull.

enjoy--Hawke'

new topic     » goto parent     » topic index » view message » categorize

12. Re: Are You Guys Serious?

Mike offered my "sequences don't need commas" this:

>sequence test
>test="12, 34, 56, 67+89"

Perhaps you meant:

    test = { 12, 34, 56, 67+89 }

>test="12  34  56  67 +89" --oops

    test = { 12 34 56 67 +89 }

As noted, this is perhaps ambigious (to the reader). But the parser would
read it as:

    test = { 12 34 56 (67+89) }

since addition has higher precedence than a unary plus.

But remain corrected, in that I pretty much claimed that commas were
*entirely* useless.

Thanks for the feedback.

-- David Cuny

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu