On Monday, 30 October 2017 at 17:35:51 UTC, jmh530 wrote:
> On Monday, 30 October 2017 at 16:50:42 UTC, Joakim wrote:
>> [snip]
>>
>> No, it happens when they streamline and automate their entire workflow much more, to the point where they aren't using antiquated document systems anymore:
>>
>> http://ben-evans.com/benedictevans/2015/5/21/office-messaging-and-verbs
>>
>> I've never written a single document in the entire time I've contributed to the D open source project.  That's because we replace that ancient document workflow with forums, email, gitter, bugzilla, git, and github, some of which is also fairly old tech, but not nearly so as typing up a bunch of documents or spreadsheets.
>>
>> Of course, the D OSS project isn't a business, but the point is made in that linked post: most businesses are also about to transition away from that doc workflow altogether, where they simply replaced a bunch of printed documents and balance sheets with digital versions of the _same_ documents over the last couple decades.  It's time for them to make the true digital transition, or they will lose out to those who did and became more efficient for it.
>>
>> Lyft and Uber are merely two public examples of the leading edge of this wave.
>>
>
> You're making a broader point about Lyft and Uber that I agree with. Automating certain things and providing a digital platform has been very successful for them. But taxicab companies switching from Excel to Google docs wouldn't have solved anything for them. Taxicab companies in London and other places have found better ways to adapt (excepting through increased regulations) by offering their own apps to compete.
>
> Similarly, the investment management industry (my industry) has seen a large increase in the share of passive management over the past 10 years (and a corresponding decline in the share of active management). Switching from Excel to Google docs is irrelevant. There are broader competitive forces at work.
>
> Now, these competitive forces have been shaped by computer-driven investing and a reduction in costs. So in this sense, your broader point has validity, but perhaps the way you were expressing it with regard to Office vs. Google Docs was not convincing.

That's because I never made that Office/Docs comparison in the first place, I merely gave an example of someone plausibly replacing their current Windows/Excel workflow with Android/Docs in a decade.  The operative comparison there is mobile Android versus desktop/laptop Windows, Docs doesn't even matter as Excel also runs on mobile.

I was talking about the mobile shift being so big that it takes out a host of Windows PC-driven shops.  I also tangentially mentioned that I don't think people will be using Office _or_ Docs in a decade, which is the bigger shift you seemed to want to explore, so I expanded on it.

Lyft and Uber are particularly apposite because they've ridden both shifts to quick success.

>> Do those Python/Numpy users have the level of VS or other Windows IDE support that D currently doesn't?
>
> You don't need VS with Python/Numpy, but python has a large number of IDEs available. I haven't used them, but they are there. The only thing I ever used was Ipython notebooks, which became Jupyter.

Never used Jupyter but I see that it's a webapp, so it should work fine on mobile, or as a frontend for a cloud instance.

On Monday, 30 October 2017 at 16:50:42 UTC, Joakim wrote:
> [...]
> Do those Python/Numpy users have the level of VS or other Windows IDE support that D currently doesn't?  Either way, math modeling is such a small niche that I'm not sure it makes a difference, though I'm glad Ilya and others are pushing D in that direction on all OS's.

Microsoft provides first class support for Python and R on Visual Studio.

https://www.visualstudio.com/vs/python/

https://www.visualstudio.com/vs/rtvs/

On Monday, 30 October 2017 at 14:46:30 UTC, Adam D. Ruppe wrote:
> If you're playing around... really no reason not to just use the 32 bit one.

Really depends what you're playing with.

If you play with large databases, containing a lot data, then 64-bit memory addressing will give you access to more memory.

And more memory means faster operations.

On Tuesday, 31 October 2017 at 01:00:29 UTC, codephantom wrote:
> If you play with large databases, containing a lot data, then 64-bit memory addressing will give you access to more memory.

That doesn't really matter. If you're IMPLEMENTING the database, sure it can help (but is still not *necessary*), but if you're just playing with it, let the database engine handle that and just query the bits you are actually interested in.

People have been working with huge, HUGE databases in 32 bit programs for years.

> And more memory means faster operations.

Not necessarily.


There are advantages to 64 bit, but you can live without them. A 32 bit program can do most the same stuff.

On Tuesday, 31 October 2017 at 01:25:31 UTC, Adam D Ruppe wrote:
> On Tuesday, 31 October 2017 at 01:00:29 UTC, codephantom wrote:
>> If you play with large databases, containing a lot data, then 64-bit memory addressing will give you access to more memory.
>
> That doesn't really matter. If you're IMPLEMENTING the database, sure it can help (but is still not *necessary*),

Kinda important, say your server is 128Gb (bugger sizes are quite typical these days).

>  but if you're just playing with it, let the database engine handle that and just query the bits you are actually interested in.
>
> People have been working with huge, HUGE databases in 32 bit programs for years.
>

Ah ye, we can do the same in 16 bits with ample 640k bytes. Just window your dataset in 64k at a time, trivial. There are advantages in bigger size of virtual address space even if you use tiny fraction of physical memory.

>
>
> There are advantages to 64 bit, but you can live without them.

I can live without hot water in my house, would I?

> A 32 bit program can do most the same stuff.

Client applications probably do not care much. Servers and cluster software can use more RAM and take advantage of huge address space in many interesting ways.

On Monday, 30 October 2017 at 14:46:30 UTC, Adam D. Ruppe wrote:
> On Monday, 30 October 2017 at 10:53:33 UTC, Kagamin wrote:
>> Because native.
>
> The processor natively supports all 32 bit code when running in 64 bit more. It just works as far as native hardware goes.

For processor it's a whole compatibility mode of operation. It's fairly deeply integrated, but still...

> You also need your library dependencies installed too, and indeed on Linux that might be an extra install (just like any other dependencies...), but on Windows, the 32 bit core libs are always installed and with D, you don't really use other stuff anyway.

For OS it's a whole emulated subsystem with separate collection of compiled code installed and loaded into RAM. On my system it's 1.36gb, 7000 files. On Windows it depends on installation too whether 32 bit subsystem is installed. Also if the code can work on linux 64 bit, there's little reason to stretch it to 32 bit.

> If you're playing around... really no reason not to just use the 32 bit one.

64 bit system is free from some legacy stuff too, it's just better. So it's better to play with 64 bit than with 32 bit. For example remember the whole OMF deal.

On Tuesday, 31 October 2017 at 01:25:31 UTC, Adam D Ruppe wrote:
> That doesn't really matter. If you're IMPLEMENTING the database, sure it can help (but is still not *necessary*), but if you're just playing with it, let the database engine handle that and just query the bits you are actually interested in.
>
> People have been working with huge, HUGE databases in 32 bit programs for years.

It's like clanging rocks together to get fire. It can be done, just expensive and doesn't scale when logic becomes complex.

On 10/30/2017 09:25 PM, Adam D Ruppe wrote:
> There are advantages to 64 bit, but you can live without them. A 32 bit program can do most the same stuff.

The differences in performance are large and growing, however. -- Andrei

On Tuesday, 31 October 2017 at 06:33:02 UTC, Dmitry Olshansky wrote:
> I can live without hot water in my house, would I?

So sad but true... my water heater went down today :( Basement flooded and it is blinking out a bad vapor sensor error code.

> Client applications probably do not care much. Servers and cluster software can use more RAM and take advantage of huge address space in many interesting ways.

Yeah, I know. And if you're writing that kind of software, installing Visual Studio isn't a big deal.

But my point is that the kind of typical hobby stuff and a huge (HUGE) subset of other work too functions perfectly well with 32 bit, yes, even with optlink. You can do web applications, desktop applications, games, all kinds of things with the out-of-the-box dmd install and nobody will be the wiser of 32 vs 64 bit unless someone makes a specific stink over it.

On Monday, 30 October 2017 at 13:32:23 UTC, Joakim wrote:
>
> I don't know how intense your data analysis is, but I replaced a Win7 ultrabook that had a dual-core i5 and 4 GBs of RAM with an Android tablet that has a quad-core ARMv7 and 3 GBs of RAM as my daily driver a couple years ago, without skipping a beat.
>  I built large mixed C++/D codebases on my ultrabook, now I do that on my Android/ARM tablet, which has a slightly weaker chip than my smartphone.
>

how do you program on your tablet? what are your tools? what is your setup? i also believe laptops are here to go.