bearophile:
> I have never programmed in a language without global state,<

That's false, I have used Scheme for several months, without global state.

Bye,
bearophile

bearophile wrote:
> Yigal Chripun:
> 
>> Could you explain why? IMO, this is actually a good idea [not having global state]. it does provide capability based security even if that wasn't the original goal.<
> 
> I have never programmed in a language without global state, so I presume I have to try it before criticizing it. I think of global vars like the "goto" in D: usually (for sizable programs) you can do better without them, but once in a while they may help. And I think in quick & dirty script-like programs 10-20 lines long that you need to use few times global variables may speed up your programming.
> 
> And in D/Python modules I use global functions all the time, I don't use just classes like in Java.
> 
> Bye, bearophile

From what I understood, global functions are allowed.
What is disallowed is global _state_ only.
regarding your goto example:
I agree that there are rare cases where unsafe features can be helpful
like goto statements. I like the D approach of being a practical
language and not force a religion on you. contrast that with Java where
goto is a reserved word specifically so you won't be able to use it.
however, I'd like to see a way to mark those features and separate them
from the regular safe code.
I'm thinking about something like "unsafe" blocks from C#. This way, all
those dirty tricks are available to you and you can use them if, for
example, you just need to do a quick'n'dirty short script. However,
those dirty trick will be marked as such in large code-bases and would
be handled appropriately.
Also, the compiler could have a "safe" flag to disallow those features
and issue errors/warnings with info about lack of safety.
for example, static state breaks multi threaded code and all such state
should be either marked as thread local or synchronized. marking this as
"unsafe" will warn the programmer about such implications.

bearophile wrote:
> Sergey Gromov:
>> I'd like to look at some real-world example written in Delight.
> 
> I have not tried to run it yet because it's for Linux for now.
> 
> 
>> I'm afraid that the lack of global state will result in either a huge amount of arguments passed to every function or huge ad-hoc interfaces grouping other interfaces just to pass some functionality up-stream.
> 
> I agree, that's one of the main things I think have to be fixed in Delight, having global vars (and maybe a global main function too).
> 
> The other main problem comes from the tabs as indents, this explains why it's bad:
> http://mail.python.org/pipermail/python-list/2003-January/183758.html
> 
> There are other problems in Delight, but I think they are minor.
> 
> There's a (for me) surprisingly large discussion on Reddit about Delight, 82 comments so far:
> http://www.reddit.com/r/programming/comments/73d15/d_meets_python/
> 
> Bye,
> bearophile
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.

OTOH, I do agree that a mixture of spaces and tabs should be forbidden in any language where indentation level is syntactically meaningful, and probably also in any language where it's semantically meaningful.

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.

Eggs should be broken from big end, everyone knows it ;-)

Bye,
bearophile

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

Yigal Chripun:
> From what I understood, global functions are allowed.

This is the (not nice to me) hello world:

import dlt.io

class Main:
	void main(Printer stdout):
		stdout("Hello World!\n")


So I presume you need a least one class into your code.

Bye,
bearophile

On Fri, Sep 26, 2008 at 4:24 AM, Charles Hixson <charleshixsn@earthlink.net> wrote:
> bearophile wrote:
>>
>> Sergey Gromov:
>>>
>>> I'd like to look at some real-world example written in Delight.
>>
>> I have not tried to run it yet because it's for Linux for now.
>>
>>
>>> I'm afraid that the lack of global state will result in either a huge amount of arguments passed to every function or huge ad-hoc interfaces grouping other interfaces just to pass some functionality up-stream.
>>
>> I agree, that's one of the main things I think have to be fixed in Delight, having global vars (and maybe a global main function too).
>>
>> The other main problem comes from the tabs as indents, this explains why it's bad: http://mail.python.org/pipermail/python-list/2003-January/183758.html
>>
>> There are other problems in Delight, but I think they are minor.
>>
>> There's a (for me) surprisingly large discussion on Reddit about Delight, 82 comments so far: http://www.reddit.com/r/programming/comments/73d15/d_meets_python/
>>
>> Bye,
>> bearophile
>
> 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.
Did you even read the doc Bearophile posted?  If so try rebutting the arguments there. That point is specifically addressed in the thing he linked to.

--bb

On Fri, Sep 26, 2008 at 4:33 AM, bearophile <bearophileHUGS@lycos.com>wrote:

> Yigal Chripun:
> > From what I understood, global functions are allowed.
>
> This is the (not nice to me) hello world:
>
> import dlt.io
>
> class Main:
>        void main(Printer stdout):
>                stdout("Hello World!\n")
>
>
> So I presume you need a least one class into your code.
>

That surprised me too.  He's probably been drinking too much OO/Java kool-aid.

--bb

bearophile wrote:
> Yigal Chripun:
>> From what I understood, global functions are allowed.
> 
> This is the (not nice to me) hello world:
> 
> import dlt.io
> 
> class Main:
> 	void main(Printer stdout):
> 		stdout("Hello World!\n")
> 
> 
> So I presume you need a least one class into your code.
> 
> Bye,
> bearophile

You're confusing two separate issues.
see: http://delight.sourceforge.net/syntax.html
there _are_ top level functions in delight.

from what I understand the Main class is due to the IoC feature and the
fact that you want to pass "global" state to your program.
here's a snippet from the above link:

# Define a class
class Main:
	# An argument that must be passed
	# when constructing this Class
	in Printer stdout

	void main():
		stdout(addNewline(greeting))

So you construct a Main instance and pass it all the needed outside
state, than you use the main method to start your program.
another option, as in your example from the "overview" page is to pass
the outside state directly as parameters to the main method.

Java is similar with this since it has dynamic class-loading - i.e. all
your classes can define a main function and you specify to the JVM which
class to load. this has other problems in java but the general idea (not
 the specific java implementation) is a good thing. if you try a similar
thing in D - compile two D files which both define main - you'll get an
error.

Bill Baxter wrote:
> On Fri, Sep 26, 2008 at 4:24 AM, Charles Hixson <charleshixsn@earthlink.net <mailto:charleshixsn@earthlink.net>> wrote:
>  > bearophile wrote:
>  >>
>  >> Sergey Gromov:
>  >>>
>  >>> I'd like to look at some real-world example written in Delight.
>  >>
>  >> I have not tried to run it yet because it's for Linux for now.
>  >>
>  >>
>  >>> I'm afraid that the lack of global state will result in either a huge
>  >>> amount of arguments passed to every function or huge ad-hoc interfaces
>  >>> grouping other interfaces just to pass some functionality up-stream.
>  >>
>  >> I agree, that's one of the main things I think have to be fixed in
>  >> Delight, having global vars (and maybe a global main function too).
>  >>
>  >> The other main problem comes from the tabs as indents, this explains why
>  >> it's bad:
>  >> http://mail.python.org/pipermail/python-list/2003-January/183758.html
>  >>
>  >> There are other problems in Delight, but I think they are minor.
>  >>
>  >> There's a (for me) surprisingly large discussion on Reddit about Delight,
>  >> 82 comments so far:
>  >> http://www.reddit.com/r/programming/comments/73d15/d_meets_python/
>  >>
>  >> Bye,
>  >> bearophile
>  >
>  > 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.
> 
> Did you even read the doc Bearophile posted?  If so try rebutting the arguments there. That point is specifically addressed in the thing he linked to.
> 
> --bb
OK, I'll try to do it point by point.  (I first read this years ago when it came out on the python list.)
1) >> All tabs works fine regardless of editor tab stops. All spaces works
>> fine. Mixed spaces and tabs is deadly.
Agreed.

2) So is the use of tabs in certain contexts; in particular any attempt
> to e-mail a python source to someone using Outlook Express. OE
> has this nasty habit of ignoring leading tabs.
Sorry, I'm not going to let MS shape my preferences.  Nor some other silly editors that also automatically convert tabs to spaces, not other silly editors that presume that a tab must equal 8 spaces.

3) long example is mixing tabs and spaces by invoking two different programmers.  This is, indeed, bad, but tabs and spaces are equally good/bad in this context.  (And yes, I've been bitten...and due to that I really despise spaces as linguistic separators.)

4) "The second argument (tabs mean everyone can use their favorite
indentation) sounds nice at first, but simply doesn't work in the real
world. It inevitably, and I do mean *inevitably*, leads to ugly
space-tab mixing. Even code written by only one author using one text
editor won't be able to avoid it!"
Now that's *REALLY* stupid and false to boot.  I only ever use spaces when I'm reformatting my code for use externally, and that's just because of people/applications who are equally .... I can't think of a polite adjective that's accurate.

5) "I don't like tab characters. I wish they would go away ..."
That's his only real argument, but at least he's eventually honest enough to come out with it.

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