June 06, 2016
On Monday, 6 June 2016 at 20:33:14 UTC, Walter Bright wrote:
> On 6/6/2016 12:44 PM, Satoshi wrote:
>> When I told of D to my boss he had a couple of reasons why not to use D for
>> development of our products.
>>
>> * Backward compatibility with existing code.
>> * D is much more complex than C++
>
> More complex? Wow!
>
>
>> * Not enough tutorials and solved problems in D on stack overflow (LOL)
>> * We have problem to recruit a good C++ not a good D programmer. (1/100 is good)
>> * My boss does not have free time to learn new things...
>> * Using GC is strictly prohibited in realtime apps. And D does not have an
>> compiler supported ARC
>> * D without GC or ARC is not powerful as it can be.
>> * More and more people are dumber, we must write our programs for later re-usage
>> by any junior what we must employ. C++ is in this way much more easier than D,
>> cuz you know what every line of your program do. Employ C++ junior programmer
>> and let him to learn D and then work on our projects is not a good (and
>> cost-effective) idea.
>
> C++ for junior programmers is easier? Wow!
>
>> * Not everyone is interested in programming, sometimes people are doing it just
>> for money.


Yes.
D have much more features than C++ to learn before you can use it in the right way.

I never met programmer who start with D as a first language but I know many poeple who started with C++. You cannot be objective in this case. It's just your point of view.

I made OS in C++ then I rewrote it into D and I must say I had much more problems with D than with C++.
June 06, 2016
On 6/6/2016 1:36 PM, Dave wrote:
> On Monday, 6 June 2016 at 20:33:14 UTC, Walter Bright wrote:
>> On 6/6/2016 12:44 PM, Satoshi wrote:
>>> [...]
>>
>> More complex? Wow!
>>
>>
>>> [...]
>>
>> C++ for junior programmers is easier? Wow!
>>
>>> [...]
>
> Most learn C++ in college. So they have a 'headstart'

Even acquiring minimal competency in C++ has a very long learning curve, or perhaps I just have a different idea of what minimal competency is. Heck, the C++ code I wrote just a few years ago I regard as crap today.

My personal pet peeve are junior programmers who think they get it, find some perverted corner case in the language, and build their entire application around that. They confuse their mastery of the corner case with competence.

(This happens with all languages, not just C++, it's just that C++ provides so many opportunities for it!)
June 06, 2016
On 6/6/16 4:56 PM, Observer wrote:
> On Monday, 6 June 2016 at 20:35:26 UTC, Walter Bright wrote:
>> What I've done, though I know that I won't convince any users of
>> BigDecimal, is use longs and have them represent pennies instead of
>> dollars. Then they're all exact to two places.
>
> I loaned out my copy of TDPL, so I don't have it nearby to
> check, but if that's your approach, you need to ensure that
> your underlying integral type is *always* 64-bits, not 32-bits.
> The reason is that otherwise, you've just limited your apps
> to handling a maximum amount of $21,474,836.48.  But banks
> can accept checks up to $99,999,999.99 (yes, they do have
> a limit, or at least they used to when I was working in that
> field).

longs are always 64-bit in D.

-Steve
June 06, 2016
On 6/6/2016 1:56 PM, Observer wrote:
> On Monday, 6 June 2016 at 20:35:26 UTC, Walter Bright wrote:
>> What I've done, though I know that I won't convince any users of BigDecimal,
>> is use longs and have them represent pennies instead of dollars. Then they're
>> all exact to two places.
>
> I loaned out my copy of TDPL, so I don't have it nearby to
> check, but if that's your approach, you need to ensure that
> your underlying integral type is *always* 64-bits, not 32-bits.

D's long is always 64 bits.

> The reason is that otherwise, you've just limited your apps
> to handling a maximum amount of $21,474,836.48.

I wouldn't mind running into that problem :-)

> But banks
> can accept checks up to $99,999,999.99 (yes, they do have
> a limit, or at least they used to when I was working in that
> field).

June 06, 2016
On Monday, 6 June 2016 at 20:19:20 UTC, Observer wrote:
> And when real-world money is involved, you'd better have arithmetic
> overflow trigger an exception, not just wrap around silently.

Suggest as compiler option, default=on.

IBM PL/I had a _FIXED DECIMAL_ datatype, many many years ago.
Could it be used as a model?
June 06, 2016
On Monday, 6 June 2016 at 16:10:29 UTC, bob belcher wrote:
> Hello,
>
> why not a poll, and ask the community that they want first.

http://www.rkursem.com/poll/view.php?id=7f7ebc16c280d0c3c

> - tiny web library from vibe.d will not be complicated
> - improve documentation, the same

I don't think it's bad in general.
It just needs more eyes - people willing to submit even small PRs for minor things!

> - tour.dlang.io improvements

We are working on it, everyone is cordially invited to help us: https://github.com/stonemaster/dlang-tour/issues

> - make an editor work properly on all platforms YES

I am fine with Vim and the amazing part about D is that you don't need a sophisticated IDE that handles the boiler-plate code, because Walter et.al. have done a great job of removing the boiler-plate code in the first place!

We should start to teach people that ala #dlanglovesanyeditor

> - weekly tutorials. (that will be 30 until the end of year)

Adam regularly features them in "This week in D"

http://arsdnet.net/this-week-in-d

Afaik he lost some of his input sources - we should just feed him with more info or tutorials!

> - more noise on how to use proper dlang. dfmd, dub, dscanner.

I agree that they dfmt and dscanner should be be included in the installer and distributed to all platforms, see e.g.

https://github.com/Hackerpilot/dfix/issues/36

> - make the website much friendly. Hire some freelancers and make the website nice!

what exactly don't you like about dlang.org? It's beautiful, fast and responsive.

> #makedlanggreatagain!

it's already great!
June 07, 2016
On 6/6/16 5:41 PM, Joseph Cassman wrote:
> On Monday, 6 June 2016 at 02:20:52 UTC, Walter Bright wrote:
>> Andrei posted this on another thread. I felt it deserved its own
>> thread. It's very important.
>> [...]
>> * The garbage collector eliminates probably 60% of potential users
>> right off.
>
> Curious of the progress/plan for RC. From the autodecode thread sounds
> like RC-string is still in the works. How's that effort coming along?

Progress is slow but steady.

> I
> am guessing it may be guiding the implementation of an RC design for D.
> If you and Andrei have a working design perhaps it could be shared (no
> pressure, just curious since it is a tough problem to solve). Perhaps
> sharing a plan on this front could dispel some of the negativity
> attached to the GC?

We will share things as soon as we have something worth sharing.


Andrei

June 06, 2016
On Monday, 6 June 2016 at 21:35:20 UTC, DLearner wrote:
> IBM PL/I had a _FIXED DECIMAL_ datatype, many many years ago.
> Could it be used as a model?

Not by me.  I just checked, and I still have my IBM Fortran IV
manuals, but my PL/I (F) Reference Manual seems to have evaporated.

On the other hand, I'd probably prefer to use PL/I as a reference
for ideas than COBOL.

But really, I assume such issues are already described in the
C/C++ standards papers I referenced in an earlier post.
June 06, 2016
On Monday, 6 June 2016 at 21:28:14 UTC, Walter Bright wrote:
>
>> The reason is that otherwise, you've just limited your apps
>> to handling a maximum amount of $21,474,836.48.
>
> I wouldn't mind running into that problem :-)
>

It's really not that hard when you consider that many institutional investors wouldn't even consider investing in mutual funds with that amount under management. Vanguard has mutual funds with 100+ billion. I imagine their NAV (net asset value) calculations have to be exact to dollars/cents too.
June 06, 2016
On 6/6/2016 9:40 AM, jmh530 wrote:
> Also, it's not like all energy will be poured into one or two of
> them - ideally several could be worked on.

Consider the recent gigantic thread on autodecoding. Is anyone working on any PRs for it?
5 6 7 8 9 10 11 12 13 14 15 16 17 18 19