Lost a new commercial user this week :(

[Chris via Digitalmars-d]

On Thursday, 18 December 2014 at 10:47:56 UTC, Manu via 
Digitalmars-d wrote:
> On 17 December 2014 at 20:34, Chris via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
>> On Wednesday, 17 December 2014 at 09:48:43 UTC, Paolo 
>> Invernizzi wrote:
>>>
>>> On Wednesday, 17 December 2014 at 09:34:45 UTC, Dicebot wrote:
>>>>
>>>>
>>>> To start using D effectively in production one needs to stop 
>>>> considering
>>>> himself a customer. This is absolutely critical.
>>>
>>>
>>> This is a very interesting point: thanks you.
>>> ---
>>> Paolo
>>
>>
>> I second this, it's a very good point. The customer attitude 
>> permeates this
>> whole thread. D is not a framework for very specific tasks in 
>> limited
>> domains like node.js. Is is a programming language that can be 
>> used to build
>> frameworks (like e.g. vibe.d) If you only need a feature or 
>> two for a web
>> project (as the 20-30 lines of JS that were mentioned 
>> suggest), you probably
>> shouldn't use vibe.d. Only if you want to create something 
>> bigger, build an
>> infrastructure from scratch say, or need high performance, 
>> should you
>> consider vibe.d, which does have a certain learning curve, no 
>> doubt about
>> it, as does D. I use vibe.d now but before I started to use 
>> it, I had tested
>> it for a while to see, if it suited the project, which 
>> included playing
>> around with it in my spare time. I did this with other D 
>> projects too.
>
> 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.

I didn't miss your point. I know you were going on about the 
tooling/infrastructure and not about the language. However, the 
approach of using a rather complex framework like vibed without 
giving your colleagues any hint about how D works is simply not a 
good idea and bound to fail. Of course they cannot find their way 
around, of course they have no clue where to start when they 
encounter a problem. And to use something like vibed for a 
trivial 20-30 line node.js solution is beyond comprehension for 
me. In doing so, you haven't done D a favor, and it's neither D's 
nor the tools' fault.

>> I don't think it's a good idea to tell people about how great 
>> D is and then
>> throw them right into it without any preliminary training. It 
>> is, after all,
>> a fully fledged programming language, not an API for certain 
>> tasks like
>> querying a web server. A language like D has to be _learned_, 
>> concepts have
>> to be _understood_, even if you are already familiar with C++, 
>> Java or C#.
>
> Again, you completely missed the problem. I haven't said 
> anywhere that
> the language itself raised any particular issues.
> It was the *tooling*. There were also numerous complaints about 
> the docs.

The docs ain't that bad. I've found my way around in worse docs 
than D's. I'm beginning to wonder, if the heavy reliance on tools 
doesn't spoil people. If it ain't served on a silver plate, bah, 
I won't eat it. Is that the attitude? I hope not.

>> The same is true of any of the more complex languages. I bet 
>> you that,
>> regardless of how good the infrastructure may be, you couldn't 
>> just sit down
>> and hack away without knowing the language, be it Java, C# or 
>> C++, no matter
>> how much you already know about programming. If you did hack a 
>> web server
>> together quickly, I'd be worried about the quality of the code.
>
> I would happily challenge that bet.
> I've learned Java, C#, python, js, lua, ..., by being told to 
> get a
> task done at work; expected to learn the languages within 
> minutes and
> produce a solution.
> I never had any problems with this in the past.

I honestly don't believe that you actually _learned_ all those 
languages in depth. I've used Lua, JS and Python too. I know how 
to use Lua but I cannot say I have _learned_ Lua to the extent 
that I can build complex systems with it without humbly going 
back and study some of its more advanced features and how to use 
them properly (e.g. metaprogramming). What you're saying is that 
you've _used_ the languages and found your way around to a 
certain extent, we all do that, and scripting languages are often 
quite limited, so it's easier to "learn" them.

> The only language I've ever 'learned' was C, and that was 15-20 
> years ago.

>> JS and Python are "quick and dirty" languages in the sense 
>> that they were
>> designed for people who are not really into programming, but 
>> want to get a
>> task done quick (and dirty if needs be). You cannot compare 
>> them with D.
>
> I can and I did.

Which is why this thread turned into a little flamewar. When you 
mix apples and oranges, people will take issue with it.

A note on "silver plate" frameworks. Without exception, I've 
found that every time one sets out with a "mature and tested" 
framework that has been around for a while, that has nice tools 
etc., is used by companies all over the world (because it saves 
time, not so much for reasons regarding its quality), it is to 
find out further down the road "Sh*t, that's not possible with 
xyz! What now, we cannot go back now, too much time invested. 
Well, we'll have to wait until they fix it, if they fix it at 
all." Little things developers might not think of when they set 
out, accessibility for example. It is dangerous to use something 
only because it seems easy to use at the beginning. It may cost 
you dearly further down the road. Before I decide to use a 
technology, I test it first, be it node.js, foundation framework, 
bootstrap or vibed.