5 ms·

Firstly, switches are arguably way, way (waaaay!) more readable than the code proposed. It's a matter of taste for sure, but arguably a basic construct of all c

by sklivvz1971 8y ago

Firstly, switches are arguably way, way (waaaay!) more readable than the code proposed. It's a matter of taste for sure, but arguably a basic construct of all curly languages and more is easier to understand than a rather esoteric code where a pattern is substituted for a keyword. Of course though, it is true that switch statements in JavaScript have issues with breaks and code blocks, but any half decent linter will tell you about those. Most importantly though, the performance profile of the solution proposed scares me a lot. To understand why, consider that it is not uncommon for switches to be JITted as: - If statements and gotos for small number of options or - Collections of lambdas for high number of choices (note, much more optimized than the lambdas proposed, very likely!) The reason they are built this way is performance (another commenter ...commented that performance doesn't matter - they are wrong, a switch can be nested in a hot loop ran millions of times and they do matter). Therefore, it's easily arguable that the presented pattern will significantly worse in some cases (few choices) and that should not be underestimated.

rojobuffalo 8y ago
switch statements are way more readable than what is demonstrated in the article. It's not even close.
- gramstrong 8y ago
  I disagree :) It's easier for me to look at an object and its contents and see where it is referenced. I think switch statements are ugly. I think if/else blocks are ugly. I prefer boolean statements when possible, although definitely not nested ternaries. I'm sure I'll get flamed, but I really liked this: const getPosition = position => ({ first: 'first', second: 'second', third: 'third' }[position] || 'infinite');
  - lhorie 8y ago
    I think equating ugly with hard-to-read is a common mistake. Many things are "ugly" but easy to read (e.g. in design circles, newbies often do far-too-small fonts with low contrast because it looks pretty, whereas accessibility guidelines tell you to do the opposite; in programming, readability of point-free style has more to do with the reader's ML-vs-Algol experience than how elegant FP may be, and educators often start w/ procedural style precisely because reading the flow of the program matches the students' expectations that things ought to be read top to bottom, rather than peeled through layers of abstractions) Honestly, I find that rating the readability of the object versions vs the switch statement is bikeshedding. This is perfectly readable and doesn't involve going back and forth with my eyes to figure out the data flow or figure out if I have mismatched brackets or what have you: const getPosition = position => { switch (position) { case 'first': case 'second': case 'third': return position; default: return 'infinite'; } } Another thing that is worth mentioning is that objects consume memory and allocating memory in JS for this is just wasting orders of magnitudes more cycles and sacrificing throughput for no good reason - other than to try to be clever and avoid an idiomatic and optimizable construct.
    - gramstrong 8y ago
      >I think equating ugly with hard-to-read is a common mistake This is just a semantics argument. I can replace "ugly" with "hard-to-read" if you want. I think it's both, in this instance. >Honestly, I find that rating the readability of the object versions vs the switch statement is bikeshedding. I agree in the context of code review, but since this is what we're talking about I figured I'd share my opinion. >Another thing that is worth mentioning is that objects consume memory and allocating memory in JS for this is just wasting orders of magnitudes more cycles and sacrificing throughput for no good reason - other than to try to be clever and avoid an idiomatic and optimizable construct. Premature optimization. If you need to optimize, then do it. Otherwise you should prioritize what you consider understandable and easy-to-write code. I guarantee the vast majority of javascript written would not be ill-affected by this.
      - lhorie 8y ago
        I'd ask you to reconsider what an optimization is, and to also consider the concept of "premature cleverification". A switch statement is a pretty idiomatic choice for the example. Merely knowing more about the low level cost of different options does not make a snippet an optimization. Examples of actual optimizations (from real world code I've seen) would include using bitmaps, lookup tables, large regexps, tries and binary search. All of these have the property of obscuring the search space in the name of performance, and many come with trade-offs such as increased startup cost or code size. Choosing to use a trie here, for example, without considering its trade offs would be a premature optimization. A switch statement is at worst a refactor that maintains the same algorithm.
  - chris11 8y ago
    My personal preference is if-else/switch blocks with enums. Doing conditionals with string parsing just seems gross to me, but I find conditionals easy to read. And the benefits of using an enum is that you can easily find where it is used, which makes reading the code and adding or removing options easier.
  - dymk 8y ago
    What happens when your values are computed? Or expensive to compute, and your map starts to get big? E.g.: {'a': foo(), 'b': bar() }[...] If foo() or bar() ever introduce side-effects or become expensive, you're gonna have a hell of a time figuring out what's going wrong.
    - Riobe 8y ago
      If your values are expensive to compute like that, then you'd have the object return a function that would call foo(), bar(), and so on; and you wouldn't call them all to setup the map in the first place.
      - Izkata 8y ago
        This is in fact demonstrated in the second example in "Working with functions"...
Scooty 8y ago
> another commenter ...commented that performance doesn't matter - they are wrong, a switch can be nested in a hot loop ran millions of times and they do matter I'm curious how often you find yourself dealing with loops that run millions of times? I think the majority of loops I've written don't need to deal with millions of iterations; most of them probably only rarely break 1000 iterations, and I know for sure that a lot of them can't exceed 100 iterations because of limits in the data. Seems to me that using a switch over another structure for performance at the expense of readability or maintainability is an example of premature optimization unless you're positive the condition is going to be in a hot loop.
- gameswithgo 8y ago
  moderately sized database, pixels on a screen
  - Scooty 8y ago
    Both of these seem like cases where you would know you're in a hot loop. I wasn't really clear in my comment that of course you should optimize loops that you know get run millions of times. I was saying: pick your tools based on the context of the code you're writing. Most simple applications involve tens or hundreds of loops that rarely iterate over more than a few values and don't get run more than once every few seconds.
  - zachrose 8y ago
    single-page web app doing n times the amount of work it should be doing because components are synced over an event bus with bindings set up wrong in a way that nobody has bothered to debug
- chrisseaton 8y ago
  > I'm curious how often you find yourself dealing with loops that run millions of times? I think the majority of loops I've written don't need to deal with millions of iterations It's trivial to come up with 80s-level counter-examples to this. A megapixel image, for example, is tiny.
s_tec 8y ago
Plus, you can solve all the issues the article points out using linting tools like ESLint. Rules like no-case-declarations, no-duplicate-case, and no-fallthrough already exist for this exact purpose.
georgeecollins 8y ago
And the problem with switch in example is solved with a set of brackets. Why is that so bad? That code with brackets would be clear.
- ezekg 8y ago
  It always surprises me how few people use brackets on switch statements when the situation calls for one.
lucideer 8y ago
> switches are arguably way, way (waaaay!) more readable than the code proposed The point in the article is not that switches are less readable, but that switches can be "less" readable. Or—more accurately—they can look like they're readable but obscure unexpected subtleties The object syntax may be slightly less readable than the switch in its simplest, most well-written form, but the point is that unlike the switch, it always unambiguously does what you expect. It's also worth noting that the object syntax is extremely idiomatic in modern JS. It may look less readable to a generalist, but to anyone regularly maintaining JS it's far more familiar than the switch. (I guess this isn't so much a point in it's favour, it's more a point against modern JS being easy to pick up, but hey). > it is true that switch statements in JavaScript have issues with breaks and code blocks, but any half decent linter will tell you about those. While you have a point about linters, and I do use a strict one in every project, I'm much more comfortable with it being a safety net than the first line of defence. Also, those problems with breaks and code blocks are hardly unique to JavaScript.

rojobuffalo 8y ago

switch statements are way more readable than what is demonstrated in the article. It's not even close.

gramstrong 8y ago
I disagree :) It's easier for me to look at an object and its contents and see where it is referenced. I think switch statements are ugly. I think if/else blocks are ugly. I prefer boolean statements when possible, although definitely not nested ternaries. I'm sure I'll get flamed, but I really liked this: const getPosition = position => ({ first: 'first', second: 'second', third: 'third' }[position] || 'infinite');
- lhorie 8y ago
  I think equating ugly with hard-to-read is a common mistake. Many things are "ugly" but easy to read (e.g. in design circles, newbies often do far-too-small fonts with low contrast because it looks pretty, whereas accessibility guidelines tell you to do the opposite; in programming, readability of point-free style has more to do with the reader's ML-vs-Algol experience than how elegant FP may be, and educators often start w/ procedural style precisely because reading the flow of the program matches the students' expectations that things ought to be read top to bottom, rather than peeled through layers of abstractions) Honestly, I find that rating the readability of the object versions vs the switch statement is bikeshedding. This is perfectly readable and doesn't involve going back and forth with my eyes to figure out the data flow or figure out if I have mismatched brackets or what have you: const getPosition = position => { switch (position) { case 'first': case 'second': case 'third': return position; default: return 'infinite'; } } Another thing that is worth mentioning is that objects consume memory and allocating memory in JS for this is just wasting orders of magnitudes more cycles and sacrificing throughput for no good reason - other than to try to be clever and avoid an idiomatic and optimizable construct.
  - gramstrong 8y ago
    >I think equating ugly with hard-to-read is a common mistake This is just a semantics argument. I can replace "ugly" with "hard-to-read" if you want. I think it's both, in this instance. >Honestly, I find that rating the readability of the object versions vs the switch statement is bikeshedding. I agree in the context of code review, but since this is what we're talking about I figured I'd share my opinion. >Another thing that is worth mentioning is that objects consume memory and allocating memory in JS for this is just wasting orders of magnitudes more cycles and sacrificing throughput for no good reason - other than to try to be clever and avoid an idiomatic and optimizable construct. Premature optimization. If you need to optimize, then do it. Otherwise you should prioritize what you consider understandable and easy-to-write code. I guarantee the vast majority of javascript written would not be ill-affected by this.
    - lhorie 8y ago
      I'd ask you to reconsider what an optimization is, and to also consider the concept of "premature cleverification". A switch statement is a pretty idiomatic choice for the example. Merely knowing more about the low level cost of different options does not make a snippet an optimization. Examples of actual optimizations (from real world code I've seen) would include using bitmaps, lookup tables, large regexps, tries and binary search. All of these have the property of obscuring the search space in the name of performance, and many come with trade-offs such as increased startup cost or code size. Choosing to use a trie here, for example, without considering its trade offs would be a premature optimization. A switch statement is at worst a refactor that maintains the same algorithm.
- chris11 8y ago
  My personal preference is if-else/switch blocks with enums. Doing conditionals with string parsing just seems gross to me, but I find conditionals easy to read. And the benefits of using an enum is that you can easily find where it is used, which makes reading the code and adding or removing options easier.
- dymk 8y ago
  What happens when your values are computed? Or expensive to compute, and your map starts to get big? E.g.: {'a': foo(), 'b': bar() }[...] If foo() or bar() ever introduce side-effects or become expensive, you're gonna have a hell of a time figuring out what's going wrong.
  - Riobe 8y ago
    If your values are expensive to compute like that, then you'd have the object return a function that would call foo(), bar(), and so on; and you wouldn't call them all to setup the map in the first place.
    - Izkata 8y ago
      This is in fact demonstrated in the second example in "Working with functions"...

Scooty 8y ago

> another commenter ...commented that performance doesn't matter - they are wrong, a switch can be nested in a hot loop ran millions of times and they do matter I'm curious how often you find yourself dealing with loops that run millions of times? I think the majority of loops I've written don't need to deal with millions of iterations; most of them probably only rarely break 1000 iterations, and I know for sure that a lot of them can't exceed 100 iterations because of limits in the data. Seems to me that using a switch over another structure for performance at the expense of readability or maintainability is an example of premature optimization unless you're positive the condition is going to be in a hot loop.

gameswithgo 8y ago
moderately sized database, pixels on a screen
- Scooty 8y ago
  Both of these seem like cases where you would know you're in a hot loop. I wasn't really clear in my comment that of course you should optimize loops that you know get run millions of times. I was saying: pick your tools based on the context of the code you're writing. Most simple applications involve tens or hundreds of loops that rarely iterate over more than a few values and don't get run more than once every few seconds.
- zachrose 8y ago
  single-page web app doing n times the amount of work it should be doing because components are synced over an event bus with bindings set up wrong in a way that nobody has bothered to debug
chrisseaton 8y ago
> I'm curious how often you find yourself dealing with loops that run millions of times? I think the majority of loops I've written don't need to deal with millions of iterations It's trivial to come up with 80s-level counter-examples to this. A megapixel image, for example, is tiny.

s_tec 8y ago

Plus, you can solve all the issues the article points out using linting tools like ESLint. Rules like no-case-declarations, no-duplicate-case, and no-fallthrough already exist for this exact purpose.

georgeecollins 8y ago

And the problem with switch in example is solved with a set of brackets. Why is that so bad? That code with brackets would be clear.

ezekg 8y ago
It always surprises me how few people use brackets on switch statements when the situation calls for one.

lucideer 8y ago

> switches are arguably way, way (waaaay!) more readable than the code proposed The point in the article is not that switches are less readable, but that switches can be "less" readable. Or—more accurately—they can look like they're readable but obscure unexpected subtleties The object syntax may be slightly less readable than the switch in its simplest, most well-written form, but the point is that unlike the switch, it always unambiguously does what you expect. It's also worth noting that the object syntax is extremely idiomatic in modern JS. It may look less readable to a generalist, but to anyone regularly maintaining JS it's far more familiar than the switch. (I guess this isn't so much a point in it's favour, it's more a point against modern JS being easy to pick up, but hey). > it is true that switch statements in JavaScript have issues with breaks and code blocks, but any half decent linter will tell you about those. While you have a point about linters, and I do use a strict one in every project, I'm much more comfortable with it being a safety net than the first line of defence. Also, those problems with breaks and code blocks are hardly unique to JavaScript.