The good news (for me anyway), is that there aren't too many surprises - most of the points being brought up are things I have spent a long time considering. That doesn't mean that I should dismiss these points out of hand, however.
I see that there are a number of complaints which recur frequently in that thread. One is about the retention of "null" in the language - the so-called "billion dollar mistake". I've written about this before - getting rid of null gets rid of some good things as well as some bad. I think that the best I can hope for is to reduce the need for null in most cases, without getting rid of it entirely. Disjoint types goes a long way towards removing the need for null, but they are not appropriate for every situation. A prime example is an array of object references - you have to initialize the array elements to something, and whatever that something is (null or void or sentinel object whatever) is going to cause an exception if you use it incorrectly. (You could enforce that arrays can only contain "optional" types - but that makes arrays a pain to use. You could always require a specific "fill value" for new arrays - but that also makes arrays a pain to use. Or you could do what many functional languages have done and just ban arrays altogether, so that everything ends up being cons'd lists.)
Another recurring theme in the thread is the lack of concurrency primitives in the language. My response to that is there are a lot of languages which do quite well on multiprocessor systems without having concurrency baked into the language itself. Most of the languages that I have seen which do have syntactical support for concurrency also constrain the programmer to one particular style of concurrent programming - message passing, immutable shared state, actor models, and so on. I would much rather make a language that is flexible enough to let users of the language define such constructs for themselves, and let them compete in the marketplace until there is a clear winner.
Lack of libraries: This is a feature, not a bug. One of the things that makes Tart so much fun to work on is the blank slate - total freedom from all those irritating library decisions made by Sun Microsystems, Microsoft, or the C++ standards committee. Also, having multiple return values and disjoint types has a dramatic impact on library APIs, so you wouldn't want to be shackled to the old libraries anyway. (That being said, it should be easy to call external libraries like zlib - expecting the entire world to re-write everything in your language is unrealistic to say the least.)
More generally, the kind of people I'd most like to attract right now are people who enjoy writing libraries.
Garbage collection: Tart doesn't actually force you to use garbage collection, however, the presence of GC has a huge impact on the design of the standard library - for one thing, a big part of the design of any nonGC API is object lifecycle management, and that problem just goes away with GC. And since I'm not ambitious enough to write two standard libraries (one with GC and one without), I'll leave that as an exercise for whoever wants it badly enough.
There's a lot of complaints about syntactical choices, which I really can't respond to, since that's mainly a matter of personal preference. The only thing I will say is that I have specific theories about how much punctuation a language ought to have in order to maximize readability - neither too much nor too little. The easy recognition of a particular piece of code not only depends on the actual letters and symbols themselves, but also the shape of the code as it is laid out on the screen. (Exercise for the reader: Take a sample of code, and replace all letters with 'x' - can you still get a rough sense of the structure of the code?)
In any case, the important thing for me is not to get discouraged by negative comments - it's easy to point out flaws, more difficult to make positive contributions. And there are many areas where I could be convinced to change my mind with a sound enough argument.
No comments:
Post a Comment