Nick Sabalausky wrote:
> "bearophile" <bearophileHUGS@lycos.com> wrote in message news:gbg5hu$189f$1@digitalmars.com...
>> D1 + Tango with a different Python-inspired syntax; close to my ideal language:
>>
>> http://delight.sourceforge.net/
>>
>> There are just few things I don't like, but they are generally minor, and maybe the author can change some of them still.
>>
>> Bye,
>> bearophile
> 
> "Python-like syntax"
> "Delight is intended for large projects with many developers."
> 
> Now that's hilarious. Good luck to him on that...he'll need it. 
> 
> 
It looks like a very nice language, and there's nothing about Python syntax that makes it unsuitable for large projects.  But it does depend on GDC, which has appeared moribund for well over a year.

bearophile wrote:

> Mosfet:
>> Is there any performance loss from compared to D language ?
> 
> No, it's just D1 resyntaxed. That is, it generally improves on the old-school syntax of D ;-)
> 
> Bye,
> bearophile

How complet is the page? From wath I read there was several good features missing from D1 and if it's just a resyntax thats a shame :)

The most notisable was that I found no mention of an equvivalent to this

foreach(i,x;collection)
        doSuff(i,x);

my experience from java is that not getting access to the index can be a real problem.

Looks good overall thou I'm particularly curious about how the dependency injection will turn out. It feels slightly similar to pure in an object oriented way :)

/Johan Granberg

In article <gbgs5p$26n$1@digitalmars.com>, charleshixsn@earthlink.net says...
> As I said, I first read this years ago.  Since that time my opinions on the matter have become more convinced.  I have never seen any evidence that on honest examination didn't boil down to "I don't like tabs".  So I kludge when I must exchange code with such people/applications, and when I receive code that uses space for indentation, I laboriously remedy the problem.  But I don't think there was was better.  (Actually, it's not usually all that laborious, but it's extra work that I despise having to do.)

To myself, I've reduced the spaces/tabs cons to the following:

If you use strictly spaces, you must negotiate indentation width for a project, you must cope with the chosen indentation width if you don't like it, and you'll probably want to switch between different widths if you work on many external projects, though nothing bad happens if you forget.

If you use strictly tabs, you must never, ever, align things in columns except by the means of indentation, and therefore you can have only one aligned column.

That's it.  The rest is a matter of personal choice.  There is only one con for tabs, and if you consider it minor, then tabs are for you.

On Fri, 26 Sep 2008 00:28:02 +0400, Charles Hixson <charleshixsn@earthlink.net> wrote:

> Nick Sabalausky wrote:
>> "bearophile" <bearophileHUGS@lycos.com> wrote in message news:gbg5hu$189f$1@digitalmars.com...
>>> D1 + Tango with a different Python-inspired syntax; close to my ideal language:
>>>
>>> http://delight.sourceforge.net/
>>>
>>> There are just few things I don't like, but they are generally minor, and maybe the author can change some of them still.
>>>
>>> Bye,
>>> bearophile
>>  "Python-like syntax"
>> "Delight is intended for large projects with many developers."
>>  Now that's hilarious. Good luck to him on that...he'll need it.
> It looks like a very nice language, and there's nothing about Python syntax that makes it unsuitable for large projects.  But it does depend on GDC, which has appeared moribund for well over a year.


I believe GDC can be replaced with LLVMDC when it matures.

Sergey Gromov a écrit :
> If you use strictly tabs, you must never, ever, align things in columns except by the means of indentation, and therefore you can have only one aligned column.

Tabs are not meant to align things. Spaces are used for that. You indent with tabs, and align with spaces. For example (___> means tab, . means space):

no indentation
___>indentation
___>|.column 1.|.column 2.|.column.3.|
___>|.field.1..|.field.2..|.field.3..|
___>|.field.4..|.field.5..|.field.6..|

If you only align with space, there will not be any problem regarding different "tabwidths", ever.

-- 
Etienne Dechamps / e-t172 - AKE Group

Website: http://www.e-t172.net/
Contact: e-t172@akegroup.org

Phone: +33547414942

In article <mailman.251.1222378060.19733.digitalmars-d- announce@puremagic.com>, e-t172@akegroup.org says...
> Sergey Gromov a ecrit :
> > If you use strictly tabs, you must never, ever, align things in columns except by the means of indentation, and therefore you can have only one aligned column.
> 
> Tabs are not meant to align things. Spaces are used for that. You indent with tabs, and align with spaces. For example (___> means tab, . means space):
> 
> no indentation
> ___>indentation
> ___>|.column 1.|.column 2.|.column.3.|
> ___>|.field.1..|.field.2..|.field.3..|
> ___>|.field.4..|.field.5..|.field.6..|
> 
> If you only align with space, there will not be any problem regarding different "tabwidths", ever.

You use a mixture of tabs and spaces.  Now you must carefully attend to what you are typing and which key you use to make a certain part of white space.  Especially if you're re-aligning things.  This approach is error-prone, and once in a while you *will* put a space or a tab somewhere it doesn't belong, annoying your colleagues and introducing indentation errors in your Python code.

Of course you can have whitespace always visible, or use a very smart editor.  But even the smartest editor will fail sometimes.

Sergey Gromov:
> You use a mixture of tabs and spaces.  Now you must carefully attend to what you are typing and which key you use to make a certain part of white space.  Especially if you're re-aligning things.  This approach is error-prone, and once in a while you *will* put a space or a tab somewhere it doesn't belong, annoying your colleagues and introducing indentation errors in your Python code.

Oh, here there are no problems: Python 3 forbids mixing tabs and spaces in the same module ^_^ So it doesn't even run ;-)

Bye,
bearophile

On Fri, Sep 26, 2008 at 6:03 AM, Sergey Gromov <snake.scaly@gmail.com> wrote:
> In article <gbgs5p$26n$1@digitalmars.com>, charleshixsn@earthlink.net says...
>> As I said, I first read this years ago.  Since that time my opinions on the matter have become more convinced.  I have never seen any evidence that on honest examination didn't boil down to "I don't like tabs".  So I kludge when I must exchange code with such people/applications, and when I receive code that uses space for indentation, I laboriously remedy the problem.  But I don't think there was was better.  (Actually, it's not usually all that laborious, but it's extra work that I despise having to do.)
>
> To myself, I've reduced the spaces/tabs cons to the following:
>
> If you use strictly spaces, you must negotiate indentation width for a project, you must cope with the chosen indentation width if you don't like it, and you'll probably want to switch between different widths if you work on many external projects, though nothing bad happens if you forget.
>
> If you use strictly tabs, you must never, ever, align things in columns except by the means of indentation, and therefore you can have only one aligned column.
>
> That's it.  The rest is a matter of personal choice.  There is only one con for tabs, and if you consider it minor, then tabs are for you.

My version of it is:

Pro tabs argument:  "Assuming everyone uses a perfect text editor that handles tabs flawlessly at all times, then tabs are great!"    Bzzzt! fail on underpinning assumption.  This is the Idealist's argument.

Pro spaces argument: "You have to modify the file to reindent, but at least everyone sees the same thing and there are no surprises".   The Pragmatist's argument.

So it is pragmatist vs idealist in the end.  I agree that in a perfect world every editor would handle tabs perfectly and we'd all work together for the common good and no one would ever be hungry or overweight or sick.  But that's not the world we live in.

--bb

bearophile wrote:
> Charles Hixson:
>> I disagree.  I always use tabs.  This allows me to adjust the indentation width on the fly and as needed, which spaces would not allow.
> 
> You can use a little regex to replace the leading spaces, to increase or decrease them at will. Your disadvantage is nothing compared to the problems shown in that post I have linked.

This is not an option if you use a source control system -- you'll change every line of the file with each revision.

Johan Granberg wrote:
> bearophile wrote:
> 
>> Mosfet:
>>> Is there any performance loss from compared to D language ?
>> No, it's just D1 resyntaxed. That is, it generally improves on the
>> old-school syntax of D ;-)
>>
>> Bye,
>> bearophile
> 
> How complet is the page? From wath I read there was several good features
> missing from D1 and if it's just a resyntax thats a shame :)
> 
> The most notisable was that I found no mention of an equvivalent to this
> 
> foreach(i,x;collection)
>         doSuff(i,x);
> 
> my experience from java is that not getting access to the index can be a
> real problem.

In C#, I don't care about the index at least 80% of the time. Maybe as much as 95%.

That still means I have to turn 1 out of every 20 loops into:
int i = 0;
foreach (Type var in collection)
{
	// do stuff, and then...
	i++;
}