Literate programming tools should never enforce that the code in the woven (pdf/html output) view appear in the same order as it does in the original code view. Unfortunately, Alectryon requires definition-order documents. I would much prefer something like Torii where I can weave the code together in an order that makes pedagogical sense, but does not necessarily pass the proof checker. The writing style in this document is severely hampered by the need to present everything before it appears.

This seems sufficient for most writing use cases, although we’ve already encountered occasional cases where it’s not enough

Edit Groups

Or perhaps you may start editing and then later realize you want to move your work to a branch.

This merging process handles syntactic conflicts in a simplistic way: for example, if “white” is changed to “frosty” in one draft and to “soft” in another draft, the merged result is either “frostysoft” or “softfrosty.” This result requires human follow-up to correct, which should be made obvious through review using tools like “Show Changes.”

Rather than rigidly encoding such processes in our software, we believe that it is better to implement such processes as social conventions around how the software is used.

A draft therefore serves a similar purpose to a commit

The fact that Histogram represents programs as lists of interactions makes implementing the above interface easy. The code in the preview does not have to laboriously transform the source code of the program and insert code corresponding to the actions made by the user. Instead, it is provided with a reference representing the data table and it triggers a number of interactions.

Second, the locations of formulas in the spreadsheet is determined automatically and a user cannot move them.

interaction does not copy the body of the function (as extract function refactoring would). It merely records the references of its inputs and output. The concrete input values are also not lost. We can select and evaluate blocks inside the body of the function and we get a value computed based on the inputs that we used when constructing the body of the function.

Histogram follows a design principle that prefers choosing over composing, because making a choice is easier than coming up with expressions without guidance

Third example: you want to add two packages to your system that depend on the same dependency but requiring different versions. You cannot have multiple classes with the same name in your system, so this is impossible.

Haskell type classes, for example, are a form of static information that has an influence over the dynamic semantics of the program

One criticism that applies equally to both proposals is that the semantics of the code now depends on the presence or absence of type information – in particular type annotations, while OCaml programmers are used to consider that they are useful for clarity and debugging purposes only.

Here we face situations where things must be handled in parallel. It appears that an index is a “space” to the user, and it always makes sense to bookmark a place in a space. Maps, timelines, and almost all indexes are spaces.

Let us visit an example: a digital geography map. Google Maps will only ever let you view details of one location at a time, as with most map programs. Occasionally, I found myself in need of comparing multiple places. Suppose you are given the task of comparing user comments on three bars. Before a certain Google Maps update, I had to do this: Pan map to location 1 Click on location 1 Pan map to location 2 Click on location 2 Repeat

But here, let me state what it is that I want happen. I am proposing a very generalized theory of GUI navigation, so instead of thinking about pages, bars, go-here-buttons, go-there-buttons, back buttons, bottom tabs, bottom sheets and so on, they are described as special cases under one system of navigation.

In the first possibility, any navigation act will open an additional frame on the side, and frames do not close unless the user decides to click a Close button.

The most permissive navigation scheme is one where any navigation act does not inhibit any other navigation act that could have taken place.

The great importance of the back button has naturally resulted from the stack navigation paradigm seen in apps. However, contrary to popular opinion, I am arguing against it on the basis of user freedom and creativity.

then attach a proof or belief that these objects are identical in some sense across the sessions

“A, B, and the person holding the Social Security Number 987-65-4321 are the same biological person (whatever ‘biological’ means)”

REPLs are nice but they work well only for reasonably isolated code with few dependencies. It's hard to set up a complex object to pass into a function. It's harder still to set up an elaborate context of dependencies around that function.

run on a wide variety of hardware - desktops, laptops, tablets, phones, watches

This preserves a clear separation between text and annotations, keeps the original text freely editable, and avoids circular feedback loops that could happen if annotations were themselves searchable

The point is to defer this process until it’s absolutely needed. It’s okay to end up with structured schemas when we need them to support computational features, but when they’re not necessary, text is a perfectly adequate representation for humans to interact with

Notably, this process can’t avoid the need to teach the computer how to interpret meaning from freeform data

There’s no way to ambiguously assign a recipe to either Tuesday or Wednesday, which would be natural to do in a paper notebook.

In Potluck, we encourage people to write data in freeform text, and define searches to parse structure from the text.

Formulas are written using JavaScript, in a live programming environment that resembles a spreadsheet

As this quote implies, formalisms are often difficult for people to use because they need to takemany extra steps (and make additional decisions) to specify anything.

Experiences with workflow systems, systems which automatically route documents and workthrough defined procedures, show that systems without the ability to handle exceptions to theformalized procedure cannot support the large number of cases when exceptional procedures arerequired (Ellis, Gibbs, Rein, 1991).

Of course, training and supervisionhelped users learning the general techniques for hypermedia authoring, but they tended to avoid(or lose interest in) the more sophisticated formalisms

Many times he struggled to create a title for his note; heoften claimed that the most difficult aspect of this task was thinking of good titles

Thus, hypertexts end up ashierarchical outlines with full pages of text connected by a single link to the next page of text

This level of formalization enablesthe system to apply knowledge-based reasoning techniques to support users by performing taskssuch as automated diagnosis, configuration, or planning.

The authors propose, based on these experiences, that the cause ofa number of unexpected difficulties in human-computer interaction lies in users’ unwillingness orinability to make structure, content, or procedures explicit

The scalability issue is somewhat related to the versionability issue. In the small, checked exceptions are very enticing. With a little example, you can show that you've actually checked that you caught the FileNotFoundException, and isn't that great? Well, that's fine when you're just calling one API. The trouble begins when you start building big systems where you're talking to four or five different subsystems. Each subsystem throws four to ten exceptions. Now, each time you walk up the ladder of aggregation, you have this exponential hierarchy below you of exceptions you have to deal with. You end up having to declare 40 exceptions that you might throw. And once you aggregate that with another subsystem you've got 80 exceptions in your throws clause. It just balloons out of control. In the large, checked exceptions become such an irritation that people completely circumvent the feature. They either say, "throws Exception," everywhere; or—and I can't tell you how many times I've seen this—they say, "try, da da da da da, catch curly curly." They think, "Oh I'll come back and deal with these empty catch clauses later," and then of course they never do. In those situations, checked exceptions have actually degraded the quality of the system in the large.

Anders Hejlsberg: Let's start with versioning, because the issues are pretty easy to see there. Let's say I create a method foo that declares it throws exceptions A, B, and C. In version two of foo, I want to add a bunch of features, and now foo might throw exception D. It is a breaking change for me to add D to the throws clause of that method, because existing caller of that method will almost certainly not handle that exception. Adding a new exception to a throws clause in a new version breaks client code. It's like adding a method to an interface. After you publish an interface, it is for all practical purposes immutable, because any implementation of it might have the methods that you want to add in the next version. So you've got to create a new interface instead. Similarly with exceptions, you would either have to create a whole new method called foo2 that throws more exceptions, or you would have to catch exception D in the new foo, and transform the D into an A, B, or C. Bill Venners: But aren't you breaking their code in that case anyway, even in a language without checked exceptions? If the new version of foo is going to throw a new exception that clients should think about handling, isn't their code broken just by the fact that they didn't expect that exception when they wrote the code? Anders Hejlsberg: No, because in a lot of cases, people don't care. They're not going to handle any of these exceptions. There's a bottom level exception handler around their message loop. That handler is just going to bring up a dialog that says what went wrong and continue. The programmers protect their code by writing try finally's everywhere, so they'll back out correctly if an exception occurs, but they're not actually interested in handling the exceptions. The throws clause, at least the way it's implemented in Java, doesn't necessarily force you to handle the exceptions, but if you don't handle them, it forces you to acknowledge precisely which exceptions might pass through. It requires you to either catch declared exceptions or put them in your own throws clause. To work around this requirement, people do ridiculous things. For example, they decorate every method with, "throws Exception." That just completely defeats the feature, and you just made the programmer write more gobbledy gunk. That doesn't help anybody.

Plus, if we can do this recursively, expanding inline items within inline items, we end up with something familiar: an outliner

Let’s say you’re in a workspace, listening to a podcast episode. Maybe you opened the podcast episode from a webpage you had open. As the episode plays, you realize that you would like to take some related notes. You open a new pane within your workspace, and take your notes. You can pause and play the podcast in the pane on the left, and you can take your notes in the pane on the right.

The concept involves having an item just like every other in your itemized system: it has a type, attributes, and references to other items.

Now, not every programmer prefers that kind of development. Some programmers prefer to think of development as a process of designing, planning, making blueprints, and assembling parts on a workbench. There’s nothing wrong with that. Indeed, a multibillion-dollar international industry has been built upon it.

In fact, there’s a style of programming, well known in Lisp and Smalltalk circles, in which you define a toplevel function with calls to other functions that don’t yet exist, and then define those functions as you go in the resulting breakloops. It’s a fast way to implement a procedure when you already know how it should work.

Moreover, because the entire language and development system are available, unrestricted, in the repl, you can define the missing function bar, resume foo, and get a sensible result.

At 3 am he realized he needed to change the process scheduler. He read enough code to find the right method, changed it, and continued with his project

Dan Ingalls implemented the first opaque overlapping windows to let users see more code and other objects on the screen

when a programming technology is "too simple", it loses generality, but to compensate it often accretes unguessable magic, which leads to yet more complexity.

when you start with something simple but special purpose, it inevitably accretes features that attempt to increase its generality, as users run into its limitations. But the result of this evolutionary process is usually a complicated mess compared to what could be achieved by designing for generality up-front, in a more holistic way.

you resort to complex hacks to subvert its limitations or combine it with some other special purpose technologies

One problem is that a person can spend years reading analogies about black hole evaporation, quantum teleportation, and so on. And at the end of all that reading they typically have… not much genuine understanding to show for it. The analogies and heuristic reasoning simply don’t go far. They may be entertaining and produce some feeling of understanding.

good tools for thought arise mostly as a byproduct of doing original work on serious problems

URLs are not democratic.

A mixin class is a parent class that is inherited from - but not as a means of specialization. Typically, the mixin will export services to a child class, but no semantics will be implied about the child "being a kind of" the parent.

Unlike the web, the classic desktop computing paradigm makes a distinction between apps and files. The default way for a desktop app to save data is to save it to an external file.

Because integrations are part of the application code, the developer of the app is responsible for integrating that app with other tools

One-off API integration doesn’t scale

For example, the range of sin is only defined for values [-1, 1]

It’s worth noting that runtime errors can be avoided with systems like a static type checker, pushing the problem into compile time. The result is that your program is often in an in-between state where it won’t even start until all errors have been resolved

You can still easily get an unexpected result, but you’ll always get some result. In our experience, this approach promotes tinkering and feels much closer to sketching than to programming.

If you find a published item of a type your system has never seen before, your system loads the item with the item view that the publisher included