Why Is Swift's String API So Hard? - <AUTHOR> https://www.mikeash.com/pyblog/friday-qa-2015-11-06-why-is-swifts-string-api-so-hard.html <comment><USER3> > Human-readable text, file paths, SQL statements, and others are all > conceptually different, and this should be represented as different types at > the language level. I think that having different conceptual kinds of > strings be distinct types would eliminate a lot of bugs. I'm not aware of > any language or standard library that does this, though.

The Common Lisp standard includes pathname objects, with an implementation- defined (since different platforms have different conventions) mapping from strings to path objects. It doesn't specifically address the type-safety issue, though, since just about every standard function which accepts a pathname will also accept a namestring.

There exist libraries such as CLSQL which enable representation of SQL queries as objects.

Common Lisp: doing it right for so long that most people haven't even heard of it!

Also:

> When measuring a string to ensure that it fits in a 140-character tweet, you > want to go by unicode code points.

Really? Doesn't one _actually_ want 140 graphemes? Regardless of what one wants, does Twitter enforce 140 code points, or 140 bytes?

It seems to me that graphemes = characters, and that the fact that some characters are made up of multiple codepoints is as important as the fact that some code points are made up of multiple bytes.

<comment> grey-area Isn't this quite common? Most languages allow you to represent those strings as different types and parse them/to from a plain string representation.

From Ruby: String, Pathname, Url, ActiveRecord::Relation etc or from Go: strings, database/sql stmt + orm types built on top, net/url etc though file paths are just strings.

<comment><USER4> Yep. He basically just described "classes" in the object-oriented world.

<comment><USER5> I don't think it has much to do with classes. Python, for example, has no pathname/string distinction that I know of.

Common Lisp is in the object-oriented world, and indeed some of the things mentioned are implemented as classes. I think the point was more about the standard library's attempt to do The Right Thing and how library implementors tend to follow that.

(Also, for better or for worse, CL's pathnames contain information like host, device, and version, that aren't so relevant on the major OSes in use these days; but try dealing with VMS filenames with Ruby's Pathname...)

<comment><USER6> Device and even host are quite common in the Windows world:

[https://msdn.microsoft.com/en- us/library/windows/desktop/aa3...](https://msdn.microsoft.com/en- us/library/windows/desktop/aa365247\(v=vs.85\).aspx)

Volume = Device

Or Microsoft's UNC path:

[https://en.wikipedia.org/wiki/Path_(computing)#Uniform_Namin...](https://en.wikipedia.org/wiki/Path_\(computing\)#Uniform_Naming_Convention)

\\\ComputerName\SharedFolder\Resource -> \\\host\device\path

</comment></comment></comment></comment></comment><comment><USER7> This article reads like the Stockholm syndrome for programmers - come on - <USER2> modern language needs to handle this stuff in a sane manner.

Recently I wanted to skip the first character of a string and then convert it to a float.

Here is the beauty:

(text.substringFromIndex(text.startIndex.advancedBy(1)) as NSString).floatValue

(Notice the start index "concept" and then the "cast" into the other string implementation (NSString) to get the to float conversion method.) In any normal language it would be something like:

Float.parse(text.substring(1))

String handling is in Swift is half-finished at best.

<comment><USER8> Let's at least write your example in a sane manner:

        Float(String(s.characters.dropFirst(1)))

Is that so bad? The need to convert back to String is slightly annoying, but overall this is not bad.

And of course there is the inevitable question: when you say "skip the first character," do you mean the first grapheme cluster, the first code point, the first UTF-16 code unit, or the first UTF-8 code unit?

You say that "any modern language" needs to handle this stuff in a sane language? Which modern languages handle all of those possibilities sanely?

I agree that the String API has some holes in it. Which, you know, is why I say things like "The String API does have some holes in it...." But in terms of how it's designed, it's the only one I've seen that gets it right.

<comment><USER9> That's pretty clean. It is also rather inefficient. I think dropFirst copies the sequence and then the result is copied again to create a String and then finally it gets parsed into a Float. No problem for one Float, but parsing a largish CSV file like that may be a different matter.

At least I think that's what's happening. I'm not 100% sure.

<comment><USER8> Nope, it's all just pointer games. I just tested it here and inspected the guts in the debugger. My initial string containing "123456789" contains a pointer internally to 0x000000010006d326 which contains that data. The result of .characters contains that same pointer. The result of .dropFirst(1) contains 0x000000010006d327 and the result of turning it back into a string still contains 0x000000010006d327.

That's the great thing about abstract APIs and immutable data types, you rarely need to actually _copy_ anything.

<comment><USER9> Maybe it's a short string optimization in this case, because the docs say that dropFirst is O(n) [https://developer.apple.com/library/prerelease/ios/documenta...](https://developer.apple.com/library/prerelease/ios/documentation/Swift/Reference/Swift_CollectionType_Protocol/index.html)

Or they have optimized it after writing the docs. In any event, there's a lot more going on than what is necessary to parse a float. But I guess that's OK if the goal is to have a clean and consistent high level API.

<comment><USER8> In that context, n is the number of items being dropped, not the length of the collection.

<comment><USER9> I wonder what makes it so slow then. I'm looking forward to the day when we can look at the source code :)

<comment><USER8> Where are you getting that it's slow?

<comment><USER9> In my own little ad-hoc micro benchmark it is. That's why I suspected that there was copying going on, but there could be so many other reasons for it that it was probably a pointless exercise in the first place.

[Edit] And I mean relatively slow (4x the C++ code), not absysmally slow. Not a big deal.

<comment><USER8> Gotcha. Do you have optimizations on? If so, I'd guess it's just the overhead of the extra indirection, plus dropFirst does have to examine that first little bit of data to determine the grapheme cluster boundaries.

<comment><USER9> Yes I've done a release build.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> Maybe it's just my first-world-privilege at work, but, honestly, why would I want to put up with a language that makes all of my day-to-day coding tasks so much more difficult than it is in other programming languages? It seems like I'm losing more than I'm gaining. 99% of what I do is in English. Everything that's not in English is going through an i18n library to convert labels and such. It doesn't seem like I'm gaining much of anything, but I sure am losing a lot. No default indexOf, length, and substring methods? Ouuuch.

<comment><USER11> Exactly. I understand where pilif and Lx1oG-AWb6h_ZG0 are coming from when they say that indexOf, length, and substring actually get a little ill-defined when Unicode is involved, but I can't see the logical leap from that to it being a good idea to exclude them entirely. The motto of a good API/SDK is "Make the easy case easy, and the hard case possible"; Swift seems to fail the first condition. Surely there are default assumptions for these methods that work most of the time, with the option for more complicated functionality _if you need it_.

Maybe all this complexity is necessary when you're writing huge i18n'd apps, but the point is that if it's too much bother to even do Hello World, I'm never going to _get_ to the huge i18n'ed apps.

<comment><USER12> The problem with strings is that there is very little that is easy. The lesson is to avoid using strings as much as possible, although sadly fashions in programming seem to have been heading in the other direction for a long time.

I don't think hiding difficult operations behind an easy facade that sometimes breaks is a good idea. It makes people think that working with strings is easy. It results in lots of people writing broken or even insecure code[1].

The idea that you only have to deal with unicode strings if you are writing an i18n'd app is wrong. File names are unicode. The content of the pasteboard is unicode. The results of calling a web API are unicode. Text the user types into a text field is unicode. Unless your app doesn't handle outside text data at all then it's going to encounter non-ascii text. And if you aren't handling text from outside the app then you probably won't have much need for string operations anyway.

[1] do a github search for 'UTF8String' and 'length' to see how much code using NSString is passing the wrong length value into C apis.

</comment></comment></comment><comment><USER13> When I was working on one of our SDKs (pre Swift 2.0), I found it rather maddening that the Swift string class had native support for emoji, but developers were left to create their own implementation of very basic features like indexOf, length, subString, etc.

<comment><USER14> ... until you realise these "very basic" features are not very basic at all and pretty much depend on your current use-case. What length do you mean? Byte length? Character length? Code Point length? In case of indexOf, how do you handle surrogate pairs? does indexOf('ä') only find 'ä' (LATIN SMALL LETTER A WITH DIAERESIS) or also 'ä' (LATIN SMALL LETTER A followed by COMBINING DIAERESIS)?

The good thing about the Swift API is that it gives you all the building blocks needed to actually having a chance at getting this right. Many other languages sweep those things under a rug and you're screwed or you'll have a _much_ , _much_ harder job to get it right if you need to.

<comment><USER15> I think there's a pretty strong generalized use case for things like length (count the number of characters in a string) and indexOf (return the position of a character in a string). No reason to punish the 99% and force them to write their own implementations of these very conventional string operations to accommodate the 1% that means something not normally meant.

<comment><USER12> Based on Github searches I've done in the past a lot of code calling length on NSString was broken. Those people probably thought they were in the 99% who just needed the convenient 'normal' length. People not realising that length isn't giving them what they want is one of the things the Swift API aims to solve.

Giving the wrong choice for most situations (and number of UTF-16 code units isn't what people want most of the time) the easy convenient name is just a recipe for broken code. It's bad API design, or at least unfortunate historical accident, and it's good to improve things when there is an opportunity to do so.

<comment><USER15> It's not an improvement to exclude functions that you know everyone wants from the API. It's just going to result in _more_ mess, because we all know most people are going to search for "swift string length function" and copy and paste direct from Stack Overflow without more than skimming it. In practice, it just makes the behavior messy and non-standard, ultimately meaning Swift applications are more difficult and/or annoying to debug and maintain.

The _correct_ way to solve this would be to design the API so that the distinction between what you're getting and what you want is clear, and the place to go to get what you actually want is also clear. Including nothing is an admission that they couldn't do this.

<comment><USER12> >It's not an improvement to exclude functions that you know everyone wants from the API.

Which functions have they excluded? You mentioned counting characters, but you haven't actually specified which definition of characters you want it to use.

>The correct way to solve this would be to design the API so that the distinction between what you're getting and what you want is clear, and the place to go to get what you actually want is also clear

This is what they have done.

<comment><USER15> >Which functions have they excluded? You mentioned counting characters, but you haven't actually specified which definition of characters you want it to use.

The typical human definition of characters. Humans usually don't think about bits or bytes and they shouldn't have to. A character is a single independent glyph, a separate unit that would be taught to a human whilst learning to write, regardless of the internal representation in the computer.

If I need something else, I should ask for something else.

Hypothetical API calls that may address this:

"String".length()

"String".lengthInBytes()

"String".lengthInCodePoints()

This would provide standard implementations for these common functions (circumventing the issue of copying a random chunk of code from SO and all its attendant problems), make it obvious that there is a difference to anyone browsing the docs and/or using autocomplete, and make it easy to select and use the one you actually want in a particular situation. This type of discoverability is an important component in a usable API.

<comment><USER8> How is your suggestion any better than the _actual_ Swift code for these?

        "String".characters.count
        "String".utf8.count
        "String".unicodeScalars.count

Looks pretty much the same to me in concept and typing difficulty.

<comment><USER16> I think it has less to do with typing difficulty and more to do with annoyance. Sometimes what people like is less about technical differences and more about previously built mental models that reduce cognitive overhead. In other words: It let's them simply start playing and experimenting without having to relearn things they take for granted.

If most people (let's say 99% for argument's sake) expect "string".length to refer to character count and only 1% need something like "string".utf8.count why not just accommodate them and make the language more accessible? This reminds me a bit of UX design. I've seen people time and again make the mistake over the years of designing their UX in a vacuum. What they produced wasn't bad or hard to use, it just broke expectations.

All that said, sometimes breaking expectations is exactly what you should do because someone has to for things to change and move in the right direction. And sometimes when you do that you're taking one for the team, so to speak. Of course I don't know shit, but if I were looking at making a language popular I'd weigh doing what's "right" against my desire to increase the popularity carefully.

<comment><USER8> Apple is an interesting position here because of their massive clout. They could have introduced a language that looks like COBOL crossed with APL and it still would have been immensely popular just because they have such a huge base of fanatical developers. I think you're right that this sort of thing could pose trouble for adoption of a normal language, but Apple doesn't need to worry about it so much. I'm hoping that this will allow them to push the Right Thing even though some developers don't like it.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> I think the Swift String API has a lot going for it conceptually.

But I have a big problem with knowing so little about the performance and memory usage characteristics of the functions I'm calling and the strings I'm keeping in data structures.

The problem is exacerbated by the fact that the API is extremely incomplete. A ton of things can only be done by resorting to NSString functions and that, I think, requires the String being copied into a UTF-16 representation underneath. Or does it? I don't know. That's exactly the problem.

The idea of putting grapheme clusters at the center of the string universe is great when it comes to text that users see and manipulate. It's excellent for writing word processors.

But it is not convenient for analysing large amounts of text data or for parsing semi structured text formats where we have a lot of fixed length stuff that could be conveniently accessed using numeric slice indexes.

I think Swift's String class would work very well as a view on top of a UTF-8 buffer.

<comment><USER8> Is a String class the right type to use for parsing text formats with lots of fixed length stuff? Maybe Array<UInt8> would be more suitable.

<comment><USER9> There's a lot of middle ground between parsing a purely structured format and UI oriented string manipulation. Most of what I have done in my life involved semi-structured data with both natural language text and structured parts with fixed lengths. It's extremely inconvenient to have no string functions available when working with byte arrays.

I actually like the C approach a lot in principle, because it doesn't make you choose one or the other.

<comment><USER8> Maybe it would be best to have a lot of these things we think of as "string" functions available on arrays, like sub-sequence matching, replacement, trimming, even something like regex. Then strings can be "all that, plus unicode."

<comment><USER9> Yes, I think that's a good idea.

</comment></comment></comment></comment></comment><comment><USER17> From the OP:

> (Incidentally, I think that representing all these different concepts as a > single string type is a mistake. Human-readable text, file paths, SQL > statements, and others are all conceptually different, and this should be > represented as different types at the language level. I think that having > different conceptual kinds of strings be distinct types would eliminate a > lot of bugs. I'm not aware of any language or standard library that does > this, though.)

There are many sub types which can be constructed from strings. Most languages treat at least following as special types that can be constructed from/to strings:

* numeric types (integer, float, etc) * regular expressions * file paths * dates * XML * JSON

The real absence is SQL. It is shocking how such an apparently old standard has no stdlib parsing support.

Until one realizes there is no such thing as "Standard SQL". Any sufficiently visible "SQL Parser" project eventually will be buried in a sea of vendor- specific edge cases.

</comment><comment><USER18> > I think that having different conceptual kinds of strings be distinct types > would eliminate a lot of bugs. I'm not aware of any language or standard > library that does this, though.

Foundation seems like the obvious one? NSURL vs. NSString?

<comment><USER19> In the Rust standard library, we have String, str, OsString, Path, and PathBuf, off the top of my head, with external crates implementing things like URLs, ropes, and others.

That said, I completely feel what this blog post is saying: strings are _hard_, especially if you're not just doing ASCII.

<comment><USER20> why are they so hard?

<comment><USER21> There's two aspects of complexity with strings:

1) 40 years of crazy encodings and languages.

2) human languages are wildly diverse and basically any assumption you wish to apply is broken.

For 1, any system that wants to deal with the outside world needs to deal with: operating system encodings (arbitrary bytes on unix, malformed UCS2 on windows), C representation (null-terminated strings), systems that only work with ASCII, systems that only work with utf8, systems that work with arbitrary encodings/languages (HTML). This is arguably unnecessary complexity that exists because of short-sighted decisions in the past.

2 is the necessary complexity; the fact that languages are really complicated.

There are thousands of symbols in writing. Do you try to encode these symbols in a monolithic manner, or in a compositional way? For historical reasons, you can often do both! ë can be a single character, or e with an accent modifier. How do you handle string searching in such a model? Do you match `noel` with `noël`? What's the length of noël? 4 characters? 5 characters? bytes? graphemes? codepoints? Can you correctly reverse noël (do it wrong and you can get leön)?

Different letters which have similar/identical representations but different semantics/origins! Is Ε "capital e" or "capital ε"? How do you upper-case or lower-case these letters? Do you expect to_upper(to_lower(char)) to roundtrip (it won't)? Do you expect capitalization to be doable in-place (it's not)? Do you expect capitalization to be region-specific (it is)?

Are any of these operations even _coherent_ in a language like Japanese? Why are you trying to do them?

God help you if you want to _display_ this text. Are you ready to handle right-to-left text? Are you assuming that your font is monospace (hey there terminal and text editors)? C̢̫a̘̺̯n ̘̜̦̹y̷̫̼̘̩o̶͉u̗̩̻̞ ̻ẹ͡v̴̤͎̹e̶̫̠̤̭̺̤̞n̛̞̹̣̩̲͉̮ ̜͖̪͔̖d̤e̘̯ͅa̺l̟̀ ͚̗̣w̭i̸͇̠̥̣̜̥t̸h̸̻̮̼̙̹ ̗̺̱̣̰̱̙z̟a̺͜l̠̦̖̟̰͍g҉̜͖͓̫ơ̩̹̰͕?̹̳̼̯̘̺̟

<comment><USER8> I think my favorite part of this article is how my Zalgo example doesn't render even remotely correctly in any browser I've tried it in.

</comment></comment></comment></comment></comment><comment><USER22> the main problem with swift strings is actually naming. You don't have simple method

replace(src:String, dst:String)

but you have weird

stringByReplacingOccurrencesOfString(src, withString: dest, options: NSStringCompareOptions(), range: nil)

Why not to have simple convenience method?

<comment><USER23> Aside from the fact that they carried that style of naming over from Objective-C, the one benefit I see is that it makes it obvious that it returns the result in a new string rather than modifying the object itself. In C++ you would need to look at the signature to tell which way a method named replace worked, e.g.

void A::replace(const A& source, const A& dest);

vs

A A::replace(const A& source, const A& dest) const;

That said, I think you can get this same benefit without such a verbose name. Perhaps something like "withReplacement"?

<comment><USER18> A solution to this would be to disallow mutable value types. Then, all methods would _have_ to return a new instance.

The compiler implementation could use mutability behind the scenes for efficiency, while the language exclusively allowed immutable values.

</comment></comment></comment><comment><USER24> > Human-readable text, file paths, SQL statements, and others are all > conceptually different, and this should be represented as different types at > the language level.

Objective-Smalltalk[1] has Polymorphic Identifiers[2][3], which are URIs used as identifiers in the language. So that handles file paths and web addresses. SQL is not solved directly, but XPath can be encoded in the URI and there are mappings from relational DB APIs to URIs[4][5][6].

I hope we can get rid of identifiers encoded as strings once and for all.

[1] [http://objective.st/URIs](http://objective.st/URIs)

[2] [http://dl.acm.org/citation.cfm?id=2508169](http://dl.acm.org/citation.cfm?id=2508169)

[3] [https://www.hpi.uni- potsdam.de/hirschfeld/publications/media...](https://www.hpi.uni- potsdam.de/hirschfeld/publications/media/WeiherHirschfeld_2013_PolymorphicIdentifiersUniformResourceAccessInObjectiveSmalltalk_AcmDL.pdf)

[4] [http://blog.dreamfactory.com/add-a-rest-api-to-any-sql-db- in...](http://blog.dreamfactory.com/add-a-rest-api-to-any-sql-db-in-minutes)

[5] [http://restsql.org/doc/Overview.html](http://restsql.org/doc/Overview.html)

[6] [http://www.slashdb.com](http://www.slashdb.com)

</comment><comment><USER25> >Human-readable text, file paths, SQL statements, and others are all conceptually different, and this should be represented as different types at the language level.

String, Path/URL Objects, Prepared Statements.

</comment><comment><USER26> i think this is apropo [http://www.joelonsoftware.com/articles/Unicode.html](http://www.joelonsoftware.com/articles/Unicode.html)

</comment><comment><USER27> While you can technically store whatever you want in there, the assumption and convention the bytes in a string in Go will be utf8.

E.g.:

       for i, x := range someString // iterates unicode code points

Works well in practice. (There are the unicode and unicode/norm packages to do more complex unicode operations.)

<comment><USER28> I don't think it works well for text manipulation. For example, in Go, how would you truncate a string and add ellipsis, without dropping an accent or otherwise splitting a grapheme cluster?

</comment></comment><comment><USER29> >I think that having different conceptual kinds of strings be distinct types would eliminate a lot of bugs. I'm not aware of any language or standard library that does this, though.)

Rebol does that AFAIK.</comment>


Ask HN: Joining a team later as a co-founder - <AUTHOR>

Has anyone here joined a team as a co-founder, even after the initial team already started and incorporated?  What are your red flags if you're approached with such an opportunity?
It's one thing being with your friends from the beginning of a project, but getting pitched an idea and then offered to become a co-founder can be shaky.
Is an even split still expected? <comment><USER2> Be very careful with these type of opportunities, especially if a lot of time has been wasted on stuff that adds very little value in terms of getting the company traction. If the company has customers already that's one thing. If the company has just some standard incorporation stuff, an idea, some failed prototypes, a bunch of sketches, etc, think long and hard before jumping on board because the other "original" founders will always hold this over your head and in one way or another you'd be second-class. A smaller percentage is one thing, but look out for any vesting or other provisions they try to bring up that may severely impact your leverage and position within the company.

</comment><comment><USER3> My situation was not identical, but similar.

If you're not there from the beginning I would not expect an equal split. The longer the startup has been around, the less equity you can expect to get.

I like to look on the brightside of things. Being a skeptic can be harmful. If your gut is telling you that something isn't right, than be careful.

Trust your instincts.

</comment><comment><USER4> Whether or not an even split is still to be expected depends on a few factors, such as how long they're busy, what their outlay was and their compensation to date vs yours.

If they've been busy for a while and they've passed through one or more cusps would mean that your risks are reduced, on the other hand if this start up is two weeks old then I'd lean towards an even split, depending on what you bring and whether or not the others have 'an even split'.

If you're being approached then that would be based on reputation and talent, have a long hard look at the business case and if you believe in it then you can weigh your options.

Make sure if you have a s.o. that they're on board, start up life can be pretty stressful.

Best of luck.

</comment><comment><USER5> An even split isn't even expected when you're there at day zero. Everything is a negotiation.

</comment><comment><USER6> I don't think an even split is expected (or even suggested -- consider that Sequoia takes around 30% only!), but a good rule of thumb is that, prefunding, someone who joins is a cofounder. It really changes your perspective when you're part of a team with a vision, maybe some duct-tape prototype, and the idea that, come hell or high water, they're in this together.

Bill Joy joined Sun after the founding. One of my partners joined us later, too, They are absolutely cofounders.

That said, the biggest red flag? Dishonesty. If you smell a whiff of it, I would advise serious caution.

<comment><USER5> If you're taking a regular wage from a company starting the first week of your employment, then whether there's funding or not, you're probably not a founder.

<comment><USER6> A wage from what? I said prefunding :-)

You're right though, I probably should have said 'prewage' :-p

<comment><USER5> We've never taken funding, but we have lots of employees. They're not all founders. =)

</comment></comment></comment></comment><comment><USER7> I was in a similar situation. I was "recruited" as a co-founder and CTO about a month after the idea was born and organized, but nothing built. I was given a smaller percent then the other founders, but adequate for what I brought to the table. As another commenter mentioned, an even split doesn't always happen even when everyone is there from day one. At this early stage its all about who brings what to the company...

</comment><comment><USER8> Only rake less if you risk has been reduced

If all the have done is pretty std business startup crap a monkey with a phonebook and checkbook could do, that does not really count as risky work

<comment><USER8> And by no means am I advocating equal splits. You should b compensated based on what you bring, your risk and based on your opportunity cost</comment></comment>


Gradually, by word of mouth - <AUTHOR> https://twitter.com/marvindanig/status/1226876279846252546 <comment><USER2> Given that startups = rapid growth (PG's definition), this is another way of saying that moving new tech from the fringes to the mainstream is unlikely to be a viable strategy for startups.

If you can get those fringes in the beginning to fall in love with your product and make you ramen profitable though, then you might be able to hang on to the rising tide of the "gradually" part long enough to have something big on your hands, assuming you can keep your organization very lean and cost- efficient in the meantime.

</comment><comment><USER3> Btw, there is another big thinker who has an idea of how to do this. The "trick" is to define the tiny market as small as it needs to be to have the tech dominate. And then, when it grows, define the market as slightly larger so it dominates the new market and so on:

[https://en.wikipedia.org/wiki/Crossing_the_Chasm](https://en.wikipedia.org/wiki/Crossing_the_Chasm)

</comment><comment><USER4> Not everything that man lets off is a piece of art worth framing and hanging in the Louvre.

<comment><USER2> Orthogonal point: not every piece of art framed and hung in the Louvre really deserves to be there.</comment></comment>


The Science of Difference (Sex Ed.) - <AUTHOR> http://pinker.wjh.harvard.edu/articles/media/2005_02_14_newrepublic.html

<comment><USER2> Interesting how the last few paragraphs on Taboo relate closely to this Paul Graham Essay: <http://paulgraham.com/say.html></comment>


The Throw Keyword Was a Mistake - <AUTHOR> https://hackernoon.com/the-throw-keyword-was-a-mistake-l9e532di <comment><USER2> > Hit Ctrl-S every few seconds or you deserve to lose it.

Huh, I remember years ago I had this habit. At some point I stopped, I don't think I do that any more. Maybe with the rise of web apps? My switch to Linux as daily driver? With those I've been logged out when writing a long message (especially if I take a break while writing), so for some apps I know to copy the text out to notepad or something. Although I'm not sure the last time that's happened either.</comment>


Five-day diet that mimics fasting may 'reboot' the body and reduce cancer risk - <AUTHOR> http://www.washingtonpost.com/news/to-your-health/wp/2015/06/22/heres-how-a-five-day-diet-that-mimics-fasting-may-reboot-the-body-and-reduce-cancer-risk/ <comment><USER2> "May" is such a nice word. Let us hear a quote of wisdom from the ancients (namely, Footprints on Everything2):

I've given this some thought, and this is what it comes down to: The facts:

On the cover of Honey Nut Cheerios is a bee holding a stethoscope and saying "May lower cholesterol." The deductions:

The bee is saying "May lower cholesterol." A true statement, as it MAY (or may not) lower cholesterol. However, it is also misleading, as it is also true that this cereal "may cause manic-depression," "may cause diabetes in geese" or "may accelerate the return of Beelzebub to his native plane."</comment>


Why You Probably Won't Get Better at Pool - <AUTHOR> https://jenniferbarretta.wordpress.com/2016/02/16/why-you-probably-wont-get-better-at-pool/ <comment><USER2> Unless you watch YouTube and understand the physics...</comment>


Simplest OAuth Introduction: The Outcome of Years of Dedication to OAuth - <AUTHOR> https://blog.oauth.io/simplest-oauth-introduction-outcome-of-dedication-to-oauth/ <comment><AUTHOR> This is my earnest effort to write an intro to OAuth that is aimed at being useful to CEOs, engineering VPs, sales, etc. Any feedback is very much appreciated!</comment>


The real reason we're upset about Sparrow's acquisition - <AUTHOR> http://www.elezea.com/2012/07/sparrow-google-acquisition/ <comment><USER2> Unfortunately, this is what you get when you pay $10 for an app.

There is a huge disparity when it comes to the cost of apps these days vs the salaries required to sustain the engineers who make those apps. Even at $10/pop, you need to sell a lot of apps just to sustain the salaries of very good engineers, and THIS is what makes great products vulnerable to acqui- hires.

The problem is that the $0.99 model of the App Store makes a $10 app look ridiculously expensive, especially when there are free alternatives out there, even though it's only 2 Starbucks coffees. And even though $10 is worth it.

It's the price of the apps that have drastically lowered the expectations of what people need to pay for software, and this goes in direct conflict to the rising costs of great engineers' salaries.

I'm not sure what the exact price point is, but my guess is that people need to start getting used to the idea of spending $30-50 PER YEAR in a subscription model for a great app in order to create enough monetary incentive for the developers to keep their products alive. Otherwise Google and Facebook will continue to drop the bills and pick off the best teams who eventually get tired of the smaller comparative payoffs that these apps bring in.

<comment><USER3> This is spot on. Thanks to the App Store, the days of paying $30+ for boxed software and paying again every year or so for version n+1 (assuming it comes out at all) are pretty far back in the rear view mirror now.

I paid $10 for Sparrow and got far more than $10 in value from it. So while I am disappointed that the best email app I have seen is EOL'd now I did get a decent value and I can't complain a whole lot. I am no worse off than had I bought a boxed copy of software with no promise for updates ever.

I would have paid $30 up front for Sparrow and purchased a large feature release for that price later down the line. Happily. That is a price far more in line with the value delivered.

How do we recalibrate people's expectations about the value of software back to pre-2008 levels? Not everything can or should cost a buck.

<comment><USER4> "Not everything can or should cost a buck."

When I talk to many developers they tell me that everything should be free.

How do you recalibrate the consumer's perception of the value of software, when so many developers don't value software either?

<comment><USER5> I guess they are meaning "free as in freedom" which is something that comes up time and time again thanks to the FSFs insistence on using poor wording.

I don't think that developers don't "value" software. It would be a push to suggest that people who use Linux,Apache or Emacs don't see any "value" to them.

I'm sure if they though about it they could probably assign a high dollar amount that would reflect the utility they receive from these programs.

Personally I don't have a problem either paying for a commercial software or using an open source alternative.

It's when an application is either free (as in $0 or outrageously cheap) and closed source and I can't "get" the developer's business model that I would be very hesitant to rely on it.

<comment><USER6> > I guess they are meaning "free as in freedom"

Not necessarily. Most of the software developers use - from IDEs/editors, through version control, synchronization, web stack, to server software and even the basic but important tools like _ls_ or _grep_ \- is free. Free as in "free beer". We are used to get tremendous value for free. We are used to give away value for free. And I'm not surprised that many developers (myself included) like this utopia, even if it is not currently sustainable.

<comment><USER5> Open source is a sustainable way of making software a zero money cost though. The contract is basically that they allow you to use the software on the basis that you _might_ give some value back in the form of patches, bug reports or even just asking intelligent questions on their forum or paying for commercial support. Even if you don't they don't really lose anything.

A huge amount of OSS is fairly "developer facing" too, with possible exceptions of stuff like firefox of VLC (few people would imagine paying for a media player or browser today).

I agree though that bad FOSS evangelism may be partly to blame, if you tell everyone to "use Linux because it is free, all software should be free!" without explaining that price not the important part of the equation and you are a software developer yourself then I guess you can't be too surprised if people see that as endorsement to pirate Photoshop.

</comment></comment></comment></comment></comment></comment><comment><USER7> In 1998 we wouldn't of complained - at least me.

It is 2012, and when I purchase software, I don't buy into the premise that this software is going to be static for perpetuity, and this is because of the fast-paced nature of OS, platform and web evolution.

I "marry" the software I love, and I am very happy to pay for upgrades. I upgrade my Mac the day after a new OS X version is released, not only that, but I use non-large company software every day for years: Panic, Bjango, Made@Gloria, etc.

When I buy software, I don't only buy into the software I get, but I support it because I think it has a bright and better future. If I knew the developer was to stop development going forward, I would simply not support it.

Going forward, if I find that a small/medium developer has received capital from an angel or VC, I am going to stay away from it (I already decided not to use Foursquare, Path, Highlight, Kik and many other mobile apps for this reason) - the investor will have the need to flip the company, whatever the outcome for the software is.

<comment><USER8> _I upgrade my Mac the day after a new OS X version is released_

I used to do that—until I realized that 10.7 (and now probably 10.8) don't offer any substantial improvements to things I care about (as discussed here: [https://jseliger.wordpress.com/2011/07/20/mac-os-10-7-is- out...](https://jseliger.wordpress.com/2011/07/20/mac-os-10-7-is-out-today- and-i-dont-care-because-in-the-beginning-was-the-command-line/)). In other words, I've probably reached "peak operating system," in that marginal improvements to OSes are really quite marginal. That's also true, at least for me, of a program like Word. Have we _really_ seen substantial improvements since, say, 2002? Maybe in stability, but not much else.

I'm not arguing that software itself isn't improving—a lot of software has a huge amount of search space left. But some doesn't, and we get diminishing marginal returns. Maybe I'll upgrade to 10.8 or its successor—Textmate 2.0 or iMovie 12 could be the inciting factors—but there's a solid chance I won't.

<comment><USER5> Problem is, what happens when they stop supporting the version that you are using and happy with?

Would you feel confident going online with an OS that has known security issues that will never be patched?

<comment><USER9> Using an outdated OS that is not supported anymore isn't good security, but in theory there shouldn't be much danger as long as you follow some basic restrictions :

1/ Put the computer behind a NAT router with no open ports/outside access 2/ Use a browser that hasn't dropped your platform (just because the OS isn't supported anymore doesn't mean you can't find at least one browser that's up to date with continuous security updates. There are still people porting Firefox to PPC macs, an initiative called "TenFourFox". You can also try Camino or iCab, two alternative browsers that have kept PPC compatibility) 3/ Don't open an email attachment unless it has been scanned through an antivirus

Point 1 and 3 are something I do even on a patched computer anyway. Your desktop shouldn't be directly exposed to the internet.

I've never ran an outdated OS myself but I would feel confident in using one as long as I respect those principles. The one thing I wouldn't be confident in doing, though, would be running an outdated browser or an outdated mail client. Security updates for anything that is in direct contact with the internet is a top priority and using an abandoned mail client like sparrow that doesn't _guarantee_ security updates is a terrible, terrible idea.

</comment></comment></comment></comment><comment><USER10> Also, frankly, I think people chose Sparrow because they weren't happy with the big boy's applications (Apple's Mail.app on Mac OS X, Apple and Gmail's apps on iOS).

It's a case of "We don't like Google or Apple's apps, so we're going to _pay extra money_ to get something we like."

So when the Sparrow team gets picked up by Google _and_ we hear that Sparrow.app is becoming abandonware, many people think "the bad guys win again."

Of course, I hope the hue and cry about this will suggest to google that Sparrow might be worth maintaining after all. A mail app that people like? That can't possibly be a bad thing, can it?

<comment><USER11> "Of course, I hope the hue and cry about this will suggest to google that Sparrow might be worth maintaining after all."

Or open source the app code? c.f Intellicad when Microsoft bought Visio

<comment><USER12> Exactly what I thought. If they are interested only in the talent, why not give the code to the community?

The publicity and goodwill alone should be worth it!

<comment><USER13> >If they are interested only in the talent, why not give the code to the community?

Because they have a directly competing product. I'm sure that getting rid of a competitor factored into the acquisition.

</comment></comment></comment></comment><comment><USER14> This posting is very true, and this is exactly why I prefer Free Software when it comes to sustainability.

Even if the developers' revenue plan (services, merchandising, whatever) turns out to not be sustainable, at least the remaining software is free (in the sense of freedom) such that others can fork it and can take care of it.

In that sense, Sparrow could have made a great move, since they don't plan to make any more money with their product: publishing their latest code base under GPL.

However, in that case Google might have hesitated to acquire them in the first place. On the other hand, MySQL has been acquired by Oracle despite being Free Software, and despite having existing forks such as MariaDB.

<comment><USER15> That's exactly what I had in my mind immediately after reading the article. I'm no Mac user, but seeing loyal users let down, I just wish the app was free software.

I don't think Google will release it as free software, but if they made it open from the start, maintaining it would be a possibility.

</comment></comment><comment><USER16> Obviously, those arguments are somewhat metaphorical. Paying $2.99 (or even $2,999) for software doesn't guarantee its sustainability. It doesn't move the needle. It's more like voting where your individual vote doesn't count but you still feel that its important to vote. Especially if you voice an opinion and try to convince others (something that probably has more effect than voting).

I think we are talking about more abstract things. We want this software to exist. We want these business models (small, profitable development companies) to exist. It's not just "I want to use this software."

I think a reason for these kind of reactions to acquisitions is that we feel or suspect that they are destroying rather than creating value. But, it's kind of hard to tell so we don't usually make that claim. For small companies, we know what they make and how many people use it so its easy to get a feel for the value they create. When Google acquires a great team, its hard to know what, if any value they create. Google obviously create enormous amounts of value but its hard to tell what a new team ads or subtracts from that. Much more nebulous are the effects that the existence of such acquisitions have on founder and investor motivation to start and fund these companies in the first place.

I think thats it at the core. A suspicion that such acquisitions are value destroying activities resulting in less/worse software being available to the world.

</comment><comment><USER5> I guess the problem with this is that in the days of app stores, internet everywhere , automatic updates and 0 day vulnerabilities software suddenly looks very fragile and susceptible to bit rot.

I remember in the late 90s there were still plenty of people around using Word 6.0 which was old at the time but still usable since MS allowed recent versions of Word to create docs compatible with it.

Now, if your favourite app gets pulled from the store (that your device is locked to), gets broken by an OS update or the developers simply release a non reversible update that you don't like you're in trouble. Not to mention the consequences of the vendor going bust or getting bought by a rival.

There seems to be a strong "C'mon just use an iPad and the cloud already!" voice on HN, I guess I can understand why people are somewhat conservative about it.

</comment><comment><USER17> Yes, the Sparrow acquisition is a great illustration of how the whole "you're the product" cult was broken from the start.

No matter how much you are (or aren't) paying you are always _both_ the customer and the product. Even Apple, who gets plenty of money from their customers directly, is willing to pimp out their customers as "400 million active credit cards" in the right context. At the other extreme, Google devotes an immense amount of effort to continuously improving search. They know that they live and die based on how happy you are as a search customer, even though they aren't paid even a nickel from searches directly.

I'll say it again: we're always both the customer and the product. There's no escaping that. Our only option is to decide which vendors' tradeoffs we are and aren't willing to live with. And black-and-white moralizing about whether or not "you're the product" gets in the way of picking the shades of gray that work for you.

</comment><comment><USER18> Perhaps we should only pay for development of open-source software, so we actually own what we're paying for.

<comment><USER19> I don't believe that changes the situation at all.

An example of this is Quicksilver on the Mac. It's considered to be one of the best Mac apps ever and the developer who made it, decided to open source it after he decided to take a job at Google. Quicksilver development fell apart afterwards.

My point is that people who used the app did so because of the talent of the developer. A community can't always make up for that hole.

<comment><USER20> > An example of this is Quicksilver on the Mac. It's considered to be one of > the best Mac apps ever and the developer who made it, decided to open source > it after he decided to take a job at Google. Quicksilver development fell > apart afterwards.

I don't use a Mac, and don't even know what Quicksilver was until I checked, but this was posted 17 hours ago:

[http://blog.qsapp.com/post/27644282840/ss69-release- quicksil...](http://blog.qsapp.com/post/27644282840/ss69-release- quicksilver-1-0-draws-nearer)

Maybe development didn't follow at the same pace as before, but to say it "fell apart" when they are very close to releasing 1.0 seems not very accurate to this outside observer.

<comment><USER19> Much of what is left of Quicksilver today is about fixing bugs and keeping it on life support which is why I used the term "fell apart" instead of "dead". This was an app that the developer stopped programming for in 2006 and the bug fixing didn't really start until last year. Th plug-ins to other apps are part of what made Quicksilver great and most still don't work and haven't been updated since that time.

<comment><USER5> Sounds like a great idea for a kickstarter.

I'd still take "basic bugfixing and maintenance" over "gone completely" however.

I suppose in some sense it's a bit like owning a classic car, the warranty and support from the manufacturer is long since gone but there exists a community of owners and refurb businesses keeping it alive.

<comment><USER19> The difference with your car analogy is that the car doesn't stop working because other cars are adopting new technology or that the roads became worse. Quicksilver broke once Leopard was released.

</comment></comment></comment></comment></comment></comment><comment><USER21> It's a fair point, but I'd suggest the main reason people get upset is it feels like they've somehow wasted time getting attached to it.

People such as the OP get excited about having this pleasant thing in their life and the implicit relationship in that as long as you buy it, it will continue to improve.

For me it's the same reason early adopters back certain tech products, why fans will follow film directors and why we sometimes get disappointed when they don't follow the path we hope they would take.

</comment><comment><USER22> This feels to me very much like the argument that "it's not worth voting unless my vote is specifically the one that changes the outcome". You are but one little person. You can do all the right things in the world and the universe can still stomp on your face. The right things are not "the right things" because they _guarantee_ success, but because they _maximize the odds_ of it. There are no actions that guarantee success.

This isn't a disproof of the "don't be a free user" philosophy; it's a disproof of the idea that it's a guarantee of success, which it never was, and never could be. The argument still holds.

<comment><USER23> > "it's not worth voting unless my vote is specifically the one that changes > the outcome"

I think that's a bad comparison - it implies the outcome would have been different if _everyone_ voted with their wallets. Yet a saturated market would increase the odds of an acquihire.

<comment><USER24> If _everyone_ had bought Sparrow, they would have had enormously larger revenues. Almost as important, they would have had much greater certainty in some portion of future revenues. That certainty is economically important, one reason for taking a chunk of Google Cash is checking off the 'funded retirement', 'funded kids college', 'bought house' items off the to-do list.

They also would have been more likely to attract investment for development without a big partner.

They might still see reasons for joining Google, but financial security and investment would have been less important.

</comment></comment></comment><comment><USER25> _If you're not paying for it, you're not the customer; you're the product being sold._

I don't think it has 'failed', as the article states. Paying for the software is necessary but no guarantee. If we slide back to everything being free, things will be worse. But even if we do pay, we cannot forget one very important thing: We are dealing with very small companies and all of the volatility that comes with them. The situation is simply exacerbated when the employees of that company are highly sought after.

It doesn't take Google to buy out a little company. They can just choose to get other jobs or spend their time other ways, get bored with the product, have a falling out, anything. Sparrow could have just as well said, "We're stopping all development on the email client today. 100% of future effort will be on games". And that's why boring enterprise software from MegaCorp still generates huge revenue, because they can go tell a GE, Chase, Honda or McDonalds something LittleCo can't. They can tell the customer that they can expect a specific level of support and life from the product, and here's 20 years of history to prove it, and that they're signing on with a $5 billion company that's not easily bought out. The cool stuff on the bleeding edge may also be fleeting. Large companies want stability, and I guess people using certain software do too.

Side-note: FOSS is a very different animal with interesting characteristics.

</comment><comment><USER26> " _This_ is the core of the disappointment that many of us feel with the Sparrow acquisition. It's not about the $15 or less we spent on the apps. It's not about the team's well-deserved payout. It's about the loss of faith in a philosophy that we thought was a sustainable way to ensure a healthy future for independent software development, where most innovation happens."

I seriously laughed out loud.

Don't get me wrong, I don't necessarily think his idea is silly, and I think he may in fact have a point. However, let's not pretend all those people who complained about the acquisition were doing this because they lost faith in this philosophy. _That_ part is silly. Those people were just being slightly dramatic because they liked a product and it would no longer get updated.

</comment><comment><USER27> I think part of the problem in all the hubbub around the Sparrow acquisition is the attempt to represent people's apprehension as a single entity. The reality seems to be more complicated than that.

Some people are probably just upset because of an irrational sense of entitlement ("I paid for X, and now I won't get free updates forever as the product is being abandoned")

But there's lots of other reasons that people can be bothered by this.

I use the Mac version of Sparrow (without using Gmail), and the entirety of my reaction when reading about the acquisition was "Oh well, I guess at some point I'll have to find a new desktop email client. That sucks, I liked Sparrow."

I do wonder what the community reaction would be if it was a different product though.

If Sublime Text (which seems to be attracting a good following) announced tomorrow that they were being acquired, and that the product was being abandoned, would people complaining about it really be that surprising?

Even assume that they were also going to continue with maintenance on it, but stop active development of new features. People would be upset. People on here would say "You should never have assumed that Sublime was going to get new features before buying it, if it didn't do what you wanted now, you shouldn't have paid money for it" (I've found myself actually giving similar advice in the past regarding buying smartphones).

People would write asshole-ish blog posts saying that those people were whining.

I don't think this is actually an indictment on the "paid vs. ad supported" dichotomy. Other people have rightfully pointed out that companies get acquired like this all the time, regardless of whether their products are free, cheap, or expensive.

</comment><comment><USER28> The reactions across the board are quite disappointing, to be honest.

All you can do as a customer (or as anything, for that matter) is give up the illusion of control.

This is the Sparrow story: A fantastic product was built, and exchanged for money. The people behind the product were recognized, and were acquired for a significant amount.

Everyone is a winner, and customers move on to the next thing.

What's more worrying is our reaction to an email client going under: it's clearly a sign that we don't have enough well designed products for a system that's been in mass use for more than a decade.

<comment><USER29> I completely agree with the fact that there are no well designed products for email, now that Sparrow stopped developing new features - hopefully someone gets a cool idea and puts it on the app store soonish.

</comment></comment><comment><USER30> "If you're not paying for it, you're not the customer; you're the product being sold."

This statement is complete nonesense and I do not understand why it keeps appearing everywhere.

You are almost always paying for apps and services, and you are never the product being sold. Sometimes you pay with cash, sometimes you pay with ad impressions. But you always pay and you are always the customer that needs to be satisfied.

Facebook is not free. You pay for it with your willingness to have Facebook show you ads. Ad impressions are as good as money for Google, because they can exchange them for USD.

Google Search/Gmail/Maps are the products. And Google has to make them as good as they can. Otherwise you, the customer, will stop paying for them.

<comment><USER31> "If it's not being bought, it must mean that it is sold" is just bad logic, plain and simple. It's just a nonsensical retort to an attempt to pigeonhole technology facilitating transactions into stupid categories that were made for a paradigm of classical economics, but still falls within the confines of the paradigm.

</comment></comment><comment><USER32> It's all about value creation. Assuming every party here is rational: Google decides to pay for the Sparrow team only because the potential value of these developers is much higher than the price they pay. And Sparrow team accepted the offer only because the big pay check exceeds the value all their own customers combined.

If we hate this, we can either make such talent acquisitions less attractive, or increase the value of software customers.

Talent acquisitions become less attractive when:

      - The number of talents available increases significantly
      - Economies of scale in software business is less substantial
      - There's ethical pressure from online communities
      - The act of "selling customers" (through data collection or ads) becomes less profitable or costs more (with things like DNT or ad blockers)

The value of customers increases when:

      - More people are willing to spend more money on independent software development
      - Access to software market is easier (with things like app stores)
      - More revenue streams with higher payouts (like high-quality ad networks such as Deck and Carbon)
      - Higher potential to get big (with VC money and building platforms/ecosystems)

The sad truth is, independent software developers tend to be less entrepreneurial than startup founders (but I don't think the line can be drawn clearly). They are only a little bit more entrepreneurial than consulting developers (which are even more likely to be hired by big companies, but we don't care much about them). Therefore they may not be willing to actively improve their revenue by taking risks, and hence the acquisitions happen.

<comment><USER33> > independent software developers tend to be less entrepreneurial than startup > founders

Why is that? Because they have a working monetization model when they launch?

<comment><USER5> In some sense they are less "ambitious" I guess.

Risk/Reward scale:

Selling your labour -> Selling your skills -> Selling your product -> Selling your vision

</comment></comment></comment><comment><USER34> The whole argument seems backwards to me. If your dream was that good software could be supported by users alone (not ads or a giant corporate checkbook), and by your own admission they were selling the software at a price-point below the value you were getting from it ("I'd have given them more money if I could")...

It sounds like you got exactly what you want. You got software that worked great, that avoided the traps of "you're the product" and produced a positive result for everyone. Then they got bought. But you know what? A thousand teams of engineers are ready to take their place, since a big payout at the end means there's considerable draw, and you really can sell an app at a bit above costs, be comfortable, and that allure of a _maybe_ payout at the end is enough to get over the hurdle of starting.

I guess it baffles the mind. It's like saying that big paychecks have ruined sports, because strong athletes are only in it for the money. Perhaps they are, but you get people who would otherwise do something else being willing to give sports a try because that potential paycheck is enough of a draw.

</comment><comment><USER35> After residing in unix-land for almost a year I decided to come back to Mac OSX just 2 days ago, and after re-downloading my purchased apps, the announcement by the Sparrow team was the second mail I picked up. Fuck.

Thinking back, in unix-land no such jokes were pulled. Something abandoned? another trooper taking over. How the $#&% can you charge money for something _non-open-source_ and then just leave it to rot?

I would pay a hundred bucks for a similar app (or a monthly fee) if I'd be assured that the developers were dedicated to ME and THEIR PRODUCT.

Sparrow is above average. Congrats, I loved you for that. But you sinked your goddamn ship before it got half way. I'm only this pissed off because it could have been so much more. I will wait and see what glorious work you do for Google. I (and all the people who paid you money) await your work with great anticipation. Good luck.

<comment><USER36> Just a few nitpicks:

"After residing in unix-land for almost a year I decided to come back to Mac OSX..."

OS X _is_ a UNIX. A real, actual UNIX.

"...in unix-land no such jokes were pulled."

I am going to guess you were using Linux, which is not, in fact, a UNIX.

For what it's worth, I spent some time in Linux land. Over the course of a year:

1\. One update left my system non-booting. After considerable research, I think I discovered it was a grub/kernel incompatibility.

2\. An upgrade left my system non-booting. It was an Ubuntu upgrade from one version to the next, which failed with a mysterious and non-helpful error.

3\. Another update caused my external monitor to no longer display the desktop correctly. I was forced to use the 1024x600 display on my netbook instead.

I am now very skeptical of Linux (on the desktop) land. All these issues resulted in a considerable time expense for me.

Now I'm thinking I'm happy to pay $x for operating systems like OS X or Windows...

</comment></comment><comment><USER37> Oddly enough, this is exactly what Stallman is on about. Without the source code and the ability to upload that code on to your devices, your programs longevity are subject to the whims of other people.

Even ignoring the whole "code wants to be free thing", the source is important for the longevity of the code. If the software really mattered to you, you would negociate a license that gave you source. Even if you weren't allowed to resell or redistribute, having source that you could hire others to work on if you needed it is important.

In fact, I'd love to see a shift to make proprietary software include the code without license to redistribute the original code; Maybe just patches, maybe nothing. But I'd love to be able to peek beneath the covers and learn, fix things, and/or make sure it runs on new platforms.

<comment><USER38> That seems pointless, because then patches could not be distributed. Seldom are patches economically viable for exactly one person to create, one at a time, for themselves. That's the same burden of being a proprietary software company without any potential upside.

Maybe for an organization, and in those cases a source-code escrow is not unheard of. But really it's just a lifeboat so you can move on gracefully.

</comment></comment><comment><USER39> I don't know why everyone keeps referring to sparrow as 'indie' developers. They took funding. When you take funding you're no longer independent.

<http://techcrunch.com/2011/02/09/sparrow-mac-mail-app/>

</comment><comment><USER40> The reason sparrow had to sell is because they didn't have a recurring revenue model. This is what limits all "pay once" desktop (and mobile) software: either they have to charge prohibitively high amounts or they have to get you to upgrade frequently. The former limits adoption and the latter is tricky and encourages feature bloat.

I now want to pay for the desktop software I like as a subscription: it keeps the developer fed and on call, and doesn't put undue pressure on them to add features, while still keeping their revenue from me contingent on the continued usefulness of their product.

<comment><USER41> Nobody outside the developer community will ever pay for any software on a recurring basis, especially if free alternatives are available.

<comment><USER42> [http://www.adobe.com/products/photoshop/buying-guide- subscri...](http://www.adobe.com/products/photoshop/buying-guide- subscriptions.html)

</comment></comment></comment><comment><USER43> For me it's as simple as knowing a product I like is not going to be developed anymore, and having a complete lack of faith in Google to use them to turn out anything near as good.

</comment><comment><USER24> If you build something of strategic value to a big player, they'll pay more for it than the present value of its expected cash flows. They're expecting improvements in cash flow in other, non-competing products, which they can realize but which the original product will never see. Big players will "overpay" for something of strategic importance.

So if the hope is that buying small products will free you from the big players, yeah, that was always dubious, at least in the corners interesting to those players.

On the other hand, Sparrow got built, didn't it? And whatever you liked about it just got a big fat Market Stamp Of Approval. It wouldn't be surprising for similar features to start appearing in other mail clients, some of them open source. Maybe someone will build Sparrow The Sequel ("Google didn't get every egg in the nest . . ."). VCs just got more interested in pitches for email software.

How much this matters depend on what you want. If you want freedom from "you are the product", the complaint makes more sense to me. But if what you want is more innovation, well, Sparrow's DNA just demonstrated its ability to generate returns. And returns on innovation more generally have been validated. So it isn't clear to me that buying Sparrow "failed" to push innovation forward.

</comment><comment><USER44> Contrary to the tweets, I think it's perfectly fine to be upset about sparrow no longer being developed.

The days of software being unchanging are gone, that's a pre-internet way of thinking about computing, and it's perfectly fine to be upset that something you rely upon is no longer supporting you into the future.

We live in an era where there is an expectation that our software titles will keep pace with the rapidly changing nature of technology. The business model of ios is simple, the vendor takes 30%, while the developer is free to lure new customers with additional innovations/features without having to worry about the expense of updating everyone who has purchased the title already. It's the life blood of competition and a business model that many titles adhere to.

So whether the developer is updating the code for new devices, adding software features that are relevant to new emerging technologies or simply staying relevant by supporting the latest standards. We treat software like a journey and not a static point. Software titles compete by out innovating each other. The moment this stops the software title is dead, it's competitors overtake it quickly and rarely would any of us rely on a piece of software that is no longer being developed.

</comment><comment><USER45> The solution to this is insisting on guaranteed support periods/contracts for software you use - if this comes free, great! If you have to pay for it, so be it.

Paying more for something just so you can nurse a philosophy you like is textbook irrational. If you are paying more for something vague, pin down what you want and pay for that precisely. Here we have a fear of software we love disappearing - pay, explicitly, for it not to disappear.

</comment><comment><USER46> Thing is, Sparrow was relatively cheap. And as I understand, they had a team of 5. So perhaps they were not as 'self-sustaining' as we assumed.

I guess the take-away is that, if you're going to remain independent - you had best charge a premium. In fact, Sparrow already was a premium app - so it is conceivable they could have doubled or tripled the price of their product with minimal impact on the size of their customer base.

</comment><comment><USER47> I'm not upset about the acquisition. I'd be happy if Google was acquiring them to put extra muscle behind developing the app. But they are moving the developers to other projects. That means a fast, native email client for Mac isn't on Google's agenda. So I'm back to Mail.app or the browser. Gmail on Chrome is good, but for me and a lot of other users of Sparrow, it's not a replacement for the real thing.

</comment><comment><USER48> The philosophy is modelled incorrectly.

Rather than being paying customers of a software costing $15 and expect support _forever_ , be a paying customer of software costing $5 a month and expect support every month, while you're paying.

With regards to perpetuity software, the developer only has incentive to keep on building the product whilst the market is relatively unsaturated. When the entire market has purchased the product, the developer is no longer incentivized to produce new features besides the ones he must build to fulfil his contract (e.g. fixing bugs).

With a monthly subscription model, the developer must continue to improve the product, lest his customers switch to alternatives.

</comment><comment><USER49> Shh.. Sparrow for Windows was just a few weeks away. <http://tmblr.co/ZWzfbyPpHG3B> <http://t.co/OBeYi3Zp>

<comment><USER50> Nope: [http://www.theverge.com/2012/7/21/3174803/sparrow-for- window...](http://www.theverge.com/2012/7/21/3174803/sparrow-for-windows- never-existed)

</comment></comment><comment><USER51> This is not true for me. I'm happy for the Sparrow team, but I got upset because I feel when I purchased their product, I got into an implicit, unspoken contract with the developers that while the current version of the product was good, there would be continued development and it would become something wonderful next year, and even better the year after.

Now I'm just sad the product will rot over time.

I know the commercial model is broken for this, but I would have been willing to pay more upfront and pay again for periodic major version bumps, assuming pace of development continued.

</comment><comment><USER52> I've downloaded Sparrow on my iPhone and used it for a bit but then later switched back to the native email app, primarily because of the lack of push notification at the time of its initial release. I wonder how much of this sale has to do with the updates to email in ios6, such as the ability to attach photos directly from the mail app. Can they differentiate enough to continue to keep an active user base? if not its hard to beat a native app.

Can't comment on the Mac, haven't tried it.

</comment><comment><USER53> There's also the very basic disappointment that a piece of good software won't grow to maturity. I finally found a mail client that restored my faith in SMTP as a communications medium; a mail client that had me managing email exclusively on my iPhone. A mail client that broke away from email as a metaphor for paper envelopes with written messages on pulp.

I liked handling email in Sparrow. It felt modern, and now it won't get any better.

</comment><comment><USER54> > I paid full price for every version of the Sparrow app I could find. I told > everyone who would listen to buy it. I couldn't have given them more money > even if I wanted to. So, as a customer, what more could I have done to keep > them running independently?

This could have been avoided if their software were open source, or if they committed to open sourcing it should they cease development on it.

<comment><USER55> How does switching to zero revenue possibly avoid the problem of developers not getting paid enough?

<comment><USER54> While I agree that there is a problem of getting paid for writing open source software, it is not quite that they all make zero revenue. There are several possible revenue models for open source.

Also, there is the other option I mentioned, that they commit to open sourcing it _if_ they cease development on it. That kind of commitment can make people buying the software safe from having the product discontinued.

</comment></comment></comment><comment><USER56> It seems to me that the real story here is that software is starting to face real and widespread commoditization on a deep scale.

Software has always been a very high-end, specialized line of work, and qualified many developers still expect to make upwards of 80K a year (at least).

Well, what happens when the software industry starts suffering from the same crisis as the rest of the economy, in an irreversible way?

<comment><USER57> I think there's software and software. Software for the masses, that adresses the masses needs, well, hello commoditization. Now there's another job which is to tell people with bucks how to make more bucks with computers. If they have 10 bucks, well, your value will be in the range of 1-2 bucks. If they have one billion, then you might help them a bit more and grab the money. The only one who make money with the masses are Apple, Google and the like. Except a few really complicated things like Amazon, PayPal or really "sweet spots" like facebook, I'd think the probability to have a deal is super low. So what's the solution ? Well I don't know. I guess we won't be able to advertise things ad infinitum... So we'll be back to added value sooner or later.

</comment></comment><comment><USER58> Actually, I don't quite get why users are so upset about this. They said they would keep releasing maintenance and security updates, so hopefully, I will be able to keep using this app for quite a while.

Because the thing is, I think this app is quite wonderful the way it is right now. I don't need any more features. As long as I can keep using it, I will keep being happy with it.

</comment><comment><USER59> The real problem is that most acqui-hire teams disappear into BigCo never to be heard from again until they resign a few years later.

</comment><comment><USER60> Not that it would have prevented this, but the App stores really need to work on an paid upgrade process. It's hard making $10 a head on software, especially when that's all you're ever going to make. I can't believe paid upgrades aren't a part of at least the Mac App store yet.

</comment><comment><USER61> What should have happened is to hand off development and/or ownership of the app to another dev team. Sofa, the team that made Versions and Kaleidoscope, did just that when they were acquired by Facebook. The apps still live on, thanks to Black Pixel, and everyone is happy.

</comment><comment><USER62> I think that's why you need to put your money into open source software, not closed source software. Mozilla thunderbird could be the next Sparrow. If the people with the vision and with the proper backing are willing to put the effort into it.

</comment><comment><USER63> According to Einstein, insanity is doing the same thing over and over again and expecting different results.

A cooperation is not the natural "business" model for software. It's a club. One won't get different results if one uses the same business model.

</comment><comment><USER64> Sparrow is never independent OK?

They depend on GMail.

They cannot even deliver push-notification for their iOS apps because they don't want to save your credentials on their servers.

The argument around Instapaper still stands as long as it's an independent, complete product.

<comment><USER50> > Sparrow is never independent OK? They depend on GMail.

False. Sparrow works with any IMAP mail server.

</comment></comment><comment><USER65> "We decided that we don't want to be free users any more. " "The philosophy..." "This is why I am a paid subscriber to services like..."

Sorry but you are an idiot if you really believed that.

</comment><comment><USER66> I never understood "If you're not paying for it, you're not the customer; you're the product being sold." It's clearly not true in the free software world.

</comment><comment><USER57> Pfff... The market has just "adjusted" : the value of a mail client is close to 0. That's what you pay almost zero for it; and that's why Googl payed almost 0 for its developers as well. Selling a mail client in the 21st century ? Let me laugh... There's 0 added value in it. All you do is provide a mrginally better experience and all the devs get is to solve the exponentially harder support issues. Their business model was wrong. Because a business model is not how to make money, it's how you are useful in the global scheme. Sparrow was not that useful it seems...

</comment><comment><USER67> >If they don't — well, at least they've eliminated a competitor, and they still win.

Since when was Sparrow a competitor to Google?

<comment><USER68> Adverts-wise, anything that shows Google's content without making ad-revenue for Google is a potential pie-eater they can eliminate.

<comment><USER69> Gmail supports POP3 and IMAP and they even mimic an exchange server, I think it's clear they think it's in their own best interests to give people a lot of options for accessing their email even if many of those options don't serve ads. I don't believe I've ever seen an ad on any of gmail's own mobile offerings, either.

</comment></comment></comment><comment><USER70> Am I the only one who didn't use it Gmail accounts?

<comment><USER27> No, I use the Mac version for my IMAP email account as well (I'm in the minority of people who finds gmail to be awful).

I suspect we're a tiny tiny minority though. ;)

</comment></comment><comment><USER71> Was Sparrow profitable?

<comment><USER72> [http://www.businessinsider.com/dom-leca-interview- sparrow-20...](http://www.businessinsider.com/dom-leca-interview- sparrow-2011-8?op=1)

>In terms of numbers we've made more than half a million dollars in the past six months since Sparrow was introduced in February.

That quote is from August last year.

</comment></comment><comment><USER73> Could it simply be that Google is willing to so overpay for engineers that it makes sense for Sparrow, which, in previous times would itself be a nice successful small business (like eudora used to be, etc.)

Back in the day, Sparrow might have grown over 5-10 years to be a big company to get swallowed up... but now, companies like google are so desperate for talent that they cut them off too early by making absurd offers?

As much as I hate working for big companies (and refused googles constant, persistent pursuit to go work for them) I'd be tempted by a $25M "Signing bonus" (or whatever a Sparrow Founder's split of that is....)

<comment><USER74> I think this is not about the engineers that built the company, but about the VCs that funded it. Usually the contractual conditions put the VCs in control of the situation so they can take an exit when it presents itself. Sometimes the original owners get nothing out of these acquisitions.

Edit: clarification.</comment></comment>


The Curse of Contemplation is thinking too much - <AUTHOR> https://46bit.com/journal/2011/curse-of-contemplation/

<comment><USER2> learn to meditate. it's pretty much trying as hard as possible to think about nothing (including not thinking about not thinking about anything). despite the apparent paradox, it does seem to help.</comment>


Google not indexing Craigslist – SearchTempest switches to Bing - <AUTHOR> http://www.tempestblog.com/2013/03/14/google-not-indexing-craigslist-searchtempest-switches-to-bing/

<comment><USER2> I left a comment on the original blog which I'll also paste here in case people want to understand what happened.

"Hi Nathan, my name is Matt Cutts and I'm an engineer in the search quality group at Google. Thanks for asking about this; it helped the indexing team uncover an issue in how we're indexing Craigslist, and we're in the process of fixing it right now.

To understand what happened, you need to know about the "Expires" HTTP header and Google's "unavailable_after" extension to the Robots Exclusion Protocol. As you can see at [http://googleblog.blogspot.com/2007/07/robots-exclusion- prot...](http://googleblog.blogspot.com/2007/07/robots-exclusion-protocol-now- with-even.html) , Google's "unavailable_after" lets a website say "after date X, remove this page from Google's main web search results." In contrast, the "Expires" HTTP header relates to caching, and gives the date when a page is considered stale.

A few years ago, users were complaining that Google was returning pages from Craigslist that were defunct or where the offer had expired a long time ago. And at the time, Craigslist was using the "Expires" HTTP header as if it were "unavailable_after"--that is, the Expires header was describing when the listing on Craigslist was obsolete and shouldn't be shown to users. We ended up writing an algorithm for sites that appeared to be using the Expires header (instead of "unavailable_after") to try to list when content was defunct and shouldn't be shown anymore.

You might be able to see where this is going. Not too long ago, Craigslist changed how they generated the "Expires" HTTP header. It looks like they moved to the traditional interpretation of Expires for caching, and our indexing system didn't notice. We're in the process of fixing this, and I expect it to be fixed pretty quickly. The indexing team has already corrected this, so now it's just a matter of re-crawling Craigslist over the next few days.

So we were trying to go the extra mile to help users not see defunct pages, but that caused an issue when Craigslist changed how they used the "Expires" HTTP header. It sounded like you preferred Google's Custom Search API over Bing's so it should be safe to switch back to Google if you want. Thanks again for pointing this out."

</comment><comment><USER3> Considering that craigslist is hostile to basically everyone who tries to use anything on their site for anything (fair use or not), I'm not sure I have any problem with Google simply ditching them.

<comment><USER4> I'm really surprised that so many people trust Google so implicitly that they'd relinquish their choice of not using a site when it appears in Google search results - in favor of letting Google deciding whose business practices deserve their being listed at all.

Especially when it comes down to a site allowing fair use of their content.

From what I can gather, Google can and does penalize sites that show copyrighted content even when the site has very legitimate fair use claims. DMCA notices are never served and never appear on chillingeffects.org. The sites aren't even delisted, as described in Google's "Transparency Report"[1], but rather moved to lower and lower positions in the search results. Google will never acknowledge that the site is being penalized, and it seems that completely removing the "offending" content won't resolve it. (Source: personal experience.)

[1] [http://www.google.com/transparencyreport/removals/copyright/...](http://www.google.com/transparencyreport/removals/copyright/faq/)

</comment></comment><comment><USER5> <http://www.craigslist.org/robots.txt>

<comment><USER6> Doesn't seem to include the /sys posts that are the main topic of discussion. Unless it has changed?

</comment></comment><comment><USER7> Why is Google not indexing craigslist?

<comment><AUTHOR> Looks like it's probably a bug: [http://productforums.google.com/d/msg/websearch/p6VbIaBkbWA/...](http://productforums.google.com/d/msg/websearch/p6VbIaBkbWA/B1q96Q1V0WgJ)

</comment></comment><comment><USER8> why would I search on Google, Bing or where ever and not just use the search on craigslist?

<comment><AUTHOR> The most common reasons are that you want to search multiple cities at the same time, or that you want to use advanced logical operators.

The nice thing about SearchTempest (in my obviously biased opinion) is that you can set a radius to only search nearby cities, rather than the shotgun approach of googling (or binging) everywhere.

</comment></comment><comment><AUTHOR> It's really amazing how little attention the Google problem is getting so far. It seems like most people search, see some posts in the past few minutes and some in February, and totally miss the fact that there's nothing in-between!

</comment><comment><USER9> Side note: I was just wishing I could search across all of CL. (Looking for a particular car.)

However about half of the ads that were relevant had expired. Do you have a way of dealing with that?

<comment><AUTHOR> We do. First off, the reason that's happening is that Bing (and Google before it) indexes craigslist pages, but has no way of knowing immediately when a previously-existing page disappears. They obviously can't be continually spidering every single page on the site to see if it's still there, and while craigslist could notify search engines of deleted posts, they have no incentive to do so.

Some searches tend to have more expired posts than others, but if you find they're a problem, we have a couple of alternatives. For searches across the whole country, the best option is RSS feeds. (Too bad 'RSS is dying' and all... ;) ) You can run any search on SearchTempest and click the 'Get Feeds for this search' link to grab an OPML file of all the craigslist results RSS feeds matching your search, within the search radius you specified. Import that file into a folder in your favorite RSS reader, and you've got a convenient, auto-updating feed of new results for your search, straight from craigslist.

The other alternative is our Direct Results mode. Basically that just opens up two windows: one for the results from craigslist, and one as an index to flip through cities. So you only see results for one city at a time, but can quickly flip through them with the 'Next' link. Obviously that can take a while for searches across the whole country though, so we recommend it more for smaller searches. Basically just a small optimization compared to manually opening up and pasting a search into a few separate CL cities directly.

More info here: <http://www.searchtempest.com/faq.php#deleted>

<comment><USER9> I guess you've gotta do the best you can with what you have to work with. ;)

Thanks for building this!

<comment><AUTHOR> I almost think that should be the site's tagline.

And you're welcome. I actually built it back in 2006, but it's evolved a fair bit since then!

</comment></comment></comment></comment><comment><USER10> I wish they would make it less ugly.

<comment><AUTHOR> 'They' craigslist, or SearchTempest? I can't do anything about the former, but I might be able to for the latter! :) (Our blog, certainly, could use an overhaul, but there's never a time when I would prefer to do that than work on the site itself!)</comment></comment>