Sylph: the programming language I want (opens in new tab)

Not at all. In this case, by 'languages without braces' we mean languages where indentation is part of the grammar. Python's grammar includes explicit INDENT/DEDENT tokens. It is impossible to reindent this mangled python:

    if z:
    print 'a'
    print 'b'

> The computer is really quite proficient at inferring block structure from indentation, and if you use a modern editor this structure is manipulated rather effortlessly.

Nonsense.

Try pasting a block of Python into Hacker News and you get something that starts off like this:

import os import random def do_something(x): if x: fd = os.open(x)

and only gets worse. A language with braces/semicolons has no such problem; it is easier to communicate with others, and the absolute value of being able to communicate with others when starting a new language is exceptional.

The only thing superior to Sexps is Forth. Mechanical syntax forever.

A token is a token. PEPpy Python's four spaces are isomorphic to Lisp's left banana and C++'s curly brace. An ASCII <bell> would be just as well with a lexer.

White space has significance for humans. The road to the Turing tarpit is paved with human intentions. Describing computation mathematically is a solved problem. Expressing it clearly for and by humans, not so much.

What's effortless is putting begin and end of blocks symbols only where they matter.

Haskell is particularly guilty of creating several different indenting possibilities, and does require constant intervention. Python is less bad, but still requires more effort than C for example.

I think they specify "INDENT foo DEDENT" and the lexer tracks indentation and issues INDENT/DEDENT as appropriate.

I have one (probably quite naive) implementation here:

https://github.com/djc/runa/blob/master/runac/parser.py#L54

(Runa uses tabs for indentation, not spaces, but it's basically the same thing.) Whitespace at the start of a line is a separate token, then I add a thin layer of processing that turns a change of indentation level (i.e. count chars in the token contents) into INDENT or DEDENT tokens.

  def fun():
      for x in xs:
          if a:
              b
            c

There's no way for an editor to know where to re-indent c to. You have to cycle through the indents manually.

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...

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.

>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.

I meant "language standard library" (I updated the text).

C/C++/Object-C/PHP have short functions with names like strlen, strstr, etc. Java/C#/JavaScript have .length() and things like System.out.println()/Console.Write(). Ideally, I would like a middle ground. The Java/C# standard library is too verbose and the C standard functions are a bit cryptic.

It's great one can use different programming styles in JavaScript/PHP/C++. In PHP many functions are available in procedural and object oriented style, e.g. http://php.net/manual/en/mysqli.query.php

> Why? Just get the machine to do it.

I meant the writing stage, not the checking stage.

Imagine you don't know which type to pass. So, you'd have to pass something (null or whatever) in order to generate an error which gives you a clue.

That doesn't sound very convenient.

Well, the machine could check which types match that fingerprint, which might work okayish if the list isn't too long, but it won't tell you anything about the writer's intend.

Is a list of doubles, a list of ints, a Float32x4List, or a Float64x2List really the same thing?

What if it's actually meant to be used with something else which also supports the [] operator and whose items support the + operator.

Static analysis might not be able to tell you because it doesn't know all packages in existence. That package might not have been referenced, because that's not required to use a type from that package.

How does the generated documentation look like? It takes one argument "foo" which is something which has a "bar" field and a "baz" method? I'd rather have a concrete type there. "int x". Done.

What if you optimize the function a bit and now the fingerprint doesn't match one or more types anymore. Was this a breaking change?

Your intention didn't change. You always had one particular type in mind.

> Just get the machine to do it.

Exactly. Many people already use IDEs, or programs which provide auto-completion or hinting of the types a function accepts when writing out a function name - the type does not need to be explicitly written for the machine to identify the type of the function.

Note that the interface between the machine and the human is one of the slowest. Being able to learn things about numbers, or about code, without touching the keyboard / mouse is important.

> It's like when you see programmers doing arithmetic in their heads. "You're sitting in front of a glorified calculator!"

At the company where I work, most engineers have real, actual calculators on their desks. I think I even saw a slide rule once. So they sit there, sometimes, doing arithmetic on their calculators and then type the results into an Excel spreadsheet.

In general this feature is sometimes called "Universal Function Call Syntax" (UFCS), though interestingly Rust does it exactly the opposite of most other languages with this feature. In Rust, defining a method lets you use it as a free function; in C# and D, defining a free function lets you use it as a method.

I hated sounding negative on the article. It represents a lot of admirable effort. My point is that the effort is not directed in a particularly constructive direction in regard to creating a new programming language.

There's a clear goal when writing a language that is both a floor wax and a desert topping. On the other hand, all writing a language with the goal of being neither floor wax nor desert topping just gets us a floor topping and a dessert wax. There's no problem solved. Griping isn't brainstorming.

Brainstorming is structured. Productive brainstorming is constrained by reality. By which I mean that brainstorming about something like type inference acknowledges that type inference is subject to the Halting problem and that dynamic typing as in Python does not entail type inference.

Starting with Assembly, all higher level programming languages are DSL's over machine code. Things I hate is not a domain that leads to insight or a coherent minimum language. Python's core was addressing pedagogical problems such as beginners learning to format code well. Google's Closure compiler addresses the problem of JavaScript performance. Rust is intended to address client server programming. For each there is something that can be measured objectively and improved.

Don't misunderstand me, there's nothing wrong with writing a programming language as a learning exercise or to scratch one's own itch or solve the world's problems. But it is an engineering design exercise not a poem. The facts of computation make it so.

We should add another stage into that routine: research.

It's no good looking at problems that other people have solved (or proven that they can't be), when we could be looking at new ways to approach problems instead. For example, we'd know that "statically inferred duck typing" is already well researched. It's called structural typing.

beautiful. i really should take the time to explore perl 6.