What's wrong with Software nowadays and how we can fix it
github.com
github.com
in the virtual world of computers,
everything can be replicated, from complex
physical phenomena to abstract ideas,
and even your own mind.
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.
Oh ... could you elaborate? I think my cut-rate, community college degree skipped that part :) it seems like a useful thing to know!
https://en.wikipedia.org/wiki/G%C3%B6del's_incompleteness_th...
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...)
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.
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 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.
And then the dawning realization, what fights the future would hold for them...
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.
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!
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.
That said, I'm highly skeptical towards the "good ideas can be stated in a sentence" heuristic.
It's a good start. I can support software literacy. Now you need to state your plan to get there just as concisely. Probably not as easy.
If you haven't read this book:
https://en.wikipedia.org/wiki/G%C3%B6del,_Escher,_Bach
...you probably should.
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...
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.
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. :)
What I meant was that in that virtual world they can be replicated. So the replications would be virtual themselves. I better make that clearer.
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.
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!
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.
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.
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 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.
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.
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.
See a list of 100+ projects that are struggling with trust and full decentralisation: https://github.com/redecentralize/alternative-internet
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 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."
Here's my manifesto based on the same starting insight as you: http://akkartik.name/about. And my project (with one other collaborator): https://github.com/akkartik/mu
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.
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.
"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.
Self-describing components in .NET
Visual Basic 6's component method.
Windows has had various of these, including ODE and COM.
Obviously, any linux distribution, and plain old C linking, probably comes closest (although that tends not to be self-describing.
Lots of RPC systems I would say fall into this list, just google for "self-describing RPC" to find a bunch of versions.
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.
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.
- 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").
- 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
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.
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).
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.
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.
And that's what most people have a problem with - except for some hard sciences, they never needed to formulate their thought that way.
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.
Of course the question this leads to is "what is thr basic level of understanding that people should have in any given topic"?
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.
Yet, you've spent months explicitly training for that task.
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.
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.
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.
The problems usually only start when it's the other way around.
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.
I started to creat a comparison of other platforms. Let me know what platforms you think are missing or where I am misjudging some. https://cdn.rawgit.com/zells/core/master/comparison.html
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.
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 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.
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.
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.
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.
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.
But I agree that this is not a software problem but a business model problem. The solution however, can be software.
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.
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?
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.
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.
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
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.
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.
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.
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).
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.
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).
(Also, the hate JS gets is unfair and diminishes your point.)
The problem with JS is that we don't have any choice about it. For a quick and dirty scripting language that you're going to write some throw away code in JS isn't too bad, it's basically on par with something like lua (although I think lua is designed a bit better). The problem is that by being the lingua franca of the web browser we're now forced to contend with it even when we really should be using a more powerful language, hence all the hate.
To add further insult to injury someone went and decided to make node which is going the exact opposite direction from where we should be going, we shouldn't be trying to put Javascript everywhere, we should be trying to rip Javascript out of the browsers (or at least provide some kind of alternative). All the churn we see in the Javascript community is basically a symptom of the fact that Javascript is being used for something it really has no business being used for. Javascript sucks as a language for writing applications in, so everyone is constantly trying to "fix" it by putting various layers on top, but you can't fix a broken design by plastering things on top like that (talking about frameworks and libraries here, a transpiler is something a little different). Fundamentally there are two root problems with JS, first it lacks a sane type system, and second it lacks a proper module or namespacing system. They're attempting to fix the later with ES6 modules but it remains to be seen how good that solution is going to be. Typescript goes a long way towards fixing the former problem although it's only capable of so much so it's still more of a bandaid than a real solution. In the meantime we have to contend with the constant churn of new tools and frameworks that are all trying to "fix" Javascript by building on its broken foundation instead of ripping it out and using something that's solid from the beginning.
As an aside to the above, for what it was originally designed for Javascript wasn't a bad solution but it needs to grow up now, and the work being done for things like ES6 really does help. It's just frustrating to see the plodding pace of this evolutionary solution to the problem rather than a more disruptive but faster revolutionary solution.
TL;DR: until the Javascript language itself changes all the frameworks, libraries, and build systems are just window dressing. Right now ES6 and transpilers like Typescript are leading the charge in an evolutionary fix to the language, but a revolutionary one would be much faster.
The frameworks and build systems are largely necessary because the web platform is rather weak, and of course to add language features.
A type system would help a lot, as will modules once they are universally used. Typescript, Flow, etc will probably settle on something useful. Evolution is generally better than revolution in language design. It's a bit slower for JS because of the nature of the web.
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.
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.
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.
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:
https://en.wikipedia.org/wiki/Mindstorms_(book)
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.
One of course being MIT's Scratch:
https://scratch.mit.edu/projects/117504922/
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.
I agree it would have been nice if it had been. But there are Reasons it didn't work out that way, and probably isn't gonna go there.
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?
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.
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.