Landscape is my pie-in-the-sky language that I someday intend to implement (maybe)

First point: Languages have been done and are being done all the time. Whatever language feature you can dream of, you can bet some LISP did it about 40 years ago or whatever. And languages are drempt up at a rate of a few serious efforts each week. Since I happen to enjoy reading about this kind of stuff I actually see some of them fly past. For most people they never hear about them at all unless it makes Slashdot or something.

Now it seems that languages either need a good lot of luck (Python, Perl, Ruby) or a multi million dollar marketing budget (C#, Java etc).

I'm not that lucky and I certainly don't have a budget that wouldn't be lost as a rounding error in Sun's or Microsoft's petty cash fund. I am, however, over-confident/optimistic/arrogant enough to think that there is something that is missed in 99% of language attempts and that I know what it is - it's this:

Processing text files sucks

Really! It sucks! Most coders are using vi or emacs and gdb. These are great tools and great stuff has been done with them. So why do I feel like I'm fighting an interface? For coding this is just poor - but for debugging it's criminal. Even mature interfaces like DDD feel clunky and badly designed. Lisp Machines had an interface and since I'm a constant dreamer I want to build the programming interface that I would really like to use.

So that's the moral of Landscape - the IDE is just as important as the language. If Landscape ever exists in code it will exist as a GUI as much as a compiler.

(Sorry console folks. I generally run X with lots of consoles (7 at the moment) and the only GUI apps I run are konqueror and xchat. I don't even have overlapping windows, they are tiled. I'm no GUI lover, but in this case I think the interface is too complex the low resolution of a console.)

So this is a file where I'm collecting ideas for the language features (at the moment). Once I have what I want (and what can be reasonably implemented) in some kindof order I'll start dreaming about the ideal interface I would like on them.

I'm in exam season for about the next 5 weeks, so I can't let myself do too much work on this. And now I need to decided if I file this under Projects or Writings (writings suggesting that it will never be code )

From Ian

Have you looked at some of the stuff in:

http://directory.google.com/Top/Computers/Programming/Languages/Visual/?tc=1

and the resulting IRC discussion

<sanity> in fact, it was as part of my effort to reinvent (unknowingly) dataflow programming languages that I discovered how to find whether one set was a subset of another using prime numbers
<agl> sanity: yea, thou I can't think of a better way (other than a resonably linear format) to spec programs generally
<sanity> i am not so sure
<agl> unless you are going to box yourself into something like dataflow or functional formats you are looking at pretty much a flow chart
<sanity> generally the problem with graphical programming languages is that it is actually slower to use the mouse than use the keyboard
<agl> (which doesn't mean you can't try to do way better than a text file)
<sanity> it all comes down to figuring out a better way to represent a flexible language than as a text file
<agl> indeed, the mouse is a lot less useful than most people think. I'm hoping for something VI like (nf, nc -> New Function, New Class etc)
<sanity> ...and then providing an interface for creating a computer program that is as fast or faster than writing a text file
<sanity> yes, i think the vi or emacs kind-of approach is better
<sanity> also, the language should take care of all layout issues transparently, the programmer shouldn't have to worry about things like "oh, where do i position this box or this line"
<agl> typing stuff (like a text file) is a good way of coding. Unfortunately text editors do not provide enough help (showing function prototypes, hyperlinking the code etc)
<sanity> the language could also use heuristics to do things like tab-completion
<agl> absolutely, Python's tab indenting is right - it's just that normal text tools have a habit of mangling the whitespace
<sanity> i think python's approach is somewhat good, it removes some of the need for the developer to worry about the asthetics of the way they right code
<sanity> at any point in writing code there is a state diagram as to what is permissible
<agl> and hinting the depth of brackets and the like with the correct (TeX style sizing) is a nice example of what a-little-bit-beyond a text editor can do
<sanity> for example, if you have just entered a complete statement, you must be about to enter the beginning of another complete statement etc
<sanity> it should be physically impossible to type even a single character which results in a syntactically incorrect program
<agl> indeed
<sanity> (so for example, lets say you type a '"', the closing '"' should be created automatically so that at-no-point is the program not syntactically correct
<agl> and as much as possible it should bitch about as much as possible as soon as possible (e.g. type-mismatch as soon as you do it)
<sanity> actually, it wouldn't be possible to have a type mismatch, it wouldn't let you type something that created a type mismatch
<agl> (there were too many possibles in that last line)
<agl> hmm, you have to have some leeway. You might want to put in a function call to a function you haven't written yet
<agl> like you are sketching the idea
<sanity> yes, but in that case it would immediately ask "are you declaring a new function?" and create a skelaton for that function if you are

A lot of functions in modern programming languages come down to function selection at some point (compile time or runtime). Object orientation is mostly concerned with run-time function selection switched on the type of the first argument.

C++ also allows compile-time selection switched on the types of other arguments (overloaded functions). Projects have added to C++ to allow this selection at runtime (see Frost).

Of course, restricting the flexability of function selection can lead to much faster compiled code since function calling is such a common operation. vanilla C++ only allows runtime switching on the first argument because it reduces to a constant-time table lookup in a vtable.

These different systems of function selection suggest that a more basic system is underlying them. The most flexable system must be to allow the functions themseleves to decide if they are the correct target. Assuming full type information is availible at runtime then each applicable function could be called, in order, at runtime until one accepts the arguments and runs. If the concrete types of a call are known at runtime then this could be optimised away in compiled code.