Remember how they sold us NAFTA? That for every low-paying job that went overseas the economy would create a well-paying job to replace it?
I always thought that jobs in the IT industry *were* those well-paying jobs.
But look at what they did with the H-1B. I think it's funny that the name sounds so much like what you'd name a bomber aircraft, because that's exactly what it did to the hi-tech job market here in America.
Ok, you can go to a fair amount of effort to achieve an inferior version of what other environments have built in, but why reinvent the wheel?
A fair amount of effort? As compared to what... using two different and largely incompatible languages to complete a project?
And in any case, so what? Apple is the one trying to get Win32 code ported to OSX. Do the effort! Give us an API that lets us stay in C++!
Although the Finder is a C++ Carbon app...
Hmmm, my bad. Why on earth would they have chosen Carbon for this? Bizarre.
The Finder nevertheless illustrates my fears over the two-language approach. When you build something that has an elaborate GUI, and where you are allowing the user to manipulate hundreds or thousands or even millions of objects of all different types and with different properties you inevitably run into the issue of how to represent all these objects in your code.
Sometimes you can use the same object that you use internally in your code to implement the GUI for that object, sometimes you can't. And what I've found is that what will distinguish a successful projects from one that is less so is the extent to which the programmer gets this one aspect of his code right.
Using Objective C for the GUI seems to lock me into this approach of deploying peer objects for all of my internal objects, and while I can appreciate how that sometimes is the way to go, it isn't always the way to go.
I'd like to be able to make such decisions for myself, rather than having my development tools do it for me.
The best analogy I can come up with that others can relate to involves the way text objects were handled in AppleScript. You generally (always?) wouldn't actually have an object instantiated in your code containing the state for
word 2 of line 3 of paragraph 4
, you would somehow encapsulate the object representing all of the text with parameters identifing the portion contained within you were interested in.
However, elsewhere in the program you would have an object, like window say, wherein you could conveniently bind your scripting functionality with the object being scripted.
Getting back to the Finder, my thought was that it was this dissonance between the actual state of an object -- which in the case of a file is maintained by the file system -- and the program's internal representation of the object -- which could be either an instance of some class or a procedural API -- along with the object or objects responsible for presenting this file to the user that was responsible for all the woe we all experience.
In short, I am bothered by the idea of being forced to always implement two objects to represent but one. One object maintains state in my C++ code. The other lets the user see it. A lot of the times you want the two to be the same.
Look at what this story is about. Apple is trying to get people to port their Win32 code over to OSX.
All I'm saying is that this is putting the cart before the horse. If they were really serious about this they would give us bindings allowing us to use the world's most popular programming language for producing shrinkwrapped applications: C++.
Because Java has sufficient dynamic capabilities so that it's a reasonable fit for the Cocoa API and runtime. C++ does not, and is not.
There are any number of ways of doing this in C++. One would be to declare a static method that returns an instance of that class. Register it with a class factory via a static constructor.
Any decent framework that supports serialization is going to have this.
Adopt a convention whereby a class instance can be constructed using a dictionary object of some kind like STL's map and you have a convenient mechanism through which parameters can be given.
The prepareWithInvocationTarget example is something that has been done a thousand times or more by C++ programmers supporting AppleScript. Factorization of verb from methods and nouns from objects is very old news.
The nice thing about C++ is that you can write this so that it runs *fast*. The Cocoa apps I've played with are cute when all that's at issue is a widget or two, but once you start trying to do real work everything slows down to the point where it's unusable. The Finder is an excellent example here. It's an embarrassment.
Not knowing how to code in C++ isn't a reason to go running away and betting everybody's future on a toy language. The language has been mature for many years now, and there are many tutorials that will help you get your footing.
But why force us to use Objective C in the first place, when C++ is perfectly capable today of handling run-time dispatching?
Why not just set an intern or two on the task of letting us call the API's from C++ and be done with it?
A little MI coupled with some RTTI and then I can stay in my language. I don't want to use Objective-C, and if there's no compelling reason to do so, I won't. I am saddled with knowing too many languages as it is.
They aren't going to be selling these planes today though. They won't be flying for years yet.
The airline industry will return to normal, eventually. People still need to go places, and with each passing day the emotional impact of 9/11 fades.
Just look at these proposals for the new WTC that were unveiled this week, and compare them to the proposals submitted some months back. Back then, nobody dared suggest building anything that rivaled the scale of the WTC for fear it would attract the attention of terrorists once again.
This time around we had at least two entries that were on that scale, including one I think that if built would be the world's largest building.
I think this story underscores capitalism's apparent inability to provide and maintain massive infrastructure. Specifically, it appears that successfully running an airline -- or building airliners -- requires a kind of long-term thinking that is seldom rewarded in the business world. So nobody bothers.
Why? It would seem to me that this would be the perfect time to sell people on ways to save travelers time, what with all the delays our new "security" has created.
A plane that goes faster makes up for lines at the gate that are getting longer and longer.
... the only people being shot at in Iraq right now are U.S. pilots.
Let me guess, you've got a subscription to The New York Times! LOL!
Those U.S. pilots of course aren't shooting at anybody, are they. They're just flying around in the airspace of a sovereign nation minding their own business.
I suppose you think that the sanctions we in the U.S. have imposed on the Iraqis haven't done any harm either.
Don't give me the shit that they're U.N. sanctions. America sold all our souls to get that one through. Estimates of the number of dead as a result range between 500,000 to 1,500,000... and that was as of this summer.
But no order was needed to put the planes in the air in the first place. They tracked Flight 77 for over forty minutes before even scrambling aircraft to intercept.
They can scramble to intercept without an order from the President.
If the military wasn't incompetent, then they were complicit.
8:20 Departs. 8:46 Goes off course. 9:41 Crashes into Pentagon.
YOU ARE FULL OF SHIT
Re:fear mongering
on
DOD vs. 802.11b
·
· Score: 4, Interesting
Fear mongering? No current examples of interference???
No current examples of interference are possible, since our military appears to be completely incompetent!
Consider 9/11. At approximately the same time the first airliner struck the World Trade Center, the flight that was to hit the Pentagon went NORDO, i.e., was identified as a hijacked aircraft. This thing was tracked on radar for FIFTY FUCKING MINUTES before crashing into THE FUCKING PENTAGON of all places and the fine men and women charged with protecting our airspace DID ABSOLUTELY NOTHING TO PREVENT IT!
It takes big balls on their part to now say that we can't do any further development on WiFi because it will impair the military use of radar. I fail to see how military radar can be rendered any more ineffective.
Slashdot Mirror
Probably should have provided a link.
That might be #1 for this decade, yes?
Pass.
And they'll seize it through the forfeiture laws, i.e., they'll steal it.
Remember how they sold us NAFTA? That for every low-paying job that went overseas the economy would create a well-paying job to replace it?
I always thought that jobs in the IT industry *were* those well-paying jobs.
But look at what they did with the H-1B. I think it's funny that the name sounds so much like what you'd name a bomber aircraft, because that's exactly what it did to the hi-tech job market here in America.
Bastards!
A fair amount of effort? As compared to what... using two different and largely incompatible languages to complete a project?
And in any case, so what? Apple is the one trying to get Win32 code ported to OSX. Do the effort! Give us an API that lets us stay in C++!
Although the Finder is a C++ Carbon app...
Hmmm, my bad. Why on earth would they have chosen Carbon for this? Bizarre.
The Finder nevertheless illustrates my fears over the two-language approach. When you build something that has an elaborate GUI, and where you are allowing the user to manipulate hundreds or thousands or even millions of objects of all different types and with different properties you inevitably run into the issue of how to represent all these objects in your code.
Sometimes you can use the same object that you use internally in your code to implement the GUI for that object, sometimes you can't. And what I've found is that what will distinguish a successful projects from one that is less so is the extent to which the programmer gets this one aspect of his code right.
Using Objective C for the GUI seems to lock me into this approach of deploying peer objects for all of my internal objects, and while I can appreciate how that sometimes is the way to go, it isn't always the way to go.
I'd like to be able to make such decisions for myself, rather than having my development tools do it for me.
The best analogy I can come up with that others can relate to involves the way text objects were handled in AppleScript. You generally (always?) wouldn't actually have an object instantiated in your code containing the state for , you would somehow encapsulate the object representing all of the text with parameters identifing the portion contained within you were interested in.
However, elsewhere in the program you would have an object, like window say, wherein you could conveniently bind your scripting functionality with the object being scripted.
Getting back to the Finder, my thought was that it was this dissonance between the actual state of an object -- which in the case of a file is maintained by the file system -- and the program's internal representation of the object -- which could be either an instance of some class or a procedural API -- along with the object or objects responsible for presenting this file to the user that was responsible for all the woe we all experience.
In short, I am bothered by the idea of being forced to always implement two objects to represent but one. One object maintains state in my C++ code. The other lets the user see it. A lot of the times you want the two to be the same.
It's not a question of toleration.
Look at what this story is about. Apple is trying to get people to port their Win32 code over to OSX.
All I'm saying is that this is putting the cart before the horse. If they were really serious about this they would give us bindings allowing us to use the world's most popular programming language for producing shrinkwrapped applications: C++.
Why not just do that?
Because Java has sufficient dynamic capabilities so that it's a reasonable fit for the Cocoa API and runtime. C++ does not, and is not.
There are any number of ways of doing this in C++. One would be to declare a static method that returns an instance of that class. Register it with a class factory via a static constructor.
Any decent framework that supports serialization is going to have this.
Adopt a convention whereby a class instance can be constructed using a dictionary object of some kind like STL's map and you have a convenient mechanism through which parameters can be given.
The prepareWithInvocationTarget example is something that has been done a thousand times or more by C++ programmers supporting AppleScript. Factorization of verb from methods and nouns from objects is very old news.
The nice thing about C++ is that you can write this so that it runs *fast*. The Cocoa apps I've played with are cute when all that's at issue is a widget or two, but once you start trying to do real work everything slows down to the point where it's unusable. The Finder is an excellent example here. It's an embarrassment.
Not knowing how to code in C++ isn't a reason to go running away and betting everybody's future on a toy language. The language has been mature for many years now, and there are many tutorials that will help you get your footing.
One, all the work was already done for the Objective C API.
Which they had no difficulty in replicating for Java.
Two, it works better (faster, more efficiently, we have the technology) in Objective C than in C++.
That's an absurd statement. For it to work better implies there's a version for C++ that works at all.
Oh, sorry to hear you're so burdened by this overabundance of knowledge. Is that what makes you so whiny, or is it something else?
No burden at all. I'll just write code for a platform other than OS X.
But why force us to use Objective C in the first place, when C++ is perfectly capable today of handling run-time dispatching?
Why not just set an intern or two on the task of letting us call the API's from C++ and be done with it?
A little MI coupled with some RTTI and then I can stay in my language. I don't want to use Objective-C, and if there's no compelling reason to do so, I won't. I am saddled with knowing too many languages as it is.
If they were really serious about seeing developers adopt Cocoa they would have released API's allowing native access from C++.
Instead, they were more interested in punishing everybody who didn't jump on the Objective C bandwagon back in the '80s.
Which is approximately as news-worthy.
Was this story straight out of the mouth of a Universal Studios weasel or what?
My money is on the monkey with the stick.
This is true, today.
They aren't going to be selling these planes today though. They won't be flying for years yet.
The airline industry will return to normal, eventually. People still need to go places, and with each passing day the emotional impact of 9/11 fades.
Just look at these proposals for the new WTC that were unveiled this week, and compare them to the proposals submitted some months back. Back then, nobody dared suggest building anything that rivaled the scale of the WTC for fear it would attract the attention of terrorists once again.
This time around we had at least two entries that were on that scale, including one I think that if built would be the world's largest building.
I think this story underscores capitalism's apparent inability to provide and maintain massive infrastructure. Specifically, it appears that successfully running an airline -- or building airliners -- requires a kind of long-term thinking that is seldom rewarded in the business world. So nobody bothers.
Why? It would seem to me that this would be the perfect time to sell people on ways to save travelers time, what with all the delays our new "security" has created.
A plane that goes faster makes up for lines at the gate that are getting longer and longer.
A very good newspaper?
IN SOVIET RUSSIA maybe.
Let me guess, you've got a subscription to The New York Times! LOL!
Those U.S. pilots of course aren't shooting at anybody, are they. They're just flying around in the airspace of a sovereign nation minding their own business.
I suppose you think that the sanctions we in the U.S. have imposed on the Iraqis haven't done any harm either.
Don't give me the shit that they're U.N. sanctions. America sold all our souls to get that one through. Estimates of the number of dead as a result range between 500,000 to 1,500,000... and that was as of this summer.
Sig heil, mother fucker.
You've got to be kidding! Score: 5 Informative???
Oooh, wait, my turn...
"Light saber" = weapon("Jedi Knight")
or how about...
"Shaken, not stirred" = drinkPreference("James Bond")
There ya go, blindingly obvious geek movie trivia, now hurry up and gimme some karma!
they wear Red Hats, so I imagine all this talk about red hats turning black will cause great consternation.
No argument about Bush...
But no order was needed to put the planes in the air in the first place. They tracked Flight 77 for over forty minutes before even scrambling aircraft to intercept.
They can scramble to intercept without an order from the President.
If the military wasn't incompetent, then they were complicit.
Here's the timeline.
8:20 Departs.
8:46 Goes off course.
9:41 Crashes into Pentagon.
YOU ARE FULL OF SHIT
Fear mongering? No current examples of interference???
No current examples of interference are possible, since our military appears to be completely incompetent!
Consider 9/11. At approximately the same time the first airliner struck the World Trade Center, the flight that was to hit the Pentagon went NORDO, i.e., was identified as a hijacked aircraft. This thing was tracked on radar for FIFTY FUCKING MINUTES before crashing into THE FUCKING PENTAGON of all places and the fine men and women charged with protecting our airspace DID ABSOLUTELY NOTHING TO PREVENT IT!
It takes big balls on their part to now say that we can't do any further development on WiFi because it will impair the military use of radar. I fail to see how military radar can be rendered any more ineffective.
Yeah, this one.
Anybody have an idea why /. would reject a submission regarding this story?