I would be impressed if you could find zillions of WordCraft users! Do that and I shall worship you as a god, since that's about the only way you could find that many.
Seriously, there's nothing fundamental in desktop publishing or word processing that can't be done with 1980s technology (WordCraft, LaTeX, etc). The improvement is primarily in the UI, since there are no really new underlying operations. But let's think about the UI for a moment. WYSIWYG is a very old design concept that has indeed also existed since the 1980s. The BBC Micro had many true WYSIWYG wordprocessors that supported multiple fonts and multiple language formats, so if Word is still not true WYSIWYG then those older wordprocessors were better at some things and you have to weigh that against those things Word can do that these museum-piece wordprocessors couldn't do.
What of the UI, though? DTP packages, such as Ventura Publisher, let you rubber-band writing areas and create complex layout templates. These are ooooooold. Are Word templates really that much more advanced? I'm not convinced. It would be very hard to generate the kinds of windowing you could do back then, or roll multiple documents into one unified presentation the way they did.
Integration? The Smart Integrated Package linked a database, wordprocessor and spreadsheet together in a way that data from one could directly be passed to any of the others. For its time, it was bloody amazing. The UI was extremely clean and could be adjusted according to your expertise, the macro language was primitive but very usable, documents were handled very cleverly using an ingenious pagination system making it very quick even on extremely long documents -- if the developers and management had retained that spark of creativity, it would likely still be a decent contender today. It failed because the brilliance was replaced with a stupidity that MTV could only marvel at. No idea why.
So, no, I'm not seeing the improvements. Menus have moved from the bottom of the screen to the top, but they're certainly not any better or cleaner than those on Smart. Images can be pasted in, which WordCraft didn't handle too well, but those systems back then that did support images handled the images at the quality they existed on disk. Word converts them to an internal format (which is inefficient, hogging disk space, and is nowhere near the quality of modern image formats), which is a major headache and lacks the professional look you could achieve with earlier systems.
Compiler architecture should be piped, with optimization as the absolute final stage. Compilers really aren't that modular, as demonstrated by the fragility of the API linking the frontend to the backend of GCC. Frontends have to be modified frequently to work with GCC, which would obviously not be the case if they were loosely coupled. This "steady refinement" (the word you want is "reification") is a bloody stupid description and if you don't understand the problem with early optimization you should go back to Software Engineering 101. You're a three digit UID, you really aught to have not only got the Dragon Book and understood it, but moved well beyond that point. Indeed, I'm fairly certain from your comment that you have.
You've also been around far too long to not know that whilst you can translate any paradigm into any other paradigm, the entanglements between logic and data differ between paradigms and that entanglement remains because it's built into the semantics of the programs.
The special purpose hardware for LISP was much faster than the general purpose hardware, and the Colossus computer rebuild proved something like 20x faster than the Pentium 1 for cracking Enigma codes because it was designed with that problem-space in mind and the Pentium wasn't.
The compiler's job is indeed to map the semantics, but where the semantics are highly inefficient on that architecture the compiler can't map any better than that. THAT is why code for the Itanium 2 and later has generally been horrible. The original processor design bugs were ghastly but were largely removed by the second iteration. However, compilers simply couldn't map the code to the architecture. That argument has been had already and you can look back through the Slashdot archives for it.
If semantics were sufficient and compilers were that great, we'd never use a programming language at all. Z would be sufficient. That defines all the semantics you need and compilers are quite capable of turning Z into instructions. Chances are that although there are hundreds of thousands of Slashdot readers, less than a dozen have ever programmed in Z*. Even hand-turning Z into code is so painful and difficult that you will find professors in computer science (including Linus' old lecturers) stating that it simply cannot be done for any program of any complexity. In fact, I seem to recall one of them posting just that on Slashdot as a rebuff to my complaint that too few people knew Z. (Compared to how long either of us have been on the system, these discussions are "new" so you've doubtless seen them.) If you haven't tried Z, I strongly recommend trying it out. It is by far the most powerful of all the Formal Methods ever developed, anything you can ever write in C can be written in Z (and vice versa), it is absolutely superb for creating provably-correct semantics, but nobody would dream of converting Linux into Z (they could, and it would let you eliminate all the bugs in the logic, leaving only bugs caused by hardware weirdness) because it's just too hard. Nor would anyone dream of writing a complex HPC application in Z, because although you can convert to C you can't convert a convoluted Z program to a C program that is high performance. In theory it would be great - HPC computers aren't cheap to run, so programs that will run correctly first time and every time would obviously be a Good Thing**. In practice, HPC programmers avoid Formal Methods like the plague. You cannot turn a Z program into a fast program.
*Software Engineering lecturers will likely barf at my claim Z is a programming language, but the fact is that that is exactly what it is. Programming is not distinct from pure maths, it is - and always has been - a subset of pure maths. A programming language is merely a mathematical representation of a problem in a form that uses a specific syntax that can be reified into a form that will run on a Turing-complete system. The fact that some syntaxes are supplied with popular compiler vendors is immaterial. Because compilatio
The following is what I could dig up on the effects of multi-lingualism. It does impact the brain in many different areas and there appears to be a growing belief that learning a new language at any age will have a pronounced impact on your ability to think and reason, but that if taught young the improvements are far more dramatic still. I didn't want to clutter the submission with this stuff, especially as these studies don't have nearly the same level of rigour as the MRI scans of the taxi drivers (where a whole host of variables can now be examined directly versus the somewhat more indirect studies done on polyglots). They're also a bit more controversial, with opposing studies claiming that the benefits either don't exist or don't exist in the way that is claimed.
There IS a fascinating "reverse" case, where alteration of the brain resulted in a remarkable alteration in musical ability, but as far as I know there has been no real work done on what changes the brain has undergone as a consequence of the new obsession.
That's actually a very good question. I'm not sure anyone has done that study, but I'd love to know the results.
If we go with current thinking (the Peter Principle, the idea that people generally will have their best ideas when young, the high failure rate of start-ups that appear to be by people moving out of regular industry, the apparent "strangeness" of inventors and innovators to those with a strong work ethic, etc) then the answer would be "almost certainly" for your first question, "quite likely" for your second and "yes but it's unimaginably rare" to your third.
However, you must bear in mind that until there's hard evidence of cause-and-effect, this is all supposition based on anecdotal evidence (which, if you remember your Dilbert videos, is only good for selling books) and apparent correlation. It seems very plausible, but without something a bit more solid I'm not confident anyone can give a real answer.
Code cannot be translated across paradigms efficiently. It is entirely possible to build an OO processor, provided the processor supports register banks. Functional programming is relevant to transistor networks because you can express things as contiguous flows between blocks of logic and contiguous flows between blocks of logic can be very easily handled by transistor networks. Far more so than procedural logic, which requires you to have a disjoint relationship between data and logic.
Compilers are crappy, for the most part, which is why Fortran is still used in maths. The level of effort that has gone into understanding how to compile Fortran programs is enormous and that's when the code mimics the way the CPU works. Further, not all paradigms are equal. Because of the complex relationship between code and data, OO will never be as efficient as procedural code, which will never be as efficient as functional code.
I don't regard Microsoft Word as much of an improvement over Wordcraft 80 or WordWise (a bow to those who recognize either name).
Well, I'd argue that there are lots of differences between good and bad programmers, often depending on what criteria is used for "good". In some cases, yes, expertise is a significant parameter. However, the primary "claim" made about higher-level programming languages is that smarter languages reduce the expertise factor. If that is the case, then expertise alone cannot explain why the 10x gap doesn't vary massively between the "generation" of the language or the paradigm of the language. Of course, one can argue that higher-level programming languages still require the same level of expertise, but in that case you'd be better off with having one language per "generation" per paradigm because having more than that dilutes the competency and therefore reduces expertise.
The Guardian and the BBC are hardly tabloid-class but they're still hyping the announcement. Both feel something important is going to be said, though both also say that no physicist actually believes so.
The news is likely of some sort of signal that doesn't meet the 5 sigma requirement of a discovery but which does look promising. As The Guardian notes, most of the other announcements of the "excluded range" kind have been given by junior staffers and not the top brass, which means it has to be something bigger -- but, as the physicists interviewed have pointed out, the energies are much too low right now to have discovered the Higgs boson.
The "best guess" outside of the "promising signal" department is that they've found something that doesn't match the Standard Model, that they've made an observation they can't explain without new physics. This would be the absolutely ideal case, since new science is far more exciting than merely confirming old theory.
The "next best guess" after that is that they've found data that backs up one of the GUT models. Being able to conduct "real science" on physics that has been more philosophical than experimental would be major news indeed.
I dunno. An electronvolt is about 1.6 x 10^-19 J, which means a teraelectronvolt is still only 1.6 x 10^-7 J, which Wikipedia helpfully says is the kinetic energy of a flying mosquito (the bug kind, not the WW2 aircraft). The energy of a mosquito, distributed over the entire collision chamber, doesn't seem to be a lot.
A language whose architecture mirrors that of the CPU can ALWAYS be compiled better and cleaner than a language whose architecture differs from that of the CPU (can != is, I'm talking limits not the state of compilers at any given time), but Aspect-Oriented and Object-Oriented CPUs don't exist at this time (although they could)
You are ALWAYS better off writing code in a language that suits the problem, rather than making the problem suit the language
At present, interfaces between different languages suck - a heterogeneous modular program where modules are written in suitable paradigm for the problem that specific module is designed to solve will have higher requirements to design but will also be cleaner and easier to maintain because you're not force-fitting
Compiler design is often flawed - GCC shouldn't optimize at all, for example, as early optimization is often bad optimization and makes platform assumptions that are increasingly invalid; optimization should either be in the linker or moved into a completely different program and run as a distinct stage in the chain
Most programmers are badly taught - Java programmers shouldn't be capable of writing programs less well-designed than Cobol programmers because Java should simply not allow the kinds of bad decisions that were commonplace in the 60s - which means a new language won't help unless it's rigorous and many programmers hate rigour because they don't know how to deal with it
Those who say they want a new language are often either unaware of what is already out there or aren't interested - they don't so much want a new approach to programming as they want the glory that goes with writing an "important" language
I wonder, how many of the languages listed on Freshmeat nee Freecode have people here actually used? Which ones do you know well enough to form a good, solid critique on what the language can and cannot do? Which compilers have you contributed code to?
Probably the answers would be "not many", "very few" and "almost none" respectively. And we're the geeks. We're the ones who are actually interested in this kind of stuff. Yet I'm willing to bet that even we couldn't form a sensible, rational, evidence-based opinion on "what is needed" because none of us has the breadth to know what has already been done and either found "not really to be needed at all" vs. "not used because nobody knows about it" vs. "a great concept but in the wrong language". Even we, the most obsessive bunch of nerds out there, simply don't have that kind of data. I reject utterly, therefore, the idea that anyone else is going to know so much more.
I'd argue that we need multiple computer languages and paradigms, but that we probably don't need as many as we have. I'm fluent in about 20 computer languages but that simply should not be necessary.
I'd be quite happy if the world reduced itself to Digital Mars' D, Occam-Pi, Erlang and Haskell. That would give us the necessary mix of procedural, functional and object-oriented languages to cover everything, and these languages are much better at developing correct software than many of the other languages out there. There are many languages which are "good" at something - Fortran is still the language of choice for mathematicians, Forth is brilliant for hardware control and C is good for developing fast general-purpose software - but these are problematic in that they make it very easy to write buggy, unreliable software.
If you want to narrow the range, then the languages chosen MUST be capable of producing code as powerful and fast as the "best of breed" without having the genetic defects which are the product of the inbreeding that have produced these languages. Haskell and OCaml are great at what they do, and compilers for them could certainly be improved upon to generate much better code, and could easily replace those languages which show definite deformities (Java, Visual Basic, C#, etc) but those alone won't replace the full range.
Occam-Pi and Erlang are more than capable of replacing C and Fortran for most purposes, including client/server and HPC, but aren't ideal for really low-level stuff and don't have the power of C++ to simplify horribly complex projects. D does, but you can't simply use D because there's a lot in Occam and Erlang for parallel programming that C-based languages just don't have. (Prior "debates"/wars on here over parallel programming and whether or not it's complicated ultimately boil down to the fact that most people insist on using languages that make it far harder than necessary to get results. Always, always, always use methodologies that are suitable for the problem-space rather than try to cram the problem-space to a specific methodology.)
It won't be a problem, as all of that (charred human remains included) would most likely be at the launch site, making it a tourist spectacle able to recoup the costs and lawsuits.
First, the guidance systems required are horribly complicated and need to be extremely reliable with almost no testing (each test is a launch and you get very few launches a year). That means you have to have competent engineers. As the Cobol-vs-Java discussion shows, competent engineers are something of a premium and always have been. The number who could actually put together a fully-functional fail-safe guidance system almost blind - no matter how much knowledge is out there - is extremely small. You also have to bear in mind that "reliable" doesn't just mean "it'll work perfectly under Earth gravity" - it has to work perfectly after being smashed with 3-4g forces along the vertical plus massive amounts of vibration from the rocket motors and side winds.
Second, the materials aren't cheap. I forget exactly how much it costs NASA to put something into orbit - isn't it something like $1000 per gram? - and that's with all the expertise on-site, the launch facilities and communications centers already existing and production-line facilities for the parts.
Third, the level of heath required is staggering. The forces involved are simply too great. Russia, hardly the epitome of transport safety, has refused wannabe millionaire space tourists on health grounds, where the issues would have been insignificant in any other line of work.
IP isn't even remotely a factor in all of this. Until titanium is as cheap as aluminium (which it could be if they ever developed a decent refining process for it), until programmers and hardware engineers are capable of making near-flawless products first time, every time, space travel will remain expensive.
This is why, despite Bloddhound SSC publishing the complete specifications, not a single hacker is going to build and race one. They could - the information is out there - but they haven't the skills. And a car is trivial compared to a spaceship.
That's fine and all part of science - learning naturally alters what you know. From that perspective, it's hardly a surprise. Earliest dates for cooking, advanced stone tool making, etc, have been pushed back by far more significant amounts this year. Domestication of horses may also have been much earlier, but for some curious reason the scholars there have......declined to release the data. Anyways, I don't regard that part as being particularly news.
The newsworthy elements to this story:
* Further evidence of abstract and indirect thinking in early humans, pretty much putting beyond question that these skills existed back then * Further evidence of society evolving gradually rather than in big leaps * Further evidence that archaeology is massively underfunded given its contributions to understanding of the human condition * Further evidence that academics in the field are completely incapable of communicating with each other, as there would otherwise be no surprise
I thought that was public knowledge. The world is divided into the righteous and the unrighteous, with the righteous always the ones doing the dividing.
Given the way the system works, the individual or entity that made the decision. Thus, if it's a "brilliant idea" by some idiot then that idiot should cover 100% of lost earnings. If it's a "brilliant departmental idea" then that department pays 100% of lost earnings.
A better approach would be to say that the person making the accusation, the person/entity making the decision and the person/entity acting on the decision share responsibility and divide the fine accordingly.
Regardless, money shouldn't be transferable to pay someone else's fine for the reason you give.
Agreed, but just as the best compilers are multi-stage and the best Unix tools are single-purpose and piped, I'd far prefer to see the "context-freeing" done outside of grep or diff. That way, it can be applied universally and uniformly. It'd also be easier to debug, since two simple tools are much easier to QA than one complex tool.
XML is ok, but there are many data formats that could really use a diff/grep utility that could make sense of them. HDF5 and NetCDF are nice in the scientific community, for example. Computer graphics geeks might find intelligent diff/grep tools for the Renderman format to be useful. Office users might want to know if two documents are genuinely different or were compressed differently. Hell, it would be incredibly useful if they could diff a MS Office file and LibreOffice file in their native formats to see if they were logically the same even if syntactically represented differently.
I'm sure that's the kind of thinking on the Google side. If you can equate two files (even if they aren't absolutely identical when in file form) and search in a file-format-independent way, then you can eliminate duplicate indexing and boost searching. An obvious place for that would be Google Docs, where the internal format used for a file isn't necessarily the format used by you on your machine.
A truly universal tool's only relationship to XML would be to use XML to define how different file formats worked. This would mean you could have a dictionary of file formats and object representations, without having to link to a billion libraries or having to stuff the utilities full of different kinds of parser. You'd have a single parser that would really be no different from the modern diff and grep, plus a layer in front that used the file format descriptions to convert the inputs into a usable representation.
If you wanted to stick to the Unix convention, and make this capability universal to all tools, you'd have a single file decompiler utility that used the dictionary to turn any stdin/file input into a standardized output and a single file compiler utility that could take the output of something like diff or grep and convert the representation back into a format that's meaningful with respect to the original file format. Hey presto, any problems Google or the DoE are solved without having to alter any specific tool or create any compatibility issue.
Oh, I completely agree that it's wrong, and I'd argue that in such cases that the website owners and employees should all be entitled to compensation equal to industry-typical (for the area they're operating from) wages for a year plus typical bonuses and other profits.
My fear is that the government will successfully claim sovereign immunity on the grounds that the seizure was done by a government employee on government time for purposes the government considered at the time to be correct. (Malicious, perhaps, senseless, definitely, but correct according to their way of thinking.) Sovereign immunity is used way too much in these sorts of cases and there should be serious consideration to revoking it entirely. Sadly, since it is the sovereign power that gets to decide whether or not it has immunity, that doesn't strike me as a likely proposition. (Sovereign Immunity is a relatively modern legal convenience that has no rational basis in a free society.)
They are hoping to get data on spectral lines not visible from within the solar system, with Voyager 1 now outside the solar system, but they're running into power budget issues. The battery is very, very low on juice, and with AAA not operating that far out, there's no chance of it getting any more. Data collected will therefore be rather more limited than NASA would like, but since existent data is zero any data will be an improvement.
Slashdot Mirror
I would be impressed if you could find zillions of WordCraft users! Do that and I shall worship you as a god, since that's about the only way you could find that many.
Seriously, there's nothing fundamental in desktop publishing or word processing that can't be done with 1980s technology (WordCraft, LaTeX, etc). The improvement is primarily in the UI, since there are no really new underlying operations. But let's think about the UI for a moment. WYSIWYG is a very old design concept that has indeed also existed since the 1980s. The BBC Micro had many true WYSIWYG wordprocessors that supported multiple fonts and multiple language formats, so if Word is still not true WYSIWYG then those older wordprocessors were better at some things and you have to weigh that against those things Word can do that these museum-piece wordprocessors couldn't do.
What of the UI, though? DTP packages, such as Ventura Publisher, let you rubber-band writing areas and create complex layout templates. These are ooooooold. Are Word templates really that much more advanced? I'm not convinced. It would be very hard to generate the kinds of windowing you could do back then, or roll multiple documents into one unified presentation the way they did.
Integration? The Smart Integrated Package linked a database, wordprocessor and spreadsheet together in a way that data from one could directly be passed to any of the others. For its time, it was bloody amazing. The UI was extremely clean and could be adjusted according to your expertise, the macro language was primitive but very usable, documents were handled very cleverly using an ingenious pagination system making it very quick even on extremely long documents -- if the developers and management had retained that spark of creativity, it would likely still be a decent contender today. It failed because the brilliance was replaced with a stupidity that MTV could only marvel at. No idea why.
So, no, I'm not seeing the improvements. Menus have moved from the bottom of the screen to the top, but they're certainly not any better or cleaner than those on Smart. Images can be pasted in, which WordCraft didn't handle too well, but those systems back then that did support images handled the images at the quality they existed on disk. Word converts them to an internal format (which is inefficient, hogging disk space, and is nowhere near the quality of modern image formats), which is a major headache and lacks the professional look you could achieve with earlier systems.
Compiler architecture should be piped, with optimization as the absolute final stage. Compilers really aren't that modular, as demonstrated by the fragility of the API linking the frontend to the backend of GCC. Frontends have to be modified frequently to work with GCC, which would obviously not be the case if they were loosely coupled. This "steady refinement" (the word you want is "reification") is a bloody stupid description and if you don't understand the problem with early optimization you should go back to Software Engineering 101. You're a three digit UID, you really aught to have not only got the Dragon Book and understood it, but moved well beyond that point. Indeed, I'm fairly certain from your comment that you have.
You've also been around far too long to not know that whilst you can translate any paradigm into any other paradigm, the entanglements between logic and data differ between paradigms and that entanglement remains because it's built into the semantics of the programs.
The special purpose hardware for LISP was much faster than the general purpose hardware, and the Colossus computer rebuild proved something like 20x faster than the Pentium 1 for cracking Enigma codes because it was designed with that problem-space in mind and the Pentium wasn't.
The compiler's job is indeed to map the semantics, but where the semantics are highly inefficient on that architecture the compiler can't map any better than that. THAT is why code for the Itanium 2 and later has generally been horrible. The original processor design bugs were ghastly but were largely removed by the second iteration. However, compilers simply couldn't map the code to the architecture. That argument has been had already and you can look back through the Slashdot archives for it.
If semantics were sufficient and compilers were that great, we'd never use a programming language at all. Z would be sufficient. That defines all the semantics you need and compilers are quite capable of turning Z into instructions. Chances are that although there are hundreds of thousands of Slashdot readers, less than a dozen have ever programmed in Z*. Even hand-turning Z into code is so painful and difficult that you will find professors in computer science (including Linus' old lecturers) stating that it simply cannot be done for any program of any complexity. In fact, I seem to recall one of them posting just that on Slashdot as a rebuff to my complaint that too few people knew Z. (Compared to how long either of us have been on the system, these discussions are "new" so you've doubtless seen them.) If you haven't tried Z, I strongly recommend trying it out. It is by far the most powerful of all the Formal Methods ever developed, anything you can ever write in C can be written in Z (and vice versa), it is absolutely superb for creating provably-correct semantics, but nobody would dream of converting Linux into Z (they could, and it would let you eliminate all the bugs in the logic, leaving only bugs caused by hardware weirdness) because it's just too hard. Nor would anyone dream of writing a complex HPC application in Z, because although you can convert to C you can't convert a convoluted Z program to a C program that is high performance. In theory it would be great - HPC computers aren't cheap to run, so programs that will run correctly first time and every time would obviously be a Good Thing**. In practice, HPC programmers avoid Formal Methods like the plague. You cannot turn a Z program into a fast program.
*Software Engineering lecturers will likely barf at my claim Z is a programming language, but the fact is that that is exactly what it is. Programming is not distinct from pure maths, it is - and always has been - a subset of pure maths. A programming language is merely a mathematical representation of a problem in a form that uses a specific syntax that can be reified into a form that will run on a Turing-complete system. The fact that some syntaxes are supplied with popular compiler vendors is immaterial. Because compilatio
The following is what I could dig up on the effects of multi-lingualism. It does impact the brain in many different areas and there appears to be a growing belief that learning a new language at any age will have a pronounced impact on your ability to think and reason, but that if taught young the improvements are far more dramatic still. I didn't want to clutter the submission with this stuff, especially as these studies don't have nearly the same level of rigour as the MRI scans of the taxi drivers (where a whole host of variables can now be examined directly versus the somewhat more indirect studies done on polyglots). They're also a bit more controversial, with opposing studies claiming that the benefits either don't exist or don't exist in the way that is claimed.
http://www.cal.org/resources/digest/0012brain.html
http://www.sfn.org/index.aspx?pagename=brainbriefings_thebilingualbrain
http://psychcentral.com/news/2010/11/10/cognitive-ability-improved-when-bilingual/20740.html
(Press coverage adds yet another level of indirectness and potential sources of errors, but there's still some useful info here)
http://www.nytimes.com/2011/05/31/science/31conversation.html
http://news.bbc.co.uk/2/hi/health/3739690.stm
http://www.guardian.co.uk/science/2011/feb/18/bilingual-alzheimers-brain-power-multitasking
The impact of music on learning is also not very well studied - I can find press links that talk about the research, but not much actual research.
http://www.livescience.com/5327-music-memory-connection-brain.html
http://www.sciencedaily.com/releases/2007/08/070801122226.htm
http://news.bbc.co.uk/2/hi/health/3095807.stm
http://www.bbc.co.uk/news/health-12135590
However, the story gets MUCH more complicated...
http://www.bbc.co.uk/news/magazine-15791973
http://www.mymultiplesclerosis.co.uk/misc/amnesia.html
There IS a fascinating "reverse" case, where alteration of the brain resulted in a remarkable alteration in musical ability, but as far as I know there has been no real work done on what changes the brain has undergone as a consequence of the new obsession.
http://en.wikipedia.org/wiki/Tony_Cicoria
If anyone can add to the list, that would be great, especially for the different areas you were mentioning.
That's actually a very good question. I'm not sure anyone has done that study, but I'd love to know the results.
If we go with current thinking (the Peter Principle, the idea that people generally will have their best ideas when young, the high failure rate of start-ups that appear to be by people moving out of regular industry, the apparent "strangeness" of inventors and innovators to those with a strong work ethic, etc) then the answer would be "almost certainly" for your first question, "quite likely" for your second and "yes but it's unimaginably rare" to your third.
However, you must bear in mind that until there's hard evidence of cause-and-effect, this is all supposition based on anecdotal evidence (which, if you remember your Dilbert videos, is only good for selling books) and apparent correlation. It seems very plausible, but without something a bit more solid I'm not confident anyone can give a real answer.
Code cannot be translated across paradigms efficiently. It is entirely possible to build an OO processor, provided the processor supports register banks. Functional programming is relevant to transistor networks because you can express things as contiguous flows between blocks of logic and contiguous flows between blocks of logic can be very easily handled by transistor networks. Far more so than procedural logic, which requires you to have a disjoint relationship between data and logic.
Compilers are crappy, for the most part, which is why Fortran is still used in maths. The level of effort that has gone into understanding how to compile Fortran programs is enormous and that's when the code mimics the way the CPU works. Further, not all paradigms are equal. Because of the complex relationship between code and data, OO will never be as efficient as procedural code, which will never be as efficient as functional code.
I don't regard Microsoft Word as much of an improvement over Wordcraft 80 or WordWise (a bow to those who recognize either name).
Well, I'd argue that there are lots of differences between good and bad programmers, often depending on what criteria is used for "good". In some cases, yes, expertise is a significant parameter. However, the primary "claim" made about higher-level programming languages is that smarter languages reduce the expertise factor. If that is the case, then expertise alone cannot explain why the 10x gap doesn't vary massively between the "generation" of the language or the paradigm of the language. Of course, one can argue that higher-level programming languages still require the same level of expertise, but in that case you'd be better off with having one language per "generation" per paradigm because having more than that dilutes the competency and therefore reduces expertise.
Been done and the consensus is that Nobel-winning physicists like ponies and limericks but not Higgs bosons.
The Guardian and the BBC are hardly tabloid-class but they're still hyping the announcement. Both feel something important is going to be said, though both also say that no physicist actually believes so.
The news is likely of some sort of signal that doesn't meet the 5 sigma requirement of a discovery but which does look promising. As The Guardian notes, most of the other announcements of the "excluded range" kind have been given by junior staffers and not the top brass, which means it has to be something bigger -- but, as the physicists interviewed have pointed out, the energies are much too low right now to have discovered the Higgs boson.
The "best guess" outside of the "promising signal" department is that they've found something that doesn't match the Standard Model, that they've made an observation they can't explain without new physics. This would be the absolutely ideal case, since new science is far more exciting than merely confirming old theory.
The "next best guess" after that is that they've found data that backs up one of the GUT models. Being able to conduct "real science" on physics that has been more philosophical than experimental would be major news indeed.
I dunno. An electronvolt is about 1.6 x 10^-19 J, which means a teraelectronvolt is still only 1.6 x 10^-7 J, which Wikipedia helpfully says is the kinetic energy of a flying mosquito (the bug kind, not the WW2 aircraft). The energy of a mosquito, distributed over the entire collision chamber, doesn't seem to be a lot.
I wonder, how many of the languages listed on Freshmeat nee Freecode have people here actually used? Which ones do you know well enough to form a good, solid critique on what the language can and cannot do? Which compilers have you contributed code to?
Probably the answers would be "not many", "very few" and "almost none" respectively. And we're the geeks. We're the ones who are actually interested in this kind of stuff. Yet I'm willing to bet that even we couldn't form a sensible, rational, evidence-based opinion on "what is needed" because none of us has the breadth to know what has already been done and either found "not really to be needed at all" vs. "not used because nobody knows about it" vs. "a great concept but in the wrong language". Even we, the most obsessive bunch of nerds out there, simply don't have that kind of data. I reject utterly, therefore, the idea that anyone else is going to know so much more.
I'd argue that we need multiple computer languages and paradigms, but that we probably don't need as many as we have. I'm fluent in about 20 computer languages but that simply should not be necessary.
I'd be quite happy if the world reduced itself to Digital Mars' D, Occam-Pi, Erlang and Haskell. That would give us the necessary mix of procedural, functional and object-oriented languages to cover everything, and these languages are much better at developing correct software than many of the other languages out there. There are many languages which are "good" at something - Fortran is still the language of choice for mathematicians, Forth is brilliant for hardware control and C is good for developing fast general-purpose software - but these are problematic in that they make it very easy to write buggy, unreliable software.
If you want to narrow the range, then the languages chosen MUST be capable of producing code as powerful and fast as the "best of breed" without having the genetic defects which are the product of the inbreeding that have produced these languages. Haskell and OCaml are great at what they do, and compilers for them could certainly be improved upon to generate much better code, and could easily replace those languages which show definite deformities (Java, Visual Basic, C#, etc) but those alone won't replace the full range.
Occam-Pi and Erlang are more than capable of replacing C and Fortran for most purposes, including client/server and HPC, but aren't ideal for really low-level stuff and don't have the power of C++ to simplify horribly complex projects. D does, but you can't simply use D because there's a lot in Occam and Erlang for parallel programming that C-based languages just don't have. (Prior "debates"/wars on here over parallel programming and whether or not it's complicated ultimately boil down to the fact that most people insist on using languages that make it far harder than necessary to get results. Always, always, always use methodologies that are suitable for the problem-space rather than try to cram the problem-space to a specific methodology.)
It won't be a problem, as all of that (charred human remains included) would most likely be at the launch site, making it a tourist spectacle able to recoup the costs and lawsuits.
First, the guidance systems required are horribly complicated and need to be extremely reliable with almost no testing (each test is a launch and you get very few launches a year). That means you have to have competent engineers. As the Cobol-vs-Java discussion shows, competent engineers are something of a premium and always have been. The number who could actually put together a fully-functional fail-safe guidance system almost blind - no matter how much knowledge is out there - is extremely small. You also have to bear in mind that "reliable" doesn't just mean "it'll work perfectly under Earth gravity" - it has to work perfectly after being smashed with 3-4g forces along the vertical plus massive amounts of vibration from the rocket motors and side winds.
Second, the materials aren't cheap. I forget exactly how much it costs NASA to put something into orbit - isn't it something like $1000 per gram? - and that's with all the expertise on-site, the launch facilities and communications centers already existing and production-line facilities for the parts.
Third, the level of heath required is staggering. The forces involved are simply too great. Russia, hardly the epitome of transport safety, has refused wannabe millionaire space tourists on health grounds, where the issues would have been insignificant in any other line of work.
IP isn't even remotely a factor in all of this. Until titanium is as cheap as aluminium (which it could be if they ever developed a decent refining process for it), until programmers and hardware engineers are capable of making near-flawless products first time, every time, space travel will remain expensive.
This is why, despite Bloddhound SSC publishing the complete specifications, not a single hacker is going to build and race one. They could - the information is out there - but they haven't the skills. And a car is trivial compared to a spaceship.
I think they were referring to the stock market, as you're right in saying they weren't referring to gravity.
Oblig. Johnny Test quote: "Cheese pants. Cheese pants were definitely the worst."
That's fine and all part of science - learning naturally alters what you know. From that perspective, it's hardly a surprise. Earliest dates for cooking, advanced stone tool making, etc, have been pushed back by far more significant amounts this year. Domestication of horses may also have been much earlier, but for some curious reason the scholars there have... ...declined to release the data. Anyways, I don't regard that part as being particularly news.
The newsworthy elements to this story:
* Further evidence of abstract and indirect thinking in early humans, pretty much putting beyond question that these skills existed back then
* Further evidence of society evolving gradually rather than in big leaps
* Further evidence that archaeology is massively underfunded given its contributions to understanding of the human condition
* Further evidence that academics in the field are completely incapable of communicating with each other, as there would otherwise be no surprise
I thought that was public knowledge. The world is divided into the righteous and the unrighteous, with the righteous always the ones doing the dividing.
Given the way the system works, the individual or entity that made the decision. Thus, if it's a "brilliant idea" by some idiot then that idiot should cover 100% of lost earnings. If it's a "brilliant departmental idea" then that department pays 100% of lost earnings.
A better approach would be to say that the person making the accusation, the person/entity making the decision and the person/entity acting on the decision share responsibility and divide the fine accordingly.
Regardless, money shouldn't be transferable to pay someone else's fine for the reason you give.
Agreed, but just as the best compilers are multi-stage and the best Unix tools are single-purpose and piped, I'd far prefer to see the "context-freeing" done outside of grep or diff. That way, it can be applied universally and uniformly. It'd also be easier to debug, since two simple tools are much easier to QA than one complex tool.
XML is ok, but there are many data formats that could really use a diff/grep utility that could make sense of them. HDF5 and NetCDF are nice in the scientific community, for example. Computer graphics geeks might find intelligent diff/grep tools for the Renderman format to be useful. Office users might want to know if two documents are genuinely different or were compressed differently. Hell, it would be incredibly useful if they could diff a MS Office file and LibreOffice file in their native formats to see if they were logically the same even if syntactically represented differently.
I'm sure that's the kind of thinking on the Google side. If you can equate two files (even if they aren't absolutely identical when in file form) and search in a file-format-independent way, then you can eliminate duplicate indexing and boost searching. An obvious place for that would be Google Docs, where the internal format used for a file isn't necessarily the format used by you on your machine.
A truly universal tool's only relationship to XML would be to use XML to define how different file formats worked. This would mean you could have a dictionary of file formats and object representations, without having to link to a billion libraries or having to stuff the utilities full of different kinds of parser. You'd have a single parser that would really be no different from the modern diff and grep, plus a layer in front that used the file format descriptions to convert the inputs into a usable representation.
If you wanted to stick to the Unix convention, and make this capability universal to all tools, you'd have a single file decompiler utility that used the dictionary to turn any stdin/file input into a standardized output and a single file compiler utility that could take the output of something like diff or grep and convert the representation back into a format that's meaningful with respect to the original file format. Hey presto, any problems Google or the DoE are solved without having to alter any specific tool or create any compatibility issue.
What if you pipe the results through /dev/tivo?
You have to figure in two's complement notation. If it's sufficiently counter-intuitive, the sign bit flips over and it becomes totally intuitive.
Oh, I completely agree that it's wrong, and I'd argue that in such cases that the website owners and employees should all be entitled to compensation equal to industry-typical (for the area they're operating from) wages for a year plus typical bonuses and other profits.
My fear is that the government will successfully claim sovereign immunity on the grounds that the seizure was done by a government employee on government time for purposes the government considered at the time to be correct. (Malicious, perhaps, senseless, definitely, but correct according to their way of thinking.) Sovereign immunity is used way too much in these sorts of cases and there should be serious consideration to revoking it entirely. Sadly, since it is the sovereign power that gets to decide whether or not it has immunity, that doesn't strike me as a likely proposition. (Sovereign Immunity is a relatively modern legal convenience that has no rational basis in a free society.)
In an extended version, a digital version, a re-digitized digital version and a Jar Jar Binks version at a later date.
They are hoping to get data on spectral lines not visible from within the solar system, with Voyager 1 now outside the solar system, but they're running into power budget issues. The battery is very, very low on juice, and with AAA not operating that far out, there's no chance of it getting any more. Data collected will therefore be rather more limited than NASA would like, but since existent data is zero any data will be an improvement.