I don't follow your comment or what you're disagreeing with, and that makes me wonder if I understand the tweet. But IMO:

• SaaS just going by the term doesn't have to encompass the entire world, and yet the examples of it we see around us are all trying to do that. Perhaps the problem is more the culture we're surrounded by, to maximize adoption and profit.

• Selling native apps for single users can also fall into the same trap, but they don't have to. The scaling here isn't in the runtime behavior but the deployment and life-cycle management.

• Open source also falls into this trap, with everyone trying to gain market-share by accreting features, shipping binaries, discouraging others from forking, etc.

Not sure if this clarifies or muddies things further..

I was just trying to grasp at the tweet’s meaning, and was taking a guess. I still don’t know. Apps are thinking too big?

You seem to get the author’s meaning of “encompass the world” - so I’ll just stand aside for others’ conversation.

Kartik Agaram What you are describing sounds more like a problem of today's attention economy than of scaling in the technical sense that I attribute to this term in computing. In a global attention economy, there is space only for a few well-known players in anything, be it tech, art, or whatever else.

I'm also in the "not sure what the original tweet means" situation, but if I take it to be "having one giant Facebook for the whole world is maybe bad", then 💯. But is that a "computing" problem or more of a human nature/network effect problem?

Yeah, we can probably improve on calling it 'scalability'. I see it as an aesthetics problem, and the urge for one single service provider feels like it stems from the same source as wanting to optimize the big-O and so on.

The pain of culture clash: not speaking remotely similar languages.

Nitpicking: the criticism of fractals is a bit superficial. People working with fractals in science are well aware that a fractal is a mathematical idealization just like the infinitely small point of geometry. They do discuss the upper and lower limits of scaling behavior. Fractals remain a useful concept in spite of their limits. For examples, see Geoffrey West's book "Scale".

Konrad Hinsen Sounds like you didn’t come across the next paragraph in the article then. :-)

Worse, I commented your excerpt before reading the whole article...

I also like it a lot! And I would like to play with this... Does anyone know if there are some RealitySketch software/code somewhere?

I would love to have this kind of interaction in a programming environment. I guess I will try to add it at some point in my future work.

this is the most exciting thing i’ve seen in AR

This reminds me of Joel Spolsky's blog Don't Let Architecture Astronauts Scare You.

The fact that there are three distinct English words "deleting/closing/stopping" suggests to me that users will have no trouble remembering and repeating these different actions.

An abstraction is useful when we want to operate at the level of the abstraction, across different implementations. How often are users going to want to delete a line of text at the same time as close a network connection or stop a process? Very, very rarely imo.

https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/

When great thinkers think about problems, they start to see patterns. They look at the problem of people sending each other word-processor files, and then they look at the problem of people sending each other spreadsheets, and they realize that there’s a general pattern: sending files. That’s one level of abstraction already. Then they go up one more level: people > send>  files, but web browsers also “> send> ” requests for web pages. And when you think about it, calling a method on an object is like sending a message to an object! It’s the same thing again! Those are all > sending>  operations, so our clever thinker invents a new, higher, broader abstraction called > messaging> , but now it’s getting > really > vague and nobody really knows what they’re talking about any more. Blah.

When you go too far up, abstraction-wise, you run out of oxygen. Sometimes smart thinkers just don’t know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don’t actually mean anything at all.

That excerpt should end with, “and then they have truly become mathematicians.”

Yeah, but our job as programming tool developers is precisely to climb that mountain and stop in the right place. That's how all our programming abstractions got started, starting with lambda. And while programming tool design is very similar to math on one side, it's very similar to OS design on the other, with both focusing on possible actions a user can take, specified in digital form, to accomplish a goal, plus all the overlap in runtime design.

There’s time for engineering and there’s time for science. The key is to know when to use which.

Chris Knott I can only surmise from this reply that you did not read the paper. Nonetheless, as a sign of good will, I made you some art inspired by the phrase "architecture astronaut"...

I read it, although perhaps I misunderstood it if you are suggesting this response is not relevant...?

You said "How often are users going to want to delete a line of text at the same time as close a network connection or stop a process?"

He makes no suggestion that they would. Instead, he talks about using a conceptually similar framework for interacting with the many databases that are maintained by the operating system, which would mean that when one seeks to perform an action they would have less cognitive work to do in order to figure out how to complete their desired task.

This is in spirit similar to how Plan9 improves upon the Unix model by using the file API to interact with various system and non-system services.

I didn't mean to suggest that the author proposed that, that was my own thoughts on when such abstractions actually have practical use.

As in; when tested against my personal rule of thumb for whether an abstraction is a good idea, I don't believe these suggestions pass it.

I am assuming the original namers of, for example, files, folders and pipes, chose these names because they felt their behaviour was naturally analogous to physical files, folders and pipes. In the real world a notepad and a pipe are very different things. Nobody thinks "hmm, writing in this notebook is really the same operation as sending water down this pipe". This is not a useful thought for anyone to have.

To be clear, I am an architecture astronaut by nature, the aesthetic attraction of a unifying abstraction is very strong for me, but I don't believe it makes the system more practically useful. It's something I have tried to train myself to fight

Really cool video Shalabh Chaturvedi, thanks for sharing!

I really like this slide 👇

Heh yeah I recommend all the videos on http://subtext-lang.org for other gems.

The most used languages don't support the real world, and especially not "functional" languages (without a lot of piping).

I believe that event emitters can potentially be composable, it just depends how you set them up. There are a lot of ideas in the data-oriented paradigm (often used in game dev) which have been by far the most composable approach to integrations, I've ever experienced.

I'm glossing over some assumptions being made about what an "event emitter" is, exactly, but in our case it's essentially something modifies a row in a shared DB, and something else was directly listening to that row to change. For example "when my postmates order arrives"

The key to this approach is that everything is talking together in the same "DB", and we're enforcing visibility. There was an interesting programming language just announced that goes in this direction: https://www.reddit.com/r/ProgrammingLanguages/comments/ik0w0q/tablam_a_experimental_relational_language/

I think at least one version of Eve also had a similar story going on

also—can’t you model event emitters with observers? which can be modeled with functional reactive programming? which can be implemented with pure functions? so you can compose in the same way?

I guess I’m a bit fuzzy on the details of what separates/defines “integration” vs “composition”

Garth Goldwater, yeah. Good point. I wonder if Aria Minaei meant something more specific.

integration vs composition: I'm not entirely sure. It makes me feel like composition is like swallowing the other service like a library, while integrations are the icons on your landing page.

integration vs composition: I'm not entirely sure. It makes me feel like composition is like swallowing the other service like a library, while integrations are the icons on your landing page.That's how I picture it too.

An example of "integration-style" programming that I deal with often, is the Node.js-style https://nodejs.org/api/events.html#events_class_eventemitter where there isn't much of a principle in event ordering, concurrency, propogation, scheduling, etc, and the topology of dataflow is more emergent rather than explicitly designed and very hard to debug. It is still possible to compose things that use EventEmitters, but it's just not ergonomic.

The composable counterpart to EventEmitter would be an FRP-style Observables like those in https://rxjs.dev/guide/overview. Observables there are just generalizations over functions and get the benefit of functions, such as recursion and explicit scope.

Another example of composition over integration (again from the JS world, sorry 🙂) is React vs, say, jQuery.

In jQuery, there is a global namespace that is the DOM tree representing the HTML document, and interactivity is peppered on top of individual html elements, like: $('ul').reorderable() (this is supposed to turn all <ul> lists into lists that the user can re-order by drag/dropping their items).

But as soon as you need to nest two re-orderable lists, the code becomes quite awkward, especially if one list can create more lists inside itself. It is not impossible, just hacky.

Compare that with React, where a <ReorderableList> is just a component, which are themselves a generalization over functions. Suddenly it becomes easy to write and use nested lists like so: <ReorderableList>...<div><ReorderableList>....

In integration, things have IDs that have to be book-kept. In composition, things are addressable through their position in the topology (parent can reference a child without having to assign a global ID to that child).

(though topology doesn't need to be hierarchical in a composition).

Aria Minaei, are you familiar with using data-oriented programming? Esp that used in game development with entity-component-systems?

In a composition, the lifecycle of things is again managed by the topology. If a thing is no longer needed, it is removed, similar to how values on a function call stack get freed after the function is done running.

In react, componentWillUnmount() gets called. In refcounting, some sort of object.free() gets called.

are you familiar with using data-oriented programming? Esp that used in game development with entity-component-systems?@Cole Lawrence Haven't used ECS in anything bigger than a toy, so not very familiar.

You might find this sort of intro to ECS interesting. It's not super Rust heavy, so the concepts are the focus https://www.youtube.com/watch?v=aKLntZcp27M

Essentially, data oriented tech is all about the state of the world is accessible by all systems, and each system will look at the data in the world to make a decision to make an update or not based on what they see. Kinda like the https://en.wikipedia.org/wiki/Blackboard_(design_pattern).

But, in this way each system can be written in a pure functional way with effects coming into the top of the funnel

You might find this sort of intro to ECS interesting.@Cole Lawrence Thank you! I was actually building another ECS toy yesterday and looking for a good intro.

I love going back and looking at this stuff, and I’ve been thinking a lot about what a modern text-focused interface would be like. It feels like there’s a bunch of neat stuff we should be able to do now that just wouldn’t have been feasible at the time. It’s especially interesting to imagine using something like GPT-3 to get the interface to react to you much more naturally than it would otherwise.

Jack Rusher you mentioned you worked on lifestreams! I’d love to hear more about what you learned in that experience. It was the primary model we wanted for history and search for Eve, we just never got to the point where it was time to invest in it.

Chris Granger Not on Lifestreams, but rather on a similar system in the context of a startup a long time ago. That was what led me to write the first purpose-built Semantic Web-style Triplestore. The sort of "global personal assistant" was scraping data from email, contacts, appointments, browsing, &c, and storing everything it learnt in a per user TripleStore to allow inferences, lookup, and so on. There was a temporal aspect to the data which allowed one to make "what was that website I visited about topic X within the last week?" sort of queries.

One reason these things are salient for me is that my computing path was unusual: I went from little 8-bit micros directly to Unix machines (first terminals, then workstations) in the mid-80s. Consequently, my formative history with GUIs included oddities like NeWS, X, Plan9, NeXTSTEP, and a couple kinds of Lisp Machine, but mostly did not include Macs or PCs.

Jack Rusher your “similar system” to lifestreams is an accurate description of at least four separate projects in this community—if you have any write ups or talks or posts about that experience anywhere lots of us would read or watch with interest!

The only surviving artifact from that project is a paper I delivered to the W3C in '02 or '03 about the TripleStore implementation. OTOH, my personal knowledge management system is basically a more advanced version of many of those ideas, and I already plan to do some show-and-tell about that when I can fence off enough time to do it properly.

I've always liked the term "low code", even though it essentially suffers from the same failing. It better communicates what a service is trying to do.

My favorite example is Excel, the world's most valuable programming language, but it does always feel like coding which I think is important

imo this isn't a very sophisticated take on the topic. The label is so wide and being applied to so many things, it's kind of meaningless to discuss without specific examples. Critique of the hype and broadness of the label itself might be useful in the context of a wider analysis but this doesn't have that either.

yoshiki Perhaps I was being too generous, but I took it to be precisely a criticism of the most extreme claims (and thus hype center) around these systems.

Nosyntaxerrors doesn't have the same ring to it

I agree this kind of tweets from popular people help reframe the actual meaning or goals. My feeling is that Gary only reminds that some people hope that nocode systems will hide all complexity, which is not possible when you design, well, complex system.

Many people run old, simple operating systems in emulators or sometimes directly on hardware. For example, my friends at Hundred Rabbits are currently using Plan9 on a Raspberry Pi as their primary development system:

https://twitter.com/hundredrabbits/status/1290361357888417793?s=20

There are definitely some who still use Plan9, and its editor Sam.

Guess there are Amiga folks too.

VMS had a great deal going for it. Just as one example, files were named in a conventional way, like FOO.TXT, but with an extra piece of metadata at the end: FOO.TXT;1. Whenever one changed a file it would create a new file with the number at the end incremented: FOO.TXT;2. A directory listing would show all versions. One could open any version by including the version metadata in the filename, and opening a file without a specific version number would just open the most recent version. One could also delete specific versions as desired while keeping other versions around, like a simple revision control mechanism built into the filesystem.

Other things, like fault tolerant clustering, load shedding, disk quotas, and so on, also worked very well. TBF, there are many reasons one might consider the victory of Unix over VMS a worse-is-better thing.

OTOH, the VMS C compiler was terrible (leading me to write hundreds of thousands of lines of VAX Pascal) and the command line language (DCL) lacked the grace of using pipes under Unix.

Electric cars in the 1930s and Segway "failed", but now battery tech is forefront - failure is manifold, mostly due to a scale factor

Probably because it was on HN recently, https://www.popularmechanics.com/science/a33896110/tiny-nuclear-reactor-government-approval/ comes to mind. I think there are a class of technologies for which this is true. It's a case of incremental improvement vs. fundamental new understanding.

The former is much more common because it's "easier to reach in the search space." I think this is another way to state "failure is manifold" from Christopher Galtenberg's comment.

I don't think all future technology can be predicted this way. There is a class of technological evolution that breaks out of such local optima. Using the nuclear example again, the shift from combustion to "understanding and harnessing of the atom", was such an event.

Marc Andreessen a few years back: "there are no bad ideas, only bad timing."

https://a16z.com/2020/01/30/neighbor

https://samypesse.gitbook.io/pmarca-notes/ideastiming

Also available on YouTube: https://www.youtube.com/watch?v=9qtd8Hc90Hw

The plane and teleporter of the “alternate reality kit” at 9:20 is magical