On Thursday, 26 September 2019 at 16:04:18 UTC, bachmeier wrote:

> Python is also used for a lot of "real" programming tasks these days.

I know, but that doesn't mean it's a good choice. I suppose people (say scientists) just started with little scripts and then kept on using the language they already knew when things got bigger. A lot of that "real" stuff is not used in contexts where performance is crucial (e.g. real time) and believe me, it's really annoying if you get a great piece of software / research in Python that is completely useless in terms of developing a product where performance is crucial. And you cannot simply rewrite it, because it depends on loads of other Python modules developed by other scientists etc. And, of course, they used Python, because of all the useful modules...it's a vicious circle.

> D is perfectly suited for scripts of 200 lines. Moderate-sized programs typically start as small scripts and grow over time. You don't have to convince anyone to switch languages if they start out with D.

It is, but who will adopt an exotic language like D for scripting? D is "too much" for that, and it lacks the libraries Python has. Plus, everybody else uses Python etc. Do you really want to market D as a scripting language? It clearly isn't a scripting language. It's more like C++, Java and C# - and who's gonna learn D for scripting tasks? The learning curve is too steep. D is not a trivial language at all. Python is better suited for that.

> Neither Walter or Andrei has a scripting background, rather they are from the large-scale enterprise software world, and that led to the current emphasis on that segment. There's no reason the community can't pick up the ball and carry it into other arenas.

I don't think that's gonna work (see previous paragraph). The D community shouldn't be delusional about software and why / how it's adopted. There are both technical and socio-dynamic aspects to it. I think Nim and maybe Zig are much more realistic about things. (Btw, Nim's forced indentation might be a good marketing strategy to get Python devs on board. It might work.)

D has become too intellectual, i.e. playing with ideas and abstract concepts have become more important than the real world. And the problem is that this playing around with ideas has negatively affected the use of D in the real world. Once the D community gets over that, D might have a convincing "story" (it did when I first started to use it, in ~2010 I think).

On Friday, 27 September 2019 at 10:45:31 UTC, Chris wrote:
> [snip]
>
> D has become too intellectual, i.e. playing with ideas and abstract concepts have become more important than the real world. And the problem is that this playing around with ideas has negatively affected the use of D in the real world. Once the D community gets over that, D might have a convincing "story" (it did when I first started to use it, in ~2010 I think).

I came to D from scripting languages like Matlab, Python, and R. It got to the point where my code was taking 24 hours + to run and I tried to find alternatives that were faster. I tried C++, but didn't like it very much. I prefer D to C++, but I'm still far more productive in Matlab/Python/R because I can depend on other people's libraries to a greater extent. However, D has made some good progress on the library front in the past two years. Mir has really come into its own with its own little universe around it (lubeck and numir are fun) and the GSOC project Magpie for Data Frames already looks promising. I would contrast this progress on the library front with the intellectual issues you are describing on the language itself. For me, the biggest downside with D was a lack of libraries. As you mentioned above, modules depending on modules. The network effect is very important for these types of use cases. So I do see progress on this front, even if there is a lot of unhappy feelings about some language issues.

On Friday, 27 September 2019 at 12:47:44 UTC, jmh530 wrote:

>
> I came to D from scripting languages like Matlab, Python, and R. It got to the point where my code was taking 24 hours + to run and I tried to find alternatives that were faster.

You're very wise. I wish more Matlab / Python users switched to highly performant languages.

> I tried C++, but didn't like it very much. I prefer D to C++, but I'm still far more productive in Matlab/Python/R because I can depend on other people's libraries to a greater extent.
> However, D has made some good progress on the library front in the past two years. Mir has really come into its own with its own little universe around it (lubeck and numir are fun) and the GSOC project Magpie for Data Frames already looks promising. I would contrast this progress on the library front with the intellectual issues you are describing on the language itself. For me, the biggest downside with D was a lack of libraries. As you mentioned above, modules depending on modules. The network effect is very important for these types of use cases. So I do see progress on this front, even if there is a lot of unhappy feelings about some language issues.

That's good to hear. Would you care to tell us what exactly you're using D for? I'd imagine it's for some sort of stats / machine learning / AI stuff. Your experience might be valuable for others who are trying to get away from Matlab / Python, and, as bachmeier suggested, D might attract more "scrpiters". Let them know what to expect and what you can do with D + Mir etc.

On Friday, 27 September 2019 at 10:45:31 UTC, Chris wrote:
> On Thursday, 26 September 2019 at 16:04:18 UTC, bachmeier wrote:
>
>> [...]
>
> I know, but that doesn't mean it's a good choice. I suppose people (say scientists) just started with little scripts and then kept on using the language they already knew when things got bigger. A lot of that "real" stuff is not used in contexts where performance is crucial (e.g. real time) and believe me, it's really annoying if you get a great piece of software / research in Python that is completely useless in terms of developing a product where performance is crucial. And you cannot simply rewrite it, because it depends on loads of other Python modules developed by other scientists etc. And, of course, they used Python, because of all the useful modules...it's a vicious circle.
>
> [...]

If any language is going to overtake Python or R among scientific users, I am betting Julia will be that language.

On Friday, 27 September 2019 at 13:04:37 UTC, Paulo Pinto wrote:

> If any language is going to overtake Python or R among scientific users, I am betting Julia will be that language.

Yep. I agree. It's geared towards scientific programming and the devs are well aware of the drawbacks of Python and Matlab.

"Julia features optional typing, multiple dispatch, and good performance, achieved using type inference and just-in-time (JIT) compilation, implemented using LLVM. It is multi-paradigm, combining features of imperative, functional, and object-oriented programming. Julia provides ease and expressiveness for high-level numerical computing, in the same way as languages such as R, MATLAB, and Python, but also supports general programming. To achieve this, Julia builds upon the lineage of mathematical programming languages, but also borrows much from popular dynamic languages, including Lisp, Perl, Python, Lua, and Ruby." [1]

[1] https://docs.julialang.org/en/v1/

On Friday, 27 September 2019 at 13:04:37 UTC, Paulo Pinto wrote:

> If any language is going to overtake Python or R among scientific users, I am betting Julia will be that language.

*If* that is going to happen, I think you're right. Many economists have been moving from Matlab to Julia. For instance, the New York Fed has ported their forecasting model (a fairly large codebase) from Matlab to Julia. Matlab is not the best language, but a bigger factor is that it's really expensive - wealthy institutions complain about Matlab licensing costs. I don't see it making much progress in replacing Python or R yet. Maybe that's just my small view of the world.

A different use case, for which Julia isn't as well suited, is writing extensions. In R, the most popular dependency for packages by far is C++ in the form of Rcpp. D is a perfect replacements, and that's primarily how I've been using it (giving up on C++ for that was why I looked at D in the first place). There's a lot of room for D in that area. Too bad I don't have time to work on marketing it.

On Friday, 27 September 2019 at 14:01:34 UTC, bachmeier wrote:
>
> *If* that is going to happen, I think you're right. Many economists have been moving from Matlab to Julia. For instance, the New York Fed has ported their forecasting model (a fairly large codebase) from Matlab to Julia. Matlab is not the best language, but a bigger factor is that it's really expensive - wealthy institutions complain about Matlab licensing costs. I don't see it making much progress in replacing Python or R yet. Maybe that's just my small view of the world.
>
> A different use case, for which Julia isn't as well suited, is writing extensions. In R, the most popular dependency for packages by far is C++ in the form of Rcpp. D is a perfect replacements, and that's primarily how I've been using it (giving up on C++ for that was why I looked at D in the first place). There's a lot of room for D in that area. Too bad I don't have time to work on marketing it.

Now, that sounds very interesting and promising. A few bullet points and maybe it could be turned into a blog post. There are two obstacles though:

1. D is huge, so you'd need a dedicated section "D for Data Scientists", so they know exactly which subset / features to use to get going.

2. Lack of consistency due to a constant change of focus by leadership / community

Imo, 2. is the biggest obstacle.

On Friday, 27 September 2019 at 14:01:34 UTC, bachmeier wrote:
>
> A different use case, for which Julia isn't as well suited, is writing extensions. In R, the most popular dependency for packages by far is C++ in the form of Rcpp. D is a perfect replacements, and that's primarily how I've been using it

Speaking of which, I've thought about D as an extension / glue language too. I think it'd be well suited for that.

On Wednesday, 25 September 2019 at 13:04:09 UTC, Chris wrote:
> I will not engage in a discussion about Python-style whitespace tyranny again. In fact, it can render code actually _less_ readable and trigger compiler errors for no reason other than

It is annoying if using a plain text editor, but I find it to be enjoyable when using a dedicated Python editor.

I feel this is an area where current languages will start to look dated as new languages appear that are designed alongside the tooling for the language.

Plain text is a rather crude representation.

On Friday, 27 September 2019 at 14:01:34 UTC, bachmeier wrote:
> On Friday, 27 September 2019 at 13:04:37 UTC, Paulo Pinto wrote:
>
>> If any language is going to overtake Python or R among scientific users, I am betting Julia will be that language.
>
> *If* that is going to happen, I think you're right. Many economists have been moving from Matlab to Julia. For instance, the New York Fed has ported their forecasting model (a fairly large codebase) from Matlab to Julia. Matlab is not the best language, but a bigger factor is that it's really expensive - wealthy institutions complain about Matlab licensing costs. I don't see it making much progress in replacing Python or R yet. Maybe that's just my small view of the world.

Octave is a  free implementation of Matlab that is quite capable, but it does not provide all the specialized matlab functions needed to achieve 100% compatibility.  So if that is an obstacle for Octave, then it probably is an obstacle for Julia as well.

Anyway, as long as Python is taking over in higher education then Python will remain the language of choice...  Since Julia is not suitable for CS students then Python most likely will keep that position.

Btw, I think most people need a very compelling reason to switch to a new language.