So we'd have lost out on some burnt cakes, but gained some good bacon, and a huge improvement in centuries of beer tradition... count me in. Let me be the first to welcome our parallel reality Danish overlords...
Numbered seating isn't all that bad. I've been to cinemas where they do, and where they don't. Cinemas without preassigned seating never get completely full, because people don't like to choose a seat next to a strange when another seat is available. So you end up with "holes" of 1-2 seats between each group that are hard to fill. With assigned seating it is usual (for a popular film) for every seat to go.
I'm used to cinemas without assigned seating, but on the few times that I've been to cinemas that assign first the atmosphere has been better. In terms of catching people with camcorders, as other people have pointed out if you paid cash then it won't help at all.
On the cellphones, one of your other replies moaned about people using cellphones in movies. That must be a cultural difference. In the uk answering a mobile phone during a film would be a lynching offence. I've seen people try it, and an entire cinema full of people baying for their blood.
Actually most of those have good reason, just not reasons that you, or I, or any other viewer of TV would find acceptable. The constant repetition and tight rotation is designed to bombard with the same advert lots in a small period of time. Because it's based on psychological studies that show advertising is more effective that way. Of course effective does not mean making you aware of their product, it means making you more likely to impulse buy it. This is much like training a dog, or domesticating any other kind of animal.
The loudness is a serious annoyance, but the rationale is that some purchasers may have fallen asleep during the show so waking them up would be good. Even if you don't wake them up completely hitting them with advertising audio while they're drifting back into REM will be very effective. The 1/3rd of air-time is an American thing. I always find it pretty shocking, and don't know how any of you watch tv at all. When "hour long" American shows are on tv in the uk they are put into 45 minute slots....
I'd be quite happy to pay for decent tv shows that were completely free of advertising and DRM. That's exactly what I said about music, and since iTunes lost the drm I've been opening my wallet to fill my boots. It's been too many years of watching tv on-demand, advertising free and normally at better bitrates than the crap they put on cable over here to ever go back that way. TV died a long time ago, it's about time they buried the corpse.
Although you are correct in a moral indignation sense, sadly you are wrong in an actual reality sense. Instruction sets have been patentable for may years, and form a large part of the Intel / AMD war-chest that they can threaten impudent upstarts with. The standard trick that gets used (and has been defended in court) is to claim that the instruction is a method of encoding a particular process. Once you reduce things to a process a patent examiner, and then a court are more likely to go along with you.
No, it shows that the poster that you are arguing with understands the different physical constraints between volatile and persistent storage. He also understands that we can make external storage look like RAM already, and the reason that we don't do so is that abstraction would kill performance for most applications that need to be aware of the distinction.
You have nothing in response other than "blah blah imagination I'll be right in ten years". Yeah, course you will sunshine. As we progress down the fab sizes I'm sure that the distinction that volatile memory only needs to store a charge for a tiny amount of time (true looking back through DRAM all the way to mercury delay lines) where-as persistent storage needs more power to flip a state in some sort of field, ie magnetic.
But of course, that's lack of imagination and physics will be drastically altered in the next ten years. I can't understand why nobody has seen you for the visionary that you are...
ObjectStore came out in 1988. The version that we used back in 1998 definitely performed this mapping for C++ code. I don't know if it counts as prior art because I can't remember how it handled the schemata for the mapping.
As you are the third reply to make the same point (although in more detail than the previous two) let me make myself clear.
OOP is not a well defined concept. The parts that are well defined - that a system should be constructed from smaller units called objects which combine data and code - are shared across all of the languages that claim to support OOP. One basic difference between possible implementations of OOP is the decision for whether or not object boundaries should be strict, or loose.
It is possible to define OOP in such a way that there are hard lexical boundaries around each object, and access is only possible using get/set methods. If the choice to define OOP in this way is made, then it can be shown that the result object is equivalent to a closure. It can also be shown that it is equivalent to a process, as the restriction on state management via explicit set/gets is a form of MPI.
The fact that we can derive a clean and elegant formulation of OOP that has these nice properties does not mean that OOP is general has these nice properties. In particular none of the mainstream language with OOP support use this strict lexical scoping over objects, and as a result the objects in most OOP systems are not equivalent to closures, or to processes, or to anything well-defined enough to be useful.
That is the distinction that I was making somewhat loosely on the earlier poster who came out with the bold claim that objects (no context given) were equivalent to closures. This claim can only be made in such general terms from somebody so deeply sucked in Scheme that they have forgotten it is not the whole world. And of course I stand by my original claim to the OP that OOP is not a paradigm, although I will now modify that slightly to make explicit the trivial consequence that (like imperative programming in general) with suitable restrictions it can be equivalent to other well-known paradigms.
As I pointed out earlier in the thread, it's not a language that I'm familiar with. After a quick look at the samples on smalltalk.org it looks like an Imperative language.
I get this idea from the way that OOP is implemented in the mainstream languages (Java, C++, Python...). What you are describing is familiar to me, although not under the label OOP. I've seen it in process oriented languages like Occam. After a wee bit of background research I see that OOP as you're describing it, and Smalltalk implemented it, is quite a different beast to what I'm used to. It's a shame Smalltalk wasn't invented a decade later:)
As for my original point about OO not being a separate paradigm as the OP mentioned; it's less obvious now. "Pure" OOP (as the Smalltalk page called it) does seem to be quite a different beast, although it is unclear to what extent the evaluation would be different to functional programming.
Analysing the timing behaviour of assembly language programs for embedded systems. Haskell was used for the majority of the analysis, with perl used to munge data about prior to processing. Huge fun to write, but left me with a lasting desire never to combine perl and Haskell again...
Not only do I not realise it I would argue strongly that it is wrong:) You are correct that both closures and objects contain a state and a function(s). But the object allows direct manipulation of the state by the external world, while the closure does not. Hence the set of operations that can be performed on the object is open (as the whole purpose is to allow functional extension), while on the closure the set is closed. Hence the semantics may look superficially similar, but there is a deep difference between them.
I'd be interested to know if that was your opinion, or if you've picked it up somewhere from the literature. Arguing about semantics always comes down to the details and it would be interesting to know what model of closures / objects gives rise to an equivalence.
I'd agree with this completely. I've worked on a few large multi-language projects, and had to combine flavours of asm, C, C++, perl, prolog, bash, maple, haskell, java and a few others together to get what I want. After years of working this way, and stumbling over the questions posed in the article (integrating build processes, dev environment etc) I had my arm twisted into using Python. What a joy it has turned out to be.
As someone with a background in functional programming (most of my PhD was implemented in Haskell) the "functional" programming support in Python is a bit barren - but list comprehensions and bound methods are powerful enough for most tasks. The shell integration is nice, and the regexps are simple enough that I hardly touch perl these days (thank god...). Sage replicates most of the functionality that I would use maple or magma for.
A sibling (AC) poster complains that Python is not "the one true language" (tm) that the parent asserts it is. Well the parent makes no such assertion. I would assert that if you want a single True Language then Python would be a good candidate for you. But if you like multi-language programming then Python is good glue. Personally I like it as glue, shockingly other people may have different uses for it. Lastly, a general word on the whole monolithic application vs small tools in multiple languages. This isn't a new debate that has sprung up in the past decade. It has always been there. There isn't even really a debate, because the two approaches are building tools for disjoint sets of users.
If you eat your own dog-food, it's vital that you have the quickest turnaround time possible on adding new features and trying out new ideas. In a sense you are continually prototyping, never finishing. You are your own end-user, although occasionally other people may pretend. As a result your target audience is highly literate in the languages that you are using, and wants to maximise the power of the tools with a programmatic interface. The unix-philosophy was constructed to service this case.
If your target user is a non-programmer, who simply wants to be able to perform a task then you will need to wrap up the functionality in a non-programmatic way. GUIs are the best way (so far) of doing this. Because there is no intention of exposing an external call interface the overhead of mapping from language to language becomes pure overhead and there is a natural tendency towards a single monolithic language approach.
The interesting gap between these two areas is when your target audience spans the non-technical and the technical. This is where monolithic applications with APIs and scripting interfaces appear. I've got to say that AppleScript is quite cute in this area, purely because it's pervasive enough that it reminds me of Arexx all those years ago...
I would read it as sarcasm. Try reading this manifesto and updating Fortran to C to account for 20 years of shift in the industry. Anyone not using C is just eating Quiche.
Although his joke went over your head, it is worth pointing out that OO is not a paradigm. I know wikipedia thinks that it is, and so do a hoard of practically illiterate researchers publishing crap papers in junk conferences. But that doesn't make it true. Object Orientation is just a method of organisation for procedural languages. Although it helps code maintenance and does a better job of unit management that modules alone, it doesn't change the underlying computational paradigm. I say procedural languages because class-based programming in functional languages is actually a different type of beast although it gets called OO to appeal to people from an imperative background.
It's the law of unintended consequences. The vision at Microsoft has always been to try and reduce complexity. Whenever there has been a tradeoff between control and simplicity, Microsoft has chosen simplicity. Unfortunately some things are inherently complex, and as you try to wrap them behind simplistic abstractions there comes a point where you simply can achieve what you want. Suddenly you, and your current task is one of the things that the designers abstracted away. The quote about "we didn't realise people would try and download it from the downloads page" is a classic example.
He actually said that academics in a computer science department use it. Don't you think that they count as developers? His anecdote isn't that uncommon, on the academic research projects that I've worked on Macs are used much more heavily than other systems. My current project may be a bit extreme but more than 90% of the participants use a mac. They are all developers - across a wide range from people who are optimising low-level assembly routines, people developing in C, through to some higher level domain specific languages.
My own work patterns haven't changed that much since I moved from a linux box. iTerm has a full-screen mode, and I've always written code in vi. There's a decent version of gcc, and the other languages that I need like python, perl, prolog and others are all available and quite stable.
I find it quite amusing that most people in this discussion are either mac-heads bashing linux users, or linux-users bashing mac heads. It is a refreshing change to find that windows doesn't even make the minimum grade for people to bother attacking it. I just like the combination of stable hardware support (especially given that I use a laptop and power-saving and hibernation are vital) with a unix interface. Maybe I missed the compulsory religious indoctrination session, so I probably don't count as a "proper" mac fan...
You don't know it yet (not meant as a jibe but it is something that clicks in after your PhD) but your primary function as a scientist is not to make discoveries. It is spreading knowledge. Sometimes that dissemination will occur in a narrow pool, through journal papers between specialists in that narrow pool of talent.
This is not the primary goal of science, although it can seem like it when you are slogging away at learning your first specialisation well enough to get your doctorate. Occasionally a wave from that little pool will splash over the side - maybe someone will write a literature review that is read by a specialist in another field. A new idea will be found - after all sometimes we know the result before we know the context that it will be applied to.
The pools get bigger as you move further downstream. Journal articles pass into conference publications, then into workshops. Less detail but carried through a wider audience. Then after a time, when the surface seems to have become still textbooks are written and the knowledge is passed on to another generation. We tend to stick around and help them find the experience to use it as well. This is why all PhD students have an advisor to point out the best swimming areas.
That was the long detailed answer to your question. The simple version is that you don't know who your target audience is yet. And limiting it to people in institutions that pay enormous access fees every year is not science. As a data-point - a lot of European institutes don't bother with IEEE fees. They run to about £50k/year which simply isn't worth it. As a consequence results published in IEEE venues are cited less in Europe. So even amongst the elite access walls have an effect.
What incentive does a massive industry have to solve cancer, when it would put them out of business? Tens of thousands of people have dedicated most of their adult lives, usually to studying specific mechanisms and biological functions so narrow that if cancer were cured tomorrow, they would be useless- their training and knowledge is so focused, so narrow- they cannot compete with the existing population of researchers in other biomedical fields. Journals which charge big bucks for subscriptions also would be useless. Billions of dollars of materials, equipment, supplies, chemicals- gone. "Centers", hospitals, colleges, universities which each rake in hundreds of millions of dollars in private, government, and non-profit sourced money would be useless.
That's an old argument and although it sounds reasonable it is completely unsound. An industry does not function as a single cohesive entity with wants and desires. It is composed of many different individuals with their own wants and desires.
I know enough academics to say for certain that if any one of those individuals could discover a cure that would put their entire employer out of business then they would leap at the chance. The fame that would follow would make another job easy enough to get, and the recognition is what they're really in it for anyway.
There is enough information on that card to create a horse within the environment of a horse. There is nowhere near enough information to create a horse from scratch.
Look at the new cloning projects trying to bring back extinct animals from the dead. The first step is to find a living species that is genetically close enough to act as a surrogate host.
That's because the author is a well-know internet crackpot and troll. He has cunningly redefined all of the technical terms that those evil authority-loving scientists use to make his arguments. Which are a pretty crap reinvention of dataflow programming. I wouldn't waste too much time on rebelscience unless it's just for the shits and giggles.
Oddly enough it is not that easy to kill someone and get away it. Don't let it stop you trying to build a strawman, it seems to be the only style of argument that you know.
You managed to read one sentence, well done. Shame you didn't get as far as:
I'm not saying that I support that point of view, so don't bother arguing it. But at least I can understand what their point of view is.
Natural Freedom is not a rhetorical device, nor is it a political statement. I'm pointing out that copying is inherently easy, and nothing that we do will ever change that. The best hope that we have is to try and enforce social contracts, but this doesn't change the fact that we are trying to stop people from doing something that is easy. We can't take that capability away from them, only dissuade them.
If you managed to read this far then you'll realise why the rest of your post was completely redundant.
So we'd have lost out on some burnt cakes, but gained some good bacon, and a huge improvement in centuries of beer tradition... count me in. Let me be the first to welcome our parallel reality Danish overlords...
Numbered seating isn't all that bad. I've been to cinemas where they do, and where they don't. Cinemas without preassigned seating never get completely full, because people don't like to choose a seat next to a strange when another seat is available. So you end up with "holes" of 1-2 seats between each group that are hard to fill. With assigned seating it is usual (for a popular film) for every seat to go.
I'm used to cinemas without assigned seating, but on the few times that I've been to cinemas that assign first the atmosphere has been better. In terms of catching people with camcorders, as other people have pointed out if you paid cash then it won't help at all.
On the cellphones, one of your other replies moaned about people using cellphones in movies. That must be a cultural difference. In the uk answering a mobile phone during a film would be a lynching offence. I've seen people try it, and an entire cinema full of people baying for their blood.
Actually most of those have good reason, just not reasons that you, or I, or any other viewer of TV would find acceptable. The constant repetition and tight rotation is designed to bombard with the same advert lots in a small period of time. Because it's based on psychological studies that show advertising is more effective that way. Of course effective does not mean making you aware of their product, it means making you more likely to impulse buy it. This is much like training a dog, or domesticating any other kind of animal.
The loudness is a serious annoyance, but the rationale is that some purchasers may have fallen asleep during the show so waking them up would be good. Even if you don't wake them up completely hitting them with advertising audio while they're drifting back into REM will be very effective. The 1/3rd of air-time is an American thing. I always find it pretty shocking, and don't know how any of you watch tv at all. When "hour long" American shows are on tv in the uk they are put into 45 minute slots....
I'd be quite happy to pay for decent tv shows that were completely free of advertising and DRM. That's exactly what I said about music, and since iTunes lost the drm I've been opening my wallet to fill my boots. It's been too many years of watching tv on-demand, advertising free and normally at better bitrates than the crap they put on cable over here to ever go back that way. TV died a long time ago, it's about time they buried the corpse.
Although you are correct in a moral indignation sense, sadly you are wrong in an actual reality sense. Instruction sets have been patentable for may years, and form a large part of the Intel / AMD war-chest that they can threaten impudent upstarts with. The standard trick that gets used (and has been defended in court) is to claim that the instruction is a method of encoding a particular process. Once you reduce things to a process a patent examiner, and then a court are more likely to go along with you.
No, it shows that the poster that you are arguing with understands the different physical constraints between volatile and persistent storage. He also understands that we can make external storage look like RAM already, and the reason that we don't do so is that abstraction would kill performance for most applications that need to be aware of the distinction.
You have nothing in response other than "blah blah imagination I'll be right in ten years". Yeah, course you will sunshine. As we progress down the fab sizes I'm sure that the distinction that volatile memory only needs to store a charge for a tiny amount of time (true looking back through DRAM all the way to mercury delay lines) where-as persistent storage needs more power to flip a state in some sort of field, ie magnetic.
But of course, that's lack of imagination and physics will be drastically altered in the next ten years. I can't understand why nobody has seen you for the visionary that you are...
ObjectStore came out in 1988. The version that we used back in 1998 definitely performed this mapping for C++ code. I don't know if it counts as prior art because I can't remember how it handled the schemata for the mapping.
Yes. It's called a battery
As you are the third reply to make the same point (although in more detail than the previous two) let me make myself clear.
OOP is not a well defined concept. The parts that are well defined - that a system should be constructed from smaller units called objects which combine data and code - are shared across all of the languages that claim to support OOP. One basic difference between possible implementations of OOP is the decision for whether or not object boundaries should be strict, or loose.
It is possible to define OOP in such a way that there are hard lexical boundaries around each object, and access is only possible using get/set methods. If the choice to define OOP in this way is made, then it can be shown that the result object is equivalent to a closure. It can also be shown that it is equivalent to a process, as the restriction on state management via explicit set/gets is a form of MPI.
The fact that we can derive a clean and elegant formulation of OOP that has these nice properties does not mean that OOP is general has these nice properties. In particular none of the mainstream language with OOP support use this strict lexical scoping over objects, and as a result the objects in most OOP systems are not equivalent to closures, or to processes, or to anything well-defined enough to be useful.
That is the distinction that I was making somewhat loosely on the earlier poster who came out with the bold claim that objects (no context given) were equivalent to closures. This claim can only be made in such general terms from somebody so deeply sucked in Scheme that they have forgotten it is not the whole world. And of course I stand by my original claim to the OP that OOP is not a paradigm, although I will now modify that slightly to make explicit the trivial consequence that (like imperative programming in general) with suitable restrictions it can be equivalent to other well-known paradigms.
As I pointed out earlier in the thread, it's not a language that I'm familiar with. After a quick look at the samples on smalltalk.org it looks like an Imperative language.
I get this idea from the way that OOP is implemented in the mainstream languages (Java, C++, Python...). What you are describing is familiar to me, although not under the label OOP. I've seen it in process oriented languages like Occam. After a wee bit of background research I see that OOP as you're describing it, and Smalltalk implemented it, is quite a different beast to what I'm used to. It's a shame Smalltalk wasn't invented a decade later :)
As for my original point about OO not being a separate paradigm as the OP mentioned; it's less obvious now. "Pure" OOP (as the Smalltalk page called it) does seem to be quite a different beast, although it is unclear to what extent the evaluation would be different to functional programming.
Analysing the timing behaviour of assembly language programs for embedded systems. Haskell was used for the majority of the analysis, with perl used to munge data about prior to processing. Huge fun to write, but left me with a lasting desire never to combine perl and Haskell again...
Not only do I not realise it I would argue strongly that it is wrong :) You are correct that both closures and objects contain a state and a function(s). But the object allows direct manipulation of the state by the external world, while the closure does not. Hence the set of operations that can be performed on the object is open (as the whole purpose is to allow functional extension), while on the closure the set is closed. Hence the semantics may look superficially similar, but there is a deep difference between them.
I'd be interested to know if that was your opinion, or if you've picked it up somewhere from the literature. Arguing about semantics always comes down to the details and it would be interesting to know what model of closures / objects gives rise to an equivalence.
I'd agree with this completely. I've worked on a few large multi-language projects, and had to combine flavours of asm, C, C++, perl, prolog, bash, maple, haskell, java and a few others together to get what I want. After years of working this way, and stumbling over the questions posed in the article (integrating build processes, dev environment etc) I had my arm twisted into using Python. What a joy it has turned out to be.
As someone with a background in functional programming (most of my PhD was implemented in Haskell) the "functional" programming support in Python is a bit barren - but list comprehensions and bound methods are powerful enough for most tasks. The shell integration is nice, and the regexps are simple enough that I hardly touch perl these days (thank god...). Sage replicates most of the functionality that I would use maple or magma for.
A sibling (AC) poster complains that Python is not "the one true language" (tm) that the parent asserts it is. Well the parent makes no such assertion. I would assert that if you want a single True Language then Python would be a good candidate for you. But if you like multi-language programming then Python is good glue. Personally I like it as glue, shockingly other people may have different uses for it. Lastly, a general word on the whole monolithic application vs small tools in multiple languages. This isn't a new debate that has sprung up in the past decade. It has always been there. There isn't even really a debate, because the two approaches are building tools for disjoint sets of users.
If you eat your own dog-food, it's vital that you have the quickest turnaround time possible on adding new features and trying out new ideas. In a sense you are continually prototyping, never finishing. You are your own end-user, although occasionally other people may pretend. As a result your target audience is highly literate in the languages that you are using, and wants to maximise the power of the tools with a programmatic interface. The unix-philosophy was constructed to service this case.
If your target user is a non-programmer, who simply wants to be able to perform a task then you will need to wrap up the functionality in a non-programmatic way. GUIs are the best way (so far) of doing this. Because there is no intention of exposing an external call interface the overhead of mapping from language to language becomes pure overhead and there is a natural tendency towards a single monolithic language approach.
The interesting gap between these two areas is when your target audience spans the non-technical and the technical. This is where monolithic applications with APIs and scripting interfaces appear. I've got to say that AppleScript is quite cute in this area, purely because it's pervasive enough that it reminds me of Arexx all those years ago...
I would read it as sarcasm. Try reading this manifesto and updating Fortran to C to account for 20 years of shift in the industry. Anyone not using C is just eating Quiche.
Although his joke went over your head, it is worth pointing out that OO is not a paradigm. I know wikipedia thinks that it is, and so do a hoard of practically illiterate researchers publishing crap papers in junk conferences. But that doesn't make it true. Object Orientation is just a method of organisation for procedural languages. Although it helps code maintenance and does a better job of unit management that modules alone, it doesn't change the underlying computational paradigm. I say procedural languages because class-based programming in functional languages is actually a different type of beast although it gets called OO to appeal to people from an imperative background.
It totally makes up for all that tentacle porn...
Well, when you point it out...
It's the law of unintended consequences. The vision at Microsoft has always been to try and reduce complexity. Whenever there has been a tradeoff between control and simplicity, Microsoft has chosen simplicity. Unfortunately some things are inherently complex, and as you try to wrap them behind simplistic abstractions there comes a point where you simply can achieve what you want. Suddenly you, and your current task is one of the things that the designers abstracted away. The quote about "we didn't realise people would try and download it from the downloads page" is a classic example.
Which of course was exactly the point that Neal Stephenson made in the essay In the beginning was the command line.
He actually said that academics in a computer science department use it. Don't you think that they count as developers? His anecdote isn't that uncommon, on the academic research projects that I've worked on Macs are used much more heavily than other systems. My current project may be a bit extreme but more than 90% of the participants use a mac. They are all developers - across a wide range from people who are optimising low-level assembly routines, people developing in C, through to some higher level domain specific languages.
My own work patterns haven't changed that much since I moved from a linux box. iTerm has a full-screen mode, and I've always written code in vi. There's a decent version of gcc, and the other languages that I need like python, perl, prolog and others are all available and quite stable.
I find it quite amusing that most people in this discussion are either mac-heads bashing linux users, or linux-users bashing mac heads. It is a refreshing change to find that windows doesn't even make the minimum grade for people to bother attacking it. I just like the combination of stable hardware support (especially given that I use a laptop and power-saving and hibernation are vital) with a unix interface. Maybe I missed the compulsory religious indoctrination session, so I probably don't count as a "proper" mac fan...
Trickle-down. Dissemination of knowledge.
You don't know it yet (not meant as a jibe but it is something that clicks in after your PhD) but your primary function as a scientist is not to make discoveries. It is spreading knowledge. Sometimes that dissemination will occur in a narrow pool, through journal papers between specialists in that narrow pool of talent.
This is not the primary goal of science, although it can seem like it when you are slogging away at learning your first specialisation well enough to get your doctorate. Occasionally a wave from that little pool will splash over the side - maybe someone will write a literature review that is read by a specialist in another field. A new idea will be found - after all sometimes we know the result before we know the context that it will be applied to.
The pools get bigger as you move further downstream. Journal articles pass into conference publications, then into workshops. Less detail but carried through a wider audience. Then after a time, when the surface seems to have become still textbooks are written and the knowledge is passed on to another generation. We tend to stick around and help them find the experience to use it as well. This is why all PhD students have an advisor to point out the best swimming areas.
That was the long detailed answer to your question. The simple version is that you don't know who your target audience is yet. And limiting it to people in institutions that pay enormous access fees every year is not science. As a data-point - a lot of European institutes don't bother with IEEE fees. They run to about £50k/year which simply isn't worth it. As a consequence results published in IEEE venues are cited less in Europe. So even amongst the elite access walls have an effect.
What incentive does a massive industry have to solve cancer, when it would put them out of business? Tens of thousands of people have dedicated most of their adult lives, usually to studying specific mechanisms and biological functions so narrow that if cancer were cured tomorrow, they would be useless- their training and knowledge is so focused, so narrow- they cannot compete with the existing population of researchers in other biomedical fields. Journals which charge big bucks for subscriptions also would be useless. Billions of dollars of materials, equipment, supplies, chemicals- gone. "Centers", hospitals, colleges, universities which each rake in hundreds of millions of dollars in private, government, and non-profit sourced money would be useless.
That's an old argument and although it sounds reasonable it is completely unsound. An industry does not function as a single cohesive entity with wants and desires. It is composed of many different individuals with their own wants and desires.
I know enough academics to say for certain that if any one of those individuals could discover a cure that would put their entire employer out of business then they would leap at the chance. The fame that would follow would make another job easy enough to get, and the recognition is what they're really in it for anyway.
It's a nice idea, but not actually true.
There is enough information on that card to create a horse within the environment of a horse. There is nowhere near enough information to create a horse from scratch.
Look at the new cloning projects trying to bring back extinct animals from the dead. The first step is to find a living species that is genetically close enough to act as a surrogate host.
That's because the author is a well-know internet crackpot and troll. He has cunningly redefined all of the technical terms that those evil authority-loving scientists use to make his arguments. Which are a pretty crap reinvention of dataflow programming. I wouldn't waste too much time on rebelscience unless it's just for the shits and giggles.
Fair enough. Good point, well made.
Oddly enough it is not that easy to kill someone and get away it. Don't let it stop you trying to build a strawman, it seems to be the only style of argument that you know.
You managed to read one sentence, well done. Shame you didn't get as far as:
Natural Freedom is not a rhetorical device, nor is it a political statement. I'm pointing out that copying is inherently easy, and nothing that we do will ever change that. The best hope that we have is to try and enforce social contracts, but this doesn't change the fact that we are trying to stop people from doing something that is easy. We can't take that capability away from them, only dissuade them.
If you managed to read this far then you'll realise why the rest of your post was completely redundant.