On Sunday, 15 March 2015 at 12:52:37 UTC, Chris wrote:
Apart from performance issues, for language processing, string handling etc., Python quickly becomes a nightmare (UTF-8). Then there are issues like the one that classes cannot really have private variables.
[I am by no means expert in Python, but python 3 does not seem to be an improvement if you want to be able to accomplish tasks involving simple processing of ASCII files]
Sometimes advocacy of Python seems a bit absurd to me when it is along the lines of "Use Python, because it's easy. But don't use real Python, use Cython or Numba (and whatnot), Python is too slow". I.e. "Use it, but don't use it!" This shows that there is something wrong. You don't have this problem with D. You too wish you were using D everywhere, which tells me that the Python + C(++) solution is not optimal.
Modern people are not very good with deferred gratification. Python allows you to throw something working up quickly, but then there are less obvious costs that are deferred. I agree that it doesn't seem to be a positive to have your codebase split between different languages - having to keep things in sync and have people understand both codebases. That's one of the reasons I am trying to do everything in D (although for javascript charting looks like I have no easy alternative to using bokeh in python - until I can get around to writing a D implementation to make the JSON).
I think it would be a positive to have some user stories from people who have moved from Python+Cython or Python+C to D and seen significant benefits. I am sure there are plenty - most users don't seem to be active in the forum. And we should collect user stories, pretty them up, and have them reachable from the front page very easily. People make decisions based upon feelings (indeed without feelings there can be no decision), and so stories - based in reality - can be more persuasive than dry facts in persuading people.
We should try to identify what the biggest sticking points are for people considering making the switch, both real (like documentation) and perception (like 'D has no web/server framework'.
All I'm saying is that when people start a new project, I advise them to use D instead of Python. But there is no way to win against the cult of Python in scientific programming. It's too easy, too tempting at the start. Instant gratification and the feeling that you're on safe ground. D can't compete with this easily.
Of course there is, but it will take time. One wants a very high appeal to a small group of the potential user base initially (which no doubt will be the best part) and from there things will diffuse. Peter Thiel makes the same point I did (based on the Innovator's Dilemma) in his book "Zero to One".
Maybe we should invent (or continue with existing efforts) to write a scripting language based on D (or a Python interpreter or something that serves as a bridge to existing technologies (other than C)).
I was thinking about this just recently. There used to be a D scripting language (now rebranded as something else - I forget the name), but this fell into disuse post rdmd. Rdmd is great, a real simple win, but doesn't substitute for a scripting language in all uses.
In particular, I do agree with Russell about the value of an ipython/Jupyter notebook for scientific computing (which means also parts of finance) - especially for playing with data. Excel won't cut the mustard any more for many modern data sets, which means new tools like ipython notebooks come into focus.
For the time being it's not the lack of a notebook, but the lack of dataframes and pandas style functionality that prevent using D easily in this domain. But dataframes are not that complicated or difficult, and it is just a bit of work, and Vlad Levenfeld has made a good start on some of this.
I wonder whether it would be feasible to integrate the D REPL with Jupyter. Russell?
If I have time, I might also put together some code snippets with the most common tasks in programming, like startsWith and so on.
This would be great. I bet more generally there are many sections of code one has oneself (or knows of on github) that could be extracted and documented in a nice, aesthetically appealing, and structured way as part of a D tutorial series.
It would not be right to expect Herr Doktor Ruppe to do this work, but maybe a few could get together and start on this and send to him if he is open to featuring. If/when I can, I will try to help. The advantage of doing in this manner is the project is less overwhelming than trying to eat the elephant in a bite. (The disadvantage is a loss of coherence).
