For simple cases (such as the example in the GP comment) a compiler can easily infer those annotations. Complications are introduced in languages which allow aliasing. Precise alias analysis has been shown to be NP-hard [1] (as are many other compiler problems), and thus in general compilers must make very pessimistic assumptions to avoid making incorrect optimizations, such as allowing two functions to execute in parallel.
Other issues crop up due to the open-world assumption. This is especially true in the presence of separate compilation when trying to reason about global behavior. Example: does function f() in file f.c modify global variable g in file g.c? The compiler may not be able to prove that one way or another at compile-time (consider if file f.c was already compiled to object code f.o, and only g.c was being recompiled), and so it must assume that f() may modify g. This particular example can be solved with link-time optimization, but you get the idea of how complicated the real world can get.
[1] Horwitz, "Precise flow-insensitive may-alias analysis is NP-hard," TOPLAS 1997.
>It's not the 70's any more, people rarely solve problems on whiteboards and paper. They solve them on the computer, sometimes through knowledge and their skill-set and other times through luck and Googling.
This isn't universally true. Anecdotally, I often find I'm much better able to think through tough problems if I step away from the keyboard and spend some time sketching out ideas on paper or on a whiteboard. I also keep the on-paper results in a notebook, which is occasionally useful to refer back to later in a project.
Sometimes just introducing some distance between you and the problem is enough to give you a key insight. That said, the interview environment is still nothing like this. There, you're under great pressure on the whiteboard, something which is probably not true in your day-to-day.
I'd like to think this is true, because I enjoy working in that manner, but I've generally found going totally offline and solving problems gives me satisfyingly worked-out-by-myself solutions to problems that... I could've solved more quickly if I'd done more reading for half that time instead.
If something really, truly has never been done before, nor even anything similar enough to be useful to me, then yes, this is the right way to work. But it's more common that someone has actually worked on something at least related (even if not quite the same), and that I could solve the problem more quickly if I looked for what they said about it first. That might take a bit of searching and reading to discover, sometimes even a few hours of it. But usually not as much time overall as re-solving it myself does... especially taking into account re-discovering all the edge cases.
My hypothesis is that many people don't realize this because they never follow up later to check if their solution was really novel, or was just lurking behind a keyword they didn't think to try. If you do that a bit and adapt your habits to miss things less often in the future, you can get better at finding and adapting existing solutions, rather than re-inventing things from scratch. But that's sometimes a bit deflating, because then you realize you weren't inventing so many new things before, either...
What you say is true, but... if it is a critical[1] task / area for you, you're better off reimplementing it anyway. Most existing work isn't so deep that concerted effort on your behalf won't improve on it - but only if you have the time to spend on it.
[1] I mean this in the sustainable competitive advantage sense
If I really need to think about a tough problem, I tend to get a pad of paper and go sit outside on my deck and think about it away from a computer. Sort of an "astrophysicists are not in the telescope business" thing :-)
"DMTCP (Distributed MultiThreaded Checkpointing) is a tool to transparently checkpoint the state of multiple simultaneous applications, including multi-threaded and distributed applications. It operates directly on the user binary executable, without any Linux kernel modules or other kernel modifications."
I don't have any strong feelings for or against coffee shop campers, but this article came across as quite self-centered. Perhaps a different approach would be more effective in changing people's opinions.
The argument against campers: "Starbucks and other coffee-shop campers just buy one cheap coffee and then take up a table for hours. We drive up the cost of coffee and inconvenience everybody else. We play loud videos and run our power cords across the floor, creating a safety hazard."
His argument for campers (in my own words): I'm an intellectual/creative person; I need to work in a coffee shop because research has shown it to increase creativity and output; I need to resist the brainwashed masses and their preconceived notions of acceptable coffee shop behavior.
Notice a theme? It's all about him, whereas the argument against campers is about everyone else. He even complains about being expected to clean up after himself (bus his own table). Shouldn't people be expected to act responsibly and clean up after themselves in a public place?
He does attempt to give an economic argument (i.e. coffee shops make more money from campers versus if they were to be banned). However, this is pure speculation on his part, and I suspect he is simply stating what he wants to believe is the truth. For example:
"I'm quite certain that if camping were banned at that store, the place would be deserted and it would make far less money. In fact, there would be no reason at all to even stay open until midnight. A huge percentage of its revenue comes from student squatters."
He has no way of knowing this, offers no supporting evidence beyond speculation, and simply states it as fact because it supports his view.
I agree with your response, it's pretty much the one I wanted to write!
I would add that I work very often from coffee shops (and restaurants). In my mind being a good camper is:
- Get to know your server/waitron's name's and interests
- Become a good "regular". To me that includes not being rude or impatient. Let the non-regulars go first. If things are getting too busy I'll move to a smaller table or even leave. Yes you're a customer, but you're also supporting the staff.
- Buy a meal if you're there for long enough that you would need to eat. If I'm spending the day I'll get breakfast at home, coffees at the coffee shop, order lunch, more drinks and head home before the dinner rush.
- Tip well. This covers a multitude of sins.
Ultimately, let respect for others guide your choices.
Boy. This is not at all the truth. Anecdotally, what I've discovered from a year at MIT is that the norm is feeling like you don't belong (e.g. here is some previous discussion about it https://news.ycombinator.com/item?id=4890267).
Saying "understand that you are here through very little of your own merit" is a recipe for causing already overly stressed students to do something rash, like jumping out of a building: http://web.mit.edu/~sdavies/www/mit-suicides/ (this list isn't even up to date).
Motivating people to work hard to feel like they've earned their place is a completely different thing than reinforcing the doubts and insecurities almost all of them have anyway.
The pressure at this place (and it's the same at any top-tier place) has been almost too much for me to handle sometimes, and that's without foolish words from foolish people designed to increase it.
The pressure at this place (and it's the same at any top-tier place) has been almost too much for me to handle sometimes, and that's without foolish words from foolish people designed to increase it.
MIT alum here. I know what you mean; the pressure can be tough. But also, they've got a lot of resources on campus to help.
I'm going to be on campus tomorrow and Thursday if you're interested in meeting up and talking about the stress. My email address is in my profile.
MIT is different. That said, I agree "through very little of your own merit" isn't fair at all; "through means other than your merit" seems a little more plausible.
Alum of the other T. Tech schools are different than Stanford/Harvard?etc.
Maybe a more useful rephrasing is that your presence at the institution is a blessing, a gift, given whether you currently deserve it or not. Enjoy the gift and grow into it.
Yes I agree going to MIT may feel like more pressure but perhaps (forgive me if I'm wrong, I obviously don't know your personal background) you, and your like minded friends, were from more modest means (i.e; not millionaires) and attending MIT was a real sense of achievement.
However, for some students attending Harvard, Stanford, Oxford or Cambridge can be an expectation and a realistic one at that if they have been given every opportunity to increase their chances of entry thanks to their parents influence and wealth. I understood the Author to be addressing these students. Perhaps they're a minority, but looking at the ranks of politicians and World leaders (from wealthy families I might add) coming from these institutions, it looks like more than just coincidence to me.
I am confused. In what sense of the phrase is this an operating system?
It says things like "Node is the primary runtime---no bash here" which to me betrays a misunderstanding of programming and operating systems on multiple levels. Bash is not a "runtime" or part of the operating system, it's a simple user-level program for managing jobs and navigating your filesystem.
The diagram of "where Node OS lives" points to a layer between kernel and userlevel called "root". What exactly does this mean? Root is a privileged user, not a layer.
Finally, "The primary goal of NodeOS is to provide a working package manager." That is unequivocally not what an operating system is.
If it's a package manager written in Node.js -- fine. If it's a shell written in Node.js -- fine. But from what I can tell, "Node OS" seems to be a misnomer.
It's 6.004, and it looks like they are still teaching it, which I was pleased to discover. Students are no longer asked to carry around the suitcase-sized breadboard "nerd kit" and they aren't using 74XX TTL chips any more. Now it's all done using simulators.
The name of the course is "Computation Structures", or, as MIT students would know it (since nearly everything at MIT is numbered, including buildings and departments), 6.004:
Well in this case, it's publicly funded research data. US citizens should have easy access to this data since we already paid for it. So yes. It is our data.
"JSTOR told the Chronicle that each and every year, they turn away 150 million attempts to gain access to articles."
Then tell your government to either provide it to the public themselves, or pay someone else to provide it to the public. Either way, funding one half of something and then demanding the rest is ridiculous.
It's not ridiculous to demand public access to public data post Internet, when almost everything is electronic.
Other people and other organizations are willing to provide this data to the public at their cost. However they can't publish data that's under lock and key.
Given the level of adjectives and expletives that I have seen being used for anyone who has made even the slightest of remarks that don't aligned perfectly with the popular stand here, I can understand uhno's stance of saying stuff from a new account. And yes, it doesn't seem that MIT was neutral on this case. But I guess dropping the case wouldn't have been a neutral stance either.
I think you're confusing HN with reddit. While the comment quality may have gone down a bit from the influx of new users, most people on HN still tend to be courteous. Out of all the comments in multiple stories, I've only seen about 5 bad words give or take which is pretty good considering that a lot of people are probably furious.
Yes, I think the conversation is definitely tamer than the last time we were discussing aaronsw or MIT.
Of course I can be brave and eat downvotes when necessary without a throwaway as I never get to meet, or work with, anyone here IRL who might punch me in the face. But I have to say that even my non-conforming comments are usually left alone by downvoters, as long as I take pains to explain my disagreement.
"First you shouldn't have to hide under a new throw away account."
But you don't know who "you" is so how can you judge that they don't want to hide under a throwaway account?
What if "you" is <person who HN fawns over> or <CEO of HN's latest darling> or <someone nearing the karma point where you get to downvote> or <someone who's feelings are more easily bruised> (Karmaphiliac?)
Would be a nice feature to be able to post a comment which isn't linked to your handle w/o doing a throwaway. Said feature only available above a certain karma level of course.
Add: Or <someone who doesn't want to upset an important co-worker, boss or partner/spouse that reads HN who views things differently>
Going off-subject, I feel that one of the main reasons that HN is really civil compared to other social sites is that not many long standing HN users use throw-aways. If using throw-aways becomes more common, I feel that the comment quality will continue suffer even more, so I'm inclined to call it out when I see it.
since MIT initiated the proceedings I wouldn't call that neutral either.
MIT initiated a process to find out who the laptop they found belonged to. MIT did not initiate any legal proceedings, and did not tell anyone that they were in favor of doing so.
it would probably weaken the prosecution's case at the very least
I can see one thing that would have weakened the prosecution's case: if MIT had been able to say definitely that Swartz's access to the MIT network was authorized. However, I'm not sure MIT could have said that definitely.
Other issues crop up due to the open-world assumption. This is especially true in the presence of separate compilation when trying to reason about global behavior. Example: does function f() in file f.c modify global variable g in file g.c? The compiler may not be able to prove that one way or another at compile-time (consider if file f.c was already compiled to object code f.o, and only g.c was being recompiled), and so it must assume that f() may modify g. This particular example can be solved with link-time optimization, but you get the idea of how complicated the real world can get.
[1] Horwitz, "Precise flow-insensitive may-alias analysis is NP-hard," TOPLAS 1997.