The article does not distinguish between recursive and nested subroutine calls. I understand, why the provided example does not allow for recursion, but doesn't it also prevent a nested call to another subroutine? If I remember correctly before FORTRAN90 we already had nested subroutine calls. How did that work? EDIT: I think I get it. The hidden global variables are prefixed with the sub's name. This is pretty waste…
Subroutine calls in the ancient world, before computers had stacks or heaps
31–40 of 241 posts
Re: Subroutine calls in the ancient world, before computers had stacks or heaps
#32Earlier quoted context omitted.
Most recursion is about as bad as goto coding methodologies. Personally, I think it should be avoided in modern compiled languages too. Haskell is fun to play around on, but it is horrific to consider using in a stable production environment. =)
Outside of a university course, if I see recursion in a non-FP language I consider it a code-smell
def process_that_tree(my_tree):
def _handle(node):
# do the things
for child in node.children:
_handle(child)
_handle(my_tree.root)
The processing can even be brought outside sometimes, or the walker can just become a generator, yielding nodes out to a regular loop doing the actual work. Either way, the recursive part is kept very minimal and easy to reason about.Obviously for the filesystem these kinds of abstractions exist already in shutil/pathlib/glob, but it still can have a place for dealing with other kinds of hierarchies, like a package dependency tree or the like.
Re: Subroutine calls in the ancient world, before computers had stacks or heaps
#33"There was just one catch: You can't do recursion." You could do tail recursion, because only the return address of the first call would be needed to be stored. `branch_with_link` would be used for the initial call, but the recursive calls would have to be regular branches.
Most recursion is about as bad as goto coding methodologies. Personally, I think it should be avoided in modern compiled languages too. Haskell is fun to play around on, but it is horrific to consider using in a stable production environment. =)
[1] https://web.archive.org/web/20091206042608/http://projectfor...
Re: Subroutine calls in the ancient world, before computers had stacks or heaps
#34Earlier quoted context omitted.
Most recursion is about as bad as goto coding methodologies. Personally, I think it should be avoided in modern compiled languages too. Haskell is fun to play around on, but it is horrific to consider using in a stable production environment. =)
Outside of a university course, if I see recursion in a non-FP language I consider it a code-smell
Do you never work with tree data structures?
I can't think of a non-trivial program I've written in the past two decades that didn't have some recursive tree traversal in it.
Re: Subroutine calls in the ancient world, before computers had stacks or heaps
#35Am I the only one who read it as the ancient world before computers existed had stacks or heaps? English is so weird sometimes...
Re: Subroutine calls in the ancient world, before computers had stacks or heaps
#36Earlier quoted context omitted.
Most recursion is about as bad as goto coding methodologies. Personally, I think it should be avoided in modern compiled languages too. Haskell is fun to play around on, but it is horrific to consider using in a stable production environment. =)
Outside of a university course, if I see recursion in a non-FP language I consider it a code-smell
Re: Subroutine calls in the ancient world, before computers had stacks or heaps
#37Am I the only one who read it as the ancient world before computers existed had stacks or heaps? English is so weird sometimes...
All that world was well before computers were a thing (even the human type were called “scribes,” “clerks” etc.)
So of course I read it the same way even though “before computers” was redundant once your comment made me think about it.
Re: Subroutine calls in the ancient world, before computers had stacks or heaps
#38Note that before we had arbitrarily extensible heaps, programmers always did at least a little engineering, in that they had to consider the probable distribution of inputs and size* all their intermediate storage appropriately. * giving rise to "BUGS AND LIMITATIONS "
Historically, that was also a big goal of GNU. It aimed to get rid of artificial limitations in core utilities. That was a big improvement over (made up example) sed having a finite and short maximum command length.
With that said, I also see benefit in having limitations. There is a certain comfort in knowing what a tool can do and cannot do. A hammer cannot become a screwdriver. And that's fine because you can then decide to use a screwdriver. You're capable of selection.
Take PostgreSQL. How many devs today know when it's the right solution? When should they use Redis instead? Or a queue solution? Cloud services add even more confusion. What are the limitations and weaknesses of AWS RDS? Or any AWS service? Ask your typical dev this today and they will give you a blank stare. It's really hard to even know what the right tool is today, when everything is abstracted away and put into fee tiers, ingress/egress charges, etc. etc.
tl;dr: limitations and knowledge of those limitations are an important part of being able to select the right tool for the job
Re: Subroutine calls in the ancient world, before computers had stacks or heaps
#39Re: Subroutine calls in the ancient world, before computers had stacks or heaps
#40Earlier quoted context omitted.
Outside of a university course, if I see recursion in a non-FP language I consider it a code-smell
This opinion is totally wild to me. Do you never work with tree data structures? I can't think of a non-trivial program I've written in the past two decades that didn't have some recursive tree traversal in it.