On Tuesday, 7 June 2016 at 08:45:14 UTC, ketmar wrote:
> never seen "this language is used in banking" to be used as the main reason for choosing one language over another (outside the banking, of course ;-).

True, positioning yourself as a toolmaker for banking/finance is basically saying it is arcane and slow-moving (like Cobol and Java).

It does not make you attractive for programmers wanting hardware access. On the contrary, any language that is stuffed into the Java category would make me highly sceptical when looking for system programming tooling.

On Tuesday, 7 June 2016 at 08:31:09 UTC, Russel Winder wrote:
> On Tue, 2016-06-07 at 05:39 +0000, ketmar via Digitalmars-d wrote:
>> 
> […]
>> funny thing: those "financial sector" most of the time doesn't give anything back. adding special decimal type complicating the compiler and all backends. i myself never needed that for my whole lifetime (and this is more than two decades of programming, in various free and commercial projects).
>
> Financial organizations generally want all their language infrastructure for free (GCC, Python, Eclipse) anything they write themselves is treated as asset and so theirs not for anyone else.
>
> Show them PyPy is 30x faster than CPython for their use case but needs £50,000 to be production ready, and they carry on using CPython. (And waste millions of £s in staff time waiting for Python codes to finish.)
>
>> i'd say: "you want it? DIY or GTFO."
>
> That leads to them using Java, Scala, C++, C# and Python. Which they do.

I only know a certain portion of that world, but for example Jane Street has done quite a lot for Ocaml, Bloomberg has released some useful things including for languages, Morgan Stanley has supported Scala, I have supported in a small way some things for D and will be releasing a working Bloomberg API soon.  Don't look for innovation to come from the banks because they have had other things to deal with, but even there there is the beginning of a broader change in mindset.

EMSI are in econ not quite finance and they released containers.

Finance is just one more industry, but it's quite a pragmatic one and still has a decent share of global IT spending.

On Tuesday, 7 June 2016 at 08:57:36 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 7 June 2016 at 08:45:14 UTC, ketmar wrote:
>> never seen "this language is used in banking" to be used as the main reason for choosing one language over another (outside the banking, of course ;-).
>
> True, positioning yourself as a toolmaker for banking/finance is basically saying it is arcane and slow-moving (like Cobol and Java).
>

I shall try to respect Andrei's advice, but really!  Hahahaha!

On Tue, 2016-06-07 at 08:41 +0000, Ola Fosheim Grøstad via Digitalmars- d wrote:
> On Tuesday, 7 June 2016 at 08:31:09 UTC, Russel Winder wrote:
> > Financial organizations generally want all their language infrastructure for free (GCC, Python, Eclipse) anything they write themselves is treated as asset and so theirs not for anyone else.
> 
> So basically no advantage in having them use your tools?

From my experience as a trainer in those organizations… no.

> > That leads to them using Java, Scala, C++, C# and Python. Which they do.
> 
> How does that benefit C++ if they never contribute anything?

It doesn't.

As a counter-point to the "downer" on financial institutions and contributing back, it perhaps should be noted that Goldman Sachs did release their Java data structures framework as FOSS, but I think it hasn't gained much traction. Also there is Jane Street Capital's contributions to OCaml.

However, in the main, financial institutions do not like giving back.

Where there is some giving back is organizations that work with the financial institutions. Python has a number of organizations contributing to Python and library development who get their income by training or consulting to financial institutions.


-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Tue, 2016-06-07 at 08:45 +0000, ketmar via Digitalmars-d wrote:
> […]
> 
> so let 'em use those languages. they will not return anything, thus i see no reason to care about their bussiness needs. i've never seen "this language is used in banking" to be used as the main reason for choosing one language over another (outside the banking, of course ;-).
> 
> if they want to contribute and support their contribution — great, they can. but if they want somebody to do the work for 'em for free... two words, seven letters.

Generally I would agree. However with something like "big decimal" I'd say it is worth doing anyway – even though the impetus appears to be from financial computing.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Mon, 2016-06-06 at 08:21 +0000, ketmar via Digitalmars-d wrote:
> On Monday, 6 June 2016 at 08:15:42 UTC, Russel Winder wrote:
> > 3. Have one lightweight D realized cross platform IDE.
> by the way, Buggins has dlangIDE written with his dlangUI package. it is cross-platform, has debugger support, and written in D!

Some months ago I cloned the repository, compiled it, and then found no way of getting a light on dark mode. I thus deleted and ignored it. Maybe I should try again and instead of ignoring problems, jump up and down, scream, throw my toys out of the pram, and write an issue :-) Yes, I know, and submit a pull request.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Tuesday, 7 June 2016 at 08:05:58 UTC, Russel Winder wrote:
> So instead of debating this endlessly, I think this is about the tenth time this has come up in the last two years, why doesn't a group of people who know about GC algorithms get together and write a new one?
> ...
> D has had lots of discussion on email lists but no-one has followed this up with actually doing something that resulted in a change.

As someone else mentioned earlier in this thread, Jeremy DeHaan is working on a GSoC project to begin overhauling the GC right now:
    http://forum.dlang.org/post/jcfwcdvvfytdkjrpdeld@forum.dlang.org

On Tuesday, 7 June 2016 at 08:54:32 UTC, Walter Bright wrote:
> On 6/7/2016 1:22 AM, Ola Fosheim Grøstad wrote:
>> So this is solved in modern C++.
>
> This is where we diverge. A language isn't safe unless it can mechanically guarantee that unsafe constructs are not used. Saying "don't write unsafe code" in C++ does not make it safe language.

C++ isn't a safe language, but if you are proficient in modern C++ then memory issues aren't the big hurdle. I find the syntactic mess that comes from having N different convoluted ways of doing the same thing in meta-programming to be more problematic in day-to-day programming than safety issues.


> How would you know some random 10,000 line piece of C++ code is using std::vector instead of [ ]?

Static analysis tooling? But I don't use std::vector. If you only "borrow" access to an array you should use gsl::span (a slice).

On Tuesday, 7 June 2016 at 09:02:05 UTC, Laeeth Isharc wrote:
> On Tuesday, 7 June 2016 at 08:57:36 UTC, Ola Fosheim Grøstad wrote:
>> On Tuesday, 7 June 2016 at 08:45:14 UTC, ketmar wrote:
>>> never seen "this language is used in banking" to be used as the main reason for choosing one language over another (outside the banking, of course ;-).
>>
>> True, positioning yourself as a toolmaker for banking/finance is basically saying it is arcane and slow-moving (like Cobol and Java).
>>
>
> I shall try to respect Andrei's advice, but really!  Hahahaha!

Try tell someone making a 3D engine that your tooling is used in banking and that they should switch from C++.

Now, don't feel insulted, but banking/finance is considered a boring application area by most programmers I know of.

On Mon, 2016-06-06 at 22:45 +0000, Carl Vogel via Digitalmars-d wrote:
> 
[…]
> I get that and agree. My point was a different one -- that these conversations are about a totally hypothetical RC implementation that we all imagine is perfect, and so we just discuss theoretical GC vs RC tradeoffs. The real one that gets made is going to have bugs and unexpected corner cases. So the risk is that at some point we'll all run to reddit and say "Tada, no more GC" and folks will then just say "D has RC, but it's buggy and unreliable and doesn't work when [insert anecdote]"
> […]

I suspect what will actually happen is that people will every so often raise these points and have long threads of debate and yet again do nothing.

RC is fine, cf. Python. GC is fine, cf. JVM.

D has a GC that can be switched off. Let's go with that. So the status quo is fine per se. The discussion should only be about whether this GC is good enough, and if it isn't write a new one. JVM did this, Go did this, D just has debates.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder