This just tells me that the original venues were not charging enough for tickets. If the tickets were priced ideally then StubHub would not be able to do this; the margins would be too low for the amount of risk involved.
Most business don't maximize short term revenue in that way. Compare it to any new tech gadget, especially ones with hard supply limitations like the limitations that exist for live events (thus preventing a true market meeting point of supply and demand). I'm sure Apple could sell a lot of iPhones at $1500 until supply stabilizes, reduce the price $200, then rinse and repeat. That might reduce the secondary market and be the ideal pricing strategy, but it would be a bad business decision especially from a public relations standpoint. Just like there will always be people waiting in line at Apple stores on day 1 to grab a device and throw in on eBay, there will always be ticket brokers doing the same.
Except it's not just one person. Most Greeks lived well beyond their means for over a decade. I'm from Turkey and have many Greek friends, and the overall sentiment in the country up until 2008 was that they could just continue borrowing and living like kings and queens until the end of time. Then the financial meltdown happened, foreign investors became bearish and the Greeks lost their easy access to capital, and things quickly unraveled.
How do you measure time spent "in-app"? Does the app have to be in the foreground or merely running in the background? If it has to be in the foreground then how does that help apps that mainly run in the background such as RunKeeper? If it's allowed to run in the background and still get credit then won't that create an incentive for battery-draining crap that users struggle to shut down?
Why, for testing. The calls to IO are replaced with calls to mocks which are then used to verify IO behavior. It's like replacing the IO monad with a type that doesn't actually do IO, only it doesn't require the code to change, so it works even for third-party code.
You can then use the security manager during the test to verify that all IO calls are indeed mocked.
I can't function that way. I'm currently typing this on a 2560x1440 monitor, in a maximized Firefox window. Occasionally I put two windows half-maximized side by side
Sounds like you'd get a lot of benefit out of a tiling window manager. I've been a full-time Xmonad user for 4 years now and I don't know how I'd ever go back to arbitrary-sized, overlapping window managers such as OS X's.
> Sounds like you'd get a lot of benefit out of a tiling window manager. I've been a full-time Xmonad user for 4 years now and I don't know how I'd ever go back to arbitrary-sized, overlapping window managers such as OS X's.
For my two use cases (maximized or left/right half-maximized), GNOME 3 works perfectly for me. I've tried tiling window managers, but I don't necessarily want something that minimal.
You have to focus on that one thing, and are not able to be bothered by distractions such as other windows/programs.
The issue with this philosophy is that the one thing you need to do might not exist as a monolithic application. This is where the unix philosophy shines: lots of small, simple tools interacting over streams of text.
it's surprising to hear colleagues talk about how important it is to separate content from presentation regarding, say, TeX
This debate never ends because, like the static vs dynamic types debate, it ignores the main tradeoff in favour of a one-size-fits-all solution. In both debates (separation and types) the tradeoff can be expressed most generally as an up-front vs deferred time investment. Static types require more up-front time investment with the advantage that they save time later. The same goes for having separated content from presentation.
Now, in light of the tradeoffs above what is the appropriate choice to make? That depends on how much time you're going to spend writing the script/document/whatever and how much time you're going to spend running/maintaining it later. For scripts, it makes no sense to have a heavyweight type system if you're only going to run the thing once and throw it away. Likewise, for documents it makes no sense to put in the extra time planning all the styles if you're only going to make a document (say, a shopping list) and then throw it away. For a long-term document such as a book or a thesis it makes a ton of sense to use something like TeX.
> Static types require more up-front time investment with the advantage that they save time later.
What exactly is it that saves time? Is it to not have to type as much? In my experience if you use a lang with good type inference you type a lot less with strict typing than without, since you don't have to have unit tests to guard for things like typos/param order/param types.
Typing on the keyboard is not what takes up most of the time in programming; thinking is. With static types you are forced to put more time into thinking about how to make the program compile whereas in a dynamic scripting language you only care about the result output. Your script may be ill-typed but if it gives the correct output for that situation then it doesn't really matter.
Static types save time later by giving you the opportunity to do a lot of refactoring with high assurance of correctness. Unit tests bring back some of this ability to dynamic languages but they require extra time to write and maintain the tests.
I just can't think of many situations when a dynamically/weakly typed program produces a meaningful result in that case. In my experience the errors are the same in both the (strong/static) case and the (weak/dynamic) case, with the only difference being whether the issue shows up at compile time or runtime. Dealing with N runtime issues is slower than fixing N compiler errors when you discover runtumr problems one at a time, but compiiler errors you get in batches of up to N.
Yes if everything is untyped then types are less useful. And for interactive scripring, compilation feels a bit strange too.
(Of course, I think text-only Unix tools as a way of interacting with a computer is a fundamentally broken idea).
Powershell is an interesting idea, though maybe not the best implementation of that idea.