I think they'll remain happy as long as nobody tells them that the Big Bang wasn't a fireball and couldn't have been viewed from the "outside".

Screw that -- make the caller responsible for handling the two possibilities by declaring an `Either` return type in its interface. That way the compiler will enforce that the caller handles both cases.

Without these protections, you are just forcing your users to become programmers and have to debug your crappy scripts (reverse engineer) what the call stack was (or what Exception they need to handle).

;)

http://stackoverflow.com/quest...

Tests *only* make sense if the compiler is trustworthy. If you can't trust the compiler, you can't trust anything it produces, including your tests! Test suites are *far* less trustworthy in comparison, so anything that *can* be handled by the compiler *should* be handled by the compiler.

Anything that's handled by the compiler doesn't need to be tested, since the tests wouldn't compile!

-- Our function
boolAnd :: Bool -> Bool -> Bool
boolAnd True True = True
boolAnd _ _ = False

-- A redundant test
testBoolAndAcceptsBools :: Bool -> Test
testBoolAndAcceptsBools b = try (boolAnd b b) Fail Success

-- An uncompilable test
testBoolAndDoesNotAcceptInts :: Int -> Test
testBoolAndDoesNotAcceptInts i = try (boolAnd i i) Success Fail

Mostly confirmation. It's good to have empirical evidence: https://news.ycombinator.com/i...

No, the point is that (pure) functional programming forces a separation between "actions", which may affect something in the program (eg. a global), in the computer (eg. a file) or in the outside world (eg. play a sound), from "computations", which can *only* return a value based on the given arguments.

This separation makes it easy to understand computations: arguments go in, return value comes out and *that's it*. In turn, this makes it safe to work at very high levels of abstraction (Monoids, Monads, Categories, etc.), since we don't care whether some function will be called or not, or what order stuff happens in, or how many times something gets called: the *only* possible thing that can happen is we get a return value.

Most languages, OOP included, don't make such a separation. An innocent-looking call like "getUserId" may in fact call out to a database, cache files to disk, obtain a lock and send some emails, which are all things we have to keep in mind whenever we try to call that function.

Actions in functional programming are just as dangerous as things like "getUserId", but they tend to be much smaller. For example, we might write all of a program's logic in a bunch of complicated computations, which ultimately takes a string as an argument and returns another string. We might then have a single, tiny action which reads a string from a file, passes it to our pure computation, then writes the result to stdout.

Python has a single type, which includes integers, bignums, floats, lists, strings, classes, functions, etc. *and errors*. In Python, a run-time error is a value which can be manipulated just like anything else. For example, this code passes errors into functions, adds together a couple of errors and prints some errors out:

def myFunction(x):
        print "CALLED"
        print x + ' world'

myFunction('hello')

try:
        myFunction(100)
except TypeError as e:
        try:
                myFunction(e)
        except TypeError as f:
                try:
                        print e + f
                except TypeError as g:
                        print "e " + str(len(str(e))) + " f " + str(len(str(f))) + " g " + str(len(str(g)))

The output is:

CALLED
hello world
CALLED
CALLED
e 50 f 67 g 84

Here "myFunction" accepts an error as an argument (it prints "CALLED" so it must have accepted the argument) and returns an error as its result (using "raise" rather than the usual "return", but that's an orthogonal issue of control flow), hence its argument and return types must include errors. The same is true for "+", "__add__", "str", "__str__" and everything else.

This means that the "TypeError" naming used in the above code is *only a convention* (just like naming the boolean values "True" and "False" is just a convention; the semantics would be identical if they were called "Chalk" and "Cheese"). In fact "type errors" in the technical sense are impossible in Python, since everything has the same type and therefore there's no alternative but to use the correct type.

Note that the name "TypeError" makes sense *within* the Python community, since the impossibility of "type errors" makes it clear what we're talking about. However, this breaks down when *comparing* languages, like we're doing here, at which point it makes sense to invoke the technical jargon as a common ground.

I find it quite interesting that dynamically-typed languages, which must rely completely on tests, are the languages worst-suited to testing!

With a decent type system I can statically *prove* that my code satisfies certain properties, *exhaustively* test it for other properties (eg. those involving small enumerations like the booleans), then fuzz-test whatever's remaining with help from the language ( http://www.reddit.com/r/haskel... ).

In dynamic languages I get *no* static guarantees (not even syntactic checks, since importing/including files is usually a run-time operation), there's *no* way to test anything exhaustively (everything has an infinite domain; there's no way to guarantee we'll only get booleans) and the language *can't* offer me any help during testing since it has no idea what I'm trying to do.

Rosetta Code solutions were chosen precisely because they're idiomatic, and hence not tuned to these benchmarks.

There are loads of Python solutions posted on http://codegolf.stackexchange.... which *are* tuned to similar benchmarks.

It's remarkable how much can be achieved with a single list comprehension.

The paper justifies their choices, and hence why C++ wasn't included.

Anyway, if all you care about is performance then why use C++? FORTRAN is faster.

There are different ways to interpret simplicity and "easy to read", especially local vs. global.

I've come across this during code reviews, where a few lines of "complex" code (eg. a fold) can replace multiple screens of "simple" code ("doThingA(); doThingB(); doThingC(); .."). Each "simple" line is straightforward and clear, but it's difficult to see the big picture of *what we're trying to achieve*. In contrast, it's obvious what the "complex" solution is trying to do, although it may take a few minutes to work out how each part works.

Of course it's always a balancing act, but I find the "simple" solutions are the ones which tend to degrade over time: where subsequent modifications forget to update one of the umpteen variables; where alterations are made by copy/pasting the existing version, since it's not clear how the changes will affect whatever algorithm all this stuff happens to implement; where it's easier to leave the broken, unfathomable data processing in place and fix the data afterwards.

They are a gang of Islamic murderers and rapists. Of course that doesn't say anything about *other* Muslims, any more than Hitler being a Christian tells us about Christians or Stalin being an atheist tells us about atheists.

http://en.wikipedia.org/wiki/N...

After reading the comments, I noticed the following fortune at the bottom of /.

You seem to think that those hating on systemd like having to use bloated, slow, barely-configurable, GUI-only, privacy-hemorrhaging browsers just to access their {bank/email/news/etc.}.

The existence of some high-profile non-UNIX projects isn't an excuse to dismiss UNIX practices. In fact, popularity is often correlated with barely-adequate, lowest-common-denominator offerings (eg. pop music).

Its strange that nobody mentions Paternosters when this elevator event horizon is brought up. I never encountered problems with the one at Sheffield University, and according to Wikipedia Hitachi are working on safer versions.

http://en.wikipedia.org/wiki/P...