Unofficial wish list status.(Jul 2008)

[Walter Bright]

Yigal Chripun wrote:
> The word example is wrong in that, in your example, bill doesn't need
> feature #1678, and sue doesn't need #543. The answer to that is a model
> similar to eclipse: both sue and bill can use eclipse but since bill
> works with c/c++ he can get a pre-packaged version with CDT which is
> much smaller than the entire eclipse project, and sue can get her
> eclipse pre-packaged with JDT since she works with Java. This is why
> Eclipse is so popular and supported by many large companies like oracle,
> IBM, etc.. The same goes to the popular browser Firefox and its
> extensions. No need to bundle everything like Microsoft word does, it's
> much better to have a system to allow users to integrate features they
> require beyond the lean & mean core.

What you're saying is provide a lean & mean core with a pluggable 
architecture that can be extended by 3rd parties. I think you're quite 
right that that is a better system than all-in-one.

D has a lot of support for "pluggable architecture", such as template 
metaprogramming and string mixins. Lisp is famous for being a very 
pluggable language.

Unfortunately, I don't see any way to be able to "plug in" the needed 
support for functional coding, there just isn't enough basic capability 
in the language. We're trying to fix that.

> C++ as an example: its syntax is horrible due to the fact that it can do
> so much.

I don't agree with that being the reason its syntax is horrible. The 
reason is more related to efforts to preserve backwards syntax 
compatibility, and because some expert advice was ignored in the case of 
using < > for templates.


> if I only do OOP, I'll prefer a syntax like Ruby or Smalltalk
> or something like that. if I want to do procedural code I'll prefer C
> syntax instead, but I definitely do not want to have a compromise of
> both syntaxes in one language (we all know that a programing language is
> an agreed upon compromise) that will not allow me to express my OOP code
> in a concise OOP way and also will not allow me to express my procedural
> code in a concise procedural way.
> 
> an everything-including-the-kitchen-sink language cannot provide concise
> syntax for any of the paradigms it supports.

You're right, it can't, but it can provide good enough syntax that 
overweights the large disadvantages of trying to get two very different 
languages to work together.