On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
The only compiler you can realistically use productively in
windows is
DMD-Win64, and that doesn't work out of the box.
We needed to mess with sc.ini for quite some time to get the
stars aligned
such that it would actually compile and find the linker+libs.
I also spent a decent bit of effort getting Win64 to work, and I
agree that this is something that DMD should attempt to bundle.
It may not need to go as far as downloading VC express for you,
but it should allow integration of an existing install during
installation (and ideally post-installation as well). This is a
pretty big deal IMO. When I was a newbie, issues with COFF vs
OMF, coffimplib confusion, etc, were almost deal-breakers to me.
I just couldn't get things easily working, and I'm sure many
others see it the same way. Having Win64 gives us a chance to fix
that, but it *has* to be integrated into the installer. The
compiler should ideally detect that the VS linker / libraries are
missing when you use -m64, and tell you how to download VS
Express as well as directing you to a batch file bundled with DMD
to update sc.ini. Going a step further, it'd be even nicer if
-m64 was default but that's not feasible with external
dependencies. However when it detects a library in an invalid
format, it should inform you about the existence of coffimplib
and a download link, as well as how this is necessary only when
compiling 32-bit executables. I don't think that the core
contributors realize how incredibly frustrating these issues are
to beginners, and thus feel as if it's not something that needs
to be solved.
Getting a workable environment:
Unsurprisingly, the Linux user was the only person happy work
with a
makefile. Everybody else wanted a comfortable IDE solution (and
the linux
user would prefer it too).
!!!!!!!!!
This has to be given first-class attention!
I am completely and utterly sick of this problem. Don made a
massive point
of it in his DConf talk, and I want to
re-re-re-re-re-re-re-stress how
absolutely important this is.
!!!!!!!!!
I have to say, I don't see why you find this to be such a large
issue. DMD is unique in the sense that it's the only thing I've
ever been able to compile on Windows without running into many
issues. So long as you have DMC installed, it just works. I've
never had any makefile related issues on any platform. This is a
big deal, as DMD evolves so rapidly that users should be able to
get the git version with minimal effort, without having to
download an IDE for it.
Overwhelmingly, the biggest complaint was a lack of symbolic
information to
assist with auto-completion. Visual-D tries valiantly, but it
falls quite
short of the mark.
This goes back to the threads where the IDE guys are writing
their own
parsers, when really, DMD should be able to be built as a lib,
with an API
designed for using DMD as a lib/plugin.
I think continuous code compilation for auto-completion and
syntax
highlighting purposes should be a service offered and
maintained by DMD.
That way it will evolve with the language, and anyone can use
it without
reinventing the wheel.
While yes, it would be wonderful if we could get DMD to do this
(again, I don't think a lot of the core contributors realize just
how incredibly important IDEs and perfect auto-completion are),
it doesn't seem to be something likely in the short-term. That
being said, I've actually found Mono-D to be excellent recently.
It doesn't handle things like CTFE properly and other similar
issues, but for my purposes it's worked rather well (that being
said, I avoid mixins for the most part, largely due to this).
Despite all this, I'm actually quite happy with Mono-D lately.
One thing I've toyed with is the idea of using reflection for
getting auto-complete information. I made a runtime reflection
module (has a fair few issues still), and I wonder if it would be
possible to use something similar for this purpose. Most modules
could be cached, allowing us to build only the module you're
altering. On top of that, some real-time parsing could be done
for code modified since the last recompile (really it would need
to primarily handle scanning for methods and variables). History
completion from the current file, such as what editors like
Sublime Text do, could perhaps be integrated to completely
eliminate the issue of not being able to find a symbol in your
auto-complete list. That would likely only kick in when it finds
no results for anything else. Plus since you're recompiling
frequently in the background, you would get early notifications
of errors/warnings like you would in C#/Java. Ultimately though,
I'm not sure if this would be updated fast enough (depends how
long compiles take) to be feasible.
Debugging:
Poor debugging experience wastes your time every 5 minutes.
I can only speak for the Windows experience (since we failed to
get OSX
working); there are lots of problems with the debugging
experience under
visual studio...
I haven't logged bugs yet, but I intend to.
There were many instances of people wasting their time chasing
bugs in
random places when it was simply a case of the debugger lying
about the
value of variables to them, and many more cases where the
debugger simply
refused to produce values for some variables at all.
This is an unacceptable waste of programmers time, and again,
really burned
us in a 48hour context.
Agreed, debugging is currently lacking thoroughly. Using Linux,
Mono-D's works okay but it still jumps around a lot (even in
debug mode) and hovering over variables isn't great yet. I really
miss the Immediate Window from C# / Visual Studio, and it would
be nice to have that. This is something that runtime reflection
could handle.
Containers:
The question came up multiple times; "I don't think this should
be an
array... what containers can I use, and where are they?"...
Also, nobody could work out how to remove an arbitrary item
from an array,
or an item from an AA by reference/value (only by key).
This code:
foreach(i, item; array)
if(item == itemToRemove)
array = array[0..i] ~ array[i+1..$];
Got a rather 'negative' reaction from the audience to put it
lightly...
Completely agreed. Containers are another huge problem which
needs to be solved as soon as possible, yet is constantly getting
pushed back. The idea that a language like D doesn't even have
anything but the most basic containers in it's standard library
is laughable. I shudder to think at how many different
implementations exist of common containers right now in user code.
Bugs:
Yes, we hit DMD bugs, like the one with opaque structs which
required
extensive work-arounds.
struct MyStruct;
MyStruct*[] = new MyStruct*[n];
We also ran into some completely nonsense error messages, but I
forgot to
log them, since we were working against the clock.
I used to hit compiler bugs very frequently, yet this is
something that D has improved incredibly on. It's wonderful to
not have to worry with every compile if there will be bugs. It's
also wonderful to not have to worry about changing your code with
every single compiler release. D has made *huge* headway in these
two issues. Sure, there are still many bugs, but they're becoming
less frequent for me and I find that workarounds are easier than
before.
One more thing:
I'll just pick one language complaint from the weekend.
It is how quickly classes became disorganised and difficult to
navigate
(like Java and C#).
We all wanted to ability to define class member functions
outside the class
definition:
class MyClass
{
void method();
}
void MyClass.method()
{
//...
}
It definitely cost us time simply trying to understand the
class layout
visually (ie, when IDE support is barely available).
You don't need to see the function bodies in the class
definition, you want
to quickly see what a class has and does.
This isn't something I've found to be an issue personally, but I
suppose it's a matter of what you're used to. Since I'm used to
C#, I haven't had problems with this. I've always felt that this
was the IDE's job, personally. That being said, perhaps .di files
could help with this?
