9 ms·

Future of Programming Languages

85 points by jfaucett 12y ago

tomcam 12y ago
This just seems like a giant incoherent wish list with no central vision or any sense of the inevitable compromise required for any language of stature.
- Trufa 12y ago
  I agree, it's basically saying that the programming language of the future should have all the good features of each language and none of the bad ones.
- brudgers 12y ago
  That's a feature of the original wiki [aka 'wikiwikiweb' and 'ward's wiki']. It is not a bug. https://en.wikipedia.org/wiki/WikiWikiWeb https://en.wikipedia.org/wiki/WikiWikiWeb
- StephenFalken 12y ago
  Your point makes all sense and I totally agree with it. And it made me remember an old joke about programming languages of the future, through a fictional book cover: [1] [1] https://i.imgur.com/dPjtGVj.jpg https://i.imgur.com/dPjtGVj.jpg
ludamad 12y ago
My person vision is lots of tiny languages that work together in such a way that you don't have to get out of their sweet spot. Of course, I'm not sure if its possible to do this nicely.
- Guthur 12y ago
  They are called Domain Specific Languages (DSLs). And it can be done reasonably well today. Lisps are very good for producing DSLs; when you have macros you have very powerful control over the syntax and can therefore produce your own language within the language. The Common Lisp LOOP macro is a great example of power of macros; though in that case it is debatable whether it was used for good or bad.
  - ludamad 12y ago
    Sure I know about DSLs in Lisps and such, but I don't think LISP DSLs are quite on the level of SQL. If everyone creates their own DSLs I don't think it has the same impact.
    - jared314 12y ago
      > but I don't think LISP DSLs are quite on the level of SQL I'm curious what you mean by this. Is your definition of a DSL based on the language's syntax, or on the language's paradigm? Clojure's core.logic [1] provides logic programming, as apposed to functional programming, but maintains the syntax of a LISP. [1] https://github.com/clojure/core.logic/wiki/Examples https://github.com/clojure/core.logic/wiki/Examples
      - lmm 12y ago
        I think the reason LISP remains obscure is that syntax is important and LISP syntax is an unpleasant way to express a lot of domain languages. (I work with embedded DSLs quite a lot, but in Scala, where infix and postfix operators are easy)
        sklogic 12y ago
        Syntax is nothing. It's trivial to build any kind of syntax on top of Lisp, with arbitrary complex DSLs. See an example here: https://github.com/combinatorylogic/mbase https://github.com/combinatorylogic/mbase
    - deerpig 12y ago
      Check out Pilog which is a query language DSL for working with picolisp's built-in databases.... I'd be interested in hearing from people with more knowledge of SQL than I do to see how they compare.
  - webnrrd2k 12y ago
    I've just started looking at Rebol, and you may find it worth while -- it has a very interesting take on DSLs. http://www.rebol.com/ http://www.rebol.com/
- jared314 12y ago
  > My person vision is lots of tiny languages that work together I personally can't work deeply in more than about 4 languages at once. This might be my memory, my experience level, or it could be a human limit, like the short-term memory 7±2 limit.
  - ludamad 12y ago
    Well I was thinking of little things like Protocol Buffers, which can interoperate with many parent languages, but are so close to data they don't require deep thinking. Edit: RE "Not same level as SQL", I meant in standardization. People can learn about SQL in isolation, too.
  - pakled_engineer 12y ago
    There is an interview with Don Knuth somewhere where he talks about having to work in numerous low level languages simultaneously to write compilers for different machines in the 1960s. He added that learning MIXAL/MMIX is no big deal compared to the days when every computer had a different architecture you had to learn, sometimes with little documentation.
  - pwr22 12y ago
    Apparently the average is five chunks now
mattxxx 12y ago
From the article: > Simple: The language of the future will have all the HolyWar features I like, and banish those that I don't. -- FillInTheBlankWeenie? ^ Only reasonable response. laugh. There's questions all around about where domain-specific stuff is going. Regardless, I think there will be a lot more testing and program-proving.
merdreubu 12y ago
Basically, the language of the future will be 90% Julia.
al2o3cr 12y ago
Everyone knows the language of 10 years in the future will be a Lisp. In ten years, everyone will STILL know the language of 10 years in the future will be a Lisp. ;)
- CmonDev 12y ago
  Lisp is a language? I thought it was a round bracket based ASCII art :S.
sanxiyn 12y ago
The most interesting language design I have seen is Noether. It is a language built on multiple layers. Inner layers guarantee more invariants (say, immutability) but forbids constructs you may want to use. Outer layers are more expressive but guarantee less invariants. Importantly, inner layers are not different languages but sublanguages of outer layers, and inner layers keep guaranteeing invariants even when used in outer layers. http://www.infoq.com/presentations/noether http://www.infoq.com/presentations/noether
- Dewie 12y ago
  This also kind of sounds like the Hume programming language.
- tel 12y ago
  That's essentially what you get from monad transformers in Haskell.
blt 12y ago
PanuKalliokoski's short-term predictions were pretty prescient if they are more than a couple of years old. I wonder when he wrote them. Is there a way to view edit history on c2?
- Marazan 12y ago
  http://c2.com/wiki/history/FutureOfProgrammingLanguages/ http://c2.com/wiki/history/FutureOfProgrammingLanguages/
jbzz 12y ago
Language of the future will be call by value quantum lambda calculus with a linear type checker... QCaml
10098 12y ago
I think the "language of the future" will be the one that will allow people get results fast with little or no training. In other words, something that requires low skill. People hate learning and all they want is a magic button that just makes things happen (for the record, writing this doesn't make me happy at all). Also, I predict something similar to the industrial revolution in software engineering, when high-skill difficult manual labor is replaced by factories operated by cheap low-skill workers.
- taeric 12y ago
  I disagree with the idea that people hate learning. As a parent, it is quite clear that people love learning. They hate being reprimanded. Which is what a lot of people mistake for teaching.
bane 12y ago
I think whatever the language of the future will be, it's likely that we're going to have to give up editing a bunch of text files. Much of modern programming these days is really about workflow of large teams. It'd be nice to have richer editing areas that allow for things like embedded diagrams and videos as comments, annotations, hypertext links out to documentation and from documentation into code, review comments (similar to MS-Word), font size; colors; background colors etc. time-tracking for payroll, etc. IDEs try to provide some of this layer on top of the piles of text files we use today, often supplemented with out-of-band config files and folder structure littering stuff all over the place. But there continues to be a proliferation of hacked on comment systems to handle things like method descriptions, code changes, reviews. People make changes in some code, then leave a comment in the code with the change they made, their name and email address so 2 years later somebody can try and track them down to remember the 2-line change they made 2 years prior. It's kind of absurd. Imagine if I could just draw a box around a section of code, make the box dashed and fill the background with red and have a call-out annotation around it that says something like "highly performance sensitive, do not touch, see bane for problems" and "bane" was a link to my bug tracker page where you could immediately file an issue with that code? And you knew the code had a problem because right above it, instead of some vague interpretive ASCII art describing the algorithm as a comment, there was a familiar vector graphic diagram and a set of equations all of us domain expert programmers know by heart. Only you noticed an error in the way I translated it from the textbook to code. You also tagged the couple lines I screwed up and wrote up a review comment in the sidebar (like in MS-Word) letting me know what you thought was wrong, that way when I go to my bug tracker, click the link that takes me directly to the code you wanted me to see, I see your review comment right next to the code in question, only it's not mixed up in the rest of the code comments explaining how the code works since it's semantically a separate thing. I check out the problem and see that you're correct, I leave a response comment (which automatically notifies you via e-mail with a link to the bug tracker and to the code in question. When I go back out to the bug tracker the amount of time I was reviewing the issue is automatically logged, a diff is stored for review so everybody knows what I changed and the review comment and reply are automatically filled out in the tracker. My boss wants to check out the entire exchange, clicks my reply, is taken directly to the block of code in question and sees that I spent a reasonable amount of time doing the change (which he can see since the changes were tracked in the diff). I close the case and the review comments disappear from the code, leaving behind only good clean code and explanatory comments. Now a year later, somebody turns on "see old bugs" and they see there was a problem there, the discussion, what the bug tracker #s were (with links they can follow), they can even play back time and see the 3 other edits that happened since then by simply moving a slider left to right.
overgard 12y ago
It seems like most languages are converging on a pretty standard feature set -- to the point where what "the" language is might not really matter because all its competitors will probably be roughly similar. I think we're at the point where almost every language will have: - Lexical scope & closures - Reflection - Functions-as-objects - The standard map/filter/reduce functions (sometimes under different guises and names) - Immutability mostly by default, with the ability to override it - Some hybrid of dynamic and static typing The last one is probably a sticking point for a lot of people, but as far as I can tell it doesn't seem clear that either dynamic or static typing is obviously better in every context, and it seems like a lot of languages are recognizing that, either by introducing duck typing into a static context (IE, Go, or to an extent templates/generics), or introducing optional type constraints into dynamic languages via hints or asserts or just doing some JIT magic. Anyway, I just see a lot of convergence. In 2000, different programming languages were really a lot different, in 2014... most of them have a pretty similar feature set.
- jamii 12y ago
  We are working on a language that has no scoping, no data structures and no control flow (incidentalcomplexity.com). There is definitely still a ton of unexplored ground. The last few decades of PLT research feel like a huge depth-first search. Our notions of what programming is settled down in the 80s and haven't changed too much since. I suspect that PLT could do with a little more explore and a little less exploit.
- mpweiher 12y ago
  Yesbut: these are features of the language(s) of the past, or at best the present. I hadn't seen this c2 entry yet and was pleasantly surprised how many of those boxes my own Objective-Smalltalk[1] ticks: - Borrows from Smalltalk but is not a direct descendant (LISP is also there, but less visibly) - Dynamic typing as default with static typing as an addition (optional most of the time, not optional when interfacing with C). So far, there is only a rudimentary implementation, but more sophisticated static conversions are planned. - Suitable for large and small applications. Yep, it does scripting and it does software architecture. - Open Source. Well, yes. - OO/Actors + FP. Currently, mostly OO. Higher Order Messaging gives a lot of the HOF/FP flavor, messages will be similar to generic functions (with a few crucial differences). Local vars will be immutable by default. - Theorem Proving system. No, too big. But yes, you will be able to build one yourself and integrated it into the language as if it were built-in. A big part of making this possible are the flexible scheme handlers that support Polymorphic Identifiers[2], meaning you can define storage variables, while flexible messaging lets you implement sophisticated control structures. - Scheme handlers + PIs also decouple storage definition from implementation, so you can have multiple implementations of the same schema. Automatic conversion is not built-in, but should be easy enough to build using the extensive meta-programming facilities. - Simple syntax: yes, first thing I stole from Smalltalk, though it needs extending/adapting here and there to deal with the software architecture aspects. - Easy to build DSLs. With Polymorphic Identifiers and flexible messaging, this is largely covered (also: the ability to define your own software-architectural connectors is largely isomorphic to being able to build your own language primitives). - First class relations. Not full there yet, but first class references/variables + connectors means you have all the tools to build these. - A later comment says 'I'm not sure the future of programming languages is even a "language." I imagine that we'll be connecting components on a bus architecture.'. Again, yes, ObjST's central theme is allowing language users to define architectural styles and then hook up the components. - Graphical: once you have made your software architecture explicit using custom connectors and components, you will often be able to diagram substantial parts of applications. [1] http://objective.st/ http://objective.st/ [2] https://www.hpi.uni-potsdam.de/hirschfeld/publications/media/WeiherHirschfeld_2013_PolymorphicIdentifiersUniformResourceAccessInObjectiveSmalltalk_AcmDL.pdf https://www.hpi.uni-potsdam.de/hirschfeld/publications/media...
cromwellian 12y ago
The language of the future is Omega (https://code.google.com/p/omega/ https://code.google.com/p/omega/)
zubairq 12y ago
I think many people are trying to solve this including the ex Light Table guys: http://incidentalcomplexity.com/ http://incidentalcomplexity.com/
CmonDev 12y ago
Future programming languages will be about tooling, not syntax. Look at C# with ReSharper and Roslyn to get the taste.
david927 12y ago
The future of programming should be one language for all layers of the stack, from the database to the model to the UI. I think that hints that it should be a form of declarative. And if it's declarative, it should be focused on managing state. And if it's a thin syntactical representation of its VM, instructions/code could be interpreted immediately at entry and be managed as state, so you wouldn't be working with a text file but querying the AST equivalent of what you wrote. And if you do that, you can create the management tools and structures to truly understand and manage both data and code. And if we do that, the future of programming would look less like today's mangle of a thousand wires to something more like sculpting and architecture.
- aikah 12y ago
  > The future of programming should be one language for all layers of the stack, Programmers will never agree on what this language should be.Ever. Because different tasks require different features,a language that tries to have all these features will be regarded as a mess,and disliked because of it.
  - david927 12y ago
    Because you're talking about looking at it as data, you can get different views. It's all about viewing and working with the appropriate layer. We do it with civil engineering, we do it with drawing, we even do it with accounting systems. It's not about being all things to all people at all times, but about being the layer of the appropriate things for the appropriate people at the appropriate time. When we look at code as data, we can look at code in context.
- sklogic 12y ago
  A curiously limited view of what programming is. Outside of the CRUD world not many things can be described as "database", "model" or "UI".
- creadee 12y ago
  > The future of programming should be one language for all layers of the stack, from the database to the model to the UI. http://www.red-lang.org/ http://www.red-lang.org/ (a Rebol-like language) promises to do that. And perhaps right down to the OS (if I've understood it correctly).
fithisux 12y ago
The language of the future is a language that allows the creation of DSLS per task. A DSL for compiler construction, model checking,driver construction,GUI programming. This language could compile to C or Assembly and be self-hosted.
kristianp 12y ago
The Language of the Future may be influenced by Alan Kay's VPRI. http://www.vpri.org/html/work/ifnct.htm http://www.vpri.org/html/work/ifnct.htm http://lambda-the-ultimate.org/node/2483 http://lambda-the-ultimate.org/node/2483
acd 12y ago
Is there a language with Pythons beautiful syntax and the speed of C plus concurrency?
- brvs 12y ago
  Haven't used it myself, but Nimrod comes to mind.
- rtpg 12y ago
  Isn't that what Go tries to be?
- sgt101 12y ago
  I think Julia has better syntax than Python, does concurrency well and is nearly as fast as C.
sgt101 12y ago
If you'd like to see something really radical, and because of an intellectual agenda, and founded on some solid principals have a look at Church. Prepare for your mind to be blown.
progman 12y ago
The LanguageOfTheFuture is already there. There is a language that fulfil all requirements. It borrows from Lisp, is neither C/C++, Java, nor any DotNet, supports dynamic typing with type inference, suitable for small and large applications, easy to do Meta programming, and write DSLs, is capable of both ahead-of-time compilation and interpretation; including the compilation of code at runtime, is Open source, is both OO and functional, supports Prolog, supports design by contract (by DSL extension), has several unit testing frameworks, supports relational DB features, and likely also the rest of the list. Guess what that language is: It is called Lisp :-) A classical version is SBCL. Modern versions are NewLisp, clojure and Shen (shenlanguage.org).
JulianMorrison 12y ago
This whole language of the future concept is just mistaken. The era of being able to choose a language, for most operations, is over. That's because the future will be (already somewhat is) the disappearance of PCs, the minimization of overt gadgets, and the rise of ubiquitous, invisible, small, smart, with no user serviceable parts. And in most cases with no option on programming languages. Embedded? You'll probably have a choice of C, C++ and maybe Rust. Android? Java. Apple? ObjC. You don't like the tools? Suck it up, there's too much momentum to re-invent the wheel even if you think square is a terrible shape. They already laid the roads in inverted catenaries.
- pjmlp 12y ago
  This is nothing new. I learned more than 20 years ago that it is less pain to just use the languages that are part of the OS vendor SDK than spending development time writing yet another FFI wrapper. This is how C got where it is now, as the language got adopted by OS vendors outside the UNIX world.
  - mpweiher 12y ago
    This is one of the great lessons from Objective-C, IMHO: layering additional functionality in such a way as to be completely compatible with the platform ABI. There are other compromises you make as a result, but that one feature is a huge win. (And yes, Objective-Smalltalk tries to extend that lesson of connectivity to other areas).

85 points by jfaucett 12y ago

This just seems like a giant incoherent wish list with no central vision or any sense of the inevitable compromise required for any language of stature.

Trufa 12y ago
I agree, it's basically saying that the programming language of the future should have all the good features of each language and none of the bad ones.
brudgers 12y ago
That's a feature of the original wiki [aka 'wikiwikiweb' and 'ward's wiki']. It is not a bug. https://en.wikipedia.org/wiki/WikiWikiWeb https://en.wikipedia.org/wiki/WikiWikiWeb
StephenFalken 12y ago
Your point makes all sense and I totally agree with it. And it made me remember an old joke about programming languages of the future, through a fictional book cover: [1] [1] https://i.imgur.com/dPjtGVj.jpg https://i.imgur.com/dPjtGVj.jpg

ludamad 12y ago

My person vision is lots of tiny languages that work together in such a way that you don't have to get out of their sweet spot. Of course, I'm not sure if its possible to do this nicely.

Guthur 12y ago
They are called Domain Specific Languages (DSLs). And it can be done reasonably well today. Lisps are very good for producing DSLs; when you have macros you have very powerful control over the syntax and can therefore produce your own language within the language. The Common Lisp LOOP macro is a great example of power of macros; though in that case it is debatable whether it was used for good or bad.
- ludamad 12y ago
  Sure I know about DSLs in Lisps and such, but I don't think LISP DSLs are quite on the level of SQL. If everyone creates their own DSLs I don't think it has the same impact.
  - jared314 12y ago
    > but I don't think LISP DSLs are quite on the level of SQL I'm curious what you mean by this. Is your definition of a DSL based on the language's syntax, or on the language's paradigm? Clojure's core.logic [1] provides logic programming, as apposed to functional programming, but maintains the syntax of a LISP. [1] https://github.com/clojure/core.logic/wiki/Examples https://github.com/clojure/core.logic/wiki/Examples
    - lmm 12y ago
      I think the reason LISP remains obscure is that syntax is important and LISP syntax is an unpleasant way to express a lot of domain languages. (I work with embedded DSLs quite a lot, but in Scala, where infix and postfix operators are easy)
      - sklogic 12y ago
        Syntax is nothing. It's trivial to build any kind of syntax on top of Lisp, with arbitrary complex DSLs. See an example here: https://github.com/combinatorylogic/mbase https://github.com/combinatorylogic/mbase
  - deerpig 12y ago
    Check out Pilog which is a query language DSL for working with picolisp's built-in databases.... I'd be interested in hearing from people with more knowledge of SQL than I do to see how they compare.
- webnrrd2k 12y ago
  I've just started looking at Rebol, and you may find it worth while -- it has a very interesting take on DSLs. http://www.rebol.com/ http://www.rebol.com/
jared314 12y ago
> My person vision is lots of tiny languages that work together I personally can't work deeply in more than about 4 languages at once. This might be my memory, my experience level, or it could be a human limit, like the short-term memory 7±2 limit.
- ludamad 12y ago
  Well I was thinking of little things like Protocol Buffers, which can interoperate with many parent languages, but are so close to data they don't require deep thinking. Edit: RE "Not same level as SQL", I meant in standardization. People can learn about SQL in isolation, too.
- pakled_engineer 12y ago
  There is an interview with Don Knuth somewhere where he talks about having to work in numerous low level languages simultaneously to write compilers for different machines in the 1960s. He added that learning MIXAL/MMIX is no big deal compared to the days when every computer had a different architecture you had to learn, sometimes with little documentation.
- pwr22 12y ago
  Apparently the average is five chunks now

mattxxx 12y ago

From the article: > Simple: The language of the future will have all the HolyWar features I like, and banish those that I don't. -- FillInTheBlankWeenie? ^ Only reasonable response. laugh. There's questions all around about where domain-specific stuff is going. Regardless, I think there will be a lot more testing and program-proving.

merdreubu 12y ago

Basically, the language of the future will be 90% Julia.

al2o3cr 12y ago

Everyone knows the language of 10 years in the future will be a Lisp. In ten years, everyone will STILL know the language of 10 years in the future will be a Lisp. ;)

CmonDev 12y ago
Lisp is a language? I thought it was a round bracket based ASCII art :S.

sanxiyn 12y ago

The most interesting language design I have seen is Noether. It is a language built on multiple layers. Inner layers guarantee more invariants (say, immutability) but forbids constructs you may want to use. Outer layers are more expressive but guarantee less invariants. Importantly, inner layers are not different languages but sublanguages of outer layers, and inner layers keep guaranteeing invariants even when used in outer layers. http://www.infoq.com/presentations/noether http://www.infoq.com/presentations/noether

Dewie 12y ago
This also kind of sounds like the Hume programming language.
tel 12y ago
That's essentially what you get from monad transformers in Haskell.

blt 12y ago

PanuKalliokoski's short-term predictions were pretty prescient if they are more than a couple of years old. I wonder when he wrote them. Is there a way to view edit history on c2?

Marazan 12y ago
http://c2.com/wiki/history/FutureOfProgrammingLanguages/ http://c2.com/wiki/history/FutureOfProgrammingLanguages/

jbzz 12y ago

Language of the future will be call by value quantum lambda calculus with a linear type checker... QCaml

10098 12y ago

I think the "language of the future" will be the one that will allow people get results fast with little or no training. In other words, something that requires low skill. People hate learning and all they want is a magic button that just makes things happen (for the record, writing this doesn't make me happy at all). Also, I predict something similar to the industrial revolution in software engineering, when high-skill difficult manual labor is replaced by factories operated by cheap low-skill workers.

taeric 12y ago
I disagree with the idea that people hate learning. As a parent, it is quite clear that people love learning. They hate being reprimanded. Which is what a lot of people mistake for teaching.

bane 12y ago

I think whatever the language of the future will be, it's likely that we're going to have to give up editing a bunch of text files. Much of modern programming these days is really about workflow of large teams. It'd be nice to have richer editing areas that allow for things like embedded diagrams and videos as comments, annotations, hypertext links out to documentation and from documentation into code, review comments (similar to MS-Word), font size; colors; background colors etc. time-tracking for payroll, etc. IDEs try to provide some of this layer on top of the piles of text files we use today, often supplemented with out-of-band config files and folder structure littering stuff all over the place. But there continues to be a proliferation of hacked on comment systems to handle things like method descriptions, code changes, reviews. People make changes in some code, then leave a comment in the code with the change they made, their name and email address so 2 years later somebody can try and track them down to remember the 2-line change they made 2 years prior. It's kind of absurd. Imagine if I could just draw a box around a section of code, make the box dashed and fill the background with red and have a call-out annotation around it that says something like "highly performance sensitive, do not touch, see bane for problems" and "bane" was a link to my bug tracker page where you could immediately file an issue with that code? And you knew the code had a problem because right above it, instead of some vague interpretive ASCII art describing the algorithm as a comment, there was a familiar vector graphic diagram and a set of equations all of us domain expert programmers know by heart. Only you noticed an error in the way I translated it from the textbook to code. You also tagged the couple lines I screwed up and wrote up a review comment in the sidebar (like in MS-Word) letting me know what you thought was wrong, that way when I go to my bug tracker, click the link that takes me directly to the code you wanted me to see, I see your review comment right next to the code in question, only it's not mixed up in the rest of the code comments explaining how the code works since it's semantically a separate thing. I check out the problem and see that you're correct, I leave a response comment (which automatically notifies you via e-mail with a link to the bug tracker and to the code in question. When I go back out to the bug tracker the amount of time I was reviewing the issue is automatically logged, a diff is stored for review so everybody knows what I changed and the review comment and reply are automatically filled out in the tracker. My boss wants to check out the entire exchange, clicks my reply, is taken directly to the block of code in question and sees that I spent a reasonable amount of time doing the change (which he can see since the changes were tracked in the diff). I close the case and the review comments disappear from the code, leaving behind only good clean code and explanatory comments. Now a year later, somebody turns on "see old bugs" and they see there was a problem there, the discussion, what the bug tracker #s were (with links they can follow), they can even play back time and see the 3 other edits that happened since then by simply moving a slider left to right.

overgard 12y ago

It seems like most languages are converging on a pretty standard feature set -- to the point where what "the" language is might not really matter because all its competitors will probably be roughly similar. I think we're at the point where almost every language will have: - Lexical scope & closures - Reflection - Functions-as-objects - The standard map/filter/reduce functions (sometimes under different guises and names) - Immutability mostly by default, with the ability to override it - Some hybrid of dynamic and static typing The last one is probably a sticking point for a lot of people, but as far as I can tell it doesn't seem clear that either dynamic or static typing is obviously better in every context, and it seems like a lot of languages are recognizing that, either by introducing duck typing into a static context (IE, Go, or to an extent templates/generics), or introducing optional type constraints into dynamic languages via hints or asserts or just doing some JIT magic. Anyway, I just see a lot of convergence. In 2000, different programming languages were really a lot different, in 2014... most of them have a pretty similar feature set.

jamii 12y ago
We are working on a language that has no scoping, no data structures and no control flow (incidentalcomplexity.com). There is definitely still a ton of unexplored ground. The last few decades of PLT research feel like a huge depth-first search. Our notions of what programming is settled down in the 80s and haven't changed too much since. I suspect that PLT could do with a little more explore and a little less exploit.
mpweiher 12y ago
Yesbut: these are features of the language(s) of the past, or at best the present. I hadn't seen this c2 entry yet and was pleasantly surprised how many of those boxes my own Objective-Smalltalk[1] ticks: - Borrows from Smalltalk but is not a direct descendant (LISP is also there, but less visibly) - Dynamic typing as default with static typing as an addition (optional most of the time, not optional when interfacing with C). So far, there is only a rudimentary implementation, but more sophisticated static conversions are planned. - Suitable for large and small applications. Yep, it does scripting and it does software architecture. - Open Source. Well, yes. - OO/Actors + FP. Currently, mostly OO. Higher Order Messaging gives a lot of the HOF/FP flavor, messages will be similar to generic functions (with a few crucial differences). Local vars will be immutable by default. - Theorem Proving system. No, too big. But yes, you will be able to build one yourself and integrated it into the language as if it were built-in. A big part of making this possible are the flexible scheme handlers that support Polymorphic Identifiers[2], meaning you can define storage variables, while flexible messaging lets you implement sophisticated control structures. - Scheme handlers + PIs also decouple storage definition from implementation, so you can have multiple implementations of the same schema. Automatic conversion is not built-in, but should be easy enough to build using the extensive meta-programming facilities. - Simple syntax: yes, first thing I stole from Smalltalk, though it needs extending/adapting here and there to deal with the software architecture aspects. - Easy to build DSLs. With Polymorphic Identifiers and flexible messaging, this is largely covered (also: the ability to define your own software-architectural connectors is largely isomorphic to being able to build your own language primitives). - First class relations. Not full there yet, but first class references/variables + connectors means you have all the tools to build these. - A later comment says 'I'm not sure the future of programming languages is even a "language." I imagine that we'll be connecting components on a bus architecture.'. Again, yes, ObjST's central theme is allowing language users to define architectural styles and then hook up the components. - Graphical: once you have made your software architecture explicit using custom connectors and components, you will often be able to diagram substantial parts of applications. [1] http://objective.st/ http://objective.st/ [2] https://www.hpi.uni-potsdam.de/hirschfeld/publications/media/WeiherHirschfeld_2013_PolymorphicIdentifiersUniformResourceAccessInObjectiveSmalltalk_AcmDL.pdf https://www.hpi.uni-potsdam.de/hirschfeld/publications/media...

cromwellian 12y ago

The language of the future is Omega (https://code.google.com/p/omega/ https://code.google.com/p/omega/)

zubairq 12y ago

I think many people are trying to solve this including the ex Light Table guys: http://incidentalcomplexity.com/ http://incidentalcomplexity.com/

CmonDev 12y ago

Future programming languages will be about tooling, not syntax. Look at C# with ReSharper and Roslyn to get the taste.

david927 12y ago

The future of programming should be one language for all layers of the stack, from the database to the model to the UI. I think that hints that it should be a form of declarative. And if it's declarative, it should be focused on managing state. And if it's a thin syntactical representation of its VM, instructions/code could be interpreted immediately at entry and be managed as state, so you wouldn't be working with a text file but querying the AST equivalent of what you wrote. And if you do that, you can create the management tools and structures to truly understand and manage both data and code. And if we do that, the future of programming would look less like today's mangle of a thousand wires to something more like sculpting and architecture.

aikah 12y ago
> The future of programming should be one language for all layers of the stack, Programmers will never agree on what this language should be.Ever. Because different tasks require different features,a language that tries to have all these features will be regarded as a mess,and disliked because of it.
- david927 12y ago
  Because you're talking about looking at it as data, you can get different views. It's all about viewing and working with the appropriate layer. We do it with civil engineering, we do it with drawing, we even do it with accounting systems. It's not about being all things to all people at all times, but about being the layer of the appropriate things for the appropriate people at the appropriate time. When we look at code as data, we can look at code in context.
sklogic 12y ago
A curiously limited view of what programming is. Outside of the CRUD world not many things can be described as "database", "model" or "UI".
creadee 12y ago
> The future of programming should be one language for all layers of the stack, from the database to the model to the UI. http://www.red-lang.org/ http://www.red-lang.org/ (a Rebol-like language) promises to do that. And perhaps right down to the OS (if I've understood it correctly).

fithisux 12y ago

The language of the future is a language that allows the creation of DSLS per task. A DSL for compiler construction, model checking,driver construction,GUI programming. This language could compile to C or Assembly and be self-hosted.

kristianp 12y ago

The Language of the Future may be influenced by Alan Kay's VPRI. http://www.vpri.org/html/work/ifnct.htm http://www.vpri.org/html/work/ifnct.htm http://lambda-the-ultimate.org/node/2483 http://lambda-the-ultimate.org/node/2483

acd 12y ago

Is there a language with Pythons beautiful syntax and the speed of C plus concurrency?

brvs 12y ago
Haven't used it myself, but Nimrod comes to mind.
rtpg 12y ago
Isn't that what Go tries to be?
sgt101 12y ago
I think Julia has better syntax than Python, does concurrency well and is nearly as fast as C.

sgt101 12y ago

If you'd like to see something really radical, and because of an intellectual agenda, and founded on some solid principals have a look at Church. Prepare for your mind to be blown.

progman 12y ago

The LanguageOfTheFuture is already there. There is a language that fulfil all requirements. It borrows from Lisp, is neither C/C++, Java, nor any DotNet, supports dynamic typing with type inference, suitable for small and large applications, easy to do Meta programming, and write DSLs, is capable of both ahead-of-time compilation and interpretation; including the compilation of code at runtime, is Open source, is both OO and functional, supports Prolog, supports design by contract (by DSL extension), has several unit testing frameworks, supports relational DB features, and likely also the rest of the list. Guess what that language is: It is called Lisp :-) A classical version is SBCL. Modern versions are NewLisp, clojure and Shen (shenlanguage.org).

JulianMorrison 12y ago

This whole language of the future concept is just mistaken. The era of being able to choose a language, for most operations, is over. That's because the future will be (already somewhat is) the disappearance of PCs, the minimization of overt gadgets, and the rise of ubiquitous, invisible, small, smart, with no user serviceable parts. And in most cases with no option on programming languages. Embedded? You'll probably have a choice of C, C++ and maybe Rust. Android? Java. Apple? ObjC. You don't like the tools? Suck it up, there's too much momentum to re-invent the wheel even if you think square is a terrible shape. They already laid the roads in inverted catenaries.

pjmlp 12y ago
This is nothing new. I learned more than 20 years ago that it is less pain to just use the languages that are part of the OS vendor SDK than spending development time writing yet another FFI wrapper. This is how C got where it is now, as the language got adopted by OS vendors outside the UNIX world.
- mpweiher 12y ago
  This is one of the great lessons from Objective-C, IMHO: layering additional functionality in such a way as to be completely compatible with the platform ABI. There are other compromises you make as a result, but that one feature is a huge win. (And yes, Objective-Smalltalk tries to extend that lesson of connectivity to other areas).