On Monday, 15 December 2014 at 05:10:25 UTC, Manu via Digitalmars-d wrote:
> On 15 December 2014 at 07:19, Nick B via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On Sunday, 14 December 2014 at 15:03:27 UTC, Sönke Ludwig wrote:
>>
>>> Lastly, when judging all these things, please always try to remember that
>>> almost all the work that goes into D (and vibe.d) is non-profit and everyone
>>> usually only contributes what (s)he is missing. If I would get payed through
>>> a support contract for my work on vibe.d, I could adjust my priorities to
>>> suit the requirements of others more, but like this I still have to somehow
>>> make sure to be able to pay my bills and can't just work full time to help
>>> other (commercial) projects (although I always try to help as far as
>>> possible).
>>
>>
>> Sonke, Can you advise how much a support contract for a individual or
>> company seriously interested in using vibe.d might cost ?
>
> Good point, I think you should really put a price on commercial
> support if you want it to be taken seriously.
> There are lots of companies that wouldn't seriously consider it if it
> DIDN'T cost them some money. If they don't pay any money, it doesn't
> look legit or professional ;)

I'll try to put something together in January.

On Wednesday, 17 December 2014 at 17:36:50 UTC, Wyatt wrote:

<snip>

>>> Bull.  D isn't magic and expecting that people need to set
>>> aside a chunk of time to "learn" it is really silly.
>> i hope such people will never adopt D.
>>
> It's too late; we're already here.  With a niche language like this (I hate to admit it, but that's how it is) that's probably most of the people that pick it up.
>
>>> But it's not as silly as the idea that you don't learn the
>>> language by diving in.
>> using the tools you never used before, without training, to
>> solve production tasks. this is what seems to be silly for me.
>>
> And over here, in reality, not every situation is optimal and we often find ourselves doing just-in-time learning.  Learn how to learn by doing and accept that you're going to exercise that skill.  A lot.  If you need a bunch of training up front just to get things done, you're probably in the wrong field.
>

<snip>

> -Wyatt

I think two things have been mixed up here. First, as a programmer you can of course make sense of and use languages you don't know, if needs be, simply because all languages share the same underlying logic (arrays, assoc arrays, functions etc.) In this respect, you can use and learn any language "on the fly". The only way to learn a language is to use it, of course. However, and this is the second point, if you want to use a language _properly_ and efficiently, you have to learn it in depth, no matter how advanced your skills as programmer are. You have to learn the concepts and ways that are peculiar to the language. Are you telling me that you never read TDPL or Ali's tutorial and that you grasped everything from templates and ranges to what you can do with D's structs immediately? If so, I doff my hat. I for my part had to ponder on the more advanced features of D and go back and rewrite some parts of my code in a better, more D-like style.

There is simply no other way for a complex, feature rich language like D. Look at D.learn. People who post there are often experienced programmers, yet they still have to ask questions about the best way to do something in D and the like. This doesn't mean that you cannot use D straight away as a newcomer, in fact, I could use it straight away and make sense of the documentation when the page background was still blue. But to throw a complex framework like vibed at people who have no experience with D whatsoever is not a good idea, even if (or because) they are all C++ guys.

> - I want a gui toolkit that is accelerated e.g. OpenGL.
> - That can be layered drawn on top of other OpenGL content.
> - Completely configurable at runtime e.g. change of shaders.
> - Centralized themeing.
> - That works on all major platforms without heartache.
>
> But here's the thing about guis in general.
> Gui toolkits are not really designed to work with OpenGL like this.

They had in D1 an awesome project fully written in D named rae:
http://www.dsource.org/projects/rae

all ui was possible by using openGL

but since the beginning all D project go to the death. Language
es not enough stable and maybe lot of others problem.

I become not anymore a D enthousiast.


erf…

On 18/12/2014 1:07 p.m., bioinfornatics wrote:
>
>> - I want a gui toolkit that is accelerated e.g. OpenGL.
>> - That can be layered drawn on top of other OpenGL content.
>> - Completely configurable at runtime e.g. change of shaders.
>> - Centralized themeing.
>> - That works on all major platforms without heartache.
>>
>> But here's the thing about guis in general.
>> Gui toolkits are not really designed to work with OpenGL like this.
>
> They had in D1 an awesome project fully written in D named rae:
> http://www.dsource.org/projects/rae
>
> all ui was possible by using openGL
>
> but since the beginning all D project go to the death. Language
> es not enough stable and maybe lot of others problem.
>
> I become not anymore a D enthousiast.
>
>
> erf…

I wonder what I can do with that for Devisualization.gmaterials thanks.

On Sunday, 14 December 2014 at 09:53:06 UTC, Rikki Cattermole wrote:
> Yeah they are great projects.
> But they won't ever be what I'm looking for.
>
> Personally?
> - I want a gui toolkit that is accelerated e.g. OpenGL.
> - That can be layered drawn on top of other OpenGL content.
> - Completely configurable at runtime e.g. change of shaders.
> - Centralized themeing.
> - That works on all major platforms without heartache.
>
> But here's the thing about guis in general.
> Gui toolkits are not really designed to work with OpenGL like this.

Hello,

I'm working on GUI toolkit DLangUI which meets almost all of your requirements

https://github.com/buggins/dlangui

Try demo app:

git clone git@github.com:buggins/dlangui.git
dub run dlangui:example1

Native. Fully written in D. Widget set can be easy extended.
Look and feel is based on themes / styles similar to Android.
Scalable UI. Resources can be selected based on screen resolution.
Layouts similar to Android UI allow to adjust UI to different window sizes.
Cross platform.

> - I want a gui toolkit that is accelerated e.g. OpenGL.

Build it with USE_OPENGL to have OpenGL acceleration.

> - That can be layered drawn on top of other OpenGL content.

Additional development required.
a) To use in some custom environment (e.g. draw GUI in some gamedev engine), you need to implement Platform and Window classes to pass Mouse / Key event to UI, and to draw UI above other content when necessary.
b) Use DLangUI platform for event processing and context creation, just extend drawing functionality to draw custom content. (Easy to do).

> - Completely configurable at runtime e.g. change of shaders.

Internally it uses only two shaders.
For custom drawn GL scenes, just write your own code.

> - Centralized themeing.

Styles and themes are being defined in XML resources. Partially compatible with ones from Android. State aware drawables. Nine-patch drawables.
Theme can be switched in run time.

> - That works on all major platforms without heartache.

For most platforms, SLD2 backend can be used (version USE_SDL).
On Windows, you may use native Win32 backend (if not specified version USE_SDL).
XCB(X11) backend is suspended for now. Didn't manage to get OpenGL working under it.

For all platforms, OpenGL acceleration can be used (version USE_OPENGL).
If OpenGL context creation is failed, app just falls back to software renderer.

Development of the project is in progress. But it is getting more and more usable every day.

Best regards,
    Vadim (aka Buggins)

On Monday, 15 December 2014 at 01:30:00 UTC, Dicebot wrote:
> On Sunday, 14 December 2014 at 08:37:36 UTC, Manu via Digitalmars-d wrote:
>> We were trying to use vibe.d, and we encountered bugs.
>>
>> We were unable to build Win64 code ...
>
> Here is exactly your problem - trying to do a web development on Windows :P Really I have never understood that counter-productive obsession with a habit that makes people differentiate development environments and production environments so much. You aren't going to use Windows servers, are you?
>

Completely, I agree with dicebot.

For a webserver usually is a Linux for many reason not a windows.
Guy who want to use a windows as server :
case 1 is a noob
case 2 is a specifics needs

Even microsoft use some linux server for his resources.

So to me the problem of D that is the waste of energy.
D exist since 1999, if we look behind, what is done?
We have :
- a huge cimetery of project
- no D killer application
- miss the goal what to do to improve D experience
- each new D release your application is broken and often with
some D compiler bugs
With around 15 years of works we are at same state as the
beginning.
What to de:
  - Stop to add new feature in D (new annotation or whatever is
not an urgent needs)
  - Get a compiler and a language stable
  - When this is done work on some free (libre) framework in some
specific fields
     * grid computing (sub-field: data-computing)
     * web-server
     * graphics conputing (sub-field: gui )
And not more, not to disperse …

But after ) years in D i start to doubt …

On Thursday, 18 December 2014 at 09:12:54 UTC, bioinfornatics wrote:
> Completely, I agree with dicebot.
>
> For a webserver usually is a Linux for many reason not a windows.
> Guy who want to use a windows as server :
> case 1 is a noob
> case 2 is a specifics needs
>

http://meta.stackexchange.com/questions/10369/which-tools-and-technologies-are-used-to-build-the-stack-exchange-network

On 17 December 2014 at 19:34, Dicebot via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Wednesday, 17 December 2014 at 08:30:59 UTC, Manu via Digitalmars-d wrote:
>> Actually, I recommended it because I had had a positive experience
>> with vibe.d in the past. It seemed pretty solid.
>> Gotta start somewhere. I've had success promoting D to commercial
>> users in the past.
>
>
> Promoting to commercial users is indeed possible but one needs to explain risks and trade-offs straight. I wonder though how you have not noticed debugger issues before if there was some positive experience. There was nothing to debug? :)

I would never use exceptions. vibe.d uses exceptions extensively. I have very little experience with exceptions in the debuggers.


>>> Idea that any D project can compete with node.js in "easy to jump in"
>>> domain
>>> is absolutely ridiculous. Attempting this is just dooming yourself to
>>> fail.
>>> Same is trying to advertise it is stable mature language - reality is it
>>> is
>>> simply not true and people will find out it sooner or later.
>>
>>
>> Sorry, maybe it wasn't clear, we never tried it out against node.js,
>> we tried it first, on my recommendation.
>> When it was rejected, someone else suggested to look at node.js. We
>> looked at that, it just worked.
>
>
> I mean that if "it just worked" was enough to make decision to use the node.js, then you didn't have any critical requirements that it fails to address (otherwise you would have looked for those first). Which means that pretty much any framework out there was suitable and ease of use was only truly important criteria.

Correct. Although as native programmers, we would have been much more comfortable with an ecosystem we were familiar with given the choice.


> Interesting part starts when you say "yeah, it have just worked, BUT.." and start evaluating if ease development will be enough to compensate for certain architectural issues in the long term (budget-wise).

It's a fairly small project, that's why I promoted D in this context
in the first place.
I needed a small project to get people amongst it before we could
consider anything more ambitious.

It was just a good opportunity to get it into the company.


>> We didn't want any of those things from .js though. We're all
>> low-level/native coders.
>> We don't have time to debug language and library issues though. If we
>> didn't have tooling/library issues, we would have been perfectly happy
>> writing whatever code we needed to do our job.
>
>
> If developer time is more expensive than server time in your project, most likely there is no point in going for native languages even if you prefer those. Otherwise debugger issues and/or necessity to switch the OS environment would not have stopped you.

We are native programmers, we know how to write native code, and we
understand the ecosystem.
That's good reason enough.

It's true, there was no compelling reason to choose any technology in
particular other than familiarity or ease of development.
It just would have been nice to create a context in the company where
people could have a go at D.


>>> If there ever appears a game development company / community interested
>>> in
>>> _investing_ into programming language that would be totally different
>>> story
>>> but also irrelevant to enterprise culture you refer to.
>>
>>
>> So, in your world, D is a language for nerds (linux nerds at that!),
>> and not for serious productivity by enterprise?
>> Give me a break!
>
>
> Of course it is language for nerds. Do you see a paid developer team working on D? At least ONE paid developer? Maybe someone of existing commercial users pays for adding tools / features? It is not a product, it is not funded and can't be anything but language for nerds unless YOU start paying for the change.

Me? Personally?
Well Remedy kicked in quite substantially for dconf, but I think my
getting my company involved increases the chances for licensing and
monetisation than any amount I can donate from my own pocket...


> Which doesn't mean that it can be very productive language for serious projects. Nerds are pretty good at doing projects when there is no one from enterprise to create trouble. I think Sociomantic has proven quite strongly that such an attitude can work for successful business.
>
> To start using D effectively in production one needs to stop considering himself a customer. This is absolutely critical.

I am obviously personally capable of working around D's ecosystem
issues; I'm still here after 6 years.
What I am presenting here is an account on why my company rejected D,
despite a large number of staff being super excited and jazzed to try
it out.
I'd like to think there's something to learn from that.

On 17 December 2014 at 19:48, Paolo Invernizzi via Digitalmars-d <digitalmars-d@puremagic.com> 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 don't get it... I really can't understand this perspective at all. We're not here to be a cool exclusive little club where super-nerdy programmers can hang out and talk about advanced language concepts. At least, that's absolutely not why I'm here.

A language end-user shouldn't require any personal involvement in the development community. I don't hang out with stroustrup and sutter and talk about C++.

On 17 December 2014 at 20:16, ketmar via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Wed, 17 Dec 2014 18:06:25 +1000
> Manu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> I'd suggest to look at high-quality commercial documentation, like MSDN or wherever.
> please, no! the fact that you are used to it doesn't mean that msdn is a quality dox.
>
> besides, msdn references are exactly what phobos documentation is: description of functions. will msdn reference dox help you to learn msvc? yet you citing it as "high-quality" and blaming phobos dox for doing (or, rather, not doing) the same.

I was referring mostly to the organisation, which never assaults you
with a wall of text.
It's categorised nicely, and content is fetched dynamically.

That said, I would say MSDN is a good technical reference; short,
concise, well formatted, easy to understand. Phobos is not that.
In some cases, Phobos it's so 'concise' that the entire doc is 3 or 4
words repeating the function name but with spaces, and in other cases
it is a wall of text, with a bunch of cryptic template args and
constraints.

>> One thing I know for sure, is when they are confronted with constraints, especially on templates, they have absolutely no idea what they're looking at...
> did they ever tried to learn the language? seems that you just throwed phobos dox at them and expecting them to use that dox to learn D.

I never threw phobos docs at them, they found that themselves. I was actually kinda trying to steer them away from those docs in some cases, by insisting they hack on the code while I was in the room...


> D is not C. D is not C++. one must learn it before using it. and phobos documentation is not for learning the language, it's reference for phobos.

I can safely say I never 'learned D' by your definition.
I brute forced my way with nothing more than the phobos reference, and
the parallel language reference.

A senior C/C++ programmer should DEFINITELY be able to learn D by osmosis.


> i bet the story was like this: "guys, look at this cool language, it's almost like C++, and has some great features! let's use it!" "ah, almost like C++? so we don't have to learn? great, let's do it! but... hey... what do all that gibberish in documentation mean? i've never seen that is C++... screw it, this wannabe C++ language is awful!"

Don't be insulting.
C++ programmers know exactly how bad C++ is. We've been discussing D's
alternative approaches to common C++ problems for months, many hours
wasted in front of the white board discussing the differences between
the languages.
They had a *lot* of background conversation to work with, much more
than I had when I learned D.