Hacker News Reader

Comment by deckiedan | Hacker News Reader

A lot of syntax / spacing / etc. problems would go away if we stopped using completely plain text as the medium for programming languages. Or rather, if we extended plain text, or got our editors to understand the languages a bit more thoroughly than just highlighting keywords and giving us autocompletion or whatever. This has been explored a bit by michaelw and others (http://www.foldr.org/~michaelw/emacs/) for lisp.

Imagine a syntax aware editor which could display code from a language using the syntax or style of another. (This might only work from a single base language, there are too many "odd" features in languages which couldn't translate universally).

So, since I like python, it could be displayed PEP8 style. Someone else could see it with LISP braces everywhere. Another could have it with 2 spaces and 'end' keywords, or {curlybraced;} (in K&R style, or whatever you like).

View on HN

This really assumes that syntax is a purely superficial thing, but in reality syntax reflects the underlying semantics of the language as well.

For example, a typical C program (sequence of imperative statements) displayed with lisp syntax will look awful, yes, but so will a typical lisp program (deeply nested expressions) rendered with C syntax.

Getting rid of text doesn't change the fundamental issues: Languages would still have different semantics (and thus suit different/custom representations) and it wouldn't make any more sense to mix-and-match than it does now.

Different semantics can be approached by several different methods though - one can simulate an interpreter for a "guest" language in a host language - or the languages can provide an FFI for interoperability. While we have various means to combine the two different semantics of a language, we have no means to combine their syntax without encountering ambiguity problems. This is why storing code in a structured format rather than plain text could be so valuable, because it would enable us to mix and match languages in whatever way we wanted - rather than resorting to putting code inside strings, loading up new files, or complicating the syntax of our language to provide the expressivity we would like (eg, LINQ).

Diekmann and Tratt have a theory of Language Boxes[0][1] which provide the groundwork for achieving this kind of editing. They enable language quotation without the need for introducing per-language delimiters, the need to quote code in strings, and the need for escaping characters when hosting one language inside another. The editor is aware of where the language boundaries occur because they are specified by the programmer. The semantics of hosting one language in another are left up to the programmer to specify.

[0]:http://lukasdiekmann.com/pubs/diekmann_tratt__parsing_compos...

[1]:http://soft-dev.org/pubs/html/diekmann_tratt__eco_a_language...

Composing a larger program, by combining functions in different languages in a new framework, seems to take things in the direction of large and complicated programs. Would it not be simpler to write smaller, independent, individually named and reusable programs in several languages, according to each language's strengths, and pipe the output from one of these programs to the other? As an added bonus not all the programs need to understand the entire problem domain.

This line of thinking ignores simple domain specific languages like SQL, which 9 times out of 10 are held in strings in the host language (and thus undergo no static checking because the contents of strings are basically ignored by the compiler. There are other examples too: html files contain nested Javascript, CSS etc. PHP files host HTML. C++ effectively hosts C and assembly.

Haskell hosts a few dozen languages called "extensions" - specified in a {-# LANGUAGE #-} pragma at the top of the file. This one is of particular interest because the language appears to have some kind of extensible syntax which allows these extensions to occur - except when you look under the surface, they're all combined into the same grammar and they all interact with each other, such that other extension developers basically need an entire understanding of all of them to know where conflicts may lie.

Using a framework like LanguageBoxes instead to host these kinds of extensions would allow individual developers to put their own, independant extensions into the language, without having to hack on the compiler and rebuild it.

Also, writing several independant programs and using any IPC to communicate between them is ideal in theory, but in practice is more often unsuitable - because Unix processes are a bloat. They take time to initialize and use lots more memory than necessary for what amounts to running code for a small amount of time and discarding of it. Perhaps if we had a more lightweight model of processes ala Erlang style, this kind of reusability would be practical and not just a good philosophy to follow.

Sure - not all syntax is superficial. But a goodly proportion of it is, I suspect.

That's why I kind of was trying to aim towards saying you /COULDN'T/ have a universal language syntax translator - but for a (new?) language, you could create (possibly) different interfaces to the central logic and structure of the code to suit different preferences.

Sort of how we have different skins and fonts and so on now.

Lisp programs are data for the reader ~ in contrast to text for a lexer as is typical in other language families. So long as AST's are in the pipeline from source to execution, the options are lexing [or its equivalent] or writing an AST directly.

This was tried. It was called APL.

http://en.wikipedia.org/wiki/APL_%28programming_language%29

It was very, very clever.

It was so clever hardly anyone understood it, and it's (mostly) forgotten.

Having said that - I kind of agree. It seems like most languages are attempts to:

1. Create a human-readable text-based representation of symbolic logic.

2. Chunk the symbolic logic in (hopefully) useful ways.

3. Cross-correlate symbolic levels, so at one extreme you have actual bytes in physical memory, at the other you have arbitrarily complex symbolic data structures.

4. Build simple error checking into the language so it's impossible to write obvious nonsense. (This includes, but isn't limited to, all type systems.)

5. Constrain the operations that are possible for similar reasons. ('State' etc.)

This is all more or less taken for granted. I'm not sure it should be. Basically it's a bottom-up approach to language design - reduce operations to binary algebra, add constraints.

But top-down languages like Prolog and (kind of...) Erlang try to do interesting, powerful, things, and have at least a few features that Just Work.

So I think the top-down approach is underexplored. There's a sweet spot between top-down simplicity, expressiveness with minimal cognitive load, and processing efficiency.

It's unlikely current syntax conventions are close to it.

I think most people know that languages are different points on various trade-off scales, so there will never be one single best language.

But more variety might not be a bad thing.

>This was tried. It was called APL.

APL is absolutely nothing like the parent described.

Iverson's design of APL was well thought out to the degree he won a Turing award. His lecture Notation as a Tool of Thought lays out some of his thinking:

http://www.jsoftware.com/papers/tot.htm

Three decades after first conception, Iverson developed the language J using only ASCII characters and based on what he learned over roughly two decades of APL's deployment in the field. IMO, J is worth looking at because it may change the way a person looks at programming languages and their design.

http://www.jsoftware.com/

Interesting that you use the past tense. I am using such a language in the present. And it is working just fine. I have no need for Python but so many people are seemingly trying to coax me to use it. Such is the case for most of the verbose languages.

I do not understand all the constant discourse about languages. Personally I prefer to choose something simple and small, and stick to it. To increase convenience when working with these terse languages, I write code generators.

To me, it is not the language that matters (except as below), it is the programs that the author chooses to write and how those programs perform.

It is probably my own selective bias but I find that the smaller programs written in relatively terse languages tend to be of higher quality. When I see a verbose language used to write a program, I am reluctant to use the program. But I would never suggest that someone else make the same decisions. I believe one should think for herself.

There is not so much discussion about the terse languages I use. I am inclined to think this is a good thing. Then I can focus on the choice of the programs the author chooses to write instead of her choice of language.

What are these terse languages you speak of?

APL, J (http://www.jsoftware.com/), k (http://kparc.com/k.txt).

www.reddit.com/r/apljk/

I made a start on it http://sediment.io

There's a pretty exhausting amount of work to get to the same toolset we have for text-based languages though.

Reply on news.ycombinator.com