Re: shared - i need it to be useful

[Norm via Digitalmars-d]

On Friday, 19 October 2018 at 02:20:22 UTC, Manu wrote:
On Thu., 18 Oct. 2018, 7:10 pm Stanislav Blinov via 
Digitalmars-d, < digitalmars-d@puremagic.com> wrote:



On Friday, 19 October 2018 at 01:53:00 UTC, Manu wrote:

> This is a red-herring.
> In short, he made up this issue, it doesn't exist.
> This is just hot air, and only strengthen my conviction.

>> Produce, or drop this presumptious crap.

> You are an obscene person. I'm out.

Oooh, I'm srry, come baack!
Really though, what is it that you wanted to achieve here? You
ask for counter-arguments, are given them on *17 pages 
already*,

are asked numerous times to actually demonstrate the value of a
small contained portion of your proposal, and all you do is 
shrug

this all off just because you presume to "know better", and on
top of that have the audacity to call someone else *obscene*?
Wow... just... wow!

> You win.

I didn't know it was a contest.



I've given use cases constantly, about taking object ownership, 
promotions, and distribution for periods (think parallel for), 
I can achieve all my goals with full @safety, absolutely no 
casts in user code, and I have infrastructure in production 
that applies these patterns successfully. It's worth pursuing.


I've spent years thinking on this, I'm trying to move the 
needle on this issue for the first time in over a decade at 
least, and you have violently opposed, in principle, from the 
very first post, and make no effort to actually understand the 
proposition.


It's clearly a contest from your insurance that my proposal in 
worthless in every single post you've made. You want me to 
admit defeat and desist. Fuck you. You win. I don't have the 
time or energy to argue against a wall.


You are obscene, you're complete unproductive, and destructive 
from no

apparent reason.
I hope you continue to love shared, just the way it is... 
useless.


There's another way; Stanislav isn't one you need to convince so 
if that particular discussion is unproductive and disruptive just 
ignore it. I.e technical discussions should be robust but once 
they become personal just ignore that input and move on. Isn't 
always possible I know but in this case I reckon you can.


Convincing Walter, Andrei and the rest of the core dev team of 
course will require a DIP.


Keep going on this, it is the first hint of movement with shared 
since like foreva!


bye,
norm

bye,
Norm

Re: Funny way to crash dmd and brick the whole computer

[Norm via Digitalmars-d]

On Friday, 28 September 2018 at 11:58:25 UTC, Zardoz wrote:

CTE fib :

module fib_cte;
import std.stdio;

long fib(long n) {
  if (n <= 1) return 1;
  return fib(n - 1) + fib(n - 2);
}

static immutable valueFib = fib(46);

void main() {
writeln(valueFib);
}


This isn't a brick, this is your OS not handling lack of 
resources. A brick is when the machine will no longer boot 
without some physical intervention like JTAGing or replacing 
parts.


DMD sacrifices memory for speed so it is not surprising given 
that code abomination.


bye,
norm

Re: Source changes should include date of change

[Norm via Digitalmars-d]

On Saturday, 8 September 2018 at 11:29:15 UTC, Josphe Brigmo 
wrote:

On Saturday, 8 September 2018 at 07:08:46 UTC, Colin wrote:
On Saturday, 8 September 2018 at 06:59:28 UTC, Josphe Brigmo 
wrote:
Having source code that doesn't show changes with dates is 
pretty useless for diagnostics. I realize that git has the 
changes but the source code should.


If some code is added or changed it is very simple to add the 
date of change in a comment.


// Date: Date1, Date2, Date3, 

Anything below a was changed at those dates.



Why not also add a link to the git hub patch or bugzilla or 
whatever?


Git is the tool that's used to manage changes, including 
viewing the changes.


A lot of dev time has gone into it and it works really well.

Some ad hoc comment system in source code to point out changes 
will never be as good.


Just Use Git!


Um, I didn't say don't use Git!

Your illogic is that you believe that one can have only one or 
the other when one can have both. Hence, you are excluding a 
completely valid addition. You think it is an alternative. You 
are wrong. Please think about the question before you answer 
next time so that you don't get in the habit of doing it. No 
one said that Git couldn't be used and telling me to use it is 
very arrogant of yourself.


The fact of the matter is that dates in source code will help 
when git is not available and one only has the source code.


Comments showing last modified date are pure noise. The code is 
what gets executed and what you should focus on. If you need 
history look at git log. The date is generally useless and code 
deltas are what you want and this is why VCS tools exist.


The only caveat to all that is a copyright statement, which 
should include the year. But this is orthogonal sprinkling dates 
throughout your code base.


But if you really want to do this more power to you, it is your 
code. Set up a hook in your fav. editor that inserts a date 
comment each time you enter ";" followed by the return key.


Bye,
Norm

Re: This thread on Hacker News terrifies me

[Norm via Digitalmars-d]

On Saturday, 1 September 2018 at 20:48:27 UTC, Walter Bright 
wrote:

On 9/1/2018 5:25 AM, tide wrote:

and that all bugs can be solved with asserts


I never said that, not even close.

But I will maintain that DVD players still hanging on a 
scratched DVD after 20 years of development means there's some 
cowboy engineering going on, and an obvious lack of concern 
about that from the manufacturer.


Firstly, you have to take into account the context around why 
that bug exists and why it is not fixed and it comes does to a 
risk-cost trade off.


Product managers are totally driven by budget and in consumer 
goods they dictate the engineering resources. I think you'll find 
most large DVD manufactures have discovered that it is not cost 
effective to give engineers the budget to fix these annoying 
bugs. This is because most consumers will be annoyed but then go 
out and purchase som other product by the same manufacturer. I.e. 
these bugs do not harm their brand enough.


This leads to the situation where the engineering is shoddy not 
because the programmers are bad engineers, but because they don't 
even get the chance to engineer due to time constraints.


Secondly, DVD players and critical flight systems are apples and 
oranges in terms of engineering rigor required. One will mildly 
annoy the odd consumer, who 9 times of 10 will still purchase 
 products again and the other will likely kill 
100s of people.


To put it another way; one will give the engineers *zero* 
resources to work on non-blocking bugs and the other must have 
*zero* non-blocking bugs.


Cheers,
Norm

Re: Dagon 3D game framewordk/engine

[Norm via Digitalmars-d]

On Friday, 17 August 2018 at 08:56:56 UTC, aberba wrote:
I'm quite happy to find a project like Dagon 
(https://code.dlang.org/packages/dagon) receiving more 
improvements. Already, it has quite a number of cutting edge 
features. The developer has really put time into writing a very 
good Tutorial on using it...which he continues to update. He's 
also working on a 3D physics engine for it 
(https://github.com/gecko0307/dmech)



You can support his work on Patreon 
(https://www.patreon.com/gecko0307).


Have any of you tried it recently?


I've been using dagon now for a couple of months with hobby 
projects and it is excellent. I can now code in D with a very 
easy to use 3D API so I've dropped Ogre and C++ completely for 
making my hobby games.


Cheers,
Norm

Re: D community's view on syntactic sugar

[Norm via Digitalmars-d]

On Tuesday, 19 June 2018 at 07:14:11 UTC, Dmitry Olshansky wrote:

On Monday, 18 June 2018 at 20:54:22 UTC, aberba wrote:

[...]


I look at popularity but I prefer crutical thinking.

Nothing beats simple non-async code in understamdability save 
for declarative stuff or no code. Really no code is best but 
obviously not always an option.


[...]


I hear your rage. People should not sip the kool aid lightly.

Avoid *ANY* form of complexity unless it is really needed.
Add code only when needed
Keep things synchronous until you cannot then redesign so you can

If you really really must use asynchronous design know why you 
must and what you are getting into then decouple that code as 
much as possible.

Re: D code obfuscator

[Norm via Digitalmars-d]

On Thursday, 14 June 2018 at 00:01:31 UTC, DigitalDesigns wrote:
Is there an obfuscator for D that at least renames identifiers? 
This is because sometimes they leak from various processes and 
could be potential sources of attack.


It would be a tool that probably just replaces their values 
with, say their hash + something else and done pre release 
build. Ideally it would be able to compile with dmd and all in 
memory or use temp storage without file issues. It can't modify 
the code directly because then that would be permanent.


I don't know any specifically for D but these C/C++ tools might 
help as a starting point.


https://github.com/obfuscator-llvm/obfuscator/wiki
https://github.com/obfuscator-llvm/obfuscator/tree/llvm-4.0

https://sourceforge.net/projects/cshroud/

Re: Pyd updates

[Norm via Digitalmars-d]

On Monday, 4 June 2018 at 01:17:31 UTC, Norm wrote:

On Monday, 4 June 2018 at 00:53:26 UTC, ROB wrote:
On Wednesday, 12 July 2006 at 23:35:55 UTC, Kirk McDonald 
wrote:

[...]


has there been any updates since July 2006 there does not seem 
to be any new msg's since unless you have forked this forum to 
a new location.  if you have please provide I am new to D I 
have been learning python for some time and thought Python and 
D would work well together.


Also are there any Projects using it yet I would like to get 
involved and contribute if possible.


Try this repo:

https://github.com/ariovistus/pyd
https://github.com/ariovistus/pyd/wiki


Sorry I meant to post this link for the wiki:

https://wiki.dlang.org/Programming_in_D_for_Python_Programmers

Re: Pyd updates

[Norm via Digitalmars-d]

On Monday, 4 June 2018 at 00:53:26 UTC, ROB wrote:

On Wednesday, 12 July 2006 at 23:35:55 UTC, Kirk McDonald wrote:

[...]


has there been any updates since July 2006 there does not seem 
to be any new msg's since unless you have forked this forum to 
a new location.  if you have please provide I am new to D I 
have been learning python for some time and thought Python and 
D would work well together.


Also are there any Projects using it yet I would like to get 
involved and contribute if possible.


Try this repo:

https://github.com/ariovistus/pyd
https://github.com/ariovistus/pyd/wiki

Re: Installation on Ubuntu 18.04 is broken

[Norm via Digitalmars-d]

On Friday, 1 June 2018 at 16:41:21 UTC, bachmeier wrote:
I would file a bug, but I don't have time to dig into this now, 
and it would just sit there with no response for six months 
anyway.


I cannot find a way to get std.net.curl to work with Ubuntu 
18.04. Details can be found here:

https://forum.dlang.org/thread/bug-1864...@https.issues.dlang.org%2F
but that only lets you install the package without having a 
broken package management system. It resolves nothing wrt 
actually being able to use curl, which is part of the standard 
library, and should be expected to work.


I tried using the install script, but that leads to this bug
https://issues.dlang.org/show_bug.cgi?id=18808
which was filed more than a month ago and still hasn't received 
a response.


This experiment with having a new release every couple of weeks 
was fun, but can we please be realistic about our resources, 
and move to a sensible schedule. D is simply not an option in 
situations that require reliability. And all the various 
deprecations and language changes that are inserted in these 
high-frequency releases (changes of arbitrary size can come 
with little warning in *any* release) make it that much more 
difficult.


Get a new distro. Ubuntu is a very sloppy distro and often breaks 
with a simple apt-get update. Compared to other distros it is 
very unstable, e.g. I haven't had a single broken package on Arch 
in 9 years and Fedora in 5 years.


But it begs the question why use any installer for D. On linux or 
BSD it is as simple as download, unzip, code.  Windows 64-bit and 
VisualD are the only non-trivial set up where I've found the 
installer was useful.


Bye,
Norm.

Re: Sealed classes - would you want them in D?

[Norm via Digitalmars-d]

On Tuesday, 15 May 2018 at 02:32:05 UTC, KingJoffrey wrote:

On Tuesday, 15 May 2018 at 02:00:17 UTC, 12345swordy wrote:

On Tuesday, 15 May 2018 at 00:28:42 UTC, KingJoffrey wrote:

On Monday, 14 May 2018 at 19:40:18 UTC, 12345swordy wrote:


A slippery slope fallacy isn't helping your case. Write a 
DIP if it bothers you so much, as it changes the languages 
fundamentally.



Alexander


If 'getting a module to respect the enscapsulation boundaries 
the programmer puts in place would change the language so 
'fundamentally', then the language 'already' presents big 
problems for large complex application development.



Evidence for this claim please.


- Object independence
- Do not violate encapsulation
- Respect the interface

All large software projects are done in (or moving toward) 
languages that respect these idioms.


Those that don't, are the ones we typically have problems with.

Isn't that evidence enough?


I'm seeing the opposite, more and more large applications 
adopting Python as much as possible and replacing big chunks of 
the C++ core and leaving only those C++ chunks where performance 
is all that really matters.


Encapsulation boundaries are completely arbitrary and where D 
choses to draw the line works very well in practice.


Bye,
Norm

Re: Binderoo additional language support?

[Norm via Digitalmars-d]

On Sunday, 6 May 2018 at 15:28:11 UTC, Ethan wrote:

https://goo.gl/forms/DtKpuwOWR9V2TCnP2

Rapidly iterating my D code from C++ or .NET is great, but 
these are only two use cases that I know of. So. Let's see what 
other use cases are out there, and what are the most common 
ones.


The link above goes to a Google Form where you can answer a 
bunch of questions that will give me an idea of what other 
languages I should account for. It doesn't require you to sign 
in, so all data is anonymous (to me anyway).


There's only six multiple choice questions, so if you have a 
minute go head and fill it out.


Cheers.


Done and fyi it is a common misconception that the "Rat Koala" is 
related to the almighty Koala :)

Re: CTFE ^^ (pow)

[Norm via Digitalmars-d]

On Friday, 23 March 2018 at 05:24:48 UTC, Walter Bright wrote:

On 3/22/2018 9:15 PM, Norm wrote:

On Friday, 23 March 2018 at 03:28:05 UTC, Walter Bright wrote:

What are the bugzilla issues on those?


This is just a few cut-paste from the collated list. Some were 
reported but found later to be duplicates, many were existing 
bugs, so no new bugzilla was created in those cases.


https://issues.dlang.org/show_bug.cgi?id=18055
https://issues.dlang.org/show_bug.cgi?id=17942
https://issues.dlang.org/show_bug.cgi?id=16317
https://issues.dlang.org/show_bug.cgi?id=16189
https://issues.dlang.org/show_bug.cgi?id=17949
https://issues.dlang.org/show_bug.cgi?id=15511
https://issues.dlang.org/show_bug.cgi?id=16107


Thank you. I have tagged them with the "Industry" keyword, 
which is for issues raised by people using D in industrial 
situations. The last one (16107) is marked as resolved and 
appears to have been fixed.


Thanks, sorry that was my mistake (posting in a hurry). It was 
this bug:


https://issues.dlang.org/show_bug.cgi?id=16108
(hardly what I would call a blocker, but I didn't make the list)

Looking at bugzilla I see this is also now fixed but we were on 
2.074 at the time. Sorry I don't have more specific details, it 
was hard enough just to get some devs to create bugzilla accounts 
let alone find existing tickets or raise new tickets.


As I was trying to point out before but unfortunately came across 
as just a negative git; many developers agreed that D is a 
fantastic language, but they have zero interest in developing or 
even raising tickets when D doesn't just work. I think the main 
reason for this is because they expect a C++/Python like 
experience where your rarely hit a compiler/interpreter bug.


This seems to be the majority of developers I talk to, so it is a 
hard sell, but on the bright side I'm starting to see more and 
more internal tools here written in D :)


Cheers,
Norm

Re: CTFE ^^ (pow)

[Norm via Digitalmars-d]

On Friday, 23 March 2018 at 03:28:05 UTC, Walter Bright wrote:

On 3/18/2018 7:56 PM, Norm wrote:
My workplace has stopped using D after a 6 month trial, which 
finished in Jan 2018. Several developers did post here during 
that period when blocked by a bug or incomplete feature, only 
to be told if they want it fixed they can always submit a PR.


What are the bugzilla issues on those?


This is just a few cut-paste from the collated list. Some were 
reported but found later to be duplicates, many were existing 
bugs, so no new bugzilla was created in those cases.


https://issues.dlang.org/show_bug.cgi?id=18055
https://issues.dlang.org/show_bug.cgi?id=17942
https://issues.dlang.org/show_bug.cgi?id=16317
https://issues.dlang.org/show_bug.cgi?id=16189
https://issues.dlang.org/show_bug.cgi?id=17949
https://issues.dlang.org/show_bug.cgi?id=15511
https://issues.dlang.org/show_bug.cgi?id=16107

We had no problem with installation or IDE support like many 
forum posts seem to talk about. Untar DMD tarball just worked 
when bin put on the path for Win, Mac and Linux. This easy 
installation to $HOME/somewhere was a bonus most developers liked 
and many thought even nicer than installing Python.


I feel like I've been bashing D here but that wasn't my intention 
at all. I am a D convert, broken beyond repair. All our 
developers liked D as a language. The biggest win I think was the 
ability to write code that cleanly brought together C, C++ and 
Python.


Cheers,
Norm

Re: CTFE ^^ (pow)

[Norm via Digitalmars-d]

On Friday, 23 March 2018 at 01:43:49 UTC, Nick Sabalausky 
(Abscissa) wrote:

On 03/18/2018 11:28 PM, Manu wrote:


I know these feels so well.
People take their one experience, and that's the truth on the 
matter.
The sad part is, it's actually a massive missed opportunity! 
If these
colleagues posted here, and instead were greeted by 
recognition of
their issue, and provided a satisfactory work-around, or even 
a prompt
fix, they would have taken a COMPLETELY different message away 
from
their interaction; it would be "this D comunity is so awesome, 
I can
have confidence that our issues will be handled in a 
personalised

way!", and there's very strong value in that for a business...



Well *of course* they would love any group that does custom 
work for them for free! ;)



[snip]

All that was expected of D in the tests that I supervised was 
zero blocking bugs and documented features to be complete and 
working as advertised. We did not expect special treatment or new 
features to be implemented on whim without giving back in time or 
cash.


While personally I agree with your sentiments regarding OSS, my 
experience has been that most companies will only donate cash or 
time when a tool has already proven itself to be a useful.


Cheers,
Norm

Re: CTFE ^^ (pow)

[Norm via Digitalmars-d]

On Monday, 19 March 2018 at 04:15:26 UTC, rikki cattermole wrote:

On 19/03/2018 5:05 PM, Norm wrote:
On Monday, 19 March 2018 at 03:53:07 UTC, rikki cattermole 
wrote:

On 19/03/2018 4:43 PM, Norm wrote:
On Monday, 19 March 2018 at 03:14:51 UTC, rikki cattermole 
wrote:


Did they at any point tell us that it was a blocker for 
your company who was trialing D?


Because I do not remember once in that time period of any 
one saying this.


Walter has gone out of his way in the past to help 
companies, even flying to them on his own dime.


If you want to be treated special, we need to have a reason 
for you to be treated special, otherwise you're just like 
everybody else complaining without giving back.


We don't want to be treated special. We don't want to give 
back. This is the *entire* point.


D claims to be "Industry Proven and Ready" but we have to 
submit PRs or get special treatment from Walter to use it 
effectively? Sorry, but this is why many feel that D is 
still just a hobby project.


We are an organisation trying to get work done. D was a 
potential replacement of our existing C++/Python tool chain. 
Unfortunately it *requires* us to give back, which as I 
stated is not our business. Our business is the development 
of medical devices and supporting application software, not 
compiler or language development.


You just said the magic word, medical.

D was never an appropriate fit here.

dmd's backend has been for thirty years (or so) been up to 
recently licensed so that you may not use it for this 
purpose. Nothing has changed here.


I have no idea what you're talking about now.

What has the backend license got to do with medical?


The code generation capabilities of dmd has not been certified 
for medical usage.


In essence, if it generated bad code, kills somebody, your the 
one at fault, even if the source is fine. You would end up 
begging to settle out of court.


It is my understanding that medical software manufacturers pay 
for their compilers already certified. So that suggests to me 
that you're not exactly life threatening but I would still 
caution you away from D even if that bit is just my own opinion.


No, compilers do not need to be certified for class B or class C 
software. These are the two highest safety classes for medical 
SW. Beyond class C SW is not allowed, e.g. safety critical 
interlocks such as the big red button to shut off a radiation 
dose or stop a robotic system.


Compilers are are treated as SOUP (Software of Unknown 
Provenance), i.e. a black box. Risk analysis leads to risk 
control measures that in turn ensure people don't die and this is 
done at the system and component level, not the codegen level. 
Verification is performed to ensure the system implements the 
requirements correctly, and subsequently the risk control 
measures. Not all requirements are risk control measures, but all 
requirements must be verified as correct.


Cheers,
Norm

Re: CTFE ^^ (pow)

[Norm via Digitalmars-d]

On Monday, 19 March 2018 at 03:53:07 UTC, rikki cattermole wrote:

On 19/03/2018 4:43 PM, Norm wrote:
On Monday, 19 March 2018 at 03:14:51 UTC, rikki cattermole 
wrote:


Did they at any point tell us that it was a blocker for your 
company who was trialing D?


Because I do not remember once in that time period of any one 
saying this.


Walter has gone out of his way in the past to help companies, 
even flying to them on his own dime.


If you want to be treated special, we need to have a reason 
for you to be treated special, otherwise you're just like 
everybody else complaining without giving back.


We don't want to be treated special. We don't want to give 
back. This is the *entire* point.


D claims to be "Industry Proven and Ready" but we have to 
submit PRs or get special treatment from Walter to use it 
effectively? Sorry, but this is why many feel that D is still 
just a hobby project.


We are an organisation trying to get work done. D was a 
potential replacement of our existing C++/Python tool chain. 
Unfortunately it *requires* us to give back, which as I stated 
is not our business. Our business is the development of 
medical devices and supporting application software, not 
compiler or language development.


You just said the magic word, medical.

D was never an appropriate fit here.

dmd's backend has been for thirty years (or so) been up to 
recently licensed so that you may not use it for this purpose. 
Nothing has changed here.


I have no idea what you're talking about now.

What has the backend license got to do with medical?

D would be a great fit for medical with its @safe, pure and GC.

Supporting application software is standard desktop development. 
Some of these applications are for production and testing and the 
rest are normal end-user Windows desktop?


We also develop mobile applications but we didn't consider D for 
that role.


Cheers,
Norm

Re: CTFE ^^ (pow)

[Norm via Digitalmars-d]

On Monday, 19 March 2018 at 03:14:51 UTC, rikki cattermole wrote:


Did they at any point tell us that it was a blocker for your 
company who was trialing D?


Because I do not remember once in that time period of any one 
saying this.


Walter has gone out of his way in the past to help companies, 
even flying to them on his own dime.


If you want to be treated special, we need to have a reason for 
you to be treated special, otherwise you're just like everybody 
else complaining without giving back.


We don't want to be treated special. We don't want to give back. 
This is the *entire* point.


D claims to be "Industry Proven and Ready" but we have to submit 
PRs or get special treatment from Walter to use it effectively? 
Sorry, but this is why many feel that D is still just a hobby 
project.


We are an organisation trying to get work done. D was a potential 
replacement of our existing C++/Python tool chain. Unfortunately 
it *requires* us to give back, which as I stated is not our 
business. Our business is the development of medical devices and 
supporting application software, not compiler or language 
development.


IMO most of D is close enough, but I am a convert and geek. Most 
of my fellow developers are not.


Cheers,
Norm

Re: CTFE ^^ (pow)

[Norm via Digitalmars-d]

On Monday, 19 March 2018 at 00:59:45 UTC, Manu wrote:
On 18 March 2018 at 17:28, Joakim via Digitalmars-d 
 wrote:


Perhaps the community simply has different priorities than 
you? For example, my Android port has never gotten much use 
either, which is fine as I primarily did that work for myself.


Nevertheless, you have to think of D as like working in a 
startup: if you see something that you think needs doing, you 
have to drive it yourself or it will never get done. Pretty 
much the same for most any OSS project too.


This is such an easy and readily-deploy-able response here.
What you say is true, and I totally understand this... but at 
the same
time, that's not actually the relationship I want to have with 
my
tool. A startup probably shouldn't still be a startup 10 years 
later.


In your case, doing the android work was obviously an interest 
you had

on the side, and you gain something from the work itself.
I have a small amount of that, but that's not where I'm at, and 
it
never has been. I want to use D to do my job, because I'm fed 
up with
C++. I want to engage in D the way I think D should **EXPECT** 
it's
users to engage in D; as an end-user, who uses the tool to get 
their

jobs done.
If D is a large-ish scale hobby project among a bunch of people 
with
mutual interests, then that should be more clearly 
communicated, but I
don't think that's the intent, and I feel perfectly fine 
interacting

with D in the way D is intended to be interacted with.

Incidentally, this particular work I'm doing is on a multimedia 
library intended for the community... so I really am truly 
trying to contribute something of value!! But like most of my 
projects, I tend to get blocked at some point, and then it goes 
on hold indefinitely.


+1024 bytes

I think D is a terrific language worthy of all the praise it gets 
and it is way way more stable than it was 3yrs ago. But the 
attitude of submit a PR if you want it fixed works very much 
against D. Like it or not these forums are a front page on the D 
marketing campaign.


My workplace has stopped using D after a 6 month trial, which 
finished in Jan 2018. Several developers did post here during 
that period when blocked by a bug or incomplete feature, only to 
be told if they want it fixed they can always submit a PR.


Inevitably when told this they simply dropped D and went back to 
C++ and Python. And they made a point to bring this experience up 
at the final go/no-go meeting.


The majority of developers, including those voting for D, had 
these common opinions (much to my disappointment)


a) We're not in the business of developing and maintaining D, but 
it seems that is what we would need to do as a company. We are 
better off with C++ and Python.


b) D feels like C++ did back in the mid 90's. A time when we 
avoided templates and often the STL because compiler 
implementations were too buggy. We are better off with C++ and 
Python.



I keep pushing D here but now it is a bit of a joke when I bring 
it up. I've become "the D guy" and it isn't discussed seriously 
any more by other developers, except a select few.


Cheers,
Norm

Re: help me with dpldocs - how to filter 3rd party libs

[Norm via Digitalmars-d]

On Sunday, 4 March 2018 at 23:31:56 UTC, Adam D. Ruppe wrote:

On Sunday, 4 March 2018 at 23:18:25 UTC, Norm wrote:
Can you run dub describe and parse the output, which is JSON I 
think. It used to indicate a role for each source file under 
each configuration, one of which is "unusedSource".


I don't see any info like that when I run it here... :(

Alternatively you could also take the simple (but fragile) 
route and dictate a convention.


aye.


Hmm, may have changed, sorry for the bum steer. I should have 
done this first. Just tried it with a simple test and there is no 
unusedSource, only "source" roles, but if I have any files in the 
excludedSourceFiles list they do not appear in the list.


Might not help much though, I imagine these third-party sources 
are built as source only libraries, so they probably appear as 
source files anyway.


Cheers,
Norm

Re: help me with dpldocs - how to filter 3rd party libs

[Norm via Digitalmars-d]

On Sunday, 4 March 2018 at 22:24:58 UTC, Adam D. Ruppe wrote:
So the dpldocs scraper right now pulls all the .d files out of 
a repo and tries to build docs for them. But in some cases, 
there's a lot of added dependencies in there that can cause the 
built to time out.


For example, take a look at dlangui:

http://dlangui.dpldocs.info/dlangui.html

Notice the sidebar on the left has a lot of other packages, 
including x11 and win32 bindings. Similarly, dplug 
 comes with some 
derelict things bundled.



I'm tempted to say if there's a D package that matches the dub 
package, just focus on it and leave the others out. I could 
also read the dub description for excludedSourceFiles or for 
the ddoxFilterArgs and piggyback off that, though a lot of 
packages haven't concerned themselves with docs at all and 
didn't set those either.


Really, I think my ideal solution would be to figure out what 
the library is supposed to export, and focus on that. Its 
internal implementation details shouldn't matter in docs; who 
cares if it bundles some dependency when that isn't meant to be 
part of its public API. But I don't see any way dub reports 
what this is meant to be, it just eats up all src too.



Do you guys have any better ideas?


Can you run dub describe and parse the output, which is JSON I 
think. It used to indicate a role for each source file under each 
configuration, one of which is "unusedSource".


Alternatively you could also take the simple (but fragile) route 
and dictate a convention. Anything under 
third-party/thirdparty/third_party/3rdparty/3rd-party/3rd_party 
will be ignored. Convention based APIs work for the internet CRLF 
CRLF.


Cheers,
Norm

Re: My choice to pick Go over D ( and Rust ), mostly non-technical

[Norm via Digitalmars-d]

On Saturday, 3 February 2018 at 15:22:37 UTC, Rubn wrote:

On Saturday, 3 February 2018 at 08:18:57 UTC, H. S. Teoh wrote:
On Fri, Feb 02, 2018 at 08:16:25PM -0800, Walter Bright via 
Digitalmars-d wrote:

On 2/2/2018 7:06 AM, Benny wrote:
> Other languages have slogans, they have selling points.
> 
> When i hear Go, you hear uniformal, fast, simple syntax 
> language.

> When i hear Rust, you hear safe, manual memory management.
> When i hear D, you hear ... ... ... ...

  Fast code, fast


Frankly, that slogan makes me cringe. Makes D sound like a 
fast food chain -- cheap code, fast. Would you like fa^Wfries 
with that?


Yup I agree, it's a horrible slogan. Speed isn't even a 
priority in D, if it was so many things would be different.


- Make dmd's optimizer better, esp. with loop unrolling on par 
with
  ldc/gdc, or better, so that we don't keep having to defend 
poor dmd

  benchmarks with "use ldc/gdc instead";


I don't think time should be wasted on making DMD's optimizer 
better. It's not an easy job and it'll just pull resources for 
something that has no purpose. The compile times with DMD -O 
can vary dramatically, it's best just to not use it at all. The 
reason I hear as to why DMD even exists instead of just having 
1 compiler like Rust or any other language that isn't 20+ years 
old. Is cause DMD's unoptimized compilation is fast and creates 
reasonably fast enough code for debugging.


I agree, DMD should switch to LLVM backend. But it is unlikely to 
happen because the core DMD developers are in their comfort zone 
with DMD backend and worried that switching to LLVM would put 
them at the mercy of the LLVM community. To be honest though I 
don't know how much time DMD backend optimizer really takes core 
devs away from D language development. It would be interesting to 
see some numbers on this.


We use LDC exclusively where I work because DMD codegen just 
isn't production ready. And the argument that DMD debug builds 
are so much faster than LDC is bogus. Yes it is faster but 
nowhere near the point where we would consider swapping compilers 
between debug and release builds.


So that leaves little scripts and the like where DMD could maybe 
replace Python. But again, LDC isn't *that* slow in debug builds 
either and could do this just as well.


Cheers,
Norm