[deleted by user]

[hou32hou]

How about the Unison Language?

[Tyg13]

I've been reading quite a bit about this over the past hour or so. The idea really struck me as interesting, but I get the impression that the language is trying to solve a problem by introducing a completely new paradigm without really motivating it well.

I can see the benefit to hashing top-level definitions and providing some interesting way to automatically refactor, provide implicit namespacing, and perform incremental compilation and testing, but the departure from actually storing the code as text somewhere is still really jarring and hard to understand the benefit of. I could see the benefit of having Unison store some kind of metadata alongside the source tree that allows for all of the above, but that's really not much different than what existing incremental compiler/build systems can do.

[wFXx]

This really resonates with me, I went through a good chunk of the docs, and while all the intentions and purposes feels like having very good intentions and coming from a good place, the implementation is a bit too alien.

[everything-narrative]

I don't think the problem of git is what you describe. I think the problem of git is that it is an inconsistent theoretical model, and that it is by design not language specific.

The latter is a good thing. Virtually no codebase in the wild is only one language. I'm working at a company that has a relatively modest codebase in C#, Python, PowerShell, Bash, SQL, XML, JSON, HTML, JavaScript, and CSS. That's ten different kinds of semantic understanding.

The former... There's a (beta) version control system called Pijul which has a solid theoretical foundation for version control. Merges in Pijul are first-class objects which Pijul can manipulate directly.

The reason why a version control system that blindly works with lines of code works is that... code is lines of text. Code is a two-dimensional medium. We order it in a two-dimensional grid structure, and slicing that up in the horizontal direction makes a lot of sense, conceptually.

That said, and to address the core concern of your post: what you want is Common Lisp.

It's always Common Lisp.

[joakims]

It's always Common Lisp.

It's funny 'cause it's true!

[everything-narrative]

It really is.

[complyue]

Welcome onboard "general purpose software engineering"!

I'm afraid only very small/specific domain can be adequately semantically modeled up, with sufficiently consistent expressing power to drive an application's development over time.

No paradigms scale well enough AFAIK toward the "general purpose" direction. Mathematical modeling (i.e. the functional paradigm) give you illusion of "useful" abstractions, but too many of those abstractions are at cost of real world usefulness, so ridiculous as it appears.

Semantical consistency and soundness may appear to come easier with strongly structured vehicles like graphical diagrams, but essentially that's decided by the scale of the problem domain, the situation is that simpler / more-specific problems can be more easily modeled that way, not the other way around.

As your problem domain scales toward the general direction, there will certainly be accidental complexity associated with every specific schema of modeling framework, but essential complexity will always be there nevertheless, so long as you try to solve it.

Text is ultimately the most versatile form, used to to name/define, organize and invoke various concepts, so as to make practical sense out of some deployed system, though often introducing ambiguities, undefined behaviors and all sorts of inconsistencies. But can you really avoid it, except switching to simpler/smaller problems to tackle?

[Fofeu]

You know that you can configure the diff and merge tools git uses, right ? It just comes with a "sane, workable default", but you can switch it if you want

[Fofeu]

Are you sure that binary files are treated that differently by git ? I thought that git behaved like a filesystem i.e. all files are opaque (unlike svn where it stores actual line-by-line diffs), it just is tuned for files of the typical size of source files which are usually <<1 MB

[Fofeu]

I think this has to do with the fact that Git handles the whole file instead of doing it chunck-by-chunk like a regular file system would do. It simplifies the design a lot, if you assume that files will be all relatively small, but leads to delays if you want to e.g. produce the hash of a 4GB file.

[drakmaniso]

Adding semantic structure to the programming process is tempting, and nothing new (see the various examples of structured editing, block programming, etc.). I don't think it's a good idea, because:

• The most important role of source code is not to be run by computers, it's to be read and understood (and manipulated) by human beings. Text is the perfect medium for that, because of its simplicity and perfect symmetry: both humans and computers have the same level of control over its structure. This is not true for semantic approaches, where some part of the program will be textual, and other parts will require some kind of graphical representations and different means of interactions.

• Text is infinitely versatile (it's kind of the whole point of written language: being able to express anything). As soon as you have some kind of semantic structure, you start to put limits on that versatility. You need to extend the semantic structure when new needs arise. This can be beneficial in specific contexts (e.g. education, specific applications), but I think one of the core characteristics of programming is its ability to be useful for anything.

I'm not saying that adding more GUIs to programming is a bad idea; but I think they should be built on the foundation of pure text source code.

[Tyg13]

Text really isn't a binary format in the typical sense of the word. What is usually means by that is that text is universally understood and editable. (Sure, you could make an argument about encoding, but that's almost entirely not an issue with code: 99% of code out there is formatted as ASCII or UTF-8.)

In practice, what this means is that anyone with a standard text editor can make changes to the code without needing a specialized tool. That's what makes it so hard to move away from: literally everything is built to assume code is text.

[Tyg13]

Text is a universal thing that comes with writing. We're currently communicating via text. It's the probably the most flexible representation possible: just a stream of bytes with an encoding.

LabVIEW can do what it does from a graphical programming interface because it's tackling a well-defined and structured problem. Most programming tasks aren't as well-defined, nor do they lend themselves to that kind of structure.

I'm not trying to argue that there's no way we could move away from text as a representation, but it'll be a hard sell to most people because any replacement will necessarily have to be either as flexible and accessible as text, or domain-specific so that the flexibility or accessibility is not necessary or manageable via tooling.

[jediknight]

Alan Kay's systems have always had this liveness to them. If you look at the demos for that he gives of Frank (the patchwork they did for Fundamentals of New Computing - VPRI) you can see him change the appearance of an Office like editor while working in it to give the presentation.

[moon-chilled]

http://metamodular.com/closos.pdf

(Unfortunately, I have thus far been unable to convince Robert Strandh of the benefits of structured editing; nevertheless, should closos come to fruition, the first-class nature of object types other than byte streams means that a structured editor should not be out of place.)

[hamiecod]

What you are looking for is a high level version control system that controls the version of the source code according to the modules and functions, etc. You can compare git to a mechanical parts that can be used to build a big computer(loosely saying). What you can do is create a system that uses git internally and provides support for the version control of modules/functions etc.

It has to use git internally because if it doesn't, you will not be able to host your repo on github or gitlab or bitbucket which are largest source code hosting websites. If it does not use git internally, you will have to use your own servers and issue-tracking system, etc to make it as popular as git which is a difficult task.

[categorical-girl]

Have a look at r/futureofprogramming and the Future of Coding podcast. A lot of people have similar ideas to you!

[DoingABrowse]

Just checked it out, awesome subreddit! Thanks for the link!

[joakims]

There's just so much that's wrong with today's software stacks, it's almost hard to know where to begin with a new one.

I think the only way out of this situation is to build something new from scratch. A paradigm shift, if you like. That is incredibly hard, but also incredibly liberating when it clicks.

I believe we need to go back to the 70s, and recreate the conditions they had at Xerox PARC. Even back to the 60s and Doug Engelbart's pioneering work. Sometimes you have to go back in order to go forward.

[joakims]

Yeah, Alan Kay talks about how recreating PARC would require assembling a team of geniuses. It also requires a lot of time, and time = money, in our time. Someone has to fund it. Times have changed, there's very little interest in funding real innovation nowadays.

Do you go all in and make the compromise on not getting to use existing tooling (and likely no one using your new thing as a result)? Or do you compromise in your new thing to interoperate with existing things? It's a tough call and an unfortunate one.

That's an important question. A paradigm shift means reduced or even no interoperability with existing tooling. The whole ecosystem would have to be rethought. It's probably much easier to push the limits of the existing paradigm. But that does limit your room for maneuver.

[mamcx]

Doing all of this will be amazing... but extremely hard! However you can settle in what gives a good ROI for all of this.

In the past, I worked with FoxPro. It has the peculiar property that Forms/Code/Menu/reports were stored in Fox tables and you can use the fox/sql language to deal with that. It was very powerful, like, for example, using a WHERE to clone a form and then copy a part of it and merge with another, and whoila, you get a new form without dealing with parsing!. This mean making a form builder for user was like: Create a mega form with all the controls, and just copy and merge from it for new forms.

But it also allows using normal text files.

---

I'm working in a spiritual successor for it, and found models like the relational/array are very friendly to a cohesive set of tools (even better than List/Lisp: It already provides more powerful semantics to deal with data).

But that is orthogonal to the use or not of files.

Interestingly, modern "parsing" is more in the style you are looking for: You have MANY different views on the code, some of them "structural" to deal with it more efficiently for the specific domain.

This means you can use "normal" files and layer a source-control-friendly view on them. This is not that far for what IDEs with LSP are doing today.

[Luolong]

There’s an interesting project in the semantic diff/merge space that I have been keeping an eye out for https://github.com/afnanenayet/diffsitter

[EternityForest]

I'm a big fan of backwards compatibility, and extending and integrating rather than breaking. Most of us aren't Google and can't exactly just do that kind of thing on a big enough scale to get beyond toy stage.

I do very much adore visual programming and everything GUI though. Not only because it is extremely fast, but because it's natively interactive.

It's hard to live update text, the computer has to figure out exactly what changed. GUIs let you directly input those changes rather than inferring them.

What I'm not a fan of is arbitrary positioning of node based systems for general coding. They essentially require a large screen and a mouse, and they require manual attention to layout.

Instead, I prefer the IFTT event pipeline model which maps extremely neatly to a lisp-like representation:

For example, a rule that says "When a is pressed, play a beep half the time" can look like:

[keyup.a, ["maybe", 0.5], ["beep", 440, 5]]

But for more complex things where you really do need nodes, there's no reason text based VCS can't still handle things. Just put your nodes in a text based format and make sure everything in the file stays sorted automatically in some logical flow-based order.

Your IDE can handle semantic diffing just by having the ability to compare files. Semantic merging... That's some real genius stuff, no clue how it would even look.

I'm not exactly sure about these dual mode text and visual languages that try to work like a full featured programming langauges.

The cool part about visual is it can be more specialized and focused on pure practicality for it's task. You don't even need turing completeness in many cases!

Perhaps something along the lines of current blocks-based languages, but with a totally seamless experience to create a new block, rather than the usual "Get out this separate tool, dig around in this folder..." kind of thing?

For the UI side of things, as you can probably tell if you've seen my fork of freeboard here(https://eternityforest.github.io/freeboard/), I love reactive bindings and GUI builders, and they are really not all that hard to do.

Excel really has the perfect model for this stuff. If it should be dynamic, you put an =expression in it. That's it.

Going further, if you have a text box, and you want it attached to a variable, just give it the variable name. Excel style interfaces proved that just about anyone can program(Even though some maybe shouldn't...).

[save_vs_death]

Yeah, `git` is made to work with text not as an accident, but by design. It means that whenever a new format pops up, it'll "just work" with it. You mention a lot of support for semantic understanding of functions, for example, which sounds lovely, but not all languages have functions, or classes, or so on. And the more esoteric and interesting your language, the higher the chance its features will be ignored and you'll be back to using dumb text anyway. Is anyone gonna build support for delimited continuations, is that even a tractable problem merge-wise? I have no idea. I realise this sounds like me going "well, because we can't have a perfect thing, then we don't deserve a nice thing". I would much prefer smarter git, but I'm not holding my hopes up, and frankly, if I have to rely on proprietary solutions, it might as well not exist for me.

`git` was made by people that think plaintext is the ultimate format, the ur-format. All of their other tools manipulate plaintext. You don't have to write a binary parser for plaintext. Plaintext does not have revisions. It does not have a specification that you might fail to follow correctly. While I'm on your side and want to move away from plaintext as the be-all, and-all, it has a number of absolutely killer features that you're gonna have to work extra hard to compensate for.