I don't think many people realize just how much of a modern processor is made around supporting preemptive multitasking. Folks know that we have a class of security bugs from it, but a lot of what happens in a CPU is around juggling multiple workloads.
Subroutine calls in the ancient world, before computers had stacks or heaps
121–130 of 241 posts
Re: Subroutine calls in the ancient world, before computers had stacks or heaps
#122Earlier quoted context omitted.
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…
Re: Subroutine calls in the ancient world, before computers had stacks or heaps
#123Earlier quoted context omitted.
We know from the Corecursive podcast on the hidden story of SQLite that Dr. Hipp did indeed reference and pull at least one alg straight from Knuth's books, which he had behind his desk. What a different world that must have been!
FYI, he's D. R. Hipp, not Dr. Hipp.
Re: Subroutine calls in the ancient world, before computers had stacks or heaps
#124Earlier quoted context omitted.
We know from the Corecursive podcast on the hidden story of SQLite that Dr. Hipp did indeed reference and pull at least one alg straight from Knuth's books, which he had behind his desk. What a different world that must have been!
FYI, he's D. R. Hipp, not Dr. Hipp.
Re: Subroutine calls in the ancient world, before computers had stacks or heaps
#125Most people just know the title and simply fetishistically refuse to use a goto (most of the time they are terrible, but not always). But really the paper argues for giving subroutines a single entry point.
Sometimes I write assembly code that falls through into another subroutine, but I don’t want all my assembly to be spaghetti like that.
Re: Subroutine calls in the ancient world, before computers had stacks or heaps
#126Earlier quoted context omitted.
"Recursion is fine [for your use-case]." In general it is naive, often dangerous, and an inefficient space/time trade-off. I have been writing software for several decades... does that make one less insightful or more biased? https://youtu.be/pmu5sRIizdw?feature=shared&t=31 =)
If you're going to make a generalization, I think recursion is fine, efficient, and rarely dangerous. There may be use cases where it's insecure or has performance concerns, but those are the exception. Most of the time, it's fine. We don't generally tell programmers that loops are naive, often dangerous, and risk locking up the program. They certainly can, but most just... don't. Just like loops, recursion can make…
Parsers are far from immune to these issues.
I think we will have to "agree to disagree" here... =)
Re: Subroutine calls in the ancient world, before computers had stacks or heaps
#127Earlier quoted context omitted.
This is just bananas. I work in programming languages. I currently have open in my editor a code formatter that I maintain that uses at least half a dozen recursive algorithms to traverse syntax trees and other data structures. This program is used by almost every user of our language, invoked on every save, and probably executed billions of times a day. Recursion is fine .
"Recursion is fine [for your use-case]." In general it is naive, often dangerous, and an inefficient space/time trade-off. I have been writing software for several decades... does that make one less insightful or more biased? https://youtu.be/pmu5sRIizdw?feature=shared&t=31 =)
with open('lulz.json') as ayy_lmao:
oops = json.load(ayy_lmao)
If you parse arbitrary json bytes from the Internet (for example, if you have some public Python API with no auth) then you have given the world a fun little stacktrace generator, and a way to lessen your server room's heating bill.EDIT: btw you can do the same thing in rust's serde_json if the type you're deserializing into somehow supports the nesting, but you'd have to work for it.
EDIT2: the only (decent) way I can think to mitigate this in the python app's case is to enforce a sufficiently restrictive Content-Length at the edge, which obviously isn't possible of you expect blobs O(100Kb) uncompressed. Or you could pre-parse to detect nesting.
[1] EDIT3: on my machine in ipython right now it's 1485:
import json
def nest(d):
return '{"k":' + str(d) + '}'
def make_mess(n):
v = 1
for _ in range(n):
v = nest(v)
return v
json.loads(make_mess(1485)) # boomRe: Subroutine calls in the ancient world, before computers had stacks or heaps
#128Earlier quoted context omitted.
I came across your works learning and consuming all things Forth and Subleq. It was great to read over how you approach things. I wanted to purchase your book but Amazon says no...will there be another run?
Thanks! You should still be able buy it, you might have to either click on "Paperback" or "Hardcover", if you want to get the kindle edition you have to go to the Amazon webpage that serves you country (e.g. if you are in the UK and you are on amazon.com you get "This title is not currently available for purchase", but if you go to amazon.co.uk, you get buy it). That's an odd user interface issue...
Re: Subroutine calls in the ancient world, before computers had stacks or heaps
#129Earlier quoted context omitted.
"Recursion is fine [for your use-case]." In general it is naive, often dangerous, and an inefficient space/time trade-off. I have been writing software for several decades... does that make one less insightful or more biased? https://youtu.be/pmu5sRIizdw?feature=shared&t=31 =)
For a fun time, make a nested json blob about 1000 layers deep[1] and in python: with open('lulz.json') as ayy_lmao: oops = json.load(ayy_lmao) If you parse arbitrary json bytes from the Internet (for example, if you have some public Python API with no auth) then you have given the world a fun little stacktrace generator, and a way to lessen your server room's heating bill. EDIT: btw you can do the same thing in rust…
And yeah, recursion is avoided in some shops for good reasons.
Re: Subroutine calls in the ancient world, before computers had stacks or heaps
#130Earlier quoted context omitted.
'2716 EPROM' was a 16K (2kb x 8) EPROM. Which customer/sector was your project intended for?
Yes, the xx(x) number in the 27xx(x) EPROM series indicates the kilo (1024) bits. So indeed this is 2 KiB. This sounds OK for the application described, especially as it was no doubt written in assembly and obviously bare metal. When it does not fit but not far off it's when the fun of code optimisation kicks in ;) Edit: Very interesting how easily available they still seem to be according to Google.