kaosjester

When I was a TA, I'd have students constantly try to add me on Facebook. The conversation would go nearly exactly like you'd describe:

Are you on Facebook? Is this your profile?

Yes, but I'm not gonna accept your friend request.

The reply was usually a bit snarky with a bit of a chuckle, and that did it for most college-aged people. The few times someone persisted, I explained that Facebook is an aspect of my social life, not my professional life, and I intended to keep it that way.

This doesn't account for the whole picture. The tax benefit is dwarfed in comparison to the losses in social security people at and below the poverty line will suffer.

How can you blur the line? It's either online multiplayer or it isn't, there's not really an in-between. You can't "kind of" have other people connected to your game. They're either there or they're not.

Dark Souls does precisely this in a fantastic way in two major mechanisms. The first is the shared player "graffiti", wherein players can write messages that are then propagated into others' games. The second is the shared "death ghosts', which play back a player's last moments before death in others' games as a ghost you can't interact with. These make the game feel like you're playing with others in a large world without having to actually put you in the same instance.

It seems like this could be fairly easily resolved by the management having a rigid "we pay everyone the same, deal with it" position, perhaps up and and including a formula for salary computations.

Could you explain what this means?

Don't forget the part where those graduate students do some 80% of the work and make <20% of the income of their their supervisor (and, in many cases, <10% or none at all in several), and the university hosting the lab absorbs some 50% of all grants "off the top." A half-million dollar grant pays a single graduate student less than 20k/year for maybe 5 years, which, in the context of other companies that get these grants, is absurd. Independent research firms working from the same grants pay their employees competitive wages and still accomplish research. If these companies could issue Ph.D.s, academia would shrivel and die: imagine working at a company for 4 years, getting a salary 3-4x what a graduate school would offer, doing real work in a professional setting, doing enough research to write a dissertation, and receiving a degree. The entire incentive to attend a university would melt away.

1. The persistent approach is not right for global variables, which are dynamically bound. So I ended up needing two Environment classes, a Map-based one for the global scope, and then a persistent one for locals. That, of course, also requires an interface so that most code can work polymorphically with both types.

Can you give an example of what you mean?

"Global variables" are simply variables declared at a top-level scope. They don't need to be "dynamically bound" if you unravel the top-level into a sequences of statements that thread their environment (which is a bog-standard practice for interpreters, and how you should handle blocks, too), unless you'd like to be able to reference variables declared below you in the global scope. And that can be resolved by passing a dynamic environment in addition to the lexical one. Or by making a single pass over the global space, grabbing all the declared names, and making that your initial lexical environment. But, of course, this is all speculation without an example.

I considered having a problem exercise to do effectively that, but I felt like it might be reaching a little too far for a first-time language implementer.

Uniquely renaming variables is, in my opinion, a far simpler concept to grasp than nesting scope resolution. It would also be far easier to implement, with notably less code change, and continue to allow you to add another compiler pass and allow the reader to cover ground. The actual downside is that it achieves your goal without needing to explain the whole mess, which means the chapter doesn't get to spend time explaining how to think about resolving variables.

code like this is not common:

Your toy example is, obviously, a situation where you should reconsider what you're doing. However, a program such as

    lookup :: Env -> Ear -> Value
    lookup = ...

    f :: Env -> Expr -> Expr
    f env exp =
      let lookup = lookup env
      in ...

Also, for what it's worth, translating the above code to JavaScript yields a stack overflow error if you invoke lookup inside of `f`.

0. https://github.com/cisco/ChezScheme/blob/06f858f9a505b9d6fb6...

As someone with years of experience writing interpreters, this seems a rather sloppy solution to a straightforward problem. There are two canonical solutions, and he uses neither:

1. The first canonical solution, which the author even describes, is persistent environments. Unfortunately, this requires passing the current environment as part of the recursive pattern, which means heavily modifying the existing code. He doesn't do this because it would require revisiting too much.

2. The second canonical solution, which you would find in any modern compiler, is to uniquely rename all the variables. His "resolver" traversal has ample opportunity to do this, and would provide a far cleaner solution (with less space overhead than his expr/scope depth lookup table).

Instead, the author creates a stack of environments and annotates variables with information akin to de Bruijn indicies for scopes. Compared to the alternatives above, this is over-engineered and inelegent, plus it complicates reasoning about scopes far beyond what's necessary.

As an aside, this assertion is also completely absurd:

Shadowing is rare and often an error so initializing a shadowing variable based on the value of the shadowed one seems unilkely [sic] to be deliberate.

Don't forget the Harry Potter branding association. That's what will end up bringing in the big bucks.

Also, this gem:

We ate on the balcony and, as we shared a bottle of wine and listened to the chorus of insects, I began to think that the year of groundwork I had put in was about to pay off. Marylin stayed the night.

You should re-record the entire intro video and leave out all the 'um' and 'uh's. It makes the product seem far less professional.

My wife got angry quite a few times in graduate school because the university's Women in Computing group forcibly signed her up to their mailing list at the start of every academic year. She unsubscribed every year and, without fail, they silently added her back. Apparently they thought a woman in computing couldn't manage without being part of this group!

It's one thing to give people the space and support they ask for. It's quite another to shove space and support, unsolicited, upon them.

To be fair, GitHub is large enough that they'll have a dozen applicants by the time you're out the door. If resolving a problem is harder than firing part of it, well... that's the layer cake.

I'm moving out of a house right now in the midwest that bumped my rent by $100/mo each year, but they listed it back at my original rate this year. For some reason, being a multi-year tenant cost me an extra ~$3000.

I'm not saying it isn't faster, I'm merely pointing out that it was a pretty serious investment in comparison to the other points of the build, and attempting to defend the idea that liquid cooling isn't insane if you're going all-out with other aspects, too.

I agree that Ryzen is a great chip! I am looking forward to getting one because, yeah, it makes for a great developer platform: it's got a bunch of cores, it's got a fantastic virtualization model that isn't randomly crippled on half the chips, it supports ECC ram easily, and it's a killer price-point.

The article doesn't really get into any of that, though.

He also didn't need to blow $500 on an SSD when he could have gotten a $100 SSD and a $100 hybrid drive and double his storage space.

This article reads like a rewrite of the wiki over at /r/buildapc, and I'm not sure I see how much of it leads to his conclusion---any modern, $1500 desktop is going to outperform a two-generation-old laptop with a quarter as much ram. That doesn't make the Ryzen `for programmers.` I came in expected some crazy assembly insights, but instead this is just a PC build log. Nothing really supports the title of this article: it's just clickbait without any real support. And, at this point, most people reading hackernews know it's cheaper to build a PC than buy another PC / laptop---and those that still don't are doing it because a thousand dollars usually buys you a lot of warranty and convenience.

Perhaps unsurprisingly, Oleg rebuilt the linked implementation in Haskell [0]. It works exactly as you'd expect, right out of the box.

0. https://arxiv.org/abs/cs/0509027

Does this mean the socks won't come out of the dryer warm? That's sort of a deal breaker for me.

It would be easier to take this comment seriously if Go wasn't a modern re-implementation of ALGOL 68.

I'll admit that I have had Netflix recommend to me movies that it thought I would rate at one star, and I have watched that movie and then rated it one star. Not only did their current system predict that I would watch that movie, they predicted my relative opinion of the movie's quality. And yet I watched the movie, and thus felt like their recommendation system served its purpose. I have to say that going into it expecting a one-star rating allowed me to set expectations for the film.

If they remove the axis of quality and merely opt for "will you watch this: yes/no", it will make it harder to select "good popcorn trash" versus "high-quality, high-enjoyment" to fit my mood.

The sheer amount of misused punctuation in this comments section seems to indicate a systematic problem.

alter it is meaning

- In some places, yes. It varies from state to state and company to company, but most companies outside of California try to do this to you. (In California, this clause is illegal.)

- Move to California or negotiate a different contract. (It depends on if your employer wants a cut, how far they are willing to litigate, and if they can show they missed out on economic growth that you made (depending on the contract clause); you should always ask permission, even before contributing to open-source projects.)

- Yes, it is. While it is unclear if Carmack actually stole code from Zenimax, the actual evidence is easy to construe in Zenimax's favor, e.g., Carmack backed up all of his emails, many of which included attachments of VR code, before he quit, and the Oculus founder had an NDA with Zenimax while working on VR with them before starting the Oculus kickstarter. (I'm not sure about the situation with the rocket hobby.)

- Obviously this is the answer: talk to both internal and external council, and remember that internal council will be the people suing you if they get unhappy.

You can build a CEK machine (https://cs.umd.edu/class/summer2015/cmsc330/material/cek/), switching from big-step operational semantics to small-step operational semantics. Then you dump the CEK machine in a while loop that runs until the continuation is empty and the code is a value. (On a side note, this is how most C-targeting Scheme implementations work.)

This seems like a great system to enable fine-grained micromanagement at a glance. It's got a weird mix of 'overbearing manager' and 'Orwellian employment coverage' that seems to primarily support over-involvement in your employees' minute-to-minute tasks. And that isn't even considering how "your outplanr task chart" factors into those yearly performance reviews. ;)

This would be a great way to manage a household chore-chart, though...

This applies to more than just logos. So much design, when turned into a public matter, suffers.

Advocating a ternary structure isn't particularly insightful, and ternary trees aren't particularly efficient as data structures (they're to rebalance, etc).

I really hate the phrase "fighting". Calling it a fight doesn't do justice to the conversations you have with the borrow checker when you use Rust every day. You don't fight with the borrow checker, because there isn't a fight to win. It's far more elegant, more precise. It's fencing; you fence with the borrow checker, with ripostes and parries and well-aimed thrusts. And sometimes, you get to the end and you realize you lose anyway because the thing you were trying to do was fundamentally wrong. And it's okay, because it's just fencing, and you're a little wiser, a little better-honed, a little more practiced for your next bout.