Actually, that is one of the changes I really like.
You can, of course, reverse it back to the old behaviour in about 10 seconds in System Preferences, but when using a trackpad (I have the big desktop Apple trackpad on my iMac) you quickly get used to the new way, since it is exactly the same way the interface works on touch screens.
It was certainly a shock to a lot of people that it swapped over to the default in Lion.
FWIW I prefer the old behaviour when using a scroll wheel mouse, since I'm so used to it, and the paradigm fits "scroll down, window moves down" but the new way when using a trackpad: "move finger down, mimics putting fingers onto a sheet of paper so it moves with your fingers" (rather than moving the wind you're viewing through).
This change, however, is slightly outside the discussion since it's something you can set with a preference. The UI changes to iCal and Address Book are fixed.
And railways weren't designed around interchangeable standards (rails, widths, couplers, even power systems), but that doesn't mean it's not a good idea to occasionally make some parts of it obsolete.
I know what you mean, re: legacy. I use a piece of software that runs a UV/Vis spectrometer that is hardcoded to 8+3 uppercase only filenames and has extremely precarious existence on the Windows XP system it runs on (even slight perturbations can bring it all down). It worked fine when it was running on a Win95 system, but then was somewhat less stable on XP (maybe they changed something wrt supporting 16 bit apps), so the choice when the machine gives up is either keep an old copy of XP around and hope it will run on whatever can be cobbled together at the time (probably not difficult, but then you have network issues to deal with - everything else is moving to 7, so at some point the XP boxes will have to either upgrade or be dropped off the network, for policy rather that technical reasons).
This wouldn't be a problem if the software wasn't originally designed for windows 3.1.
Apple, on the whole, make very functional UIs but just occasionally they mess up their good work - the rework of iCal is just one of them. I mean, it still does the job and so and and is pretty intuitive, but now if I want to make a new event that's not on my default calendar I have to pop open the menu and click, rather than simply clicking (or seeing at a glance what calendar I have selected already).
I've taken to just making events in the default and switching them to the correct calendar when I'm editing the details.
FWIW regarding the Ribbon, I think it gets a lot of hate for being a new way to use Office, when everyone had already hardcoded the old, crappy way into their minds. I know familiarity can hide many ills, but the love and devotion for the old interface is quite bemusing.
Not every car company is like the US ones. Renault is doing just fine. This is just the logical extension of selling your car with an iPod/USB interface.
It's a different API, but it doesn't mean you have to throw out all your old C.
And yes, it took time to move things - the ten years Apple kept Carbon around after they indicated it was deprecated certainly speak to that. If it takes you 10 years to update your code for Cocoa then I guess you'll just be keeping Snow Leopard around until someone else comes along with a Cocoa version of whatever it is your code does.
I'm aware that transitions to a new API are not as simple as a quick alteration (depending on complexity). Don't mistake my lack of specifically defining the difficulties for a belief that it's trivial.
No, of course not (eyeroll), they just had the Classic environment that was essentially an OS 9 VM (not exactly, but for all intents and purposes, that is the function it served) for years after OS X was released (worked on all PPC Macs up to 10.4, finally ended with the release of Leopard in 2007).
They knew that OS 9 was pretty stone age as far as code went (I mean, just look at the memory model), so at some point you just have to call time - for Apple that was *long* after OS X had been the main OS.
If you had an end user system that was "reliable, consistent and remain unchanged for many years" and relied on the Carbon API then it would have worked from OS X's release ten years ago right up to Lion's release 3 months ago (assuming you updated OS X every time there was a new version, not that you have to even do that). I'd say that was "many years" of unchanging stability.
I'm not arguing that backwards compatibility is bad, or that everyone should jump on the "hot new thing" at every opportunity, just that things do change over time, and it's hard to argue that Apple hasn't been giving people fair warning about deprecating old APIs or cutting people off when they changed architectures.
Right, I understand that backwards compatibility matters, and that you're arguing that Apple *doesn't* care about that, despite the clar evidence to the contrary - ten years of support for a deprecated API, extensive support for Classic (OS 9 apps) long into the life of OS X, strong support and tools to facilitate the changes in architecture (68k > PPC, PPC > x86), running with Universal binaries for a long time.
You're trying to argue a position that simply isn't supported by the evidence.
So, Apple occasionally phases out APIs that were originally introduced in OS 9, and gives a decade of warning while keeping them in OS X - I'm failing to see how this demonstrates that they don't believe backwards compatibility matters. At some point you have to get rid of the outdated code. Just look at the mess Windows was left in because they *didn't* do that.
DISCLAIMER: I'm not arguing that all old code is outdated and needs to be replaced, but some pieces of it do.
This is not just related to Apple (although feel free to just dismiss me out of hand by calling me a fanboy if you think it makes your argument stronger), this applies to any non-static codebase. Some things stay the same, some things get improved over time.
Do you think that OS X should have kept OS 9's memory model? I mean, you shouldn't have to change your code, right?
Come on, you're arguing that ten years is too short of a time span?
So far Apple has not deprecated Cocoa, so going by their past history with Carbon I'd say you have approximately a decade to make some changes to your code if they say it's deprecated tomorrow.
You say there's no reason to have to rewrite your code, except that it's been ordained by Apple. So, your argument is that once you've done it once that it should be forever supported?
I'll let Microsoft know it's cool to bring back ActiveX, or that ALL code written on Linux systems 10 years ago should run perfectly *especially* between kernel versions. Nothing is ever allowed to be replaced with a different way of doing things.
So, out of interest, what "more stable" (I assume you mean it turns over its APIs less frequently than every decade) platform have you moved to?
Seriously, you're arguing like Apple just rocked up one day and told you Carbon was now gone and your defence is "wah wah! I shouldn't have to rewrite this code! I wrote it fine 10 years ago!".
Call on line 2 for you, it's the whaaaaaaaaaaambulance.
"every few years" is being disingenuous. Here in the "real world" we like to debate using accurate language.
Carbon was the state of the art, so to speak, in OS 8.6 (and released before then). It was finally killed off in Lion (and strongly limited during the push into 64 bit with Snow Leopard).
To say that, if your app relied on the Carbon API, that Apple was "forcing you to rewrite your code every few years" is to just be laughably dishonest. It was in use on the Mac (in the current latest OS version) since 1997 to 2011 - that's hardly a rewrite "every few years" - that's longer than the entire lifetime of OS X itself (not including its time as a NeXT product).
Cocoa was introduced with OS X and worked alongside Carbon for many years until finally taking over as the sole player in mid 2011 (and slightly earlier in Snow Leopard for 64 bit apps, it was still there just in 32 bit only).
If you can't manage to alter your code to transition to Cocoa in the TEN YEARS that OS X has been around (and the same amount of time you've known that Carbon was deprecated) and you're whining that Apple is making it hard for you then you need to get a different fucking job. Perhaps something with a little less "time pressure" like Bonsai tree gardener or continental plate drift measurer or something. I know ten years is barely enough time to make changes to your code.
I am of course, assuming that your code existed on the Mac in OS 9. If it started its life on OS X and you still used Carbon then... well, I return to my point about getting a different job. Clearly reading the documentation is too challenging.
Porsche doesn't sell pickup trucks, and they seem to be doing fine - would they be doing better if they made a pickup? (DISCLAIMER: not trying to claim that Apple is Porsche, I just picked a company that makes something for a particular market segment but not another).
We're constantly told on here that "Apple has no business in enterprise" and if the Xserve told them anything, I guess it was that they were right - they simply didn't sell. Maybe they'll try again later if iOS makes more inroads, but it's not hurting them being out of that sector - in fact, it is costing them less by staying out of it.
Carbon was from the OS 9 days - it needed to die, and it was deprecated really early in OS X's life. Apple said "it's still in here, but work away from it because eventually it will be removed".
They gave everyone *years* to move away from Carbon. It's not like they just whisked it out of the OS overnight with the release of Lion.
Same thing with the switch from 68k to PPC and then again to x86. They bent over backwards to keep the backwards compatibility to smooth the transition in each case but said to developers "eventually this stuff is going away".
People got pissy because they had software that relied on Carbon, or was PPC only etc and whined that the support was going away after the very long period they had to update it. This is what happens when you rely on transitional elements and *already marked deprecated* libraries that were there to make moving to the more modern libraries and architectures more fluid.
They've certainly had some foolish moves (like removing backwards compatibility in Final Cut X, while simultaneously withdrawing Final Cut Studio from sale) and various other things, but it's not like they're just yanking things left and right and saying "surprise! too bad!"
Also, how are we quantifying "do better" in the phrase "Apple would do better if... [insert opinion]". They aren't short of cash, their products are selling as fast as they can make them (with some notable exceptions), their customer satisfaction results consistently poll very high, they're growing marketshare in the PC arena (bucking the general trend of PC makers), they're growing in the mobile space (despite very healthy competition from multiple Android vendors). How else can they "do better"?
The only thing they seem to be missing is the slashdot geek vote, but I'm not sure that's terribly troubling to them.
What the hell are the mods smoking and where can I get some?
Spend any time on Google and look at the vast swathes of evidence that socialised healthcare systems are not only *at least* twice as cheap in terms of GDP per capita than the US system, but that they're affordable and a massive boon to the countries that have them (that would be every developed nation except the US).
Sure, nothing is perfect - the UK's system needs some serious TLC after an 18 year stretch starting in the 80s under a Tory government that wanted to kill it but without committing political suicide, so they let it drown in neglect - something it is still recovering from, along with further management gaffes in the 2000's, but overall there's plenty of data on all the countries that run socialised healthcare systems that it works well and it works affordably.
I love many things about the US (I have lived there), but your backwards healthcare system that is designed almost exclusively for the profit of insurance and medical companies is not one of them. The sooner you move to a single payer system (with private insurance still available, just like in the UK, for those who can afford to choose it if they want) the better you'll all be. It'll save you money too.
What Apple box is marked up over 100%? I'm very curious.
Also, my Linux box cost more than my Apple box. So, the Linux box must have been marked up more than 100% too? I'm so confused! It must be my sheeple brain! (DISCLAIMER: I am aware of the presence of the word "usually" in your comment, but I am going for a touch of facetiousness here to keep it light).
And they didn't sue HTC over hardware design and interface style, there was a lawsuit involving a specific touch patent. There was nothing about design in it at all, other than the multitouch issue - by the standards of the Samsung debacle, it was very narrow.
Put it this way, where are all the Apple lawsuits seeking to prevent sales of anything *other* than Samsung Galaxy line products?
I mean, I'm certainly not apologetic - as to whether I classify as a bona fide Slashdot Certified (tm) Apple fanboy, I'm not so sure. I mean, I have said positive things about Android before, and negative things about Apple. I think I am failing on at least two criteria here.
We don't "believe" a Higgs particle exists any more then we "believe" oxygen is a bi-radical molecule with two unpaired electrons that occupy a pair of orbitals...
As scientists, we form theories and models to explain the observations we make and find the ones that fit. When we found that G = H -TS we didn't set it as immutable fact, merely that the equation has stood the test of time over many repeated experiments and observations of real world experiments.
I say "I believe" in an imprecise manner - it's merely shorthand for "our current theory for thermodynamics fits this model, but that does not mean the model can't change in the presence of new evidence.
It's not a religious statement to say "we believe the Higgs exists" because what is actually meant is "all of our models and observations to this point fit the existence of the Higgs, but as yet it has not been observed directly". If the data changes, then so will the models.
When Mendeleev laid out the Periodic Table for the first time he didn't just shove the elements together so they were all adjacent - he saw that there were patterns in the properties of the known elements and that there were gaps (undiscovered elements) in his table. Using the known elements he predicted the physical properties of several undiscovered elements (very accurately as it turns out) by looking at where the gaps were in the table. He used his model to predict something he had yet to observe directly but that he inferred existed.
What do you know, his predictions using his model were very accurate, and we still use his Table every day - we're still adding to it in fact. The experimental measurements of the new discovered elements matched up perfectly with the predictions. If they had not, he would have revised the model, not just "left off" the inconvenient new elements that didn't fit.
The Higgs is no different. We have extensive modelling and other fields of science that suggest that something exists. We just haven't seen it yet, but are getting closer. If we don't find it, we'll look at possible alternatives for the physical observations we have made.
Slashdot Mirror
Actually, that is one of the changes I really like.
You can, of course, reverse it back to the old behaviour in about 10 seconds in System Preferences, but when using a trackpad (I have the big desktop Apple trackpad on my iMac) you quickly get used to the new way, since it is exactly the same way the interface works on touch screens.
It was certainly a shock to a lot of people that it swapped over to the default in Lion.
FWIW I prefer the old behaviour when using a scroll wheel mouse, since I'm so used to it, and the paradigm fits "scroll down, window moves down" but the new way when using a trackpad: "move finger down, mimics putting fingers onto a sheet of paper so it moves with your fingers" (rather than moving the wind you're viewing through).
This change, however, is slightly outside the discussion since it's something you can set with a preference. The UI changes to iCal and Address Book are fixed.
And railways weren't designed around interchangeable standards (rails, widths, couplers, even power systems), but that doesn't mean it's not a good idea to occasionally make some parts of it obsolete.
I know what you mean, re: legacy. I use a piece of software that runs a UV/Vis spectrometer that is hardcoded to 8+3 uppercase only filenames and has extremely precarious existence on the Windows XP system it runs on (even slight perturbations can bring it all down). It worked fine when it was running on a Win95 system, but then was somewhat less stable on XP (maybe they changed something wrt supporting 16 bit apps), so the choice when the machine gives up is either keep an old copy of XP around and hope it will run on whatever can be cobbled together at the time (probably not difficult, but then you have network issues to deal with - everything else is moving to 7, so at some point the XP boxes will have to either upgrade or be dropped off the network, for policy rather that technical reasons).
This wouldn't be a problem if the software wasn't originally designed for windows 3.1.
This hits the nail on the head.
Apple, on the whole, make very functional UIs but just occasionally they mess up their good work - the rework of iCal is just one of them. I mean, it still does the job and so and and is pretty intuitive, but now if I want to make a new event that's not on my default calendar I have to pop open the menu and click, rather than simply clicking (or seeing at a glance what calendar I have selected already).
I've taken to just making events in the default and switching them to the correct calendar when I'm editing the details.
FWIW regarding the Ribbon, I think it gets a lot of hate for being a new way to use Office, when everyone had already hardcoded the old, crappy way into their minds. I know familiarity can hide many ills, but the love and devotion for the old interface is quite bemusing.
And?
It's no different to a Linux/Android/GNU/EFF/End Software Patenttttzz! fanboi....
Are they paid shills too? Or is it ok when the shill is spouting something you agree with?
"surprise! too bad!" ... uh, siri? Taking a snapshot by pressing a volume button? wifi syncing? I could go on... lol
Sure, you could go on... some random non sequitur.
"lol"
I think I can stop reading right there. Also, you forgot to log in.
I said modern diesels, not those old tractors ;)
Three random troll posts in a short period.
Are you off your Ritalin?
Ask Ford where it got the technology for it's modern diesels from.
Not every car company is like the US ones. Renault is doing just fine. This is just the logical extension of selling your car with an iPod/USB interface.
It's a different API, but it doesn't mean you have to throw out all your old C.
And yes, it took time to move things - the ten years Apple kept Carbon around after they indicated it was deprecated certainly speak to that. If it takes you 10 years to update your code for Cocoa then I guess you'll just be keeping Snow Leopard around until someone else comes along with a Cocoa version of whatever it is your code does.
I'm aware that transitions to a new API are not as simple as a quick alteration (depending on complexity). Don't mistake my lack of specifically defining the difficulties for a belief that it's trivial.
No, of course not (eyeroll), they just had the Classic environment that was essentially an OS 9 VM (not exactly, but for all intents and purposes, that is the function it served) for years after OS X was released (worked on all PPC Macs up to 10.4, finally ended with the release of Leopard in 2007).
They knew that OS 9 was pretty stone age as far as code went (I mean, just look at the memory model), so at some point you just have to call time - for Apple that was *long* after OS X had been the main OS.
If you had an end user system that was "reliable, consistent and remain unchanged for many years" and relied on the Carbon API then it would have worked from OS X's release ten years ago right up to Lion's release 3 months ago (assuming you updated OS X every time there was a new version, not that you have to even do that). I'd say that was "many years" of unchanging stability.
I'm not arguing that backwards compatibility is bad, or that everyone should jump on the "hot new thing" at every opportunity, just that things do change over time, and it's hard to argue that Apple hasn't been giving people fair warning about deprecating old APIs or cutting people off when they changed architectures.
Right, I understand that backwards compatibility matters, and that you're arguing that Apple *doesn't* care about that, despite the clar evidence to the contrary - ten years of support for a deprecated API, extensive support for Classic (OS 9 apps) long into the life of OS X, strong support and tools to facilitate the changes in architecture (68k > PPC, PPC > x86), running with Universal binaries for a long time.
You're trying to argue a position that simply isn't supported by the evidence.
So, Apple occasionally phases out APIs that were originally introduced in OS 9, and gives a decade of warning while keeping them in OS X - I'm failing to see how this demonstrates that they don't believe backwards compatibility matters. At some point you have to get rid of the outdated code. Just look at the mess Windows was left in because they *didn't* do that.
DISCLAIMER: I'm not arguing that all old code is outdated and needs to be replaced, but some pieces of it do.
This is not just related to Apple (although feel free to just dismiss me out of hand by calling me a fanboy if you think it makes your argument stronger), this applies to any non-static codebase. Some things stay the same, some things get improved over time.
Do you think that OS X should have kept OS 9's memory model? I mean, you shouldn't have to change your code, right?
Come on, you're arguing that ten years is too short of a time span?
So far Apple has not deprecated Cocoa, so going by their past history with Carbon I'd say you have approximately a decade to make some changes to your code if they say it's deprecated tomorrow.
You say there's no reason to have to rewrite your code, except that it's been ordained by Apple. So, your argument is that once you've done it once that it should be forever supported?
I'll let Microsoft know it's cool to bring back ActiveX, or that ALL code written on Linux systems 10 years ago should run perfectly *especially* between kernel versions. Nothing is ever allowed to be replaced with a different way of doing things.
So, out of interest, what "more stable" (I assume you mean it turns over its APIs less frequently than every decade) platform have you moved to?
Seriously, you're arguing like Apple just rocked up one day and told you Carbon was now gone and your defence is "wah wah! I shouldn't have to rewrite this code! I wrote it fine 10 years ago!".
Call on line 2 for you, it's the whaaaaaaaaaaambulance.
And by a few years you mean a whole decade. They gave it long enough.
"In ten years time, this API is being removed from OS X, just a heads up"
"every few years" is being disingenuous. Here in the "real world" we like to debate using accurate language.
Carbon was the state of the art, so to speak, in OS 8.6 (and released before then). It was finally killed off in Lion (and strongly limited during the push into 64 bit with Snow Leopard).
To say that, if your app relied on the Carbon API, that Apple was "forcing you to rewrite your code every few years" is to just be laughably dishonest. It was in use on the Mac (in the current latest OS version) since 1997 to 2011 - that's hardly a rewrite "every few years" - that's longer than the entire lifetime of OS X itself (not including its time as a NeXT product).
Cocoa was introduced with OS X and worked alongside Carbon for many years until finally taking over as the sole player in mid 2011 (and slightly earlier in Snow Leopard for 64 bit apps, it was still there just in 32 bit only).
If you can't manage to alter your code to transition to Cocoa in the TEN YEARS that OS X has been around (and the same amount of time you've known that Carbon was deprecated) and you're whining that Apple is making it hard for you then you need to get a different fucking job. Perhaps something with a little less "time pressure" like Bonsai tree gardener or continental plate drift measurer or something. I know ten years is barely enough time to make changes to your code.
I am of course, assuming that your code existed on the Mac in OS 9. If it started its life on OS X and you still used Carbon then... well, I return to my point about getting a different job. Clearly reading the documentation is too challenging.
Yawn.
"Any opinion that is contrary to mine is a paid shill".
But, again, why would they?
Porsche doesn't sell pickup trucks, and they seem to be doing fine - would they be doing better if they made a pickup? (DISCLAIMER: not trying to claim that Apple is Porsche, I just picked a company that makes something for a particular market segment but not another).
We're constantly told on here that "Apple has no business in enterprise" and if the Xserve told them anything, I guess it was that they were right - they simply didn't sell. Maybe they'll try again later if iOS makes more inroads, but it's not hurting them being out of that sector - in fact, it is costing them less by staying out of it.
Carbon was from the OS 9 days - it needed to die, and it was deprecated really early in OS X's life. Apple said "it's still in here, but work away from it because eventually it will be removed".
They gave everyone *years* to move away from Carbon. It's not like they just whisked it out of the OS overnight with the release of Lion.
Same thing with the switch from 68k to PPC and then again to x86. They bent over backwards to keep the backwards compatibility to smooth the transition in each case but said to developers "eventually this stuff is going away".
People got pissy because they had software that relied on Carbon, or was PPC only etc and whined that the support was going away after the very long period they had to update it. This is what happens when you rely on transitional elements and *already marked deprecated* libraries that were there to make moving to the more modern libraries and architectures more fluid.
They've certainly had some foolish moves (like removing backwards compatibility in Final Cut X, while simultaneously withdrawing Final Cut Studio from sale) and various other things, but it's not like they're just yanking things left and right and saying "surprise! too bad!"
Also, how are we quantifying "do better" in the phrase "Apple would do better if... [insert opinion]". They aren't short of cash, their products are selling as fast as they can make them (with some notable exceptions), their customer satisfaction results consistently poll very high, they're growing marketshare in the PC arena (bucking the general trend of PC makers), they're growing in the mobile space (despite very healthy competition from multiple Android vendors). How else can they "do better"?
The only thing they seem to be missing is the slashdot geek vote, but I'm not sure that's terribly troubling to them.
If Google can buy innovation and have it credited to them, then so can Apple I guess.
Weather is not climate.
2/10 for effort.
MPEG is not MPEG-LA.
What the hell are the mods smoking and where can I get some?
Spend any time on Google and look at the vast swathes of evidence that socialised healthcare systems are not only *at least* twice as cheap in terms of GDP per capita than the US system, but that they're affordable and a massive boon to the countries that have them (that would be every developed nation except the US).
Sure, nothing is perfect - the UK's system needs some serious TLC after an 18 year stretch starting in the 80s under a Tory government that wanted to kill it but without committing political suicide, so they let it drown in neglect - something it is still recovering from, along with further management gaffes in the 2000's, but overall there's plenty of data on all the countries that run socialised healthcare systems that it works well and it works affordably.
I love many things about the US (I have lived there), but your backwards healthcare system that is designed almost exclusively for the profit of insurance and medical companies is not one of them. The sooner you move to a single payer system (with private insurance still available, just like in the UK, for those who can afford to choose it if they want) the better you'll all be. It'll save you money too.
He's not wrong though, is he?
I thought slashdot was a tech literate site? This stuff is hardly rocket science.
Oh, I'm sorry, I forgot the party line... my mistake. Microsoft evul! Microsoft shitty! Rar!
What Apple box is marked up over 100%? I'm very curious.
Also, my Linux box cost more than my Apple box. So, the Linux box must have been marked up more than 100% too? I'm so confused! It must be my sheeple brain! (DISCLAIMER: I am aware of the presence of the word "usually" in your comment, but I am going for a touch of facetiousness here to keep it light).
And they didn't sue HTC over hardware design and interface style, there was a lawsuit involving a specific touch patent. There was nothing about design in it at all, other than the multitouch issue - by the standards of the Samsung debacle, it was very narrow.
Put it this way, where are all the Apple lawsuits seeking to prevent sales of anything *other* than Samsung Galaxy line products?
I mean, I'm certainly not apologetic - as to whether I classify as a bona fide Slashdot Certified (tm) Apple fanboy, I'm not so sure. I mean, I have said positive things about Android before, and negative things about Apple. I think I am failing on at least two criteria here.
We don't "believe" a Higgs particle exists any more then we "believe" oxygen is a bi-radical molecule with two unpaired electrons that occupy a pair of orbitals...
As scientists, we form theories and models to explain the observations we make and find the ones that fit. When we found that G = H -TS we didn't set it as immutable fact, merely that the equation has stood the test of time over many repeated experiments and observations of real world experiments.
I say "I believe" in an imprecise manner - it's merely shorthand for "our current theory for thermodynamics fits this model, but that does not mean the model can't change in the presence of new evidence.
It's not a religious statement to say "we believe the Higgs exists" because what is actually meant is "all of our models and observations to this point fit the existence of the Higgs, but as yet it has not been observed directly". If the data changes, then so will the models.
When Mendeleev laid out the Periodic Table for the first time he didn't just shove the elements together so they were all adjacent - he saw that there were patterns in the properties of the known elements and that there were gaps (undiscovered elements) in his table. Using the known elements he predicted the physical properties of several undiscovered elements (very accurately as it turns out) by looking at where the gaps were in the table. He used his model to predict something he had yet to observe directly but that he inferred existed.
What do you know, his predictions using his model were very accurate, and we still use his Table every day - we're still adding to it in fact. The experimental measurements of the new discovered elements matched up perfectly with the predictions. If they had not, he would have revised the model, not just "left off" the inconvenient new elements that didn't fit.
The Higgs is no different. We have extensive modelling and other fields of science that suggest that something exists. We just haven't seen it yet, but are getting closer. If we don't find it, we'll look at possible alternatives for the physical observations we have made.
Science: it works.