Why inventing a new language that requires the use of the "let" statement.
OK there's also "let!" for asynchronous asignments (i.e. when passed to another function as a parameter, its actual value is not computed but will be computed lazily when it will be needed and made available, blocking only the place where the value will be really required.) This merits a separate statement but even this could be abbreviated:
would probably become simply:
But then why not simply making ALL assignments executed lazily and asynchronously ? As in a pure functional language. So this could have been more simply:
Microsoft won't convince Python programmers to use F# (it's perfectly possible to make Python purely functional with lazy evaluation). The distinction made in F# between the two assignments using the ugly "let" (and "let!") statement, that was forgotten since long in Basic (even in VB#), is just a pure local optimization which defeats the pure functional definition of the language.
In other words, F# is not a functional language, as it enforces an execution schedule, by its syntax, instead of infering it according to the execution context and other constraints. This makes algorithms still hard to prove correct, and not suitable for strong mathematical definitions (unlike Java, which can easily be parallelized with lazy evaluation as well, thanks to its strict constraints for the evaluation preconditions and due to its strict postconditions that enforce invariant rules),
The local optimization and scheduling of instructoins (when to evaluate the lazily assigned expressions according to satisfied constraints) being the job of the run-time compiler (which can take profit of the effective current capability of the local host on which the application runs, with more or less available processors, including possibly remote processors, or step-by-step debuggers which may force an earlier evaluation for inspection purpose, if all other dependency constraints are satisfied).
Keep Up with TechRepublic