On Thursday, 18 December 2014 at 14:34:10 UTC, Manu via
Digitalmars-d wrote:
On 18 December 2014 at 23:52, Mathias LANG via Digitalmars-d
<digitalmars-d@puremagic.com> wrote:
On Thursday, 18 December 2014 at 10:47:56 UTC, Manu via
Digitalmars-d wrote:
I think you've missed my entire point.
The summary is this:
Tried D, tried a very popular and often hyped D
library/framework,
encountered bugs. There was friction along the way which
undermines
confidence, but the critical point, the thing that caused the
call to
be made, was that the debugger didn't work, and we were
unable to
diagnose the bug with relative ease.
It's possible that wouldn't have inspired the call to be made
if it
weren't for the prior friction... ie, if it were the first
point of
friction, we might have persevered through that one, but the
aggregate
prior to that point painted a clear picture, and that was the
proverbial straw.
Immaturity in the language seemed to allow for greater
tolerance than
immaturity in the tooling.
This is the experience I was trying to convey... which was to
be taken
as a case study, that is all.
What I'm wondering is how is it you didn't encounter this
issue yourself
before ? If you've been using D for 6 or 7 years, and it was a
small project
that was done in 20 to 30 lines of node.js ? So you clearly
entered unknown
territory and expected everything to be fine, despite your
experience with
D.
Simple, I never tried to use websockets in vibe.d
I had some past experience with vibe.d to do some web page
stuff, and
my experience was practically flawless, which is why I had
confidence
in it in the first place.
Other common language issues that I did anticipate, I expected
to be
able to work through. I did know the debugger was an issue; it
was
actually my biggest fear going in. It did turn out to be the
thing
that bit me in the arse!
I just hoped/expected we wouldn't need the debugger in such a
small
and simple program.
The debugger does work okay for certain tasks, particularly if
you
control your coding style and make sure it's compatible with the
debugger. I didn't have that luxury though as I usually do,
since we
were working on a foreign framework.
Can you link us to the issue(s) you created on Vibe.d's Github
?
https://github.com/rejectedsoftware/vibe.d/issues/931
I can't really articulate the problem well. Google's Native
Client is
a part of the puzzle, and that's a complex environment to get
working.
We tested the NaCl client against some other websocket servers
though,
and the problem didn't occur.
I want to try and isolate a test case if I ever get some free
time at work :/
The other problem I can't isolate, it's just that the first file
that's requested from time to time locks up the browser... if I
kill
the browser, reload and refresh, the problem goes away.
I'll also see if I can post some code that demonstrates that
case, but
I have my suspicions that's client specific too.
We know some stuff sux. Just look at std.datetime's
documentation. On my 15"
laptop, the links take all the screen. And this part is
totally useless, as
no one is going to use it (beside ctrl + f, but you have to
know what you
are looking for). Not mentioning the size of enum (just look
at how much
space trivial enums such as "DayOfWeek" or "Month" takes).
However, many of us lack the time and interest to fix this, as
we know our
way around. The same goes for all the tooling/libraries, they
were
developped, and are maintained out of one's necessity, not
because "we" need
it.
I know. I only said that there were a lot of complaints
relating to
the documentation, because there were.
Although that said, as far as I can tell, it wasn't a
particularly
heavily weighting factor in the decision. Just worth noting; it
wasn't
endearing to anyone.
So to sum things up
1. you blindly walked into something you had no real experience
with, apart from some vague memory that some parts of vibed
worked for you a while ago.
2. you knew the debugger might be an issue, if not _the_ issue,
but chose not to test it beforehand, or couldn't test it
beforehand, because
3. you were working on a foreign framework (and simply hoped
things would work out fine, fingers crossed!).
These are crucial bits of information that were missing from your
first report.
Please try to be more accurate the next time. Holding back
crucial information gets us nowhere. It only leaves the (false)
impression that D is completely unusable.
