abhayb

Former student and TA here. There is so much great stuff in this class and its assignments! Couple of highlights:

- Data lab formally verifies all of the submissions and gives you an exact failing test case if the submission isn't correct.

- Malloc lab is run competitively. You don't need to compete to do well, but you do if you want to do great. And the competition drives students to great feats. I know people who rewrote their inner loops in assembly to get better perf. Another built splay trees to get lower fragmentation. They both had comfortable A's in the class at the time.

- The automated grading of assignments meant that the class could scale to many hundreds of students while the TAs could dedicate their time to office hours. Turnaround time for exams was sub-one-day.

- The instructors are wonderful (and well dressed!) people and they ran the class expertly.

Roughly three parts to this. First off, these folks are already "here" . Busy learning to America. Paying tuition to their schools and taxes from their internships/OPTs. Contributing and being contributed to so that there's already a relationship between them, the country, and the country's citizens.

This is also what a lot of other countries do so it's consistent with "the way things are done".

Finally, it seems politically expedient. There are already provisions for prioritizing Masters degrees. This change is a modification of those provisions. That (crucially) doesn't have to go anywhere near the legislature.

These particular masses are not huddled. Nor are they all leading lights (though some will grow into greatness in time) . So there are also plenty of reasonable arguments against this approach.

This will make getting work visas even harder for folks with only U.S. undergrad degrees. Expect growth in 4+1 and 3+1 integrated Masters programs to compensate. Prioritizing people with U.S. degrees is a pretty reasonable move. And given the existing structure, prioritizing U.S. Masters degrees is also reasonable. But a B.S. in CS is qualitatively equivalent to an M.S. The lack of nuance is not surprising but still unfortunate.

Thank you! This is the argument that made me give TypeScript a try. I work in Kotlin day to day which tries to fix its base language (and batteries included with it) while not fixing it too much. TS sounded like a language in that vein.

I believe that you get good by getting better. And I think it's easier to tell that you've gotten better than it is to tell that you've gotten good.

Look back 6 months, a year, 2 years. How have you grown? What can you do now that you couldn't do then? Are there things that you'd do differently? Things you wouldn't do at all? That might give you a sense of where you are now.

Repeat the process of getting better many times. Then one day you'll take some call, draw some diagram, write some code and you'll know. For a brief shining moment you will know without a doubt that it is good and you are too. Then the moment will pass and you'll spend a couple of years trying to find the next one.

I think the piece illustrates a very good point that the general public would enjoy reading about. Which is that booms can push out diversity and that a tragedy of the commons is occurring in SF with people driving out the character they came to SF to experience.

The problem is that:

a) It's taking about us. People who are not software developers would brush past the descriptions of developers as mere scene setting. But it's rather insulting to those being described. b) If it is true, it makes us the villains. And we don't like being the villains. We believe our motives and actions are reasonably noble (or at least not harmful). It hurts to be told that their not. c) It's colored with a lot of emotion from the author. I get the sense that this is precipitated by an underlying feeling of: "Does my time in SF mean NOTHING!?" Which is a reasonable emotion, but comes across to the subjects (us) as a sense of superiority.

I believe that it conveys it's point much better to a "lay" audience than it does to us because we (rightly) get lost in the details.

I'm very luck that I like what I like and that what I like is the "hot" industry right now. I do want to remember that everything isn't roses and sunshine. That this boom does have losers. But I'm still moving to SF because that's where the place I want to work is and because I like the city. And screw you Rebecca Solnit for making me feel like I don't belong. You were new to SF once and you don't have that right. But I might just take the train instead of a shuttle.

The title is somewhat inaccurate/misleading. The conclusion the blog comes to is that there are far better chocolates available for far less and that Noka are intensionally obtuse and misleading about how their chocolate is made and where it comes from.

Their site and other marketing material gave the impression that they oversaw the entire chocolate making process from "bean to bar", while in actuality they bought blocks for chocolate from what Dallas Food found to be Valrhona. This buying of chocolate and "rebranding" it is commonplace and accepted. What is not accepted or acceptable is concealing the source of the chocolate and misleading potential buyers.

The real issue (I wouldn't call it a scam) is that Noka doesn't seem to add any value while marking up the chocolate massively. And while being evasive about the chocolate's provenance. Once again, reselling and "rebranding" chocolate is no different from the OEM-Brand Company relationship and is not an issue.

Couldn't pass this one up seeing as I should actually be dealing with this for a class instead of commenting on Hacker News. What it means is that certain sets of symbols cannot be parsed unambiguously without information generated during the parse itself (the grammar is not context-free).

The link in the sibling comment has the canonical example:

foo * bar;

can either be parsed a multiplication or a declaration depending on whether "foo" has been typedefed previously. So you need to keep track of typedefs in a symbol table to correctly parse things.

The biggest problem with this is that many parser generators (including yacc) are much harder (if not impossible) to use with context sensitive grammars.