This city is part of the Indus valley civilisation. Most scholars believe the Indus language and culture were Dravidian, that is pre-Aryan and (probably) pre anything like Hinduism.
Hancock disagrees, but then, as you say, he's not the most reliable source of evidence.
He also said "[UML's] real strength is at the object (ie. implementation) level", which was where I stopped reading. Using OO modelling techniques does not imply that one is modelling the OO implementation. Conceptual and specification level models are much more practical and useful. For a start, you don't need A0 paper to print them out on.
Seriously, though, we already have a implementation model. Its called "the code". The only reason to model implementation in UML is if you want to use some code generation thingy because typing method and class declarations is somehow too onerous for you. The best use for UML (IMHO) is to model the system at a level that lacks many of the implementation details that don't impact the system concepts or overall design. These things can get lost in the code, and thus modelling them can be a real benefit.
But I'm a bit suspicious of the claim that a Cherokee chief said Madoc's people were called "welsh". Welsh is an old English word meaning "strangers" or "enemies". Welsh people (as I guess you know) would have called themselves "cymraeg", or even "British" (Prythaeg ?).
Henry Sinclair beat the Chinese by another 30 years. When he got there he found people in Nova Scotia speaking a Celtic dialect, He, in turn, was directed there by a couple of Venetians. The Vikings beat him by a few hundred years, and there is plenty of evidence that European fishermen had been sailing across the Atlantic pretty much all through history.
The only thing that makes Columbus different is that by the time he got there the mechanisms and motivation to publicise the discovery and start the process of conquest and colonisation were in place.
I can see the goal. However the proposed mechanism is basically ghastly. It allows you to stick extra bits of invisible code in all over the place that get executed without anyone even realising they're there. Its a similar problem to operator overloading, or C#/Delphi's property mechanisms, only much, much worse.
To make it work better, something has to be done to reduce the power of the mechanism. Say, preventing the "apsects" from having any having any side-effects that affect the code that triggers them.
A very long time ago, someone suggested a programming construct called "COMEFROM" that allowed you to declare you code to be called from somewhere else, regardless of whether the caller wanted to or not. That was a joke. Obviously no sane person would suggest being able to write code that gave you no clue what other code was being invoked, right ?
Well, apparently, this is exactly what a supposed expert on design is now suggesting. Code that executes on arbitrary conditions. Stuff that executes before and after your methods that changes their results. I can only conclude, given that Booch is clearly not joking, that this is a conspiracy to lower the quality of software and thereby drive more poor benighted, deluded souls into the arms of the Ration Unified Straightjacket and mechanistic OO design methodologies.
You can write unmanaged C++ and target the CLR, in the sense that the compiler will generated CIL, and a CLR-compliant execution environment will be able to run it. What you cannot do is have the CLR understand your C++ classes and objects as classes and objects, because the CTS object systems only supports single implementation inheritance, uses a garbage collector and so on. To shoehorn C++ classes into the CTS object model you have to use managed C++ (which is really gross lookinng).
In order to interoperate with other CLR languages you need to comply with the CLS as well. This limits the use of various things. I think it is at this level that you lose templates.
You could explain to anyone with a modicum of intelligence how C's pointers differ from object references in Java in about 10 minutes. Anyone with a CS degree will know about the memory model of computers well enough to understand.
I don't know what planet you live on, but on mine "top coding jobs" rarely hire people on the basis on knowledge of awkward features of aging programming languages.
There are huge numbers of major Java projects. You just haven't seem them because they are used internally by large corporations in "invisible" roles. Absence of evidence is not evidence of absence. I happen to have lots of evidence of presence.
I largely agree with you about Smalltalk. I often rant in a similar veign myself. I just want to present some things that have given Java (at least) something of an advantage:
1. Memory usage. I know its somewhat spurious, but things like VisualWorks could get really huge. Squeak is better, and of course computers have largely caught up, but Java's one-application-per-process approach and dynamic class loading has arguably been more practical than the Smalltalk wopping great image file approach.
2. Dynamic compilation. OK, it was invented for Self, which is arguably even neater than Smalltalk, but its finally found widespread use with Hotspot.
3. Static typing. I'm unconvinced myelf, but a lot of people are very suspicious of dynamically typed languages, probably because they're confusing dynamically typed with weakly typed. However, it does help with static analysis - although of course 99% of Java environments don't do this.
Regarding A: The JVM and CLR are at a higher level of abstraction that assembler. As such, they limit the range of languages that can be implemented more than assembler. This is more true of the JVM than the CLR, but both of them include high level object-manipulation instructions that you don't get in most assemblers that make them more suitable for some kinds of languages than others. Notably, garbage collected, statically types, single dispatch, single inheritance languages like C# and Java work better than most others.
That error is covered on Lomborg's website at www.lomborg.com in the "corrections" section. There is also a complete rebuttal of the WRI/WWF critique under "criticism/responses". To summarise: they are selective, and they misrepresent.
Come to that, some of the SA rebuttals are OK too. However, it is Lester Brown, not Lomborg, who is fighting the scientific consensus on population, and EO Wilson spends most of his bit bemoaning being disturbed from his majesterial slumbers, and attacking Lomborg's credentials. Like Wilson is great respecter of intellectual turf. Not.
Lomborg is largely in agreement with other environmental scientists in this. However, their concern tends to come through to the general public as a conviction of impending doom. This is the problem SE was written to counteract.
No conspiracy is required. Lomborg is exactly with the scientific consensus in most of what he says. His criticisms are mostly of the interpretations that have been made of the scientific data.
The book published in Denmark was less complete than that published in the UK and USA. It also contained several errors that have been corrected, as well as some that have not.
I seriously recommend that you read the book as well as the rebuttals. Many of them badly misrepresent Lomborg's case.
Go and read the book. Now. Or at least look at it. Creation scientists are basically at odds with the whole edefice of scientific naturalism. Lomborg is just saying that some of the claims often made about the environment are wrong. In most fields he is not contradicting the scientific consensus at all, just pointing out how it has been misrepresented. On some occasions, he does point out that claims made by scientists (biologists get a hard time) are not supported by empirical evidence, but you do not need to be a specialist to make such a judgement. Indeed, as a statistician, he has the qualifications required.
He is also eminently reasonable. If you go and read his website, you'll see several admissioms to errors in SE (seen Henry Morris do that ? thought not), and several serious efforts to answer his critics.
Now stop propogating slanders and go an learn what you're talking about.
Lomborgs claims are well within the remit of science. It behooves anyone who believes him to be wrong to reply as a scientist, not as a high priest trying to cast the impostor out of the temple. Its not like he's claiming the invisible sky pixie is going to save us or something.
Thank you. I've been wanting to write one for ages, and now you've done it for me, and written pretty much exactly what I would have done. Now, if you'd just post it to kuro5hin, that would be even better:)
A couple of random points: Are you sure that Lomborg's cost-benefit analyses ignore costs to the extent you imply ? My understanding is that he's included all effects that could impact humans, but ignored those that only impact the natural world. Of course, such analysese are tricky, and arguable completely worthless, so there's no guarantee he has got it right. However, in principle, if the lesser-spotted fenge cricket of outer mongolia has no known impact on human wellbeing, it seems quite defensible not to consider its loss a cost.
I agree that catastrophic changes, such as switching ocean currents, or positive feedbacks, are very serious possibilities. These kinds of things, where the probability is low or unknown, but the potential consequences are catastrophic, are the hardest issues to deal with. I cannot buy into the "precautionary principle", that we must avoid possible problems, even if there is no evidence that there really is a problem, because it seems to undermine out standards of evidence.
I agree absolutely about the treatment Lomborg has received. It is a disgrace. The number of scientists who have butted in merely in order to dismiss his credentials, or complain at even having to respond, and then obviously failed to even read the book is appalling. It is equally appalling how many people on the "other side" have picked up Lomborg and equally misrepresented him as being completely opposed to all environmental controls. Unfortunately all these misrepresentations, which oddly enough turn out to be very similar, show up in the comments here. On that note:
Lomborg does not claim everything is fine. Nor does he claim all environmental research is fraudulent. Indeed, he cites lots of it. Although many of his critics have accused him of abusing statistics, very few such claims appear to be supported (one or two are). Its just easier to snicker "lies, damned lies, and statistics" than it is to engage in a serious argument. A few serious errors in the book have been spotted by various people, but these do not, in fact, damage the book as a whole.
To see that, you have to understand the skeleton of the argument being made. This breaks up into bits. The first "big picture" claim is that most people believe things that are just plain wrong about the state of the world: that population is growing out of control, or that disease is more prevelant now than ever before. Lomborg refers to this broadly eroneous picture of doom as "the litany". Environmentalists tend to play on this, even though they often know it to be incorrect, because it helps their cause. Lomborg takes them to task for this.
However, Lomborg also makes a series of other, largely unconnected, claims about the scientific consensus in different fields. For instance, he disagrees with many biologists about species extinction rates, and with the IPCC about the Kyoto treaty, but agrees with the UN about population growth. These various claims stand or fall alone, and although they reinforce the overall case that most people have an exaggerated idea of how bad environmental problems are, attacking one does not destroy the whole thesis of the book. In different fields, Lomborg is either with the consesus, but that consensus has failed to penetrate the media and acitivist organisations (population), differs only slightly from the consensus, but believes the political action being taken is wrong (global warming), or opposes the consensus because he believes it to lie on statistically shaky foundations (species extinction).
And I thought it was a simple statement of fact. Technology X existed at time Y. Language Z was invented at time Y+1. Language Z did not include technology X. Ergo, either the inventors of Z were ignorant of X, or chose not to use it. Its not exactly difficult. Take a day off and work it through for yourself.
Or at least confusing. A JIT compiler is simply a technique for implementing a VM. Technically, a VM is a defined bytecode and data model, *not* a piece of software. To say that VMs always interpret is a terrible misrepresentation. Several languages - those that invented "JIT" technology, such as Smalltalk and Lisp - have referred to systems involving bytecode to machine language conversion as VMs since the very beginning. I don't see any reason to change that terminology now. Several MS representatives have referred to the CLR as a VM. Now stop confusing the issue.
You're wrong on the other point too. The CLR specifically supports the type system described by the CTS. IL's instructions operate specifically on those types. You can, of course, implement any set of language semantics you like, but it won't necessarily be either efficient or worthwhile. Why else do you think Meyer has cut Multiple Inheritance and covariance entirely out of Eiffel# ? The same goes for C++: only "managed C++" (C# that looks like C++) actually compiles to the CLR as a target, and guess what ? Managed C++ does not support multiple inheritance.
You really should learn what you're talking about before "explaining" it.
The progress apparent in Java had mostly already been made by 1980, around the same time C++ was being created. The problems with C++ are a result of either ignorance or a deliberate decision to ignore those advances.
VMs, JITs and C#
on
What is .NET?
·
· Score: 3, Insightful
The author is confused about JIT compilers and virtual machines. A virtual machine is just a piece of software that executes programs in some machine-code-like language. It does not necessarily interpret the instructions. Indeed, almost all virtual machines compile to the local machine's instruction set at some point.
A JIT compiler is a technique used in virtual machine design to speed execution. Technically, a JIT compiler ought to compile code as it reaches it on the execution path for the first time, but thanks to some sly work by Symantec, its become acceptable to call something a JIT compiler even if it actually compiles all the code at load time regardless of whether it is executed or not. Hence the complaints about Java's startup time. Microsoft's efforts in this direction seem faintly bizarre to me. All previous evidence is that keeping compiled code around between runs is not worth it. However, I suppose since they only really support one platform, it won't really cause any problems.
C# is very much not "C++ for rapid application development". It's a completely different language, much more closely related to Java. While C# and Java share C++'s syntax, their underlying semantics are more closely related to Beta or Smalltalk.
As I would expect from someone who obviously doesn't know much about VM or language design, the author also makes far too much of the CL?'s cross-language abilities. While it has good support for implementing functional languages, as far as the much more important OO features are concerned, it is only going to work well for statically typed, single inheritance, single dispatch languages that don't need to do any code generation. Its is my contention that any OO language that can be implemented on the CLR can be implemented equally well on teh JVM.
Slashdot Mirror
This city is part of the Indus valley civilisation. Most scholars believe the Indus language and culture were Dravidian, that is pre-Aryan and (probably) pre anything like Hinduism.
Hancock disagrees, but then, as you say, he's not the most reliable source of evidence.
He also said "[UML's] real strength is at the object (ie. implementation) level", which was where I stopped reading. Using OO modelling techniques does not imply that one is modelling the OO implementation. Conceptual and specification level models are much more practical and useful. For a start, you don't need A0 paper to print them out on.
Seriously, though, we already have a implementation model. Its called "the code". The only reason to model implementation in UML is if you want to use some code generation thingy because typing method and class declarations is somehow too onerous for you. The best use for UML (IMHO) is to model the system at a level that lacks many of the implementation details that don't impact the system concepts or overall design. These things can get lost in the code, and thus modelling them can be a real benefit.
1. Einsteins ? What the hell ? OK, so the author wanted to avoid "geeks", and "tech workers" is too long, but honestly ...
2. Most of the advice is applicable to managing *anybody* not hopelessly demoralised and/or terminally stupid.
3. "Peopleware" already tackled many of these issues without having to flatter its audience so much.
But I'm a bit suspicious of the claim that a Cherokee chief said Madoc's people were called "welsh". Welsh is an old English word meaning "strangers" or "enemies". Welsh people (as I guess you know) would have called themselves "cymraeg", or even "British" (Prythaeg ?).
Henry Sinclair beat the Chinese by another 30 years. When he got there he found people in Nova Scotia speaking a Celtic dialect, He, in turn, was directed there by a couple of Venetians. The Vikings beat him by a few hundred years, and there is plenty of evidence that European fishermen had been sailing across the Atlantic pretty much all through history.
The only thing that makes Columbus different is that by the time he got there the mechanisms and motivation to publicise the discovery and start the process of conquest and colonisation were in place.
I can see the goal. However the proposed mechanism is basically ghastly. It allows you to stick extra bits of invisible code in all over the place that get executed without anyone even realising they're there. Its a similar problem to operator overloading, or C#/Delphi's property mechanisms, only much, much worse.
To make it work better, something has to be done to reduce the power of the mechanism. Say, preventing the "apsects" from having any having any side-effects that affect the code that triggers them.
A very long time ago, someone suggested a programming construct called "COMEFROM" that allowed you to declare you code to be called from somewhere else, regardless of whether the caller wanted to or not. That was a joke. Obviously no sane person would suggest being able to write code that gave you no clue what other code was being invoked, right ?
Well, apparently, this is exactly what a supposed expert on design is now suggesting. Code that executes on arbitrary conditions. Stuff that executes before and after your methods that changes their results. I can only conclude, given that Booch is clearly not joking, that this is a conspiracy to lower the quality of software and thereby drive more poor benighted, deluded souls into the arms of the Ration Unified Straightjacket and mechanistic OO design methodologies.
public class Hello {
public static void main(String[] args) {
System.out.println("Hello !");
}
}
compare:
#include "stdio.h"
int main() {
printf("Hello !");
}
5 lines each. Its a draw.
You can write unmanaged C++ and target the CLR, in the sense that the compiler will generated CIL, and a CLR-compliant execution environment will be able to run it. What you cannot do is have the CLR understand your C++ classes and objects as classes and objects, because the CTS object systems only supports single implementation inheritance, uses a garbage collector and so on. To shoehorn C++ classes into the CTS object model you have to use managed C++ (which is really gross lookinng).
In order to interoperate with other CLR languages you need to comply with the CLS as well. This limits the use of various things. I think it is at this level that you lose templates.
You could explain to anyone with a modicum of intelligence how C's pointers differ from object references in Java in about 10 minutes. Anyone with a CS degree will know about the memory model of computers well enough to understand.
I don't know what planet you live on, but on mine "top coding jobs" rarely hire people on the basis on knowledge of awkward features of aging programming languages.
There are huge numbers of major Java projects. You just haven't seem them because they are used internally by large corporations in "invisible" roles. Absence of evidence is not evidence of absence. I happen to have lots of evidence of presence.
I largely agree with you about Smalltalk. I often rant in a similar veign myself. I just want to present some things that have given Java (at least) something of an advantage:
1. Memory usage. I know its somewhat spurious, but things like VisualWorks could get really huge. Squeak is better, and of course computers have largely caught up, but Java's one-application-per-process approach and dynamic class loading has arguably been more practical than the Smalltalk wopping great image file approach.
2. Dynamic compilation. OK, it was invented for Self, which is arguably even neater than Smalltalk, but its finally found widespread use with Hotspot.
3. Static typing. I'm unconvinced myelf, but a lot of people are very suspicious of dynamically typed languages, probably because they're confusing dynamically typed with weakly typed. However, it does help with static analysis - although of course 99% of Java environments don't do this.
Regarding A: The JVM and CLR are at a higher level of abstraction that assembler. As such, they limit the range of languages that can be implemented more than assembler. This is more true of the JVM than the CLR, but both of them include high level object-manipulation instructions that you don't get in most assemblers that make them more suitable for some kinds of languages than others. Notably, garbage collected, statically types, single dispatch, single inheritance languages like C# and Java work better than most others.
That error is covered on Lomborg's website at www.lomborg.com in the "corrections" section. There is also a complete rebuttal of the WRI/WWF critique under "criticism/responses". To summarise: they are selective, and they misrepresent.
Come to that, some of the SA rebuttals are OK too. However, it is Lester Brown, not Lomborg, who is fighting the scientific consensus on population, and EO Wilson spends most of his bit bemoaning being disturbed from his majesterial slumbers, and attacking Lomborg's credentials. Like Wilson is great respecter of intellectual turf. Not.
Lomborg is largely in agreement with other environmental scientists in this. However, their concern tends to come through to the general public as a conviction of impending doom. This is the problem SE was written to counteract.
No conspiracy is required. Lomborg is exactly with the scientific consensus in most of what he says. His criticisms are mostly of the interpretations that have been made of the scientific data.
The book published in Denmark was less complete than that published in the UK and USA. It also contained several errors that have been corrected, as well as some that have not.
I seriously recommend that you read the book as well as the rebuttals. Many of them badly misrepresent Lomborg's case.
Go and read the book. Now. Or at least look at it. Creation scientists are basically at odds with the whole edefice of scientific naturalism. Lomborg is just saying that some of the claims often made about the environment are wrong. In most fields he is not contradicting the scientific consensus at all, just pointing out how it has been misrepresented. On some occasions, he does point out that claims made by scientists (biologists get a hard time) are not supported by empirical evidence, but you do not need to be a specialist to make such a judgement. Indeed, as a statistician, he has the qualifications required.
He is also eminently reasonable. If you go and read his website, you'll see several admissioms to errors in SE (seen Henry Morris do that ? thought not), and several serious efforts to answer his critics.
Now stop propogating slanders and go an learn what you're talking about.
Lomborgs claims are well within the remit of science. It behooves anyone who believes him to be wrong to reply as a scientist, not as a high priest trying to cast the impostor out of the temple. Its not like he's claiming the invisible sky pixie is going to save us or something.
Thank you. I've been wanting to write one for ages, and now you've done it for me, and written pretty much exactly what I would have done. Now, if you'd just post it to kuro5hin, that would be even better :)
A couple of random points: Are you sure that Lomborg's cost-benefit analyses ignore costs to the extent you imply ? My understanding is that he's included all effects that could impact humans, but ignored those that only impact the natural world. Of course, such analysese are tricky, and arguable completely worthless, so there's no guarantee he has got it right. However, in principle, if the lesser-spotted fenge cricket of outer mongolia has no known impact on human wellbeing, it seems quite defensible not to consider its loss a cost.
I agree that catastrophic changes, such as switching ocean currents, or positive feedbacks, are very serious possibilities. These kinds of things, where the probability is low or unknown, but the potential consequences are catastrophic, are the hardest issues to deal with. I cannot buy into the "precautionary principle", that we must avoid possible problems, even if there is no evidence that there really is a problem, because it seems to undermine out standards of evidence.
I agree absolutely about the treatment Lomborg has received. It is a disgrace. The number of scientists who have butted in merely in order to dismiss his credentials, or complain at even having to respond, and then obviously failed to even read the book is appalling. It is equally appalling how many people on the "other side" have picked up Lomborg and equally misrepresented him as being completely opposed to all environmental controls. Unfortunately all these misrepresentations, which oddly enough turn out to be very similar, show up in the comments here. On that note:
Lomborg does not claim everything is fine. Nor does he claim all environmental research is fraudulent. Indeed, he cites lots of it. Although many of his critics have accused him of abusing statistics, very few such claims appear to be supported (one or two are). Its just easier to snicker "lies, damned lies, and statistics" than it is to engage in a serious argument. A few serious errors in the book have been spotted by various people, but these do not, in fact, damage the book as a whole.
To see that, you have to understand the skeleton of the argument being made. This breaks up into bits. The first "big picture" claim is that most people believe things that are just plain wrong about the state of the world: that population is growing out of control, or that disease is more prevelant now than ever before. Lomborg refers to this broadly eroneous picture of doom as "the litany". Environmentalists tend to play on this, even though they often know it to be incorrect, because it helps their cause. Lomborg takes them to task for this.
However, Lomborg also makes a series of other, largely unconnected, claims about the scientific consensus in different fields. For instance, he disagrees with many biologists about species extinction rates, and with the IPCC about the Kyoto treaty, but agrees with the UN about population growth. These various claims stand or fall alone, and although they reinforce the overall case that most people have an exaggerated idea of how bad environmental problems are, attacking one does not destroy the whole thesis of the book. In different fields, Lomborg is either with the consesus, but that consensus has failed to penetrate the media and acitivist organisations (population), differs only slightly from the consensus, but believes the political action being taken is wrong (global warming), or opposes the consensus because he believes it to lie on statistically shaky foundations (species extinction).
And I thought it was a simple statement of fact. Technology X existed at time Y. Language Z was invented at time Y+1. Language Z did not include technology X. Ergo, either the inventors of Z were ignorant of X, or chose not to use it. Its not exactly difficult. Take a day off and work it through for yourself.
Or at least confusing. A JIT compiler is simply a technique for implementing a VM. Technically, a VM is a defined bytecode and data model, *not* a piece of software. To say that VMs always interpret is a terrible misrepresentation. Several languages - those that invented "JIT" technology, such as Smalltalk and Lisp - have referred to systems involving bytecode to machine language conversion as VMs since the very beginning. I don't see any reason to change that terminology now. Several MS representatives have referred to the CLR as a VM. Now stop confusing the issue.
You're wrong on the other point too. The CLR specifically supports the type system described by the CTS. IL's instructions operate specifically on those types. You can, of course, implement any set of language semantics you like, but it won't necessarily be either efficient or worthwhile. Why else do you think Meyer has cut Multiple Inheritance and covariance entirely out of Eiffel# ? The same goes for C++: only "managed C++" (C# that looks like C++) actually compiles to the CLR as a target, and guess what ? Managed C++ does not support multiple inheritance.
You really should learn what you're talking about before "explaining" it.
The progress apparent in Java had mostly already been made by 1980, around the same time C++ was being created. The problems with C++ are a result of either ignorance or a deliberate decision to ignore those advances.
The author is confused about JIT compilers and virtual machines. A virtual machine is just a piece of software that executes programs in some machine-code-like language. It does not necessarily interpret the instructions. Indeed, almost all virtual machines compile to the local machine's instruction set at some point.
A JIT compiler is a technique used in virtual machine design to speed execution. Technically, a JIT compiler ought to compile code as it reaches it on the execution path for the first time, but thanks to some sly work by Symantec, its become acceptable to call something a JIT compiler even if it actually compiles all the code at load time regardless of whether it is executed or not. Hence the complaints about Java's startup time. Microsoft's efforts in this direction seem faintly bizarre to me. All previous evidence is that keeping compiled code around between runs is not worth it. However, I suppose since they only really support one platform, it won't really cause any problems.
C# is very much not "C++ for rapid application development". It's a completely different language, much more closely related to Java. While C# and Java share C++'s syntax, their underlying semantics are more closely related to Beta or Smalltalk.
As I would expect from someone who obviously doesn't know much about VM or language design, the author also makes far too much of the CL?'s cross-language abilities. While it has good support for implementing functional languages, as far as the much more important OO features are concerned, it is only going to work well for statically typed, single inheritance, single dispatch languages that don't need to do any code generation. Its is my contention that any OO language that can be implemented on the CLR can be implemented equally well on teh JVM.