Well the stacktraces are deeper, there is no way getting around that. In practice it's not much of a problem though as you quickly learn to identify the lines from your own code.
Debugging tends to be more REPL based than debugger based. It is possible to debug from Eclipse using the build in debugger, but it's not something i have done as it is not really necessary.
One thing that seems to missing from most travel sites is the ability to compose a travel consisting of several legs.
For instance, this spring I am going to India with work, after which I want to travel to somewhere in southeast asia, probably with one or two stops, and then home to copenhagen.
It should be possible to have an overview over my entire travel, not just the one leg or a simple return trip as my travels are rarely just that.
(looks good though, I am definitely going to try it)
Asking from ignorance here, is there a common protocol in use to communicate with printers e.g. find, interact with (print) and query (ask for toner level for instance) them?
Seems it would make a valuable tool for managing a larger number of printers, to know when to switch the toner for instance.
I have another anecdote from WoW regarding randomness.
The raid boss Onyxia (a great big dragon in a cave, which you could only kill once a week as i recall) had a phase where she would take off and fly above the raid. Once in a while she would then do a deep breath, a fire attack which had a high chance at killing you if it hit you.
Now, all sorts of tactics emerged on how to handle the fire attacks. One that stuck for a very long time was that the number of DOTs (Damage Over Time) would lower the number of deep breaths you got.
I'm sure there were other theories as well, but this one stuck for years with raid leaders yelling at warlocks, the class with most dots, to add more dots and even stacking the raid with warlocks to get as many dots as possible (we need at least 4 warlocks to take her).
In the end there was a developer (or just Blizzard employee) who admitted that it was in fact random. This story pops back in my head once in a while because I think we do this a lot on larger scales too without realizing it: See some phenomenon caused by randomness, come up with a theory, and because it is not easily refuted (after all it works most of the time right?) it becomes common knowledge that everyone follows.
I use Eclipse simply because it allows me to have multiple projects open in the same workspace and search for files/classes across all projects. When Idea gets that feature I'll probably take another look at it.
When then Programming Language Shootout use to include LuaJIT, it had a benchmark against Java.
If you want to see just LuaJIT vs Lua, [1] is a good comparison.
The reason why I liked the inclusion of LuaJIT in the Programming Language Shootout was that it compared LuaJIT to other language implementations not just on speed, but memory consumption and lines of code. All of which, LuaJIT typically dominated.
https://github.com/darius/superbench is not a big fancy cross-language shootout, at all, but I tried a few little programs I actually cared about. LuaJIT 'won' in the sense that of the languages I tried it had the best combo of performance and pleasant productivity, informally. I didn't try to quantify the latter.
(Also, no Java because I wouldn't seriously consider it for hacking-for-fun.)
And where does ITA get it's data. I assume there must be a few competing standards, and the airlines use one of them to give their data to ITA. Why can't other companies get the data directly from the airlines?
Debugging tends to be more REPL based than debugger based. It is possible to debug from Eclipse using the build in debugger, but it's not something i have done as it is not really necessary.