I'm interested in groups who are thinking about the next thirty years, rather than the next five years.
Some projects I find interesting:
* Subtext by Jonathan Edwards: https://vimeo.com/106073134
* Apparatus by Toby Schachman: http://aprt.us
* Bret Victor's explorable explanation and introspectable programming demos: http://worrydream.com
* Eve by Kodowa: https://www.youtube.com/watch?v=VZQoAKJPbh8
* Scratch by the MIT Media Lab: https://scratch.mit.edu
* Mathmatica by Wolfram Research: https://www.wolfram.com/mathematica
Why am I interested? I'm working on Code Lauren, a game programming environment for beginners: http://codelauren.com I want to learn as much as possible about work done by others in the same area.
...and STEPS:
http://www.vpri.org/pdf/tr2011004_steps11.pdf
"We set a limit of 20,000 lines of code to express all of the “runnable meaning” of personal computing (“from the end‑user down to the metal”) where “runnable meaning” means that the system will run with just this code (but could have added optimizations to make it run faster). One measure will be what did get accomplished by the end of the project with the 20,000 lines budget. Another measure will be typical lines of code ratios compared to existing systems. We aim for large factors of 100, 1000, and more . How understandable is it? Are the designs and their code clear as well as small? Can the system be used as a live example of how to do this art? Is it clear enough to evoke other, better, approaches?"
* Refinement types
Liquid Haskell: https://ucsd-progsys.github.io/liquidhaskell-tutorial/02-log...
* SMT Solver Language Integration
Cryptol: https://github.com/GaloisInc/cryptol
* Session Types
Scribble: http://www.scribble.org/
* Dependent Types
Agda: https://en.wikipedia.org/wiki/Agda_(programming_language)
Idris: http://www.idris-lang.org/
* Effect typing
Koka: https://research.microsoft.com/en-us/um/people/daan/madoko/d...
* Formal verification
Coq: https://www.cis.upenn.edu/~bcpierce/sf/current/index.html
TLA+: http://research.microsoft.com/en-us/um/people/lamport/tla/tl...
This is the general trend, generally making more composable abstractions and smarter compilers and languages that can reason about more of our programs for us.
* Unsion by Paul Chiusano: http://unisonweb.org/2015-05-07/about.html
* APX by Sean McDirmid: https://www.youtube.com/watch?v=YLrdhFEAiqo
* Awelon by David Barbour: https://github.com/dmbarbour/awelon/blob/master/AwelonProjec...
And perhaps more in the "next five years" category:
* Om Next by David Nolen: https://www.youtube.com/watch?v=MDZpSIngwm4
* Elm by Evan Czaplicki: http://elm-lang.org/
I'm working on Full Metal Jacket, a strongly-typed, visual, pure dataflow language (http://web.onetel.com/~hibou/fmj/FMJ.html) with its own IDE.
Things have advanced a fair bit since I wrote those pages, and published the recent paper, so I'll add to the tutorials very soon, and announce this in Hacker News. Type definition, macros, and a few other things have been added to the language.
.303 shared-source release approaches, but I don't do deadlines.
No battle plan survives contact with the enemy, but I have some ideas for future directions, including adding dependent types, running on a multi-core machine with speculative execution, and automatic programming (i.e. user supplies just inputs and outputs). Very long-term ideas involve a developing a variant of the language which enables programs to run backwards, to enable execution on a gated quantum computer.
But I'm sticking with the keyboard. And the "visuals" will still be text, with the option of other visualizations. Keyboard+text scales better than anything else.
Who do you see as the core users of these tools?
Some that are fairly mature projects:
vvvv - https://vvvv.org/
Puredata - https://cycling74.com/products/max/
Max MSP - https://puredata.info/
Conal Elliott's work on Tangible FP was an interesting attempt to unify functional and "visual" programming that has been mostly abandoned: http://conal.net/papers/Eros/ Hopefully some of its ideas may yet survive in other projects.
The Berkeley Orders of Magnitude project is somewhere at the intersection of database and PL research, aimed at handling orders of magnitude more data with orders of magnitude less code: http://boom.cs.berkeley.edu/ The Dedalus language in particular is interesting, as it integrates distributed- and logic-programming: http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-17...
Joe Armstrong's thoughts on a module- or namespace-less programming environment are interesting: http://erlang.org/pipermail/erlang-questions/2011-May/058768...
I've been meaning to write a blog post about the convergence of various ideas of what the future of programming might look like for a while now, so I have a bunch of notes on this topic. The OP & other folks have already mentioned most of the other projects in my notes - in particular Unison, Subtext, Eve, & Bret Victor's work.
My current line of work is on tackling a tiny little corner of what I see as the future's problems - trying to find a better way to combine database/relational programming and functional programming. My work is here (but the docs are almost entirely in type-theory-jargon at the moment, sorry! feel free to shoot me an email if you have questions): https://github.com/rntz/datafun
At the beginning, when defining what types, expressions, contexts, etc. looks like. I use a bunch of BNF (https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form). I'm afraid I don't actually know a good introduction to BNF.
The clearest account I know of of the most critical part of my notation, namely inference rules (those things with the big horizontal bars), is in Frank Pfenning's notes for his course on Constructive Logic: http://www.cs.cmu.edu/~fp/courses/15317-f09/lectures/02-natd... (the full course of notes is at http://www.cs.cmu.edu/~fp/courses/15317-f09/schedule.html, but the one I've linked is most relevant)
A lot of the rest of my notation (types like A × B, A → B, expressions like λx.e, the judgment Δ;Γ ⊢ e : A meaning "e has type A in context Δ;Γ", and the inference rules themselves) is borrowed from fairly standard type-theory-of-functional-languages stuff. Standard books to read here are Types and Programming Languages by Benjamin Pierce (https://www.cis.upenn.edu/~bcpierce/tapl/); or Practical Foundations for Programming Languages by Bob Harper (https://www.cs.cmu.edu/~rwh/plbook/book.pdf). Those are pretty heavy books that cover a lot of ground, including stuff that's mostly irrelevant to my work. If you're interested, though, they're a great place to start learning about formal PL theory!
Was there anything else in particular you wanted to know about?
Some guiding principles:
1. So much of what hinders programmers is that the friction to using existing solutions is so high that they choose to redo the work themselves. In Tonic we've made every package for javascript immediately available (over 200,000), so that you can focus on putting existing pieces together. We keep adding them as they come in immediately, as well as making notebooks accessible to each other. Its like you have access to the global library.
2. There shouldn't be any snippet of code online that isn't runnable. Every example you read on the internet should be immediately runnable (regardless of whether it require binary packages or what have you). The difference in understanding when you can tweak an example and see what happens vs just cursory reading over it and thinking you get it is huge. Tonic embeds allows this: https://tonicdev.com/docs/embed
As insane as a lot of it seems, most of it are just logical conclusions from a few base ideas: what would computers look like if you owned your own data, if it was all built on top of a purely functional VM backed by bignum binary trees, if you could replace all the mistakes made over the years (nonversioned file systems, untyped shells, manually serializing data structures)
"Re-inventing the wheel" is a phrase usually used in derogatory manner, but it's computing has changed so much in its brief lifetime that I've often wondered why we haven't started over; shed things we don't need any more, and built everything as we would today with all those lessons learned.
It's too easy to be confused over or not sure how to accomplish something Unix-y, and for the answer to begin with "oh well because originally", or "well, you see, in the eighties.."
It's mostly conceptual right now, but my idea is to represent knowledge as a hypergraph with spatial and temporal dimensions on both edges and vertices. This, I hope, could represent every kind of knowledge I can imagine. The hypergraph would function as a filesystem and database, and you could query/program the system. It would be Emacs for all media, and not just text.
I want to augment the inherent power of the hypergraph with a mashup of the OpenEndedGroup's Field, Xerox PARC's Smalltalk, Doug Engelbart's NLS, Symbolics' Open Genera, org-mode, Vim, the Wolfram Language, Bell Labs' Plan 9, and Ted Nelson's ZigZag and Xanadu projects.
If anyone finds this interesting and wants to chat about this stuff, please email me at the email address in my profile.
However a noob in building a language ;)
I have learn a lot of stuff. For example, columnar-stores provide some nice oportunities to manage data in-memory + compress values in columns.
Sorting, joining & selecting on multiple-arrays that are a necessity for OLAP queries translate well to the need of normal programming.
SQL is a overcomplication and a bad "programming" language. Unfortunately, the only practical way to interface with most databases.
If my plan work, this could be good to build a relational store, that with let your to say: The name is a string, and I need to search on it. A normal engine will need to store it again in a index. I will say instead, the name column is the index and the values are stored once.
Or something like that.
BTW: A relation have some simmetry with inmutable functions, but I still don't know how exploit this fact
Datomic is a database that uses it as its query language -- it is really nice to work with.
It's in the very early stages at the moment.
Wrt to Code Lauren you may also be interested in http://www.cs.cmu.edu/~NatProg/index.html - a HCI approach to tooling (the WhyLine is my favourite).
Dog hasn't released much info yet but it's an interesting concept - http://dl.acm.org/citation.cfm?id=2502026 https://www.media.mit.edu/research/groups/social-computing
Program synthesis is really interesting area of research eg http://research.microsoft.com/en-us/um/people/sumitg/
VPRI has already been mentioned but I'd like to highlight their work on Programming as Planning - http://www.vpri.org/pdf/m2009001_prog_as.pdf
From the last FPW, there were a couple of projects that really stood out for me: http://probcomp.csail.mit.edu/bayesdb/ http://2015.splashcon.org/event/fpw2015-an-end-user-programm...
Also not really a new language, but Sam Aarons work on Sonic Pi is pedagogically interesting - http://sonic-pi.net/
A Functional and Logical Dataflow language.
http://www.reddit.com/r/unseen_programming
Status: under development.
Functions are components, which can be used recursively. Arrows are logical relations between these functions. Inspired by Scala and VHDL.
The logic and flow deal with the control and time aspect.
Testing and commenting is integrated in the graphical system as different layers. All graphical structures can be converted to (reasonably) simple text, resembling Scala.
Really, its how GLSL and other shader languages work already, just hidden behind C-like syntax and lies.
I wrote this non-traditional program editor: https://youtu.be/tztmgCcZaM4?t=1m32s
And a new kind of visual debugger: https://www.youtube.com/watch?v=NvfMthDInwE
This guy seems kinda young. Does anyone think that the future of programming can come from people without extensive programming experience of current programming?
Anyway, good luck!
I'd like to see a system where you have tiny, composable pieces of syntax written declaratively in a domain specific language that's as terse and general as possible - stuff like "a[n] -> (list-ref a n)" and "a..b -> (iota a b)". You want to make it as easy as possible to port language concepts to the system. Most of the wacky semantics you can get in other languages can be had in Scheme through some sort of library already, they're just usually kind of a pain in the ass to use without the syntax. Then making the language of your dreams is just a matter of enabling all the syntax you like. You'd need some kind of mechanism for handling grammar conflicts.
Of course, it's really hard. "Syntax" masks a lot of complexity. A feature I want, for instance, is to have the whole language behave like a CAS, where instead of bombing out on an undefined symbol it just computes as much as it can symbolically and hands it back to you e.g. "x+2+3" returns "x+5" if x isn't defined. That sort of thing has been done in Scheme of course, but it's hard to imagine a syntax specification language that would let you just turn that on as a single "feature" without massively affecting basic things like expression parsing grammar.
https://en.wikipedia.org/wiki/Probabilistic_programming_lang...
Formal verification using ACL2 or Coq or other tools also.
On the other hand, we do have two good examples: emacs and paredit. We don't abstract away text because we haven't really figured out how (some in this thread are trying, but the exceptions prove the rule), and parentheses we just abstract into fewer parentheses.
The point being: the medium must remain the same for the pleasant feeling of muscle memory to occur.
One interesting point is programming paradigms; a paradigm is (among other things) a relatively constrained set of actions one takes. Were programming changed to a more physical activity, one could imagine watching a developer and discerning, "ah, the object-oriented style," much as popular imagination imagines a martial artist watching another fight and discerning his style.
The last idea I'm having as I write this: I have also worried about "be careful what you wish for." Do we really want to repeat the same gross movements not as comfort demand, but as the code requires?
So one idea I have is: what if you tied certain operations/manipulations not to body movements, but to aspects of that movement. Short, staccato movements of any kind might correspond to indents or whatever: what's important is that one can do short staccato movements while walking, or golfing around with a pen, or reaching for a snack.
Weird stuff, just throwing it out there.
I expect we'll end up with a predominantly interactive approach to programming, most likely visual drag-and-drop style programming, in a live environment that knows common patterns, data structures, algorithms; giving real-time advice, showing native code output as you go, etc. Basically, you're molding the system while monitoring it under various contexts, and you're programming against data models.
Got a new Arduino board? Just drag and drop the data sheet model into your environment. It contains memory address information, read/write contexts, access protocols, contexts, etc for every component, and how they're connected. Now you design the rest of the logic.
"A programming language is a user interface as much as it is any other thing. Why have multiple ones? They are all Turing equivalent."—Alan C. Kay (see the talk for the context of the quote; starts at around 23:25)
"Rethinking CS Education | Alan Kay, CrossRoads 2015." https://www.youtube.com/watch?v=N9c7_8Gp7gI
"Most computer people went into computing because they were disturbed by other human beings."—Alan C. Kay
Because we're prelaunch(and working hard on getting it to all of you!) I can't talk about it much yet, but we're funded and looking to work with great people.
Email me at cammarata.nick@gmail.com if you're interested in this space, would love to hear ideas and talk more.
The way that Datomic uses Datalog is really interesting from a perspective of "new approach to programming" (databases).
Erik Demaine's course on advanced data structures gives some interesting ideas for time-travel-based games: https://courses.csail.mit.edu/6.851/spring14/ . His work also has application to other fields like creating an efficient in-app version control system http://www.cs.utexas.edu/~ecprice/papers/confluent_swat.pdf .
Lots of cool stuff on HaskellWiki; for example https://wiki.haskell.org/Functional_Reactive_Programming .
If you really want to jump into the deep end there's a whole blog called Lambda: the Ultimate about new approaches to programming: http://lambda-the-ultimate.org/
As a concrete examples making industry waves, see Excel's new Flashfill and Trifacta ETL wrangling product.
Underneath, these use search (ML, SMT, ...) to allow non-tradiotional & sloppy coding: fill in the blanks, program by demonstration, etc.
John Maloney (co-inventor of Scratch), Jens Moenig (who was on the Scratch Team and develops Snap!), along with Yoshiki Oshima (who may also have been on the Scratch team), are deveolping a new langauge "GP" (for General Purpose) which like "professional Scratch".
Here's a video of it: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&c...
There's also lots of extenstions to Scratch and Snap! particularly around CS education, and I'd be happy to discuss those!
Spiral http://www.spiral.net/index.html and spiralgen - going straight from math to code optimized for multiple platforms: http://www.spiralgen.com/
Automatically solving bugs using genetic algorithms : http://dijkstra.cs.virginia.edu/genprog/
Automatic bug repair(2015): http://news.mit.edu/2015/automatic-code-bug-repair-0629
YC company run by Mike McNeil. Visual backend programming. Built off Node, Sails and Machine Spec. The latter is particularly interesting:
@maryrosecook I'm glad this post showed up in our Slack feed- really cool topic! As I'm sure you've noticed from the volume, variety, and impressive comments in this thread, improving approachability/usability for software development is an exciting (albeit broad) effort, and there is a lot of amazing work underway. In the area of declarative programming specifically, there's a lot still to do, but as a community we're getting really close. That said, there is far too much work to do here for any one team to do it by themselves.
To be successful, or at least to expedite the process of democratizing software development, I believe we need to establish a common set of semantics for describing _what software is_. And the first step towards that is deconstructing functions-- or perhaps more accurately: "subroutines".
The rest of the Sails.js core team and I have been working on this problem for quite some time now, primarily as a reaction to having to build plugin system after plugin system in Sails as the framework's user base grew, and getting frustrated with every plugin system being a little bit different. After we had our first working prototype of the tech that would become Treeline, we extrapolated and open-sourced the machine specification and related utilities as a way of exposing building blocks for other devs to reuse for their own projects.
To add a little background, machines are stateless building blocks; nothing fancy. They're more or less equivalent to asynchronous functions in JavaScript, just highly specified. In particular, machines encapsulate definitions of their inputs, their exits, and whether they are "cacheable", just "idempotent", or neither (and therefore have side effects). Machines are oftentimes implemented as JavaScript functions-- although part of the project's philosophy is that what's important is the _usage_, not the implementation.
From the perspective of a traditional "intro to programming", an example of a machine is `moveTurtleDown()`: https://gist.github.com/mikermcneil/864b930a67b0d00d3d8b
As a more practical example, here's the documentation for a handful of machines related to string manipulation: http://node-machine.org/machinepack-strings (To try any of them out, just copy and paste the generated sample code into e.g. a Tonic sandbox: https://tonicdev.com/npm/machinepack-strings)
Each of a machine's expected inputs may be required or optional (with a potential default value) and declare a type schema. Each of its exits may optionally declare a return value, and if so declare a type schema for it. In addition, machines have strict conventions for meta properties (e.g. the machine `description`, which summarizes the machine's behavior when run, is ~80 characters or less of English, written in the imperative mood and in sentence case with ending punctuation)
This can be used to generate documentation, code for interactive form elements, or in the case of the default machine runner, runtime type validations.
But most important of all, once a piece of code is written to the machine spec and open-sourced, it can be used by any tool or platform which consumes that spec (think USB).
As an example, in Treeline we use machines as draggable/droppable components that you can compose into what we call a "circuit"; which can _itself_ be used as the implementation of another "composite" machine with its own inputs and exits (vs. an "analog" machine; i.e. a machine implemented with JavaScript code). We are planning to publish the circuit spec and related tooling for composite machines later this year. In the mean time, the analog machine spec is stable and ready to use. Around 500 MIT-licensed machines are available today on NPM, with generated documentation hosted on the Node Machine registry.
Hopefully that was a helpful first look- if I can help explain further or if you'd like to discuss the project roadmap, just hit me up on Twitter. It's really awesome to see so much new interest and progress in this tech, and particularly in the context of education. Excited to see where you go with CodeLauren!
1. https://github.com/jonnor/projects/blob/master/introspectabl..., maybe especially Agree
1. Modula-2-style systems language with macros, better typing, and typed assembler to replace C with minimal hit on performance or ease of use.
2. Relatively-simple, imperative language plus translators to equivalent functionality in mainstream languages to leverage their static analysis or testing tools if possible.
3. Unified architecture to natively represent and integrate both imperative (C or Modula style) and functional (Ocaml or Haskell style) languages. Extensions for safety/security at hardware level for both.
4. Hardware/software development system using Scheme or abstract, state machines that can turn a high-level description into software, hardware, or integrated combo of both.
5. Defining TCB's for type systems, OS architectures, etc that minimize what must be trusted (mathematically verified) to ensure invariants apply while maximizing expressiveness. crash-safe.org and CertiKOS are more concrete, useful, and professional versions of what I'm getting at with 5.
6. Building on 5, a series of consistent ways of expressing one program that capture sequential, concurrent, failure, integration, and covert channel analysis in a clean way for formal analysis. As in, an all-in-one high assurance toolkit that automates the common stuff a la static analysis or reusable, composable proofs. And makes hard stuff easier for pro's.
7. Occasional thoughts on automatic programming via heuristics, patterns, rules, human-guided transforms, and so on. Got me started in advanced SW and my mind occasionally goes back to possibilities for achieving it.
8. A way to do any of that with the rapid iteration, safety, performance, live updating, and debugging properties of Genera LISP machine. I mean, we still don't have all that in mainstream tooling? ;)
The focus of my tool is creating graphical interactive software: iphone and Android apps, desktop apps, and things that run in the browser. The notation is compact, readable, and straightforward. It has many innovative aspects: new data structures, physical units (something FORTRAN just got after 30 years in the in-basket), and deductive reasoning which dramatically reduces the length of programs. It is not a design by graphics system, but a language. It isn't that abstract, and is far more straightforward than Haskell or PROLOG. It is not a LISP derivative.
Agent-oriented programming lives on today in a new form. Just dawned on me as I saw your post. :)
1) well, in the traditional Telescript sense. I am a bit interested for load balancing and redundancy.
https://bitbucket.org/djarvis/rxm/
https://bitbucket.org/djarvis/rxm/wiki/Discussion
Currently generates SQL code from a DSL, which can be run against a database to produce an XML document.
I'm working on Animation CPU platform, ACPUL declarative algorithmic language for same purposes.
https://www.youtube.com/watch?v=ubNfWarTawI
Also LiveComment information tool:
Still haven't found a syntax I like yet. Yorgey and Classen both have nice Haskell libraries as a springboard.
- Have a summary what future-programming.org is about on the homepage?
- Help to complete this table: https://docs.google.com/spreadsheets/d/1JJ14iwi-UU4Zw2dc9XHY... (Use the "comment only" dropdown button to request edit access)
- Create a Wiki organizing the information from this thread?
I also don't think you can simply graft supercomputing onto mainstream (i.e. Algol-descended) languages and expect to keep all your cores equally busy. You might get away with some SIMD parallelism, but MIMD parallelism, and quantum computing, require completely different approaches, and completely different programming mindsets.
Previously we'd developed a code exploration tool: http://codeconnect.io
http://categoricaldata.net/fql.html FQL Functorial Query Languages
For me it is interesting that in my career, code base sizes grew to gigantic proportions -- there are many applications that are 10s of millions of lines of code. In the middle of my career I worked on a few. Interestingly, I'm doing web development now and a lot of my colleagues think that 5000 lines is unbearably big. I think the take-away here is that we have gotten slightly better at abstracting things out and using development libraries (and dare I say, frameworks).
OO was just becoming a big thing at the start of my career. Everybody did it incredibly badly. Then Kent Beck and Ward Cunningham came along and told people how to do it not-so-badly. I think the biggest thing that I saw in this time frame was the breaking of the myths of OO being about code re-use, and the movement away from huge brittle design structures. Good OO developers moved back to the really basic ideals of dealing with coupling and cohesion in design. We even started to have a language to be able to discuss design intelligently. Of course, quite a huge number of people were oblivious to this, but it always struck me how amazing it was that Beck and Cunningham were really 15 years ahead of most of the rest of us.
Lately, functional programming is coming into vogue. For the second time in my career I was surprised. People in the know are talking about idempotence, and immutable structures. This was the stuff that the crazy people were talking about in the 80's -- stuff that was "too slow", and "too memory intensive" to take seriously. But now it's pretty obvious this is the way to go.
I think the other big thing that blew me away in the last 30 years was testing. Probably some people will remember pre-conditions, post-conditions, and class invariants. This was unfortunately forgotten by most, but the most astonishing thing was unit testing. Especially the practice of Test Driven Development that not only allowed you to document your code with executable examples, but also forced you to decouple your objects/modules by the very behaviour that creates the documentation. Very few people do this well (just like most of the other things I've mentioned), but it is completely game changing.
As for the future, what is coming up? I suggest you look at what has gone before you for hints to that. In the last 30 years, apart from TDD (which came completely out of the blue as far as I could tell), the major advancements came from stuff we already knew about. It was the stuff that the "crazy" people advocated in the 70's and 80's, but that seemed impractical. If I were to guess, I suspect that we will see further progress on decoupling in design. Immutable data structures will not just be common, they will be how ever professional designs code. As performance moves from single processing to multi-processing, this will be important. Look at innovative ways of processing like flow based processing and other crazy ideas from bygone years.
My last piece of advice: Don't look for large revolutionary changes. I think those are unlikely. The programmer of 30 years from now will probably still be doing the same job as I am today. The changes will be much more qualitative. Also, expect that the vast majority of programmers will be as oblivious to the advancements as most programmers are today.
RE: People/Groups who are researching 'new approaches to programming' - you have the typical universities putting out papers. Conferences like POPL and ICFP tend to be where most of the major academic work gets put out. From within the industry, commercial entities aren't really doing much, bar Microsoft Research, Cambridge (UK, not MA). They're really pushing the envelope with regards to strict PL research. www.rise4fun.com to see the dozens of projects they're putting out. Oracle, too, is surprisingly doing some interesting work.
30 years is a hard guess, but 5 years you'll certainly see: 1) a lot more emphasis on concurrency, at 14nm we're rapidly approaching the physical limitation of transistor density (which is why you're seeing 18 core Xeons). Sharing memory is notoriously hard, so the move towards immutability (whether it's pass by ref const in 'traditional' languages like C++ or more esoteric languages like Haskell, that's the direction it's going in, whether by using the actor model, STM, etc) 2) Especially with Intel's Knight's Landing. RDMA has been around for ages, but bringing it to Xeon means the common-man doesn't have to pay Infiniband prices for HBAs. RAM has been getting cheaper but imagine being able to just deck out a 42u filled to the brim with ~18 2u's of half a TB of DDR4 RDIMM a piece that your main application can access. 3) Disks, which used to be a huge thrashing bottleneck (who here is old enough to remember thrashing on GCC 2.95 when trying to compile E17?), are now posting amazing numbers, even for SSDs.
Effectively every level of computing that used to be a barrier (minus SRAM and the CPU caches which seem to have been stuck at the same spot for a while in terms of capacity) has, or will within 6 months be consumer accessible. I couldn't guess what's going to happen in 5 years. I can't even guess what's going to happen in 5 months and I've been at this nearly 20 years.
What is more interesting is your points towards hardware limitations, and that seems like more of an area in which such a question would have meaning. I tend to think less about what we will code, and more about where that code will run, and how low/high level it will be -- Will we still be coding to browsers in 30 years? Will firmware still be a black box for most people, or will your average joe start to play in that realm? Will coding be a specialty, or will it be as pervasive as knowing how to read and write? If everyone on the planet could at least code to a basic level, and all devices had at least a minimal API to configure, what will that even look like? Will Legos have embedded code, so 4 year olds can assemble blocks and do robotics instead of just static toys?
I have no idea on any of those answers... but those are examples of the kinds of questions we should be looking at, not whether React or Angular will have more longevity, because frankly, in 30 years, very little of what we are doing today is going to have any relevance.
That's where you lost me. ;)
(It's sort of like a physicist claiming force, mass and momentum to be the hottest new research areas for the coming 30 years...)
sounds like you think pretty highly of Rails, Angular and React.
There are maybe tons more but each of these did have a massive impact in their respective communities.
