Should we support NFC? Should we launch a digital wallet? Should we build a robotic Prius? Should we develop augmented reality glasses and launch those glasses by doing a live Google+ hangout with skydivers jumping out of a blimp over San Francisco?
The answer is "Yes". Without having an ok NFC, you are not going to get a good NFC. Apple can come out and make it perfect, awesome, amazing, but there has to be something to start with.
> And beating expectations buoys our mood. All else being equal, people who wait less than they anticipated leave happier than those who wait longer than expected.
The same philosophy which underlies the familiar "under promise and over deliver". Guess this also explains the enormous amount of outrage that comes out of schedule slips, even in cases where schedule is of little consequence.
That's the troubling part. Even when Ben came to know that Tim was not conducting 1:1s, his first instinct should be to know why 1:1s were not happening. He could've asked Steve or even Tim. Maybe Tim had a different way of knowing and talking to his employees, maybe he figured out a better mechanism to connect with his employees. Wouldn't Ben want to know about it?
Even if there are no external customers waiting for the release, a business' other departments have to plan their activities. When will marketing start their pre-release activities without engineering's estimates? When will sales start talking to customers about the new release? There is just too many things that need engineering's estimates.
App discovery is a problem for consumers as well. My iPad does not show no more than ~40 games. I don't know if I am not looking hard enough or I just can't browse more than that what the app store app shows. I can search for an app, but I have to know the name of the app for that. So for me, if the app does not show in the app store app links, then the app pretty much does not exist.
If I do want a particular application, I search Google first than the app store. Most probably some one has already gone through the pains of finding an app and has talked about it online.
So discovery problem exists for app consumers as well. And there in lies a startup idea in app discovery but I wonder how Apple/Google would allow that.
Some anecdotal evidence: I went searching for an app that would stream the radio stations in iTunes. Several pages in, I ran into a ton of radio station streaming apps - they were the same app, each wrapping a different radio station.
After 10 pages of that, I gave up.
Searching the App Store or the Play is a painful experience whether you're just browsing around to find something interesting or if you're looking for something that does a specific thing. The categorization isn't fine-grained enough and the "curators" will pretty much let anything thru without showing any signs of quality or originality.
The desktop software market still suffers from this a little bit, but enough time has passed that some standards for quality have emerged from the general consciousness. You release a desktop app, there are some gold standards to compare to.
If anything, the app market is going to be incredibly painful for quite some time.
Agree with this. App discovery is rough for devs and users. From a dev perspective, it's hard to stick out. There's some fantastic apps out there that get lost in all the noise.
From a user perspective, the goal of discovery is to find the best apps that match my interests. This goal is hard to reach because of a poor user experience paired with inefficiencies in search and the download process.
It's this culmination of factors that makes app discovery a headache.
Guns are not banned in India. It just takes more effort to get guns. You need a license to own a firearm. One of the high courts declared that unless there is something adverse against the candidate one cannot be denied license. This effectively makes it a right to own a firearm.
1. This solution eliminates the decentralized nature of email.
2. No solution for corporate customers who would want to keep their emails private.
3. How would new contacts form?
Probably? You think there is even the slightest chance that fortune 500 companies would consider this? I noticed in your profile that you are a patent lawyer. What do you think would happen if you brought this suggestion up at the next partners meeting?
Respectfully, I think you are mistakeningly assuming that your email use case is representative of the rest of the worlds. Are you subscribed to any mailing lists? Do you ever engage in long form conversations with people in another timezone? Any non-corporate collaborative work with friends (software/volunteer activities/fiction/nonfiction writing)?
I thought the link would be of companies that use Haskell as their primary language of development, but it is more of companies which use/had used Haskell in one of their projects. The former would be interesting to know, if indeed such companies exist.
Edit: I should note, however, that the trend over the last year has been increasing that haskell share; you get just a lot done in not a lot of code... reuse is very good.
I didn't really believe Github's inflated line counts (125klocs) and was curious was sloccount would say...
I'm a bit surprised with the results. The sheer quantity of C/C++, brainless coding over a few days, was impressive. Experience buys something I guess :-/
Haskell has much more of a group inside of a company will use it as their primary environment then adopting it wholesale. Haskell is used extensively in trading with almost every major bank and hedge fund using it, although no one talks about it. It is also extensively used in energy companies.
There are a few companies out there that use it as their primary language such as Tsuru Capital and my company, Alpha Heavy Industries. By definition companies using it as their primary language will be smaller companies. Standard Chartered has a very large Haskell group.
That Haskell is used extensively in trading is quite interesting to know. This distinction did not come out that well on the wiki link. This is probably the reorganization that the page needs. Split in to sections highlighting companies which use Haskell as primary language, then split along industry lines.
Highlighting companies which use Haskell as primary language will be beneficial to both the language and the companies. Brings along a trust factor that real money can be made while using on Haskell.
The major problem with the 'smaller languages' is that sometimes, even if you want to, and can use it effectively, it's difficult to interface with other systems.
For example, services using SOAP. Drivers to DBs and other systems.
Sometimes it's easier to have your core login in Haskell for example, then make it interface with something else in Java/C#/etc which will have plugins for everything.
Depending on how some endeavors pan out, my wee company, WellPosed, is likely to be in that rarified category in the near future :-)
(strictly speaking it may be 2-3 distinct enterprises under the same umbrella, but same thing). Also some interesting stuff on the algorithmic & open source pipeline that'll be made available as those services come out.
(a vague summary of the pending products/services can be seen in this month's who's hiring thread.)
That would probably limit a lot the number and diversity of the potential candidates. As a complete outsider I find more interesting that Haskell is used for even few projects inside, say, Credit Suisse than a one-man shop nobody has heard of that uses Haskell exclusively; YMMV.
There is at least one: Scrive. Their codebase is almost completely Haskell. I think the only other language they use is Javascript for web stuff (but their web apps are built with Happstack).
