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.

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

On Monday, 28 April 2014 at 18:45:54 UTC, John Colvin wrote:
>> Libraries.
> not part of the language (unless you count the standard library. I don't see anything particularly special about python's standard library).

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

>> For closures for arrays and dicts.
> I don't understand

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

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

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

>> (Runtime integration of python and templates.)
> I presume you mean web templates?

That is the most common scenario.

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

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

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

>> Lots of how-to-stuff on the web.
> Ditto

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

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

On Tuesday, 29 April 2014 at 10:51:26 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 28 April 2014 at 18:45:54 UTC, John Colvin wrote:
>>> Libraries.
>> not part of the language (unless you count the standard library. I don't see anything particularly special about python's standard library).
>
> Hmm… I think that for Python, Ruby and Perl, the libraries and the ecosystems to a large extent are part of the language. And I think the lack of C-like efficiency in the language encourage that, e.g. you don't really care that much about a library being 50% faster/slower. You care primarily about getting the job done. Not so with C/C++ libraries…
>
>>> For closures for arrays and dicts.
>> I don't understand
>
> I used the wrong term, I meant list comprehensions. The most important feature in Python for me. I find it very powerful in combination with tuples, lists and dicts.
>
>> improvements. It's surprising how much python-style tuple code you can do in D already, but the syntax is a little lacking.
>
> But for tuples the ease-of-use syntax is important, otherwise you can just use struct or some other aggregate. Tuples are often used as anonymous on-the-fly structs.
>
>>> (Runtime integration of python and templates.)
>> I presume you mean web templates?
>
> That is the most common scenario.
>
>> This is a strong point in favour of an interpreted language, although the compile-time approach in vibe.d is powerful. As long as the code doesn't change too often, you can always recompile it and load as a shared library (I believe this is being looked at by vibe.d developers).
>
> Yeah, except when you build a CMS, but you can always include a scripting language.
>
> However, given the trade offs I still think I would prefer static typing (such as D) because runtime errors tend to show up after release. (Assuming fast on-the-fly compilation which is a must-have for web development.)
>
>>> Lots of how-to-stuff on the web.
>> Ditto
>
> Actually,  I think it is part of the language's resulting eco system.
>
> I believe "toolbox" languages like Python and Perl will have more recipes and "nimble quick fix libraries" on the web than application languages.

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

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.

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

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

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

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…

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]