Re: My two cents
On 10/20/2017 11:11 AM, Adam D. Ruppe wrote: On Friday, 20 October 2017 at 16:36:28 UTC, jmh530 wrote: It might help to have some sense of how the main devs time on D is being used. Definitely, I currently have no clue what they are on. Whiling away the hours, conferring with the flowers, consulting with the rain. My head I'm scratching while my thoughts are busy hatching.
Re: [OT] Generative C++
On Friday, 28 July 2017 at 07:49:02 UTC, Yuxuan Shui wrote: Someone made an interesting proposal to C++: https://herbsutter.files.wordpress.com/2017/07/p0707r1.pdf Thoughts? Sutter gave a longer presentation on his proposal at CppCon, which was posted online late last month and is the most-viewed talk from the conference after Bjarne's keynote: https://www.youtube.com/watch?v=4AfRAVcThyA I enjoyed watching Regehr's talk on undefined behavior, particularly since I hit that shift UB issue in D some time back: https://www.youtube.com/watch?v=v1COuU2vU_w https://www.youtube.com/watch?v=TPyLrJED0zQ http://forum.dlang.org/thread/xxqdnjscsdtbbwkma...@forum.dlang.org
D for microservices
I just read the following two week-old comment on the ldc issue tracker, when someone tried to run D on Alpine linux: "For now everything works(?) but I think the process could be improved.. Would be really cool to have LDC easily building alpine containers + static D binaries for microservice and tooling development. I'm pretty tired of reading Go code :)" https://github.com/ldc-developers/ldc/issues/2341#issuecomment-334626550 It strikes me that microservices are a great way for new programming languages like D to get tried and gain some uptake, but that D might not be that easy to deploy to that scenario yet. So this is a question for those deploying microservices, as I'm not in that field, what can the D devs do to make it as easy as possible to get D microservices up and running, make some Docker and Alpine containers with ldc/dub/vibe.d preinstalled publicly available? What else, what kinds of libraries do you normally use? This is a niche that D and all newer languages should target. How do we do it?
Re: So why double to float conversion is implicit ?
On Saturday, 21 October 2017 at 20:17:12 UTC, NX wrote: Interestingly enough, I realized that atan() returns double (in this case) but wait, it's assigned to a float variable! Compiler didn't even emit warnings, let alone errors. There a few lessons here. (1) D is not Java ;-) (2) Know what types are being returned from your calls, before you call them. (3) Know what the language spec says about conversions (and their order): - https://dlang.org/spec/type.html (4) If unsure, test it: - https://dlang.org/phobos/std_traits.html#isImplicitlyConvertible Only then should you start coding ;-) oh...and... (5) Don't waste time arguing with the spec ;-) (6) Don't expect the compiler to not comply with the spec
Re: My two cents
On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
Hi,
I had been using D for almost 6 years and I want to share my
opinion with you.
I don't want to blame anyone but I'll focus more on bad things
and possible improvements.
And this is just how I see D from my perspective.
(Sorry for my English, I'm too lazy to take the lessons).
First, D started as a great new language with the best from all
languages. But now D seems more and more conservative. New
syntactic sugars aren't added just because they can be found in
phobos. (this was Walter's answer when I asked for maybe monad
syntactic sugar).
OK, what I'm missing in D and what I think is wrong?
syntactic sugar for:
tuples
maybe monad (why we cannot have same syntax as in C#?)
conditional dereferencing and stuff about that (same as in C#)
foo?.bar;
foo?[bar];
return foo ?? null;
async/await (vibe.d is nice but useless in comparison to C# or
js async/await idiom)
I want to create function returning Promise/Task and await
where I want to.
e.g.
auto result = device.start(foo, bar); // This is RPC to remote
server returning Task!Bar
// do some important stuff
return await result; // wait for RPC finish, then return it's
result
I want to do this and not any ugly workaround about that.
@trusted, @safe, @system - why we have 3 keywords instead of
one? And why it's so complicated to use?
First, we should have one 'unsafe' keyword.
Second, everything should be safe by default.
3rd, if we want to declare @system func, use 'void foo()
unsafe;'
if we want to declare @trusted func, use
void foo() {
unsafe {
}
}
This fulfills the D's idiom in better way, because we should be
defining unsafe sections as small as possible.
C# properties instead of existing ones.
function and property should be two different things.
Calling function without () or assigning to it by = is a ugly
behavior and should be avoided.
implement this thing from C# (just because it's cool)
new Foo() {
property1 = 42,
property2 = "bar"
};
Reference counting when we cannot use GC...
Commercial usage, shared libraries and stuff
There isn't any handy tool to download, manage and publish
closed source stuff.
dub is great for simple solutions but useless in big projects
with multiple targets, configurations, etc.
Everything is primary focused on opensource development (but
everyone here wants to see D as a next successor of C++ in
commercial sphere).
Still cannot easily develop closed source dlls on Windows. On
Linux every symbol is public by default, but on Windows not so
it's needed to export them manually.
Unable to publish closed source library without workaround and
ugly PIMPL design.
Add dll/so usage without header files
(export enums, templates and stuff right into dll/so and let D
compiler to import these stuff from it)
For me, it seems like Walter is solving edge case problems like
return ref parameters and return functions but is unable to add
some basic stuff.
These guys are old now and don't have the drive they used to
have. It happens, part of life. Unfortunately they do not realize
this and do not want to pass the torch. I wouldn't expect
anything major for D any more unless something significant
changes in the management. D is stagnate, unfortunately and will
almost surely never be a major player. It's unfortunate but D has
a lot of problems. It is not commercially viable for the mass
market. D is a hobby language and will remain that way for the
majority of it's users. This is almost entirely due to the mind
set you have. It's a lot of work to bring D up to par with the
other languages and there seems very little interest in actually
making that happen.
Walter only see's what he wants. He looks at D and does not see
the flaws like mother looking at her ugly baby. If one always
looks at the pros and ignores the cons then anything looks good.
D has a lot of great things but also a lot of bad things... until
those bad things are fixed D won't go anywhere... it would be
nice, at least, if the management would be objective about the
bad things instead of sweeping them under the rug. Faking it
until you make it is not an option here.
Re: My two cents
On Saturday, 21 October 2017 at 21:45:11 UTC, Adam D. Ruppe wrote: On Saturday, 21 October 2017 at 20:02:28 UTC, user1234 wrote: I'm not sure that people talked much about the elvis operator (which was introduced in the topic by M.Nowak). In the first message were mentioned the null coalescence operator "??" What's the difference between `?:` and `??`? As far as I can tell, they'd do the same thing in most cases. Elvis operator returns LHS if LHS is true, otherwise RHS Null coalescing operator returns LHS if LHS is not null, otherwise RHS But since in D nullable values can be interpreted as booleans you're right "?:" would do the same as "??" and even more. Actually "?:" is preferable (which i didn't realize in first place :/).
Re: My two cents
On Saturday, 21 October 2017 at 20:02:28 UTC, user1234 wrote: I'm not sure that people talked much about the elvis operator (which was introduced in the topic by M.Nowak). In the first message were mentioned the null coalescence operator "??" What's the difference between `?:` and `??`? As far as I can tell, they'd do the same thing in most cases.
Re: My two cents
On 10/21/2017 1:40 PM, Adam Wilson wrote:
Walter has stated numerous times both here and at conferences that Async/Await
is definitely a goal. However, it's not as high a priority as the @safe/@nogc
work so it hasn't made it to any official vision statement. Also I just talked
to him offline about it, and he would need some serious help with it. He doesn't
know how to do the compiler rewrite, and there a number of tricky situations one
has to deal with. As much as I like Async/Await, I agree that the current plan
has higher priority.
I'll probably start poking around Async/Await when I can clear the decks a bit
of paid work. But that could be a while. :(
Async/Await can be implemented by rewriting ("lowering") the code to simpler D
code. Implementing it awaits (!) figuring out just what those rewrite rules are.
Re: My two cents
On 10/21/17 11:52, bitwise wrote: On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote: async/await (vibe.d is nice but useless in comparison to C# or js async/await idiom) Reference counting when we cannot use GC... If I understand correctly, both of these depend on implementation of 'scope' which is being worked on right now. I think reference counting needs 'scope' to be made safe. RC also benefits from scope in that many of the increments/decrements of the ref count can be elided. The performance gain can be significant, and even more so when you use atomic reference counting (like C++ shared_ptr) for thread safety. Async/Await needs to allocate state for the function's local variables. When it's detected that the function's state/enumerator won't escape it's current scope, it can be put on the stack, which is a pretty big optimization. I should also note that, RC has been formally acknowledged as a future goal of D, but as far as I know, async/await has not. Walter has stated numerous times both here and at conferences that Async/Await is definitely a goal. However, it's not as high a priority as the @safe/@nogc work so it hasn't made it to any official vision statement. Also I just talked to him offline about it, and he would need some serious help with it. He doesn't know how to do the compiler rewrite, and there a number of tricky situations one has to deal with. As much as I like Async/Await, I agree that the current plan has higher priority. I'll probably start poking around Async/Await when I can clear the decks a bit of paid work. But that could be a while. :( -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: So why double to float conversion is implicit ?
On Saturday, 21 October 2017 at 20:17:12 UTC, NX wrote: I was working on some sort of math library for use in graphical computing and I wrote something like this: const float PiOver2 = (atan(1.0) * 4) / 2; Interestingly enough, I realized that atan() returns double (in this case) but wait, it's assigned to a float variable! Compiler didn't even emit warnings, let alone errors. I see no reason as to why would this be legal in this century, especially in D. So can someone tell me what's the argument against this? Why type conversions differ between integral and floating types? Why can't I assign a long to an int but it's fine when assigning double to float? I think this is a serious topic and needs clarification. D is compliant with C++ in this case (see http://en.cppreference.com/w/cpp/language/implicit_conversion) so the question is rather why does C++ allow this conversion. When you convert a double to a float you're more likely to have a precision loss while when you convert an ulong to an int you risk a most serious data loss.
Re: My first experience as a D Newbie
On Saturday, 21 October 2017 at 09:51:41 UTC, Mark wrote: Honestly, I do not believe that an open-source project, beyond a certain scale, can sustain itself without a consistent income stream. It is possible, but you need a very modular architecture. The main problem for large open source projects is restructuring/refactoring, which can kill the project. One example of large open source volunteer based projects are MUDs, but they tend to be very modular in nature.
So why double to float conversion is implicit ?
I was working on some sort of math library for use in graphical computing and I wrote something like this: const float PiOver2 = (atan(1.0) * 4) / 2; Interestingly enough, I realized that atan() returns double (in this case) but wait, it's assigned to a float variable! Compiler didn't even emit warnings, let alone errors. I see no reason as to why would this be legal in this century, especially in D. So can someone tell me what's the argument against this? Why type conversions differ between integral and floating types? Why can't I assign a long to an int but it's fine when assigning double to float? I think this is a serious topic and needs clarification.
Re: My two cents
On Saturday, 21 October 2017 at 19:39:31 UTC, Andrei Alexandrescu wrote: [...] Using the topic of the Elvis operator as a running example, a good DIP would contain motivation such as: * Present evidence of the successful use of ?: in other languages I'm not sure that people talked much about the elvis operator (which was introduced in the topic by M.Nowak). In the first message were mentioned the null coalescence operator "??" and the safe navigation one "?." . The later was more discussed.
Re: My two cents
On 10/21/17 9:47 AM, Martin Nowak wrote: On Friday, 20 October 2017 at 18:11:50 UTC, Adam D. Ruppe wrote: On Friday, 20 October 2017 at 16:36:28 UTC, jmh530 wrote: It might help to have some sense of how the main devs time on D is being used. Definitely, I currently have no clue what they are on. Tried that, didn't resonate that much, and is also quite some work. So we mostly stick to internal discussions atm. https://forum.dlang.org/post/o2g7mg$12oa$1...@digitalmars.com Timelines and planning also don't work too well with volunteering. Martin's levelheaded answers are much appreciated. (For what it's worth I've been traveling a fair amount recently which brings money in Foundation's coffers and more attention to the D language. I am coping with the unpleasant reality I haven't written real code in months.) The matter discussed in this thread seems to have been suddenly rendered political, which is why I find it opportune to intervene - in all likelihood, improving nothing :o). Sticking to technical points, some of the original points are easy to explain as misunderstandings (e.g. safe/system/trusted - yes all three are needed), whereas others can be converted productively into real steps forward for the language. Using the topic of the Elvis operator as a running example, a good DIP would contain motivation such as: * Present evidence of the successful use of ?: in other languages * Present evidence of workarounds being used in D such as orElse, lazyElse etc. * Present evidence of the usefulness of the ?: operator in gcc, see https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Conditionals.html * Show how production code fragments in dmd, phobos, or other codebases would be significantly improved by the use of the operator Yes, there's no guarantee that such a DIP would be approved. But the "need a relationship with the cabal to get things in" angle is very damaging to our community. So is the framing of the language enhancements topic as a fight against arbitrary prejudice. These kind of allegation discourage people from putting good work in, which is all that's needed. Andrei
Re: My two cents
On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote: async/await (vibe.d is nice but useless in comparison to C# or js async/await idiom) Reference counting when we cannot use GC... If I understand correctly, both of these depend on implementation of 'scope' which is being worked on right now. I think reference counting needs 'scope' to be made safe. RC also benefits from scope in that many of the increments/decrements of the ref count can be elided. The performance gain can be significant, and even more so when you use atomic reference counting (like C++ shared_ptr) for thread safety. Async/Await needs to allocate state for the function's local variables. When it's detected that the function's state/enumerator won't escape it's current scope, it can be put on the stack, which is a pretty big optimization. I should also note that, RC has been formally acknowledged as a future goal of D, but as far as I know, async/await has not.
Re: My two cents
On Friday, 20 October 2017 at 22:25:20 UTC, Adam Wilson wrote: For example, ?? and ?. are ridiculously common idioms that we all perform every day in our D code. And as Mr. Ruppe rightly pointed out, it'd probably take about an hour each to knock together a complete PR for these features. Well, ignoring communication doesn't make it unnecessary. It just means that the communication has to happen after throwing a drive-by PR at us. Would be great if we could adequately capture arguments to facilitate those discussions. Seems like there wasn't even an ER for that https://issues.dlang.org/show_bug.cgi?id=17924.
Re: My two cents
On Friday, 20 October 2017 at 18:11:50 UTC, Adam D. Ruppe wrote: On Friday, 20 October 2017 at 16:36:28 UTC, jmh530 wrote: It might help to have some sense of how the main devs time on D is being used. Definitely, I currently have no clue what they are on. Tried that, didn't resonate that much, and is also quite some work. So we mostly stick to internal discussions atm. https://forum.dlang.org/post/o2g7mg$12oa$1...@digitalmars.com Timelines and planning also don't work too well with volunteering.
Re: My two cents
On Friday, 20 October 2017 at 20:05:51 UTC, jmh530 wrote:
Interesting proposals, but IMHO, the only ESSENTIAL feature
missing in D is the possibility to program in D using a
built-in reference-counting based variant of the standard
library.
Look at the goals for H2 2017
https://wiki.dlang.org/Vision/2017H2
The top three things: 1) @safety, 2) @nogc, 3) betterC. Under
#2, it specifically says safe reference counting. It's getting
worked on...
Yes, it's being worked on, but it's also a huge topic to come up
with @safe memory management approach. It's literally about
eradicating one of the biggest security bug classes,
use-after-free.
Currently I'm working towards an ORM library starting at I/O
(https://github.com/MartinNowak/io) to better inform the
necessary design.
We already found couple of interesting litmus tests, like the
window in iopipe.
auto window = iopipe.window;
iopipe.extend(512); // invalidates window :/
window[0]; // use after-free
Another thing that Walter previously found out is that exceptions
are a major hassle for @nogc. I don't like the RC Exception
solution much though, as it's a fairly specific workaround
(https://github.com/dlang/druntime/pull/1804).
Towards that goal, making exception nesting optional and
providing access to the current Exception in flight would allow
to use the staticError approach in most places.
https://github.com/dlang/druntime/blob/bc832b18430ce1c85bf2dded07bbcfe348ff0813/src/core/exception.d#L683
Recently I wondered why we cannot semantically transform
exceptions to the equivalent of function calls.
- throw Uniq!Exception; // ctor, some struct that's implicitly
convertible to a Throwable
- catch (scope Exception e) // handler 1
{
throw e; // basically continue to unwind
}
- catch (scope Exception e) {} // handler 2
- done unwinding, destroy thrown value
We still support gotos in catch handlers, but should be possible
to call destructors in catch handlers anyhow.
https://github.com/dlang/druntime/pull/1804/files#diff-f3953348bb302c27a8cea926c62c02e6R69
Re: My two cents
On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote: Hi, I had been using D for almost 6 years and I want to share my opinion with you. I don't want to blame anyone but I'll focus more on bad things and possible improvements. And this is just how I see D from my perspective. (Sorry for my English, I'm too lazy to take the lessons). [...] Thanks for your time. - Satoshi I'm surprised that you didn't mention pattern matching. I really like it in Rust.
Re: My first experience as a D Newbie
On Saturday, 21 October 2017 at 01:45:40 UTC, codephantom wrote: The real challenge (and ultimate goal) for any open-source project (especially a volunteer based one), is finding equilibria. Honestly, I do not believe that an open-source project, beyond a certain scale, can sustain itself without a consistent income stream.
Re: Deimos X11 bindings license question
How we can use it in https://mobile-phone-tracker.org mobile recorder on Android?
Re: D for Android
How we can use it in [url=https://mobile-phone-tracker.org]mobile tracker[/url] on Android?
