Re: forum.dlang.org, version 2 (BETA)
On Thursday, 4 June 2015 at 15:04:05 UTC, Vladimir Panteleev wrote: http://beta.forum.dlang.org/ Many major and minor improvements. Some major ones: - dlang.org theme, fully responsive and mobile-friendly - keyboard navigation in all views - automatically saved post drafts - get notified of new posts and replies with subscriptions - full text search - by persistent request, a new view mode (vertical-split) - post to mailing lists - even faster, believe it or not. This update is the sum of 256 commits over 34 days of development. feels like a mobile site which is bad on a 1440p screen.
Re: Reggae binary backend: build your project with a D compiled executable
On Monday, 8 June 2015 at 05:51:58 UTC, Atila Neves wrote: On Sunday, 7 June 2015 at 12:06:52 UTC, Kagamin wrote: On Sunday, 7 June 2015 at 07:00:18 UTC, Atila Neves wrote: I'm currently considering (because of dmd, druntime and phobos) how to strip it down to its bare essentials and have a core set of source files that only knows how to build D code, i.e. no C/C++, no dub, no make/ninja. Why strip? I meant strip in a general sense, not in the sense of stripping symbols. Atila I still agree with what he says. ninja and make have had countless manhours poured into them, from optimizations to bugfixes. D community seems obsessed with NIH.
Re: Now official: we are livestreaming DConf 2015
On Wednesday, 27 May 2015 at 19:01:00 UTC, Andrei Alexandrescu wrote: Thanks to John Colvin! He rigged his webcam centrally so we can livestream DConf 2015 in passable quality to youtube. Link: https://www.youtube.com/watch?v=-OCl-jWyT9E It's live now (30 minutes of break still ongoing so not a lot going on at the moment). Schedule at: http://dconf.org/2015/schedule/index.html Times are in MDT (GMT-0600). Andrei Does anyone know what is needed to get the HTML5 stream to work in Firefox?
Re: Now official: we are livestreaming DConf 2015
On Wednesday, 27 May 2015 at 20:18:11 UTC, weaselcat wrote: On Wednesday, 27 May 2015 at 19:01:00 UTC, Andrei Alexandrescu wrote: Thanks to John Colvin! He rigged his webcam centrally so we can livestream DConf 2015 in passable quality to youtube. Link: https://www.youtube.com/watch?v=-OCl-jWyT9E It's live now (30 minutes of break still ongoing so not a lot going on at the moment). Schedule at: http://dconf.org/2015/schedule/index.html Times are in MDT (GMT-0600). Andrei Does anyone know what is needed to get the HTML5 stream to work in Firefox? http://docs.livestreamer.io/ can be used to stream it outside the browser. Not sure if this will help people with location issues.
Re: Now official: we are livestreaming DConf 2015
On Wednesday, 27 May 2015 at 20:31:17 UTC, weaselcat wrote: On Wednesday, 27 May 2015 at 20:18:11 UTC, weaselcat wrote: On Wednesday, 27 May 2015 at 19:01:00 UTC, Andrei Alexandrescu wrote: Thanks to John Colvin! He rigged his webcam centrally so we can livestream DConf 2015 in passable quality to youtube. Link: https://www.youtube.com/watch?v=-OCl-jWyT9E It's live now (30 minutes of break still ongoing so not a lot going on at the moment). Schedule at: http://dconf.org/2015/schedule/index.html Times are in MDT (GMT-0600). Andrei Does anyone know what is needed to get the HTML5 stream to work in Firefox? http://docs.livestreamer.io/ can be used to stream it outside the browser. Not sure if this will help people with location issues. Forgot to add that it's in Arch Linux's repository.
Re: D needs...
On Monday, 11 May 2015 at 12:22:34 UTC, Dennis Ritchie wrote: On Monday, 11 May 2015 at 11:59:02 UTC, Namespace wrote: Inspired by ponce idioms list for D I've set up something similar. There are some themes in D which come up regulary and are discussed to the vomit. If something is agreed, it gets forgotten sometimes and the theme disappears into oblivion (for a few months :P). To prevent this, I've collected some hot-discussed themes, their history and their current state. I hope this helps to avoid unnecessary discussions in the future and finally cut off these issues (either with an official decision Nope, keep as it is or with an implementation). I've tried to stay as objective as possible, but if something seems to be too subjective, please let me know, so I can fix it. http://dgame.github.io/dneeds/ Thanks. Many programmers find fault with this problem: No problem. But if you have more elements it could be annoying to count them. That's why some D users wanted that the compiler does that for them. int[$] c = [1, 2, 3]; // the compiler detects the dollar and count the elements for us +1, I have to go review why this was removed. It's annoying that I have to manually count static arrays.
Re: [hackathon] ARE WE SLIM YET?
On Sunday, 3 May 2015 at 13:04:41 UTC, Vladimir Panteleev wrote: Gah, I'm late! Anyway, this is my hackathon project: http://digger.k3.1azy.net/trend/ Succinctly, it is the lovechild of Digger and Mozilla's areweslimyet.com. It measures stats about D built from D's entire GitHub history, as well as those of programs built with said D versions. Currently only two programs are tested (empty program and hello world), so please send PRs for meaningful benchmarks. Adding new programs is very easy: http://j.mp/1I7ELEc. There is a bunch of cool things happening under the hood about which I might or might not do a full blog post later. Currently it's still collecting data from recently added benchmarks, so coverage is spotty for some tests - should be fleshed out in a few days. Enjoy! Cool project, can't wait to see benchmarks/compile times for larger programs get tracked.
Re: The hackathon week roundup
On Saturday, 2 May 2015 at 23:02:05 UTC, Andrei Alexandrescu wrote: * WIP: Unique https://github.com/D-Programming-Language/phobos/pull/3225 and RefCounted (can't seem to find the PR - where is it?) already got pulled https://github.com/D-Programming-Language/phobos/pull/3171 Worth adding: AFAIK unique(?) and refcounted are completely usable in @nogc, and most of the unit tests likely can be marked @nogc for them to help prevent breakage.
Re: This week in D #14: job opening, Silicon Valley meetup, Dsource on GitHub
On Monday, 20 April 2015 at 06:23:36 UTC, ketmar wrote: as Adam didn't post announce for current TWiD, i'll try to do that instead, as i like to see that announcements here. http://arsdnet.net/this-week-in-d/apr-19.html the notable thing is Job Opening part. let's hope that it will become regular. not with the same content each week, of course. no tip/trick :(
Re: Reggae v0.0.5 super alpha: A build system in D
On Friday, 3 April 2015 at 19:07:09 UTC, Jacob Carlborg wrote: On 2015-04-03 20:06, Atila Neves wrote: Interesting. It's true that it's not always faster to compile each module separately, I already knew that. It seems to me, however, that when that's actually the case, the practical difference is negligible. Even if 10x slower, the linker will take longer anyway. Because it'll all still be under a second. That's been my experience anyway. i.e. It's either faster or it doesn't make much of a difference. I just tried compiling one of my project. It has a makefile that does separate compilation and a shell script I use for unit testing which compiles everything in one go. The makefile takes 5.3 seconds, does not including linking since it builds a library. The shell script takes 1.3 seconds which include compiling unit tests and linking as well. change one file and see which one is faster with an incremental build.
Re: Reggae v0.0.5 super alpha: A build system in D
On Friday, 3 April 2015 at 17:55:00 UTC, Dicebot wrote: On Friday, 3 April 2015 at 17:25:51 UTC, Ben Boeckel wrote: On Fri, Apr 03, 2015 at 17:10:31 +, Dicebot via Digitalmars-d-announce wrote: On Friday, 3 April 2015 at 17:03:35 UTC, Atila Neves wrote: . Separate compilation. One file changes, only one file gets rebuilt This immediately has caught my eye as huge no in the description. We must ban C style separate compilation, there is simply no way to move forward otherwise. At the very least not endorse it in any way. Why? Other than the -fversion=... stuff, what is really blocking this? I personally find unity builds to not be worth it, but I don't see anything blocking separate compilation for D if dependencies are set up properly. --Ben There are 2 big problems with C-style separate compilation: 1) Complicates whole-program optimization possibilities. Old school object files are simply not good enough to preserve information necessary to produce optimized builds and we are not in position to create own metadata + linker combo to circumvent that. This also applies to attribute inference which has become a really important development direction to handle growing attribute hell. Not sure about other people, but I do not care about whole program optimization during an edit-compile-run cycle. I just want it to compile as fast as possible, and if I change one or two files I don't want to have to recompile an entire codebase.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Monday, 30 March 2015 at 12:04:22 UTC, Laeeth Isharc wrote: On Monday, 30 March 2015 at 07:29:56 UTC, Jonathan M Davis wrote: On Saturday, March 28, 2015 14:19:46 Walter Bright via Digitalmars-d-announce wrote: Thank you. I need to learn std.algorithm better. Don't we all. Part of the problem with std.algorithm is its power. It's frequently the case that you think that something isn't there when it's either there under a different name, or you just have to look at one of its functions from a different angle to use it for what you're trying to do. It wouldn't surprise me at all if folks who know it quite well get surprised by what it can do at least from time to time. - Jonathan M Davis when this happens, it would be great if the person could post to the group a few lines about it so someone (possibly someone else) can collate into a future series on gems in phobos. maybe give subject some consistent name so it is easy to find them later. I regularly review std.algorithm just because I'm not used to functional programming, it has so many useful things.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Monday, 30 March 2015 at 18:41:17 UTC, Russel Winder wrote: On Mon, 2015-03-30 at 11:19 -0700, Walter Bright via Digitalmars-d-announce wrote: […] My brain still thinks in terms of loops. The excellent influence of functional programming on imperative programming is implicit iteration and higher-order functions. Any explicit for/while loop in a modern imperative language code should *necessarily* involve a side-effect or it is coded wrongly. Even then it can almost certainly be recast to preserve the side- effect and remove the loop – unless you are implementing the implicit iteration function. This has nothing to do with tail recursion optimization and all that Lambda Calculus stuff, this is to do with correct levels of abstraction that allow the tool chain to maximize support for the programmer. Java programmers are having to come to terms with this. Python programmers sort of have, except that BDFL has failed to accept the correct end point and still likes loops. Scala has done it all wrong. (Further opinions available on request :-) speaking of optimization, are there any guarantees(documented?) on the kind of optimizations you should expect from range programming in D(i.e, function chaining) similar to Haskell's stream fusion?
Re: This Week in D #11: new release, undocumented feature exposed, FAQ answered, DConf schedule posted.
On Monday, 30 March 2015 at 01:14:59 UTC, Adam D. Ruppe wrote: http://arsdnet.net/this-week-in-d/mar-29.html The big pieces have already been posted to Reddit, so idk if we want to post again, but if you want to, go ahead and just post the reddit link here too as this is a nice little roundup. I also took the opportunity to document the new ddoc `code` feature! I think reddit is starting to act unfriendly to frequent D posts now, this week in D maybe shouldn't be cross-posted there so much. Thanks for the update.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sunday, 29 March 2015 at 19:09:52 UTC, Laeeth Isharc wrote: On Sunday, 29 March 2015 at 02:15:38 UTC, cym13 wrote: Urr As an active Python developer, I find that one pretty harsh. It's not that we need to enforce good style, it's that we take good style as granted and choose to lighten it consequently. On the contrary I think that D has everything to attract a pythonista. Most new, trendy languages like Go or Rust are to down a level to easily suit a python's formated mind, and I guess that if most python developers come to switch language for performance issues (like myself) D's code safety system is definitely very appealing because python's safety is... well... ^^ Moreover, it is possible to reach a good expressiveness (maybe not as good as python, but that's the whole goal of python so there's no shame in not matching it). UFCS FTW! As an active Python developer, what would you add to or change about the following: http://bitbashing.io/2015/01/26/d-is-like-native-python.html while it mentions concurrency/parallel, a quick example of showing how easy it is to do parallel operations in D would probably benefit considering python's current state of parallelism.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Saturday, 28 March 2015 at 18:47:04 UTC, Walter Bright wrote: On 3/28/2015 3:20 AM, Jonathan M Davis via Digitalmars-d-announce wrote: Personally, I'm not sure that much is gained in pitting Go against D precisely because they're so different that they're likely to appeal to completely different sets of people. I also do not regard Go as a competitor to D. It's more of a competitor to Java and Ruby. I find most people I know using Go are from the python camp and either wanted static typing or faster runtime execution.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Saturday, 28 March 2015 at 17:57:35 UTC, ketmar wrote: On Sat, 28 Mar 2015 14:28:00 +, Russel Winder via Digitalmars-d-announce wrote: It could be argued that it is all just co-routines underneath, but I think that would be missing the point that we have 55 years more experience of doing these things since that single processor operating system model was created. We really should be doing this all a lot better these days. yet current CPUs are still the same as 50 years before, that is the problem. ;-) heavily disagree
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Saturday, 28 March 2015 at 18:39:47 UTC, Russel Winder wrote: On Sat, 2015-03-28 at 17:57 +, ketmar via Digitalmars-d-announce wrote: On Sat, 28 Mar 2015 14:28:00 +, Russel Winder via Digitalmars-d-announce wrote: It could be argued that it is all just co-routines underneath, but I think that would be missing the point that we have 55 years more experience of doing these things since that single processor operating system model was created. We really should be doing this all a lot better these days. yet current CPUs are still the same as 50 years before, that is the problem. ;-) I'd suggest that a Intel x86_64 of 2015 bears only a passing relationship to an IBM 360 of the 1960s. It is true that hardware design has been constrained by a weird constraint that no-one has investigated alternative architectures to the register/CPU that software people insist is the only way forward. With all the transistors available per mm² these days, it is about time we investigated alternate, implicitly parallel ways of working. Intel had a go a few years ago with various alternative dataflow based architectures, but they were told by the software people that they had no future because software inertia was more important than innovation. Thoughts on mill architecture?
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 20:20:07 UTC, Nick Sabalausky wrote: On 03/26/2015 09:47 PM, Walter Bright wrote: It seems to me that every significant but one feature of Go has a pretty much direct analog in D I'm no Go expert, but AIUI, Go seems to be one of those languages that considers *lacking* certain features to *be* a feature. Ie the whole minimalism approach to language design. For people who value that (not for me personally though), it's a feature D doesn't offer and deliberately doesn't try to. there's a difference between minimalism and blatantly not adopting core advances in language design over the past 40 years.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 20:58:44 UTC, Walter Bright wrote: On 3/27/2015 1:35 PM, weaselcat wrote: there's a difference between minimalism and blatantly not adopting core advances in language design over the past 40 years. Yes, and there's also a difference between gratuitous complexity and finding the underlying simplicity. It's a tricky thing finding the sweet spot. I don't disagree, but Go is definitely not in that sweet spot - it's crippled by its benevolent dictators for the sake of being crippled.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 22:32:32 UTC, ketmar wrote: On Fri, 27 Mar 2015 16:11:41 +, Ola Fosheim Grøstad wrote: Not a broken design. If I have to run multiple servers just to handle an image upload or generating a PDF then you are driving up the cost of the project and developers would be better off with a different platform? but it is broken! the whole point of async i/o servers is that such servers spend most of their time waiting for i/o. and if you need to do some lengthy calculations, you either spawns a real thread and commands it to wake you up when it is finished, or asking external server to do the job (and wake you when it is finished). what moving fibers from thread to thread does is bringing in state copying (we want our threads fairly isolated, aren't we? so either copying, or ownership management). the whole thing of cooperative multitasking is to be... cooperative. in several years some Shiny New Async Framework will use no transferring fibers between worker threads as Spectacular Invention. as an outsider to the web-scale world, this entire thing seems like a half-baked fork reimplementation
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 01:47:57 UTC, Walter Bright wrote: On 3/26/2015 12:40 PM, Russel Winder via Digitalmars-d-announce wrote: (Almost) All publicity is good publicity. I attended a presentation at NWCPP on Go last week. I have never written a Go program, so filter my opinion on that. It seems to me that every significant but one feature of Go has a pretty much direct analog in D, i.e. you can write Go code in D much like you can write C code in D. The one difference was Go's support for green threads. There's no technical reason why D can't have green threads, it's just that nobody has written the library code to do it. vibe has (experimental?) green threads, doesn't it? I don't keep up with vibe, so I may be wrong.
Re: Release D 2.067.0
On Wednesday, 25 March 2015 at 21:38:15 UTC, weaselcat wrote: On Tuesday, 24 March 2015 at 17:08:03 UTC, Martin Nowak wrote: Glad to announce D 2.067.0. This release comes with many improvements. The GC is a lot faster for most use-cases, we have improved C++ interoperability and fixed plenty of bugs. See the changelog for more details. http://dlang.org/changelog.html Download pages and documentation will be updated within the next few hours. http://downloads.dlang.org/releases/2.x/2.067.0/ http://ftp.digitalmars.com/ Until the binaries are mirrored to the official site, you can get them here. https://dlang.dawg.eu/downloads/dmd.2.067.0/ -Martin from the reddit thread: Anyone know if there's been any comparisons of different heapSizeFactor values? Primarly, compared to the default 2, 1.5 or 1.618. has anyone working on the GC actually done any comparisons of the new options? nothing?
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Thursday, 26 March 2015 at 22:43:06 UTC, ketmar wrote: On Thu, 26 Mar 2015 12:27:13 +, Chris wrote: ... or Google abandons Go! Ha ha ha. they almost did that with Dart, so they have no language to replace Go right now. i think that Go programmers are safe for three or five years. average Google product lifespan is something like 4 years.
Re: Release D 2.067.0
On Tuesday, 24 March 2015 at 17:08:03 UTC, Martin Nowak wrote: Glad to announce D 2.067.0. This release comes with many improvements. The GC is a lot faster for most use-cases, we have improved C++ interoperability and fixed plenty of bugs. See the changelog for more details. http://dlang.org/changelog.html Download pages and documentation will be updated within the next few hours. http://downloads.dlang.org/releases/2.x/2.067.0/ http://ftp.digitalmars.com/ Until the binaries are mirrored to the official site, you can get them here. https://dlang.dawg.eu/downloads/dmd.2.067.0/ -Martin from the reddit thread: Anyone know if there's been any comparisons of different heapSizeFactor values? Primarly, compared to the default 2, 1.5 or 1.618. has anyone working on the GC actually done any comparisons of the new options?
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Wednesday, 25 March 2015 at 23:00:32 UTC, bearophile wrote: Ola Fosheim Grøstad: Downplaying other languages makes the D crowd look desperate... That kind of articles are bad for the image of the D community (and the D code shown in that article is not the best). Bye, bearophile +1 but his points about go really are right.
Re: Release D 2.067.0
On Tuesday, 24 March 2015 at 17:58:54 UTC, Dicebot wrote: Arch Linux packages have been uploaded. Thanks for maintaining the D packages on arch.
Re: This Week in D #9 - marketing discussion, final beta, special interview with Sönke
On Monday, 16 March 2015 at 13:06:39 UTC, weaselcat wrote: On Monday, 16 March 2015 at 12:45:58 UTC, Martin Nowak wrote: On Monday, 16 March 2015 at 04:54:12 UTC, Adam D. Ruppe wrote: Ruby has over 6,000 packages, ...starting with letter A. It's over 100K in total. http://www.modulecounts.com/ Hey, that's over 6000 ;) Also, yes more interviews please. Also also, An example of a simple but fundamental issue are the defaults of the built-in attributes. I think some of them, for historical or compatibility reasons, are currently simply the wrong way around (pure, @safe, final and scope should really all be enabled by default, with scope providing recursive guarantees) and using them properly completely destroys the initial idea of having a clean language syntax. It's sometimes really sad to see modern idiomatic D code degrading into a mess of attributes and contract syntax noise. After all, a clean syntax used to be one of the key selling points. +1 for this entire paragraph, sometimes D looks simple and elegant, other times it looks like someone puked attributes.
Re: This Week in D #9 - marketing discussion, final beta, special interview with Sönke
On Monday, 16 March 2015 at 12:45:58 UTC, Martin Nowak wrote: On Monday, 16 March 2015 at 04:54:12 UTC, Adam D. Ruppe wrote: Ruby has over 6,000 packages, ...starting with letter A. It's over 100K in total. http://www.modulecounts.com/ Hey, that's over 6000 ;) Also, yes more interviews please.
Re: This Week in D #9 - marketing discussion, final beta, special interview with Sönke
On Monday, 16 March 2015 at 13:21:13 UTC, ponce wrote:
On Monday, 16 March 2015 at 13:11:56 UTC, weaselcat wrote:
An example of a simple but fundamental issue are the defaults
of the built-in attributes. I think some of them, for
historical or compatibility reasons, are currently simply the
wrong way around (pure, @safe, final and scope should really
all be enabled by default, with scope providing recursive
guarantees) and using them properly completely destroys the
initial idea of having a clean language syntax. It's
sometimes really sad to see modern idiomatic D code degrading
into a mess of attributes and contract syntax noise. After
all, a clean syntax used to be one of the key selling points.
+1 for this entire paragraph, sometimes D looks simple and
elegant, other times it looks like someone puked attributes.
Rust code is safe by default and it is littered with unsafe{ }
blocks.
I think this has more to do with Rust's extreme safety, many
things doable in @safe D code would be no-no in Rust(i.e, you
can't even manipulate pointers IIRC)
Re: GSoC 2015 - Application Rejected
On Tuesday, 3 March 2015 at 08:14:55 UTC, Russel Winder wrote: On Mon, 2015-03-02 at 23:00 +, CraigDillabaugh via Digitalmars-d-announce wrote: […] Yes, but I didn't see Rust, Nimrod, or Go on there, so I suppose we are on even footing with our main competition. It's called Nim now. I suspect there was a rationale for the change, but I am not sure it was worth it. The rationale was that Nimrod has a fairly negative meaning attached to it in American(?) English. I'm not sure if it exists in other English dialects.
Re: GSoC 2015 - Application Rejected
On Tuesday, 3 March 2015 at 00:45:12 UTC, Andrei Alexandrescu wrote: On 3/2/15 2:36 PM, weaselcat wrote: On Monday, 2 March 2015 at 19:08:49 UTC, CraigDillabaugh wrote: Unfortunately our organizational proposal for the 2015 Google Summer of Code was rejected. Thanks to everyone who helped out on this, especially to those who volunteered to mentor. I've asked Google to provide me with feedback, and I will post that here once/if I get something from them. If I am not asked to resign I am happy to volunteer for this post again next year. Hopefully I can learn something from this year and any feedback they provide. Cheers, Craig List of accepted projects https://www.google-melange.com/gsoc/org/list/public/google/gsoc2015 a lot of other languages got accepted :( Comparing our application with that of the accepted language projects might yield some insight. I ran a cursory read of Clojure's idea page and on first sight it seems comparable to ours'. -- Andrei Haskell's page just seems to be its bug tracker?
Re: This Week in D: Issue #4
On Wednesday, 11 February 2015 at 14:32:46 UTC, Adam D. Ruppe wrote: On Wednesday, 11 February 2015 at 11:21:46 UTC, Dominikus Dittes Scherkl wrote: Did I missed issue #5 ? No, I did; I was sick most of last week and decided to skip it, just going to bed instead on sunday night. Hope you feel better, health is more important than a blog update : )
Re: This Week in D, Issue 3
On Monday, 26 January 2015 at 05:15:51 UTC, Adam D. Ruppe wrote: I've been out of town this week and also dealing with trying to remotely find my lost dog (she got away from the sitter... and no luck yet :( ) so I haven't been as active as I often am in the D community, but I still made time to compile another issue! http://arsdnet.net/this-week-in-d/jan-25.html Also available via RSS: http://arsdnet.net/this-week-in-d/twid.rss This week's tip goes into the import statement which many people use but not everyone realizes what all it can do. D.announce seemed a bit less active this week too (my criteria for inclusion there is simply a new thread made since last time, so new posts in an existing thread don't count), but there were a lot of bug and pull request action this week (mostly related to the style tweaks)! At first I feared there wouldn't be enough content for you to do this weekly but I'm glad I was wrong. D seems more popular than ever. Can't wait for next week's update.
Re: This Week in D, issue 1
On Tuesday, 13 January 2015 at 14:08:58 UTC, Adam D. Ruppe wrote: I've started writing a weekly D newsletter. Here's the first issue, any feedback welcome! http://arsdnet.net/this-week-in-d/jan-12.html In the future, I intend to have it written by Saturday for a weekend release, so if you want something to appear this week, please try to get it to by before then. Thanks for this, I love being able to quickly see what major changes are happening in D.
Re: D idioms list
On Saturday, 10 January 2015 at 20:37:04 UTC, Walter Bright wrote: On 1/8/2015 2:21 AM, ponce wrote: I've started a list of curated D tips and tricks here: http://p0nce.github.io/d-idioms/ Anything that you wished you learned earlier at one point in the D world is welcome to be added or suggested. My contribution: http://digitalmars.com/articles/b68.html (Member function pointers in D) Sorry for the off-topic noise, but where will you be publishing your articles since Dr.Dobbs has closed? Sorry if you have answered this elsewhere.
Re: D idioms list
On Thursday, 8 January 2015 at 10:21:26 UTC, ponce wrote: I've started a list of curated D tips and tricks here: http://p0nce.github.io/d-idioms/ Anything that you wished you learned earlier at one point in the D world is welcome to be added or suggested. I think the focus should be on stuff that could make you more productive, or is just funky but that is up to debate. Of course the D Cookbook still stays irreplaceable for a consistent, in-depth discussion of being D-enabled. Thoughts? Not much to add but I enjoy reading 'idiomatic' D content - coming from C++, I feel like I'm often not writing my D code like I should be. Thanks for the extra resource.
Re: Programming in D book, draft of the first print edition and eBook formats
Congrats on (nearly) finishing your book. It's one of the best D resources available and very high quality.
Re: D is for Data Science
On Monday, 24 November 2014 at 15:27:19 UTC, Gary Willoughby wrote: Just browsing reddit and found this article posted about D. Written by Andrew Pascoe of AdRoll. From the article: The D programming language has quickly become our language of choice on the Data Science team for any task that requires efficiency, and is now the keystone language for our critical infrastructure. Why? Because D has a lot to offer. Article: http://tech.adroll.com/blog/data/2014/11/17/d-is-for-data-science.html Reddit: http://www.reddit.com/r/programming/comments/2n9gfb/d_is_for_data_science/ Why is File.byLine so slow? Having to work around the standard library defeats the point of a standard library.
Re: D is for Data Science
With algorithm.sort the deciles bench from the article runs twice as fast(it's in the reddit thread) I see array.sort is planned for future deprecation, what does future fall under?
