Re: Changes to Euphoria

new topic     » goto parent     » topic index » view thread      » older message » newer message

Jeremy Cowgar wrote:
> 
> Jason Gade wrote:
> > 
> > 
> > It's not like I'm against /every/ feature, I'm trying to make that clear.
> > And
> > I'm not so much in the "bloating the interpreter" camp or in the "slowing
> > down
> > the interpreter" camp because these days it just doesn't really matter that
> > much. Clear code is far more important.
> > 
> 
> I am in the do not slow down the interpreter camp and the clear code camp. I
> do not care too much if the executable grows a bit.

Which is why I like you smile !

> 
> > Maybe it's just pie-in-the-sky idealism, but for me it has more to do with
> > the
> > overall look and feel of the language, which features /should/ be included
> > because
> > they fit the philosophy of the language and which are just the syntactic
> > sugar
> > flavor-of-the-week.
> > 
> 
> I am not against syntactic sugar as a lot of times the syntactic sugar is
> nice.
> Many people consider the for loop syntactic sugar:
> 
> }}}
<eucode>
> for a = 1 to length(lines) do
>    --body
> end for
> </eucode>
{{{

> 
> That's simply sugar for:
> 
> }}}
<eucode>
> integer a
> a = 1
> while a < length(lines) do
>     -- body
>     a = a + 1
> end while
> </eucode>
{{{

> 
> What I am for is not to reduce 2 character here or there, but sugar above is
> great stuff. It means I (the programmer) have to work less to achieve the same
> goal. That's my end desire. Am I lazy? I guess one could say that, but if you
> have a ditch to dig will you choose a spoon, a shovel or back hoe?
> 
> Now, I am also in the camp that says let's try to have one way of doing
> things.
> I say try because, you could use a for or while loop to accomplish the same
> thing, but each has their own benefit. They are not duplicating functionality.
> I have used languages that have added every little new buzz word out there and
> they are so complex it's no fun to program in. After all, I do like my
> programming
> job, why? I think it's fun.

Right, and the "one way" and the "sugar" or "tool in the toolbox" (to borrow
another phrase) sometimes conflict. I understand that. Which is why I'm trying to
make clear that I don't want to obstruct things just for the sake of being
obstructionist.

> 
> > I think there should be a compelling reason to add anything --feature or new
> > built-in-- to the interpreter, and a broad consensus as well. Not just
> > "because
> > it's cool."
> >
> 
> Again, can you please tell me what has been added to the interpreter "because
> it's cool" ? In your opinion, I am not asking for fact, simply your opinion.

"retry" is the one that comes to mind mostly, for arguments that I've already
given, and I've also already conceded on it.

Other things which have only been proposed here, and like yesterday, I realize
that it's just discussion at this point though sometimes, like yesterday, it
still feels like being steam rolled, like some things will be included no matter
what anybody thinks.

nested routines felt like that yesterday, just other vague feelings.

>  
> > Same rant, different day I guess.
>  
> > Heh, for true minimalism and performance I guess I can always just stick
> > with
> > C.
> >
> 
> Hm, C has goto, right grin (added for goto fans, sorry, could not resist)

Yes, C has goto. Nothing wrong with that.

I was once going to port Rogue from C to Euphoria (just because) and I reached a
piece of code that does something like the proposed "entry" keyword. Since C
doesn't have "entry", it used a goto. It took awhile for me to figure out how to
do that properly in Euphoria and I eventually had to ask here in the list.

Of course, someone gave me the obvious and elegant solution using an "if"
statement.

Pity I never finished that project...

> > But allow me to make a comparison -- in some ways, going from C (a beautiful
> > language, IMO, missing some features) to C++ (not so beautiful, lots of
> > little-used
> > features) introduced a lot of power and expressiveness at the expense of a
> > lot
> > of clunkiness and ugliness. And some missing features remain missing, or at
> > least non standard. I'd like to avoid that here.
> > 
> 
> Hm, I hardly think C to C++ is a valid comparison of Eu 3.1 to Eu 4.0.
> 
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>

Right, again to be more clear -- my rants are less about 4.0 specifically (even
though it still seems like features are being piled on) but the future of the
language in general, beyond 4.0.

As I've said both here and in the developer's list, I'm pretty much on board
with the 4.0 roadmap that you have spelled out.

--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.

"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare

j.

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu