April 29, 2014
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.
April 29, 2014
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/ShardTools/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?
April 29, 2014
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.
April 29, 2014
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
April 29, 2014
On Tuesday, 29 April 2014 at 10:51:26 UTC, Ola Fosheim Grøstad wrote:
>>> For closures for arrays and dicts.
>> I don't understand
>
> I used the wrong term, I meant list comprehensions. The most important feature in Python for me. I find it very powerful in combination with tuples, lists and dicts.

I think that list and dictionary comprehensions could be implemented with mixins fairly easily, but I haven't had a chance to test this theory yet.
April 29, 2014
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.
April 30, 2014
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.

April 30, 2014
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.
April 30, 2014
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/ShardTools/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.
April 30, 2014
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).