On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
Configuring compilers:
Naturally, this is primarily a problem with the windows
experience, but
it's so frustrating that it is STILL a problem... how many
years later?
My first setup took me days :D Somehow it improved. It still
sucks.
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).
I came to the same conclusion, and that is why SDC is relying on
libd. Our tooling sucks hard.
Obviously, we settled on Visual-D (Windows) and Mono-D
(OSX/Linux); the
only realistic choices available. The OSX user would have
preferred an
XCode integration.
I don't know any dev that is happy of XCode, even OSX lovers. I
mean, how good is a editor that propose you to export functions
to iTune (I should try it one day, I really wonder what it does),
but not finding declaration in its contextual menu ?
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.
Considering DMD never deallocate anything, expect to restart your
IDE every hour or so.
Debugging:
Ho god ! The demangler do not demangle most things. Hello stack
trace of incomprehensible symbol. If gdb is able to give me
file/line, druntime is completely unable to do so, so you have to
use external tooling to get back this info.
The best of the best being too long mangling being truncated in
the output. Backtrace is the bare minimum to dubug and it isn't
working.
Documentation:
Okay for the most part, but some windows dev's want a CHM that
looks like
the typical Microsoft doc's people are used to. Those that
aren't familiar
with the CHM viewer; it's just HTML but with a nice index +
layout tree.
I don't understand that. I never understand anything at MS
documentation because of its look and feel (the content is
usually pretty good).
I guess it is matter of taste/habit.
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...
Me miss 1 piece in the language to make that work properly (and
another one to make that more effiscient). Namely covariance on
template instances and allocators.
I've been raising the first one as it is also a problem for SDC.
People raised it to implement AA as lib, and it is a recurring
discussion around dcollection.
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.
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).
Arguably, this is because of lack of IDE support and because C++
screwed you up :D I recognize the feature as good to have, but
definitively not as big as an issue as the one mentioned above.
If the problem mentioned before are solved, then this one won't
be a big issue.
I'm doing some more work on premake (a nice light buildsystem
that
generated makefiles and project files for popular IDE's) to
tightly
incorporate D into the various IDE's it supports.
That look a good project !
