That kinds of make my point, when 1/2 hour is considered "super quick". Coming from Montreal, I indeed would be like "omg, so fast!". Someone in Mass would think that's crazy long. Someone from Boston's west end would be completely floored at the idea.
It depends where you live. Some places in the US have terrible wait times, some are good. Same with Canada. I'm just going from my personal experience, toronto/montreal, which is absolutely terrible. Seems like there's data on it too:
Even Health Canada's own statistics are pretty damn bad. If you're wealthy in Canada, the taxes you end up paying completely overwhelms the amount you'd pay in the US for private insurance even if you paid for it yourself (not your employer), and then you get crappy service in return.
Remember my original point though: The Canadian system is more fair and overall better, I'm not arguing that. What I was saying is, its not a surprise some people would be against it, because for many, it would mean paying way more to get way less. Human greed is a universal constant.
Google or not, that is simply my personal experience having lived in Canada 30 years and then moving out. My grandmother almost died as a critical heart surgery had been delayed and rescheduled for 9 times over a year. When I went traveling and had to get shots done, I had to turn to go to a travel clinic to get shots that should have been free because I couldn't find a doctor that would take me for 5+ months. Everyone I've known is basically terrified to go to the ER because of hour long wait times unless you're dying. My friend got into a motorcycle accident, showed up outside of peek hour with a broken arm and leg and had to wait 5 hours. Those are real, personal stories from Toronto and Montreal (Quebec is way way worse, so that's part of it). In Boston you can show up at the hospital with a pimple and you'll be seen immediately.
My point is simply that there's nowhere in the world right now with a good, working system. A few countries (Poland for example) have currently decent system, but my understanding is that its relatively new and isn't deep in debt yet (I didn't verify this, its just what Ive been told). Some used to be good (UK) until they ran out of money. Canada's has been terrible for the last 20 years or so (before that it was decent, but then all the cuts came in). The US' system only works for the rich. Germany's probably the closest to a healthy system, and its basically a private system with heavy government oversight (what the US tried to do, but its too late for them because of all the inefficiency).
The resources aren't there. There aren't enough people graduating from medical school to take care of everyone. Aside for a few exceptions, look at all the countries that have such systems. Either they're running themselves dry into impossibly debts, either only a small fraction of the population get access to the care their need (mainly the extreme cases) because there's not enough doctors.
Resources are limited, needs are not. Not everyone can be a doctor.
Its mainly that once upon a time, when costs were lower, it didn't matter too much. Then costs went up, and now going to a public system is rough, because the costs are escalated by the fact that employers foot the bills and are used to getting wtfpwned by impossibly high insurance costs, which then allow providers to keep charging more, etc. The Canadian government wouldn't be able to pay for public healthcare if they had to deal with US costs. And well, Canada is having more and more issues keeping up with the costs on their side too.
That said, being Canadian and having moved to the US, the US system works great if you have money, so its easy to see why a select privileged few wouldn't want to give it up. 2 weeks ago I woke up with a a terrible stomach ache. I walked up to MGH (one of the best hospitals in North America, and up there in the world too). There's so much staff that some of the nurses were bored waiting for patients. Total wait....lol, what wait? They walked up to me before I was in the door even though I was clearly not dying. Lab tests took minutes, some of the best doctors in the world saw me immediately, and all around everything went well. Need to see my doctor? I can get an appointment tomorrow.
In Toronto or Montreal, if you're dripping blood all over the place you MAY see someone in an hour, otherwise you may as well come back tomorrow. And to see your family doctor? If you even have one (good luck with that), you may see him in 6 months (all personal experience in those cities). The Canadian system works great....if your life is on the line. Otherwise, its inexistant, and you pay 40-50% tax for the privilege. The US system is terribly unfair, but for those on top its quite nice (which is morally wrong in so many ways...but there's a lot of people it doesn't stop)
The SQL BI stack is in line with others in term of "usuability". Its not as powerful as, let say, Informatica, but the deployment of packages and all that fun stuff is in line. There's reasons for these woes, but overall it works fine once you understand the best practices. The excel issue is because of how the excel drivers work. Not so much an issue with SSIS as it is with the drivers (you'll have that issue with virtually anything that interface with excel unless it isn't using the default driver). So the same solution applies. Not saying its good, just saying you'll have these issues with any similar tools. Competing spreadsheets have their share of bullshit. There's a FEW that are better on the market, but none are open source, and they're brutally expensive.
Visual Studio while decent fails miserably on large (I mean actually large. No, your 100k lines of code per main component/service isn't large.) while other IDEs do fine (IntelliJ for java comes to mind...Eclipse is a joke =P). I used to love Visual Studio, but lately I want to toss it out the window because of that issue. At least.NET itself is awesome.
Replicated with Linux, a few things like samba, and _a datacenter support contract_
The gap in price gets much lower when you compare apples to apples. If you just want a small cluster of windows servers for your business, you can get that for almost free (included support!)
Maybe you do need to know, maybe you don't. Maybe the object is being introspected, maybe its used to feed to a template engine, maybe its just converted from one format to another. All these things can be done in any language. Some languages make it easier than others.
Static languages make structured stuff easy and dynamic stuff hard(er). Dynamic languages make dynamic stuff easier. Shocker, i know.
Dynamic languages have better support for introspection, handling what happens when a property is missing, dealing with objects that aren't QUITE the same but "close enough", and deep nested dynamic data structures.
If you want to represent the same things in a static languages, you need things like arbitrarily nested dictionaries or very complex data structure with meta data. Thats why to handle a JSON string in Java or.NET, you'll need a JSON object framework. The parsing is the trivial part.
I also won't be able to use these JSON objects as real objects, with inheritance chains, polymorphic, etc, without a lot of work. If you're, let say, in javascript, and you parse a json string into an object with an appropriate prototype, you get all of it without needing to look at the data. Then your methods can do all the introspection to do the "magic".
That, again, comes in handy when dealing with object representations of arbitrary UI elements, and thats not limited to the web (WPF, Cocoa, or any other UI framework that use resource files of some kind to represent widgets).
So let say I only care about a specific part of my UI object tree... but I don't know -where- in my UI that part is. It could be arbitrarily nested, it could be dynamically added, IT COULD BY ADDED VIA A DIFFERENT PROGRAMMING LANGUAGE AT RUNTIME... It could be skinned with mixins.... You can deal with that in a static language (again, all the static languages UI frameworks do it). Its just a god damn clusterfuck.
Another example is invoking APIs written in a functional static programming language from a non-functional one. You can't just "serialize the part you care about" when you're dealing with actual code as opposed to serialized stuff. Then you end up with a mess of nested generics (or whatever the interface between the two languages look like). Not fun.
Don't get me wrong. These are very small subset of requirements, but when you hit them, reflection, attributes or meta programming is just not cutting it anymore. For everything else, static languages ftw.
I'm a static language guy myself, but its important to keep in mind that different problems have different solutions.
Doing heavy image processing or transnational operations, number crunching, I/O with third party APIs, etc? Yeah, static languages are probably better.
Doing prototyping, or UI intensive work? Most UI frameworks suck, but the ones designed for static languages generally suck more, because some stuff just can't be done (well), so they have to rely on data binding expressions, strings, etc, that are out control of the language. At least dynamic languages deal with those like they deal with everything else and have them as first class concepts.
Case in point: an arbitrary JSON string, in a dynamic language, can be converted to any standard object without needing to know what it will look like ahead of time. In a static language, you either need a predesigned contract, or you need a mess of a data structure full of strings that won't be statically checked, so you're back at square one. These type of use cases are horribly common in UI.
Won't change much. Even the "real theory" is half assed except in a select few colleges, usually (but not always) the high end ones. Then the professors that are good at the theory are usually impossibly terrible at the engineering aspect but still pass on their words as laws.
The ecosystem is a big deal. If we're talking financial apps, the required ecosystem to interop in the distributed environment are all off the shelf. Doing SWIFT or SOAP in C++ is totally doable and there's plenty of open source or not so open source frameworks out there, but its "awkward" on the best of days (and those things suck no matter what, so you really don't want to make them suck worse).
Also, the only real bottleneck is these type of applications is I/O (database, file system, and network). The language is almost irrelevant. You do have to pay attention to the algorithms, but beyond that, it could be in VB6 for all you care.
I used to work for one of the "top 3" big financials, and all major languages were used in some fashion, C, C++, Python, Java, C#, F# (!!), Perl, whatever. They were always selected due to the ecosystem and total cost of ownership analysis related to what tools we'd use. Performance rarely came into consideration because the difference was insignificant for these scenarios. And those were GIGANTIC distributed systems with thousands of different physically separated services and where a difference of 0.001 second in the time it took for something to go through all of them was worthy of waking up 50 people at 3 in the morning.
Java was the most common language because it had the intersection between distributed system frameworks (.NET actually is better for this in audited, "standard" environment ironically...it has better support for some of the open standard protocols than what the open source community spit out to this day...) and being able to cheaply scale horizontally (whoops,.NET just got kicked in the balls =P).
That's it. If you can do these kind of things in C++ faster than in Java (or.NET, or whatever), then you don't know how to use the 2 languages equally. Talk to someone who's done REAL, similar complexity integration projects for 5-10 years in each of those, and they'll laugh at you for even hinting you could do it at the same speed in C++. Again, thats for THIS PARTICULAR TYPE OF PROBLEM. Making a game, an office suite, a browser or a rendering engine would be a totally different story.
Thats what Im saying. You have a format riddled with DRM and it succeeded just fine. The person I replied to seem to imply that a DRMed format would be dead on arrival.
If your company is of significant size, you still put a huge amount of trust in SOMEONE SOMEWHERE that you shouldn't. If shit happens at a third party you can sue a large entity. If one of your own employees screw you over, you can only sue an individual that won't be able to cough up any kind of reasonable damage settlement.
Thats why people outsource payroll, employee performance evaluations and all that other crap.
it can still be useful: I have a smart tv, and it has an "app store" with quite a few more obscure video streaming service, not just the big ones like netflix and hulu.
It, however, doesn't support Google Video. And while it supports Amazon Video, that has pretty shitty support on Android if you don't use a Kindle Fire.
Yeah yeah, DRM evil blah blah, but if you WANT to use the same "evil" service on both devices, this helps a lot.
The boxes better be big if you go look weekly. I have a fairly large mailbox, and if i wait a full week to pick mail up, because of all the trash mail, my REAL mail barely fits or gets damaged as the mailman squish it in the box. So i have to go every 2 days or so.
The issue is that the basic theory, algorithms, oop, and everything the languages have in common is the trivial stuff that can be outsourced. The differences is where things get interesting. They look insignificant until entire system designs revolve around them.
Of course, currently these developers are in such high demand that no one cares. Java shops hire.NET devs,.NET shops hire Java devs, and you end up with a clusterfuck of people ignoring edge cases of the platform.
Its not so much a spike as a steady (insane) increase month after month.
Its been going on for a few years now, and it just keeps on getting more and more ridiculous, with employers offering crazier sign on bonuses, vacation packages, and better conditions every day to outbid each other.
I for one, am not complaining. I just hope it lasts until I'm done paying my mortgage.
The problem wasn't looked at more seriously because people spent years blaming it on the wrong thing. Now that scientists don't have to waste resources proving it isn't vaccines doing it, they can actually study the problem for real.
And windows 8's release was timed for the rise of tablets.
A lot of people are buying tablets over lap-tops, which had replaced a lot of desktops. And its all happening now. I already have 2 mobile devices for every desktop/laptop in the house... half of those would have been lap-tops if not for tablets. I'm not special.
XML may be an over engineered piece of crap, but while JSON isn't perfect, its pretty darn simple and "just works", with very few gotchas... REST is just "use http the way it was designed to be used and not one bit more".
Slashdot Mirror
That kinds of make my point, when 1/2 hour is considered "super quick". Coming from Montreal, I indeed would be like "omg, so fast!". Someone in Mass would think that's crazy long. Someone from Boston's west end would be completely floored at the idea.
It depends where you live. Some places in the US have terrible wait times, some are good. Same with Canada. I'm just going from my personal experience, toronto/montreal, which is absolutely terrible. Seems like there's data on it too:
http://en.wikipedia.org/wiki/Comparison_of_the_health_care_systems_in_Canada_and_the_United_States#Wait_times
Even Health Canada's own statistics are pretty damn bad. If you're wealthy in Canada, the taxes you end up paying completely overwhelms the amount you'd pay in the US for private insurance even if you paid for it yourself (not your employer), and then you get crappy service in return.
Remember my original point though: The Canadian system is more fair and overall better, I'm not arguing that. What I was saying is, its not a surprise some people would be against it, because for many, it would mean paying way more to get way less. Human greed is a universal constant.
Google or not, that is simply my personal experience having lived in Canada 30 years and then moving out. My grandmother almost died as a critical heart surgery had been delayed and rescheduled for 9 times over a year. When I went traveling and had to get shots done, I had to turn to go to a travel clinic to get shots that should have been free because I couldn't find a doctor that would take me for 5+ months. Everyone I've known is basically terrified to go to the ER because of hour long wait times unless you're dying. My friend got into a motorcycle accident, showed up outside of peek hour with a broken arm and leg and had to wait 5 hours. Those are real, personal stories from Toronto and Montreal (Quebec is way way worse, so that's part of it). In Boston you can show up at the hospital with a pimple and you'll be seen immediately.
My point is simply that there's nowhere in the world right now with a good, working system. A few countries (Poland for example) have currently decent system, but my understanding is that its relatively new and isn't deep in debt yet (I didn't verify this, its just what Ive been told). Some used to be good (UK) until they ran out of money. Canada's has been terrible for the last 20 years or so (before that it was decent, but then all the cuts came in). The US' system only works for the rich. Germany's probably the closest to a healthy system, and its basically a private system with heavy government oversight (what the US tried to do, but its too late for them because of all the inefficiency).
The resources aren't there. There aren't enough people graduating from medical school to take care of everyone. Aside for a few exceptions, look at all the countries that have such systems. Either they're running themselves dry into impossibly debts, either only a small fraction of the population get access to the care their need (mainly the extreme cases) because there's not enough doctors.
Resources are limited, needs are not. Not everyone can be a doctor.
Its mainly that once upon a time, when costs were lower, it didn't matter too much. Then costs went up, and now going to a public system is rough, because the costs are escalated by the fact that employers foot the bills and are used to getting wtfpwned by impossibly high insurance costs, which then allow providers to keep charging more, etc. The Canadian government wouldn't be able to pay for public healthcare if they had to deal with US costs. And well, Canada is having more and more issues keeping up with the costs on their side too.
That said, being Canadian and having moved to the US, the US system works great if you have money, so its easy to see why a select privileged few wouldn't want to give it up. 2 weeks ago I woke up with a a terrible stomach ache. I walked up to MGH (one of the best hospitals in North America, and up there in the world too). There's so much staff that some of the nurses were bored waiting for patients. Total wait....lol, what wait? They walked up to me before I was in the door even though I was clearly not dying. Lab tests took minutes, some of the best doctors in the world saw me immediately, and all around everything went well. Need to see my doctor? I can get an appointment tomorrow.
In Toronto or Montreal, if you're dripping blood all over the place you MAY see someone in an hour, otherwise you may as well come back tomorrow. And to see your family doctor? If you even have one (good luck with that), you may see him in 6 months (all personal experience in those cities). The Canadian system works great....if your life is on the line. Otherwise, its inexistant, and you pay 40-50% tax for the privilege. The US system is terribly unfair, but for those on top its quite nice (which is morally wrong in so many ways...but there's a lot of people it doesn't stop)
The SQL BI stack is in line with others in term of "usuability". Its not as powerful as, let say, Informatica, but the deployment of packages and all that fun stuff is in line. There's reasons for these woes, but overall it works fine once you understand the best practices. The excel issue is because of how the excel drivers work. Not so much an issue with SSIS as it is with the drivers (you'll have that issue with virtually anything that interface with excel unless it isn't using the default driver). So the same solution applies. Not saying its good, just saying you'll have these issues with any similar tools. Competing spreadsheets have their share of bullshit. There's a FEW that are better on the market, but none are open source, and they're brutally expensive.
Visual Studio while decent fails miserably on large (I mean actually large. No, your 100k lines of code per main component/service isn't large.) while other IDEs do fine (IntelliJ for java comes to mind...Eclipse is a joke =P). I used to love Visual Studio, but lately I want to toss it out the window because of that issue. At least .NET itself is awesome.
Replicated with Linux, a few things like samba, and _a datacenter support contract_
The gap in price gets much lower when you compare apples to apples. If you just want a small cluster of windows servers for your business, you can get that for almost free (included support!)
Maybe you do need to know, maybe you don't. Maybe the object is being introspected, maybe its used to feed to a template engine, maybe its just converted from one format to another. All these things can be done in any language. Some languages make it easier than others.
Static languages make structured stuff easy and dynamic stuff hard(er). Dynamic languages make dynamic stuff easier. Shocker, i know.
Dynamic languages have better support for introspection, handling what happens when a property is missing, dealing with objects that aren't QUITE the same but "close enough", and deep nested dynamic data structures.
If you want to represent the same things in a static languages, you need things like arbitrarily nested dictionaries or very complex data structure with meta data. Thats why to handle a JSON string in Java or .NET, you'll need a JSON object framework. The parsing is the trivial part.
I also won't be able to use these JSON objects as real objects, with inheritance chains, polymorphic, etc, without a lot of work. If you're, let say, in javascript, and you parse a json string into an object with an appropriate prototype, you get all of it without needing to look at the data. Then your methods can do all the introspection to do the "magic".
That, again, comes in handy when dealing with object representations of arbitrary UI elements, and thats not limited to the web (WPF, Cocoa, or any other UI framework that use resource files of some kind to represent widgets).
So let say I only care about a specific part of my UI object tree... but I don't know -where- in my UI that part is. It could be arbitrarily nested, it could be dynamically added, IT COULD BY ADDED VIA A DIFFERENT PROGRAMMING LANGUAGE AT RUNTIME... It could be skinned with mixins.... You can deal with that in a static language (again, all the static languages UI frameworks do it). Its just a god damn clusterfuck.
Another example is invoking APIs written in a functional static programming language from a non-functional one. You can't just "serialize the part you care about" when you're dealing with actual code as opposed to serialized stuff. Then you end up with a mess of nested generics (or whatever the interface between the two languages look like). Not fun.
Don't get me wrong. These are very small subset of requirements, but when you hit them, reflection, attributes or meta programming is just not cutting it anymore. For everything else, static languages ftw.
I'm a static language guy myself, but its important to keep in mind that different problems have different solutions.
Doing heavy image processing or transnational operations, number crunching, I/O with third party APIs, etc? Yeah, static languages are probably better.
Doing prototyping, or UI intensive work? Most UI frameworks suck, but the ones designed for static languages generally suck more, because some stuff just can't be done (well), so they have to rely on data binding expressions, strings, etc, that are out control of the language. At least dynamic languages deal with those like they deal with everything else and have them as first class concepts.
Case in point: an arbitrary JSON string, in a dynamic language, can be converted to any standard object without needing to know what it will look like ahead of time. In a static language, you either need a predesigned contract, or you need a mess of a data structure full of strings that won't be statically checked, so you're back at square one. These type of use cases are horribly common in UI.
Won't change much. Even the "real theory" is half assed except in a select few colleges, usually (but not always) the high end ones. Then the professors that are good at the theory are usually impossibly terrible at the engineering aspect but still pass on their words as laws.
Its really an awkward situation.
The ecosystem is a big deal. If we're talking financial apps, the required ecosystem to interop in the distributed environment are all off the shelf. Doing SWIFT or SOAP in C++ is totally doable and there's plenty of open source or not so open source frameworks out there, but its "awkward" on the best of days (and those things suck no matter what, so you really don't want to make them suck worse).
Also, the only real bottleneck is these type of applications is I/O (database, file system, and network). The language is almost irrelevant. You do have to pay attention to the algorithms, but beyond that, it could be in VB6 for all you care.
I used to work for one of the "top 3" big financials, and all major languages were used in some fashion, C, C++, Python, Java, C#, F# (!!), Perl, whatever. They were always selected due to the ecosystem and total cost of ownership analysis related to what tools we'd use. Performance rarely came into consideration because the difference was insignificant for these scenarios. And those were GIGANTIC distributed systems with thousands of different physically separated services and where a difference of 0.001 second in the time it took for something to go through all of them was worthy of waking up 50 people at 3 in the morning.
Java was the most common language because it had the intersection between distributed system frameworks (.NET actually is better for this in audited, "standard" environment ironically...it has better support for some of the open standard protocols than what the open source community spit out to this day...) and being able to cheaply scale horizontally (whoops, .NET just got kicked in the balls =P).
That's it. If you can do these kind of things in C++ faster than in Java (or .NET, or whatever), then you don't know how to use the 2 languages equally. Talk to someone who's done REAL, similar complexity integration projects for 5-10 years in each of those, and they'll laugh at you for even hinting you could do it at the same speed in C++. Again, thats for THIS PARTICULAR TYPE OF PROBLEM. Making a game, an office suite, a browser or a rendering engine would be a totally different story.
Thats what Im saying. You have a format riddled with DRM and it succeeded just fine. The person I replied to seem to imply that a DRMed format would be dead on arrival.
Unfortunately that describes Blu Ray, and that, also unfortunately, worked out just fine.
If your company is of significant size, you still put a huge amount of trust in SOMEONE SOMEWHERE that you shouldn't. If shit happens at a third party you can sue a large entity. If one of your own employees screw you over, you can only sue an individual that won't be able to cough up any kind of reasonable damage settlement.
Thats why people outsource payroll, employee performance evaluations and all that other crap.
TVs with all the bells and whistles aren't all that expensive anymore, unless you want a 60+ inch or something and do a bit of research.
it can still be useful: I have a smart tv, and it has an "app store" with quite a few more obscure video streaming service, not just the big ones like netflix and hulu.
It, however, doesn't support Google Video. And while it supports Amazon Video, that has pretty shitty support on Android if you don't use a Kindle Fire.
Yeah yeah, DRM evil blah blah, but if you WANT to use the same "evil" service on both devices, this helps a lot.
You do know that by "master key" they just mean the private secret for certificates right?
The boxes better be big if you go look weekly. I have a fairly large mailbox, and if i wait a full week to pick mail up, because of all the trash mail, my REAL mail barely fits or gets damaged as the mailman squish it in the box. So i have to go every 2 days or so.
That's gonna be annoying as hell.
The issue is that the basic theory, algorithms, oop, and everything the languages have in common is the trivial stuff that can be outsourced. The differences is where things get interesting. They look insignificant until entire system designs revolve around them.
Of course, currently these developers are in such high demand that no one cares. Java shops hire .NET devs, .NET shops hire Java devs, and you end up with a clusterfuck of people ignoring edge cases of the platform.
Its not so much a spike as a steady (insane) increase month after month.
Its been going on for a few years now, and it just keeps on getting more and more ridiculous, with employers offering crazier sign on bonuses, vacation packages, and better conditions every day to outbid each other.
I for one, am not complaining. I just hope it lasts until I'm done paying my mortgage.
The problem wasn't looked at more seriously because people spent years blaming it on the wrong thing. Now that scientists don't have to waste resources proving it isn't vaccines doing it, they can actually study the problem for real.
And windows 8's release was timed for the rise of tablets.
A lot of people are buying tablets over lap-tops, which had replaced a lot of desktops. And its all happening now. I already have 2 mobile devices for every desktop/laptop in the house... half of those would have been lap-tops if not for tablets. I'm not special.
Probably all of these answers, but in the end, one thing we know for sure: if you paid the debt today, it would be back tomorrow.
XML may be an over engineered piece of crap, but while JSON isn't perfect, its pretty darn simple and "just works", with very few gotchas... REST is just "use http the way it was designed to be used and not one bit more".
Not too sure where the problem is.