1. 23
  1.  

  2. 5

    One can imagine a dark dystopic future where Google and other API providers pay money to have their featured microservice APIs shilled in the editor. “Would you like to find every point in Jefferson County? Try using this Google Maps™ invocation”.

    I’m not sure how bad that would be, honestly.

    EDIT: Fix speeeling. :X

    1. 2

      What scares you about it (if anything; I don’t want to assume)?

      1. 6

        Am not sure “scares” is the right verb. More like “fills me with unspecified regret and gloom”.

        On the one hand, I think that long-term the real wins in programming and software engineering are going to be in declarative languages where you specify a problem, specify the constraints, and then something backsolves and samples and montecarlos until it has an AST that can compile to roughly what you want. I don’t know how much work is being done in this direction, though a lot of the typing theory and inference and stuff seems to be waggling its eyebrows suggestively in that direction.

        On the other hand, the intermediate term wins in software engineering (as distinct from programming) are almost certainly going to be us standardizing on a common set of idioms and services that perform the same functions over and over and that are managed/hosted by other people. Due to the scale involved and the increasing reliance on handwavy ML and mass data collection, this is almost certainly going to be out of the reach of small businesses to offer and instead will be a handful of big folks like Google, Facebook, Microsoft, Apple, Valve, Amazon, and whoever else has the ops experience to run a big fleet and to harvest the data of users to train their algorithms.

        On the gripping hand…on the gripping hand I think there is something lost in the transition away from a single developer talking with their machine to solve problems. I think there is something fragile about having to depend on ever-deeper layers of other people’s stacks. I think that the profession is going to be a lot less fun; then again, maybe that’s what it’ll finally take for it to be a profession.

        1. 4

          the intermediate term wins in software engineering […] are almost certainly going to be us standardizing on a common set of idioms and services that perform the same functions over and over and that are managed/hosted by other people.

          I believe the industry is essentially there in all aspects (spirit, desire, and direction) except for perhaps literal execution. Most “software engineering” that I have done professionally–and most of my friends whom are SE’s, but not necessarily in my domain–all lament that 90% of “software engineering” is piecing together the API’s and libraries that are already out there and getting them to work, and very the remaining 10% is bludgeoning the result into something that solves a current business need. The novel algorithmic discoveries are left to Academia.

          Yes, some shops will use Java, others C, and yet others still Python or Ruby, but they are all sharing the same idioms (design patterns, underlying data structures, etc) and differ not in their underlying functions. I don’t necessarily see this as a negative, though.

          Due to the scale involved and the increasing reliance on handwavy ML and mass data collection, this is almost certainly going to be out of the reach of small businesses to offer and instead will be a handful of big folks like Google, Facebook, Microsoft, Apple, Valve, Amazon, and whoever else has the ops experience to run a big fleet and to harvest the data of users to train their algorithms.

          I think this is the most unfortunate aspect of the whole ordeal (if I can even call it that). Realistically, this is the same process that any other market that have consolidated goes through. Competitors and new entrants shrink as truly novel and “disruptive” (ugh, I do hate that word) ideas are all exploited by existing firms, until only a few remain and a thin veneer of competition exist among them (c.f. the auto industry).

          However, I will maintain that this will happen with, or without, such tools as shown in the article itself. And I find this particular approach to the problem very novel and refreshing, and I welcome it wholeheartedly (in fact, it’s inspired me to build something similar for Elixir!)

          On the gripping hand

          I have never seen this phrase used before to refer to a third auxiliary point before; I like it :)!

          I think that the profession is going to be a lot less fun; then again, maybe that’s what it’ll finally take for it to be a profession.

          That’s perhaps true–Plumbing, Car mechanics, Civil Construction, are all “professions” in the sense that there are very little cow-boy'ing around, and perhaps Software will asymptotically inch ever closer to that group, though I doubt it will ever get there to the same degree and concreteness as something that has a physical manifestation and can be regulated part by literal part.

          That said, this is the progress of all industries that I can think of (and of most social endeavours in general). You have the pioneers, then the settlers, and eventually the civil developers (in broad strokes), and at each stage, the amount of “cow-boy'ing” (or “fun”, depending on your perspective) shrinks.

          1. 3

            I have never seen this phrase used before to refer to a third auxiliary point before; I like it :)!

            I cannot take credit–it’s from old science fiction.

            1. 2

              The Gripping Hand is a sequel to The Mote in God’s Eye. Both books are really good.

          2. 3

            Heh. Well said.

            Those are all things I’ve thought about as well, and I have nothing worth adding, since indeed it’s all wait-and-see. Thanks.

      2. 5

        Check out the literature for “program synthesis” for lots of interesting work related to this kind of problem. A recent example I thought was nifty is myth which synthesizes ML programs. MS Research have actually done some interesting work on this, for example check out prose which shows some applications beyond synthesizing functions for programmers (which often feels far-fetched) and shows how you might want this kind of example-driven thing as part of a UI.

        1. 4

          Hey $COLLEAGUE, is there any function that takes this list and returns a list like this?

          I don’t think I’ve ever personally heard or asked anything like this question before.

          I’m not saying it’s not a valid question necessarily, but typically in software engineering, I find that the question is normally going from a high-level description of a process (e.g. process a shopping cart for checkout) and asking “how do I break this down into more concrete instructions that a machine can do?” (e.g. take the sum of each item price, compute the sales tax as X percentage of that sum, etc.) At that point, maybe it’s useful to have the computer figure out given an example that it should use addition for the subtotal? Though I think a human is likely well-enough equipped to do so her/himself.

          Can anyone give a better example than the ones provided in this write-up?

          1. 3

            Since this is integrated in emacs, how about “Hey editor, make me a keyboard macro that has the same effect as these changes I just made”?

            1. 3

              As a way of matching inputs and outputs with possible functions, this is a neat way to learn elisp experimentally. Calling it “Example Driven Development” is really overselling it IMHO.

              1. 1

                “I have a List of Options but want an Option of a List” is a common problem when doing functional programming. I get asked for these functions very often.

              2. 0

                I’ve included a few impure functions that read the filesystem, as they’re safe.

                So which function that reads the filesystem do I need to pass (list 1 2 3) to to get 6 as the return value??