This makes error-correcting the foundation of the universe, but I would prefer to have causality be fundamental, such as with the causal sets program. This is interesting though, especially for quantum computing.
The first question that comes to mind is, what is wrong with using the JVM or the CLR as a compilation target for such a language. The only thing that I can think of is that they want to exist on the Python platform, which makes some sense. Python is taking over the computing industry and programming education and it does have a lot of libraries. Perhaps Python should have a standard Python virtual machine, but that almost certainly is never going to happen, for multiple reasons. So here you are stuck with a transpiler. A transpiler whose purpose is to make a functional language compile to a language which was explicitly designed not to be functional at all.
Yes. It is a bit of a head scratcher why people would be going to enormous effort to transpile to an execution environment that is as gimped as Python's. I use Groovy pretty much as "python for the JVM", and a big reason for that is simply that Python's runtime limitations are unacceptable to me from a basic engineering standpoint (primarily, GIL). I guess Python's ecosystem is big enough now that the selling point of "you can use all your favorite libraries" is enough of a drawcard?
The problem is that maintaining a browser engine is enormously expensive. There are so many features you need to maintain, security issues to deal with, etc. In the past Microsoft made money off of their operating system, and they made Internet explorer then Edge off of that, but now they make money off of the cloud and clients expect people to support Chrome. Microsoft was spending too much money they didn't need to for return. I think because of the expensiveness of maintaining a browser engine used by so many people, they were destined to be basically a natural monopoly operated by a few concerned actors. Of course, google as one of the two major internet giants, is the most concerned with supporting the development of a web browser.
> It also means exposure to paradigms like functional programming, or logic programming. I recommend Haskell, not because you need to learn yet another language, but because the knowledge ceiling in its ecosystem is really high and it's the current lingua franca for papers on functional programming.
Common Lisp is also ideal, it effectively supports paradigms other then functional, and has been or at least was the lingua franca for artificial intelligence for decades.
Guido Van Rossum and the development team didn't want the language to be functional. There is very little functional support in Python in general, besides not supporting first class functions over multiple lines.
> There is very little functional support in Python in general, besides not supporting first class functions over multiple lines.
You are confusing “first-class functions” and “anonymous functions”, which are completely different things. Python functions are first-class, independent of length.
Some definitions of "first-class function" require that it have the same value semantics as any other first-class type, which would include a literal syntax/anonymous functions.
One note about point (2) dealing with the versions and the languages object oriented features. I noticed the object-oriented support has been tacked on, before Python 2.2 the objects had their own type which was accessed by .__class__. The tacked on nature of the OOP support of the language is perhaps why there are these __identifiers__ which are hard to type using consecutive letters, needing shift to be held down, are still used in the language. Although Python fixed the problem partially, it only did so only by adding new style classes along the old style ones in order to avoid breaking compatibility, which only complicated the issue. Unfortunately, Python 2.7 is still around. As this post mentions, Python 2.7 & 3 are both installed on Linux machines and the default is still Python 2.7 when you type python.
> Lisp programmers tend to be ignorant of applied mathematics.
As a Lisp programmer and a mathematician myself I must disagree. I spent years working on mathematical applications using Lisp dialects, initially drawing inspiration from computer algebra systems like Axiom, Derive, Maxima, and Reduce and later drawing inspiration from ontologies and knowledge bases like SUMO and Cyc. All of these systems are heavily math based and they are based upon Lisp.
