It's all about the context switches. When you're typing along productively, then have to stop to get the mouse, find the pointer on the screen, get it to where you want it, perform whatever action, then pop back to the keyboard to continue, you've had to bounce your attention across several distinct actions. That just isn't productive.
I think that really depends on what sort of coding you're doing. Now I have no idea what your work is like, but I find that the amount of time I spend continuously pounding out code on the keyboard is pretty limited -- I spend far more time reading code then writing, and far more time thinking than reading -- so context switches are pretty cheap, especially when you can grab the mouse and move it to where you need while reading or thinking. But as I say, that's one type of coding; I have seen code that has people just pound away at the keyboard without having to stop and read or think about what they're writing. That may well be your situation. It is not the case for everyone.
Unfortunately, the extremes of the parties are the ones in control...
Really? The last election was a close fought battle between Ron Paul and Dennis Kucinich? I must have missed that.... Perhaps you should check out what the extremes of the parties actually are?
Why this one and not the other one? Because they know this one, or it was the first the help file spit out when they searched for a "search function". But then again, it does not matter. The other function that might have been faster because it happens to implement an algo that is more fitting to the problem at hand would have saved about 0.0something seconds, because the machine running the program eventually is fast enough that it means jack what algo you use. Memory amounts today mean that it is pointless to ponder whether you really need double linked lists or whether you get by with single linked ones. Or that you use variables smaller than DWords to store integers.
I've worked on time critical code and you know what? Most of the time using that standard library search or sort function is the right thing to do. Using whatever slightly inefficient but general and prewritten library function is usually the right choice. You see code maintainability is very important too, and doing things in the clear and simple way with library functions helps a great deal with maintainability. Yes, you do still need to know your different sort algorithms, and there will be sections of code that will have to be rewritten with a more careful hand-tooled solution, but as a first pass it's better to start with the naive library based approach until you've actually identified which portions of code are actually the time critical ones -- premature optimization is painful to deal with later: I've inherited code bases where everything was completely hand-tooled and extremely fast but were incomprehensibly complicated and ran just as fast with 90% of those carefully hand optimized things replaced by simple library calls.
I can't give opinions on all of these (and some are still in development at this time anyway), but here's a list of some languages with paralellism designed in:
Erlang -- Very popular message passing/actor model based language.
Scala -- A functional language with actor model concurrency for the JVM.
Fortress -- Sun's language for serious scientific computing. It was Sun's entry into DARPA's HPCS programming language competition, but lost and is now open sourced.
Eiffel SCOOP -- An effort to take a CSP model and make it elegantly compatible with object oriented programming
The idea itself may not be bad, but as a suggestion to open.gov it is bad simply because it is completely politically infeasible to implement at this time. You may as well be wishing for ponies.
What do you think about the rather fundamental flaw in science that Godel uncovered ?
I don't recall Godel having anything to say on the subject of science. He did produce some interesting theorems in mathematics, metamathematics, and logic, but I don't see where science enters into this. When I combine this statement with some of the statements from your previous post it seems clear to me that you have a woefully poor understanding of exactly what Godel's Incompleteness Theorems actually say and mean.
Do you believe this proof...
Godel's Incompleteness Theorems seem sound to me if that's what you mean.
... and agree that it creates a major theoretical problem for any kind of proof of science that goes further than giving examples of stuff working ?
I wasn't aware that there was any other kind of proof in science than the empirical. Science is not mathematics, and nor is it logic. You seem to be swinging at a strawman here.
There are 2 standards of proof, it would seem to me: theoretical proof -- deducing whatever conclusion you reach from first principles exclusively...
Which is a perfecly fine approach to take when working with mathematics, or say, a particular model of what we assume reality is like that has been cast into mathematical or other purely logical terms... but that's just a model, not reality. Investigation of reality by science utterly hinges on the empirical: how well does the model match empirical reality.
You know that it has been proven that science cannot satisfy this standard of proof, ever. All of science is subject to the theoretical problem Godel uncovered
You know that science's inability to meet that standard of proof has nothing to do with Godel's Incompleteness theorem, and that, equally, Godel's incompleteness theorems really say nothing about epistemology in science right? Well, obviously you don't or you won't be dragging Godel into this. You'd be much better served actually reading some philosophy rather than grasping at straws and dragging in mathematics that you clearly have little understanding of. Human Knowledge: Its Scope and Limits by Bertrand Russell might be a good start.
<Snip bizarre ranting and selective comparison of religion>
But atheists that actually know anything about the foundation of mathematics, much less ones that actually take such knowledge into account, now that's rare.
Hmmm, I'm an atheist and I believe I know something about foundations of mathematics. I didn't think I was all that rare, but then maybe you'll say I don't really know anything about the foundations of mathematics...
Of course, whether they do one or the other, not know about mathematical foundations, or the other, disregard scientific knowledge about mathematical foundations, they remain hypocrites.
I'm not even sure what you mean here; I don't think I fall in case one, so I guess you're suggesting that I "disregard scientific knowledge about mathematical foundations"; but what you mean by that is unclear. Presumably you're referring back to your claim "This obviously means everyone who says "math works" is making a statement of belief, not the least bit better founded than "God made the world", or Santa Claus.", which seems poorly grounded. I can certainly say that "math works" in terms of efficacy in the sciences on the basis of vast amounts empirical evidence in support of that statement, which is certainly not an equivalent in terms of belief to the equivalent statement, with no empirical evidence supporting it, that Santa Claus exists. Perhaps you're assuming I will say "math works" in terms of assuring determination of absolute truth, but there's no reason whatsoever to assume that; one need not be a mathematical platonist.
We don't have records about ships making it through then, but it was warmer then than it is now in the more northern and arctic regions and we know for a fact that the vikings had habitable settlements where it is all frozen ice now and you can't grow anything
Your statement about the Norse settlements in Greenland is patently false (unless by "now" you mean "February - March" as opposed to "this century"). The locations of the Norse settlements are known. Google maps and satellite photos can come to out aid. in determining how ice covered they are:
Consider these Googlemaps images of the sites for the Western and Eastern Settlements:
Doesn't look very "ice-covered" to me, and there seems to be quite a bit growing, what with those ruins sitting amidst tall green grass and wildflowers...
I'd have to assume that those that agree with 'climate-change' and don't have a the appropriate science background are irrelevant as well?
Yes, people who are convinced and could not be dissuaded by any evidence are just as bad as those who are deniers. Interestingly completely uncritical convinced people are often the shrill annoying ones.
Phil Jones has admitted that there has been no global warming since 1995.
No, he said that there was warming since then but the trend failed to meet a 95% significance level.
Suppose we have a coin that might be biased. You flip it four times and it comes up heads all four times. A statistician kindly points out that while there's indications of bias, it doesn't meet the 95% significance level. You then say "Aha! The expert says the coin is not biased!". That is of course not what the statistician said -- essentially he said that four tosses is not yet sufficient to conclude that it is biased (at least not at the 95% significance level). Of course a fifth toss that came up heads as well we could make that conclusion (at least at the 95% significance level); alternatively even if the next toss comes up tails it wouldn't take too many further tosses coming up heads to get us to the 95% significance level either. That is, if you collect a little more data (e.g. start from a year a little further back than 1995) and you'll probably have enough data to conclude the trend is real (at the 95% significance level).
In an important sense, software is the specification. The only unambiguous specification is the actual software [otherwise we could make whatever was used for the specification be the programming language].
This isn't strictly true. I can write a specification for a square root function (i.e. that the return value squared is within some tolerance of the input) that is most definitely not an implementation of of a square root function. Likewise, I can write a specification of a sort function that could be fulfilled by many different implementations (merge sort, quick sort, etc.). And indeed, there are specification languages for software (JML, SPARK, Z, CASL, etc.) that are definitely not programming languages. Think of it this way: a type signature is a specification of a function, but a header file giving type signatures is certainly not an implementation. Of course a type signature is a fairly weak specification in most languages because type signatures are not very expressive, but that should give you the general idea -- replace raw type signatures with a more expressive specification language and you can specify without implementing just fine.
First of all, 30-40,000 lines of code is not lots of code. Try, 250,000 of code.
To start, use a good programming editor/environment (Xcode, Vslick, Visual Studio, etc.) that gives you the ability to easily go to definition or references to variables, functions, structs and such.
30-40,000 lines can be lots of code, it really depends on how maintainably it is written. I've had to pick up codebases that were somewhat smaller but were still diabolical... good programming environments don't buy you much when the code consists of functions that are many thousands of lines long making little or no use of typedefs or structs (arrays and lots of variables should be enough right?) and convenient variable names like 'e', 'ee', and 'eee'. Even small codebases can become practically incomprehensible if written with little thought given to long term maintenance.
Don't your mobile phones take videos? Record the lecture. Take photos of the diagrams. Narrate your own thoughts and comments.
I want notes to provide a condensed version of the lecture that I can study from. If the only way to revisit material from the lecture is to sit through the whole damn thing again on video then I've achieved little. Yes, yes, you can jump to a portion, but you're still left wading through a mass of material to find what you want. I want brief concise notes that hit the high points that are relevant to my understanding of the material (skip over bits I find easy, provide elaboration on parts I foubnd more challenging). That's the whole damn point of taking notes; and those notes are the whole damn point of going through the lecture.
The usefulness does depend on the problem. Anything using sets or arrays larger than a few number is going to be much easier and faster (and less prone to error) on a spreadsheet. A spreadsheet is probably more useful for experimentation, as well.
I really do think it is matter of what one is used to. For me manipulating lists, arrays, sets, matrices, tensors etc. seems easiest and most natural in something like ipython (with numpy), mathemematica or matlab. Of course those are the sorts of tools I use every day, so it seems most obvious to me how to quickly make them do what I want. I rarely if ever use spreadsheets, and unsurprisingly I would find one a rather clunky experience. I imagine you use spreadsheets far more than say mathematica, and so you will instantly know how to do whatever it is you need in spreadsheet (while I will certainly not), but find using mathematica a clunky experience.
Showing that the system was rigged and that some valid papers were rejected is enough. Even showing that a single valid paper was rejected is enough, because it's not supposed to be possible.
A conspiracy has been exposed...
You seem to be leaping a bit there. I think you missed the bit where a valid paper was shown to be rejected. All I've seen is a quote from a reviewer who said he rejected two papers; there's no reason to presume those papers should have been published, or that they weren't rejected for good reasons. If you can pony up that then I'll start to pay attention, in the meantime I don't see a conspiracy.
Because otherwise, the only thing you've shown is that.... a single person rejected two papers based on personal bias against the conclusion.
He didn't even show that; he showed that a person with a stake in the matter wrote damning reviews of two papers. He may have written damning reviews because he didn't like the conclusion, but he may have written damning reviews because the papers were crap and riddled with errors. All the quote shows is that he wrote damning reviews.
Why is the Medieval Warming Period completely eliminated by AGW "proofs"? Are you suggesting that documented colonization of Greenland by the vikings during the MWP followed by the gradual destruction of the colony during the Little Ice Age... didn't happen?
It is true that the Norse colonised Greenland around 1000 CE, and failed around 1300 CE. If this is meant to imply that, at that time, Greenland must have been much warmer than it is today, or that the little ice age marked a dramatic drop in temperatures, it's misleading. The reality is that there were only 2 Norse settlements in Greenland, located in fjords on Greenland's west coast. The areas of both those settlements are quite green and hospitable today, and there are several farms there now (Eastern settlment area, and Eastern settlment map; Western settlment area, and Western settlement map. Just for reference, here is a zoom of the area of the Brattahlid and Gardar farms (two of the largest/richest farms), and a zoom of the Sandnes farm area from the Western settlment), so Greenland need not have been any warmer than today to have provided the Norse with sustainable settlements. Further the archaeological evidence from the sites implies the Norse hardly had an easy life: Greenland cows were the smallest ever known, largely due to malnutrition, and it seems the cows and sheep may have had to be force fed seaweed over the winter to keep them alive -- and this was pre the little ice age. The Norse also tended to rely on trips to the Eastern Canadian coast, most likely the Labrador area, for many things, most particularly wood. Read Collapse by Jared Diamond for a good account of the settlement and decline of Greenland colonies. Climate was a factor, but one among many, and it didn't require much of a shift since the colonies were already in the brink due to other factors.
Is Greenland green yet or is it still covered in ice? If Vikings farmed there then, doesn't that mean the world was much much warmer than today?
With regard to the greenness of the areas of Greenland settled by the Norse, it seems Google maps and satellite photos can come to out aid. Consider these Googlemaps images of the sites for the Western and Eastern Settlements:
And the only correct documentation is the code itself. Anything else is a opinion and should be viewed accordingly.
Of course the code itself only tells you what the code does, not what the code is supposed to do, nor why it is doing it. Note that the difference can be rather crucial in maintenance and bug fixing.
I don't know how many times over my 30 year career that I've read documentation and started work only to find out later that it hadn't been updated. The first standard in your documentation rules should be that all relevant documentation is created and updated before code goes into production. No excuses.
Which is why it's always nice to have documentation that can be tested against the code. Now the "why" part of documentation is rather hard to verufy against code, but the "what it is supposed to do" should be able to be automatically verified if it is sensibly written: for instance in Eiffel requires and ensures clauses, or in JML, or splint, or SPARK; which allow for varying levels of static checking, runtime assertions, and automatic unit test generation (depending on what you are using) to ensure that if code and documentation falls out of sync an error should be immediately flagged.
Simple, clever doesn't pay the bills, reliable and maintainable do. It's a cost benefit analysis: if that clever one-liner saves many man-hours of work, then probably a good idea. If it saves you two or three lines of code and all of an addition 45 seconds, probably not worth the blow to maintainability and readability.
I view it as a premature optimization issue. It's very rare indeed that you save much time in writing code by doing something cute or clever; usually it's a matter of trying to do something slickly to save cpu time or memory. Rather than prematurely optimize I find it is best to try and write things in the most clear straightforward fashion first (even if it's not the most efficient implementation) and then go back later and make things more efficient if it proves to be necessary (often it doesn't because of real bottlenecks elsewhere).
how do you know the CO2 rise is man made in the first place, and not oh say from the oceans which are the largest stores of CO2?
By isotope analysis of atmospheric CO2. The isotope ratios for carbon from fossil fuels are distinct from those of carbon in CO2 outgassed from the oceans. By looking at the (changing) isotope ratios of atmospheric CO2 it is possible to track the relative origins of the increasing amounts of CO2 in the atmosphere. It turns out the increase is due to humans burning fossil fuels.
Name me ONE FUCKING ARTIST who started out with 100% original music
W. A. Mozart?
Mozart certainly started composing young, but he learned playing the works of others. Mozart is also an intriguing choice since he is an interesting early case of "music piracy": using he remarkable memory and musical talent he transcribed Miserere from memory after listening to it once (he did go back a second time to correct errors. At the time the piece was notable as having no transcriptions (of the very few floating around) that captured the beauty of of the annual performance at the Sistine chapel. Mozart's excellent transcription eventually made it to London where it was widely published and the piece was available all over Europe.
But if all you're doing is reinventing Perl with C-like syntax, it's not really a step forward.
Perl already has C-like syntax. It doesn't, however, have static type checking, let alone robust static type checking (with nice features like variance annotation etc.); nor does it have particularly robust functional programming support -- you can certainly do functional programming in Perl, but it isn't as clean and syntactically sugared as it could be; nor does perl have particularly clean OO if we're being honest -- yes it works and can be made to work quite well, but elegant isn't a word that comes to mind when I think Perl and OO; nor does Perl have function pattern matching and algebraic data types; nor does Perl have a nice concurrent programming interface based on the Actor model. None of this is really to say that Perl is bad -- it is very good for a great many things, and the features I've mentioned needn't hold it back. My point is that Scala is most certainly not re-inventing Perl. In fact Scala doesn't even have a particularly C-like syntax: it's less C-like than Perl really.
Of course if you take this line of thought seriously then you realise that Java and C# are the light options that don't really force you to do enough. If you were serious about being forced to be more explicit for the sake of maintainable code you would be using Eiffel, or Spec#, or JML abd ESC/Java2 with your Java, or SPARK-Ada, or writing specifications in B or Z. I'm betting you don't do any of that though because you view it as "too much work", even though many of those options (such as Spec# of JML) really aren't that much more work if you really are serious about robust maintainable code.
Slashdot Mirror
It's all about the context switches. When you're typing along productively, then have to stop to get the mouse, find the pointer on the screen, get it to where you want it, perform whatever action, then pop back to the keyboard to continue, you've had to bounce your attention across several distinct actions. That just isn't productive.
I think that really depends on what sort of coding you're doing. Now I have no idea what your work is like, but I find that the amount of time I spend continuously pounding out code on the keyboard is pretty limited -- I spend far more time reading code then writing, and far more time thinking than reading -- so context switches are pretty cheap, especially when you can grab the mouse and move it to where you need while reading or thinking. But as I say, that's one type of coding; I have seen code that has people just pound away at the keyboard without having to stop and read or think about what they're writing. That may well be your situation. It is not the case for everyone.
Unfortunately, the extremes of the parties are the ones in control...
Really? The last election was a close fought battle between Ron Paul and Dennis Kucinich? I must have missed that .... Perhaps you should check out what the extremes of the parties actually are?
Why this one and not the other one? Because they know this one, or it was the first the help file spit out when they searched for a "search function". But then again, it does not matter. The other function that might have been faster because it happens to implement an algo that is more fitting to the problem at hand would have saved about 0.0something seconds, because the machine running the program eventually is fast enough that it means jack what algo you use. Memory amounts today mean that it is pointless to ponder whether you really need double linked lists or whether you get by with single linked ones. Or that you use variables smaller than DWords to store integers.
I've worked on time critical code and you know what? Most of the time using that standard library search or sort function is the right thing to do. Using whatever slightly inefficient but general and prewritten library function is usually the right choice. You see code maintainability is very important too, and doing things in the clear and simple way with library functions helps a great deal with maintainability. Yes, you do still need to know your different sort algorithms, and there will be sections of code that will have to be rewritten with a more careful hand-tooled solution, but as a first pass it's better to start with the naive library based approach until you've actually identified which portions of code are actually the time critical ones -- premature optimization is painful to deal with later: I've inherited code bases where everything was completely hand-tooled and extremely fast but were incomprehensibly complicated and ran just as fast with 90% of those carefully hand optimized things replaced by simple library calls.
I can't give opinions on all of these (and some are still in development at this time anyway), but here's a list of some languages with paralellism designed in:
The idea itself may not be bad, but as a suggestion to open.gov it is bad simply because it is completely politically infeasible to implement at this time. You may as well be wishing for ponies.
What do you think about the rather fundamental flaw in science that Godel uncovered ?
I don't recall Godel having anything to say on the subject of science. He did produce some interesting theorems in mathematics, metamathematics, and logic, but I don't see where science enters into this. When I combine this statement with some of the statements from your previous post it seems clear to me that you have a woefully poor understanding of exactly what Godel's Incompleteness Theorems actually say and mean.
Do you believe this proof ...
Godel's Incompleteness Theorems seem sound to me if that's what you mean.
... and agree that it creates a major theoretical problem for any kind of proof of science that goes further than giving examples of stuff working ?
I wasn't aware that there was any other kind of proof in science than the empirical. Science is not mathematics, and nor is it logic. You seem to be swinging at a strawman here.
There are 2 standards of proof, it would seem to me: theoretical proof -- deducing whatever conclusion you reach from first principles exclusively ...
Which is a perfecly fine approach to take when working with mathematics, or say, a particular model of what we assume reality is like that has been cast into mathematical or other purely logical terms ... but that's just a model, not reality. Investigation of reality by science utterly hinges on the empirical: how well does the model match empirical reality.
You know that it has been proven that science cannot satisfy this standard of proof, ever. All of science is subject to the theoretical problem Godel uncovered
You know that science's inability to meet that standard of proof has nothing to do with Godel's Incompleteness theorem, and that, equally, Godel's incompleteness theorems really say nothing about epistemology in science right? Well, obviously you don't or you won't be dragging Godel into this. You'd be much better served actually reading some philosophy rather than grasping at straws and dragging in mathematics that you clearly have little understanding of. Human Knowledge: Its Scope and Limits by Bertrand Russell might be a good start.
<Snip bizarre ranting and selective comparison of religion>
But atheists that actually know anything about the foundation of mathematics, much less ones that actually take such knowledge into account, now that's rare.
Hmmm, I'm an atheist and I believe I know something about foundations of mathematics. I didn't think I was all that rare, but then maybe you'll say I don't really know anything about the foundations of mathematics ...
Of course, whether they do one or the other, not know about mathematical foundations, or the other, disregard scientific knowledge about mathematical foundations, they remain hypocrites.
I'm not even sure what you mean here; I don't think I fall in case one, so I guess you're suggesting that I "disregard scientific knowledge about mathematical foundations"; but what you mean by that is unclear. Presumably you're referring back to your claim "This obviously means everyone who says "math works" is making a statement of belief, not the least bit better founded than "God made the world", or Santa Claus.", which seems poorly grounded. I can certainly say that "math works" in terms of efficacy in the sciences on the basis of vast amounts empirical evidence in support of that statement, which is certainly not an equivalent in terms of belief to the equivalent statement, with no empirical evidence supporting it, that Santa Claus exists. Perhaps you're assuming I will say "math works" in terms of assuring determination of absolute truth, but there's no reason whatsoever to assume that; one need not be a mathematical platonist.
We don't have records about ships making it through then, but it was warmer then than it is now in the more northern and arctic regions and we know for a fact that the vikings had habitable settlements where it is all frozen ice now and you can't grow anything
Your statement about the Norse settlements in Greenland is patently false (unless by "now" you mean "February - March" as opposed to "this century"). The locations of the Norse settlements are known. Google maps and satellite photos can come to out aid. in determining how ice covered they are:
Consider these Googlemaps images of the sites for the Western and Eastern Settlements:
Eastern settlement area, and Eastern settlement map
Western settlement area, and Western settlement map.
Just for reference, here is a zoom of the area of the Brattahlid and Gardar farms (two of the largest/richest farms), and a zoom of the Sandnes farm area from the Western settlement.
Want more? How abut on the ground photos of the ruins?
Gardar ruins
Bratthlid ruins
Hvalsey church
Doesn't look very "ice-covered" to me, and there seems to be quite a bit growing, what with those ruins sitting amidst tall green grass and wildflowers ...
I'd have to assume that those that agree with 'climate-change' and don't have a the appropriate science background are irrelevant as well?
Yes, people who are convinced and could not be dissuaded by any evidence are just as bad as those who are deniers. Interestingly completely uncritical convinced people are often the shrill annoying ones.
Phil Jones has admitted that there has been no global warming since 1995.
No, he said that there was warming since then but the trend failed to meet a 95% significance level.
Suppose we have a coin that might be biased. You flip it four times and it comes up heads all four times. A statistician kindly points out that while there's indications of bias, it doesn't meet the 95% significance level. You then say "Aha! The expert says the coin is not biased!". That is of course not what the statistician said -- essentially he said that four tosses is not yet sufficient to conclude that it is biased (at least not at the 95% significance level). Of course a fifth toss that came up heads as well we could make that conclusion (at least at the 95% significance level); alternatively even if the next toss comes up tails it wouldn't take too many further tosses coming up heads to get us to the 95% significance level either. That is, if you collect a little more data (e.g. start from a year a little further back than 1995) and you'll probably have enough data to conclude the trend is real (at the 95% significance level).
In an important sense, software is the specification. The only unambiguous specification is the actual software [otherwise we could make whatever was used for the specification be the programming language].
This isn't strictly true. I can write a specification for a square root function (i.e. that the return value squared is within some tolerance of the input) that is most definitely not an implementation of of a square root function. Likewise, I can write a specification of a sort function that could be fulfilled by many different implementations (merge sort, quick sort, etc.). And indeed, there are specification languages for software (JML, SPARK, Z, CASL, etc.) that are definitely not programming languages. Think of it this way: a type signature is a specification of a function, but a header file giving type signatures is certainly not an implementation. Of course a type signature is a fairly weak specification in most languages because type signatures are not very expressive, but that should give you the general idea -- replace raw type signatures with a more expressive specification language and you can specify without implementing just fine.
First of all, 30-40,000 lines of code is not lots of code. Try, 250,000 of code.
To start, use a good programming editor/environment (Xcode, Vslick, Visual Studio, etc.) that gives you the ability to easily go to definition or references to variables, functions, structs and such.
30-40,000 lines can be lots of code, it really depends on how maintainably it is written. I've had to pick up codebases that were somewhat smaller but were still diabolical ... good programming environments don't buy you much when the code consists of functions that are many thousands of lines long making little or no use of typedefs or structs (arrays and lots of variables should be enough right?) and convenient variable names like 'e', 'ee', and 'eee'. Even small codebases can become practically incomprehensible if written with little thought given to long term maintenance.
Don't your mobile phones take videos? Record the lecture. Take photos of the diagrams. Narrate your own thoughts and comments.
I want notes to provide a condensed version of the lecture that I can study from. If the only way to revisit material from the lecture is to sit through the whole damn thing again on video then I've achieved little. Yes, yes, you can jump to a portion, but you're still left wading through a mass of material to find what you want. I want brief concise notes that hit the high points that are relevant to my understanding of the material (skip over bits I find easy, provide elaboration on parts I foubnd more challenging). That's the whole damn point of taking notes; and those notes are the whole damn point of going through the lecture.
The usefulness does depend on the problem. Anything using sets or arrays larger than a few number is going to be much easier and faster (and less prone to error) on a spreadsheet. A spreadsheet is probably more useful for experimentation, as well.
I really do think it is matter of what one is used to. For me manipulating lists, arrays, sets, matrices, tensors etc. seems easiest and most natural in something like ipython (with numpy), mathemematica or matlab. Of course those are the sorts of tools I use every day, so it seems most obvious to me how to quickly make them do what I want. I rarely if ever use spreadsheets, and unsurprisingly I would find one a rather clunky experience. I imagine you use spreadsheets far more than say mathematica, and so you will instantly know how to do whatever it is you need in spreadsheet (while I will certainly not), but find using mathematica a clunky experience.
Showing that the system was rigged and that some valid papers were rejected is enough. Even showing that a single valid paper was rejected is enough, because it's not supposed to be possible.
A conspiracy has been exposed...
You seem to be leaping a bit there. I think you missed the bit where a valid paper was shown to be rejected. All I've seen is a quote from a reviewer who said he rejected two papers; there's no reason to presume those papers should have been published, or that they weren't rejected for good reasons. If you can pony up that then I'll start to pay attention, in the meantime I don't see a conspiracy.
Because otherwise, the only thing you've shown is that.... a single person rejected two papers based on personal bias against the conclusion.
He didn't even show that; he showed that a person with a stake in the matter wrote damning reviews of two papers. He may have written damning reviews because he didn't like the conclusion, but he may have written damning reviews because the papers were crap and riddled with errors. All the quote shows is that he wrote damning reviews.
Just saying it looks like a vast ice sheet from where I'm sitting
That depends on where you look -- if you look where the Norse settlements were...
Eastern settlment area, and Eastern settlment map ... You'll find it's fairly green.
Western settlment area, and Western settlement map. A zoom of the area of the Brattahlid and Gardar farms (two of the largest/richest farms), and a zoom of the Sandnes farm area from the Western settlment. Plus ground photos of the ruins:
Gardar ruins; Bratthlid ruins; Hvalsey church
Why is the Medieval Warming Period completely eliminated by AGW "proofs"? Are you suggesting that documented colonization of Greenland by the vikings during the MWP followed by the gradual destruction of the colony during the Little Ice Age ... didn't happen?
It is true that the Norse colonised Greenland around 1000 CE, and failed around 1300 CE. If this is meant to imply that, at that time, Greenland must have been much warmer than it is today, or that the little ice age marked a dramatic drop in temperatures, it's misleading. The reality is that there were only 2 Norse settlements in Greenland, located in fjords on Greenland's west coast. The areas of both those settlements are quite green and hospitable today, and there are several farms there now (Eastern settlment area, and Eastern settlment map; Western settlment area, and Western settlement map. Just for reference, here is a zoom of the area of the Brattahlid and Gardar farms (two of the largest/richest farms), and a zoom of the Sandnes farm area from the Western settlment), so Greenland need not have been any warmer than today to have provided the Norse with sustainable settlements. Further the archaeological evidence from the sites implies the Norse hardly had an easy life: Greenland cows were the smallest ever known, largely due to malnutrition, and it seems the cows and sheep may have had to be force fed seaweed over the winter to keep them alive -- and this was pre the little ice age. The Norse also tended to rely on trips to the Eastern Canadian coast, most likely the Labrador area, for many things, most particularly wood. Read Collapse by Jared Diamond for a good account of the settlement and decline of Greenland colonies. Climate was a factor, but one among many, and it didn't require much of a shift since the colonies were already in the brink due to other factors.
Is Greenland green yet or is it still covered in ice? If Vikings farmed there then, doesn't that mean the world was much much warmer than today?
With regard to the greenness of the areas of Greenland settled by the Norse, it seems Google maps and satellite photos can come to out aid. Consider these Googlemaps images of the sites for the Western and Eastern Settlements:
Eastern settlment area, and Eastern settlment map
Western settlment area, and Western settlement map.
Just for reference, here is a zoom of the area of the Brattahlid and Gardar farms (two of the largest/richest farms), and a zoom of the Sandnes farm area from the Western settlment.
Want more? How abut on the ground photos of the ruins?
Gardar ruins
Bratthlid ruins
Hvalsey church
So yes, Greenland was green with regard to where the Vikings settled, but then it has been the whole time, and still is today.
And the only correct documentation is the code itself. Anything else is a opinion and should be viewed accordingly.
Of course the code itself only tells you what the code does, not what the code is supposed to do, nor why it is doing it. Note that the difference can be rather crucial in maintenance and bug fixing.
I don't know how many times over my 30 year career that I've read documentation and started work only to find out later that it hadn't been updated. The first standard in your documentation rules should be that all relevant documentation is created and updated before code goes into production. No excuses.
Which is why it's always nice to have documentation that can be tested against the code. Now the "why" part of documentation is rather hard to verufy against code, but the "what it is supposed to do" should be able to be automatically verified if it is sensibly written: for instance in Eiffel requires and ensures clauses, or in JML, or splint, or SPARK; which allow for varying levels of static checking, runtime assertions, and automatic unit test generation (depending on what you are using) to ensure that if code and documentation falls out of sync an error should be immediately flagged.
Simple, clever doesn't pay the bills, reliable and maintainable do. It's a cost benefit analysis: if that clever one-liner saves many man-hours of work, then probably a good idea. If it saves you two or three lines of code and all of an addition 45 seconds, probably not worth the blow to maintainability and readability.
I view it as a premature optimization issue. It's very rare indeed that you save much time in writing code by doing something cute or clever; usually it's a matter of trying to do something slickly to save cpu time or memory. Rather than prematurely optimize I find it is best to try and write things in the most clear straightforward fashion first (even if it's not the most efficient implementation) and then go back later and make things more efficient if it proves to be necessary (often it doesn't because of real bottlenecks elsewhere).
how do you know the CO2 rise is man made in the first place, and not oh say from the oceans which are the largest stores of CO2?
By isotope analysis of atmospheric CO2. The isotope ratios for carbon from fossil fuels are distinct from those of carbon in CO2 outgassed from the oceans. By looking at the (changing) isotope ratios of atmospheric CO2 it is possible to track the relative origins of the increasing amounts of CO2 in the atmosphere. It turns out the increase is due to humans burning fossil fuels.
Name me ONE FUCKING ARTIST who started out with 100% original music
W. A. Mozart?
Mozart certainly started composing young, but he learned playing the works of others. Mozart is also an intriguing choice since he is an interesting early case of "music piracy": using he remarkable memory and musical talent he transcribed Miserere from memory after listening to it once (he did go back a second time to correct errors. At the time the piece was notable as having no transcriptions (of the very few floating around) that captured the beauty of of the annual performance at the Sistine chapel. Mozart's excellent transcription eventually made it to London where it was widely published and the piece was available all over Europe.
But if all you're doing is reinventing Perl with C-like syntax, it's not really a step forward.
Perl already has C-like syntax. It doesn't, however, have static type checking, let alone robust static type checking (with nice features like variance annotation etc.); nor does it have particularly robust functional programming support -- you can certainly do functional programming in Perl, but it isn't as clean and syntactically sugared as it could be; nor does perl have particularly clean OO if we're being honest -- yes it works and can be made to work quite well, but elegant isn't a word that comes to mind when I think Perl and OO; nor does Perl have function pattern matching and algebraic data types; nor does Perl have a nice concurrent programming interface based on the Actor model. None of this is really to say that Perl is bad -- it is very good for a great many things, and the features I've mentioned needn't hold it back. My point is that Scala is most certainly not re-inventing Perl. In fact Scala doesn't even have a particularly C-like syntax: it's less C-like than Perl really.
Of course if you take this line of thought seriously then you realise that Java and C# are the light options that don't really force you to do enough. If you were serious about being forced to be more explicit for the sake of maintainable code you would be using Eiffel, or Spec#, or JML abd ESC/Java2 with your Java, or SPARK-Ada, or writing specifications in B or Z. I'm betting you don't do any of that though because you view it as "too much work", even though many of those options (such as Spec# of JML) really aren't that much more work if you really are serious about robust maintainable code.