51–57 of 57 posts
The language of the future is Lisp. always has been, always will be. (which is a shame, because APL and its children J and K would be a better foundation).
A better foundation for...what? Many important programming domains don't fit naturally into the array-oriented model.
Earlier quoted context omitted.
I very much hope you turn out to be right. Unfortunately I'm afraid the momentum of the web client platform will be so strong, the impedance mismatch between client and server such a pain, and the progress of JS as a better compiler target so slow (the pressure to interoperate with existing JS libraries may also be a factor here) - that the dominant trend will be towards using JS as a source language everywhere. So t…
JS doesn't solve the client/server impedance mismatch at all. The JS community is struggling with designing libraries that work as well on the server as well as the client. As Ryan (Node.js) has said, I see JS going the way of PHP. That's great and that it will attract certain kinds of coders and certain kinds of projects. But setting programming back by a decade? Personally I find JS a much better foundation for lea…
Disagree. YUI3 was a library written for the web, but it was so well designed that it took one YUI engineer hacking around for a few days to get it fully running in Node.js. Now, some awesome stuff is happening and it's an area of focus for the YUI team. http://express.davglass.com/
Mustache.js and Underscore.js are other examples of popular JS libraries that work great server-side right off the bat.
The main one left out is jQuery, and that is a library written primarily for DOM manipulation, which isn't really the point server-side (most of the time). Once JSDOM is a bit more mature, I'm certain you'll see jQuery become more popular server-side.
The language of the future is Lisp. always has been, always will be. (which is a shame, because APL and its children J and K would be a better foundation).
> J and K would be a better foundation A better foundation for...what? Many important programming domains don't fit naturally into the array-oriented model.
And specifically, the APL/K/J focus on data makes it a better foundation for optimization, parallelization and reasoning about program behaviour.
Earlier quoted context omitted.
Two visible things to come out of logic programming are Erlang and constraint programming. Both are very significant, in their own niches. I don't think Prolog is dead yet, either.
Erlang is not a logic programming language. They started with a logic programming language and eventually removed every feature that made it a logic programming language.
In terms of programming language features i expect the next hot topics to be:
Dependent types, however, the question, whether a type system should be turing-complete is not answered yet.
Optional types for dynamically typed languages. Common Lisp had this for centuries of course, but now Python introduced the syntax and Clojure etc. also support this.
Various mixes of concurrency related concepts. There are lots of ideas currently (see X10, Clojure, Go, D, Haskell, ...), but no sweet spot is found yet.
As Sir A. C. Clarke said (or at least to paraphrase)-- predicting the future is at best a crap shoot. That said I know what I'd like to see. As suggested elsewhere, much of what we see in 'new' languages is syntactic sugar bolted on to existing approaches; new on the outside, same old on the inside. I'd like to suggest that, that is not necessarily a bad thing. Consider what 'syntactic sugar' is--- a tweak or rephras…
In the real world, the innocent bystanders matter, code is written as much for other people to understand as it is for computers to execute. I think that instead of plastering over all your content with sweeties, languages should be designed in such a way that the sugar is not necessary by choosing the right fundamental concepts, so programmers can understand what's going on. Learn to cook with the right ingredients, and learn when to add spices. And when not to.
For another example of a syntactic sugar friendly design, have a look at C macros.
Earlier quoted context omitted.
> J and K would be a better foundation A better foundation for...what? Many important programming domains don't fit naturally into the array-oriented model.
The array model fits the relational model way, way better than the object oriented model (no "o/r impedance mismatch"). I think most domains fit just as well (if not better) with arrays. And specifically, the APL/K/J focus on data makes it a better foundation for optimization, parallelization and reasoning about program behaviour.
I'll give you the first two points (though some heavy-weight optimizations become necessary to eliminate big wasteful temporaries), but certainly not the last. At least not in general--- recursion is a terrible pain with arrays! Even stateful object-oriented languages deal with inductive structures better than array languages.
What does tree processing in APL look like? I'm it's possible and I'm also sure it's hell. The K/Q approach of nested vectors is a first step towards making recursion tolerable in an array language, but it's still a kludge.