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(): http://dlang.org/phobos/object.html#.TypeInfo.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 the only language doing that. Haskell, OCaml and F# have similar 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