"Conspiracy to Deprive Civil Rights...while acting under color of the laws... did knowingly and willfully conspire to injure, oppress, threaten, and intimidate Abner Louima in the free exercise and enjoyment of the rights and privileges secured to him by the Constitution and laws of the United States, to wit: the right to be free from the intentional use of unreasonable force by one acting under color of law." (from here)
Sounds similar to what the OP was talking about, although telling you you need ID doesn't sound like unreasonable force, exactly, unless your lawyer's a real fast talker...
If you have prototypes classes are not needed. They give no further possible abstraction. If you have only classes prototypes are not needed either, but they provide a lot of power you lose otherwise.
What you likely want to say is static typing versus dynamic typing. Most prototype bases languages are dynamic typed... so the method dispatch etc. is very much done during runtime.
No, I stand by what I said. Prototype-based languages typically allow the structure of instances to be modified arbitrarily, e.g. allowing variables to be added or even removed. This is part of what I meant by the structure provided by classes. Traditional class-based systems impose a contract on instances, which is not usually offered in prototype-based languages - the contract is that an instance conforms to the exact structure specified by the class. As it turns out, this does make it easier to do static typing, but that's a consequence of the underlying difference in the structural qualities of prototype vs. class-based systems. It's that underlying difference to which I was referring.
In case you want to "design" a larger system with a prototyped language, you of course "design" traits objects. They are just the same thing what classes are in C++/Java etc.
Your statement The structure provided by classes can be useful, too. comes irrelevant then, as the structure is the structure of the traits/prototype objects.
Certainly, I agree that there's a correspondence between e.g. classes and prototype objects. However, that correspondence is not exact - if it were, there'd be no difference between the two approaches. However, there is a difference, one of the main ones being what is allowable for instances cloned from prototypes, vs. instances instantiated from classes. It is this point which makes class-based programming more structured than the prototype equivalent, in general.
Voodoo1man's reply linked to a thread which hashes out some the issues with lambda in Python.
The brief summary is that there are currently two problems, that I know of offhand, with lambda in Python:
Statements are not allowed, only expressions.
Modifying the value of a variable in an enclosing scope is not allowed.
These are both quite severe restrictions that limit the ability to use lambda effectively, i.e. in ways that it is common to use them in languages which support lambda correctly.
In languages that implement lambda correctly, lambda and functions are equivalent: you can do anything inside a lambda that you can do inside any other function. In fact, in Scheme, Lisp, Javascript and Perl, lambdas *are* functions and vice versa - there's no significant distinction (other than how a function is associated with its name, if any).
Significantly restricting what you can do inside a lambda makes about as much sense as restricting what you can do inside a function: it cripples the construct. You can't get a real sense for what lambda can do, using Python, because in Python, lambda can't do what it can do in other languages.
A good language to learn to get a better understanding of lambda is Scheme. You can try this tutorial, and download PLT's DrScheme to play with it.
There does seem to be a fair amount of interest in prototype-based languages lately. Javascript's object system is also prototype-based, also inspired in part by Self, as well as Lisp/Scheme. Javascript may have helped trigger the current wave of interest in this subject.
Purely prototype-based languages don't really compete with their more structured (class-based) cousins, though. One of the main benefits of prototype-based langauges is that they give a lightweight way to create an abstraction - you don't necessarily have to create a class first. This isn't necessarily a pure win. The structure provided by classes can be useful, too. A good language should provide both capabilities, no matter what mechanisms it uses to do that. It's possible Slate does this, I haven't looked.
Another good candidate mechanism for lightweight abstraction is first class anonymous functions, i.e. lambda, as found in Scheme, Lisp, Javascript, Perl (Python got it wrong, unfortunately). Having real lambdas tends to eliminate a lot of the problems which other languages find themselves trying to solve. Although it helps to also have macros, which limits the list to Scheme and Lisp.
Re:Let's have a little poll.
on
Testing Relativity
·
· Score: 3, Interesting
If string theory is borne out, it will only be because it's the most ridiculous kludge you can imagine - epicycles all over again. But maybe the anomalies in the upcoming results will help someone figure out a better solution. It's great to see some tests, any tests!
For programming to get "good" it's going to have to get unfun. No more will long haired super cool geniuses plug away for hours on end.
It'll have to be a managed engineering process with all the fun and excitement of a CPA convention.
This only works when no innovation is necessary. You can't CPA-ify innovation (at least, no-one has ever succeeded at that). That's why big companies have to buy small companies, and why big companies run research departments for the long-haired super cool geniuses to play.
I'm dying to know whether you actually know what the reference is. The real reference is hardly obscure, so I'm wondering if you're imagining it originated in some cult movie or something (Monty Python?) instead of a classic work of literature.
Hint: the real reference spawned a new word in the English language (and probably one or two other languages, also).
I wonder if a company semi-secretly paying another company to smear its competition could be construed as a violation of the RICO act? Probably a stretch, but it would be oh-so-fitting if Microsoft could be brought down the same way the Mafia were. It worked on Michael Milken, after all...
I have a Debian server rented at a hosting company that gets 30Mbps actual throughput to various Debian mirrors and other download sites. Who needs a local mirror, all you need are fat pipes!;)
Scheme is more like Python than it is like Haskell, so I really cannot see why you'd name Python imperative while naming Scheme a FP.
That reveals a lot about your knowledge of FP. FP is not just having a grab bag of functions like map, filter, reduce, or list comprehensions, or anything like that. That's superficial surface stuff, but it's the underlying semantics that are important.
The first problem with Python & FP is simply that it's not an expression-based language. It's fundamentally imperative in the sense that programs consist of sequences of statements, which rely on mutable state to communicate. This alone prevents you from writing real functional programs in Python, and is also one of the major issues which makes programs harder to reason about, harder to debug, and buggier. (As an aside, this is one of the areas in which Python's lambda is broken - they are restricted in what can appear in them.)
Although Scheme allows this sequence-of-statements programming style, good Scheme code doesn't use it. Scheme is expression-based, and programs can be composed of nothing but referentially-transparent expressions. This alone makes Scheme functional, and is more or less the flip side of the issue which makes Python non-functional.
Anything you can do in languages like Haskell or ML can be implemented quite directly in Scheme, using macros. The reason this is possible is that all of these are based on lambda calculus, at their core. The same can't be claimed of Python.
The second problem with Python is that it doesn't handle recursion well, and its built-in data structures like lists are not recursive structures. Although Stackless Python does a better job of supporting recursion at a low level, it still doesn't fix the data structure issue. Recursive programs which process recursive data structures are a fundamental feature of functional languages, and Python just doesn't do that well.
So, when you say "I feel very comfortable writing Functional-style python, and yet I still prefer to write some of my code in more imperative style", you're talking about using some fairly superficial functional features embedded in a fundamentally imperative language.
No offense, but I'm afraid you're an example of one of my pet peeves, which is that people are going around thinking this is "functional", and based on that, feeling assured that imperative makes more sense. Of course it does, in an imperative language! What's happening is that people are being discouraged from learning about important and powerful programming concepts and techniques, because they think they already have them. You've been conned.
What you call the real-world test reflects what people have been brought up on - a result of the evolution of computing to date. It's like the days before engineers knew how to build bridges that didn't shake themselves apart. Heck, I was brought up on it myself - all I learned at university were imperative languages. You can't change the training of millions of programmers overnight, or all the legacy code that's in use.
As I said, I don't even think people should or could all switch to functional languages right now, because those languages haven't evolved in terms of libraries and tools to support the applications that most people need to write. However, I do think that anyone who considers themselves a good programmer and doesn't want to stagnate, should make a real effort to learn more about functional programming - more than you can learn within an imperative language like Python. The knowledge you gain will translate back into your program designs, and you'll design and write better code as a result.
The real-world situation now can be compared to what it was 10 or 20 years ago. You could have said the same things you're saying about "real world" back then about features like automatic garbage collection, or object orientation - and people did say those things. They said they w
I'm curious about whether you think it was a good emulation of Hunter Thompson. I read some of Thompson's work a long time ago, and my memory is that it was a lot more compelling. With this article, I should have been interested - the topic interests me in general - but I found the piece was just fluffy and melodramatic. That's not what I remember Thompson being like.
Python fits the way most human minds work, including those of experienced programmers, like myself or the more-experienced Eric Raymond.
Sorry, but this is nonsense. How much experience have you had with imperative languages, and how much with functional? Same goes for ESR, no matter how experienced he is. In fact, more experience can be a disadvantage here. What you're describing is simply what happens when a particular approach has become ingrained. People who are introduced to functional languages first find the imperative approach unnatural, not to mention buggy (unfettered variable mutation tends to seem abhorrent, for good reason).
I agree that the *pure* FP languages have practicality issues. But your original post broadened to cover FP in general, and that's what I'm taking issue with.
You talked about whether practical code bases are available. I'm not suggesting that everyone can switch to functional languages right now, or that they should. I'm saying that languages are evolving in directions that the functional and academic languages have long recognized as important, and that the functional languages have more coherent models for just about every feature that traditional languages offer. The FP languages are almost more important for learning about these models, than they are for actual programming right now.
Object-orientation in traditional languages is an unholy mess, for example, an example of the kind of ad-hoc crap I was talking about. You'll get more insight into what OO is attempting to achieve if you examine Haskell's typeclasses (or you can play with them in Scheme, via this post).
Re LOC, if you compare apples with apples, functional languages are usually better at LOC than traditional languages, and that's part of their point. They support higher levels of abstraction, which is one of the reasons people think they're mind-boggling. Many people can't deal with the abstraction, so they prefer to hand-code similar stuff over and over. So yeah, if you write naive code in a functional language and don't take advantage of its features, you'll have higher LOC - but that's once again the effect of someone with only imperative language experience using something they're unfamiliar with.
Another reason to learn about functional programming is because if you accept the features that the imperative languages give you as models, you're being screwed. For example, Stackless Python adds continuations to Python, and Perl 6 is supposed to get continuations, and there's a version of Javascript with continuations, but in all cases it's a kind of bizarro-world implementation of the feature, which can entirely put people off from important concepts. An example of this happening is with Python's lambda, which messed up the lexical scope issue and so makes people think lambda isn't particularly useful.
In fact, one person who claims that imperative languages fit human minds better is Guido van Rossum. He says that because he has a certain model already burnt into his brain. It's ironic that he said it about recursion, which is one of the things that actually makes all sorts of programming much easier and more manageable, once you understand how to use it. Anyway, if you want to be smarter than Guido van Rossum, you need to learn more about FP. Otherwise, you're doomed to be learning from people like him, and unfortunately, they're just confused.
Make no mistake: all of this "more natural for humans" stuff is just your brain rebelling against having to deprecate any of the investment you've already made in learning imperative languages, and having to invest effort in starting from scratch learning a different model. Don't kid yourself that you know anything true about these other languages, until you've actually put in the effort to learn them to the point where programming in them feels natural.
I don't think the OP's solution was the most transparent, but that's not Haskell's fault.
It's simply wrong to assume that because you see code you don't understand when you're looking at an advanced language that you don't know, that those languages "are simply mind-boggling, and no - that's not a good thing".
What those languages are, are different than what you're used to. There's a reason for that - what you're used to is largely an ad-hoc collection of crap that evolved before people understood what computers were really about. Now, we have good models for things like abstraction and control flow and structure in languages, but unfortunately, languages like C and Java and C# don't even begin to take advantage of these models.
Really, you shouldn't focus on learning FP languages. Focus instead on learning basic computing principles, as you'll find in a book like SICP. Once you understand basic computing principles, you'll understand why and how functional languages make sense, and why ultimately, the crappy languages we have today will evolve in that direction. You already see it happening, in fact, as various languages slowly absorb academic features that have been around for decades - it just happens very slowly. You can get a jump on the next 30 years of language evolution by learning something about the underlying principles, right now.
Haskell is just one possible expression of functional principles, and it's one that emphasizes purity and syntactic conciseness. That doesn't always result in the most friendly code. Neither of these constraints are fundamental to functional languages in general. You might find ML, or Scheme, or Erlang, or OCaml more to your taste. But if you ignore FP because you think it's mind-boggling, you're simply admitting that you're not serious about programming.
I think this practice goes beyond embedded systems, device drivers, and kernel modules. You'll find this sort of thing quite routinely in data structures (or classes, in the C++ case) implemented in libraries. I.e. some data structure, say a hash table, will heap allocate a big chunk, and use it up bit by bit - even when the structure itself could easily support incremental allocation. There are good reasons to do this sort of thing, having to do with allocation cost, heap fragmentation, and locality of reference. The latter can have performance effects on things like CPU the effectiveness of the CPU cache.
However, this is probably a lot less common in "end programmer" code, as it should be. It used to be a lot more common, I suspect, because machines were slower, had less memory, and the negative effects of relying blindly on heap allocation for everything were more evident. A lot of "sins" are covered today (or are no longer sins) by the speed of processors & memory.
Hell, with the strength of the pound against the dollar even I might buy it! $3,950,000 that's like, what, 2 grand of my money? (just getting one back for the Canadians)
This makes no sense. You'd be much better off spending your 2 grand in Canada, where it would be worth something like a billion Canadian dollars. You could probably buy most of Toronto!
We didn't ask for all these particles to show up. We're just trying to figure out what we're seeing in nature.
It's worth bearing in mind that one might have said the same sort of thing back when epicycles were the state of the art way to describe planetary orbits: "we didn't ask for all these epicycles to show up. We're just trying to figure out what we're seeing in nature."
I find this such a pathetic comment on education and business.
Look at all the people in school. When they graduate they should be able to cure diseases or invent spaceships. Look at all these people thinking they can just bank on their respectability and take over jobs doable by dumbasses.
One problem is that curing diseases and inventing spaceships requires huge organizations to fund the activity, and someone with the paper qualifications to cure diseases and invent spaceships can't necessarily just walk into a position that actually allows them to do that. So the choices are often between doing something boring and menial working as an employee for someone else, or something boring and menial working for yourself. With the former, you don't control your destiny - there's no guarantee you'll ever get to work on what you really are good at, you can be laid off, etc.
That is just selfish and cowardly.
That's a bit narrow-minded. One flaw in your reasoning is the idea that these are jobs "doable by dumbasses". The only people who hire dumbasses to work for them, are other dumbasses. When I hire, say, a landscaping company, I want someone who I can communicate with, who understands my needs, who's reliable, etc. Dealing with the dumbasses is a waste of my time. There's room for a range of qualities of service, and someone providing a high-class version of a service, at a higher price, is not "taking over the jobs doable by dumbasses", he's doing something the dumbasses can't do.
More correctly, the existence of the Higgs boson validates an assumption in a theory and theory is what claims to explain why all other particles have mass. The important thing to remember is that these are theories that are explaining things; real world particles explain nothing.
I would be careful of pissing off the Higgs boson if I were you. If it decides to stop explaining your mass, you're in trouble!
ARE YOU FUCKING BLIND!!!! al Queda doesn't give a rats ass about politics. If you are anything BUT of the Islamic faith, you are scum and condemed to hell by the rath of Alah (read the Quran sometime).
Or, read the Bible sometime. I have a hard time seeing any significant difference between it and the Koran. The God of the bible instructs people to go out and slaughter entire communities, women, children, babies and goats included. Now, Christians will protest "that's the old testament!", as though Jesus actually died for *God's* sins and washed them all away. (The religion would actually make a lot more sense that way.) But mainstream Islam will tell you the same thing - that bad old stuff in the Koran should be ignored, just as the bad old stuff in the bible should be ignored.
Balan's exaggerating about the currency
on
Spam Bits
·
· Score: 1
...it's really $140,000 Canadian, which is like, $372 U.S.
From what the Horizon documentary said it is not clear that a sufficient value of "a long way off" is available on the Earths surface.
So it could be that the death wish is mandatory.
If you're outside the continental U.S., the direct effects of the eruption are unlikely to be a problem. But the global climatic effects could be a problem for everyone, severely affecting food production, for example. The Horizon documentary pointed to genetic evidence that indicated that the global human population shrunk significantly during the last supervolcano eruption.
Anyone with a shed full of missiles, that's planning to try something like this, presumably would also set up a bunker out of harms way (i.e. off-continent) with a few year's supply of food. And if not, well, Darwin works in mysterious ways...
The next due date for an eruption is, well, any century now...
No. People keep saying it's on a "clockwork" eruption cycle and we're "overdue". ...
The fact is we don't know when Yellowstone will erupt, it could be tomorrow, it could be in a million years.
The way I might put that is, "The next due date for an eruption is, well, any century now..."
Could you please be a little more specific when saying the "right (or wrong) way".
Sure - I'm always up for an adjustment of the status quo. All you have to do is breach the main magma chamber such that it is exposed to more or less normal atmospheric pressure. The gases that are currently dissolved in the magma, under pressure, will then release explosively.
It's analogous to the cork on a champagne bottle: you only have to remove the cork a little way - providing a route for pressure equalization - and all the gas bubbles dissolved in the champagne simultaneously decide to head for freedom, taking the cork with them.
But a champagne bottle is more like a regular volcano: it has a neck which constrains the flow of champagne, like an ordinary volcano's primary magma conduit. That happens because normal volcanos have magma chambers far below the surface of the earth, which severely constrains the escape of magma.
In Yellowstone's case, there's a large magma chamber much closer to the surface, the heat of which causes all the geysers and other geologic activity in Yellowstone. If that magma chamber is breached, the magma escaping under pressure won't have to force its way through nearly as much rock. Instead, much of Yellowstone and the surrounding region will become the cork on a well-shaken champagne bottle without a neck.
It just happens that I have 15 SS-21 warheads in my garden shed, and with some general pointers, I might be able to speed things along a little bit.
I suspect that bombarding the surface may not help much, unless you get lucky and vibrations deeper down cause something to crack. I think you're looking at a venture along the lines used in the asteroid-hitting-Earth movies: you're going to have to drill a bunch of holes a few miles deep, preferably at widely spaced points around the caldera's 1500 square mile area. Then insert your warheads, rigged with remote detonators or people very dedicated to your cause, down to the bottom of the holes. Unless you have a death wish, I suggest being on the other side of the planet when triggering the detonation.
Slashdot Mirror
Sounds similar to what the OP was talking about, although telling you you need ID doesn't sound like unreasonable force, exactly, unless your lawyer's a real fast talker...
Certainly, I agree that there's a correspondence between e.g. classes and prototype objects. However, that correspondence is not exact - if it were, there'd be no difference between the two approaches. However, there is a difference, one of the main ones being what is allowable for instances cloned from prototypes, vs. instances instantiated from classes. It is this point which makes class-based programming more structured than the prototype equivalent, in general.
The brief summary is that there are currently two problems, that I know of offhand, with lambda in Python:
- Statements are not allowed, only expressions.
- Modifying the value of a variable in an enclosing scope is not allowed.
These are both quite severe restrictions that limit the ability to use lambda effectively, i.e. in ways that it is common to use them in languages which support lambda correctly.In languages that implement lambda correctly, lambda and functions are equivalent: you can do anything inside a lambda that you can do inside any other function. In fact, in Scheme, Lisp, Javascript and Perl, lambdas *are* functions and vice versa - there's no significant distinction (other than how a function is associated with its name, if any).
Significantly restricting what you can do inside a lambda makes about as much sense as restricting what you can do inside a function: it cripples the construct. You can't get a real sense for what lambda can do, using Python, because in Python, lambda can't do what it can do in other languages.
A good language to learn to get a better understanding of lambda is Scheme. You can try this tutorial, and download PLT's DrScheme to play with it.
Purely prototype-based languages don't really compete with their more structured (class-based) cousins, though. One of the main benefits of prototype-based langauges is that they give a lightweight way to create an abstraction - you don't necessarily have to create a class first. This isn't necessarily a pure win. The structure provided by classes can be useful, too. A good language should provide both capabilities, no matter what mechanisms it uses to do that. It's possible Slate does this, I haven't looked.
Another good candidate mechanism for lightweight abstraction is first class anonymous functions, i.e. lambda, as found in Scheme, Lisp, Javascript, Perl (Python got it wrong, unfortunately). Having real lambdas tends to eliminate a lot of the problems which other languages find themselves trying to solve. Although it helps to also have macros, which limits the list to Scheme and Lisp.
If string theory is borne out, it will only be because it's the most ridiculous kludge you can imagine - epicycles all over again. But maybe the anomalies in the upcoming results will help someone figure out a better solution. It's great to see some tests, any tests!
Hint: the real reference spawned a new word in the English language (and probably one or two other languages, also).
I wonder if a company semi-secretly paying another company to smear its competition could be construed as a violation of the RICO act? Probably a stretch, but it would be oh-so-fitting if Microsoft could be brought down the same way the Mafia were. It worked on Michael Milken, after all...
I have a Debian server rented at a hosting company that gets 30Mbps actual throughput to various Debian mirrors and other download sites. Who needs a local mirror, all you need are fat pipes! ;)
Scheme is more like Python than it is like Haskell, so I really cannot see why you'd name Python imperative while naming Scheme a FP.
That reveals a lot about your knowledge of FP. FP is not just having a grab bag of functions like map, filter, reduce, or list comprehensions, or anything like that. That's superficial surface stuff, but it's the underlying semantics that are important.
The first problem with Python & FP is simply that it's not an expression-based language. It's fundamentally imperative in the sense that programs consist of sequences of statements, which rely on mutable state to communicate. This alone prevents you from writing real functional programs in Python, and is also one of the major issues which makes programs harder to reason about, harder to debug, and buggier. (As an aside, this is one of the areas in which Python's lambda is broken - they are restricted in what can appear in them.)
Although Scheme allows this sequence-of-statements programming style, good Scheme code doesn't use it. Scheme is expression-based, and programs can be composed of nothing but referentially-transparent expressions. This alone makes Scheme functional, and is more or less the flip side of the issue which makes Python non-functional.
Anything you can do in languages like Haskell or ML can be implemented quite directly in Scheme, using macros. The reason this is possible is that all of these are based on lambda calculus, at their core. The same can't be claimed of Python.
The second problem with Python is that it doesn't handle recursion well, and its built-in data structures like lists are not recursive structures. Although Stackless Python does a better job of supporting recursion at a low level, it still doesn't fix the data structure issue. Recursive programs which process recursive data structures are a fundamental feature of functional languages, and Python just doesn't do that well.
So, when you say "I feel very comfortable writing Functional-style python, and yet I still prefer to write some of my code in more imperative style", you're talking about using some fairly superficial functional features embedded in a fundamentally imperative language. No offense, but I'm afraid you're an example of one of my pet peeves, which is that people are going around thinking this is "functional", and based on that, feeling assured that imperative makes more sense. Of course it does, in an imperative language! What's happening is that people are being discouraged from learning about important and powerful programming concepts and techniques, because they think they already have them. You've been conned.
What you call the real-world test reflects what people have been brought up on - a result of the evolution of computing to date. It's like the days before engineers knew how to build bridges that didn't shake themselves apart. Heck, I was brought up on it myself - all I learned at university were imperative languages. You can't change the training of millions of programmers overnight, or all the legacy code that's in use.
As I said, I don't even think people should or could all switch to functional languages right now, because those languages haven't evolved in terms of libraries and tools to support the applications that most people need to write. However, I do think that anyone who considers themselves a good programmer and doesn't want to stagnate, should make a real effort to learn more about functional programming - more than you can learn within an imperative language like Python. The knowledge you gain will translate back into your program designs, and you'll design and write better code as a result.
The real-world situation now can be compared to what it was 10 or 20 years ago. You could have said the same things you're saying about "real world" back then about features like automatic garbage collection, or object orientation - and people did say those things. They said they w
Sorry, but this is nonsense. How much experience have you had with imperative languages, and how much with functional? Same goes for ESR, no matter how experienced he is. In fact, more experience can be a disadvantage here. What you're describing is simply what happens when a particular approach has become ingrained. People who are introduced to functional languages first find the imperative approach unnatural, not to mention buggy (unfettered variable mutation tends to seem abhorrent, for good reason).
I agree that the *pure* FP languages have practicality issues. But your original post broadened to cover FP in general, and that's what I'm taking issue with.
You talked about whether practical code bases are available. I'm not suggesting that everyone can switch to functional languages right now, or that they should. I'm saying that languages are evolving in directions that the functional and academic languages have long recognized as important, and that the functional languages have more coherent models for just about every feature that traditional languages offer. The FP languages are almost more important for learning about these models, than they are for actual programming right now.
Object-orientation in traditional languages is an unholy mess, for example, an example of the kind of ad-hoc crap I was talking about. You'll get more insight into what OO is attempting to achieve if you examine Haskell's typeclasses (or you can play with them in Scheme, via this post).
Re LOC, if you compare apples with apples, functional languages are usually better at LOC than traditional languages, and that's part of their point. They support higher levels of abstraction, which is one of the reasons people think they're mind-boggling. Many people can't deal with the abstraction, so they prefer to hand-code similar stuff over and over. So yeah, if you write naive code in a functional language and don't take advantage of its features, you'll have higher LOC - but that's once again the effect of someone with only imperative language experience using something they're unfamiliar with.
Another reason to learn about functional programming is because if you accept the features that the imperative languages give you as models, you're being screwed. For example, Stackless Python adds continuations to Python, and Perl 6 is supposed to get continuations, and there's a version of Javascript with continuations, but in all cases it's a kind of bizarro-world implementation of the feature, which can entirely put people off from important concepts. An example of this happening is with Python's lambda, which messed up the lexical scope issue and so makes people think lambda isn't particularly useful.
In fact, one person who claims that imperative languages fit human minds better is Guido van Rossum. He says that because he has a certain model already burnt into his brain. It's ironic that he said it about recursion, which is one of the things that actually makes all sorts of programming much easier and more manageable, once you understand how to use it. Anyway, if you want to be smarter than Guido van Rossum, you need to learn more about FP. Otherwise, you're doomed to be learning from people like him, and unfortunately, they're just confused.
Make no mistake: all of this "more natural for humans" stuff is just your brain rebelling against having to deprecate any of the investment you've already made in learning imperative languages, and having to invest effort in starting from scratch learning a different model. Don't kid yourself that you know anything true about these other languages, until you've actually put in the effort to learn them to the point where programming in them feels natural.
It's simply wrong to assume that because you see code you don't understand when you're looking at an advanced language that you don't know, that those languages "are simply mind-boggling, and no - that's not a good thing".
What those languages are, are different than what you're used to. There's a reason for that - what you're used to is largely an ad-hoc collection of crap that evolved before people understood what computers were really about. Now, we have good models for things like abstraction and control flow and structure in languages, but unfortunately, languages like C and Java and C# don't even begin to take advantage of these models.
Really, you shouldn't focus on learning FP languages. Focus instead on learning basic computing principles, as you'll find in a book like SICP. Once you understand basic computing principles, you'll understand why and how functional languages make sense, and why ultimately, the crappy languages we have today will evolve in that direction. You already see it happening, in fact, as various languages slowly absorb academic features that have been around for decades - it just happens very slowly. You can get a jump on the next 30 years of language evolution by learning something about the underlying principles, right now.
Haskell is just one possible expression of functional principles, and it's one that emphasizes purity and syntactic conciseness. That doesn't always result in the most friendly code. Neither of these constraints are fundamental to functional languages in general. You might find ML, or Scheme, or Erlang, or OCaml more to your taste. But if you ignore FP because you think it's mind-boggling, you're simply admitting that you're not serious about programming.
However, this is probably a lot less common in "end programmer" code, as it should be. It used to be a lot more common, I suspect, because machines were slower, had less memory, and the negative effects of relying blindly on heap allocation for everything were more evident. A lot of "sins" are covered today (or are no longer sins) by the speed of processors & memory.
This makes no sense. You'd be much better off spending your 2 grand in Canada, where it would be worth something like a billion Canadian dollars. You could probably buy most of Toronto!
It's worth bearing in mind that one might have said the same sort of thing back when epicycles were the state of the art way to describe planetary orbits: "we didn't ask for all these epicycles to show up. We're just trying to figure out what we're seeing in nature."
I would be careful of pissing off the Higgs boson if I were you. If it decides to stop explaining your mass, you're in trouble!
Or, read the Bible sometime. I have a hard time seeing any significant difference between it and the Koran. The God of the bible instructs people to go out and slaughter entire communities, women, children, babies and goats included. Now, Christians will protest "that's the old testament!", as though Jesus actually died for *God's* sins and washed them all away. (The religion would actually make a lot more sense that way.) But mainstream Islam will tell you the same thing - that bad old stuff in the Koran should be ignored, just as the bad old stuff in the bible should be ignored.
...it's really $140,000 Canadian, which is like, $372 U.S.
Anyone with a shed full of missiles, that's planning to try something like this, presumably would also set up a bunker out of harms way (i.e. off-continent) with a few year's supply of food. And if not, well, Darwin works in mysterious ways...
Sure - I'm always up for an adjustment of the status quo. All you have to do is breach the main magma chamber such that it is exposed to more or less normal atmospheric pressure. The gases that are currently dissolved in the magma, under pressure, will then release explosively.
It's analogous to the cork on a champagne bottle: you only have to remove the cork a little way - providing a route for pressure equalization - and all the gas bubbles dissolved in the champagne simultaneously decide to head for freedom, taking the cork with them.
But a champagne bottle is more like a regular volcano: it has a neck which constrains the flow of champagne, like an ordinary volcano's primary magma conduit. That happens because normal volcanos have magma chambers far below the surface of the earth, which severely constrains the escape of magma.
In Yellowstone's case, there's a large magma chamber much closer to the surface, the heat of which causes all the geysers and other geologic activity in Yellowstone. If that magma chamber is breached, the magma escaping under pressure won't have to force its way through nearly as much rock. Instead, much of Yellowstone and the surrounding region will become the cork on a well-shaken champagne bottle without a neck.
It just happens that I have 15 SS-21 warheads in my garden shed, and with some general pointers, I might be able to speed things along a little bit.
I suspect that bombarding the surface may not help much, unless you get lucky and vibrations deeper down cause something to crack. I think you're looking at a venture along the lines used in the asteroid-hitting-Earth movies: you're going to have to drill a bunch of holes a few miles deep, preferably at widely spaced points around the caldera's 1500 square mile area. Then insert your warheads, rigged with remote detonators or people very dedicated to your cause, down to the bottom of the holes. Unless you have a death wish, I suggest being on the other side of the planet when triggering the detonation.
Hmmm - so you worry about terrorism in Wyoming more than volcanoes - but are you sure that's rational? Seems like it could be a close call...