When it comes to solving problems in an interview setting as a software engineer, few topics come up quite as often as string manipulation. And whe...
For further actions, you may consider blocking this person and/or reporting abuse
Thanks for sharing, i don't understand why you made it so complicated?
Just convert the string into an array with split, reverse the returned array, convert it into a string with join and compare it with the original string.
I think the author's main goal is to show the reader how to check if a string is a palindrome algorithmically, using javascript methods is fine but it makes the code idiomatic/would make most sense for a js dev.
Also, generally performance should never be a primary factor. Writing clean, easy to understand and maintainable code is the goal any dev should have. Because your example is idiomatic to js devs in a js codebase it will seem more intuitive to any new dev as opposed to the author's.
I saw a few comments talking about perf. Performance shouldn't be a decision factor. Performance can be optimized if it becomes a problem.
Yes, this was originally my goal. I love this that sparked so much discussion on different ways of approaching the same problem!
I mainly approached this (relatively simple problem) from the perspective of how someone might solve it in a more language agnostic, algorithmic way that touched on a few other aspects of problem solving that new developers might not have as much practice with, like moving pointers and checking/comparing string characters similar to how you might compare array elements.
I was aiming for more of an informational approach than the simplest solution, but I appreciate that there are comments on here now for folks to see other solutions that work as well (especially using in-built JS methods, since that's a perfectly valid approach too.) 😃
The combination of generally and never seems confused... and the sentiment is troubling...
Especially when developing software libraries,
Empathy should be out guiding principle, both for those inheriting and maintaining the code we write and for those consuming it.
"generally" => most cases so you can read it out as "in most cases, performance should never", which means performance should only be a deciding factor in specific situations where the operation is costly in some way, is used frequently, etc.
For example, the palindrome code from the post doesn't have to be optimized for performance but say you were batching a bunch of expensive asynchronous tasks, you could use Promise.all and generators together to do so. The question you should ask before working on this optimization is whether or not maintaining that extra complexity is going to bring any net benefit. For the palindrome example, there's little to no net benefit so going with an idiomatic approach is fine, even if it's slower.
I don't understand why you think that a library author is in no position to determine whether or not a performance compromise is problematic. Making decisions like that is literally the job of a developer. True, consumer's are in no position to resolve such problems, and that's exactly why building healthy communities is important, so consumers come back to you and tell you that something isn't doing the job well (when it comes to libraries, for product consumers, you can use analytics, performance metrics, etc.)
Yes, Empathy should be every developer's guiding principle, and unnecessary performance optimizations have nothing to do with being empathetic. I'm not saying optimizations are unnecessary but optimizing unnecessarily, is unnecessary.
Hi, i think your code look shorter and cleaner but the fact that author's code run faster with less complexity!.
Not so sure either we can do shorter and faster :-)
Less complexity? About performance, you can scale out, you need to write code which is easy to maintain, read and modify, when you look at original method, you won't know what's going on without some serious effort, with second one, within 2-5 seconds you understand exactly what it's doing
Don't get me wrong I like your algorithmic way better (it's probably faster too) but I have been on a kick lately trying to make things smaller. In case this is useful for anyone here is what I came up with in 6 lines. (probably better ways to do it too... bit shifting?)
Use like: