Feature request: one-statement functions without brackets

[David B. Held]

Jari-Matti Mäkelä wrote:
> [...]
> I personally would like to see the gap between static (compile time) and
> dynamic (runtime) worlds closing. There are so many similarities between
> templates and ordinary functions & lambdas. Also type inference could be
> more general. Of course I understand Walter has only limited time and
> everyone has their favorite feature request, but these things look
> important to me ATM.

I assure you that you are not the only person who feels that way. ;)

> It just seems that there's no clear roadmap and the
> language is just wandering blindfolded there somewhere. What do you think?

I think that the most important industrial language today is C++, which 
was created by an engineer trying to solve real world problems with 
real-world constraints.  On the other hand, there is no end to 
academically designed "pure" languages (I don't mean 'pure' in the 
technical sense, but rather the aesthetic one), but few to none of them 
are commercial/industrial/popular successes.  So while languages built 
around "religious principles" (everything is an Object, everything is 
message-passing, everything is a function, etc.) may be elegant, they 
are often not entirely practical.

Somewhere in between Haskell and C is a set of compromises that result 
in an elegant type system that recognizes that memory is not infinite 
and processors take real clock cycles to get things done.  While D does 
not necessarily position itself ideally within this space, I think it 
offers some compelling features in a unique combination that is fairly 
rare in many of the newer languages.

I think the idea of a roadmap is alluringly misleading.  It presumes 
that there is a best way to design a language, in the way that there 
might be a best way to design an operating system or a car.  At the end 
of the day, a programming language is a tool to solve problems. 
Sometimes those problems are nicely solved by a set of features that fit 
together like a jigsaw puzzle, and other times problems require a 
pocketknife and some elbow grease.  Being able to maintain that balance 
is, I think, the key to producing a language that possesses both beauty 
and utility.

Personally, I find Don Clugston's metaprograms to be fairly exquisite, 
because they demonstrate a simplicity and power that similar programs in 
other languages stuggle for.  Of course, Lisp can pretty much do 
anything that any other language can, within reason, but at the expense 
of syntax.  Don's programs still look like programs.  Haskell can be 
even more elegant and concise, but odds are, you will never be able to 
drop down into inline assembly and hack some SSE instructions into an 
inner loop to squeeze that last bit of performance out of your program. 
  The fact that Walter gives you a screwdriver and lets you get at the 
bare metal is not something to be taken lightly, but it does require 
some sacrifices in the language (you could never give the kind of 
security guarantees that Java can, for instance).  You can't eat your 
cake and have it too.

So, although the development of D may seem 'haphazard' at times, that is 
the nature of all great art.  If you saw Michaelangelo's 'David' when it 
was half-complete, it would probably look a little haphazard as well.
Unfortunately, there is not enough science to design a language from 
start to finish with every feature you might want to add.  So you have 
to build it up by pieces and hope that what comes out in the end is 
something that you enjoy using.  And if you really want D to become more 
refined and elegant, then code, code code.  There's nothing like 
real-world use cases to motivate making a potentially painful change to 
clean things up.  Walter is very open-minded about his language, but 
he's also very practical.  He's not going to waste his time implementing 
something that he doesn't think anybody will use.

The more you expose the rough edges of the language with practical 
programs, the more motivation will exist to recast those features in a 
more refined mold.  It also doesn't hurt to air your feature wish-lists, 
either.  I mean, there's no guarantee that anything will get 
implemented, but it's human nature to oil the squeaky wheels.  Squeak 
loud enough, and you might get your black gold...

And if you *really* want to see the language succeed, lend a helping 
hand.  If you haven't noticed, there isn't exactly a Sun or IBM or 
Microsoft throwing its weight behind D...yet.  Most people would agree 
that the success of Java had as much to do with its rich library set as 
anything else.  There's a bajillion different D libraries you could 
write, and each one has the potential to make D more attractive to other 
programmers.  Not only that, but the front-end is completely Open 
Source, so you can even experiment with your own feature ideas without 
even bugging Walter.  Finally, keep in mind that tools really leverage 
the productivity available with a language.  Helping out with toolchains 
is probably the single biggest help you could offer, and there are 
plenty of projects that could use the manpower (or womanpower, as the 
case may be).

Dave