Stroustrup's talk on C++0x

[Jari-Matti Mäkelä]

eao197 wrote:

> On Mon, 20 Aug 2007 17:31:59 +0400, Jari-Matti Mäkelä
> <jmjmak at utu.fi.invalid> wrote:
> 
>>>> I would put my hopes on the macros, type system and other
>>>> metaprogramming
>>>> stuff.
>>>
>>> If someone really need flexible macro- and metaprogramming-subsystem it
>>> is
>>> better to look to Nemerle.
>>
>> It isn't well suited for system programming.
> 
> What kind of system programming? Writting compilers and writting drivers
> are examples of system programming, but Nemerle is well suited for the
> first, but not the second. Is low-level system programming (like drivers
> really need macros or/and metaprogramming)?

If you look at e.g. linux sources there's some heavy use preprocessor
macros. With proper language support that could be made less error prone
and productive. Even some formal proofing might became possible.

Nemerle isn't bad as a language, but it doesn't scale to low level stuff as
long as it runs on a VM. In my opinion having a language that scales from
driver/kernel level to end user GUI apps and OTOH from asm opcode level to
high level FP constructs isn't a bad idea. For example game development is
one area where more speed and abstractions are always welcome.

I suppose most application programs will run in a VM in the distant future,
but at the moment at least my PCs are crying for mercy if I try to run
bigger Java apps (running code analysis for a relatively small Java GUI app
took about 2 hours in Eclipse). Flash applets aren't any better: a 300x200
mpeg2 movie can choke the system even though mplayer plays several
simultaneous 720p streams just fine. The only .Net app I've used was a
video card control panel on Windows. It felt too unresponsive to be usable
in the long term.

> 
>>>> Those are areas in which C++ doesn't really shine.
>>>
>>> IMHO, macro and metaprogramming are areas which C++ simply does not
>>> need.
>>> It is much easyer to write some small codegeneration script in
>>> Perl/Ruby/Python and include its result into C++ via '#include'.
>>
>> Is it better for each C++ coder to write his own domain-specific build
>> tool
>> to solve exactly the same problem than bolt that functionality to the
>> core
>> language?
> 
> There are more modern than make build tools (like Scons) which make
> pre-compile-time code generation more smoothly task.
> 
> And after years of C++ development I've came to conclusion that usage of
> C++ and some scripting language (like Ruby) is more flexible, easy and
> fast than usage of only one main language (like C++/Java).

I agree. But I was on another abstraction level. Things like the active and
atomic keywords in C++0x are features that are much easier to implement
with builtin macro functionality than 3. party preprocessors / build tools.

> 
>> In case you haven't noticed,
>> there are already 18+ GUI toolkit bindings/implementations (according to
>> wiki4d) for D and D is 41 years younger than Lisp.
> 
> Do you think that 18+ GUI bindings is good thing?

Probably not.

> I know that D has two standard libraries and this is not good at all :(

I know :/