Lambda the Ultimate

1. makes code shorter. I want to be able to describe client-server programs with ten lines or less. I want to be able to write gui code with just a data structure and telling it to represent itself. How? Standard templates? Code generation of gui, protocols? Transparent functions and data?

I recall someone affiliated with the Fonc Project describing a very short, very declarative implementation of a TCP stack.

2. makes code less error prone. Typos and Logic errors should be the only thing to exist. How can we enforce less errors by making errors impossible to express?

You said you weren't interested in the dynamic/static debate, but you might want to reconsider that in light of that comment. That's all I'll say on that matter :)

3. makes intention/purpose over implementation. In a perfect world, programming would be done with strong AI assistants (paid in cpu hours). Without AI what methods would we use intention to guide (potentially automatic) implementation?

I'm not going to comment on AI assistants, but since you have brought up "intention", you might want to take a look at Intentional software and what the people at Intentsoft.com are doing.

4. makes reading, sharing, and reusing over writing. OOP was touted as the solution to sharing. Is it?

Brad Cox who invented the Objective-C used to talk about pluggable "software circuits" and the market that would develop because of them, but we seem to be still stuck in "libraries" mode.

I'll never be a PLT - I'll leave that to the brains around here. But maybe I would consider myself a SET (Software Engineering Theorist). With that, I consider tooling to be an underappreciated topic (well in some quarters of software development). I think we have a lot to learn from the Smalltalk style of development. I have great hopes for what the guys and gals at Intentsoft are doing with Intentional programming. I think the people doing the FONC project have some interesting ideas.

But I also believe that programming languages and tooling are intertwined and that you really have to think about them together.

I want to be able to write gui code with just a data structure and telling it to represent itself.

Make sure you can write your data structures declaratively, and that each object can have both attributes and children. (ala XML, but preferably with richer attributes than just strings)

Without AI what methods would we use intention to guide (potentially automatic) implementation?

Take a look at Epigram. It has such strict types that it can guide you a lot, because there is very little a programmer could actually do at each point in the program.

If you haven't designed a language before, its helpful to get some experience re-inventing wheels. Learning doesn't have to be "justified." Also, you should study existing languages and steal ideas whenever possible. As a theiving language designer, I started with a linking language (Jiazzi) based on something baked (program units) in a new environment (Java). I moved up to other languages like SuperGlue, this time based on FRP, Self, Prolog, and others. Now I'm looking at natural language and trying to steal ideas from AppleScript.

My advice: start simple and move up. Anything you do has probably been done before in some form (probably by the 70s, maybe even in the 60s), but what you can contribute is understanding and progressively more refined implementations and applications.

...from most of the things that you say you want to ignore. In particular, a new language that wants not to be a re-tread of the various iconic languages supporting concepts that you've mentioned, limits errors to those of logic alone as much as possible, and is as declarative as it sounds like you wish it to be, is going to be faced foursquare with exactly "an algebra that unifies logic into a computable framework" and "static/dynamic, typed/untyped, etc debates," at least if you're serious about maximizing your chances for a successful design (and you're still not likely to design a language that becomes popular). You can no more ignore the Curry-de Bruijn-Howard Isomorphism than you can the law of gravity given the goals that you've set for yourself.

With all of that said, if I were you, I would be paying a lot of attention to the space of type-theory-based interactive theorem provers such as Coq and the efforts behind using it as a programming language in its own right, as well as using it to develop certified compilers for powerful programming languages. From the other end, I would pay attention to dependently-typed programming languages such as the aforementioned Epigram, Sage, Cayenne... as well as how far you can go down this road without dependent types (e.g. lightweight static capabilities). Finally, since you seem to be interested in declarative languages, you'll want to pay attention to Mercury and, I would think, Oz. I think Ben Moseley's work on Functional Relational Programming is important. There's a ton of work to do around Bell-LaPadula and type theory, certified program verifiers, information flow security, and proof-carrying code. A language that makes it easy to express "Secure Property Titles With Owner Authority" and "A Formal Language for Analyzing Contracts," both by Nick Szabo, would be an eminently worthwhile goal.

So as you can see, there's a lot to do—the above just reflect my own off-the-cuff thoughts and therefore are not even representative, let alone comprehensive—but the unifying themes behind them all are precisely a lot of deep type theory, logic, etc. that you ignore, IMHO, at your peril.

Stealing and reusing is good, obviously the language would have to be realistic in the sense that it would look something that has been made before. And since I'm not a genius, I doubt I could invent something entirely new anyway - so I'm asking for some ideas here. But I feel just programming a language for the sake of learning is educational, not time efficient, so at least if there is a new feature of some sort it would be more interesting. Also, just because i want a new feature, does not mean that the language won't be somehow functional/imperative/whatever is possible.

David and Paul, thank you for the links to various projects, it will help me learn more about the languages.

But I also believe that programming languages and tooling are intertwined and that you really have to think about them together.

In terms of tools, I also believe that tools are important. I was considering example-based programming, where you could take data and do your specific operation, and it would record it down like a macro, except with potential for guessing where loops should be. Navigation tools are quite important too as code bases become big. So perhaps a good idea on that front is good.

However, most tools I feel add to the language, rather than form an integral part of the language. So with a good foundation on language (depending on if I can even get that far), the next step would be tools.

but the unifying themes behind them all are precisely a lot of deep type theory, logic, etc. that you ignore, IMHO, at your peril.

Correctness in the pragmatic sense and mathematical sense are good if you language allows you to express incorrect things. Array overflow is impossible in java. Correctness of result, however, would perhaps be better tested by people using the program, rather than theorem provers. Perhaps in large/multithread/multicomputer situations provable correctness is a big issue.

You can no more ignore the Curry-de Bruijn-Howard Isomorphism than you can the law of gravity given the goals that you've set for yourself.

However, is it possible to box off these difficult to discern issues into modules separate from ordinary code that is declaratively correct? We usually do not consider whether a linked list works or not because we have boxed off all proof that it works away from the user. To the user, as long as they do nice things to a linked list, it will give correct results. The interior designer, or the electrical engineer in a rocket does not care about whether it flies or not - they make their part work - as for whether that needs as much mathematical sophistication, we shall see.
Although typing does not help in terms of logic errors, does it?

I think what you have to consider first is why you want to build a new language. Too much intellectual resources have been spent on building languages that have never been used by more than a few. A new language is good if it solves problems that existing ones haven't. Otherwise, it is just an example of how people try to show how smart they are and fail. Please tell me what you want to do with your new language.

Well, the purpose of the language is to make programming easier. So my reasoning is easy=short+reusable+bugfreeautomatically. As for how to achieve short, reusable and bug free code is a mystery to me. Perhaps you are suggesting that targeting general purpose programming is too far of a challenge, and in a small domain I could make such a language.

It's very good that you try to make a language that is easy to program in. However, you haven't answered my question. What do you want your language to do ?
What kind of problems can it solve? Does it enable users to write robust and extensible code? What is the performance? Is it easy to develop new libraries?
There are many things to consider. I suggest you read The Design and Evolution of C++ by Bjarne Stroustrup. The book explains how C++ has been created and evolved.
Anyway, I think people should spend more time building good libraries for existing languages and less time on making a new language.

I want to be able to describe client-server programs with ten lines or less.

Your language should be based on signals. A function should not return values, but yield signals. Then programming would be as easy as connecting functions to signals. Example:

receiveMessages()
    => messageReceived(m : CloseMessage) : {
           close(); 
           receiveMessages();
    }
    => messageReceived(m : OpenMessage) : {
           open(); 
           receiveMessages();
    }

Incidentally, the above style can be reused in anything (GUI events, server/client events, exceptions, signals and slots, callbacks, concurrency etc).

I want to be able to write gui code with just a data structure and telling it to represent itself.

You need named arguments and tuples with named members. A gui structure can be expressed nicely with named arguments like this:

(Window(title="hello world", layout=Grid(2)) {
    Button(text="Exit", click=function() {
        exit()
    })
}).do

makes code less error prone. Typos and Logic errors should be the only thing to exist. How can we enforce less errors by making errors impossible to express?

You need to make values as types. For example, an integer variable with range 0 to 100 should be used only with values that are compatible. Example:

var x : 0 .. 100 = 50;
var y : 50 .. 60 = 55;
var z = 0 .. 1000 = 500;

//ok, because y falls in the range of x
x = y;

//error, because z is outside of the range of x
x = z;

By carefully telling the program which values are allowed at each specific place, most errors will be caught at compile-time, rather than at run-time.

Static ifs could be used to promote values from one type to another. Example:

var i : int;
var x : 0 .. 100;

i = input();

if i in 20..80 then
    //we know that 'i' has a good value, therefore the code below is valid
    x = i;
end if

makes intention/purpose over implementation. In a perfect world, programming would be done with strong AI assistants (paid in cpu hours). Without AI what methods would we use intention to guide (potentially automatic) implementation?

You need compile-time code execution that can be used to transform code arbitrarily during a compile (and also do other side effects). For example, you can declare a database schema like this:

var db = database(username="john", password="blabla") {
    table Customers {
        column FirstName : string;
        column LastName : string;
    }
};

Then you could have the following meta code that is executed after a translation unit is compiled and that it transforms the translation unit:

meta {
    function database(AbstractSyntaxTree tree) {
        ///bla bla transform the code
    }
}

In this way, you don't even need macros.

OOP was touted as the solution to sharing. Is it?

OOP has its own problems, one of them being the mixing of subtyping and inheritance. I suggest to separate the two by using type classes / structural subtyping.

makes reading, sharing, and reusing over writing.

1. don't let the user manage libraries and versioning. Make network imports and let the compiler import the appropriate library. Example:

import "www.mycompany.com/MyLanguage/".MyModule;

The compiler will check online if there is a new version of the library upon each compile by talking to the server defined at the import declaration. If there is a new version, then it will be downloaded and used. If not, the compiler will use the old one (if the contents of the new one are not compatible) or declare an error.

This will allow the sharing of code much easier than in any other way.

2. define a standard binary interface. In C++, I can't take code compiled with one compiler and use it with another compiler, which is quite a problem in some cases.

This post gives some basic guidelines to help when designing a new language. The rest of the discussion is interesting too.

1. makes code shorter. I want to be able to describe client-server programs with ten lines or less.

This distributed contract net protocol is written in Oz in three lines. The basic idea is to use functional combinators (Fold, Map, etc.) as concurrency patterns (see sections 5.4.3 and 5.2.1 in CTM). This is completely natural with dataflow variables. It works in a distributed setting if the language supports network-transparent distribution.

I want to be able to write gui code with just a data structure and telling it to represent itself. How? Standard templates? Code generation of gui, protocols? Transparent functions and data?

The QTk tool in Oz lets you write GUI code as a nested record, cleanly separating the declarative and procedural parts of a user interface. We measure 1/4 to 1/3 the number of lines of code of procedural toolkits (like Tk itself). As a bonus, since GUIs are data structures they can be computed. See chapter 10 of CTM or the QTk documentation in Mozart.