←back to thread

90 points rbanffy | 8 comments | | HN request time: 0.001s | source | bottom
Show context
SeenNotHeard ◴[] No.45133316[source]
One limitation not mentioned is that Action! didn't support recursion. This had to do with how local variables were stored.

Whether it was the best language for 8-bit programming, it certainly was a great fit for the 6502, as the language targeted the peculiarities of that chip. Accessing hardware-specific features of the 8-bit Atari's was a snap, which was necessary in order to do anything more interesting than sieves or print loops.

Action! probably could've been ported to the Apple line, but 8-bits were winding down by the time it was released. Porting to 16-bit machines like the IBM PC or Mac (or even the Atari ST) would have been a tougher sell, since Pascal and C were better established by that point, and worked well on those machines.

Two bad things about Action!: Charging a license fee to distribute the runtime, and that dumb bang in the name.

replies(2): >>45135475 #>>45136874 #
1. keyle ◴[] No.45135475[source]
Wasn't recursion a problem for early C and Pascal in those days anyway? They didn't have tail call optimisations.

As in after X recursion, you'd get in trouble as the memory kept allocating new stack frames for every recurse...

replies(3): >>45136010 #>>45136862 #>>45145984 #
2. pasc1878 ◴[] No.45136010[source]
C and Pascal still don't have TCO.

But you still need some recursion and C and Pascal can do that.

replies(1): >>45136261 #
3. keyle ◴[] No.45136261[source]
When would you absolutely need recursion that couldn't be fulfilled with a while loop?
replies(3): >>45136624 #>>45139341 #>>45162618 #
4. unnouinceput ◴[] No.45136624{3}[source]
Never, but I can counter with "when do you absolutely need switch that can't be fulfilled with if-else"?

It's a nice to have that makes your life easier

5. stevefan1999 ◴[] No.45136862[source]
You still don't have TCO anyway unless you use [[must_tail]] (or the upcoming become keyword in Rust)
6. gavinray ◴[] No.45139341{3}[source]
Many algorithms are more simply expressed as recursive functions than stack-based iterators or "while" loops.
7. vincent-manis ◴[] No.45145984[source]
No, recursion still works well without TCO (though as a Schemer, I love TCO). I was programming in BCPL in the early 1970s, and it handled recursive procedures with aplomb. The big revolution was realizing that, if you don't allow access to automatic variables declared in outer scopes, you could store all the variables in the stack frame, and access them with a small offset from the stack or frame pointer. That made automatic variables just about as fast as static ones (which, on System/360, had to be accessed via a base register), with small overheads at call and return sites.

Again on System/360, I benchmarked BCPL procedure call costs against subroutine call costs in Fortran G (the non-optimizing compiler). BCPL was about 3 times faster.

That said, as soon as you added multi-tasking (what we'd now call threads), it all went to hell. It's not an accident that one IBM PL/I manual of the 1960s said “Do not use procedures, they are expensive.”

As mentioned by others, it was the tiny stack in the 6502 that killed this approach. I appreciate all those who pine for the 6502, but it made implementing modern (even for the 1970s) languages almost impossible.

8. AnimalMuppet ◴[] No.45162618{3}[source]
Adaptive quadrature is an algorithm for numerical integration. You have a function of one variable, and two endpoints of a range, and an error limit. You want to return the value of the integral of that function over that range, a value that is no further from the correct value than the error limit.

What you do is, you do a three-point approximation and a five-point approximation. The difference between the two gives you a fairly good estimate of the error. If the difference is too high, you cut the region in half, and recursively call the same function on each half.

That calling twice is what makes it hard for a while loop. I mean, yes, you could do it with a work queue of intervals or something, but it would be much less straightforward than a recursive call.