It's Getting Harder to Tell Banks from Tech Companies - <AUTHOR> https://www.bloomberg.com/view/articles/2018-02-15/lloyd-blankfein-wants-goldman-sachs-to-push-technology <comment><USER2> I work for a large healthcare system, and the "we're not a tech company" line is often heard. At many levels, I agree—we're in the business of delivering healthy outcomes to our communities, so we need to make sure that efforts across the enterprise support that—but it is often applied in ways that stifle us from delivering what we feel would be the most impactful and cost-effective solutions.

I like to respond that Netflix isn't a tech company, either—they're in the business of delivering entertainment. Their position and reputation allows them to build a stronger engineering culture, but their technology still is subservient to their non-tech business goals. While "software is eating the world" has been quoted to the point of being a cliché, the organizations that recognize software as a competitive differentiator—rather than merely a cost center—definitely have an edge against their tech-averse competitors.

<comment><USER3> I work in technology for an investment bank and i hear "we are not a technology company" every quarter. Ironically, the tech we develop is a major factor, if not the only factor, for revenue. My motivation is instantly shattered when i hear that.

<comment><USER4> I used to work in another financial-related company and "IT is a cost not a revenue center" was thrown around as often as possible. Raise, promotion, formation, a computer made in this decade, anything really would get us that answer. Not only from my boss, but from the IT's top director in various meetings and one-on-one. I used to find it highly frustrating and unfair given that the company would cease to exists without our software, and that all new customers were acquired through new development in our software.

Now that I'm older and not working there anymore, I understand that it's a culture problem and that management just didn't know any better, but I've come to accept the fact that it was a great way to cut costs and get away with it. After all, they still have many employees and manage to make more profit year after year. It just made for a very demotivating environment.

<comment><USER5> The old "We _are_ a tech company, we just happen to do retail/advertising/communication/movies/hospitality/transportation/payments better than you idiots" seems to be working pretty well for Amazon/Google/Facebook/Netflix/AirBnB/Uber/Lyft/Stripe.

</comment></comment></comment></comment><comment><USER6> I'm of the opinion that all banks _should be_ technology companies, in that pretty much all of their operations rely on computing, so the better they are at developing and operating computer systems they better they'll be able to do business.

Unfortunately, many banks (at least in the UK market) seem to see IT as some kind of overhead, to be minimized in cost and/or outsourced (e.g. Lloyds outsourcing to IBM [https://www.theregister.co.uk/2017/06/06/lloyds_confirms_ibm...](https://www.theregister.co.uk/2017/06/06/lloyds_confirms_ibm_cloudy_outsourcing/))

Of course there are ranges of new banks (the UK has a range of challenger banks most of whom take a more tech-focused approach) to challenge the "traditional" approach, and it'll be interesting to see how that shakes out...

<comment><USER7> The problem is legacy culture & systems. Theres almost no chance of a transformation unless a paradigm shift in senior management thinking takes place.

Maintaing their mess costs massively and large projects carry risks and a bad track record no one on top can support.

Too bad the fintech revolution lost some of its momentum challenging the profitable areas of banking

<comment><USER6> I'd agree that a paradigm shift is definitely needed to address the problem. Banks need to see that constant investment not "put it in and let it run for 10-15 years" is what's needed.

And yes the point about risk of new projects... who wants to lead a project to replace a mainframe system that's been running successfully for the last 30-40 years and if it goes wrong you're guaranteed to be on the front page of the papers...

I wonder if a pattern will emerge where big banks let the challengers develop the tech, then they buy them and move across to it, once the kinks are all ironed out.

</comment></comment></comment><comment><USER8> One of the large trends in financial technology development that I've seen is that banks seem to heavily prefer that their staff leave and form third party software service providing companies than hire and allocate resources to internal teams. This means transaction costs are driven up massively, but the leading industry players typically deploy innovations in tandem with their competitors.

My banker friends have big problems trying to modernize sections of their operations on the basis that too much political capital is needed to liquidate entire floors of staff - but that restriction only lasts until someone has an off-the-shelf solution offering 25M in labour savings per quarter.

These inefficiencies and cultural issues hamper execution leading to poorer client outcomes, lower margins, and weaker strategic positioning.

I'm glad that some banks are pushing forward to gobble up that easy ROI, but I am concerned that the net effect of this type of automation is systemic risk, as the industry begins to bifurcate between low and high margin banks, and the latter are afforded accelerating capability to consolidate the former.

Less players. More capacity. More reliance. Less redundancy. Not necessarily bad for John Q. Everyman, but if he's ultimately carrying that risk while pocketing none of the efficiency gains...

</comment><comment><USER9> This sounds like marketing baloney. I would bet most of that "engineering" headcount is actually just analytical headcount. not a bad thing, but it's not what we used to call engineering.

This is part of an ongoing trend to describe everything as some form of "engineering."

Honestly, if I'm going to Goldman for M&A - I want a human relationship. That relationship may be buttressed by research and analysis using "big data" and "machine learning" \- but that's not engineering, that's just good research using the latest useful tools.

I'm only addressing the actual investment banking component of GS. Sure, the consumer banking stuff requires technology and "engineering" but there's absolutely nothing new about this, it's just that consumer banking has lagged horribly behind in consumer-friendly technology.

Not much to see here.

<comment><USER10> To be honest Software Engineering looks like child play when compared to actual engineering work.

Imagine the left-pad incident in a different engineering domain.

<comment><USER11> It's a bit disingenuous to draw parallels between 24x7 electronic trading operations and javascript web cowboys.

</comment></comment></comment><comment><USER12> The idea that companies can be defined as a binary "tech company" or "not a tech company" is a trope created by tech VCs/entrepreneurs as a means to signal that they are "special" from businesses that we created more than 15 years ago.

Most of my clients (mainly PE investors) typically define companies as either "Tech enabled", "tech lead", "nothing". This means usually two things to them: (1) the more tech enabled the higher the margins (EBITDA) I can achieve and (2) the more tech enabled the higher the multiple I can achieve.

And that's just it. Everything else is marketing.

</comment><comment><USER13> That being said I wouldn't say Goldman is your typical bank. Other banks are much slower at embracing automation and software development is more often than not considered as a non strategic commodity which budgets and headcount fluctuates up and down based on how much is available for discretionary spending. And the statements from its senior management are also too often aspirational and disconnected from the reality of the organisation.

<comment><USER14> That's interesting to hear! I'm going through "Flash Boys" right now, and it (to me at least) paints GS in a pretty negative light wrt their engineering culture.

Granted the book mostly focuses on HFT firms, so I could easily see that GS is way better than most large banks but a bit lacking behind, say, Citadel.

<comment><USER15> _> That's interesting to hear! I'm going through "Flash Boys" right now, and it (to me at least) paints GS in a pretty negative light wrt their engineering culture._

As an aside, if you're not planning to already, _please_ read _Flash Boys: Not So Fast_ when you're done.

</comment></comment></comment><comment><USER16> Really? Sounds like the author has never _worked_ in either, and just reads news sites. Having worked in several of both 'MegaBank LLC' and 'A Small Tech Company', they're utterly different beasts. Just because both mention blockchain doesn't mean they're the same.

Culturally, they're worlds apart. Banks offer a career path up and away from technology so you get unmotivated developers joining who are just looking for the next leg-up the career ladder.

Banks are only driven to make money, and the "worst" of the employees are utterly driven by the end-of-year bonus, and to hell with anyone that gets in their way.

<comment><USER17> From the article:

> (Disclosure: I used to work at Goldman designing derivatives, not apps. Also > I have a Marcus savings account.)

</comment></comment><comment><USER18> Odd, I was just talking to someone yesterday about this because there was a lamentation of not enough "tech companies" in our area to work for.

I pointed out that in the DevOps Handbook one of the lines I highlighted was that in 2013, HSBC (a very large bank) employed more software engineers than Google.

So I went to search other tidbits like that and found that in 2015 Goldman Sachs employed more software engineers than Facebook.

Banks aren't companies that have tech, they're tech companies that do banking.

</comment><comment><USER19> This isnt really true. Banks dont pay anywhere near tech salaries. Its all lip service.

The flow of good engineers is always banks -> tech companies and never tech companies -> banks.

<comment><USER20> I make significantly more at GS than I did at google. The difference is that the majority of my compensation comes from the yearly bonus - a quirk in finance.

<comment><USER19> As a regular engineer? Or is there a math heavy component?

My understanding is that I could get about 200k base at goldman and maybe a 20% bonus, this is for working in a high in demand field. Google/FB/Other job I can get 300k+ while working less hours, paid for lunch, better treatment, more respect.

<comment><USER21> That's a realistic compensation package for a normal Sr engineer role at a big bank ime. No, it's not Goog/FB pay but a lot of the jobs are available in LCOL areas like Delaware and the Triangle fwiw.

<comment><USER22> That's the biggest thing some people don't take into account when it comes to salaries: cost of living. $300k is not always more money than $200k.

</comment></comment></comment></comment></comment><comment><USER23> Do they?

Have they dropped "corporate" solutions that barely work, sold in golf courses to people that are not affected in the least by their decisions?

Are they still using XML (or even worse, CORBA) as duct tape tying everything together?

Have they dropped waterfall?

Do they allow developers to have their say on architectures and solutions to use? Can they experiment with, let's say, Scala, Elixir or are they stuck with some old Java version and don't even think of adding a library besides the approved ones?

<comment><USER24> Disclaimer: I work as a data scientist at a large financial institution based in the US; to be fair it is one that has a reputation for being on the "cutting edge of tech", FWIW.

The data teams I work with don't know SAS and some members aren't even that facile with Excel, opting to use Apache Spark (mostly Python, but also Scala bindings) or pandas instead. Almost no one does serious data work on their local machines, and there is a big push to store all of our data off-prem.

The dev teams I work with actively experiment with different cloud-based architectures, devops automation tools, database solutions, etc.

From a product perspective, lots of teams use agile workflows, but each team is allowed to (and encouraged to) choose their own style of getting work done.

This is not meant to imply that banks have largely moved to this model; I think that we are the exception rather than the rule. This is _also_ not meant to imply that top-down corporate "solutions" don't affect us, and that greed has been completely factored out of the equation. But I've been pleasantly surprised by how much leverage and freedom we have as the "tech department".

<comment><USER25> Capital One?

</comment></comment></comment><comment><USER26> Tech and finance are two very broad brushes that both paint a large swath of the business landscape.

When speaking of finance there is everything from regional banks or loan originators to investment banks and trading firms. They are often very far apart in terms of culture, abilities, and pay.

On the higher end in tech you get front desk trading, and they are most definitely a tech subsidy inside a larger institution. Some of the best tech teams I've ever been exposured to. I would take the best team GS over the best team from Google any day of the week. Even a mediocre front desk team are far far above average for the industry because they focus on getting the best talent.

Even companies like Bloomberg that you wouldn't really think of beyond their news service is a massive tech company on the back end. They also have trading and low latency data infrastructures. One of the best teams i ever met was the core bond team at Bloomberg. I was blown away at how good they were.

All these places know they are tech companies and pay appropriately. On the other side you have regional banks or even old school trading firms where they aren't really tech companies, but are mostly admin work with average pay.

I've worked at tech companies and finance (hfts, algo trading, dark pool, banks), one thing i really like about finance is how difficult and interdisciplinary it can be. The tech problems I've encountered at finance firms have been so much more difficult than any other place. Google scales by throwing more machines at it, as most other web tech firms. Many times you don't have that luxury in finance. You have to be smart about it.

Remember, Google gives it developers Go because it considers them above average cogs. Finance firms gives it developers APL/A+/KDB :) I jest a little, but I think there is definitely something telling in what is expected of you.

You can go into a big bank and be a 9 to 5er in an auxiliary role. Or you can go in and workn your tail off and move up. But be prepared to work a lot for those bonuses.

<comment><USER27> > Even companies like Bloomberg that you wouldn't really think of beyond their > news service is a massive tech company on the back end

The company's entire founding premise was to computerize tasks still accomplished by humans and paper in 1981. The News subsidiary was founded nearly a decade later in 1990. So it's more a case of the tech company considering News the "News-end" rather than tech being considered the "back end" :)

<comment><USER26> I was at an APL(ish) lecture a year ago that veered off into the early years of Bloomberg. I thought it was awesome.

</comment></comment></comment><comment><USER28> I wish banks would learn what a "transaction" is. I have repeated problems with electronic banking where one party to the transaction shows it as a "success" and the other party shows it as a "failure". These problems tend to be tough for me to resolve as both parties insist on their end.

I'm almost ready to go back to writing checks by hand. Waving a cancelled check around has always worked well to resolve transaction disputes. There's no paper trail with electronic banking.

</comment><comment><USER29> I think the headline should be "It's Getting Harder to Tell Goldman Sachs from Tech Companies"...

Insinuating that all banks are becoming tech companies is being a bit too generous.

EDIT: I am pretty sure Bloomberg does A/B testing on their headlines to see which get more clicks. The URL of the article indicates that the headline may have been different to start out with. I've also often observed the same article on the web and the Bloomberg Terminal with different headlines.

</comment><comment><USER30> If by "tech companies" the OP means established technology companies like IBM, Cisco, and Oracle, as opposed to Silicon Valley upstarts, then I agree.

Otherwise, I disagree. Most banks are large, slow-moving, bureaucratic organizations saddled with decades-old technology.

<comment><USER31> Using the latest hyped thing does not make one a tech company.

</comment></comment><comment><USER32> I think another interesting paradigm is breaking up companies by:

1\. embracing technology early 2\. chasing technology 3\. last movers

Recent examples of last movers that still have been extremely successful have been TJMaxx and Costco, both functioning with very little e-commerce presence. Why does this make some intuitive sense? The first mover has to break ground and if they are successful in applying innovative technologies, they reap the benefits. Meanwhile, several companies chase this innovator, building out similar systems, but these companies are unable to catch the leader, yet still spend a ton in R&D to develop the technology or spend too much acquiring it. Eventually, third-party software is built, commoditizing much of the associated costs. At this point, being the last mover is actually beneficial since the last mover can make the same technological shift without the associated costs that the chasers faced. In 2018, every company pretty much needs cloud instances, notifications, websites, etc. just like companies in the 1970s needed switchboard operators, fax machines, etc. I think its more a question of what companies quickly adapt fundamental new ways to think about an industry than whether the company employs a bunch of developers.

</comment><comment><USER33> Is this an entire article based on a subtitle on the summary page of the CEO's presentation? Not a bad advertisement for GS but come on, this is _incredibly_ light on content, by which I mean there is absolutely zero content.

</comment><comment><USER34> I'd like to see a tech company where the time to process a simple transaction like a balance transfer is measured in _days_.

</comment><comment><USER35> Banks are tech companies. When other countries say that they trust the US dollar, what do you think that means? It means they trust that our IT systems which manage the dollar are correct. They trust that when we say Warren Buffet has eleventy billion dollars, it actually means something tangible.

And when they discover that trust is utterly and entirely misplaced, that our IT systems have been run as cost centers and endlessly rushed and slapped together and subjected to every form of intellectual rot that modern business practice could infuse into it.... well then things will get interesting. What if Walmart goes to pay off a supplier and the supplier asks for proof that the numbers Walmart is sending over the wire are actually backed by something and not just computational funny money? Well, we do have a form of money that's actually verifiably real and non-counterfeitable and doesn't just rely on some garbage IT....

</comment><comment><USER36> it is extremely easy to tell a bank from a tech company: tell if they hash their damn passwords. i'm not even talking salt here, just hashing

<comment><USER6> if you're thinking of some bank's propensity to ask for specific characters of passwords (rather than the whole thing) meaning they can't have hashed it, it's worth noting that many protect the passwords with symmetric encryption and then store the keys in an HSM to mitigate the risk of unauthorised access.

<comment><USER37> Unless the HSM is also doing the decryption, the key(s) can still be stolen while in RAM..

<comment><USER38> That's the whole point of an HSM... A somewhat tamper resistant device that executes all encryption operations. You give it the hash and a reference to the the key, and it returns the signed data.

</comment></comment></comment></comment><comment><USER39> I was just at a dev mixer and ran into an engineer at Bank of America. He told me they have 5000 Python developers on staff. I almost fell out of my chair - never would have guessed it. I know there's competition for top talent in NYC, but that's still a surprising number.

<comment><USER40> There's 100k IT workers at BofA.

The new software engineering stack is JIRA, bitbucket, Ansible, Jenkins, Artifactory, Sonar, etc. Every team is being trained on SAFe. Aka the executives choice for "agile" etc

Also the working areas are being transformed from full height or quarter height cubes to open offices where employees no longer have a laptop and use a thinclient attached to standing desks. This is a dream for information security team but personally I hate it as I spent 2-3 hours working from home every day and the rest in the office. I don't want to develop though a windows GUI in the browser :/

</comment></comment><comment><USER41> As witnessed by Bank of America's aggressive pursuit of blockchain technology & patents:

"[Bank of America] has applied for or received at least 43 patents for blockchain, the ledger technology used for verifying and recording transactions that's at the heart of virtual currencies. It is the largest number among major banks and technology companies"

[https://www.bloomberg.com/news/articles/2018-01-16/bofa- tops...](https://www.bloomberg.com/news/articles/2018-01-16/bofa-tops-ibm-and- payments-firms-with-most-blockchain-patents)

<comment><USER42> I feel like some of the reasons for this are political rather than technical.

</comment></comment><comment><USER43> It seems like banks are realizing that they need to become tech companies faster than tech companies become banks.

<comment><USER44> No, it's that it is much _easier_ for a bank to become a tech company than for a tech company to become a bank. The barriers to entry for becoming a tech company are merely technological. They are not trivial to surmount, but they are surmountable. By way of contrast, the barriers to entry to becoming a bank are regulatory, and nearly impossible to surmount, at least in the U.S. When was the last time you heard of a new bank being founded here?

<comment><USER45> There are many, many small banks in the US; you can just buy one that already has a license. Certainly not insurmountable.

<comment><USER46> None of those small banks are subject to the regulation that large BHC are. The potential barrier is off by orders of magnitude. The development cycle on those models is multi year. It would take a massive effort to recruit and build the quant teams alone, much less the finance, compliance, and legal personnel with the expertise.

</comment></comment></comment></comment><comment><USER47> Really pretty much every company is a tech company in 2018 at some level.

<comment><USER48> "Software is eating the world", came out 7 years ago and is still as true as ever.

</comment></comment><comment><USER49> It would be helpful to use the full term _Informatation_ Technology to understand these trends.

Financial institutions and many other administrative orgs have always been about storing, distributing and processing information. They did this at scale even before the advent of computers. And they were also early adopters of computers. Their _core business_ is providing service by using IT, whether that technology is computers, paper or human brains.

Back in the long ago we didn't call them IT companies, because that designated a supplier of IT equipment (and we used to think of software as equipment). But now in the age of SaaS, we think of IT companies providing services using IT, just as the banks et. al. have always done.

It's the same kind of business, evolved through two different paths, each with strengths and weaknesses. It seems inevitable that the two paths will merge.

</comment><comment><USER50> I used to work for a bank for a long time. IMHO, this new fascination with technology is kind of a fad and more of a lip service for marketing purposes. In practice, we still use MS Excel as per what we have been doing for the past twenty years.

</comment><comment><USER51> Any sufficiently large company is a tech company, and any sufficiently large tech company is a bank.

I'm pretty sure I originally heard that here on HN, I can't seem to track it down though. Seems to only have gotten more and more true as time goes on.

</comment><comment><USER52> For some reason, I thought this article would go into a different direction - like about how tech companies are borrowing money at record rates because of dirt cheap Fed interest, which to me is a sign of a new financial bubble.

</comment><comment><USER53> Banks are better described as tech companies than the media / advertising behemoths. Information security is their bread and butter.

As far as I can tell, the only thing that qualifies a company as "tech" nowadays is a technical tradition of building on open source from the ground up (eg. LAMP and its successors), while banks have traditionally been dependent on a constellation of vendors.

The open source approach has proven a more effective model and it seems that this realization has finally spread outside of silicon valley. It's about time.

</comment><comment><USER54> I don't have that feeling when I see online banking websites...

</comment><comment><USER55> Just Banks? No, "tech" - which stands for information technology- is just about everything, every industry and job is affected and will change. Information is like electricity...

</comment><comment><USER56> Haha, i heard lines like that at so many places i interviewed with. 'we're not a finance company, we're a tech company that does finance' etc

</comment><comment><USER57> I work currently at one of the larger banks, and they actually like to describe themselves as "a tech company who happens to focus on financial things". It's as true as you are willing to believe it, but modern global money movement is really just tech these days, and has been so well before distributed ledger tech came along.

Now, whether any of the banks are any good as tech companies is a different question.

(some grammar fixed)

</comment><comment><USER58> what is a tech company, really?

it's like saying something is a "concrete company" because that's what the corporate buildings are made of, or a "people company" because they only employ humans

(terms that actually make sense: SaaS product (Salesforce, Dropbox), advertising marketplace (Google, Facebook)... and so on. Not "tech")

</comment><comment><USER59> Anyone else think that the finance folks are just realizing what the tech sector gets away with by being incomprehensible and too fast for regulators? They're just doubling down and digging into tech to get away with more, for longer...

<comment><USER60> Finance have been doing this for a _long_ time.

See J.K. Galbraith's _The Great Crash: 1929_.

</comment></comment><comment><USER61> isn't it everything ? everything is techno engineered these days

uber the tech taxi

amazon the tech store

... it's the engineered era

<comment><USER62> Amazon is the way to put your product on the internet. AWS is their biggest profit center and a lot of Amazon's product sales are from merchants who happen to sell their product on Amazon (and use Amazon's fulfillment centers).

</comment></comment><comment><USER63> Sanford Weill, while chairman of Citigroup, once remarked that their main asset was information, not money (I haven't been able to find the quote but i distinctly remember it from my b-school lectures).

</comment><comment><USER63> Technology has always driven the financial markets--because better access to data is what allows new instruments and/or the active trading of new instruments.

</comment><comment><USER64> Very true (and actually has been that way for a while now). Big banks are largely tech companies that happen to do banking.

</comment><comment><USER65> [http://archive.is/D7vIv](http://archive.is/D7vIv)

</comment><comment><USER66> It's still easy to tell banks from tech companies. Banks probably won't offer you 2FA or allow you to use secure passwords and will cheerfully bring down their website for maintenance for twelve hours at a stretch. They'll also charge you mysterious transaction fees.

</comment><comment><USER67> heh yea, but no. All our clients are banks. I spent a good part of the day working on a project to convince them to upgrade their browsers to something that supports TLS1.2.

</comment><comment><USER68> Isn't every company becoming a tech company?

</comment><comment><USER69> sad

</comment><comment><USER70> meh. Software is a new form of literacy. No one goes around arguing if we have literate companies any more. It's like fish noticing water. Give it one more generation.

</comment><comment><USER71> I work in a bank and man - shits cool af

</comment><comment><USER72> Goodbye Wells Fargo, Bank of America, Citi, and the rest of the credit cartel! You will never be missed.

Hello Wealthfront, Robinhood, Simple, and the rest of the movers and shakers!

<comment><USER73> > Simple, and the rest of the movers and shakers

Yeah, a bank that announce that 1% of their customers had their account involuntarily closed with 30 days notice is sure to build trust in the new world order.

[https://techcrunch.com/2017/04/14/simple-account- closures/](https://techcrunch.com/2017/04/14/simple-account-closures/)

<comment><USER74> Simple engineer here, not representing the company's views necessarily but relaying my own opinions.

That situation was indeed a load of bullshit, but the other side of that coin is that we were doing something that has never had to happen in the history of modern banking, probably because it's insane.

You see, normally when a bank is acquired by another bank, the acquirer gets the acquiree's FED terminals, ACH numbers, deals with Visa, etc. that make the transition more-or-less seamless for customers. So customers keep their cards, their direct deposit still works, their checks still work, and all they need to do is log in to a different website to manage their accounts.

What we were forced to do was to essentially close hundreds of thousands of bank accounts at our former banking partner, open new accounts at our new partner, transfer funds, and issue new cards. And we had a contractual deadline before which the transition had to be 100% complete. We explored literally every other option available, including having BBVA acquire our ACH and Visa prefixes, but that was a no-go for reasons I'm not aware of.

So we got the vast majority of our customers to make this painful switch, which was a miracle in itself, but we could not make it all the way down the list, and that sucked. New bank means new account-holder rules, customers changed email addresses/phones, customers moved, we underestimated the complexity/time requirements, all sorts of reasons applied; but the bottom line is that it was an inevitable situation for this kind of transition, and while we did what we could, we let some customers down (0.7% to be exact).

At least I can say that we won't have to go through this again, and we're finally out of the woods with all of these platform transitions, and we're back to building products again. Feel free to AMA.

<comment><USER75> Are fed terminals still are actual physical vt100 like contraptions? Or it is simply a metaphor for a kind of API access over the internet?

<comment><USER74> I believe the vt100 terminals have been phased out for FedACH/FedWire, which are the "modernized" APIs (read: the same weirdo fixed-width NACHA format but sent over HTTP/SFTP).</comment></comment></comment></comment></comment>


I'm done building Facebook apps for clients - <AUTHOR> http://ryanwaggoner.com/2010/09/im-done-building-facebook-apps-for-clients/ <comment><USER2> Their iPhone Facebook Connect documentation is beyond atrocious. What little there is was written by someone who, besides not being a non-native English speaker, also does not care about getting things right.

Several people have mentioned how bad the documentation is, but nobody has provided examples. In case anyone from Facebook (or "facebook" as it's sometimes called in the docs) reads this and cares, I'm putting some examples from the docs below.

The problem with having mistakes in the docs, is that as the reader notices more and more mistakes, they begin to have less and less confidence in everything that is written there. Once the documentation is suspect, every word in it is suspect.

Here's an example of a sentence lifted from the docs: "i whose fields and values can be inspected and accessed."

Yes, that was the entire sentence, if you can call it that.

How about: "Application can implement these interface to handle them."

Seems like a small error, but a more important message is given to the reader: You cannot trust this document.

Just to preempt an obvious reaction, yes, you shouldn't trust any document, but there are levels of trust, and this kind of grammar makes the trust fall quickly to a very low level.

Another one: "The FBSessionDelegate is a callback interface that your application should implement: it's methods will be invoked when the application successful login or logout."

Same message there. You can't trust this.

Then there are the code examples. Here's their example of how to use something the docs call a stream.publish flow:

NSMutableDictionary* params = [NSMutableDictionary dictionaryWithObjectsAndKeys: apiKey, @"api_key", nil]; [facebook dialog: @"stream.publish" andParams: params andDelegate:self];

Ignoring the bizarre inconsistent use of spaces after colons, this example gives no clue about what else should be in the params object in order to make a publishable post. I could look it up on the Facebook developers (sic) site, but that data can't be trusted either since it changes so frequently and so little care is given to getting it right.

</rant>

<comment><USER3> This is just spelling / grammar, I have no problems with these errors, especially when the main documentation is wiki-based (this may be because I'm not a native speaker). In my limited experience with Facebook docs before the Open Graph API, I haven't seen factual errors, but there are _a lot_ of omissions.

Open Graph API seems very clean and it also seems like it doesn't need much documentation... if the API calls actually worked. I haven't used it and I don't plan to start using it given these reports (in the old API there were also quite a few things that break occasionally and take forever to be repaired).

<comment><USER4> _This is just spelling / grammar_

Some syntactic errors are so egregious as to obscure, change, or remove the meaning of a sentence.

</comment></comment></comment><comment><USER5> I agree with most of the comments here and on the blog post; having hit many of the same issues myself.

Fortunately, I get to do something about it.

I work for Facebook (joined ~3 weeks ago).

Part of my job is to help fix the developer site, documentation, etc. (along with a host of other issues related to developer relations).

We are working on updating the site and docs as fast as we can and this thread is helpful.

If you have any issues/feedback/whatever with our platform docs or API, email me at firstname.lastname@example.com and we'll get them addressed as soon as we can.

<comment><USER6> When are you going to put the Wiki back online? That should be a matter of a few man-hours of work. Until then, it's not believable to claim "We're working on updating the site and docs as fast as we can."

In my experience developing a couple of FB apps in the past, the information in the Wiki was absolutely crucial. (I'm talking about the Wiki that was located at <http://wiki.developers.facebook.com/> in the past.)

<comment><USER7> It's up now!

<comment><USER6> No, it's not.

</comment></comment></comment></comment><comment><USER8> In case anyone didn't see it down at the bottom, this comment was left on the post:

      Ryan (& Everyone Else) –

      My name is Mike Vernal, and I manage the engineering team for Facebook
      Platform.

      I understand and am legitimately sorry for the frustration you guys are
      experiencing.

      I think there were three themes in this post — frequency of change, bugs,
      and documentation. I wanted to give you some more context on all three
      points, not as a way of excusing the problems you've had but as a way of
      adding some additional context.

      Over the past year or so, we've been pushing to simplify and standardize
      our development platform as much as possible, to address some of the root
      causes of the issues you point out here. For instance, we've been trying
      to move from FBML to IFrames over the past year because we think that
      IFrames are both a lot simpler to develop for and a lot simpler to
      maintain because they're based on standard web technologies. We've also
      been moving towards simpler ways of integrating Facebook context
      (e.g., iframe-based social plugins) because they're easier to use, debug,
      and maintain.

      Our end goal is to have a technology stack that is simple and
      standards-based, because we believe that's actually the best way to
      address many of the issues you raise here.

      In terms of bugs, you're right — we haven't been doing a good enough job
      here. We're working on this. We're triaging bugs on a daily basis and
      working through the bug backlog. We're continually adding more automated
      unit + functional tests to help prevent regressions and issues in the
      first place. And we're working on our communication processes — the way
      the system works today, we actually copy verified bugs from Bugzilla into
      an internal bug tracking system, and we then use that internal bug
      tracking system to drive bugs to resolution. We don't do a good enough
      job of communicating back to the Bugzilla bug the internal status and when
      we actually push a fix, which we're working on.

      In terms of documentation, again, you're right. We're building up a team
      and focusing on this as well.

      That said, actions speak louder than words. If you don't see meaningful
      improvement by the end of October, please let me know. My email is
      email@example.com.

      Thanks,

      -mike

<comment><USER9> Very interesting. As an FB developer, some of the bugs they introduce (and re- introduce) are baffling. Their QA process always appears non-existant.

I'd like to believe him, but would have to see it first. We often file bugs that sit there forever, and some parts of their platform break on a weekly cycle, if not more often.

<comment><USER10> I worked at a company developing proprietary image processing SDKs (more like libraries) for .NET/ActiveX. We actually had very extensive QA, probably >100% code coverage (at least 1 test for most code paths) in unit and functional tests, but it's _really_ difficult to predict how customers are going to use your product.

For this reason, newer employees had to do a cycle of QA/support/dev, where you found out that there would always be one customer whose entire use case was the one case you didn't test for, and that makes your toolkit fail horribly. I'm not excusing these bugs, and Facebook is certainly a more complex platform to build on top of, but I can certainly see how a QA team could be working nonstop and appearing to accomplish nothing.

(Also note that since leaving this job better testing tools have come out/become more popular. The Ruby community especially is very oriented toward automating "mutate this test until it fails".)

</comment></comment></comment><comment><USER11> I recently ported my app back to the old Javascript API; I wish I could say that it was for the superior older documentation, but it was actually because the new API randomly stopped returning my calls from time to time.

All of the big moneymakers' apps are built on the older stuff, so I figure when it breaks, it gets a bit more love.

The documentation is still shoddy, the Bing-powered documentation search is abysmal, and when things don't work I don't understand why. I'd have happily paid a few hundred dollars to be part of the developer program and have a contact over there, but they killed that. Ah well.

<comment><USER12> More than once, when I searched the documentation, the top result was a link to the very search page I was on.

<comment><USER13> I just started noticing that about two weeks ago. What an monumental pile of failure those docs are.

Why they dumped the only hope they had -- the wiki -- I will never understand.

</comment></comment></comment><comment><USER14> Just want to say I'm really happy you wrote this post.

Unannounced changes to the platform - breaking core things we were working with - under deadline, with a client recently resulted in one of the worst disasters I've ever had to deal with on a project. It devolved into the collapse of a startup, not getting paid for almost half of the work we did, sleepless nights trying to hack impossible workarounds, a shady last-ditch buyout deal and multiple shouting matches with otherwise rational executives over un-realized expectations.

Facebook, get your freakin act together.

</comment><comment><USER15> I couldn't agree more with this article (though I sadly can't say 'no' to Facebook development). I recently did a tiny amount of Facebook integration into a site and it was horrific.

All I wanted to do was add a `Like` button that would broadcast to the clicker's friends timeline. What could be simpler? Just copy and paste their code onto your page and you're done. Right?

The _second sentence_ on their documentation page says "when the user clicks the Like button on your site, a story appears in the user's friends' News Feed with a link back to your website."

But it turns out that's not true. It turns out you have to jump through all kinds of hoops to get that behavior. The documentation for their simplest and most used integration feature couldn't go _one paragraph_ without falsehood.

<comment><USER16> So when you like something, it doesn't actually appear in friends' newsfeeds? Elaborations please.

<comment><USER17> It does - I think the OP is referring to all the open graph data you need to add to your page to have this functionality work properly.

<comment><USER15> Yup, the whole point of putting a `Like` button your page is so that site visitors can broadcast your page to their friends. However, to cause that broadcast to actually occur you have to put a bunch of Open Graph meta tags on your page and also (I think?) have a registered Facebook Application to go along with your site.

There's no place that's documented except for the developer forums.

<comment><USER18> > also (I think?) have a registered Facebook Application to go along with your > site.

Can you please elaborate on this? I thought it was just the meta tags that were needed?

</comment></comment></comment></comment></comment><comment><USER19> I, and several people I know, have been in this situation before. Facebook seems to have very little commitment to backwards-compatibility and comprehensive documentation.

On a more general note, I'd strongly recommend against building your entire business around a single platform.

<comment><USER3> > strongly recommend against building your entire business around a single > platform

I see this statement a lot and I never understand it. If you're Zynga, should you build Farmville for OpenSocial and as an independent site too? The cost of doing this seems prohibitive.

Most businesses built on Facebook can be taken elsewhere if the cost of the Facebook platform starts to outweigh the benefits. Even Farmville can be ran independently, but consider how many users they'd lose in the transition and afterwards.

</comment></comment><comment><USER20> I think they do this on purpose - rapidly changing apis, and having poor or overly verbose documentation is a way to weed out all but the largest development companies, thereby reducing support costs, and allowing partnerships with the big companies that survive. It's right from microsoft's playbook.

<comment><USER21> You think "rapidly changing apis" is "right from microsoft's playbook"? Microsoft has been known to abandon a platform (VB6 being the prime example), but they have also put tremendous effort into preserving compatibility in their APIs. So while they may have introduced new APIs over time, they've also shouldered the massive burden of keeping the old way working for many years. I would even say they realised this was a vital component in maintaining their dominance: the sheer number of applications that work on Windows.

<comment><USER22> If they'd done things the facebook way, they'd never have made it past DOS.

</comment></comment></comment><comment><USER23> He's right on the money. The documentation is horrible. The 1 app I wrote that used the Facebook APIs convinced me never to do so again. Even the simplest things required hours and hours of effort, mostly by trial and error, just to figure out the important details that the documentation left out.

</comment><comment><USER24> The docs are horrible and often contradictory -- but with enough trial and error most things can be figured out.

The unannounced breaking changes are _absolutely inexcusable_ and _screw the people using your platform_. It is not a sustainable development plan, you will eventually alienate 'the next Zynga' and all the smaller developers. Please, please, please put some effort into API stability.

<comment><USER25> _you will eventually alienate 'the next Zynga'_

One can only hope.

</comment></comment><comment><USER26> I'm glad I'm not the only one that feels this way about their documentation. I don't make Facebook apps all the time. I've made a couple. Each time a client has me make one I have to spend hours trying to gather info about whether a requirement is possible because the docs suck.

</comment><comment><USER27> I think the issue Ryan mentioned with FB is a general issue these past several years with more than just FB's API and documentation. Everyone seems to be more sloppy these days. People call their processes agile, throw in a task manager, throw tasks into it willy nilly, and call that process.

Hiring a tech writer and sending your lead dev to scrum school won't help either. You need to value good work at work. If you're too busy worrying about how to skim by with less money or worried about losing your employees, you're too distracted. Work with fewer people, get less done, but make sure you do it right! Why do people need a primer on this? It is just common sense.

</comment><comment><USER28> I'm in 100% agreement with this article. My company has sold more and more Facebook app / custom tab work lately, and it amounts to nothing but headaches.

Most clients simply refuse to understand that so many of the problems encountered are Facebook's fault as a result of bugs in their system or APIs broken from upgrades.

I wouldn't wish this kind of pain on any developer.

</comment><comment><USER29> This also applies to login via Facebook Connect. They change the rules on this sometimes, and don't give much warning beyond a post on their dev blog.

Guess who your users blame when all of a sudden they can't log into your site anymore with their Facebook account?

We user RPX/Janrain to deal with this, but we still get burned sometimes nonetheless.

</comment><comment><USER30> It seems like a cultural issue. We were at an event on Tuesday where they let us know about a host of API changes relating to apps specifically, but when I got back and emailed asking for some documentation (even anything internal), all I got was a "we'll get back to you."

Ironically (or maybe not), part of the presentation was a slide featuring a workgroup with a "Done is better than perfect" poster. Well, yeah, but when you're running a platform service...

<comment><USER2> With docs, correct is better than done.

</comment></comment><comment><USER31> Their API woes lead to problems with other components they offer. Their original iphone sdk component was one of the more polished freely available objective c components out there. Their updated version using that relies on the updated API's is a step backwards in functionality, ease of use and documentation.

</comment><comment><USER32> I wrote a simple plugin to update Facebook and Twitter statuses when I published a new post in WordPress. Simply authenticating to Facebook took about 2 hours of work, following API links that no longer worked and linked to Bing searches, etc. Problem is, I always swear never to write code on Facebook anymore after one of these experiences, but the next month...

</comment><comment><USER13> My favorite game is finding easy-to-fix bugs in the bug tracker that have thousands of votes and have been rotting away with no action for months or years.

I really don't understand how FB can have so much interest in the future of their platform but let the fruits of their labor spoil like this.

Hopefully highly read posts like this will finally bring some attention to the matter. Where are you Zuck?!%

</comment><comment><USER3> This is Bret Taylor's Graph API - the concept simplified the API a lot, and companies like Freebase copied it for their own data. Too bad it is not working...

<comment><USER33> Explain, please?

<comment><USER3> The way Facebook's Graph API is structured can be applied to other datasets containing interconnected objects. It's like a REST service serving JSON, with a specific way to construct the URLs. I like it a lot. Here is a blog post explaining the Freebase implementation:

[http://blog.freebase.com/2010/04/29/a-freebase- implementatio...](http://blog.freebase.com/2010/04/29/a-freebase- implementation-of-the-facebook-graph-api/)

The Facebook docs:

<http://developers.facebook.com/docs/api>

But even the cleanest API is of no use if the API calls don't actually work...

<comment><USER34> Explain "doesn't work".

Also, does FQL work? I'm just starting to look at it for an app.

</comment></comment></comment></comment><comment><USER35> I have to use the Facebook api for work. I have asked that I no longer have anything to do with Facebook development due the the immense stress it causes, seriously, just thinking about it can put me in a bad mood. unfortunately this isnt really an option so im stuck with it _sadface_

</comment><comment><USER36> I found at times that I got more info from the depreciated wiki than any form of new documentation they had up, and my use case was pretty damn simple, just implementing a half decent usage of facebook connect which runs with SSL and plays nice with a modified wordpress user system.

I found myself at times resorting the trawling through js source to find how I could use certain button images that were very simple in the old version.

I feel your frustration and am glad I don't really have to do much in the facebook space at the moment.

</comment><comment><USER34> In a sadly ironic fashion, a lousy API, that makes you invest months on kludging your code, can tie a company or developer _to_ a platform.

This was a factor with Microsoft's domination.

How much do you think this is a factor with Facebook.

</comment><comment><USER37> I like how Twitter has versioned their API, and I wish Facebook would do something similar. With 500+ developers and deep knowledge of backend changes, they should be able to handle the minor discrepancies instead of off loading that burden to platform developers.

<comment><USER36> The Twitter API is excellent in comparison, I guess in a way the newer Facebook API drew a lot of inspiration from it. Problem is it was rushed out and judging by the article and comments left here not much has happened documentation wise in the last 3 months or more since I last touched it.

<comment><USER38> What actions can you do in twitter? 1\. Post a tweet That's everything.

<comment><USER39> You can do everything through the API that you can on twitter.com. In fact the new twitter.com site uses the API! One more thing, their API does what it says in the docs... when twitter is up ;-)

</comment></comment></comment></comment><comment><USER40> I'm actually quite surprised that HN-ers are complaining about Facebook API, documentation, and quality assurance process. Isn't Facebook the kind of companies where most HN-ers fall in love with?

1) Young founder with visions

2) Hacking culture (to the max)

3) Cool technology (Erlang, C++, Java, Hadoop, HBase)

Every time I saw a Facebook engineer giving a talk or writing a blog, the word "quality" (unit test, test, automation, manual, or whatever) and "documentation" are nowhere to be found.

It's not in the company's blood/gene when it comes to QA process. Maybe that's the reason why they're hiring super smart and super young individuals? to pull all-nighters fixing bugs and pray during the release day?

It'll be super hard to get better in QA because it's probably too late for them: too many hot-shot developers who aren't used to testing (automated or manual). They'll probably hire tons QA and automation engineers, but at the end of the day, their developers will "fix" bugs and throw it over the wall.

Some people might not like the way Google works (too much bureaucracy in terms of code quality), but they work really hard to make sure their engineers are responsible toward the code they produce. It's hard to have that kind of mentality embedded onto your engineers.

</comment><comment><USER41> Don't forget the awesome recent and upcoming changes: [http://dipinsi.de/post/1166448458/things-they-wont-tell- you-...](http://dipinsi.de/post/1166448458/things-they-wont-tell-you-new- facebook-policies)

</comment><comment><USER42> I love this thread. The last six month of frustration finally have a place to express itself.

I found Facebook's documentation to be awful, and their online tools not very clear \ friendly. What I did find immensely useful is the community's support and knowledge. SO is filled with excellent questions and "How To"s. Also Facebook's developer forum is quite good. In other words, my fellow developers... keep on the good work, help build a strong community, Facebook sure isn't.

</comment><comment><USER22> Whenever I encounter a site that gives me many ways to login, I click the Facebook icon just for the heck of it.

And when it fails, one can only conclude: situation normal

</comment><comment><USER43> this is the thing about monopoly - the only recourse one has against it is to whine.

</comment><comment><USER44> Really sorry about you giving up an income stream - I hope you've found other, better, more rewarding projects to work on.

So, can I have your clients, then? =)

</comment><comment><USER45> I really didn't understand why they deprecated the wiki. It makes as little sense as the way programmers misuse the word deprecate.

</comment><comment><USER46> Perhaps a splinter of StackExchange for the Facebook APIs could be arranged?

a la <http://www.joelonsoftware.com/items/2010/08/31.html>

</comment><comment><USER47> A few months ago we developed our first Facebook application for a client. It was such an awful experience that I suspect it may be our last.

</comment><comment><USER48> Yeah, it's bad enough developing your own applications on someone else's unstable API - I'd definitely hate to do it as client work.

</comment><comment><USER49> So here's the obvious way for someone to beat Facebook.

</comment><comment><USER50> For Rails: Devise 1.1.2 + MiniFB (both on Rails3) works very well.

</comment><comment><USER51> Facebook documentation SUCKS!

<comment><USER52> that's pretty much the tldr of the post. I've no idea why it's on the frontpage. I thought it was going to be some philosophical objection to the walled-garden approach, or some experience with facebook being anti-open web, or the way fb apps teach users bad habits or at least _something_ of substance. but really it was just a rambling rant.

<comment><AUTHOR> All of those would be interesting posts, but I don't really have a problem with them. I do have a problem with the way Facebook treats their developers, so that's what I wrote about. I'm sure the post could have been better, and I'd enjoy any specific suggestions you might have. Thanks!</comment></comment></comment>


Ask HN: License to use for an interview project? - <AUTHOR> I'm in an unusual situation. I'm working on a demo application for a company I'm interviewing with. This has never been an issue before, but in this particular case the scope of the application is closing in on something I would normally build as an mvp or v1 for an internal tool.
Its somewhat surprising to me because the company is rather large and well known, so this isn't a case of the interview app being a way to get free work done.
However, I think I will be more comfortable by including a non-commercial use license with the project. What are some simple licenses I could use? Most searches I've done all return variations of open source ones. <comment><USER2> It sounds like you're not being paid for your time/effort. If this is the case, why not tell them that you own the copyright on your work? If you insist on a non-commercial license, how about CC 3.0?

[https://creativecommons.org/licenses/by- nc/3.0/us/](https://creativecommons.org/licenses/by-nc/3.0/us/)

</comment><comment><USER3> "All Rights Reserved"?

</comment><comment><USER4> Are you saying you want to prevent the company you are interviewing with from using it?

<comment><AUTHOR> Right. Its nearly at the scale of being something I would finish in a 40 hour work week as an mvp internal tool. Way out of the normal scale of a demo app for an interview.

I just ended the interview process today in part because of this.

</comment></comment><comment><USER5> Better to not do this project unless they're paying you.

<comment><AUTHOR> Yeah, I just ended the interview process about an hour ago. I thanked them for their time and included some thoughts about the scope of the demo project.</comment></comment>


Ask HN: What happens to Failed Startup furniture? - <AUTHOR>

Every startup seems to have really nice monitors and chairs, but of course some startups fail and shut down at some point. What happens to said equipment when they close up shop? Is this liquidation process different for say a 50 person startup vs a 10 person startup? <comment><USER2> The office next to my place of work (we share a floor) recently went under. They had really nice furniture, most of it was just left when they closed.

In this case I think it changed hands to the building owner. They failed to pay the rent so I think pretty much everything inside changed hands as there was a bailiffs notice on the door.

It looks like the new company which is in there is actually re-using their old tables and chairs.

</comment><comment><USER3> When I was younger, I used to work for a commercial furniture company. Most of our work was to go into closed down companies and dismantle their furniture. Take it back to the warehouse, refurb it and then resell it. Typically used cubes would cost $1-$5 cube (plus labor costs to retrieve and refurb) but then re-sold for several hundred and sometimes thousands per cube.

<comment><AUTHOR> That's very interesting.

Those are are walls of a cubicle right? Anecdotally cubes seem to be falling out of style. Did you get a chance to see the negotiation process for either buying or selling the cubes?

Seems like negotiations would be pretty one-sided in both cases. For sellers, they are so busted up from having a failed business, getting a good price and terms are not at the top of mind. For buyers, they need office equipment pronto to get their people productive in a way that price is a secondary factor.

<comment><USER4> I doubt that all buyers are in a position where they "need office equipment pronto." I'm sure many are, but building out a new office can take months, leaving plenty of time for negotiation with multiple sellers. Some purchasers likely need equipment immediately and others are likely planning several months ahead of time to predict future needs.

</comment></comment></comment><comment><USER5> This sounds like its own startup idea waiting to happen.</comment>


Where Smalltalk Went Wrong (2004) - <AUTHOR> http://www.ianbicking.org/where-smalltalk-went-wrong.html <comment><USER2> "In fact, I'd say the image is perhaps the biggest problem with Smalltalk."

There need not be a single image. You can save and load as many images as you like. In fact, you can have thousands or hundreds of thousands of images if you prefer. You may think I'm being uncharitable to the author by construing his words as I did, but it's entirely appropriate given the tendency of those ignorant of Smalltalk (like him) to speak and act as if there is some monolithic, fragile image that everyone on a project shares and each must strive to avoid breaking.

The Smalltalk image may seem unfamiliar or even scary at first, but it's really little different from a standard Ruby or Python process, except that it is serializable and contains all of the code (both compiled and in source form), data, and execution state as objects that you can manipulate.

Further, every Smalltalk (that I know of) supports saving and loading source code to text files and often some form of package management and source control as well. Many Smalltalk also integrate with file-based tools quite well. For example, you can use git with Pharo, and many Pharo developers use Github exclusively for their development.

People citing the image as a reason for not using Smalltalk clearly don't know Smalltalk. They're also likely hypocrites, because at some point or another they've no doubt asked themselves why, after so many years, are programmers still programming by the mere editing of dumb text files? Well, in part because of your hostility to any system that isn't the mere editing of dumb text files.

<comment><USER3> > why, after so many years, are programmers still programming by the mere > editing of dumb text files?

Well, there's nothing wrong with text per se. Text is easy, it's simple, it's persistent and platform-agnostic. Text based source code is portable, because it's human readable. You could print it on paper or write it on a napkin if you wanted. Alternatives have the potential of locking programming, and programming knowledge, into some company's particular black box.

<comment><USER4> > Text is easy, it's simple, it's persistent and platform-agnostic.

You never moved away from cozy 7 bit ASCII in one single human language, I imagine.

<comment><USER3> You would be correct, in that I have never seen source code written in Unicode in multiple languages.

However, i'm trying to make an argument that text is fundamentally more free than the alternatives. When I say "simple, persistent, and platform-agnostic" I mean, literally, you don't even need a computer to deal with it, much less an IDE. Source code is a means of communication between people, as well as between people and a machine. Imagine how restricted the development of the early web would have been if you _couldn 't_ just bang together some html and javascript and put it on a server?

<comment><USER4> I don't need to imagine it.

Just went through the wonderful world of codepages, codemaps, ASCII 7 and 8 bit, EBCDIC and many other formats.

Text formats on mainframes, mini-computers, home micros and many other hardware and OSes.

Text, easy?!? No it ain't.

</comment></comment></comment></comment></comment><comment><USER5> Smalltalk is (literally) a window on an alternative computer architecture and OS/language paradigm. There's a reason it runs on a 'virtual machine'! It's the path that computing _could_ once have taken, the equivalent of a parallel universe: What if computers had gone with _this_ different design; what if the language and underlying operating system were one-and-the-same... (There was even a initial attempt at object-oriented hardware: [http://en.wikipedia.org/wiki/Rekursiv](http://en.wikipedia.org/wiki/Rekursiv))

Of course, Lisp is the other example of an alternative computing ecosystem: the famous Lisp Machines, with Lispy turtles all the way down; and Interlisp, that came closest to Smalltalk's emulation of a physical machine.

Modern Smalltalk is the environment that would have emerged from this kind of platform. That it includes modern tooling and inter-operability (however limited) is a huge bonus - it represents a genuine effort to coexist with the mainstream.

That there's so much criticism of its 'image' and language syntax only drives home the absolute grip on our thinking that Algol languages and Von Neumann architectures have imposed. In my mind, that makes it an environment of inestimable value.

Ecological diversity is more than good; it's _essential_.

<comment><USER4> There was a third window that many people tend to forget.

Mesa/Cedar, a interactive environment first done in Mesa, the Modula-2 predecessor and later on improved as Cedar, which was a system programing language with GC!

It was a working environment similar to Interlisp-D and Smalltalk, but using dynamic libraries, an interactive debugger, REPL and lots of nice goodies for an Algol like language. Back when at AT&T green phosphor terminals were being used.

Mesa was the inspiration for Lilith operating system done in Modula-2.

Similarly Cedar was the inspiration for Oberon and its derivatives.

Using Oberon felt to certain extent like Smalltalk, in a strong typed system programming language with a GC.

But Oberon based systems had the bad luck to appear at the same time the world was paying attention to Java and rise of VMs. So just like Plan9, only a few of us enjoyed using such environments.

</comment></comment><comment> vezzy-fnord _It 's not just that the syntax looks weird to people -- though that doesn't help -- but it also looks weird to other programming languages._

Not sure if it's any consolation, but Smalltalk was the first non-ALGOL language that I really "got", and remarkably quickly. The saying that Smalltalk syntax fits on a postcard is no joke, see: [http://c2.com/cgi/wiki?SmalltalkSyntaxInaPostcard](http://c2.com/cgi/wiki?SmalltalkSyntaxInaPostcard)

The hardest part is wrestling with the class libraries and getting used to the hermit kingdom that is the image-based environment, though the community behind Pharo and other modern Smalltalk environments have done some interesting advances when it comes to bridging the gap, such as the Monticello VCS for snapshotting code state to a regular file system in the form of an archive.

That said, I haven't used Smalltalk all too extensively.

<comment><USER6> I don't find Smalltalk's syntax bad per se, but I think there's too much of it. When I see it, my eyes glaze over. Not because I don't understand the concepts behind what is being represented, but because I have a hard time getting a handle on the shape of things.

It's a matter of familiarity, and while I've spent some time looking at the object model I haven't written a lot of code in it. So perhaps that complaint is only really valid for newcomers. On the other hand, I still think it's a bit convoluted since a language like Io can express much the same stuff with less. The postcard version is something like:

        Object setSlot("foo", 12);

That demonstrates the entire informal BNF description at [http://iolanguage.org/scm/io/docs/IoGuide.html#Syntax- Expres...](http://iolanguage.org/scm/io/docs/IoGuide.html#Syntax-Expressions)

That doesn't account for [] and {} being translated to messages (with their contents as arguments) or for the infix operator stuff (sends the operator message—eg. +, xyzzy, etc.—to LHS with RHS as the argument) which also has precedence. Aside from that there's nothing much going on. Everything except infix operators always look like like regular message sends unless you're using a DSL. I think that's shat Smalltalk ought to look like, since that's what it's trying to be about.

Edit: Before anyone gets the wrong idea, I don't mean Smalltalk should look like Io, but that it should have little more shape than looking like message sends.

<comment><USER7> and Smalltalk would be:

      Object setSlot:"foo" to:12.

I have always liked Smalltalk's (via Objective-C) message syntax as it put the meaning of the function call slots where I am calling them. I hate what they've done in Swift however.

I have toyed with a scripting language that had:

      Object.[setSlot:"foo" to:12]

Still not sure on that. I immensely respect the creator of Io but it didn't click with me (my fault, not the language).

<comment><USER6> I think you misunderstand. The Smalltalk is this:

        exampleWithNumber: x
        "[ *wall-of-text elided* ]"
        | y |
        true & false not & (nil isNil) ifFalse: [self halt].
        y := self size + super size.
        #($a #a "a" 1 1.0)
            do: [ :each |
                Transcript show: (each class name);
                           show: ' '].
        ^x < y

I'm talking about an Io equivalent of the "Syntax In a Postcard" link provided above, partly reproduced here for convenience. What the code does isn't so important as how much of the syntax it covers.

<comment><USER7> Oh, sorry, yes, I got your meaning totally wrong.

</comment></comment></comment></comment></comment><comment><USER7> It was my understanding that GNU Smalltalk [http://smalltalk.gnu.org](http://smalltalk.gnu.org) is text file and not image based.

<comment><USER4> Using GNU Smalltalk doesn't do any justice to what means to use a Smalltalk environment.

<comment><USER7> True, too true, but it does ease people into the language and proves the language is not defined by the implementation. This is important since most of the discussion in this thread is based on the common implementation and not the language.

<comment><USER4> Usually I am the first to push for comments "Language != Implementation", however the whole Smalltalk experience only makes sense in the official implementation of the IDE married with the language and OS.

Using an implementation like GNU Smalltalk, while valid in terms of language implementation, leaves out the whole development experience back to the stone age of UNIX tools.

Exactly the development experience of environments inspired by Smalltalk is what made me always favor IDEs over vim, emacs + CLI.

<comment><USER7> and usually I will defend the different environments, but I have to disagree with you here. Smalltalk environments try to build their own everything. Squeak and Visual Works do not use native widgets, heck Squeak is a horrible UI. Both have editors that are inferior to current text editors. They have cool attributes, but there rejection of every part of the OS is problematic.

</comment></comment></comment></comment></comment><comment><USER8> I think the situation is way simpler than the author contends.

Smalltalk simply has poor workflow from the programmers perspective, compared to what he's used to.

It may be awesome. But no one will ever know, because it's too different from the normal developer's work flow to easily gain adoption, even if the benefits are substantial.

Could something like Smalltalk work in such a way that the "image" is a series of files and folders, so if something goes nuts we can do what we always do and poke around in the data?

Could automatic code reloading and online introspection be applied through a more traditional client (debugger) - server (running process) setup?

Something like that may have a better chance. This machine ain't got time to slow down and make repairs.

<comment><USER9> > Could something like Smalltalk work in such a way that the "image" is a > series of files and folders, so if something goes nuts we can do what we > always do and poke around in the data?

Well, speaking for Squeak: The image is just a file. You can open it and poke around in it.

I don't recall why I had to do it exactly (did some meta-programming with Smalltalk at university... maybe my program overwrote some fundamental functions in Object or similar), but I don't remember it to be terribly complicated.

Definitely not as simple as opening a JSON file, but not as hard as decrypting the assembly of a compiled C-program or analyzing the memory of a crashed program.

<comment><USER10> > maybe my program overwrote some fundamental functions in Object or similar

This is why I don't use smalltalk.

<comment><USER11> Do you use JavaScript?

<comment><USER10> Unfortunately.

</comment></comment></comment></comment></comment><comment><USER12> People loves spanking Smalltalk :)

I think that's good because it shows (a) is really different so is a direct hit to the Comfort Zone on many and (b) its significative value is real, otherwise it wouldn't annoy them to the point of talking about it.

It seems that a source of anger for some people is that Smalltalk is good enough to get mainstream but it didn't reached really mainstream. Probably due to the strategic mistake of not making it open source right from the start in the 80's. This interview puts some light into what happened, who influenced that decision and why was made: [https://www.youtube.com/watch?v=IGNiH85PLVg](https://www.youtube.com/watch?v=IGNiH85PLVg)

If Smalltalk would have been open sourced in 1980 the world would be different: programming would be more humane and less technologically-self- serving.

Now we have the "pleasure" of listening people that tells you "the compiler is your friend"

No it's not. Smalltalk rewards the creative spirit. Compilers hits it with a hammer. That's why it's so different (Ref: [http://www.cs.virginia.edu/~cs655/readings/smalltalk.html](http://www.cs.virginia.edu/~cs655/readings/smalltalk.html))

1984 here we go. (Ref: [https://vimeo.com/115154289](https://vimeo.com/115154289))

<comment><USER13> This is exactly right. People are so invested in what they've learned that they are reluctant to give it up and try something new and different. Humans are creatures of habit.

For some reason, this has never afflicted me. I've used many languages and environments in my time (eg, FORTRAN, Tandem TAL, C/C++/C#/Objective-C, Java, Python, Go, and Smalltalk), and I've treated each and every one of them as a fun opportunity to play and learn. This is my intellectual playground and those languages are my toys! Smalltalk was completely different from everything else I had used over 20+ years, and it still didn't phase me. Go figure.

Today, I continue to have a warm place in my heart for Smalltalk.

</comment></comment><comment><USER13> I find this resistance to the Smalltalk environment a bit puzzling. It's really fundamentally no different from modern IDEs and virtual machine runtimes such as JVM. The key differentiator is the fact that every object in the Smalltalk environment is "live" and can be examined and altered at will. One of the great benefits from this fallout is the powerful debugger.

Rather than whining about how Smalltalk doesn't play well with existing file- based tooling, we should focus on improving and extending the tooling for the Smalltalk environment. We have an opportunity here to define the __future __. Smalltalk is a break from the traditional way of doing things (the use of files and folders is positively antediluvian!). It 's truly innovative.

The transition may incur some cost and pain now, but positive change is never free. If you argue we should wait for a more opportune time, the question is, "If not now, then when?" What exactly are we waiting for?

If you argue we should never change, files and folders are perfect forever and ever, then I say we are stuck in a rut. Software engineering is off the rails.

<comment><USER13> Also, people bitch about not being able to use their favourite editors. I've never understood this, either. In my 20+ years in IT, I've never been wedded to any particular editor. And the way source is organized and presented in the Smalltalk environment (via the class browser), I've never needed the power of emacs or Eclipse or Sublime Text. Super-editors are for file-based software development. In Smalltalk, they're rather unnecessary.

</comment></comment><comment><USER14> I think there is really something that makes people prefer files over some database, even though the latter has undeniable advantages.

Do you remember IBM's VisualAge for C++? It had a clear Smalltalk pedigree (there was a VisualAge for Smalltalk first, and I think the IDE was written in ST, but I could misremember that point).

And a "translation unit" was not a file, like in every other C++ compiler. All translation units were entries in an internal database. And you couldn't find the header files with a file manager search.

Some people liked it. A lot. But in the end IBM reverted to the common approach.

<comment><USER4> Eclipse was Visual Age for Smalltalk reborn.

I miss Visual Age for C++.

Personally I think the biggest problem was the hardware requirements. If memory doesn't fail me, it already required 8 MB when most PCs were still being shipped with 4 MB.

Also I think the version to go for was the OS/2 one, which didn't help as well.

Vague memories now, so I don't recall how it really was.

<comment><USER15> You are correct:

VAST was in Smalltalk. VAC++ was ALSO in Smalltalk. And the first VAJAVA? Also Smalltalk. They ultimately rewrote it in Java and it became Eclipse.

It required 8MB to be useful but 16MB (or more, which was unheard of) was preferable.

</comment></comment></comment><comment><USER16> I'm not sure the image paradigm would be much of a problem today.

Virtualization is common today, Docker is very trendy, and many such tools rely on the concept of images. Smalltalk images are similar to VM snapshots, and not very different to Docker images.

I think the Image was one of Smalltalk's best ideas.

I used Parkplace, VisualAge and Cincom professionally, and I think the real problem has always been the cost: Smalltalk tools were expensive, Java tools were free.

</comment><comment><USER17> * Being image based has traditionally been a problem for many, except now that VMWare and Xen allow you to pause your running Image, move it somewhere else and restart it running from the snapshot point, you now have for an operating system what Smalltalk has always had at an application level.

* One traditional problem with a Smalltalk Image is that it can be hard to reproduce - to get from scratch to where it has evolved to. Pharo is working hard to make a reproducible bootstrap that builds up from scratch using CI infrastructure.

* Squeak and Pharo are strong and responsive open source communities. In [pharo-dev] maillist you often see people report a problem and its fixed the next day.

* Traditional interpretive performance issues are mitigated by Cog's JIT compiler.

A good discussion on where Smalltalk went wrong - more commercial than technical - can be found here... [http://c2.com/cgi/wiki?WhyIsSmalltalkDead](http://c2.com/cgi/wiki?WhyIsSmalltalkDead)

</comment><comment><USER18> Q: Where did Smalltalk go wrong? A: Excessive cost of development tools at a time when Java was free.

Java was easy for C, C++ and Pacal programmers to migrate to. It had enough incremental benefits to justify the leap. Most importantly, Java surfaced with inbuild support for the Internet, just when the Internet rally was building.

If Smalltalk development tools had been less costly, it would have surpassed Java on every front. And, Smalltalk is such a joy to use.

Smalltalk is a success on the technical front. Current software technologies are still duplicating the innovations originated in Smalltalk. Docker is the latest, saving the state of a software solution.

Developer productivity is where Smalltalk really shines. There are many ways to measure productivity and code quality. Ultimately, total effort per function point is a useful one. On page 46 of [http://namcookanalytics.com/wp- content/uploads/2013/07/Funct...](http://namcookanalytics.com/wp- content/uploads/2013/07/Function-Points-as-a-Universal-Software- Metric2013.pdf) a table sets out number of months to implement a 1,000 function point program. Here's a few metrics for dynamic and static languagues:

Smalltalk 21 coding months Ruby 46 C# 51 Python 53 C++ 53 Java 53 PHP 53 JavaScript 71 C 128 Assembly 213

By these measures, Smalltalk projects will be completed in less than half the time as projects using C#, Java or C++. Javascript centric projects will take 3x, but this is not really an apples to apples comparison.

Where Smalltalk really failed, was on the commercial side. It failed to be adopted by a critical mass of developers. Smalltalk was used successfully, due to tool costs, mostly in Fortune 1000 class enterprises. For my small software company, it was a secret weapon enabling me to outperform competitors. I didn't sell Smalltalk, I sold "solutions."

</comment><comment><USER19> What hurt Smalltalk was very expensive software licenses.

I think that if something like the free Pharo system had been available 20 years ago then history would be different.

A Smalltalk license for my old Lisp Machine would have cost, if I remember correctly, about $5K

<comment><USER20> Like $150 ($50 educational) for Smalltalk 80 on the Mac around 1985, directly from Apple?

Which Apple open sourced as Squeak in 1996. Which then was forked into Pharo?

</comment></comment><comment><USER21> Here's my thoughts about the demise of Smalltalk, if you will. There are of course many reasons, and as said by others it's still alive and well with Pharo.

The first reason may be just that it was too good, too ahead of its time. A huge programmer population already existed for C and C++ at the time Java with its C-like syntax came around. In programming languages "incrementalism" rules, which is easy to understand when considering how big an effort it takes to become an expert in one.

I think Smalltalk was also a victim of its own success. It promised a huge increase in productivity and software quality. This caused a business-war among its few suppliers at the time (Parc Place, Digitalk) and wars are never good.

And there's a technical reason for that too. Smalltalk is not just a language, it is an environment with a big library built into it. Even though the class- hierachy was mostly given by the original Smalltalk-80 there were small differences between the vendor-provided libraries which made it hard to run a Smalltalk application written for one Smalltalk virtual machine on another one. Which made it more important for every Smalltalk vendor to try to tightly own their users.

Here again ST was a victim of its own "goodness". The class-hierarchy is a tightly-knit set of classes which allows for maximum of code-reuse, but also means that it was not easy to combine classes from different platforms. If you took one class from vendor X it meant that many other classes had to follow and those could override similarly named classes in the target environment, which again would break many other things in the target platform and so on.

In other words Smalltalk was not modular enough, it was not easy to combine classes written on different platforms with each other. Smalltalk is not only an "island of its own", every Smalltalk is more or less an island of its own. Then again there's still only talk about bringing modularity to Java. But Java has the benefit of non-diverged platform. THAT also almost happened, with "Microsoft Java".

The ability to easily reuse large portions of the Smalltalk platforms is a huge benefit for productivity, at the same time it hinders co-operation between programmers working on different Smalltalk platforms.

</comment><comment><USER22> A follow up post is [http://www.ianbicking.org/where-smalltalk-went- wrong-2.html](http://www.ianbicking.org/where-smalltalk-went-wrong-2.html) (via [https://news.ycombinator.com/item?id=8797560](https://news.ycombinator.com/item?id=8797560)).

</comment><comment><USER9> Back in university, I did an introductory course in Smalltalk/Squeak as well as three seminars that used Smalltalk, two of which were group projects. (One chair was heavily invested into Smalltalk)

I won't use Smalltalk/Squeak professionally, and I've come to enjoy functional programming much more than OO programming (at least for non-UI tasks, which I generally enjoy more). That said, I do not regret learning and investing time into Smalltalk [1].

I'm dismissing the syntax-argument, as Obj-C has brought a Smalltalk-like syntax into the mainstream [2].

The one thing that I REALLY miss about Smalltalk sometimes is the ease of working with (stored) objects. You basically don't have to do anything. So much CRUD - just removed. I don't know how much time I wasted debugging or optimizing Hibernate-stuff in Java, or wrestling with CoreData in iOS.

With Smalltalks image, you just don't have to waste ANY braincycles on storing your data [3]. If you've created the object in memory, consider it stored. If you remove the last reference to it, consider it deleted. It's just so much more natural (for an OO program) than working with an ORM.

However, the image in Squeak was, in fact, the most difficult thing to get used to. The image contains not only your runtime, it is also your IDE. As an IDE, it had some good parts (similar to a browser where you can inspect any HTML-element, you can inspect any (visual) object with a right click), and after a while I was kinda OK with navigating the (not file-based) code. That said, it does neither rival a full-blown IDE nor Vim - the IDE always kept disturbing my flow somehow. And, with limiting your methods to a maximum of 7 lines of code, you're bound to use the IDE a lot.

> It's also hard to isolate a "program" in Smalltalk -- it's all one big heap > of code, you may have added methods to Object, who knows what.

This hasn't been my experience at all. If you use some sort of versioning (we used SVN), you'll have to separate your code from your workspace. I don't remeber it to be any harder than it is in a traditional environment (do a diff before you check-in to make sure you've cleaned up everything and if your code/unit tests use any non-code files, make sure to check them in as well).

[1] In fact, I'd recommend anyone who is serious about becoming a good programmer to learn several (>3) distinctly different programming languages (i.e. Java and C# are too similar to count). And Smalltalk is really different, not only syntax-wise but conceptually a lot of stuff will broaden one's horizon.

[2] Thankfully, it's being replaced by Swift now. I've worked with it in the last 3 weeks, but I'm more happy to see the C-stuff go and functional programming concepts arrive than the Smalltalk-stuff removed.

[3] Well, for a certain scale at least... not feasible for Big Data, but sufficient for your average mobile or desktop app.

</comment><comment><USER17> This is a very good discussion of what went wrong with Smalltalk was more commercial than technical. [http://c2.com/cgi/wiki?WhyIsSmalltalkDead](http://c2.com/cgi/wiki?WhyIsSmalltalkDead)

</comment><comment><USER23> There should likely be a [2004] in the title. Plus, it says "half-baked" and points to an updated version, also from 10 years ago.

<comment><USER24> I found this one to be more interesting: [https://news.ycombinator.com/item?id=6601748](https://news.ycombinator.com/item?id=6601748)

</comment></comment><comment><USER25> Serious question, I'm interested in Smalltalk, is it a viable option in 2014? Does anyone use it professionally? Personally? Open source projects?

<comment><USER26> This, and also I am specifically interested in if you can do modern web development in it, and if playing with smalltalk will result in similar epiphanies that learning multiple functional languages did.

<comment><USER27> It's hard to embed in your regular flow because of the image based nature. If regular files systems and git(hub) are your thing be prepared for some drastic adjustments.

Also, it is quite slow. But it is definitely worth a look just for the added insights into what programming could be like.

<comment><USER2> "If regular files systems and git(hub) are your thing be prepared for some drastic adjustments."

Not so with Pharo. And "slow" relative to what? Surely not compared with Ruby or Python, two of HN's darling languages.</comment></comment></comment></comment>