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

[Russel Winder via Digitalmars-d]

On Sun, 2015-03-15 at 14:13 +0000, Laeeth Isharc via Digitalmars-d
wrote:
[…]
> [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]

Not entirely true, this is a "belief" being put about by those who wish
to stay with Python 2 and not move to Python 3 for reasons other than
practical ones.

There are some cases, cf. Mercurial, where the code has been founded on
the equivalence of byte and character, which means they have to use
Python 2 or undertake a very serious rewrite of everything so as to use
Python 3 – which to date they are saying will never happen.

For most people though the fact that strings are sequences of Unicode
codepoints in Python 3 is not a problem processing files as long as they
remember that a file has an encoding. I can see that many like to slide
back to everything is ASCII encoded ergo bytes are strings of length 1
(there are no characters in Python). However once you get over the
barrier of "there are byte sequences and there are strings and they are
different", life becomes very much easier. Certainly I find I have no
problem doing networking with Python 3 having made the mental jump to
"remember about encodings".
 
[…]
> 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.

This would be a good addition to the website. Along with any C++ → D
stories.

It might be worth collecting D → … stories as well, not perhaps to
publish but to ascertain what the issues were. 
> 
> 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'.

I am fairly confident that the major issue is "presence in the market".
D is not a language that is known about, or talked about, in the same
sentences as Java, Python, C++, Fortran, Go, Scala, Groovy, etc. All too
often when I mention D in a conversation about language choice, the
reaction is "I've not heard of that one.". Nim, Ceylon, Kotlin are in
the same boat. Raising the presence of D in the minds of programmers and
their bosses so it get used in the same sentences as the other languages
is the task at hand.

[…]
> 
> 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.

Unless a REPL is needed (see previous rant of mine on REPLs, but you
possibly have a genuine need for one), editor+fast compilation is almost
certainly a better solution that a single line REPL. So rdmd almost
certainly its most people needs for "scripting with D".

The question is how to deal with evolving a persistent data set that
takes a long time to construct. I wonder if, rather than writing an
interpreter/REPL à la Scala, it might be better to build a small
framework for managing a persistent dataset. On Posix at least wrapping
something around mmap should do the job. This would then allow
snapshotting.

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

s/Russell/Russel/ ?

Excel is still the most used tool in quant work in many financial
institutions :-( Some banks are even going to the extent of
incorporating its use into their Python/C#/C++ workflows.

> 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?

Jupyter's aim is to be as language agnostic as possible. Hence it's
separation from IPython: having a separate identity makes it easier for
people to acknowledge the UI can be used with R, Julia, Markdown, LaTeX
as well as Python.

[…]

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20150317/cb83b986/attachment.sig>