notb

shbobo.net

Google does the same kind of software interviews as anywhere else. They aren't special. You code on a whiteboard and it's supposed to be compilable in C or Java. The process beyond that is just as subjective as anywhere else and is largely based on gut. They depend largely on employee references/friends.

The data they collect is really only to make the process more efficient, not more effective. They reward employees that process the most phone screens in a month. The strangest thing, in my opinion, is that the interviewers usually don't make a decision at all, they just give a rating. Then, a group of people who've never even met the candidate decide whether to hire them based on forms that were filled out.

But.. Socket.io is built in sooo realtime ... Right?

Probably could be considered a competitor. This offers socket.io built-in, but doesn't seem to have the reactive data binding templates like meteor. This looks to be a Ruby on Rails for node.

There's a whole spectrum of users, as well. Programmers can be Python users, wherein the python implementation takes complexity hits to simplify it for the user.

It's all subjective, and the design of the high level concepts (maybe mechanics?) influence the complexity at every level below it. The idea of a 'file' goes from the GUI down to the hard disc format.

Can't tell if trolling... every single icon has a different drop shadow.

Seems like a disadvantage to me. It's mostly just confusing and the only thing it affords is the ability to use :keywords as functions (:like so) which is just sugar for property access, so["like"]. This is broken, though.

The coolest thing about :keywords in Clojure is that they really are functions and you can do things like (map :keywords ontoSomething) to extract the same property out of many things. It don't work in Wisp.

The work FOR us theme is present throughout. I'd guess it was intentional...

This has been my experience with recruiters but once you get past the wall of pleasantries and fake attitudes, they usually talk with more sense.

Edit: Sibling comments are talking a lot about the author's personal motivating factors but are ignoring the bigger message of poor hiring tactics like repeating talking points and marginalizing personal goals. I got you, though, op.

I think he's asking how it got so obfuscated in the first place. Seemingly, the spammers could just pilot a standard up to date client with a bot, rather than try and figure out the protocol.

I'm sure it's more complicated than that however, like client side rate limiting or something.

The whole aesthetic seems wrong. The perfect circles and even lines seriously clash with the naturally drawn clefs. In the example music, they adopt a new font for the time signature to blend in better, I guess, but the clefs are still out of place. There's an appealing naturalness to traditional notation that this system abandons and ends up looking like a schematic or alien code. Should really work the style into a more natural feel. There's potential here, but it's falling a bit flat (a pun and also literally the lines are too flat).

The sharps look like a guy flipping the bird. And the flats look a guy with a fist, ready to fight. Funny but a bit distracting.

The focus on pitch letters (abcdefg) and lack of key signatures reveals a weak music theory foundations. The key says what scale to use and then you think about the relative positions, you don't think about the letters.

It feels a bit like training wheels for reading music. Maybe thats the real purpose?

I don't understand these questions:

“Is optimization of speed premature while productivity languishes?”; “Are semantic elegance and lexical simplicity just means by which to further our productive capacity?”

The flowery language is confusing me. Is there any real content here? I've never heard anyone talk about programming languages like this. Writing like this just makes it harder to understand and seems like putting on airs

Its also a self fulfilling prophecy. When everyone colludes to start selling at the $200 mark, it will certainly burst.

Lexical scoping is a term to classify languages. The 'point' is to make it easier to understand how a language behaves.

If you want to have var with the same name as something in an outer scope, there are ways to do it, specifically an IIFE.

Here's an article for you: https://github.com/raganwald/homoiconic/blob/master/2012/09/...

That article points out a design decision that the author disagrees with. It does not prove that CoffeeScript's scoping is broken.

Very good introduction to Lisp, as well.

Oh I see. Yes I was thinking of alpha-equivalence, sorry.

Now I must ask, do you know any good papers/algos on that reduction? And how would you envision animating? It seems a bit like a lambda/var pair just fall off...

Agreed, it is unwieldy. However, because of it, eta-reduction is not as important because equivalent terms look the same, and name collisions can't happen. It made it a bit simpler.

And, that is definitely a bug, thanks. I think I could solve it by lazy evaluation (it wouldn't reduce that term) but I think I just need to correctly change vars when they move scope.

Right, thanks! Corrected.

Yeah. I was trying to balance more common terms and descriptiveness.

I honestly have no idea what a precise name would be. S-exps are actually a super set of these right?

The source is kinda crude at this point, but I hope to eventually allow named abstractions as well as direct manipulation of the tree (click n drag). Supporting types might be interesting as well.

Spoiler alert: Ender commits xenocide just to prove his worth. Is that a win?

I agree. Ultimately, he does all the things he does because the system is using him. Harry Potter is closer to a perverse ideal than Ender.

In honor of the Y-Combinator, here's a nearly equivalent fixed-point combinator named Gordan.

  An eater, Ditto
    who becomes Ditto's food eating
      Ditto's food
  
  An eater, Gordon
    who becomes Ditto eating
      an eater, Freeman
        who becomes
        Gordon's food eating
          Freeman's food eating
            Freeman's food.

I dont think so... c() would be evaluated first which is inconsistent with the other examples

Edit: I realize vemv's examples are inconsistent as well