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

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.

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.

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.

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

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.

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

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

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.