4 ms·

Topics that I think will be important: - Functional Programming - Logic Programming - Managing asynchronicity - Managing concurrency / Managing state

Topics that I think will be important: - Functional Programming - Logic Programming - Managing asynchronicity - Managing concurrency / Managing state - Pruning bad directions in OO (see the first two) - Type Systems - Virtual Machines Languages/technologies that I would look at more closely given these are Haskell, Scheme, Prolog, Clojure, Qi, LLVM. I love JS but as far languages go, I would not look there for new ideas. At best I see it becoming a fantastic compile target. I also don't see Haskell and Clojure being particularly specialized. They are very general purpose and suitable for tackling any kind of programming problem - simple to complex, JS on the other hand is a language with a very specific focus. I don't see the importance of being able to read and understand C/C++ diminishing anytime soon as those languages are intimately tied to our operating systems. EDIT 2: I added Type Systems above. I think Haskell has shown the power of an expressive type system. However it has it's problems. I look forward to see the distinction between languages w/ strong type systems and those without being abolished. Languages should support turning the type system on and off - see Qi. Type systems also should allow the typing of a much richer set of values - Qi's sequent calculus types is eye-opening in this regard. EDIT: I'm opinionated about this, but the constant announcement of new languages that simply continue the traditional stateful OO paradigms (perhaps tacking on a couple of syntactic niceties or a crippled static type system) seem like complete dead ends.

contextfree 16y ago
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 the turn to the web will set back the state of the art in programming by a decade, as the turn to microcomputers did.
- swannodette 16y ago
  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 learning FP principles than PHP - there's enough in there to guide people to the topics I've outlined above. In fact my interest in these topics arose from being a JS coder for 5 years! JS is the gateway drug to the new future.
  - drgath 16y ago
    "The JS community is struggling with designing libraries that work as well on the server as well as the client." 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/ 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.
chriseidhof 16y ago
You can look at Agda, Idris or Epigram for some ideas about what's possible if you go beyond Haskell's type system: dependent types. It allows for even more expressive code. Instead of tests, you write your types, and your program is an executable proof that your type holds. Quite mind-boggling, and very awesome. Of course, these languages are currently only suited for academic use, but I suspect they will inspire other languages.
ggchappell 16y ago
Both your list and your comments look good, generally, but I have to wonder about your mention of logic programming. I think logic programming has a lot to offer the world, in theory, but in practice it seems to be pretty much dead. True, there is probably more going on with Prolog now than, say, a decade ago. But widespread use is not happening, nor is inclusion of logic-programming features into other languages. Further, I don't see this changing in any truly significant way in the near future. Apparently, you do see it changing. Would you care to comment on that?
- silentbicycle 16y ago
  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.
  - EdiX 16y ago
    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.
    - silentbicycle 16y ago
      Hence, "to come out of logic programming". It's declarative, but not an LP per se - backtracking really clashes with the priority on (soft) real-time behavior and concurrency. The Prolog origins are probably most visible in the syntax and emphasis on pattern-matching.
    - gtani 16y ago
      Correct, what's left in erlang from prolog is the pattern matching syntax for function definition, where you have multiple clauses to test, sequentially, whether runtime args match the number and types of parameters in each clause (and values, if guards are used). No unification/backtrackig involved.
  - deleted 16y ago
    [deleted]
nickik 16y ago
Data parallelism is something you missed spezially if you think haskell will get bigger.

contextfree 16y ago

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 the turn to the web will set back the state of the art in programming by a decade, as the turn to microcomputers did.

swannodette 16y ago
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 learning FP principles than PHP - there's enough in there to guide people to the topics I've outlined above. In fact my interest in these topics arose from being a JS coder for 5 years! JS is the gateway drug to the new future.
- drgath 16y ago
  "The JS community is struggling with designing libraries that work as well on the server as well as the client." 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/ 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.

chriseidhof 16y ago

You can look at Agda, Idris or Epigram for some ideas about what's possible if you go beyond Haskell's type system: dependent types. It allows for even more expressive code. Instead of tests, you write your types, and your program is an executable proof that your type holds. Quite mind-boggling, and very awesome. Of course, these languages are currently only suited for academic use, but I suspect they will inspire other languages.

ggchappell 16y ago

Both your list and your comments look good, generally, but I have to wonder about your mention of logic programming. I think logic programming has a lot to offer the world, in theory, but in practice it seems to be pretty much dead. True, there is probably more going on with Prolog now than, say, a decade ago. But widespread use is not happening, nor is inclusion of logic-programming features into other languages. Further, I don't see this changing in any truly significant way in the near future. Apparently, you do see it changing. Would you care to comment on that?

silentbicycle 16y ago
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.
- EdiX 16y ago
  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.
  - silentbicycle 16y ago
    Hence, "to come out of logic programming". It's declarative, but not an LP per se - backtracking really clashes with the priority on (soft) real-time behavior and concurrency. The Prolog origins are probably most visible in the syntax and emphasis on pattern-matching.
  - gtani 16y ago
    Correct, what's left in erlang from prolog is the pattern matching syntax for function definition, where you have multiple clauses to test, sequentially, whether runtime args match the number and types of parameters in each clause (and values, if guards are used). No unification/backtrackig involved.
- deleted 16y ago
  [deleted]

nickik 16y ago

Data parallelism is something you missed spezially if you think haskell will get bigger.