skysight-inc/HackerNews huggingface dataset:
it's great for employees at facebook that the company allows their engineers such tinkering (to an absolute extreme in this point). but I think fb engineers should work on bigger problems than hacking the dalvik vm - like stopping the erosion of their younger user base.
Focussed practice is effective; unfocussed practice is useless. No surprises there.
I couldn’t agree more and have long been arguing that we should use exceptions when they are a useful tool for the job because their semantics do what we need at the time. Sometimes that means exiting early because you can’t do what you’ve been asked to for some reason. Other times it means exiting early because you’ve already done everything you were asked to and there is no point in continuing further.

The main thing I would add to the original article is that the author is being a little kind to the critics on some of those points. For example, not only do exceptions not inherently need to be slow, they can actually be faster than the “classical” equivalent via return codes and the like. This is essentially because any jump-table-based exception mechanism means the non-exceptional control path can omit all the test logic that would serve only to exit the current block early. That could both reduce the size of the non-exceptional code and reduce the number of potential branches, each of which can be helpful for optimization. Although it’s rather less significant in performance terms because it only tends to happen once, when an exception does occur you also don’t have to run through all the individual levels of unwinding the stack with a jump table approach, as you can jump straight to levels that actually need to do something on their way to handling the exception and skip over anything that was just going to return immediately anyway.

As another minor data point, I haven’t found exceptions in C++ to be slow. Most/all of the major compilers seemed to have moved to a table-driven approach last time I used a broad set of them. The nasty overhead in C++ is more likely to be in the size of the generated executables; I’ve seen a compilation with exceptions disabled shave nearly 1/3 off the executable size.

Of course exceptions have somewhat different meanings and can have very different implementation overheads in different languages, so I’m not arguing that all advice to use them sparingly is bad. As always, it’s important to separate the dogma from the rational arguments.
I think it all depends on context. I use checked exceptions for handling edge cases in Java, which turns something like this:

public Session startByInterviewId(Long interviewId, String email, String name) {
Session session;
Interview interview = interviewService.getPublicById(interviewId);
if (interview != null) {
Account user = userService.createUser(name, email, interview.getLocale());
if (user != null) {
session = startByInterview(interview, user);
}
}
return session;
}

into this:

public Session startByInterviewId(Long interviewId, String email, String name)
throws Interview.NotActive, Interview.NotPublic, Interview.DoesNotExist, Account.EmailExists {
Interview interview = interviewService.getPublicById(interviewId);
Account user = userService.createUser(name, email, interview.getLocale());
return startByInterview(interview, user);
}

in which case I'm very much in favor of using exceptions as control flow mechanisms.

Instead of just getting nulls to indicate failure I now even know exactly what caused my error.

I would never even think of writing code like this in JavaScript or Clojure though and I'd guess is that in Scala/Haskell a custom Option would be much better.
Keep losing your Raspberry Pis? This is what's happening
For what it's worth I think you've managed to improve the speeds quite dramatically recently. Still a bit slow, but I've found Kayak on my iPhone can be pretty damn slow about returning a full set of results depending on the time of day.
Is Opera popular in other countries?
Comparisons with data.table on performance are much more favorable than with vanilla R or plyr; a lot of progress has been made last couple years, too. I personally find the data.table syntax to be a bit obtuse at times but it's a great library.
I re-read articles I read and didn't understand and if now I do, I learned something that allow me to better understand a wider range of subjects. If not, I didn't progress.

I retry puzzles that I failed to complete in the past and if they appear easier to do, I progressed. It worked for some Euler Puzzle that I couldn't begin to understand and a few months afterward they seemed trivial.

Redoing anything you struggled to achieve (or didn't achieve) could be a proof of progress, as long as it's actually understood.
Because using exceptions as control flow introduces a very awkward and strange type of coupling between components: dependence by one component on the presence of another known component higher up in the call stack.

Dependencies between components should ideally be as explicit and as few as possible. Dependency injection is one good way of achieving this, but even global variables or singletons are more clearly self-documenting than exceptions. A piece of code that returns a value or makes a call to some functionality in another piece of code is easy to understand. If instead, that code throws an exception, then it sends the reader on a voyage of discovery throughout the codebase to investigate all the places that catch this type of exception, and which of those pieces of code can ever potentially be higher in the call stack than the piece that throws it.

The only reason we even put up with such complexity in the case of handling errors is that it is the one problem that is ubiquitous to every piece of software ever written and therefore merits its own first-class language support.
Actually it seems pretty inevitable. Light is sprayed across the black hole from Earth; some of it ends up in every possible trajectory; some ends up in the critical 'orbit window' to be reflected back to where earth is going to be.
The flip side of this is that you have to keep up with breaking changes all the time. I've developed numerous in house apps that run on linux, and it is hard to keep up with every minute details that changes in all parts of such a system.
It is exceedingly hard to justify that you have to spend a day figuring out what they changed in gtk that now makes the text appear a bit different, or why the init.d script that has never had a problem now sometimes fail to stop the service etc.
ISVs, at least small ones, simply cannot keep up with the frequent external changes on such platforms, and the fewer people there are developing applications, in-house, open source, proprietary or what not, less people will use that platform.
While neat, all the web audio stuff I've seen fundamentally relies on setTimeout() for sequence playback. This only works at all because the apis let you schedule playback events ahead of time, against their special high resolution timer. To see how it doesn't work, press play and then move to a different browser tab.

The audio processing itself works fine while in the background, but the api makes no facility at all for any sequencing or any user-supplied control-rate data which runs as part of the audio graph. This is rather unfortunate and makes it hard to build real applications.

If somebody knows some solution for scheduling playback events while in a background tab, please speak up. In my own experiments, the very best I was able to do was synthesizing control-like signals inside of a ScriptProcessorNode. I quit before I got it to work, but that's all I could really come up with. The other option would have been to start scheduling 500ms ahead once the tab goes into the background, but you have to know it's coming.
Ditto to the gambler comment. Read Nate Silver's book on predictions for more. Working as a stock broker shouldn't be compared to software development without some explanation of why the link is valid, which it isn't in this case.
Can those work in the upper atmosphere? If not, why not?

I'm working on a new way to get into orbit and they'll play a part if I can figure out if it's possible to operate them in the upper atmosphere.
Yes, I researched this, and my wife is also an experienced lawyer and works in the judiciary system, prior her current job at family tribunal, she worked in commercial sections.

There are many laws here that forbids using any currency that's not the national one, from consumer's laws to financial laws.
> So if a choice must be made between superior language and reasonable amount of time, project managers usually choose reasonable amount of time.

Sure. Of course project managers usually choose deadlines over people, then when talented people burn out and leave, they wonder why talents are so difficult to keep. We know what the safe choice is: hire average programmers who see programming languages as interchangeable, and are themselves interchangeable. No worries about competitors, for they are doing the same. Nothing wrong with that, but please let's not pretend things are any different.
I like PHP. But I can understand why people hate it when they read articles like these.

Not escaping user input, storing password in the session. Bad practice all over the place.
I feel like I should go on my old laptop and dig up my ~0.5 bitcoins.

I wonder just how many bitcoins have been permanently lost already.
http://www.u.arizona.edu/~rubinson/copyright_violations/Go_T...

http://www.ckwop.me.uk/Why-Exceptions-Suck.html

Not saying that this is the last word on exceptions, but these are the arguments.
UK Court of Appeal rejects Tesla's appeal in BBC/Top Gear case
To install the whole set of Python modules needed and iPython in a virtualenv (trick: there is no "pylab" module to install):

% virtualenv --distribute --no-site-packages pandas_venv
[blahblah]
% . pandas_venv/bin/activate
(pandas_venv) % easy_install readline # Probably only needed in Mac OS X for iPython to behave
[blahblah]
(pandas_venv) % pip install ipython
[blah blah]
(pandas_venv) % pip install numpy
[lots of blahblah]
(pandas_venv) % pip install matplotlib
[quite a bit of blahblah]
(pandas_venv) % pip install pandas
[some more blah blah]
(pandas_venv) % pandas_venv/bin/ipython --no-banner

In [1]: import numpy as np

In [2]: import pandas as pd

In [3]: import pylab as pl

In [4]:
The google talk video is like a more detailed version of the TED talks. https://www.youtube.com/watch?v=IlPj5Rg1y2w&feature=gv
Actually both those sources do nothing but repeat the non-arguments that TFA debunks.
Personally, I've seen a lot of qualitative analysis and anecdotal evidence to support remote working, specifically when it comes to technology companies. I've worked with a notable company who almost exclusively used remote employees and, from that experience, would never advocate remote work on a regular basis. It certainly has a place, for specific people of good standing and character who are put in an extraneous circumstance; but I've consistently observed what I believe Mayer has: smart people in the same space day after day will breed a more innovative, collaborative culture.

Most of the criticism that I've observed regarding the announcement seems to reek of the opinion that telecommuting is a "Good Thing" and that anyone who can't see that is missing the forest for the trees. This usually goes in hand with laughable academic braying and vaunted statistics about (some number less than 40) hour work weeks.

Forgoing my inclination to rant about how that kind of opinion is generally cancerous to an organization trying to change the landscape of it's industry through creativity, I think that Yahoo! is in a position where it can't afford to treat their employees like a productive group. And to that effect, it's much easier to identify shit employees who show up an hour+ late and leave with the herd at 5pm when you(or your managers) can observe that behavior regularly. Regardless of their output, I've observed that people who can't be bothered to adhere to simple routine will become an abrasive factor in a fast moving, creative culture; and tend to inevitably diminish the effectiveness of their peers. That kind of situation is the last thing that Yahoo! needs at the moment.

If Yahoo! can get out from under it's own sense of prior accomplishment and entitlement, and I remain confident that Mayer can do this for them, I'm sure she would consider a situation like remote working when it comes to top talent. But, until that happens, everyone there should be treated like a rich son in a boarding school -- assume the worst about most of those individuals and the one's who are weighing down the company will start to show their true color.
In the specific case of Java, it looks like the compiler understands that you might want to use exceptions for flow control or other things. How else would you explain behaviour such as this:

http://jawspeak.com/2010/05/26/hotspot-caused-exceptions-to-...
Yes, that's not exception safe. Writing this error safe without exceptions requires nearly identical discipline. How much non-exception code have you seen checking every return value and restoring state? There are alternative more safe ways of writing this, but none have to do with whether exceptions were used.

This is a case where the developer needs to know that all update calls may not be completed. This may be a high or low probability, and may have fatal or no consequence. How many programs can handle a hard drive crashing or CPU glitch? Writing good error handling requires a lot more than removing exceptions, and often is not worth the cost. No software handles every error condition.
Other than what?
Oh no. I'm not saying it would be easier without exceptions. I'm just saying that the current status of our programming tools makes writing safe code very hard, and exceptions are one more thing you have to think about. I use them a lot...

The authors of the paper propose their "worlds" API as a way to make writing safe code easier. They're still using exceptions, but they would require no cleanup...

The code becomes:

try {
in thisWorld.sprout() {
for (var idx = 0; idx < xs.length; idx++)
xs[idx].update();

thisWorld.commit();
}
} catch (e) {
// no clean-up required!
}

So it's commit for data structures for data structures. If an exception is thrown and the commit line is not executed, no changes will be visible.
Rework - http://37signals.com/rework/
> This isn't really relevant to the thread of discussion.

It was, before I got carried away: I was going to say that Turing-completeness does not translate to practice. And whoever chooses a language according to its Turing-completeness is missing the big picture.
The law I pasted to some other replies just states that the only currency that can be used for commerce within the country is the national one. Also defines that national currency is the one created and regulated by the central bank.
Some 37 signals outlet had a nice discussion on this. The key in their view was to limit the number of features rather than the quality of said features. Something about thinking of the features you want on a 2D map, and the thickness being the quality, building up your volume of work. To reduce volume you can break off pieces, but you should strive for even (and sufficient) thickness.

Too thin - pump & dump. To big volume - group 2. Small, but thick - good shit.
In my opinion, this is not an issue with exception handling. It's an issue with bad programmers.

You can dumb it down as much as you want, people are still going to screw it up.

And you have exactly the same issue with "classical" error handling: you have to undo the partial job. Here's a bit of C code I wrote just this morning which closely ressembles your example:

for (i = 0; i < pdata->overlay_nr; i++)
if ((ret = overlay_init(data, i))) {
while (i--)
overlay_destroy(data, i);
goto overlay_err;
}

No exceptions, but I still have to remember to clean up before I dispatch the error.

I use exception quite a bit in C++, but it does fit my coding style. I use RAII almost exclusively, which alleviates most of the issues. That means that I don't have try{}catches everywhere, mostly only when I want to do actual error handling.

Exceptions are a tool, it's up to you to use it correctly (or not use it).
Interesting, I first looked at the second code segment and really didn't like it. However, I think thats just the whole Java checked exception thing (which I think everyone now regards as a mistake) - if you removed the throws and everything after it on that line it actually looks quite sensible and much better than simply returning null to mean "it didn't work for some reason I'm not going to tell you about".
Back in my early years as a software developer I once though that I could make some really eligent code by using exceptions for control flow. I used it to do a form of what I now know is pattern matching. It really cleaned up the code and made it super easy to extend and read, but it was a _terriable_ idea. It was slow and since nothing was checked by the compiler I found myself often at my root catch block trying to figure out how my nested catches didn't work.

Exceptions are not suitable for control flow. Yes they work and can sometimes give nice features, but typically they are just showing that you have poorly designed code and should be doing something differently.

'/s/Exceptions/GOTO/g' and you have essentially the same argument
Me at $24 by accident (stupid misclick on Mt. Gox, and didn't think paying the trade fee again would be worth it). Wanted to wait till $27, then the socks I bought would have been free. Free, as in, I earned them back.

I do wonder from whom I stole though; these socks cost labor but I did pay the laborer. Then the price rose and I got an equal amount of euros back as I put in. Who did I steal from, the Bitcoin community in general?
I would encourage you to do that post. Because the two documents you linked to are very unconvincing when placed beside David MacIver's essay.

The first link (http://www.javaspecialists.eu/archive/Issue187.html) says the code was hard to understand, that this is the 'wrong' way to use exceptions, that reusing a normal exception type instead of an exception intended for control-flow might mask other exceptions, and that debuggers will pause. These are MacIver's points #4, #2, #6, and #5 and he debunked each one.

The second link (http://onjava.com/pub/a/onjava/2003/11/19/exceptions.html?pa...) says "This not only makes the code difficult to read, but also makes it slower." That is MacIver's points #4 and #1 and he debunked them.

Do you feel that any of MacIver's points are incorrect? Do you know of any arguments that he did not already address?
If you can do all that, you shouldn't be working on simple CRUD applications.
Steve Case - the ‘Mark Zuckerberg of the 1990s’ | Next Up Asia
One huge thing pandas does damn well is Google Analytics integration. It has been a god send in this way.
I am sure that HTML5 is the future platform for games in the browser.

Personally i see HTML5 just as a deployment target in the future, like flash or ios for most major engines today. I bet Unity Technologies is already working on a "Deploy to HTML5" feature as they haben been doing for Flash as well. Other will do the same so we can continue to develop games in the mature and excellent software there already is, instead of reinventing the wheel in Javascript.
I can't believe they moved the tab selector to the top. Who can easily reach the top of a screen with a finger in single-hand use? I cannot. Placing buttons up there makes using these apps incredibly annoying. Even worse would be on the top left, since that is the place farthest from my finger.

Apart from UI changes there does not seem much new. I am still hoping they will make site preferences easily accessible so one can protect his privacy and security easily even on mobile devices. And of course extensions (they had a beta once).
Early in the blockchain there are thousands of addresses with a single 50BTC block reward in them. Presumably people downloaded the client, mined a block and got bored. At that time you could only mine using Bitcoin-QT, which reuses the same addresses for each block reward. Most, if not all coins mined in this way are lost forever.
this is really highlighting the fact that there isn't one way to build one interface for all needs. Some people have to travel on certain days - they can't rearrange those days for love nor money, and existing interfaces (while not great) work within those parameters.

Other people want to say "2 weeks in Moscow in April or May" and have something find either the cheapest, or quickest, or longest flights around. Adioso is going for that (obviously), but I'm wondering what else they can do to perhaps market more towards the 'free and easy traveller' crowd vs the 'locked down scheduled days' crowd.
I would expect the same, but I'm not in any way an economist so I'll wait and see. I also think that after the correction the price will rise again anyway.
> Who can easily reach the top of a screen with a finger in single-hand use

Every iPhone owner. Just joking. But this is an issue with big screens in smartphones that we as developers have to consider when making apps.
> '/s/Exceptions/GOTO/g' and you have essentially the same argument

Absolutely untrue. Eliminating GOTO was a major step forward in programming language design, one better known as "Structured Programming". The advantage was that it eliminated random entry points so that bits of code ("subroutines", "methods", or "functions") could be reasoned about independent of the entire program by starting from the "top" and working forward. Arbitrary exit points (like exceptions, break, and return) still permit this reasoning; allowing GOTO to target arbitrary statements makes it impossible to reason this way.

For a better explanation, see this essay I wrote on the subject:
http://mcherm.com/permalinks/1/in-defense-of-the-much-malign...
The Option/Maybe monad seems the way to do it. The null object pattern could also apply here, but you have to be pretty disciplined across your project to make it really work. Seems like the kind of thing you need language support for.

Actually: while the second code block is more readable, if I encountered it in the wild I would assume that it's full of bugs. It just doesn't seem very idiomatic. I'd much rather take advantage of the 'goto' nature of the return statement:

public Session startByInterviewId(Long interviewId, String email, String name) {
Interview interview = interviewService.getPublicById(interviewId);
if(interview == null) { return null; }

Account user = userService.createUser(name, email, interview.getLocale());
if(user == null) { return null; }

return startByInterview(interview, user);
}

There we go. 5 lines, one level of indentation for the main path, and semantics which are obvious to anybody who reads it.

But your point about the exceptions adding more information is well taken.
H4 is a dependent visa for spouses. You can legally stay in the US but cant work (you won't get an SSN). Only thing that you can do is keep coding on side projects and wait till you find a company willing to sponsor you H1.
Where does the money come from when mining (bitcoin)?
Throwing exceptions across API and module boundaries is a separate discussion which has separate pros and cons.

When you define an API in a language that has exceptions you should be careful to define the behaviour around how exceptions are used.

This is similar to how, when you define an API in a language that has threads, you should be careful to define your reentrancy and thread-safety guarantees.
This is great! Here's mine:

{"kitIndex":0,"effectIndex":1,"tempo":100,"swingFactor":0,"effectMix":0.10204081632653061,
"kickPitchVal":0.5102040816326531,"snarePitchVal":0.5,"hihatPitchVal":0.5,"tom1PitchVal":0.4285714285714286,"tom2PitchVal":0.5,"tom3PitchVal":0.5,"rhythm1":[2,2,0,0,0,0,1,2,2,0,0,0,1,2,2,2],"rhythm2":[0,0,0,1,0,0,0,0,0,0,0,1,0,1,0,0],"rhythm3":[0,0,0,2,2,2,0,0,0,2,2,0,2,0,2,2],"rhythm4":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"rhythm5":[0,0,0,2,0,1,2,0,0,2,0,0,2,0,0,2],"rhythm6":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]}