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.
> 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.
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.
> 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.
This wouldn't really be Hacker News unless an arrogant Lisp devotee shows up and claims that Lisp does everything better, so I'll now try to be that arrogant Lisp devotee.
Sean Johnson has given a fantastic talk about pattern matching in Clojure:
"Dynamatch addresses these challenges by enforcing a certain structure in our ordering of match clauses such that many of the incidental complexities of order dependence in a dynamically extensible pattern matching system become more manageable."
Sometimes it seems like Erlang or Haskell has the last word in Pattern Matching, but I'm not aware of anything like Dynamatch in those languages.
No thread on HN would be complete without the JavaScript programmer jumping in to "well actually" your response, so I formally nominate myself to fill that role. ECMAScript is getting pattern matching! It's currently a stage 1 proposal with backing from Microsoft, npm, and Facebook.
I don't think pointing the way to a better understanding of the problem is arrogance, especially when these type of posts effectively just add to other learners' misunderstandings. I can tell the poster is still learning due to that title, and because they call a switch statement on constants "typical" (as opposed to seeing it as a broken implementation of match).
The fundamental issue is called the "expression problem", and arises because the problem of assigning behavior is two dimensional (one dimension is the types/cases, the second dimension is the methods/operations), and possibly open along either dimension. Match works better when the methods/operations are open. Objects work better when the types/cases are open. If they're both open, then you need to figure out which one to make less open. At best, you can carve off partial sections where one particular dimension is open by fixing the other dimension, etc.
CLOS kind of punts and has you express each element of the matrix on its own. Which doesn't actually solve the problem, but at least makes it symmetrical.
That is the state of the art, AFAIK. Fixing the problem along either dimension is enough to make a workable language, but neither one is "better". There could be something better, but we haven't found it, and we're certainly not going to find it if people don't appreciate the whole problem!
What about method dispatch in CLOS, pretty sure that counts as "does everything better" - at least when it comes to mapping tuples of values to methods.
≥Object lookups are fast and they're faster as their size grow
It's difficult to imagine a switch large enough where the performance difference would matter, but this ignores the memory required to store the lookup in the first place. In all of the switch examples a switch is more straightforward.
In the latter examples (see the Boolean example) we now perform the lookup twice if the value is present. I feel like this is just another case of "use the right tool for the job".
A lot of C/C++/Fortran compilers have very well-developed handling for huge switch statements because of generated code. Interpreters and other finite state machines, etc etc.
I seem to remember some colleagues once getting performance problems because V8 didn't optimize switch-cases with more than 512(?) cases. Which was easily solved by adding an "if", splitting the table into two, until V8 removed or raised that limit.
If you're using an object, the object and any closures in it also need to be constructed on each execution. If the object is large, you're not just doing a lookup, you're constructing a full map object.
With a switch, there is no up-front allocation, case expressions are only evaluated if the case is reached, and the body of a case is only evaluated if the case is executed. The lookups are hardly the performance concern.
While you can use any value as an object property key in JavaScript, I’m not convinced the negative performance tradeoffs are worth the supposed benefits in the article.
I appreciate `switch` - with its case-fallthrough surprises beginners but most C-style languages all share this quirk - and modern-day compilers and linters will gladly remind you that usung Duff’s Device-type tricks in JS don’t work.
As an aside, in C#, a string-based switch statement is actually compiled to a lazily-initialised hidden Dictionary<String,Int32> object where the values are the real integer case values - so kinda similar to the linked article - except without the runtime possibly reallocating and reinitialising the dictionary object on every invocation.
The author's basic complaint with the Javascript switch statement is that it's essentially a structured series of 'goto' statements. They think that each 'case' should behave as an 'if-else' where each case has its own lexical scope, and the control flow doesn't leak from one case to another. They think that pattern matching is a better model for 'switch' in practice.
How often do you use a 'switch' statement whose cases don't always end in 'return' or 'break'? The "coroutines in C" [0] article is a clever use of switch-case as a goto, but it seems like you need to invent new types of control flow to use 'goto' properly. Does anyone have other clever uses of 'switch'?
The goal is to accept a 'filter' argument that can either be a string, an array of strings, a regular expression, or a filter function. It fully uses fall-through and the multiple entry points. I find it magical, in that it turns all of those into a function so the remainder of the code doesn't have to care, and it's not any less efficient. Similar feeling to finding a use case for 'Infinity' :)
switch (type(filter)) {
case 'array' : filter = filter.join('|')
case 'string' : filter = new RegExp('^('+filter.replace('*', '.*')+')$', 'i')
case 'regexp' : filter = filter.exec.bind(filter)
case 'function' : return filter
}
I would like it better if switch statements used the keyword `continue` to fallthrough and `break` is implied.
Switch statements are much easier to maintain if you keep them one or two lines long, and just have it immediately delegate to a function call then break. I think that's true for almost any code-flow syntax: if/elseif/else blocks, various loops. They all break down quickly if you have too much in them.
I agree. Their complaint on the use cases (pun!) for switch seem to ignore the flexibility of the syntax. I don't think the requirement to include breaks/returns is a problem if you know how it's intended to work. I prefer switches for the easy to follow flow but also the ability to "waterfall" multiple conditions, which is syntactically clunky with other approaches.
I mean, they're both useful for different purposes.
When you're dealing with 4 possible values, each of which will result in wildly different code (e.g. evaluating the value of a options variable, or handling error codes that mean very different things), then switch is clearly the way to go.
When you're dealing with 20 or 200 different values, all of which map to a few similar variations, then defining an object or array lookup is clearly preferable.
"Preferring" objects over switch statements is like saying you prefer bitmaps over vector drawings -- it's nonsensical. Different tools are better for different jobs.
I remember getting in arguments when I was doing F# over my use of Maps of functions to basically handle dynamic dispatch. I would construct a map like `let handlers = [| "somekey",func1; "otherKey", func2 |] |> Map.ofArray`, and then when I needed to handle something down the line, I would write something along the lines of:
let myHandler = defaultArg (Map.tryFind theKey handlers) (fun x -> //default stuff)
myHandler theValue
....
I liked this approach, since I could dynamically add functionality, and it could be completely decoupled from the business logic, and I didn't have to use strings for keys, but my coworkers didn't like that how dynamic it was, since in fairness, it did sometimes make it a bit more difficult to figure out which path the code was going to go down.
Never really determined who was "right" in this case, but this post reminded me of that.
I wrote an old computer emulator in javascript. The inner loop is a large switch statement where each case handles one of 256 opcodes. Firefox handled it fine, but chrome performance was poor. It turns out that above a 128-way switch, the jit gives up (or it seemed to).
First I tried doing what the author suggested -- having 256 routines, and a dispatch table. Chrome performance got better, and Firefox performance got worse.
In the end, the fastest thing to do was to have "if (opcode < 128) { 128-way switch } else { 128-way switch }".
In Swift, switch is my new favorite tool, combined with Swift's enums and amazingly strong native pattern matching. It has absolutely changed how I write code, and makes me wish it were a tool I could reach for whenever I'm working in another language. Some examples: http://austinzheng.com/2014/12/16/swift-pattern-matching-swi...
Came here to say this. Many of the complaints about switch statements are about classic, kinda terrible, implementations of switch statements. Swift gets that right. Like, really super right.
I'm conflicted. Swift's switch is powerful, but it's also complex, and even after using it for years, I still have to occasionally look up the syntax for some variant. Other HLLs have other ways of accomplishing these tasks that work just as well.
The whole language feels like they crammed every possible feature into every other feature, as a cartesian product of syntax, rather than as Lisp or Tcl or Forth does, with simple syntax that's flexible so everything naturally works everywhere. Someone even made an http://fuckingifcaseletsyntax.com for Swift, so I don't think I'm alone here.
You can really see the C legacy by the name and overall structure. I still miss the simplicity and flexibility of COND, and :keywords. It's nice that Swift can identify unhandled enum cases, I guess, but I can't say that's ever been a problem I've run into.
Most of the examples here I would prefer to write as a dictionary literal (more declarative), or possibly a method on the enum (easy in Swift). It's only single-dispatch, but it's still much better than burying functionality inside single-use, untestable switch statements in the middle of a func. If something is useful enough to justify writing 8 or 10 lines of code to handle a set of cases, then I guarantee I'm going to want to evaluate it in the debugger next week.
The older I get, the less Turing-complete code I want to write. Code is a liability. Constant tables are pure value. Switch, then, is the worst: it takes something which looks very much like a constant table, and forces it to be code.
The article provided some good examples of times when code readability can be increased without a bulky switch statement. However, there are times when I find the switch statement most closely communicates the idea of what needs to occur to some developer in the future.
As someone who has migrated between heavy use of these patterns in the past (object -> switch), I'd like to provide a few counterpoints.
First, and this is more of a general observation for any kind of programming content, these pompous-sounding abstract value judgements need to stop:
1. Is more structured.
2. Scales better.
3. Is easier to maintain.
4. Is easier to test.
5. Is safer, has less side effects and risks.
Regarding `switch`, only the last is a fact and that's because of the `break` statement peril. Still there aren't really side effects or other 'risks' involved. Everything else is completely subjective and not supported by the examples above - I, for example, find switch easier to maintain as you don't need to juggle variables defined outside the object to keep it clean.
Second, these articles use innocuous examples that don't reflect real use cases, and hence fail to demonstrate their utility. You'll find a ton of switch statements in any kind of parser since it's the perfect construct for the occasion where each branch can wildly differ in content and complexity, and might embed flow control that would complicate the object-based version:
switch (node.type) {
case "Identifier":
case "ObjectPattern":
case "ArrayPattern":
break
case "ObjectExpression":
node.type = "ObjectPattern";
for (var i = 0; i < node.properties.length; i++) {
...
}
break
case "ArrayExpression":
...
}
Finally, `switch` is wonderful when paired with `return`, since it eliminates point 5 above. Sample taken from a project I have lying around:
switch (unit) {
case 's': return value * 1000;
case 'm': return value * 1000 * 60;
case 'h': return value * 1000 * 60 * 60;
case 'd': return value * 1000 * 60 * 60 * 24;
default : return null;
}
With the key lookup, you'd also end up precomputing all of those values (imagine that's a slightly more expensive operation than simple math), or turning each one into a function. Another good example is the state reducer pattern:
switch (action.type) {
case 'ADD':
return state.concat(action.payload);
case 'REMOVE':
return state.filter(item => item.id !== action.payload.id);
default:
return state;
}
The key lookup pattern can hold its own in the simple cases, but it's hard to justify it with anything more than stylistic preference.
This is exactly correct. The cost of holding the entire object in memory, for any significantly complex statement, is going to add up quick if you're dealing with large numbers of users/pageviews/etc. The cost of pre-calculating everything in the object for any complex math similarly gets large when you're dealing with something large-scale. Early returns matter a lot with scale, and make [code line of sight](https://medium.com/@matryer/line-of-sight-in-code-186dd7cdea...) much clearer -- which matters a lot of if your team scale is larger, as in many companies that might have multiple teams working on one shared codebase.
I don't know javascript, but in the proposed "structured" code, doesn't it execute initialization statements for every potential cases even when you call it only once? I.e.,
Now "const email = ..." will be executed every time even when you're just asking for password. Eventually, such a code "scales", become a bloated behemoth with twelve cases, called a hundred time deep inside a server, initializing everything every time it is called, with potential side effects...
...and then one day a starry-eyed new hire looks at the top-level code, thinking "Heh, this is an internal graph server, why does it need customer email addresses?", removes the top-level config line, and then suddenly all internal dashboards go blank because they can't read email addresses.
...Yeah, you can probably tell that I'm not a fan of this technique.
Fun fact: There's an optimization technique for OO languages called polymorphic inline caching that boils down to... a switch statement that speeds up method dispatch by branching directly to a method implementation for one of a few common types. If the object is none of those types, it falls through to a more conventional method lookup.
The discussion is missing the most important point, IMHO: readability and maintainability of the larger system in the long term.
I used to love objects and multimethods (or single-dispatch multimethods for those more limited languages). But then I ended up debugging a large code base which used them extensively. It is a nightmare: by reading the code, there is no way to find out what all the dispatch options are, and without interactively debugging it there is no way to see which code will get called (inheritance messes things up greatly).
I think performance is secondary to these problems, so these days I prefer switch statements (or pattern matching), for their simplicity and reliability.
I've never used this pattern in Javascript, but it's somewhat common in Python because of how handy the dictionary.get() method is. A few problems TFA solves in JS are much easier with .get(), like defaults and false values.
Plus the fact that python doesn't have a switch statement so you kind of have to use a dict if you want that functionality without a long chain of if/elif/else.
[+] [-] sklivvz1971|7 years ago|reply
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.
[+] [-] lucideer|7 years ago|reply
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|7 years ago|reply
[+] [-] georgeecollins|7 years ago|reply
[+] [-] s_tec|7 years ago|reply
[+] [-] Scooty|7 years ago|reply
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.
[+] [-] lkrubner|7 years ago|reply
Sean Johnson has given a fantastic talk about pattern matching in Clojure:
https://www.youtube.com/watch?v=n7aE6k8o_BU
He offers some interesting comparisons between Clojure and Erlang.
Going even further, I recently discovered Dynamatch:
https://github.com/metasoarous/dynamatch
"Dynamatch addresses these challenges by enforcing a certain structure in our ordering of match clauses such that many of the incidental complexities of order dependence in a dynamically extensible pattern matching system become more manageable."
Sometimes it seems like Erlang or Haskell has the last word in Pattern Matching, but I'm not aware of anything like Dynamatch in those languages.
[+] [-] bastawhiz|7 years ago|reply
https://github.com/tc39/proposal-pattern-matching
[+] [-] mindslight|7 years ago|reply
The fundamental issue is called the "expression problem", and arises because the problem of assigning behavior is two dimensional (one dimension is the types/cases, the second dimension is the methods/operations), and possibly open along either dimension. Match works better when the methods/operations are open. Objects work better when the types/cases are open. If they're both open, then you need to figure out which one to make less open. At best, you can carve off partial sections where one particular dimension is open by fixing the other dimension, etc.
CLOS kind of punts and has you express each element of the matrix on its own. Which doesn't actually solve the problem, but at least makes it symmetrical.
That is the state of the art, AFAIK. Fixing the problem along either dimension is enough to make a workable language, but neither one is "better". There could be something better, but we haven't found it, and we're certainly not going to find it if people don't appreciate the whole problem!
[+] [-] arethuza|7 years ago|reply
[+] [-] agumonkey|7 years ago|reply
David Nolen publicly used some paper about optimized PM
[+] [-] AnimalMuppet|7 years ago|reply
[+] [-] EpicEng|7 years ago|reply
It's difficult to imagine a switch large enough where the performance difference would matter, but this ignores the memory required to store the lookup in the first place. In all of the switch examples a switch is more straightforward.
In the latter examples (see the Boolean example) we now perform the lookup twice if the value is present. I feel like this is just another case of "use the right tool for the job".
[+] [-] greglindahl|7 years ago|reply
[+] [-] detaro|7 years ago|reply
[+] [-] bastawhiz|7 years ago|reply
With a switch, there is no up-front allocation, case expressions are only evaluated if the case is reached, and the body of a case is only evaluated if the case is executed. The lookups are hardly the performance concern.
[+] [-] rgoulter|7 years ago|reply
The JavaScript 'object' here is called "map" or "dictionary" etc. in other programming languages. (And the article's technique is fine).
[+] [-] DaiPlusPlus|7 years ago|reply
I appreciate `switch` - with its case-fallthrough surprises beginners but most C-style languages all share this quirk - and modern-day compilers and linters will gladly remind you that usung Duff’s Device-type tricks in JS don’t work.
As an aside, in C#, a string-based switch statement is actually compiled to a lazily-initialised hidden Dictionary<String,Int32> object where the values are the real integer case values - so kinda similar to the linked article - except without the runtime possibly reallocating and reinitialising the dictionary object on every invocation.
[+] [-] rovolo|7 years ago|reply
How often do you use a 'switch' statement whose cases don't always end in 'return' or 'break'? The "coroutines in C" [0] article is a clever use of switch-case as a goto, but it seems like you need to invent new types of control flow to use 'goto' properly. Does anyone have other clever uses of 'switch'?
[0] https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
[+] [-] ricardobeat|7 years ago|reply
https://github.com/ricardobeat/require-tree/blob/master/inde...
The goal is to accept a 'filter' argument that can either be a string, an array of strings, a regular expression, or a filter function. It fully uses fall-through and the multiple entry points. I find it magical, in that it turns all of those into a function so the remainder of the code doesn't have to care, and it's not any less efficient. Similar feeling to finding a use case for 'Infinity' :)
[+] [-] xahrepap|7 years ago|reply
Switch statements are much easier to maintain if you keep them one or two lines long, and just have it immediately delegate to a function call then break. I think that's true for almost any code-flow syntax: if/elseif/else blocks, various loops. They all break down quickly if you have too much in them.
[+] [-] ivyirwin|7 years ago|reply
[+] [-] ioddly|7 years ago|reply
I do, occasionally. I prefer the inverted golang switch where fallthrough needs to be specified, since these cases (heh) are generally the minority.
[+] [-] crazygringo|7 years ago|reply
When you're dealing with 4 possible values, each of which will result in wildly different code (e.g. evaluating the value of a options variable, or handling error codes that mean very different things), then switch is clearly the way to go.
When you're dealing with 20 or 200 different values, all of which map to a few similar variations, then defining an object or array lookup is clearly preferable.
"Preferring" objects over switch statements is like saying you prefer bitmaps over vector drawings -- it's nonsensical. Different tools are better for different jobs.
[+] [-] tombert|7 years ago|reply
let myHandler = defaultArg (Map.tryFind theKey handlers) (fun x -> //default stuff)
myHandler theValue ....
I liked this approach, since I could dynamically add functionality, and it could be completely decoupled from the business logic, and I didn't have to use strings for keys, but my coworkers didn't like that how dynamic it was, since in fairness, it did sometimes make it a bit more difficult to figure out which path the code was going to go down.
Never really determined who was "right" in this case, but this post reminded me of that.
[+] [-] tasty_freeze|7 years ago|reply
First I tried doing what the author suggested -- having 256 routines, and a dispatch table. Chrome performance got better, and Firefox performance got worse.
In the end, the fastest thing to do was to have "if (opcode < 128) { 128-way switch } else { 128-way switch }".
That was 2014, so likely things have changed.
[+] [-] yosser|7 years ago|reply
[+] [-] tengbretson|7 years ago|reply
[+] [-] oflannabhra|7 years ago|reply
[+] [-] paultopia|7 years ago|reply
[+] [-] ken|7 years ago|reply
The whole language feels like they crammed every possible feature into every other feature, as a cartesian product of syntax, rather than as Lisp or Tcl or Forth does, with simple syntax that's flexible so everything naturally works everywhere. Someone even made an http://fuckingifcaseletsyntax.com for Swift, so I don't think I'm alone here.
You can really see the C legacy by the name and overall structure. I still miss the simplicity and flexibility of COND, and :keywords. It's nice that Swift can identify unhandled enum cases, I guess, but I can't say that's ever been a problem I've run into.
Most of the examples here I would prefer to write as a dictionary literal (more declarative), or possibly a method on the enum (easy in Swift). It's only single-dispatch, but it's still much better than burying functionality inside single-use, untestable switch statements in the middle of a func. If something is useful enough to justify writing 8 or 10 lines of code to handle a set of cases, then I guarantee I'm going to want to evaluate it in the debugger next week.
The older I get, the less Turing-complete code I want to write. Code is a liability. Constant tables are pure value. Switch, then, is the worst: it takes something which looks very much like a constant table, and forces it to be code.
[+] [-] bigtech|7 years ago|reply
[+] [-] ricardobeat|7 years ago|reply
First, and this is more of a general observation for any kind of programming content, these pompous-sounding abstract value judgements need to stop:
Regarding `switch`, only the last is a fact and that's because of the `break` statement peril. Still there aren't really side effects or other 'risks' involved. Everything else is completely subjective and not supported by the examples above - I, for example, find switch easier to maintain as you don't need to juggle variables defined outside the object to keep it clean.Second, these articles use innocuous examples that don't reflect real use cases, and hence fail to demonstrate their utility. You'll find a ton of switch statements in any kind of parser since it's the perfect construct for the occasion where each branch can wildly differ in content and complexity, and might embed flow control that would complicate the object-based version:
Finally, `switch` is wonderful when paired with `return`, since it eliminates point 5 above. Sample taken from a project I have lying around: With the key lookup, you'd also end up precomputing all of those values (imagine that's a slightly more expensive operation than simple math), or turning each one into a function. Another good example is the state reducer pattern: The key lookup pattern can hold its own in the simple cases, but it's hard to justify it with anything more than stylistic preference.[+] [-] kaizendad|7 years ago|reply
[+] [-] yongjik|7 years ago|reply
...and then one day a starry-eyed new hire looks at the top-level code, thinking "Heh, this is an internal graph server, why does it need customer email addresses?", removes the top-level config line, and then suddenly all internal dashboards go blank because they can't read email addresses.
...Yeah, you can probably tell that I'm not a fan of this technique.
[+] [-] bitwize|7 years ago|reply
[+] [-] jwr|7 years ago|reply
I used to love objects and multimethods (or single-dispatch multimethods for those more limited languages). But then I ended up debugging a large code base which used them extensively. It is a nightmare: by reading the code, there is no way to find out what all the dispatch options are, and without interactively debugging it there is no way to see which code will get called (inheritance messes things up greatly).
I think performance is secondary to these problems, so these days I prefer switch statements (or pattern matching), for their simplicity and reliability.
[+] [-] androidgirl|7 years ago|reply
[+] [-] UncleEntity|7 years ago|reply
[+] [-] dewaine|7 years ago|reply
[+] [-] maxxxxx|7 years ago|reply
[+] [-] perfunctory|7 years ago|reply
[+] [-] makz|7 years ago|reply
It could be as well lookups on a hashmap.
Not very expressive.