There are lots of merchant banks that allow you to accept cards. For very low volume transactions, you can get a 3% rate. If you're putting a lot through, most will offer you a better deal and they will compete with each other for your business.
A few years ago there was an article on Slashdot that looked at all of the costs. For very small businesses, cash was a clear winner. For large businesses, which are big enough to be paying less than the 3% that you pay for low-volume transaction rates accepting cards, credit cards were a clear winner. The cut-off point where cards were cheaper was much lower than I'd expect, and below the turnover for most shops and restaurants.
The term of the debt was that it was for a very short period and that it would be settled with a card. You may be able to argue that they are legally required to accept cash in payment for the debt, but if you are also not agreeing to the terms of the contract then they are free to add additional processing charges and may even simply refer you to a debt collection agency that can handle the cash payment.
Not universally true. For example, New York has a skills shortage for kitchen staff because they require at least a 6-month vocational training course and then end up making less than unqualified front-of-house staff (and in New York State it is legal to pool tips between front of house staff, but illegal to share tips with kitchen staff). A few of the upmarket restaurants have now started banning tips. This has been popular with their staff, because their income is now much more consistent (prior to that, it could vary hugely when, for example, you got a table of teetotalers or someone who orders the $200 bottle of wine, even if you give precisely the same service).
A Pizza Hut franchise near where I used to live made the mistake of doing this to some off-duty police officers. It didn't end well for either the employees responsible or the managers who were supposed to have prevented this.
Good suggestion, except don't use Bob'sFineEatery as the username. As Bruce Schneier said, if you give him schneier@example.com, he can probably guess the email that you use for Amazon. Instead, generate either a random ID and store who you've given it to, or use some term that's easy to map back to the original name but isn't obviously tied to it.
There are some places I'd like to see a merge. AppKit is showing its age and adding support for things like windows, drag and drop, and so on to UIKit and making the desktop a new UIKit mode (just as it already has separate tablet and phone personalities) would make it possible to share a lot more code between the two. Being able to have almost identical code bases for iOS and macOS, with just a few tweaks to the UI to make them more appropriate for the different UI models (rather than a load of code duplication for UIKit and AppKit versions of common UI elements) would be an improvement.
NeXT believed that they were complying with the GPL. They shipped GCC with the option to load a plugin that handled Objective-C. The Objective-C code was in a separate module. It never went to court, so it's not clear which way the license would have been interpreted, but this is exactly what nVidia does with the Linux kernel, so it's not clear that a court would have found that this actually was copyright infringement. NeXT decided that the code was not worth very much and throwing it over the wall was cheaper than going to court. If the code had been valuable, they'd have defended it and may or may not have been forced to release it.
As the maintainer of the GNUstep Objective-C runtime, I can attest to the fact that the code in GCC is of negative value. If the FSF had been forced to implement it from scratch, they'd have been better off (Iain Sandoe is now starting to clean it up, some decades later, and I wish him well). Meanwhile, I started hacking on clang and added an abstraction layer that makes it easy to support multiple runtimes. The Apple folks, including quite a lot of former NeXT employees back then, picked this up and helped us maintain something that made it easier for us to support a different implementation. Oh, and they also open sourced their runtime, though it's quite closely integrated with functionality that's only available on Darwin so it's not that interesting to anyone else.
These names are all pretty self explanatory. Outlook is a pun, as in 'look out, you're forced to work with Exchange!'. Excel is also pretty obvious. The ex- prefix means dead, and cells are the things that you find in spreadsheets: it's where data goes to die. Powerpoint refers to mains sockets, as in 'I would rather stick my fingers in a mains socket than watch another Powerpoint presentation'. Access is a credit card brand, and the name is intended to signify that you'll pay for putting your data in an Access database. Word is used in the singular to highlight the fact that it doesn't work so well with sentences or paragraphs.
Their stated reason for dropping XMPP support was spam. XMPP makes it possible to validate the server that a message is coming from, but it's still possible for a new XMPP server to pop up, send spam until it's blacklisted, and then shut down and restart with a new domain name and IP address. Within a walled-garden network, you can require some external identification for new users and rate limit them until other people have added them to their rosters and validated that they're probably useful. Within an open federated network, this is much harder (and, unlike email, if you block suspicious instant messages for a few hours until you've learned if the server is malicious, users get really grumpy).
None of the newer distributed IM systems have really done anything to tackle this problem either. You really need some form of distributed, anonymous, reputation system, but designing such a thing is really hard.
The problem with XMPP is fragmentation. The core protocol is an IETF standard, but it's very minimal (messages, presence notifications, basically nothing else, including how clients authenticate with servers). Everything else is handled via XEPs and for every feature there are 3-4 XEPs describing incompatible ways of providing it. Google did a pretty good job with Jingle, which provided file transfer and a way of setting up streams to use for video / voice, but clients all implement different file transfer mechanisms. I don't think I found a single pair of Android XMPP clients that could exchange files, for example. There are multiple mechanisms for publishing avatars. The last time I looked, the most widely supported one was vcard-temp, which involves setting an base64-encoded image in an XML encoding of a vcard that you publish inside your presence stanzas. This XEP was deprecated as soon as it was published because it had a bunch of well-known problems and was intended as a temporary stop-gap. The replacement was built on top of PEP (personal eventing via PubSub) which was, in turn, built on top of PubSub. The PubSub XEP is fiendishly complicated to implement and PEP adds even more complexity, so it was years between the standard being published and any clients or servers properly supporting it.
This last point really highlights the problem with the XMPP standards process. The IETF requires two interoperable implementations for an RFC to advance. The XMPP Foundation happily publishes standards-track XEPs with zero implementations. They never produced a reference implementation of a client library. Some newer open IM standards have learned from this mistake. For example, Tox provides a client library that is used by multiple clients and serves as a reference implementation. Unfortunately, it's not GPLv3, so anyone wanting to implement a non-GPL Tox client must reimplement the protocol (it's still better than no reference implementation though, and providing an incentive to implement a second client library may be good for the protocol in the long term).
Depends on the plan. I pay 2p per SMS and 1p/MB of data on a pre-pay plan, but if you're on a contract you typically get a bundled SMS allowance that's more than anyone who isn't a teenager can possibly use or unlimited on the less-cheap plans. I don't send more than a dozen SMS messages in a month, so paying 2p each cost me very much in aggregate (I typically spend under £1/month in total on my phone, which is less than the cheapest contracts with inclusive allowances). SMS is, per byte, very expensive. One SMS is 140 bytes, so I'm paying more than 14 times as much for SMS than data. That's gone down a lot - about 15 years ago, I was paying around £500/MB for SMS data, and a tiny fraction of that for IP data - but carriers are still milking SMS.
If you can't afford broadband, you can't afford a BT phone. We have their FTTP service, but are required by them to pay for a landline service that we don't even have a phone plugged into. Their line rental costs more than both of us pay for the mobile phones that we actually do use. If you actually make calls on the BT phone, it becomes even more expensive.
There's nothing that the Flash plugin can do that you can't do in HTML5 in a modern browser. The big problem with HTML5 is that Flash came with some really polished development tools, whereas HTML5 is still in its infancy in that regard.
That won't help you measure one of the hypothesised benefits of UBI: adjusting the balance of power between worker and employer. If a worker can always quit their job and continue to live, then that shifts the balance of power considerably. The predicted outcome is an increase in pay for low-skilled but unpleasant jobs (e.g. the folks that collect your rubbish and clean your toilets) and a push to automate more things where no one would take the job if they didn't have to work to live.
The GDP of the USA is around $60K per capita. Give everyone 0.1% of that and they'll each get $60, or $5/month. That's not enough to make a measurable difference in anyone's life (unless they're really, really close to starving already). Turn it up to a liveable amount but then turn it off periodically, and you don't remove the fear of losing a crappy job. Employers can still threaten unemployment, because even if you won't starve this year while you're receiving UBI, you will next year.
The fully-costed UBI proposals that I've seen include tax increases at higher rates and eliminates the tax-free personal allowance. You begin paying tax on all earned income. In the US, around 45% of all households are estimated to pay no income tax. With a UBI proposal, they'd still be net recipients, but they would be paying some money in income tax and so their impact on the budget would be less than you are calculating. Most people in well-paid skilled professions would see their income drop slightly, factoring in both their receipt of UBI and their increased income taxes. The last proposal I looked at for the UK suggested that I'd pay around 2-4% more tax (depending on how big the administrative savings from removing means-tested benefits were and a few other costs that were difficult to accurately predict) if we rolled out UBI, which seems like a pretty good deal considering the benefits.
Sweden , Danemark seem to work because these were very rich capitalist countries before they became solcialist
So you're saying that countries that follow the transition path that Marx outlined work, whereas ones that try to skip a step and jump straight from feudalism to communism don't? I'm sure Marx would be shocked to learn this!
So your argument is that life for you sucks and so life for everyone should suck? Like Opportunist, I have never been in that situation and have always been able to turn down paid work that didn't look interesting and have enough paid work that I enjoyed to live comfortably on. I have basically been able to use offers of payment to prioritise my list of things that I want to do: things that I want to do that people will pay me for get moved to the top of my to-do list. I could have made more money if I'd done things that I didn't want to do, but I've never had to chose between doing something that I didn't want to do for money and starving / being homeless / giving up activities that I enjoy.
So my attitude is similar to yours in one respect: I think everyone should have the opportunity to live like me. The difference is that I want to extend an opportunity to people who weren't as lucky as me, whereas you want to make sure that everyone suffers as much as you.
Why do we need a law when using Facebook or any of the other Social Media application and services are non-mandatory? Nobody is forced to publish the details of their lives on any of these services.
I would be completely happy if this were the case. I have never signed up to Facebook and never agreed to their T&Cs. As long as this means that Facebook does not collect any information about me, then that's completely fine. Unfortunately, that's not even slightly the case.
There's a lot missing from that story. For example:
The GCC Objective-C code was shockingly bad. It's about 10,000 lines of code in a single file doing everything from semantic analysis to code generation. It has no clean layering, so GCC still accepts different subsets of Objective-C syntax in C and C++ mode. It is full of comments that refer to pre-NeXT versions of Objective-C that the released code has never supported.
There are two parts to an Objective-C implementation, the compiler and the runtime. With ARC, the compiler is the more complex of the two, but back in 1988 the majority of the complexity was in the runtime. NeXT was not forced to release the code for their runtime, which made the compiler useless on non-NeXT platforms. Eventually other GCC contributors wrote a replacement runtime, but this was not quote compatible with the NeXT one and so the ugly GCC code was then full of 'if (next_runtime)' chunks.
By forcing NeXT to release the code, rather than persuading them to join the community, they burned any goodwill that existed. NeXT (and Apple) never imported the GNU changes into their GCC tree, so never got any of those 'if (next_runtime)' checks. This meant that new features of the language were supported by the Apple fork and were difficult to merge into upstream GCC. As a result, modern GCC supports a dialect of Objective-C circa 2005, and only gained support for that around 2010. And, because of aforementioned layering issues, it doesn't support most of these features in Objective-C++ mode.
In other words, if the GCC Objective-C story is a poster child for the success of the GPL (and for a long time, it was on the FSF web site) then the GPL is an abject failure.
For prototyping a language quickly, using a Packrat parser generator is far quicker, but generally requires building your own AST.
Pegmatite is designed for rapid prototyping and for teaching (where students are expected to add new language features in a couple of hours. It uses PEGs in an embedded DSL in C++. It doesn't do Packrat optimisation, because that makes it harder to debug (and by the time you need that kind of performance it's probably worth replacing it with a hand-written recursive-descent parser (which also makes helpful error messages easier to write). You can define AST node classes and declaratively associate grammar rules with AST nodes.
There are a couple of example languages in the same GitHub organisation that are about 1,000 lines of code each for a complete language with an LLVM-based JIT.
I don't necessarily need to run it myself, but for me to be willing to sign up, I need:
To use an identifier that I own and can port to another provider without their cooperation. For example, something based on a domain name that I own, as with email. A large number of email providers, for example, allow me to point my DNS records at their server and use them to handle my mail. This dramatically reduces lock-in, because if I don't like them I can just point the DNS records elsewhere.
To be able to extract all of my data in a standard format. Again, with email I can move between providers by just pointing an IMAP client (including a command-line tool like imapsync) at both and telling it to move my data.
To use a federated open protocol, so that I can communicate with users who do not use the same provider. Again, with email I can communicate with people who host their own service, people who use an employer-provided service, people who use a free service such as GMail or Hotmail, without any problems.
To be supported by multiple implementations. With a single implementation of a protocol, you have no guarantee that it's actually documented well enough for anyone else to use and you have no guarantee that it doesn't expose implementation details by accident. Equally importantly, if there's a single implementation then there's nothing stopping the developers from pushing the UI in a direction that I don't like, because there's nothing for me to switch to. Again, with email there are a load of different clients (native and web-based) that I can use, so if one annoys me then I can switch without losing any of my data.
Diaspora appears to be pretty close to this. The federation protocol is mostly sane and has a few implementations (though putting an extreme copyleft license on the reference implementation wasn't such a great idea), though the client-server part of the protocol doesn't seem to be very well documented or possible to support with different implementations. Ideally, I'd want to see a clean separation between client-server protocol and web UI, so the web interface is just that: an interface that talks to a back-end server as a separable component. Again, this improves competition because someone else can easily decide that they hate the UI, write a better one, and reuse all of the back-end code.
Oh, and in an ideal world it wouldn't involve PHP. Anywhere.
Facebook and Google don't (intentionally) sell your information, because if they sell it then someone else can offer services that currently only they can offer. Instead they offer services that use that information, which often end up leaking that information.
A friend of mine designed such a system for his PhD. It included a content-addressible storage system and any user could host their content in any cloud provider (or their own systems). As I recall, the cost was about $1-2/year, back in 2012 (cloud storage prices have gone down a lot since then).
I'm a bit surprised that someone like Amazon or Microsoft isn't pushing a social networking protocol with a reference implementation of the platform that's trivial to host in their cloud.
It an independent figure, but one that factors in the success:failure ratio. A lot of drug development goes nowhere, and a comparatively small but still quite substantial subset goes nowhere after fairly expensive clinical trials. If you can identify a compound that can treat or cure a disease immediately and just have to work out how to cheaply synthesise it and get it through FDA approval then it's a lot cheaper.
Slashdot Mirror
There are lots of merchant banks that allow you to accept cards. For very low volume transactions, you can get a 3% rate. If you're putting a lot through, most will offer you a better deal and they will compete with each other for your business.
A few years ago there was an article on Slashdot that looked at all of the costs. For very small businesses, cash was a clear winner. For large businesses, which are big enough to be paying less than the 3% that you pay for low-volume transaction rates accepting cards, credit cards were a clear winner. The cut-off point where cards were cheaper was much lower than I'd expect, and below the turnover for most shops and restaurants.
The term of the debt was that it was for a very short period and that it would be settled with a card. You may be able to argue that they are legally required to accept cash in payment for the debt, but if you are also not agreeing to the terms of the contract then they are free to add additional processing charges and may even simply refer you to a debt collection agency that can handle the cash payment.
Chefs get paid more
Not universally true. For example, New York has a skills shortage for kitchen staff because they require at least a 6-month vocational training course and then end up making less than unqualified front-of-house staff (and in New York State it is legal to pool tips between front of house staff, but illegal to share tips with kitchen staff). A few of the upmarket restaurants have now started banning tips. This has been popular with their staff, because their income is now much more consistent (prior to that, it could vary hugely when, for example, you got a table of teetotalers or someone who orders the $200 bottle of wine, even if you give precisely the same service).
A Pizza Hut franchise near where I used to live made the mistake of doing this to some off-duty police officers. It didn't end well for either the employees responsible or the managers who were supposed to have prevented this.
Good suggestion, except don't use Bob'sFineEatery as the username. As Bruce Schneier said, if you give him schneier@example.com, he can probably guess the email that you use for Amazon. Instead, generate either a random ID and store who you've given it to, or use some term that's easy to map back to the original name but isn't obviously tied to it.
There are some places I'd like to see a merge. AppKit is showing its age and adding support for things like windows, drag and drop, and so on to UIKit and making the desktop a new UIKit mode (just as it already has separate tablet and phone personalities) would make it possible to share a lot more code between the two. Being able to have almost identical code bases for iOS and macOS, with just a few tweaks to the UI to make them more appropriate for the different UI models (rather than a load of code duplication for UIKit and AppKit versions of common UI elements) would be an improvement.
NeXT believed that they were complying with the GPL. They shipped GCC with the option to load a plugin that handled Objective-C. The Objective-C code was in a separate module. It never went to court, so it's not clear which way the license would have been interpreted, but this is exactly what nVidia does with the Linux kernel, so it's not clear that a court would have found that this actually was copyright infringement. NeXT decided that the code was not worth very much and throwing it over the wall was cheaper than going to court. If the code had been valuable, they'd have defended it and may or may not have been forced to release it.
As the maintainer of the GNUstep Objective-C runtime, I can attest to the fact that the code in GCC is of negative value. If the FSF had been forced to implement it from scratch, they'd have been better off (Iain Sandoe is now starting to clean it up, some decades later, and I wish him well). Meanwhile, I started hacking on clang and added an abstraction layer that makes it easy to support multiple runtimes. The Apple folks, including quite a lot of former NeXT employees back then, picked this up and helped us maintain something that made it easier for us to support a different implementation. Oh, and they also open sourced their runtime, though it's quite closely integrated with functionality that's only available on Darwin so it's not that interesting to anyone else.
These names are all pretty self explanatory. Outlook is a pun, as in 'look out, you're forced to work with Exchange!'. Excel is also pretty obvious. The ex- prefix means dead, and cells are the things that you find in spreadsheets: it's where data goes to die. Powerpoint refers to mains sockets, as in 'I would rather stick my fingers in a mains socket than watch another Powerpoint presentation'. Access is a credit card brand, and the name is intended to signify that you'll pay for putting your data in an Access database. Word is used in the singular to highlight the fact that it doesn't work so well with sentences or paragraphs.
Their stated reason for dropping XMPP support was spam. XMPP makes it possible to validate the server that a message is coming from, but it's still possible for a new XMPP server to pop up, send spam until it's blacklisted, and then shut down and restart with a new domain name and IP address. Within a walled-garden network, you can require some external identification for new users and rate limit them until other people have added them to their rosters and validated that they're probably useful. Within an open federated network, this is much harder (and, unlike email, if you block suspicious instant messages for a few hours until you've learned if the server is malicious, users get really grumpy).
None of the newer distributed IM systems have really done anything to tackle this problem either. You really need some form of distributed, anonymous, reputation system, but designing such a thing is really hard.
The problem with XMPP is fragmentation. The core protocol is an IETF standard, but it's very minimal (messages, presence notifications, basically nothing else, including how clients authenticate with servers). Everything else is handled via XEPs and for every feature there are 3-4 XEPs describing incompatible ways of providing it. Google did a pretty good job with Jingle, which provided file transfer and a way of setting up streams to use for video / voice, but clients all implement different file transfer mechanisms. I don't think I found a single pair of Android XMPP clients that could exchange files, for example. There are multiple mechanisms for publishing avatars. The last time I looked, the most widely supported one was vcard-temp, which involves setting an base64-encoded image in an XML encoding of a vcard that you publish inside your presence stanzas. This XEP was deprecated as soon as it was published because it had a bunch of well-known problems and was intended as a temporary stop-gap. The replacement was built on top of PEP (personal eventing via PubSub) which was, in turn, built on top of PubSub. The PubSub XEP is fiendishly complicated to implement and PEP adds even more complexity, so it was years between the standard being published and any clients or servers properly supporting it.
This last point really highlights the problem with the XMPP standards process. The IETF requires two interoperable implementations for an RFC to advance. The XMPP Foundation happily publishes standards-track XEPs with zero implementations. They never produced a reference implementation of a client library. Some newer open IM standards have learned from this mistake. For example, Tox provides a client library that is used by multiple clients and serves as a reference implementation. Unfortunately, it's not GPLv3, so anyone wanting to implement a non-GPL Tox client must reimplement the protocol (it's still better than no reference implementation though, and providing an incentive to implement a second client library may be good for the protocol in the long term).
Depends on the plan. I pay 2p per SMS and 1p/MB of data on a pre-pay plan, but if you're on a contract you typically get a bundled SMS allowance that's more than anyone who isn't a teenager can possibly use or unlimited on the less-cheap plans. I don't send more than a dozen SMS messages in a month, so paying 2p each cost me very much in aggregate (I typically spend under £1/month in total on my phone, which is less than the cheapest contracts with inclusive allowances). SMS is, per byte, very expensive. One SMS is 140 bytes, so I'm paying more than 14 times as much for SMS than data. That's gone down a lot - about 15 years ago, I was paying around £500/MB for SMS data, and a tiny fraction of that for IP data - but carriers are still milking SMS.
If you can't afford broadband, you can't afford a BT phone. We have their FTTP service, but are required by them to pay for a landline service that we don't even have a phone plugged into. Their line rental costs more than both of us pay for the mobile phones that we actually do use. If you actually make calls on the BT phone, it becomes even more expensive.
There's nothing that the Flash plugin can do that you can't do in HTML5 in a modern browser. The big problem with HTML5 is that Flash came with some really polished development tools, whereas HTML5 is still in its infancy in that regard.
That won't help you measure one of the hypothesised benefits of UBI: adjusting the balance of power between worker and employer. If a worker can always quit their job and continue to live, then that shifts the balance of power considerably. The predicted outcome is an increase in pay for low-skilled but unpleasant jobs (e.g. the folks that collect your rubbish and clean your toilets) and a push to automate more things where no one would take the job if they didn't have to work to live.
The GDP of the USA is around $60K per capita. Give everyone 0.1% of that and they'll each get $60, or $5/month. That's not enough to make a measurable difference in anyone's life (unless they're really, really close to starving already). Turn it up to a liveable amount but then turn it off periodically, and you don't remove the fear of losing a crappy job. Employers can still threaten unemployment, because even if you won't starve this year while you're receiving UBI, you will next year.
The fully-costed UBI proposals that I've seen include tax increases at higher rates and eliminates the tax-free personal allowance. You begin paying tax on all earned income. In the US, around 45% of all households are estimated to pay no income tax. With a UBI proposal, they'd still be net recipients, but they would be paying some money in income tax and so their impact on the budget would be less than you are calculating. Most people in well-paid skilled professions would see their income drop slightly, factoring in both their receipt of UBI and their increased income taxes. The last proposal I looked at for the UK suggested that I'd pay around 2-4% more tax (depending on how big the administrative savings from removing means-tested benefits were and a few other costs that were difficult to accurately predict) if we rolled out UBI, which seems like a pretty good deal considering the benefits.
Sweden , Danemark seem to work because these were very rich capitalist countries before they became solcialist
So you're saying that countries that follow the transition path that Marx outlined work, whereas ones that try to skip a step and jump straight from feudalism to communism don't? I'm sure Marx would be shocked to learn this!
So your argument is that life for you sucks and so life for everyone should suck? Like Opportunist, I have never been in that situation and have always been able to turn down paid work that didn't look interesting and have enough paid work that I enjoyed to live comfortably on. I have basically been able to use offers of payment to prioritise my list of things that I want to do: things that I want to do that people will pay me for get moved to the top of my to-do list. I could have made more money if I'd done things that I didn't want to do, but I've never had to chose between doing something that I didn't want to do for money and starving / being homeless / giving up activities that I enjoy.
So my attitude is similar to yours in one respect: I think everyone should have the opportunity to live like me. The difference is that I want to extend an opportunity to people who weren't as lucky as me, whereas you want to make sure that everyone suffers as much as you.
Why do we need a law when using Facebook or any of the other Social Media application and services are non-mandatory? Nobody is forced to publish the details of their lives on any of these services.
I would be completely happy if this were the case. I have never signed up to Facebook and never agreed to their T&Cs. As long as this means that Facebook does not collect any information about me, then that's completely fine. Unfortunately, that's not even slightly the case.
The GCC Objective-C code was shockingly bad. It's about 10,000 lines of code in a single file doing everything from semantic analysis to code generation. It has no clean layering, so GCC still accepts different subsets of Objective-C syntax in C and C++ mode. It is full of comments that refer to pre-NeXT versions of Objective-C that the released code has never supported.
There are two parts to an Objective-C implementation, the compiler and the runtime. With ARC, the compiler is the more complex of the two, but back in 1988 the majority of the complexity was in the runtime. NeXT was not forced to release the code for their runtime, which made the compiler useless on non-NeXT platforms. Eventually other GCC contributors wrote a replacement runtime, but this was not quote compatible with the NeXT one and so the ugly GCC code was then full of 'if (next_runtime)' chunks.
By forcing NeXT to release the code, rather than persuading them to join the community, they burned any goodwill that existed. NeXT (and Apple) never imported the GNU changes into their GCC tree, so never got any of those 'if (next_runtime)' checks. This meant that new features of the language were supported by the Apple fork and were difficult to merge into upstream GCC. As a result, modern GCC supports a dialect of Objective-C circa 2005, and only gained support for that around 2010. And, because of aforementioned layering issues, it doesn't support most of these features in Objective-C++ mode.
In other words, if the GCC Objective-C story is a poster child for the success of the GPL (and for a long time, it was on the FSF web site) then the GPL is an abject failure.
For prototyping a language quickly, using a Packrat parser generator is far quicker, but generally requires building your own AST.
Pegmatite is designed for rapid prototyping and for teaching (where students are expected to add new language features in a couple of hours. It uses PEGs in an embedded DSL in C++. It doesn't do Packrat optimisation, because that makes it harder to debug (and by the time you need that kind of performance it's probably worth replacing it with a hand-written recursive-descent parser (which also makes helpful error messages easier to write). You can define AST node classes and declaratively associate grammar rules with AST nodes.
There are a couple of example languages in the same GitHub organisation that are about 1,000 lines of code each for a complete language with an LLVM-based JIT.
To use an identifier that I own and can port to another provider without their cooperation. For example, something based on a domain name that I own, as with email. A large number of email providers, for example, allow me to point my DNS records at their server and use them to handle my mail. This dramatically reduces lock-in, because if I don't like them I can just point the DNS records elsewhere.
To be able to extract all of my data in a standard format. Again, with email I can move between providers by just pointing an IMAP client (including a command-line tool like imapsync) at both and telling it to move my data.
To use a federated open protocol, so that I can communicate with users who do not use the same provider. Again, with email I can communicate with people who host their own service, people who use an employer-provided service, people who use a free service such as GMail or Hotmail, without any problems.
To be supported by multiple implementations. With a single implementation of a protocol, you have no guarantee that it's actually documented well enough for anyone else to use and you have no guarantee that it doesn't expose implementation details by accident. Equally importantly, if there's a single implementation then there's nothing stopping the developers from pushing the UI in a direction that I don't like, because there's nothing for me to switch to. Again, with email there are a load of different clients (native and web-based) that I can use, so if one annoys me then I can switch without losing any of my data.
Diaspora appears to be pretty close to this. The federation protocol is mostly sane and has a few implementations (though putting an extreme copyleft license on the reference implementation wasn't such a great idea), though the client-server part of the protocol doesn't seem to be very well documented or possible to support with different implementations. Ideally, I'd want to see a clean separation between client-server protocol and web UI, so the web interface is just that: an interface that talks to a back-end server as a separable component. Again, this improves competition because someone else can easily decide that they hate the UI, write a better one, and reuse all of the back-end code.
Oh, and in an ideal world it wouldn't involve PHP. Anywhere.
Facebook and Google don't (intentionally) sell your information, because if they sell it then someone else can offer services that currently only they can offer. Instead they offer services that use that information, which often end up leaking that information.
A friend of mine designed such a system for his PhD. It included a content-addressible storage system and any user could host their content in any cloud provider (or their own systems). As I recall, the cost was about $1-2/year, back in 2012 (cloud storage prices have gone down a lot since then).
I'm a bit surprised that someone like Amazon or Microsoft isn't pushing a social networking protocol with a reference implementation of the platform that's trivial to host in their cloud.
It an independent figure, but one that factors in the success:failure ratio. A lot of drug development goes nowhere, and a comparatively small but still quite substantial subset goes nowhere after fairly expensive clinical trials. If you can identify a compound that can treat or cure a disease immediately and just have to work out how to cheaply synthesise it and get it through FDA approval then it's a lot cheaper.