22 ms·

Near Future of Programming Languages [pdf]

385 points by myth_drannon 9y ago

adamnemecek 9y ago
"It's like X but more practical". -> "There's a library for my domain". 3real5me
quickben 9y ago
It looks like the presentation stops short of any strong conclusion.
- banachtarski 9y ago
  It's still pretty useful as far as identifying the problem is concerned.
jlward4th 9y ago
"Where will the next great programming language come from?" Interestingly Scala has come from Academia, Industry, and Hobbyists. And for me it's already the next great programming language. Yeah, it has some warts and is hard to learn but that's true of all great things. :)
- deleted 9y ago
  [deleted]
- cpeterso 9y ago
  > Scala has come from Academia, Industry, and Hobbyists. That's an interesting point. The slide implies there will be no next great programming language because academia nor industry nor hobbyists can deliver it, but overlooks the possibility of a combination working together. For example, Rust started as Graydon Hoare's hobbyist language and then development was sponsored by Mozilla.
- mlazos 9y ago
  Yeah this comment stuck out to me in the presentation. Industry has a great record of creating + supporting languages. C#, F#, Dart, Swift, Rust, D are all languages that are actively supported by industry, and some were even created by industry too. Just seemed like a weird statement for the slides to say that new languages just aren’t going to appear.
  - throwaway7645 9y ago
    If anything, almost too many of them. In the esoteric language area, every new language takes away from libraries for other ones as the communities get spread out. I do think the spread of ideas from that setup is good though.
  - saas_co_de 9y ago
    But how many of those languages include substantial innovation? To me they seem to be mostly rehashing existing technology with slight cosmetic tweaks in order to serve the profit interests and ego of their creators. Now, whatever innovation this proliferation of languages may bring, it also brings fragmentation which acts as a counter-weight on the value created for the industry as a whole. Whether the net effect is positive or negative is very difficult to tell.
telotortium 9y ago
Is there a talk for these slides? I haven't been able to find it.
drefanzor 9y ago
TLDR The future of programming languages should involve not naming your language "Coq". I know I am going through the lowest common denominator, but how do you explain to your boss that you're proficient with using Coq. Ugh. Or professor, since apparently it's a proofing language for academia.
- davemp 9y ago
  It gets really bad when you're using "Hoare Logic" in "Coq"
- tdb7893 9y ago
  I would just pronounce it like "coke" and it would just sidestep the whole pronunciation issue. I'm not sure how most people pronounce it but that's what I would do to talk to my boss about it.
  - logicchains 9y ago
    I refer to it as "the See Oh Queue theorem proover" at work, which seems to get the idea across.
  - taneq 9y ago
    This is the precise reason why "route" is pronouced "root" but "router" is mysteriously pronounced "raow-ter". No-one's gonna stand in front of a room full of people and talk about the "rooter".
    - polymeris 9y ago
      Huh, TIL. As a non-native English speaker, I have always pronounced "route" as "raowt", probably influenced by the pronunciation of "router". Btw, why is it "pronUnciation", but "pronOUced". English is hard.
      - jamesrcole 9y ago
        > Btw, why is it "pronUnciation", but "pronOUced" In Australian English, it is "pronOUNCiation"
qaq 9y ago
Coq should have good interop with cockroachDB.
- qaq 9y ago
  Why are people so against the future of tech?
WoodenChair 9y ago
What people who do academic analysis of programming languages often miss is culture. So much about what programming language gets used has to do with what ecosystem it's been targeted at and what colleagues in that ecosystem are using.
- stmw 9y ago
  I couldn't agree more and was just making this point to someone last week - for many of the well-established languages, 80% of the reasons to use or not to use them is the associated culture, from the qualifications of the average applicant to the prevailing approaches to solving problems.
curryhoward 9y ago
> Languages that have dabbled with modeling effects with row types have backtracked on it in favor of IO. Interesting. I thought algebraic effects + handlers were the new hotness in modeling effects with types.
- iitalics 9y ago
  They are hotness because they are having trouble getting them to work (trouble = open research topic :) ), and they want to convince the monad proponents that they are better.
  - toolslive 9y ago
    what trouble ? http://www.eff-lang.org/ http://www.eff-lang.org/
lain-dono 9y ago
> It’s lightweight > I was able to install the compiler It does not prevent the browser from eating all the resources.
YZF 9y ago
One area I haven't seen any good solutions for is the interleaving of tests with production code. I think we need better ways to express tests without cluttering the production code and excessive mocking. What I'd like to do, and really can't in any language/tooling that I know of, is to extract some arbitrary subset of the code and surround it with tests or a test harness. I'd also like to specify various injection points for tests right as I'm writing the code in a way that doesn't affect the production code and contributes to its readability. Perhaps this is pieces of server and client code or various services all tested together. When I refactor the code I want the tests to "refactor" with the code. I don't want to need to rewrite my tests... Automatic test generation is another interesting area (beyond the basic table or algorithm stuff we might do in tests today). It's almost like the "problem" isn't the languages themselves, it's the tooling around the languages. I want to be able to do a lot more than "compile", "run", with my code... I can imagine machine learning driven tooling being able to automate a lot of the mechanical aspects of code writing beyond the simple generate a closing bracket that an IDE can do...
- enobrev 9y ago
  I can imagine something like a code-collapse indicator next to every method in a class (or function or code block, whatever), which would expand tests that can be run on-the-fly - even while you type. Kind of like how comments can be collapsed in some IDEs. Technically, these could very well be simple commented annotations that point to a separate .test file or something, but are shown in-line by your favorite IDE or code-editor.
- tomelders 9y ago
  I don’t do coding tests. I talk to the candidate about programming and I only require one interview. I haven’t made a hiring mistake in 6 years.
  - closeparen 9y ago
    Uh, this is about automated testing of programs, not interviewing.
chewbacha 9y ago
TL;DR Everything is awful and nothing will save you
whytheam 9y ago
Very disappointed not to see Cilk included.
- stmw 9y ago
  Do you mean this Cilk? https://en.wikipedia.org/wiki/Cilk https://en.wikipedia.org/wiki/Cilk
  - whytheam 9y ago
    Yes. Cilk is very easy to use and has pretty good performance. I would love to see it used more in industry rather than just in academic work.
cromwellian 9y ago
Perhaps the future of programming isn't in linear deterministic code but in stochastic or probablistic languages dealing with machine learning or biology. Maybe we're hitting Godel/Turing-like wall and as we strive for more perfection and provable soundness, we will find we can't scale up to bigger and bigger systems. We'll be stuck with human debuggable linear languages like we have today or systems which operate more like a composition of machine learning models.
- yazaddaruvala 9y ago
  Of course in practice we know is a lot easier to build and use probabilistic models. However, I hope we don't give up on proovable systems. When given enough time, if math can stay pure and adequately abstract to eventually describe our entire universe concisely. Shouldn't code similarly have no limitation?
- deleted 9y ago
  [deleted]
wsxiaoys 9y ago
In case of anyone interested a reasonable engineered language that supports Closure Serialization (mentioned as "hard" in last slide), checkout: Gambit Scheme: A fast scheme implementation. http://github.com/gambit/gambit http://github.com/gambit/gambit Gerbil Scheme: Provides full module and syntactic tower on top of Gambit Scheme. https://github.com/vyzo/gerbil https://github.com/vyzo/gerbil
- mrkgnao 9y ago
  Does Guile (or even Chicken) do anything similar? (My only exposure to it is from Andy Wingo's blog, and I don't know much about Scheme.)
  - wsxiaoys 9y ago
    Nope.
joe_the_user 9y ago
“It just feels readable”. -> “It looks like this other language I know.” But: that language might be English (or other natural language). Which is to say maybe computer languages are leveraging the human "language faculty" and rightly so. Which may mean that some languages are always going to feel more foreign.
- fasquoika 9y ago
  Considering how many programmers will tell you that C style semicolons and curly braces are more readable than using keywords, I think they've got a point
  - Symmetry 9y ago
    At some extremes yes but, for example, I've spent at least twice as much time programming C and C+ than I have with Python but I still find Python generally more readable. Maybe if the ratio were 100 to 1 instead of 2 to 1 I'd feel differently but that suggests there are actually intrinsic differences in readability apart from just familiarity.
jamesrom 9y ago
So are we just going to pretend Perl doesn't exist?
- chrisseaton 9y ago
  You can't expect 20-or-so slides to cover all languages. And I'm not aware of any PL research topics being explored in Perl, so not sure how talking about Perl would fit in.
  - cestith 9y ago
    Perl6 in its spec has auto-parallelization of at least the hyperoperators. It has hyperoperators themselves. It has full LL and LR grammars as part of the language. It has optional strong typing for support of incrementally typing your source. It has junctions. It has a native MOP. It has active metadata on all data types (values, variables, subroutines, and types themselves). Beyond what might be purely PL research, there are some other neat ideas being explored. It does function currying, lazy evaluation, grapheme-level Unicode support, and custom operators from any Unicode grapheme. It's definitely a language I'd be watching if I was writing about near-future languages.
samth 9y ago
This talk is right that effect systems aren't popular yet, except the way Haskell does them. But it's wrong about the trajectory of languages. Right now is the best time to be interested in using cutting edge languages in practice. Also right now has seen an explosion of new languages with interesting ideas, from Rust to Purescript to Elm (in the authors preferred realm of typed languages). Also industry is backing major post-Java languages like F# and Rust. In short, the near future of PL is great, and exciting stuff keeps happening. Don't believe the naysayers.
david927 9y ago
This is a brilliant synopsis of the state of the art -- truly fantastic -- and yet the presentation concludes with, "The innovation won't happen because I can't see where it will come from," and that's not entirely fair. Some areas he covers aren't exhaustively covered and what's missing is quite interesting. In other words, cheer up, there's more hope than what's shown here.
- ghthor 9y ago
  I think this is just a fustration with how little direct incentive there is from our economic system to fix the problem. The only chance of this paradigm existing is as a long shot project that is gifted to society, and the person that makes this gift has the slim chance that it doesn't succeed and all the effort is wasted.
  - peoplewindow 9y ago
    I found that the weakest part of the presentation. Kotlin and Ceylon both came out of corporate/industrial development. C#, JavaScript and Java continue to evolve entirely due to industrial funding. I agree that academia is not a great place to do PL research as all the other non-idea aspects of a successful PL don't get enough attention. But industry is doing OK at launching new languages. Perhaps he feels that's "incrementalism" but there's nothing wrong with making solid upgrades that aren't attempts at unicorn style magic cure-alls. It'd also help if we collectively got over our demand for our tools to always be open source. This has solid justifications behind it but it ensures that programming languages will always be spinoffs of other endeavours rather than having truly focused attention in their own right. When you take away the profit motive, you get stagnation, and that seems to be the main point of the presentation.
  - david927 9y ago
    The only chance of this paradigm existing is as a long shot project I couldn't agree more but I also am not as pessimistic as he is at its chances of happening.
- kd0amg 9y ago
  The central claim isn't that innovation won't happen. It's that they won't go mainstream because nobody has both the means and motive for good tech transfer work.
samcodes 9y ago
This is a great deck... but leaving TLA+ out of Formal Methods? It is hands down the most important thing going on there. And it is a combo between academia and industry. Amazon uses it extensively.
- hwayne 9y ago
  It also left out Alloy, which is another really exciting formal method that a lot of really cool work has been done in.
- pron 9y ago
  It also left out all PL research outside of typed FP. It isn't really about the future of programming, but about the future of typed FP. For example, it lists Eve as a "reinvention of Smalltalk" when, in fact, Eve incorporates at least as much cutting-edge PL research as Idris.
fulafel 9y ago
This could be titled "Static typing is not going to save you"? There's nothing but static typing languages and related theorem provers from the timeline slide onwards and the conclusion is that it's too hard. This is a good companion piece for the recent Rich Hickey Clojure/Conj talk :)
- stmw 9y ago
  I don't really see where you get that. Is dynamic typing demonstrating a lot of sustainable success?
  - fulafel 9y ago
    I edited in the Clojure part after you replied. Languages that have forgone static typing aren't necessarily trying to solve everything using language types at runtime. See eg Clojure's approach. Or SQL's. But at the base popularity-contest level the answer is clearly yes: Dynamic languages have been on a roll for the last 30 years - Perl, Python, Ruby, Erlang, Clojure, even JS.
    - 35bge57dtjku 9y ago
      That certainly doesn't mean it's because of their dynamic typing. And Erlang and Clojure, as nice as they are, are still about as popular as AWK is.
  - kowdermeister 9y ago
    I've seen a comparison lately with static vs. dynamic languages and it compared bugs/open issues and there was not really an advantage there IIRC.
    - machiaweliczny 9y ago
      It's just my opinion, but there definitely is difference in favor of optional static typing. It simply adds more expressivness to language - you get free documentation standard (input,output,structures) backed in. You don't have annoying typos and you leave data manipulation computation to computer lowering programmer cognitive load. Also you can change code in editor(fastest feedback loop) without even running it(very important if there is high price for running code - ex. complicated system bootstrap, deployment, hardware).
stmw 9y ago
This is a great presentation, I wish I could hear the talk track. While we can all differ on the right "winner" for the next programming language (I don't think Clojure is the right answer, someone else might), we are all stuck with the same set of facts - and this covers the state of things very well. Most importantly, it explains certain truths of the social/economic ecosystem for programming languages - which is what gave us Java, Python, Javascript, and a few other really popular systems that seemed unlikely to succeed when they first appeared. The reasons for their success have just as much to do with "ecosystems" than with language features.
- makach 9y ago
  my thoughts exactly. it's difficult to understand this presentation without the discussion that goes with each slide. it's too easy to just be biased about the meaning of each slide;
- saas_co_de 9y ago
  On twitter he says: "The thesis was that programming in 2030 will have very advanced research languages but mainstream languages will effectively stop advancing and we'll be last [sic - left?] with a vast insurmountable gap between the two." That provides some context for what the slides are about.
aryehof 9y ago
My thoughts are that we don't really need more languages. Arguably we don't need better ones either, because they aren't the problem in general computing. Instead we need better design paradigms that better let us model complex requirements and systems into code. Let's have new languages that then support those paradigms. We continue to struggle abstracting complex problems using functional decomposition, structured analysis, information (data) modeling, and object-based decomposition. Many newcomers I meet only know modeling problem domain concepts as data in a database, with behavior and constraints acting on that data in a separate layer, organized using functional decomposition. Of course that layer increasingly approaches a 'big ball of mud' as size and complexity increases. Sounds a lot like we are back data-flow modeling as so popular in the 1980's, in a new guise. A focus on programming languages in my opinion, masks the real issues we face.
- ShallowLearning 9y ago
  Much of the time, new languages lead to new design paradigms. As a general rule, newer languages are more abstracted than older ones. When people don't need to get hung up on the intricacies of low level programming, real progress can be made on the design paradigm front.
  - aryehof 9y ago
    I'm curious which languages have resulted in which new design paradigms?
    - miguelrochefort 9y ago
      Elm -> Elm Architecture
    - arianvanp 9y ago
      Two good examples: Erlang led to Microservices and the Reactive Manifesto. the Open Telecom Platform is still a very modern Microservice library (in my opinion) after more than three! decades ML led to programming against generic interfaces (http://www.cs.cornell.edu/courses/cs312/2006fa/recitations/rec08.html http://www.cs.cornell.edu/courses/cs312/2006fa/recitations/r...)
la6470 9y ago
In the next evolution writing software should be as easy as writing a word document .. not a macro based wordstar dociment. In other words the code should be auto generated and humans should only specify the design -ui and workflows.
Animats 9y ago
"OTP" on p. 23? "One True Pairing"? "Online Transaction Processing"? probably not "On The Phone".
- paulsmal 9y ago
  Open Telecom Platform? Erlang's runtime
  - tormeh 9y ago
    I think it's just the biggest Erlang framework. BEAM is the runtime.
- CognitiveLens 9y ago
  My guess is the Erlang OTP: http://learnyousomeerlang.com/what-is-otp http://learnyousomeerlang.com/what-is-otp
Animats 9y ago
Things to think about for the near future of programming languages: - The borrow checker in Rust is a great innovation. Previously the options were reference counts, garbage collection, or bugs. Now there's a new option. Expect to see a borrow checker in future languages other than Rust. - Formal methods are still a pain. The technology tends to come from people in love with the theory, resulting in systems that are too hard to use. Yet most of the stuff you really need to prove is very dumb. X can't affect Y. A can't get information B. Invariant C holds everywhere outside the zone (class, module, whatever) where it is transiently modified. No memory safety violations anywhere. What you really need to prove, and can't establish by testing, is basically "bad thing never happens, ever". Focus on that. - The author talks about "Java forever". It's more like Javascript Everywhere. - Somebody needs to invent WYSIWYG web design. Again. - Functional is OK. Imperative is OK. Both in the same program are a mess. - Multithread is OK. Event-driven is OK. Coroutine-type "async" is OK. They don't play well together in the same program. Especially if added as an afterthought. - Interprocess communication could use language support. - We still can't code well for numbers of CPUs in triple digits or higher. - How do we talk to GPU-type engines better?
- PaulRobinson 9y ago
  I disagree with a few of your thoughts, but they're good thoughts! * Javascript everywhere is a function of low barrier-to-entry for it, but almost everybody agrees it is flawed as a language. If that's the future, we are screwed as an industry. One thing I've noticed (and I say this as a guy who wrote Ruby for 10+ years), is that type safety is becoming a hugely desired feature for developers again. * WYSIWYG web design (a la Dreamweaver) died off a little because the tools saw a web page as standing in isolation. We know however that isn't interesting on its own - it needs to be hooked up to back-end functionality. Who is producing static HTML alone these days? In the case of SPAs it needs API integration. In the case of traditional web app dev, it needs some inlining and hooks to form submission points and programatically generated links to other "pages". Making that easier is the hard part - seeing a web document as an artefact of an output from a running web application container. * Multi-threaded, event-driven, coroutine-type patterns are fine in Go, to my eye. What's making you think we can't mix this up with the right type of language and tooling support? * Is it that we can't code well for CPU counts > 100 or that the types of problems we're looking at right now that need that level of parallelism tend to be targeted towards GPUs or even ASICs? I think I'd need to see the kind of problems you're trying to solve, because I'm not sure high CPU counts are the right answer. * Talking to GPU-type engines is actually pretty simple, we will deal with it the same way we deal with CPU-type engines: abstraction through a compiler. Compilers over time will learn how to talk GPU optimally. GPU portability over the next 20 years will be a problem to solve as CPU/architecture portability was over the last 40.
Schampu 9y ago
Dynamic analysis + machine learning could become next-generation coding: https://maierfelix.github.io/Iroh/ https://maierfelix.github.io/Iroh/
ernst_klim 9y ago
OCaml is as "industrial" as Haskell is.
josefrichter 9y ago
Just curious where does Elixir fall in this scheme of things? Any experienced devs who could give a qualified answer, please?
- machiaweliczny 9y ago
  Elixir is mostly different syntax(Ruby-like instead of Prolog-like) for Erlang. Beyond syntax change it fixes some Erlang warts, ads better metaprograming and great tooling. Elixir isn't academic innovation - it's about proffessionals convinience and effectivness similar as go lang. Started by 1 person.
- bjz_ 9y ago
  Elixir doesn't really push much of the state of the art forward. It's pretty much Erlang with new clothes (and some nice cleanups). I worked with it for over a year and while I loved the 'fail fast' model of programming, most of the errors that were caught were stupid programming errors that would have been trivial to catch by a type system. What I really want is a type system for reasoning about distributed, stateful, programs. Has to deal with mixing strongly consistent eventually consistent (CRDT) data with synchronisation points (see Bloom/Lasp), hot code reloads, migrations, messaging across nodes, possibly some sort of row polymorphism combined with clojure's namespaced symbols... Like sort-of like Cloud Haskell but with zero-downtime deployments. Or like Pony but with a better distribution story.
  - rurban 9y ago
    Distributed Pony will be there soon. https://www.doc.ic.ac.uk/~scd/Disributed_Pony_Sept_13.pdf https://www.doc.ic.ac.uk/~scd/Disributed_Pony_Sept_13.pdf [pres], https://www.ponylang.org/media/papers/a_string_of_ponies.pdf https://www.ponylang.org/media/papers/a_string_of_ponies.pdf [paper] I'm not sold on Cloud Haskell or Clojure.
lispm 9y ago
Looking at the 2010 Haskell report: most of the committee members come from 'Academia': https://www.haskell.org/onlinereport/haskell2010/haskellli2.html#x3-2000 https://www.haskell.org/onlinereport/haskell2010/haskellli2.... How is it an 'industrial' language? Haskell is the main 'academic' language for a branch of Functional Programming. 'industrial' is just another weasel word.
- throwaway7645 9y ago
  If you keep your head to the ground, there are quite a few companies like Facebook that use Haskell for important things in production, but it isn't the language even 50% of the company is using. I'm sure there is a lot more lisp in production, but you typically hear about the same ratio from both camps in the blogosphere.
  - lispm 9y ago
    I would guess that in a company like Facebook, 99.5% of the code they wrote is not Haskell. If they have, say, 200MLOC of code written (just a number), this would be 1MLOC...
    - pjmlp 9y ago
      There are companies using a bit more of Haskell in production. http://cpmed.de/jobs/ http://cpmed.de/jobs/
- mrkgnao 9y ago
  Haskell lends itself pretty well to "backend"[0] work, and there are more than a few organisations using it to write servers, trading systems, and so on. It definitely fits his metric, which is "> 1000 industrial users". [0] (Unlike applying it to the frontend, which is a comparatively less mature situation with multiple proposed solutions.)
  - deleted 9y ago
    [deleted]
pron 9y ago
> Will we just be stuck in a local maxima of Java for next 50 years? 1. Yes, if the extent of the imagination is languages like Idris and ideas like effect systems, that follow a gradient descent from Java, and always in the same direction: being able to express more constraints. What you get "for free" from such languages may not be significant enough to justify the cost of adoption, and the valuable stuff you can get is not much easier than the options available today, which are too hard for anyone to take. If you were to consider truly novel languages that think out of the box (e.g. Dedalus/Eve) then maybe one will stick and make an actual impact rather than just a change in fashion. 2. How do you even know that we can do much better? NASA engineers may not like it, but they don't complain that we're "stuck" at sub-light speeds. Maybe Brooks was right and we are close to the theoretical limit (that we know must exist). > We talk about languages as a bag of feelings and fuzzy weasel words that amount to “It works for my project”. Can you find another useful way, available to us today, of talking about languages? > “Use the right tool for the job” Zero information statement. That's right, but it's not a dumb cliché so much as it is a tool we've developed to shut down religious/Aristotelian arguments that are themselves devoid of any applicable, actionable data. One, then, is often confronted with the reply, "but would you use assembly/Cobol?" to which the answer is, "of course, and it's not even uncommon, and if you don't know that, then you should learn more about the software industry before giving any more Aristotelian arguments."
- lmm 9y ago
  > if the extent of the imagination is languages like Idris and ideas like effect systems, that follow a gradient descent from Java, and always in the same direction: being able to express more constraints. I don't think that's a fair reflection of what these languages feel like. When your constraints mean that only the right thing can be done, you can make the thing implicit. The things that are tacit when humans talk about the problem can be tacit in our programming as well. You have ways to factor out concerns that are separate, even when they are entangled. "Better decomposition of the problem" doesn't sound exciting, but ultimately that's the very essence of programming. I don't think we need new grand ideas, at least if we're just talking about the next 50 years of industrial programming; I think we need to follow through on the ideas we already have, and I actually think that gradient ascent from Java will happen, and will move the industry forward, even if it ends up being a lot slower than I'd like. > How do you even know that we can do much better? NASA engineers may not like it, but they don't complain that we're "stuck" at sub-light speeds. Maybe Brooks was right and we are close to the theoretical limit (that we know must exist). I think we can go at least one or two substantial steps better than Idris: I want Noether's levels of stratification (beyond just total/not-provably-total), and I want Rust-style linearity, not as a specialised capability but as something integrated into the regular type system. But even if Idris is the limit, it's still a big step ahead of Java, and it's going to take the industry a while to make that step. (Maybe it will have to be two or three steps to get there - it feels like most of the industry is only just adopting the things that OCaml offered, and not yet familiar enough with them to appreciate what Haskell offers above that. And I can't blame them - I only have an appreciation of those things because I've been able to work for a long time in Scala and very gradually work my way up towards using the less familiar facilities). "The future is already here — it's just not very evenly distributed." > Can you find another useful way, available to us today, of talking about languages? Yeah, that's the problem :(. The whole industry is a huge iceberg in terms of what's visible about the practice of programming versus what's actually happening. I'd like to see more programming happening in public - which I think probably means more publicly-funded programming (I was thinking about this a few days ago in the context of research and scientific code - we have a relatively good system in place for providing grants for research, but we're a lot less good at funding the infrastructure that's used for research - we end up with a lot of researchers repeating the same work because they're only ever funded for a specific project, rather than being funded to produce something that's useful for many research projects). What makes sense in an open-source webdev project is all that most of us ever see about most languages, and while it's a lot better than nothing it's still a seriously distorted picture of what most programmers are actually doing.
js8 9y ago
I would love to see programming as a dialogue between user and computer (programmer and compiler). For example: Compiler would infer the types, and the programmer would read it and say, oh, I agree with this type, but I disagree with this type, that's perhaps wrong, this should be rather that type. Then the compiler would infer types again, based on programmer's incremental input. Data structure selection. Programmer would say I want a sequence here. The compiler would say, I chose a linked list representation. The programmer would look over it, and disagree, saying, you should put this into an array. And compiler could say, look, based on measurements, array will save this much space but list will be this much faster. Code understanding. Programmer should be able to say just, I don't know what happens here, and the compiler would include some debug code to show more information at that point. Or take refactoring. Programmer would write some code, computer would refactor it to simplify it. Then programmer would look over it, and say, no, I rather want this, and don't touch it, and he would perhaps write some other code. The compiler would refactor again... But all this requires that there is syntactically distinct way (so that perhaps editor could selectively hide it) to specify these remarks in the code, both for computer and programmer. So each of them should have a special kind of markup that would be updated at each turn of the discussion. Because you don't want to just overwrite what the other side has just said; both are good opinions (which complement each other - human understands the purpose of the code but the computer can understand the inner details much better). So, to conclude - I wish future programming language would include some framework like this.
- mrkgnao 9y ago
  > Compiler would infer the types, and the programmer would read it and say, oh, I agree with this type, but I disagree with this type, that's perhaps wrong, this should be rather that type. Then the compiler would infer types again, based on programmer's incremental input. This is possible today, at least in Haskell. (and I'd guess in OCaml too ... surely also Scala?) Your proposal for adaptive data structure selection based on benchmarking is intriguing!
- currymj 9y ago
  wrt your first paragraph there, I urge you to take a look at Idris. That's the exact workflow.
miguelrochefort 9y ago
cough Prolog cough
TuringTest 9y ago
> Lots of people are reinventing Smalltalk on a Mac. (See Bret Victor and Eve). At last, someone noticed! ;-) Though from that expression, what the author doesn't seem to grok is why having a Smalltalk-like environment is desirable; maybe not as the primary way to program computers but certainly as a tool alongside. It's a shame that a family of programming languages that build on and expanded that model hasn't gained more traction in the industry (not necessarily for people who dedicate their lives to build complex software with a highly general programming language, but for the rest of us).
- vanderZwan 9y ago
  I find the jab at Bret Victor especially undeserved. He's an interaction designer (a really good one who sees through all the fads[0], which is kind of the opposite of what this one-liner implies). His focus is on better interface design, not formal language design; why criticize someone for something they're not trying to do? And it's not useless; we probably wouldn't have had Elm without Bret Victor's Inventing on Principle[1][2]. And there has been some progress in that direction of interface design of, for a lack of a better term, "programmable environments": look at Apparatus, for example[3]. Where would you even fit that on these slides? [0] http://worrydream.com/ABriefRantOnTheFutureOfInteractionDesign/ http://worrydream.com/ABriefRantOnTheFutureOfInteractionDesi... [1] http://elm-lang.org/ http://elm-lang.org/ [2] https://vimeo.com/36579366 https://vimeo.com/36579366 [3] http://aprt.us/ http://aprt.us/
  - TuringTest 9y ago
    Quite true. I find likely that the next revolution in programming languages will come from designing a PL that's a good fit for these programmable environments. Maybe it should break from current undisputed conventions like the radical separation between "data" and "source code", and be more like a spreadsheet. End-User Development has lots of under-explored ideas on how to build software automatisms that don't require the end user to learn a hard formalism (even if such formalism exists as the basis for the system). Though I understand that programming language theorists are not interested in that angle of the evolution of PLs.
rotten 9y ago
Recently a famous AI project was shut down because it was inventing its own language. Perhaps the next generation programming language and design paradigms won't come directly from humans at all.
- myth_drannon 9y ago
  Are you talking about Theano?
lmm 9y ago
The "Language Gap" slide seems massively overstated, or maybe I'm misunderstanding. We really have seen a lot of progress in the last 10-20 years, both in industrial languages and in academic ideas that could become the industrial languages of the next 10-20 years (e.g. Idris on the short end, Noether on the longer end). The author laments that pattern-matching is still not standard, but we're getting there; map/reduce/filter are standard in all new languages these days (they weren't 10-20 years ago), some kind of lightweight record feature is standard in all new languages, some level of type inference is standard in all languages. Yes, it's taken longer than you might imagine it should, but progress is happening. Likewise formal methods - they may not be practical in 2016, but there's a lot more awareness, a lot more work being done, and people are starting to try to take the useful parts and apply them in more and more industrial settings. Likewise graphical representation of code - not the LabView nonsense that's exciting to talk about at cocktail parties, but the little touches that today's IDEs do almost invisibly - highlighting, mouseover information, outline views, smart code folding. I wish we were better at communicating about programming languages. I wish we were moving faster. But despair is unwarranted. We really are in a much better place than 10-20 years ago, and the next 10-20 years look set to bring more improvements.
- pjmlp 9y ago
  10-20 years ago some of us could use Smalltalk, do systems programming with strong type safe languages, use RAD environments like Delphi, release applications in Prolog, for example. To me it seems we are catching up with the past, and as someone already programming on those environments, it looks we have spent 10-20 years loosing our tools, educating the masses, only to get a taste of things used to be.
  - lmm 9y ago
    I've certainly seen cases where we take one step back in one area to take two steps forward in another; where it takes 5-10 years to get language C that can do something that language A we were using 5-10 years before that could do - but only if we forget that we also wanted some capability in the language B that we couldn't do in A, and C is the first language that manages to synthesise both. And industry is always going to be a long way behind the cutting edge - most of the features we're excited about today are things that were present in ML. But on the whole it feels to me like both a) the mainstream industrial programming experience today is better than it was 10 years ago and b) the academic cutting edge of programming language design today is better than it was 10 years ago, and I expect both those things to continue to be true.
andrepd 9y ago
Well this person sure seems very angry and opinionated, yet there's hardly any justifications for his criticisms in this childish rant. I mean if you're going to say everything is "dumb", and "shit" and whatnot, at least tell us why. As it stands this is definitely a case of "maximal opinions and minimal evidence".
Klasiaster 9y ago
Hype is too strong and good ideas of the past are a niche topics. Computer science should focus more on its own history and realize what has been done and needs to be taken further. I wish I studied much earlier about things like process calculi, PL/type system theory, alternative OS design and verification approaches. Just by chance I pick up important information from the web or in rare master's courses where we are just a handful of students (while the machine learning courses get hundreds).
dom96 9y ago
Regarding the effect systems slide. One of my favourite features of the Nim programming language is its effect system,[1] it tracks IO effects, but more importantly it also tracks the exceptions that are raised by each procedure. This allows for a very nice implementation of checked exceptions and docs which contain the possible raised exceptions of each procedure. 1 - https://nim-lang.org/docs/manual.html#effect-system https://nim-lang.org/docs/manual.html#effect-system
shion 9y ago
My project introduction book contains a description of the future programming language, you can see. https://github.com/ShionAt/Keys https://github.com/ShionAt/Keys twitter: @ShionKeys
fmap 9y ago
I like the slides and agree with the widening language gap. I have a few comments about the conclusions, though. > The UPenn dependently typed Haskell > program shows a great deal of promise and > is likely to manifest a decade before other > DT languages generate practical backends. I don't agree with this at all. The design problems with tacking on dependent types to an existing system are massive - it's a research problem for a reason. On the other hand, writing a "ghc quality" backend for Coq/Agda/Idris/F* seems difficult, but at least it's an engineering problem instead of a rough idea. In particular, CertiCoq is a compiler for Coq written in Coq, and the main problem here is verification. Simply writing a compiler is no harder than writing a compiler in any language. > Interesting ideas out of Microsoft Research on SMT solver > directed programming editors that enforce invariants and can > generate code during development. Another interesting Microsoft Research project along the same lines as Dafny is F. Both are nice, but F is closer to modern dependently typed languages. > Lots of non-local reporting problems associated > with using unification during type-checker. I would argue that the problem is that we use constraint solving for type checking. For example, strict bidirectional type checking leads to more tractable errors, since it's straightforward to follow the compiler's reasoning. On the other hand, bidirectional type checking is less powerful, so it's not like there's a silver bullet here. > Type-safe OTP. I wish more people were working on things like this. There's some theoretical work on calculi for distributed systems, but once they encounter the real world they inevitably become horrendously complicated.
AnimalMuppet 9y ago
"Use the right tool for the job" is not the dumbest cliche in software... in theory. But it requires actually knowing what options are available, what their strengths and weaknesses are, and what problems (various kinds of yak shaving) the job will throw at you. Picking the tool that can best reduce the yak shaving is the difference between professionalism and masochism. In practice, though, a lot of people quote this who don't know what options are available, what their strengths and weaknesses are, and what the problems of the job will be, and so when those people quote it, it's just a cliche.
bagswatchesus 9y ago
Maybe not for me and you, but for software development in JavaScript generally it's really not ideal. http://www.sellbagswallets.com/handbags http://www.sellbagswallets.com/handbags

385 points by myth_drannon 9y ago

adamnemecek 9y ago

"It's like X but more practical". -> "There's a library for my domain". 3real5me

quickben 9y ago

It looks like the presentation stops short of any strong conclusion.

banachtarski 9y ago
It's still pretty useful as far as identifying the problem is concerned.

jlward4th 9y ago

"Where will the next great programming language come from?" Interestingly Scala has come from Academia, Industry, and Hobbyists. And for me it's already the next great programming language. Yeah, it has some warts and is hard to learn but that's true of all great things. :)

deleted 9y ago
[deleted]
cpeterso 9y ago
> Scala has come from Academia, Industry, and Hobbyists. That's an interesting point. The slide implies there will be no next great programming language because academia nor industry nor hobbyists can deliver it, but overlooks the possibility of a combination working together. For example, Rust started as Graydon Hoare's hobbyist language and then development was sponsored by Mozilla.
mlazos 9y ago
Yeah this comment stuck out to me in the presentation. Industry has a great record of creating + supporting languages. C#, F#, Dart, Swift, Rust, D are all languages that are actively supported by industry, and some were even created by industry too. Just seemed like a weird statement for the slides to say that new languages just aren’t going to appear.
- throwaway7645 9y ago
  If anything, almost too many of them. In the esoteric language area, every new language takes away from libraries for other ones as the communities get spread out. I do think the spread of ideas from that setup is good though.
- saas_co_de 9y ago
  But how many of those languages include substantial innovation? To me they seem to be mostly rehashing existing technology with slight cosmetic tweaks in order to serve the profit interests and ego of their creators. Now, whatever innovation this proliferation of languages may bring, it also brings fragmentation which acts as a counter-weight on the value created for the industry as a whole. Whether the net effect is positive or negative is very difficult to tell.

telotortium 9y ago

Is there a talk for these slides? I haven't been able to find it.

drefanzor 9y ago

TLDR The future of programming languages should involve not naming your language "Coq". I know I am going through the lowest common denominator, but how do you explain to your boss that you're proficient with using Coq. Ugh. Or professor, since apparently it's a proofing language for academia.

davemp 9y ago
It gets really bad when you're using "Hoare Logic" in "Coq"
tdb7893 9y ago
I would just pronounce it like "coke" and it would just sidestep the whole pronunciation issue. I'm not sure how most people pronounce it but that's what I would do to talk to my boss about it.
- logicchains 9y ago
  I refer to it as "the See Oh Queue theorem proover" at work, which seems to get the idea across.
- taneq 9y ago
  This is the precise reason why "route" is pronouced "root" but "router" is mysteriously pronounced "raow-ter". No-one's gonna stand in front of a room full of people and talk about the "rooter".
  - polymeris 9y ago
    Huh, TIL. As a non-native English speaker, I have always pronounced "route" as "raowt", probably influenced by the pronunciation of "router". Btw, why is it "pronUnciation", but "pronOUced". English is hard.
    - jamesrcole 9y ago
      > Btw, why is it "pronUnciation", but "pronOUced" In Australian English, it is "pronOUNCiation"

qaq 9y ago

Coq should have good interop with cockroachDB.

qaq 9y ago
Why are people so against the future of tech?

WoodenChair 9y ago

What people who do academic analysis of programming languages often miss is culture. So much about what programming language gets used has to do with what ecosystem it's been targeted at and what colleagues in that ecosystem are using.

stmw 9y ago
I couldn't agree more and was just making this point to someone last week - for many of the well-established languages, 80% of the reasons to use or not to use them is the associated culture, from the qualifications of the average applicant to the prevailing approaches to solving problems.

curryhoward 9y ago

> Languages that have dabbled with modeling effects with row types have backtracked on it in favor of IO. Interesting. I thought algebraic effects + handlers were the new hotness in modeling effects with types.

iitalics 9y ago
They are hotness because they are having trouble getting them to work (trouble = open research topic :) ), and they want to convince the monad proponents that they are better.
- toolslive 9y ago
  what trouble ? http://www.eff-lang.org/ http://www.eff-lang.org/

lain-dono 9y ago

> It’s lightweight > I was able to install the compiler It does not prevent the browser from eating all the resources.

YZF 9y ago

One area I haven't seen any good solutions for is the interleaving of tests with production code. I think we need better ways to express tests without cluttering the production code and excessive mocking. What I'd like to do, and really can't in any language/tooling that I know of, is to extract some arbitrary subset of the code and surround it with tests or a test harness. I'd also like to specify various injection points for tests right as I'm writing the code in a way that doesn't affect the production code and contributes to its readability. Perhaps this is pieces of server and client code or various services all tested together. When I refactor the code I want the tests to "refactor" with the code. I don't want to need to rewrite my tests... Automatic test generation is another interesting area (beyond the basic table or algorithm stuff we might do in tests today). It's almost like the "problem" isn't the languages themselves, it's the tooling around the languages. I want to be able to do a lot more than "compile", "run", with my code... I can imagine machine learning driven tooling being able to automate a lot of the mechanical aspects of code writing beyond the simple generate a closing bracket that an IDE can do...

enobrev 9y ago
I can imagine something like a code-collapse indicator next to every method in a class (or function or code block, whatever), which would expand tests that can be run on-the-fly - even while you type. Kind of like how comments can be collapsed in some IDEs. Technically, these could very well be simple commented annotations that point to a separate .test file or something, but are shown in-line by your favorite IDE or code-editor.
tomelders 9y ago
I don’t do coding tests. I talk to the candidate about programming and I only require one interview. I haven’t made a hiring mistake in 6 years.
- closeparen 9y ago
  Uh, this is about automated testing of programs, not interviewing.

chewbacha 9y ago

TL;DR Everything is awful and nothing will save you

whytheam 9y ago

Very disappointed not to see Cilk included.

stmw 9y ago
Do you mean this Cilk? https://en.wikipedia.org/wiki/Cilk https://en.wikipedia.org/wiki/Cilk
- whytheam 9y ago
  Yes. Cilk is very easy to use and has pretty good performance. I would love to see it used more in industry rather than just in academic work.

cromwellian 9y ago

Perhaps the future of programming isn't in linear deterministic code but in stochastic or probablistic languages dealing with machine learning or biology. Maybe we're hitting Godel/Turing-like wall and as we strive for more perfection and provable soundness, we will find we can't scale up to bigger and bigger systems. We'll be stuck with human debuggable linear languages like we have today or systems which operate more like a composition of machine learning models.

yazaddaruvala 9y ago
Of course in practice we know is a lot easier to build and use probabilistic models. However, I hope we don't give up on proovable systems. When given enough time, if math can stay pure and adequately abstract to eventually describe our entire universe concisely. Shouldn't code similarly have no limitation?
deleted 9y ago
[deleted]

wsxiaoys 9y ago

In case of anyone interested a reasonable engineered language that supports Closure Serialization (mentioned as "hard" in last slide), checkout: Gambit Scheme: A fast scheme implementation. http://github.com/gambit/gambit http://github.com/gambit/gambit Gerbil Scheme: Provides full module and syntactic tower on top of Gambit Scheme. https://github.com/vyzo/gerbil https://github.com/vyzo/gerbil

mrkgnao 9y ago
Does Guile (or even Chicken) do anything similar? (My only exposure to it is from Andy Wingo's blog, and I don't know much about Scheme.)
- wsxiaoys 9y ago
  Nope.

joe_the_user 9y ago

“It just feels readable”. -> “It looks like this other language I know.” But: that language might be English (or other natural language). Which is to say maybe computer languages are leveraging the human "language faculty" and rightly so. Which may mean that some languages are always going to feel more foreign.

fasquoika 9y ago
Considering how many programmers will tell you that C style semicolons and curly braces are more readable than using keywords, I think they've got a point
- Symmetry 9y ago
  At some extremes yes but, for example, I've spent at least twice as much time programming C and C+ than I have with Python but I still find Python generally more readable. Maybe if the ratio were 100 to 1 instead of 2 to 1 I'd feel differently but that suggests there are actually intrinsic differences in readability apart from just familiarity.

jamesrom 9y ago

So are we just going to pretend Perl doesn't exist?

chrisseaton 9y ago
You can't expect 20-or-so slides to cover all languages. And I'm not aware of any PL research topics being explored in Perl, so not sure how talking about Perl would fit in.
- cestith 9y ago
  Perl6 in its spec has auto-parallelization of at least the hyperoperators. It has hyperoperators themselves. It has full LL and LR grammars as part of the language. It has optional strong typing for support of incrementally typing your source. It has junctions. It has a native MOP. It has active metadata on all data types (values, variables, subroutines, and types themselves). Beyond what might be purely PL research, there are some other neat ideas being explored. It does function currying, lazy evaluation, grapheme-level Unicode support, and custom operators from any Unicode grapheme. It's definitely a language I'd be watching if I was writing about near-future languages.

samth 9y ago

This talk is right that effect systems aren't popular yet, except the way Haskell does them. But it's wrong about the trajectory of languages. Right now is the best time to be interested in using cutting edge languages in practice. Also right now has seen an explosion of new languages with interesting ideas, from Rust to Purescript to Elm (in the authors preferred realm of typed languages). Also industry is backing major post-Java languages like F# and Rust. In short, the near future of PL is great, and exciting stuff keeps happening. Don't believe the naysayers.

david927 9y ago

This is a brilliant synopsis of the state of the art -- truly fantastic -- and yet the presentation concludes with, "The innovation won't happen because I can't see where it will come from," and that's not entirely fair. Some areas he covers aren't exhaustively covered and what's missing is quite interesting. In other words, cheer up, there's more hope than what's shown here.

ghthor 9y ago
I think this is just a fustration with how little direct incentive there is from our economic system to fix the problem. The only chance of this paradigm existing is as a long shot project that is gifted to society, and the person that makes this gift has the slim chance that it doesn't succeed and all the effort is wasted.
- peoplewindow 9y ago
  I found that the weakest part of the presentation. Kotlin and Ceylon both came out of corporate/industrial development. C#, JavaScript and Java continue to evolve entirely due to industrial funding. I agree that academia is not a great place to do PL research as all the other non-idea aspects of a successful PL don't get enough attention. But industry is doing OK at launching new languages. Perhaps he feels that's "incrementalism" but there's nothing wrong with making solid upgrades that aren't attempts at unicorn style magic cure-alls. It'd also help if we collectively got over our demand for our tools to always be open source. This has solid justifications behind it but it ensures that programming languages will always be spinoffs of other endeavours rather than having truly focused attention in their own right. When you take away the profit motive, you get stagnation, and that seems to be the main point of the presentation.
- david927 9y ago
  The only chance of this paradigm existing is as a long shot project I couldn't agree more but I also am not as pessimistic as he is at its chances of happening.
kd0amg 9y ago
The central claim isn't that innovation won't happen. It's that they won't go mainstream because nobody has both the means and motive for good tech transfer work.

samcodes 9y ago

This is a great deck... but leaving TLA+ out of Formal Methods? It is hands down the most important thing going on there. And it is a combo between academia and industry. Amazon uses it extensively.

hwayne 9y ago
It also left out Alloy, which is another really exciting formal method that a lot of really cool work has been done in.
pron 9y ago
It also left out all PL research outside of typed FP. It isn't really about the future of programming, but about the future of typed FP. For example, it lists Eve as a "reinvention of Smalltalk" when, in fact, Eve incorporates at least as much cutting-edge PL research as Idris.

fulafel 9y ago

This could be titled "Static typing is not going to save you"? There's nothing but static typing languages and related theorem provers from the timeline slide onwards and the conclusion is that it's too hard. This is a good companion piece for the recent Rich Hickey Clojure/Conj talk :)

stmw 9y ago
I don't really see where you get that. Is dynamic typing demonstrating a lot of sustainable success?
- fulafel 9y ago
  I edited in the Clojure part after you replied. Languages that have forgone static typing aren't necessarily trying to solve everything using language types at runtime. See eg Clojure's approach. Or SQL's. But at the base popularity-contest level the answer is clearly yes: Dynamic languages have been on a roll for the last 30 years - Perl, Python, Ruby, Erlang, Clojure, even JS.
  - 35bge57dtjku 9y ago
    That certainly doesn't mean it's because of their dynamic typing. And Erlang and Clojure, as nice as they are, are still about as popular as AWK is.
- kowdermeister 9y ago
  I've seen a comparison lately with static vs. dynamic languages and it compared bugs/open issues and there was not really an advantage there IIRC.
  - machiaweliczny 9y ago
    It's just my opinion, but there definitely is difference in favor of optional static typing. It simply adds more expressivness to language - you get free documentation standard (input,output,structures) backed in. You don't have annoying typos and you leave data manipulation computation to computer lowering programmer cognitive load. Also you can change code in editor(fastest feedback loop) without even running it(very important if there is high price for running code - ex. complicated system bootstrap, deployment, hardware).

stmw 9y ago

This is a great presentation, I wish I could hear the talk track. While we can all differ on the right "winner" for the next programming language (I don't think Clojure is the right answer, someone else might), we are all stuck with the same set of facts - and this covers the state of things very well. Most importantly, it explains certain truths of the social/economic ecosystem for programming languages - which is what gave us Java, Python, Javascript, and a few other really popular systems that seemed unlikely to succeed when they first appeared. The reasons for their success have just as much to do with "ecosystems" than with language features.

makach 9y ago
my thoughts exactly. it's difficult to understand this presentation without the discussion that goes with each slide. it's too easy to just be biased about the meaning of each slide;
saas_co_de 9y ago
On twitter he says: "The thesis was that programming in 2030 will have very advanced research languages but mainstream languages will effectively stop advancing and we'll be last [sic - left?] with a vast insurmountable gap between the two." That provides some context for what the slides are about.

aryehof 9y ago

My thoughts are that we don't really need more languages. Arguably we don't need better ones either, because they aren't the problem in general computing. Instead we need better design paradigms that better let us model complex requirements and systems into code. Let's have new languages that then support those paradigms. We continue to struggle abstracting complex problems using functional decomposition, structured analysis, information (data) modeling, and object-based decomposition. Many newcomers I meet only know modeling problem domain concepts as data in a database, with behavior and constraints acting on that data in a separate layer, organized using functional decomposition. Of course that layer increasingly approaches a 'big ball of mud' as size and complexity increases. Sounds a lot like we are back data-flow modeling as so popular in the 1980's, in a new guise. A focus on programming languages in my opinion, masks the real issues we face.

ShallowLearning 9y ago
Much of the time, new languages lead to new design paradigms. As a general rule, newer languages are more abstracted than older ones. When people don't need to get hung up on the intricacies of low level programming, real progress can be made on the design paradigm front.
- aryehof 9y ago
  I'm curious which languages have resulted in which new design paradigms?
  - miguelrochefort 9y ago
    Elm -> Elm Architecture
  - arianvanp 9y ago
    Two good examples: Erlang led to Microservices and the Reactive Manifesto. the Open Telecom Platform is still a very modern Microservice library (in my opinion) after more than three! decades ML led to programming against generic interfaces (http://www.cs.cornell.edu/courses/cs312/2006fa/recitations/rec08.html http://www.cs.cornell.edu/courses/cs312/2006fa/recitations/r...)

la6470 9y ago

In the next evolution writing software should be as easy as writing a word document .. not a macro based wordstar dociment. In other words the code should be auto generated and humans should only specify the design -ui and workflows.

Animats 9y ago

"OTP" on p. 23? "One True Pairing"? "Online Transaction Processing"? probably not "On The Phone".

paulsmal 9y ago
Open Telecom Platform? Erlang's runtime
- tormeh 9y ago
  I think it's just the biggest Erlang framework. BEAM is the runtime.
CognitiveLens 9y ago
My guess is the Erlang OTP: http://learnyousomeerlang.com/what-is-otp http://learnyousomeerlang.com/what-is-otp

Animats 9y ago

Things to think about for the near future of programming languages: - The borrow checker in Rust is a great innovation. Previously the options were reference counts, garbage collection, or bugs. Now there's a new option. Expect to see a borrow checker in future languages other than Rust. - Formal methods are still a pain. The technology tends to come from people in love with the theory, resulting in systems that are too hard to use. Yet most of the stuff you really need to prove is very dumb. X can't affect Y. A can't get information B. Invariant C holds everywhere outside the zone (class, module, whatever) where it is transiently modified. No memory safety violations anywhere. What you really need to prove, and can't establish by testing, is basically "bad thing never happens, ever". Focus on that. - The author talks about "Java forever". It's more like Javascript Everywhere. - Somebody needs to invent WYSIWYG web design. Again. - Functional is OK. Imperative is OK. Both in the same program are a mess. - Multithread is OK. Event-driven is OK. Coroutine-type "async" is OK. They don't play well together in the same program. Especially if added as an afterthought. - Interprocess communication could use language support. - We still can't code well for numbers of CPUs in triple digits or higher. - How do we talk to GPU-type engines better?

PaulRobinson 9y ago
I disagree with a few of your thoughts, but they're good thoughts! * Javascript everywhere is a function of low barrier-to-entry for it, but almost everybody agrees it is flawed as a language. If that's the future, we are screwed as an industry. One thing I've noticed (and I say this as a guy who wrote Ruby for 10+ years), is that type safety is becoming a hugely desired feature for developers again. * WYSIWYG web design (a la Dreamweaver) died off a little because the tools saw a web page as standing in isolation. We know however that isn't interesting on its own - it needs to be hooked up to back-end functionality. Who is producing static HTML alone these days? In the case of SPAs it needs API integration. In the case of traditional web app dev, it needs some inlining and hooks to form submission points and programatically generated links to other "pages". Making that easier is the hard part - seeing a web document as an artefact of an output from a running web application container. * Multi-threaded, event-driven, coroutine-type patterns are fine in Go, to my eye. What's making you think we can't mix this up with the right type of language and tooling support? * Is it that we can't code well for CPU counts > 100 or that the types of problems we're looking at right now that need that level of parallelism tend to be targeted towards GPUs or even ASICs? I think I'd need to see the kind of problems you're trying to solve, because I'm not sure high CPU counts are the right answer. * Talking to GPU-type engines is actually pretty simple, we will deal with it the same way we deal with CPU-type engines: abstraction through a compiler. Compilers over time will learn how to talk GPU optimally. GPU portability over the next 20 years will be a problem to solve as CPU/architecture portability was over the last 40.

Schampu 9y ago

Dynamic analysis + machine learning could become next-generation coding: https://maierfelix.github.io/Iroh/ https://maierfelix.github.io/Iroh/

ernst_klim 9y ago

OCaml is as "industrial" as Haskell is.

josefrichter 9y ago

Just curious where does Elixir fall in this scheme of things? Any experienced devs who could give a qualified answer, please?

machiaweliczny 9y ago
Elixir is mostly different syntax(Ruby-like instead of Prolog-like) for Erlang. Beyond syntax change it fixes some Erlang warts, ads better metaprograming and great tooling. Elixir isn't academic innovation - it's about proffessionals convinience and effectivness similar as go lang. Started by 1 person.
bjz_ 9y ago
Elixir doesn't really push much of the state of the art forward. It's pretty much Erlang with new clothes (and some nice cleanups). I worked with it for over a year and while I loved the 'fail fast' model of programming, most of the errors that were caught were stupid programming errors that would have been trivial to catch by a type system. What I really want is a type system for reasoning about distributed, stateful, programs. Has to deal with mixing strongly consistent eventually consistent (CRDT) data with synchronisation points (see Bloom/Lasp), hot code reloads, migrations, messaging across nodes, possibly some sort of row polymorphism combined with clojure's namespaced symbols... Like sort-of like Cloud Haskell but with zero-downtime deployments. Or like Pony but with a better distribution story.
- rurban 9y ago
  Distributed Pony will be there soon. https://www.doc.ic.ac.uk/~scd/Disributed_Pony_Sept_13.pdf https://www.doc.ic.ac.uk/~scd/Disributed_Pony_Sept_13.pdf [pres], https://www.ponylang.org/media/papers/a_string_of_ponies.pdf https://www.ponylang.org/media/papers/a_string_of_ponies.pdf [paper] I'm not sold on Cloud Haskell or Clojure.

lispm 9y ago

Looking at the 2010 Haskell report: most of the committee members come from 'Academia': https://www.haskell.org/onlinereport/haskell2010/haskellli2.html#x3-2000 https://www.haskell.org/onlinereport/haskell2010/haskellli2.... How is it an 'industrial' language? Haskell is the main 'academic' language for a branch of Functional Programming. 'industrial' is just another weasel word.

throwaway7645 9y ago
If you keep your head to the ground, there are quite a few companies like Facebook that use Haskell for important things in production, but it isn't the language even 50% of the company is using. I'm sure there is a lot more lisp in production, but you typically hear about the same ratio from both camps in the blogosphere.
- lispm 9y ago
  I would guess that in a company like Facebook, 99.5% of the code they wrote is not Haskell. If they have, say, 200MLOC of code written (just a number), this would be 1MLOC...
  - pjmlp 9y ago
    There are companies using a bit more of Haskell in production. http://cpmed.de/jobs/ http://cpmed.de/jobs/
mrkgnao 9y ago
Haskell lends itself pretty well to "backend"[0] work, and there are more than a few organisations using it to write servers, trading systems, and so on. It definitely fits his metric, which is "> 1000 industrial users". [0] (Unlike applying it to the frontend, which is a comparatively less mature situation with multiple proposed solutions.)
- deleted 9y ago
  [deleted]

pron 9y ago

> Will we just be stuck in a local maxima of Java for next 50 years? 1. Yes, if the extent of the imagination is languages like Idris and ideas like effect systems, that follow a gradient descent from Java, and always in the same direction: being able to express more constraints. What you get "for free" from such languages may not be significant enough to justify the cost of adoption, and the valuable stuff you can get is not much easier than the options available today, which are too hard for anyone to take. If you were to consider truly novel languages that think out of the box (e.g. Dedalus/Eve) then maybe one will stick and make an actual impact rather than just a change in fashion. 2. How do you even know that we can do much better? NASA engineers may not like it, but they don't complain that we're "stuck" at sub-light speeds. Maybe Brooks was right and we are close to the theoretical limit (that we know must exist). > We talk about languages as a bag of feelings and fuzzy weasel words that amount to “It works for my project”. Can you find another useful way, available to us today, of talking about languages? > “Use the right tool for the job” Zero information statement. That's right, but it's not a dumb cliché so much as it is a tool we've developed to shut down religious/Aristotelian arguments that are themselves devoid of any applicable, actionable data. One, then, is often confronted with the reply, "but would you use assembly/Cobol?" to which the answer is, "of course, and it's not even uncommon, and if you don't know that, then you should learn more about the software industry before giving any more Aristotelian arguments."

lmm 9y ago
> if the extent of the imagination is languages like Idris and ideas like effect systems, that follow a gradient descent from Java, and always in the same direction: being able to express more constraints. I don't think that's a fair reflection of what these languages feel like. When your constraints mean that only the right thing can be done, you can make the thing implicit. The things that are tacit when humans talk about the problem can be tacit in our programming as well. You have ways to factor out concerns that are separate, even when they are entangled. "Better decomposition of the problem" doesn't sound exciting, but ultimately that's the very essence of programming. I don't think we need new grand ideas, at least if we're just talking about the next 50 years of industrial programming; I think we need to follow through on the ideas we already have, and I actually think that gradient ascent from Java will happen, and will move the industry forward, even if it ends up being a lot slower than I'd like. > How do you even know that we can do much better? NASA engineers may not like it, but they don't complain that we're "stuck" at sub-light speeds. Maybe Brooks was right and we are close to the theoretical limit (that we know must exist). I think we can go at least one or two substantial steps better than Idris: I want Noether's levels of stratification (beyond just total/not-provably-total), and I want Rust-style linearity, not as a specialised capability but as something integrated into the regular type system. But even if Idris is the limit, it's still a big step ahead of Java, and it's going to take the industry a while to make that step. (Maybe it will have to be two or three steps to get there - it feels like most of the industry is only just adopting the things that OCaml offered, and not yet familiar enough with them to appreciate what Haskell offers above that. And I can't blame them - I only have an appreciation of those things because I've been able to work for a long time in Scala and very gradually work my way up towards using the less familiar facilities). "The future is already here — it's just not very evenly distributed." > Can you find another useful way, available to us today, of talking about languages? Yeah, that's the problem :(. The whole industry is a huge iceberg in terms of what's visible about the practice of programming versus what's actually happening. I'd like to see more programming happening in public - which I think probably means more publicly-funded programming (I was thinking about this a few days ago in the context of research and scientific code - we have a relatively good system in place for providing grants for research, but we're a lot less good at funding the infrastructure that's used for research - we end up with a lot of researchers repeating the same work because they're only ever funded for a specific project, rather than being funded to produce something that's useful for many research projects). What makes sense in an open-source webdev project is all that most of us ever see about most languages, and while it's a lot better than nothing it's still a seriously distorted picture of what most programmers are actually doing.

js8 9y ago

I would love to see programming as a dialogue between user and computer (programmer and compiler). For example: Compiler would infer the types, and the programmer would read it and say, oh, I agree with this type, but I disagree with this type, that's perhaps wrong, this should be rather that type. Then the compiler would infer types again, based on programmer's incremental input. Data structure selection. Programmer would say I want a sequence here. The compiler would say, I chose a linked list representation. The programmer would look over it, and disagree, saying, you should put this into an array. And compiler could say, look, based on measurements, array will save this much space but list will be this much faster. Code understanding. Programmer should be able to say just, I don't know what happens here, and the compiler would include some debug code to show more information at that point. Or take refactoring. Programmer would write some code, computer would refactor it to simplify it. Then programmer would look over it, and say, no, I rather want this, and don't touch it, and he would perhaps write some other code. The compiler would refactor again... But all this requires that there is syntactically distinct way (so that perhaps editor could selectively hide it) to specify these remarks in the code, both for computer and programmer. So each of them should have a special kind of markup that would be updated at each turn of the discussion. Because you don't want to just overwrite what the other side has just said; both are good opinions (which complement each other - human understands the purpose of the code but the computer can understand the inner details much better). So, to conclude - I wish future programming language would include some framework like this.

mrkgnao 9y ago
> Compiler would infer the types, and the programmer would read it and say, oh, I agree with this type, but I disagree with this type, that's perhaps wrong, this should be rather that type. Then the compiler would infer types again, based on programmer's incremental input. This is possible today, at least in Haskell. (and I'd guess in OCaml too ... surely also Scala?) Your proposal for adaptive data structure selection based on benchmarking is intriguing!
currymj 9y ago
wrt your first paragraph there, I urge you to take a look at Idris. That's the exact workflow.

miguelrochefort 9y ago

cough Prolog cough

TuringTest 9y ago

> Lots of people are reinventing Smalltalk on a Mac. (See Bret Victor and Eve). At last, someone noticed! ;-) Though from that expression, what the author doesn't seem to grok is why having a Smalltalk-like environment is desirable; maybe not as the primary way to program computers but certainly as a tool alongside. It's a shame that a family of programming languages that build on and expanded that model hasn't gained more traction in the industry (not necessarily for people who dedicate their lives to build complex software with a highly general programming language, but for the rest of us).

vanderZwan 9y ago
I find the jab at Bret Victor especially undeserved. He's an interaction designer (a really good one who sees through all the fads[0], which is kind of the opposite of what this one-liner implies). His focus is on better interface design, not formal language design; why criticize someone for something they're not trying to do? And it's not useless; we probably wouldn't have had Elm without Bret Victor's Inventing on Principle[1][2]. And there has been some progress in that direction of interface design of, for a lack of a better term, "programmable environments": look at Apparatus, for example[3]. Where would you even fit that on these slides? [0] http://worrydream.com/ABriefRantOnTheFutureOfInteractionDesign/ http://worrydream.com/ABriefRantOnTheFutureOfInteractionDesi... [1] http://elm-lang.org/ http://elm-lang.org/ [2] https://vimeo.com/36579366 https://vimeo.com/36579366 [3] http://aprt.us/ http://aprt.us/
- TuringTest 9y ago
  Quite true. I find likely that the next revolution in programming languages will come from designing a PL that's a good fit for these programmable environments. Maybe it should break from current undisputed conventions like the radical separation between "data" and "source code", and be more like a spreadsheet. End-User Development has lots of under-explored ideas on how to build software automatisms that don't require the end user to learn a hard formalism (even if such formalism exists as the basis for the system). Though I understand that programming language theorists are not interested in that angle of the evolution of PLs.

rotten 9y ago

Recently a famous AI project was shut down because it was inventing its own language. Perhaps the next generation programming language and design paradigms won't come directly from humans at all.

myth_drannon 9y ago
Are you talking about Theano?

lmm 9y ago

The "Language Gap" slide seems massively overstated, or maybe I'm misunderstanding. We really have seen a lot of progress in the last 10-20 years, both in industrial languages and in academic ideas that could become the industrial languages of the next 10-20 years (e.g. Idris on the short end, Noether on the longer end). The author laments that pattern-matching is still not standard, but we're getting there; map/reduce/filter are standard in all new languages these days (they weren't 10-20 years ago), some kind of lightweight record feature is standard in all new languages, some level of type inference is standard in all languages. Yes, it's taken longer than you might imagine it should, but progress is happening. Likewise formal methods - they may not be practical in 2016, but there's a lot more awareness, a lot more work being done, and people are starting to try to take the useful parts and apply them in more and more industrial settings. Likewise graphical representation of code - not the LabView nonsense that's exciting to talk about at cocktail parties, but the little touches that today's IDEs do almost invisibly - highlighting, mouseover information, outline views, smart code folding. I wish we were better at communicating about programming languages. I wish we were moving faster. But despair is unwarranted. We really are in a much better place than 10-20 years ago, and the next 10-20 years look set to bring more improvements.

pjmlp 9y ago
10-20 years ago some of us could use Smalltalk, do systems programming with strong type safe languages, use RAD environments like Delphi, release applications in Prolog, for example. To me it seems we are catching up with the past, and as someone already programming on those environments, it looks we have spent 10-20 years loosing our tools, educating the masses, only to get a taste of things used to be.
- lmm 9y ago
  I've certainly seen cases where we take one step back in one area to take two steps forward in another; where it takes 5-10 years to get language C that can do something that language A we were using 5-10 years before that could do - but only if we forget that we also wanted some capability in the language B that we couldn't do in A, and C is the first language that manages to synthesise both. And industry is always going to be a long way behind the cutting edge - most of the features we're excited about today are things that were present in ML. But on the whole it feels to me like both a) the mainstream industrial programming experience today is better than it was 10 years ago and b) the academic cutting edge of programming language design today is better than it was 10 years ago, and I expect both those things to continue to be true.

andrepd 9y ago

Well this person sure seems very angry and opinionated, yet there's hardly any justifications for his criticisms in this childish rant. I mean if you're going to say everything is "dumb", and "shit" and whatnot, at least tell us why. As it stands this is definitely a case of "maximal opinions and minimal evidence".

Klasiaster 9y ago

Hype is too strong and good ideas of the past are a niche topics. Computer science should focus more on its own history and realize what has been done and needs to be taken further. I wish I studied much earlier about things like process calculi, PL/type system theory, alternative OS design and verification approaches. Just by chance I pick up important information from the web or in rare master's courses where we are just a handful of students (while the machine learning courses get hundreds).

dom96 9y ago

Regarding the effect systems slide. One of my favourite features of the Nim programming language is its effect system,[1] it tracks IO effects, but more importantly it also tracks the exceptions that are raised by each procedure. This allows for a very nice implementation of checked exceptions and docs which contain the possible raised exceptions of each procedure. 1 - https://nim-lang.org/docs/manual.html#effect-system https://nim-lang.org/docs/manual.html#effect-system

shion 9y ago

My project introduction book contains a description of the future programming language, you can see. https://github.com/ShionAt/Keys https://github.com/ShionAt/Keys twitter: @ShionKeys

fmap 9y ago

I like the slides and agree with the widening language gap. I have a few comments about the conclusions, though. > The UPenn dependently typed Haskell > program shows a great deal of promise and > is likely to manifest a decade before other > DT languages generate practical backends. I don't agree with this at all. The design problems with tacking on dependent types to an existing system are massive - it's a research problem for a reason. On the other hand, writing a "ghc quality" backend for Coq/Agda/Idris/F* seems difficult, but at least it's an engineering problem instead of a rough idea. In particular, CertiCoq is a compiler for Coq written in Coq, and the main problem here is verification. Simply writing a compiler is no harder than writing a compiler in any language. > Interesting ideas out of Microsoft Research on SMT solver > directed programming editors that enforce invariants and can > generate code during development. Another interesting Microsoft Research project along the same lines as Dafny is F. Both are nice, but F is closer to modern dependently typed languages. > Lots of non-local reporting problems associated > with using unification during type-checker. I would argue that the problem is that we use constraint solving for type checking. For example, strict bidirectional type checking leads to more tractable errors, since it's straightforward to follow the compiler's reasoning. On the other hand, bidirectional type checking is less powerful, so it's not like there's a silver bullet here. > Type-safe OTP. I wish more people were working on things like this. There's some theoretical work on calculi for distributed systems, but once they encounter the real world they inevitably become horrendously complicated.

AnimalMuppet 9y ago

"Use the right tool for the job" is not the dumbest cliche in software... in theory. But it requires actually knowing what options are available, what their strengths and weaknesses are, and what problems (various kinds of yak shaving) the job will throw at you. Picking the tool that can best reduce the yak shaving is the difference between professionalism and masochism. In practice, though, a lot of people quote this who don't know what options are available, what their strengths and weaknesses are, and what the problems of the job will be, and so when those people quote it, it's just a cliche.

bagswatchesus 9y ago

Maybe not for me and you, but for software development in JavaScript generally it's really not ideal. http://www.sellbagswallets.com/handbags http://www.sellbagswallets.com/handbags