Ask HN: Which people and groups are researching new approaches to programming?
Which people and groups are researching new approaches to programming?
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.
122 comments
[ 2.7 ms ] story [ 156 ms ] threadRE: 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.
* 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/
https://en.wikipedia.org/wiki/Probabilistic_programming_lang...
Formal verification using ACL2 or Coq or other tools also.
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
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/
http://vpri.org/index.html
...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?"
http://kayia.org
* 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.
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?
I've heard about the BNF notation with the recent news about Peter Naur death and before but never took to time to get my head around.
I think your description of Datafun and the references you gave me are good and enough to make me learn something new and to understand your project.
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.
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/
Not exactly trying to question whether it's a good/bad thing (as I'm aware that for many creators this might be exactly what they need), just trying to understand.
What might well be very hard is making a language where all abstractions and interfaces map to useful graphical representations; I imagine it's much, much easier to represent a JSON object graphically than it is to represent a piece of C code this way.
For instance, how would jumps look? Lines going from far-removed boxes, producing code that literally looks like spaghetti? Moreso, do you even want to graphically represent things like pointer arithmetic, will this be easier to work with? How do you represent variables, globals?
Maybe you would only represent course features such as data flow graphically, and hide finer grained details and code in "blocks" with labels and defined in- and outputs. You would still mostly write your code, but the graphical view might help you mentally model your program.
I wouldn't want to do general purpose programming in them -- at least as they exist currently.
Different general-purpose languages are better adapted to different programming tasks, however, and Full Metal Jacket may in time find its niche. I wouldn't write a neural network in Prolog, or an expert system in C, for example.
At present, FMJ is interpreted and runs on a virtual dataflow machine. This was a necessary step to ensure the computation model was implemented accurately. Compilation to run on a single processor would actually be simplified, however: there's no parsing or dataflow analysis required. Looking into the future, the question that should really be asked is whether languages designed to run on a single processor, or to execute the same instructions in parallel (SIMD), can be easily adapted to run on MIMD architectures. Do you really want to be using MPI?
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.
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.."
e.g. http://arxiv.org/abs/1507.00996
Really, its how GLSL and other shader languages work already, just hidden behind C-like syntax and lies.
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.
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.
[1] http://lara.epfl.ch/w/
https://gist.github.com/clumma/58253f3692e4c1c28087
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.
Might have been different if Cyc or OpenMind had achieved anything. They could be the reference point for autonomous, mobile agents using knowledge-based programming. Best just to create more high-level languages, good libraries, and ways to package them up. It's not just good enough: it's more predictable and reliable than agent or expert systems even on their intended use-cases. Funny how that worked out, eh?
The applications and stuff that goes into containers has to be written in some language, and I think an agent oriented language might be more suitable for large programs than what we currently have. I really don't think they are better, just more in line with what we have now.
As I said, I'm not really interested in the expert system aspect (AI). I'm looking at this as a language issue to build big systems. I think containers are not a language answer but a coping mechanism for current languages and practices. I've been doing research on a different path. I hope others are looking beyond what we have now and what paths history didn't take because C and UNIX won.
To me, it's just a VM (or source), ability to capture state, and one or more function calls. Any language could do this.
Obliq just in case you didn't know about it:
https://en.wikipedia.org/wiki/Obliq
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.
I learnt it before Prolog, and personally really like it, much more than I do SQL. It's a slightly different mindset - "what is a result" rather than "how do I go about finding a result" - but one that I found more intuitive in an Intro to DB course.