The genesis of the perfect programming language
slidetocode.com
slidetocode.com
> The programmer should be able to use Unicode, so the source file _must_ declare its encoding.
Another Great Lesson we've learned, is to avoid clutter. So a reasonable rule, IMHO, would be that any standard Unicode encoding can be declared, but the lack of such a declaration is equivalent to a declaration of UTF-8.
Even C++, OOP's flagwaver-in-chief, now supports
templating, which is effectively a competing compile
time strategy for writing polymorphic code.
Along similar lines, Unity uses a slightly restricted JavaScript than compiles to Mono's CLR implementation, as well as Boo, which is a Python-like language that also compiles to Mono. Iron Python, of which I have no direct experience, is another example.
And of course there's Clojure if you're so inclined.
The only real problem I know of with languages is that they don't die off fast enough. If the perfect language arrived tomorrow, it would be lost in the sea of languages anyway.
A language debate is a sign the there is an extra language lurking and it should die off. Python vs Ruby is a lively debate. I don't care which one survives, but do we really need both? The most curious debate of all is "Haskell?", a debate that seems to exist apart from any other language, the clearest sign of a lurking "extra" language.
Great use of the available tools.
Now to answer your question: I have no idea. Perhaps like you, I consider C and C++ to be pretty much one language because they occupy nearly the same slot in the toolbox. Maybe ones a regular screwdriver and the other is a power screwdriver? I dunno.
The most peculiar debates are about the latest versions of C and C++. Really smart guys, how much nicer if they would listen to Peter Thiel and work on real innovation. The economy needs it.
It's hypothetically possible for a language to be both expressive and performant. If a language could prevent a problem, but doesn't, doesn't it share responsibility for the problem?
This sentiment seems to be at odds with the preference of
abs(val) {
int abs(int val) {
1) the order (or names) of its arguments (how to call it)
2) the types of its arguments (what to feed it)
3) the type of its return value(s) (what to expect)
4) whether the function maintains referential transparency (whether it plays nice with the rest of your program)
Relying on type inference in the function signature abandons two of these and forces the casual reader to manually infer the manner in which the function may be safely used. Of course, in this position, one may always opt to use a documentation generation tool (doxygen, rdoc, javadoc, etc.)--however, when it comes to this, our code can no longer be considered to be self-documenting.
Common Lisp is the only programming language I know of that provides both the prototyping power of dynamic languages and the execution power of static languages. This is achieved through the Lisp declarations system.
The maxima computer algebra system also offers a variety of algebraic declarations such as linear, additive, multiplicative, outative, evenfun, oddfun, commutative, symmetric, antisymmetric, nary, lassociative, and rassociative. In my opinion all programs should be written this way - the Lisp way.
> So far my fondness with Scheme has coexisted with disappointment at its unsuitability for real world tasks
I am fond of Scheme, Kernel, Arc, Shen and many other Lisp dialects. The unsuitability of these languages for real world tasks can be solved to some extent by embedding them in a larger host platform. Clojure does the embedding approach quite nicely.
Right, except for Facebook, Twitter, Reddit and Wikipedia (yes, Facebook has a different PHP runtime which uses gcc to get a performance boost, this is an irrelevant implementation detail).
EDIT: according to Wikipedia the service itself moved from Ruby to Scala while search moved from Ruby to Java.
A lot of their backend stuff is now Java, though.
Maybe there could be a single, perfect language with different implementations providing the tradeoffs. The most difficult challenge may be bridging the performance/productivity gap between the C's and the Pythons of the world, but that may be a side effect of making multi-core programming easier. Amdahl's law[1] may prohibit that, though.
"need for a multithreading-centric, statically typed, type inferred language that compiles to native code but possesses the feel, readability and programmer efficiency of Python."
Language designers have moved on to writing on-top of LLVM to provide the native code benefit. That includes even Apple, Objective-C's backer. Of these, the highly interesting languages that provide the other benefits demanded:
Julia
Rust
Clay.
The one true language is mathematics. John McCarthy (a math professor) discovered that programs could be represented as out degree one directed graphs (cons cells) that compose mathematical functions (lambda expressions). These simple mathematical principles form the basis of the functional programming paradigm and they have led Lisp programmers to success for nearly a half a century.
D is really great. The terseness, modeling power, and general ease of writing it correctly the first time seem to obviate the need for higher level languages, for me.
How easy is it to take a D program cross platform? Can it cross compile easily?
Setting up a virtualbox and building from that is pretty easy these days. And you need to test the executables somewhere anyway.
D will be perfectly portable by default, just as with modern C++. If you use the standard library it will compile and run everywhere.
Of course, there is some serious selection bias here for me, largely because programming language design has been one of my primary interest lately, and as I said earlier, the field seems generally biased towards static typing.