in the virtual world of computers,
everything can be replicated, from complex
physical phenomena to abstract ideas,
and even your own mind.
Does not understand computers well enough to be lecturing the world about the need for software "literacy". The assertion that computers can represent any of those things is a complete falsehood.
Computers are great with complex mathematical models of physical phenomena, and in some limited cases this is extremely useful. But smart engineers know the limits of their tools, and computer models are not an exception.
But to assert that abstract ideas or the human mind can be replicated in a computer only shows that the author either has no idea of the actual state of the art, and/or has no idea of what he means when he says this is possible.
One of the first things you learn in Computer Science is that not all problems can be solved with a computer. It's amazing that people so enamored with math that they want to believe they can model every phenomenon in the universe with a computer apparently disbelieve the math that proves computers can't correctly model everything.
Weird. Please don't try to teach the world that computers can do everything. They can't. And that should be lesson one in any plan to increase software literacy. Starting, apparently, with its advocates.
I remember a draft of the manifesto that had indeed way more classifiers in it. I guess removing almost all of them for better readability was maybe not the best idea.
DecoPerson and noxToken are right about this being a general statement about computing and not present day technology. Whether or not the human brain can be completely simulated by a machine is still an unanswered question but nothing I came across so far convinced me that it's not possible.
While it's true that not all mathematical problems can be solved algorithmically, that doesn't limit at all the kind of things a computer can simulate. Most physical phenomena don't have a mathematically precise answer and approximations are usually good enough. I hope I understood you correctly there.
If you say "computers can't correctly model everything" then I probably disagree with your definition of a "model". In my understanding of the word the concept of correctness doesn't even make sense. I'm convinced that models should be first and foremost be judged by their "usefulness".
To make this discussion more concrete, it would be very helpful if you could provide an example of something that cannot be modeled with a computer.
Sure! Most real numbers are uncomputable, for starters. "approximations are usually good enough" is a smoke screen that assumes that it's always possible to make approximations and iteratively improve their accuracy, something which generally is only true for computable numbers!
Another example, something I've been studying recently, is the phenomenon of patterns. Patterns are very abstract, and it's not at all clear how a computer can model a pattern without resorting to some concrete instantiation of it. At best, we have blueprints, models, code, designs, and instances; these are all themselves occurrences of patterns, but they fail to embody the pattern itself.
While I've got your attention, "Cryptography also enables a high level of security." is a ridiculous line. Cryptography, by itself, is only a building block. Security is structural. Check out object capabilities: http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf
Edit: Scott Aaronson discusses limits of quantum computation in this talk: http://www.scottaaronson.com/blog/?p=2903 Basically it is totally possible that minds cannot be simulated by computers without destroying the mind in question!
I must admit that I have only very limited understanding of numeric and cryptography. But I do find these very interesting discussion points.
The uncomputable real numbers are the irrational ones, no? But those you can compute to an arbitrary precision. It's just for most applications, you don't need much precision. But again, I've not done very much simulation so I might miss something.
Patterns are something I haven't thought about in this context. I'm not entirely sure what kind of patterns you're talking about. I'm guessing software patterns. I was thinking about abstract patterns and had to think of Deep Mind and how it learned to play Go by recognizing patterns.
I stay with my statement about security. I never said that it's sufficient. But necessary. I think a cryptography-enabled capability-based security model could be very interesting.
Will definitely read Aaronson's talk. That's a very interesting subject.
I want to "increase the number of people who are able to write, modify, combine and share software by building a tool that makes writing software easy and fun, and accessible to everyone." I even have a slogan. I call it "Enabling Software Literacy"
That said, I'm highly skeptical towards the "good ideas can be stated in a sentence" heuristic.
> Whether or not the human brain can be completely simulated by a machine is still an unanswered question but nothing I came across so far convinced me that it's not possible.
It may or may not change your mind, but it will bring up some interesting concepts and other meanderings that will keep you thinking about things.
Let me put it this way: Before I read it, your words above echoed my ideas. Interestingly, they still do. That said, after I read the book, there are certain nagging issues deep in the recesses of mathematics where few have dared to delve that raise interesting questions...
That's one of my all-time favourite books so if I hadn't read it I'd be eternally thankful to you for pointing me to it =) It definitely blew my mind.
It didn't make me feel that mathematics is somehow limited though. As far as I understand Gödels theorem, all he says is that there is no such thing as a contradiction-free system of axioms a la Principia Mathematica.
But that's fine with me. I keep tons of contradicting believes in my head all the time. And I'm actually not that interested in simulating an entire brain (although that would be very exciting) but the thing I really care about is the ability to express a part of my mind that I care about in software, sort of like expert systems do. And as a software developer, that's exactly what I do everyday with the minds of my clients. That's also the main idea behind DDD in my opinion.
This topic deserves an essay. If I manage to wrap my head around it, I'll publish something on my blog this week.
I remember the long faces, when i took my programming class through the introduction of floating points to the windows calculator- and they realized that this thing makes mistakes-
(x/(9^64))*(9^64) != x
And then the dawning realization, what fights the future would hold for them...
I don't think he was talking about present day technology; rather, he was referring to abstract machines.
Whoever taught you computer science must have had a very pessimistic attitude, which is surprising to me as most of the academics I've talked with think the computers of the distant future will have no limitations.
In the preset day, though, we have limited time and must choose our battles carefully. I respect the OP for his attempts, if a little a misguided. Just ask any active member of the Linux kernel and they'll tell you how often they see such people undertake similarly bold approaches which deliver little outcome (and, hopefully, a life lesson...)
> academics I've talked with think the computers of the distant future will have no limitations.
This could mean a lot of liberal arts students. Academics aren't in any advantageous position to understand the progress of technology. Computers necessarily have limits because of their physical properties of matter and energy.
Thinking that "future = no limits = no scarcity = everyone gets everything they want even fantasy" is kind of a logical leap that most people in tech are not comfortable making. Maybe "academics" are more optimistic because they don't know anything, and it's easier to believe we'll have flying cars in the future than to realize that there will never be a time on Earth that it makes economical sense to fight gravity for an individual transport medium.
One really nice thing about academia is that "unlimited resources" are indeed a valid premise while you are in design space. It's only when you start implementing your idea that you have to face a limited universe.
But on the other, for somebody has programmed in the 60s, the computing power and memory we have nowadays probably seem "limitless" in comparison.
I don't really get how that's a critique of the ability to represent complexity on a computer well. After all, isn't a human mind constrained by P ?= NP in the same way as a computer architecture?
We do not know that actually.
While it might be true that classical mechanics is the only machine behind our brain, evolution is just as likely to have stumbled into a quantum computer design we have not yet discovered in the last billion years.
Change replicated to represented or modeled, and it's a true and useful observation. Maybe the author believes "replicated," or maybe he just didn't find the right word that day.
In any case, if I change that word as I read it, it becomes a useful observation to me. Just because I'm reading an authors words doesn't mean I have to accept those words as-is. I just got a useful thought out of an incorrect statement. :)
Perhaps there's intended subtext saying that computers have the capability to do such things, but we are unable to do such things with the current technology and knowledge. I mean, you're right. The statement shouldn't have been said without being explicit.
I dunno. I'm just trying to give benefit of the doubt.
In writing this defense of the article, I realize that such a flawed premise shouldn't exist when talking about teaching fundamentals.
>To fix this, we need to increase the currently tiny number of people who are able to write, modify, combine and share software. We need a tool that makes writing software easy and fun, and accessible to everyone. A tool that enables software literacy.
Global access to niche knowledge doesn't seem like an effective use of the world's time to me. Let's look at this same idea, but replace "develop software" with "perform brain surgery."
> To fix this, we need to increase the currently tiny number of people who are able to perform brain surgery. We need a tool that makes performing brain surgery easy and fun, and accessible to everyone. A tool that enables neurosurgical literacy.
Just like Software Engineers don't need to know how to perform neurosurgery, accountants, marketers, burger flippers, and salespeople don't need to know how to write software. I'd rather the CEO of the company I work for spend time on growing the business, not learning how to write a "Hello, world!" program.
Ok, but what makes brain surgery a good analogy? Why not replace "writing software" with "hopping on one foot" instead?
Most of us own computers that can run software, but we don't own the equipment required to do brain surgery. More people have problems that can be solved by software than can be solved by brain surgery.
I think software is more like basic arithmetic: a bit of training (plus the pen and paper you already have) and you can do something yourself that used to require a professional. Of course, software is way more powerful!
A lot of people use software, but does that really mean they need to know how to create their own?
sbov's car analogy suggestion is apt: a lot of people drive cars, but should they be expected to be able to maintain their own?
A kinda related side observation:
I found my brief stint working with Max/MSP (a visual language typically used by musicians) to be illuminating. This is a tool for non programmers (musicians in this case) to write software for their own use and it succeeds at this. Its kind of like excel for musicians. But, just like excel, the software created by these people, while functionally they work and do what the musician wants, are written in pretty terrible spaghetti code (giving visual programming a bad name in the process), because the users never learned software engineering principles (even simple ones like abstraction).
Just as with excel, this is fine for write-only once-off tools and I certainly do think that more excel-like tools that allow non-programmers to solve their own problems are necessary and will help in software literacy. However, I don't think that these tools or skills will achieve a world where most people can write and modify software in general because they won't have been trained in the software principles we take for granted. Try and debug a large non-programmer-created excel sheet sometime for example. :)
My point is that its not exactly like basic arithmetic, but as you say its not thaaat different either. Yes, some excel-like tools and a bit of training will allow more people to create their own little solutions to their day to day problems, and this is something worth striving for, but it won't be enough to let them create/modify large software in the general case. For that, they need the full blown mathematicians training (or, some of it, anyway).
> you can do something yourself that used to require a professional
I suppose THIS is what the goal is or should be. Not to make everyone a programmer, but to allow people to do more things for themselves that they previously required experts for.
I haven't used it personally but I have heard the same issues come up with LabView visual programming for laboratory automation and instrument control.
Another fault with his logic is that programming languages are very specialized and very powerful tools. You could try to dumb them down to make them work for the average person (which has been done ad nauseum at this point) but then they would no longer be capable of solving certain classes of problem either simply or quickly.
To go back to the car analogy, yes most people understand at least at a rudimentary level how modern cars function, but most people also lack the tools to do anything but the most basic of maintenance on a modern car. Even assuming they had the tools available, they still wouldn't understand how to use them or even how to diagnose certain classes of fault. We could say that in order to allow everyone to perform maintenance on their cars at home that car manufacturers aren't allowed to use anything but standard tools to build their cars, but that would basically undo the last ~30 years of advances in the auto industry. Want to own a Tesla? Oh sorry, non-standard parts, going to need to pull that off the market. The situation in the programmer world is basically the same, yeah we could make everyone program in something like BASIC (and even that is probably too complicated for most people), but that's kind of like tieing one hand behind your back and then jumping in the deep end of the pool. Programming is hard enough as is, we don't need to start introducing handicaps.
I don't like the car analogy too much since a car is basically a tool while computers are a medium.
I agree with you that programming languages on the other hand, definitely are tools.
He meant that people usually have cars that they need to run well. They just pay someone else to take care of it.
Similarly people usually have computers that they want to run programs on. They don't write them themselves though - they pay someone else to take care of it.
People don't commonly need brain surgery. It wouldn't really be a useful skill unless it is your full-time job.
Anyway I don't think you need an analogy to reason about this.
but if you were informed about how your car worked, you would know that the 200$ "break pad cleaning" recommendation your dealer was asking you to do is pure bullshit.
I disagree with your analogy. In my opinion, programming is more analogous to composition. Most courses of study require at least one composition course, because no matter what discipline you're studying, it's important that you be able to organize your thoughts and express them clearly as well as understand the formal expressions of others.
I personally experience a huge overlap between ordering my thoughts for writing and making a mental model of a problem and its programmatic solution. Yet it's easier for most people to pick up a pen or open a word processor and express themselves than it is to write a working program.
Why should it be so? Apart from implementation details of hardware platforms and runtimes, you're really talking about expression in different units: subroutines rather than paragraphs, APIs rather than outlines, user stories rather than theses.
To bring it back to your analogy, consider what a tool that lowered the barrier to entry to brain surgery might do. It might certainly do things like list the particular skills, tools, and medications required to perform certain procedures. It might provide a check list of crucial steps and a sort of troubleshooting tool. It isn't going to make an expert out of an unskilled user, and a particularly skillful surgeon might not benefit from the tool at all, but on balance, it would raise the baseline competency of many users and help ensure that certain critical requirements were met.
A good assisted programming tool would do the same. It would help the user accurately model the problem, it would advise the user of certain best practices, and it would certainly warn the user of common mistakes. This is all very much in line with a good word processor, with features like spellcheck and document templates.
So I disagree that programming is analogous to brain surgery. Programming itself is a tool for the expression of an idea and much more akin to composition, and there is no good argument in my opinion against tools to assist with either. Remember that for a large part of our history, literacy was considered a niche skill, and widespread literacy led to explosive growth of our knowledge of the world. I'm not one of those "literally everyone should learn to code" types, but there is quite a lot of potential in spreading programming literacy, even if you feel most people have no business practicing it.
Why not we (software developers) take the route of improving end-user software and letting people easily accomplish their mundane everyday tasks, instead of letting them program as a remedy to the sorry state of software? Have you looked at it that way? Would people buy a car that required them to tweak it and service it right after it went out of the showroom?
I think you misunderstood me. I'm not saying that people should become literate in programming so they can program their own solutions, although that'd obviously be good. I'm saying that we should encourage people to become literate in programming if only so they could express their needs more clearly and evaluate solutions better.
I likened programming to composition. Most people who took composition courses don't necessarily need to write papers on a daily basis, but they certainly benefit from being able to interpret and evaluate material. If I could get people to understand the general concept of a data type, I'd certainly have an easier time of communicating with them and satisfying their needs.
That's definitely an approach we should keep trying. But it hasn't worked out very well so far and I'm convinced that it's impossible to create an application that fits 100% of the needs of 100% of its users.
I would definitely buy a car that allows me and maybe even makes it easy to tweak it. But I wouldn't want one that requires me to do so.
> Apart from implementation details of hardware platforms and runtimes
The platform described to share all this knowledge and code is beyond what humanity can build today. The manifesto described that we share "All cells exist in a single, globally shared hierarchy". The trust problem has many forms, from trusted medical info on Wikipedia, Facebook fake news filtering, to open Github code with hidden backdoors.
That's an awesome list, thanks. There seem to be two concept intermingled here though.
First is decentralization which I'm a big fan of not only for social and humanitarian reason but also because I'm convinced that it's the better design. And while there are many problems still unsolved, there are also very promising approaches.
The other one is trust which is required in centralized and decentralized networks but has a very different taste in both and I think it might be actually easier so solve in an open, decentralized environment.
Lastly, I wanted to point out that while all cells exist in a single address space, that doesn't mean that every cell is accessible to everyone.
This was an insightful and thought-provoking response. Thank you for taking the time to write it. Given how much a word processor's spelling and grammar checking improves my own writing, I can definitely see how an equivalent assisted-programming tool could help people.
We have pretty good static analysis tools now which warn the user of common mistakes at the code construction level. But at the architecture and design levels I don't think there is much that tools can do short of AGI.
There is plenty a tool could do to aid software design. You might sit down to plan a new program and launch your programming assistance tool. It might ask questions like what platform your program should run on, what time or storage constraints it must run under, whether it's a server or intended for users, and so on. As you go, it creates a project scaffold for you to build on and makes recommendations: to consider .NET since you're targeting Windows, to follow this security tutorial since you'll be using a database for persistence, to use a particular pattern for the application's core responsibility, etc.
Oh, I think we could go a lot further as a society if we had more understanding of basic software and related concepts like revision control.
It hurts my head watching people sometimes, going through major contortions to achieve something just because they do not know a few commands or programming ideas. Is it “better” to develop massive, twisted dependencies on programs like Excel, when a few lines of real code would have been equivalent and infinitely more maintainable (not to mention vendor-independent)? Is it better to have massive, manually-copied-around duplicates of files because no one knows about revision control systems? Is it better to do things manually, like repetition, that computers do extraordinarily well?
Programming not only gives you the power to solve arbitrary previously-unknown problems but it puts you in the mindset to assume that an external tool will work better than an internal one. It makes you stop waiting for Your Only Vendor to “implement” feature X, and instead realize that there are already 4 other ways to do that with existing tools.
I thought long and hard about a apt analogy and decided on "literacy" because I'm hoping that using computers as a medium for formulating and exchanging ideas would have a similar effect as reading and writing had.
I can very well imagine that a couple of hundred years ago people thought that writing was some niche knowledge and it's perfectly fine to leave that to the monks.
My goal is not to make everybody a professional software engineer just like everybody should not be a professional author. But people should be able to use the medium to discover and understand powerful ideas.
"I think we're in a preliterate state with programming: it's hard for anyone to quickly look at a program listing and answer the basic sorts of comprehension questions we might test school kids on for prose.
"What we find easy is to read programs we wrote. Recently."
Nice to meet ya! I'd love to chat more at some point once the HN rush dies down, perhaps over email (address in profile). We seem to be attacking the same problem but from very different directions. I'm focusing on new methodologies rather than tools, and heading down to fix the foundations before creating empowering interfaces on top. Cross-pollination of ideas would be useful.
The typical U.S resident interacts with or otherwise has their life significantly effected by software not only every single day, but likely nearly _every single minute_.
The same is not true of brain surgery -- it's probably not even true of 'medicine' in general.
I absolutely agree with the OP that being an empowered individual in this environment absolutely requires some degree of 'computational literacy', and optimally would involve nearly every person, yes, actually knowing how to write software to some extent, the more the better.
I don't agree this is realistically going to happen though. The Hypercard future is not the road we went down. I do think this has pretty major unfortunate impacts on the degree of alienation and loss of control most people are likely to continue to experience in our highly digital society though.
But I think the best thing we can do right now is focus on some notion of accessible "computational literacy" within the present actually existing environment, not thinking we're going to get everyone to the point of being able to build actually-useful software. But they still can _understand_ software better. A hypercard-like learning environment might be useful for this. But it's unlikely to change the face of software development any time soon.
Many many people write scripts in Excel. It is easy and accessible to the majority of people who have computers today. Some accountants and quants would even call it fun.
I usually try hard not to be cynical, but in this case I can't stop myself.
This seems to be another attempt at a grand, unified packaging and IPC / linking method. There have been hundreds of these, and there is no attempt at all to discuss where all the others went wrong, and how this will improve upon them.
I would love instantly dig into any software component. I can do that with website: I can right-click on button and click "Inspect" and I'm very close to discover what code executes. Imagine the entire computing platform built this way. Few navigations and you are reading TCP/IP code. Click here and there and you are inspecting USB packet from your mouse.
Also live code update is so rare, yet so useful. Set breakpoint on that line, stop there. Add some code and it'll be executed immediately.
Java invented Javadocs, which is awesome. I can read almost 0 documentation on some simple library yet I can use it with autocomplete. JavaScript isn't quite there yet, but it could be.
There's a lot of improvements to be made in current software stack.
What's more, I'm fairly certain developers would prefer smaller, incremental, and separate improvements to their software ecosystems.
"One library to rule them all" isn't as compelling as the UNIX principle. Because when one of these systems is proven to be inefficient or buggy, it doesn't discredit the entire library.
I want some of these parts in some of my apps. But not all, always.
Also, it's not quite correct to say that these failed. They did what they were supposed to do; they simply were not the magic bullet some proponents made them out to be.
Since you're 100% right I wouldn't call that cynical. It is indeed another approach to create a unified messaging standard. And yeah there are plenty and I haven't even looked at every single one in detail to be able to reject them. But that's definitely an exercise I will try soon.
I tend to think that these xkcd URLs are becoming like bible verses for geeks. I find myself memorizing those numbers. (e.g. "Ugh, he's getting like xkcd/386 again.")
At first glance, it seemed like yet another silicon-valley-neoliberlist-style lots of words and ideologies, but no code and practicalities. But it seems like OPs thesis has a more hands-on approach:
- It seems some kind of language/computation-model. Loosely based on a "everything is an actor" model.
- It did look goodish. I tried following the Fibonacci example, which sort of made sense (I got the impression that recursion is handled by creating new nodes/zells). The discussion chapter also seemed interesting.
- It has that abstruse academic feel, where sometimes it is hard to assess whether the problem is my ignorance, or just vagueness of the publication.
- Motivation sections usually have an exaggerated tone to them (i.e. this will totally change everything), but this one, and the article above, are a bit over the top.
- There are also some over-the-top statements sprinkled throughout the thesis (e.g. "a model of virtual objects which exist independent of any hardware").
- that's exactly what it is. And the way I see it, actors are an implementation of OOP (in it's original meaning) so I would stick with "everything in an object"
- thanks =)
- I had that same feeling while writing it, constantly balancing my own ignorance with an acceptable level of vagueness
- call me the over-the-top guy. But the way I see, your vision has to be grand, if not megalomaniac if you want the essence to survive the collision with reality
- seamlessly migrating networked objects are one of the lesser over-the-top ideas though
If the thesis is relevant at all to what you're doing now, might I suggest linking to it directly from the manifesto? Otherwise it sounds mostly like you are very excited about something, but I got almost no idea what that something is.
That's probably the biggest weakpoint of the manifesto but also kinda on purpose. While the thesis was all about "let's build something" the manifesto is a fresh start trying to answer the question "what is the problem?". The thesis is still relevant but a bit outdated and I'll probably rewrite it in multiple blog articles.
What I'm planning to use as information starting point is zells.org but it's all still in an early stage. At the moment I'm working on creating a document that visualizes the "end product" that I have in mind.
After looking at the thesis and the manifesto, I think your best bet is to create one worked example, in pseudo-code or whatever, and then see if you can get anyone on board with that.
This looks interesting to me as a programmer, but it looks much too complex and niche-knowledge-dependent to be, in my opinion, a real contender as a tool to allow non-programmers to program.
I only glanced at it, though, so maybe its easier than it seems, but to me, the samples looked complex enough that I don't see it.
It does look great as an experiment into different programming models though and that's something I always enjoy (and is needed if we're to get better future tools).
> Just as knowing why apples fall down and aeroplanes fly
up, the citizens of the 21st century need to know that
computers are not magical boxes but composed of dynamic
models.
In all honesty, I don't know why apples fall down and aeroplanes fly up. I just know that they do. No doubt that improving software literacy is a worthwhile goal, but I think the author hasn't made a strong case for it in the opening paragraphs.
One of the most common challenges that I see engineers face is to effectively empathize with the user. When you know a lot about something, you just see it in a fundamentally different way. This makes it difficult to focus on making it easy for the user to do what they want, not what you think they should want.
When I drive my car, I just want to get from point A to point B while listening to a podcast. I don't care to know how they work. This doesn't make me enfeebled or ignorant, I would just rather commit my learning cycles elsewhere.
Computers need to be the same. Why would we be so foolish as to think that it's a wrongdoing that people are able to effectively use computers without having any clue about how they function?
Literacy isn't about forcing people to learn things, it's about ensuring that everyone has the baseline exposure to help them discover if they have an interest in a topic, and then the resources to explore that topic if they choose.
Remember, one of the key aspects of OO is hiding implementation details because they shouldn't matter. This fascination with exposing them and forcing them on end users is absurd.
We have to accept that some tasks and jobs are not for everyone and that's okay. That could be due to aptitude, skill gaps, education gaps, interest, or dozens of other things, some due to education system, some due to abilities of the individual.. and that's still okay.
The problem with computers (abstracting from accidental complexity) is, that they do what you tell them to do, not what you think you told them to do. You cannot somehow make an agreement or solve it, how it is solved with humans - by communicating. You must formulate your thought exactly.
And that's what most people have a problem with - except for some hard sciences, they never needed to formulate their thought that way.
> Literacy isn't about forcing people to learn things, it's about ensuring that everyone has the baseline exposure to help them discover if they have an interest in a topic, and then the resources to explore that topic if they choose.
That sounds hilariously naive. If we'd let people decide themselves what they want to learn the majority would still be in the sandbox making castles and playing with toys all day.
Its about exposure, not learning enough to be a professional.
For example, I learned some basic mathematics, physics, chemistry, biology, history, geography, etc in school. Until I got to university, what I learned wasn't enough to make me a mathematician, physicist, chemist etc. It did give me a baseline on which I could build and it gave me exposure. This exposure was forced on me, but what I did with it (a computer science degree and a programming career), was something that was left up to me to choose later.
I see computers/software the same way. Its common enough in day to day lives now that I think a baseline of computer literacy and some basic exposure should be required and afterwards the students can choose if they wish to explore more or not.
The exposure doesn't necessarily have to prep them for real work (I'm pretty sure dissecting a frog isn't going to prepare me for veterinary work...), just give them a taste of how things work.
And people have spent years learning how to check facebook.
The problem with this pitch is that it doesn't understand the distinction.
By a lot of people's standards, I am a scientist (just not a domain scientist). I spend my life understanding how things work and figuring out ways to further our understanding of those. It is great. If you ask me about how a computer works, I can talk for hours. Physical phenomena? Minutes. Biology? I can make a crude joke
As for a car? I vaguely understand the principles of a combustion engine, but I couldn't for the life of me make one. My understanding is "You get gas into the engine. You light it with a spark plug. It bursts into flames which moves a piston which moves a crank which moves a bunch of gears and eventually moves wheels". I don't know anything beyond that
Hell, another good example is in the realm of video games. Kerbal Space Program is awesome and does a great job of making people remember why they learned physics. But engines are a black box for the vast majority of us and you genuinely don't need to understand how the fuel gets to the thruster or what happens. It is just a black box where fuel goes in one end and fire comes out the other, with fire generating delta V.
And same here. Most people don't need to know WHY an apple falls. They just have to know that stuff will fall. Whereas the physicists and funky table makers DO have to understand why the apple falls and how it can be stopped.
I think the car analogy kind of falls apart at this point. Using a computer and writing programs for a computer are both interacting with software. Take spreadsheets, for example: is making a spreadsheet analogous to building a car or to driving one? What about drag-and-drop visual programming?
Maybe if you drive an automatic. It took me a long time to be comfortable enough with shifting gears, operating turn signals and what not to leave enough attention for the actual traffic around me.
True, I still can't do manual quite right and it certainly adds danger to my trips. But my point was that people put time into learning how to use their cars because they're killing machines, most computers aren't, but the ones that are usually require some sort of formal training and certification, just like cars.
In the (proximate) words of Alan Kay: "Giving people what they want is marketing, given them what they need is education." I'm more interested in the latter.
But I do very much agree that using a computer should not require any idea about how they function. But that's for using a computer like a tool. For me, computers are not mere tools but a medium. So what you wanna do is to express yourself with computers. And for that you need to know how to do it.
That's unfortunate since I put a lot of work in these paragraphs. I'd love to know what you think would make a better case for improving software literacy.
> Software is fundamentally broken. It's limited, never quite works the way we want it to, but it can't be changed, can't be combined and can't be trusted.
In general, this level of hyperbole puts me off. Besides anything else, this sentence is outright false, since much software can be changed, combined, and trusted. I know it's a manifesto, but still, this kind of rhetoric is unlikely to persuade people who don't already agree with you.
The issues you are discussing in this manifesto are not new, and many people have attempted to create tools to tackle those things before. Perhaps try to clarify why you think those tools fall short, in order to persuade people that zells is useful.
Sorry that the style puts you off. I wanted to make a strong statement that people either strongly agree or disagree with or maybe find ridicoulous. But if it helps me finding peopoe who already agree with me I'd say mission accomplished. The rothers I'll try to persuade with the implementation of those ideas.
> Just as knowing why apples fall down and aeroplanes fly up, the citizens of the 21st century need to know that computers are not magical boxes but composed of dynamic models.
I'm not sure most of the public could explain why gravity works, or how an airplane actually gets in the sky. This is because most people are not inquisitive by nature, they generally take things at face value without questioning why. This kind of attitude does not work if you want to build something complex whether it be software, a car, or a bridge. I think the first step is how we as a society can encourage a generation of thinkers and tinkerers.
> This is because most people are not inquisitive by nature, they generally take things at face value without questioning why.
I have to disagree with this statement. Almost all people that I meet, pretty much across all group boundaries you can imagine, I find to be inquisitive. Very inquisitive in fact.
What I think you may be observing is that the depths of questions that many are interested in aren't great... gossip magazines, for example serve to give answers to an inquisitive populous, we can question the value of such questions, but that is still a drive to know something.
Also, I find that when people do ask deeper questions they can be simply overwhelmed by the answers. I'm not particularly good at mathematics, but often times work with people that are in the very top tier in that realm: I will ask certain questions for which I'm simply not prepared to hear the answer... the answer requires background that I simply don't have... I am genuinely interested, but the required prep work is simply out of the question. One could argue that the answers can be simplified as well, but that's not always true.
I think the problem with creating a society of thinkers and tinkerers is that some people just do not find it interesting, so we should not force them into it.
I am curious by nature and like learning new things and figuring out how things work, and it has been like that since I was a kid. My brother is the exact oposite to me, yet we both had the same upbringings (we differ just three years).
When he studied the sciences, it was just pass highschool degree, and after that he went into the social field as a caretaker for special-needs children. I doubt he would benefit a great deal in his day to day life from knowing why apples fall down or planes fly up.
Whilst I like the idea of encouraging a generation of thinkers and tinkerers, I accept that it just isn't for everyone, and neither should it be. Maybe it's just not in their nature.
That's a nice example since nobody can explain how gravity works. It's the least understood force in the universe =)
I agree that most people are not inquisitive but I don't think it's by nature since most children I met were very very inquisitive. So my approach is to make it easy to stay a tinkerer.
I'm going to buck the trend of cynicism and say this is beautiful and matches my own ideas closely, though I have not read the paper yet.
How many of us seasoned programmers came to an understanding with computers by playing in a "toy world" of comprehensible, somewhat visible, documented, predictable abstractions, such as Logo, HyperCard, Excel, BASIC, or even assembly code, and now perform bizarre ceremonial rites on a daily basis to get a teetering stack to perform our bidding as part of "real" programming? There's a vicious interplay between how "bad" and complex software is and how arcane and unapproachable it is, even to experts, driving away all but the most determined to crack the code, who then work together to try to build quality components and applications against great odds.
After reading the thesis, the proposed model of computing is like a concurrent Smalltalk where everything is completely mutable, even an object's code and prototype chain. The author then writes a function to calculate the Fibonacci sequence by turning it into a distributed system, with some effort, and then runs the code and talks about its performance!
At first glance, there seems to be a lot of incidental complexity and creative choice in expressing a function from integer to integer in this system, which goes against the ideas of code reuse and separating meaning from optimization -- i.e. that there is one global Fibonacci function that we can inspect and understand and don't have to rewrite for performance, or in another language, or to run in a distributed fashion.
> More and more, users are put into - sometimes golden - cages, and forced to hand over their ideas, personal information, and even identities to international quasi-monopolies that put everything into walled gardens which the creator can only access through tiny keyholes.
I don't think this has anything to do with software, it seems more like an attempt to educate the masses on the evils of facebook and twitter, but then again that isn't a software problem. You can see this kind of locking system in financial businesses like loans/mortgages, or even benign ones like the eyeglasses business.
Pleased to see more efforts to fix fundamental problems with computing. It's certainly needed, this won't get fixed by piling more crap on top of the existing stacks (including: building OSS versions of proprietary things.)
This one seems to address some of the values I think are important, so, neat.
But I'd argue ordinary people just need to be able to use software, not necessarily build it. So, available software should be high-quality. There should be meaningful choices between alternatives. I think that means: no lock-in.
Whenever the physical world intrudes on the illusory "virtual world of computers", the man behind the curtain is observed in its less than superlative aspects and we're less prone to attribute OZ powers to "software".
Software /is/ magical in many aspects. But its own inherent magic has never been anything other than sleight of hand sort of magic. Even then, software magic borrows from the glory of /insanely/ complex physical machines, and various wondrous features of Nature itself.
One case in point was when Moore's Law and economy collided and the practice had to ramp up on concurrency and deal with SMP. A bit later (and still on going) we're ramping up on distribution and dealing with CAP. In the former case, the illusory 'indivisible' platform was seen to have a sort of geography. In the latter case, the illusory notions of linear 'time' and smooth 'space' was smashed.
OP's remedy for a software-driven world's ailments is software literacy. But the physical head poking through the curtain should make it clear a large subset of these ailments have to do with physical things, such as computing devices, infrastructure, access to energy, and even softer concerns such as legal and political cover for making, providing, and operating software.
Imagine if every single person was a world class chemist and biologist. Would we be able to do away with drug companies? You have that amazing molecule all figured out -- do you have the physical capability for actually realizing it?
I'm taking the opposite opinion for the sake of argument: The more you understand about software, the more frustrated and disappointed you will be, as you see all the easily avoidable flaws around you.
Web pages that have a few lines of text are unreadable on mobile devices and drain your battery.
Setting the spin speed on a washing machine takes ages because the computer polls for input only about once per second, so it misses most of your button presses. How to reconcile this if the clock speed is thousands to millions of cycles per second and the whole system has only a handful of inputs and outputs.
These are not tough technological limitations, but completely easily avoidable human failures. There can be nothing but negligence, cynicism and depression to explain them.
People would be a lot happier to just say "I guess it must be like this", or "My device is getting old and slow". A bit like "God works in mysterious ways" or "it must be fate" can often feel better than "our government is corrupt" or "I don't have any kind of plan".
I guess it's the same about any thing you feel passionate about. If you cared about clothes or food, seeing all the junk out there might make you less happy. A friend of mine was a barista. He wasn't happy that people were paying the same amount for worse coffee.
Wow that's depressing. I suddenly feel the impulse to give you a hug and tell you that it's gonna be alright. I wish I was more sure that it actually will be.
I haven't read the paper yet but the idea looks promising.
I've had this itch myself for a long time. I can't quite put my finger on it but we really need something like a high level assembly language. One that incorporates high level concepts like networked computers, cryptographic identites for users, access to a global, shared pool of data and algorithmic primitives regardless of which application they were originally written for, or what domain specific higher level language they were created in.
Like, once a user has entered their address into a computer, they shouldn't ever have to enter it again in a different software. Once someone has written an algorithm which takes input x and produces output y, noone should ever have to rewrite it again, but everyone should be able to reuse it. Applications shouldn't all indvividually handle transferring data between devices of the same user or even between users, this should be already built into our programming model. And so on.
If this sounds like some utopian dream or incoherent babble, that's because it probably is at this point. But I'm convinced this is the future of computing we should be aiming for, not piling up more stuff onto our existing stack that's just barely held together by ~50 year old technolgies built for that age.
Wow that's exactly how I feel. I couldn't even formulate it that well. But I'm very happy to know that other people feel this itch as well.
Your sentiment of "aiming for the future we want" instead of "piling up more stuff on our existing stack" reminded me very much of this talk: https://www.youtube.com/watch?v=gTAghAJcO1o
IMO we're kind of headed that way now. I always saw this as the point of Google's combined interest in TensorFlow and Kubernetes.
Containers are the piece of the toolchain we've been missing. Now we actually have some feasible logical methods (deep neural networks + gradient descent) that can be used to structure existing computational tools into deeper, more intelligent systems.
Think of it this way: what's the difference between (an ideal) container and an artificial neuron? Structurally, they are nearly identical: they both have collectors and emitters, and perform some non-linear action in concert with other similarly-structured systems. Containers can also help with some of the "trust" problems: if we're shipping around trained data models (or container images) rather than the actual training data, we can push storage out to the edge of the network and run the models there. Containers provide a common computing language that enables you to do that.
This platform is not a leap forward for the theoretical capabilities of AI; but it is a shortcut that should eventually make it easy for AI researchers to leverage vast existing libraries of software written in any one of hundreds of programming languages.
I actually suspect that this is just the first generation; there are a number of software problems that currently can't be solved easily in a multithreaded manner. However, if you can build a container that does what you need, you can eventually train a model to replicate the container -- it may be less computationally efficient, but with future orchestration platforms it may end up being more time-efficient.
This industry is in its infancy. We have some of the greatest minds working in it, and yet we barely know how to make things work right, and OP’s suggesting we try and design tools that an average person can use to create powerful software. How about we let highly-trained specialists figure out how to write complex software first, before we try to teach average programmers how to do it, and perhaps then we can turn our heads towards the masses.
Making computers incredibly simple to use seems to have worked out well in the case of the iPhone. Lots of common usability problems in computer UI simply went away with a much better design. It's hard to say where the mobile-phone industry would be today if that shift hadn't happened in 2007.
Perhaps the same could happen for computer programming. For example, in the 1990s, HTML introduced coding to lots of people who otherwise probably wouldn't ever have considered it. A forgiving declarative interface was a lot more appealing than learning what compilers, linkers, functions, parameters, and APIs were.
Since this is my first submission on hacker news, I'm a bit overwhelmed by the amount and quality of the responses. I'll try to address critiques individually but in order to not have to repeat myself continuously I wanted to thank everybody for their time and energy this way. Your feedback is much appreciated and I'll use it to debug the idea and the manifesto.
I think this misses the problem completely. The problem is not that people that trust computers need to put more effort into understanding computers. The problem is that people keep trusting computers.
What people really need to be educated on is "Why computers are not and never will be trustworthy". And they don't need the details of why, just the bottom line.
Can we please just let this idea die. Almost since the day programming was invented there has been at least one person out there trying to dumb it down to work for the average person and it always fails. Computers are hard to program because they're complicated. Programming languages strike a balance between simplifying some aspects of that complexity and exposing enough of the inner workings to efficiently implement algorithms. Different languages strike different balances but ultimately they all are more complicated than the average person can handle because at the end of the day the computer itself is more complicated than the average person can handle. No amount of dumbing down or simplifying things is going to create a programming language that you're going to want to write serious programs in but that the average person is going to be able to understand.
> Almost since the day programming was invented there has been at least one person out there trying to dumb it down to work for the average person and it always fails.
In a manner, one person succeeded - and he did it without "dumbing it down" - but rather by understanding and utilizing what was then known about how we learn things - particularly as children:
Sadly, it seems that Papert's work is mostly forgotten by those who seek to re-implement it - and generally poorly in most instances, with few exceptions.
Though I still think Papert's language to be superior, as it is like LISP, is functional, and is a real language you type in an editor (vs "drag-n-drop" programming). In other words, it approaches programming closer to how programmers code.
On the contrary, I want programming to be easier where possible, but the goals of this manifesto (and all the similar ones before it) are trying to fix the wrong thing. Better and more powerful abstractions are always good, I'll always welcome a new tool that makes my job easier. However the goal of this project is to make a tool that's explicitly designed to make code that's easier to read for the average person, not easier to program in. This is in many ways a set of opposing goals. Things that are easier to understand tend to lead to more verbose code and vice versa. Look for instance at assembler. Conceptually assembler is very simple but because of that simplicity implementing anything non-trivial in assembly tends to be very verbose. On the other extreme languages like APL and Haskell are very concise but they're hard to understand because they're very complex and leverage a lot of very powerful concepts.
What I want are new tools that leverage powerful concepts to allow me to efficiently express complex ideas. These tools by their very nature are hard for the non-programmer to understand. Look at what's being proposed in this manifesto. They're advocating for what is in essence internet enabled Excel. Do we really want to start trying to write applications in Excel? Can you imagine the horrible spaghetti code that would result in? Imagine how much code you're going to have to write to express even mildly complicated concepts? Imagine trying to maintain one of these beasts.
Further more, for this idea they propose to get off the ground, the vast majority of programs would need to be written in this new language they're proposing, which is, quite frankly, not going to happen anytime in the next 20 years at least. We're still using C and assembly, and they don't look to be going anywhere anytime soon (although maybe Rust can dislodge a little of the C). I do think it would be good for more of the population to at least have a passing understanding of basic programming concepts, at the very least learning how to solve problems using abstract thinking would be useful, but I don't think trying to create some kind of "simple" programming language is the way to do it. There are "simple" programming languages out there, just look at any of the toy languages designed to teach children how to program. But that's the thing, they'll always just be toys, they expose a very limited subset of capabilities for solving a limited subset of problems (mostly they focus on making it easy to draw on the screen since it allows for simple games that provide positive feedback for children learning).
If I understand you correctly you're probably thinking about how more concise notation systems make things easier for experts but harder for novices, e.g. maths and music scores, and probably Haskell as well.
So I suppose you mean "Things that are easier to understand for novices [...]".
But that's not always the case which is incidentally proven by your examples. Assembly Language is a lot easier to write and understand for novices than machine code. And Fortran even more so. Bret Victor illustrates this very nicely in the video I linked to.
I'm convinced that the power that makes something more concise and at the same time easier to write and understand is abstraction. Or more precisely, the right abstraction, since a bad one can have to opposite effect. So I agree with you that better and more powerful abstractions are always good. Spreadsheets for example are a great abstraction for some problem but terrible for others.
So in order to "leverage powerful concept" and "express complex ideas" you need to be able to create your own abstraction. In this way my proposal is very different from Excel which barely allows to create any new abstractions.
What the manifesto apparently doesn't make clear is that I'm not proposing a new programming language but a programming model. The language part is more like byte-code than Java but it's really a protocol. The result is something that would serve a similar purpose as HTTP but would be vastly more powerful.
I think the mistake that these "language designed for children" that you have in mind is that they add training wheels instead of removing the pedals. The latter manages way better to teach you the basic concepts (steering, balancing) first and once you mastered these, gears and transitions increase your efficiency.
When it comes to software, I would take a similar approach and create a software authoring/execution environment that can be used by novices and experts alike. Novices would learn the concepts (message passing, abstraction) without actually writing code. The coding would then be added to increase the user's efficiency by providing a more concise notation. The actual language used would best be domain-specific to achieve maximum efficiency.
Ah, now this is a very interesting conversation and you're right, the manifesto doesn't get any of that across.
Abstractions are the key to powerful programming languages, but they're also the thing that people struggle with the most when learning programming. It appears a certain segment of the population is just not capable of thinking in abstractions in the way that programming requires (or at least they do not care to invest the effort to learn how). Math has a similar problem, with high level maths requiring a level of abstract thinking most people are not comfortable with.
The flip side of that though is that all abstractions leak. Abstractions are convenient shorthand, but to properly use them you still need to understand the thing they're abstracting over and that becomes more true the larger and more powerful the abstraction is. The leap from machine code to assembly language for instances is a very small abstraction, it's mostly a matter of mechanical symbol replacement with very nearly a 1 to 1 mapping from assembly keyword to machine OP (there's some small nuance around single vs. multi-byte ops as well a register vs. immediate vs. address ops). Because the abstraction to machine code is so thin it's not terribly important to understand the actual machine code because the abstraction when it does leak does so in only very small and minor ways and it's usually easy to figure out what's going on. Once you start working in larger and more powerful abstractions it becomes a lot more important to be able to peek behind the curtain as it were. Understanding classes for instance and the nuance involved in dynamic dispatch in something like C++ is very important to properly understanding their behavior, limitations and tradeoffs.
When you talk about using this new Excel like model as a generic programming model I'm immediately reminded of the actor model. It's a very similar design, but it's also not really a good fit for certain kinds of tasks. That's part of the problem when you start talking about some kind of generic model (or abstraction as the case may be), it likely will work quite well for certain classes of problem but be wholly unsuitable for others. I also don't see it actually addressing the issue the manifesto brings up which is to promote programming literacy. The vast majority of people are going to have no interest in learning about the various abstractions programmers employee. It could be argued that they would benefit from doing so, and that some classes that teach basic programming abstractions should be mandatory in either Highschool or College level courses, but I suspect we'd see as much success there as we do with the higher level maths like statistics and calculus.
As for the toy languages most of them aren't too terrible but in the interest of not getting bogged down in a study of advanced topics they tend to force certain abstractions such as being loosely typed, or having no namespacing. For most real languages various escape hatches are provided to allow you to bypass the abstractions when necessary (in extreme cases FFI allows for escaping the language entirely), but all those escape hatches tend to introduce dark and mysterious corners in the language that are very hard to explain to novices because they tend to strip away all the layers of abstraction exposing the dangerous moving parts of the language. In order to avoid confusing novices with features it's assumed they'll never use most of the toy language elide the escape hatches you'd expect of a real language and instead simply say "No, you can't do that" in instances where the student wants to do something that isn't built into the language. In particular being able to link to and utilize C libraries is a hugely powerful feature that most real languages support, but which tends to introduce all kinds of complications not only at the language level but also at the tooling and build level that most toy languages want to avoid.
> Do we really want to start trying to write applications in Excel? Can you imagine the horrible spaghetti code that would result in? Imagine how much code you're going to have to write to express even mildly complicated concepts? Imagine trying to maintain one of these beasts.
Have you not worked in business much? Or software development (or b2b software development, or vertical integration software development, or...)?
Everything you mention in these few sentences has already come to pass, almost as soon as Excel was released. You would not believe the ungodly horrors we software developers have seen since then...then been forced to maintain, or re-write, or attempt to document.
/sob
I once found an ANN implemented as a set of Excel worksheets - thankfully, this wasn't a real-world system, but rather a tutorial designed to help teach ANNs to those with only Excel knowledge...but I know that someone - some manager, likely - somewhere out there - has chosen to add this beast into his or her own Excel worksheet system, and that it lurks, waiting like Cthulhu for a hapless sacrificial victim.
Sadly yes, yes I have. One of the very first professional projects I worked on was a system to replace an Excel spreadsheet because they were having issues with locks when trying to concurrently modify it on their network share. The project requirements where literally "implement what Excel does", and the answer to any question about the program behavior was "What does Excel do? Do that". On the one hand it was wonderfully simple and a great opportunity to play around with Backus-Nauer forms and the guts of an interpreter. On the other hand spending months re-implementing Excel rather than solving the actual problem was rather soul destroying.
I can't tell from the manifesto what this supposed to do, but the goal of making programming more accessible seems worthwhile.
An Internet-enabled open source Excel would be, well, at least better than Excel, which runs more of the world than we'd probably like to admit. Of course, the chances of that happening are effectively zero.
It looks more like Smalltalk, which actually isn't known for being easy to read. So I'll reserve judgment for now, but I support the ambitious effort.
> It looks more like Smalltalk, which actually isn't known for being easy to read.
That's sort of one of my points though. They're going to come up with basically one of two things:
A) Something that's conceptually simple (so the average person can understand it without needing to take a bunch of programming classes) but which leads to most programs being very hard to read because they have to implement all the complexity in the program.
or
B) Something that's conceptually complex (and which will require a bunch of programming classes to understand) but allows for simple and easy to understand programs (once you understand the language).
All the horrible Excel and Access code out there (not to mention some of the worst Javascript out there) are basically the first category, while most serious programs and programming languages are the second category, or somewhere in-between the two.
Smalltalk is somewhere between the two. It uses a number of relatively complex concepts but tries to hide them behind some fancy tooling. It was a hugely influential language and pioneered a number of interesting, although perhaps ultimately misguided, concepts and abstractions. Personally I think the message passing concept Smalltalk pioneered (the predecessor to todays actor model and one of the originators of the OO concept) is going to go down as an evolutionary dead end that's poorly suited as a model for general purpose programming (it has certain niche uses that it's very well suited for but shouldn't be applied to the general case).
There is a ton of low-hanging fruit in just making the basic logistical details of programming more accessible. (Try to imagine explaining npm to the average Excel user.) Now this project may go after that and produce an incremental improvement that finds a niche in education or wherever, or it may pursue a re-invent computer science, boil the oceans strategy and end up with a smoldering heap of nothing after much effort.
I think there is room for a "global librarian". Moreover, when AI starts to program itself, having a logically linked system that can be queried for potential implementation strategies will be beneficial for integrating new features. However I think google can already do this to some regard. Perhaps its time for something like "site: github, lang: python, tags: [csv, excel, graph]. Then add some local db that can receive notifications from github on changes?
Viewpoints Research Institute (Alan Kay's group) is working on solving some of those problems. They have published some interesting papers although I don't know how practical their ideas are.
I propose capital punishment for people who do not put enough effort into optimizing memory usage and performance. I know we have more than 64kb of ram now. That does not mean we have to add useless shit that just bloats everything.
What do you think those reasons are? In case of HyperCard I think it's that there wasn't any inter-stack-linking let alone networking.
What I'm crying about is that Smalltalk was not the future.
It's too hard/expensive to make that kind of abstracted GUI that lets you make real software, and too hard to keep it updated as the environments/contexts change, as in your example of networking became important, and it wasn't part of hypercard, and would have taken a lot of time and skill to make it so in a useful way.
It's just too hard. You can make that kind of layer for a special special purpose domain (say, making simple games, or sound engineering, or what have you), but it's hard even to do that right, let alone a general purpose universal environment. Software is expensive enough to develop with quality the 'ordinary way', let alone trying to develop and maintain some kind of layer on top that let's people do it without.... without what? Without knowing what they're doing? At some point, if you are able to make it actually powerful enough, it's going to be just as 'hard' as anything else, isn't it?
HyperCard failed, but not necessarily for technical reasons.
It might be worth making some hypotheses and testable predictions here about how much complexity is needed for various tasks, and how well current tools are doing at avoiding unnecessary complexity.
I think surveying the current landscape and past efforts, and getting a dialog going along the way, would be a lot more valuable than immediately starting to design a solution.
I'm very confident there are opportunities here, but not so confident about the chances of any particular approach.
Hi rtens, I would like a concrete (not abstract) explanation of what a cell is and how to compose an application with them; your docs are very abstract. Perhaps a hello world application?
The thesis mentioned elsewhere contains some concrete examples but my goal with the manifesto was to get to the root of the problem I'm trying to solve which is quite abstract indeed. I do not have a document yet that visualizes what I want to build but I'm working on that. I'll post updates on twitter.
I'm also working on solving this problem, but my solution is to teach vanilla HTML, CSS and JavaScript by making an IDE with WYSIWYG, real time analysis and other goodies.
Trying to get people who make Word documents to make web documents instead, using HTML. I think it's time to bring HTML and the web to the mainstream. Companies are currently paying hundreds thousands of dollars to copy/paste from Word to a CMS that store the document in a database blob, when they could make HTML documents themselves for peanuts. Once you have the documents in HTML format instead of a closed binary format, it's possible to use all the nice tools we developers use, like git.
The cells concept seems like a global git repo atop a NFS.
While such a thing might help the people who choose to use it. I think you will have to be very careful to avoid the competing standards trap.
https://xkcd.com/927/
If you are truly passionate about bringing programming to more people, then I suggest starting by trying to teach each existing language to a different person who doesn't know programming.
The intro experiences of each of those people should confirm or refine your ideas about what needs to be built in order to get the maximum number of people programming.
Alternately, you could start with the observation that it seems to be the case that even most programmers do not make most of their own solutions.
If that is true then a good thing to build might be a general programming language that would get most programmers to start making most of their own solutions.
Either way, the result should be a language that is so much simpler to write in and that provides such a small time to useful solution that not only will most programmers choose to use it to solve their own problems but most programming instructors will choose to use it as a first language.
Computers are great with complex mathematical models of physical phenomena, and in some limited cases this is extremely useful. But smart engineers know the limits of their tools, and computer models are not an exception.
But to assert that abstract ideas or the human mind can be replicated in a computer only shows that the author either has no idea of the actual state of the art, and/or has no idea of what he means when he says this is possible.
One of the first things you learn in Computer Science is that not all problems can be solved with a computer. It's amazing that people so enamored with math that they want to believe they can model every phenomenon in the universe with a computer apparently disbelieve the math that proves computers can't correctly model everything.
Weird. Please don't try to teach the world that computers can do everything. They can't. And that should be lesson one in any plan to increase software literacy. Starting, apparently, with its advocates.