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.win...@ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part