The problem with microchip delivered medication is that a large number of large states (including NY) have laws in the books which allow for coercive and/or involuntary psychiatric treatment. For the coerced or involuntarily treated patient, non-compliance is the only way out of a nightmare that some have described as "chemical lobotomization". (Anti-psychotics, neuroleptics, mood stabilizers and anti-depressants ALL interfere with and modify "normal" brain functioning and are quite possibly brain damaging over the long term. There is no medical literature that asserts a strictly biological etiology for all mental illness.)
Whether it's a benefit to voluntary and/or non-psychiatric patients or not, microchip medical delivery would better ensure that the state has even more power over those they decide are mentally ill.
that it was either the BBC taken in by the hoax or the "researchers" mentioned by the BBC that were taken in.
i think that the more interesting possibility is the researchers having been taken in.
discuss.
i dont mean to be overly critical, but...
your observation (albeit interesting), lacks attendance to unscientific biases.
i suppose the corollary to the postulate you present is: the control to an experiment attempting to disprove (or at the very least expose) the logical hypocrisy of the hypothesis suggested at by the above is -- ahem -- to gather some animals that do indeed 'think on their own' and subject them to the same conditions as the penguins.
and see what happens.
i spend alot of time around playgrounds. when noone is looking i go to over to the monkey bars and i find a child and i say to the child: "kids can fly. its true. its just that your parents and everyone else in the world has convinced you that this cannot possibly be true. " to which the child might respond (or in this case, did -- respond, that is), "I am calling my mommy. You scare me."
-ouch
I read the BYTE article. I bought the first Smalltalk IDE for DOS (Digitalk) in 1986 and taught myself OO and Smalltalk programming. I architected dozens of large scale Smalltalk projects for several Fortune 500 companies. I endured the hype that (incredibly and unironically) predicted that Smalltalk would become the COBOL of the 90s. I made tons of dough.
I watched as Smalltalk use soared and then -- at last -- plummeted. I reeducated myself as a Java (gak) programmer and said goodbye to a language that I once thought could never be bettered and might someday dominate computing.
So Why Did Smalltalk Fail?
First: Why Not
Myth #1 Smalltalk failed because of poor marketing. Okay, Smalltalk marketing was not the textbook example of high tech marketing that was the introduction and distribution of Java but it was far from bad. If anything, the hype behind Smalltalk seemed to inspire an almost religious fervor. While Smalltalk use never approached the ubiquity of COBOL alot of very smart people believed that it would. Christ had St Paul and Smalltalk had Adele Goldberg. You should have heard the starry-eyed predictions of the execs leaving a ParcPlace road show.
Myth #2 Smalltalk failed because it was slow. Okay for some purposes and in some implementations Smalltalk provided less than optimal performance. But most enterprise applications do not require blazing performance at the Client (where Smalltalk was primarily deployed). The speed of Smalltalk development more than countered its performance hitches. Even if a Smalltalk application was dog slow, any reasonable thinking corporate IT manager just needed to requisition the latest PC hardware for the application's users.
Myth #3 Smalltalk failed because it was so expensive. Yes its likely that if the major Smalltalk vendors of the 80s and early 90s had given away their product more programmers would be programming in Smalltalk today. The simple fact is that at the time PCs and programming were not as widespread as they are today and most programmers or people interested in learning programming had access to computers through work or school and such institutions could and often did afford themselves access to Smalltalk.
So how come a language that by most accounts is elegant, powerful and expressive did not achieve widespread popularity?
Here's Why:
Reason #1: Enterprise Smalltalk application development was beyond the grasp of most corporate IT managers. Smalltalk fosters reuse of a very high order and tends to attract programmers whose focus is on reuse. This is not a bad thing at all. But (and that is a big but) code reuse and its benefits cannot be enjoyed in a unsupportive and uncooperative environment. Except in a few rare instances most organizations threw Smalltalk at their PC "front end" applications, allowed the applications developers (outside consultants usually) to create rich and highly reusable development frameworks and business models and then failed to share the work with the rest of the department. This happened simply because the amount of effort that went into sharing and managing code within an IT department was too great and the manager's bosses saw no value in the attempt. A professional software company sees their software as an asset. Many firms that may very well rely on software see (or did see until recently) their software as a replaceable resource.
Reason #2: Smalltalk, a simulation language at heart, was employed too often as a simple GUI builder. Okay, you are a project lead at a large Wall Street firm. You have nine months (why is it always nine months?) to complete a very important and high visibility application that could guarantee you a promotion. You are told by your IBM (or Microsoft -- believe it or not Bill Gates used to say good things about Smalltalk) representative that the latest and greatest language and GUI application builder is Smalltalk the OOiest of OO languages. So you dive in. What happens? Well nine months later you discover that your fancy graphical front end to your mainframe application has evolved into a large (okay, fat. okay, obese.) client application that is a generic screen-scraping/rdbms-to-Object mapper/business model with extra menthol eukeneuba three for more whitening power that is brittle to the touch (the more moving parts the more chance for breakage) and dog slow because the application designers in their zeal to objectify everything in sight (because they can) re-developed the key mainframe components and their business logic in Smalltalk. On a PC client. With 200 - 1000 ms latency for every data call to compose the applications objects. (This of course presumes you have found the developers who know Smalltalk well enough to put something this sophisticated together). Meanwhile the monkey down the hall has whipped up a huge bowl of visual basic spaghetti that may not be terribly elegant or useful to anyone except the end user but is working and in production. The simple fact is that Smalltalk which preceded the Client Server revolution by several years, belonged on the Server not the Client. Smalltalk grew into what little prominence it enjoyed in the bad old days of 2 Tier Fat Client Architecture. Because Smalltalk was graphically oriented and the client was where the money and the sex appeal was, Smalltalk ended up a GUI solution (and wrongly associated with the fat client problem) and not the business modelling solution it should have been.
Reason #3: The Learning Curve. Smalltalk syntax is odd and does frighten away the timid. Setting up a Smalltalk environment for enterprise programming is a nightmare and deploying the application once it is built is the nightmare you wake up into from the previous nightmare. More significantly, I think the "idea" of a stand alone Smalltalk program doesn't exist as such. A Smalltalk image is a large and often unwieldy executable. The novice programmer accustomed to taking their program home on a floppy and seeing the result of their effort encapsulated entirely in a single main function is bewildered by the image concept wherein the programmer does not use the development environment to build a program but modifies the development environment to be the program.
Reason #4: Java. Java in its ubiquity and immediate appeal (small programs, manageable memory footprints, familiar syntax and wealth of easy to follow examples) made Smalltalk as an OO choice irrelevant. Also, the Java folk ceded (mostly) the client to other languages and have concentrated on network computing thereby avoiding the pitfalls of GUI OO development. Java ain't pretty (unless you have been doing C++) and it ain't all that fast but it is programmer friendly and OO friendly enough to achieve some of the promises of Smalltalk. I like to think that spirit of Smalltalk lives on in Java and that Java is just yet another step in the evolution of C into Smalltalk. On bleaker days I look at the retarded in bred cousin that is Java and despair that his Daddy had more money and that's why he inherited the family business. Oh well.
I believe that in the reasonably near future Programming languages will evolve from systems inwhich Use is dictated by Definition to systems inwhich the opposite is true: Definition will result from Use. I call these systems Adaptive Natural Programming Environments.
Of course I just made up that name but that's neither here nor there. It does help to identify ideas in concise terms. So ANPE or Anne P. (whoever she may be) if you please, it is.
The simple fact is that ALL programming languages in their deployed forms (ie programs) be they interpreted or compiled are restricted in use by the definitions applied at construction time. In other words and by example, the verb, or lets call it a function to be mathematical for a moment, "Move" no matter what its encapsulation (Function library or Object Class) has a definition that is determined by the programmer and is applicable only to that which the programmer has decided it is applicable to. So I may be able to "move" a MoveableObject in Object terms or execute the function "move()" given the appropriate parameters
but these operations have pre-determined scope.
What then is the abstract definition of "move" and does it exist as an action outside of its prescribed use? Cognitively this is (pardon the pun) a no-brainer. Of course "move" has meaning. Does that mean in the programmatic analog all things which are to be moved are required to subscribe to the appropriate protocol in order to be moved? What if something needs to be moved that the programmer has not ever anticipated moving?
Given that "move" implies displacement and certain well-known variables (lets call 'em X,Y and Z) need to be "adjusted" what is to be done with the object that has been moved and does not reference any variables that are displacable? Surely the user knows what they are doing. Why not let the object that needs to be moved adopt displacability as a feature? Why not, further to the point, allow for this instance of use to determine the degree to which the object is displacable? This is useful info. A house for example largely stays put but every now and then it needs to get moved (Damn highway keeps getting closer every year!) so why not give it membership in the Displaceable world but not the same degree of membership as say a wheelbarrow? By maintaining this history of use and adoption of characteristics a very powerful meta info system necessarily evolves.
So why haven't these ideas been explored in traditional programming languages? For one most applications are not appropriate for this level of functional fuzziness (thank you very much but I like the intransigence of my ATM) but as computer applications encroach into more complex areas (simulation systems, gaming, virtual environments) the resistance to dynamic runtime change that is evident in the most abstractly defined Object-Oriented system will disappear. I believe that adaptive systems will prove to be the theoretical basis for non-adaptive systems and will become the paradigm for the future. Moreover I believe that this will result from the application of linguistic concepts (beyond the encapsulation of noun and verb) to programming languages which will result in enriched machine to machine communication and the "automation" of complex simulations and virtual environments and even more work for me.
Slashdot Mirror
The problem with microchip delivered medication is that a large number of large states (including NY) have laws in the books which allow for coercive and/or involuntary psychiatric treatment. For the coerced or involuntarily treated patient, non-compliance is the only way out of a nightmare that some have described as "chemical lobotomization". (Anti-psychotics, neuroleptics, mood stabilizers and anti-depressants ALL interfere with and modify "normal" brain functioning and are quite possibly brain damaging over the long term. There is no medical literature that asserts a strictly biological etiology for all mental illness.)
Whether it's a benefit to voluntary and/or non-psychiatric patients or not, microchip medical delivery would better ensure that the state has even more power over those they decide are mentally ill.
that it was either the BBC taken in by the hoax or the "researchers" mentioned by the BBC that were taken in. i think that the more interesting possibility is the researchers having been taken in. discuss.
i dont mean to be overly critical, but... your observation (albeit interesting), lacks attendance to unscientific biases. i suppose the corollary to the postulate you present is: the control to an experiment attempting to disprove (or at the very least expose) the logical hypocrisy of the hypothesis suggested at by the above is -- ahem -- to gather some animals that do indeed 'think on their own' and subject them to the same conditions as the penguins. and see what happens.
i spend alot of time around playgrounds. when noone is looking i go to over to the monkey bars and i find a child and i say to the child: "kids can fly. its true. its just that your parents and everyone else in the world has convinced you that this cannot possibly be true. " to which the child might respond (or in this case, did -- respond, that is), "I am calling my mommy. You scare me." -ouch
I was there.
I read the BYTE article. I bought the first Smalltalk IDE for DOS (Digitalk) in 1986 and taught myself OO and Smalltalk programming. I architected dozens of large scale Smalltalk projects for several Fortune 500 companies. I endured the hype that (incredibly and unironically) predicted that Smalltalk would become the COBOL of the 90s. I made tons of dough.
I watched as Smalltalk use soared and then -- at last -- plummeted. I reeducated myself as a Java (gak) programmer and said goodbye to a language that I once thought could never be bettered and might someday dominate computing.
So Why Did Smalltalk Fail?
First: Why Not
Myth #1 Smalltalk failed because of poor marketing. Okay, Smalltalk marketing was not the textbook example of high tech marketing that was the introduction and distribution of Java but it was far from bad. If anything, the hype behind Smalltalk seemed to inspire an almost religious fervor. While Smalltalk use never approached the ubiquity of COBOL alot of very smart people believed that it would. Christ had St Paul and Smalltalk had Adele Goldberg. You should have heard the starry-eyed predictions of the execs leaving a ParcPlace road show.
Myth #2 Smalltalk failed because it was slow. Okay for some purposes and in some implementations Smalltalk provided less than optimal performance. But most enterprise applications do not require blazing performance at the Client (where Smalltalk was primarily deployed). The speed of Smalltalk development more than countered its performance hitches. Even if a Smalltalk application was dog slow, any reasonable thinking corporate IT manager just needed to requisition the latest PC hardware for the application's users.
Myth #3 Smalltalk failed because it was so expensive. Yes its likely that if the major Smalltalk vendors of the 80s and early 90s had given away their product more programmers would be programming in Smalltalk today. The simple fact is that at the time PCs and programming were not as widespread as they are today and most programmers or people interested in learning programming had access to computers through work or school and such institutions could and often did afford themselves access to Smalltalk.
So how come a language that by most accounts is elegant, powerful and expressive did not achieve widespread popularity?
Here's Why:
Reason #1: Enterprise Smalltalk application development was beyond the grasp of most corporate IT managers. Smalltalk fosters reuse of a very high order and tends to attract programmers whose focus is on reuse. This is not a bad thing at all. But (and that is a big but) code reuse and its benefits cannot be enjoyed in a unsupportive and uncooperative environment. Except in a few rare instances most organizations threw Smalltalk at their PC "front end" applications, allowed the applications developers (outside consultants usually) to create rich and highly reusable development frameworks and business models and then failed to share the work with the rest of the department. This happened simply because the amount of effort that went into sharing and managing code within an IT department was too great and the manager's bosses saw no value in the attempt. A professional software company sees their software as an asset. Many firms that may very well rely on software see (or did see until recently) their software as a replaceable resource.
Reason #2: Smalltalk, a simulation language at heart, was employed too often as a simple GUI builder. Okay, you are a project lead at a large Wall Street firm. You have nine months (why is it always nine months?) to complete a very important and high visibility application that could guarantee you a promotion. You are told by your IBM (or Microsoft -- believe it or not Bill Gates used to say good things about Smalltalk) representative that the latest and greatest language and GUI application builder is Smalltalk the OOiest of OO languages. So you dive in. What happens? Well nine months later you discover that your fancy graphical front end to your mainframe application has evolved into a large (okay, fat. okay, obese.) client application that is a generic screen-scraping/rdbms-to-Object mapper/business model with extra menthol eukeneuba three for more whitening power that is brittle to the touch (the more moving parts the more chance for breakage) and dog slow because the application designers in their zeal to objectify everything in sight (because they can) re-developed the key mainframe components and their business logic in Smalltalk. On a PC client. With 200 - 1000 ms latency for every data call to compose the applications objects. (This of course presumes you have found the developers who know Smalltalk well enough to put something this sophisticated together). Meanwhile the monkey down the hall has whipped up a huge bowl of visual basic spaghetti that may not be terribly elegant or useful to anyone except the end user but is working and in production. The simple fact is that Smalltalk which preceded the Client Server revolution by several years, belonged on the Server not the Client. Smalltalk grew into what little prominence it enjoyed in the bad old days of 2 Tier Fat Client Architecture. Because Smalltalk was graphically oriented and the client was where the money and the sex appeal was, Smalltalk ended up a GUI solution (and wrongly associated with the fat client problem) and not the business modelling solution it should have been.
Reason #3: The Learning Curve. Smalltalk syntax is odd and does frighten away the timid. Setting up a Smalltalk environment for enterprise programming is a nightmare and deploying the application once it is built is the nightmare you wake up into from the previous nightmare. More significantly, I think the "idea" of a stand alone Smalltalk program doesn't exist as such. A Smalltalk image is a large and often unwieldy executable. The novice programmer accustomed to taking their program home on a floppy and seeing the result of their effort encapsulated entirely in a single main function is bewildered by the image concept wherein the programmer does not use the development environment to build a program but modifies the development environment to be the program.
Reason #4: Java. Java in its ubiquity and immediate appeal (small programs, manageable memory footprints, familiar syntax and wealth of easy to follow examples) made Smalltalk as an OO choice irrelevant. Also, the Java folk ceded (mostly) the client to other languages and have concentrated on network computing thereby avoiding the pitfalls of GUI OO development. Java ain't pretty (unless you have been doing C++) and it ain't all that fast but it is programmer friendly and OO friendly enough to achieve some of the promises of Smalltalk. I like to think that spirit of Smalltalk lives on in Java and that Java is just yet another step in the evolution of C into Smalltalk. On bleaker days I look at the retarded in bred cousin that is Java and despair that his Daddy had more money and that's why he inherited the family business. Oh well.
I believe that in the reasonably near future Programming languages will evolve from systems inwhich Use is dictated by Definition to systems inwhich the opposite is true: Definition will result from Use. I call these systems Adaptive Natural Programming Environments.
Of course I just made up that name but that's neither here nor there. It does help to identify ideas in concise terms. So ANPE or Anne P. (whoever she may be) if you please, it is.
The simple fact is that ALL programming languages in their deployed forms (ie programs) be they interpreted or compiled are restricted in use by the definitions applied at construction time. In other words and by example, the verb, or lets call it a function to be mathematical for a moment, "Move" no matter what its encapsulation (Function library or Object Class) has a definition that is determined by the programmer and is applicable only to that which the programmer has decided it is applicable to. So I may be able to "move" a MoveableObject in Object terms or execute the function "move()" given the appropriate parameters
but these operations have pre-determined scope.
What then is the abstract definition of "move" and does it exist as an action outside of its prescribed use? Cognitively this is (pardon the pun) a no-brainer. Of course "move" has meaning. Does that mean in the programmatic analog all things which are to be moved are required to subscribe to the appropriate protocol in order to be moved? What if something needs to be moved that the programmer has not ever anticipated moving?
Given that "move" implies displacement and certain well-known variables (lets call 'em X,Y and Z) need to be "adjusted" what is to be done with the object that has been moved and does not reference any variables that are displacable? Surely the user knows what they are doing. Why not let the object that needs to be moved adopt displacability as a feature? Why not, further to the point, allow for this instance of use to determine the degree to which the object is displacable? This is useful info. A house for example largely stays put but every now and then it needs to get moved (Damn highway keeps getting closer every year!) so why not give it membership in the Displaceable world but not the same degree of membership as say a wheelbarrow? By maintaining this history of use and adoption of characteristics a very powerful meta info system necessarily evolves.
So why haven't these ideas been explored in traditional programming languages? For one most applications are not appropriate for this level of functional fuzziness (thank you very much but I like the intransigence of my ATM) but as computer applications encroach into more complex areas (simulation systems, gaming, virtual environments) the resistance to dynamic runtime change that is evident in the most abstractly defined Object-Oriented system will disappear. I believe that adaptive systems will prove to be the theoretical basis for non-adaptive systems and will become the paradigm for the future. Moreover I believe that this will result from the application of linguistic concepts (beyond the encapsulation of noun and verb) to programming languages which will result in enriched machine to machine communication and the "automation" of complex simulations and virtual environments and even more work for me.