[danso]

> In order to accomplish that, we do need a way to describe processes. We need a way to "program." But switching the goal from building applications to analyzing and communicating information changes everything. Our current programming tools are awful thinking tools. Instead, they were designed to build complex systems. How much effort does it take to write a program to scan through your facebook friends and check to see if someone who usually isn't in your area currently is?...People aren't really tring to build the next Facebook, they're trying to use the information from it in a different way.

The example given here by the OP strikes me as a good example of how and why programming is complicated, and what people generally want their programs to do is unlikely to be doable without knowing how to program.

Case in point: why can't a layperson just make a little app "to scan through your facebook friends and check to see if someone who usually isn't in your area currently is"? The ease, glib answer is: well, Facebook's developer API requires several hoops to jump through, including OAuth of clients and so forth. So that's why there's no drag-and-drop-plug-and-play module system for such a feature.

The bigger answer is the answer to the question of why does Facebook's API have to be so complicated? Well, besides business reasons...FB's API is a public-facing abstraction over a system in which a billion people have agreed to (semi-)authenticate themselves and communicate a variety of real-time things about themselves. As annoying as it is to program your own little FB apps...it's complicated because the system it interfaces with is overwhelmingly and amazingly complicated.

I don't see much room for improvement in making programming easier in this regard. It'd be like making Shakespeare more digestible to people who don't want to learn to read (OK, ignoring oral storytelling, for this limited analogy)

[toby]

Agree -- if Facebook had an "export my friend list to Excel" button, then plenty of non-programmers could perform this task using existing tools.

I read the tutorial and I am sort of struggling to see what benefit this would give someone who was already an Excel power-user.

[jamii]

> If Facebook had an "export my friend list to Excel" button, then plenty of non-programmers could perform this task using existing tools.

The task was to send alerts whenever a friend was nearby. Excel is amazing for non-professional programmers, but it doesn't deal well with changing data, unless you want to click the "export my friend list to Excel" button every five minutes. There are tools that will act as real-time data sources in Excel but it's not a natural fit. If we did nothing but make "real-time Excel" it would still be incredibly useful for a lot of people.

[infinite8s]

Have you seen the work on Gneiss (http://www.cs.cmu.edu/~shihpinc/gneiss.html) on user programmable spreadsheets?

[crisnoble]

An excel power-user is indistinguishable from a programmer. If you are an excel power-user, and don't think you are a programmer, learn javascript, http://eloquentjavascript.net/.

[dang]

I've known many Excel power users who are technically minded and experts in their domains, but nevertheless are not programmers. (Edit: obviously they're programmers in the sense that they make the computer compute things, but not via a general-purpose language.) They have no interest in learning Python or JavaScript or even VBA—it doesn't fit with how they like to think. Instead, they lay out complex calculations in Excel using long chains of intermediate columns (zeros and ones and COUNTIF, anyone?).

[eximius]

Sounds like Functional Programming might make a lot of sense to them (operating on transformations and whatnot)

[dang]

There are definitely some symmetries there, but also differences. These users don't think so abstractly. They get their computation working on one set of numbers and then, if they need to reuse it, copy-paste and modify.

[crisnoble]

The only thing a super complex formula is missing is the notion of a for loop. In lieu of that, I used to pull a column down as many times as the loop needed to run. Then I discovered macros, then I discovered javascript.

[dang]

Some spreadsheet users discover programming and take to it, which is great. Others have the opposite reaction—writing scripts doesn't fit how they like to think or work. It sounds like you are the first kind of user; the ones I was thinking of are the latter.

[mistermann]

> Then I discovered macros, then I discovered javascript.

Is the javascript comment somehow related to Excel, or had you moved beyond Excel at that point?

[crisnoble]

I have move beyond Excel, and now I am a web developer. I still have a special place in my heart for overly complex spreadsheets.

[ModernMech]

Excel is a very powerful tool, but it reaches a utility plateau very quickly when you start going outside its intended purpose of being a spreadsheet application. You're correct that a power-user can do pretty much anything in Excel, but when you start talking about actual database operations (like Join), state, and UI, then you're at the point where the tool is working against you.

[JBiserkov]

I'm not sure what you mean by state and UI, but Excel definitely has a join-like functionality in the form of vlookup function.

https://support.office.com/en-in/article/VLOOKUP-function-0b...

[mistermann]

Now try doing a VLookup using more than one column.

Artificial limitations like this are one reason people rightfully hate Microsoft.

[tycho01]

The so-so way: use MATCH in one column to get the row numbers, INDEX in one column for each column you want to pull in to actually grab them using that row number. Alternative: join the tables using Power Query so you could have it refresh and give you the combined version even after adding more columns.

I mean, point taken, but in case you were wondering, then yeah. VBA also does SQL operations on Excel tables, but that's, well, worse.

[mistermann]

> VBA also does SQL operations on Excel tables, but that's, well, worse.

Are you sure about that? Afaik it doesn't but I may be mistaken.

[toby]

This is totally true, of course... I just think that exploring examples that would be really hard with Excel would make the point better.

[MrDosu]

I would argue that an API is easier to learn by several factors regardless of how complex it is compared to the abstract reasoning and modelling skills to actually transform the faced problems into a precise model.

[cmontella]

I respectfully disagree. People who are not programmers use abstract reasoning and modelling skills all the time in their daily lives. They more than have the skills to solve this problem: You have a list of friends and where they are, you have your own location. Find the list of friends that are near your location, and send an alert (text, e-mail, whatever). How hard is that?

There is absolutely no inherent complexity to this problem.

[Too]

I frequently use software specifications as a counter argument to this. Non developers can't write specifications without leaving out major key bits in the information, my point then would be that since they are not constrained by limitations of programming language but only their own expressions in written text that should not be a limiting factor.

Your example is extremely simple and could work for a new coder but once things get just slightly more complicated things get messy. I can already find exceptions in your very simple example: how exactly are user supposed to be alerted? Do all users have a mobile number so they can be texted? If not do you try email? What if they are online, do you send an im-message? Should you send to all available addresses? In which order do you prioritize message if you only send to the first available destination, email first or sms first?

[athenot]

This can be solved by having sensible defaults. So instead of having to specify everything, there's a baseline behavior. Most may be acceptable, some is not. Fine, then the user can change what needs to be changed.

The most important part is that the user is not spec'ing in the dark, instead they are modifying existing behavior to suit what they want.

[discreteevent]

The spec is a bit more complex than that. It's not "Friends who are in your location" but "Friends who are not usually in your location but are now" (prodigal sons?)

[MrDosu]

This is just not true.

You cannot just give a smart person with common sense some pages of API docu and suddenly they are software architects. This takes years of experience to do. What you can do is be a code monkey and solve a very specific small problem space that an architect has assigned to you.

[cperkins]

You are supporting cmontellas point, not negating it.

His point is that the inherent complexity of the problem is fairly trivial, and he stated it concisely. And you are correctly pointing out that to realize the solution to the problem requires a great amount of work and expertise. Meaning, the actual programming has a great deal of additional (accidental) complexity.

[dorgo]

Maybe some non-programmers manage to solve the problem itself. But only a tiny part of them will be able to write down what they actually did (step by step) in a precise way suiteable to tranlate it into a computer program.