I think many people are trying to solve this including the ex Light Table guys:
Future of Programming Languages
31–40 of 73 posts
Re: Future of Programming Languages
#32Everyone 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. ;)
Lisp is a language? I thought it was a round bracket based ASCII art :S.
Re: Future of Programming Languages
#33Future programming languages will be about tooling, not syntax. Look at C# with ReSharper and Roslyn to get the taste.
Re: Future of Programming Languages
#34It 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 na…
They are all converging on these features because they have proven universally useful. But there is still a lot of work going on about other, new features. Some examples that interest me:
- effects and exceptions - should we use monads (Haskell), macros (Rust), handlers (Eff, algebraic effects), extensible rows (Koka)
- memory usage - how should we handle deallocation - using reference counting with infrequent GC (Python) or by being very careful (C++), using just GC and allocating freely (OCaml/Haskell, Java & Nim use "realtime" GC), using uniqueness semantics (Rust, ATS), using memory pools and great care (Objective C) - none of these approaches is perfect and optimal for all situations, and it's very frustrating that they don't really fit together
- safety and security - I'm really interested about provable programs, either dependent typing (Agda) or refined types (Liquid Haskell, ATS). Both require quite a bit of "static knowledge" - immutable data structures, or unique mutable data structures, and effect annotations for functions (plus, there are additional problems in lazy languages).
All of the above seem really hard to do using a dynamically typed language, but hopefully we can devise a way to have both a dynamic and a static provably efficient and secure code in the same program, same language, with clear split between the two.
Re: Future of Programming Languages
#35The 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.
Re: Future of Programming Languages
#36This 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.
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]
Re: Future of Programming Languages
#37Earlier quoted context omitted.
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.
> 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
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)
Re: Future of Programming Languages
#38The 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.
Re: Future of Programming Languages
#39I 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 comment…
That's a lot of baked in dependencies for a language.
Re: Future of Programming Languages
#40I 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 comment…
Version control system commit comments are already very useful for many common development tasks, if done right (jira ticket number in each commit, commits divided properly, good commit messages with reasons for change). I wish there was more metadata there (like which tests failed during automatic build after each commit).
But I disagree using text as underlying data format is a problem. It's godsend. Text can be grepped, copy-pasted, diffed and versioned easily.
I cringe when I have to work with versioned word or excel documents. Working with versioned code is much easier.
you may think big red arrow would be nice to put in code, but how do I later search for all red arrows related to X, added by John between 3 and 4 months ago?
I have specification divided into 100s of versioned office documents. When I want to grep I have to know where to look (or zipgrep the underlying xml, which sometimes work sometimes doesn't).
If it was in a text format I could grep and see real differences, not edit history.
If it had embedded video I would need to watch the whole thing. And no - adding keywords isn't much help. I want to be able to search by content.