├── comparison.html ├── manifesto.md ├── model.md └── readme.md /comparison.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | Software Literacy Complications 9 | 10 | 11 | 12 | 13 | 29 | 30 | 31 | 32 |
33 | 34 |

Comparison of existing platforms

35 | 36 |

The goal of zells is to enable Software Literacy by providing a software platform without the incidental complications found in current platforms. The [manifesto] describes these complications in details, although in a rather abstract manner. The purpose of this document is to look at a selection of current platforms more closely and how certain complications materialize in them.

37 | 38 |

Restricted by my own knowledge, the list of platforms is all but complete and not every complication is discussed for every platform. If you find something missing, wrong or imprecise, please help improving this document. Any form of contribution or feedback will be appreciated.

39 | 40 |

For an up-to-date list and descriptions of identified complications and how they are avoided in zells, please refer to the manifesto.

41 | 42 | 43 |

Platforms

44 | 45 |

This list contains a variety of software products and protocols which I all consider to be platforms, since they allow users to create, run and share their own software.

46 | 47 |

The categories are protocols for platforms that are defined by standards rather than an implementation, operating systems for everything which is located directly between user and hardware, virtual machines for things that could be called programming languages and everything else is considered an application.

48 | 49 |

The lines between these categories are fluent since it could be argued that some virtual machines behave like operating systems or have well defined protocols and some applications behave like virtual machines.

50 | 51 | 52 |

Complications

53 | 54 |
55 | 56 | 57 | 58 | 59 | 69 | 79 | 89 | 99 | 109 | 119 | 129 | 139 | 149 | 159 | 169 | 179 | 180 | 181 | 182 | 183 | 184 | 185 | 186 | 188 | 189 | 191 | 193 | 195 | 197 | 199 | 201 | 203 | 205 | 207 | 209 | 211 | 213 | 214 | 215 | 216 | 218 | 219 | 221 | 223 | 225 | 227 | 229 | 231 | 233 | 235 | 237 | 239 | 241 | 243 | 244 | 245 | 246 | 248 | 249 | 251 | 253 | 255 | 257 | 259 | 261 | 263 | 265 | 267 | 269 | 271 | 273 | 274 | 275 | 276 | 278 | 279 | 280 | 281 | 282 | 283 | 284 | 285 | 286 | 287 | 288 | 289 | 290 | 291 | 292 | 293 | 294 | 296 | 297 | 298 | 299 | 300 | 301 | 302 | 303 | 304 | 305 | 306 | 307 | 308 | 309 | 310 | 311 | 312 | 314 | 315 | 317 | 319 | 321 | 323 | 325 | 327 | 329 | 331 | 333 | 335 | 337 | 339 | 340 | 341 | 342 | 343 | 344 | 345 | 346 | 348 | 349 | 351 | 353 | 355 | 357 | 359 | 361 | 363 | 365 | 367 | 369 | 371 | 373 | 374 | 375 | 376 | 378 | 379 | 381 | 383 | 385 | 387 | 389 | 391 | 393 | 395 | 397 | 399 | 401 | 403 | 404 | 405 | 406 | 408 | 409 | 411 | 413 | 415 | 417 | 419 | 421 | 423 | 425 | 427 | 429 | 431 | 433 | 434 | 435 | 436 | 438 | 439 | 440 | 441 | 442 | 443 | 444 | 445 | 446 | 447 | 448 | 449 | 450 | 451 | 452 | 453 | 454 | 456 | 457 | 459 | 461 | 463 | 464 | 466 | 467 | 469 | 471 | 473 | 475 | 476 | 478 | 479 | 480 | 481 | 483 | 484 | 486 | 488 | 490 | 492 | 494 | 496 | 498 | 500 | 502 | 504 | 506 | 508 | 509 | 510 | 511 | 512 | 513 | 514 | 515 | 516 | 517 | 519 | 521 | 523 | 525 | 527 | 529 | 531 | 533 | 535 | 536 | 537 | 538 | 539 | 540 | 541 | 542 | 543 | 544 | 545 | 546 | 547 | 548 | 549 | 550 | 551 | 552 | 553 | 554 | 555 | 556 | 557 | 558 | 559 | 560 | 561 | 562 | 563 | 564 | 565 | 566 | 567 | 568 | 569 | 570 | 571 | 572 | 573 | 574 | 575 | 576 | 577 | 578 | 579 | 580 | 581 | 582 | 583 | 584 | 585 | 586 | 587 | 588 | 589 | 590 | 591 | 592 | 593 | 594 | 595 | 596 | 597 | 598 | 599 | 600 | 601 | 602 | 603 | 604 | 605 | 606 | 607 | 608 | 609 | 610 | 611 | 612 | 613 | 614 | 615 | 617 | 619 | 621 | 623 | 625 | 627 | 629 | 631 | 633 | 635 | 637 | 639 | 640 |
Set-Up 60 | 61 |

Getting from zero to developing, knowledge assumed

62 | 63 | 64 | 65 | 66 | 67 |
Usually no set-up required and free download without installation
Free download and simple installation or wide-spread availability
Not free or cumbersome installation
Costly to acquire or complicated to install
68 | 		Syntax 70 | 71 |

Burden of learning a specific syntax

72 | 73 | 74 | 75 | 76 | 77 |
Wide range or interchangable syntaxes available
Multiple syntaxes available
Single, but simple syntax
Single syntax
78 | 		Interactivity 80 | 81 |

Level of direct and immediate interaction with pieces of software

82 | 83 | 84 | 85 | 86 | 87 |
All parts of running system can be directly inspected and manipulated
Easy inspection and more or less direct manipulation
Indirect manipulation but quick feedback or complicated or non-persistent more direct manipulation
Only very indirect manipulation with slow feedback
88 | 		Discoverability 90 | 91 |

Finding useful third-party services

92 | 93 | 94 | 95 | 96 | 97 |
Built-in discovery of service functionality and usage, and new services
In-context discovery of functionality and usage common, good documentation of existing services
Context switch for discovery usually necessary
Very difficult to discover anything
98 | 		Dependencies 100 | 101 |

Using third-party services

102 | 103 | 104 | 105 | 106 | 107 |
Services can be directly accessed without installation or authentication
Direct access without installation but usually requires authentication
Services must be downloaded and managed but tool support is common
Manual download and management necessary
108 | 		Serialization 110 | 111 |

Need for and ease of serialization

112 | 113 | 114 | 115 | 116 | 117 |
Serialization completely automated
Little serialization neccessary, usually automated
Good tool support for serialization, standardized formats exist
Complicated serialization causing much frustration
118 | 		Data Safety 120 | 121 |

Risk of losing software (program or data)

122 | 123 | 124 | 125 | 126 | 127 |
Almost impossible to lose data
Built-in tools for data safety
Third-party tools available and common
Manual data management, tools uncommon
128 | 		Segregation 130 | 131 |

Difference between environments of creating and using software

132 | 133 | 134 | 135 | 136 | 137 |
Software is written and used in the same environment
Software can always be modified with an easy switch in environments
Modification possible but switch is complicated
Writing and running software completely segregated
138 | 		Sharing 140 | 141 |

Giving access to your software to somebody else

142 | 143 | 144 | 145 | 146 | 147 |
Extremely likely that any receipient can access software with almost no trouble
Very likely to access and well-defined group
Receipient must meet certain criteria and expand some effort
Very unlikely to access without considerable effort
148 | 		Autonomy 150 | 151 |

Dependencies on others

152 | 153 | 154 | 155 | 156 | 157 |
No permission required, not controlled by anyone
Controlled by public authority, permission always granted
Controlled by private authority, permission likely to be granted
Depends completely on single, private authority
158 | 		Security 160 | 161 |

Protection of identity and information

162 | 163 | 164 | 165 | 166 | 167 |
Very secure against technological and social attacks, no single point of failure
Effective security, very rare breaks
Unreliable security, breaks are common
No built-in security measures
168 | 		Universality 170 | 171 |

Range of problems that can be solved

172 | 173 | 174 | 175 | 176 | 177 |
No limits of applicability
Very wide range of applicability
Limited applicability
Very limited in usefulness
178 |
Virtual Machines
187 | Smalltalk 190 | Just download an run the image. 192 | Bein a very pure language, the syntax is quite elegant. 194 | Every object can be inspected and changed live with immediate effect. 196 | Objects are self-documenting, explorable and can be found by text- or example-based search. 198 | Third-party modules must be downloaded manually or from a repository. 200 | Objects live in the image, no need to serialize them ever. 202 | All changes of the image are tracked and can be reverted. The image can get lost or corrupted though. 204 | Everything happens in the image 206 | Modules need to be filed-out or exported to a repository. Alternatively, the whole image can be shared. Once the image is obtained, accessing the software is very easy. 208 | There are many open-source implementations with high compatibility. 210 | I'm not aware of built-in security mechanisms. It's only as secure as the operating system it runs on. 212 | I'm not aware of any limits. Operating systems, embedded systems and even Smalltalk itself can be written in Smalltalk.
217 | JavaScript 220 | All you need is a browser and they're almost everywhere. 222 | Many many languages can be compiled to JavaScript these days. 224 | While some browser allow pretty good inspection into objects, changes are not persistent. 226 | Even experienced JavaScript programmers need to look up every second function name and signature. 228 | There are a million package managers but it gets really messy really quickly (left-pad, anyone?). 230 | Almost anything keep-worthy must be serialized. But the native JSON format is basically the de-facto standard on the web. 232 | Nothing buil-in but easy to integrate with any version control system. 234 | JavaScript programs are almost always delivered in source code so how every you run them is not too far away from how you edit them. 236 | Just send the files. Everybody has a browser and there are tons of libraries to enhance compatibility. 238 | Many open-source implementations are available. 240 | The code has full access to the page it's running on. Most security comes from the virtual machine being sand-boxed in a browser. 242 | Depends on the interpreter but very wide applicability nowadays.
247 | Python 250 | Depends very much on your operating system. There are also packages to ease set-up but it's usually a hassle. 252 | Only one syntax but a rather clean one (if you like significant whitespace). 254 | There are debuggers which allow to inspect a running system but not make changes to it on-the-fly. Also, the use of a debugger is not very common. 256 | Objects are self-documenting and can be dynamically explored in the REPL. 258 | Installing packages for Python is too many times very painful. 260 | Necessary for persistence but good native support. 262 | Version control system adviced but not commonly used, at least in the scientific community. 264 | Python programs are usually run as applications which is far away from the editor to change them. If used as script segregation is less. 266 | Few people who are not on Linux have Python installed and even if, it might be the wrong version. Putting a module in a completely self-contained package is very tricky. 268 | The language itself is open-source and many open-source implemenations available. 270 | Only as good as the operating system that runs it. 272 | Python can be used for virtually anything.
277 | unison
295 | LiveCode
313 | JVM 316 | Download and install the Java development kit (JDK). 318 | Many languages can be compiled to the bytecode of the JVM. 320 | Programs are usually distributed as bytecode and run as applications. 322 | As a typed language, support for capability discovery is usually good but requires IDE. 324 | Usage of dependency manager is not common. 326 | Object databases are available must most information must be serialized without any good native support. XML is wide-spread and at all times present. 328 | Version control system advised. 330 | Programs are usually discributed as bytecode and run as applications. 332 | Chances that a Java runtime environment (JRE) is installed are good and it's easy to install if not. 334 | There are open-source implemenations but Java is still controlled by a single company. 336 | Access to the system can be restricted. 338 | Java runs everywhere.
Applications
347 | Etoys 350 | Just download and run the image. 352 | Tile-based is default but can be switched to textual programming as well. 354 | Every object can be inspected and changed while running the program. 356 | Objects are self-documenting. Help and an object catalogue are included in the environment. 358 | Actually I've never come across instructions of how to access third-party software. 360 | Everything lives in the image. Only external data must be de-/serialized. 362 | Everything is automatically persisted in the image. Recovering old state is difficult though. 364 | Writing and running a program happens in the same environment and mode. 366 | Projects can be saved as files. The receiver needs to download Etoys and import the project. 368 | I'm only aware of a single open-source implementation. 370 | Only as secure as the operating system it's running on. 372 | Considered an learning environment. Not meant for the creation of complex systems although could be used for anything since it's stil Smalltalk.
377 | Scratch 380 | Just open the webpage. 382 | Only a single tile-based langauge available. 384 | Objects can be manipulated easily while the program is running. 386 | Inspectors make it easy to discover capabilities of objects and there is a catalogue for existing software. 388 | I don't know if it's possible to access third-party software. 390 | Very rarely necessary but very difficult if. 392 | Automatic saving but no control over history. 394 | Writing and running programs happens in the same environment. 396 | By sending a URL. 398 | Complete dependency on MIT. 400 | Secure through limitation. 402 | Very limited usage. Mostly animations and very simple games.
407 | Spreadsheet 410 | Requires download and installation. 412 | Limited but very simple. 414 | Values can be directly modified with immediate effect. 416 | Auto-complete for function names and signature. Further information must be obtained from help file. 418 | Very difficult to use third-party spreadsheets. 420 | Usually no serialization neccessary. If so, CSV is very wide-spread. 422 | Manual saving required and difficult to integrate with VCS. 424 | No segregation possible. 426 | Most users have a spreadsheet application installed. Some compatibility issues are common. 428 | Open-source implementations available, but dominated by Microsoft. 430 | No security measures provided. As secure as the operating system. 432 | Very limited in use cases and permittable complexity.
437 | Eve
455 | Matlab 458 | Very expensive licence. 460 | Optimized for matrix notation. 462 | Sequential debugger, values can be inspected and manipulated. 465 | Must be manually managed. 468 | REPL history kept for a while. Integration with VCS possible but not common. 470 | Software is usually created and run in the same environment 472 | Very difficult to package all dependencies. 474 | Completely dependent on MathWorks 477 | Very restricted use cases but extensions are available.
482 | Flash 485 | Download and install application but requires licence. 487 | Single syntax available. 489 | Objects can be mostly modified directly with immediate effect. 491 | Usage of help file and external documentation neccessary, albeit well structured. 493 | Very difficult to use third-party software. 495 | Necessary to persist data, very painful. 497 | Manual saving required and difficult to integrate with VCS. 499 | Programs are run with a completely different environment than they are written. 501 | Flash players used to be very wide-spread but are decreasing in popularity. 503 | Completely dependent on Adobe. 505 | Some built-in security mechanisms are provided. 507 | Programs are quite restricted in their capabilities.
Operating Systems
Linux 518 | Installation process is improving but still a major hurdle. 520 | Different interpreters and compilers available. 522 | Memory and disk contents can be directly inspected and manipulated but only in a unstructured way. 524 | Man pages allow to discover functionality on-line. New tools must be searched externally. 526 | Package managers exist but changes are often time irreversible. 528 | Data must always be serialized for persistence and exchange. Little standardization of formats. 530 | Few mechanisms to guard against irreversible operations. 532 | Source code of much software is available and can be edited and executed in terminal. 534 | Incompatibilities between distributions and difficult to package all dependencies.
Macintosh
Windows
Android
iOS
Protocols
WWW 616 | Web browsers are installed on almost every consumer computer. 618 | Wide range available for describing dynamic behaviour but limited for layout description. 620 | Elements can inspected and manipulated directly, not persistently though. 622 | Functionality of web application can be discovered easily by humans but not by machines. 624 | Available resources can easily be used but sometimes require complicated authentication. 626 | Everything must be serialized for communication. Standardized formats are available. 628 | Not meant to be persistent. Persistence is fragile and must be implemented by application. 630 | Software is created and executed in two completely different environments. 632 | Just pass along the URL. 634 | Theoretically no dependencies exist but in reality host space and domain names are needed. 636 | Computer is protected by browser but data in the web is prone to many different attacks. 638 | Not suitable for very interactive or time-critical applications.
641 |
642 | 643 |
644 | 645 | 646 | 647 | 688 | 689 | 690 | -------------------------------------------------------------------------------- /manifesto.md: -------------------------------------------------------------------------------- 1 | # zells - Enabling Software Literacy 2 | 3 | Computers are amazing. They let us connect with friends on the other side of the globe, access endless streams of entertainment, be super heroes, discover new truths about our universe, and bring a million other wonders that would have been considered pure magic a couple of generations ago. And yet, in spite of these achievements, we still live in the Dark Ages of computing. 4 | 5 | To unleash the full power of computers, we need to increase the number of software literate people - people who can write and read software, not just use it. And just like most people aren't professional authors, the goal is not for everybody to be professional software developers, but to enable every person with access to a computer to express their own ideas, as well as understand and build upon powerful ideas of others through the medium of software. 6 | 7 | **The mission of *zells* is to work towards Universal Software Literacy by drastically decreasing the cost of writing, reading, changing, and sharing dynamic models.** 8 | 9 | 10 | ## Software as a Medium 11 | 12 | Hundreds of years ago, before the Age of Enlightenment, producing texts was incredibly expensive. They had to be written on rare paper and bundled up into bulky and fragile books. They could only be written by well trained professionals, were usually big and complicated, and therefore took a long time to write. Only the largest and wealthiest institutions could afford to create them, and controlled which texts were written and which were not. With a tiny number of books around and reading being considered difficult to learn, people instead listened to their interpretations at weekly gatherings. It was free, easy and convenient. 13 | 14 | Few people could imagine a world of universal literacy where text is virtually everywhere and almost everybody can access and contribute to an ever growing corpus of collective human knowledge. It wasn't until the invention of the printing press that text production became cheap enough to start an upward spiral of printed books and literate citizens, which ultimately lead to the Scientific Revolution. 15 | 16 | Four millennia after the first written word marked the beginning of history, the invention of the computer gave us a new medium, one of executable dynamic models - called software. It lets us express ideas not only statically - being identical for every reader - but also dynamically - reacting to a changing world and interacting with its users. The potential of this new medium to augment the human intellect was already described 50 years ago, yet almost nobody is literate, let alone fluent in it. 17 | 18 | Instead of learning to express our own ideas, and understand those of others enough to change and reproduce them, we are content with the limited interpretations and options that user interfaces give us, making their designers our priests, their companies our churches, and their developers our monks. To enable Software Literacy, we need a printing press for software. A way to make software cheap enough to start a spiral of accessible dynamic models and software literate citizens, which could lead to the next cognitive revolution. 19 | 20 | 21 | ## The Cost of Software 22 | 23 | To make software cheaper, we need to understand what it is that makes it expensive. The hardware necessary to run it is definitely a factor, but a rapidly decreasing one. Also, a single computer is enough to access the entire library of all existing software, so the contribution of hardware cost to each individual piece is tiny. 24 | 25 | Software is expensive because software developers are expensive. And developers are expensive, because it requires years of training to become a good one. The reason that you can get many programs for the equivalent of a cup of coffee or even for free, is that it's almost free to copy software. So every user only has to contribute a tiny fraction to its total cost. But the cost is always enormous, even if only consisting of volunteered evenings. 26 | 27 | Why is this extensive training necessary? Because many software projects are big and complex. It's all but simple to build something that works, is fast, reliable, and solves an actual problem for thousands if not millions of people. Complex problems require complex solutions, which causes the majority of complications that make these projects expensive. These are essential complications. 28 | 29 | But what about simple problems? Maybe you just want to write a little app that helps you with organizing your household chores. It only has to work somewhat, doesn't has to be very fast or reliable and only has to solve your own problem. Why is that still difficult to write? This is because of accidental complications. 30 | 31 | Writing a novel or reading a scientific paper is hard, because of essential complications inherent in the task itself. It takes years of practice to become a good novelist or scientist. But writing a letter to your mother is easy. All you need is a pen and paper. If you would have to make your own paper from trees and your own pen from goose feathers, that would be accidental complications, because if would only keep you from writing that letter. 32 | 33 | 34 | ## Accidental Complications 35 | 36 | To find out what the accidental complications of software are, let's follow a hypothetical coffee shop owner Mary, who recently noticed that the queues in her shop are getting longer and longer. She wants to find out what would be the best way to increase the shop's throughput - the number of coffees sold per hour. The options are to either hire more staff or buy more machines. She thinks software can help her with this problem and indeed finds a coffee shop simulation which seems to fit her needs. But after a first glance Mary realizes that it only simulates Cappuccinos, not the other five variants of coffee that she serves. Luckily, Mary is software literate and the simulation is open-source which means she can adapt it to her needs. Theoretically. 37 | 38 | Mary's first challenge is to overcome the **segregation** of the execution and authoring environments of the simulation. To run it, all she had to do was download and open it. But to modify it, she has to find its source code, download it, and "build" it - turning the code into its executable form. 39 | 40 | To do so, she needs to first **set up** the programming platform that the simulation was written for. This includes downloading and installing another program, which takes her only half an hour but she remembers another time when a whole day was gone before she had a platform installed and working. 41 | 42 | The next step is to download and install all the **dependencies** of the simulation - pieces of software, so-called libraries, which the simulation depends on, but are distributed separately. Since many libraries in turn depend on other libraries, most platforms have programs for downloading and installing them. But even with such a dependency manager, this step still feels like a lottery to Mary, since it either works or it doesn't, and there is usually little she can do in the latter case. This time all libraries are successfully installed and it only took her two hours to build the coffee shop simulation from source. That's over a hundred times slower than just running it but she is still happy since it usually takes longer. 43 | 44 | In order to add the other kinds of coffee to the simulation, Mary has to learn the **syntax** of the programming language - the meaning and rules of its words and punctuation. Every language has a different syntax of which some are quite cryptic. Since Mary is not familiar with the one she is facing, she makes many mistakes - mostly forgotten colons, parentheses or accidentally using spaces instead of tabs. These mistakes are even harder to find by the unhelpful error messages that she is presented with. Instead of a simple "you forgot a colon here", the only clue she gets is the number of the line where the code stopped making sense to the computer, which is sometimes miles aways from the actual mistake. 45 | 46 | Even once Mary has learned the syntax, in order to modify the simulation, she has to understand its structure and behavior. But all she has to go by is static text in files, with very little hints on what a certain part is actually doing or how it is connected with other parts. It seems to her like the program was never intended to be **read and understood** by another person - and she is probably right. She knows there is a well thought-out mental model hidden in these files, but it takes her hours to put the pieces together. 47 | 48 | She does this mostly by using a scientific approach: study the code, guess what a piece does, change it a little bit, run the program and see if she guessed right. While she likes being able to experiment with the model this way, she is annoyed that every time she wants to change a piece of code, she needs to restart the program, **losing its state**. With every restart, she has to configure the simulation again - define how many machines and staff members there should be and how long it takes to grind the beans, brew the coffee and foam the milk. 49 | 50 | And even after she figured out what a certain piece of the program does, she still has to **discover the protocol**, the very limited vocabulary and sentence structures that she can use to make the piece do what she wants it to do. There is some documentation explaining the protocols, but more often than not it's outdated, so she has to infer them from the code. 51 | 52 | Eventually she figured it out and even found an open-source project that models how a Frappuccino is made which would save her quite some time if she could use it in her simulation. But unfortunately, it was written in another programming language. And even though the two languages are very similar, she can't **access other languages** from within her simulation. There is no other way - she had to write the Frapuccino model herself. 53 | 54 | Now that the simulation fits her situation, Mary can finally find out what the total coffee throughput looks like for different numbers of staff and machines. She wants to save the result for each scenario on the hard drive disk in order to compare them, so she has to serialize them. **Serialization** is the act of transforming a multi-dimensional, interconnected data structure, into a one-dimensional string of bits, which has to be done every time before saving data to disk or sending it over a wire. During this transformation, a lot of contextual information gets lost which has to recreated when reading the results back into memory. 55 | 56 | But even if the structure can be re-created, the lost context means that a correct **interpretation** is needed to make sense of the simulation results. So Mary has to make sure that she serializes them in exactly the format that her analytics program understands. It takes Mary several dozen tries to get this fragile process right since even the slightest deviation means she can't use the result at all. Luckily, she only uses very simple data and finally manages to save it in the correct format. More complex information, e.g. web pages, are almost impossible to interpret correctly or even to decide what "correct" means. 57 | 58 | After Mary simulated many different scenarios and is looking forward to the insights she might get from the collected data, she realizes that she accidentally used the same file name for saving the results of each run. That means that all results except the last one were overridden. Because of this lack of **data safety**, she lost the results of several hours of work. 59 | 60 | Too frustrated to repeat the whole procedure, Mary decides to push it to another day and instead wants to **share** her version of the simulation with her friend Joe from across town who also owns a coffee shop and might benefit from it. This means though that he too has to set-up the platform, install all dependencies and build the program before he can run it. It takes him several hours but in the end he gets the simulation running. 61 | 62 | The next day Joe calls Mary and asks why her program accesses his address book file where he keeps the personal information of his customers. After hours of digging, Mary discovers that some library that was downloaded as a dependency of a dependency contained malicious code that searches for address book files and uploads them to a private forum on the Web. Because of the weak **security** of her operating system and a lack of control over what program may and may not do, the customers personal information got stolen. 63 | 64 | Even worse, the next day a customer tells her that he thought her shop was closed since its Facebook page has disappeared. Puzzled, Mary checks her emails and indeed finds one from Facebook saying that her page was suspended because it "violated the terms and conditions" - without any further details. After several weeks of emails and calls, Mary still doesn't know why her page was suspended. She realizes that she gave Facebook too much control over her digital existence, sacrificing her **autonomy** for convenience. But at least she doesn't have to worry about increasing the shop's throughput anymore since without the page the number of her customers has halved. 65 | 66 | 67 | ## Advantages of Software Literacy 68 | 69 | But even though devastated by her struggles with the numerous accidental complications of software development, Mary kept at her simulation project and eventually got it working securely and robustly. 70 | 71 | In the end she is glad to be software literate, since it helps her with **understanding** all the physical and virtual things around her. Before, things like her cash register, ATMs or most apps on her phone were black boxes to her. Now she understands how they work, why if not, and what risks are involved when using them. The world seems a little less magical, but she enjoys the feeling that, if she wanted to, she could probably learn to build and control any of these things. 72 | 73 | When putting an idea of herself into software, Mary also notices that she spends a lot of time thinking about her own thoughts and often times she only really understood a concept after expressing it on software. This **thinking about thinking** eventually became second nature and not only helped her with her business, but also with personal problems. 74 | 75 | She also enjoys using software like the simulation for **learning** new things about her business by experimenting with different scenarios and seeing how things change. 76 | 77 | Software literacy lets her use a more **scientific** approach to running her shop. Instead of gut feelings and anecdotes, she is able to support her decisions with data collected from simulations. Instinctively, she wouldn't have taken the risk of hiring a new staff member, but the data show that this will increase throughput more economically than a new machine. 78 | 79 | And once she had expressed an idea in software, she enjoys how easy it is to improve it by **collaborating** with her peers. After she made the simulation safe to run, Joe added some of his knowledge about coffee brewing so now it's even more accurate. 80 | 81 | But the one thing she likes the best about being software literate is how **empowering** it is. She can create her own simulations, set-up her own website and booking system and solve her own problems. She would never want to give that up. 82 | 83 | 84 | ## Software without Complications 85 | 86 | The vision of *zells* is a world in which people like Mary are able to take advantage of the full power of software, without having to struggle through accidental complications. A world where you can easily write, read, share and collaborate on ideas using dynamic models instead of static artifacts, without constantly having to solve problems that are not essential to your goal. 87 | 88 | Although for every mentioned complication there exists already at least one software platform that successfully avoids it, in order to make software sufficiently inexpensive to enable Software Literacy, we need a platform that avoids all accidental complications without decreasing its usefulness or usability. 89 | 90 | Writing software should be as easy as picking up a pen and paper. Reading it should be as easy as opening a book. Sharing dynamic models should be as easy as showing a drawing to a friend. And shaping an idea together should be as easy as molding clay. This is the goal of [zells](http://zells.org). -------------------------------------------------------------------------------- /model.md: -------------------------------------------------------------------------------- 1 | # zells Programming Model 2 | 3 | This document describes the current programming model of *zells*. Please note that the programming platform and the model are under active development and likely to change. 4 | 5 | ## Zell 6 | 7 | The programming model consisting of a single behavioural element, called `Zell`, with a single capability: to *receive* a `Signal`. Upon receiving a Signal, it is up to the Zell to decide how to react or whether to react at all. 8 | 9 | .-----------------. 10 | | Zell | 11 | |-----------------| 12 | |-----------------| 13 | | receive(Signal) | 14 | '-----------------' 15 | 16 | ## Signal 17 | 18 | A `Signal` is a finite data stream of any content. The only requirement is that it can be interpreted correctly be the intended receiver. 19 | 20 | .-------------------. 21 | | Signal | 22 | |-------------------| 23 | |-------------------| 24 | | serialize():byte* | 25 | '-------------------' 26 | 27 | ## Dish 28 | 29 | A `Dish` can be used to *transmit* a `Signal`. A copy of each transmitted `Signal` is received by every `Zell` of the `Dish`es culture simultaneously. A `Dish` that is connected to other `Dish`es transmits every `Signal` to all its *peers*. 30 | 31 | .------------------. 32 | | Dish | 33 | |------------------| 34 | | culture:Zell* | 35 | | peers:Dish* | 36 | |------------------| 37 | | transmit(Signal) | 38 | '------------------' 39 | -------------------------------------------------------------------------------- /readme.md: -------------------------------------------------------------------------------- 1 | # zells 2 | 3 | *zells* is a platform to create, modify, use and share any kind of software. Its design goal is to systematically remove all accidental complications that make programming unnecessarily difficult. 4 | 5 | The mission of zells is to work towards Universal Software Literacy by drastically decreasing the cost of writing, reading, changing, and sharing dynamic models. 6 | 7 | ## Documents 8 | 9 | This repository contains documents and specifications describing the *zells* computing platform. 10 | 11 | - **[Model](model.md)** - Describes the programming model of *zells* 12 | - **[Manifesto](manifesto.md)** - Describes the vision of *zells* and accidental complications 13 | - **[Comparison](https://rawgit.com/zells/core/master/comparison.html)** - Compares incidental complications of existing platforms 14 | 15 | 16 | ## Contributing 17 | 18 | Please don't hesitate to edit any document via pull requests. This can be typos or improvements of the structure or content of document. I will respond as soon as I can. 19 | 20 | 21 | ## License 22 | 23 | The documents and software in this repository are licensed under the [GPLv3] License. 24 | 25 | [GPLv3]: http://www.gnu.org/licenses/gpl-3.0.html 26 | --------------------------------------------------------------------------------