Re: OT: Photo of a single atom by David Nadlinger wins top prize
On 14/02/2018 1:11 AM, David Nadlinger wrote: On Tuesday, 13 February 2018 at 23:09:07 UTC, Ali Çehreli wrote: David (aka klickverbot) is a longtime D contributor […] … who is slightly surprised at the amount of media interest this has attracted. ;) — David Congrats and well done!
Re: Vulkan
On 13/02/2018 10:54 PM, Danni Coy wrote: On Wed, Feb 14, 2018 at 8:20 AM, Ivan Trombley via Digitalmars-d mailto:digitalmars-d@puremagic.com>> wrote: I wanted to do some experimentation with Vulkan using D. None of the projects that I found (derelict-vulkan, d-vulkan and erupted) work. Are there D bindings to Vulkan that actually work? strictly speaking you don't need a binding, you can access C code directly as long as you write compatible header definitions for the parts of vulkan you are actually using in your code. Which is then called a binding ;)
Re: "Why Black Boxes are so Hard to Reuse?", a lecture by Gregor Kiczales
On Wednesday, 14 February 2018 at 01:20:24 UTC, Mark wrote: I came across this one hour lecture [1] on Youtube. It's from 1994, but I think it's still very relevant today, both to developers in general and to the D language in particular. [...] I have mentioned some related thoughts by a designer of Common Lisp here before: https://forum.dlang.org/thread/jqbwxtdiyqqyzdthl...@forum.dlang.org
Re: Vulkan
On Wednesday, 14 February 2018 at 02:40:18 UTC, Mike Parker wrote: What doesn't it mean Eh, what *does* it mean.
Re: Vulkan
On Tuesday, 13 February 2018 at 22:20:15 UTC, Ivan Trombley wrote: I wanted to do some experimentation with Vulkan using D. None of the projects that I found (derelict-vulkan, d-vulkan and erupted) work. Are there D bindings to Vulkan that actually work? What doesn't it mean to say they don't work? Have you reported any issues? I don't see any in the DerelictVulkan repo. If something's broken, please report it so it can be fixed.
Re: OT: Photo of a single atom by David Nadlinger wins top prize
On 02/13/2018 05:11 PM, David Nadlinger wrote: On Tuesday, 13 February 2018 at 23:09:07 UTC, Ali Çehreli wrote: David (aka klickverbot) is a longtime D contributor […] … who is slightly surprised at the amount of media interest this has attracted. ;) — David Yeah... Especially when it's all about a missing pixel. :p Ali
"Why Black Boxes are so Hard to Reuse?", a lecture by Gregor Kiczales
I came across this one hour lecture [1] on Youtube. It's from 1994, but I think it's still very relevant today, both to developers in general and to the D language in particular. A TL;DR summary of the lecture: Abstraction is a central theme in software engineering, since it allows us to control complexity. However, most abstractions in software development do not (and cannot) completely hide their implementation; the implementation leaks via the performance characteristics of the abstraction. This is because the designer of the abstraction chose to implement its interface in some specific way, making design decisions that may be different than those that some clients would have wanted. The lecturer then suggests the following remedy: In addition to providing the client with a suitable interface, we should also allow him to make changes to the implementation through a separate "meta interface", i.e. we should allow him to change some (or all) of our design decisions. The lecturer suggests making such a meta interface using reflection and OO techniques but doesn't go deep into that. This reminds me a lot of D's Design by Introspection, and also of a previous paradigm that Andrei introduced to C++ (Policy Based Design [2]). C++ and Rust throw the phrase "zero cost abstractions" around but without good compile-time introspection support, you can't really get there - as soon as you make a non-trivial design decision you've limited the user of the abstraction in some way. For instance, the interfaces of Rust's HashMap [3] and C++'s unordered_map [4] do not allow for a custom collision handling policy. The Rust implementation uses Round Robin hashing while for C++ it isn't specified (as far as I can see). That said, Phobos doesn't have a hash table implementation at all so maybe this isn't the best example :=) Still, I think that D looks much better than them as far as "zero cost abstractions" go. [1] https://www.youtube.com/watch?v=5l2wMgm7ZOk [2] https://en.wikipedia.org/wiki/Policy-based_design [3] https://doc.rust-lang.org/std/collections/struct.HashMap.html [4] http://www.cplusplus.com/reference/unordered_map/unordered_map/
Re: OT: Photo of a single atom by David Nadlinger wins top prize
On 2/13/2018 5:11 PM, David Nadlinger wrote: On Tuesday, 13 February 2018 at 23:09:07 UTC, Ali Çehreli wrote: David (aka klickverbot) is a longtime D contributor […] … who is slightly surprised at the amount of media interest this has attracted. ;) — David You shouldn't be surprised. I'm amazed that such a photo is even possible! You have done the impossible. Mad props to you! -Walter
Re: Being Positive
On Tuesday, 13 February 2018 at 16:04:11 UTC, Abdulhaq wrote: Psychotic rabbit disturbed by programming related video. In other news don't poke the rabbit.
Re: Multiple Alis
On 2/12/2018 8:33 PM, Nick Sabalausky (Abscissa) wrote: I know another Ali I've tried to turn onto D, but he's pretty happy with Python. Oh, well. I don't think he deserves the name Ali :-)
Re: OT: Photo of a single atom by David Nadlinger wins top prize
On Tuesday, 13 February 2018 at 23:09:07 UTC, Ali Çehreli wrote: David (aka klickverbot) is a longtime D contributor […] … who is slightly surprised at the amount of media interest this has attracted. ;) — David
Re: OT: Photo of a single atom by David Nadlinger wins top prize
On 13 February 2018 at 15:09, Ali Çehreli via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > David (aka klickverbot) is a longtime D contributor. > > > https://www.epsrc.ac.uk/newsevents/news/single-trapped-atom- > captures-science-photography-competitions-top-prize/ I was just about to post that here :P
Re: Vulkan
On Tuesday, 13 February 2018 at 22:20:15 UTC, Ivan Trombley wrote: I wanted to do some experimentation with Vulkan using D. None of the projects that I found (derelict-vulkan, d-vulkan and erupted) work. Are there D bindings to Vulkan that actually work? Maybe these work, not sure; https://github.com/Rikarin/VulkanizeD
OT: Photo of a single atom by David Nadlinger wins top prize
David (aka klickverbot) is a longtime D contributor. https://www.epsrc.ac.uk/newsevents/news/single-trapped-atom-captures-science-photography-competitions-top-prize/ Ali
Re: Vulkan
On Wed, Feb 14, 2018 at 8:20 AM, Ivan Trombley via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > I wanted to do some experimentation with Vulkan using D. None of the > projects that I found (derelict-vulkan, d-vulkan and erupted) work. > > Are there D bindings to Vulkan that actually work? > strictly speaking you don't need a binding, you can access C code directly as long as you write compatible header definitions for the parts of vulkan you are actually using in your code. eg extern(C) int someExternalCLibraryFunction (); auto a = someExternalCLibraryFunction(); Just make sure that you link to that C Library when you build. If you do this on an as needed basis It's not too painful.
Vulkan
I wanted to do some experimentation with Vulkan using D. None of the projects that I found (derelict-vulkan, d-vulkan and erupted) work. Are there D bindings to Vulkan that actually work?
Re: Being Positive
On Tuesday, 13 February 2018 at 18:25:25 UTC, 9il wrote: Do we follow main initial promise to be better / to replace C/C++? The last one question is the most important. Instead of targeting a real market for as, which is C/C++, we are building a "trendy" language to compete with Python/Java/Go/Rust. Trends are changing but C/C++ market are waiting us! That is probably true. Also in the convenience department any small language will have problems reaching a high valuation... Rust seems to be able to pick up some of the C market though.
Re: Being Positive
On 2/12/18 10:46 PM, jmh530 wrote: On Tuesday, 13 February 2018 at 03:15:44 UTC, bachmeier wrote: I don't see a negative trend. [snip] I don't know if there's a negative trend or not, but every 2 or 3 months there's inevitably a thread about things D needs to add or improve that tends to devolve into complaints about the language. One thing that has happened visibly starting around December 2017 is that most activity has moved onto github. I can barely keep up with the action going on in there. This is good on many levels, among which obviously there's progress being made. Also, on github it's much easier to keep things on track because the implicit goal is to reach a binary conclusion pull/not, whereas in idle forum discussion the implicit incentive is to keep discussion going. -- Andrei
Re: Being Positive
On Tuesday, 13 February 2018 at 07:35:19 UTC, Dukc wrote: On Monday, 12 February 2018 at 23:54:29 UTC, Arun Chandrasekaran wrote: Sorry if I'm hurting someone's sentiment, but is it just me who is seeing so much negative trend in the D forum about D itself? Well, programmers are engineers, and engineers tend to focus on things that need improvement. We aren't constantly effusive and positive because we care. We care and we see the cracks in the plaster and know that we, all of us, can do better; can BE better. Often all in different ways that others don't agree with. And that's fine. That said, there's a difference between constructive and destructive negativity. It pays to recognise the difference and not indulge the latter. -Wyatt
Re: Being Positive
On Monday, 12 February 2018 at 23:54:29 UTC, Arun Chandrasekaran wrote: Sorry if I'm hurting someone's sentiment, but is it just me who is seeing so much negative trend in the D forum about D itself? The reason is (as I see it) is very simple. People have/had a lot of expectations about the language, its future and invest/invested a lot of their time/money to the language. But D is a community driven language and sometime we can have question like that: - - - - - Do we have strong business driven goals? (Go) Do we have strong theory driven goals? (Rust) Do we follow main initial promise to be better / to replace C/C++? The last one question is the most important. Instead of targeting a real market for as, which is C/C++, we are building a "trendy" language to compete with Python/Java/Go/Rust. Trends are changing but C/C++ market are waiting us! - - - - - Community is moving. I see it during 8-9 years. The problem is direction and speed. So, if you see next time a negative emotions from someone just remember that possibly this person likes the language and wants it to be better then it is. Best, Ilya
Re: Multiple Alis
On 02/13/2018 03:05 AM, Andrea Fontana wrote: > I read this thread just because it was so strange that Ali was calling > "Multiple Alias This" in this way. I like it! :) Actually, I tried to make a code joke for this thread with "alias this" and discovered a compiler bug: https://issues.dlang.org/show_bug.cgi?id=18429 That bug has promptly been fixed by one of the multiple awesome Razvans: https://forum.dlang.org/post/nu5rap$m5a$1...@digitalmars.com Ali
Re: Being Positive
On Tuesday, 13 February 2018 at 17:03:26 UTC, flamencofantasy wrote: On Tuesday, 13 February 2018 at 02:29:46 UTC, Seb wrote: On Monday, 12 February 2018 at 23:54:29 UTC, Arun Chandrasekaran wrote: [...] Yeah, I think it's a different community. I'm not sure why this is the case, maybe because Rust doesn't promise to be a great language and people suffer enough from fighting their compiler all day, that they have no energy left for trolling? [...] Never heard of Steve Klabnik but browsing through his blog I came across this; http://words.steveklabnik.com/the-expressive-c-17-coding-challenge-in-rust and here is the original C++ challenge; https://www.fluentcpp.com/2017/10/23/results-expressive-cpp17-coding-challenge/ I wonder what the some code would like like in D. Previous discussions on this: https://forum.dlang.org/post/or0o85$tvc$1...@digitalmars.com
Re: Being Positive
On Tuesday, 13 February 2018 at 02:29:46 UTC, Seb wrote: On Monday, 12 February 2018 at 23:54:29 UTC, Arun Chandrasekaran wrote: [...] Yeah, I think it's a different community. I'm not sure why this is the case, maybe because Rust doesn't promise to be a great language and people suffer enough from fighting their compiler all day, that they have no energy left for trolling? [...] Never heard of Steve Klabnik but browsing through his blog I came across this; http://words.steveklabnik.com/the-expressive-c-17-coding-challenge-in-rust and here is the original C++ challenge; https://www.fluentcpp.com/2017/10/23/results-expressive-cpp17-coding-challenge/ I wonder what the some code would like like in D.
Re: Being Positive
On Monday, 12 February 2018 at 23:54:29 UTC, Arun Chandrasekaran wrote: Sorry if I'm hurting someone's sentiment, but is it just me who is seeing so much negative trend in the D forum about D itself? I don't remember seeing so much negative about Rust on rust forum and so on. Do you think it will help in reminding people not to post any negative things? It shouldn't become strict moderation, but at the same time, I really don't like seeing so much negative trend. I would even go to the extent and suggest to email Walter/Andrei in person (even if they don't agree) to vent your frustration with D, but please don't post it on the forum. Several structural reasons for negativity (I'll be negative myself saying all that): - It's an internet forum - and an addictive one - so each message has a bit of social standing at stake. Strong talk is thus mechanically encouraged, makes you appear strong and knowledgeable, like a big meeting room. It's common for internet forums to devolve into negativity. - Because we don't ban people from the forums, some individuals that don't use D and have zero skin in the game come here to spread negativity at every occasion. If you delve into the smaller D communitites they aren't especially negative, on the contrary. The forums are not the D community at large, it's an addictive subset of it. If the forums were _worse_ to use, we wouldn't have this problem.
Re: Being Positive
On Tuesday, 13 February 2018 at 11:36:35 UTC, psychoticRabbit wrote: On Tuesday, 13 February 2018 at 08:08:28 UTC, bauss wrote: On Tuesday, 13 February 2018 at 01:32:29 UTC, psychoticRabbit wrote: Personally, I found that youtube video (Life is better with Rust's community automation - YouTube) rather disturbing. Psychotic rabbit disturbed by programming related video. In other news
Re: missing HexString documentation
On 2/11/18 4:48 PM, Walter Bright wrote: I also notice that hex strings are not simply equivalent to strings with \x in them -- the latter is more constrained, as it must be a pair of hex digits per \x. hex strings allow spaces between them. The idea was to be able to cut&paste text from things like hex dumps, which include whitespace formatting. I've never seen a hex dump where the individual nibbles were separated by spaces in odd ways. In other words, what I was saying is that: "\x12\x34" could be written as: x"1 23 4" which is... odd. What it does is make it so you can't reuse the parsing code inside the string escape processor to handle the hex string, necessitating an extra 80-line function. I wouldn't call invoking CTFE "no overhead" It is no overhead in the generated code. It's overhead that adds up, memory and time-wise. Really, the memory concerns of using CTFE are a bigger problem than the extra tenths of a second of compile time. I tested it out, and generating a hex string of about 600 bytes took 3x as long as using builtin hex strings. That's only a potential issue if you've got a very, very large number of hex strings. And if you do, those strings can be put in a separate module and compiled separately. Or a very large hex string (very feasible). But very true that there are mitigating methods that can be used. Well, nobody asked :) Besides, it's still not "fixed", as it has the same poor performance as the previous version. And the new version has broken existing code. It didn't break code that used x"deadbeef", it broke code that used the broken hexString. In the past, we have not broken code, even when it depends on known bugs, if we can help it. But maybe if we can fix the bug I filed above, it won't matter. What the update shows is that you have to jump through incredible hoops to get the compiler not to include your compile-time only generation code in the resulting binary. With a language that supports both templates and separate compilation, this will always be an issue. Essentially, you have instantiated the template eagerly, which kind of, sort of, defeats the purpose of a template. Though, you still do get the benefit of code generation, it's just not an "open-ended" template that you can instantiate with any type. Perhaps we should be using this pattern all throughout phobos where strings are involved, since there are ever only 3 types you instantiate with. The solution here is not "incredible", it is just not obvious. The solution isn't incredible, but the fact that this solution is the only way to get the CTFE-only code not to creep into your object file is a bit dissatisfying. You would think the linker/compiler would not inject the unused function into the object file without having to do this. And nothing has changed here, it's still a library function, as it was before. What's changed is it works now with -betterC, and it doesn't produce bloat in the executable. I think this is due to functions-that-aren't-used being included. In other words, there was nothing inherent in the old library code that created a requirement for druntime to be included. The bloat is also a deficiency of the compiler, not the code itself. But if you already have the compiler feature, I don't see why we should remove it because a slower library version exists. It was not an arbitrary and capricious decision, and the rationale behind it was presented here multiple times. If you are not convinced, that's cool, but the "why" should be pretty clear. I missed the discussion (there are times where I can't pay attention to D for a month or so due to being busy). But in any case, sure I understand the "why", but the cost/benefit for me was not high enough, and in some aspects, it is all cost, no benefit. In any case, it isn't a decision that needs to be reversed, as there is a workable solution in the library, even if it's sub-optimal. I just think it's not as beneficial as has been reported. -Steve
Re: Being Positive
On Tuesday, 13 February 2018 at 03:40:52 UTC, Jonathan M Davis
wrote:
{snip} I suspect that part of it is that a lot of folks seem to
come to D looking for the perfect language after having be
frustrated by another language like C++, and while D is a lot
closer to that for many folks than other languages are, it
still has plenty of flaws, and we want those flaws fixed so
that it can become the perfect language. Obviously, that's not
going to happen. No language is perfect, but the vocal portion
of the D community does have a tendency to want to push for
everything that's arguably wrong with D to be fixed, and that
can result in a lot of negativity, but it can also result in
things getting fixed (though that requires actually doing
something about it rather than just complaining).
I think what would help here is a D wiki page (maybe
could be expanded) that
lists perceived flaws in the language, together with an
explanation whether or not it's really considered a flaw, and if
it is, why it's not being fixed. Those not-being-fixed reasons
are the real crux of the issue, I think:
* If the reason is lack of manpower or expertise in the area,
then complaints about the flaw can be responded with, "see [that
wiki page], can you pitch in?".
* If the reason is that by fixing the issue it would cause
problems {x}, {y}, and {z}, then the person raising the complaint
learns something about language design.
* If the reason is the language design team's personal
preference on the matter, and the tradeoffs are listed, then
users learn what the tradeoffs are and have to live with it.
* If the reason for not fixing the issue is hesitation to break
backward compatibility, then this may be an issue that D
leadership wants to hear feedback on.
But I think pointing people to that wiki page and laying it out
like that may diffuse a lot of arguments.
Re: Multiple Alis
On Tuesday, 13 February 2018 at 11:05:03 UTC, Andrea Fontana wrote: On Tuesday, 13 February 2018 at 00:47:42 UTC, Ali Çehreli wrote: Nothing serious but in case you are confused, there are at least three separate and awesome Alis frequenting these newsgroups. :) From: Ali Çehreli Email: acehr...@yahoo.com Almost always ends posts simply with "Ali" From: Ali Email: fakeem...@example.com Usually does not use any signature From: aliak Email: someth...@something.com Usually ends with "Cheers", occasionally with an added "- Ali" Ali "me" I read this thread just because it was so strange that Ali was calling "Multiple Alias This" in this way. LOL +1, + @ Ali Çehreli (trying to use a Gravatar picture would be cool, you may use a picture of your wonderful book, if you are to shy :-)
Re: GSOC 2018 - no slots for D
On Tuesday, 13 February 2018 at 13:33:00 UTC, Andrei Alexandrescu wrote: On 02/12/2018 08:20 PM, Jakub Łabaj wrote: https://summerofcode.withgoogle.com/organizations/ Seems like we didn't make it this year :( Is there any feedback from Google when they don't accept an organisation? Do you think that maybe they don't perceive D as a viable option or just the projects could have been defined better? Google does not provide feedback to rejected organizations. Far as I can imagine approval depends on a number of imponderables such as the person who does the review etc. GSoC 2018 was not a considerable part of our plans so we are not affected negatively. I'd like to take this opportunity to thank Seb who worked on the application. It was stronger than in past years (including those when we've been accepted). Andrei I also want to thank Seb for the excellent work he did on this year's application. It looked really solid, so I am a bit disappointed it didn't get accepted, but I am sure D will carry on without Google's money just fine. Being a big fan of conspiracy theories I personally think it was blocked by the Go folks :o)
Re: Being Positive
On Tuesday, 13 February 2018 at 14:17:00 UTC, Steven Schveighoffer wrote: On 2/12/18 11:29 PM, Nick Sabalausky (Abscissa) wrote: A bunch of stuff I 100% agree with. Me too. So refreshing to read. Mike
Re: Being Positive
On 2/12/18 11:29 PM, Nick Sabalausky (Abscissa) wrote: A bunch of stuff I 100% agree with. Thanks. Let's keep the negativity coming, and we'll all be better for it ;) Problems don't get fixed if you ignore them or pretend they don't exist. It's part of a healthy debate. If you don't like the negativity, or you feel it's just trolling, ignore it. -Steve
Re: immutable postblit unusable?
On 2/11/18 3:25 AM, Jonathan M Davis wrote: In the case of immutable, the postblit is actually completely unnecessary, because there's no need to do a deep copy of an immutable object, since it's guaranteed to never change its value (whereas with const, a deep copy can still be necessary, since other references to that data may be mutable and could thus change the data). What about reference counting? Essentially, you could be changing values external to the type itself. I don't think postblit should be illegal on immutable types. -Steve
Re: GSOC 2018 - no slots for D
On Tuesday, 13 February 2018 at 13:33:00 UTC, Andrei Alexandrescu wrote: On 02/12/2018 08:20 PM, Jakub Łabaj wrote: https://summerofcode.withgoogle.com/organizations/ Seems like we didn't make it this year :( Is there any feedback from Google when they don't accept an organisation? Do you think that maybe they don't perceive D as a viable option or just the projects could have been defined better? Google does not provide feedback to rejected organizations. Far as I can imagine approval depends on a number of imponderables such as the person who does the review etc. GSoC 2018 was not a considerable part of our plans so we are not affected negatively. I'd like to take this opportunity to thank Seb who worked on the application. It was stronger than in past years (including those when we've been accepted). Andrei just out of interest, is that application publicly available? I just would be interested to see what it was about, that is all.
Re: GSOC 2018 - no slots for D
On 02/12/2018 08:20 PM, Jakub Łabaj wrote: https://summerofcode.withgoogle.com/organizations/ Seems like we didn't make it this year :( Is there any feedback from Google when they don't accept an organisation? Do you think that maybe they don't perceive D as a viable option or just the projects could have been defined better? Google does not provide feedback to rejected organizations. Far as I can imagine approval depends on a number of imponderables such as the person who does the review etc. GSoC 2018 was not a considerable part of our plans so we are not affected negatively. I'd like to take this opportunity to thank Seb who worked on the application. It was stronger than in past years (including those when we've been accepted). Andrei
Re: Which language futures make D overcompicated?
On Tuesday, 13 February 2018 at 11:36:50 UTC, Andre Pany wrote: On Tuesday, 13 February 2018 at 11:14:25 UTC, rikki cattermole wrote: On 13/02/2018 11:11 AM, Russel Winder wrote: On Tue, 2018-02-13 at 10:45 +, aberba via Digitalmars-d wrote: […] I wish complaints about Dub would include exactly what was impossible with it. There's no reason to throw dub away and start something new. If one can run cmake before build in dub, then a lot is possible. Those edge cases can be ironed out. I think there have been many actual complaints made in detail in this thread. There is always a reason to replace, because you can build on what has gone before and do better. CMake is part of the problem. Dub fulfills all my use cases so I don't complain. Those here with not much issue with dub will also not complain. And that does not make it a minority opinion without stats to prove dub usage. No problem, and I guess you'll be happy to carry on using Dub after something new and better appears. In the case of Maven → Gradle, many people still use Maven even though it is provably inferior to Gradle simply because they cannot be bothered to change. At point, dub will likely remain the default package management tool. The build functionality can be improved for those who deal with such stuff often. Manpower is what remains. […] Why should Dub remain the one true way? Just because it was the first doesn't mean it is the best. It wasn't the first and it was the best in over a 10 year period. While I am really suffer from some painful behavior of dub, in my opinion it is a great tool and it would damage the D ecosystem to go away from dub. Companies already starting investing into this tool. In my case, without dub it would not be possible at all to use D at work. The involved developers doing a great job. Kind regards André Well backward compatibility with dub could always be a possibility.
Re: Old but interesting link as to the low adoption reason for D
On Tuesday, 13 February 2018 at 11:45:00 UTC, Bo wrote: * Your guaranteed that this will have maintainers. Unlike alternative unofficial solutions. This is where you're wrong. Considering that D is an open-source language, nothing is guaranteed. Neither is there any guarantee who works on what and the same people who works on the "unofficial libraries" might as well be the __same__ people who works on the "official libraries"... That is actually the case in many of the __popular__ "unofficial" libraries, that they also contribute to D itself. * Guaranteed for a official stable API that will be similar across libraries. Cutting down on time for new developers to get familiar with the language. I partially agree with this, but again history shows that D's official API sometimes isn't as reliable as other unofficial equivalents. There's just a lot of restrictions in how the API is designed in ex. Phobos, which is why new modules sometimes just gets frozen for an unknown time and/or gets completely abandoned. That same issue can be said about some unofficial libraries, but in those cases it's usually just because they don't gather the attention they deserve and that is where I agree with your point. Perhaps just adding unofficial libraries as official libraries would be the best solution. * Having a load of different Independent libraries that "do the same but not exactly the same" is simply bad practice. Case and point: https://code.dlang.org/search?q=mysql No official library, some are not supported, some are duplicates with minor changes, no official API or standard... can go on a long time. My point above stands here too.
Re: Being Positive
On Monday, 12 February 2018 at 23:54:29 UTC, Arun Chandrasekaran wrote: Sorry if I'm hurting someone's sentiment, but is it just me who is seeing so much negative trend in the D forum about D itself? Here's an example from 2013, just a few months after I started using D. Andrei posted that Facebook had started using D in production. Someone thought the best possible response was to post this: When you will look at claim that some language (lets take for example C# or Java) "supports feature X", that really means that the feature is supported. In D this for sure means that the feature is either broken or misdesigned (shared libraries, routine code breakages, obsolete ms32 object format, AA arrays, shared, const postblits, odd template crosstalk bugs, type system holes, segfaulting lambdas, unstable stdlib, absent of third-party libraries). Untill this stuff is fixed this is a huge barrier irrespective of whether D is used in Facebook or not.
Re: Old but interesting link as to the low adoption reason for D
On Tuesday, 13 February 2018 at 01:46:02 UTC, Token wrote: D should recognize and embrace its nature as research platform/compiler enthusiasts playground favorite. I think this is a really good point, and one that D should be proud of. That is pretty much how I see D, and I really enjoy seeing how people 'play' with it. You get some really interesting outcomes, including this one I saw today: "abc".repeat(1000).joiner.writeln; https://forum.dlang.org/thread/nmewpndfcyvidcvxc...@forum.dlang.org Stuff like that comes from playing around. But.. I would add.. that D already can (and already does) solve a great number of real world programming problems, while falling short of solving many others. But modern day demands of programming languages are really complex, and getting more and more so by the day...as the world seeks to become more and more connected - and 'safer'. Personally, I think C++ has more challenges to contend with than D, in terms of becoming a modern day programming language.
Re: Old but interesting link as to the low adoption reason for D
On 13/02/2018 11:45 AM, Bo wrote: Community attitude is just as important as the language. As a language D may been gaining exposure but if you dislike new people coming here and pointing out major and minor issues, then that exposure is useless and will only reinforce a negative image for the language. No point in putting time feeding trolls, time is money after all. We like constructive reports. Most of the time however outsiders don't provide or willing to help with that. Some of us do attempt at the very least to just ignore the non-productive ones, since it isn't going to help anyone here.
[OT] - Re: Workaround for https://issues.dlang.org/show_bug.cgi?id=18422?
On Sunday, 11 February 2018 at 15:34:07 UTC, Andrei Alexandrescu wrote: I'm trying to sketch a simple compile-time reflection system, and https://issues.dlang.org/show_bug.cgi?id=18422 is a blocker of the entire approach. BTW please write a descriptive subject, not a bug ID. The #dbugfix posts of late without description make it annoying to browse the newsgroup - thanks!
Re: Old but interesting link as to the low adoption reason for D
On Tuesday, 13 February 2018 at 09:11:44 UTC, ketmar wrote: because Business Developers wants it that way. they are... well... Doing Business, and they wants someone to maintain all the libraries they are using. for free, of course. and what can be better than to offload this burden to language developers? ... really? This is the attitude here. almost each time we hear about "D should have XXX in standard library", it comes either from Business Developer, The reason why people prefer official supported library functionality is because: * Your guaranteed that this will have maintainers. Unlike alternative unofficial solutions. * Guaranteed for a official stable API that will be similar across libraries. Cutting down on time for new developers to get familiar with the language. * Having a load of different Independent libraries that "do the same but not exactly the same" is simply bad practice. Case and point: https://code.dlang.org/search?q=mysql No official library, some are not supported, some are duplicates with minor changes, no official API or standard... can go on a long time. If your idea is that people need to sift past the junk each time and hope that the library they pick is still supported in 5 years, your dead wrong. It does not work like that in any business environment. If you want a language to be adopted beyond hobbyist, you need to offer more then simply a language. Languages are a dime a dozen, well supported languages with a thriving eco-system that is a different market. People seem to have it in their head that its a good thing to not have a lot of officially supported libraries. Well, from a business perspective it is simply not feasible to adopt a language, when it only offers, quote: "10% improvement", and the rest of the eco-system relies on those same (unpaid) people. People who one day can simply drop all support on packages. or from Business Developer in Disguise. 'cause they always want someone to work for 'em for free. I have no problem paying as do a lot of people but do you hand over your money to projects where to attitude does not align with yours? I put money in several projects only to see no good come from it. I learn from my business mistakes. Do i need a language that keeps pushing more advanced features while introducing regressions all the time. Or do i prefer a stable language with official supported libraries that is easy to learn for new employees and has no baggage holding it back. Pick one ... and guess what gets a language adopted by us. I noticed after reading topics how there is a very clear group of people, with a real motivation to maintain the status quo. They have found their language and use any excuse to not gain a mass market audience. Community attitude is just as important as the language. As a language D may been gaining exposure but if you dislike new people coming here and pointing out major and minor issues, then that exposure is useless and will only reinforce a negative image for the language. No point in putting time feeding trolls, time is money after all. Zhù nǐ hǎo yùn! Wish you luck!
Re: Being Positive
On Tuesday, 13 February 2018 at 09:46:14 UTC, Dave Jones wrote: Arguing, friction, grumbling, it's all a symptom of Ds open volunteer based development process IMO. It's also how democracy works. Walk into any parliament session, in any democracy, and you will see arguing, friction and grumbling. You won't however, see that in authoritarian countries.
Re: Which language futures make D overcompicated?
On Tuesday, 13 February 2018 at 11:14:25 UTC, rikki cattermole wrote: On 13/02/2018 11:11 AM, Russel Winder wrote: On Tue, 2018-02-13 at 10:45 +, aberba via Digitalmars-d wrote: […] I wish complaints about Dub would include exactly what was impossible with it. There's no reason to throw dub away and start something new. If one can run cmake before build in dub, then a lot is possible. Those edge cases can be ironed out. I think there have been many actual complaints made in detail in this thread. There is always a reason to replace, because you can build on what has gone before and do better. CMake is part of the problem. Dub fulfills all my use cases so I don't complain. Those here with not much issue with dub will also not complain. And that does not make it a minority opinion without stats to prove dub usage. No problem, and I guess you'll be happy to carry on using Dub after something new and better appears. In the case of Maven → Gradle, many people still use Maven even though it is provably inferior to Gradle simply because they cannot be bothered to change. At point, dub will likely remain the default package management tool. The build functionality can be improved for those who deal with such stuff often. Manpower is what remains. […] Why should Dub remain the one true way? Just because it was the first doesn't mean it is the best. It wasn't the first and it was the best in over a 10 year period. While I am really suffer from some painful behavior of dub, in my opinion it is a great tool and it would damage the D ecosystem to go away from dub. Companies already starting investing into this tool. In my case, without dub it would not be possible at all to use D at work. The involved developers doing a great job. Kind regards André
Re: Being Positive
On Tuesday, 13 February 2018 at 08:08:28 UTC, bauss wrote: On Tuesday, 13 February 2018 at 01:32:29 UTC, psychoticRabbit wrote: It is a human right..to complain ;-) Not to be that guy, but technically you have no rights in an online community. You have privileges. You may have the privilege of participating in an online community, sure. But expressing something 'negative' would fall under the right to freedom of thought, opinion, an expression (Article 19 of Universal Declaration of Human Rights). It takes a very special kind of community to recognise that the community does not come at the expense of the rights of the individual. It also takes a very special kind of person to know that the individual does not come at the expense of the rights of the community. Many communities, and individuals, continue to struggle with this philosophy - preferring one over the other. That is the real cause of conflict, not the expression of negativity. Personally, I found that youtube video (Life is better with Rust's community automation - YouTube) rather disturbing.
Re: Which language futures make D overcompicated?
On 13/02/2018 11:11 AM, Russel Winder wrote: On Tue, 2018-02-13 at 10:45 +, aberba via Digitalmars-d wrote: […] I wish complaints about Dub would include exactly what was impossible with it. There's no reason to throw dub away and start something new. If one can run cmake before build in dub, then a lot is possible. Those edge cases can be ironed out. I think there have been many actual complaints made in detail in this thread. There is always a reason to replace, because you can build on what has gone before and do better. CMake is part of the problem. Dub fulfills all my use cases so I don't complain. Those here with not much issue with dub will also not complain. And that does not make it a minority opinion without stats to prove dub usage. No problem, and I guess you'll be happy to carry on using Dub after something new and better appears. In the case of Maven → Gradle, many people still use Maven even though it is provably inferior to Gradle simply because they cannot be bothered to change. At point, dub will likely remain the default package management tool. The build functionality can be improved for those who deal with such stuff often. Manpower is what remains. […] Why should Dub remain the one true way? Just because it was the first doesn't mean it is the best. It wasn't the first and it was the best in over a 10 year period.
Re: Which language futures make D overcompicated?
On Tue, 2018-02-13 at 10:45 +, aberba via Digitalmars-d wrote: > […] > I wish complaints about Dub would include exactly what was > impossible with it. There's no reason to throw dub away and start > something new. If one can run cmake before build in dub, then a > lot is possible. Those edge cases can be ironed out. I think there have been many actual complaints made in detail in this thread. There is always a reason to replace, because you can build on what has gone before and do better. CMake is part of the problem. > Dub fulfills all my use cases so I don't complain. Those here > with not much issue with dub will also not complain. And that > does not make it a minority opinion without stats to prove dub > usage. No problem, and I guess you'll be happy to carry on using Dub after something new and better appears. In the case of Maven → Gradle, many people still use Maven even though it is provably inferior to Gradle simply because they cannot be bothered to change. > At point, dub will likely remain the default package management > tool. The build functionality can be improved for those who deal > with such stuff often. Manpower is what remains. […] Why should Dub remain the one true way? Just because it was the first doesn't mean it is the best. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Multiple Alis
On Tuesday, 13 February 2018 at 00:47:42 UTC, Ali Çehreli wrote: Nothing serious but in case you are confused, there are at least three separate and awesome Alis frequenting these newsgroups. :) From: Ali Çehreli Email: acehr...@yahoo.com Almost always ends posts simply with "Ali" From: Ali Email: fakeem...@example.com Usually does not use any signature From: aliak Email: someth...@something.com Usually ends with "Cheers", occasionally with an added "- Ali" Ali "me" I read this thread just because it was so strange that Ali was calling "Multiple Alias This" in this way.
Re: Which language futures make D overcompicated?
On 13/02/2018 10:45 AM, aberba wrote: On Sunday, 11 February 2018 at 11:47:25 UTC, rikki cattermole wrote: snip Will it result in binaries that are decent? Probably not for most use cases. Can you file a bug report on this? Nah this should remain out of scope. If binary (from e.g. cmake) exists, do not run cmake. Easy!
Re: Which language futures make D overcompicated?
On Sunday, 11 February 2018 at 11:47:25 UTC, rikki cattermole wrote: On 11/02/2018 11:40 AM, Jonathan M Davis wrote: On Sunday, February 11, 2018 11:26:30 rikki cattermole via Digitalmars-d wrote: On 11/02/2018 11:18 AM, Russel Winder wrote: Clearly though there is a problem with Dub as a build system for many of it's users – or rather people who try and reject. Put simply, they expect far too much. Dub's scope is limited, lets not forget that. The problem with that is that if dub is the way to build D projects in general, then it needs to be able to do pretty much whatever you need to do for pretty much any project - even if that involves backdoors. You need to be able to do arbitrary stuff with your builds. It's not as critical for applications so long as dub provides an easy way to link in any libraries that it pulls in, but dub needs to be able to build libraries no matter what crazy stuff you need to do, otherwise, those libraries can't interact with the dub ecosystem, and dub is how D projects in general pull in their dependencies. So, for instance, if your D library has to build C or C++ code and link that in as part of what it does, that needs to be possible with dub, even if dub itself doesn't handling building code that isn't D. Also, if you need to generate code as part of your build and then build those files, that needs to be possible. And the way that dub is set up at this point, that sort of stuff is rather difficult to do. dub wouldn't have to be all that powerful if it were simply a handy build tool for the average use case, but when it's tied in to package management for D libraries and is the primary way that D projects pull in libraries, it needs to be far more than a simple build tool. And right now, it's not far enough away from being a simple build tool. - Jonathan M Davis Dub can do everything that you have described. You are fully free to run cmake if you wish before the build. I wish complaints about Dub would include exactly what was impossible with it. There's no reason to throw dub away and start something new. If one can run cmake before build in dub, then a lot is possible. Those edge cases can be ironed out. Dub fulfills all my use cases so I don't complain. Those here with not much issue with dub will also not complain. And that does not make it a minority opinion without stats to prove dub usage. At point, dub will likely remain the default package management tool. The build functionality can be improved for those who deal with such stuff often. Manpower is what remains. Will it result in binaries that are decent? Probably not for most use cases. Can you file a bug report on this? Its a hard problem to solve, I just wish people respected dub's scope more. Because it is very decently well scoped for its job already. Same opinion here.
Re: Dub, Cargo, Go, Gradle, Maven
On Tuesday, 13 February 2018 at 10:06:43 UTC, welkam wrote: ADG? Google doesnt find anything relevant Acyclic directed graph
Re: Dub, Cargo, Go, Gradle, Maven
ADG? Google doesnt find anything relevant
Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests
On 2018-02-12 23:35, Walter Bright wrote: The last dstep commit was November 2017. Yes? I've been working on a separate branch lately I take it dstep spawns the clang compiler? No, it uses libclang, i.e. using the Clang compiler as a library. -- /Jacob Carlborg
Re: Being Positive
On Monday, 12 February 2018 at 23:54:29 UTC, Arun Chandrasekaran wrote: Sorry if I'm hurting someone's sentiment, but is it just me who is seeing so much negative trend in the D forum about D itself? I don't remember seeing so much negative about Rust on rust forum and so on. Do you think it will help in reminding people not to post any negative things? It shouldn't become strict moderation, but at the same time, I really don't like seeing so much negative trend. I would even go to the extent and suggest to email Walter/Andrei in person (even if they don't agree) to vent your frustration with D, but please don't post it on the forum. I think the thing is that the main D newsgroup has always felt like a bunch of people arguing over how to make D better, and that's kind of what it's always been, new ideas and directions are discussed in here by the main devs. Do Go and Rust have similar user groups, or do they do all that kind of stuff behind closed doors and then dictate from the top of a tower? Arguing, friction, grumbling, it's all a symptom of Ds open volunteer based development process IMO.
Re: Bye bye, fast compilation times
On Tuesday, 13 February 2018 at 05:47:10 UTC, Dmitry Olshansky wrote: Was once on my together with other OS memory manager functions, but postponed the work indefinetly. https://github.com/dlang/druntime/pull/1549 If someone is willing to revive that I’d gladly assist with review. Lastly on Windows it would need FlushCpuCaches call before executing new memory. And ofc JIT is cool, but it would be more cool to have sane interpreter that doesn’t leak sooner. Simply put JIT is x5 work due to different architectures and seeing first-hand how it goes I’m not sure we want that in our compiler yet. Since dmd is only targeting x86/x86_64 there is really just one arch to support for now. All the others can fallback to either the interpreter or generated c code compiled into a shared lib :) newCTFE already provides a very low-level IR that should be trivially translatable to machine -code. (famous last words :o) )
Re: Old but interesting link as to the low adoption reason for D
welkam wrote: On Monday, 12 February 2018 at 22:10:49 UTC, Bo wrote: * Lack of default OFFICIAL libraries like HTTP(s), database access, ... Why there should be one default OFFICIAL library for anything? because Business Developers wants it that way. they are... well... Doing Business, and they wants someone to maintain all the libraries they are using. for free, of course. and what can be better than to offload this burden to language developers? almost each time we hear about "D should have XXX in standard library", it comes either from Business Developer, or from Business Developer in Disguise. 'cause they always want someone to work for 'em for free.
Re: Old but interesting link as to the low adoption reason for D
On Monday, 12 February 2018 at 22:10:49 UTC, Bo wrote: * Lack of default OFFICIAL libraries like HTTP(s), database access, ... Why there should be one default OFFICIAL library for anything? Writing libraries is about choosing between different tradeoffs so no library satisfy all use cases. Also its ecosystem problem not language
Re: Being Positive
On Monday, 12 February 2018 at 23:54:29 UTC, Arun Chandrasekaran wrote: Sorry if I'm hurting someone's sentiment, but is it just me who is seeing so much negative trend in the D forum about D itself? That's because people love D so much they want it to become better.
Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests
On Tuesday, 13 February 2018 at 04:44:27 UTC, timotheecour wrote: Try to comment that with `/* */`: ``` void drawCircle(int angle /* in degrees */); ``` When you want to disable whole declaration, version(none) works just fine.
Re: Being Positive
On Tuesday, 13 February 2018 at 07:47:39 UTC, JN wrote: "There are only two kinds of languages: the ones people complain about and the ones nobody uses." Wasn't that from Bjarne Stroustrup?
Re: Being Positive
On Tuesday, 13 February 2018 at 01:32:29 UTC, psychoticRabbit wrote: It is a human right..to complain ;-) Not to be that guy, but technically you have no rights in an online community. You have privileges.
Re: GSOC 2018 - no slots for D
On Tuesday, 13 February 2018 at 02:38:28 UTC, psychoticRabbit wrote: On Tuesday, 13 February 2018 at 02:12:10 UTC, Seb wrote: On Tuesday, 13 February 2018 at 01:59:16 UTC, psychoticRabbit wrote: Second, I don't get it. Are you saying D Foundation currently only provides such to students of UPB? https://dlang.org/blog/2016/12/05/the-d-language-foundations-scholarship-program/ You gotta start somewhere ;-) ok.. but I've never heard of UPB. Where is Romania anyway? Is that one of those little islands in the pacific? In any case, I think it would be great if the foundation setup a process whereby everyday people can contribute funds to projects. Those projects need to be approved and costed. Funds upto those 'per project costs' get accepted, then contributions are no longer accepted for that project - (otherwise contributions will exceed the cost of the project). The projects once approved, could be published for people to see, and then people decide if they want to contribute. Then the commuinity of contributors essentially get to decide which projects are worthwhile - i.e those that get funded by contributors. Essentially, crowd sourcing, and stop replying on big corporations to decide what is worthwhile and what is not. Romania is in Eastern Europe.
