www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - python vs d

reply "Suliman" <evermind live.ru> writes:
I am following discussions about GC and some other 'critical' 
improves in D language for a long time. I see a lot of arguments 
and heaps of code, that often hard to understand (for example 
Templates) even more complicated to use it.

I like D, but more and more I am playing with Python, and 
understanding it's philosophy. And I like it because it's do not 
have any overhead like C++. It's clean any easy to understanding. 
As result it's harder to write bad code in it.

Does anybody make tests of speed most common algorithm in D and 
Python. I am trying to understand which project better to start 
in Python and which in D.
Apr 23 2014
next sibling parent "bytedruid" <someone fake.com> writes:
On Thursday, 24 April 2014 at 06:38:42 UTC, Suliman wrote:

 I am following discussions about GC and some other 'critical' 
 improves in D language for a long time. I see a lot of 
 arguments and heaps of code, that often hard to understand (for 
 example Templates) even more complicated to use it.

 I like D, but more and more I am playing with Python, and 
 understanding it's philosophy. And I like it because it's do 
 not have any overhead like C++. It's clean any easy to 
 understanding. As result it's harder to write bad code in it.

 Does anybody make tests of speed most common algorithm in D and 
 Python. I am trying to understand which project better to start 
 in Python and which in D.


I'm completely new to D, but have been writing in python for 
quite a while.  Python is a very good language but it can be 
slow.  I've noticed that anything involving bit shifting is very 
slow.

On one project I had a CRC algorithm in a python program that had 
to read a 2 megabit/sec datastream, calculate/compare CRC's and 
write data to disk files based on encoded times.  The calculation 
involved bit shifting and the program couldn't keep up with the 
input stream at 96% CPU utilization.  I implemented the CRC 
calculation in C (with almost no change to the algorithm), and 
added a python binding, leaving the rest of the python program 
unchanged.  CPU utilization dropped to 4.5% and I was able to 
keep up with the input stream, no problem.

In general I guess that anytime you need native performance write 
the program in D.  If it doesn't matter one way or the other 
write in D because you can deliver a binary with no dependency on 
an interpreter.  But if you know that the python interpreter will 
be available on the target system, and you need to make use of 
the extensive python standard library, and your program isn't 
multi-threaded, then use Python.
Apr 24 2014
prev sibling next sibling parent reply "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
On Thursday, 24 April 2014 at 06:38:42 UTC, Suliman wrote:

 I am following discussions about GC and some other 'critical' 
 improves in D language for a long time. I see a lot of 
 arguments and heaps of code, that often hard to understand (for 
 example Templates) even more complicated to use it.

 I like D, but more and more I am playing with Python, and 
 understanding it's philosophy. And I like it because it's do 
 not have any overhead like C++. It's clean any easy to 
 understanding. As result it's harder to write bad code in it.

 Does anybody make tests of speed most common algorithm in D and 
 Python. I am trying to understand which project better to start 
 in Python and which in D.


In my experience alot of the code you see popping up on this 
forum is from people who are interested in developing reusable 
libraries (parts of Phobos) and pushing the limits of D.

To accomplish some task in D, I would suggest that the normal D 
code would (could) look a lot closer to the Python code 
performing the same task, than much of what you see posted on 
here.

Most of my D code looks nothing like what you see posted on these 
lists. I likely don't write code in the idiomatic D way, but it 
still works and is a lot easier on the eyes than my C++ code.

I think improving the library documentation and some parts of the 
library (ie. XML, JSON a few others) would likely help close the 
gap with Python in terms of 'ease of use'.  Of course it will 
likely never be as easy as Python for quick and dirty apps. 
However, just because you can do crazy complex stuff in D doesn't 
mean you have to.
Apr 24 2014
parent reply "Suliman" <evermind live.ru> writes:
 Most of my D code looks nothing like what you see posted on 
 these lists. I likely don't write code in the idiomatic D way, 
 but it still works and is a lot easier on the eyes than my C++ 
 code.

 I think improving the library documentation and some parts of 
 the library (ie. XML, JSON a few others) would likely help 
 close the gap with Python in terms of 'ease of use'.  Of course 
 it will likely never be as easy as Python for quick and dirty 
 apps. However, just because you can do crazy complex stuff in D 
 doesn't mean you have to.


It would be very nice to add to dlang wiki comparison woth 
Python, to show that D code can be easy as Python. Because some 
of solution here are very hard for understanding. For example 
topic that was few days ago about филге checking element in an 
array 
http://forum.dlang.org/thread/lbhtghccdtoojwpfyapw forum.dlang.org

Also what about web. Is I understand there is another situation, 
and 90% of task in middle site is SELECT operation. So where is 
speed of D can be used? What benefits I will get in speed and 
writing code instead of Python or even PHP. Both of them have 
good optimization for such operations...
Apr 24 2014
next sibling parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Thursday, 24 April 2014 at 08:05:53 UTC, Suliman wrote:

 Most of my D code looks nothing like what you see posted on 
 these lists. I likely don't write code in the idiomatic D way, 
 but it still works and is a lot easier on the eyes than my C++ 
 code.

 I think improving the library documentation and some parts of 
 the library (ie. XML, JSON a few others) would likely help 
 close the gap with Python in terms of 'ease of use'.  Of 
 course it will likely never be as easy as Python for quick and 
 dirty apps. However, just because you can do crazy complex 
 stuff in D doesn't mean you have to.


 It would be very nice to add to dlang wiki comparison woth 
 Python, to show that D code can be easy as Python. Because some 
 of solution here are very hard for understanding. For example 
 topic that was few days ago about филге checking element in an 
 array 
 http://forum.dlang.org/thread/lbhtghccdtoojwpfyapw forum.dlang.org

 Also what about web. Is I understand there is another 
 situation, and 90% of task in middle site is SELECT operation. 
 So where is speed of D can be used? What benefits I will get in 
 speed and writing code instead of Python or even PHP. Both of 
 them have good optimization for such operations...


Based upon what I've tested on my machine which I might add has a 
problem with hard drive speed (bottleneck) Cmsed/Vibe is capable 
of a very large number of connections per second with quite a low 
memory footprint. Which does exceed any PHP web service framework 
currently available.
I've seen around 16k possible locally with logging off, release 
build and keep alive. Still thats a far cry from 2.5k which is 
around PHP frameworks usual max.
Perhaps with some form of caching for complex pages it'll stay 
quite high, although I haven't really looked into this.

Speed isn't the only consideration with building web services 
however. How well does it scale? Productivity to write?

Either way at this stage the bottleneck isn't the runtime 
performance its actually compilation. Right now with Vibe/Cmsed 
you cannot do reloading of templates/routes/models at runtime.
This is the next step to getting D as a real substitute for e.g. 
Java for web development.
I've been waiting up to this point for shared library support on 
all platforms but.. in the end I want this kinda now. Here is 
what I'm doing [0].

[0] 
http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/1404/
Apr 24 2014
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Suliman:


 It would be very nice to add to dlang wiki comparison woth 
 Python, to show that D code can be easy as Python.


In the Rosettacode site there are around one thousand Python-D 
comparisons.

Bye,
bearophile
Apr 24 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/24/14, 2:20 AM, bearophile wrote:

 Suliman:


 It would be very nice to add to dlang wiki comparison woth Python, to
 show that D code can be easy as Python.


 In the Rosettacode site there are around one thousand Python-D comparisons.

 Bye,
 bearophile


Guess we could link from dlang.org to some. -- Andrei
Apr 24 2014
next sibling parent "Meta" <jared771 gmail.com> writes:
On Thursday, 24 April 2014 at 16:23:22 UTC, Andrei Alexandrescu 
wrote:

 Guess we could link from dlang.org to some. -- Andrei


It would be neat to have some of the shorter Rosetta Code 
examples on rotation... Do they allow the examples to be 
displayed outside of RC?
Apr 24 2014
prev sibling next sibling parent "Meta" <jared771 gmail.com> writes:
On Thursday, 24 April 2014 at 16:23:22 UTC, Andrei Alexandrescu
wrote:

 Guess we could link from dlang.org to some. -- Andrei


It would be neat to have some of the shorter Rosetta Code
examples on rotation... Do they allow the examples to be
displayed outside of RC?
Apr 24 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


 Guess we could link from dlang.org to some. -- Andrei


A simpler solution is to to just link to this page, that contains 
the links to all pages that contain D entries:

http://rosettacode.org/wiki/Category:D

Bye,
bearophile
Apr 24 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/24/14, 10:30 AM, bearophile wrote:

 Andrei Alexandrescu:


 Guess we could link from dlang.org to some. -- Andrei


 A simpler solution is to to just link to this page, that contains the
 links to all pages that contain D entries:

 http://rosettacode.org/wiki/Category:D

 Bye,
 bearophile


Great, but I'm not seeing the PR. -- Andrei
Apr 24 2014
prev sibling parent reply "Suliman" <evermind live.ru> writes:
On Thursday, 24 April 2014 at 16:23:22 UTC, Andrei Alexandrescu 
wrote:

 On 4/24/14, 2:20 AM, bearophile wrote:

 Suliman:


 It would be very nice to add to dlang wiki comparison woth 
 Python, to
 show that D code can be easy as Python.


 In the Rosettacode site there are around one thousand Python-D 
 comparisons.

 Bye,
 bearophile


 Guess we could link from dlang.org to some. -- Andrei


It's much better to add best examples at wiki.dlang.org it's 
would be much easy for new comers to get info there than on 3 
-parts sites. And program code is good, but would be very good to 
examples of simple algorithms like intersect to arrays, find 
copies in arrays, create thread and so on.

Very often I am googling such info because I know how to do it in 
one language and have now idea how to do it's in D.
Apr 24 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Suliman:


 It's much better to add best examples at wiki.dlang.org


I am updating the examples on Rosettacode almost daily (example: 
I am currently modifying tens of entries to use  nogc). So you 
Suliman do you want to keep updating the dwiki to follow the very 
frequent changes in the rosettacode entries code?

Bye,
bearophile
Apr 24 2014
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 24 Apr 2014 17:08:40 -0400, bearophile <bearophileHUGS lycos.com>  
wrote:


 Suliman:


 It's much better to add best examples at wiki.dlang.org


 I am updating the examples on Rosettacode almost daily (example: I am  
 currently modifying tens of entries to use  nogc)


I don't think this is a very good idea. The code should likely build with  
the latest released compiler.

-Steve
Apr 24 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Steven Schveighoffer:


 I don't think this is a very good idea. The code should likely 
 build with the latest released compiler.


Yes, sorry, I know this could cause some troubles, but if you 
think hard about the situation, you will see that this is 
currently the best (or less bad) solution. It was recently 
discussed in D.learn, but I can't find the thread. So let's not 
discuss it again, because the conclusion will be the same.

Bye,
bearophile
Apr 24 2014
parent Jacob Carlborg <doob me.com> writes:
On 24/04/14 23:49, bearophile wrote:


 Yes, sorry, I know this could cause some troubles, but if you think hard
 about the situation, you will see that this is currently the best (or
 less bad) solution. It was recently discussed in D.learn, but I can't
 find the thread. So let's not discuss it again, because the conclusion
 will be the same.


An ugly hack is to add a  nogc UDA.

-- 
/Jacob Carlborg
Apr 24 2014
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Steven Schveighoffer:


 I don't think this is a very good idea. The code should likely 
 build with the latest released compiler.


Oh, if you want to help rosettacode efforts, then try to fix this 
entry:
http://rosettacode.org/wiki/Parallel_calculations#D

Bye,
bearophile
Apr 24 2014
prev sibling next sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Thursday, 24 April 2014 at 06:38:42 UTC, Suliman wrote:

 I am following discussions about GC and some other 'critical' 
 improves in D language for a long time. I see a lot of 
 arguments and heaps of code, that often hard to understand (for 
 example Templates) even more complicated to use it.


Try this intro: http://nomad.so/2013/07/templates-in-d-explained/ 
Once you understand what the extra parens and exclamation marks 
are it all becomes clear.
Apr 24 2014
prev sibling next sibling parent "w0rp" <devw0rp gmail.com> writes:
On Thursday, 24 April 2014 at 06:38:42 UTC, Suliman wrote:

 Does anybody make tests of speed most common algorithm in D and 
 Python. I am trying to understand which project better to start 
 in Python and which in D.


I think I split my decision based on the tools available. So I'd 
probably write a website in Django instead of vibe.d because I 
would save a lot of time. I'd probably write D instead of Python 
in a lot of cases.

More than just for speed, I've come to appreciate type 
information and what I call "statically checked duck typing," 
which is how ranges work and so on. In D I can write code such 
that I can know very early on that it has a good chance of 
actually working. In Python, I often find out about problems too 
late, and I have to rely on tests with good code coverage to make 
sure that very basic code works at all.
Apr 24 2014
prev sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Thursday, 24 April 2014 at 06:38:42 UTC, Suliman wrote:

 I am following discussions about GC and some other 'critical' 
 improves in D language for a long time. I see a lot of 
 arguments and heaps of code, that often hard to understand (for 
 example Templates) even more complicated to use it.

 I like D, but more and more I am playing with Python, and 
 understanding it's philosophy. And I like it because it's do 
 not have any overhead like C++. It's clean any easy to 
 understanding. As result it's harder to write bad code in it.

 Does anybody make tests of speed most common algorithm in D and 
 Python. I am trying to understand which project better to start 
 in Python and which in D.


In my experience, it is better to start a new project with D, not 
only because of speed. As a project grows, the restrictions of 
Python become more apparent (and annoying). If copyright is an 
issue, D is the better option, too. Python can be decompiled 
easily. I don't know what kind of projects you have in mind, but 
in our projects Python is always the bottleneck and has to be 
rewritten in a different language anyway, sooner or later.
Apr 28 2014
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Monday, 28 April 2014 at 09:10:53 UTC, Chris wrote:

 On Thursday, 24 April 2014 at 06:38:42 UTC, Suliman wrote:

 I am following discussions about GC and some other 'critical' 
 improves in D language for a long time. I see a lot of 
 arguments and heaps of code, that often hard to understand 
 (for example Templates) even more complicated to use it.

 I like D, but more and more I am playing with Python, and 
 understanding it's philosophy. And I like it because it's do 
 not have any overhead like C++. It's clean any easy to 
 understanding. As result it's harder to write bad code in it.

 Does anybody make tests of speed most common algorithm in D 
 and Python. I am trying to understand which project better to 
 start in Python and which in D.


 In my experience, it is better to start a new project with D, 
 not only because of speed. As a project grows, the restrictions 
 of Python become more apparent (and annoying). If copyright is 
 an issue, D is the better option, too. Python can be decompiled 
 easily. I don't know what kind of projects you have in mind, 
 but in our projects Python is always the bottleneck and has to 
 be rewritten in a different language anyway, sooner or later.


My experience mirrors this exactly. I find Python quite quickly 
becomes unwieldy for large projects, even if the performance is 
not an issue.

As with all these things, YMMV; there are many large, successful 
Python projects.


It is pretty good for interactive work, especially if you can 
leverage the large body of work that the scientific community has 
produced in python.


Choosing between D and Python:

Pretty much anything written in pure Python can be easily 
demolished by D in terms of performance.

D doesn't have much provision for interactive work (work in 
progress).

You can do 2-way communication between D and Python 
(https://bitbucket.org/ariovistus/pyd)

Fast algorithms that you use in Python are often implemented in C 
as extensions. D can call C code directly. C vs D is very much 
splitting hairs when it comes to performance.

D has a steeper learning curve, but it will teach you widely 
applicable knowledge and skills.
Apr 28 2014
next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 2014-04-28 at 09:27 +0000, John Colvin via Digitalmars-d wrote:
[…]

 As with all these things, YMMV; there are many large, successful 
 Python projects.


I think this is a crucially important thing to remember: YMMV.

This is not a black and white, D or Python. Different organization and
projects will have different metrics for choice, meaning that Python, D,
Go, C++, Java, Groovy, etc. all have valuable roles in the world. Choice
of programming language is about making the least worst choice in a
given context.

The fact that I am rewriting a Python + GTK project in D + GtkD does not
mean I now no longer use Python, it is that the context has changed,
making a change of language appropriate.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Apr 28 2014
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Monday, 28 April 2014 at 09:41:43 UTC, Russel Winder via 
Digitalmars-d wrote:

 On Mon, 2014-04-28 at 09:27 +0000, John Colvin via 
 Digitalmars-d wrote:
 […]

 As with all these things, YMMV; there are many large, 
 successful Python projects.


 I think this is a crucially important thing to remember: YMMV.

 This is not a black and white, D or Python. Different 
 organization and
 projects will have different metrics for choice, meaning that 
 Python, D,
 Go, C++, Java, Groovy, etc. all have valuable roles in the 
 world. Choice
 of programming language is about making the least worst choice 
 in a
 given context.

 The fact that I am rewriting a Python + GTK project in D + GtkD 
 does not
 mean I now no longer use Python, it is that the context has 
 changed,
 making a change of language appropriate.


Although I stick by the YMMV, I use python 3 several hours a day 
and it's caused me no end of pain with very little gain. If it 
wasn't for pandas and (I shudder to say it) matplotlib, I really 
wouldn't have any reason to stay.

What features does python, as a language (syntactical preferences 
aside), actually have to recommend it over D (assuming drepl* or 
similar became full-featured)? This is definitely not a 
rhetorical question, it could be useful to D development.

* http://drepl.dawg.eu/ and https://github.com/MartinNowak/drepl
Apr 28 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 28 April 2014 at 18:07:45 UTC, John Colvin wrote:

 What features does python, as a language (syntactical 
 preferences aside), actually have to recommend it over D 
 (assuming drepl* or similar became full-featured)?


Libraries.
For closures for arrays and dicts.
Tuples.
Heavy duty reflection and runtime dynamics.
(Runtime extensible classes.)
(Runtime integration of python and templates.)
System support (app engine, etc).
Lots of how-to-stuff on the web.
Apr 28 2014
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Monday, 28 April 2014 at 18:18:25 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 28 April 2014 at 18:07:45 UTC, John Colvin wrote:

 What features does python, as a language (syntactical 
 preferences aside), actually have to recommend it over D 
 (assuming drepl* or similar became full-featured)?


 Libraries.


not part of the language (unless you count the standard library. 
I don't see anything particularly special about python's standard 
library).


 For closures for arrays and dicts.


I don't understand


 Tuples.


std.meta is on it's way, possibly with some small language 
improvements. It's surprising how much python-style tuple code 
you can do in D already, but the syntax is a little lacking. 
(e.g. `int a, b, c; std.typetuple.TypeTuple!(a, c, b) = 
std.typecons.tuple(2, 3, 7).expand;`)


 Heavy duty reflection and runtime dynamics.


Agreed. However, a lot of this is obviated by the compile-time 
abilities of D. Perhaps I'm just not that imaginative with my 
runtime introspections.


 (Runtime extensible classes.)


I don't imagine this being difficult to do as a library type with 
opDispatch. This would be an interesting little project.


 (Runtime integration of python and templates.)


I presume you mean web templates? This is a strong point in 
favour of an interpreted language, although the compile-time 
approach in vibe.d is powerful. As long as the code doesn't 
change too often, you can always recompile it and load as a 
shared library (I believe this is being looked at by vibe.d 
developers).


 System support (app engine, etc).


Not part of the language


 Lots of how-to-stuff on the web.


Ditto
Apr 28 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 28 April 2014 at 18:45:54 UTC, John Colvin wrote:

 Libraries.


 not part of the language (unless you count the standard 
 library. I don't see anything particularly special about 
 python's standard library).


Hmm… I think that for Python, Ruby and Perl, the libraries and 
the ecosystems to a large extent are part of the language. And I 
think the lack of C-like efficiency in the language encourage 
that, e.g. you don't really care that much about a library being 
50% faster/slower. You care primarily about getting the job done. 
Not so with C/C++ libraries…


 For closures for arrays and dicts.


 I don't understand


I used the wrong term, I meant list comprehensions. The most 
important feature in Python for me. I find it very powerful in 
combination with tuples, lists and dicts.


 improvements. It's surprising how much python-style tuple code 
 you can do in D already, but the syntax is a little lacking.


But for tuples the ease-of-use syntax is important, otherwise you 
can just use struct or some other aggregate. Tuples are often 
used as anonymous on-the-fly structs.


 (Runtime integration of python and templates.)


 I presume you mean web templates?


That is the most common scenario.


 This is a strong point in favour of an interpreted language, 
 although the compile-time approach in vibe.d is powerful. As 
 long as the code doesn't change too often, you can always 
 recompile it and load as a shared library (I believe this is 
 being looked at by vibe.d developers).


Yeah, except when you build a CMS, but you can always include a 
scripting language.

However, given the trade offs I still think I would prefer static 
typing (such as D) because runtime errors tend to show up after 
release. (Assuming fast on-the-fly compilation which is a 
must-have for web development.)


 Lots of how-to-stuff on the web.


 Ditto


Actually,  I think it is part of the language's resulting eco 
system.

I believe "toolbox" languages like Python and Perl will have more 
recipes and "nimble quick fix libraries" on the web than 
application languages.
Apr 29 2014
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 29 April 2014 at 10:51:26 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 28 April 2014 at 18:45:54 UTC, John Colvin wrote:

 Libraries.


 not part of the language (unless you count the standard 
 library. I don't see anything particularly special about 
 python's standard library).


 Hmm… I think that for Python, Ruby and Perl, the libraries and 
 the ecosystems to a large extent are part of the language. And 
 I think the lack of C-like efficiency in the language encourage 
 that, e.g. you don't really care that much about a library 
 being 50% faster/slower. You care primarily about getting the 
 job done. Not so with C/C++ libraries…


 For closures for arrays and dicts.


 I don't understand


 I used the wrong term, I meant list comprehensions. The most 
 important feature in Python for me. I find it very powerful in 
 combination with tuples, lists and dicts.


 improvements. It's surprising how much python-style tuple code 
 you can do in D already, but the syntax is a little lacking.


 But for tuples the ease-of-use syntax is important, otherwise 
 you can just use struct or some other aggregate. Tuples are 
 often used as anonymous on-the-fly structs.


 (Runtime integration of python and templates.)


 I presume you mean web templates?


 That is the most common scenario.


 This is a strong point in favour of an interpreted language, 
 although the compile-time approach in vibe.d is powerful. As 
 long as the code doesn't change too often, you can always 
 recompile it and load as a shared library (I believe this is 
 being looked at by vibe.d developers).


 Yeah, except when you build a CMS, but you can always include a 
 scripting language.

 However, given the trade offs I still think I would prefer 
 static typing (such as D) because runtime errors tend to show 
 up after release. (Assuming fast on-the-fly compilation which 
 is a must-have for web development.)


 Lots of how-to-stuff on the web.


 Ditto


 Actually,  I think it is part of the language's resulting eco 
 system.

 I believe "toolbox" languages like Python and Perl will have 
 more recipes and "nimble quick fix libraries" on the web than 
 application languages.


My bet is that D users will be able to produce the same sort of 
quick-fix libraries. The newsgroups are dominated by systems-type 
people and there is a serious emphasis on super-low-cost 
abstractions, but in my opinion D is a more than suitable 
language for throwing together something that just "does the 
job", but with much more pleasant routes for later optimisation 
than other languages.
Apr 29 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 29 April 2014 at 11:04:38 UTC, John Colvin wrote:

 My bet is that D users will be able to produce the same sort of 
 quick-fix libraries. The newsgroups are dominated by 
 systems-type people and there is a serious emphasis on 
 super-low-cost abstractions, but in my opinion D is a more than 
 suitable language for throwing together something that just 
 "does the job", but with much more pleasant routes for later 
 optimisation than other languages.


To a certain extent, but some things are just easier in a dynamic 
language. Like reading a xml file, then decorate the nodes with 
your own class attributes an properties, transform it and dump it 
back to file.

Sure, you can do it in a stricter languge, but only if the 
library author planned for it.
Apr 29 2014
prev sibling next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 2014-04-29 at 10:51 +0000, via Digitalmars-d wrote:
[…]

 I used the wrong term, I meant list comprehensions. The most 
 important feature in Python for me. I find it very powerful in 
 combination with tuples, lists and dicts.


Don't forget dictionary comprehensions and set comprehensions.

And definitely don't forget generator expressions.

And indeed generator functions.

[…]

 Yeah, except when you build a CMS, but you can always include a 
 scripting language.


Python vs Lua here. Photo-related C++ systems tend to drift to Lua for
scripting. Post-production effects C++ systems seem to rely on Python.

[…]

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Apr 29 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 29 April 2014 at 11:31:11 UTC, Russel Winder via 
Digitalmars-d wrote:

 Don't forget dictionary comprehensions and set comprehensions.


Yes, I use dict comprehensions a lot too. I have never used set 
comprehensions.


 And definitely don't forget generator expressions.


Actually, I do. :-) They are so transparent that they look like 
list comprehensions.


 Python vs Lua here. Photo-related C++ systems tend to drift to 
 Lua for
 scripting. Post-production effects C++ systems seem to rely on 
 Python.


I believe Inkscape uses C++, Boehm GC and Python, Blender uses 
C++ and Python…
Apr 29 2014
prev sibling parent "Meta" <jared771 gmail.com> writes:
On Tuesday, 29 April 2014 at 10:51:26 UTC, Ola Fosheim Grøstad 
wrote:

 For closures for arrays and dicts.


 I don't understand


 I used the wrong term, I meant list comprehensions. The most 
 important feature in Python for me. I find it very powerful in 
 combination with tuples, lists and dicts.


I think that list and dictionary comprehensions could be 
implemented with mixins fairly easily, but I haven't had a chance 
to test this theory yet.
Apr 29 2014
prev sibling parent reply "Kapps" <opantm2+spam gmail.com> writes:
On Monday, 28 April 2014 at 18:18:25 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 28 April 2014 at 18:07:45 UTC, John Colvin wrote:

 What features does python, as a language (syntactical 
 preferences aside), actually have to recommend it over D 
 (assuming drepl* or similar became full-featured)?


 Libraries.
 For closures for arrays and dicts.
 Tuples.
 Heavy duty reflection and runtime dynamics.
 (Runtime extensible classes.)
 (Runtime integration of python and templates.)
 System support (app engine, etc).
 Lots of how-to-stuff on the web.


D can actually do a rather good job of runtime reflection. I made 
a runtime reflection module 
(https://shardsoft.com/stash/projects/SHARD/repos/shardtools/browse/source/Sha
dTools/Reflection.d 
/ https://shardsoft.com/docs/ShardTools/Reflection.html) for my 
own personal code and it's served the uses I've needed it for 
quite nicely. Python I'd imagine has runtime reflection by 
default, but you could do this in D too by using RTInfo to 
automatically generate reflection data for every class. And while 
I'm sure Python has much more advanced reflection capabilities, I 
don't think the vast majority of users really require much more 
than the basics like looking up fields / invoking methods from 
user input, which D can easily handle. In the situations where 
you do need a completely dynamic type, people have already made 
such types in D by using opDispatch 
(http://forum.dlang.org/post/kuxfkakrgjaofkrdvgmx forum.dlang.org).

(I wouldn't recommend others to use my reflection module directly 
as it'll get breaking changes and probably has bugs, but it's 
Boost licensed so if anyone wanted to they could add relevant 
parts into their project. I think it's also responsible for very 
large executables on OSX/Linux, but not on Windows.)
Apr 28 2014
parent reply "Kagamin" <spam here.lot> writes:
On Monday, 28 April 2014 at 19:34:38 UTC, Kapps wrote:

 D can actually do a rather good job of runtime reflection. I 
 made a runtime reflection module 
 (https://shardsoft.com/stash/projects/SHARD/repos/shardtools/browse/source/Sha
dTools/Reflection.d 
 / https://shardsoft.com/docs/ShardTools/Reflection.html) for my 
 own personal code and it's served the uses I've needed it for 
 quite nicely.


Cool. Can it access private members?
Apr 29 2014
parent "Kapps" <opantm2+spam gmail.com> writes:
On Tuesday, 29 April 2014 at 14:50:38 UTC, Kagamin wrote:

 On Monday, 28 April 2014 at 19:34:38 UTC, Kapps wrote:

 D can actually do a rather good job of runtime reflection. I 
 made a runtime reflection module 
 (https://shardsoft.com/stash/projects/SHARD/repos/shardtools/browse/source/Sha
dTools/Reflection.d 
 / https://shardsoft.com/docs/ShardTools/Reflection.html) for 
 my own personal code and it's served the uses I've needed it 
 for quite nicely.


 Cool. Can it access private members?


Fields, but not methods.

Private methods is something I was thinking about, but the only 
way I can think of to do it would involve making the type use a 
mixin (which does make sense in a way). I haven't done any work 
on anything like this though, and it's not really high priority 
since fields work and I haven't needed anything else yet.
Apr 29 2014
prev sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 2014-04-28 at 18:07 +0000, John Colvin via Digitalmars-d wrote:
[…]

 What features does python, as a language (syntactical preferences 
 aside), actually have to recommend it over D (assuming drepl* or 
 similar became full-featured)? This is definitely not a 
 rhetorical question, it could be useful to D development.


Principally there are a large number of users and installation and there
is a wealth of support for different user bases from sys admins to
quants. Python is a relatively small language that is easy to learn. The
esoteric libraries can be a pain, but the core libraries do what they
say on the can and are easy to use with a simple syntax. People can
write working, tested code quickly without having to fight the fascist
intransigence of a compiler.

Most importantly though Python has penetration in the market so it is a
safe choice. This is reinforced by the quants driving "performance
Python" so that it can play in the CPU bound arena as well as the IO
bound arena of sys admins and Web-related stuff. Ian Oszvald and
co-author are just bringing a book to market about all this driven by
the needs of the "data scoence" community

This is as much about perception and marketing as about actual technical
features. There is also an element of Python evolving to fit with what
end-user programmers who aren't really programmers need. This is a
self-reinforcing feedback loop.

Python doesn't have a "killer app", it invaded programming on multiple
fronts to create a perception, and indeed reality, of all-pervasiveness
as a programming platform.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Apr 29 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Tuesday, 29 April 2014 at 11:28:07 UTC, Russel Winder via 
Digitalmars-d wrote:


 Principally there are a large number of users and installation 
 and there
 is a wealth of support for different user bases from sys admins 
 to
 quants. Python is a relatively small language that is easy to 
 learn. The
 esoteric libraries can be a pain, but the core libraries do 
 what they
 say on the can and are easy to use with a simple syntax. People 
 can
 write working, tested code quickly without having to fight the 
 fascist
 intransigence of a compiler.


As opposed to the fascist intransigence of the Python interpreter 
with its ridiculous indent-mania. Maybe you are only referring to 
static vs. dynamic typing. Be it a compiler or an interpreter, 
they are all inherently stubborn and fond of rules.

A D program can be written with the same ease as a Python 
program. It's up to the user to make it fancy or straight 
forward. I like the freedom of choice that ships with D.

[snip]
Apr 29 2014
parent reply "logicchains" <jonathan.t.barnard gmail.com> writes:
On Tuesday, 29 April 2014 at 13:05:34 UTC, Chris wrote:

 As opposed to the fascist intransigence of the Python 
 interpreter with its ridiculous indent-mania. Maybe you are 
 only referring to static vs. dynamic typing. Be it a compiler 
 or an interpreter, they are all inherently stubborn and fond of 
 rules.


As someone who only occasionally uses D and Python, I just wanted 
to add as a datapoint that I find the D compilers an order of 
magnitude more agreeable than the Python interpreter. The thought 
that anybody could actually enjoy significant whitespace baffles 
me.
Apr 29 2014
parent reply "Brian Rogoff" <brogoff gmail.com> writes:
On Tuesday, 29 April 2014 at 14:01:44 UTC, logicchains wrote:

 As someone who only occasionally uses D and Python, I just 
 wanted to add as a datapoint that I find the D compilers an 
 order of magnitude more agreeable than the Python interpreter. 
 The thought that anybody could actually enjoy significant 
 whitespace baffles me.


You must be perpetually perplexed then, because Haskell, Clean, 

signify indentation.

The argument is roughly like this: if we accept that it would be 
a good thing if there was a universal indentation/code formatting 
standard that everyone followed (like gofmt for Go) then 
punctuation is redundant and the remaining question is whether 
the added punctuation helps or hinders readability on the whole. 
I'm guessing you find the lack of punctuation to hinder 
readability. I find that the opposite is true, and so enjoy 
reading such code more.

I'm also a frequent user of Python and my main issue with it is 
the lack of static typing, not the syntax. I'm a rather slapdash 
coder and I benefit greatly from a type system that gets in my 
way. The same is true of most Lisps too; I'm fine with the 
syntax, but I suffer from the lack of static typing.

BTW, there is even a surface syntax for D2, 
https://github.com/pplantinga/delight, which uses indentation, 
though I have to say that I dislike the separation of function 
and procedure a lot.
Apr 29 2014
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/29/2014 1:05 PM, Brian Rogoff wrote:

 The argument is roughly like this: if we accept that it would be a good
 thing if there was a universal indentation/code formatting standard that
 everyone followed (like gofmt for Go) then punctuation is redundant and
 the remaining question is whether the added punctuation helps or hinders
 readability on the whole. I'm guessing you find the lack of punctuation
 to hinder readability. I find that the opposite is true, and so enjoy
 reading such code more.


The problem with the "standardized indentation" argument is that it's 
*impossible* for a language like python to enforce indentation rules. 
All it can do, and indeed all is *does* do, is blindly assume that the 
indentation as presented is correct and adheres to the universal style. 
If something is indented wrong, there is no enforcement, only bugs.

So there's definitely more to it than just whether a person finds 
non-whitespace syntax to help/hinder readability.
Apr 29 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 30 April 2014 at 01:46:21 UTC, Nick Sabalausky 
wrote:

 indentation rules. All it can do, and indeed all is *does* do, 
 is blindly assume that the indentation as presented is correct 
 and adheres to the universal style. If something is indented 
 wrong, there is no enforcement, only bugs.


Not blindly. Python will complain if the indentation does not 
make sense. I very seldom run into indentation issues now, but 
had some when I was new to Python. Just like C's syntax, it takes 
some time getting used to.
Apr 29 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Wednesday, 30 April 2014 at 06:12:24 UTC, Ola Fosheim Grøstad 
wrote:

 On Wednesday, 30 April 2014 at 01:46:21 UTC, Nick Sabalausky 
 wrote:

 indentation rules. All it can do, and indeed all is *does* do, 
 is blindly assume that the indentation as presented is correct 
 and adheres to the universal style. If something is indented 
 wrong, there is no enforcement, only bugs.


 Not blindly. Python will complain if the indentation does not 
 make sense. I very seldom run into indentation issues now, but 
 had some when I was new to Python. Just like C's syntax, it 
 takes some time getting used to.


Say you have a Python file with 500 lines of code. Try to copy 
and paste something with a different indentation from somewhere 
else into an if statement. You'll have to clean up before you can 
test the program. This kind of patronizing bullshit was invented 
for non-programmers who might make a mess of the code otherwise. 
Any programmer will structure and clean up the code once s/he's 
happy with it. Indentationists seem to assume that you cannot 
indent in C-style languages or if it is not prescribed, people 
will make a mess of it (which is patronizing fascist thinking).

In D you can do this:

if (mode == "TEST") {  // Second block added later
if (x == 1) {  // First block
  writeln("Hurray!");
}
}

In my opinion, this helps to test and bypass etc. things while 
debugging. Often I don't keep them, and if I do, I clean them up 
immediately as soon as I'm happy with it. In Python you have to 
clean up, even if it's just for 2 minutes of debugging / testing. 
Not to mention the nightmare of merging Python files with 
different indentation levels or styles (tab vs. space).
Apr 30 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 30 April 2014 at 08:52:48 UTC, Chris wrote:

 Say you have a Python file with 500 lines of code. Try to copy 
 and paste something with a different indentation from somewhere 
 else into an if statement.


Paste in non-formatting-mode and use the editor's ability to 
block indent? Having an editor that will indent/unindent regions 
when you hit tab/shift-tab helps.


 This kind of patronizing bullshit was invented for 
 non-programmers who might make a mess of the code otherwise.


It is true that Python grew out of a programming language 
tradition meant for teaching/prototyping.

But the Python syntax it is more useful for an interpreter prompt 
(REPL) than a syntax with explicit begin/end markers. Most of the 
non-trivial transformations I do start at the REPL before being 
pasted into the editor.


 In D you can do this:

 if (mode == "TEST") {  // Second block added later
 if (x == 1) {  // First block
  writeln("Hurray!");
 }
 }


I think Go did the right thing by not requiring the redundant 
parantheses on the if statement and perhaps also by allowing the 
omission of semicolons where appropriate etc. Room for improved 
legibility right there.

In Python I would probably use «TEST» rather than «mode=="test"»:

if TEST&& x == 1:
     …

Ola.
Apr 30 2014
next sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Wednesday, 30 April 2014 at 10:16:12 UTC, Ola Fosheim Grøstad 
wrote:

 On Wednesday, 30 April 2014 at 08:52:48 UTC, Chris wrote:

 Say you have a Python file with 500 lines of code. Try to copy 
 and paste something with a different indentation from 
 somewhere else into an if statement.


 Paste in non-formatting-mode and use the editor's ability to 
 block indent? Having an editor that will indent/unindent 
 regions when you hit tab/shift-tab helps.


Yes it helps, but a language's syntax / usability should not 
depend on tools like editors. Also, what if I want to use an 
editor that doesn't support all the fancy formatting stuff?


 This kind of patronizing bullshit was invented for 
 non-programmers who might make a mess of the code otherwise.


 It is true that Python grew out of a programming language 
 tradition meant for teaching/prototyping.

 But the Python syntax it is more useful for an interpreter 
 prompt (REPL) than a syntax with explicit begin/end markers. 
 Most of the non-trivial transformations I do start at the REPL 
 before being pasted into the editor.


 In D you can do this:

 if (mode == "TEST") {  // Second block added later
 if (x == 1) {  // First block
 writeln("Hurray!");
 }
 }


 I think Go did the right thing by not requiring the redundant 
 parantheses on the if statement and perhaps also by allowing 
 the omission of semicolons where appropriate etc. Room for 
 improved legibility right there.

 In Python I would probably use «TEST» rather than 
 «mode=="test"»:

 if TEST&& x == 1:


By this you change the substance of the if statement merely for 
test purposes, i.e.

if x == 1: > if TEST && x == 1:

which is not very elegant, and it's error prone (what if you 
overlook the TEST && bit for release?)

In my D example you leave the essential part untouched. On top of 
that, the fact that to if statements are at the same indentation 
level makes it easier to spot that there is something unusual 
going on there.
Apr 30 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 30 April 2014 at 10:56:22 UTC, Chris wrote:

 which is not very elegant, and it's error prone (what if you 
 overlook the TEST && bit for release?)


I'd probably tie it to DEBUG and make sure it has the correct 
value whenever DEBUG is false. No need to remove it before 
release.

Ola.
Apr 30 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Wednesday, 30 April 2014 at 14:57:44 UTC, Ola Fosheim Grøstad 
wrote:

 On Wednesday, 30 April 2014 at 10:56:22 UTC, Chris wrote:

 which is not very elegant, and it's error prone (what if you 
 overlook the TEST && bit for release?)


 I'd probably tie it to DEBUG and make sure it has the correct 
 value whenever DEBUG is false. No need to remove it before 
 release.

 Ola.


I think it is not feasible to tie everything to DEBUG. Debug is a 
signpost that marks well-defined "problem zones". Often I need 
just a little writefln() statement somewhere in the code to see 
what is going on / wrong in a certain block. The simplest example 
is to insert writeln() simply to see up to which point it prints 
before the app crashes. Believe it or not, I find this technique 
very efficient in certain situations.
Python often gets in my way when micro-debugging in this way, 
because of indentation terror.
Apr 30 2014
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/30/2014 11:59 AM, Chris wrote:

 The simplest example is to insert
 writeln() simply to see up to which point it prints before the app
 crashes. Believe it or not, I find this technique very efficient in
 certain situations.


I do that all the time. :)


 Python often gets in my way when micro-debugging in this way, because of
 indentation terror.
Apr 30 2014
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/30/2014 6:16 AM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Wednesday, 30 April 2014 at 08:52:48 UTC, Chris wrote:

 In D you can do this:

 if (mode == "TEST") {  // Second block added later
 if (x == 1) {  // First block
  writeln("Hurray!");
 }
 }




Yea, I do that all the time for debugging...*deliberately* since it 
makes it trivial to spot the temporary testing code. A language 
shouldn't get in my way just because it made a false assumption about my 
workflow.


 I think Go did the right thing by not requiring the redundant
 parantheses on the if statement and perhaps also by allowing the
 omission of semicolons where appropriate etc. Room for improved
 legibility right there.


Personally, I find Go's reduced parens and such to make it noticeably 
harder to read. There's less for my eyes to lock onto when visually 
parsing/scanning. YMMV of course.
Apr 30 2014
parent "Chris" <wendlec tcd.ie> writes:
On Wednesday, 30 April 2014 at 11:46:32 UTC, Nick Sabalausky 
wrote:

 On 4/30/2014 6:16 AM, "Ola Fosheim Grøstad" 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Wednesday, 30 April 2014 at 08:52:48 UTC, Chris wrote:

 In D you can do this:

 if (mode == "TEST") {  // Second block added later
 if (x == 1) {  // First block
 writeln("Hurray!");
 }
 }




 Yea, I do that all the time for debugging...*deliberately* 
 since it makes it trivial to spot the temporary testing code. A 
 language shouldn't get in my way just because it made a false 
 assumption about my workflow.


Yep. Good to know I'm not the only one who does this all the time 
:-)


 I think Go did the right thing by not requiring the redundant
 parantheses on the if statement and perhaps also by allowing 
 the
 omission of semicolons where appropriate etc. Room for improved
 legibility right there.


 Personally, I find Go's reduced parens and such to make it 
 noticeably harder to read. There's less for my eyes to lock 
 onto when visually parsing/scanning. YMMV of course.
Apr 30 2014
prev sibling parent reply "logicchains" <jonathan.t.barnard gmail.com> writes:
On Tuesday, 29 April 2014 at 17:05:50 UTC, Brian Rogoff wrote:

 You must be perpetually perplexed then, because Haskell, Clean, 

 signify indentation.



bothersome because the static type systems catch most of the 
mistakes at compile time that would occur in Python. Haskell also 
allows optional braces instead of whitespace (whitespace is just 
syntactic sugar for braces), which can be quite useful at times, 
especially when copying code.
Apr 30 2014
parent reply "Brian Rogoff" <brogoff gmail.com> writes:
On Wednesday, 30 April 2014 at 11:41:29 UTC, logicchains wrote:

 On Tuesday, 29 April 2014 at 17:05:50 UTC, Brian Rogoff wrote:

 You must be perpetually perplexed then, because Haskell, 

 whiitespace to signify indentation.



 bothersome because the static type systems catch most of the 
 mistakes at compile time that would occur in Python. Haskell 
 also allows optional braces instead of whitespace (whitespace 
 is just syntactic sugar for braces), which can be quite useful 
 at times, especially when copying code.


Right, it's not the significant indentation which perplexes you, 
but the complete lack of compile time checking from Python. I'm 
perplexed that anyone could prefer that too, but I suppose those 
programmers who are way smarter than me and don't make any 
mistakes find types burdensome, or are always writing correct 
code that can't be type checked by any current checker.
Apr 30 2014
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2014-04-30 at 16:38 +0000, Brian Rogoff via Digitalmars-d wrote:
[…]

 Right, it's not the significant indentation which perplexes you, 
 but the complete lack of compile time checking from Python. I'm 
 perplexed that anyone could prefer that too, but I suppose those 
 programmers who are way smarter than me and don't make any 
 mistakes find types burdensome, or are always writing correct 
 code that can't be type checked by any current checker.


I believe it is not that at all. Writing code using a dynamic language
is a totally different mind set to working with a static language, even
if many similar code idioms appear to be being used. Further, the sort
of errors that are common in the two varieties of language are very
different. Writing code in Groovy, which is an optionally typed dynamic
language and a statically typed language, is a really interesting
playground for tinkering with many of these ideas, and is confirming to
me that I have a totally different approach to programming when using
Python than when using D, C++ or Go.

Python has just one type of variable, reference to object, which is
reasonable since although all objects have a type, there is no guarantee
of any "interface" to an instance given the type label. Except for the
primitive value types, the type of an object only tells you which class
was the originating creator; everything else is malleable. In this
context compile type type checking is an irrelevance.

With D (and Go and C++) variables are typed as are values and it makes
sense for there to be static type checking and programmers can rely on
the results of compilation. OK so Go blurs the edges a bit with its
interface types and the fact that there are no classes, all methods are
extension methods, but this turn out to be a really interesting way of
working. In Go. The idioms of Go do not apply to D and C++.

So it all really comes down to whether an individual can be comfortable
in the mindset associated with the language.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Apr 30 2014
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 30 April 2014 at 17:05:54 UTC, Russel Winder via 
Digitalmars-d wrote:

 I believe it is not that at all. Writing code using a dynamic 
 language
 is a totally different mind set to working with a static 
 language, even
 if many similar code idioms appear to be being used.


I kind of agree, but as you pointed out (with Go): no language is 
  really static, but a point in a design space.

You still get runtime errors.
You still get values out of bounds.
So both Python and D are on the same scale.

And they are both less "strict" than a functional language with 
heavy duty type constraints and formal proof mechanisms.


 The idioms of Go do not apply to D and C++.


I think the issues I am having with Go is that it hasn't quite 
found the idioms that work best yet. So libraries are a bit 
lacking in terms of usability IMO.

You can probably say the same about D, even though it draws 
heavily on C++. Perhaps drawing on C++ is holding it back too.

Time will show.

Ola.
Apr 30 2014
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/30/2014 1:05 PM, Russel Winder via Digitalmars-d wrote:

 On Wed, 2014-04-30 at 16:38 +0000, Brian Rogoff via Digitalmars-d wrote:
 […]

 Right, it's not the significant indentation which perplexes you,
 but the complete lack of compile time checking from Python. I'm
 perplexed that anyone could prefer that too, but I suppose those
 programmers who are way smarter than me and don't make any
 mistakes find types burdensome, or are always writing correct
 code that can't be type checked by any current checker.


 I believe it is not that at all. Writing code using a dynamic language
 is a totally different mind set to working with a static language,


I've heard this a lot, but I've yet to hear anyone explain concretely 
how this "dynamic mindset" causes the lack of things like static code 
checks and low-overhead primitives from being actual drawbacks. Maybe it 
really is a case of me not "getting it", but it always sounds to me like 
this "dynamic mindset" gets around these issues simply by ignoring them. 
Since I don't personally do heavy development in dynamic languages, I'd 
be interested in a strong rebuttal to this.
Apr 30 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 30 April 2014 at 19:21:25 UTC, Nick Sabalausky 
wrote:

 I've heard this a lot, but I've yet to hear anyone explain 
 concretely how this "dynamic mindset" causes the lack of things 
 like static code checks and low-overhead primitives from being 
 actual drawbacks. Maybe it really is a case of me not "getting


I think you see it in Java too?

Restricting dicts and arrays to a single element type requires 
more complicated logic in some cases.

People don't write Rpython, which is a strictly typed subset of 
Python,  because they have to write more complicated logic?

I could probably live with the Rpython subset, though.
Apr 30 2014
parent "Kagamin" <spam here.lot> writes:
On Wednesday, 30 April 2014 at 19:28:24 UTC, Ola Fosheim Grøstad 
wrote:

 Restricting dicts and arrays to a single element type requires 
 more complicated logic in some cases.


How you would handle elements of unexpected type in those arrays? 
What if mishandling is silent and causes a heisenbug? We had it 
and killed untyped arrays with fire, then breathed with a relief.
May 05 2014
prev sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2014-04-30 at 15:21 -0400, Nick Sabalausky via Digitalmars-d
wrote:
[…]

 I've heard this a lot, but I've yet to hear anyone explain concretely 
 how this "dynamic mindset" causes the lack of things like static code 
 checks and low-overhead primitives from being actual drawbacks. Maybe it 
 really is a case of me not "getting it", but it always sounds to me like 
 this "dynamic mindset" gets around these issues simply by ignoring them. 
 Since I don't personally do heavy development in dynamic languages, I'd 
 be interested in a strong rebuttal to this.


The best way of approaching this is not to try and attempt a long
theoretical essay, but to try (a possibly lengthy exchange of question
and answer accompanied by actually writing code in both Python and D.
Also looking at things like Rosettacode and all Bearophile and others'
work there.

There are two questions above to kick start things, let's take the
second first:

Low-overhead primitives: This immediately implies you are looking for
raw CPU-bound performance or you are undertaking premature optimization.
Python has no direct "play" in this game. If a Python code requires out
and out CPU-bound performance, you profile to find the small bit of the
total code that is performance critical. If it is not already a function
you extract it as a function, put it in it's own module and Cythonize it
(*). Still Python code but with a few judicious extra annotations so as
to enable Cython to generate C which is then compiled to native code.

Static code checks: The object (aka data) model, and variable model of
Python (and indeed other dynamic languages) means there cannot be any
static code checks. At this point, I have to yield (in this co-routine
exchange :-) with a question: what is it about static code checks that
you feel you have to have in order to be able to program?


(*) There are other techniques, but this is the lowest overhead in terms
of programmer time, and it gives excellent runtime speed-up.
-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Apr 30 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Thursday, 1 May 2014 at 06:04:57 UTC, Russel Winder via 
Digitalmars-d wrote:

 On Wed, 2014-04-30 at 15:21 -0400, Nick Sabalausky via 
 Digitalmars-d
 wrote:
 […]

 I've heard this a lot, but I've yet to hear anyone explain 
 concretely how this "dynamic mindset" causes the lack of 
 things like static code checks and low-overhead primitives 
 from being actual drawbacks. Maybe it really is a case of me 
 not "getting it", but it always sounds to me like this 
 "dynamic mindset" gets around these issues simply by ignoring 
 them. Since I don't personally do heavy development in dynamic 
 languages, I'd be interested in a strong rebuttal to this.


 The best way of approaching this is not to try and attempt a 
 long
 theoretical essay, but to try (a possibly lengthy exchange of 
 question
 and answer accompanied by actually writing code in both Python 
 and D.
 Also looking at things like Rosettacode and all Bearophile and 
 others'
 work there.

 There are two questions above to kick start things, let's take 
 the
 second first:

 Low-overhead primitives: This immediately implies you are 
 looking for
 raw CPU-bound performance or you are undertaking premature 
 optimization.
 Python has no direct "play" in this game. If a Python code 
 requires out
 and out CPU-bound performance, you profile to find the small 
 bit of the
 total code that is performance critical. If it is not already a 
 function
 you extract it as a function, put it in it's own module and 
 Cythonize it
 (*). Still Python code but with a few judicious extra 
 annotations so as
 to enable Cython to generate C which is then compiled to native 
 code.


In my experience the problems with this approach are as follows:

1. The workflow: you write Python code, then profile it, extract 
the bottlenecks and then compile them to native code. A lot of 
overhead.
2. It can soon become messy when the code is changed, and there's 
a mess of different technologies applied over the years (Swig, 
Cython and whatnot).

In my opinion it's cleaner to write a project in D (C/C++). Code 

 native, in one go. I always feel uneasy, when I have to bring 


in third party software (i.e. a blackbox) to boost the 
performance of my code. I accept that, if you already have a 
substantial code base in Python, technologies like Cython are the 
way to go. But when I start a new project, why on earth should I 
go down that rocky path again?


 Static code checks: The object (aka data) model, and variable 
 model of
 Python (and indeed other dynamic languages) means there cannot 
 be any
 static code checks. At this point, I have to yield (in this 
 co-routine
 exchange :-) with a question: what is it about static code 
 checks that
 you feel you have to have in order to be able to program?


 (*) There are other techniques, but this is the lowest overhead 
 in terms
 of programmer time, and it gives excellent runtime speed-up.
May 01 2014
parent reply "Suliman" <evermind live.ru> writes:
Here on Forum I had found 2 interesting link. I decided to put 
it's here. Maybe it would be helpful
http://codegolf.stackexchange.com/questions/26323/how-slow-is-python-really-or-how-fast-is-your-language
http://codegolf.stackexchange.com/questions/26371/how-slow-is-python-really-part-ii
May 04 2014
parent "bearophile" <bearophileHUGS lycos.com> writes:
Suliman:

 Here on Forum I had found 2 interesting link. I decided to put 
 it's here. Maybe it would be helpful
 http://codegolf.stackexchange.com/questions/26323/how-slow-is-python-really-or-how-fast-is-your-language
 http://codegolf.stackexchange.com/questions/26371/how-slow-is-python-really-part-ii


See:
http://forum.dlang.org/thread/pvojsrqmaksqwokuekhk forum.dlang.org

Bye,
bearophile
May 04 2014
prev sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Monday, 28 April 2014 at 09:27:33 UTC, John Colvin wrote:

 On Monday, 28 April 2014 at 09:10:53 UTC, Chris wrote:

 On Thursday, 24 April 2014 at 06:38:42 UTC, Suliman wrote:

 I am following discussions about GC and some other 'critical' 
 improves in D language for a long time. I see a lot of 
 arguments and heaps of code, that often hard to understand 
 (for example Templates) even more complicated to use it.

 I like D, but more and more I am playing with Python, and 
 understanding it's philosophy. And I like it because it's do 
 not have any overhead like C++. It's clean any easy to 
 understanding. As result it's harder to write bad code in it.

 Does anybody make tests of speed most common algorithm in D 
 and Python. I am trying to understand which project better to 
 start in Python and which in D.


 In my experience, it is better to start a new project with D, 
 not only because of speed. As a project grows, the 
 restrictions of Python become more apparent (and annoying). If 
 copyright is an issue, D is the better option, too. Python can 
 be decompiled easily. I don't know what kind of projects you 
 have in mind, but in our projects Python is always the 
 bottleneck and has to be rewritten in a different language 
 anyway, sooner or later.


 My experience mirrors this exactly. I find Python quite quickly 
 becomes unwieldy for large projects, even if the performance is 
 not an issue.

 As with all these things, YMMV; there are many large, 
 successful Python projects.


 It is pretty good for interactive work, especially if you can 
 leverage the large body of work that the scientific community 
 has produced in python.


Yeah, Python is good for fast prototyping, that's why the 
scientific community uses it. However, when it comes to using the 
code for real world apps, you have to rewrite it in C/C++ or D 
(or the like).


 Choosing between D and Python:

 Pretty much anything written in pure Python can be easily 
 demolished by D in terms of performance.

 D doesn't have much provision for interactive work (work in 
 progress).

 You can do 2-way communication between D and Python 
 (https://bitbucket.org/ariovistus/pyd)

 Fast algorithms that you use in Python are often implemented in 
 C as extensions. D can call C code directly. C vs D is very 
 much splitting hairs when it comes to performance.


This is true, and this is one of the arguments I use, when it 
comes to rewriting code in D, i.e. that D can interface 
_directly_ to those libraries anyway.


 D has a steeper learning curve, but it will teach you widely 
 applicable knowledge and skills.


And you can write sound code in D without templates and ranges 
etc, if you don't understand the concepts yet. Once you 
understand them, you can soup up your code with all the fancy 
stuff.
Apr 28 2014
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 2014-04-28 at 09:43 +0000, Chris via Digitalmars-d wrote:
[…]

 Yeah, Python is good for fast prototyping, that's why the 
 scientific community uses it. However, when it comes to using the 
 code for real world apps, you have to rewrite it in C/C++ or D 
 (or the like).


Why?

Many people use Python codes in the real world quite happily, there is
no necessity to rewrite at all.

[…]

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Apr 28 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Monday, 28 April 2014 at 13:26:51 UTC, Russel Winder via 
Digitalmars-d wrote:

 On Mon, 2014-04-28 at 09:43 +0000, Chris via Digitalmars-d 
 wrote:
 […]

 Yeah, Python is good for fast prototyping, that's why the 
 scientific community uses it. However, when it comes to using 
 the code for real world apps, you have to rewrite it in C/C++ 
 or D (or the like).


 Why?

 Many people use Python codes in the real world quite happily, 
 there is
 no necessity to rewrite at all.

 […]


E.g. an algorithm for signal processing. Python is fine for 
prototyping, but if you want your algorithms to work in a real 
world app at real time, you'll have to rewrite it in C/C++, D or 
whatever. I've adopted the policy (where ever applicable) to use 
D straight away. It's just not worth it to develop something in 
Python and rewrite it in D later. I don't see the benefits of 
writing in Python, only drawbacks in the long run.
Apr 28 2014
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 2014-04-28 at 14:15 +0000, Chris via Digitalmars-d wrote:
[…]

 E.g. an algorithm for signal processing. Python is fine for 
 prototyping, but if you want your algorithms to work in a real 
 world app at real time, you'll have to rewrite it in C/C++, D or 
 whatever. I've adopted the policy (where ever applicable) to use 
 D straight away. It's just not worth it to develop something in 
 Python and rewrite it in D later. I don't see the benefits of 
 writing in Python, only drawbacks in the long run.


Certainly for signal processing algorithms where speed, concurrency and
parallelism are orders of the day, I would choose D or Go from the
outset. I wouldn't choose to use Python for this, but many people do,
including the folk I am off to do a Python workshop for in a couple of
weeks. Their environment is one in which Python is the only option (long
story), so they write in Python and then optimize by using Cython on the
CPU intensive codes. This actually works very well for them.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Apr 28 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 28 April 2014 at 16:22:47 UTC, Russel Winder via 
Digitalmars-d wrote:

Their environment is one in which Python is the only
 option (long
 story), so they write in Python and then optimize by using 
 Cython on the
 CPU intensive codes. This actually works very well for them.


Don't forget that pypy compiles rpython to C or llvm.
Apr 28 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Monday, 28 April 2014 at 17:28:16 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 28 April 2014 at 16:22:47 UTC, Russel Winder via 
 Digitalmars-d wrote:

Their environment is one in which Python is the only
 option (long
 story), so they write in Python and then optimize by using 
 Cython on the
 CPU intensive codes. This actually works very well for them.


 Don't forget that pypy compiles rpython to C or llvm.


But all of the above are extra steps you have to take and are not 
really Python anymore. You depend on 3rd party software to tune 
your code. With D I have full control over my code from the 
start. Cython and the like can introduce their own little 
problems. Another layer of complexity. Another black box.

If you have a nice algorithm that really improves the program and 
then you hear "Well, it takes about 4-10 seconds, it's written in 
Python", then you go "Arrgghhh!" Cython can help to speed things 
up, but you have little control over what is going on. So why not 
craft your own custom code in C or D whenever possible?
Apr 28 2014
parent reply "Chris" <wendlec tcd.ie> writes:
My point is basically: a lot of projects / modules start out as 
little helper functions, prototypes or proofs-of-concept, but 
grow bigger very fast. Especially in the scientific community 
Python is popular because one can protoype very fast, test things 
etc. However, as the code base grows it becomes more and more 
obvious that Python is too slow and doesn't scale very well. I 
always say that if you have good code, think production and 
deployment, choose a systems programming language, it will pay in 
the end. Because the headaches you will have later with 
Python/Cython, will outweigh the initial advantages of "fast 
development". (I think it's better to develop a tad slowlier and 
consider various options for and aspects of a program than to 
have a quick success, but a solid mess. A lot has to do with 
impatience, not only deadlines).
Apr 28 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Chris:


 Especially in the scientific community Python is popular 
 because one can protoype very fast, test things etc. However, 
 as the code base grows it becomes more and more obvious that 
 Python is too slow and doesn't scale very well.


Julia seems to be gaining many users, it's a language that is 
growing very fast, it's already usable despite being rather 
young. The number of its major design mistakes seems small (like 
arrays indexing not starting from 0, and few other things).

Bye,
bearophile
Apr 28 2014
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 28.04.2014 22:31, schrieb bearophile:

 Chris:


 Especially in the scientific community Python is popular because one
 can protoype very fast, test things etc. However, as the code base
 grows it becomes more and more obvious that Python is too slow and
 doesn't scale very well.


 Julia seems to be gaining many users, it's a language that is growing
 very fast, it's already usable despite being rather young. The number of
 its major design mistakes seems small (like arrays indexing not starting
 from 0, and few other things).

 Bye,
 bearophile


Pascal expatriates like myself won't consider indexes from 1 a design 
mistake. :)

--
Paulo
Apr 28 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Paulo Pinto:


 Pascal expatriates like myself won't consider indexes from 1 a 
 design mistake. :)


What's the good of having all arrays always start from index 1 
(this is different from Ada, where you can choose the indexing 
range and type)?

Bye,
bearophile
Apr 28 2014
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/28/2014 6:31 PM, bearophile wrote:

 Paulo Pinto:


 Pascal expatriates like myself won't consider indexes from 1 a design
 mistake. :)


 What's the good of having all arrays always start from index 1 (this is
 different from Ada, where you can choose the indexing range and type)?


VB6 let you choose your starting index, too. It was rarely useful and 
constantly made array-handling code a pain in the ass. Of course, VB 
made pretty much everything a PITA...(I used to work at a VB6 house. 
*shudder*)
Apr 28 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Nick Sabalausky:


 VB6 let you choose your starting index, too. It was rarely 
 useful and constantly made array-handling code a pain in the 
 ass. Of course, VB made pretty much everything a PITA...(I used 
 to work at a VB6 house. *shudder*)


(As far as I know, and I am ignorant about Julia) in Julia you 
can't choose the start index of an array, they start from index 
1. So the situation is not the same as VB.

I have written more Delphi code than D code, and I've seen that 
being able to choose the index range is quite useful, you can use 
enumerations and characters to index arrays :-) You avoid "c - 
'0'" the idiom used in D, and associative arrays with enum keys, 
while keeping the code very efficient and generally not bug-prone.

I don't know VB much, but all language features should not be 
abused. And they work or fail not just being good themselves, but 
in the context (and ecology) of all other features of a language. 
This means choosing arrays index types and start values is very 
good in Ada, it's rarely a PITA. But perhaps a similar feature is 
not good if used in VB. Ada has a very strong static typing, so 
being able to specify array index types gives you back lot of 
safety that probably is not available in VB. So the return of 
investment is probably different.

I think it could be a good idea to add something intermediate to 
D: optional strong typing for array indexing. I'd like to write a 
DIP on this someday (note that this does not mean I am suggesting 
D array indexes to optionally start from values different from 0. 
I am referring just to types, and enumerations are could be not 
supported).

Bye,
bearophile
Apr 28 2014
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/28/2014 7:02 PM, bearophile wrote:

 Nick Sabalausky:


 VB6 let you choose your starting index, too. It was rarely useful and
 constantly made array-handling code a pain in the ass. Of course, VB
 made pretty much everything a PITA...(I used to work at a VB6 house.
 *shudder*)


 (As far as I know, and I am ignorant about Julia) in Julia you can't
 choose the start index of an array, they start from index 1. So the
 situation is not the same as VB.

 I have written more Delphi code than D code, and I've seen that being
 able to choose the index range is quite useful, you can use enumerations
 and characters to index arrays :-) You avoid "c - '0'" the idiom used in
 D, and associative arrays with enum keys, while keeping the code very
 efficient and generally not bug-prone.

 I don't know VB much, but all language features should not be abused.
 And they work or fail not just being good themselves, but in the context
 (and ecology) of all other features of a language. This means choosing
 arrays index types and start values is very good in Ada, it's rarely a
 PITA. But perhaps a similar feature is not good if used in VB. Ada has a
 very strong static typing, so being able to specify array index types
 gives you back lot of safety that probably is not available in VB. So
 the return of investment is probably different.


Yea. To be perfectly fair, "classic" VB made pretty much anything a 
pain. I imagine a better language could probably manage custom index 
ranges much better than VB6 did.

In VB6, it was a pain because of iterating over the elements. Since it 
lacked anything like foreach (as I recall), the simplest "iterate over 
an array" was something like (from memory, might not have it exact):

FOR index = 0 TO Len(myArray)

*But* that code was wrong. It would *usually* work, and then suddenly 
blow up whenever someone used a different starting index. So instead, it 
was best to use this syntactic mess every time you iterated:

FOR index = LBound(myArray) TO UBound(myArray)

Ugh, I don't miss VB. Worse still, it was so "simple" it encouraged 
companies (like the one where I worked) to use "programmers" who were 
absolute bottom-level and wrote the WORST code. I saw shit at that job 
that (I'm not exaggerating here) even CS 101 students know not to do. It 
was amazing any of our codebase even worked at all.

Back to the point though, having never looked at Julia, I assume it 
probably does a much better job of this stuff than VB did.
Apr 29 2014
prev sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Monday, 28 April 2014 at 23:02:03 UTC, bearophile wrote:

 I think it could be a good idea to add something intermediate 
 to D: optional strong typing for array indexing. I'd like to 
 write a DIP on this someday (note that this does not mean I am 
 suggesting D array indexes to optionally start from values 
 different from 0. I am referring just to types, and 
 enumerations are could be not supported).

 Bye,
 bearophile


Any reason why this needs language support? I haven't tried it, 
but I can't see why it can't be trivially done in a library.
Apr 29 2014
next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 29 April 2014 at 08:21:04 UTC, John Colvin wrote:

 On Monday, 28 April 2014 at 23:02:03 UTC, bearophile wrote:

 I think it could be a good idea to add something intermediate 
 to D: optional strong typing for array indexing. I'd like to 
 write a DIP on this someday (note that this does not mean I am 
 suggesting D array indexes to optionally start from values 
 different from 0. I am referring just to types, and 
 enumerations are could be not supported).

 Bye,
 bearophile


 Any reason why this needs language support? I haven't tried it, 
 but I can't see why it can't be trivially done in a library.


Pascal example:

type
   colors = (red, blue, yellow);

var
   pallete : array colors of integer;

begin
  pallete[red] := 4;
end



You want a compiler error if the index is invalid and bounds 
checking when iterating over the enumeration and using it as 
indexes.

Probably possible with some heavy duty compile time 
metaprogramming, not sure about the quality of possible error 
messages and if it would cover all scenarios Pascal and Ada allow 
for.

--
Paulo
Apr 29 2014
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
John Colvin:


 Any reason why this needs language support? I haven't tried it, 
 but I can't see why it can't be trivially done in a library.


I don't yet know the answer. I have to think more about the 
topic, and to try to implement something in library code. And 
then I can judge (a bit) if the result is good enough.

In D there are things that can be implemented well enough in 
library code (tensors). And we don't yet know if other things can 
be implemented well enough in D library code (like Typedef, or 
Algebric: 
http://forum.dlang.org/thread/olpznzscwiqdysfqvydb forum.dlang.org 
  Currently Algebraic is not acceptable). And then there are 
things that now we know cannot be implemented acceptably well in 
D library code (like Phobos tuples, that lack essential features 
like unpacking in some different contexts. See Rust for an 
example of simple and reasonably designed built-in tuples: 
http://rustbyexample.github.io/examples/tuples/README.html ).

For D programmers to invest in the usage of (optionally) strongly 
typed array indexing in their medium-integrity D programs (you 
can avoid using that indexing style in script-like D programs), 
such feature has to return them some valuable advantages. This 
means this feature should increase compile-time safety and offer 
a rich enough semantics. Otherwise it's a waste of time for the 
people that implement it, because D programmers (rightfully) will 
not use it.

If you look at Ada, where this feature is more developed, you see 
some semantics that could be not so trivial to reproduce in D 
library code.

Time ago I have suggested to add to D "enum preconditions" that 
in theory can be used in library code to better implement some of 
the static semantics of similar data structures.

Bye,
bearophile
Apr 29 2014
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 28 April 2014 at 22:31:58 UTC, bearophile wrote:

 Paulo Pinto:


 Pascal expatriates like myself won't consider indexes from 1 a 
 design mistake. :)


 What's the good of having all arrays always start from index 1 
 (this is different from Ada, where you can choose the indexing 
 range and type)?

 Bye,
 bearophile


True, in Pascal languages you can choose the starting index.
Apr 28 2014
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Monday, 28 April 2014 at 22:31:58 UTC, bearophile wrote:

 What's the good of having all arrays always start from index 1 
 (this is different from Ada, where you can choose the indexing 
 range and type)?


I'd say, for a math-oriented language starting position 1 is more 
meaningful than starting offset 0, the latter is an idiom for 
system programming language, the former better corresponds to 
mathematical formalism.
Apr 29 2014
parent reply "logicchains" <jonathan.t.barnard gmail.com> writes:
On Tuesday, 29 April 2014 at 14:53:48 UTC, Kagamin wrote:

 I'd say, for a math-oriented language starting position 1 is 
 more meaningful than starting offset 0, the latter is an idiom 
 for system programming language, the former better corresponds 
 to mathematical formalism.


An argument for zero-based indexing from Dijkstra: 
https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html
Apr 29 2014
parent "Kagamin" <spam here.lot> writes:
On Tuesday, 29 April 2014 at 14:59:25 UTC, logicchains wrote:

 An argument for zero-based indexing from Dijkstra: 
 https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html


Well, indeed, it's impossible to select an empty subrange with 
convention c (pascal?). Is it a problem? Simply use null instead 
of an empty range.
Apr 30 2014