Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #39991

Re: Understanding &&

Show key headers only | View raw

Jon Ribbens <jon+usenet@unequivocal.eu> writes:

> On 2021-04-19, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> Jon Ribbens <jon+usenet@unequivocal.eu> writes:
>>> Here's a topical conundrum I have right now about readability...
>>> I needed to implement CSS.escape, which node doesn't have built-in:
>>>
>>>   https://drafts.csswg.org/cssom/#the-css.escape%28%29-method
>>>
>>> Two implementations I have written are shown below. They both do exactly
>>> the same thing. I'd say the first one is *much* more readable. But sadly
>>> it's almost *five times* slower than the second one. So the dilemma is
>>> which one to use...
>>
>> How important is the speed?  Five times almost nothing is almost
>> nothing, so one would have to know how much this code is used and how
>> slow the slow one is.
>
> Yes, to be fair I will probably go with the one I find more readable
> (i.e. the one you find less readable ;-) ) because I can't imagine this
> ending up actually taking any measurable amount of the whole program's
> execution time. It just does hurt me slightly that it's so much less
> efficient. I guess it must be the overhead of calling the anonymous
> function.

That, and the cost of replacing lots of tiny matches I would think.  I
think most implementations make growing a string more efficient than
doing a mid-string replacement.

For what it's worth, I don't find the factor of 5 that you do, but my
version is *way* slower than either of yours.  That, I think, is because
it matches every character.  (As I said I did that to minimise the
changes.)

If I change the string.replace to a simple for loop, then it matches
your escape2 in performance.

>> But it's an excellent example of what we've been talking about.  I found
>> your preferred version (the first one) quite hard to verify.  My
>> difficulty was not due to any language feature that you'd used but came
>> from the algorithm combining a negative character class and some
>> positive tests to implement a set of rules that are not written that
>> way.
> ...
>> For me, readability is about how easily can I see that the code is doing
>> the right thing, and given the specification:
>>
>> https://drafts.csswg.org/cssom/#serialize-an-identifier
>>
>> I would write something like this:
> ...
>> and then I'd check to see if I really needed to complicate the tests
>> and/or pull out special cases to get a more speed.  By the way, the
>> replace(/./g) is not an important part of what I'm saying.  I used that
>> method to minimise the differences between our approaches.
>>
>> When if comes the language features, I would probably write this:
> ...
>> but this is not really my point.  Readability goes much deeper than the
>> surface constructs.  It's about, as I think you said, how easy the code
>> is to verify, and that often means how closely it matches the
>> specification.
>>
>> If this was hard-line production code, I think I'd include the seven
>> sentences from the specification as a comment.  That would go a long way
>> to explaining why the code is written as it is.
>
> That's interesting, because there is an npm package which implements
> the function (which I couldn't use for $reasons) and it's written
> *exactly* as you describe.

So it does.  The comment is split between the cases but, yes, the same.

> You do of course have a point about following the spec, but to my mind
> (and we're deviating considerably from the original topic here) it just
> shows how this sort of "specification" is an absolute abomination. Many
> of the modern web specifications are similar. They don't tell you what
> things mean, they just give random algorithms and you have to work out
> the meaning for yourself. They're basically the opposite of a
> specification. I had to reverse-engineer the CSSOM spec in order to find
> out what it actually meant, in order to write my implementation. If it
> was an actual specification, what I just said would be nonsensical.

I think concentrating on the term "specification" is slightly
distracting up from the big picture.  I was trying to say that
readability is much deeper than the meaning of the surface syntax.
After all, that can be looked up, but how clearly the code represents
the method used to get the desired result is often the hard part of what
we mean by "readability".

-- 
Ben.

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Understanding && Andrew Poulos <ap_prog@hotmail.com> - 2021-04-16 14:30 +1000
  Re: Understanding && Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-16 11:00 +0100
  Re: Understanding && Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-04-16 11:17 +0000
    Re: Understanding && Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-16 16:09 +0100
      Re: Understanding && Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-04-16 15:26 +0000
        Re: Understanding && Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-16 21:09 +0100
          Re: Understanding && Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-04-16 21:06 +0000
            Re: Understanding && Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-17 02:01 +0100
              Re: Understanding && The Natural Philosopher <tnp@invalid.invalid> - 2021-04-17 08:33 +0100
              Re: Understanding && John G Harris <niam@jghnorth.org.uk.invalid> - 2021-04-17 12:06 +0100
                Re: Understanding && The Natural Philosopher <tnp@invalid.invalid> - 2021-04-17 14:13 +0100
                Re: Understanding && Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-17 15:50 +0100
              Re: Understanding && Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-04-17 15:21 +0000
                Re: Understanding && Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-17 23:46 +0100
                Re: Understanding && Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-04-17 23:46 +0000
                Re: Understanding && Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-18 23:59 +0100
                Re: Understanding && Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-04-19 13:56 +0000
                Re: Understanding && Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-19 23:08 +0100
                Re: Understanding && Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-04-19 22:52 +0000
                Re: Understanding && Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-20 01:23 +0100
                Re: Understanding && Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-04-20 01:08 +0000
              Re: Understanding && Arno Welzel <usenet@arnowelzel.de> - 2021-04-18 00:49 +0200
                Re: Understanding && Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-18 17:26 +0100
          Re: Understanding && Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2021-04-17 17:05 +0200
            Re: Understanding && Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-17 23:04 +0100
              Re: Understanding && Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2021-04-18 00:48 +0200
                Re: Understanding && Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-18 17:13 +0100
                Re: Understanding && Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2021-04-19 21:58 +0200
            Re: Understanding && John G Harris <niam@jghnorth.org.uk.invalid> - 2021-04-18 18:20 +0100
          Re: Understanding && Arno Welzel <usenet@arnowelzel.de> - 2021-04-18 00:40 +0200
            Re: Understanding && Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-18 00:14 +0100
              Re: Understanding && Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-04-18 00:01 +0000
                Re: Understanding && Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-18 17:44 +0100
                Re: Understanding && Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-04-18 17:51 +0000
              Re: Understanding && Arno Welzel <usenet@arnowelzel.de> - 2021-04-19 13:41 +0200
                Re: Understanding && John G Harris <niam@jghnorth.org.uk.invalid> - 2021-04-19 15:02 +0100
                Re: Understanding && The Natural Philosopher <tnp@invalid.invalid> - 2021-04-20 17:40 +0100
                Re: Understanding && John G Harris <niam@jghnorth.org.uk.invalid> - 2021-04-20 18:19 +0100
                Re: Understanding && The Natural Philosopher <tnp@invalid.invalid> - 2021-04-21 10:11 +0100
                Re: Understanding && John G Harris <niam@jghnorth.org.uk.invalid> - 2021-04-21 19:46 +0100
                Re: Understanding && The Natural Philosopher <tnp@invalid.invalid> - 2021-04-22 13:48 +0100
                Re: Understanding && Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-19 21:28 +0100
                Re: Understanding && Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-04-19 21:56 +0000
                Re: Understanding && Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-19 23:13 +0100

csiph-web