www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - =?UTF-8?B?QSBsb29rIGF0IHRoZSBEIHByb2dyYW1taW5nIGxhbmd1YWdlIGJ5IEY=?=

reply Walter Bright <newshound2 digitalmars.com> writes:
http://fgda.pl/post/8/a-look-at-the-d-programming-language
Jan 07 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 http://fgda.pl/post/8/a-look-at-the-d-programming-language



 From the article:


 if you only count the natively-compiled ones that could be used
 instead of C++ and have a similarly looking code. D is the best
 fit in this category, if not the only fit.1


There is also Rust.



 if (!tmp) throw new Exception("Memory allocation failed");


The error for memory overflow isn't immediate to find.



 The garbage collector in D isn't very fast and stops the
 world (halts other threads).


A Rust GC doesn't need to stop more than one thread.

Bye,
bearophile
Jan 07 2013
next sibling parent reply Max Klyga <email domain.com> writes:
On 2013-01-07 11:31:45 +0000, bearophile said:


 Walter Bright:

 http://fgda.pl/post/8/a-look-at-the-d-programming-language


 
  From the article:
 

 if you only count the natively-compiled ones that could be used
 instead of C++ and have a similarly looking code. D is the best
 fit in this category, if not the only fit.1


 
 There is also Rust.
 

 if (!tmp) throw new Exception("Memory allocation failed");


 
 The error for memory overflow isn't immediate to find.
 

 The garbage collector in D isn't very fast and stops the
 world (halts other threads).


 
 A Rust GC doesn't need to stop more than one thread.
 
 Bye,
 bearophile


bearophile, WHY U KEEP POSTING ABOUT OTHER LANGUAGES?!
http://alltheragefaces.com/img/faces/large/misc-jackie-chan-l.png

This comment has no real value, and looks like you are promoting 
Rust/Ada/whatever instead of D.
No, seriously, why are you doing this? Its not like Walter, Andrei or 
any other D core team are not aware of Rust existance.
Jan 07 2013
next sibling parent "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Monday, 7 January 2013 at 11:48:36 UTC, Max Klyga wrote:

 On 2013-01-07 11:31:45 +0000, bearophile said:


 Walter Bright:

 http://fgda.pl/post/8/a-look-at-the-d-programming-language


 
 From the article:
 

 if you only count the natively-compiled ones that could be 
 used
 instead of C++ and have a similarly looking code. D is the 
 best
 fit in this category, if not the only fit.1


 
 There is also Rust.
 

 if (!tmp) throw new Exception("Memory allocation failed");


 
 The error for memory overflow isn't immediate to find.
 

 The garbage collector in D isn't very fast and stops the
 world (halts other threads).


 
 A Rust GC doesn't need to stop more than one thread.
 
 Bye,
 bearophile


 bearophile, WHY U KEEP POSTING ABOUT OTHER LANGUAGES?!
 http://alltheragefaces.com/img/faces/large/misc-jackie-chan-l.png

 This comment has no real value, and looks like you are 
 promoting Rust/Ada/whatever instead of D.
 No, seriously, why are you doing this? Its not like Walter, 
 Andrei or any other D core team are not aware of Rust existance.


He is into programming languages, and naturally likes to compare 
them. I believe every language designer does the same, however 
most of them are quiet... :)
Jan 07 2013
prev sibling next sibling parent reply "nazriel" <spam dzfl.pl> writes:
 bearophile, WHY U KEEP POSTING ABOUT OTHER LANGUAGES?!
 http://alltheragefaces.com/img/faces/large/misc-jackie-chan-l.png

 This comment has no real value, and looks like you are 
 promoting Rust/Ada/whatever instead of D.
 No, seriously, why are you doing this? Its not like Walter, 
 Andrei or any other D core team are not aware of Rust existance.


I don't think he has any bad intention, just trying to make core 
developers focus on the biggest issues (GC, Shared libraries, 
Allocators :>).

Guessing at number of bugs reported by Bugophile he is on our 
side ;)))) And has some good points about Rust, that we could 
adapt in D.


Anyways, great read. Also nice to see that more and more Polish 
people are getting interested in D Programming Language. Maybe in 
near future I will be able to meet someone in real world living 
close to me and drink some beer and talk about D.
Jan 07 2013
next sibling parent Max Klyga <email domain.com> writes:
On 2013-01-07 11:55:59 +0000, nazriel said:


 snip...


 
 I don't think he has any bad intention, just trying to make core 
 developers focus on the biggest issues (GC, Shared libraries, 
 Allocators :>).
 
 Guessing at number of bugs reported by Bugophile he is on our side 
 ;)))) And has some good points about Rust, that we could adapt in D.
 
 
 Anyways, great read. Also nice to see that more and more Polish people 
 are getting interested in D Programming Language. Maybe in near future 
 I will be able to meet someone in real world living close to me and 
 drink some beer and talk about D.


I know that he has good intentions, but sometimes it just looks weird.
Jan 07 2013
prev sibling parent reply FG <home fgda.pl> writes:
On 2013-01-07 12:55, nazriel wrote:

 Anyways, great read. Also nice to see that more and more Polish people are
 getting interested in D Programming Language. Maybe in near future I will be
 able to meet someone in real world living close to me and drink some beer and
 talk about D.


Who knows. Maybe there will even be a D conference in Poland in our lifetime. ;)
Jan 07 2013
parent reply "David Nadlinger" <see klickverbot.at> writes:
On Monday, 7 January 2013 at 16:57:05 UTC, FG wrote:

 Who knows. Maybe there will even be a D conference in Poland in 
 our lifetime. ;)


Not sure if you were implying this, but actually there was a D 
conference in Poland already, the Tango Conference in 2008. ;)

David
Jan 07 2013
next sibling parent FG <home fgda.pl> writes:
On 2013-01-07 18:20, David Nadlinger wrote:

 Not sure if you were implying this, but actually there was a D conference in
 Poland already, the Tango Conference in 2008. ;)


Oh. I didn't know much about D back then and haven't tried Tango.
IIRC I only started following D after regular expressions in Phobos got decent.
Jan 07 2013
prev sibling parent "nazriel" <spam dzfl.pl> writes:
On Monday, 7 January 2013 at 17:20:23 UTC, David Nadlinger wrote:

 On Monday, 7 January 2013 at 16:57:05 UTC, FG wrote:

 Who knows. Maybe there will even be a D conference in Poland 
 in our lifetime. ;)


 Not sure if you were implying this, but actually there was a D 
 conference in Poland already, the Tango Conference in 2008. ;)

 David


Yeah, it was hosted in Torun.
Unfortunately I had no idea about D back then, buu.

Lets hope there will be more in near future *winks
Jan 07 2013
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 7 Jan 2013 14:48:38 +0300
Max Klyga <email domain.com> wrote:

 
 bearophile, WHY U KEEP POSTING ABOUT OTHER LANGUAGES?!
 http://alltheragefaces.com/img/faces/large/misc-jackie-chan-l.png
 


Because it's good to not have blinders on when developing or using a
language.

I do like that image though. :)
Jan 07 2013
prev sibling parent reply "thedeemon" <dlang thedeemon.com> writes:
On Monday, 7 January 2013 at 11:31:46 UTC, bearophile wrote:


 There is also Rust.


I had the impression that Rust was at embryonic stage where it 
changes all the time, can't really live by itself and is not born 
yet. It's an interesting project but not a language one would use 
today for real work. Or am I mistaken?
Jan 07 2013
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
thedeemon:


 I had the impression that Rust was at embryonic stage


Beside reading/seeing some tutorials, blog posts and talks, I 
have used Rust only for little experiments, so I don't know a lot 
about it.

Compared to D it's less finished, but at version 0.5 most of its 
parts/syntax seems designed, and its compiler is self-hosted, so 
the language is already usable for largish experiments. At 
Mozilla there are several persons working on it.

Bye,
bearophile
Jan 07 2013
prev sibling parent reply "SomeDude" <lovelydear mailmetrash.com> writes:
On Monday, 7 January 2013 at 12:16:04 UTC, thedeemon wrote:

 On Monday, 7 January 2013 at 11:31:46 UTC, bearophile wrote:


 There is also Rust.


 I had the impression that Rust was at embryonic stage where it 
 changes all the time, can't really live by itself and is not 
 born yet. It's an interesting project but not a language one 
 would use today for real work. Or am I mistaken?


Yeah, my impression is it's still pretty embryonic, especially on 
the library side.
Jan 13 2013
parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Sunday, 13 January 2013 at 16:00:27 UTC, SomeDude wrote:

 On Monday, 7 January 2013 at 12:16:04 UTC, thedeemon wrote:

 On Monday, 7 January 2013 at 11:31:46 UTC, bearophile wrote:


 There is also Rust.


 I had the impression that Rust was at embryonic stage where it 
 changes all the time, can't really live by itself and is not 
 born yet. It's an interesting project but not a language one 
 would use today for real work. Or am I mistaken?


 Yeah, my impression is it's still pretty embryonic, especially 
 on the library side.


Also we don't know how well it performs, although it looks like 
the design is intended to perform reasonably well.
Jan 13 2013
prev sibling parent reply Max Klyga <email domain.com> writes:
On 2013-01-07 09:32:30 +0000, Walter Bright said:


 http://fgda.pl/post/8/a-look-at-the-d-programming-language


Now on Reddit: 
http://www.reddit.com/r/programming/comments/1647y1/a_look_at_the_d_programming_la
guage_by_ferdynand/
Jan 07 2013
parent reply "Chris" <wendlec tcd.ie> writes:
On Monday, 7 January 2013 at 12:26:12 UTC, Max Klyga wrote:

 On 2013-01-07 09:32:30 +0000, Walter Bright said:


 http://fgda.pl/post/8/a-look-at-the-d-programming-language


 Now on Reddit: 
 http://www.reddit.com/r/programming/comments/1647y1/a_look_at_the_d_programming_language_by_ferdynand/


Nice article. Once I have enough time I would like to write a 
short article about how D has solved practical issues for me. I 
think it is not enough to talk about all the features of the 
language (templates, GC) without giving practical examples (one 
more Fibbonacci example and I'll go maD!), i.e. things 
programmers have to deal with every day and that make life 
(needlessly) difficult like encoding issues, portability and 
interfacing to C, to mention but a few. Big companies will always 
be able to make people believe that they alone have solved 
concurrency issues and everyone should use their products. But D 
is much more than a language that was born out of the need to 
address (con)current issues. It already is as versatile as C and 
C++ (system language, portable), as productive as Python, it has 
the benefit of hindsight and is felxible enough to react to new 
demands. Sure, we all know that. However, in order to convince 
people to use D for new projects, it would be nice to have some 
practical real-world examples and possibly a list of "Made with 
D"-software.
Jan 07 2013
next sibling parent FG <home fgda.pl> writes:
On 2013-01-07 14:31, Chris wrote:

 (one more Fibbonacci example and I'll go maD!)


Sorry for using the most overused one. :)


 However, in order to convince people to use D for new projects,
 it would be nice to have some practical real-world examples
 and possibly a list of "Made with D"-software.


Definitely.
Jan 07 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/7/2013 5:31 AM, Chris wrote:

 Nice article. Once I have enough time I would like to write a short article
 about how D has solved practical issues for me.


Please do!



 I think it is not enough to talk
 about all the features of the language (templates, GC) without giving practical
 examples


This is a very important point. Without showing how features combine to solve 
interesting problems, people tend to view lists of features as just

    ...buzz...buzz...buzz...buzz...buzz...
Jan 07 2013
next sibling parent reply "Phil Lavoie" <maidenphil hotmail.com> writes:
Cool article.

Most of my favorite features are just skipped but hey, you can't 
cover everything in an overview! Plus, every new article 
describing D's is important.

What's he saying about "delete" being deprecated? Is that true? 
Are we talking about that delete:

class {
   new( size_t size ) { ... }
   delete( void * v ) { ... }

}

Or the global one he uses? Personally, I would like the delete 
operator to continue to exist, just to explicitly delete objects 
when needed (although scope objects works fine in most cases).

Phil
Jan 07 2013
next sibling parent reply "Phil Lavoie" <maidenphil hotmail.com> writes:
On Monday, 7 January 2013 at 21:49:12 UTC, Phil Lavoie wrote:

 Cool article.

 Most of my favorite features are just skipped but hey, you 
 can't cover everything in an overview! Plus, every new article 
 describing D's is important.

 What's he saying about "delete" being deprecated? Is that true? 
 Are we talking about that delete:

 class {
   new( size_t size ) { ... }
   delete( void * v ) { ... }

 }

 Or the global one he uses? Personally, I would like the delete 
 operator to continue to exist, just to explicitly delete 
 objects when needed (although scope objects works fine in most 
 cases).

 Phil


I meant scope objects work fine in most cases, but sometimes its 
good to explicitly delete objects on the heap.
Jan 07 2013
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 01/07/2013 01:57 PM, Phil Lavoie wrote:


 I meant scope objects work fine in most cases, but sometimes its good to
 explicitly delete objects on the heap.


Usually, what is needed is to just finalize the object. The memory that 
it sits on should still be managed by the GC.

So, now there is destroy():



         auto variable = new Foo;
         // ... later ...
         destroy(variable);

Ali
Jan 07 2013
parent "thedeemon" <dlang thedeemon.com> writes:
On Monday, 7 January 2013 at 22:14:46 UTC, Ali Çehreli wrote:

 On 01/07/2013 01:57 PM, Phil Lavoie wrote:


 I meant scope objects work fine in most cases, but sometimes


 its good to

 explicitly delete objects on the heap.


 Usually, what is needed is to just finalize the object. The 
 memory that it sits on should still be managed by the GC.


This is all fine when GC is precise. With current GC in 32 bits 
I'd rather have manual deallocation than leaks. This is actually 
what I successfully did in a photo editing app: using 'delete' 
for large chunks of data (uncompressed photos) and GC for the 
rest. This way everything worked smoothly.
Jan 08 2013
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 7 January 2013 at 21:49:12 UTC, Phil Lavoie wrote:

 Or the global one he uses?


Both actually, iirc. delete foo; is discouraged in favor of a 
library function destroy(foo) (or something, the name has changed 
once), and the class allocators can be done at the creation site 
(std.typecons has functions like emplace or Scoped) or with 
static methods and private constructors.


 Personally, I would like the delete operator to continue to 
 exist, just to explicitly delete objects when needed (although 
 scope objects works fine in most cases).


Bah, I'd like to get rid of both new and delete, replacing both 
with simple library functions. Well, probably not "get rid of" 
because that'd break too much code, but certainly discourage in 
favor of library function templates.

A benefit there is you could swap out to other things without 
changing the syntax, and it can return special library types.

import gc;
auto foo = New!Foo(); // could return a NotNull!Foo, which is 
substitutable for plain Foo, but also gives the guarantee that it 
isn't null

or
import malloc;
auto foo = New!Foo(); // could return RefCounted!Foo or whatever




Another benefit with all library is it'd clear up the delete 
deprecation... since new is just a library function, there'd be 
no confusion about delete being a library function either :)
Jan 07 2013
prev sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Monday, 7 January 2013 at 19:59:44 UTC, Walter Bright wrote:

 On 1/7/2013 5:31 AM, Chris wrote:

 Nice article. Once I have enough time I would like to write a 
 short article
 about how D has solved practical issues for me.


 Please do!


I'd love to.


 I think it is not enough to talk
 about all the features of the language (templates, GC) without 
 giving practical
 examples


 This is a very important point. Without showing how features 
 combine to solve interesting problems, people tend to view 
 lists of features as just

    ...buzz...buzz...buzz...buzz...buzz...


Exactly, especially since not everyone who uses a programming 
language uses it because of _all_ the features but because it 
solves certain specific problems for them. Think of scientists 
who create a tool for their research (e.g. Hidden Markov models - 
http://en.wikipedia.org/wiki/Hidden_Markov_model). They are not 
necessarily interested in templates, but they might need speed, 
concurrency and interfacing to existing C libraries. Python took 
off in the scientific community (well, it was designed as a 
scientific language, I think). The question is usually "What can 
the language do for me? How can it help me?" The good thing about 
D is that it can help a lot of people in a lot of different ways 
(systems programming, UTF-8, concurrency etc.) but not everyone 
needs all features (and you don't need to use them all at the 
same time). D can boast that it has it all but people need to see 
what "all" means, and here we need practical examples (real 
projects).

Another thing, IMO, is that there is an overemphasis on C++ vs. 
D. Usually people have to choose between systems programming 
(learn C/C++) or high level (learn Python, Ruby etc.). Most 
non-programmers who need to write a piece of software opt for 
Python and other scripting languages, because nobody wants to 
learn C/C++ only to write a small parser for data files. With D 
you no longer have to choose. You can write both quick and dirty 
script-like stuff and stuff that is close to the machine. Python 
and Ruby took off, I think, because they appealed to people who 
are not fully fledged programmers but who want or need to do some 
programming. This is the crowd the D community has to get on 
board. Don't forget that this is what has made JavaScript one of 
the most widely used languages (alas!).
Jan 07 2013
parent reply "Rob T" <alanb ucora.com> writes:
On Monday, 7 January 2013 at 22:21:59 UTC, Chris wrote:

 Another thing, IMO, is that there is an overemphasis on C++ vs. 
 D. Usually people have to choose between systems programming 
 (learn C/C++) or high level (learn Python, Ruby etc.). Most 
 non-programmers who need to write a piece of software opt for 
 Python and other scripting languages, because nobody wants to 
 learn C/C++ only to write a small parser for data files. With D 
 you no longer have to choose. You can write both quick and 
 dirty script-like stuff and stuff that is close to the machine. 
 Python and Ruby took off, I think, because they appealed to 
 people who are not fully fledged programmers but who want or 
 need to do some programming. This is the crowd the D community 
 has to get on board. Don't forget that this is what has made 
 JavaScript one of the most widely used languages (alas!).


A really important advantage that scripting languages provides 
that D does not currently provide, is direct runtime 
interpretation of the language. This is very important for the 
use cases of script languages such as Ruby and PHP, because often 
they are used for coding and testing on the fly, ie., used in an 
environment that requires frequent changes with almost instant 
feedback.

You can also embed a scripting language directly into other 
applications, and store "code" as data, which can be transmitted 
from one machine to another over the wire. We can store and 
transmit D code too, but getting it to automatically run on the 
other end is not so easy or convenient.

All of these things D, as a language, probably can do (although 
perhaps only as a subset of the full language), but the tools are 
simply not there yet.

A language such as C++ seems like a bad fit for a scripting 
language because of it's complexity and the difficultly with 
parsing through it. Also a scripted language probably should not 
have low level access that is provided by languages such as D and 
C/C++.

--rt
Jan 14 2013
next sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Tuesday, 15 January 2013 at 06:30:33 UTC, Rob T wrote:


 A really important advantage that scripting languages provides 
 that D does not currently provide, is direct runtime 
 interpretation of the language. This is very important for the 
 use cases of script languages such as Ruby and PHP, because 
 often they are used for coding and testing on the fly, ie., 
 used in an environment that requires frequent changes with 
 almost instant feedback.


This is true. On the other hand, if you do quick and dirty stuff 
(count the frequency of certain words, parse data files etc.), 
the compilation time is not really an issue, and due to 
unnecessarily ugly syntax (PHP, Perl) or indentation (t)errors 
(Python) you sometimes lose time, or cannot just copy and paste 
snippets to test them without checking your spaces.

[...]


 A language such as C++ seems like a bad fit for a scripting 
 language because of it's complexity and the difficultly with 
 parsing through it. Also a scripted language probably should 
 not have low level access that is provided by languages such as 
 D and C/C++.

 --rt


Why not? In my experience small scripts often turn into bigger 
programs and sooner or later you need some sort of low level 
features. Then you have to write modules in C/C++ and use Swig or 
something to integrate them. That's why I prefer D, because you 
can get the whole shebang _if necessary_. There are also 
copyright issues. If you deliver a Python program, anyone could 
rip it, even if you compile it to byte code. If you distribute 
native executables, it's harder to rip your program. In general, 
I find scripting languages less useful for projects that (might) 
develop into something bigger. Now that I come to think of it, 
scripting languages are inherently "quick and dirty", that's why 
they are not really scalable (think of the class system in Python 
and Lua, not the real deal).
Jan 15 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Chris:


 or indentation (t)errors (Python)


In practice Python usually decreases the number of 
indentation-related bugs, even considering the "dangling else" 
warning we have added to D, because indentation and block nesting 
are the same thing, it's more DRY :-)

Bye,
bearophile
Jan 15 2013
next sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Tuesday, 15 January 2013 at 11:00:29 UTC, bearophile wrote:

 Chris:


 or indentation (t)errors (Python)


 In practice Python usually decreases the number of 
 indentation-related bugs, even considering the "dangling else" 
 warning we have added to D, because indentation and block 
 nesting are the same thing, it's more DRY :-)

 Bye,
 bearophile


Maybe it does, but it's annoying while you are writing it, and to 
be honest, indentation bugs are far and few between, in my 
experience, if you use the curly braces consistently. Only you 
have more freedom. What I was referring to was the annoying 
Python message "Wrong indentation in line ...", when you run a 
script, which makes it hard to copy & paste and just test a 
snippet, before you integrate it properly. Well, that's me. Other 
people like rules and regulations.
Jan 15 2013
parent reply David <d dav1d.de> writes:
 Maybe it does, but it's annoying while you are writing it, and to be
 honest, indentation bugs are far and few between, in my experience, if
 you use the curly braces consistently. Only you have more freedom. What
 I was referring to was the annoying Python message "Wrong indentation in
 line ...", when you run a script, which makes it hard to copy & paste
 and just test a snippet, before you integrate it properly. Well, that's
 me. Other people like rules and regulations.
 


Stereotypes of people who never actually used it, other than tried it
and gave up because they didn't configure their editor correctly and
blaming python for it. I bet my last indentation error was more than two
years ago.
Jan 15 2013
parent "Chris" <wendlec tcd.ie> writes:
On Tuesday, 15 January 2013 at 11:43:58 UTC, David wrote:


 Stereotypes of people who never actually used it, other than 
 tried it
 and gave up because they didn't configure their editor 
 correctly and
 blaming python for it. I bet my last indentation error was more 
 than two
 years ago.


Not a stereotype, sorry to disappoint you, I have used Python 
quite a lot in my job (and still do). My point is, as soon as you 
have to use a specialized editor and configure the editor to 
format Python properly, there is something wrong, in my opinion. 
A language shouldn't depend on indentation. Indentation is just a 
means to an end (=readability) but not an end in itself. To make 
it part of the syntax is over the top, if not neurotic. Everyone 
in his or her right mind will use some kind of formatting anyway 
and avoid spaghetti code. No need to enforce it. It should be up 
to the programmer / team how to do this. But this is not a Python 
forum, and I am quite happy with the C-style D offers.
Jan 15 2013
prev sibling parent reply 1100110 <0b1100110 gmail.com> writes:
On 01/15/2013 05:00 AM, bearophile wrote:

 Chris:


 or indentation (t)errors (Python)


 In practice Python usually decreases the number of indentation-related
 bugs,


Thats so funny I forgot to laugh.
Jan 15 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
1100110:


 Thats so funny I forgot to laugh.


One common indentation-related bug is caused by relying on the 
indentation to understand code, while the curly brace language 
compiler ignores what you were seeing and only sees the braces. I 
have seen many cases of delayed code understanding caused by 
that. Making the syntax more DRY (this means stating the logical 
indentation using only one communication channel) helps avoid 
those mistakes (and reduces the visual noise, further helping 
code readability).

Bye,
bearophile
Jan 15 2013
next sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Tuesday, 15 January 2013 at 12:09:21 UTC, bearophile wrote:

 1100110:


 Thats so funny I forgot to laugh.


 One common indentation-related bug is caused by relying on the 
 indentation to understand code, while the curly brace language 
 compiler ignores what you were seeing and only sees the braces. 
 I have seen many cases of delayed code understanding caused by 
 that. Making the syntax more DRY (this means stating the 
 logical indentation using only one communication channel) helps 
 avoid those mistakes (and reduces the visual noise, further 
 helping code readability).

 Bye,
 bearophile


That's not my experience. Nested for loops with if-statements can 
be hard on the eye in Python, because you have to go back an 
double check on which level you actually are and the fact that 
one missing white space (a typo after deleting a line) screws up 
the whole script is just annoying. The Python indentation terror 
is a peculiar personal preference enshrined in the language's 
syntax. It's simply not my style.
Jan 15 2013
next sibling parent reply David <d dav1d.de> writes:
 That's not my experience. Nested for loops with if-statements can be
 hard on the eye in Python, because you have to go back an double check
 on which level you actually are and the fact that one missing white
 space (a typo after deleting a line) screws up the whole script is just
 annoying. The Python indentation terror is a peculiar personal
 preference enshrined in the language's syntax. It's simply not my style.
 


If you use notepad to write your Python Code yes. If you see yourself
too many indentation levels, that's a good indicator you're writing bad
code (bad is the wrong term, but can't think of the correct english word).
Jan 15 2013
parent David <d dav1d.de> writes:
Am 15.01.2013 13:23, schrieb David:

 That's not my experience. Nested for loops with if-statements can be
 hard on the eye in Python, because you have to go back an double check
 on which level you actually are and the fact that one missing white
 space (a typo after deleting a line) screws up the whole script is just
 annoying. The Python indentation terror is a peculiar personal
 preference enshrined in the language's syntax. It's simply not my style.


 
 If you use notepad to write your Python Code yes. If you see yourself
 too many indentation levels, that's a good indicator you're writing bad
 code (bad is the wrong term, but can't think of the correct english word).
 


I think we are getting into a language flame, we should probably stop
here. I love Pythons indentation because of various reasons, you don't
like them.
Jan 15 2013
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Chris:


 Nested for loops with if-statements can be hard on the eye in 
 Python, because you have to go back an double check on which 
 level you actually are


If you use the standard 4 spaces indentations and you don't have 
ten indentation levels this problem is not common. Some persons 
also avoid your problem with an editor that shows thin vertical 
lines every 4 spaces (but only where the lines are actually 
reaching that length).



 and the fact that one missing white space (a typo after 
 deleting a line) screws up the whole script is just annoying.


It's a small price to pay for increased code readability. And if 
I see one missing white space in D code, I fix it right now, so 
there is not a lot of difference.



 The Python indentation terror is a peculiar personal preference 
 enshrined in the language's syntax. It's simply not my style.


Curiously the Python significant syntax was the motive for me to 
start using Python in the first place, years ago. I was looking 
right for that, being fed up of begin-end, curly braces, and 
those code reading mistakes I was talking about.

Bye,
bearophile
Jan 15 2013
next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 15 January 2013 at 12:36:42 UTC, bearophile wrote:

 Chris:


 Nested for loops with if-statements can be hard on the eye in 
 Python, because you have to go back an double check on which 
 level you actually are


 If you use the standard 4 spaces indentations and you don't 
 have ten indentation levels this problem is not common. Some 
 persons also avoid your problem with an editor that shows thin 
 vertical lines every 4 spaces (but only where the lines are 
 actually reaching that length).



 and the fact that one missing white space (a typo after 
 deleting a line) screws up the whole script is just annoying.


 It's a small price to pay for increased code readability. And 
 if I see one missing white space in D code, I fix it right now, 
 so there is not a lot of difference.



 The Python indentation terror is a peculiar personal 
 preference enshrined in the language's syntax. It's simply not 
 my style.


 Curiously the Python significant syntax was the motive for me 
 to start using Python in the first place, years ago. I was 
 looking right for that, being fed up of begin-end, curly 
 braces, and those code reading mistakes I was talking about.

 Bye,
 bearophile



Although Python gets bashed a lot due to this issue, it is not 

rules.
Jan 15 2013
prev sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Tuesday, 15 January 2013 at 12:36:42 UTC, bearophile wrote:

 Chris:


 Nested for loops with if-statements can be hard on the eye in 
 Python, because you have to go back an double check on which 
 level you actually are


 If you use the standard 4 spaces indentations and you don't 
 have ten indentation levels this problem is not common. Some 
 persons also avoid your problem with an editor that shows thin 
 vertical lines every 4 spaces (but only where the lines are 
 actually reaching that length).


It happens very quickly if you have a class, a def, a nested for 
loop with one or two if statements

class:
     def:
         for:
             if:

You could call it "south west" code.



 Curiously the Python significant syntax was the motive for me 
 to start using Python in the first place, years ago. I was 
 looking right for that, being fed up of begin-end, curly 
 braces, and those code reading mistakes I was talking about.

 Bye,
 bearophile


It's simply not my style. I don't believe indentation should be a 
rule. I clean up my code in my own way.
Jan 15 2013
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 15 January 2013 at 13:43:12 UTC, Chris wrote:

 On Tuesday, 15 January 2013 at 12:36:42 UTC, bearophile wrote:

 Chris:


 Nested for loops with if-statements can be hard on the eye in 
 Python, because you have to go back an double check on which 
 level you actually are


 If you use the standard 4 spaces indentations and you don't 
 have ten indentation levels this problem is not common. Some 
 persons also avoid your problem with an editor that shows thin 
 vertical lines every 4 spaces (but only where the lines are 
 actually reaching that length).


 It happens very quickly if you have a class, a def, a nested 
 for loop with one or two if statements

 class:
     def:
         for:
             if:

 You could call it "south west" code.



 Curiously the Python significant syntax was the motive for me 
 to start using Python in the first place, years ago. I was 
 looking right for that, being fed up of begin-end, curly 
 braces, and those code reading mistakes I was talking about.

 Bye,
 bearophile


 It's simply not my style. I don't believe indentation should be 
 a rule. I clean up my code in my own way.


I used to think like that a few decades ago.

Then I started working in multi-site projects with developers 
from all types of backgrounds, and understood the value of a 
consistent project code formatting.

--
Paulo
Jan 15 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/15/2013 8:37 AM, Paulo Pinto wrote:

 Then I started working in multi-site projects with developers from all types of
 backgrounds, and understood the value of a consistent project code formatting.


I agree with the value as you say, but as I posted previously I think
consistent 
formatting is the job of a source code formatter, not the language.
Jan 15 2013
parent "pjmlp" <pjmlp progtools.org> writes:
On Tuesday, 15 January 2013 at 20:07:49 UTC, Walter Bright wrote:

 On 1/15/2013 8:37 AM, Paulo Pinto wrote:

 Then I started working in multi-site projects with developers 
 from all types of
 backgrounds, and understood the value of a consistent project 
 code formatting.


 I agree with the value as you say, but as I posted previously I 
 think consistent formatting is the job of a source code 
 formatter, not the language.


Sure, I was speaking in general.

Even better, have some kind of indent tool run as part of the
check-in process.
Jan 15 2013
prev sibling parent "Chris" <wendlec tcd.ie> writes:
 class:
     def:
         for:
             if:

 You could call it "south west" code.


Recte: South east code, of course!


 Then I started working in multi-site projects with developers 
 from all types of backgrounds, and understood the value of a 
 consistent project code formatting.

 --
 Paulo


In most languages, there are coding conventions, and projects 
should have consistent formatting. I agree. However, I think 
indentation as part of the syntax is highly exaggerated. A 
language can and should protect programmers from making stupid or 
common mistakes and offer features that make programming more 
efficient and software more reliable. To enforce a certain 
aesthetic style, based on personal preferences more often than 
not, should not be part of the language, but up to the teams that 
use the language. On top of that, Python code can be messy too 
(although it might look "nice"). In _my_ experience, readability 
is often impeded by the use of obscure variable and function 
names.

v = r.calc(m.get_p() / m.get_r())

What is "v", what is calc() calculating ...?

Such code can be due to laziness or arrogance. But no language 
feature can prevent bad or lazy programmers from producing such 
code, even if it's nicely formatted.

Anyway, 1,000 programmers will have 1,001 views on coding style.
Jan 15 2013
prev sibling parent reply "renoX" <renozyx gmail.com> writes:
On Tuesday, 15 January 2013 at 13:43:12 UTC, Chris wrote:

 On Tuesday, 15 January 2013 at 12:36:42 UTC, bearophile wrote:

 Chris:


 Nested for loops with if-statements can be hard on the eye in 
 Python, because you have to go back an double check on which 
 level you actually are


 If you use the standard 4 spaces indentations and you don't 
 have ten indentation levels this problem is not common. Some 
 persons also avoid your problem with an editor that shows thin 
 vertical lines every 4 spaces (but only where the lines are 
 actually reaching that length).


 It happens very quickly if you have a class, a def, a nested 
 for loop with one or two if statements

 class:
     def:
         for:
             if:

 You could call it "south west" code.


I'm not sure what is your point, even with 5 level of 
indentations and the standard 4 space indentations, on a normal 
80 colum window you still have 3/4 of the window for the code..

renoX
Jan 16 2013
parent reply "Chris" <wendlec tcd.ie> writes:
On Wednesday, 16 January 2013 at 15:55:09 UTC, renoX wrote:

 On Tuesday, 15 January 2013 at 13:43:12 UTC, Chris wrote:

 On Tuesday, 15 January 2013 at 12:36:42 UTC, bearophile wrote:

 Chris:


 Nested for loops with if-statements can be hard on the eye 
 in Python, because you have to go back an double check on 
 which level you actually are


 If you use the standard 4 spaces indentations and you don't 
 have ten indentation levels this problem is not common. Some 
 persons also avoid your problem with an editor that shows 
 thin vertical lines every 4 spaces (but only where the lines 
 are actually reaching that length).


 It happens very quickly if you have a class, a def, a nested 
 for loop with one or two if statements

 class:
    def:
        for:
            if:

 You could call it "south west" code.


 I'm not sure what is your point, even with 5 level of 
 indentations and the standard 4 space indentations, on a normal 
 80 colum window you still have 3/4 of the window for the code..

 renoX


My point is that Python code is not necessarily more readable 
only because it enforces indentation via syntax. If the code 
between the different blocks (for, if, else etc) is long enough, 
you easily lose track of where exactly you are when scrolling 
down, just like in any other language (Yes, you need tools that 
help you!). And one of the biggest drawbacks is that it is a 
nuisance to cut and paste or comment out in Python because you 
have to format your code _before_ you even know whether it works 
as desired. If it doesn't, all the extra formatting work was in 
vain. So much for "saving time". I do believe that abstract 
ideals should not be given precedence over (coding) reality. If 
Python is the ideal, why and how do other languages manage to 
survive? How can people read code written in other languages at 
all?

As has been said many times before, it should not be the 
language's job to enforce indentation. This should be handled by 
customizable code editors. Any programmer in his/her right mind 
will use indentation. So why enforce it through syntax rules?
Jan 21 2013
parent "Peter Sommerfeld" <noreply rubrica.at> writes:
Am 21.01.2013, 15:42 Uhr, schrieb Chris <wendlec tcd.ie>:

 As has been said many times before, it should not be the language's job  
 to enforce indentation. This should be handled by customizable code  
 editors. Any programmer in his/her right mind will use indentation. So  
 why enforce it through syntax rules?


The discussion about using indentation as block delemeter is a holly
war about personal preferences IMHO.

There is a strong argument against enforced indentation: Automatic
code generation is hard or even impossible in languages like Python.
I don't think it makes any sense in languages with generics.

Much more important is an  orthogonal and consistent syntax...

Peter
Jan 21 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/15/2013 4:09 AM, bearophile wrote:

 One common indentation-related bug is caused by relying on the indentation to
 understand code, while the curly brace language compiler ignores what you were
 seeing and only sees the braces. I have seen many cases of delayed code
 understanding caused by that. Making the syntax more DRY (this means stating
the
 logical indentation using only one communication channel) helps avoid those
 mistakes (and reduces the visual noise, further helping code readability).


This is the job of a syntax aware editor (and other source code formatting 
tools), not the language. In my not-so-humble opinion.

BTW, I'd like to see a source code formatter for D. Anyone want to step up?
Jan 15 2013
parent reply "Regan Heath" <regan netmail.co.nz> writes:
On Tue, 15 Jan 2013 20:06:05 -0000, Walter Bright  
<newshound2 digitalmars.com> wrote:


 On 1/15/2013 4:09 AM, bearophile wrote:

 One common indentation-related bug is caused by relying on the  
 indentation to
 understand code, while the curly brace language compiler ignores what  
 you were
 seeing and only sees the braces. I have seen many cases of delayed code
 understanding caused by that. Making the syntax more DRY (this means  
 stating the
 logical indentation using only one communication channel) helps avoid  
 those
 mistakes (and reduces the visual noise, further helping code  
 readability).


 This is the job of a syntax aware editor (and other source code  
 formatting tools), not the language. In my not-so-humble opinion.

 BTW, I'd like to see a source code formatter for D. Anyone want to step  
 up?


In an ideal world the source code would be stored in file on disk in some  
"standard" format, and displayed in each programmers editor in their own  
preferred format.  It could end all arguments about code formatting, for  
good.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Jan 16 2013
parent "mist" <none none.none> writes:
On Wednesday, 16 January 2013 at 10:59:46 UTC, Regan Heath wrote:

 In an ideal world the source code would be stored in file on 
 disk in some "standard" format, and displayed in each 
 programmers editor in their own preferred format.  It could end 
 all arguments about code formatting, for good.

 R


It is partially achievable now with IDE's auto-formatting tools 
and git commit hooks. Not on disk, of course, but repo is more 
relevant.
Jan 16 2013
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 15 January 2013 at 12:09:21 UTC, bearophile wrote:

 1100110:


 Thats so funny I forgot to laugh.


 One common indentation-related bug is caused by relying on the 
 indentation to understand code, while the curly brace language 
 compiler ignores what you were seeing and only sees the braces. 
 I have seen many cases of delayed code understanding caused by 
 that. Making the syntax more DRY (this means stating the 
 logical indentation using only one communication channel) helps 
 avoid those mistakes (and reduces the visual noise, further 
 helping code readability).


The sane option are either to acknowledge that code is in a text 
file and choose syntax construct that make it readable (python) 
or decorrelate the presentation of the code from its actual form 
in the file and use a formatted.

Other options are choosing on purpose to inflict an extra 
workload to yourself, and risking confusion on badly formatted 
code.
Jan 21 2013
parent "Rob T" <alanb ucora.com> writes:
On Tuesday, 22 January 2013 at 03:00:59 UTC, deadalnix wrote:

 The sane option are either to acknowledge that code is in a 
 text file and choose syntax construct that make it readable 
 (python) or decorrelate the presentation of the code from its 
 actual form in the file and use a formatted.


Out of the two options, I would say that the correctness of the 
source should not be dependent on how it is formatted. One 
advantage of this, is that you can compact the source by removing 
all unnecessary white space and line returns. Another reason is 
that source code can be automatically generated without the 
costly complication of having to correctly format it.

Compacted source code works well for transmission over a network 
and for storage in a database. Sure, speeds are high and storage 
is cheap, but if you consider something like javascript, there's 
an overall huge amount of continual resource waste when 
needlessly formatted code is transmitted, interpreted, and 
stored. This is why JS code is usually compacted when it goes 
into a release state.

--rt
Jan 22 2013
prev sibling parent reply "Rob T" <alanb ucora.com> writes:
On Tuesday, 15 January 2013 at 10:22:20 UTC, Chris wrote:

 A language such as C++ seems like a bad fit for a scripting 
 language because of it's complexity and the difficultly with 
 parsing through it. Also a scripted language probably should 
 not have low level access that is provided by languages such 
 as D and C/C++.

 --rt


 Why not? In my experience small scripts often turn into bigger 
 programs and sooner or later you need some sort of low level 
 features. Then you have to write modules in C/C++ and use Swig 
 or something to integrate them. That's why I prefer D, because 
 you can get the whole shebang _if necessary_. There are also 
 copyright issues. If you deliver a Python program, anyone could 
 rip it, even if you compile it to byte code. If you distribute 
 native executables, it's harder to rip your program. In 
 general, I find scripting languages less useful for projects 
 that (might) develop into something bigger. Now that I come to 
 think of it, scripting languages are inherently "quick and 
 dirty", that's why they are not really scalable (think of the 
 class system in Python and Lua, not the real deal).


For many applications where a scripted language really shines, 
there are usually security related issues that require placing 
strict limitations on what the scripts are allowed to do. You 
have to understand that the scripts tend to be implemented by the 
users of the system, rather than just the original developers. 
Also code may be transmitted from one machine to another and 
executed, so you have to be careful that malicious code cannot do 
much harm.

I agree with your comment about larger projects that are 
scripted. I think you'll tend to use large applications like that 
in environments where the scripting provides little to no 
advantages, and it becomes mostly a disadvantage in terms of 
eating up resources for no good reason. I can see an advantage 
for the developers, but the users of the application tends to 
suffer, so if the application could later be compiled to native 
machine code for distribution, that would close the gap.

--rt
Jan 15 2013
parent "Chris" <wendlec tcd.ie> writes:
 For many applications where a scripted language really shines, 
 there are usually security related issues that require placing 
 strict limitations on what the scripts are allowed to do. You 
 have to understand that the scripts tend to be implemented by 
 the users of the system, rather than just the original 
 developers. Also code may be transmitted from one machine to 
 another and executed, so you have to be careful that malicious 
 code cannot do much harm.



 I agree with your comment about larger projects that are 
 scripted. I think you'll tend to use large applications like 
 that in environments where the scripting provides little to no 
 advantages, and it becomes mostly a disadvantage in terms of 
 eating up resources for no good reason. I can see an advantage 
 for the developers, but the users of the application tends to 
 suffer, so if the application could later be compiled to native 
 machine code for distribution, that would close the gap.

 --rt


But scripting languages still can do a lot of harm, even if they 
are not as low level as C/C++ or D. But transmission is actually 
an issue. Scripting languages are better for this purpose. My 
point is that developers should think twice before using 
scripting languages, because the disadvantages may sooner or 
later outweigh the initial advantage of "ease of use" and "no 
compilation time". A lot of cross-platform software is still 
written in C and C++, not without a reason. What D can offer here 
is modern (scripting like) convenience plus cross platform native 
machine code.
Jan 16 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/14/2013 10:30 PM, Rob T wrote:

 A really important advantage that scripting languages provides that D does not
 currently provide, is direct runtime interpretation of the language. This is
 very important for the use cases of script languages such as Ruby and PHP,
 because often they are used for coding and testing on the fly, ie., used in an
 environment that requires frequent changes with almost instant feedback.


The way this is currently done is to put the code that would otherwise be in a 
script into a DLL, and then the dev process becomes:

1. run program
2. dynamically load DLL with "script"
3. debug
4. change "script" code
5. recompile "script" into new DLL
6. reload DLL
7. rinse, repeat

It turns out that step 5 is nearly instant, on the order of a few seconds.

The hair in the process, however, is DLLs still need better support in D.


 You can also embed a scripting language directly into other applications, and
 store "code" as data, which can be transmitted from one machine to another over
 the wire. We can store and transmit D code too, but getting it to automatically
 run on the other end is not so easy or convenient.


Just so you know, we have a Javascript engine written in D, meaning you can 
embed Javascript.
Jan 15 2013
parent "Rob T" <alanb ucora.com> writes:
On Tuesday, 15 January 2013 at 20:02:58 UTC, Walter Bright wrote:

 On 1/14/2013 10:30 PM, Rob T wrote:

 A really important advantage that scripting languages provides 
 that D does not
 currently provide, is direct runtime interpretation of the 
 language. This is
 very important for the use cases of script languages such as 
 Ruby and PHP,
 because often they are used for coding and testing on the fly, 
 ie., used in an
 environment that requires frequent changes with almost instant 
 feedback.


 The way this is currently done is to put the code that would 
 otherwise be in a script into a DLL, and then the dev process 
 becomes:

 1. run program
 2. dynamically load DLL with "script"
 3. debug
 4. change "script" code
 5. recompile "script" into new DLL
 6. reload DLL
 7. rinse, repeat

 It turns out that step 5 is nearly instant, on the order of a 
 few seconds.


Doing that is still more difficult in terms of technical skills. 
Also even when you have the skills, you need more access to 
perform code modifications remotely. Often too, you do not want 
to take down the entire application to make a quick fix to some 
bad code.

I think fully scripted languages appeal to the less technically 
inclined who prefer to "just get it done" with the least amount 
of hassle.

I'll suggest that the gap can be filled between scripted and 
compiled in a way that may get some serious attention. The rapid 
development process of a scripted language loses its advantage 
the minute the code stabilizes because at the point of stability, 
the interpretation process becomes a burden on resources without 
any advantages. If the stable scripted code can be compiled and 
linked in, then it gains the advantages of a compiled language.

This is an important point, because companies with large server 
farms are aware that they are paying far more money for 
processing power than they need to because their servers are 
running scripted code most of the time. For example, Twitter 
moved from Ruby to Java to gain performance, so imagine what they 
could get if they moved to something like D instead.


 The hair in the process, however, is DLLs still need better 
 support in D.


Yes, having full DLL support will help, and I cannot wait for 
that support.

When we say "DLL" that usually means Microsoft's implementation 
of dynamic linking, but we need support for Linux too. Also 
please do not overlook the importance of dynamically loaded 
libraries (loaded during runtime) for implementing loadable 
plugins giving you extensibility options like what you see with 
Firefox and other popular applications. Once D has plugin 
support, I'll be very happy.


 You can also embed a scripting language directly into other 
 applications, and
 store "code" as data, which can be transmitted from one 
 machine to another over
 the wire. We can store and transmit D code too, but getting it 
 to automatically
 run on the other end is not so easy or convenient.


 Just so you know, we have a Javascript engine written in D, 
 meaning you can embed Javascript.


I knew about it, but I read somewhere that it was not fully 
compatible with the version of JS that is being used for web 
related work, is this correct? Still, it can be useful to have a 
look at it to see how it does its job.

I wonder if the work on the CTFE can be somehow spun off into an 
embeddable D interpreter?

--rt
Jan 15 2013