This is just an attempt by apple to make this appealing
By Apple?
I read Andrew Lim in the byline.
No relevant search results seem to pop up for "Andrew Lim Apple Flack" or "Andrew Lim Apple Shill," so it seems likely this was just a guy with a theory on the internet.
Of course, it could be that Apple's PR and marketing tendrils are even more subtle, deep, and devious than we've ever suspected.
The ipad wont let you do DUN. Apple's idea of bluetooth is wireless keyboards and headphoness. It would upset their partner AT&T and their own bottom line if they cant bundle a new iphone with the ipad.
If it can't to bluetooth DUN with a generic phone, why would it be able to do it with an iPhone?
Well, assuming for some reason you've got an aversion against or unusual obstacle to using WiFi, you could use a phone that costs around $50. At least, that's what I do with my laptop and a Nokia 2865 (via bluetooth DUN). It's not 3G speeds, which means you don't want to be pushing video over it, but for sending model data between games it should work just fine.
As for the rest of the economics... yeah, if you're just going to buy one board game, it probably doesn't make a lot of sense, to buy an iPad just to play it. The question is if you're going to do anything else... whether that's a handful of other games, or something else the device does (as well as whether game titles cost less or more than the equivalent board game). In other words, whether or not the iPad makes sense for games is probably going to a have a lot to do with whether the iPad makes sense in general for you.
Personally, for me the bigger objection would generally have to be that it's a bit small for group board gaming.
But it's also curious that while President Obama is moving towards a kind of nationalization-lite with other major industries... autos, banking, etc...
The "nationalization-lite" we've engaged in is actually unfortunately consistent with hypocritical market fundamentalism that passes for our free-market gospel: just enough conservatorship to bleed resources into specific large institutions in those sectors, but not enough receivership to actually work effectively. Socialize losses, sure, but don't you dare interfere with corresponding private gains, because *that* would be Socialism(TM)!
Other countries with comparable market economies and levels of personal economic freedom wouldn't and haven't hesitated to simply do the effective if "socialist" things to clean up their industries when corruption and crisis break things. But *we* have to take the effective thing and bend it to the private advantage of the sector we're working with, because that's just The American Way.
In other words, far from being inconsistent, the "nationalization lite" and the privatization of space are pretty much manifestations of the same underlying economic/political philosophy.
Why should there be a marginal cost to a phone call? There isn't - once you're paying for the infrastructure, it's free.
Costs of maintaining and more importantly expanding the capacity of the infrastructure are directly tied to usage, though: each call connected goes through at the opportunity cost of another potential phone call. Having some kind of economic feedback go through the system based on usage makes a certain amount of sense.
Of course, nobody likes being on the meter all the time, particularly if costs for small uses of service are large (SMS, anyone?), or if costs go up dramatically with even marginal overuse (overage charges are pretty much usurious).
That's a really good point, and I can see why that means that you wouldn't want to use bluetooth as your primary means of moving large media files between devices. And then, if you're going to go with a cable, I guess everything else is redundant.
Thing is, though, redundancy can be pretty nice for the consumer. If you've forgotten your cable, it might not be the time to download a few movies onto your iPod, but it might be nice to still be able to move a podcast or two, your calendar, some ringtones, and a few new contacts.
I'd recommend some time thinking about Nontransitive games before proceeding to think about the topic. I think half the problem here is that lots of geeks love straight transitivity.
The other half of the problem is that geeks tend to believe in absolutely objective standards--even binary standards--for utility. So you got discussions about the iPhone that were something like "Why do people like the iPhone more than OtherPhone? OtherPhone can tether, and has been able to for years! OtherPhone is clearly superior, because tethering is important to me!" And if tethering is important enough to you, OtherPhone is superior. I can relate: it's one of the reasons I don't have an iPhone. But here's where I think a lot of geeks lose the thread: they can't imagine that anyone else has a different utility curve than they do. I like tethering because there's a lot of things I like to do with my laptop that I'd find annoying (if not impossible) to do on most any phone. But what a lot of people would use tethering for if they had it with the iPhone... the iPhone does just fine by itself. Thus they don't care about tethering. Or maybe they care about it a *little*... there could be a whole range of how much someone might care about tethering. Maybe someone gets some marginal utility out of the occasional ability to connect a laptop via their phone when they're on the road... but not enough to outweigh the overall utility they derive from other features of the iPhone. Again, I'm not really talking about the iPhone and tethering specifically, I'm using it as an example of this idea that a feature that's of crucially high utility to one person might be of marginal if any utility to another.
So, with those in mind, let's talk about how the iPad might compare to other devices.
it can't make calls
Not true, actually. It would be accurate to say that it is less useful for making calls, it can make calls using VOIP apps. But yeah, like the Nokia 8xx series, it's probably a worse phone than... well, most mobile phones.
On the other hand, it's a better phone than a Kindle or Nook or just about any eReader out there. In fact, chances are, it's probably a less awkward phone than most netbooks.
It's an unportable iPod
While it's accurate to say that it is less portable in the sense that it's more awkward to store in a pocket, this will fit comfortably inside a handbag, a bookbag. Less portable than a mobile phone... but not less portable than a paperback.
Equation: phone > iPad ~ eReader some netbooks > other netbook
It's an eReader with a bright ass screen that will strain your eyes.
It's a worse eReader than those with eInk for reasons of eyestrain and battery life... for people who spend long consecutive amounts of time reading. But it might be a perfectly acceptable eReader for people who are casually reading for an hour or two and can charge it once a day, and for reasons of eyestrain and battery life, it's certainly a better eReader than most mobile phones, and probably many netbooks.
It surfs the internet the way Apple says you should (no flash, IE: no Hulu, etc).
It's a very bad device for viewing flash sites / playing flash games. If that's a priority for you, definitely, this is not your device.
Equation: depends entirely on your enthusiasm for Flash-delivered content.
It plays limited games so it's not going to dominate the handheld market.
It's always possible there are games you like that aren't a part of this particular ecosystem, but "limited" hasn't even occurred to me. There are over 20,000 titles for Cocoa Touch devices. Even if you go by the 80-20 rule (80% crap, 20% worthwhile), that's around 4,000 acceptable titles. That's competitive with the DS, PSP, PCs, and certainly eReaders.
When is the iPhone getting that? The iPad can use a bluetooth keyboard, but the iPhone can't? What kind of crap is this?
And while we're at it.... why not bluetooth syncing (with SYNCH, FTP, & OBEX), DUN for the touch and iPad, BPP (printing), and Audio/Video Remote Control Profile (AVRCP)?
This isn't just an Apple problem, by the way. This is an industry-wide problem right now: "bluetooth" means a lot of things and most of the market doesn't seem to care to specify what. The BSIG ought to require those using the Bluetooth logo to specify which profiles a device supports, for the sake of consumer awareness and market pressure.
Apple fanboy sees all negative observations as complaints, and ends his post with a question where he is wondering why anyone would ever publicly make negative observations about Apple or Apple Products.
And in turn, the anti-fanboy sees any positive observations--heck, in some cases, any observation at all--as threats to the legitimacy of his alternative of choice.
Apple, as a publicly traded company, only has one obligation: to make a profit for shareholders.
It goes beyond "obligation" in a couple of important ways. For one thing, obligation or not, it's quite simply the existential proposition for a publicly traded company, a cold hard reality that Apple had an ample chance to consider a while back, if the analysts of the mid 1990s are to be believed.
But for the other thing, that's where the list of motivationsstart, not end. Some companies exploit opportunities that don't create a lot of value for everyone involved. Some companies take or make opportunities for unfulfilled needs and wants. Which decision you make may not matter to investors, but particularly since making money isn't an existential question for most company leadership (by the time you get to that level, chances are you make or have made enough money to retire in middle-class comfort within a short period of time), the choice is generally one of values rather than obligation.
I think it's pretty clear that whatever flaws Apple's leadership has, they're not simply in it for the money, they're interested in bringing about a certain product vision. I'm glad we live in a world where people who don't like that product vision have choices (sometimes their vision doesn't align with mine), but the fact is that if Jobs only cared about money, there's probably lots of places he could invest his time and cash where he'd get a better purely financial return.
That means doing things like closing off Darwin for developers
Any technology that has been sold or in use for over a year is unpatentable.
A patent based on such technology may not stand up in court, but to start with, in practice "patentable" means something the USPTO will issue a patent on. And the examiner looking at whether to grant such an issue may not be familiar with relevant prior art, not to mention that they may not even have any particular incentive to examine a given patent application closely.
I love the way you cherry-pick your evidence and ignore the evidence already discussed.
Feel free to list points that I've ignored.
If you wanted to have an honest argument
I've made one.
you would have picked nits with my claim that (for example) encapsulation is done by the programmer, not the language.
As I pointed out earlier, most of the time I believe encapsulation is a design issue, so, no, not really. But if you'd like, you can focus on my earlier statement that sometimes it's important to have a mechanism in the language for enforcing it, and I demonstrated that mechanism. One that I might add is as succinct and labor equivalent as comparable Java code, and relies on a feature woven as completely into the language as a "private" or "protected" keyword.
Instead you point to the ability to create objects.
Sure, among other things, including the ability to do all the things you layed out as general criteria for an OOL.
That ability is in any language. That's the fourth time I've pointed it out
You've made that claim, I've challenged you, and rather than explaining in detail, you've simply reiterated. Perhaps you need to watch the video in your sig, but I'd settle for an elaboration.
which is why this thread no longer has any interest for me.
It's a pity. You clearly have a lot left to learn.
To spell it out: The action that gives rise to consciousness/intelligence might be simple, but also bound to specific substances and processes. Or it might be complex but bound to specific substances and processes. Or it might be complex but not bound in any way. Or perhaps simple but not bound in any way. In other words, it's a completely orthogonal concern... which is to say it "has nothing to do with that hypothesis at all."
Not at all. The language is doing the work when you type "Square.prototype = new Shape" in exactly the same way that the language is doing the work when you type "class Square extends Shape."
can think of ways to do OOP in languages that don't support function pointers.
I can too. However, off the top of my head I can't think of a way to build a library that abstracts away the manual/bookkeeping work involved in doing inheritance and polymorphism without them.
a Java programmer would say the same about your workarounds.
Which Java programmer? I'm a Java programmer, among other things, and I wouldn't say that at all.
Perhaps you're talking about people who know chiefly Java and not much else?
No, I'd say at a minimum you need function pointers (or functions as a first class data type) and a mechanism for aggregate data types that can encompass them. Otherwise you can't really marry the methods to the members and abstracted mechanisms for inheritance and polymorphism probably aren't possible.
In order to wedge JS into the category, you've made it meaningless.
If there's any wedging being done in our discussion, it's on C, which might need it.
Javascript? It's got objects and does encapsulation, polymorphism, and inheritance right out of the box. I'm using your definition:
to be a real OOL, and not just a procedural language with pretensions, you have to support encapsulation (hiding the inner workings of the object from the code that uses it), polymorphism (the ability for various kinds of objects to all support the same method, so that user code doesn't need to know precisely what kind of object it's dealing with) and inheritance (the ability to define new object types based on an existing object types)
So any language that can implement objects is an OOL? So C is an OOL?
To quote my earlier post:
"having done OOP in even plain ol' C (definitely not the most OOL..."
So, no. I don't think of C as a particularly OOL. Perhaps minimally so because it provides a decent basis to get as OO as you like, but only minimally because it doesn't give you shortcuts for doing the three essentials we've discussed.
Javascript has convenient ways of doing all three built into the language, though, as I believe I've conclusively shown.
Assembly language?
Possibly more purely than anything else, as it's nothing but method calls on a few simple real objects.;)
(Seriously, I'm happy to draw a bright line between 2GLs and 3GLs)
Given the the extremely tiny portion of the universe we've actually explored, "no evidence" proves nothing.
It's true that absence of evidence is not evidence of absence and I'm sure there's a lot interesting things left to discover. It's not a particularly supporting argument that something specific is likely to exist, and it doesn't work for machine intelligences any better than it works for elves or pink unicorns.
It seems to come down to the idea that intelligence is too complicated a phenomenon for any mechanical system.
Um, no. Complicatedness has nothing to do with that hypothesis at all.
I'm not pooh-poohing classes in general; I'm happy to use classes and class hierarchies when they seem to fit the problem domain. The pooh-poohing I'm doing is the idea that you're not doing "real" object-oriented programming -- or that a language isn't an OOL -- if you don't have them built into the language.
you seem to be using OO as shorthand for both OOL and OOP, as if the two concepts were interchangeable. They're not.
I'm aware of the difference, having done OOP in even plain ol' C (definitely not the most OOL, but structs can hold function pointers and after that it's a matter of bookkeeping, which is why Strousup was able to more or less make the first implementation of C++ with a glorified C preprocessor). It's a good exercise which helps one appreciate the possibilities of a generally capable language as well as the work that other languages will do for you.
I'm not going to criticize the duck object paradigm, but it's definitely not the same as the OOP paradigm.
I suspect some confusion between static strong typing and classes. Some of the most dominant languages in the industry do things this way, which I think leads to the confusion, but it's only one possible mix of two largely orthogonal concerns.
But let's get to the meat of my comment:
And I was taught to be a real OOL, and not just a procedural language with pretensions, you have to support encapsulation (hiding the inner workings of the object from the code that uses it), polymorphism (the ability for various kinds of objects to all support the same method, so that user code doesn't need to know precisely what kind of object it's dealing with) and inheritance (the ability to define new object types based on an existing object types).
Sounds like a pretty good list to me.
All three of those criteria don't work without something resembling classes.
Sigh. And we were on a roll there. Let's go back to talking about Encapsulation, Polymorphism, and Inheritance.
Encapsulation: Javascript has methods, so it has OO encapsulation. That's my threshold, anyway. For some people it's different; they take the term to mean there exist means to ensure one can't examine the internal state of an object, that the language has some mechanism for enforcing privacy of member data. Personally, I think that many programmers overuse and abuse language-level enforcement mechanisms of this kind. If you're doing your design well, the methods you provide will be so convenient a developer won't even be curious about implementation and internal state. But there are some cases where enforcement really is important, and some people who aren't satisfied that it's OO if there's not a mechanism for it. So, in Javascript, you can do this with lexical scoping rules and closures:
function Example() {
var private = 0;
this.get = function () { return private; }
this.set = function (v) { private = v; } }
e = new Example(); e.set(5); e.private// the interpreter will have no idea what you're talking about, so it'll yield null e.get();// yields 5
You've got a simple object with a single private property that can be modified by a setter, retrieved with a getter, and touched no other way. And without being told or seeing the source, the programmer won't know whether Example objects do their storage in a closed-over scope, or on a remote server, or in a local database. Simple privacy-enforced encapsulation of concerns.
Polymorphism: if an object has a method, it'll respond to it. If not, you'll get an error/exception.
function Counter() {
var i = 0;
this.get = function () { return i++; } }
Can you cite a reason why silicon-based systems shouldn't be as capable carbon-based ones?
Because there's no evidence thus far for consciousness and cognition in anything other than carbon-based wetware.
You can hypothesize that consciousness and cognition are just another kind of computation, and a lot of people do, which near as I can tell is how we get the idea that silicon-based systems will someday do cognition and maybe even self-awareness when we find the right algorithm. But there are no such systems at the moment, and there's no particular evidence that given hypothesis is correct. It may well be self-aware intelligence is tied to the particular mix of phenomena that take place inside of carbon brains.
But if you can't define new classes, you can't build object frameworks.
I believe you mean:
"if you can't define new classes, you can't build class hierarchies."
But there's ways of doing things when it comes to frameworks beyond setting up a class hierarchy.
Definitely not OO.
Even if you start with the axiom that OO means classes (a questionable assertion at best), and even if you don't like manually dealing with the prototype hierarchy as a proxy, it's been pretty convincingly demonstrated that you build classes onto standard javascript.
It is OO, but you did not make a new instance of a class, you made a new object. Apple is not a class, it is a closure.
I'm trying to stretch the definition of a closure to fit your statement and am not coming up with anything promising. I suppose you can look at an object as a scope of sorts and this or with as invoking that scope in the right context, but it doesn't seem to fit cleanly in my mind.
The semantics of the new keyword in JavaScript are the second most horrendous part of the spec.
It does what it says it does: creates a new object with a given prototype initialized with a constructor that's a function of the same name.
You're basically calling the closure with this bound to a new object which has Object as its prototype.
No, the type is object. The prototype is the "Apple" object (or, more precisely, the immediate link up the prototype chain is Apple and then ultimately Object).
Slashdot Mirror
This is just an attempt by apple to make this appealing
By Apple?
I read Andrew Lim in the byline.
No relevant search results seem to pop up for "Andrew Lim Apple Flack" or "Andrew Lim Apple Shill," so it seems likely this was just a guy with a theory on the internet.
Of course, it could be that Apple's PR and marketing tendrils are even more subtle, deep, and devious than we've ever suspected.
The ipad wont let you do DUN. Apple's idea of bluetooth is wireless keyboards and headphoness. It would upset their partner AT&T and their own bottom line if they cant bundle a new iphone with the ipad.
If it can't to bluetooth DUN with a generic phone, why would it be able to do it with an iPhone?
$499 + $299/phone
$299 phone?
Well, assuming for some reason you've got an aversion against or unusual obstacle to using WiFi, you could use a phone that costs around $50. At least, that's what I do with my laptop and a Nokia 2865 (via bluetooth DUN). It's not 3G speeds, which means you don't want to be pushing video over it, but for sending model data between games it should work just fine.
As for the rest of the economics... yeah, if you're just going to buy one board game, it probably doesn't make a lot of sense, to buy an iPad just to play it. The question is if you're going to do anything else... whether that's a handful of other games, or something else the device does (as well as whether game titles cost less or more than the equivalent board game). In other words, whether or not the iPad makes sense for games is probably going to a have a lot to do with whether the iPad makes sense in general for you.
Personally, for me the bigger objection would generally have to be that it's a bit small for group board gaming.
But it's also curious that while President Obama is moving towards a kind of nationalization-lite with other major industries... autos, banking, etc...
The "nationalization-lite" we've engaged in is actually unfortunately consistent with hypocritical market fundamentalism that passes for our free-market gospel: just enough conservatorship to bleed resources into specific large institutions in those sectors, but not enough receivership to actually work effectively. Socialize losses, sure, but don't you dare interfere with corresponding private gains, because *that* would be Socialism(TM)!
Other countries with comparable market economies and levels of personal economic freedom wouldn't and haven't hesitated to simply do the effective if "socialist" things to clean up their industries when corruption and crisis break things. But *we* have to take the effective thing and bend it to the private advantage of the sector we're working with, because that's just The American Way.
In other words, far from being inconsistent, the "nationalization lite" and the privatization of space are pretty much manifestations of the same underlying economic/political philosophy.
Why should there be a marginal cost to a phone call? There isn't - once you're paying for the infrastructure, it's free.
Costs of maintaining and more importantly expanding the capacity of the infrastructure are directly tied to usage, though: each call connected goes through at the opportunity cost of another potential phone call. Having some kind of economic feedback go through the system based on usage makes a certain amount of sense.
Of course, nobody likes being on the meter all the time, particularly if costs for small uses of service are large (SMS, anyone?), or if costs go up dramatically with even marginal overuse (overage charges are pretty much usurious).
That's a really good point, and I can see why that means that you wouldn't want to use bluetooth as your primary means of moving large media files between devices. And then, if you're going to go with a cable, I guess everything else is redundant.
Thing is, though, redundancy can be pretty nice for the consumer. If you've forgotten your cable, it might not be the time to download a few movies onto your iPod, but it might be nice to still be able to move a podcast or two, your calendar, some ringtones, and a few new contacts.
This is exactly what I don't get.
I'd recommend some time thinking about Nontransitive games before proceeding to think about the topic. I think half the problem here is that lots of geeks love straight transitivity.
The other half of the problem is that geeks tend to believe in absolutely objective standards--even binary standards--for utility. So you got discussions about the iPhone that were something like "Why do people like the iPhone more than OtherPhone? OtherPhone can tether, and has been able to for years! OtherPhone is clearly superior, because tethering is important to me!" And if tethering is important enough to you, OtherPhone is superior. I can relate: it's one of the reasons I don't have an iPhone. But here's where I think a lot of geeks lose the thread: they can't imagine that anyone else has a different utility curve than they do. I like tethering because there's a lot of things I like to do with my laptop that I'd find annoying (if not impossible) to do on most any phone. But what a lot of people would use tethering for if they had it with the iPhone... the iPhone does just fine by itself. Thus they don't care about tethering. Or maybe they care about it a *little*... there could be a whole range of how much someone might care about tethering. Maybe someone gets some marginal utility out of the occasional ability to connect a laptop via their phone when they're on the road... but not enough to outweigh the overall utility they derive from other features of the iPhone. Again, I'm not really talking about the iPhone and tethering specifically, I'm using it as an example of this idea that a feature that's of crucially high utility to one person might be of marginal if any utility to another.
So, with those in mind, let's talk about how the iPad might compare to other devices.
it can't make calls
Not true, actually. It would be accurate to say that it is less useful for making calls, it can make calls using VOIP apps. But yeah, like the Nokia 8xx series, it's probably a worse phone than... well, most mobile phones.
On the other hand, it's a better phone than a Kindle or Nook or just about any eReader out there. In fact, chances are, it's probably a less awkward phone than most netbooks.
It's an unportable iPod
While it's accurate to say that it is less portable in the sense that it's more awkward to store in a pocket, this will fit comfortably inside a handbag, a bookbag. Less portable than a mobile phone... but not less portable than a paperback.
Equation: phone > iPad ~ eReader some netbooks > other netbook
It's an eReader with a bright ass screen that will strain your eyes.
It's a worse eReader than those with eInk for reasons of eyestrain and battery life... for people who spend long consecutive amounts of time reading. But it might be a perfectly acceptable eReader for people who are casually reading for an hour or two and can charge it once a day, and for reasons of eyestrain and battery life, it's certainly a better eReader than most mobile phones, and probably many netbooks.
Equation: eReader > iPad > phone/pda/most netbooks
It surfs the internet the way Apple says you should (no flash, IE: no Hulu, etc).
It's a very bad device for viewing flash sites / playing flash games. If that's a priority for you, definitely, this is not your device.
Equation: depends entirely on your enthusiasm for Flash-delivered content.
It plays limited games so it's not going to dominate the handheld market.
It's always possible there are games you like that aren't a part of this particular ecosystem, but "limited" hasn't even occurred to me. There are over 20,000 titles for Cocoa Touch devices. Even if you go by the 80-20 rule (80% crap, 20% worthwhile), that's around 4,000 acceptable titles. That's competitive with the DS, PSP, PCs, and certainly eReaders.
Equation: DS/PSP/PC ~ iPad ~ i
I have to buy the right to use the hardware in a way that I want to?
No. Not at all. You're welcome to poke at it with a magnetized needle or any other tool you've got in order to program it the way you want.
You could even recreate the work other people have already done in creating an open toolchain on the iPhone. Or you could just use that toolchain.
You can even use the developer tools Apple has created for free -- they give those away.
If you want to participate in the marketplace that Apple has developed, though, they ask you for fees.
When is the iPhone getting that? The iPad can use a bluetooth keyboard, but the iPhone can't? What kind of crap is this?
And while we're at it.... why not bluetooth syncing (with SYNCH, FTP, & OBEX), DUN for the touch and iPad, BPP (printing), and Audio/Video Remote Control Profile (AVRCP)?
This isn't just an Apple problem, by the way. This is an industry-wide problem right now: "bluetooth" means a lot of things and most of the market doesn't seem to care to specify what. The BSIG ought to require those using the Bluetooth logo to specify which profiles a device supports, for the sake of consumer awareness and market pressure.
People who want to use a lot of Flash sites and read books outdoors who don't get in to a place where they can charge their device once a day.
So... flash-loving backpackers and forest rangers?
Apple fanboy sees all negative observations as complaints, and ends his post with a question where he is wondering why anyone would ever publicly make negative observations about Apple or Apple Products.
And in turn, the anti-fanboy sees any positive observations--heck, in some cases, any observation at all--as threats to the legitimacy of his alternative of choice.
See also "But what's wrong with the way Perl does it?"
Apple, as a publicly traded company, only has one obligation: to make a profit for shareholders.
It goes beyond "obligation" in a couple of important ways. For one thing, obligation or not, it's quite simply the existential proposition for a publicly traded company, a cold hard reality that Apple had an ample chance to consider a while back, if the analysts of the mid 1990s are to be believed.
But for the other thing, that's where the list of motivations start, not end. Some companies exploit opportunities that don't create a lot of value for everyone involved. Some companies take or make opportunities for unfulfilled needs and wants. Which decision you make may not matter to investors, but particularly since making money isn't an existential question for most company leadership (by the time you get to that level, chances are you make or have made enough money to retire in middle-class comfort within a short period of time), the choice is generally one of values rather than obligation.
I think it's pretty clear that whatever flaws Apple's leadership has, they're not simply in it for the money, they're interested in bringing about a certain product vision. I'm glad we live in a world where people who don't like that product vision have choices (sometimes their vision doesn't align with mine), but the fact is that if Jobs only cared about money, there's probably lots of places he could invest his time and cash where he'd get a better purely financial return.
That means doing things like closing off Darwin for developers
You might mean OS X. Darwin is open source.
... it's that any point of failure completely invalidates other successes.
Be sure to tell your boss or clients, your SO, and your friends.
Any technology that has been sold or in use for over a year is unpatentable.
A patent based on such technology may not stand up in court, but to start with, in practice "patentable" means something the USPTO will issue a patent on. And the examiner looking at whether to grant such an issue may not be familiar with relevant prior art, not to mention that they may not even have any particular incentive to examine a given patent application closely.
the cost of malpractice insurance at every level of healthcare is a major driver of the enormous cost
Take a read Tom Baker's The Medical Malpractice Myth.
Ezra Klein also has a highlight/review of the book.
I love the way you cherry-pick your evidence and ignore the evidence already discussed.
Feel free to list points that I've ignored.
If you wanted to have an honest argument
I've made one.
you would have picked nits with my claim that (for example) encapsulation is done by the programmer, not the language.
As I pointed out earlier, most of the time I believe encapsulation is a design issue, so, no, not really. But if you'd like, you can focus on my earlier statement that sometimes it's important to have a mechanism in the language for enforcing it, and I demonstrated that mechanism. One that I might add is as succinct and labor equivalent as comparable Java code, and relies on a feature woven as completely into the language as a "private" or "protected" keyword.
Instead you point to the ability to create objects.
Sure, among other things, including the ability to do all the things you layed out as general criteria for an OOL.
That ability is in any language. That's the fourth time I've pointed it out
You've made that claim, I've challenged you, and rather than explaining in detail, you've simply reiterated. Perhaps you need to watch the video in your sig, but I'd settle for an elaboration.
which is why this thread no longer has any interest for me.
It's a pity. You clearly have a lot left to learn.
Please view the video linked in my sig.
To spell it out: The action that gives rise to consciousness/intelligence might be simple, but also bound to specific substances and processes. Or it might be complex but bound to specific substances and processes. Or it might be complex but not bound in any way. Or perhaps simple but not bound in any way. In other words, it's a completely orthogonal concern... which is to say it "has nothing to do with that hypothesis at all."
The language doesn't do these things.
Not at all. The language is doing the work when you type "Square.prototype = new Shape" in exactly the same way that the language is doing the work when you type "class Square extends Shape."
can think of ways to do OOP in languages that don't support function pointers.
I can too. However, off the top of my head I can't think of a way to build a library that abstracts away the manual/bookkeeping work involved in doing inheritance and polymorphism without them.
a Java programmer would say the same about your workarounds.
Which Java programmer? I'm a Java programmer, among other things, and I wouldn't say that at all.
Perhaps you're talking about people who know chiefly Java and not much else?
In other words, all languages are OOLs.
No, I'd say at a minimum you need function pointers (or functions as a first class data type) and a mechanism for aggregate data types that can encompass them. Otherwise you can't really marry the methods to the members and abstracted mechanisms for inheritance and polymorphism probably aren't possible.
In order to wedge JS into the category, you've made it meaningless.
If there's any wedging being done in our discussion, it's on C, which might need it.
Javascript? It's got objects and does encapsulation, polymorphism, and inheritance right out of the box. I'm using your definition:
So any language that can implement objects is an OOL? So C is an OOL?
To quote my earlier post:
"having done OOP in even plain ol' C (definitely not the most OOL..."
So, no. I don't think of C as a particularly OOL. Perhaps minimally so because it provides a decent basis to get as OO as you like, but only minimally because it doesn't give you shortcuts for doing the three essentials we've discussed.
Javascript has convenient ways of doing all three built into the language, though, as I believe I've conclusively shown.
Assembly language?
Possibly more purely than anything else, as it's nothing but method calls on a few simple real objects. ;)
(Seriously, I'm happy to draw a bright line between 2GLs and 3GLs)
Given the the extremely tiny portion of the universe we've actually explored, "no evidence" proves nothing.
It's true that absence of evidence is not evidence of absence and I'm sure there's a lot interesting things left to discover. It's not a particularly supporting argument that something specific is likely to exist, and it doesn't work for machine intelligences any better than it works for elves or pink unicorns.
It seems to come down to the idea that intelligence is too complicated a phenomenon for any mechanical system.
Um, no. Complicatedness has nothing to do with that hypothesis at all.
From the way you poo-poo classes
I'm not pooh-poohing classes in general; I'm happy to use classes and class hierarchies when they seem to fit the problem domain. The pooh-poohing I'm doing is the idea that you're not doing "real" object-oriented programming -- or that a language isn't an OOL -- if you don't have them built into the language.
you seem to be using OO as shorthand for both OOL and OOP, as if the two concepts were interchangeable. They're not.
I'm aware of the difference, having done OOP in even plain ol' C (definitely not the most OOL, but structs can hold function pointers and after that it's a matter of bookkeeping, which is why Strousup was able to more or less make the first implementation of C++ with a glorified C preprocessor). It's a good exercise which helps one appreciate the possibilities of a generally capable language as well as the work that other languages will do for you.
I'm not going to criticize the duck object paradigm, but it's definitely not the same as the OOP paradigm.
I suspect some confusion between static strong typing and classes. Some of the most dominant languages in the industry do things this way, which I think leads to the confusion, but it's only one possible mix of two largely orthogonal concerns.
But let's get to the meat of my comment:
And I was taught to be a real OOL, and not just a procedural language with pretensions, you have to support encapsulation (hiding the inner workings of the object from the code that uses it), polymorphism (the ability for various kinds of objects to all support the same method, so that user code doesn't need to know precisely what kind of object it's dealing with) and inheritance (the ability to define new object types based on an existing object types).
Sounds like a pretty good list to me.
All three of those criteria don't work without something resembling classes.
Sigh. And we were on a roll there. Let's go back to talking about Encapsulation, Polymorphism, and Inheritance.
Encapsulation: Javascript has methods, so it has OO encapsulation. That's my threshold, anyway. For some people it's different; they take the term to mean there exist means to ensure one can't examine the internal state of an object, that the language has some mechanism for enforcing privacy of member data. Personally, I think that many programmers overuse and abuse language-level enforcement mechanisms of this kind. If you're doing your design well, the methods you provide will be so convenient a developer won't even be curious about implementation and internal state. But there are some cases where enforcement really is important, and some people who aren't satisfied that it's OO if there's not a mechanism for it. So, in Javascript, you can do this with lexical scoping rules and closures:
function Example() {
var private = 0;
this.get = function () { return private; }
this.set = function (v) { private = v; }
}
e = new Example(); // the interpreter will have no idea what you're talking about, so it'll yield null // yields 5
e.set(5);
e.private
e.get();
You've got a simple object with a single private property that can be modified by a setter, retrieved with a getter, and touched no other way. And without being told or seeing the source, the programmer won't know whether Example objects do their storage in a closed-over scope, or on a remote server, or in a local database. Simple privacy-enforced encapsulation of concerns.
Polymorphism: if an object has a method, it'll respond to it. If not, you'll get an error/exception.
function Counter() {
var i = 0;
this.get = function () { return i++; }
}
function showObjValInTextBox(o) {
Wow, talk about carbon bias!
Can you cite a reason why silicon-based systems shouldn't be as capable carbon-based ones?
Because there's no evidence thus far for consciousness and cognition in anything other than carbon-based wetware.
You can hypothesize that consciousness and cognition are just another kind of computation, and a lot of people do, which near as I can tell is how we get the idea that silicon-based systems will someday do cognition and maybe even self-awareness when we find the right algorithm. But there are no such systems at the moment, and there's no particular evidence that given hypothesis is correct. It may well be self-aware intelligence is tied to the particular mix of phenomena that take place inside of carbon brains.
But if you can't define new classes, you can't build object frameworks.
I believe you mean:
"if you can't define new classes, you can't build class hierarchies."
But there's ways of doing things when it comes to frameworks beyond setting up a class hierarchy.
Definitely not OO.
Even if you start with the axiom that OO means classes (a questionable assertion at best), and even if you don't like manually dealing with the prototype hierarchy as a proxy, it's been pretty convincingly demonstrated that you build classes onto standard javascript.
It is OO, but you did not make a new instance of a class, you made a new object. Apple is not a class, it is a closure.
I'm trying to stretch the definition of a closure to fit your statement and am not coming up with anything promising. I suppose you can look at an object as a scope of sorts and this or with as invoking that scope in the right context, but it doesn't seem to fit cleanly in my mind.
The semantics of the new keyword in JavaScript are the second most horrendous part of the spec.
It does what it says it does: creates a new object with a given prototype initialized with a constructor that's a function of the same name.
You're basically calling the closure with this bound to a new object which has Object as its prototype.
No, the type is object. The prototype is the "Apple" object (or, more precisely, the immediate link up the prototype chain is Apple and then ultimately Object).