21–30 of 57 posts
Who is this article written for? There's a whole section on "What is memory?". If you are optimizing to remove memory leaks I really hope you already know what memory is.
Earlier quoted context omitted.
Meh, if you try and split hairs, even assembly has magic in it nowdays. Not all instructions take the same amount of time. Some flush caches, thus cause unexpected memory behavior, etc. However, I think it is fair that most people learn roughly what the side effects are of each line at a local level. Ironically, this is an argument against many functional languages. There are not side effects of the logic, per se. Ho…
Like I said - it's mostly arbitrary. ;) That said I think the issues with assembly you mention aren't magic as such, they're just consequences of the commands. They don't really hide much (if anything) behind the scenes that you'd have access to anyhow. It's just that CPUs do so much more than they used to.
Earlier quoted context omitted.
I agree. I strongly dislike "magic" in programming. I prefer to call it "denial" because you need to know about the complexities anyway, and "magic" often means sweeping them all under the rug.
At some point every abstraction above Assemby meets that criteria though. The lines are personal and mostly arbitrary.
Earlier quoted context omitted.
Meh, if you try and split hairs, even assembly has magic in it nowdays. Not all instructions take the same amount of time. Some flush caches, thus cause unexpected memory behavior, etc. However, I think it is fair that most people learn roughly what the side effects are of each line at a local level. Ironically, this is an argument against many functional languages. There are not side effects of the logic, per se. Ho…
Like I said - it's mostly arbitrary. ;) That said I think the issues with assembly you mention aren't magic as such, they're just consequences of the commands. They don't really hide much (if anything) behind the scenes that you'd have access to anyhow. It's just that CPUs do so much more than they used to.
You can think of assembly on those cpus as a high level language. It has little correlation with what's actually happening in hardware.
This is EXACTLY the same type of "magic" that is getting complained about above. The real implementation details are hidden and unknown, but the abstraction is useful.
Nice article. Minor gripe about the static vs dynamic memory section. The requirement that the data sizes be known at compile-time for static memory (with the example of an array allocated to a user-inputted size), seems to be based on a past restriction of the C language. C has since remove the requirement that stack-based arrays are sized with a compile-time constant; there is nothing at the hardware/assembly level…
Wait, is #3 for real? If that's the case it seems like a huge oversight.
Wait, is #3 for real? If that's the case it seems like a huge oversight.
Would it be better to have to explicitly declare what variables you want to import into the closure like PHP or C++ do? C# also captures everything by default and reference which has tripped me up quite a few times.
Wait, is #3 for real? If that's the case it seems like a huge oversight.
Yeah, of the four things listed, I think it's the one that would trip me up the most. I think the safety net here would be dead code elimination: `unused()` should be detected as never called and removed during compilation/transpilation so that this wouldn't be an issue. I am sort of surprised that `unused` is not picked up by the garbage collector in the first place though. Since JS functions are objects, shouldn't…
Is my understanding correct?
Earlier quoted context omitted.
Meh, if you try and split hairs, even assembly has magic in it nowdays. Not all instructions take the same amount of time. Some flush caches, thus cause unexpected memory behavior, etc. However, I think it is fair that most people learn roughly what the side effects are of each line at a local level. Ironically, this is an argument against many functional languages. There are not side effects of the logic, per se. Ho…
Like I said - it's mostly arbitrary. ;) That said I think the issues with assembly you mention aren't magic as such, they're just consequences of the commands. They don't really hide much (if anything) behind the scenes that you'd have access to anyhow. It's just that CPUs do so much more than they used to.
I was just musing on how the arbitrary line is probably not as difficult to see as many other lines we have out there. I think this would fall into "systems languages" and related things.
Wait, is #3 for real? If that's the case it seems like a huge oversight.