Slashdot Log In
Open Source Programming Language Design
Posted by
krow
on Fri Apr 27, 2001 08:37 PM
from the more-languages-should-look-like-LISP dept.
from the more-languages-should-look-like-LISP dept.
descubes writes: "It's been a long time since Java, the last major change in programming languages. Could the next one be designed "the Open Source Way"? For a few years, I have been working on a programming language called LX, which is part of a larger system called Mozart. I need some feedback. Could Slashdot readers comment on which programming language features they would like?"
This discussion has been archived.
No new comments can be posted.
Open Source Programming Language Design
|
Log In/Create an Account
| Top
| 243 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Don't forget the curse of PL/I (Score:4)
What I'd like to see. (Score:5)
The key is to be unique, you'll notice Python and recently rose to fame in that it contained ideas not seen in mainstream lately, such as tabs for delimeters of the score. Try to come up with someone radical that most people can't even think of now, but keep it simple so people can use.
Re:COME FROM (Score:3)
Oh, you mean exceptions. After all,
try {
foo...
} catch (SomeExceptionType baz) {
try_to_recover_from_baz...
}
(This text is here in an effort to prevent this post from being considered filled with junk and rejected. Please ignore it and bitch to CowboyNeal that his "lameness filter" fails to catch first ports, hot grits, all your base, and natalie portman garbage but somehow rejects this perfectly valid and even fairly on-topic post. Thanks for nothing, CowboyNeal.)
is really no different from
foo...
baz:
if (some_condition)
COME FROM foo;
At least Intercal folks realize their language is a joke, I don't think Sun have caught on yet.
Re:Jikes (Score:5)
Re:Likes/dislikes (Score:4)
Any function/method with more than, oh, two arguments causes confusion and bugs. Most of the time there is no real natural order to the arguments -- perhaps some conventions, but that's about it. Does the file come first in fputs, or is that fprintf...? Does either of those make more sense then the other?
Argument ordering is usually arbitrary, but named arguments are never arbitrary. For large function calls (which would include object instantiation) keywords (named arguments) are very good.
Define a problem domain for your language (Score:5)
Congratulations on your development of LX. It seems like you've made excellent progress so far, and the language definition and examples are useful for understanding the language itself. It looks cool.
Rather than commenting on the language and its features, I'd suggest that you identify a problem domain where your language (and Mozart) are a better solution than any other options out there. This will allow users to identify your language more quickly and bring more users to it. When people think of Java they think "the language of the web." PERL? "The duct tape of the Internet." I'm sure you get the idea.
Cheers!
ERe:Define a problem domain for your language (Score:5)
Anyway, there is no such thing as the "perfect optimizing compiler". To be verifiably optimal, as well as knowing everything there is to know about the machine's internal architecture, it would have to have complete knowledge about the dataset that the program to be compiled is to be run on - if that is not available, if there is a tradeoff to be made the compiler has to make a choice that will be suboptimal
To take a simple example, the compiler might choose functions to be placed in a certain order in the object file so that functions called repeatedly in sequence can all fit in the cache at once. Running the program with a different dataset could produce different call patterns, and thus the optimal layout of functions in the object file might be different.
So, your program, and any non-trivial program, could only ever be truly "optimized" for one input dataset. Anything else is a compromise.
Go you big red fire engine!
Re:<Insert-deity>-damn indentation-sensitive (Score:3)
And I only need them for languages which lack any capacity to pretty-print, and thus force me to do it manually.
--
Mainstream influence of Functional Languages (Score:5)
However, Java focuses almost exclusively on strongly-typed object-orientiation as its primary concept. It completely ignores two related features which make Smalltalk powerful: code blocks and closures. These Smalltalk features were actually derived from LISP, which at the time (1972) could only be called a proto-functional language. The first truly functional language was probably Scheme, in 1975.
Because the functional ideas inherent in LISP were not fully developed at the time Smalltalk was created, the conceptual emphasis in Smalltalk was on object-orientation, derived from Simula. If Smalltalk had been able to draw from Scheme instead of LISP, there's a strong chance that it would have had a more functional bent, which might have affected the languages which were influenced by Smalltalk.
Instead, Scheme came along just a little too late to directly influence the mainstream. Only recently have we started to see functional features appearing in mainstream languages. PERL and Javascript both support lambda-calculus-compliant closures, and first-class procedures, which are fully realized incarnations of the original concepts on which Smalltalk's somewhat limited code blocks and closures were based. Python has also recently moved in this direction.
I predict that functional features will slowly be adopted by most mainstream languages over the next decade or two. Java will be the last new mainstream language that's completely non-functional (pun intended). The power of these functional capabilities is too great for language designers to ignore.
Note that I'm not saying that current functional languages will become mainstream languages. Rather, just as mainstream languages have absorbed object-oriented concepts, they will also absorb functional concepts.
Anyone writing a language today who isn't familiar with Scheme, Haskell, and ML may as well throw in the towel right now. Unless they plan to invent the next great paradigm, they will not succeed. I think it's impossible, in 2001, to write a language without taking functional concepts into account. (Of course I'm reminded of Tanenbaum telling Torvalds that writing a monolithic OS kernel in 1991 was a fundamentally bad idea...)
Oooo! Oooo! I want... (Score:5)
It should be work on Palm Pilots, and Beowolf clusters. It should be easy to extend, easy to parrellize, and easy to optimize for every major processor currently in use. It should be easy to read, have a powerful and compact syntax, familar to people who understand Pascal, Ada, LISP, Prolog, or SQL. It should be comprehensible to an advanced two-year old, usable for teaching computer science concepts in college, and usable in a professional environment. It should be loved by both the Slashdot community and Microsoft, and it should be immune to embrace-and-extend.
It needs to perfectly fit my needs but also perfectly fit the needs of my grandmother. It should have a dancing baby as a atomic object. By the way, whatever your language is currently doing is totally wrong, and you should totally change it around. Also, you need to satisfy every last comment posted in response to this article, plus the ones people only thought, but didn't take the time to post.
Your language should replace OpenGL as the dominant graphics platform. Your language should have an order-N searching algorithm built in. Your language should easily extend into the quantum domain when such computers become available. There should be a command-line option that will read in all of my old QuickBasic programs from when I used DOS.
Your language should be interpreted, compiled to byte-code, compiled to Java(tm) byte-code, or compiled to native code, depending on context. Your language should make sure that all programs written with it should be optimally thread-safe. Your program should be able to detect whether a given program will go into an infinite loop. Your language should have no patent issues. Your language should have all the whiz-bang features other languages have.
I want to be able to apply an XSL stylesheet to my source code and get the equivalent program in Turing Machine code, but I don't want to learn XML... that's too much to ask. Your language should automatically internationalize all programs written in it.
Your language should be elegant. I want to be able to implement the Linux kernel in three lines of code.
I would take any suggestions on Slashdot with a Detroit-salt-mine-sized grain of salt. Consult a real language expert.... because most of all, your language should not designed by a committee of random computer users.
Great languages come about to solve real problems (Score:5)
When developers (Pike + friends) needed an efficient, processor-independent language for systems programming, they created C. Later, when the systems got so huge that they needed a new layer of abstraction, they (Stroustrup et al) looked at the problem and came up with C++.
Guido wanted a language with the readability of ABC, but with exceptions, OOP, and extensibity, while Larry Wall obviously needed a Postmodern Extension and Reporting Language. Java's history is similarly tied in with very specific problems (smart devices, then applets).
A programming language is an answer. If you propose to design one without first asking a concrete question (no, it doesn't count if your question is "what would be a really cool language?"), I suggest that you name it "42" for obvious reasons.
--JRZ
Re:Straight jacket vs. control (Score:5)
Our resucue here is JNI. With this you can even segfault java
Bases (Score:5)
integer Large
integer Twenty_Seven
real MAX_FLT is 2#1.1111_1111_1111_1111_1111_1111#E127
If I can choose a base arbitrarily, why the assumption that I want to choose my base in base 10? Why can't I choose my base in base 16, as such...
integer thirtytwo = 16#20#10
But then I still need to choose the base I want to choose my base in in base ten... why not
integer thirtytwo = 2#10000#20#10
But then... agh! We're stuck in a loop.
To be slightly less snide for a moment, what I'm trying to point out is that, while this is a good idea, it is slightly silly and slightly unnecessary. There are certain bases that are used... there are others that, in general, are not. Don't support every base through a clumsy yet silly syntax. I'd rather be able to do the following, and only the following:
integer ten = 10
integer ten = 10d
integer ten = 12o
integer ten = 0Ah
integer ten = 1010b
where the default encoding is decimal, but I can use one of d, o, h, or b to switch to another common base.
Consider simplicity (Score:3)
I'm glad to see the influence of Eiffel in there. Eiffel is a language which achieves its generality not by adding features to the language, but by removing them. It doesn't try to cover everything you could want to do with a special case; it has a few well-chosen abstractions that cover a lot of ground.
Anyway, when your language description looks like a big bag of toys a programmer could use, then perhaps you should take a step back here and ask yourself "what am I contributing?" What is new about your language? If it's just syntactic sugar, then don't bother.
(I'm not saying LX is just syntactic sugar; I'm saying that your website hasn't convinced me that it isn't. The presentation of language features as a shopping list doesn't convey the real contribution of your new language.)
You seem to have a grasp of languages that are general because of their complexity (Ada, C++), but make sure you have experience with languages that are general because of their simplicity (Eiffel, scheme, Smalltalk).
A few other things:
--
Re:Define a problem domain for your language (Score:4)
Earlier comment; People are superficial. (Score:4)
Programmers do not like a syntax that is not close to the syntax of their first language (usually an algolic variant)..
It's no harder to get used to than C, or any other real language. Try using it with an indenting, syntax hilighting editor for a week. Now, did you spend more than a week when you learned the syntax of your first algolic language?
Anyone notice how all the languages that seem to be coming out are always algolic? And that they suck... They don't even have closures!
Syntax is superficial. Semantics is everything.
Re:What I'd like to see. (Score:3)
Object o=new Object(); java.lang.reflect.Method hashcode=o.getClass().getDeclaredMethod("hashCode" ,new Class[0]);
Integer hc=(Integer)hashcode.invoke(o,new Object[0]);
System.out.println(hc);
Now you try.
Why the grail fight yet again? (Score:5)
WHY does everyone have a favourite language, and assume it's the cat's PJs for every problem under the sun?
I use, primarily, Java. Why? Because for what I do, I need the portability, and it's more than fast enough, and yes, the recent versions are portable properly. They're also likely a lot faster than you think they are.
But my real point, is that it's not the only language, and the reference to MIT is found early in the book Structure and Interpretation of Computer Programs by Abelson, Sussman and Sussman. I myself did not go to MIT, so if I mess up, don't blame them, but the point made in the book is thus:
Different languages evolve to solve different problems. People don't build things like Simula for writing a network driver or the next 1st person shooter. They build it to solve complex, physical simulations. The expressive power is greatly increased, but the problem domain is restricted.A general language is a nice idea, but we're starting to need something beyond that. The whole idea of the project is actually meta-programming. Not writing your next device driver. Write it in C. Maybe C++ if you must. But the OOP languages have given us a large number of very reusable, efficient components, regardless of what detractors of the OOP approach itself may claim. Knitting those components together right now is tedious in C++, Java, VB or even many of the visual designers. We're still bolting rods to wheels, instead of expressing the transfer of linear force to rotation at a higher level.
I would humbly suggest that all the crock about the syntax and such be backed off. Especially type constructs, object aspects, and the other things addressed quite well in many different ways by other 3GLs.
Start with interfaces. Describe the interfaces, and describe the use of an object that adheres to those interfaces. From there, find ways of describing systems of those interactions.
Contrived example (required): database connector, table model, grid component, graph component, statistical analysis tool. Each has certain interfaces that can connect to each other singly or in groups, and can control things singly or in groups. The old MVC writ large. Find a way to describe and program the MVC system at the MVC level.
I wish I had any idea how to do this, but I don't. I write in C, C++, Java, Perl, and have dabbled in everything from assembly up to Scheme. It's all so similar in far too many ways. It's not ideas and systems, it's still bits and branches.
Many posters argue the efficiency. Your points are valid, but large, complex systems spend tens or hundreds of millions of dollars in programmer time for software running on "mere" millions of dollars of hardware. Doubling the amount of hardware and halving the amount of programming is a WIN for all involved.
Odds are that the approach of the project is already correct. It uses a 3GL as the "worker" bits (Java, in this case, fight about it somewhere else), and tries to put a true meta-layer on top of that.
The concept is as foreign to working programmers today as it could be. It's like knowing Classical Greek physics only, and getting hit by Relativity and being asked to design the analysis tools for it. You don't even know Newtonian theory yet. There is that large a jump in there.
So skip the bits about the next cool language. It's a valid discussion, but unless I miss my mark, this project is grasping at something far, far beyond that. And being able to code to a pointer doesn't really matter at that level.
My thoughts... (Score:4)
Here's some things I do like:
Indentation-sensitive syntax. I've seen Python code and this seems to really improve readability. It would be especially great for a beginner's language, since it's important to stress proper indentation at the beginning.
Named and out-of-order parameters. Your example very clearly demonstrated the advantage of named operators for complex function parameters. This is a feature I don't think I've seen in any language but VHDL. (Though some Perl modules sort of cheat to get this functionality.)
Constrained generic types. I think this nicely solves the problem in C++ of getting confusing compile errors when you try to sort objects you've forgotten to define operator< for. This is especially important if plug in the types at runtime instead of compile-time, which it sounds like you intend to do.
Here's some things I don't like:
Expression reduction. This seems like it would be hard to implement and very confusing. Specifically, think about expressions like that within larger expressions. If I define "A*B", "A+B", "A/B", "A*B+C" and "(A+B)/C", what happens when I use "(A*B+C)/D"? What gets called? You could do "(A*B)" then "(A+B)/C" or "A*B+C" then "A/B" or just use the binary operators. There would be a bunch of different cases and its unclear what code would actually be executed. I think it creates too much confusion unless you can demonstrate that this would be a huge speed boost.
Variant records.
The first example you showed of these was basically using them as a replacement for unions. I hate unions. I like the way you can in Java set a security manager that controls what various bits of code can and can not do. But this depends on those bits of code only accessing other objects through the public interfaces. So unions in this case would be very bad for security, and they are very bad already for type safety. I really think we're past the point where we need to save a few bytes.
Second, you used a variable to size an array. Basically, you created much simpler syntax for dynamic memory management. I think this masks a lot of problems. What happens when you run out of memory trying to resize the array? You never explicitly resize the array, so I don't even know where you'd go about inserting code to deal with that failure. Second, what happens when that variable changes in some non-obvious way? Ie, through a pointer to it or through the union thing you described above. The array isn't resized, and nothing good can come of that.
Multiple kinds of pointers.
I can't help but see so many different types of pointers as needlessly complicated and confusing. What will you really be needing pointers for? You've defined "in", "out", and "inout" parameters, so pointers are no longer needed to pass by reference. They are needed for dynamically allocated memory. And they are needed for really low-level stuff that needs to address specific bits of memory.
I suggest instead doing this: having the simple pointer type you've defined which does not allow pointer arithmetic or pointers to arbitrary addresses. Having the address type you defined available if the security manager allows it (again, the idea of not only type safety but security from not allowing access to arbitrary regions of memory). autoptr really isn't that different from ptr...especially since in C++ it can be implemented without any language support at all. Leave the others out.
Function-based dynamic dispatch (polymorphism). You talk about how C++ has the fragile base class problem, that new virtual functions can't easily be added to the base class. But I think you are misinterpreting where the problem lies. The problem is not that you have to add the virtual functions to the base class. That's just the way it has to be; otherwise, very weird stuff would happen when you try myBaseClass->onlyDefinedInInheritedClass() (remember, you don't know if a shape object is a rectangle or a triangle or whatever, that's the point of polymorphism). The real problem is the way C++ represents virtual function tables in compiled code. Java, for example, does not have this problem.
Really, quite a few of these features I don't like. It seems like they just add complication to the language spec without solving any huge problem. This will both make it harder for you to create a compiler and harder for people to learn/use the language.
Straight jacket vs. control (Score:4)
I like C++ because it makes me really say what I want to do if I try and do crazy shit to memory.
I like Java because no matter what I do I can't do anything dangerous. Err wait, I hate that about it
C++ has a nice way of protecting people.. you need to explicitly say "Yeah I'm totally sure I need to take this hunk of memory, cast it into a void* and do some arithemtic on it." It's too long though.. the lines of source that is.
Allow a Java like straight jacket... using something like #pragma preprocessor defs or something.
Examples:
#babysit_me_i_am_dumb
#make_sure_i_am_sure
#back_the_fuck_up
Justin
Re:What I'd like to see. (Score:3)
In Smalltalk:
Transcript show: (Object new perform: #hash).
Re:Interesting (Score:5)
Those that do not use LISP are condemned to reinvent it. Badly.
Every good computer programmer I know has designed several "mini-languages." They all improve expressability in some minor way (because they scatch an itch or are optimized for a specific domain.) But, 99% of them never catch on because they are not extensible in a "deep" fashion, or if extensible, the meta-language of extensibility is painful for real-world problems.
Languages become nasty because programmers try to write "nice" APIs for their users. E.g. the systems guys provide "clean" APIs for the library writers. The library guys provide "clean" APIs for the application writers. The application writers provide "clean" APIs for the users. Each layer uses a lot of crufty stuff in an attempt to make life easy for the users of the layer. Eventually, the entire system is cruft, and hard for everyone.
C was clean, but began to collapse when programmers were forced into heavy macro hacks to implement more complex systems.
C++ started nicely, but soon was burdened by the ancient linker. Templates have become the new evil that replaces the old evil of macros.
Fortran avoided the whole issue by making abstraction beyond the subroutine level impossible.
Common Lisp, ML, Prolog, Scheme, Smalltalk, etc, all try to be "honest" languages: the writer of a piece of code trusts his users, and the users can inspect the system they are using. Everyone is assumed to be intelligent, and "information hiding" is looked upon with a degree of suspicion. The more "features" a language has, the more it worries me: these are decisions made by the designer that I cannot change. This is why I like LISP: your program must conform to certain basic rules (it is a list,) but all other design decisions are visible to me, and probably changable by me.
Of thelist of 38 unqiue characteristics of LX, Common Lisp already has 33 of them. Indentation sensitive syntax is similar to paren-balancing syntax. The other 4 are either artifacts of non-sexpr languages, or trivially implementable in a few lines of LISP.
LISP was the original user-built, customizable language.
It needs to enforce modularity! (Score:4)
If object A is dependant on a certain public member always being available from object B and suddenly the variable is assigned different types of values or used in another way, the object A will have to be changed to accept the changes in B. Well this synchonization never usually happens unless there is a lot of documentation written (We all know coders love to write documenation!) or it finally produces a bug and you whip out the debugger and start tracing...
This is just one of the many examples. I would like to see a language where objects are forced to be seperate and truly defined only by their interfaces. C++ almost had it until it introduced all the hack keywords which broke everything.
A truly modular lanuage would be great for a Open Source language because people could work on different objects without having to worry about the internal details being compatible with another coder's object. This would allow parrallel coding to work more efficiently. Also when people join on Open Source projects, they don't have to time to go through all the code in the project to see how things work, they only have the time to look at a few sections, understand those and start coding. With enforced modular code, the new coder will only have to look at interfaces to understand how a program works.
Modularity is the key to making Open Source work.
Re:What nobody else wants (or will say)... (Score:5)
NO! NO! NO! DO NOT DO THIS! (Score:3)
About six years ago I went on alt.folklore.computers on Usenet to create a language spec by this very process, except I did it as a joke. You don't want to write a spec by Bazaar methods -- it's a sure guarantee of an unnecessarily baroque design that will be a bitch to implement from the ground up. If you're doing it seriously, you'll start unnecessary language wars as people pull out there MFTLs for design inspiration. You will get a reference manual two inches thick like Ada or C++. You will get bitched and whined at because your objects aren't as pure as Smalltalk, because your functions aren't as functional as ML, because you're more baroque than Perl.
Too tough even to change, now that I think of it -- I went back to try and rework Magenta into something coherent and I couldn't cram enough of the design back into my head to make any sense of it a year later. Implementation by committee can be a thing of beauty; that's how the Internet was built. But design by committee... let's just say I originally wanted to call Magenta Linda (as in Lovelace) because it sucked so bad.
/Brian
What is your goal with the language? (Score:5)
What is so insanely great about this language that would convince a programmer to use it?
From my brief reading of the webpage, the language seems to be a mish-mash between Pascal, Perl, C, and Python. Those are all good languages... but I didn't see any reason why Pascal, Perl, C, or Python users should switch to your language.
Remember that getting in a language is hard. Right now, many programming tools already support the major languages. Unless you have a large corporation behind your language, it's hard to get enough mindshare to get all the tools that programmers want. Are you really willing to do the compiler, debugger, profiler, editor, and all yourself? Across all platforms?
Before you create a new language, I recommend that you do two things:
Re:What nobody else wants (or will say)... (Score:5)
No offense at all, but unless you're coding an OS, you need to let go of your outdated concepts of low "level code running super efficient" and recognize that abstraction and OOP are here to help the HUMANS - the HUMANS are not created to help the machine! Just imagine Linux being ALL ASM! Unmanageable.
Likes/dislikes (Score:4)
Likes
Digit grouping- makes programs far more readable
Base selection- Will make low level programming easier by making the bases explicit. No more problems due to forgetting an h or b.
In/out specifying in param lists- will increase efficiency and help tell when functions will actually change a parameter.
Dislikes
Tabbing as program structure- Its going to cause problems. People will think that lines will be executed conditionally when they won't be due to forgetting a tab (and vice versa). The reason for a grouping char was to force them to think about what is/isn't in a statement
Underscore ignoring- Too confusing. People will try to read each others code and be unable to figure out what open_file is. Either make _ illegal or let it be a full character.
Too many keywords- will make language hard to learn. Plus too much typing.
Preconditions- If one compiler uses it for optimization and another throws an error at a broken one, your code will do two VERY different things on the compilers. Choose one, then it may be cool.
Named/out of order arguments- will cause confusion and bugs
Lack of types- will cause inefficencies of too much/little space being allocated. Also having compiler defined types like integer wioll make programs too compiler dependent.
Customizable for/cases/etc- It will cause confusion when programmers start taking standard language ideas and twist them. Trust me on this.
No opinion
Case insensitive- doesn't make a huge difference, but I do see it causing confusion as the _ ignoring will.
Im curious- what is the use of this language? I see a basic language, a lot of sytactic sugar with no real use, and a lot of features that will make compiler writing EXTREMELY difficult. Not to mention that most of the language features will be rarely used- You really are trying to add too much to one language. This language does everything, but wont be able to do all of it well. Jack of all trades, master of none.
And you have one major question left to answer- So why should I use it? What feature(s) does it have that the existing languages don't? I don't see any- in fact you define its features in terms of other languages that have them. You need something that is yours and yours alone if you want this to suceed.
Mandatory comments are a better idea (Score:3)
Indentation should help the programmer to understand the code. It should not be an additional source of worry.
As such, indentation should represent the program structure. It should not embody it.
First, because this approach makes it possible to compute the indentation from the program structure, and this helps to flag many errors without the need for compilation.
But perhaps more importantly, because the indentation is computable, it is discardable.
And this makes the language easy to transcribe: you can easily copy and paste snippets of C or Perl code to and from weblogs and email messages and get them to compile, usually without worrying about spaces or tabs or newlines or any such transformations that may have occurred in the process.
Yes, properly indented code looks gorgeous, and this counts. But in any non-trivial program, semantical ugliness quickly dwarfs syntactical ugliness.
Mandatory comments would be a better idea.
Nice feature list, a few comments (Score:5)
Comments. Make it really easy to provide strong in-line documentation. Don't, for example, emulate whatever brain-dead folks at M$ are responsible for VB still not permitting comments after the "_" used for line continuations, making it impossible to have function parameters documented one-per-line. Consider multiple documentation-related conventions, e.g. "//" for end-of-line comments, perhaps support for standardized structured comment blocks in preambles, ways to comment-out and uncomment blocks of code, ways to group sets of procedures, ways to draw separator lines etc. within listings (printed listings are still useful even in this day and age), ways to generate indices/crossrefs etc. Think of it as an algorithm publication problem.
PL/1 disease. You've proposed lots of good features. However, as others have pointed out, it will be easy to overload the language with a bazillion keywords and features to satsify every participant's biases. At the end, there will be n separate incarnations of the language, consisting of each user's set of preferred constructs. Nobody will really grasp the whole thing. Instead, strive for the kind of expressive purity of C (better: LISP), where a small number of primitive syntactic components can yield a rich semantics. It's a hard problem, and frankly a collaborative effort rarely can yield the conceptual purity that a single author can impart. But don't give up.
Extensibility. The most useful languages (IMO) can be extended to suit new situations. In many complex environments, it's better to adapt the language of the solution to match the language of the problem. This is why meaningful names, operator overloading, shared libraries, named constants, preprocessor definitions etc. are so helpful -- you can extend a language's working suite of concepts by documenting the specific interfaces used to interact with a particular execution environment or problem domain. So, for example, resist including I/O primitives and instead make it easy to create extensions from within the language. (Why consider them extensions rather than just traditional function calls? So that we can specify compile-time properties and behavior for their interfaces, such as argument marshalling, synchronization, error handling, exception conditions, etc., without bloating the runtime environment.)
Encapsulation. We should always be able to replace a named entity that appears to be an atomic value (integer, string, etc.) with a named property having a complex programmatic implementation, with either compile-time or run-time behavior. Such a replacement should be transparent to clients of the associated interface or name. Preferably, this should be possible within a narrow lexical scope, not just between packages or interfaces.
Integrated data definition/metadata. Try to bridge the gulf between the language's internal namespace and the external database environment. It should be anathema to reference entities using names stored or specified as character strings ("MyDatabase.OpenTable('Employees').Fields('SSN')" as we must do in so many languages when referencing external data). Instead, somehow let us bind the external data definitions into the compiler's namespace, so that referring to "Employees.FirstNaame" generates a compile-time error. (Obviously, we need to control the binding semantics so that in some cases this occurs at run-time, in some cases at link/load time, in some cases at compile-time, in some cases at preprocessing time.) Ideally, the same mechanism should support run-time interfaces to external resources such as CORBA components, including run-time retrieval of interface metadata.
Incremental compilation. Design the interactive programming environment, the language, and the compiler together, a la Smalltalk, rather than using the raw source code paradigm. Assume that we'll want the ability to dereference variables, determine variable scope, jump to definitions, view cross-references, etc., all while editing the source. This isn't really a language design issue, other than putting an emphasis on components that support separate compilation. But if you build your first compiler this way, e.g. via a p-code implementation, all your successor environments will preserve the interactive development model rather than the batch compilation model.
Explicit declaration and lexical scope. Help us find those dangling/incorrect references.
Constants and other compile-time tools. Give us strong support for creating highly-readable code that nevertheless can compile efficiently into in-line code and integer arithmetic. Combining the ability to drill-down to the physical machine with high-level encapsulation and incremental compilation would give us a wonderful span of control. (This is what we love about Smalltalk, being able to hack the running device drivers from inside the source code editor.)
Asynchrony, continuation-passing, message-passing, interrupts, critical sections, real-time constraints, shared memory, etc. Give serious thought to how deep issues of OS programming would be handled. If possible, address such issues through highly-visible fundamental mechanisms rather than hacks. For example, if you want to provide a way for two execution threads to share write access to a variable, implement some kind of encapsulation that provides well-defined interfaces and behaviors, rather than permitting indeterminate and possibly system-crashing results by making it look like a normal variable.
Well, that's enough blather for the moment. I hope these comments are useful. A few inspirations I'd love for you to consider in language design: C and BLIS, for their conceptual simplicity; Cedar, for its richness and language/environment integration; Smalltalk, for its extensibility and structural encouragement of small code fragments rather than monolithic procedures; CLU (and Simula and Smalltalk and SQL-embedded languages) for integration of external and internal data.
Good luck. -- Trevor
Mozart, what an original name! (Score:3)
Comments on the features so far (Score:3)
Current Features
The current features I didn't mention are the ones I thought were well thought out or didn't really have any issues with.
- style insensitive names: These sounds like it will cause more confusion and cause more problems than it will solve (that said, is there actually a problem that it solves or was this just a cool feature you thought of hacking in?).
- using keyword: Be careful about Keonig lookup [hp.com] if your language isn't going to dynamically load classes like Java does. Some people think the "using" or "import" style keywords should behave like #include but they usually are more subtle than that.
Features To ConsiderRe:Another victory for buzzwordism! (Score:3)
My first thought on "open source programming lanugage development" was along the lines of: "You mean... like this?"
Suppose someone, call him "Dennis", produces their own computer programming language. For the sake of argument, let's call our example language 'C', because it programs Computers.
Dennis releases the language C to the public domain, by releasing sources (specs).
Then suppose someone, call him Richard, comes along and takes C and adds a few bits and pieces he wants in it plus some ideas some other people have had. Something he can only do because the language is, er, "open source".
Then, say, Bjarn and Steve come along and decide to add some features to C and Richard's C (who has named his after his favourate animal) to make it support object orientation. Bjarn calls his version "C++", and Steve calls his "Objective C".
Then, someone else, ooh, I dunno, Bill J, and maybe another person called Bill G, decide to take C++, and clean up the language and implement a virtual computer architecture in it. Bill J names his after his favourate brand of coffee, and Bill G names his after a musical note.
And all of them are able to do this because:
Dennis made his language "open source" by releasing the specs, so Richard and Bjarne were able to add features.
Richard made his extentions to the language "open source" so Steve was able to add features.
Bjarne made his extentions "open source", by documenting them again, so Bill G and Bill J were able to add features.
Would that be what "open source" development of a programming language would be like?
--