At that point they'd necessarily have some way to quantify dangerousity. There will be a ranking. Somewhere deep in the bowels of google, there will be a list, Top Ten most dangerous drivers. Google is about to get into the car insurance business.
Police and Government should be two different entities, but if you're living in a police state then you're probably right.
Otherwise, what Google could do is, say, record your dangerous driving (maybe that one time you were rushing a friend to hospital and ignored some speed limits). And then, every time a potential employer googled your name, they would see this "dangerous driver" notification. And you have no way of removing this, there's no statute of limitations, there's no way to correct it. For the rest of your life, that's the first result anyone sees when looking up who you are.
Well I thought that was pretty reasonable. But since you disagree, lets look at what is actually happening now.
The youngest MP for a few hundred years was elected the other day. Her name is "Mhairi Black". Google her name, and see what you find on the first page.
Now, what have Police Scotland been up to....The last thing I remember seeing was a complaint about their ridiculous policy of sending armed officers to events that clearly didn't require them. They apologised and gave assurances that armed units would only be sent out in response to specific incidents.
Or do you mean personal interaction with the police? Last time I saw our local policeman, it was because his young son was scared of dogs as a big dog had knocked him down while playing. We took our puppy round so he could pet him and get over his fear.
I'm not sure what lack of government oversight you think there is. Holyrood is under constant scrutiny, not least by those who'd like to see it abolished!
farfetched and unrealistic at the moment, but totally plausible: compile a list of destinations you visit on some sort of schedule, commit some physical crime along that path during a time you can be shown to be in the area, and frame you for it, potentially by including things like relevant search data, falsified emails... lots of possibilities here.
You'd want to get smarter, not dumber: taking into account the fact that the unpredictable (to the car behind) braking could in itself cause an accident, and calculating a best compromise to avoid both collisions, with priority to the more dangerous of the two (the fender-bender could be a great option if you avoid another car doing 50). I'd be surprised if their software doesn't support this kind of thing already.
What is the difference between allowing users to put custom JS on a subdomain, vs. someone just opening up the developer console and running whatever JS they like? Does JS loaded from the server have different privileges to JS entered at the console?
The difference is, I can put custom JS on my Github page and send you a link, when you open it you run code I authored.
Developer console is just me running code, and is also on any arbitrary domain on any site.
To date, software engineering has failed to deliver on one critical goal, which is why we are in this mess.
The world of software development needs to be divided in two -- the component creators, and the component assemblers.
To stick with the given analogy, component creators are the people inventing new kinds of plumbing: easier ways of connecting pipes, taps that don't ever drip. Component assemblers are the people fitting out bathrooms.
Creating new components is high-end engineering. It needs to happen far away from the day-to-day challenges of making a client happy.
To a large extent, this division is already present, but it doesn't go far enough. There has been amazing progress - nowadays we work on top of an incredible stack of technology that we don't have to re-invent, but so far we've not achieved the "last mile".
We'll know when we're there because component assembly (i.e. making something for a client) will start to look more like a trade.
Today, just getting a regular been-done-a-million-times-before database-driven website (or whatever), requires FAR too much low-level code. This, I think is what is meant here by "hand made". We should be snapping things together, and often we are, but suddenly you get to an awkward bit and you're back to forging a new kind of pipe joint that never existed before.
This is one of those classic ideas that's been around forever. It was more or less implied when the idea of "code reuse" became popular alongside object-oriented programming, I think. But I don't think it's ever really going to happen, because one of two things will happen. One is that you'll run into a set of requirements that no one has run into before, not because any of the requirements is unusual but because the space of possible requirements is very big if not infinite in size, and once you combine requirements that space increases exponentially. The other is that you'll run into a requirement that's simpler to implement directly than it is to write the glue code for all the components you could use to solve it. Both of these more or less happen already; the real question is what would surmount these problems.
> You'll run into a set of requirements that no one has run into before.
Inevitably. Which means you'll have to resort to "real programming" (as opposed to component assembly) for /that part/ of your project. I don't see this as a fundamental reason why component-assembly can never become viable. As we get better at creating flexible components, these situations will get less common, but they will never go away.
> you'll run into a requirement that's simpler to implement directly than it is to write the glue code for all the components you could use to solve it
100% this. For me this pretty much sums up why component-assembly isn't viable today. For all but the simplest components this turns out to be the case. (e.g. date-picker, file-uploader, or maybe something a bit bigger with /very/ fixed requirements, like a disqus comment trail). But jumping from this to "I don't think it's every going to happen" is overly pessimistic. The glue code is too hard to write? We need a better way to write glue code. That could be a fundamentally different type of language, or a fundamentally different conception of what we mean by "component".
(Aside: In my foolishness I am working on such things).
> Inevitably. Which means you'll have to resort to "real programming" (as opposed to component assembly) for /that part/ of your project.
It's not just that you'll run into one unique requirement; you might run into a unique combination of requirements, each of which already has proven solutions, but with no good way to glue it all together. That's the reason C programmers still sometimes write their own string handling or memory allocation code despite that stuff being literally in the standard library.
Writing general purpose software components is hard. If you're creating a product, you know what kind of component you need, and you don't really care about anyone else. If you're making a general purpose component, you have almost literally no possible way of even comprehending, much less fulfilling, all the requirements of every product that could potentially use your component.
You're always going to notice a difference between something that's been cobbled together out of spare parts and something that's been designed to fit an integral product vision. There's a reason we've been hearing about reusing program components for literally decades. I'm sure some chunk of the problem will be broken off and solved, some kind of standard solution to the CRUD app or something, but there are still going to be products out there that need real engineering, not just component assembly.
I think you're spot on. Just as the personal computer and GUI brought "computing" to the masses for their use and massive scale return on investment, we need to see the equivalent innovation in programming components. In other words just as it's now easier than ever to edit movies, write a paper, polish a photo: we need to see this ease of interface brought to programming.
I know hard core CS types will say that making programming easy for the masses will mean it won't be fast, it won't allow for the optimal algorithms. However computing speed and bandwidth is rising exponentially and countless applications for software do not need to be as optimal as possible.
In the future people who are not programmers but who are one step removed (e.g. okay with spreadsheets, SQL, some basic scripting when needed, visual programming like Labview, and who understand software architecture) will need to be able to do more complex things with computers, things that today only programmers can do.
We need to see the separation between programmer and the technical creative masses disappear a bit. Or at least as tablatom says, there has to be room for two types: those who build the tools for easy programming and those who do easy programming.
I'm just reading the book Flow-Based Programming (2nd Edition) by Paul Morrison.
I would say the main idea is to shift focus from control-flow to how data ("information packets") flow through a network of (black box) components and only use traditional control-flow style programming for the most simple, atomic components. The book presents some convincing examples from business programming but I think the idea should work very well for other areas than text processing, certainly for image manipulation or sound processing.
The split between component creators and component assemblers (application programmers) is highlighted in the book, I hate it how often I tend to slip from one role to the other in regular programming, maybe such an explicit split would help a lot (well, or certainly a lot of experience will ...)
It is not as simple as that, at least in the UK, and the fact that so many payment services seem to think it is explains why any UK business relying on them for payment processing is probably breaking the law.
There are all kinds of rules on disclosure of VAT registration details on invoices, sequential numbering of VAT invoices (across an entire company) for audit purposes, etc. Any payment system that doesn't integrate with other company procedures to meet these basic statutory obligations can't be sufficient.
I have an online business selling globally operating out of the EU and I now know more about VAT than I care too. I agree that the rules can get quite complex but as far as I can tell the payment processor does not need to be able to do anything special other than the ability to store/display the required information with each transaction (date, sequential invoice number, and VAT number in the case of a B2B transaction). You can just put that in a free format field (in PayPal for example), that's all they would need to add I think.
Sure it would be nice if they stored tax (multiple rates possible on one invoice!) and VAT numbers in a separate field, it would be even nicer if they validated the VAT numbers for you, or the buyers location, but it can all be done outside the payment processor.
Indeed, but you do need to be able to store and display that information in the right places.
As you say, technically invoices are supposed to record the VAT against each line item, because the rates can be different for different types of product/service.
Regarding the serialised invoice numbers, if you as the merchant are having to keep track of such things then you're still doing some of the tedious work so the value of outsourcing the billing process is lessened. I agree that it might be viable to record the extra information in a separate field for one-off transactions, if the billing service allows that kind of annotation on transactions and your systems can generate the appropriate number taking into account any other sales channels you're also using.
Even then, for subscription services that renew automatically, there would need to be some robust mechanism for the billing service to "claim" the next invoice number when they collect a scheduled payment. Perhaps some of these services could cope with this, but I have yet to see one personally whose documentation explains how to set it up using their APIs and callbacks. And if you get to the point where you have to handle scheduling regular subscription payments on your in-house system to account for this, again you're defeating the point of outsourcing the billing in the first place.
IME, it doesn't take long before you have to do so much in-house anyway that you might as well do the lot and save yourself a signficant overhead and the additional risk/dependency of involving another organisation in your billing process. This sort of processing is tedious but not rocket science, so if you can't just wrap everything up and shove it out to a specialist service, avoiding having to go near that sort of stuff in-house at all, I just don't see how the cost/benefit of these services is going to make them attractive to a business here in the UK. YMMV, of course.
Agreed, there are no services offering recurring payments (in Europe anyway) that do the whole thing, and I would love to outsource more if I could since billing is a nuisance that just detracts so much from the actual business. We currently use PayPal but that doesn't even allow you to pro-rate subscriptions when up- or downgrading. I noticed in the API docs that stripe.com at least has that one covered already.
Very nice. Another nitpick - I really like what Apple have been trying to do to in creating a UI affordance that says "this is a search box" - i.e. a text entry with round ends. I hope all the devs out there can join in and not use that appearance for regular text fields.