Re: A look at the D programming language by Ferdynand Górski
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
Re: A look at the D programming language by Ferdynand Górski
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?
Re: A look at the D programming language by Ferdynand Górski
Am 21.01.2013, 15:42 Uhr, schrieb Chris wend...@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
Re: A look at the D programming language by Ferdynand Górski
On Tue, 15 Jan 2013 20:06:05 -, Walter Bright newshou...@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/
Re: A look at the D programming language by Ferdynand Górski
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).
Re: A look at the D programming language by Ferdynand Górski
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
Re: A look at the D programming language by Ferdynand Górski
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.
Re: A look at the D programming language by Ferdynand Górski
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.
Re: A look at the D programming language by Ferdynand Górski
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.
Re: A look at the D programming language by Ferdynand Górski
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
Re: A look at the D programming language by Ferdynand Górski
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.
Re: A look at the D programming language by Ferdynand Górski
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.
Re: A look at the D programming language by Ferdynand Górski
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.
Re: A look at the D programming language by Ferdynand Górski
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).
Re: A look at the D programming language by Ferdynand Górski
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.
Re: A look at the D programming language by Ferdynand Górski
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.
Re: A look at the D programming language by Ferdynand Górski
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
Re: A look at the D programming language by Ferdynand Górski
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.
Re: A look at the D programming language by Ferdynand Górski
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.
Re: A look at the D programming language by Ferdynand Górski
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?
Re: A look at the D programming language by Ferdynand Górski
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.
Re: A look at the D programming language by Ferdynand Górski
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
Re: A look at the D programming language by Ferdynand Górski
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
Re: A look at the D programming language by Ferdynand Górski
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.
Re: A look at the D programming language by Ferdynand Górski
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.
Re: A look at the D programming language by Ferdynand Górski
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.
Re: A look at the D programming language by Ferdynand Górski
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
Re: A look at the D programming language by Ferdynand Górski
On 2013-01-07 11:31:45 +, 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.
Re: A look at the D programming language by Ferdynand Górski
On Monday, 7 January 2013 at 11:48:36 UTC, Max Klyga wrote: On 2013-01-07 11:31:45 +, 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... :)
Re: A look at the D programming language by Ferdynand Górski
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?
Re: A look at the D programming language by Ferdynand Górski
On 2013-01-07 09:32:30 +, 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/
Re: A look at the D programming language by Ferdynand Górski
On 2013-01-07 11:55:59 +, 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.
Re: A look at the D programming language by Ferdynand Górski
On Monday, 7 January 2013 at 12:26:12 UTC, Max Klyga wrote: On 2013-01-07 09:32:30 +, 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.
Re: A look at the D programming language by Ferdynand Górski
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
Re: A look at the D programming language by Ferdynand Górski
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. ;)
Re: A look at the D programming language by Ferdynand Górski
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.
Re: A look at the D programming language by Ferdynand Górski
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
Re: A look at the D programming language by Ferdynand Górski
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.
Re: A look at the D programming language by Ferdynand Górski
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
Re: A look at the D programming language by Ferdynand Górski
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...
Re: A look at the D programming language by Ferdynand Górski
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
Re: A look at the D programming language by Ferdynand Górski
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.
Re: A look at the D programming language by Ferdynand Górski
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 :)
Re: A look at the D programming language by Ferdynand Górski
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!).
