Eve: the dev diary of a programming environment aimed at non-programmers
lambda-the-ultimate.org
lambda-the-ultimate.org
> Eve is our way of bringing the power of computation to everyone, not by making everyone a programmer but by finding a better way for us to interact with computers.
The more I try to teach programming to non-programmers, the less I understand the notion of what "programming for non-programmers" really means...in the same way that "writing, but for people who can't write" is a bizarre concept.
Programming, and the notion that code is an explicit way to communicate with a computer, isn't just an inconvenient technical detail that prevents amateurs from reaching their full computational power...it is a true way of thinking, and to not be able to do it limits you in the same way that being illiterate prevents you from creating the next American Great Novel.
I've always believed that understanding a for-loop and if-statement are all you need to really wield the benefits of computation...but I've found that I constantly underestimate what an epiphany is to actually grok those concepts. It's not just the ability to abstract a routine, but the concept of a block of stored instructions and variables that is, as far as I can tell, pretty much alien to anyone who is not a programmer. Or a mathematician.
I'm not saying that efforts like Eve should stop, or that they can't be significantly helpful in bringing greater understanding to non-programmers...I'm just saying its stated goal is incoherent and inherently unattainable, like trying to build a scientific framework aimed at people who refuse to learn math.
[1] http://www.chris-granger.com/2014/10/01/beyond-light-table/
Environments like Excel aren't powerful because they make programming fundamentally easier, but exactly because they don't require you to put yourself through the process of trying to grok for loops and if statements, patiently waiting for an epiphany to come, before you can do anything useful. It's just a nicer route to the programmer way of thinking.
"Programming for non-programmers" just means reducing the set of concepts and thinking processes you have to absorb before you can do something useful – just like Excel does. The Eve guys may or may not achieve that, but I definitely think it's a worthwhile goal to have.
Again, I don't want to be too harsh on what the OP excerpts as I'm not sure if Eve's ultimate intent is to just make programming more accessible to non-programmers...but from how I interpret the original announcement, Eve is pushing the notion that the hard computational problems can be approached by anyone, if it weren't for that programming hurdle:
> Imagine a world where everyone has access to computation without having to become a professional programmer - where a scientist doesn’t have to rely on the one person in the lab who knows python, where a child could come up with an idea for a game and build it in a couple of weekends, where your computer can help you organize and plan your wedding/vacation/business. A world where programmers could focus on solving the hard problems without being weighed down by the plumbing. That is the world we want to live in. That is the world we want to help create with Eve.
http://www.chris-granger.com/2014/10/01/beyond-light-table/
For starters, some of that is already realizable. Does anyone doubt that GameMaker is a legit platform after the success of Spelunky? I haven't used it but I've heard it billed sometimes as a way to make games without coding. However...AFAIK, Spelunky and other big hits were most definitely not constructed solely through a drag-and-drop editor. In other words, making something truly fun and unique requires programming, because programming is as explicit a medium for us to communicate our commands and creativity to a machine.
To refer back to the Eve announcement, to that scientist who has to rely on the sole Pythonista to get some kind of task done...why shouldn't the ambition be that that scientist learns some Python? Why is programming seen as some dirty work relegated to the lab nerd with an obsessive interest in closures and indentation, instead of being integral to the scientific process?
To use another analogy, in the world of journalism, it is possible to be a fantastic reporter -- the kind who knows how to seek stories, sources, ask the tough questions, understand the important issues, etc. -- and be a horrible, horrible writer. And vice versa. And yet it would be unheard of to hire a great investigative journalist who was functionally illiterate...it's not as if that journalist couldn't just focus on the reporting and then dictate his findings to a writer. But besides the inefficiency of hiring two people just to get a story in written form...there is something most definitely lost when the reporter/observer of facts and events is not the same person who is structuring the narrative and arrangement of facts and events. If you've ever been heavily edited, you know what I mean.
And to address the example of "A world where programmers could focus on solving the hard problems without being weighed down by the plumbing"...maybe I'm just very narrowminded and have turned into the prototypical code-nerd...but it's hard to think of many hard software engineering problems that didn't involve plumbing. The reality of programming is that it almost always deals with very mundane, boring, pedantic work...but isn't that the point? That the programmer's main worth is to be able to succinctly and efficiently translate and delegate that work to a machine, so that the programmer (and the rest of society) can move on to more complex things?
Because to many, programming is a industrial process that is kept deliberately obscure and obtuse by programmers who fear the loss of their power. Not as something that has a certain inherent amount of complexity to it. It's the same as people who hate doctors because they believe medicine is 99% fancy vocabulary.
To many such people, programs should be as simple as they look. So should everything else in life. I can only assume they have never looked under the hood of a car.
Or, given the studies of actual excel use, before you can do something that appears useful but produces incorrect results.
The hard part of programming isn't learning languages and tools, its learning the technology-independent processes that allow you to correctly address needs and verify that they are correctly addressed.
Projects that aim to make programming accessible that aren't focused on that end, but are only focused on revising (even if radically) the way in which we interact with code aren't going to make successful programming more accessible (and, anyway, most of the time, what they end up doing is creating tools that, at best, end up being used by programmers, not non-programmers.)
Instead of asking how to make programming more accessible, why not ask... What would an evolved Excel look like?
Take cell-based formulas for example. For all their benefits, there are a few obvious issues with cell formulas in Excel.
First, it's not always obvious where they are. You can have formulas all over an Excel spreadsheet and it's not easy to tell at a glance where they are, so you don't know what parts of your spreadsheets are static and which parts are dynamic.
Second, formulas can become unwieldy very quickly. Whilst Excel formulas are very Lisp-like, the lack of user-defined functions within Excel (you can do it other ways) means you often have large nested functions or resort to suboptimal methods like storing intermediate steps of a calculation in other cells to keep the formulas manageable. The language constructs aren't designed to enable semantically-rich yet succinct formulas, though occasionally there are useful tricks to extend beyond what is immediately obvious (such as the ways SUMPRODUCT has been twisted beyond its original purpose). You want to encourage elegant creativity, rather than relying on arcane tricks.
Lastly, plenty of scope to improve performance.
All three of these issues above are very much solvable, would allow non-professional-programmers a far nicer tool to work with, whilst unlocking more of their creativity and the potential of the machines they're using. Seems like it would also be a reasonable base for further research into improving the accessibility of programming, as you could learn which concepts stick in people's heads and which ones don't.
Reminds me of Book from the Ground[1], a novel written entirely in pictograms. The intent is to write a story that any person - even someone who's illiterate - can read. I should mention that it can really only be made legible to sighted people, which is a shortcoming it shares with many attempts to create programming languages for non-programmers. That said it's remarkably successful. But the story is extremely simple, a side effect of the author's choice to use a form of expression that cuts expressivity to the bone. As an exploration and mental exercise it's fascinating. But I don't think it heralds a major change in how we communicate nowadays, even across language boundaries.
[1] http://asiasociety.org/blog/asia/always-pioneer-artist-xu-bi...
Plenty of others like thumbs up sign are culturally dependent. EX: You see someone doing a thumbs up, but their biting the thumb what does that mean?
PS: It's still an interesting exercise IMO because people recognize a much wider symbolic language than they generally think about.
Start with not discussing computers having a mind. The metaphor that I've usually seen working well with neophytes is variables (or memory locations, depending on context)-as-boxes, and assignment and mutation as putting something in the box or doing something to whatever is in the box, respectively.
"Mind" is a fuzzy concept that lacks the concreteness of boxes, and makes a poor (in utility terms) metaphor for program state (no matter that it might actually be reasonably analogous -- most people don't have a good concrete intuition about the operation of minds to make it a useful metaphor.)
You can even make it physical: http://aturingmachine.com/
I feel the same way about text-based programmers who refuse to wrap their heads around flow-based programming using graphical interfaces depicting control networks.
I don't think the hard part about conventional programming is understanding branches and loops, or even things like pointers and trees. It's the uncertainty about how to structure a program (which is like the difference between being able to write an answer to a question and being able to compose a long essay) and how get familiar with library functions - it's not obvious to someone new to programming sitting in an editor what things they can do, and a great deal of documentation written by programmers is appalling - a cardinal sin among developers is a poor ability to articulate what tools are for and how they can be used. It's like handing some kid a box of paints and brushes but refusing to tell them anything about picture composition, color theory, or brush technique.
Another part of the problem is many developers' veneration of syntax. There is nothing worthy about making people do lots of typing, both the hitting-keys-on-the-keyboard kind and the using-the-right-sort-of-variable kind. OK, it is worthwhile to understand the basics of char, string, int, and float, but that's all that most people need to know. Faffing about with extended types and understanding the way the CPU works isn't important for most people. Kernel and other low-level programmers, sure, but most people want to solve an external problem, not become expert on the insides of their computer - just as most people want to drive cars rather than be mechanics, most people want to drill holes rather than become experts in brushless motors and tool manufacture, and most programmers want to talk about relatively high level concepts rather the messy business of transistors and voltages and digital circuits (witness the slightly panicked tone of any discussion on FPGAs where people say that HDLs like Verilog are scary hard).
It's bizarre to me that people are still getting up every day and worrying about whitespace, semicolons, and matching braces. In general this stuff is a complete waste of time; it can be automated away, so why do we expect people to do all this typing other than because that was what we had to do when we learned to program? When I was young, the only way to study computers in college in my country was to do an electrical engineering degree. This wasn't that attractive to me because while I do sort of enjoy breadboarding and building analog circuits, I was a lot less interested in learning about the internals of power supplies and so on than I was in constructing text adventure games or fiddling with sprites or browsing the source code for Rogue. Many developers today are making the same mistake, saying that if you want to play with computers you need to learn a bunch of language-specific stuff which must be typed out with a keyboard, yea, as has been the tradition on the hallowed command line of thy god, UNIX...
...let's get real. You don't become an architect by spending years learning to lay bricks, install plumbing, and hang drywall until finally the secrets of the holy blueprints are revealed. Rather, you study a mix of things from structural engineering to the properties of different materials to aesthetic theories to economics. You could be first in your class at architecture without necessarily being especially skilled in construction. It seems to me that you're arguing for programming to be more like (mythical) freemasonry, but that;'s a good way to get sidelined as more and more people demand software development tools for more utilitarian ends.
I'm not saying that a detailed grasp of these low-level concepts lacks value. Of course it has value. I have a soft spot for hand-rolling things inn assembler. But you shouldn't have to come to it through a text-based paradigm, any more than children should be required to study injection-molding and styrene monomers before being allowed to make things out of Lego.
Ahh, you need more than that. Understanding the principles of abstraction is also key. The ability to capture functionality into a black box and give it a descriptive name so that it can be treated as an indivisible unit is critical to this task of communication with computers (and other humans).
At first we had analysts writing the scripts to program the system, and that worked OK for a few years, but it didn't scale with the workload of requests and we had to divide the labor into business analysts and developers. Today it is a department full of developers writing thousands of scripts in a proprietary language with no package/module system and only global variables, so there is lots of copying and pasting but no real code reuse. There is also no syntax highlighting, code completion, debugger, automated test harness, or deployment scripts. They do everything manually. And of course no "real" trained software developer wants to touch the whole mess with a ten-foot pole, so it stays that way.
After experiencing the horrors of such a system I say leave the programming to real programmers, or become a real programmer yourself. If you try to bring programming to non-programmers, you will never be able to pay down the technical debt they rack up.
I'm not in the "it's a talent and you either have it or don't" camp, but I do absolutely believe the core skills of any programming task are in problem breakdown and solution visualization. The best environments serve those two purposes specifically, and preferably as transparently as possible. Environments which end up with a rigid expression in the service of accessibility usually end up counterproductive very quickly because they don't generalize enough. There's a fine line between "opinionated" and "obstinate."
subroutines, subroutines, subroutines!
Scripting languages, mouse-operated visual operating systems; we have been there before and taking away the micromanagement of the development process has been a good thing. And while the challenge back then was to abstract away the processor, now the goal is abstract away web technology stacks, having to learn at least 3 different languages to build the most simple web app, and so on.
An even more interesting question which is implied in this proposal is whether non-imperative languages can be made easier to learn by being closer to the way the brain works.
There are any evidence that no programmers need/want to program ?
Some of you will say that Excel is programming and it is used every day. Fair enough, but excel is suppose to be extremely narrow in scope, definitely not as big as Eve, and honestly the vast majority of people do not use it to program, they use it as extremely smart database... A crucial different from a programming language/environment...
Ironically, it's not particularly accessible or simple. It's certainly more complicated than 80s-style BASIC.
And the number of VBA users compared to the number of Office users is not huge.
Even so - VBA proves that if you make a development tool accessible enough and obviously useful enough at least some non-programmers will start writing code for it.
The challenge for something like Eve is usefulness. What's the user benefit? To date I'm not seeing one - which doesn't mean there isn't one, just that so far it's not obvious to me.
I can certainly understand a vision that makes technology of all kinds far more accessible and responsive. But asking users to make their own code probably isn't the answer there - I think it's more likely to be some kind of contextual inference/AI/NLP system that's smart enough to make good guesses about what users want and handles the low level stuff for them.
Fast forward to today and I am writing scripts and building apps in ruby, python, JS, Java, Clojure and Haskell.
Isn't it incredible that VBA is still around (and probably unchanged since the late 90's). Bummer that MS has let Access stagnate for the past decade.