My first assembly was 6502 which kept a call stack in page 3 (128 levels deep being the maximum call depth as a consequence). When I learned 370 assembly, I remember being shocked to discover that an application was responsible for maintaining its own call stack.
Subroutine calls in the ancient world, before computers had stacks or heaps
51–60 of 241 posts
Re: Subroutine calls in the ancient world, before computers had stacks or heaps
#52When I was first starting out a very long time ago, I wrote a lot of Fortran (mainly for digital signal processing applications), and a couple of times I had to work around the lack of recursion by building my own stacks for intermediate results, with arrays and a position to keep track of where I was. It was ugly.
Re: Subroutine calls in the ancient world, before computers had stacks or heaps
#53Earlier quoted context omitted.
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 t…
I see zero benefit in having artificial functionality limitations. In my hypothetical example, imagine that `sed 's/foo/bar/'` works but `sed 's/foo/bark/'` does not because it's 1 character too long. There's not a plausible scenario where that helps me. You wouldn't want to expand sed to add a fullscreen text editor because that's outside its scope. Within its scope, limitations only prevent you from using it where you need it. It would be more like a hammer that cannot be made to hammer 3 inch nails because it has a hard limit of 2.5 inches.
Those are the kinds of limits GNU wanted to remove. Why use a fixed-length buffer when you can alloc() at runtime? It doesn't mean that `ls` should send email.
Re: Subroutine calls in the ancient world, before computers had stacks or heaps
#54the headline reminded me of "ancient computers" in sci fi games, which was essentially a tower of Hanoi problem inmplemented in-game
Re: Subroutine calls in the ancient world, before computers had stacks or heaps
#55Earlier 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. =)
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
Sure, or just add a polymorphic functor to walk a tree autonomously.
There are shorter ways to admit you already sold your soul. lol =)
Re: Subroutine calls in the ancient world, before computers had stacks or heaps
#56Whenever Raymond Chen retires, I am going to be really sad.
Re: Subroutine calls in the ancient world, before computers had stacks or heaps
#57Earlier quoted context omitted.
Outside of a university course, if I see recursion in a non-FP language I consider it a code-smell
Recursion is like an inductive proof, you can show it is correct and it normally fits on half of a small screen.
There is an argument that all recursive proofs can be made iterative due to isomorphism.
You are not lazy enough to be a good programmer yet. ;-)
Re: Subroutine calls in the ancient world, before computers had stacks or heaps
#58Whenever Raymond Chen retires, I am going to be really sad.
Why? I feel he will able to write more.
Re: Subroutine calls in the ancient world, before computers had stacks or heaps
#59"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. =)
It's interesting because I love using Haskell in a stable production environment. In fact I'd hate to use anything else!
On the other hand, I almost never use naked recursion in Haskell. It typically do recursion indirectly through more familiar combinators such as for loops.
Re: Subroutine calls in the ancient world, before computers had stacks or heaps
#60Earlier quoted context omitted.
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.
Depends on the CPU, in some architectures the stack pointers had low finite capacity before overflowing.