1. Nested routines
What is the utility of nested routines? What problems do they solve that can't
be solved by refactoring and simplification?
--
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.
2. Re: Nested routines
Jason Gade wrote:
>
> What is the utility of nested routines? What problems do they solve that can't
> be solved by refactoring and simplification?
>
Have you ever had to repeat a task over and over in a function that takes
multiple local paramters and is only used within that one function? Why make a
top-level function putting it at least into the file scope, deal with passing all
the parameters to the function and getting the result when one could create a
nested routine?
Take a peek at: http://en.wikipedia.org/wiki/Nested_function for a little more
info.
--
Jeremy Cowgar
http://jeremy.cowgar.com
3. Re: Nested routines
Jason Gade wrote:
>
> What is the utility of nested routines? What problems do they solve that can't
> be solved by refactoring and simplification?
>
> --
> 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.
Sharing of private data and simple splitting of otherwise large routines.
Instead of passing arguments (whih has a cost) between 3,4, 5 routines, use
variables common to all the involved routines, and hide these symbols even from
the rest of the file.
This also makes code more maintainable, as the scope of more variables is being
restricted in a visible way.
Perforance call: call_func/call_proc have to check that a dynamic call o a
nested routine is valid. Not much, and not often at all. It's not even a loss, as
non nested routine calls are not affected (apart from a "if (symtab[s].u->parent
!= toplevel) test in backend.
CChris
4. Re: Nested routines
Jeremy Cowgar wrote:
>
> Jason Gade wrote:
> >
> > What is the utility of nested routines? What problems do they solve that
> > can't
> > be solved by refactoring and simplification?
> >
>
> Have you ever had to repeat a task over and over in a function that takes
> multiple
> local paramters and is only used within that one function?
Not that I can recall. I'd probably just make a separate function.
> Why make a top-level
> function putting it at least into the file scope, deal with passing all the
> parameters to the function and getting the result when one could create a
> nested
> routine?
Again, I don't see the utility of nesting it vice putting it at the file scope.
If your file is so large that putting the function in file scope would cause a
name clash then maybe your file needs to be split up better.
>
> Take a peek at: <a
> href="http://en.wikipedia.org/wiki/Nested_function">http://en.wikipedia.org/wiki/Nested_function</a>
> for a little
> more info.
>
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
Right, I know what they are even though I've never used them. I just don't see
any use for them.
--
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.
5. Re: Nested routines
Jason Gade wrote:
>
> > Have you ever had to repeat a task over and over in a function that takes
> > multiple
> > local paramters and is only used within that one function?
>
> Not that I can recall. I'd probably just make a separate function.
>
Have you ever used a language that supports nested routines? I suspect that it's
much like the for-in loop. Sure, you can program with out it, but once you use
it, you'll miss it.
One could ask, what can be done with a for-in loop that couldn't be done w/a
simple for loop? The answer is easy... nothing! But why use a for loop if you
have access to a for-in loop and your iterating a sequence?
Nested routines is the same thing.
--
Jeremy Cowgar
http://jeremy.cowgar.com
6. Re: Nested routines
Jason Gade wrote:
>
> What is the utility of nested routines? What problems do they solve that can't
> be solved by refactoring and simplification?
You have hit the nail firmly on the head. It's a marketing ploy... "Look at
the cool (and useless) stuff we have!"
7. Re: Nested routines
ken mortenson wrote:
>
> You have hit the nail firmly on the head. It's a marketing ploy... "Look at
> the cool (and useless) stuff we have!"
>
How many lines of code have you written Ken?
--
Jeremy Cowgar
http://jeremy.cowgar.com
8. Re: Nested routines
Jeremy Cowgar wrote:
>
> Jason Gade wrote:
> >
> > What is the utility of nested routines? What problems do they solve that
> > can't
> > be solved by refactoring and simplification?
> >
>
> Have you ever had to repeat a task over and over in a function that takes
> multiple
> local paramters and is only used within that one function?
All the time.
> Why make a top-level function putting it at least into the file scope,
Because it makes your current function cleaner and easier to maintain.
> deal with passing all the parameters to the function
Which is another advantage. Thinking of variable as semi-public within
a function is a baaaaad idea.
> and getting the result when one could create a nested routine?
And another advantage. Those results are part of the unit test procedure.
divide and conquer folks. It's the human thing to do.
Short answer. It reduces the mental strain on the humble programmer.
9. Re: Nested routines
Jeremy Cowgar wrote:
> Have you ever used a language that supports nested routines? I suspect that
> it's much like the for-in loop. Sure, you can program with out it, but once
> you use it, you'll miss it.
>
> One could ask, what can be done with a for-in loop that couldn't be done w/a
> simple for loop? The answer is easy... nothing! But why use a for loop if you
> have access to a for-in loop and your iterating a sequence?
Two questions. Same answer. Because less is more!!!!!!!!!!!!!!
Imagine how effecient and less complicated your compiler becomes when you
remove all the unneccessary bells and whistles and just leave the pure and
clean, unadulterated core. Bells and whistles are for libraries (which are
optional in a project) while the core should be a finely crafted tool. It's
one of the main things that attracted me to the language in the first place.
10. Re: Nested routines
ken mortenson wrote:
>
> Two questions. Same answer. Because less is more!!!!!!!!!!!!!!
>
I agree! Less code I type the better.
> Imagine how effecient and less complicated your compiler becomes when you
> remove all the unneccessary bells and whistles and just leave the pure and
> clean, unadulterated core. Bells and whistles are for libraries (which are
> optional in a project) while the core should be a finely crafted tool. It's
> one of the main things that attracted me to the language in the first place.
Imagine how efficient and less complicated your code will be (which you have to
maintain, not the compiler) if the compiler does it's job and provides the common
constructs/functionality necessary for me to do my job (programming) easily!
That's what I look for. If I wanted a bare minimum compiler I'd go with
whitespace or something.
--
Jeremy Cowgar
http://jeremy.cowgar.com
11. Re: Nested routines
Jeremy Cowgar wrote:
> How many lines of code have you written Ken?
You do the math. Between 500 to 1500 lines a day on average during one seven
year period. Much less on average since I started programming in 1975, but
still a considerable amount.
I have professional experience in over a dozen languages, some working in
engineering department at other times in software or service companies.
This does not include dialecs of a single language (probably a dozen of
basic alone.)
I also have hobbiest experience in another dozen languages (I include
Euphoria in this catagory.)
I speak from real world experience. This doesn't make me right, just
well informed.
12. Re: Nested routines
Jeremy Cowgar wrote:
>
> ken mortenson wrote:
> >
> > Two questions. Same answer. Because less is more!!!!!!!!!!!!!!
> >
>
> I agree! Less code I type the better.
>
> > Imagine how effecient and less complicated your compiler becomes when you
> > remove all the unneccessary bells and whistles and just leave the pure and
> > clean, unadulterated core. Bells and whistles are for libraries (which are
> > optional in a project) while the core should be a finely crafted tool. It's
> > one of the main things that attracted me to the language in the first place.
>
> Imagine how efficient and less complicated your code will be (which you have
> to maintain, not the compiler) if the compiler does it's job and provides the
> common constructs/functionality necessary for me to do my job (programming)
> easily! That's what I look for. If I wanted a bare minimum compiler I'd go
> with
> whitespace or something.
>
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
I prefer a bare minimum to a kitchen-sink approach.
It seems like we've gone from discussing and adding functionality that has been
requested and/or generally agreed upon by the community to just adding in any old
thing.
This beautiful, simple language is starting to suffer from some serious
uglification IMV.
--
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.
13. Re: Nested routines
Jeremy Cowgar wrote:
> Imagine how efficient and less complicated your code will be (which you have
> to maintain, not the compiler) if the compiler does it's job and provides the
> common constructs/functionality necessary for me to do my job (programming)
> easily! That's what I look for. If I wanted a bare minimum compiler I'd go
> with
> whitespace or something.
Having nested routines isn't a show stopper for me. I never use them, but
tastes vary. My objection to this is weaker than for other ideas. My
objection is more because of the sharing of vars. which may create the
habit of doing the same thing at a higher scope. Practically though,
it's not that big an issue to me. I raise my one itty, bitty vote nay,
the yays may carry the day.
One another note, bloated software happens because many people like the
cool ideas and not enough people will stand against (call it apathy if
you like) I feel the need to raise objections often just to be on the
record. I generally don't regret my record.
14. Re: Nested routines
Jason Gade wrote:
> I prefer a bare minimum to a kitchen-sink approach.
>
> It seems like we've gone from discussing and adding functionality that has
> been
> requested and/or generally agreed upon by the community to just adding in any
> old thing.
>
> This beautiful, simple language is starting to suffer from some serious
> uglification
> IMV.
Version 5 may turn out to be a gutting of version 4.
Einstein said, "keep everything as simple as possible, but no simpler" or
something to that effect. Some people have a profound appreciation for
this idea, but it's not unexpected that most don't.
GACT - life itself is a simple as possible. GAC - too simple!
15. Re: Nested routines
ken mortenson wrote:
>
> Version 5 may turn out to be a gutting of version 4.
>
Ken,
I will finish up my line of questioning with an observation that may be true or
false, it may be implied or not. You speak to others as though the are immature
and as though you have been enlightened by the programming gods. There are many
very intelligent people here on EUforum who have vast amounts of professional
programming experience who have studied language design who have programmed
millions of lines of code and finally who are not dumb. The way you speak is
condescending and irritating to many people. You have said such things as:
"but the rewards (this is just one of many voices of experience) are more than
you know."
"With all due respect, this is incorrect."
"Back in the day, I thought I could never live without ON X GOTO, as well as ON
X GOSUB. I have matured quite a bit since then."
"This isn't the only problem related to GOTO's but it is perhaps the easiest
to perceive."
"A programmer after my own heart (soon you will achieve oneness...)"
"I am but a simple and humble servant to whatever is true."
And those are just from your most recent posts. I didn't want to spend all day
picking all of them out.
So, I am not complaining, rebuking or upset, I am merely letting you know that
your style of speaking is not helping your cause. In addition to this, please
when making a statement provide information to back it up. I do not wish to go
back and pick out more quotes, but statements such as "that's ugly", "it's bad
practice", "..." says who? Can you give examples? Can you prove your point? An
opinion is not worth much in today's world. Please provide real content.
I will leave this subject now and continue on with improving Euphoria for the
masses.
--
Jeremy Cowgar
http://jeremy.cowgar.com
16. Re: Nested routines
Jason Gade wrote:
>
>
> I prefer a bare minimum to a kitchen-sink approach.
>
> It seems like we've gone from discussing and adding functionality that has
> been
> requested and/or generally agreed upon by the community to just adding in any
> old thing.
>
Jason,
I would like to point out that everything that has been added has been
discussed, with the exception of the entry keyword, which was a carry over from a
merge. At that, the entry keyword is being discussed currently because people are
questioning it as they saw in the peer reviewing that is continuously going on
during svn commits.
Euphoria 4.0 has not yet hit an alpha stage and even during the alpha stage the
keywords, constructs and API are free to change.
The current discussion about nested routines, OO, etc... are just that, they are
very, very pre-even thinking about adding, discussions to see what people think
of those constructs.
> This beautiful, simple language is starting to suffer from some serious
> uglification IMV.
>
Can you be a little more precise on what additions to Euphoria in 4.0 you think
are ugly so we can re-evaluate them? If they are currently being discussed,
please let those out as discussions are already going on. If they have not yet
been added, please leave those out as they are also being discussed already. I am
speaking of what has been added or has been approved to be added?
The list can be seen:
http://sourceforge.net/mailarchive/message.php?msg_name=4831C95F.709%40cowgar.com
To keep things in order and the discussions able to be followed, for each issue
that you wish to discuss, can you start a new thread for? Thank you.
--
Jeremy Cowgar
http://jeremy.cowgar.com
17. Re: Nested routines
Jeremy, I've already discussed some of the things that I don't like, and now new
ones come up.
While I consider myself one of the minimalists here, and as something of an
amateur I certainly can't compete with others' professional education and
experience, I'm not against every single feature that has been considered and
added. Only a few of them.
What's frustrating to me is that just when it seems like we've come to an
agreement on one contentious issue we get, "oh, one more thing..."
Maybe I'm just grousing/ranting. *shrug*
I've obviously had as much luck arguing what I like/don't like with regards to
additions as I did when trying to argue to have Euphoria added to the Shootout.
So I should just STFU and code, but when I see yet another proposal it just sets
my teeth on edge. I realize that sometimes there's a line between being an
obstructionist for the cause of creating obstructions, and being an
obstructionist when you see things taking a tack that is adding stuff to the
language "just because".
--
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.
18. Re: Nested routines
Jeremy Cowgar wrote:
>
> Jason Gade wrote:
> The current discussion about nested routines, OO, etc... are just that, they
> are very, very pre-even thinking about adding, discussions to see what people
> think of those constructs.
Sorry, if we're just discussing, then I'm just adding my 2c to the discussion
then, and trying to explain where I'm coming from. Sometimes the discussions tend
to turn into steamrollers though.
--
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.
19. Re: Nested routines
Jason Gade wrote:
>
> What's frustrating to me is that just when it seems like we've come to an
> agreement
> on one contentious issue we get, "oh, one more thing..."
>
I understand. That's one reason the email was created about organizing 4.0 which
lists what will be added to it. It was just a view but I think it has common
acceptance.
Right now, however, it seems with the idea of 4.0 everyone has on their thinking
caps and while their thinking caps are on, discussions might as well roll.
4.0 alpha is not too far away. Not as much as many people think has been added
to 4.0, but 4.0 is going to be one nice new release. In 4.0 are many items that
have been on SF.net or EUwiki in the request areas for a long time.
>
> So I should just STFU and code, but when I see yet another proposal it just
> sets my teeth on edge. I realize that sometimes there's a line between being
> an obstructionist for the cause of creating obstructions, and being an
> obstructionist
> when you see things taking a tack that is adding stuff to the language "just
> because".
>
This is a difficult time for us all. I'm getting tired of discussions as well as
many others. We are all itching to have our hands at 4.0. 4.0 is reaching a state
that it's worthy to be called 4.0. I am going to start renewed discussion on the
Organizing 4.0 thread on the dev list and see what people think about finalizing
the 4.0 roadmap. I do not wish to instantly shutoff peoples thinking caps though
but 4.0 does need to come to some type of conclusion. There is an outstanding
vote that needs to be made about namespaces/overriding, the idea of a
select/switch statement that has not been discussed to much, other than that, I
think 4.0 alpha is almost ready. Some more unit tests, a few known bugs and a bit
better of a build system and I think we are ready.
During the alpha stages changes can still happen but once we move to beta, the
API/functionality will be locked *unless* a bug is found that *requires* an API
change to fix.
So, bear with us, we're getting close. This has been a long time for us all.
--
Jeremy Cowgar
http://jeremy.cowgar.com
20. Re: Nested routines
Jeremy Cowgar wrote:
>
> This is a difficult time for us all. I'm getting tired of discussions as well
> as many others. We are all itching to have our hands at 4.0. 4.0 is reaching
> a state that it's worthy to be called 4.0.
...
> I do not wish to instantly shutoff peoples thinking caps...
Jeremy, you've done an excellent job so far. A+++. Would hire again. :D
It's great to see you, Matt, DerekP, CChris, and other gurus involved in
improving the interpreter (I just wish Rob would speak up more, but I know
he had family engagements recently). Keep it up, and let's get to 4.0 Release!
