I tried out the english->hungarian and it's pretty hilarious, because hungarian version sound so german that even I can't understand what it says without the text. :D

It's interesting how many language wants to be part of the ML family or at least look like an ML language.

Kotlin has a really nice and simple syntax compared to Scala, which has way to many features.

I agree that Ocaml is just extremely well suited for making new programig languages. If you are interested in Ocaml+programming languages check out the plzoo: http://plzoo.andrej.com/

I personally think that Ocaml is really good at this, because I started converting the Scheme examples from the PLAI book to Ocaml and it's just felt right(maybe because I'm not fan of the scheme syntax).

If you want better type information for Python, you could use the new typing hints and the typing module(https://docs.python.org/3/library/typing.html).

You could also use mypy(https://mypy.readthedocs.io/en/latest/index.html) which is a static type checker for Python.

I was laughing out loud, when I saw that it was based on node. They want to build a secure and fast browser and they use JS to accomplish it.

I have to nitpick.

2) You can't prove correctness with tests. You can only state that it ran correctly for that test case(s).

"Proving correctness" is sort of windmill-tilting for today. Just don't despair of this :)

Good test vectors are a great investment, as are constraint checks and supporting instrumentation of said constraint checks.

I don't despair, because I know that to prove correctness of a program you need to use math.

For example proof assistants(like Coq, Agda, Idris, hol) are capable of proving correctness of a program.

Well, usually my code does not run in space. ;)

But you are right, tests are biased. Pair programming can reduce the chance of code/tests being biased in a negative way.

No, I literally mean that you can't prove correctness with tests, because you would need a lot of test cases to prove the simplest function.

For example: int addOne(int input) function would need test cases for every number in the int type, which would be 2,147,483,647 * 2 + 1 test case.

The point of writing tests is to provide information, not prove correctness.

IE, a test is another way to explain what the developer of that test cared about, worried about, needed to verify of the code that is exercised.

Also, tests provide anothing built in consumer of the code, and all code with more consumers is better code, purely by surviving the stress.

It depends on the terms we set for our tests. Usually we infer things to be correct that are out of scope. For instance, my tests usually don't cover to test the runtime or hardware before executing tests. And what if laws of physics change? No seriously, I know what you mean. But I mean correctness in the bounds we set. Those bounds are different if you write software for aviation or biometric devices or an Instagram clone.

It's perfectly possible to write a function with a small enough set of arguments to make it practical to exhaustively test.

Well it's possible, but how many developer would rather make a new type for using the first ten integer instead of just using int?

I think random testing is a good way to get almost exhaustively tests.

A developer that uses a narrower integer data type, or who wants to be clear that the argument is a member of an enumerated set of options, not an integer. What kind of developer represents non-integer data as an integer data type?

> I think random testing is a good way to get almost exhaustively tests.

I think that testing known/predictable edge and corner cases makes more sense (in some cases), but I also think that I was responding to a comment about the impossibility of using tests to prove correctness of a function, not about how to derive practical benefits despite theoretical limitations.

You are right, I didn't think the example through.

You are right, you can use tests to prove a function if - the function has very limited arguments and - the function is pure or does very limited amount of state change(side effect)

Generally speaking tests are not the right tool for proving program correctness.

integers are frequently used to represent fixed point numbers anytime you're doing interesting math in an embedded system

And old PC hardware, where you aren't guaranteed to have an FPU, or where integer operations were a lot quicker than FP ones.

I used Jerry at work and it's really one fine HTML parser. I like it better than JSoup, although it works a little bit weirder. :D

What about isolates in Dart? I mean isolates are isolated processes, which also can be a thread and they also can communicate with each other.

Unfortunately:

1. Isolates can only communicate with each other using asynchronous method calls. So even though you can move some work to another isolate, you can't block waiting for it to complete, so your function still has to be red.

2. Isolates are very limited in what you can send between them, which makes then not very useful in practice for much of anything.

But waiting is non-blocking right? It means that we can just make one isolate's role to wait for all other isolates to complete.

For me the bad part of "red" functions is that testing is harder for it or I just suck at it.

Nice article, although I couldn't really understand some of the examples which had template in it.

Agreed. When the manual says you can pattern match with term rewriting macros, I think of Erlang pattern matching. Would something like this be possible?

    template mysum{a = @[]}(a: seq[int]): int = 0
    template mysum{a}(a: seq[int]): int =
      while a.low <= a.high:
        a[a.low] + mysum(a[a.low + 1 .. a.high])

    var x: seq[int] = @[1, 2, 3]

    echo mysum(x)

Term rewriting templates are only supposed to be optimizations, not change the semantics. They happen on the AST, so the pattern matches are on the AST as well. You won't get the actual values of any variables, they aren't even known at compile-time anyway.

Your post. :D

Actually Eloquent Javascript and sometimes Programming -- Principles and Practice Using C++. I found the C++ book a little bit boring and maybe i wont read it trough.