Re: Scott Meyers wants to bring default zero-initialization to C++, mentions TDPL for precedent
On Friday, 20 November 2015 at 20:37:10 UTC, deadalnix wrote: On Friday, 20 November 2015 at 12:12:42 UTC, Chris wrote: Would you guys please stop calling PHP a language. JS and PHP are not languages, they are a fiddly feckin mess, which accounts for their high adoption rate. Sigh. Please, no gainsaying now, no "Yes, buts". You may say that, yet, it both are widely used. There are reasons for that, and people are idiot is not one of them. It is a big part of the reasons. PHP scales. This is why people use it. And this is why people will continue to use it. This is why Facebook, wikipedia, Baidu, wordpress and many others are using it. There is always a reason, and if you don't understand it, you are doomed to miss the point. Whut? PHP scales?! If you simply mean that it is easily coded by lowest-common denominator programmers, so it's easy to throw a bunch of those low-skilled coders on the job, then perhaps that's why you end up with monstrosities like this: http://quellish.tumblr.com/post/126712999812/how-on-earth-the-facebook-ios-application-is-so http://www.darkcoding.net/software/facebooks-code-quality-problem/ Potshots at your employer aside- ;) I could have done the same for Wikipedia and Wordpress, don't know much about Baidu- I'd honestly like to know how you think PHP scales, because it's success has always been a perfect example of Gresham's law to me: http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2015-06.html#e2015-06-14T09_17_33.htm
Re: foreach and element type inference
On Friday, 20 November 2015 at 19:43:16 UTC, Jack Stouffer wrote: On Friday, 20 November 2015 at 19:37:09 UTC, Nicolas F. wrote: My suggestion is to have the compiler output a specific error message should it encounter "auto" inside a foreach declaration, pointing out that "auto" is neither needed nor allowed in this context to get type inference. Sounds like a good idea! Please file an enhancement request on http://issues.dlang.org/ Yeah. Whenever you think that an error message is bad, and you have a better suggestion, please create an enhancement request for it. - Jonathan M Davis
Re: Scott Meyers wants to bring default zero-initialization to C++, mentions TDPL for precedent
On 11/20/2015 09:06 PM, Chris Wright wrote: ... When people complain about others being offended, it's usually to distract from the issue at hand. When people complain about others being offended, I think it is usually because being offended can be a way to artificially add weight to the issue at hand, and they feel treated unfairly. Sometimes, they have gotten offended themselves. It is always possible to inflate the issue at hand by generalizing and extending it until it can be put in the same category with only slightly related, but much worse issues. So let me say it straight: it doesn't matter whether I'm offended. It only matters what effect your words have on people. People should assume responsibility for their own actions and reactions.
Re: Here's looking at you, kid
On Friday, 20 November 2015 at 11:44:02 UTC, Chris wrote: On Friday, 20 November 2015 at 08:51:13 UTC, Warwick wrote: But keep burying you heads in the ground. Would you bother to define "beginners"? The getting started page says.. "absolute begginners" and IIRC "does not assume any prior programming experience". Or something like that. It's not my definition.
Re: Formal Review of std.range.ndslice
On Friday, 20 November 2015 at 21:23:40 UTC, Jack Stouffer wrote: On Friday, 20 November 2015 at 20:33:27 UTC, Ilya wrote: Great! Added to PR's TODO list :-) This will be interesting because there is no defined idiomatic usage of std.allocator. I imagine std.range.ndslice will be the trend-setter for Phobos in this regard. Slice is only a shell over a range/array. There is no reason to add any kind of counters or special stuff entities. All this idioms work out of the box because Slice holds an array. It is already works with std.container.array, and it will work with the future Array container based on allocators. -- Ilya
Re: Scott Meyers wants to bring default zero-initialization to C++, mentions TDPL for precedent
On Friday, 20 November 2015 at 22:01:58 UTC, Chris wrote: D is not in that league. Doesn't matter? It is clear you shit on things you don't understand. That makes you sound like an idiot to these who understand.
Re: Scott Meyers wants to bring default zero-initialization to C++, mentions TDPL for precedent
On Friday, 20 November 2015 at 20:37:10 UTC, deadalnix wrote: On Friday, 20 November 2015 at 12:12:42 UTC, Chris wrote: On Wednesday, 18 November 2015 at 19:09:48 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 18 November 2015 at 18:52:02 UTC, Jack Stouffer wrote: For those of you who have never had the pleasure of writing PHP, lots of PHP code does completely different things depending on the compiler switches when the interpreter was Php is a dynamic language, that's different. Would you guys please stop calling PHP a language. JS and PHP are not languages, they are a fiddly feckin mess, which accounts for their high adoption rate. Sigh. Please, no gainsaying now, no "Yes, buts". You may say that, yet, it both are widely used. There are reasons for that, and people are idiot is not one of them. PHP scales. This is why people use it. And this is why people will continue to use it. This is why Facebook, wikipedia, Baidu, wordpress and many others are using it. There is always a reason, and if you don't understand it, you are doomed to miss the point. D is not in that league.
Re: Formal Review of std.range.ndslice
On 11/20/15 4:23 PM, Jack Stouffer wrote: On Friday, 20 November 2015 at 20:33:27 UTC, Ilya wrote: Great! Added to PR's TODO list :-) This will be interesting because there is no defined idiomatic usage of std.allocator. I imagine std.range.ndslice will be the trend-setter for Phobos in this regard. There's the persistent list example that I posted on dpaste a couple weeks back. I do expect things to evolve a bit before stabilizing. BTW thanks Jack for reaching out via email. Andrei
Re: Formal Review of std.range.ndslice
On Friday, 20 November 2015 at 20:33:27 UTC, Ilya wrote: Great! Added to PR's TODO list :-) This will be interesting because there is no defined idiomatic usage of std.allocator. I imagine std.range.ndslice will be the trend-setter for Phobos in this regard.
Re: Referencer
On Friday, 20 November 2015 at 18:23:57 UTC, HaraldZealot wrote: All ranges in Phobos pass by value, but if I have output range with state like cumulative statistics this is useless. Realistically, output ranges really should be passed by ref, but I'm not sure whether that's really being done in Phobos at this point - though output ranges aren't used all that much in Phobos anyway. It's mostly input ranges, which are a very different beast. But if you just make it so that your output range is a reference type (e.g a class or a struct with a single pointer to its state), then you get around any issues caused by a function not accepting its output range by ref. - Jonathan M Davis
Re: Scott Meyers wants to bring default zero-initialization to C++, mentions TDPL for precedent
On Friday, 20 November 2015 at 12:12:42 UTC, Chris wrote: On Wednesday, 18 November 2015 at 19:09:48 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 18 November 2015 at 18:52:02 UTC, Jack Stouffer wrote: For those of you who have never had the pleasure of writing PHP, lots of PHP code does completely different things depending on the compiler switches when the interpreter was Php is a dynamic language, that's different. Would you guys please stop calling PHP a language. JS and PHP are not languages, they are a fiddly feckin mess, which accounts for their high adoption rate. Sigh. Please, no gainsaying now, no "Yes, buts". You may say that, yet, it both are widely used. There are reasons for that, and people are idiot is not one of them. PHP scales. This is why people use it. And this is why people will continue to use it. This is why Facebook, wikipedia, Baidu, wordpress and many others are using it. There is always a reason, and if you don't understand it, you are doomed to miss the point.
Re: Formal Review of std.range.ndslice
On Friday, 20 November 2015 at 19:21:45 UTC, Jack Stouffer wrote: On Wednesday, 18 November 2015 at 10:26:13 UTC, Ilya Yaroshenko wrote: On Wednesday, 18 November 2015 at 08:52:11 UTC, Robert burner Schadek wrote: [...] I have added makeSlice, however this function can be easily implemented by user: allocate array -> pass array to `sliced`. updated docs http://dtest.thecybershadow.net/artifact/website-7a646fdea76569e009844cdee5c93edab10980ca-ce47155797f387348826317811c4af0c/web/phobos-prerelease/std_experimental_range_ndslice.html --Ilya I spoke with Andrei over email and his opinion was that if this module makes any allocation that can't be avoided, then std.experimental.allocator should be integrated. Great! Added to PR's TODO list :-)
Re: Scott Meyers wants to bring default zero-initialization to C++, mentions TDPL for precedent
On Fri, 20 Nov 2015 16:48:06 +, Chris wrote: > On Friday, 20 November 2015 at 16:38:02 UTC, Chris Wright wrote: >> On Fri, 20 Nov 2015 12:12:41 +, Chris wrote: >> >>> On Wednesday, 18 November 2015 at 19:09:48 UTC, Ola Fosheim Grøstad >>> wrote: On Wednesday, 18 November 2015 at 18:52:02 UTC, Jack Stouffer wrote: > For those of you who have never had the pleasure of writing PHP, > lots of PHP code does completely different things depending on the > compiler switches when the interpreter was Php is a dynamic language, that's different. >>> >>> Would you guys please stop calling PHP a language. JS and PHP are not >>> languages, they are a fiddly feckin mess, which accounts for their >>> high adoption rate. Sigh. Please, no gainsaying now, no "Yes, buts". >> >> I'd rather limit the number of posts on this forum that contain >> contempt or dismissiveness. It's unfriendly and doesn't help anything. > > Now, now, no need to feel offended. No need to be condescending to me, either. I want this newsgroup to be helpful and friendly in its attitude. I think that's a reasonable goal, and I think most people here would agree that it would be good if that goal were achieved. When people complain about others being offended, it's usually to distract from the issue at hand. So let me say it straight: it doesn't matter whether I'm offended. It only matters what effect your words have on people. > Bashing programming languages is > part of programming. Never read any of those "Why [Python|PHP|JS|C++...] > sucks" articles on the internet? I've had the misfortune of having to > work with PHP and JS, and no shaming me will ever convince me that they > are serious languages. Anyway, > D is being bashed here all the time, haven't you noticed ;)
Re: Here's looking at you, kid
On Fri, 20 Nov 2015 16:59:28 +, Chris wrote: > On Friday, 20 November 2015 at 16:39:52 UTC, Chris Wright wrote: >> On Fri, 20 Nov 2015 14:41:04 +, Chris wrote: >>> Yep, what can one say. >>> >>> 1. Who goes to the language reference, when they want to _learn_ a >>> language? >> >> It's the obvious place if you're familiar with other programming >> languages. Tutorials tend to be geared toward people who have little to >> no programming experience, who view learning a new language (even in a >> paradigm they're used to) as a large thing. >> >> We were all there once, but we're not all there now. When I learn a new >> language, I want typically 20-30 lines of example code and a language >> reference. I can start writing code after reading a short example, and >> I can use the language reference to fill in the remaining gaps. The >> language reference is usually both denser and better categorized for my >> needs. >> >>> 2. If you really want to learn a language, you will learn it. There >>> are enough resources for D now, there's room for improvement, but >>> there always is. >> >> I was choosing between programming languages a while ago, most of which >> I hadn't used before. For each of them, it wasn't the case that I >> wanted to learn them, but I knew I probably wanted to use one of them. >> >> If any of them were as obtuse to learn as D, I would have skipped past >> them post haste. >> >> If I'm evaluating a programming language to start using at work, I will >> evaluate it on how easy it is for me to accomplish things in that >> language and how easy it will be for my coworkers to start using the >> language. My coworkers mostly know Ruby and are just tentatively >> switching to Java. Moving to Haskell probably isn't an option despite >> the existence of decent tutorials, but D is similar enough that they >> could learn -- assuming there are good tutorials readily available. >> >>> I know, catering for the "one second attention span" crowd is a recipe >>> for success, if you deal with PHP or JS. But D is not in that league. >>> Even if you cater for them, they will soon be frustrated anyway, >>> because for D you'll need a deeper understanding of things, sooner or >>> later. >> >> You were contemptuous toward PHP and JavaScript, and now you are being >> contemptuous toward people who are potentially interested in learning >> D. Please be more respectful. > > Have you been able to learn D? Yes or no? I have an unusually large tolerance for pain in technical terms. It tends to take me a long time to realize that it's hard to use a programming language. Recently, for instance, I tried using Nim. I spent several months on it before I realized that I was debugging library errors and was about to dive into the compiler's semantic analysis code to fix a problem and it was stopping me from writing the code I wanted to write. That sort of tolerance, that sort of ignorance about the painfulness of a situation, let me learn D ten years ago. I also spent a fair bit of time learning D. It was my own time, no one else's. I was free to spend months learning the language, if that was what it took. And again, I learned probably 4-5 programming languages last year. My coworkers, some of them, were having issues switching from Ruby to Java. They're quite competent at what they do, and they might be better at Ruby than I ever will be, but they won't quickly switch in the best case. With the existing tutorials, it'd be far worse. This alone would suffice to make D not be a viable option for my employer. Of course, we also have to contend with the poor library situation. > I'm sorry, if If your apology starts with "I'm sorry if", it's not an apology, and most of the time you're better off omitting the statement entirely. > I'm not always politically correct Most of the time, "politically correct" means being respectful to others, except the speaker intends to indicate that that is a bad thing. > and I'm the first one to understand the needs of > programming novices, because we've all been there (as you pointed out). Which gives you no special advantage over anyone else, so I'm having a hard time seeing how you're "the first one to understand the needs of programming novices", especially since you seem to be advocating against making more tutorials and making them easier to find. > My point is that for D you will need a deeper understanding of things, > and Ali's book provides this. Before you seemed to be saying that the language reference provides this. Ali's book is much heavier in prose and provides much more guidance than the language reference. Making Ali's book much more prominent, and especially more prominent than the language reference, would be awesome. Python, for instance, has a language reference, but it recommends tutorials for you first, and while it shows you the language reference, it warns that it can be rather dry. > D is not like Javscript where type > "al
Re: Referencer
On Friday, 20 November 2015 at 18:48:51 UTC, Alex Parrill wrote: On Friday, 20 November 2015 at 18:23:57 UTC, HaraldZealot wrote: I'm not sure how useful this is as opposed to plain pointers. For structs, since `foo.bar` is the same as `(&foo).bar`, you may as well use a pointer, and the only thing it saves for numbers is a pointer deference or two. I realized that for my initial purposes simple pointer simply work, but when I'm trying make as possible universal template as it can be, I discover that the main problem with direct operators (and this touches not only numbers). You say ranges are pass-by-value, but that's not entirely true. Ranges themselves can be classes, or be made references via std.range.refRange. Range elements can be made lvalues by using ref functions [1]. Possible refRange is what I was looking for. Thanks. As for the code: * Your example usage (x = x += x = (x * 5)) is confusing, due to the chained assignments. This is special one of boundary cases, that clarify why is it so complicated to create full-functional wrapper.
Re: foreach and element type inference
On Friday, 20 November 2015 at 19:37:09 UTC, Nicolas F. wrote: My suggestion is to have the compiler output a specific error message should it encounter "auto" inside a foreach declaration, pointing out that "auto" is neither needed nor allowed in this context to get type inference. Sounds like a good idea! Please file an enhancement request on http://issues.dlang.org/
foreach and element type inference
Today I stumbled upon something somewhat confusing to me with
regards to type inference and foreach loops.
As hopefully people are aware, declaring variables works like
this:
int[] foo = [1, 2, 3, 4];
and declaring them with type inference works like this:
auto foo = [1, 2, 3, 4];
However, if we have a foreach loop, the following is the case:
foreach (int e; foo) { } // Works as expected
foreach (auto e; foo) { } // Does not work, "Error: basic type
expected, not auto"
foreach (e; foo) { } // Works, type inference!
Somebody on #d told me that this is due to "auto" being
essentially meaningless other than a keyword for saying "we're
declaring a variable", and since we're always declaring a
variable in the case of foreach, it'd be redundant.
Allowing "auto" here, as somebody pointed out, would lead to two
styles which may be confusing as one might mistake "foreach (e"
to be different from "foreach (auto e", and even worse, might be
led to believe that "e" was declared earlier in the former case.
Enforcing "auto" inside foreach declarations would break old code
for no reason other than adding a redundant keyword to make
things more obvious to people who don't know the semantic
workings of "foreach" (i.e. don't realise it's always a
declaration there).
The third, and in my opinion, most pragmatic approach to clearing
things up is to improve the compiler error message for this
special case of somebody trying to use "auto" inside foreach.
"Error: basic type expected, not auto" was misleading to me,
since it almost seems like it requires a basic type
syntactically, which it doesn't. This would also make things
clearer without actually changing the language spec.
TL;DR: My suggestion is to have the compiler output a specific
error message should it encounter "auto" inside a foreach
declaration, pointing out that "auto" is neither needed nor
allowed in this context to get type inference.
Any thoughts or opinions on this?
be mine
i suck the best dick int the wolrd
Re: Formal Review of std.range.ndslice
On Wednesday, 18 November 2015 at 10:26:13 UTC, Ilya Yaroshenko wrote: On Wednesday, 18 November 2015 at 08:52:11 UTC, Robert burner Schadek wrote: I couldn't easily find how to make the module work with allocators. IMO combining this module with std.experiemtal.allocator should be possible. And if it is already possible, there should be tests for documentation and validation. I have added makeSlice, however this function can be easily implemented by user: allocate array -> pass array to `sliced`. updated docs http://dtest.thecybershadow.net/artifact/website-7a646fdea76569e009844cdee5c93edab10980ca-ce47155797f387348826317811c4af0c/web/phobos-prerelease/std_experimental_range_ndslice.html --Ilya I spoke with Andrei over email and his opinion was that if this module makes any allocation that can't be avoided, then std.experimental.allocator should be integrated.
Re: Referencer
On Friday, 20 November 2015 at 18:23:57 UTC, HaraldZealot wrote: All ranges in Phobos pass by value, but if I have output range with state like cumulative statistics this is useless. After discussion with Dicebot I try this work-arround: http://dpaste.dzfl.pl/8af8eb8d0007 It is unfinished. But direction is observable. Is this good solution? And how about to include something like this tool in Phobos? I'm not sure how useful this is as opposed to plain pointers. For structs, since `foo.bar` is the same as `(&foo).bar`, you may as well use a pointer, and the only thing it saves for numbers is a pointer deference or two. You say ranges are pass-by-value, but that's not entirely true. Ranges themselves can be classes, or be made references via std.range.refRange. Range elements can be made lvalues by using ref functions [1]. As for the code: * Your example usage (x = x += x = (x * 5)) is confusing, due to the chained assignments. * I wouldn't mark this struct as @safe because the passed value may leave scope, causing invalid dereferences. * There's no point in making the Reference struct a template, as the function its defined in is also a template. Just replace usages of U with T. [1]: http://dlang.org/function.html#ref-functions see also std.range.interface.hasLvalueElements
Referencer
All ranges in Phobos pass by value, but if I have output range with state like cumulative statistics this is useless. After discussion with Dicebot I try this work-arround: http://dpaste.dzfl.pl/8af8eb8d0007 It is unfinished. But direction is observable. Is this good solution? And how about to include something like this tool in Phobos?
Re: Here's looking at you, kid
On Friday, 20 November 2015 at 18:11:41 UTC, Chris wrote: On Friday, 20 November 2015 at 17:57:06 UTC, Chris wrote: It seems clear that there are a variety of different types of people who would want to learn the language. Maybe split up the Getting Started page to a few sections, like "new programmers", "intermediate programmers", "expert programmers". IMO, it's not a good idea to classify people like that, because even a beginner might need advanced stuff and they might ignore the "advanced" section. Also, people might rate themselves as "intermediate" while they actually do pretty advanced stuff. Let's order by topic. It should come up when someone types "dlang set up socket", and so on. One important thing is to direct people to the right library modules. This is something that really confuses people. std.algorithm covers a lot of stuff that people would expect elsewhere. I think std.string already tells people to go to std.algorithm, but an overview would be nice. Strings std.string, std.algorithm (std.ascii etc) with a short explanation. Arrays etc. Basically a "Get sh*t done" page. To be clear with this I don't mean what's in the library section now like "std.stringAlgorithms that work specifically with strings." but something more practical, strings: wanna find a string in a string? Do this ...
Re: Here's looking at you, kid
On Friday, 20 November 2015 at 17:57:06 UTC, Chris wrote: It seems clear that there are a variety of different types of people who would want to learn the language. Maybe split up the Getting Started page to a few sections, like "new programmers", "intermediate programmers", "expert programmers". IMO, it's not a good idea to classify people like that, because even a beginner might need advanced stuff and they might ignore the "advanced" section. Also, people might rate themselves as "intermediate" while they actually do pretty advanced stuff. Let's order by topic. It should come up when someone types "dlang set up socket", and so on. One important thing is to direct people to the right library modules. This is something that really confuses people. std.algorithm covers a lot of stuff that people would expect elsewhere. I think std.string already tells people to go to std.algorithm, but an overview would be nice. Strings std.string, std.algorithm (std.ascii etc) with a short explanation. Arrays etc. Basically a "Get sh*t done" page.
Re: Here's looking at you, kid
On Friday, 20 November 2015 at 17:26:40 UTC, jmh530 wrote: On Friday, 20 November 2015 at 16:39:52 UTC, Chris Wright wrote: On Fri, 20 Nov 2015 14:41:04 +, Chris wrote: Yep, what can one say. 1. Who goes to the language reference, when they want to _learn_ a language? It's the obvious place if you're familiar with other programming languages. Tutorials tend to be geared toward people who have little to no programming experience, who view learning a new language (even in a paradigm they're used to) as a large thing. It seems clear that there are a variety of different types of people who would want to learn the language. Maybe split up the Getting Started page to a few sections, like "new programmers", "intermediate programmers", "expert programmers". IMO, it's not a good idea to classify people like that, because even a beginner might need advanced stuff and they might ignore the "advanced" section. Also, people might rate themselves as "intermediate" while they actually do pretty advanced stuff. Let's order by topic. It should come up when someone types "dlang set up socket", and so on.
Re: range.save
On Friday, 20 November 2015 at 16:35:01 UTC, Sönke Ludwig wrote:
The lowering of "foreach" to "for" would also have to be
adjusted accordingly.
I'm actually wondering if we should change it even to support the
way that we currently do things. The problem is that the
semantics of copying a range are undefined. They depend entirely
on how the range is implemented (value types, reference types,
and pseudo-reference types all act differently when copied). The
result is that if you want generic range-based code to work with
all range types, you can never use a range after it's been copied
unless it's assigned a new value - and foreach does a copy!
foreach(e; range)
{
// do stuff
}
->
for(auto __c = range; !__c.empty; __c.popFront())
{
auto e = __c.front;
// do stuff
}
So, in generic code, once you use foreach on a range, you can't
use it again. Something like
foreach(e; range)
{
if(cond)
break;
}
// do something with range again
is inherently broken. You're pretty much forced to use a naked
for loop, e.g.
for(; !range.empty; range.popFront())
{
auto e = range.front;
if(cond)
break;
}
// do something with range
So, what we really want is probably something more like
foreach(e; range)
{
// do stuff
}
->
for(; !range.empty; range.popFront())
{
auto e = range.front;
// do stuff
}
Unfortunately, that _does_ risk breaking some code with forward
ranges - but only because they're being implicitly saved, which
is arguably a bug. So, I'd be inclined to argue that the change
should be made - if nothing else, because any attempts to break
out of the loop are screwed with the currently lowering, and pure
input ranges can't be saved to work around the problem, meaning
that they're doubly screwed.
Now, that does have the downside of making foreach work
differently for arrays, since they don't use the normal range
lowering (rather, they're effectively saved), which means that
we're still pretty much screwed...
So, maybe what we need to do is have the foreach lowering check
for save and just call it if it exists so that pure input ranges
get
for(; !range.empty; range.popFront())
{
auto e = range.front;
// do stuff
}
whereas forward ranges get
for(auto __c = range.save; !__c.empty; __c.popFront())
{
auto e = __c.front;
// do stuff
}
That's more complicated, but it avoids breaking code while still
making it so that input ranges and foreach aren't quite so broken
- though it means that input ranges and forward ranges act
differently with foreach. But the alternative is basically tell
folks that they need to call save explicitly when using foreach
on forward ranges in generic code and to tell them that they
should never use foreach on pure input ranges unless they intend
to iterate over the whole range.
save tries to solve the copying problem with ranges, but the
overall situation is _far_ worse than just trying to make it so
that reference type ranges have a way to be copied properly.
- Jonathan M Davis
Re: Here's looking at you, kid
On Friday, 20 November 2015 at 17:06:52 UTC, David DeWitt wrote:
On Friday, 20 November 2015 at 16:59:30 UTC, Chris wrote:
Have you been able to learn D? Yes or no? I'm sorry, if I'm
not always politically correct and I'm the first one to
understand the needs of programming novices, because we've all
been there (as you pointed out). My point is that for D you
will need a deeper understanding of things, and Ali's book
provides this. D is not like Javscript where type
"alert('Hello, world!');" and go "Yeah!". One cannot always
blame D and its community for mistakes and/or bad choices
people make.
Maybe the community (20 or so ppl) to write some quick
tutorials on common tasks like socket programming, file system
stuff, memory, etc... and we just combine them in a common
format on the D site (wiki maybe) and refer learners to that.
Alot of ground could be covered if we just organize that and
get it done. We really would need to create a section and
decide on what topics to cover and get on it.
That's a good idea. We should ask people what they need most
urgently. String manipulation is one. Then arrays, sockets,
concurrency? ... please continue. Let's make a thread about "how
do want to use D and what are the most urgent things for you?"
Re: Here's looking at you, kid
On Friday, 20 November 2015 at 15:12:13 UTC, Andrei Alexandrescu wrote: One thing we need to do is deemphasize the "Language Reference" entry in the left menu and promote Ali's book to top level. -- Andrei In that case, if he were willing, might it be worthwhile to host it for him? Maybe apply the usual dlang.org styling to it, as well? I'm not sure how common it really is for the "officially-blessed" tutorial to live on an entirely different domain, but it seems like something that would be viewed as "less professional". -Wyatt
Re: Rust's simple download script
On Thursday, 19 November 2015 at 07:58:52 UTC, Jacob Carlborg wrote: DVM already does all this. Why reinvent the wheel? Because we already have the code for Travis-CI and Heroku. Also an intransparent binary is yet another hurdle trying to convince someone to try out D. BTW, I hust tried to use dvm. The linux binary doesn't work for my distribution (Fedora). ./dvm: error while loading shared libraries: libbz2.so.1.0: cannot open shared object file: No such file or directory Compiling dvm with the latest dmd fails. ../../.dub/packages/tango-1.0.1_2.067/tango/io/vfs/ZipFolder.d(302,27): Error: function tango.io.vfs.ZipFolder.ZipSubFolder.toString cannot have an in contract when overriden function object.Object.toString does not have an in contract ../../.dub/packages/tango-1.0.1_2.067/tango/io/vfs/ZipFolder.d(977,27): Error: function tango.io.vfs.ZipFolder.ZipFile.toString cannot have an in contract when overriden function object.Object.toString does not have an in contract Not too surprising given the amount of code, the number of dependencies, and the lack of any CI testing. I managed to build dvm using dmd-2.067.0 (as indicated by the tango dependency). Apart from the fact that dvm --help offers weird choices (-t, --tango Installs Tango as the standard library.), dvm install --help or dvm --help don't explain how to install a compiler. dvm install dmd-2.068.2 tango.core.Exception.IOException@../../.dub/packages/tango-1.0.1_2.067/tango/core/Exception.d(59): The resource with URL "http://ftp.digitalmars.com/dmd.dmd-2.068.2.zip"; could not be found. dvm install -l An error occurred: dvm.dvm.Exceptions.DvmException@.dub/packages/dvm-0.4.4/dvm/commands/Fetch.d(270): Failed to get the latest DMD version. dvm install -l -v # doesn't tell me either what fails Looking at strace it seems you're trying to parse http://dlang.org/download.html, please just use http://ftp.digitalmars.com/LATEST instead. After some trial and error it fails to install the selected compiler (and doesn't use the much smaller tar.xz downloads btw). dvm install 2.068.2 Fetching: http://downloads.dlang.org/releases/2.x/2.068.2/dmd.2.068.2.linux.zip [>] 25969/25335 KB Installing: dmd-2.068.2 An unknown error occurred: tango.core.Exception.IOException@../../.dub/packages/tango-1.0.1_2.067/tango/core/Exception.d(59): /home/dawg/.dvm/bin/dmd-2.068.2 :: No such file or directory All of the above, plus the ability to install gdc/ldc and verify downloaded dmd binaries, are achieved by a ~500LOC bash script. Of course downloading and installing dmd used to be a lot more chaotic when DVM was originally written. But making installations more scriptable is a direct outcome of writing such scripts, which works much better than building complex tools to deal with inconsistencies.
Re: Here's looking at you, kid
On Friday, 20 November 2015 at 16:39:52 UTC, Chris Wright wrote: On Fri, 20 Nov 2015 14:41:04 +, Chris wrote: Yep, what can one say. 1. Who goes to the language reference, when they want to _learn_ a language? It's the obvious place if you're familiar with other programming languages. Tutorials tend to be geared toward people who have little to no programming experience, who view learning a new language (even in a paradigm they're used to) as a large thing. It seems clear that there are a variety of different types of people who would want to learn the language. Maybe split up the Getting Started page to a few sections, like "new programmers", "intermediate programmers", "expert programmers".
Re: Here's looking at you, kid
On Friday, 20 November 2015 at 16:59:30 UTC, Chris wrote:
Have you been able to learn D? Yes or no? I'm sorry, if I'm not
always politically correct and I'm the first one to understand
the needs of programming novices, because we've all been there
(as you pointed out). My point is that for D you will need a
deeper understanding of things, and Ali's book provides this. D
is not like Javscript where type "alert('Hello, world!');" and
go "Yeah!". One cannot always blame D and its community for
mistakes and/or bad choices people make.
Maybe the community (20 or so ppl) to write some quick tutorials
on common tasks like socket programming, file system stuff,
memory, etc... and we just combine them in a common format on the
D site (wiki maybe) and refer learners to that. Alot of ground
could be covered if we just organize that and get it done. We
really would need to create a section and decide on what topics
to cover and get on it.
Re: Here's looking at you, kid
On Friday, 20 November 2015 at 16:39:52 UTC, Chris Wright wrote:
On Fri, 20 Nov 2015 14:41:04 +, Chris wrote:
Yep, what can one say.
1. Who goes to the language reference, when they want to
_learn_ a language?
It's the obvious place if you're familiar with other
programming languages. Tutorials tend to be geared toward
people who have little to no programming experience, who view
learning a new language (even in a paradigm they're used to) as
a large thing.
We were all there once, but we're not all there now. When I
learn a new language, I want typically 20-30 lines of example
code and a language reference. I can start writing code after
reading a short example, and I can use the language reference
to fill in the remaining gaps. The language reference is
usually both denser and better categorized for my needs.
2. If you really want to learn a language, you will learn it.
There are enough resources for D now, there's room for
improvement, but there always is.
I was choosing between programming languages a while ago, most
of which I hadn't used before. For each of them, it wasn't the
case that I wanted to learn them, but I knew I probably wanted
to use one of them.
If any of them were as obtuse to learn as D, I would have
skipped past them post haste.
If I'm evaluating a programming language to start using at
work, I will evaluate it on how easy it is for me to accomplish
things in that language and how easy it will be for my
coworkers to start using the language. My coworkers mostly know
Ruby and are just tentatively switching to Java. Moving to
Haskell probably isn't an option despite the existence of
decent tutorials, but D is similar enough that they could learn
-- assuming there are good tutorials readily available.
I know, catering for the "one second attention span" crowd is
a recipe for success, if you deal with PHP or JS. But D is not
in that league. Even if you cater for them, they will soon be
frustrated anyway, because for D you'll need a deeper
understanding of things, sooner or later.
You were contemptuous toward PHP and JavaScript, and now you
are being contemptuous toward people who are potentially
interested in learning D. Please be more respectful.
Have you been able to learn D? Yes or no? I'm sorry, if I'm not
always politically correct and I'm the first one to understand
the needs of programming novices, because we've all been there
(as you pointed out). My point is that for D you will need a
deeper understanding of things, and Ali's book provides this. D
is not like Javscript where type "alert('Hello, world!');" and go
"Yeah!". One cannot always blame D and its community for mistakes
and/or bad choices people make.
Re: Scott Meyers wants to bring default zero-initialization to C++, mentions TDPL for precedent
On Friday, 20 November 2015 at 16:38:02 UTC, Chris Wright wrote: On Fri, 20 Nov 2015 12:12:41 +, Chris wrote: On Wednesday, 18 November 2015 at 19:09:48 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 18 November 2015 at 18:52:02 UTC, Jack Stouffer wrote: For those of you who have never had the pleasure of writing PHP, lots of PHP code does completely different things depending on the compiler switches when the interpreter was Php is a dynamic language, that's different. Would you guys please stop calling PHP a language. JS and PHP are not languages, they are a fiddly feckin mess, which accounts for their high adoption rate. Sigh. Please, no gainsaying now, no "Yes, buts". I'd rather limit the number of posts on this forum that contain contempt or dismissiveness. It's unfriendly and doesn't help anything. Now, now, no need to feel offended. Bashing programming languages is part of programming. Never read any of those "Why [Python|PHP|JS|C++...] sucks" articles on the internet? I've had the misfortune of having to work with PHP and JS, and no shaming me will ever convince me that they are serious languages. Anyway, D is being bashed here all the time, haven't you noticed ;)
Re: Here's looking at you, kid
On Fri, 20 Nov 2015 14:41:04 +, Chris wrote: > Yep, what can one say. > > 1. Who goes to the language reference, when they want to _learn_ a > language? It's the obvious place if you're familiar with other programming languages. Tutorials tend to be geared toward people who have little to no programming experience, who view learning a new language (even in a paradigm they're used to) as a large thing. We were all there once, but we're not all there now. When I learn a new language, I want typically 20-30 lines of example code and a language reference. I can start writing code after reading a short example, and I can use the language reference to fill in the remaining gaps. The language reference is usually both denser and better categorized for my needs. > 2. If you really want to learn a language, you will learn it. There are > enough resources for D now, there's room for improvement, but there > always is. I was choosing between programming languages a while ago, most of which I hadn't used before. For each of them, it wasn't the case that I wanted to learn them, but I knew I probably wanted to use one of them. If any of them were as obtuse to learn as D, I would have skipped past them post haste. If I'm evaluating a programming language to start using at work, I will evaluate it on how easy it is for me to accomplish things in that language and how easy it will be for my coworkers to start using the language. My coworkers mostly know Ruby and are just tentatively switching to Java. Moving to Haskell probably isn't an option despite the existence of decent tutorials, but D is similar enough that they could learn -- assuming there are good tutorials readily available. > I know, catering for the "one second attention span" crowd is a recipe > for success, if you deal with PHP or JS. But D is not in that league. > Even if you cater for them, they will soon be frustrated anyway, because > for D you'll need a deeper understanding of things, sooner or later. You were contemptuous toward PHP and JavaScript, and now you are being contemptuous toward people who are potentially interested in learning D. Please be more respectful.
Re: Scott Meyers wants to bring default zero-initialization to C++, mentions TDPL for precedent
On Fri, 20 Nov 2015 12:12:41 +, Chris wrote: > On Wednesday, 18 November 2015 at 19:09:48 UTC, Ola Fosheim Grøstad > wrote: >> On Wednesday, 18 November 2015 at 18:52:02 UTC, Jack Stouffer wrote: >>> For those of you who have never had the pleasure of writing PHP, lots >>> of PHP code does completely different things depending on the compiler >>> switches when the interpreter was >> >> Php is a dynamic language, that's different. > > Would you guys please stop calling PHP a language. JS and PHP are not > languages, they are a fiddly feckin mess, which accounts for their high > adoption rate. Sigh. Please, no gainsaying now, no "Yes, buts". I'd rather limit the number of posts on this forum that contain contempt or dismissiveness. It's unfriendly and doesn't help anything.
Re: range.save
Am 20.11.2015 um 16:37 schrieb Andrei Alexandrescu:
On 11/20/2015 04:42 AM, Sönke Ludwig wrote:
I think that .save is a serious design flaw in the range API
How would you redo it? -- Andrei
That's why I wrote that the alternatives had their own issues - I
unfortunately don't have a solution to this either. Making usage errors
fail loudly at runtime is the only one improvement I had in mind that
wouldn't result in unacceptable code breakage.
Now if we could exclude reference type ranges from the picture* and
ignore the fact that this would break tons of code, I think making input
ranges non-copyable and using the postblit constructor to do the job of
save() would be the right approach. Recently this was mentioned
somewhere and the counter argument was that this wouldn't work for
wrapper ranges:
struct FilterRange(R) {
private R _input;
this(R input) {
_input = input; // error: R not copyable
}
// ...
}
But it does work!
struct FilterRange(R) {
private R _input;
this(R input) {
swap(_input, input); // fine!
}
// ...
}
Passing a range into such a wrapper range can still be done directly in
case of rvalues: FilterRange!MyRange(MyRange(...))
L-values require an explicit "move" call (which is a good thing):
MyRange r;
auto fr = FilterRange(r.move);
The lowering of "foreach" to "for" would also have to be adjusted
accordingly.
The main drawback of using postblit for forward ranges is that it might
happen that it gets invoked accidentally, resulting in hidden
performance issues (IMO better than correctness issues, but anyway).
That could either be mitigated by performing substantial work lazily
instead of directly in this(this), or by keeping support for save() in
addition to this(this), so that a valid forward range could still
disable this(this) if it's costly and expose the copy functionality
through save() instead.
* To still support reference type ranges, we could turn this around and
define a copyref() method that creates a new range that references the
same internal range object. The advantage is that this way around
failure to call copyref() will result in an immediate error.
Re: I have this game engine...
On 4/11/2015 7:09 PM, Iain Buclaw via Digitalmars-d wrote: I'm aware of this, not because I take an interest, but because I was cc'd into discussion when they discovered a C++ regression that was seen by comparing the md5sum of (D frontend) interpret.c sources between 2nd and 3rd generation bootstrapped builds. ;-) That's awesome!
Re: range.save
On 11/20/2015 04:42 AM, Sönke Ludwig wrote: I think that .save is a serious design flaw in the range API How would you redo it? -- Andrei
Re: Here's looking at you, kid
On Friday, 20 November 2015 at 14:34:10 UTC, bachmeier wrote: On Friday, 20 November 2015 at 08:51:13 UTC, Warwick wrote: It says on the website and I quote... "a great starting point for absolute beginners" But the fundamental problem and what everyone seems to be refusing to acknowledge is that in spite of what *you think people should be doing* many visitors are ending up using language reference to learn D. Or they use that reference to get their first impressions. It's like going to a restaurant and being given the recipes instead of the menu. But keep burying you heads in the ground. Hence my post in this thread that we should be adding links to the relevant sections of Ali's book to the documentation. I will be doing so as time permits, but it's quite easy, so please do so when you see an opportunity. Good idea.
Re: Here's looking at you, kid
On 11/20/2015 09:37 AM, bachmeier wrote: On Friday, 20 November 2015 at 14:15:32 UTC, Jack Stouffer wrote: On Friday, 20 November 2015 at 08:51:13 UTC, Warwick wrote: many visitors are ending up using language reference to learn D. Or they use that reference to get their first impressions. Then they're fools. In order to go to the link "D Reference" on dlang.org, your eyes have to scan past the "Getting Started" link and you have to purposely decide not to click on it. If I wanted to get up and running with a language, I wouldn't ignore the page that was obviously meant to help me. Even if they didn't see the link, the FIRST result if you google "D language tutorial" is Ali's book. I'm really not sure what else can be done to help people. I agree. There's not a lot more that I can see that needs to be changed on the website. And Ali's book is really good. Plus, the forum is friendly. One thing we need to do is deemphasize the "Language Reference" entry in the left menu and promote Ali's book to top level. -- Andrei
Re: Pattern Based Design
On Wednesday, 18 November 2015 at 13:12:16 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 18 November 2015 at 02:41:33 UTC, Jonny wrote: I am mainly talking about the organizational aspects of higher level of abstraction rather than code generation. Basically dealing with "files" is so old school. They reduce coherence of the abstraction. Modules help but still are file based. I'd rather have a list of functions, a hierarchical view of class relationships(the uml like design). I'd like to see the project on a higher level of abstraction instead of the very concrete "files" approach that hasn't changed since punch cards. Yes, I agree with you. I've felt the same way for a long time. Unfortunately it is very hard and expensive to build such tools. They exist and are in use, but in very specific domains. One of the key problem with the concept is that programmers often edit and mutate their programs with many unfinished pieces laying around before they compile. If they started by defining interfaces then it would be a lot easier to make a good tool. Defining interfaces gets you only so far. As a program grows, you have to change many things and redefine the interface later. What looks like a good plan/interface when you set out, invariably will have to be revised and changed later. This is the reality of programming. No matter what they tell you about planning your program beforehand, it changes later anyway, sometimes even drastically. If anyone has the perfect plan, please let me know. [snip]
Re: Here's looking at you, kid
There you go: http://ddili.org/ders/d.en/foreword2.html Beginners and experienced programmers, you're welcome!
Re: Here's looking at you, kid
On Friday, 20 November 2015 at 13:57:16 UTC, David DeWitt wrote: The "New Library Reference Preview" under Resources is much cleaner and has comments. I personally prefer the look of that resource. It isn's updated and is on 2.067.1. Don't works for me now, problem with http://dlang.org/library/symbols.js both Chromium and Firefox. I have to wait for timeout for every page - symbols.js end is not detected by browser so he is waiting for next chunk until timeout. But yes, it's better.
Re: Here's looking at you, kid
On Friday, 20 November 2015 at 14:15:32 UTC, Jack Stouffer wrote: On Friday, 20 November 2015 at 08:51:13 UTC, Warwick wrote: many visitors are ending up using language reference to learn D. Or they use that reference to get their first impressions. Then they're fools. In order to go to the link "D Reference" on dlang.org, your eyes have to scan past the "Getting Started" link and you have to purposely decide not to click on it. If I wanted to get up and running with a language, I wouldn't ignore the page that was obviously meant to help me. Even if they didn't see the link, the FIRST result if you google "D language tutorial" is Ali's book. I'm really not sure what else can be done to help people. Yep, what can one say. 1. Who goes to the language reference, when they want to _learn_ a language? 2. If you really want to learn a language, you will learn it. There are enough resources for D now, there's room for improvement, but there always is. I know, catering for the "one second attention span" crowd is a recipe for success, if you deal with PHP or JS. But D is not in that league. Even if you cater for them, they will soon be frustrated anyway, because for D you'll need a deeper understanding of things, sooner or later.
Re: Here's looking at you, kid
On Friday, 20 November 2015 at 14:15:32 UTC, Jack Stouffer wrote: On Friday, 20 November 2015 at 08:51:13 UTC, Warwick wrote: many visitors are ending up using language reference to learn D. Or they use that reference to get their first impressions. Then they're fools. In order to go to the link "D Reference" on dlang.org, your eyes have to scan past the "Getting Started" link and you have to purposely decide not to click on it. If I wanted to get up and running with a language, I wouldn't ignore the page that was obviously meant to help me. Even if they didn't see the link, the FIRST result if you google "D language tutorial" is Ali's book. I'm really not sure what else can be done to help people. I agree. There's not a lot more that I can see that needs to be changed on the website. And Ali's book is really good. Plus, the forum is friendly.
Re: Here's looking at you, kid
On Friday, 20 November 2015 at 08:51:13 UTC, Warwick wrote: It says on the website and I quote... "a great starting point for absolute beginners" But the fundamental problem and what everyone seems to be refusing to acknowledge is that in spite of what *you think people should be doing* many visitors are ending up using language reference to learn D. Or they use that reference to get their first impressions. It's like going to a restaurant and being given the recipes instead of the menu. But keep burying you heads in the ground. Hence my post in this thread that we should be adding links to the relevant sections of Ali's book to the documentation. I will be doing so as time permits, but it's quite easy, so please do so when you see an opportunity.
Re: Here's looking at you, kid
On Friday, 20 November 2015 at 08:51:13 UTC, Warwick wrote: many visitors are ending up using language reference to learn D. Or they use that reference to get their first impressions. Then they're fools. In order to go to the link "D Reference" on dlang.org, your eyes have to scan past the "Getting Started" link and you have to purposely decide not to click on it. If I wanted to get up and running with a language, I wouldn't ignore the page that was obviously meant to help me. Even if they didn't see the link, the FIRST result if you google "D language tutorial" is Ali's book. I'm really not sure what else can be done to help people.
Re: Here's looking at you, kid
On Friday, 20 November 2015 at 12:52:15 UTC, crimaniak wrote: Library reference is not very good too. In my previous try with D I even made a browser extension to show classes, functions, variables, etc. in 'jump to' section with different backgrounds. The reference should definitely be more fine grained and is equipped with user comments, which are extremely useful. See PHP document pages for example http://www.php.net/manual/en/function.session-set-cookie-params.php The "New Library Reference Preview" under Resources is much cleaner and has comments. I personally prefer the look of that resource. It isn's updated and is on 2.067.1.
Re: Here's looking at you, kid
Library reference is not very good too. In my previous try with D I even made a browser extension to show classes, functions, variables, etc. in 'jump to' section with different backgrounds. The reference should definitely be more fine grained and is equipped with user comments, which are extremely useful. See PHP document pages for example http://www.php.net/manual/en/function.session-set-cookie-params.php
Re: Formal Review of std.range.ndslice
On Monday, 16 November 2015 at 22:45:35 UTC, Jack Stouffer wrote: This is the start of the two week formal review for the proposed std.range.ndslice. This new addition to the standard library would add the ability to create and manipulate multi-dimensional random access ranges in a way that will be very familiar to those of you who use numpy. This has the potential to give D a huge boost in popularity in numerical and scientific applications. A quick run down for those that are not familiar with the process. After two weeks, the PR author (Ilya Yaroshenko) will have time to make proposed changes. Then, when the author feels it's ready, the PR will go to a vote. In the vote, everyone in the community has a say, but if one of the main contributors or maintainers has a very negative opinion (for example) that will carry more weight. Github: https://github.com/D-Programming-Language/phobos/pull/3397 dub: http://code.dlang.org/packages/dip80-ndslice docs: http://dtest.thecybershadow.net/results/bac6211c1d73b2cf62bc18c9844c8c82c92c21e1/5c6071ca953cf113febd8786b4b68916cbb2cdaf/ previous discussion: http://forum.dlang.org/thread/rilfmeaqkailgpxoz...@forum.dlang.org ## Guide for Slice/Matrix/BLAS contributors 1. Pay _unprecedented_ attention to functions to be a. inlined(!), b. `@nogc`, c. `nothrow`, d. `pure`. 95% of functions will be marked with `pragma(inline, true)`. So, use _simple_ `assert`s with messages that can be computed at compile time. The goals are: 1. to reduce executable size for _any_ compilation mode 2. to reduce template bloat in object files 3. to reduce compilation time 4. to allow a user to write an extern C bindings for code based on `Slice`. 2. Do not import `std.format`, `std.string` and `std.conv` to format error messages.`"Use" ~ Concatenation.stringof ~ ", really ."` Why? Please, read [1] again. 3. Try to use already defined `mixin template`s for pretty error messaging. 4. Do not use `Exception`s/`enforce`s to check indexes and length. Exceptions are allowed only for algorithms where validation of an input data is significantly complex for user. `reshaped` is a good example where Exceptions are required. Put an example of Exception handing and workaround for function that can throw. 5. Do not use compile time flags for simple checks like transposition of a matrix. It is much better to have runtime matrix transposition. Furthermore, Slice provide runtime matrix transposition out of the box. 6. Do not use _Fortran_VS_C_ flags. They are about notation, but not about algorithm itself. To care about math world users add appropriate code example in the documentation. `transposed` / `everted` can be used for cash friendly code. 7. Do not use compile time power of D to produce dummy entities like `IdentityMatrix`. 8. Try to separate allocation and algorithm logic whenever possible. 9. Add CTFE unittests to new functions. --- Update docs: http://dtest.thecybershadow.net/artifact/website-7a646fdea76569e009844cdee5c93edab10980ca-87c7c7a1a6e59a71179301c54d012057/web/phobos-prerelease/std_experimental_range_ndslice.html -- Ilya
Re: Scott Meyers wants to bring default zero-initialization to C++, mentions TDPL for precedent
On Wednesday, 18 November 2015 at 19:09:48 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 18 November 2015 at 18:52:02 UTC, Jack Stouffer wrote: For those of you who have never had the pleasure of writing PHP, lots of PHP code does completely different things depending on the compiler switches when the interpreter was Php is a dynamic language, that's different. Would you guys please stop calling PHP a language. JS and PHP are not languages, they are a fiddly feckin mess, which accounts for their high adoption rate. Sigh. Please, no gainsaying now, no "Yes, buts".
Re: Here's looking at you, kid
On Friday, 20 November 2015 at 11:44:02 UTC, Chris wrote:
On Friday, 20 November 2015 at 08:51:13 UTC, Warwick wrote:
This example makes no sense to a programming novice:
// Sort lines
import std.stdio;
import std.array;
import std.algorithm;
void main()
{
stdin
.byLine(KeepTerminator.yes)
.map!(a => a.idup)
.array
.sort
.copy(
stdout.lockingTextWriter());
}
But programming novices are taught programming in a bad way. A
lot of programming books are full of "step by step" code which
doesn't make sense in the real world and only spoils people for
the rest of their programming life.
I think the most important thing is to teach people the concepts
behind D. Not just 'writeln("Hello, world!");' and be happy code.
The example above illustrates chained programming with ranges and
components. A > B > C = D!. This is what we have to explain
first. People will expect "Hello, world!", but if we want people
to use D, we'll have to teach the concepts as well, and explain
why D has those concepts. This is the hardest bit. People prefer
rules to explanations.
Re: Here's looking at you, kid
On Friday, 20 November 2015 at 08:51:13 UTC, Warwick wrote: On Friday, 20 November 2015 at 01:28:00 UTC, rsw0x wrote: On Friday, 20 November 2015 at 00:47:17 UTC, Warwick wrote: On Thursday, 19 November 2015 at 12:28:44 UTC, Andrei Alexandrescu wrote: On 11/18/2015 11:02 PM, Saurabh Das wrote: [...] Generally a language reference is not good for learning a language. -- Andrei IE. There's nothing on the D website that is "good for learning" D. There's an offsite tutorial aimed at "absolute begginers". ing great set of options aint it. Ali's book is not a tutorial or aimed at absolute beginners, it's /the/ material for learning D and in my opinion a great reference book. It says on the website and I quote... "a great starting point for absolute beginners" But the fundamental problem and what everyone seems to be refusing to acknowledge is that in spite of what *you think people should be doing* many visitors are ending up using language reference to learn D. Or they use that reference to get their first impressions. It's like going to a restaurant and being given the recipes instead of the menu. But keep burying you heads in the ground. Would you bother to define "beginners"? Someone studying biology who has to use some script like stuff to process DNA sequences, with no programming experience at all? Or someone who comes from C++ and wants to try something different? Someone who's interested in programming and wants to write apps for mobile phones? My experience is that people who come to D already know other programming languages (and that's basically why they end up here).
Re: Here's looking at you, kid
On Friday, 20 November 2015 at 08:51:13 UTC, Warwick wrote: On Friday, 20 November 2015 at 01:28:00 UTC, rsw0x wrote: On Friday, 20 November 2015 at 00:47:17 UTC, Warwick wrote: [...] Ali's book is not a tutorial or aimed at absolute beginners, it's /the/ material for learning D and in my opinion a great reference book. It says on the website and I quote... "a great starting point for absolute beginners" But the fundamental problem and what everyone seems to be refusing to acknowledge is that in spite of what *you think people should be doing* many visitors are ending up using language reference to learn D. Or they use that reference to get their first impressions. It's like going to a restaurant and being given the recipes instead of the menu. But keep burying you heads in the ground. i agree with warwick. language reference as of now is language spec and people will take a look at it before reading any books.
Re: range.save
Am 19.11.2015 um 22:30 schrieb Freddy:
Does anyone else think range.save is a hack? I often find myself
forgetting to call range.save in my generic code with my unittests
working fine. Also, working with a range of ranges may forget to call
range.save.(Ex: [1,2,4].repeat)
I think that .save is a serious design flaw in the range API and there
must me countless theoretical or future bugs lurking in todays code
bases, only working by chance due to undefined algorithm behavior.
The problem is that all of the alternatives that were discussed all had
different trade-offs and solving the .save issue would lead to other
issues/limitations (or at least AFAIR there hasn't been a suggestion
where that wouldn't be the case). And since we now already have an API,
that wouldn't help anyway.
Maybe we could inject code into existing ranges that, in debug mode, at
least causes assertions to trigger whenever an operation is done on an
outdated copy of an input range (or of a non '.save'd forward range).
That could then be advertised as a standard pattern for user defined
ranges ("mixin RangeSemantics;").
Re: Here's looking at you, kid
On Friday, 20 November 2015 at 08:51:13 UTC, Warwick wrote: On Friday, 20 November 2015 at 01:28:00 UTC, rsw0x wrote: On Friday, 20 November 2015 at 00:47:17 UTC, Warwick wrote: [...] Ali's book is not a tutorial or aimed at absolute beginners, it's /the/ material for learning D and in my opinion a great reference book. It says on the website and I quote... "a great starting point for absolute beginners" But the fundamental problem and what everyone seems to be refusing to acknowledge is that in spite of what *you think people should be doing* many visitors are ending up using language reference to learn D. Or they use that reference to get their first impressions. It's like going to a restaurant and being given the recipes instead of the menu. But keep burying you heads in the ground. I seriously don't see what the problem is. The best resource for learning D is the second link on the "getting started" page. The language reference is under the 'for more depth' category.
Re: Here's looking at you, kid
On Friday, 20 November 2015 at 01:28:00 UTC, rsw0x wrote: On Friday, 20 November 2015 at 00:47:17 UTC, Warwick wrote: On Thursday, 19 November 2015 at 12:28:44 UTC, Andrei Alexandrescu wrote: On 11/18/2015 11:02 PM, Saurabh Das wrote: [...] Generally a language reference is not good for learning a language. -- Andrei IE. There's nothing on the D website that is "good for learning" D. There's an offsite tutorial aimed at "absolute begginers". ing great set of options aint it. Ali's book is not a tutorial or aimed at absolute beginners, it's /the/ material for learning D and in my opinion a great reference book. It says on the website and I quote... "a great starting point for absolute beginners" But the fundamental problem and what everyone seems to be refusing to acknowledge is that in spite of what *you think people should be doing* many visitors are ending up using language reference to learn D. Or they use that reference to get their first impressions. It's like going to a restaurant and being given the recipes instead of the menu. But keep burying you heads in the ground.
Re: IRC dead?
On 19 November 2015 at 15:55, Jonathan M Davis via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On Wednesday, 18 November 2015 at 23:24:14 UTC, Chris Wright wrote: > >> #ubuntu, for comparison, is so outrageously active that you can log in >> and see a new message every few seconds. >> > > Wow. That seems like it would be too active to even be useful. > > >From the time I was around being a community member, I found a lot of the general flow of discussion to be a question followed by a link to a wiki, askubuntu, the forum, a manpage. If you had a problem, you'd never get a concrete answer. Anything too technical was deemed not fit for discussion and you were directed towards the forums or some other channel. Iain
Re: Here's looking at you, kid
On Friday, 20 November 2015 at 05:59:14 UTC, Jack Stouffer wrote: On Friday, 20 November 2015 at 05:00:16 UTC, jmh530 wrote: On Friday, 20 November 2015 at 01:56:41 UTC, Jack Stouffer wrote: On Friday, 20 November 2015 at 01:28:00 UTC, rsw0x wrote: Ali's book is not a tutorial or aimed at absolute beginners, it's /the/ material for learning D and in my opinion a great reference book. Ali's book is to blame really for the lack of D tutorials, it's just so good that no one else bothers ;) Wouldn't that suggest doing a better job pointing beginners to it? The second link on the "Getting Started" page on dlang.org is to the book http://dlang.org/getstarted.html. That page says that Ali's book is an "extensive tutorial" that's "a great starting point for absolute beginners." Presumably that's what pissed Warwick off, I guess he wants something more aimed at intermediate to advanced programmers. That would be TDPL, which is excellent and not free. Perhaps TDPL should be mentioned on that page too, along with how it's different.
