Comment by kettlecorn | Hacker News Reader

Comment by kettlecorn | Hacker News Reader

A few advancements that could be very good:

* Moving towards representing code on disk as an abstract syntax tree, and anyone can edit with whatever syntax they prefer. Syntax becomes virtually irrelevant.

* The above point opens the possibility to represent code as visual graphs (even to code within virtual reality). Graphs and visual programming are useful, but to be able to toggle between textual and graph representation gives you the best of both worlds.

* Smarter compilers. For example: easy to use compile time constraints. Think about the ability to specifiy something like the minimum value an integer can be set to. This could allow the compiler to produce compile time errors for things like index out of bound errors, with zero runtime overhead. More complex constraints could be user defined. The mindset of programming could move to thinking about how you can do as much as possible at compile time.

* The ability to embed documentation alongside code. For most codebases the ability to understand the code is part of value of the code. Comments don't go far enough, particularly when working with visual concepts. Being able to embed readily accessible documention within the code could help dramatically.

> Syntax becomes virtually irrelevant

This is probably a big mistake. Code must communicate ideas. Communication requires a shared language. A language has syntax, not just semantics. A given semantics has only a few natural expressions as syntax.

Can't pair program, can't program during a talk or a stream, etc. without that shared language.

If anything, we should be looking at the reverse of what you said: reading code is more important than ever due to the scale of programs, so we should be looking into creating the most readable language ever.

Edit: I think overloadable and definable operators can be very useful (like Haskell, OCaml), and that's probably as much syntactic flexibility as we need. Even this can be abused though.

> I think overloadable and definable operators can be very useful (like Haskell, OCaml), and that's probably as much syntactic flexibility as we need. Even this can be abused though.

I remember being very concerned about the performance of some Ocaml code that was overriding (* *) until I realised what it was doing :)

Not sure how to type that on HN!

Use a code block:

  (* *)

Then the asterisks show up as literals. Two leading spaces for each line in the code block.

The longer I work as a developer the more I appreciate simple, reliable tools. I don’t want it to be possible for people to have different syntaxes. I want there to be one syntax enforced by the tool. That consistency is a lot more valuable in production code, diffs etc than letting people choose tabs vs spaces.

Since I started using prettier with JS I hate switching to a language that doesn’t have it.

That criticism doesn't make sense if one syntax is completely identical to another in terms of the underlying semantics. Different syntax, same language.

I’m always sharing diffs of code, screenshots, browsing code snippets online etc. Unless every single one of these tools also allows me to configure the way the AST is rendered then this approach adds a lot of confusion for not much benefit.

The actual representation of code is just as important as the AST in many cases. If it wasn’t then we would all just code in lisp.

> Different syntax, same language.

This is probably a fiction for any reasonably complex language. Being able to view a C program in S-expression form doesn't solve any real open problems in software engineering, but it certainly creates some new ones.

In case you're unaware, your smarter compilers bullet point is called dependent typing. You can try it out in languages like Idris. Also the person who wrote "The little schemer" recently released "The little Typer" which is a nice intro to some of the theory behind it, very easy to follow.

When I researched this concept previously I did come across Idris but I did not actually study it much.

I will do that now, thank you for reminding me of it again!

Dependent type systems are one way to verify logical constraints in code, but not the only way. Look at Dafny for a good example of how checked invariants can be integrated into an ordinary imperative language. Or ESC/Java for the same approach but integrated into Java. The basic technique goes back at least to Dijkstra’s predicate transformers and nowadays the verification is mostly automatic with SMT solvers.

Those can be integrated with dependent types too - for an example look at F*.

You might be interested in Jetbrains MPS [0] which uses a projectional editor. The same AST can be projected to different 'visualizations', e.g. as a table AND as a just code

[0] https://www.jetbrains.com/mps/

Reply on news.ycombinator.com