[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
What would your ideal language be like...
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
> 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
> VHDL(VHDL is derived from Ada, so I feel very sure I would hate
> Ada by implication)
> x86 assembly - I've seen many architectures, this one is truly
> Subversion ...
> OO is overrated
> Regex's are overrated :)
> 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