What does "HREF" stand for? (2008) - <AUTHOR> http://tomayko.com/writings/wtf-is-an-href-anyway <comment><USER2> So, I go to Google Groups to try to find the first mention of HREF on Usenet.

I have no idea how to do this. It takes four clicks just to get to the Google Groups page.

I see a search box. I look for something to give me the advanced search page. I can't find it. (I can see 2 buttons for settings.) So, I type HREF into the search bar and click seach. The drop down offers "in any group" or "groups named". First attempt I ignore both of those and just click the button.

Posts: 28200040, groups: 58

I need to narrow this down. I need the advanced search pane. It's still not there.

I arrange by date. LOL NO, that hasn't worked for literally years.

The advance options turn up if I'm in a group. They allow me to narrow the search down, but not to change the group I'm searching in.

I will donate $5 to the charity of your choice to the first person who tells me how the fuck I can perform the following search:

[HREF]

any Usenet group (or the news hierarchy)

Before 1998

Sorted by date

Bonus $5 if the instructions you give are in any Google documentation online.

<comment><USER3> site:groups.google.com "href" daterange:2453006-2450815

Edit: sorry I bungled the conversion to the Julian format but you get the idea. You could also click around the 'search tools' sub-menu to do that.

Edit 2: It won't let you sort by date but you can just limit it to before 1994 :)

It only finds one message from 1993 (Dec 6), on comp.os.linux.development: [https://groups.google.com/d/msg/comp.os.linux.development/Pk...](https://groups.google.com/d/msg/comp.os.linux.development/Pk3iKRsE5F0/RsBxmvSex7sJ)

<comment><USER2> [http://imgur.com/a/FZYmz](http://imgur.com/a/FZYmz)

Who knows.

<comment><USER4> The query is meant to be entered into Google web search.

<comment><USER2> Wait. What. Really?

Oh my goodness.

Okay, so that sort of works. It's a bit of a kludge though.

<comment><USER5> It's not a kludge. It's a way to search websites that happen to have awful search (like Google Groups).

In most cases that works very well and it's universally applicable. It's a consistent search interface for (pretty much) any website there is. You can just throw Google at it and it works as good if not better than the websites' own search (depending on how good that is), but it's also a consistent interface you do not have to discover and re-learn for every website individually. Sometimes int

Kludge to me implies that it's complicated to set up (it's not; just "site:" in front of the website plus your search terms) or that is either not universally useable or at least requires a lot of manual adjustment every time you want to use it elsewhere (it's not; universal and consistent search that works the same every time).

Sometimes a website's own tools can be somewhat more comprehensive, sometimes they are so bad that switching over to Google is a necessity to find anything at all.

<comment><USER2> You're right. But in the context of the largest and best search engine in the world it's a bit kludgey to not be able to use their supplied search tools for one of their own products, because they broke it so much, and to have to rely upon a different product.

> consistent search that works the same every time

\+ vs "" ?

> sometimes they are so bad that switching over to Google is a necessity to > find anything at all.

Yes, Google search is a useful tool for websites that have hopeless search. I've used it for Wikipedia and other websites. It's baffling that Google's own product has search so broken that using a different Google product to search it is considered not-kludgey.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> "Hypertext reference," I said to myself as I clicked the link. What do I win?

<comment><USER7> a downvote apparently :)

<comment><USER6> It's nice to be noticed. :)

</comment></comment></comment><comment><USER8> I'm surprised to see that this submission is from 2008; while I identify with the author's struggle (and subsequent delight) as he plays the part of an Internet archaeologist, I thought this was a common piece of knowledge five years ago, let alone today. Goes to show how incorrect assumptions about what we do (and do not) know can be.

Burners-Lee's talks are wonderful. My favorite is his talk "Hypertext and Our Collective Destiny": [http://www.w3.org/Talks/9510_Bush/Talk.html](http://www.w3.org/Talks/9510_Bush/Talk.html)

<comment><USER9> Yeah, I just assume that today's 23-year-olds (or 13-year-olds) should all know this, and had the same experience as me, using notepad.exe to alter/test some html, which was grabbed from a "CD-ROM", that came with a "magazine", with something like "Netscape 1.0" (for Win 3.1) on it, in late 1994! What's The Frequency, Kenneth?

<comment><USER10> Haha, I still edit some of my HTML in TextEdit or some simple txt editor... It just opens so much quicker than Dreamweaver...

<comment><USER11> I taught myself beginning HTML/XHTML/PHP using Vieka Wordpad on a Samsung SGH-i607. 3G was my only connection to the net at the time.

I never did use an IDE until lately, but Geany isn't much of an IDE compared to some other choices.

</comment></comment></comment></comment><comment><USER12> Let's see - the HREF attribute that implements the basic principle of hypertext referencing in the Hypertext Markup Language which TBL invented as a file format to serve over his Hypertext Transfer Protocol... what could it possibly mean? I can see the confusion.

<comment><USER13> The answer might sound logical to you but all this time I thought the expansion was Hyperlink REFerence. My HTML education started in 1998 or 1999 from reading a PC Magazine series of articles on how to program in HTML. I don't remember how I got the wrong info and frankly didn't bother to care about this difference but I clicked this article with a smug face and reached the bottom feeling childishly embarrassed.

</comment></comment><comment><USER14> I just wonder how many people think that web is so wonderful invention. But they completely forget Gopher. There isn't so much difference between web and gopher after all. It's just a bit different linking method. After all, it's rare that invetions are relly great, most of those are just small gradual change over time. Still remember how much hype there was about hypertext back in old days. See: [https://en.wikipedia.org/wiki/Gopher_%28protocol%29](https://en.wikipedia.org/wiki/Gopher_%28protocol%29)

</comment><comment><USER15> In the software world we often seem to end up with abbreviations which are ubiquitous but no longer strongly linked to their unabbreviated form. I often find this annoying and distracting. I try an avoid being the source of such annoyance for others. For example if I find myself using abbreviations in my source code, maybe as a prefix for example, I will always ensure the abbreviation is explained at least once in a place that won't be lost (in a header file for example).

An example from back in the day was the acronym (presumably) "Afx". Vast numbers of identifiers in the old MFC (Microsoft Foundation Classes) Windows API C++ wrapper used this prefix. For some reason not knowing what it meant caused me chronic stress.

<comment><USER16> "One interesting quirk of MFC is the use of "Afx" as the prefix for many functions, macros and the standard precompiled header name "stdafx.h". During early development what became MFC was called "Application Framework Extensions" and abbreviated "Afx". The name Microsoft Foundation Classes (MFC) was adopted too late in the release cycle to change these references" [http://en.wikipedia.org/wiki/Microsoft_Foundation_Class_Libr...](http://en.wikipedia.org/wiki/Microsoft_Foundation_Class_Library)

<comment><USER15> Thanks. Actually this explanation reminds me that part of the frustration came from the feeling that Mfc would have been a much more logical prefix and wondering why oh why they hadn't used that instead.

</comment></comment></comment><comment><USER17> I like this kind of article because what seems obvious isn't always correct. It could have just as easily meant... anything... and seeing the process and resources different people use to dig into things is always pretty neat.

<comment><USER18> In real life language etymology, people joke (with some degree of seriousness) that if there is an explanation for a particular term or phrase, that is logical, reasonable, and has some historical corroboration, it is almost certainly wrong.

The evolution of language is a strange and unexpected process. I think this clearly applies to programming languages too. Surely more so for some languages than for others... but this seems to definitely be the case for web languages, since the ecosystem they evolve in is so chaotic.

<comment><USER17> It's funny. I half jokingly apply that maxim to a lot business decisions I see.

Someone will say "oh it makes sense that apartment a does this, because x y z" and I respond with "they may be doing something right, but theyre almost certainly not doing it hat way _because_ it's right"

But yeah. It pays not assume the obvious answer is the right one

</comment></comment></comment><comment><USER19> I'm surprised they didn't fix this sillyness in HTML5 when they were making up semantically-sensible tags for everything else.

A tag with

        <link to="http://somepage" in="new window">

or something like that would make more sense as having the "article" inside the "body" of the document. Yes, I know link is already used in the head. You know what I mean, though.

I mean, the dual-use of a as both anchor and link has always been bizarre.

<comment><USER20> > I mean, the dual-use of a as both anchor and link has always been bizarre.

In the original Ted Nelson "Xanadu" conception of hypertext (which inspired Berners-Lee and others at the time), all links were bi-directional.

We now use  as a target and  as a source but the original idea was that every link would be both a target _and_ source – you'd link from one page to another then travel through the bi-directional link _backwards_ and resume the original page.

Yeah, it didn't happen because it was grossly impractical didn't serve any real-world purpose. But that's why they share the same tag.

</comment></comment><comment><USER21> The term Hypertext was coined by Ted Nelson, probably 1965. Check out his book Computer Lib/Dream Machines. He envisioneers the internet quite well.

<comment><USER22> Coined '63, published '65 according to wikipedia [http://en.wikipedia.org/wiki/Ted_Nelson](http://en.wikipedia.org/wiki/Ted_Nelson)

I'm old enough to have read Computer Lib ('74) when it came out, I have a first edition which I imported into the UK by sending some sort of international money order to a US bookshop. For some reason I also have a second edition.

</comment></comment><comment><USER23> According to Wikipedia the "href" attribute stands for: "Hypertext REFerence" ([http://en.wikipedia.org/wiki/Hyperlink](http://en.wikipedia.org/wiki/Hyperlink))

</comment><comment><USER24> Even my high school computer science text book taught me HREF= Hypertext REFerence...

Though I didn't know the A stands for Anchor, so there's that.

</comment><comment><USER25> Open proposals - No patents attached:

href => @,to,dest,target (others: [http://json-ld.org/](http://json-ld.org/))

\</comment><comment></comment><comment>-

/etc => /config

/etc/rc.d => /config/start.d

[beyond POSIX]

</comment><comment><USER26> I don't get it. Is this a joke?

</comment><comment><USER27> href stands for HiddenReflex

</comment><comment><USER28> yeah upvotes must just be for humiliation's sake.</comment>


Y Combinator's lady problems, in three charts - <AUTHOR> http://www.washingtonpost.com/blogs/the-switch/wp/2014/03/04/y-combinators-lady-problems-in-three-charts/

<comment><USER2> Is the problem that VCs are ignoring startups with female founders, or is it that women are not becoming startup founders in general? For the first one, that's a problem that VCs need to fix. For the second, if there's something systemically keeping women out of tech startups, that's a problem the _world_ needs to fix.

Assuming that VCs always pick the most promising startup founders without discrimination, the next question is would everyone rather VCs fund unprepared or unqualified founders in order to be more inclusive and look better from a PC standpoint, or pick the best founders that come in front of them and accept that there may not be a diverse mix of people at the company?

It's really easy to prove that they're not funding female founders. It's just as easy to shame them for it in the media. It's a lot harder to prove that this is done out of bias or malice. It's even harder to make the business decision to fund more female founders if you're fairly certain that the female founders that approach you for funding are not prepared to be startup founders.

So what can we do? Women leaders in tech aren't exactly uncommon, nor do they necessarily make the news more than male leaders. I'm sure there are _fewer_ female tech leaders than there are men, but that brings us back to the question of is there actually a problem, and if so is it for the tech companies to solve, or is it for the world to solve?

<comment><USER3> The other possibility is that women just aren't as interested in tech as men. The same is true of other professions like pilots and car mechanics.

[https://en.wikipedia.org/wiki/Women_in_computing#Female_and_...](https://en.wikipedia.org/wiki/Women_in_computing#Female_and_Male_Perspectives)

Men and women's brains are wired slightly differently, so this shouldn't really be a surprise. We just need to make sure that women are given sufficient opportunity to enter the tech industry.

</comment></comment><comment><USER4> I'd like to see these normalized by number of applications per category, but I suppose that's a graph only YC could provide.

<comment><AUTHOR> If YC want to put more figures in the spreadsheet I'll remake the graph. [https://docs.google.com/spreadsheets/d/1tZVHgKnNS5ghjkQou4QO...](https://docs.google.com/spreadsheets/d/1tZVHgKnNS5ghjkQou4QOyQtQWX9sURgSMVYgyC76z-Q/edit?usp=sharing)

</comment></comment><comment> jack-r-abbit That second chart is most telling: [https://twitter.com/shanley/status/440591732283961344/photo/...](https://twitter.com/shanley/status/440591732283961344/photo/1)

Sure it took them 10 years... but they did finally get to the point that they pretty much match the BLS number. So what is their problem exactly? They didn't get there _fast enough_? This just strikes me as one of those _never enough_ issues. They got there... late... but there. But damn them anyway.

And as others have mentioned, we would need to compare this to a plot of _all applicants_ for each year. More important than "percentage of funded companies that had 1+ female" would be "percentage of companies with 1+ female that got funded." Those are two totally different data points.

</comment><comment><USER5> Two things prevent this from being a cogent narrative, in my opinion:

\- How do these figures compare to the overall population of applicants?

\- How do these figures compare to the entirety of VC-backed startups?

Without that knowledge, this is just extrapolation around a set of isolated data points.</comment>


App-Only Banks Rise in Europe and Aim at Traditional Lenders - <AUTHOR> https://www.nytimes.com/2018/09/23/technology/online-banking-monzo.html <comment><USER2> I used Monzo as my day-to-day bank for two months and have only stopped using it because I'm not in the UK and need to keep my money in local currency. It was a terrific experience. Having an instant push notification when money enters or leaves my account, treating card purchase reservations instantly as unconfirmed transactions and not as nebulous inaccessible money, having transaction information presented in a human-friendly format, showing foreign currency transactions in the foreign currency, not charging currency exchange fees, being able to add notes to transactions… it's such a stark contrast to the mobile banking efforts of mainstream banks.

By the way, if you're in the EU, bunq is a similar mobile challenger bank but based in the Netherlands and serving all of SEPA (if you're in the Eurozone you can use them as your main bank; I live in a non-Euro EU country so hold an account just for the hell of it).

Disclaimer: I have multiple friends who work at Monzo.

<comment><USER3> I've been using Monzo for a few years now and also have some friends there.

I have to say the app is just amazing, none of the traditional banks even come close to what Monzo provide. There is nothing overly complex to it - but it just works. Shows you things you would expect a bank to be able to show you, for example the name of the shop where you made a purchase and it's location. Rather than some random name of a parent company.

Sending money to friends has also become so easy now, I make Monzo to Monzo payments on a weekly basis it just works.

I've heard they're great to work for too. Would be interested in working there myself one day.

<comment><USER4> > name of the shop where you made a purchase and it's location.

i would hope that this data can be obfuscated or hidden if the end user desires it.

<comment><USER5> Hidden from who though? The bank obviously needs to know the exact business because what if a dispute opens over the charge. And the end user presumably would like to check that they actually made the purchase so they will need to see the details.

<comment><USER6> I'm guessing they were considering the possibility of a curious spouse/partner looking at your records. Which to me seems far, far less likely to happen with an app-based transaction history than a traditional paper statement posted out to you.

<comment><USER7> If your spouse is checking your bank statements you're probably in an abusive relationship. Hiding things from them seems like a huge red flag in this respect, too (though I'll admit that perhaps gifts are a valid exception here).

</comment></comment></comment></comment></comment></comment><comment><USER8> I would like to see more banks /fintech startups with the same approach to things as Czech primordial fintech startup: Fio.

It is combination of stock broker and credit union (nowadays full-fledged bank) that was founded by bunch of CS graduates. They had internet access to account from the start, originally supported by custom made authentication device and 20 line officially supported shellscript that emulated the device by means of bunch of few "openssl something" commands. They have rest API that really is REST (GET account movements, PUT bunch of payment orders, no bullshit) and when they didn't have API they docummented format of movement notification emails and officially acknowledged and supported machine parsing of such messages (to the order of providing example code).

Somehow I think that EU's PTS2 and such things tries to force banks to do this, but solves the problem from the wrong end.

<comment><USER9> You just described the bank I want. Why oh why we can't have this?

For instance, right now I'm figuring out how to simply query my account balance in a non-interactive way, just to have it displayed on my machine. I basically have two options - try to drive a headless browser through full login process and scrap the main site, or reverse engineer whatever mechanism they have that lets their mobile app show my balance without logging in. Either way, I'm worried the bank will sack my account for breach of TOS, or "attempt at hacking", or some other bullshit.

Really, why can't I just get a token and query some API?

<comment><USER10> Monzo have an API you can use: [https://developers.monzo.com/](https://developers.monzo.com/)

</comment></comment></comment><comment><USER11> I have been using N26 as my daily driver for the last year, and I really don't want to look back at any bank that is using branches. However, I feel N26, Revolut, Monzo, Tomorrow, and all of the others are driving customers away with very expensive "premium" plans.

I recently opened an account with DKB, another German direct bank, but with a shitty app. They offer everything I paid N26 5,90€ month to month (which they raised to 9,90€, can you imagine that) and much more like overnight money and a stock depot, for the tradeoff of having a shitter app, which is basically a webview loading their webpage.

The next thing Europe needs is a Robinhood-like app for fee-free trading.

<comment><USER12> > The next thing Europe needs is a Robinhood-like app for fee-free trading.

Definitely. For generic Europeans wanting to invest in stock market you don't have much choice. There are couple of archaic and/or dodgy brokers with shitty apps (or no apps at all, just some bad websites built decade ago an never upgraded).

<comment><USER13> You can use Interactive Brokers UK even if not based there. It's the best consumer-oriented broker available anywhere.

<comment><USER14> I've looked at a lot of brokers and the choice is overwhelming. Interactive Brokers UK didn't stand out, except for using branding that gives deceiving impressions on who it's regulated by. A more common example is falsely posturing to be regulated by Swiss. I'm not sure why present yourself as a UK brokerage, when in fact you're US regulated.

Anyway, why do you hold IB to be best consumer-oriented broker available anywhere?

Edit: Actually I was looking at forex brokers, stocks is probably different in that a lot of people want access to the US market.

<comment><USER13> IB is the largest retail broker with access to most global exchanges. I'm not sure there are any competitors in the same league so it's hard to compare.

<comment><USER7> Do you work for them?

</comment></comment></comment></comment></comment></comment><comment><USER15> Call me underwhelmed by all of this.

I've never paid a cent for my EU € banking needs for twenty years. Decent web based banking. Real people in a branch a 5 minute walk away. Free SEPA € transactions, free debit and credit card.

<comment><USER16> Where are you? Where I live the banks are pretty much a cartel that haven't had to handle competition for decades and view their customers with infantilizing condescension. And there are loads of fees, as well as absurd interest rates on mortgages. Oh, and they destroyed the country, at least for a while.

<comment><USER15> Belgium. Banking is one of the only services price competitive with other EU countries here.

</comment></comment></comment><comment><USER17> N26 all the way!

Instant account update on purchases (I mean instant, I get a little ding on my phone before the tx has even gone thru at pos). No charges. Can use throughout Europe with no additional cost. No branches no bricks and mortar to subsidise.

In case anyone is interested, the EU has been taking an active interest in disrupting banking monopolies. Check out PSD2! [1]

[0] [https://n26.com/en-eu/](https://n26.com/en-eu/)

[1] [https://en.wikipedia.org/wiki/Payment_Services_Directive#Rev...](https://en.wikipedia.org/wiki/Payment_Services_Directive#Revised_Directive_on_Payment_Services_\(PSD2\))

<comment><USER18> Nobody in his right mind should be using N26, if he cares about his account security. It's beyond my mind, how an online-first bank can be built by hiring dozens of software engineers, but not a single security expert, leaving hundreds of thousands of customers vulnerable to multiple attack vectors[1].

[1] [https://media.ccc.de/v/33c3-7969-shut_up_and_take_my_money](https://media.ccc.de/v/33c3-7969-shut_up_and_take_my_money)

<comment><USER17> gosh, 30 mins.. care to post a TLDR?

I'm not too concerned by this to be honest. Since the last 10 years banking is regulated to such a painful degree that such concerns are _minutiae_.

This isn't bitcoin or a stage coach hurtling through the wild west. The only way money is leaving my account is by way of my chip & pin card, which is no easier or difficult than any other, and subject to the same protections, or by wire transfer which is easily detected and reversed.

Beyond that, it's the bank's problem, ergo their underwriters and if they weren't happy they wouldnt be underwriting. Even then, if the bank does go tits up my deposits are guaranteed.

That said, of course there may be risks of bad actors within the bank itself, but even in that regard I'm _at least as safe_ as I am with any other bank.

<comment><USER18> TLDR: A German security researcher was able to take over any N26 account, even though that theoretically required having an access to customer's email address, phone number, and MasterCard ID. He was then able not only to transfer the money from the account, but also to take a credit on customer's behalf.

<comment><USER17> Thanks. As I said, both of these actions are both easily traceable and reversible. Some inconvenience to me certainly but I am covered, and the the thief is most probably in jail.

This does affect N26's own risk-profile and they'd do well to address it as such it would affect their bottom line but as a customer I have little more to fear than I have with any other bank.

I'd expect they have a lot of latitude to play with on the risk side though vs B&M banks because they don't have any actual physical exposure.

<comment><USER18> > As I said, both of these actions are both easily traceable and reversible. > Some inconvenience to me certainly but I am covered, and the the thief is > most probably in jail.

That's only true, if the bank itself was aware of its security issues, which N26 was not. From the bank's point of view, you had just started using its mobile app on a new device after successfully proving your identity without any suspicious activity in the logs.

<comment><USER17> Yeah a mobile device that I don't own, in a location I haven't been in, buying things I didn't buy. Most of this is easily provable, and I make such assertions based on fear of prosecution for fraud if I'm lying.

Obviously if this is the case it's an issue for them to address and to not do so puts them at risk of negligence.

So I reckon I'm safe enough!

<comment><USER18> You probably would have been safe, unless you lived in Germany and used CASH26[1], like many N26 users do. In that case, a hacker could have just taken all the money out at the place you frequent using any device. Good luck trying to prove to the app-only bank that you didn't give your credentials to anybody, when the bank is not aware of any security breaches.

[1] [https://n26.com/en-de/cash26](https://n26.com/en-de/cash26)

<comment><USER17> That's a cool feature!

I wonder is there a waiver in the T&C that says you're responsible for any losses of that kind ...

Would make for an interesting court case if not!

I still think any such losses are on the bank itself. It would be incumbent upon them to refund, especially given that the details of such an attack are in the public domain!

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> I have one question, and one question only. Which of those providers offer an API - one that I can use as an individual to automate my finances?

That's really the only thing I need over traditional banking. I can handle the rest for myself from there. Even a read-only API would do.

<comment><USER19> Monzo: [https://docs.monzo.com](https://docs.monzo.com)

Starling: [https://developer.starlingbank.com/](https://developer.starlingbank.com/)

</comment></comment><comment><USER20> What I love about my current app-only bank's approach, is that that also includes customer service. I had to speak to them a couple of times, and all the chat is handled inside the app. And dealt with quickly. Love it.

With my old high street bank their app is ok, but often have to refer to the web based service for more extensive features. That made me anxious about using an app-only bank. 1 year in and I have never thought "hmmm wish I could do this on my laptop". You do everything via the app, and it is intuitive.

Since the only time I go into a bank's branch is to open the initial account and then never again, I have no need for them anymore. App-only is fine for me.

I do wonder how services like Curve affects the app-only banks though.

</comment><comment><USER21> The title mentioned lending, but the article says almost nothing about it.

As other commenters have noted, these new banks often have great customer experience. But they don't do much lending. For example, as of February this year, Monzo's loan book totalled 160,000 GBP [0]

Disclosure: I co-founded a UK-based fintech lending business (www.oakam.com). We're hiring PMs, Data Scientists and Software Engineers. Message me if you might want to work on expanding access to credit, and increasing financial inclusion.

[0] [https://monzo.com/annual-report/2018/](https://monzo.com/annual- report/2018/) (ctrl+F 'Loans and advances to customers')

<comment><USER22> Monzo loan book is currently about £10m.

But it's true that we're intending to stay relatively balance-sheet light - the aim is to offer a "financial hub", plugging in third-party products to a central current account (or "checking account" for our US friends).

(I'm the CEO of Monzo)

<comment><USER23> I like this approach; feels very unix-y in philosophy. I am in the position where I'm undoubtably going to need to become an adult soon, and the prospect of going back to traditional banks makes me ill.

</comment></comment></comment><comment><USER12> I've been using Monzo for some while but since I've moved away from London for a while, I couldn't give them a UK address for the new checking bank account. I have been using the original Monzo prepaid debit card and was happy with it but that was discontinued.

Funny enough, I am also a long time TSB customer which is a bank mentioned in the article. Ignoring their huge mess around migrating users to new platform (made by Spanish bank that owns them now), their mobile app is surprisingly good.

Given I travel a lot and have lived in multiple countries, I have several bank accounts so I don't rely on any single one.

</comment><comment><USER24> Why app-only? Is it so hard to provide a website too?

<comment><USER25> I seriously expect, in the near future, only people with highly specialist needs like software developers, video/audio professionals and the like to still use some kind of laptop or desktop -- everyone else will pretty much move to some kind of tablet of various sizes (including mobile "phones").

<comment><USER12> Don't think so. 90% of office jobs in service economy are still basically about entering numbers into Excel spreadsheets and making documents, powerpoint presentations etc. I just don't see any way to make spreadsheet application like Excel work on a touchscreen at an acceptable level for generic office employees.

Furthermore, I am going to make a crazy prediction. I think we will see a substantial revival of PCs in the coming decade as people start finding out there are some things mobile phones or tables will just never be able to do. Only thing needed is an open source operating system with good UI because Windows is obviously not a way forward.

<comment><USER25> "Entering numbers into Excel spreadsheets" is being replaced by automated processes as we speak.

<comment><USER12> So what will all those people do? It would be politically impossible to allow automation to replace all these jobs. I think these jobs will be kept around just to make the electorate happy.

<comment><USER7> I suppose that view makes sense if you conveniently ignore _everything that 's happened since the industrial revolution_.

</comment></comment></comment></comment></comment></comment><comment><USER26> With these app-only banks I am always considered about their security if their main forcus for the first years is to grow at a startup-like pace.

This talk from 2016 shows how they cut corners when it comes to security in order to achieve this: [https://media.ccc.de/v/33c3-7969-shut_up_and_take_my_money](https://media.ccc.de/v/33c3-7969-shut_up_and_take_my_money)

<comment><USER27> Many of the "big traditional banks" used to have this idiotic rule of not using more than 10-12 characters in your account password for many many years, many still do now. So I would not be so judgeful on the new app-only banks.

<comment><USER28> EU banks issue security tokens which are used for login and to authorize every transaction.

<comment><USER29> Some of the banks of some EU countries*

Most French banks don't do that, for example.

<comment><USER28> French banks don't use TAN codes? Isn't it an EU directive at this point? It doesn't have have to be a dedicated hardware token or a chip TAN, mTAN or soft tokens are also acceptable.

<comment><USER30> Not French, but German here. TANs are obviously used for transactions, but I've never seen them used for login purposes. To add insult to injury, the _only_ permissible password length for my bank was 5 (five!) characters.

Looking to make a switch right now..

<comment><USER31> Sounds like Sparkasse, but hey, you can change your _username_ to a longer, unguessable bunch of alphanumeric characters ;)

</comment></comment></comment></comment></comment></comment></comment><comment><USER32> So Mr. Stevenson was frustrated when his previous retail bank's computers were down - so he moved to a computer only bank? Nice logic. I hate branches but its nice to know when everything is screwed up I can go into a physical place and talk to someone. The next crisis when your virtual bank app stops working - what are you going to do then?

<comment><USER33> If it's down for you, it'll be down for the branches. The point of these new banks are so that you can do _anything_ inside the app without having to jump through endless hoops. An example, I'm using Monzo now (a new "challenger bank" in the UK). If I want an overdraft I can enable / disable that in the app. Same goes for if I want to disable my card, change the pin, order a new card. Everything's just easier. No need to spend ages on the phone going through menus and verifying who you are.

<comment><USER34> The bank can disable your account by mistake or have any number of other bugs affecting only small number of customers. With physical bank it is so much easier to make enough noise so at least they spend some time on you. With phone support they can just promise to call you later.

<comment><USER35> My experience with message based support from challenger banks has been very good. Much better than I get from my traditional bank.

<comment><USER36> Devil's advocate: when that new market settles (app-only is the norm and not a "challenger"), will the effort/cost expended on effort be as high?

<comment><USER9> Unfortunately, it won't. So let's enjoy things while they last - when a market matures, quality always goes down the drain.

</comment></comment></comment></comment></comment></comment><comment><USER37> Using Monzo, Monese, N26, TransferWise Borderless, Revolut, for both personal and business purposes, and am a happy camper. EUR and non-EUR accounts.

<comment><USER13> I've tried several of those and TransferWise Borderless is definitely the best. Free debit card, US ACH numbers, good rates.

<comment><USER37> Low rate international transfers is how they started out, before becoming a bank

</comment></comment></comment><comment><USER38> This is an exciting time for banking startups like this, and I know several of the traditional players are looking to emulate this success via app-only onboarding and less reliance on branches.

Security is a concern, so I wouldn't keep my life savings in it, but they are pretty on the ball compared to the established banks. I know of two absolutely massive banks that have absolutely no clue of what IP addresses they own, let alone what services they have running on them.

I've also used both Monzo and Revolut, and I definitely prefer Revolut. I really recommend anyone in Europe tries them! The crypto integration is interesting, but day to day stuff like an automatic savings pot and interbank rate transfers are really good.

</comment><comment><USER39> While the apps look nice, I can't say I see anything that major banks in Sweden haven't offered already for the past 5 years or so. Are we so far ahead or is online banking in such a shitty state?

<comment><USER40> How do I, as a resident in Sweden, open an account that can receive a payment in Euros, then spend those euros without having to convert them to Swedish crowns and back, and pay conversion fees each way?

Revolut does this. It also works out 2-3% cheaper for converting SEK to Euros than either SEB or Nordea.

Unfortunately, as it's UK based, it's not at all clear if Revolut will continue to exist in its current form after brexit.

<comment><USER41> >Unfortunately, as it's UK based, it's not at all clear if Revolut will continue to exist in its current form after brexit.

They recently applied for a banking license in Belgium.

<comment><USER40> Ah, I was not aware. Hopefully they're successful and it just keeps working seamlessly.

</comment></comment></comment></comment><comment><USER42> With the mentioned services, you have to be aware that there is a real sense in which, while Monzo and Starling are _Banks_ , Revolut is not a bank. The other two are FSCS protected (1), guaranteeing your deposit up to £85K, but Revolut is not.

You can check here [https://protected.fscs.org.uk/tools/check-your-money-is- prot...](https://protected.fscs.org.uk/tools/check-your-money-is-protected/)

Revolut is still a useful foreign exchange service - I find it great for holiday money, but it's not the same kind of account as a bank's current account, and it would be a mistake to use it as if it was.

1) [https://en.wikipedia.org/wiki/Financial_Services_Compensatio...](https://en.wikipedia.org/wiki/Financial_Services_Compensation_Scheme)

</comment><comment><USER43> What are your experiences of neobanks for business accounts in the UK? I'm looking for something that will make managing expenses/VAT returns automatic, hopefully connects to Zero or Wave via a real API (and not Yodlee) and is FCSC protected.

Which one is the best?

-Starling

-TransferWise Borderless Business account

-Revolution Business

Do any of them offer interest on cash balances on business account?

</comment><comment><USER44> I'm using N26 right now, and this is obviously the future. It's just so smooth.

</comment><comment><USER45> > The systems failure in April, affecting nearly two million TSB customers, > was a breaking point for Mr. Stevenson. He moved his money to Monzo, a > British start-up that is among a growing number in Europe offering checking > accounts and A.T.M. cards, but lack physical branches — everything is done > through an app.

I don't quite understand this logic. Sure there was a very inconvenient failure. But the reaction is the move your money away from established banks with thousands of employees to an app-based startup? No, not for me, thank you.

<comment><USER7> I'd love to see what TSB's tech stack looks like now. I've worked on data migration projects with financial institutions in the past and the mountains of technical debt are truly terrifying. If TSB have gone through all of this pain and emerged at the other end as a truly modern bank without all the historical cruft I'd be seriously tempted to move over to them.

Don't get me wrong - I'm firmly in the "don't fix it if it ain't broke" camp and have no problem at all with 40-year-old COBOL code handling my transactions. But in my experience plenty of this code _is_ broke and the amount of manual intervention to make things work would have a lot of people keeping their money under their mattress if they saw it first hand.

Food for thought.

<comment><USER46> _If TSB have gone through all of this pain and emerged at the other end as a truly modern bank without all the historical cruft I 'd be seriously tempted to move over to them_

They haven't eliminated it, they just moved from Lloyds cruft to Sabadell cruft.

</comment></comment></comment><comment><USER47> Does anyone have experience using these in the UK as an expat (US)?

<comment><USER48> Not in the UK specifically, but as a US citizen living in the EU I've had small online only banks close my account or refuse my business because dealing with the paperwork that comes with having US citizens as customers just isn't worth their time and effort.

</comment></comment><comment><USER49> I use N26, Revolut, and Revolut for Business. All are amazing.

</comment><comment><USER50> Anyone knows how PTS2 will affect these apps, and traditional banks?

It's a topic that isn't discussed a lot but I'm sure many startups are already working on awesome projects with the PTS2 API spec.</comment>


Do you think browsers should show data downloaded per tab? - <AUTHOR> I read an article saying that some websites download vast amounts of data.<p>I wonder if this information could be surfaced to the user level in a way that makes sense and is not pointlessly "techy". <comment><USER2> They do.

<comment><AUTHOR> Where?

I'd love to see total data downloaded by a table - without opening the developer console.</comment></comment>


$30k b-plan/PROTOTYPE comp.: deadline SUNDAY, free flight to Boston - <AUTHOR> http://www.vator.tv/competition/show/the-20000-babson-innovation-competition

<comment><AUTHOR> Babson College is hosting an open business plan/idea competition. I'd be right up there with my plan - but my prototype (sadly) isn't ready yet. So I'm hoping that one of the Hacker News teams can come in and claim some glory. Right now the competition is very light on technical teams, I think a HN team could have a very good chance with a good prototype.

Here's the dirty deets: 23 companies/plans right now, $75 entry fee (it's a legit contest, legit school: [http://www3.babson.edu/Newsroom/Releases/BabsonForumthis- yea...](http://www3.babson.edu/Newsroom/Releases/BabsonForumthis-year.cfm)), $30k award: $20k cash, $10 services (I presume this means with Highland Capital, which is helping judge), US residents 21 and older.

THIS IS WHAT YOU NEED: a good prototype (not necessary, but after checking out the competitors, you'll need it to get into the top 3 for the free flight + presentation in front of VCs), a very short, basic business plan (executive summary, business model description, competitive advantage, management bio).

Good luck!</comment>


Ask HN: Relationship between OO and functional programming? - <AUTHOR> Since Alan Kay has shown interest (https://news.ycombinator.com/item?id=11806853) in saying something on the topic of OO and functional programming I opened this thread.<p>I purposefully left out the word "versus" because I do not believe there is such a strong dichotomy and to avoid flamewars. <comment><AUTHOR> Disclaimer: I am surely not experienced enough to give a highly informed opinion on the topic.

As I mention in the opening I do not think there is a strong dichotomy between functional and OO programming. I believe historical accident created "Objects vs functions", and by historical accident I mean Java. It is unclear to me why would you not allow to create plain simple functions and force everything in objects. Probably a misunderstanding of "everything is an object".

Famously Alan Kay emphasizes "message passing" as the key characteristic of object orientation. Because every discussion about OOP and functional programming eventually ends up talking about State as the main discussion point, I fail to note how a definition of OO based on message passing contrasts the benefits of functional programming around state management.

In fact the way I see it is that when we have more units communicating with each other they form a system that should be functionally pure from an external point of view but can be OO in its internal implementation.

EDIT: Continuing my train of thought: the problem with OO in it's current common form is that objects often/always leak details about their state. So you have a tuple (state, [actions]) where often using an action is invalid given the tuple's state.

</comment><comment><USER2> I was reading "The Early History of Smalltalk" a while back ([http://worrydream.com/EarlyHistoryOfSmalltalk/](http://worrydream.com/EarlyHistoryOfSmalltalk/)) by Alan Kay, and the thing that jumped out at me was goal-oriented methods (see the section "Object-oriented" Style). That is, when you are calling other code you don't tell the other code how to do something – and of course you don't go poking into what the other code "knows" (i.e., accessing properties on an object) – instead you say "please, make it this way". The code may succeed or may fail, but you aren't micromanaging the code.

From my time with Smalltalk I found this pattern quite remarkable, though also at times hard to trace. You'd tell an object to do something, and it might access some object it knows about, maybe do a test or guard, and then it would tell the other object to go do that thing. And the other object might in turn delegate, many levels deep. The result could be really incredible and compact, though it also felt like it wasn't actually easier to understand. Kind of Ravioli Code ([http://c2.com/cgi/wiki?RavioliCode](http://c2.com/cgi/wiki?RavioliCode)), though not the kind of modern Ravioli Code you might see because someone takes DRY too seriously – instead it reminded me more of a mathematical proof. Mathematical proofs are really cool, but they do not contain the information necessary to reproduce them; a mathematical proof is the result of studying and pondering and struggling with a problem for a long time until you reduce it to something compact and beautiful. The result seems magical, but in part because you threw away all the struggling that produced the result. That's what the core Smalltalk class hierarchy felt like to me; beautiful, maybe not reproducible, not always accessible. All of which is a critique of one place and time of code, and OO is bigger than that, but I suspect it's also some of the result of created goal-oriented methods All The Way Down.

Functional programming can also be goal-oriented if you can reify all your goals, because ultimately that which isn't reified (that is, made into data or state) can't be the result of a function. I don't have as intuitive a sense there, is goal-oriented functional programming an ideal people hold?

Another Smalltalk lens on OO is message-oriented programming, where you have a set of objects or actors which pass messages, but never directly "touch" each other, and in some sense objects are more autonomous than a conventional understanding of OO. This does not map well to functional programming – the purpose of messages to autonomous objects is to effect state, to make changes in the world. Of course that's the purpose of all programming, so it's not crazy. In some sense functional programming lifts the purposeful and useful outcomes of a program out of the programming, and into the environment. I would consider that a stronger contrast with OO.

</comment><comment><USER3> Stuart Halloway has a great talk on this called "Simplicity Ain't Easy" [0] where he more or less states that a FP language like Clojure is basically a better designed OOP language, because FP is basically contains all its strengths (namespaces, abstractions and the like) and none of its weaknesses (e.g. uncontrolled state mutation) and you are able to select and use specific features you need to solve a specific problem, and not being saddled with every feature (including the ones you do not need to solve the problem at hand) at once.

[0] [https://www.youtube.com/watch?v=cidchWg74Y4](https://www.youtube.com/watch?v=cidchWg74Y4)

</comment><comment><USER4> One way to start to think about this is the relationship between objects and abstract data types. These are both techniques for introducing data abstraction, but their approach is different and have different tradeoffs.

[https://www.cs.utexas.edu/users/wcook/papers/OOPvsADT/CookOO...](https://www.cs.utexas.edu/users/wcook/papers/OOPvsADT/CookOOPvsADT90.pdf) is a paper that argues them as complementary to one another. It's worth reading in its entirety, but an excerpt from the conclusion:

 _A detailed analysis of the trade-offs involved must be made in order to choose whether an ADT or PDA [ "object"] is better suited for a problem. Some relevant questions in this choice are: How likely is it that the system will be extended? Must the security of the system be preserved, even at the expense of extensibility? Is it possible the unforeseen interactions may be desired? Is the environment dynamically extensible, and must the additions interact in complex ways with existing code? How much efficiency is required? Is it likely that there will be a large number of binary operations with complex behavior?_

In general, ADTs tend towards tight coupling, yielding more predictability, performance, etc. Objects tend towards looser coupling, allowing more flexibility and extensibility. This is a reasonable microcosm of the relationship between FP and OO.

</comment><comment><USER5> OO is when you really love objects, you put objects in objects.

FP is when you really love functions, you put functions in functions.

Of course, if you like both, you can put functions into objects and objects into functions.

</comment><comment><USER6> For my money, OOP and FP are two axes on the same Expression Problem [0]. OOP languages, it's easy to add data on which a fixed set of functions can operate. In FP languages, it's easy to add functions that can operate on a fixed set of data. This is why there will never be a distinct "winner" between the two.

It's also why you have Greenspun's Tenth Rule, and why there is probably a Smalltalk corollary for FP languages. You eventually need to be able to solve both halfs of the expression problem.

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

<comment><USER7> Maybe the future of programming is a language with a highly dynamic, flexible syntax that can switch axes easily/visually/syntactically (or _gasp_ <meta>programmatically!</meta>).

</comment></comment><comment><USER8> I like Michael Feather's quote [https://twitter.com/mfeathers/status/29581296216](https://twitter.com/mfeathers/status/29581296216)

OO makes code understandable by encapsulating moving parts. FP makes code understandable by minimizing moving parts.

I think they can be used in a complementary manner. One area where functional thinking can be a benefit can be in code that is tested with a lot of mocks. Instead of having a bunch of objects that mutate state and that need to be mocked out, model that part of the program as a series of pure function transformations of data. It will be much easier to test and reason about.

<comment><USER9> Tiny request -- can you indicate that the line following the link is a quote? I wasn't sure if that was from the 'tweet' or if that was your interpretation/summary of it

</comment></comment><comment><USER10> Rich Hickey has mentioned that abstracting i/o devices is an example of where OO can make sense. using OO properly requires a honed intuition about how to build large, stable software systems and see occasions where, in such systems, some component or aspect would truly benefit from a bit of OO sprinkled in. i think one great way to develop such an intuition is pick up a functional language and use it for a significant period of time (a couple years) -- because this let's you see how far you can get just by writing simple functions and passing around simple data structures without any classes.

</comment><comment><USER11> I really whish more people knew about OCaml's object system.

I would actually argue that OCaml has a better OO system than most OO languages, but it looks and feel quite different (it's "functionalish": immutable by default, objects are structural and can be classeless, etc).

In the end, despite its strength, it's used very little in the OCaml community: Modules are better 95% of the time.

The gold standard for doing nice encapsulation, abstraction and separation of concern is neither functions nor objects, it's ML modules.

</comment><comment><USER12> eh when you get down to it they tend to be 2 extremes with most programing being somewhat in the middle, there is a great article [0] that discusses the absurdity about talking about object oriented program by comparing it to talking about 'pants oriented clothing' in that it misses the big picture

[0] [http://steve-yegge.blogspot.com/2006/03/execution-in- kingdom...](http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of- nouns.html)

</comment><comment><USER13> One relation I feel is that OO stresses on behavior and data to be a part of a single entity. Functional paradigm asks to keep them separate, with immutable data structures being passed to pure functions that have the behavior.

</comment><comment><USER14> It seems to me that this is all about access to data (state).

Pre-OO (and FP), we had structured programming, where the data lived in variables or structs, and _anybody at all in the entire program_ could alter the data. That turned out to be difficult to maintain, because if the data wound up in a bad state, any line in the program could have changed it.

OO (as typically used) meant that an "object" owned the data, and nobody else could touch it. That meant that, if the data wound up in a bad state, only a very small section of the program could have (directly) changed it. That was a huge improvement.

In (pure) FP, the data disappears. You don't talk about it directly (except within one function, where you have bindings to it). The data disappears into the plumbing (the connections between functions), and _nobody_ changes it. If it was computed correctly when created, it's correct forever, because nobody can change it.

In this sense, both FP and OO are trying to solve one of the biggest problems with the old structured paradigm.

</comment><comment><USER15> The biggest difference I've seen in my career:

\- OOP code is usually separated and organized by the principal data it operates on, i.e. the instance of a class, and more specifically the instance's fields.

\- FP code is usually separated and organized by the more abstract or philosophical responsibility of the functions, and they may not always share the same arguments.

</comment><comment><USER16> Smalltalk has a lot of similarity with functional programming. Smalltalk's True and False instances are basically Church Booleans, and Smalltalk collections were processed frequently by passing a Block (like a first class function).

I joke that if Smalltalk were invented today, it would be called a "functional/object hybrid language for creating Internal DSLs"

</comment><comment><USER17> I wrote the following blog post after a fairly detailed exchange with Dr Alan Kay.

[http://www.brandonkeown.com/2016/01/the-interrelationship- of...](http://www.brandonkeown.com/2016/01/the-interrelationship-of- object.html?m=1)

</comment><comment><USER18> I suggest people to take the pharo mooc on FUN. I have to admit, smalltalk has a very different flavour of OO. It's very tiny, and helps thinking in tiny reusable pieces of logic from objects to objects, not very far from function composition.

[https://news.ycombinator.com/item?id=11690331](https://news.ycombinator.com/item?id=11690331)

</comment><comment><USER7> Here's a weird viewpoint: OO and FP only seem different because we serialize code through text.

Some languages (spoken languages) construct sentences Subject->Verb->Object, others Subject->Object->Verb, etc, etc. The underlying relations between the parts are still there (there's an isomorphism in the graph), but the projection onto linearized words just takes a slightly different angle.

In OO languages, we treat objects as the important component, and functions as their children: bar.foo(). In FP languages, we treat functions as the important component, and objects as data passing through: (foo bar).

There's no difference in the relations, it's just a different projection from high-dimensional computation-space onto one-dimensional text that causes all sorts of confusion.

That's not to say the difference doesn't matter: projecting computation in a different way frames a different mental model for the programmer that might help or hurt, depending on the specific domain and on the specific problem.

But I think there's value in trying to see the zen in OO's and FP's isomorphism, and practicing switching projections in the same domain as a problem-solving technique.

<comment><USER19> Don't agree with this. Usually, when people refer to "OO", they're talking about subtype-polymorphism along with OO 'encapsulation' of mutable state.

These are very distinct from a FP approach. Note that in Scala, you can do 'pure FP' that _looks_ very much like OO,

        myData = oldData.change().map(x => x+1).filter(x => isTrue(x))

So you can see that the verb/object dichotomy sort of breaks down. In mutable 'OO' worlds, state is always _implicit_ (because of this).

In the large, this is much harder to reason about! Even in Scala, a language which gives us OO, we (Verizon Labs) as an organization elected to lean _hard_ on the FP side and shy away from the OO side of things.

<comment><USER7> I agree the analogy is loose, but your comment raises an interesting question. It seems like we're talking about talking about two different definitions of what FP is.

There's a strict, technical definition of "functions which have no side effects", which defines a coding style. But there's also a more subtle, ambiguous definition of "functions as the primary and most irreducible building block of code", which defines a coding philosophy. In my opinion, FP is the latter, so I'd actually disagree and say that your Scala code _isn 't_ FP, since it emphasizes transformations _on_ an object.

Maybe I'm in the minority here.

<comment><USER19> the term 'function' refers to a true function, no side effects. So, when I say "FP", that's what I mean.

>so I'd actually disagree and say that your Scala code isn't FP, since it emphasizes transformations on an object.

What I wrote is no different than

       change(oldData) |> map(x => x+1) |> filter(x => isTrue(x)

Often the '.' style in scala is literally syntactic sugar that will get rewritten to pass the data to a stand alone function.

</comment></comment></comment></comment><comment><USER20> My take on this is that computation is the act of describing different states that the processor can be in - or describing the path from one state to the next.

I think an understanding of state is fundamental - one thing that brought this home to me was a talk I watched given by Sophie Wilson [[https://en.m.wikipedia.org/wiki/Sophie_Wilson](https://en.m.wikipedia.org/wiki/Sophie_Wilson)] in which she displayed an image of a cpu. The image showed a 'path' across the cpu that was the current state, the next image showed a different path describing a different state. The path was a lot like a bolt of lightening.

An understanding of functional programming (FP) matches this a bit more directly than OO as FP is a pipeline of functions that describes state change and it is easy to reason about the state at any point in the pipeline. OO represents a real world object so you are encouraged to think about the problem you are modelling rather than the how to represent different states. But obviously in the end they both describe state and logic that describes state transition.

<comment><USER21> Neat take on it. Finite state machines tend to be very robust since the designer has to lay out all the state transitions beforehand. Everything else is all combinational logic. Bad OO tends to have state spread out everywhere, but even good OO usually won't be so strict about state.

<comment><USER20> Yeah - I think FP forces you to think about state and state transition while OO forces you to think about your abstraction and modelling. So if you do OO without consideration of what's going to happen next - the compilation and what the computer is actually doing, i.e. moving from state to state, then it's easier to make bad design decisions.

</comment></comment></comment><comment><USER22> Leaving out the 'VS' was exactly the theme behind a presentation our team mate Wojtek done on OOP & FP: [https://tech.evojam.com/2016/05/23/take-the-best- from-both-w...](https://tech.evojam.com/2016/05/23/take-the-best-from-both- worlds-functional-and-object-oriented-programming/)

</comment><comment><USER23> Well, OO tries to represent entities, and their state, via objects.

FP emphasizes immutability. So in OO + FP, objects are treated as immutable data. Functions create new objects instead of modifying the same object (avoiding side effects).

For convenience you can create functions to access parts of an object instead of creating new objects to achieve the same.

</comment><comment><USER24> Question: What is the difference between x.foo(12) and foo(x,12)?

Answer: Nothing but syntax and ideology.

</comment><comment><USER25> I wrote about this here: [http://somethingdoneright.net/2015/07/30/when- object-orienta...](http://somethingdoneright.net/2015/07/30/when-object- orientation-works-a-rule-of-thumb.html)

Comments welcome.

</comment><comment><USER26> Just a bit of a fun post on the subject, I quite like this koan about OO vs Closures [0]:

 _The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures."

Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.

On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened._

I was surprised at having come to a similar understanding after implementing a very basic OO system in Scheme some years ago.

[0] - [http://c2.com/cgi/wiki?ClosuresAndObjectsAreEquivalent](http://c2.com/cgi/wiki?ClosuresAndObjectsAreEquivalent)

<comment><USER27> I was going to post this -- beat me to it!

Once you internalize the truth that Objects and Closures are two ways to express the same sort of things, your mind is free to craft wonderful solutions.

</comment></comment><comment><USER28> The original idea behind OOP as articulated by Dr. Kay was that since general- purpose computers (Turing Machines) are powerful enough to simulate/approximate any process, then computers should be the smallest building block of a system (especially one that wants to scale -- recursion is awesome).

In general, objects are supposed to be _processes_ (in the general sense, not necessarily OS processes). Some of those processes might be equivalent to full Turing Machines, but most will be much more limited; it just depends on what kind of formal grammar they recognize, which is key to understanding objects: They are just processes that accept some input and dispose of it as either _code_ (something that is translated and executed) or _data_ (something that is stored and forwarded). Crucially, in either case, objects do work by sending and responding to _messages_. This is why Dr. Kay says that the actual big idea of OOP is message passing[1].

Once I learned to appreciate _real_ OOP, I realized that there is actually a natural _simpatico_ between FP and OOP rather than a dichotomy. Consider that if you're doing real OOP, you're going to end up designing lots of little languages and then implementing interpreters/compilers for them. Well, it turns out that it's comically easy to build compilers and interpreters using statically-typed languages like ML (F# in my case).

Now days, I use F#, C# (immutably w/o setters), and SQL to simulate an environment that recapitulates what I think is the real power of Smalltalk/OOP: It can rather directly simulate the process of scientific progress itself. I now find myself designing classes that represent falsifiable statements [2] (e.g rather than a class 'SearchEngine', I'd have something like 'LowLatencySearchEngine'). Just as scientific progress is often concomitant with theories and models that have ever more symmetry, so it is the case with the graph of classes that describe my system: I somehow end up with fewer central points of failure. For instance, in the case of 'SearchEngine' vs 'LowLatencySearch' engine, the latter made it apparent that my class should be initialized with a _set of search providers_ , and that it should keep latency statistics (thus being able to falsify the proposition). The end result is that the proposition represented by the class naturally contraindicates that I should rely on any one search engine.

There's a lot more to say about this, but the last thing I'll mention is that FP languages like ML teach you that there is a difference between a class and a (static) type. The big idea is that types correspond to logical propositions (the so-called Curry-Howard Isomorphism), but I naturally ended up there just by trying to more effectively simulate the process of science, which brings us full circle to Alan Kay's big idea: computers can simulate any process, they can even simulate better computers. I would argue the scientific process is the best computer of all.

[1] [http://c2.com/cgi/wiki?AlanKayOnMessaging](http://c2.com/cgi/wiki?AlanKayOnMessaging)

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

<comment><USER29> >objects are supposed to be processes

>FP languages like ML teach you that there is a difference between a class and a (static) type

DING DING DING THIS MAN GETS THE PRIZE. I've been trying to come up with a nice way to articulate this. When writing Java I try to think of "value classes" as structs, and classes as "actors".

</comment></comment><comment><USER30> On the meta level, I came to think of the relationship between OO and FP as similar to being and doing.

Does a duck, walks like a duck and talks like a duck, because it is a duck (being) ?

OR

Is a duck, a duck because it walks like a duck and talks like a duck (doing) ?

</comment><comment><USER31> See [https://wiki.haskell.org/OOP_vs_type_classes](https://wiki.haskell.org/OOP_vs_type_classes)

</comment><comment><USER32> I think they are both concepts with different traits or required features. These are my subjective definitions:

OOP:

\- _Everything_ is an object

\- Inheritance (an object inherits all features of its class and super classes)

\- Polymorphism (one object can replace another if the required class is one of its own or its super classes)

\- Encapsulation (an object exposes only what it is meant to expose (black box))

FP:

\- Functions can be used as values (therefore it is possible to write higher order functions)

\- There is no state/variables, so that any function call with its input parameters define the result and can therefore be cached quite easily

So in theory it should be possible to combine the two concepts, but in my opinion it doesn't make much sense as they have different strengths and weaknesses (e.g. introducing state to FP is a very bad idea...).

Sadly many languages try to combine both concepts and implement both poorly and on the other hand there are too few people who actually understand the concepts and use them appropriately.

As a rule of thumb:

\- Take OOP if you have to model the relationship and interaction between things (objects)

\- Take FP if you have to calculate something (like Excel formulas do)

<comment><USER33> >As a rule of thumb ...

I've heard variations on that a lot, but have not found it to be true at all. I've tried 3 times over the years as I got better at programming to write a server for a little mmorpg in OO languages. Each time it turned into a buggy, unmaintainable mess. On my fourth try I was using ocaml because I thought a better type system could help. Again the OO version I wrote initially was buggy and terrible. But being ocaml, I could rewrite bits and pieces in a functional style and improve it gradually. I ended up with no OO code at all, and very little imperative code (which was only for performance reasons). This is the very definition of "you have to model the relationship and interaction between things (objects)", but OOP was terrible and FP is great.

</comment></comment><comment><USER34> I would say an object is a state machine and a pure function is a transition.

</comment><comment><USER35> I believe OO and FP are separate. OO languages should not be extended to have functional characteristics. OO is a complete system and functional is a different system although I cannot say why it is.

<comment><USER36> Hmm...you don't "extend" OO with FP, you constrain it, OO is the richer paradigm.

See [https://www.info.ucl.ac.be/~pvr/book.html](https://www.info.ucl.ac.be/~pvr/book.html)

</comment></comment><comment><USER37> OO favors indirection to make code supposedly "maintainable." FP likes completeness in one place so code is more readable.

<comment><USER23> I don't think FP will necessarily translate into increased readability.

That depends on proper code organization, identifiers, formatting, documentation, coupling, good practices in general.

</comment></comment><comment><USER38> I gave at talk about this at Scala Days NY, and I'll give it again in Berlin in a few weeks if I remember to actually book transport and a hotel. I'll just try and summarise here, because I don't have the energy or time to write out my talk :-)

I think FP and OO are fundamentally different in how they approach programming: the way they break down problems, what they consider to be good code, and so on. OO views code as small unit of encapsulated state communicating with one another. FP views code as a series of transformations. OO code is not good FP code, and vice versa.

On a lower level you can find many similarities. OO patterns are largely FP language features, from a time when knowledge of FP was not very widespread. At least five of the Gang of Four patterns are first class functions is disguise. Going the other way, a very typical pattern in functional programming is to build up a description of what should happen, and then have an "interpreter" actually execute that description. These interpreters often look like "coalgebraic" structures, which is an FP term for ... objects. Now isn't that interesting?

In summary, the techniques often look very similar if you squint, but the fundamental way they approach programming is very different.

That's a very quick sketch, which is somewhat hazy on the details. Apologies for the brevity and lack of nuance.

<comment><USER9> That's really neat you've given a talk about this. If by any chance the talk is recorded it'd be great to watch it!

<comment><USER39> Looks like he's posted slides here: [https://twitter.com/noelwelsh/status/730449315789934593](https://twitter.com/noelwelsh/status/730449315789934593)

I also really liked his talk on probabilistic programming: [https://www.youtube.com/watch?v=e1Ykk_CqKTY](https://www.youtube.com/watch?v=e1Ykk_CqKTY)

<comment><USER9> Awesome, thanks!

</comment></comment></comment></comment><comment><USER40> Already lots of good comments and ideas below. My first attempt here on this topic turned out too wordy -- and this attempt is also (I tried to explain things and where the ideas came from). A summary would be better (but Pascal was right). I'll try to stash the references and background somewhere (perhaps below later in a comment).

I had several stages about "objects". The first was the collision 50 years ago in my first weeks of (ARPA) grad school of my background in math, molecular biology, systems and programming, etc., with Sketchpad, Simula, and the proposed ARPAnet. This led to an observation that almost certainly wasn't original -- it was almost a tautology -- that since you could divide up a computer into virtual computers intercommunicating ad infinitum you would (a) retain full power of expression, and (b) always be able to model anything that could be modeled, and (c) be able to scale cosmically beyond existing ways to divide up computers. I loved this. Time sharing "processes" were already manifestations of such virtual machines but they lacked pragmatic universality because of their overheads (so find ways to get rid of the overheads ...)

Though you could model anything -- including data structures -- that was (to me) not even close to the point (it got you back into the soup). The big deal was encapsulation and messaging to provide loose couplings that would work under extreme scaling (in manners reminiscent of Biology and Ecology).

A second stage was to mix in "the Lisp world" of Lisp itself, McCarthy's ideas about robots and temporal logics, the AI work going on within ARPA (especially at MIT), and especially Carl Hewitt's PLANNER language. One idea was that objects could be like servers and could be goal-oriented with PLANNER-type goals as the interface language.

A third stage were a series of Smalltalks at Parc that attempted to find a pragmatic balance between what was inevitably needed in the future and what could be done on the Alto at Parc (with 128K bytes of memory, half of which was used for the display!). This was done in partnership with Dan Ingalls and other talented folks in our group. The idealist in me gritted my teeth, but the practical results were good.

A fourth stage (at Parc) was to deeply revisit the temporal logic and "world- line" ideas (more on this below).

A fifth stage was to seriously think about scaling again, and to look at e.g. Gelernter's Linda "coordination language" as an approach to do loose coupling via description matching in a general publish and describe manner. I still like this idea, and would like to see it advanced to the point where objects can actually "negotiate meaning" with each other.

McCarthy's Temporal Logic: "Real Functions in Time"

There's lots of context from the past that will help understanding the points of view presented here. I will refer to this and that in passing, and then try to provide a list of some of the references (I think of this as "basic CS knowledge" but much of it will likely be encountered for the first time here).

Most of my ways of thinking about all this ultimately trace their paths back to John McCarthy in the late 50s. John was an excellent mathematician and logician. He wanted to be able to do consistent reasoning himself -- and he wanted his programs and robots to be able to do the same. Robots were a key, because he wanted a robot to be in Philadelphia at one time and in New York at another. In an ordinary logic this is a problem. But John fixed it by adding an extra parameter to all "facts" that represented the "time frame" when a fact was true. This created a simple temporal logic, with a visualization of "collections of facts" as stacked "layers" of world-lines.

This can easily be generalized to world-lines of "variables", "data", "objects" etc. From the individual point of view "values" are replaced by "histories" of values, and from the system point of view the whole system is represented by its stable state at each time the system is between computations. Simula later used a weaker, but useful version of this.

I should also mention Christopher Strachey -- a great fan of Lisp and McCarthy -- who realized that many kinds of programming could be unified and also be made safer by always using "old" values (from the previous frame) to make new values, which are installed in a the new frame. He realized this by looking at how clean "tail recursion" was in Lisp, and then saw that it could be written much more understandably as a kind of loop involving what looked like assignment statements, but in which the right hand side took values from time t and the variables assigned into existed in time t+1 (and only one such assignment could be made). This unified functional programming and "imperative like" programming via simulating time as well as state.

And let me just mention the programming language Lucid, by Ashcroft and Wadge, which extended many of Strachey's ideas ...

It's also worth looking at "atomic transactions" on data bases as a very similar idea with "coarse grain". Nothing ever gets smashed, instead things are organized so that new versions are created in a non-destructive way without race conditions. There is a history of versions.

The key notion here is that "time is a good idea" \-- we want it, and we want to deal with it in safe and reasonable ways -- and most if not all of those ways can be purely functional transitions between sequences of stable world- line states.

The just computed stable state is very useful. It will never be changed again -- so it represents a "version" of the system simulation -- and it can be safely used as value sources for the functional transitions to the next stable state. It can also be used as sources for creating visualizations of the world at that instant. The history can be used for debugging, undos, roll-backs, etc.

In this model -- again partly from McCarthy, Strachey, Simula, etc., -- "time doesn't exist between stable states": the "clock" only advances when each new state is completed. The CPU itself doesn't act as a clock as far as programs are concerned.

This gives rise to a very simple way to do deterministic relationships that has an intrinsic and clean model of time.

For a variety of reasons -- none of them very good -- this way of being safe lost out in the 60s in favor of allowing race conditions in imperative programming and then trying to protect against them using terrible semaphores, etc which can lead to lock ups.

I've mentioned a little about my sequence of thoughts about objects. At some point, anyone interested in messaging between objects who knew about Lisp, would have to be drawn to "apply" and to notice that a kind of object (a lambda "thing", which could be a closure) was bound to parameters (which kind of looked like a message). This got deeper if one was aware of how Lisp 1.5 had been implemented with the possibility of late bound parameter evaluation -- FEXPRs rather than EXPRs -- the unevaluated expressions could be passed as parameters and evaled later. This allowed the ungainly "special forms" (like the conditional) to be dispensed with, they could be written as a kind of vanilla lazy function.

By using the temporal modeling mentioned above, one could loosen the "gears" of "eval-apply" and get functional relationships between temporal layers via safe messaging.

So, because I've always liked the "simulation perspective" on computing, I think of "objects" and "functions" as being complementary ideas and not at odds at all. (I have many other motivations on the side, including always wondering what a good language for children should be epistemologically ... but that's another story.)

<comment><USER41> > many kinds of programming could be unified and also be made safer by always > using "old" values (from the previous frame) to make new values, which are > installed in a the new frame

John Carmack came across this idea at some point - in 'Functional programming in C++' [1], he writes:

"When you start thinking about running, say, all the characters in a game world in parallel, it starts sinking in that the object-oriented approach of updating objects has some deep difficulties in parallel environments. Maybe if all of the object just referenced a read only version of the world state, and we copied over the updated version at the end of the frame… Hey, wait a minute…"

I don't know if he got this explicitly from the Strachey lineage, or if it's the inevitably approach if you try to use immutability to tackle concurrency.

[1] [http://www.gamasutra.com/view/news/169296/Indepth_Functional...](http://www.gamasutra.com/view/news/169296/Indepth_Functional_programming_in_C.php)

<comment><USER40> The way I have looked at this is that a big problem is the confusion of "objects" with "abstract data types" and the clinging to "data" and "assignment statements". As soon as encapsulation is really enforced the object can do what it needs to deal with the design parameters (including keeping histories, etc.).

Again: it's really worth looking at Dave Reed's MIT thesis ...

</comment></comment></comment><comment><USER42> In the past five years, I've written C#, Ruby, and Javascript in a style I'd describe as "OO, but with a heavy functional accent"; it might even be fair to call it "object-functional".

A few little things I've identified that I do, that aren't totally mainstream:

\- Don't reassign parameters, in fact, don't reassign things at all, if you can avoid it; show your work. It makes for more expressive code, and you'll have fewer bugs.

\- Think of your code as doing "evaluation", not "computation". Code should take a bunch of inputs, do some stuff to them, and then return an "evaluated" response, vs. the viewpoint of "doing a procedure".

\- Try not to make functions side-effecting. Avoid "void" unless you really need it, and really, _really_ avoid distant side-effects.

\- Don't be afraid to return a new object that seems "large" from a method. If you do it right, you'll mostly be copying references anyway which is pretty cheap.

\- Share data liberally by reference all over your code.

\- Don't be afraid to use a bit of recursion.

On the other hand, I'm not afraid of a little grubby OO now and then, especially when dealing with I/O, file handles, network streams, etc.

All to say, I think the two styles are about 90% compatible but there are some parts that don't mesh well. I'm not afraid to mix them, though.

<comment><USER43> "-Share data liberally by reference all over your code. -Try not to make functions side-effecting" Aren't those 2 points contradictory?

<comment><USER44> Immutable data is very easily shared.

<comment><USER45> Doesn't "by reference" imply mutability and allow for side-effects (as opposed to by value, which cannot side-effects by design).

<comment><USER14> No. In C++, for instance, you can share data either by a const reference (or pointer), or by a non-const reference (or pointer). The latter allows mutation; the former does not.

Now, that means that the language is not _forcing_ you to share without mutability, because you can leave off "const". That is, you have to be disciplined. But if you put "const" on the reference, the compiler won't permit you to modify the data through that reference.

</comment></comment></comment></comment></comment><comment><USER46> This is a really interesting question and much work has been done.

For a long time, lambda-calculus has been seen by a lot of programming language researchers as the foundation of programming to which every other paradigm has to be reduced. This research tradition produced much work on encoding object orientation (whether class-based or object based) into lambda- calculus. Ideally such encodings should be sound and complete. That has proven difficult. In parallel, functional languages acquired OO extensions. The first serious implementation to make this (sort of) work was OCaml. Arguably, all that work wasn't quite convincing. Eventually, it became clear that lambda- calculus isn't the basis of all other programming paradigms. Instead people tried the reverse: encoding lambda-calculus into object-orientation.

Scala really nails this, and validates your intuition that there isn't a dichotomy. Instead FP is a special case of OO.

If you want to understand the relationship between OO and FP there is no better way at this point to learn Scala and study how lambda-calculus (both at program and type level) is encoded into class-based object orientation.

<comment><USER47> This is unfortunately not true, though I think the factually incorrect parts (as opposed to those I simply disagree with) are due to misuse of terminology more than anything.

First, the factually incorrect:

> For a long time, lambda-calculus has been seen by a lot of programming > language researchers as the foundation of programming to which every other > paradigm has to be reduced.

... not really. The lambda calculus is a way to represent computation, which is Turing equivalent; it can encode any computation which a Turing machine can. You can reduce _any_ program to either a Turing machine _or_ the lambda calculus, as they are both capable of representing any computation. The lambda calculus is not inherently functional, or OO, it's much lower level. To be fair, lambda calculus did lead directly to Lisp, which has long been associated with functional programming (though it is also not inherently functional - see Emacs Lisp or Common Lisp).

> Eventually, it became clear that lambda-calculus isn't the basis of all > other programming paradigms.

Again, no. The lambda calculus is as much a basis of all other programming paradigms as the turing machine is.

> encoding lambda-calculus into object-orientation

After the above explanation, hopefully it's clear that this statement doesn't really make sense. Again, I'm guessing that this is mostly due to incorrect use of the term "lambda calculus" \- you likely meant to use another term.

On to the stuff I just disagree with:

> FP is a special case of OO

Highly disagree. FP and OO are simply two different methods of organizing and connecting code and data - in OO, you have objects that encapsulate state and expose functions to the outside world that modify and retrieve that state. In FP, you write programs as series of functions that transform data. The fundamental difference is that in OO you are treating data and its related functions as a fundamental unit _together_ and structure your program around connecting objects together, and in FP your program is essentially a data pipeline. The other distinctions between OO and FP (immutable vs mutable state, generic collection interfaces vs specialized interfaces for different kinds of data) stem from that fundamental dichotomy.

Scala may combine the two, and may do so elegantly (I really don't know, I've never used it), but even if its particular kind of FP is encoded in an OO system, that doesn't imply that FP at large is a special case of OO. In fact, I'd argue the opposite: a method on an object is simply a function with an implied argument (the object) in a scope where that argument is inacessible from outside. You can see this clearly in pre-ES6 JS, where that's literally how an object is constructed (in the Crockford style - the prototype style is a bit different).

<comment><USER46> I'm afraid this is wrong.

Yes, all programming languages are equivalent in the sense of the Church- Turing thesis. From the point of view of PL research that means equivalency with TMs is an uninteresting criterion for comparing PLs. Consequently, PL researchers have developed finer tools for comparing languages, typically centring around _compositionality_. An encoding _enc_ from language _L1_ to language _L2_ is compositional whenever _P = f(P1, ..., Pn)_ is a program, then _enc(P)_ is of the form _enc(f)(enc(P1), ..., enc(Pn))_. This idea, that I present here in a very simplified form, has been studied quite deeply, and in this sense it has been difficult to reduce OO to FP, unlike the other way around.

And yes, lambda-calculus is the essence of FP. Indeed there is no PL paradigm that is so closely connected with a single formalism as FP.

       a method on an object is simply ...

This view is too simplistic, and doesn't scale up to include OO features such as method overriding.

In summary: OO is substantially more expressive than FP.

<comment><USER48> Not really.

The goals of OO features such as method overriding is accomplished by typeclasses or implicits in FP.

It's just that the default polymorphic mechanism for FP is parametric polymorphism, and the default mechanism for OO is ad-hoc polymorphism.

OO didn't have parametric polymorphism initially, and added it with Generics.

FP didn't have ad-hoc polymophism initially, and added it later with typeclasses or implicits.

Choosing OO or FP really just puts you one of the two side of the [https://en.wikipedia.org/wiki/Expression_problem](https://en.wikipedia.org/wiki/Expression_problem) . They are more complimentary than proper subsets of each other.

<comment><USER46> I agree that implicits and type-classes can provide ad-hoc polymorphism, but I'm not aware that they have been reduced completely to FP without them, I'm also not aware of implicits and type-classes working in an untyped setting. If you have references to the contrary, I'd be interested to hear about it.

<comment><USER48> Well if one is looking for proofs, I think this is hard while remaining abstract from specific languages.

I could counter that support for parametric polymorphism is poor in OO langs as much as you claim support for ad-hoc polymorphism is poor in FP langs. (but I don't place much stock in any of the aforementioned claims outside of some kind of artifical, academic context)

Real-world problems that aren't an academic edge-cases will be supported by both FP and OO.

Multimethods give you ad-hoc polymorphism in an uptyped setting.

<comment><USER46> Parametric polymorphism is a concept that is orthogonal from the FP/OO distinction. You can define parametric polymorphism for parallel computation for example.

</comment></comment></comment></comment></comment></comment></comment><comment><USER49> They are orthogonal. Program in Scala and do both.

[http://www.scala-lang.org/](http://www.scala-lang.org/)

Free course(s):

"Functional Programming Principles in Scala" [https://www.coursera.org/learn/progfun1](https://www.coursera.org/learn/progfun1)

"Functional Program Design in Scala" [https://www.coursera.org/learn/progfun2](https://www.coursera.org/learn/progfun2)

(There are two more free courses in the "specialization" \- only the certificates and the capstone project cost money - original announcement [http://www.scala-lang.org/blog/2016/05/23/scala-moocs- specia...](http://www.scala-lang.org/blog/2016/05/23/scala-moocs- specialization-launched.html))

<comment><USER50> "Program in Scala" is just promotion, not an answer to the question. There are more than a few languages which advertise the possibility of using both OO and functional styles.

<comment><USER46> That's correct, but in which other ones is the integration so smooth as in Scala?

<comment><USER4> Swift, OCaml, F#, Common LISP?

<comment><USER51> No?

<comment><USER4> I am not a Scala programmer. Can you please give some examples of how Scala integrates OO and FP better than other languages?</comment></comment></comment></comment></comment></comment>