[benjaminjosephw]

Exactly. A paradigm shift implies new mental models and new metaphors for our abstractions that might not be valuable to people who think our current abstractions serve us well.

A great example of this is the fact that we still use the metaphor of files and folders for organizing our source code. The Unison language works directly with an AST that is modified from a scratch file[0]. For people committed to new models of distributed computing, that makes sense; for everyone else, it might be seen as an idea that messes with their current tooling and changes existing and familiar workflows.

I think the really big leaps forward are going to go well beyond this and they will look like sacrilege to the old guard. New programmers don't care if a programming language is Turing complete or if the type system has certain properties, they only care about working software but existing programmers are dogmatic about these concepts. I think the next leap forward in programming is going to offend the sensibilities of current programmers. Having to break with orthodoxy to get a job done won't worry people who don't know much about programming tradition to begin with.

[0] - https://www.unisonweb.org/docs/tour#-to-the-unison-codebase-...

[giantDinosaur]

Perhaps. Or it'll be like civil engineering or something, where the fundamental principles really stay similar even as technology/theory dramatically improves.

[_8ljf]

“I think the next leap forward in programming is going to offend the sensibilities of current programmers.”

Honestly, programmers have been railing against progress ever since the first machine coders shook their canes at those ghastly upstart programming languages now tearing up their lawns.

Meanwhile, what often does pass for “progress” amounts to anything but:

https://fermatslibrary.com/s/the-emperors-old-clothes

--

“It’s a curious thing about our industry: not only do we not learn from our mistakes, we also don’t learn from our successes.” – Keith Braithwaite

[xorcist]

> we still use the metaphor of files and folders for organizing our source code

We don't use the metaphor for storing things. What we use is an hierarchical naming scheme. This makes sense for a number of use cases, and has been independently discovered multiple times through the short history of computing.

You may call the nodes files and folders. It is however just a word, a parable for the underlying data structure, which is the physical reality. You could just as easily call it something else. And many people, whose first language is different from yours, probably does.

[zupa-hu]

Wow, thanks for sharing Unison, seems super interesting! I've been thinking about content addressed code compilation lately that could allow one to have all versions of a program within a single binary. Apparently there are other benefits to it. Can't wait to learn what they have discovered!

[brabel]

I've played a little bit with Unison and it's definitely very interesting and a little bit of a new paradigm (some people compare their "images" to Smalltalk images, but I think they differ enough to be considered as distinct paradigms)... but they're still working on very basic things, like how to enable people to do code reviews when the committed code is an AST, not just text... and how to actually distribute such software (I asked in their very friendly chat but apparently you can't run the code outside the interpreter for now, which I think is written in Haskell)... also, the only help you can get writing code is some syntax highlighting, even though the ucm CLI can display function docs and look up functions by type, for example, similar to Haskell's Hoogle (but in the CLI!!). ... so just be aware it's very early days for Unison (and they do make that clear by "forcing" you to join the #alphatesting Slack chat to install it, which is a great idea IMO as it sets expectations early).

[tabtab]

Re: "A great example of this is the fact that we still use the metaphor of files and folders for organizing our source code."

I agree 100%! Trees are too limiting. I'm not sure we need entirely new languages to move away from files, we just need more experiments to see what works and what doesn't, and add those features to existing languages & IDE's if possible. I don't like the idea throwing EVERYTHING out unless they can't be reworked. (Files may still be an intermediate compile step, just not something developers have to normally be concerned with.)

I believe IDE's could integrate with existing RDBMS or something like Dynamic Relational, which tries to stick to most RDBMS norms rather than throw it all out like NoSql tried, in order to leverage existing knowledge.

Your view of source code would then be controlled by querying (canned and custom): bring all of aspect A together, all of aspect B together, etc. YOU control the (virtual) grouping, not Bill Gates, Bezos, nor your shop's architect.

Most CRUD applications are event driven, and how the events are grouped for editing or team allocation should be dynamically determined and not hard-wired into the file system. Typical event search, grouping, and filter factors include but are not limited to:

   * Area (section, such as reference tables vs. data)
   * Entity or screen group
   * Action type: "list", "search", "edit", etc.
   * Stage: Query, first pass (form), failed validation, render, save, etc.

And "tags" could be used to mark domain-specific concerns. Modern CRUD is becoming a giant soup of event handlers, and we need powerful RDBMS-like features to manage this soup using multiple attributes, both those built into the stack and application-specific attributes/tags.

[goatlover]

Then why hasn't this happened over the past 40 years? That's more than one generation of programmers over a whole lot of change from mainframes to PCS, the web, mobile devices and cloud services with thousands of programming languages and tools being invented over that time, but mostly it's incremental process. PLs today aren't radically different than they were in the 60s. It's something visionaries like Alan Kay have repeatedly complained about.

[benjaminjosephw]

New paradigms emerge when people think differently about the problems to solve or try to solve new problems. It makes sense to me that it might take more than one generation of people working on a similar set of problems before we have significantly different solutions.

[waheoo]

> Unison language

There goes my Christmas break.

Thanks.

[renox]

I wonder why they created their own language over creating a tool over Go for example.

[PaulDavisThe1st]

> A great example of this is the fact that we still use the metaphor of files and folders for organizing our source code.

I think there's something akin to a category error here.

First, let's agree that we do want to organize our source code to some degree. There are chunks of source code (on whatever scale you prefer: libraries, objects, concepts etc) thare are related to each other more than they are related to other chunks. The implementation of "an object" for example consists of a set of chunks that are more closely related to each other than they are to any chunk from the implementation of a different object.

So we have some notion of conceptual proximity for source code.

Now combine that with just one thing: scrolling. Sure, sometimes when I'm working on code I want to just jump to the definition of something, and when I want to do that, I really don't care what the underlying organization of the bytes that make up the source code.

But scrolling is important too. Remove the ability to scroll through a groups of conceptually proximal code chunks and I think you seriously damage the ability of a programmer to interact in fundamentally useful ways with the code.

So, we want the bytes that represent a group of conceptually proximal code chunks to be scrollable, at least as one option in a set of options about how we might navigate the source code.

Certainly, one could take an AST and "render" some part of it as a scrollable display.

But what's another name for "scrollable bytes"? Yes, you've guessed it: we call it a file.

Now, rendering some subset of the AST would make sense if there were many different ways of putting together a "scroll" (semantically, not implementation). But I would suggest that actually, there are not. I'd be delighted to hear that I'm wrong.

I think there's a solid case for programming tools making it completely trivial to jump around from point to point in the code based, driven by multiple different questions. Doing that well would tend to decouple the programmer's view of the source as "a bunch of files" from whatever the underlying reality is.

But ... I haven't even mentioned build systems yet. Given how computers actually work, the end result of a build is ... a set of files. Any build system's core function is to take some input and generate a set of files (possibly just one, possibly many more). There's no requirement that the input also be a set of files, but for many reasons, it is hellishly convenient that the basic metaphor of "file in / file out" used by some many steps in a build process tends to lead to the inputs to the build process also being files.

[the__alchemist]

I wonder if these's a way to deal with these concerns with a different visual approach that's better than files. I haven't seen one, but am still curious. Jetbrains' IDEs code navigation (ctrl+b to go to definition etc) are a step in that direction, but ultimately, the scrollable areas are still separated into files, even though you can navigate between them more directly.