I'm doing a meetup talk about my game next week and one of my slides is literally "**** Typescript".

Doing God's work.

I was all set to like typescript btw. And I am fine with it with Angular 2 since auto-complete is nice for a massive framework with a million built in components, and webpack works a lot more seamlessly in the browser. But typescript with node is an abomination.

We're using Typescript. I'm not sure if I have a strong opinion, as of yet. It's been a few months. I am not a former java dev, but I've done a fair amount of Scala so maybe it functions the same way. If anything the main plus so far imo is being able to write ES6 and compile to ES5, but I suppose babel would accomplish the same thing.

In large projects i do also like static typing. It makes it easier to know what you have to fix when you decide it's time to refactor something. I don't think that's totally worthless. On the other hand, JSON and static typing are sort of annoying together, a problem I have dealt with a lot in scala.

As is typically the case in these conversations, I'm not sure which side is right :P

Those things can very easily be done in C# (pretty sure Nullable<T> is equivalent to Option) with generics. They just haven't, for whatever reason.

TypeScript kind of sucks because it's layered on top of an existing language, rather than being built in in a way which makes sense. Java kind of sucks because it's Java. Neither is an indictment of static typing. Using C#'s functional programming, especially LINQ with Intellisense, is easily the nicest programming experience I've ever had. I don't need dynamic typing when I can map things into anonymous types and have the compiler still able to check typing and the IDE still able to autocomplete everything.

I agree that typescript being a compile-time superset of JS creates some pretty goofy scenarios. I also agree that C# has some pleasant features. I don't really miss Visual Studio though, TBH :P

So far I don't mind typescript that much though. It's mostly fine. I'm having a harder time getting used to ruby, although part of that is just I'm not doing a lot of it, just enough to be perplexed. And ostensibly there's a lot of ruby features I like. Apparently I just can't deal with languages that don't have curly braces.

haha I love Typescript. ofc, before that I used Java and C#.

Oh, we're having this conversation again?

Yeah but this time we're going to settle it forever

TS is wonderful. I was wishing I could use it (instead of vanilla JS) at work this week for a dependency management script I wrote, but then I'd have to make sure everyone installed it. It adds a layer of enforced correctness to your code (would have been helpful to have when I decided to change an array of items used in many places into a dictionary keyed on item name) that JS otherwise lacks, and if you get into a weird situation where it's too hard to use in your code, you can just type your vars as "any" and it basically becomes optional.

Why?

TO THE DEATH

Random dumb question.

So I've finally started writing tests and I'm currently not 100% sure how to pass props into components in tests (using jest/enzyme) to pass PropType checks. The examples on stackoverflow don't work of just adding it like you would normally with jsx in render.

In my experience, the sliver of run-time errors that would be caught by type-safety but not by a good linter is very small. Maybe it's a node thing. I don't have a ton of experience with TS in the browser other than angular 2 - which as I've said is probably the best application of TS for the code completion alone.

Lol I had to solve both of these in an hour:

First one I figured out very quickly but since it had to be in C, the syntax and semantics took me about 25 mins. The last one I had no idea how the **** to do: I knew i could solve it recursively using the left operand, the sign, and then recursively solve the right operand but parsing it I was having difficulty doing under the 30 mins I had so I just sent an explanation of how I'd approach it.

I'm hoping my 6 line solution of #1 will save me.

#1 is there a better way to do it than just iterate over the binary digits comparing them?

#2 the parsing is kind of gross. I'd do it like this:

1. Remove the external parentheses, if there are any.
2. Find an operator which, when you split the string on it, results in an equal number of left and right parentheses on either side. So for instance, (1 + 2) + (3 + 4). If you split on either "wrong" operator, there are unequal numbers of left and right parentheses in the two split strings. If you split on the "correct" operator, you get 1 of each on either side. This will guarantee the operator is not within parentheses.
3. Recurse on each operand.

The way I'm doing the parsing is not very efficient, I'm sure there are better ways.

Another way would be to use regex to search within the string for parenthetic expressions. Something like

Then you can replace them with their evaluation and repeat. That's probably even less efficient.

Because each paren group can only have left, operand, right, it's fairly easy to do recursively. You need a method to tokenize the input, which is basically

- if the first character is a paren, grab the whole contents of that group (including sub-groups), that's your first token. Call the evaluating function (recursively) on that group, which will do the same thing to all the sub-groups inside of it, and finally return a numeric value. If the first character is not a paren, then it is just a numeric value

- then grab the operator

- then grab the third token, which again is either an expression (which you recursively evaluate to a numeric value) or a numeric value

- perform the operation on the left and right values

It would be slightly more complicated if you could have multiple operators in the same expression, but that's explicitly disallowed.

That's probably a good result. Based on your earlier interviews it sounds like they want someone who can use math to solve problems. I think the typical solution to #2 would be to put the operations in a stack. It can be done like that without much code so you could conceivably solve both in an hour but you would need to recognize the ideal solutions right away. Probably not many people who do that.

My solution to #1 is compare first bit to last bit, 2nd bit to 2nd to last bit, etc. it’s log(n), not sure you can do it faster than that.

A little more than 6 lines i guess. The if clause is messy because for some ****ing reason, get_bit kept returning the integer value of the kth bit. I explained that in my email.

It does work i’m pretty sure though.

I need to sign up for leetcode and grind the *** out of puzzles, i’m really rusty

You could replace your length loop with int len = (int)(log(n)/log(2))+1;
Check for n==0 first though.

This is O(n) not O(log(n))

no because i'm only iterating through the bit representation of a decimal number n, which is O(k) where k is the number of bits in the decimal number, which is log n

the function grows logarithmically w/ respect to the integer, not linear

it's kind of nitty but I'm 99% sure. in my solution i said "It's O(k) where k is the number of bits in n's binary representation"

If I read correctly that your maximum arg size is 64 bit, then worst case is O(1). When I interviewed at Google I encountered one person who was pretty pedantic about something like that.

Haha, you’re right! Good catch

if that was the answer he was looking for, I'm glad I phrased my answer the way I did.