Live data from Hacker News

Subroutine calls in the ancient world, before computers had stacks or heaps

devblogs.microsoft.com

31–40 of 241 posts

Re: Subroutine calls in the ancient world, before computers had stacks or heaps

#31

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…

Nor reentrant. In machines where the JSR that stores the return address at the jump target, usually interrupts are locked for 1 following instruction so that you have a chance to load the return address into the accumulator. Back in the day I worked with a RTOS on one of those beasties.

Re: Subroutine calls in the ancient world, before computers had stacks or heaps

#32

Earlier 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

The only time I ever do it is for tree walking, and then it's always a private internal function, so like:

    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. =)

I'd recommend you read Guy Steele's blog post Why Object-Oriented Languages Need Tail Calls [1] and perhaps the essay by William Cook [2] and the discussion over on Lambda the Ultimate [3]

[1] https://web.archive.org/web/20091206042608/http://projectfor...

[2] https://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf

[3] http://lambda-the-ultimate.org/node/3702

Re: Subroutine calls in the ancient world, before computers had stacks or heaps

#34

Earlier 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

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.

Re: Subroutine calls in the ancient world, before computers had stacks or heaps

#35
post #7

Am I the only one who read it as the ancient world before computers existed had stacks or heaps? English is so weird sometimes...

"Novel analysis of the Antikythera mechanism suggests all of its wheels were statically allocated at construction time"

Re: Subroutine calls in the ancient world, before computers had stacks or heaps

#36

Earlier 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

While I am not a fan of recursion, the call stack that enables it sounds infinitely better than statically allocating space for parameters and return values. Besides, it makes some algorithms clearer. That is certainly useful in learning environments, including early academic research.

Re: Subroutine calls in the ancient world, before computers had stacks or heaps

#37
post #7

Am I the only one who read it as the ancient world before computers existed had stacks or heaps? English is so weird sometimes...

The ordinarily “The Ancient World” means an era ending with the fall of the Western Roman Empire circa 476 CE.

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

#38

Note 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.

I can understand why people wanted that, and the benefit of doing that.

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

#39
post #7

Am I the only one who read it as the ancient world before computers existed had stacks or heaps? English is so weird sometimes...

I’m no grammarian but I think it should have a comma after “world”.

[dead]

Re: Subroutine calls in the ancient world, before computers had stacks or heaps

#40

Earlier 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.

Tree traversal uses stacks / queues unless you're dealing with a small tree such that you're sure recursion won't blow your stack, or your algorithm can work with tail calls and your language guarantees TCO.
Post reply on HN