Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Ben Bacarisse Newsgroups: comp.lang.javascript Subject: Re: I don't get it Date: Wed, 14 Apr 2021 01:32:36 +0100 Organization: A noiseless patient Spider Lines: 43 Message-ID: <875z0pn1sr.fsf@bsb.me.uk> References: <1e965vkgenq7l$.hqmrkifgr4m5$.dlg@40tude.net> <586d1b88-77d5-42b0-ae5b-7506307df499n@googlegroups.com> <957a79db-946e-4f23-931a-ef7d4f0dbb3cn@googlegroups.com> <305fecc4-43da-4378-8430-ed10ac4dbe5bn@googlegroups.com> <20917gl3dv8shs6qqf1dqginq69e50aa54@4ax.com> <8735vytcwa.fsf@bsb.me.uk> <87lf9qrozz.fsf@bsb.me.uk> <875z0tq723.fsf@bsb.me.uk> <8b594439-379f-431f-8bf6-43c8066d3525n@googlegroups.com> <87o8ejpzv0.fsf@bsb.me.uk> <845c8b8e-d415-4b41-8327-6b31bc50825an@googlegroups.com> <1ae0aa1d-162d-4666-acf9-50376e1acd9fn@googlegroups.com> <8090782c-7564-4881-a97e-70dd1e865674n@googlegroups.com> <87y2dmmgln.fsf@bsb.me.uk> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="8c26916253c32cdde332367cf4f34a56"; logging-data="19434"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18I36xouhBTGSyGNBZ4SVJCC53G30AcBhU=" Cancel-Lock: sha1:fHxzchfc6XyuhmqhHSqyTEVc3yk= sha1:65qxX7EjbkXDeGiaKsTgZ2iRZYs= X-BSB-Auth: 1.6ccd9f98f514afb0da8a.20210414013236BST.875z0pn1sr.fsf@bsb.me.uk Xref: csiph.com comp.lang.javascript:39929 The Natural Philosopher writes: > On 13/04/2021 14:58, Ben Bacarisse wrote: >> The function is doing exactly what you wrote. > > Not for at least two decades, and certainly not in JavaScript. > > The function is doing what the compiler and/or interpreter decided you > *meant* by what you wrote. It's a common mistake to think of code as implying more than it does. This is particularly true of high-level languages like ECMAScript, but it's also true of languages like C. Assuming more than the language guarantees has been the source of many bugs in C programs. > Which is why you now have new keywords like 'volatile' to try and > force it not to be clever with loop optimisations and Number() to > ensure it actually does cast an unknown variable type to a number... Hmm... Your recent Number() example seems to be simply a case of your not knowing what the language guarantees. > Years ago I could look at a bit of C code and translate it into the > actual assembler that the compiler would spit out. Today it produces > nothing like that at all. > > So far I have always been impressed at how good it was at > optimisation, but as I have said elsewhere, sometimes it gets it > wrong. I agree that all of this is contingent on the specification being clear and there being no bugs in the language implementation. But in JT's case, I would be very surprised if the problem where a bug in the implementation. All beginners think they have found a compiler bug! > And there are holes in the spec - areas that are 'indeterminate' and > up to the whim of the compiler/interpreter and of course things like > uninitialised memory. > > Then when you get to concurrent threads... -- Ben.