What would your ideal language be like...

[Matthew Estes <address@hidden>]

         A friend asked me this, "If you could design a language, what 
would it be like?" question, and I wrote up a response. I'm just an 
undergraduate electrical engineering major, but I learned to program in 
elementary school and have continued with a passion ever since. The biggest 
monolithic project I've ever written was 7000 lines of C code.
         I say all this to preface the fact that I'm no expert, not a 
working programmer(yet), and not an academic(although I have asperations 
:). But this is what I've had gripes with, and some is based on 
speculation, but what I tried to do is approach the question not by looking 
at specific concepts(typing, object orientation, functional, etc.) but by 
trying to say what I want those concepts to help me DO. Since things seem 
to be kinda slow around here, I just figured I would allow my ignorance to 
start a nice long discussion :).

> > If you could design a language, what would it be like?
>
>         Ah, I have thought about this a lot. Honestly, syntax is not 
> DRAMATICALLY important to me(s-expr's would suffice, but something more 
> would be nice too. I'm not for or against infix, prefix, and even postfix).
>         I know what principles it would embody. I'll list them below:
>
>         Say It Once - any piece of information, from low-level details, 
> to the highest architectural ones, should be able to be said "once". If I 
> have to put the same information in two different places, one of them 
> will get out of sync with the other, and then bugs happen.
>
>         Do It Once - typing, I don't care whether its strong or weak, 
> anal or lax, or whatever the current fad is. I want to write code that 
> will work on the widest variety of "datatypes"(whatever those are) and 
> the compiler still catch errors in usage(not to favour operator 
> overloading, but "sort" for instance, should only require the ability to 
> iterate, compare(greater than), and swap, nothing more, any "structure" 
> you can do that too, should be sortable. period.)
>
>         Self Documenting - I like the idea behind Doxygen, and 
> CWeb(Knuth's little toy), and the ilk, but its almost against the "say it 
> once" thing. I should be able to make "smart comments", that are used to 
> automatically make documentation, dare I say it, or even the User Manual.
>
>         Help the Compiler - Abstractions are nice, but there are times 
> when we know things about our code that the compiler doesn't(perhaps this 
> is Contract stuff ala Eiffel), and we should be able to tell the compiler 
> constraints about our code, and it optimize accordingly AND check to make 
> sure we're doing what we say(detecting any violations of our "statement 
> of intent"). We all know that our code is compiled, why pretend 
> otherwise. I'm not saying violate any separation of concerns or anything 
> about the underlying CPU model, but nonetheless, we should be able to 
> make "meta statements" about our code that compiler understands.
>
>         Metaprogramming - Programs that manipulate programs. This should 
> not be hard. Reflection is an example. 90% of LISP is an example, but it 
> should just Not Be Hard to do this(C can sorta, but you have to be a wizard).
>
>         Dependencies and Namespaces - should be simple to deal with. 
> People just don't build monolithic applications, so why should compilers 
> assume everything is in house. Java's package system(based on DNS, a good 
> idea, and yet... a mistake, because its too centralized) is a good start 
> in this... it's really simple and for the most part It Just Works.
>
>         Standard Libraries - Java's stdlib's are an example of people who 
> delight in overabundance. While C's libraries could be far more 
> extensive. I think I would prefer a "conceptual" standard library. Assume 
> that user code will, in cases, override the standard library, but certain 
> concepts, like networking, parsing, streams, graphics, gui's, file 
> handling,  threading, file types(like loading a gif, xml, database), and 
> "data structures"(lists, hashes, trees, sorting, serialization, etc.) 
> should be "conceptual" unified in a standard "interface" that can be 
> adapted for later use. My XML parser in C uses my own file-handling code, 
> and later on, I adapted  it to do networking in 15 minutes, but only my 
> code benefited. It would be nice if you could override the built-in's(no 
> difference between built-in and user code), so that code written 
> elsewhere can and should use the built-in's but benefit from your stuff 
> if you reuse their code.
>
>         Garbage collection - Yeah, I want it, but I would also like to 
> have fine tuned control over it(no collection now, collect some stuff 
> here). If the language were "reflective"(imprecise use) enough perhaps 
> have it in the stdlib and be able to override it. Same with your 
> allocators, often times, if you know something about WHAT you're 
> allocating you can get better performance. Speed is not the be-all 
> end-all, but when you get ready to optimize for speed, the language could 
> help you by not necessarily requiring you to "butcher" your code. 
> Built-in profiling... that would be nice too.
>
>         Separation of concerns and exception Handling - Not sure how to 
> do it right, but SOC is a cool idea, its similiar to stuff like in CWeb. 
> The idea of writing code that does NO error handling and then writing it 
> elsewhere. I like lexically separating Error handling, in C, extensively 
> handling errors often obfuscates the algorithm. Something I potentially 
> like is writing a tag on the end of a function that perhaps intercepts 
> function calls and handles errors, or something that can catch errors at 
> the end using contracts. I'm pretty sure I don't like Exception Handling 
> the way its done in Java.
>
>         Support for evolution - A "program" is never finished, we just 
> get tired of typing. The tools that come with the compiler should assume 
> that I intend to "fork" previous pieces of code I've written and rework 
> it, and maybe back-port it. People do this all the time, why pretend we don't?
>
>         Multithreaded - It should be able to be multithreaded,  and have 
> the tools to support it.
>
>         Embeddability - Embedded systems are cool, and honestly, 
> everywhere. The language should be able to be plunked down into a 
> microcontroller, so handling hardware level stuff(like interrupts) should 
> just not be a big deal.
>
>         Simple - It should be simple. :). All of this stuff I mentioned 
> should be tucked away in a clean, orthogonal language. Some parts of the 
> implementation may be hard. But parsing the langauge should be 
> simple(context free grammer at the most). The semantics should be just be 
> simple. I think most of this can be done simply. I think one of C's and 
> Scheme's strong points is its simplicity. I think its Java's weak 
> point(this is a relative thing. Its a huge win over C++ who is manages to 
> score dead last in this category. Maybe ADA, APL, or VHDL could top it...)
>------------------
>         That's just the language, but I spoke of tools, and now I'm going 
> to really talk about them.
>         I want an IDE. Makefiles are dandy, Ant is amusing, but frankly, 
> I was happy when I progressed to a GUI environment. I like just popping 
> up a dialog and including stuff. I can and do learn these things when I 
> have too, but, honestly, Smalltalk integrating a GUI, and LISP 
> intergrating a REPL are steps FORWARD not back.
>         I want my code to be hypertext. I like that. I want to click on a 
> function see its documentation, definition, prototype and everything. I 
> want to see what code calls my code, I want to see what code my code 
> calls. I want to follow the graph, I want to play with it.
>         Actually, I wouldn't mind if I could literally choose to switch 
> to "graphically" programming. Altera's VHDL compiler lets you interface 
> "schematics" with VHDL. I like that. Do the structural parts of your 
> program graphically(link this to that this way) and then do the guts in 
> text. Be able to switch... start it graphically then maybe edit it 
> textually, and then view it graphically. LabView is a HORRIBLE way to do 
> Visual programming, but Altera _almost_ gets it right.
>         Make and configuration and version management should be at least 
> supported, but preferably truly INTEGRATED into the language. I should be 
> able to send you a tarball of files in a directory tree(from a windows 
> box) and you(on your *bsd, *nix, whatever) system fire up(maybe 
> independently written) your compiler and it should be able to compile. 
> I'm not neccessarily advocating source portability between operating 
> systems, but if you stay in the stdlib it should Just Work. Configuration 
> code should be integrated in with your system. The compiler can help it. 
> Version control would be nice too. I think you could get a really cool 
> system by making these things truly cooperate.
>
>-----------------------
>Interesting programming languages to me...
>         ML - Cool take on strong typing
>         Eiffel - Contracts
>         Forth(innovative way of using postfix, also the standard 
> "two-stack" model, control flow stack separated from "parameter stack").
>         Lisp    \  Macros, higher order functions, code/data what's the 
> difference
>         Scheme  /  Scheme's approach to math, forced tail-recursion 
> opitimization. Simplicity.
>         C - Simple semantics. Purity :). It may screw up, but honestly, 
> there's not a lot to it.
>         Java - package system mostly
>         Prolog - I like backtracking. I wish
>         QuickBASIC - had a good IDE, and was a very good basic. Alas, MS 
> couldn't stop there, and they "fixed" it by turning it into VB. At least, 
> with the name change I can list it and you guys know the difference
>         Assembly language - :)
>         Smalltalk - as long as I'm naming names :).
>         Larry Wall - Perl's okay, but honestly, I enjoy his 
> philosophizing on programming more than his language :).
>
>Languages that I mostly dislike
>         C++
>         Ada
>         VHDL(VHDL is derived from Ada, so I feel very sure I would hate 
> Ada by implication)
>         Pascal
>         x86 assembly - I've seen many architectures, this one is truly 
> baroque.
>
>Cool tools
>         CWeb
>         Doxygen
>         Subversion ...
>
>Other notes.
>         OO is overrated
>         Regex's are overrated :)
>
>---------------------
>
>Closing Comments
>         You asked for it, I hope you enjoyed this. I would love to 
> continue this discussion with anyone who wants to, so please read this. 
> If anyone knows of this language I have described, send me to it. If 
> anyone thinks any or all of this is full of crap let me know. Also, if 
> you're truly interested, the MIT Lightweight Languages Workshop has a 
> mailing list, and I'm on it. Its currently kinda quiet, but I think I'm 
> going to repost Marc's message and get them going again...
>
>
>                                                         Matt Estes