www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Delight

reply bearophile <bearophileHUGS lycos.com> writes:
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
Sep 25 2008
next sibling parent reply Mosfet <mosfet anonymous.org> writes:
bearophile wrote:
 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

Is there any performance loss from compared to D language ? I can predict the following destiny to Delight Language, the main maintener of delight will create a good standard lib called Deimos but another developer not satisfied by the methods name will fork and create another one called Salsa. Then Delight will evolve and there will be a Delight 1.0 and a Delight 2.0 with incompatible code. So poor developers will be lost and will keep on waiting for another language without all the issues. Of course this scenario is pure fiction ;-)
Sep 25 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Sep 25 2008
next sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
In article <gbg74u$1bom$1 digitalmars.com>, bearophileHUGS lycos.com 
says...
 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 ;-)

I'd like to look at some real-world example written in Delight. 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.
Sep 25 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Sep 25 2008
next sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
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).

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 also liked the IoC built into the language.
 
 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
 

(even though I like some of the ideas behind it). I hate Python syntax. mainly because the indentation style is forced on the programmer. I do recognize that there are use-cases for this style but I also think this should not be forced for _all_ use-cases. Ruby, for example, provides two ways (you can either use braces or the "end" keyword). IMHO, this should be provided as a compiler option. another example is Nemerle that provides "#pragma indent". see http://nemerle.org/Indentation-based_syntax
 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

Sep 25 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Sep 25 2008
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
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
Sep 25 2008
prev sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
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.
Sep 25 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Sep 25 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
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.
Sep 25 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Sorry for my answering delay, I was busy.

Yigal Chripun:

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

I see. In Python this problem is solved with this not nice syntax: code if __name__ == "__main__": more_code The 'code' is run when you import that module. But the more_code is run only when you run that module as main module. So every module can have that if __name__==... part, so every module can be run both stand alone (for example to run a little demo of its purpose, or to run just its own tests), or imported like a normal module. Time ago in one of my lists of improvements I have asked to have something similar (with a different syntax, a better syntax too) in D. At the moment lot of the D modules I write have a structure like this: const bool do_benchmarks = false; void foo() { ... } unittest { // unittest of function foo ... } void bar() { ... } unittest { // unittest of function bar } static if (do_benchmarks) { import d.time: clock; void benchmark1() { ... } void benchmark2() { ... } } unittest { printf(__FILE__ " unittest performed.\n"); } static if (0) { void main() { static if (do_benchmarks) { putr("\nSome benchmarks:"); benchmark1(); benchmark2(); } } } So when I want to test it I replace the 0 with a 1 at the end and I add -unittest to the command line of the 'bud' tool. When I want to test the performance I also set do_benchmarks to true. With a syntax to denote if a module is run as main the code can become simpler, for example: mainmodule { void main() { static if (do_benchmarks) { putr("\nSome benchmarks:"); benchmark1(); benchmark2(); } } } Or even adding just a compile-time constant to D (that is true only for the main module) may suffice: static if (mainmodule) { void main() { static if (do_benchmarks) { putr("\nSome benchmarks:"); benchmark1(); benchmark2(); } } } Do you like? ------------------------------ Johan Granberg:
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 :)<

I think the language is just born, so more things will be added in the future. Probably the purpose is to support all D. Bye, bearophile
Sep 28 2008
next sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Sun, 28 Sep 2008 18:04:08 -0400,
bearophile wrote:
 static if (mainmodule) {
     void main() {
         static if (do_benchmarks) {
             putr("\nSome benchmarks:");
             benchmark1();
             benchmark2();            
         }
     }
 }
 
 Do you like?

There is no main module in D. The main() function can be in any module. There are no specific privileges for the first module on the command line except sometimes compiler derives an output name from it. Why don't you want to use versions instead? For the module builders for instance it could be: version (builders) { version (benchmark) { import d.time: clock; benchmark1() {...} benchmark2() {...} } } version (builders) { void main() { version (benchmark) { putr("\nSome benchmarks:"); benchmark1(); benchmark2(); } } } do unittests: bud builders -unittest -version=builders benchmark: bud builders -version=builders -version=benchmark
Sep 28 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Sergey Gromov:

 There is no main module in D.  The main() function can be in any module.

This true for Python too. What I have named conventionally "main module" is the module you call bud (or a saner D compiler able to find the necessary modules by itself) with. If you call bud with another name, then the "main module" becomes magically the new one.
 There are no specific privileges for the first module on the command 
 line except sometimes compiler derives an output name from it.

I think that's bad.
 Why don't you want to use versions instead?  For the module builders for 
 instance it could be:
 do unittests:
 bud builders -unittest -version=builders
 benchmark:
 bud builders -version=builders -version=benchmark

Don't you see something bad in what you have written? You have expressed the name 'builders' two times in your command line. So why can't the compiler, given the line: dmd builders define a compile variable that's true inside builders.d and false for all the other modules. While when you compile for example: dmd foo is true inside foo and false for all the other modules, including builders? Bye, bearophile
Sep 28 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Sun, 28 Sep 2008 19:34:25 -0400,
bearophile wrote:
 Sergey Gromov:
 
 There is no main module in D.  The main() function can be in any module.

This true for Python too. What I have named conventionally "main module" is the module you call bud (or a saner D compiler able to find the necessary modules by itself) with. If you call bud with another name, then the "main module" becomes magically the new one.
 There are no specific privileges for the first module on the command 
 line except sometimes compiler derives an output name from it.

I think that's bad.

What if a makefile builds all modules by "dmd -c module.d" and then links object files together? That's how bud works. Which module is "main" then? I'll tell you, it's not the compiler's task. Compiler is not a build system. Recursive building is a special case for simple tools, and in a large project you do want an incremental build. But a build system can definitely do that. Bud could do that. Bud could define a -version=builders, or define -version=mainmodule when compiling the first module in the chain.
 Why don't you want to use versions instead?  For the module builders for 
 instance it could be:
 do unittests:
 bud builders -unittest -version=builders
 benchmark:
 bud builders -version=builders -version=benchmark

Don't you see something bad in what you have written? You have expressed the name 'builders' two times in your command line.

I'd definitely better specify a module name twice than modify module source every time I want to benchmark.
Sep 28 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Sergey Gromov:

 Recursive building is a special case for simple tools, and in a 
 large project you do want an incremental build.

This is true, but for small programs it seems bud (and another similar tool) is enough (my experience with DMD shows that 'small' means up to more than 80000 lines of code). And putting that basic functionality into the compiler, that already parses code, can probably bump that limit up a little higher. So why not offer a handy feature for all the small cases, plus the capability of using complex incremental builds for large programs? Giving the programmer sensible "defaults" for simple very common cases (such very common cases have to be found experimentally) sometimes makes the difference between a handy computer language (or a handy technological system) and a language that isn't nice at all (this is often one little secret of scripting languages). If D wants to be used for smaller programs too (see the other thread here about people using D for scripting-like purposes of text processing) sensible defaults and a handy building becomes important. Do you know why DMD has the -run compilation flag, plus it accepts the shebang syntax that you often find at the top of scripts like Perl/Python ones? It may be of little use if you have to compile a large project, but for smaller quicker things they are useful.
 But a build system can definitely do that.  Bud could do that.  Bud 
 could define a -version=builders, or define -version=mainmodule when 
 compiling the first module in the chain.

I see :-) Well, this solution of yours is better than nothing. I don't know if bud is updated still. But the name of the constant you have to use into the code is is different for each module, it's not a standard one like I have suggested. So your solution is worse still. Bye, bearophile
Sep 28 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Sun, 28 Sep 2008 20:40:53 -0400,
bearophile wrote:
 Sergey Gromov:
 
 Recursive building is a special case for simple tools, and in a 
 large project you do want an incremental build.

So why not offer a handy feature for all the small cases, plus the capability of using complex incremental builds for large programs?

Well, the "give me all source on the command line" thing is a C legacy where compiler simply couldn't deduce the files required to build the project. In D it's possible and there probably should be an -auto option in DMD. Maybe -version=auto could be defined for the first module then. I'm not sure.
 But a build system can definitely do that.  Bud could do that.  Bud 
 could define a -version=builders, or define -version=mainmodule when 
 compiling the first module in the chain.

I see :-) Well, this solution of yours is better than nothing. I don't know if bud is updated still.

Bud supports D2. This means it's being maintained.
 But the name of the constant you have to use into the code is is
 different for each module, it's not a standard one like I have
 suggested. So your solution is worse still.

Please read again:
 or define -version=mainmodule when compiling the first module in the
 chain.


It's completely up to the build system which way to go, it has all the flexibility.
Sep 28 2008
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Sergey Gromov" <snake.scaly gmail.com> wrote in message 
news:MPG.234a6d462c08ea3198971e news.digitalmars.com...
 or define -version=mainmodule when compiling the first module in the
 chain.


It's completely up to the build system which way to go, it has all the flexibility.

Flexibility can be nice, but for something like what's being discussed here I think I'd prefer a language-wide standard.
Sep 28 2008
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Sergey Gromov:

 Please read again:
 or define -version=mainmodule when compiling the first module in the
 chain.



You are right, I am sorry for missing that. ----------- Nick Sabalausky:
Flexibility can be nice, but for something like what's being discussed here I
think I'd prefer a language-wide standard.<

I agree. Bye and thanks for the interesting discussion, bearophile
Sep 28 2008
prev sibling parent Yigal Chripun <yigal100 gmail.com> writes:
bearophile wrote:
 Sorry for my answering delay, I was busy.
 
 Yigal Chripun:
 
 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.<

I see. In Python this problem is solved with this not nice syntax: code if __name__ == "__main__": more_code The 'code' is run when you import that module. But the more_code is run only when you run that module as main module. So every module can have that if __name__==... part, so every module can be run both stand alone (for example to run a little demo of its purpose, or to run just its own tests), or imported like a normal module. Time ago in one of my lists of improvements I have asked to have something similar (with a different syntax, a better syntax too) in D. At the moment lot of the D modules I write have a structure like this: const bool do_benchmarks = false; void foo() { ... } unittest { // unittest of function foo ... } void bar() { ... } unittest { // unittest of function bar } static if (do_benchmarks) { import d.time: clock; void benchmark1() { ... } void benchmark2() { ... } } unittest { printf(__FILE__ " unittest performed.\n"); } static if (0) { void main() { static if (do_benchmarks) { putr("\nSome benchmarks:"); benchmark1(); benchmark2(); } } } So when I want to test it I replace the 0 with a 1 at the end and I add -unittest to the command line of the 'bud' tool. When I want to test the performance I also set do_benchmarks to true. With a syntax to denote if a module is run as main the code can become simpler, for example: mainmodule { void main() { static if (do_benchmarks) { putr("\nSome benchmarks:"); benchmark1(); benchmark2(); } } } Or even adding just a compile-time constant to D (that is true only for the main module) may suffice: static if (mainmodule) { void main() { static if (do_benchmarks) { putr("\nSome benchmarks:"); benchmark1(); benchmark2(); } } } Do you like? ------------------------------ Johan Granberg:
 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
 :)<

I think the language is just born, so more things will be added in the future. Probably the purpose is to support all D. Bye, bearophile

In a perfect world, I'd want a different solution: the _linker_ needs to have a command line flag that tells it what compilation unit contains the main function. (i.e. what's the "main" module). the compiler can safely compile the main function in each module so all object files can contain main functions, but at link time the linker will use only the main function in the specified module. No need for anything in the code such as a a version block or an if statement. this solution does require to change the linker though, and mark "main" functions with a marker of some sort to be recognized by the linker. I know that Walter is unlikely to make any changes to the liker though :( build tools like rebuild do parse the code so maybe they can implement the above instead of the linker. another possibility is to have an _implicit_ version block with the name of the module defined for each module. your code is: module A; ...code... void main() {..code..} the compiler treats it as: module A; ...code... version A { void main() {..code..} } on the command-line you'd use it as: dmd source_files -version=A (or maybe define a different name like --main=A)
Sep 28 2008
prev sibling parent reply Charles Hixson <charleshixsn earthlink.net> writes:
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

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.
Sep 25 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Sep 25 2008
parent Christopher Wright <dhasenan gmail.com> writes:
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.
Sep 25 2008
prev sibling parent reply Charles Hixson <charleshixsn earthlink.net> writes:
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

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.


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.

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.)
Sep 25 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
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.
Sep 25 2008
next sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
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.
Sep 25 2008
parent bearophile <bearophileHUGS lycos.com> writes:
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
Sep 25 2008
prev sibling parent reply 0ffh <frank youknow.what.todo.interNETz> writes:
Bill Baxter wrote:
 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.

Well, yes, it just works! I've done the odd bit of coding in Python, and the first thing I learned was never touch anybode elses code before first doing a "convert tabs to spaces" and then activate "insert spaces for tabs". And I did never, ever again have any trouble with indentation whatsoever. regards, frank
Sep 25 2008
parent reply Benji Smith <dlanguage benjismith.net> writes:
0ffh wrote:
 Bill Baxter wrote:
 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.

Well, yes, it just works! I've done the odd bit of coding in Python, and the first thing I learned was never touch anybode elses code before first doing a "convert tabs to spaces" and then activate "insert spaces for tabs". And I did never, ever again have any trouble with indentation whatsoever. regards, frank

The trouble with that is, if you work on a team, and you check your changes back into the repository, you'll generate a lot of worthless diffs, and people will have a more difficult time following the revision history. When I work on a team with other people, I always adapt my indentation and bracing style to the code I'm currently working on. And I never change a line of code someone else wrote, unless I'm making a semantic change. My own modules are written with my favorite coding style, but I don't mind slumming in someone else's style for the sake of consistency. I used to work with a guy who regularly checked out the whole source tree, ran it through a pretty-printer, with his favorite code style, and then checked the changes back in. His stupid reformatting projects drove pretty much everyone crazy, since we had a hell of a time making sense of our diffs. --benji
Sep 26 2008
parent 0ffh <frank youknow.what.todo.interNETz> writes:
Benji Smith wrote:
 The trouble with that is, if you work on a team [...]

OCTAOE. That was not the use case I had in mind. But I would try to avoid working in a team on a Python project without clear rules of indentation. regards, frank
Sep 26 2008
prev sibling parent reply Johan Granberg <lijat.meREM OVEgmail.com> writes:
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
Sep 25 2008
next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Johan Granberg wrote:
 bearophile wrote:
 
 Mosfet:
 Is there any performance loss from compared to D language ?

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++; }
Sep 25 2008
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Johan Granberg, el 25 de septiembre a las 22:33 me escribiste:
 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);

Loops There are various different constructs for loops: # Iterate over a sequence for x in ["red", "green", "blue"]: stdout.formatln("Next is {}", x) # Iterate over a sequence backwards for x in ["red", "green", "blue"] reversed: stdout.formatln("Next backwards is {}", x) # Get the index as well as the value for i, x in ["red", "green", "blue"]: stdout.formatln("Item #{} = {}", i, x) # Get all key/value pairs from an associative array for key, value in dictionary: stdout.formatln("{} -> {}", key, value) # A C-style for loop for (int i = 1; i < 10; i++): stdout.formatln("i = {}", i) # A C-style while loop int j = 10 while j > 0: stdout.formatln("j = {}", j) j-- (http://delight.sourceforge.net/syntax.html) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Con todas las manos que me acogotan, no puedo respirar Con todos sus dedos me harĂ­a una torta, para festejar Que no me estoy yendo solo de este lugar
Sep 27 2008
prev sibling next sibling parent Sergey Gromov <snake.scaly gmail.com> writes:
Sat, 11 Oct 2008 06:01:18 +0200,
Jarrett Billingsley wrote:
 On Fri, Oct 10, 2008 at 9:33 PM, Thomas Leonard <talex5+d gmail.com> wrote:
 
 I don't think so. For example:

Well in that case, couldn't they be required if there's code on the same line, and optional otherwise? That is, a newline followed by an indent is a perfectly clear indication that a block is beginning. It's redundant (and ugly) to force the colon at the end of a line.

How do you wrap a long expression?
Oct 10 2008
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Jarrett Billingsley:
 Is there any syntactic requirement for colons on blocks as in Python?

People have performed an usability survey, and they have seen that in Python code colons improve code readability there. So removing them is bad. (Performing such studies is light years ahead to the way D syntax currently develops). Bye, bearophile
Oct 11 2008
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Few comments on Delight:
- The string type is used quite commonly, so it may be named 'str' instead.
- The syntax for "new" may be improved
- "in" syntax for arrays may be added.
- I can offer code for set() compatible with Python (currently missing a couple
of methods still, I'm finishing it still).
- Time ago I have sent an email to Thomas Leonard regarding Delight,
unanswered. But I haven't used that talex5+d at gmail dot com address, is
talex5+d... usable?

Bye,
bearophile
Oct 11 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Thomas Leonard:

 I might rename some other types too. e.g.
   int16, int32, int64
   uint16, uint32, uint64

I don't like to type "int32" all the time, so I think "int" and "long" may be better. An intermediate solution of mine that allows for shorter names is to use the number of bytes instead: int1, int2, int4, int8, uint1, uint2, uint4, uint8 float4, float8, float10 int uint (they are ssize_t/size_t, that is the signed/unsigned size_t). But maybe keeping the current D names may be better...
 - The syntax for "new" may be improved


I don't know. Maybe the D syntax: new Classname May become as in Ruby: Classname.new
 Like this?
   if ':' in aString: ...
   if "seq" in aString: ...
 Would be nice.

Yes, like that.
 Any chance of getting this in D?

I think Walter doesn't like that in D. But I think your "compiler" may translate this Delight code: if ':' in aString: ... into the equivalent of the following D: if isIn(':', aString) { ... You can find the isIn() function template is in my libs. Tango probably has a similar function.
 Likewise.

It's just a module of mine, so (once it's complete) you can add it to the stanrdard modules of Delight... You may even load it by default, but Delight isn't Python, so adding an import when you want to use sets seems acceptable. (If necessary, it's probably easy to translate my "sets" module into Delight code).
 Let me know if you still didn't get a reply...<

I have received it now (generally I don't want to disturb, so I didn't press myself in other ways, thinking you were uninterested in my comments). I suggest you to add few more examples of small Delight programs in your site, plus if you want a few benchmarks to compare it with D/Python (benchmarks can be found here: http://shootout.alioth.debian.org/gp4/index.php), so you can give put some numbers behind your statement that performance is sometimes one advantage of Delight over Python (but not in everything, for example Python dicts are often faster, etc). Bye, bearophile
Oct 11 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Thomas Leonard:

"int" would still be available as an alias (probably to int64).

That may cause troubles because in D int is 32 bit. So it may be an alias to the signed size_t, or of the 32 bit int...
Doesn't that work at the moment?<

I don't see the Ruby-like syntax in your site.
There's a simple web server here, for a slightly longer example:<

I did see that. But I think few more mixed little examples are can be really useful. Look at the code of the Shootout, because it's useful as "rosetta code" too, not just for its original benchmarking purposes. Look in your filtered emails again :-) -------------------- More things from the site:
- anonymous functions work ("function(int x): x + 1"). This is like

Note that D1 and D2 already support this syntax: (int x, float y) { return x+y; } For Delight a little shorter syntax may be adopted, for example: (int x, float y): x+y Or: lambda int x, float y: x+y Or: fun int x, float y: x+y Or: int x, float y => x+y
- any object can be implicitly cast to Object (D doesn't allow this)<

Is this good? (just asking)
Statements end at the end of a line. Semi-colons are not required.<

Is the \ syntax possible for too much long lines, as in Python?
(the author is arguing for spaces, but the main point is consistency).<

Nope, the main point was to not use tabs to indent code in Python. You can't miss a "detail" as important as this in such post.
Anonymous functions cannot access variables in their containing function, but
you can use a delegate for that:<

When not specified you can use a delegate by default (as D does inside functions).
These are D/Java style try/catch/finally syntax:<

The semantics of D exceptions is quite different from the Java one. Bye, bearophile
Oct 12 2008
parent bearophile <bearophileHUGS lycos.com> writes:
Thomas Leonard:
 Having 'function' or 'delegate' come first makes parsing easier (e.g. for 
 syntax highlighters, etc).

A syntax like C# lambdas looks better, but I understand your points. func o fun or def may be used as shorter form of function. Bye, bearophile
Oct 26 2008
prev sibling next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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.

arguments there. That point is specifically addressed in the thing he linked to. --bb
Sep 25 2008
prev sibling next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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
Sep 25 2008
prev sibling next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
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
Sep 25 2008
prev sibling next sibling parent Thomas Leonard <talex5+d gmail.com> writes:
On Thu, 25 Sep 2008 22:33:54 +0200, 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 :)

It's now based on D2. The main problem was that Tango's D2 branch doesn't work with GDC, so I had to switch to Phobos instead. Pretty much all D syntax has a direct equivalent in Delight. The main missing things are: - labels (and therefore goto). They might come back later (with a new syntax, since colon is used for indented blocks). - anonymous functions are limited to expressions (as in Python). In addition, these things are only available to modules in the dlt.* namespace: - module level variables - static variables - extern This is to encourage external libraries to be wrapped, since they generally don't fit in with the style the language is experimenting with.
 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 :)

Oct 09 2008
prev sibling next sibling parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Thu, Oct 9, 2008 at 8:06 PM, Thomas Leonard <talex5+d gmail.com> wrote:
 - labels (and therefore goto). They might come back later (with a new
  syntax, since colon is used for indented blocks).

Is there any syntactic requirement for colons on blocks as in Python? At least when I've used Python I've done nothing but curse and swear profusely when I forget a colon where it's completely obvious what my intent is. Couldn't they be eliminated?
Oct 09 2008
prev sibling next sibling parent Thomas Leonard <talex5+d gmail.com> writes:
On Thu, 09 Oct 2008 20:40:57 +0200, Jarrett Billingsley wrote:

 On Thu, Oct 9, 2008 at 8:06 PM, Thomas Leonard <talex5+d gmail.com>
 wrote:
 - labels (and therefore goto). They might come back later (with a new
  syntax, since colon is used for indented blocks).

Is there any syntactic requirement for colons on blocks as in Python? At least when I've used Python I've done nothing but curse and swear profusely when I forget a colon where it's completely obvious what my intent is. Couldn't they be eliminated?

I don't think so. For example: if a .b .c could mean if a: .b.c or if a.b: .c Probably removing the : would require () around the condition.
Oct 10 2008
prev sibling next sibling parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Fri, Oct 10, 2008 at 9:33 PM, Thomas Leonard <talex5+d gmail.com> wrote:

 I don't think so. For example:

Well in that case, couldn't they be required if there's code on the same line, and optional otherwise? That is, a newline followed by an indent is a perfectly clear indication that a block is beginning. It's redundant (and ugly) to force the colon at the end of a line.
Oct 10 2008
prev sibling next sibling parent Thomas Leonard <talex5+d gmail.com> writes:
On Sat, 11 Oct 2008 10:34:44 -0400, bearophile wrote:

 Few comments on Delight:
 - The string type is used quite commonly, so it may be named 'str'
 instead.

I might rename some other types too. e.g. int16, int32, int64 uint16, uint32, uint64 The only reason to use short or long is because you care about the size, so might as well make it explicit.
 - The syntax for "new" may be improved

How? It could be removed, I suppose, as in Python.
 - "in" syntax for arrays may be added.

Like this? if ':' in aString: ... if "seq" in aString: ... Would be nice. Any chance of getting this in D?
 - I can offer code for set() compatible with Python
 (currently missing a couple of methods still, I'm finishing it still).

Likewise.
 - Time ago I have sent an email to Thomas Leonard regarding Delight,
 unanswered. But I haven't used that talex5+d at gmail dot com address,
 is talex5+d... usable?

Ah. I found some messages about it in my spam folder today. Let me know if you still didn't get a reply...
Oct 11 2008
prev sibling next sibling parent Thomas Leonard <talex5+d gmail.com> writes:
On Sat, 11 Oct 2008 13:33:15 -0400, bearophile wrote:
 Thomas Leonard:
 
 I might rename some other types too. e.g.
   int16, int32, int64
   uint16, uint32, uint64

I don't like to type "int32" all the time, so I think "int" and "long" may be better.

"int" would still be available as an alias (probably to int64).
 - The syntax for "new" may be improved


I don't know. Maybe the D syntax: new Classname

Doesn't that work at the moment?
 Like this?
   if ':' in aString: ...
   if "seq" in aString: ...

 Any chance of getting this in D?

I think Walter doesn't like that in D.

Ah, OK. It's pretty useful, so I might add it anyway. [sets]
 It's just a module of mine, so (once it's complete) you can add it to
 the stanrdard modules of Delight... You may even load it by default, but
 Delight isn't Python, so adding an import when you want to use sets
 seems acceptable. (If necessary, it's probably easy to translate my
 "sets" module into Delight code).

No need. Delight can parse D code too. The only problem is D code doesn't indicate whether pointers can be null or not. I might add a "notnull" type modifier to the D parser so that D interfaces can be modified easily without changing their whole syntax.
 I suggest you to add few more examples of small Delight programs in your
 site,

There's a simple web server here, for a slightly longer example: http://delight.sourceforge.net/examples.html
Oct 12 2008
prev sibling parent Thomas Leonard <talex5+d gmail.com> writes:
On Sun, 12 Oct 2008 09:56:56 -0400, bearophile wrote:
 More things from the site:

 Thomas Leonard:
- anonymous functions work ("function(int x): x + 1"). This is like

Note that D1 and D2 already support this syntax: (int x, float y) { return x+y; }

Unfortunately, the corresponding syntax is ambiguous: while 1 + (something): ... Is something an expression or a list of arguments? D just looks after the closing ) and sees that the next character is a block start, but that only works because it always has an extra outer pair of (). We could do something like: map( (int x) -> x + 1, [1,2,3]) But I don't really like having to look ahead to work out what it is. Having 'function' or 'delegate' come first makes parsing easier (e.g. for syntax highlighters, etc).
- any object can be implicitly cast to Object (D doesn't allow this)<

Is this good? (just asking)

I've now adding a 'linkage' field to interfaces. You can cast any interface to Object iff it has D linkage. So COM objects can't be accidentally treated as D objects again, but it's still convenient in the common case. I don't use COM, but I needed this when adding GObject linkage: http://delight.sourceforge.net/gtk.html
Statements end at the end of a line. Semi-colons are not required.<

Is the \ syntax possible for too much long lines, as in Python?

Currently you need some kind of brackets, but I'll add \ at some point.
Oct 26 2008
prev sibling next sibling parent reply BLS <nanali nospam-wanadoo.fr> writes:
bearophile schrieb:
 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

Good to see another BOO. bearophile, if you hate D that much : write a Python compiler. Bjoern
Sep 25 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
BLS:
 bearophile, if you hate D that much : write a Python compiler.

You are silly, I like D. And I have already done that (I have given help): http://code.google.com/p/shedskin/ Bye, bearophile
Sep 25 2008
parent BLS <nanali nospam-wanadoo.fr> writes:
bearophile schrieb:
 BLS:
 bearophile, if you hate D that much : write a Python compiler.

You are silly, I like D. And I have already done that (I have given help): http://code.google.com/p/shedskin/ Bye, bearophile

Bjoern PS / I know that you are a D Enthusiast. But Sometimes I wonder why.
Sep 25 2008
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"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.
Sep 25 2008
next sibling parent reply Charles Hixson <charleshixsn earthlink.net> writes:
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.

syntax that makes it unsuitable for large projects. But it does depend on GDC, which has appeared moribund for well over a year.
Sep 25 2008
parent reply Mosfet <mosfet anonymous.org> writes:
Denis Koroskin wrote:
 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

"Delight is intended for large projects with many developers." Now that's hilarious. Good luck to him on that...he'll need it.

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.

GCC does. For instance I am interested by ARM platforms, does LLVMDC support it ?
Sep 26 2008
parent Lutger <lutger.blijdestijn gmail.com> writes:
Mosfet wrote:
...
 I believe GDC can be replaced with LLVMDC when it matures.

GCC does. For instance I am interested by ARM platforms, does LLVMDC support it ?

LLVM does, see: http://llvm.cs.uiuc.edu/ "...static back-ends for the X86, X86-64, PowerPC 32/64, ARM, Thumb, IA-64, Alpha, SPARC, MIPS and CellSPU architectures, a back-end which emits portable C code, and a Just-In-Time compiler for X86, X86-64, PowerPC 32/64 processors, and an emitter for MSIL."
Sep 26 2008
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
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

"Delight is intended for large projects with many developers." Now that's hilarious. Good luck to him on that...he'll need it.

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.
Sep 25 2008
prev sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Nick Sabalausky wrote:
 "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. 

AFAIK, Google writes quite a few of their "large projects with many developers" in Python.
Sep 27 2008
prev sibling next sibling parent e-t172 <e-t172 akegroup.org> writes:
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

Sergey Gromov a =E9crit :
 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=20 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=20 different "tabwidths", ever. --=20 Etienne Dechamps / e-t172 - AKE Group Website: http://www.e-t172.net/ Contact: e-t172 akegroup.org Phone: +33547414942
Sep 25 2008
prev sibling parent Kenny B <funisher gmail.com> writes:
has anyone mentioned that the color scheme of the page comes straight outa the
70's?

Maybe it's just me...



Sorry, now, I'll continue reading :)

(or perhaps other possible inspirations could have been UNO the card game or
Iberia Airlines)


bearophile wrote:
 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

Sep 25 2008