What Makes A Programming Language Good

[Vladimir Panteleev]

On Tue, 18 Jan 2011 13:28:32 +0200, Walter Bright  
<newshound2 at digitalmars.com> wrote:

>>> What is that message?
>>  C:\Temp\D\Build> dmd test1.d
>> OPTLINK (R) for Win32  Release 8.00.8
>> Copyright (C) Digital Mars 1989-2010  All rights reserved.
>> http://www.digitalmars.com/ctg/optlink.html
>> test1.obj(test1)
>>  Error 42: Symbol Undefined _D5test21fFZv
>> --- errorlevel 1
>>  1) The error message is very technical:
>>   a) does not indicate what exactly is wrong (module not passed to  
>> linker, not that the linker knows that)
>
> There could be many reasons for the error, see:

Sorry, you're missing the point. The toolchain has the ability to output a  
much more helpful error message (or just do the right thing and compile  
the whole project, which is obviously what the user intends to do in 99%  
of the time).

> http://www.digitalmars.com/ctg/OptlinkErrorMessages.html#symbol_undefined
>
> which is linked from the url listed:
>
> http://www.digitalmars.com/ctg/optlink.html
>
> and more directly from the FAQ:
>
> http://www.digitalmars.com/faq.html
>
>>   b) does not give any indication of what the user has to do to fix it
>
> The link above does give such suggestions, depending on what the cause  
> of the error is.

This is not nearly good enough. I can bet you that over 95% of users will  
Google for the error message instead. Further more, that webpage is very  
technical. Some D users (those wanting a high-performance high-level  
programming language) don't even need to know what a linker is or does.

>> 2) OPTLINK doesn't demangle D mangled names, when it could, and it  
>> would improve the readability of its error messages considerably.
>>    (I know not all mangled names are demangleable, but it'd be a great  
>> improvement regardless)
>
> The odd thing is that Optlink did demangle the C++ mangled names, and  
> people actually didn't like it that much.

I think we can agree that there is a significant difference between the  
two audiences (users of your C++ toolchain who need a high-end,  
high-performance C++ compiler, vs. people who want to try a new  
programming language). You can make it an option, or just print both  
mangled and demangled.

>>> dmd can build entire programs with one command:
>>>
>>>     dmd file1.d file2.d file3.d ...etc...
>>  That doesn't scale anywhere. What if you want to use a 3rd-party  
>> library with a few dozen modules?
>
> Just type the filenames and library names on the command line. You can  
> put hundreds if you like. If you do blow up the command line processor  
> (nothing dmd can do about that), you can put all those files in a file,  
> say "cmd", and invoke with:
>
>      dmd @cmd
>
> The only limit is the amount of memory in your system.

That's not what I meant - I meant it doesn't scale as far as user effort  
in concerned. There is no reason why D should force users to maintain  
response files, make files, etc. D (the language) doesn't need them, and  
nor should the reference implementation.

-- 
Best regards,
  Vladimir                            mailto:vladimir at thecybershadow.net