A few notes on choosing between Go and D for a quick project

[Laeeth Isharc via Digitalmars-d]

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).