On Thursday, 18 December 2014 at 11:19:11 UTC, ketmar via Digitalmars-d wrote:
> On Thu, 18 Dec 2014 10:54:22 +0000
> Ondra via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> No. There are almost no examples on practical usage of packages. Have you tried to use e.g.: std.json from scratch with only reading documentation without googling forums for help how to actually use it?
> yes. strange thing is that i had zero troubles with that. it's kind of
> thing that "just works". and reference dox doing exactly what i want:
> gives me names i need.

Strange is that you don't understand that beginner to D have different problems than guy who actively develop D library/language itself.

> i can't see what can be so hard with simple recursive data structure
> implementation.
> the same for 'std.mmfile', by the way.
mmfile is way easier and simpler to use from scratch. And I agree on this with you, both docs pages are very brief.

On Thursday, 18 December 2014 at 11:54:52 UTC, ketmar via Digitalmars-d wrote:
> On Thu, 18 Dec 2014 11:43:43 +0000
> Ondra via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> I meant more to focus only on D. Like : "What do you have most difficulty with while learning language/you were learning langeuage?" "What do you consider most confusing part of D library/language features." etc...
> that's what i'm talking about: people with different backgrounds find
> different things difficult.
>
>> I personally, have problems with: Endless confusion about class/struct. endless confussion about array slices. String details.
> see? those was the things i got almost immediately. but it's not 'cause
> i'm a kind of genious, i just used to concepts internally.
>
>> Lack of enough practical examples on library packages...
> yeah, having more practical samples is the most universal desire, i
> believe. let's hope that someone will write "Phobos Cookbook". ;-)
>
>> On the other hand I don't feel that templates are so hard. That's actually why i started to learn D.
> i bet you didn't do alot of convoluted templates in C++, aren't you?
> 'cause people with that background tent to run away screaming when they
> hear the word "template". ;-)

Well I have some and actually this was the reason I started looking for something better. I felt like C++ doesn't allow me to express myself. And I found D... which is awesome ;)

On Thu, 18 Dec 2014 12:03:55 +0000
Ondra via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Thursday, 18 December 2014 at 11:19:11 UTC, ketmar via Digitalmars-d wrote:
> > On Thu, 18 Dec 2014 10:54:22 +0000
> > Ondra via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >
> >> No. There are almost no examples on practical usage of packages. Have you tried to use e.g.: std.json from scratch with only reading documentation without googling forums for help how to actually use it?
> > yes. strange thing is that i had zero troubles with that. it's
> > kind of
> > thing that "just works". and reference dox doing exactly what i
> > want:
> > gives me names i need.
> 
> Strange is that you don't understand that beginner to D have different problems than guy who actively develop D library/language itself.
how many times i have to say that phobos reference documentation is not for beginners?

i agree that we need "Phobos Cookbook", and what i want to stress is that trying to use phobos reference dox as such cookbook is doomed to fail.

On Thu, 18 Dec 2014 12:07:53 +0000
Ondra via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> >> On the other hand I don't feel that templates are so hard. That's actually why i started to learn D.
> > i bet you didn't do alot of convoluted templates in C++, aren't
> > you?
> > 'cause people with that background tent to run away screaming
> > when they
> > hear the word "template". ;-)
> 
> Well I have some and actually this was the reason I started looking for something better. I felt like C++ doesn't allow me to express myself. And I found D... which is awesome ;)
i believe that human-understandable templates and metaprogramming are among the strongest D selling points. yet those are features that are hard to understand for many people.

> how many times i have to say that phobos reference documentation is not
> for beginners?

Let us agree to disagree on that point.

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@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.

On Thursday, 18 December 2014 at 11:21:09 UTC, Dicebot wrote:
>
> Exactly what I have meant - we don't truly have END-users. There are more involved users and less involved users, each working on parts and tools he needs. Some of those users do it in spare time and for fun, few are paid programmers enhancing tools needed to use D in their company. But there is not a single person actually selling D or getting anything from its success, maybe apart from Walter himself. How can one have customers without having sellers?
>
> We are all bunch of investors here.

SR Labs is using D under Windows and linux in production, since a long time: for example, D will be present at CES this year, powering an eye-tracker linux kiosk from the ground-up.

Sadly, currently we have not a single minute to spare, contributing back to the D ecosystem, but I've more than a hope that we can change that in the near future... finger crossed...
---
Paolo

On Thursday, 18 December 2014 at 11:50:46 UTC, Vadim Lopatin wrote:
> On Thursday, 18 December 2014 at 11:00:43 UTC, Chris wrote:
>
>> Very good! I tried it and couldn't clone the repo (permission denied). Downloaded the master zip instead, ran the above command and got this message (dmd v2.066.0 64bit Linux):
> ...
>> Error executing command run: dmd failed with exit code 1.
>>
>> I'd really love to test your gui toolkit, something I've been dreaming of for a long time!
>
> Sorry, 64bit build has been broken by recent changes.
> Fixed in v0.1.5
>
> Https should be used instead of SSH to clone repository.
>
> git clone https://github.com/buggins/dlangui.git
> cd dlangui
> dub run dlangui:example1

This worked! Thanks. It's very good! Maybe we should think about writing a IDE based on dub and dlangui. What do you think?

If you need any help with the artwork, maybe next year I'll have some time to design icons etc.

please stop with this dub ....

It do not respect OS specification
Is a monolith application,inside they are at least 3 kinds of software:
- a builder
- a package manager
- a package indexer

In any case the :
 - no respect of OS specification and standard path
 - any discussion with OS packager or development with their needs

it is to me no dub!!!

On Thursday, 18 December 2014 at 13:43:15 UTC, Chris wrote:
> On Thursday, 18 December 2014 at 11:50:46 UTC, Vadim Lopatin wrote:
>> On Thursday, 18 December 2014 at 11:00:43 UTC, Chris wrote:
>>
>>> Very good! I tried it and couldn't clone the repo (permission denied). Downloaded the master zip instead, ran the above command and got this message (dmd v2.066.0 64bit Linux):
>> ...
>>> Error executing command run: dmd failed with exit code 1.
>>>
>>> I'd really love to test your gui toolkit, something I've been dreaming of for a long time!
>>
>> Sorry, 64bit build has been broken by recent changes.
>> Fixed in v0.1.5
>>
>> Https should be used instead of SSH to clone repository.
>>
>> git clone https://github.com/buggins/dlangui.git
>> cd dlangui
>> dub run dlangui:example1
>
> This worked! Thanks. It's very good! Maybe we should think about writing a IDE based on dub and dlangui. What do you think?

How did you guess? :)

git clone git@github.com:buggins/dlangide.git
cd dlang ide
dub run

Recent changes are to be able writing IDE:
- Tree view (usable)
- FileOpen dialog (in progress)

> If you need any help with the artwork, maybe next year I'll have some time to design icons etc.

UI theme itself now looks ugly - mix of resources from Android, gnome Oxygen, and hand drawn images. All of different styles and palette.

It will be great if someone could help to make them better.
(Mostly, editing on theme XML and PNGs is necessary).