js-exercisms.md

Hamming

My code (here)

• Respoder #1(code): This implimentation has two main differences. 1 is that they explicitly check if the strings are equal and return 0 before they check element by element. While this is logically appealing, I believe that you would need to loop all the way through both strings to confirm equality, so if the strings aren't even then both strings are traversed one extra time. 2 is that they use recursion. Since it can easily and clearly be implemented without recursion, I believe the overhead of recursion means this isn't the best place for it

• Responder #2(code): This implimentation is very similar to mine, except that it casts the arrays to strings first. This is unnecessary since index notation can be used to access strings, however arrays may have better performance than strings.

• Responder #3(code): This implimentation is similar to mine logically, but it looks to be using ECMAScript6's class syntax rather prototyping. The difference I am a lot bigger fan of is where the error lives. An externally facing compute function checks if an error should be thrown, and if not goes and calls another function that computes the Hamming difference. This feels like better encapsulation.

• Responder #4(code): This implimentation differs from mine only in style. I believe there is way too much whitespace in this code, making it somewhat difficult to read. The stylistic thing that I do like about this using ++ rather than += 1 to increment. I wasn't sure if this was available when I wrote mine.

• Responder #5(code): This implimentation has a lot that I like and don't like. I like that functions were refactored out and then called into. I think that implimentation is quite a bit more complicated than it needs to be. I don't see the benefit of zipping the two strands into a nested array rather than just directly comparing the elements in two different strands.

Rna

My Code (here)

• Responder #1(code): This implimentation uses flow-control for looking up the transcription rather than the object I used in mine. I think that using an object to look it up is faster than checking against 4 cases every time. We both use the strategy of concatenating into a result string.

• Responder #2(code): This implimentation uses mapping. I like the idea of using a map here rather than just a naked for-loop, but when function for mapping is as simple as looking up a value in an object the value is less obvious. If the string was not split first, I believe the if-statement that checks for length == 1 could be gotten rid of.

• Responder #3(code): This implimentation has two things I think could be improved. The case statements seems wrong to me for the same reason I thought flow-control was inappropriate. The case statement makes this worse as it is more verbose and has an explicit break each time. Additionally, splitting the string, pushing into a result array and then joining the array is unnecessary.

• Responder #4(code): This is very similar to the previous implimentation. It uses case statements for flow control. However, in this case I believe that the single line cases make it much more readable. It is also uses string manipulation rather than casting to arrays first.

• Responder #5(code): This one likes case statements, which I don't like. However, I really like the fact that the cases are pulled out into a seperate method, which increases the encapsulation. I'm not sure if mine would be better with my object defined in a seperate method.

Bob

My Code (here)

• Responder #1(code): This implimentation uses regex. I'm not a huge fan of using regex here because the conditions can be simply phrased without regex. I have been taught that regex are 1) write-once, read never (nobobdy will understand your regex easily) and 2) since regex tries to find a match starting at each char in the string, they can be a big performance hog. This problem doesn't seem like it warrents regex.

• Responder #2(code): This implimentation also uses regex. However, I find it much more readable, as the regex are wrapped by definitions. This makes the main method body parsable without knowing what the regex do, and achieves better encapsulation. I think putting my logic into named functions could improve mine. This feels offset by the casting the string to an array. Why use an array when you can use index accessing on a string?

• Responder #3(code): This implimentation feels very similar to mine. The logic to check conditions is very similar, but the logic is wrapped by functions. The main difference in our logic is handling silence. Rather than checking if the trimmed input is === "", they return !input.trim(). Since input.trim() is falsey for the empty string and true for non-empty strings, this works. This sorta feels like abusing the wonkiness around truthy/falsey-ness in js, it is very terse.

• Responder #4(code): This implimentation is quite similar to mine. It uses a regex rather than trim to check for silence. This is fine, but I think a bit less clear than trim. Likewise, the logic for shouting is slightly different from mine. They check that upcase is equal to the input (which I do), and then check against a regex to see if it is made of letters. Instead,I check upcase is equal to input and that downcase is not equal to the input (which is the case for non-alphabet characters). I do like them using .slice(-1) to check the last characters.

• Responder #5(code): This implimentation is logically almost identical to mine, but stylistically quite different. They store the responses as an object, which is nice encapsulation, though I think it might be even better as a constant. I'm torn on the ternary operators - the code is already longer than most other solutions and would be quite a bit longer without them. On the other hand, without familiarity with the ternary operator, it is totally unclear what is happening. I like the use of .endsWith("?") even better than my method or slice for checking the final character.