Hacker News new | ask | show | jobs
by al2o3cr 3305 days ago
Isomorf seems like a great way to write Isomorf code in many languages, in much the same way that you can "translate" Lisps to any language by writing a tiny interpreter. If you can push one button and get either Haskell or Javascript, either weird Haskell or weird Javascript is likely coming out.

Further, watching that video I was reminded of using the Equation Editor in Word long long ago. Frightfully un-ergonomic pixel-fiddling ("no, I meant put the insertion point INSIDE that expression!") compared to entering the same formulas boring-ASCII-style in LaTeX.

    For example we will get structured version control. No need to have something like git tracking lines in files.
If there's "no syntax", what exactly is this showing diffs of? ASTs? "We will get" is handwaving a lot of R&D here, even before you get to "how can Programmer A communicate about a diff to Programmer B when they read the code with different syntax?"

I don't see a huge difference between things like "tests embedded in metadata" and "tests embedded in comments"; they're both blocks of associated bytes that tooling is responsible for interpreting. Many of the examples you're describing are entirely possible with things like static analysis, annotations, etc. The difference is that in order to get them we didn't have to throw away EVERY tool we were using and start over. Bootstrapping a new non-text environment would be a substantial effort, and doing it without ending up in the same spot as M-expressions (where an intended for-machines-only representation displaced the more-complex planned notation) would be even harder.

I'd recommend checking out some of Joe Armstrong's stuff - he's been pondering the "global registry of functions with unique name" thing for a couple years.

2 comments

With regards to the "diff" which I forgot to address earlier.

The changeset still has a textual representation.

So the diff could be like a webpage that is showing:

On 5 June 2017 John Smith authored the following changeset:

- Added new function that calculates sum of given numbers (click to view)

- Removed function called "old calculate sum"

The program is not the syntax the syntax is just a representation of it.

So if I have added a new function we can both look at the diff.

We will both see that I have added a function.

We could both choose to view the body of the function in the same syntax, or you could configure your editor to show it in a different way. In the same way that you could configure the font size or the colour scheme.

The point is to reduce the importance of things that are not inherently part of the domain and give that importance to the problem/domain itself.

So you could view a "number node" like "5,000,000" and I could view it like "5_000_000".

I could view a function definition like "declare function named blah" you could view it as "def fun blah".

Because we are still looking at the exact same thing it makes no difference in the result of the program.

It will be something close to an AST.

"syntax" is the textual representation of an underlying structure.

When all of our tooling revolves our modifying text/syntax not the underlying structure we make our lives very difficult and create new "artificial" problems with regards to parsing/extracting and so on.

A sufficiently good editor could make the experience even better than a normal text editor.

The crucial difference is that there's no such concept as "lines" or "files". But it could visually almost represent it to you in that way.

So you would type "let x = 1;" instead of it saving those characters in some file it would modify the program/tree and add a node that represents the fact that "assign 1 to name x".

As I also stated I know many of the things I have mentioned are already kind-of possible with the tooling that we have but they are bolted on in such a way that is disconnected from other components so we lack a more global view into a system as a whole.

This creates little isolated/disconnected worlds within a system and significantly reduces the potential and benefits of things we could do.

It also reduces accuracy to a level that you always have to have your guards up and can't fully trust the system. It turns into a helpful heuristic but not a first-class part of the system.

It is one thing to be able to "parse all of this crap and extract these blocks of characters that we think are the documentation" vs having strong accurate links established so that the entire system is capable of querying navigating metadata associated to objects.

Tests and benchmarks and documentation and all sorts of stuff can become first-class citizen objects in a programming language and the compiler and tooling gets exposed to that information it can suddenly start helping you a lot more than it is otherwise able to when it has no view into that stuff (i.e. compiler ignoring the comments).

Lots of things that are today very cumbersome and require sophisticated parsing and so on become very easy because you don't have to parse/compute stuff, information about the structure is readily available and queryable.

For example all your "logging" stuff could simply be tagged as "log".

Then when you are compiling you could say "take out all function calls tagged as log as if they didn't exist".

Again there's a huge but yet subtle difference between that and what we are capable of doing today.

We today we have ways of kind-of achieving the same thing by #ifdef compile constants and so on but one is inherently semantic and logically sound the other one is just arranging a sequence of side-effects to achieve a desired effect without exposing that insight to the compiler/environment itself.

That difference is the essence of intentional programming.

The system allows you to express and preserve your intent in its original semantic form that is the blueprint for the software that is produced from it.

If you are interested to learn more about this topic you can watch some of Charles Simonyi's presentations on YouTube on this topic, they are long but worth a listen.

https://www.youtube.com/results?search_query=charles+simonyi