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 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 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 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 next sibling parent "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
prev sibling 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 next sibling parent "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
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 "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 "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 "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next 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.

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
prev sibling next 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 "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 next 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
next sibling 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 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 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 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
next sibling parent 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
prev sibling 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 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
prev sibling next sibling parent "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
prev sibling next sibling parent 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
prev sibling next sibling parent "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
prev sibling next sibling parent 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
prev sibling next sibling parent "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
prev sibling next sibling parent 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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.

I don't see anything particularly special about python's standard library).
 For closures for arrays and dicts.

 Tuples.

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.

abilities of D. Perhaps I'm just not that imaginative with my runtime introspections.
 (Runtime extensible classes.)

opDispatch. This would be an interesting little project.
 (Runtime integration of python and templates.)

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

 Lots of how-to-stuff on the web.

Apr 28 2014
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
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 next sibling parent "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
prev sibling 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 next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 28 April 2014 at 18:45:54 UTC, John Colvin wrote:
 Libraries.

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


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.


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
prev sibling next sibling parent "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.

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


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.


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
prev sibling next sibling 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 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
prev sibling next sibling parent 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
prev sibling next 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 "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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next 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 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 next sibling parent "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, F#, Nimrod and many other languages also use whiitespace to 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
prev sibling next sibling parent "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
prev sibling next sibling 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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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, 
 F#, Nimrod and many other languages also use whiitespace to 
 signify indentation.

I suppose I haven't found the whitespace in Haskell and F# so 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
prev sibling next sibling 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 next sibling 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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, 
 Clean, F#, Nimrod and many other languages also use 
 whiitespace to signify indentation.

I suppose I haven't found the whitespace in Haskell and F# so 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
prev sibling next sibling parent 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
prev sibling 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 next sibling parent "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
prev sibling next sibling parent 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
prev sibling next sibling parent "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 

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
prev sibling next sibling parent "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
prev sibling next sibling 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 "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