Is there a language with Pythons beautiful syntax and the speed of C plus concurrency?
Isn't that what Go tries to be?
Future of Programming Languages
51–60 of 73 posts
Re: Future of Programming Languages
#52Is there a language with Pythons beautiful syntax and the speed of C plus concurrency?
I think Julia has better syntax than Python, does concurrency well and is nearly as fast as C.
Re: Future of Programming Languages
#53If 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.
Re: Future of Programming Languages
#54The 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).
Re: Future of Programming Languages
#55It 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…
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…
I'd be very interested to see an example of an embedded theorem proving system here. My understanding is that unless your language lives and breathes type theory you cannot embed a proof system.
Re: Future of Programming Languages
#56It 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 (Py…
Theorem proving doesn't require immutability it anything like that—its requirements are far more severe. Your language must have at least some fragment which is the internal proof language of a complete and consistent type theory! This is why, for instance, these languages are always Turing incomplete.
Re: Future of Programming Languages
#57The 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…
That's essentially what you get from monad transformers in Haskell.
Re: Future of Programming Languages
#58PanuKalliokoski'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?
Re: Future of Programming Languages
#59I 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…
People have being working on things like this since the early nineties when there was sufficient point and click graphical power to make it sensible.
The issues is that now the code document is incredibly fragile. It can only be viewed, edited and manipulated with the one particular tool suite.
Raw text files suck but have amazing interoparability.
Re: Future of Programming Languages
#60This 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.