Well, provided that Gore and his cabal of evil Democrats push towards AGW on behalf of environmental lobbies, and that Bush and his cabal of evil Republicans push away from AGW on behalf of oil lobbies, I'd wager political pressure is too fragmented and inconsistent to have a significant impact.
Politically, climate change is a very contentious issue, both of the extreme positions being promoted by sides that can win elections. If the science behind it was significantly altered by political pressure, the current scientific consensus would be extremely difficult to reach, because different governments in different countries would push their own researchers in opposite ways. Worse even, a scientist could see his funding cut for showing evidence for AGW, and four years later, see his funding cut for showing evidence against it, because the new guys want different conclusions.
Interesting. That wouldn't be too bad, since forgetting to tag SQL code parts with the suffix would cause SQL code to become user data rather than the opposite. So for instance, declaring c as a string would just append c and d to the table name, likely causing a runtime error.
A similar idea could be implemented in pretty much any language, by using sql("abc") instead of "abc"sql, though I'm worried some people would misunderstand the purpose and wrap user data with it (which is at least not possible with a suffix on literals). I tend to prefer a more structured approach, but at least this one doesn't look like it would cause any security issues in practice (at first glance, anyway).
That would not work. Let's say that id is a string and contains "blabla AND 1 = 1". "SELECT * FROM table WHERE Id = " is a string. id is a string. The + operator has a string on its left and a string on its right. Therefore, it will do a string-on-string operation, yielding "SELECT * FROM table WHERE Id = blabla AND 1 = 1". And THEN, there will be a type conversion to safe_string. But it is too late! How exactly do you think you can sanitize the string now?
In general, when you build a query, there are strings you want to sanitize, and other strings which you do not want to sanitize. Consider the following:
string a = "SELECT * from "; string b = table; string c = " WHERE id = "; string d = id; safe_string query = a + b + c + d;
We want to sanitize b and d, but we don't want to sanitize a and c (or the result would not be a query). How exactly is your type system (or any type system for that matter) supposed to figure this out? You're just screwed. The only way your system can work is if the user explicitly marks every single string that must be sanitized, but that completely defeats the purpose.
The program could still compile, as long as it fails at runtime. Point is, I understand what you are saying, but such a library could be implemented in pretty much all languages that allow the definition and checking of custom types. It is perfectly possible to implement this feature in Python, Ruby or even the train wreck that is PHP, so at best it is really more a standard library problem than a language problem. But typing really doesn't have much to do with anything anyway: the first line of SQLfunc can very well be "sane_input = sanitize(input)", and then you don't even need a new type.
The real problem lies with writing SQL queries and passing them to a generic "execute" function. All languages will allow you to build a string like ("SELECT * FROM some_table WHERE column = " + name) which is not sanitized at all. If there is a way to execute that query, terrible things will happen and there is absolutely nothing you can do about it, because a SQL query string cannot be sanitized, you wouldn't be able to execute it otherwise. The only solution is to have libraries that do not allow executing SQL queries as strings, ever, period. But if that is the case, sanitizing inputs is not your problem anymore, it's the library's job. For instance you could write "results = select(ALL, table, where(equals(column, name)))", and obviously it should be part of these functions' contracts to sanitize their inputs. Virtually all languages can do this.
It is generally not a good idea to cry wolf too much. Once you get the grant, you have to actually find evidence for your claim, and if you don't, then you lose credibility. What you say is true, but over time the system will not sustain a lot of false alarms. Lying, misleading and falsifying data will rarely get you very far, because first, you will have to convince many intelligent people; second, because nobody wants to act on alarmist results without being certain. From the moment evidence is provided to support the "DANGER" position, the "there is nothing there" position, which amounts to reproducing experiments or trying to find alternative explanations, suddenly becomes viable. Grants are not given out of fear, they are given out of estimated impact. Economically, climate change is a pain in the ass, so if one could convincingly show the science to be bunk, they would not get snubbed. In other words, there are counterweights to the phenomenon you describe. The issue right now seems to be that climate skeptics actually do not have any leg to stand on and that convincing evidence and arguments for the skeptic position are nowhere to be found. In this case I would say that the window of opportunity for skepticism was there a couple decades ago, but instead of uncovering flaws in the theory the research vindicated it. So the window has closed.
There is no need to spend a lot on the skeptical viewpoint since there is no research to be done on that front. Billions will buy research, millions will buy people.
As for government interference, it's pretty obvious that conservatives (at least republicans and Canadian conservatives) are trying to push the skeptical point of view. I'm not sure how a government conspiracy to shove climate alarmism down our throats could survive eight years of Bush presidency and the staunch opposition of roughly half of the political spectrum. There has been intimidation, partisan appointments and attempts at censorship from the government *against* the theory of anthropogenic climate change, so at best I would say scientists have been getting a pretty damn mixed signal from big government.
Of course I guess you could just say these valiant heroes are putting their careers on the line saving us from the green apocalypse. But of course, they are nearly powerless in the face of the gargantuan amounts of money Al Gore has been personally channeling into universities with the help of the dark cabal with which he has deeply infiltrated all levels of government and acts in spite of whatever party is supposed to control it.
I could just as easily say that forcing beginners to understand that the semicolon at the end of a statement is not optional is asking for trouble. Forcing beginners to understand that a program might not behave as it looks is also asking for trouble. Beginners will have trouble with one particular kind of thing in syntax: features that seem useless or redundant. Forgetting the semicolon at the end of a statement is a common error in C/C++, precisely because it looks redundant with the line break, and that multi-line statements are comparatively rare. For this reason, line breaks should be significant. In general, significant whitespace is not intuitive: it makes no sense to differentiate "a + b" from "a+b", or "( a )" from "(a)". Languages that do these things are very annoying, and Python is not one of them.
As for significant indent, it depends on whether there is a block terminator or not. If your block is of the form "if condition then... end if", requiring indent for statements inside the block is completely redundant. However, if, as in Python, the block is precisely the statements that are indented, then there is no problem, because it is impossible to forget to indent. Once your block ends, you will wonder how to close it, and you will remember that "oh yeah, I need to indent". This is something all beginners can understand.
Beginners will actually have way less problems with Python's rules than with C's if statement. If you can write something like "if (cond)\n[indent]statement", and you want to add a new statement, the immediate intuition (of a beginner, anyway) is to add a second statement after the first one, indented the same. Of course, IDEs will help, but I can see a lot of beginners mess it up or wonder why it doesn't work.
Okay, so he is confusing the ability to solve the halting problem with the ability to understand why that's impossible.
That is probably a rather common error in the man versus machine debate, since a lot of philosophers have trouble wrapping their minds around what it means for a machine to "understand" something. There is a tendency to think that being able to understand the limitations of a system means we are not subject to these limitations, even though that is not true in general, and that even if it was, you would actually have to prove it first.
His argument was more like: "Human are capable of recognizing when an algorithm will halt (or not); computers are not; therefore thought cannot be reduced to computation".
That is patent nonsense, though, and if it is better than the caricature of your parent, it is only very barely so. There is no proof, nor even the shadow of a supporting argument, to the idea that humans are capable of recognizing when an algorithm will halt, for all possible algorithms.
First, only an astonishingly small subset of all algorithms is even intelligible to a human - if a computer was to solve the halting problem for "intelligible" programs, but was not itself "intelligible", how would you go about proving that such a program can't exist? All the proofs I know of imply applying the algorithm to a derivative of itself, but you can't do that if the algorithm does not belong to its own domain. And I see no reason - much to the contrary - to think that the brain is intelligible to itself (maybe the big picture is, but you don't solve the halting problem with an overview of the code).
Second, if you say an algorithm will not halt, how do you think you can be sure, without resorting to formal proofs... which are isomorphic to programs via the Curry–Howard correspondence?
Third, humans often miss rare or fringe cases, leading them to be overconfident in their answers for as long as these cases do not occur. I mean, if humans truly can solve the halting problem, they are not doing a very good job.
And then there is the fact that the halting problem is vastly overstated: by waiting long enough, a Turing machine can come arbitrarily close to solving it. Furthermore, there is a very large number of algorithms that pretty obviously halt/do not halt, for reasons that can be codified. There is nothing at all controversial with the idea that a computer could figure out whether the vast majority of programs halt or not. It just can't work for *everything*, but the idea that humans do is nothing short of laughable.
To me, the big pro of a command line is actually the usage paradigm: I type a command to get information, the information is displayed so that I can read it, and then the focus is on the prompt, leaving me free to do my next thing. I do stuff, I get a report about what was done, and once again, the focus is on the prompt, and I choose what to do next. The CLI, to me, is a log of command/report/command/report/etc., where at each step I can tell the computer what to do next.
Now, do I want pictures in my CLI? The answer is yes. I want to be able to type "show picture.jpg", and then have the picture pop up in the CLI, and then have a prompt for my next move. Yeah, yeah, I can open an image viewer from the command prompt already. But here's the thing: I do NOT want to open a window, because first, it is not as snappy, second, it means I have to close that goddamn window once I'm done looking at the picture (which will be a mere few seconds later in 99% of cases), and third, the image is nowhere to be found in my interaction log. It is not the end of the world, but I will gladly take what I can get.
Low resource usage has little relevance nowadays and all the prettifying should be on the client side anyhow - I mean, if you used this remotely, the remote node would produce html, and you would render it. This is not X, this is not a huge amount of traffic by any means, and worst comes to worst, html or json remain readable. This has nothing to do with automation either. The only difference is that instead of having a stream of text, you would get a stream of objects. If piping is done well, if existing programs work, if I can make compatible scripts painlessly, and if there is a pure text fallback (you never know in what pickle you will get), I will gladly take it.
I just want all the files modified in 1997: ls -l | grep 1997. Yeah, that's not suitable for usage in a script, but it's easy, so if I'm not looking for a general, reusable, bullet-proof "solution" and am just looking for output, it's quick as hell.
There are many, many ways that this could still work. If data is exchanged as JSON, grep could simply be outfitted in such a way that instead of returning lines that match, it returns records that match. For each record, it would try matching the string to all fields, recursively, and if there is a hit, the whole record is returned. I like this idea, if only because I have been known to deliberately cram a lot of information on single, hardly readable lines in the output of my scripts so that I could grep them.
Now, in the eventuality that you would want to use a tool that does not understand these fancy records, I do believe that the tool should still work as it always has (I assume you share the same concern). For this purpose, it would be reasonable to be able to tag programs as either understanding rich data or not. If a program outputs JSON to a program that is not marked as understanding it (by default, programs would be assumed not to support the feature), then the system could refuse to pipe one into the other, unless a *serializer* is provided to convert the JSON into the "normal" terminal output. For instance, the output of "ls" would simply revert to what it has been for the past forever years.
I do not know exactly what TermKit does, I will look into it. Worst comes to worst, I just might fork it and make it behave the way I think it should, if it is not too hard (if only for my own use).
The examples, while pretty, are ridiculous. If I want to display an image, I can open it in my GUI. If it's actually a common enough operation, I'll write a quick script so I can make it pop up by typing something: showimage blah.png.
Well, it doesn't have to be called "cat", but personally, I've always wanted a command that just displays an image directly in my terminal's output stream. I just want to *see* an image, I don't want to open a window (that I would close five seconds later with ctrl+w) and I don't want it to take over my console. I just want the image to be displayed, and my prompt to appear below it, ready to take the next command. Like for instance it would be really nice if "convert..." displayed the image it created in the output stream. Then I could see it immediately, be like "oh crap, -rotate is clockwise", and fix my mistake immediately, or I could fine tune some parameters, because after every command, I would see the image, and the focus would already be on the prompt. It would save some time - not a whole lot, but it sure would be nice.
This, like powershell, forgets that CLIs are user interfaces, and tries to force a bunch of "correctness" that we don't need on us. If it needs to handle weird filenames with newlines and shit in them--here's the critical part that the author is missing--I'll use something stronger than bash. You don't need to use the same interpreter as your scripting language as you do to hack around in a CLI.
But if you could, why wouldn't you? No tool will be perfect for all jobs, but that doesn't mean we can't get better tools than what we have now. Take "ls -l", for instance. Instead of displaying a list of files in plain text, it could display the exact same information in a sortable table, in essentially the same space. Now, if I wanted to sort files with buttons, I guess I could start a GUI file manager like dolphin or whatever, but if I just want to know what the most recent file is and I forget what the option is, I'd enjoy being able to do it in the little div ls would produce. I wouldn't like to start a file manager, have a window pop up half a second later, do a bunch of clicks, memorize the name of the file, close the window, and type my next command.
Fitness is an individual measure, though. Individuals are fit, not species, and it does not seem fair to compare a member of one species to a member of another species in terms of fitness. A rat which produces less mature offspring than most other rats could be said to be unfit (its genes will fail to spread), whereas a human who has more children than the average human will be deemed fit (their genes will spread faster), due to their respective competition. The "unfit" rat might be "fitter" than the "fit" human, but is that meaningful? They have very different lifespans, very different sizes and do not play in the same reproductive pool anyway. Apples and oranges.
Species as a whole could be said to be fitter in proportion of the total number of mature offspring a generation produces, but this is heavily and unequivocally slanted to the benefit of smaller organisms. It might be the correct definition of "fit", but I do not find it very meaningful or useful - obviously the same amount of resources can support more small organisms than big ones. Thus the count should at least be scaled by biomass (rats might still win, but at least the comparison is more fair).
As far as *species* go, to me, it makes more sense to define its "fitness" as its ability to spread its collective genes on a macroscopic time scale: a species is "fit" in proportion of the percentage of the biomass that runs on genes derived from the species (including members of the species itself). Thus the "first mammal species" (does that make sense?) was much fitter than all of its contemporaries that died without trace, because it had many more "offspring" (sub-species in this case). Under that definition, of course, it's rather difficult to evaluate fitness of contemporary species...
What does "successful" mean, though? Greater numbers? Resilience to environmental changes? I don't think "successful" is a particularly meaningful term - in an evolutionary sense, any species is successful as long as it does not go extinct, which makes all current species successful. Great numbers, large geographical extent, being at the top of the food chain, potential to survive catastrophic events could all be interpreted as "success", but depending on which you value more, you will rank species differently. I don't see any objective reason to consider that rats, as a species, are any more or less successful than we are.
Did they ask them to "describe the bias", or did they ask them "is there a bias?", and then asked them what kind of bias? Just wondering if the people really felt a bias or found one under the assumption that there was bias. Any opinion you hold will tend to make you more sensitive or tolerant to arguments for that position, moving your perception of "unbiased" in whatever direction your opinion pulls you. In all circumstances that would lead you to see some bias in a neutral piece, but of course more so if it is suggested to you that it is not neutral.
Until people get bitten by personal information being leaked to the wrong people, they will not care about their privacy. If your private photos get leaked to your employer and there are allusions or consequences that embarrass you, you might get mad enough about it to stop using the service. If they get leaked to faceless corporations that will crunch the data to suck as much money as possible out of you and your friends with targeted advertising, the connection is fuzzy, remote, indirect, and it is unlikely you will care at all. For 99.99% of people, the lack of privacy will have no effect they can relate to their use of the service. The remainder might get into trouble, but 0.01% of users has no pull. And if the whole of society was to get into trouble because of things like this getting out of hand, the responsibility will be diluted among everyone - ergo, still, nobody cares.
In short, people care about their privacy versus the core of people they interact with or might interact with in the future. Outside of that core, their information might be distributed on flyers in the streets of Bangkok for all they care. At best they will be momentarily disturbed by the thought.
People who "make rational attempts to critique or debunk global warming science" are hardly going against the grain of anything. Both sides of the debate on global warming have made inroads in pretty much all sizable communities. I see arguments from both sides modded up here. Same for liberal/conservative viewpoints. Doesn't make the arguments any less bitter, though.
Overall, posts and moderation seem to mirror the makeup of American society, with minor but not overwhelming slants. There might be an inflated perception of bias due to the fact that polemic opinions are more likely to attract counter-arguments from the other side than supportive posts from the same side. This is in contrast with real life where people are more likely to interact with like-minded people, getting reinforcement rather than confrontation.
Yes, *maybe* all life on earth has an intelligent designer behind it. It is mere speculation, though, and I don't see any reason why anybody would mod you up for saying that. Evolution is a theory with so much maturity and evidence behind it that intelligent design appears contrived by comparison. Virtually every single post, anywhere, that I have seen promoting ID shows a blatant misunderstanding of science, when it doesn't outright mislead, get facts wrong, or insists that the mere fact that something is possible makes it worthy of serious consideration.
So you can either point out that ID is possible - which isn't particularly interesting and should not be modded up (nor down) - or try to argue for it, which is nearly unfeasible without resorting to shoddy arguments and drawing the ire of people who know what they are talking about. I mean, I don't know what it is you want to say about ID, but it might very well be a case of "you don't get it" or "your point is not as interesting or relevant as you think". "Differing ideas" are cool and all, but sometimes, and forgive me for sounding a tad dismissive, they are uninteresting - and sometimes, they are just plain wrong. A good moderating system should not promote them.
Logic is not a limitation on anything but language - it certainly does not count as a "limitation" on omnipotence. To say that God is omnipotent does not mean that for each and every grammatically correct sentence representing an action, God can perform the action - what it means is that for each and every *action*, God can perform that action.
The key difference is that there is no bijection between the set of all actions and the set of all grammatically correct sentences that look like they are describing actions. Presumably, there exist actions (that an omnipotent being could do) that cannot be described with words. And conversely, there exist sentences that look like they are describing actions, but in fact describe nothing at all (so an omnipotent being does not have to be able to do what is described, because nothing is being described). Basically, logic cannot limit reality in any way, it only limits the range of acceptable descriptions.
Not that the actual existence of an omnipotent being makes much sense either way.
The brain is not monolithic, it is comprised of many parts and many layers that communicate with each other. I might have spoken vaguely, but the basic idea is that irrelevant stimuli is reaching parts of the brain that should not be receiving them, due to failures in the gateways that are supposed to filter them out or redirect them to parts of the brain that are meant to deal with noise. All these gateways are technically part of the brain, but it makes sense in my mind to separate the "routing" subsystems of the brain from the "processing" subsystems.
In your example, you could imagine that stimuli is routed through many places in your brain, including filters that will make a very rough analysis of the signal and determine whether you are hearing a language you can understand. Thanks to these filters, the language processing part of your brain will receive in priority all the English sounds, and the South Asian sounds will be blocked from being processed that way. You still hear Hindi, but the autopilot that analyzes English and other languages you know is never triggered. Over time, your brain might carve a subconscious circuit that will automatically notify you that "Hindi is being spoken", but that will be a separate circuit that does not interfere with others. Until you actually learn Hindi, the core "language and meaning processing" module of your brain simply never sees it.
In the case of a schizophrenic person, the Hindi might get through to English language processing, and that part of the brain, which normally operates under the handy assumption that it is analyzing English, will make them hear sentences that are a loose compromise between fitting the noise and being coherent. In general, the brain is comprised of many highly specialized parts that do an excellent job at analyzing certain particular kinds of data. In order for it to work as smoothly as possible, data has to be routed smartly and parsimoniously so that the right kind of data is given to the parts that are specialized for it. The idea is that letting spurious signals seep through to the parts of your brain that analyze salient events = schizophrenia. In other words, a schizophrenic brain, in some sense, might inadvertently assume it knows Hindi, because language-like signals indiscriminately fall through to meaning analysis, without the safeguards normal brains have. Obviously, it will do a catastrophic job at understanding it, but it might not have the resources it needs to figure out there is a problem at this level, so it will "adapt" in somewhat random ways, paving the way to even deeper troubles and madness.
I find the summary a bit confusing, though. What I have heard before is that the schizophrenic brain is poor at filtering out stimuli, meaning that unimportant details will stand out as much as important ones. For instance, it might have trouble filtering out ambient noise, so whereas a normal brain will cut off processing early on, a schizophrenic brain will process the noise the same way it would process salient, meaningful sounds. So what might happen is that the phoneme processing part of the brain will receive ambient noise as input and will make out voices and whispers out of it, because that is its job, and then these will be manipulated and interpreted as a conversation - maybe neighbors plotting against you, because why else would you be paying attention?
Stimuli that should never make it past saliency processing get dispatched to the brain, which assumes that if it got this far, it must be meaningful (this is normally a fair assumption). From then on, it will "learn" to find meaning in noise, hence visual or auditive hallucinations, delusions, etc. From what I can gather, this study shows that an excess of dopamine could inhibit normal filtering functions, hence the "hyperlearning" on stimuli that should be thrown out, but isn't.
The issue is that speedy changes might wreak havoc on many population centers, forcing them to relocate. A warmer planet might be nicer for humanity, but you'll be sacking one or two generations in the transition. To the extent that we are not willing to accept something as radical as sacrificing swaths of people all around the world for the good of their great-grandchildren, we'd rather make sure that if we can prevent it, we will. We can warm the planet at a slower, safer rate.
I think this underscores a major problem in this debate, though: nobody actually reads the papers, nor make a serious attempt at parsing the whole picture. People read press reports, aggregates, blogs, and everybody knows how much information gets distorted through these lenses. Or they will focus on a single graphic and give it much more relevance than is probably warranted by the hour an intern spent making it.
So the thing is, you will get people who will interpret some piece of information as saying that China will get flash flooded or something equally inane. Those of them who are climate alarmists will believe it, whereas those of them who are climate deniers will point to that as evidence that climate change is full of shit. Neither will realize that they are basing their beliefs on distortions. This makes reasonable discourse on this subject particularly difficult, since there is nothing you can say that you can guarantee won't be grossly misinterpreted by either fringe, and that's essentially what laymen will see in the end.
As far as I can tell, Ceylon uses = to initialize immutable variables, and:= to assign to mutable variables, so I doubt it really avoids any confusion.
I do like the idea of making syntactic distinctions between immutable and mutable variables, though. It can make code easier to read, when you can assume that some variables won't change and others probably will, especially in large function bodies.
Slashdot Mirror
Calling it "basic logic" implies that at some point in time most people had it. But that is false - they never did.
Well, provided that Gore and his cabal of evil Democrats push towards AGW on behalf of environmental lobbies, and that Bush and his cabal of evil Republicans push away from AGW on behalf of oil lobbies, I'd wager political pressure is too fragmented and inconsistent to have a significant impact.
Politically, climate change is a very contentious issue, both of the extreme positions being promoted by sides that can win elections. If the science behind it was significantly altered by political pressure, the current scientific consensus would be extremely difficult to reach, because different governments in different countries would push their own researchers in opposite ways. Worse even, a scientist could see his funding cut for showing evidence for AGW, and four years later, see his funding cut for showing evidence against it, because the new guys want different conclusions.
Interesting. That wouldn't be too bad, since forgetting to tag SQL code parts with the suffix would cause SQL code to become user data rather than the opposite. So for instance, declaring c as a string would just append c and d to the table name, likely causing a runtime error.
A similar idea could be implemented in pretty much any language, by using sql("abc") instead of "abc"sql, though I'm worried some people would misunderstand the purpose and wrap user data with it (which is at least not possible with a suffix on literals). I tend to prefer a more structured approach, but at least this one doesn't look like it would cause any security issues in practice (at first glance, anyway).
That would not work. Let's say that id is a string and contains "blabla AND 1 = 1". "SELECT * FROM table WHERE Id = " is a string. id is a string. The + operator has a string on its left and a string on its right. Therefore, it will do a string-on-string operation, yielding "SELECT * FROM table WHERE Id = blabla AND 1 = 1". And THEN, there will be a type conversion to safe_string. But it is too late! How exactly do you think you can sanitize the string now?
In general, when you build a query, there are strings you want to sanitize, and other strings which you do not want to sanitize. Consider the following:
string a = "SELECT * from ";
string b = table;
string c = " WHERE id = ";
string d = id;
safe_string query = a + b + c + d;
We want to sanitize b and d, but we don't want to sanitize a and c (or the result would not be a query). How exactly is your type system (or any type system for that matter) supposed to figure this out? You're just screwed. The only way your system can work is if the user explicitly marks every single string that must be sanitized, but that completely defeats the purpose.
The program could still compile, as long as it fails at runtime. Point is, I understand what you are saying, but such a library could be implemented in pretty much all languages that allow the definition and checking of custom types. It is perfectly possible to implement this feature in Python, Ruby or even the train wreck that is PHP, so at best it is really more a standard library problem than a language problem. But typing really doesn't have much to do with anything anyway: the first line of SQLfunc can very well be "sane_input = sanitize(input)", and then you don't even need a new type.
The real problem lies with writing SQL queries and passing them to a generic "execute" function. All languages will allow you to build a string like ("SELECT * FROM some_table WHERE column = " + name) which is not sanitized at all. If there is a way to execute that query, terrible things will happen and there is absolutely nothing you can do about it, because a SQL query string cannot be sanitized, you wouldn't be able to execute it otherwise. The only solution is to have libraries that do not allow executing SQL queries as strings, ever, period. But if that is the case, sanitizing inputs is not your problem anymore, it's the library's job. For instance you could write "results = select(ALL, table, where(equals(column, name)))", and obviously it should be part of these functions' contracts to sanitize their inputs. Virtually all languages can do this.
It is generally not a good idea to cry wolf too much. Once you get the grant, you have to actually find evidence for your claim, and if you don't, then you lose credibility. What you say is true, but over time the system will not sustain a lot of false alarms. Lying, misleading and falsifying data will rarely get you very far, because first, you will have to convince many intelligent people; second, because nobody wants to act on alarmist results without being certain. From the moment evidence is provided to support the "DANGER" position, the "there is nothing there" position, which amounts to reproducing experiments or trying to find alternative explanations, suddenly becomes viable. Grants are not given out of fear, they are given out of estimated impact. Economically, climate change is a pain in the ass, so if one could convincingly show the science to be bunk, they would not get snubbed. In other words, there are counterweights to the phenomenon you describe. The issue right now seems to be that climate skeptics actually do not have any leg to stand on and that convincing evidence and arguments for the skeptic position are nowhere to be found. In this case I would say that the window of opportunity for skepticism was there a couple decades ago, but instead of uncovering flaws in the theory the research vindicated it. So the window has closed.
There is no need to spend a lot on the skeptical viewpoint since there is no research to be done on that front. Billions will buy research, millions will buy people.
As for government interference, it's pretty obvious that conservatives (at least republicans and Canadian conservatives) are trying to push the skeptical point of view. I'm not sure how a government conspiracy to shove climate alarmism down our throats could survive eight years of Bush presidency and the staunch opposition of roughly half of the political spectrum. There has been intimidation, partisan appointments and attempts at censorship from the government *against* the theory of anthropogenic climate change, so at best I would say scientists have been getting a pretty damn mixed signal from big government.
Of course I guess you could just say these valiant heroes are putting their careers on the line saving us from the green apocalypse. But of course, they are nearly powerless in the face of the gargantuan amounts of money Al Gore has been personally channeling into universities with the help of the dark cabal with which he has deeply infiltrated all levels of government and acts in spite of whatever party is supposed to control it.
I could just as easily say that forcing beginners to understand that the semicolon at the end of a statement is not optional is asking for trouble. Forcing beginners to understand that a program might not behave as it looks is also asking for trouble. Beginners will have trouble with one particular kind of thing in syntax: features that seem useless or redundant. Forgetting the semicolon at the end of a statement is a common error in C/C++, precisely because it looks redundant with the line break, and that multi-line statements are comparatively rare. For this reason, line breaks should be significant. In general, significant whitespace is not intuitive: it makes no sense to differentiate "a + b" from "a+b", or "( a )" from "(a)". Languages that do these things are very annoying, and Python is not one of them.
As for significant indent, it depends on whether there is a block terminator or not. If your block is of the form "if condition then ... end if", requiring indent for statements inside the block is completely redundant. However, if, as in Python, the block is precisely the statements that are indented, then there is no problem, because it is impossible to forget to indent. Once your block ends, you will wonder how to close it, and you will remember that "oh yeah, I need to indent". This is something all beginners can understand.
Beginners will actually have way less problems with Python's rules than with C's if statement. If you can write something like "if (cond)\n[indent]statement", and you want to add a new statement, the immediate intuition (of a beginner, anyway) is to add a second statement after the first one, indented the same. Of course, IDEs will help, but I can see a lot of beginners mess it up or wonder why it doesn't work.
Okay, so he is confusing the ability to solve the halting problem with the ability to understand why that's impossible.
That is probably a rather common error in the man versus machine debate, since a lot of philosophers have trouble wrapping their minds around what it means for a machine to "understand" something. There is a tendency to think that being able to understand the limitations of a system means we are not subject to these limitations, even though that is not true in general, and that even if it was, you would actually have to prove it first.
His argument was more like: "Human are capable of recognizing when an algorithm will halt (or not); computers are not; therefore thought cannot be reduced to computation".
That is patent nonsense, though, and if it is better than the caricature of your parent, it is only very barely so. There is no proof, nor even the shadow of a supporting argument, to the idea that humans are capable of recognizing when an algorithm will halt, for all possible algorithms.
First, only an astonishingly small subset of all algorithms is even intelligible to a human - if a computer was to solve the halting problem for "intelligible" programs, but was not itself "intelligible", how would you go about proving that such a program can't exist? All the proofs I know of imply applying the algorithm to a derivative of itself, but you can't do that if the algorithm does not belong to its own domain. And I see no reason - much to the contrary - to think that the brain is intelligible to itself (maybe the big picture is, but you don't solve the halting problem with an overview of the code).
Second, if you say an algorithm will not halt, how do you think you can be sure, without resorting to formal proofs... which are isomorphic to programs via the Curry–Howard correspondence?
Third, humans often miss rare or fringe cases, leading them to be overconfident in their answers for as long as these cases do not occur. I mean, if humans truly can solve the halting problem, they are not doing a very good job.
And then there is the fact that the halting problem is vastly overstated: by waiting long enough, a Turing machine can come arbitrarily close to solving it. Furthermore, there is a very large number of algorithms that pretty obviously halt/do not halt, for reasons that can be codified. There is nothing at all controversial with the idea that a computer could figure out whether the vast majority of programs halt or not. It just can't work for *everything*, but the idea that humans do is nothing short of laughable.
To me, the big pro of a command line is actually the usage paradigm: I type a command to get information, the information is displayed so that I can read it, and then the focus is on the prompt, leaving me free to do my next thing. I do stuff, I get a report about what was done, and once again, the focus is on the prompt, and I choose what to do next. The CLI, to me, is a log of command/report/command/report/etc., where at each step I can tell the computer what to do next.
Now, do I want pictures in my CLI? The answer is yes. I want to be able to type "show picture.jpg", and then have the picture pop up in the CLI, and then have a prompt for my next move. Yeah, yeah, I can open an image viewer from the command prompt already. But here's the thing: I do NOT want to open a window, because first, it is not as snappy, second, it means I have to close that goddamn window once I'm done looking at the picture (which will be a mere few seconds later in 99% of cases), and third, the image is nowhere to be found in my interaction log. It is not the end of the world, but I will gladly take what I can get.
Low resource usage has little relevance nowadays and all the prettifying should be on the client side anyhow - I mean, if you used this remotely, the remote node would produce html, and you would render it. This is not X, this is not a huge amount of traffic by any means, and worst comes to worst, html or json remain readable. This has nothing to do with automation either. The only difference is that instead of having a stream of text, you would get a stream of objects. If piping is done well, if existing programs work, if I can make compatible scripts painlessly, and if there is a pure text fallback (you never know in what pickle you will get), I will gladly take it.
I just want all the files modified in 1997: ls -l | grep 1997. Yeah, that's not suitable for usage in a script, but it's easy, so if I'm not looking for a general, reusable, bullet-proof "solution" and am just looking for output, it's quick as hell.
There are many, many ways that this could still work. If data is exchanged as JSON, grep could simply be outfitted in such a way that instead of returning lines that match, it returns records that match. For each record, it would try matching the string to all fields, recursively, and if there is a hit, the whole record is returned. I like this idea, if only because I have been known to deliberately cram a lot of information on single, hardly readable lines in the output of my scripts so that I could grep them.
Now, in the eventuality that you would want to use a tool that does not understand these fancy records, I do believe that the tool should still work as it always has (I assume you share the same concern). For this purpose, it would be reasonable to be able to tag programs as either understanding rich data or not. If a program outputs JSON to a program that is not marked as understanding it (by default, programs would be assumed not to support the feature), then the system could refuse to pipe one into the other, unless a *serializer* is provided to convert the JSON into the "normal" terminal output. For instance, the output of "ls" would simply revert to what it has been for the past forever years.
I do not know exactly what TermKit does, I will look into it. Worst comes to worst, I just might fork it and make it behave the way I think it should, if it is not too hard (if only for my own use).
The examples, while pretty, are ridiculous. If I want to display an image, I can open it in my GUI. If it's actually a common enough operation, I'll write a quick script so I can make it pop up by typing something: showimage blah.png.
Well, it doesn't have to be called "cat", but personally, I've always wanted a command that just displays an image directly in my terminal's output stream. I just want to *see* an image, I don't want to open a window (that I would close five seconds later with ctrl+w) and I don't want it to take over my console. I just want the image to be displayed, and my prompt to appear below it, ready to take the next command. Like for instance it would be really nice if "convert ..." displayed the image it created in the output stream. Then I could see it immediately, be like "oh crap, -rotate is clockwise", and fix my mistake immediately, or I could fine tune some parameters, because after every command, I would see the image, and the focus would already be on the prompt. It would save some time - not a whole lot, but it sure would be nice.
This, like powershell, forgets that CLIs are user interfaces, and tries to force a bunch of "correctness" that we don't need on us. If it needs to handle weird filenames with newlines and shit in them--here's the critical part that the author is missing--I'll use something stronger than bash. You don't need to use the same interpreter as your scripting language as you do to hack around in a CLI.
But if you could, why wouldn't you? No tool will be perfect for all jobs, but that doesn't mean we can't get better tools than what we have now. Take "ls -l", for instance. Instead of displaying a list of files in plain text, it could display the exact same information in a sortable table, in essentially the same space. Now, if I wanted to sort files with buttons, I guess I could start a GUI file manager like dolphin or whatever, but if I just want to know what the most recent file is and I forget what the option is, I'd enjoy being able to do it in the little div ls would produce. I wouldn't like to start a file manager, have a window pop up half a second later, do a bunch of clicks, memorize the name of the file, close the window, and type my next command.
I do
Fitness is an individual measure, though. Individuals are fit, not species, and it does not seem fair to compare a member of one species to a member of another species in terms of fitness. A rat which produces less mature offspring than most other rats could be said to be unfit (its genes will fail to spread), whereas a human who has more children than the average human will be deemed fit (their genes will spread faster), due to their respective competition. The "unfit" rat might be "fitter" than the "fit" human, but is that meaningful? They have very different lifespans, very different sizes and do not play in the same reproductive pool anyway. Apples and oranges.
Species as a whole could be said to be fitter in proportion of the total number of mature offspring a generation produces, but this is heavily and unequivocally slanted to the benefit of smaller organisms. It might be the correct definition of "fit", but I do not find it very meaningful or useful - obviously the same amount of resources can support more small organisms than big ones. Thus the count should at least be scaled by biomass (rats might still win, but at least the comparison is more fair).
As far as *species* go, to me, it makes more sense to define its "fitness" as its ability to spread its collective genes on a macroscopic time scale: a species is "fit" in proportion of the percentage of the biomass that runs on genes derived from the species (including members of the species itself). Thus the "first mammal species" (does that make sense?) was much fitter than all of its contemporaries that died without trace, because it had many more "offspring" (sub-species in this case). Under that definition, of course, it's rather difficult to evaluate fitness of contemporary species...
What does "successful" mean, though? Greater numbers? Resilience to environmental changes? I don't think "successful" is a particularly meaningful term - in an evolutionary sense, any species is successful as long as it does not go extinct, which makes all current species successful. Great numbers, large geographical extent, being at the top of the food chain, potential to survive catastrophic events could all be interpreted as "success", but depending on which you value more, you will rank species differently. I don't see any objective reason to consider that rats, as a species, are any more or less successful than we are.
Did they ask them to "describe the bias", or did they ask them "is there a bias?", and then asked them what kind of bias? Just wondering if the people really felt a bias or found one under the assumption that there was bias. Any opinion you hold will tend to make you more sensitive or tolerant to arguments for that position, moving your perception of "unbiased" in whatever direction your opinion pulls you. In all circumstances that would lead you to see some bias in a neutral piece, but of course more so if it is suggested to you that it is not neutral.
Until people get bitten by personal information being leaked to the wrong people, they will not care about their privacy. If your private photos get leaked to your employer and there are allusions or consequences that embarrass you, you might get mad enough about it to stop using the service. If they get leaked to faceless corporations that will crunch the data to suck as much money as possible out of you and your friends with targeted advertising, the connection is fuzzy, remote, indirect, and it is unlikely you will care at all. For 99.99% of people, the lack of privacy will have no effect they can relate to their use of the service. The remainder might get into trouble, but 0.01% of users has no pull. And if the whole of society was to get into trouble because of things like this getting out of hand, the responsibility will be diluted among everyone - ergo, still, nobody cares.
In short, people care about their privacy versus the core of people they interact with or might interact with in the future. Outside of that core, their information might be distributed on flyers in the streets of Bangkok for all they care. At best they will be momentarily disturbed by the thought.
People who "make rational attempts to critique or debunk global warming science" are hardly going against the grain of anything. Both sides of the debate on global warming have made inroads in pretty much all sizable communities. I see arguments from both sides modded up here. Same for liberal/conservative viewpoints. Doesn't make the arguments any less bitter, though.
Overall, posts and moderation seem to mirror the makeup of American society, with minor but not overwhelming slants. There might be an inflated perception of bias due to the fact that polemic opinions are more likely to attract counter-arguments from the other side than supportive posts from the same side. This is in contrast with real life where people are more likely to interact with like-minded people, getting reinforcement rather than confrontation.
Yes, *maybe* all life on earth has an intelligent designer behind it. It is mere speculation, though, and I don't see any reason why anybody would mod you up for saying that. Evolution is a theory with so much maturity and evidence behind it that intelligent design appears contrived by comparison. Virtually every single post, anywhere, that I have seen promoting ID shows a blatant misunderstanding of science, when it doesn't outright mislead, get facts wrong, or insists that the mere fact that something is possible makes it worthy of serious consideration.
So you can either point out that ID is possible - which isn't particularly interesting and should not be modded up (nor down) - or try to argue for it, which is nearly unfeasible without resorting to shoddy arguments and drawing the ire of people who know what they are talking about. I mean, I don't know what it is you want to say about ID, but it might very well be a case of "you don't get it" or "your point is not as interesting or relevant as you think". "Differing ideas" are cool and all, but sometimes, and forgive me for sounding a tad dismissive, they are uninteresting - and sometimes, they are just plain wrong. A good moderating system should not promote them.
Logic is not a limitation on anything but language - it certainly does not count as a "limitation" on omnipotence. To say that God is omnipotent does not mean that for each and every grammatically correct sentence representing an action, God can perform the action - what it means is that for each and every *action*, God can perform that action.
The key difference is that there is no bijection between the set of all actions and the set of all grammatically correct sentences that look like they are describing actions. Presumably, there exist actions (that an omnipotent being could do) that cannot be described with words. And conversely, there exist sentences that look like they are describing actions, but in fact describe nothing at all (so an omnipotent being does not have to be able to do what is described, because nothing is being described). Basically, logic cannot limit reality in any way, it only limits the range of acceptable descriptions.
Not that the actual existence of an omnipotent being makes much sense either way.
The brain is not monolithic, it is comprised of many parts and many layers that communicate with each other. I might have spoken vaguely, but the basic idea is that irrelevant stimuli is reaching parts of the brain that should not be receiving them, due to failures in the gateways that are supposed to filter them out or redirect them to parts of the brain that are meant to deal with noise. All these gateways are technically part of the brain, but it makes sense in my mind to separate the "routing" subsystems of the brain from the "processing" subsystems.
In your example, you could imagine that stimuli is routed through many places in your brain, including filters that will make a very rough analysis of the signal and determine whether you are hearing a language you can understand. Thanks to these filters, the language processing part of your brain will receive in priority all the English sounds, and the South Asian sounds will be blocked from being processed that way. You still hear Hindi, but the autopilot that analyzes English and other languages you know is never triggered. Over time, your brain might carve a subconscious circuit that will automatically notify you that "Hindi is being spoken", but that will be a separate circuit that does not interfere with others. Until you actually learn Hindi, the core "language and meaning processing" module of your brain simply never sees it.
In the case of a schizophrenic person, the Hindi might get through to English language processing, and that part of the brain, which normally operates under the handy assumption that it is analyzing English, will make them hear sentences that are a loose compromise between fitting the noise and being coherent. In general, the brain is comprised of many highly specialized parts that do an excellent job at analyzing certain particular kinds of data. In order for it to work as smoothly as possible, data has to be routed smartly and parsimoniously so that the right kind of data is given to the parts that are specialized for it. The idea is that letting spurious signals seep through to the parts of your brain that analyze salient events = schizophrenia. In other words, a schizophrenic brain, in some sense, might inadvertently assume it knows Hindi, because language-like signals indiscriminately fall through to meaning analysis, without the safeguards normal brains have. Obviously, it will do a catastrophic job at understanding it, but it might not have the resources it needs to figure out there is a problem at this level, so it will "adapt" in somewhat random ways, paving the way to even deeper troubles and madness.
I find the summary a bit confusing, though. What I have heard before is that the schizophrenic brain is poor at filtering out stimuli, meaning that unimportant details will stand out as much as important ones. For instance, it might have trouble filtering out ambient noise, so whereas a normal brain will cut off processing early on, a schizophrenic brain will process the noise the same way it would process salient, meaningful sounds. So what might happen is that the phoneme processing part of the brain will receive ambient noise as input and will make out voices and whispers out of it, because that is its job, and then these will be manipulated and interpreted as a conversation - maybe neighbors plotting against you, because why else would you be paying attention?
Stimuli that should never make it past saliency processing get dispatched to the brain, which assumes that if it got this far, it must be meaningful (this is normally a fair assumption). From then on, it will "learn" to find meaning in noise, hence visual or auditive hallucinations, delusions, etc. From what I can gather, this study shows that an excess of dopamine could inhibit normal filtering functions, hence the "hyperlearning" on stimuli that should be thrown out, but isn't.
The issue is that speedy changes might wreak havoc on many population centers, forcing them to relocate. A warmer planet might be nicer for humanity, but you'll be sacking one or two generations in the transition. To the extent that we are not willing to accept something as radical as sacrificing swaths of people all around the world for the good of their great-grandchildren, we'd rather make sure that if we can prevent it, we will. We can warm the planet at a slower, safer rate.
I think this underscores a major problem in this debate, though: nobody actually reads the papers, nor make a serious attempt at parsing the whole picture. People read press reports, aggregates, blogs, and everybody knows how much information gets distorted through these lenses. Or they will focus on a single graphic and give it much more relevance than is probably warranted by the hour an intern spent making it.
So the thing is, you will get people who will interpret some piece of information as saying that China will get flash flooded or something equally inane. Those of them who are climate alarmists will believe it, whereas those of them who are climate deniers will point to that as evidence that climate change is full of shit. Neither will realize that they are basing their beliefs on distortions. This makes reasonable discourse on this subject particularly difficult, since there is nothing you can say that you can guarantee won't be grossly misinterpreted by either fringe, and that's essentially what laymen will see in the end.
As far as I can tell, Ceylon uses = to initialize immutable variables, and := to assign to mutable variables, so I doubt it really avoids any confusion.
I do like the idea of making syntactic distinctions between immutable and mutable variables, though. It can make code easier to read, when you can assume that some variables won't change and others probably will, especially in large function bodies.
I wish the left-pointing arrow was an ASCII character and/or standard on a US keyboard. It would be the perfect assignment operator :(
Well, I guess a language could use <-, but it's awkward.