Path: csiph.com!news.mixmin.net!weretis.net!feeder1.news.weretis.net!news.solani.org!.POSTED!not-for-mail From: Thomas 'PointedEars' Lahn Newsgroups: comp.lang.javascript Subject: Re: Give alert if form checkbox array is empty Date: Fri, 29 Jan 2016 20:34:24 +0100 Organization: PointedEars Software (PES) Lines: 135 Message-ID: <3578026.uz7IMZfZDu@PointedEars.de> References: <1851504.v7CTRd67sv@PointedEars.de> <6772cf1e-3a97-4a4c-9f18-72064d765eac@googlegroups.com> <3172174.YdVlHmXemb@PointedEars.de> <1921981.XUuFBCho4f@PointedEars.de> Reply-To: Thomas 'PointedEars' Lahn Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8Bit X-Trace: solani.org 1454096066 24422 eJwFwQkBACAIBLBKIMcXB1D6R3BTMbZxmBp0deUJFZ9Fzg3FYD3okptE83a+vNOELrQVcD4ZthEq (29 Jan 2016 19:34:26 GMT) X-Complaints-To: abuse@news.solani.org NNTP-Posting-Date: Fri, 29 Jan 2016 19:34:26 +0000 (UTC) User-Agent: KNode/4.14.2 X-User-ID: eJwNycEBwEAEBMCWcCzK4ZLtv4RkvhMHipuOgAeDV2ZssIUC9lB3qCn+6Nt2yNI2j1kX0Wp1y3qEO5vy3/YHT5QVIg== Cancel-Lock: sha1:QIUJ42Prhjz2qchpseSyYiyhEeA= X-NNTP-Posting-Host: eJwFwYEBwCAIA7CXdC1lnIMI/59gYtBWOWWijQ2a3fAvwg9PeCtXIEup43/tNUVP4hJL4H0a8hDY Xref: csiph.com comp.lang.javascript:29491 Gene Wirchenko wrote: > On Thu, 28 Jan 2016 20:06:14 +0100, Thomas 'PointedEars' Lahn > wrote: >>Gene Wirchenko wrote: >>> On Thu, 28 Jan 2016 14:46:44 +0100, Thomas 'PointedEars' Lahn >>> wrote: >> >>Attribution _line_, not attribution novel. Will you ever learn? > > I know what a novel is, and two lines do not qualify. It is a metaphor for “too long for the common good”. The point is that it makes threads harder to read because if this is repeated or if everyone does it you have to read through a lot of superfluous information before you get to the good parts of a posting. It wastes everybody’s time. There is a good example above. Imagine a few more quotation levels in this way, imaging that I had posted an attribution novel too, and you get the picture. Whenever you are unsure whether you should do something in Usenet, do not do those things that likely waste your reader’s time. >>>> Scott Sauyet wrote: >>>>> Thomas 'PointedEars' Lahn wrote: >>>>>> Keep in mind that the built-in implementation of an algorithm is >>>>>> naturally always the most efficient one to use as it is, at best, >>>>>> provided in machine code already. >>>>> Proof by statement. >>>> I have already explained why. It is not my problem if you are not >>>> paying attention and can only come up with apples vs. oranges. >>> >>> Sorry, but your reasoning is invalid. >> >>No, it is not. >> >>> It is quite possible for an implementation to be inefficient. >> >>Yes; nobody debated that. But AISB that reasoning presupposes that the >>developers of script engines do not know what they are doing. Since WLOG > > Stating that it is possible for an implementation to be > inefficient is not the same as stating that an implementation is > inefficient. The notion of an inefficient implementation is a misconception to begin with. As I indicated, an implementation can be less efficient (or more inefficient) than another, or more efficient (and less inefficient) than another. The point here is that you cannot know what the script engine will be, so it is pointless and can be even counterproductive to optimize in that direction. It is, however, _not_ pointless to optimize in the other direction: to write your own code so that it implements the most efficient algorithm so solve a problem. >>you do _not_ know what script engine your code will be exposed to, it is >>not logical to write your code based on either assumption, and *that* >>reasoning is "invalid" instead. > > One can test a variety of them. To what end? Drawing such a conclusion from a subset of script engines – and it is *always* a subset – to the general case would be a hasty generalization and is fallacious because of that already. Add to this that what you have tested today is literally obsolete tomorrow because of rapid releases. Even and especially with the *same* script engine (but then a different version of it). >>In addition, AISB, comparing implementations of different algorithms is >>comparing apples and oranges; it is a fallacious argumentation. For >>example, you can use lodash’s _map() instead of Array.prototype.map() and >>the former can be more efficient than the latter for the cases that _map() >>supports (at least with regard to execution speed), but you need to be >>aware that the former is both deficient regarding standards compliance […] >>and does more than the standard implementation does at the same time […], >>so in general the former *cannot* be used as a stand-in for the latter. > > In general. I deal in specific cases. Not my problem. The claim, or at least the implication, was a general one. >>> I would require good reason to not use the built-in >>> implementation rather than coming up with my own, but if the built-in >>> implementation were that bad, it might be worth it. >>You cannot not know what you cannot know, and using conditionals in order >>to > > I really doubt that it is impossible to learn if I wanted to. That doubt is evidentially not based on rational, but on wishful thinking. It is along the same line of thought that people use to justify the umbrella term “javascript”. Ignoring differences does not make them go away. >>to tell script engines apart so that you could *perhaps* know that your >>script is executed by a less efficient implementation regarding a certain >>use-case (my research – […] shows that with the exception of JScript you >>can only *infer* the script engine version, and that knowledge will always >>be out of date at the time the code is run) is only going to make your >>script *less* efficient *for execution under all script engines* because >>you have to run those tests precisely when your code is executed. > > I may well be able to control the execution environment You can to some extent control the execution environment if it is one like Node.js. But without further specification, we are discussing ECMAScript implementations in Web browsers here instead. > so I could well know what script engines could be executing the code. And then you optimize for each new version of it? Think twice. >>BTW, it is an oft-neglected fact, which can be seen in this discussion >>prior to this posting, that the term efficiency in computer science is not >>limited >>to execution speed but also has as memory-usage component. There is >>runtime efficiency *and* memory efficiency. > > We are quite aware of that. I do not think so. Not once has anyone in this thread mentioned memory usage. > Why should we belabour the obvious? If it were obvious to those making the claim, “efficiency” would not have been used only to refer to execution speed. > If you are trying to be a pedant, you are not doing a very good > job of it. Ad hominem. -- PointedEars FAQ: | SVN: Twitter: @PointedEars2 | ES Matrix: Please do not cc me. / Bitte keine Kopien per E-Mail.