Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?
On Thursday, 23 November 2017 at 01:16:59 UTC, codephantom wrote: That's why we have the concept of 'undefined behaviour'. Errr, no. High level programming languages don't have undefined behaviour. That is a C concept related to the performance of the executable. C tries to get as close to machine language as possible.
Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?
On Thursday, 23 November 2017 at 01:33:39 UTC, codephantom wrote: On Thursday, 23 November 2017 at 00:15:56 UTC, Ola Fosheim Grostad wrote: By what proof? And what do you mean by mathematics? A mathematical claim, that cannot be proven or disproven, is neither true or false. What you are left with, is just a possibility. And how is this a problem? If your program relies upon the unbounded version you will have to introduce it explicitky as an axiom. But you dont have to, you can use bounded quantifiers. What you seem to be saying is that one should accept all unproven statements as axioms implicitly. Why have a type system at all then? Thus, it will always remain an open question as to whether the conjecture is true, or not. Heh, has the Goldbach conjecture been proven undecidable?
Re: Looking for a job in USA
On Wednesday, 22 November 2017 at 10:24:52 UTC, Indigo wrote: On Saturday, 18 November 2017 at 08:59:53 UTC, Satoshi wrote: [...] Um, it's the same! You won't escape it if you come to stay. Just because the shit hasn't hit the fan yet does not mean it's not coming down the pipe. There are many here that seem to believe that ignorance is bliss, that is true, for a while. [...] I have some concerns about the these United States of America too, but the Republic is not dying anytime soon. Your hysteria is caused and amplified by sensational media outlets that have the mission to get people to watch and read; scaremongering is a very effective tactic to garner viewership and thus money. Most people live their lives happily and will continue to do so. Immigrants with skills that are in high-demand (like OP) would have a good life here if they can get their foot in the door.
Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?
On Thursday, 23 November 2017 at 06:32:30 UTC, codephantom wrote: Here is another demonstation of why you can trust your compiler: Why you "can't" ... is what i meant to say. I love not being able to edit posts. It's so convenient.
Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?
On Wednesday, 22 November 2017 at 00:39:21 UTC, codephantom wrote:
On Wednesday, 22 November 2017 at 00:19:51 UTC, codephantom
wrote:
Its seems to be, that you prefer to rely on the type system,
during compilation, for safety. This is very unwise.
To demonstrate my point, using code from a 'safe' language (C#):
(i.e. should this compile?)
// --
using System;
public class Program
{
public static int Main()
{
Foo();
return 0;
}
static void Foo()
{
const object x = null;
//if (x != null)
//{
Console.WriteLine(x.GetHashCode());
//}
}
}
// --
Here is another demonstation of why you can trust your compiler:
using code from a 'safe' language (C#):
(i.e. should this compile?)
// -
using System;
using System.IO;
public class Program
{
public static int Main()
{
Console.WriteLine( divInt(Int32.MinValue,-1) );
return 0;
}
static int divInt (int a, int b)
{
int ret = 0;
//if ( (b != 0) && (!((a == Int32.MinValue) && (b ==
-1))) )
//{
ret = a / b;
//}
//else
//{
// throw new InvalidOperationException("Sorry.. no can
do!");
//}
return ret;
}
}
// ---
Re: Looking for a job in USA
On Thursday, 23 November 2017 at 04:13:33 UTC, Indigo wrote: Wow, no need to get offended Actually, I was not at all offended. And we always find it kind of humorous, how people around the world view Australia. We don't get offended by it. In any case, I think you underestimate the U.S. Yes, many objectionable people are doing many objectional things. But there are many good people doing many good things too. I'm confident that in the U.S, as in other freedom loving countries, the good people will get the upper hand again soon. It's an unfortunate ongoing cycle - part of the evolution of humanity I guess. Go seek out, and connect with good people. They are out there you know. The U.S is the worlds last defense against tyranny and chaos..which is right on our doorstep. Don't give up on the U.S. Instead go out and make it better.
Re: Looking for a job in USA
On Wednesday, 22 November 2017 at 13:48:34 UTC, codephantom wrote: On Wednesday, 22 November 2017 at 10:24:52 UTC, Indigo wrote: I have been told by several that Australia is a good place to go and I myself have thought about it. It seems that Australia is probably a rather insulated society in that the rest of the world could kill itself off and they'd be ok(probably a lot to do with it it being so physically isolated and somewhat small. Goods and people can't move as easily between it and the rest so mentally the people are more independent minded and closer knitted society). I've heard though that it is expensive to live there and one it is difficult to stay. Australia is not small. Who told you that? https://www.google.com.au/maps/place/Australia If you want to talk about small, consider the tiny land mass of Indonesia just to our north - it has the 4th largest populated country in the world (260+ million). That's more than 10 times Australia's population, in such a small land mass. Needless to say, that's something our defense forces are keanly aware of, and constantly monitoring. Wow, no need to get offended. I wasn't talking about land mass but population size. It has about 25M people in a large landmass... That means that persons/sqmi is pretty low. This means you don't have a lot of people cooped up close to each other that do not get along. So we pretty much agree. But you are talking about land mass when I'm talking about people... and without the people in the equation it is all relevant. People are the problem, not land. We are also close to the worlds busiest shipping lanes, and goods travel very easily between us and the rest of the world. We are the 23rd largest export economy in the world. In 2016, we exported $159B and imported $181B. So we have a negative trade balance actually, which makes us very vulnerable to what's going on in the rest of the world. As long as China is ok, we're ok. As long as U.S is ok, China is ok..and around around it goes...we all rise together, and we all go down together. For the most part, yes, but if the shit hits the fan in the world, you are much more insulated than most other 1st world countries. That was my point. No need to try to defend your position, I am not arguing against it and no need to try to bolster Australia's image. Australia is sort of like Texas, about the same about the same population but 10 times larger. It is also far more insulated than texas. One must travel by boat or plane to get to australia but texas can be "invaded" by land in all directions reaching almost across the planet(from the Chile to Alaska). Since it is far cheaper and easier to go by land than sea or plane, it means that the mobility of people flowing in to and out of texas is much greater than Australia(it's basic vector calculus and physics). As far as goods and such, the same logic applies. It is much cheaper to ship things by land than air or sea. You can't put goods on a train and ship them to Australia... Trains are 10x cheaper to use in America because we already have the railways and it's just more efficient than truck or air. Since most goods consumed in the US are produced in the US we don't have too look externally for most common goods. For example, most 3rd world countries have to import the goods we take for granted(e.g., cheap electrical parts, books, computers, luxury items, etc). If you want a real estimation of just how isolated Australia is, regardless of what you claim, here is a heat map of the trading that really goes on in the world(more or less): http://siteresources.worldbank.org/INTWDRS/Resources/477365-1327525347307/8392086-1327528510568/WDR09_12_Ch06web.pdf or if you don't wanna believe that: https://en.wikipedia.org/wiki/Freight_transport Again, I'm not saying Australia is a hole in the wall.. but it is relatively isolated from many factors. If, say, a deadly plague started sweeping across the US and can spread very quickly, Australia is in a good position to be one of the least effected places, assuming they can shut down the airports quick enough. It would be nearly impossible for the US to control. The same applies to anything like an economic collapse. All this is precisely because of it's isolation by water. If all continents were connection then we wouldn't be having this conversation. You might not think it is much of a thing but in certain circumstances it could mean the difference between life and death. In other cases it still is a factor but depends on the context to know exactly how much. Since I don't follow Australian news, politics, or culture you know more about those specifics than I do. I do live in the US so I know more about it than you. The US is not doing good... that is an undeniable fact. One can pick and choose their metric to weasel away from the truth but as a whole the US has some very deep and serious problems
Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?
On Thursday, 23 November 2017 at 00:15:56 UTC, Ola Fosheim Grostad wrote: By what proof? And what do you mean by mathematics? A mathematical claim, that cannot be proven or disproven, is neither true or false. What you are left with, is just a possibility. Thus, it will always remain an open question as to whether the conjecture is true, or not.
Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?
On Thursday, 23 November 2017 at 00:15:56 UTC, Ola Fosheim Grostad wrote: On Thursday, 23 November 2017 at 00:06:49 UTC, codephantom wrote: true up to a number < n ... does not address the conjecture correctly. So what? We only need to a proof up to N for regular programming, if at all. That's really the point I was making. It's the reason you'll never be able to put your complete trust in a compiler. The compiler can only ever know something, about something, up to a point. That's why we have the concept of 'undefined behaviour'.
Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?
On Wednesday, 22 November 2017 at 18:16:16 UTC, Wyatt wrote: "Need"? Perhaps not. But so far, I haven't seen any arguments that refute the utility of mitigating patterns of human error. Ok. that's a good point. But there is more than one way to address human error without having to further regulate human behaviour. How about we change the way we think...for example. I 'expect' bad people to try to do 'bad stuff' using my code. It's the first thing I think about when I start typing. This perspectives alone, really changes the way I write code. It's not perfect, but it's alot better than if I didn't have that perspective. And all it required was to think differently. No language change, no further regulation. So yeah, you can change the language.. or you can change the way people think about their code. When they think differently, their code will change accordingly. My point about sophisticated IDE's and AI like compilers, is that they don't seem to have addressed the real issue - that is, changing the way people think about their code. If anything, they've introduced so many distractions and so much automation, that people are just not thinking about their code anymore. So now, language designers are being forced to step in and start regulating programmer behaviour. I don't like that approach. You rarely hear anything about defensive programming these days, but it's more important now, than it ever was. I'd make it the number one priority for new developers. But you won't even find the concept being taught at our universities. They're too busy teaching students to program in Python ..hahha...the future is looking pretty bleak ;-( Where are the 'Secure Coding Guidelines for Programming in D' (I'm not saying they don't exist. I'm just not aware of them). What if I did a security audit on DMD or PHOBOS. What would I discover? What if I did a security audit on all the D code at github. What would I discover? Sophisticated IDE's and AI like compilers have not rescued us from this inherent flaw in programming. The flaw, is a human flaw. A flaw in the way we think.
Re: TickDuration deprecation
On 2017-11-23 12:55, sarn wrote: +1 to using integer arithmetic for the low-level time APIs. and nobody is advocating to change this. it is about being able to use such result (duration) with non-time focused libraries/functions (eg. general maths/stats) expecting doubles. if this is not possible in an obvious/standard way (being to!... in D) this is the very moment all potential python-to-D converts will run away screaming. putting the solution for this common problem only in the docs will not appease them either but rather make them mock D. i still don't understand how problems could arise from a supported one-way conversion -> double. of course, double -> time or duration is something different and i tend to agree that this should be left for the user to implement. i for my part could live with just one supported to!double conversion resulting in seconds. (i guess i am biased as i prefer to use SI units only for all my calculations.) /det
Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?
On Thursday, 23 November 2017 at 00:06:49 UTC, codephantom wrote: true up to a number < n ... does not address the conjecture correctly. So what? We only need to a proof up to N for regular programming, if at all. hint. It's not a problem that mathmatics can solve. By what proof? And what do you mean by mathematics?
Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?
On Wednesday, 22 November 2017 at 22:02:11 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 22 November 2017 at 04:55:39 UTC, codephantom wrote: Consider the Goldbach Conjecture, that every even positive integer greater than 2 is the sum of two (not necessarily distinct) primes. According to the principle of bivalence, this should be either true or false. «The Goldbach conjecture verification project reports that it has computed all primes below 4×10^18» Which is more than you'll ever need in any regular programming context. Next problem? Come on. Really? "It's true as far as we know" != "true" true up to a number < n ... does not address the conjecture correctly. Where it the 'proof' that the conjecture is 'true'. hint. It's not a problem that mathmatics can solve.
Re: TickDuration deprecation
On Wednesday, 22 November 2017 at 22:17:05 UTC, Walter Bright wrote: On 11/22/2017 5:45 AM, Steven Schveighoffer wrote: 1. All OS calls with timing requirements use non-floating point to represent how long to sleep. After all a CPU uses discrete math, and the timing implementation is no different. Microsoft has numerous COM APIs for time functions. One of them I had to deal with used doubles to represent seconds. This had to be interfaced with other time functions that used integers. The trouble came from round trips - there were cases where double=>integer=>double did not produce the same result. Even worse, double=>integer=>double=>integer=>double ... produced a creeping shift in the value! It took much time to come up with a method of preventing such drift, and even that was unreliable. It's fixed point, not floating point, but this famous software disaster is a pretty dramatic example: http://www-users.math.umn.edu/~arnold/disasters/patriot.html +1 to using integer arithmetic for the low-level time APIs.
Re: TickDuration deprecation
On 11/22/2017 5:45 AM, Steven Schveighoffer wrote: 1. All OS calls with timing requirements use non-floating point to represent how long to sleep. After all a CPU uses discrete math, and the timing implementation is no different. Microsoft has numerous COM APIs for time functions. One of them I had to deal with used doubles to represent seconds. This had to be interfaced with other time functions that used integers. The trouble came from round trips - there were cases where double=>integer=>double did not produce the same result. Even worse, double=>integer=>double=>integer=>double ... produced a creeping shift in the value! It took much time to come up with a method of preventing such drift, and even that was unreliable. 5. Responding to Walter's one-liner resistance, if the one liner is trivial to get right, then sure, don't include it. It could even be written in-line. But if it's easy to get WRONG, or is annoying to have to write, then I think it's worth having, even if it's a one-liner. In my opinion, type conversion is one of those things that falls into that second category. How can I construct the most accurate Duration with a given double that is in the form of seconds? You'd have to know the representation of Duration as hectonanoseconds in order to get this right. While trivial to write once you *know* that, it's not trivial to write if you *don't*. Having a library function (even a one-liner) that says "I'll save you from the implementation details" is useful. Another solution is to put the one-liner not in Phobos, but in the documentation as an example of how to use it. The user will have to look up the function in the documentation anyway. Bottom line: one-liner-ness shouldn't be an automatic disqualifier. As always, use good judgement. You and I differ on where that line is, however. I prefer a small interface with a minimal number of orthogonal functions, from which I can assemble what I need. An interface with a blizzard of functions all doing overlapping things with unknown tradeoffs is cognitive overload. The documentation of such an interface should, of course, provide examples of how to assemble those minimal functions into commonly needed solutions. --- As an aside, Andrei has worked very hard trying to figure out how to break down the memory allocator into the smallest collection of orthogonal parts that can then be assembled *by the user* into whatever he needs. It is not obvious, and amazingly nobody has done it before. https://dlang.org/phobos/std_experimental_allocator.html He did the same thing with the checked int package, which blows away every other checked integer solution I've seen. I believe it's the future of How To Do Interfaces Right :-) https://dlang.org/phobos/std_experimental_checkedint.html The documentation for both is a bit intimidating, though. There should be a more tutorial oriented overview.
Re: D client for ROS
On Wednesday, 22 November 2017 at 19:02:17 UTC, thinwybk wrote: On Saturday, 29 July 2017 at 10:21:32 UTC, Johan Engelen wrote: Hi all, Are there any robot folks out here that are working with ROS and would be able to work on creating a D client library for it? ROS is used a lot at our university and in robot research in general, and most people use the C++ client (the main one, next to Python). In arguing for teaching D at our university, it would help a lot if students could use D with ROS. Cheers, Johan (fyi: I'm an assistent prof Robotics and Mechatronics and LDC developer) Hi Johan, a bit late... yes, I am working in robotics and I would be interrested in helping out. I know that other people visit ROS and D meetups in munich and could be interrested as well. Cheers, Florian Have you considered to post on discourse.ros.org (client libraries) https://discourse.ros.org/c/client-libraries as well? You would propably get more response there.
Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?
On Wednesday, 22 November 2017 at 04:55:39 UTC, codephantom wrote: Consider the Goldbach Conjecture, that every even positive integer greater than 2 is the sum of two (not necessarily distinct) primes. According to the principle of bivalence, this should be either true or false. «The Goldbach conjecture verification project reports that it has computed all primes below 4×10^18» Which is more than you'll ever need in any regular programming context. Next problem?
Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?
On Wednesday, 22 November 2017 at 17:17:07 UTC, Mark wrote: On Tuesday, 21 November 2017 at 09:12:25 UTC, Ola Fosheim Grostad wrote: Runtime checks are part of the type system though I wouldn't say that, particularly if we are talking about a statically typed language (which Java is). Very few imperative programming languages are fully statically typed.
Re: TickDuration deprecation
On 11/22/2017 2:45 AM, Walter Bright wrote: On 11/22/2017 1:41 AM, Timon Gehr wrote: Why would the conversion function be linked in if I never use it? Good question. It depends on how the code is written, and how the compiler represents it in the object file, and how the linker deals with unreferenced parts of object files. For another example, unreferenced virtual functions never get elided because a reference to them does exist - they're in the virtual function pointer table. And then, of course, everything that virtual function references is never elided. Another reason to be careful of "kitchen sink" abstractions.
Re: Precise GC state
On 11/22/17 05:44, Nicholas Wilson wrote: On Wednesday, 22 November 2017 at 13:23:54 UTC, Nordlöw wrote: On Wednesday, 22 November 2017 at 10:53:45 UTC, Temtaime wrote: Hi all ! https://github.com/dlang/druntime/pull/1603 Only the Win32 build fails as Error: more than 32767 symbols in object file What's wrong? Thats a linker(?) limitation for OMF (or whatever is the win32 object file format). We really should be using the MSVC linker on Windows for both x86 and x64. I propose we change the default behavior of -m32 to point to MSVC, keep the -m32mscoff, but mark it as deprecated, and add a -m32omf flag to retain the current behavior. -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: D client for ROS
On Saturday, 29 July 2017 at 10:21:32 UTC, Johan Engelen wrote: Hi all, Are there any robot folks out here that are working with ROS and would be able to work on creating a D client library for it? ROS is used a lot at our university and in robot research in general, and most people use the C++ client (the main one, next to Python). In arguing for teaching D at our university, it would help a lot if students could use D with ROS. Cheers, Johan (fyi: I'm an assistent prof Robotics and Mechatronics and LDC developer) Hi Johan, a bit late... yes, I am working in robotics and I would be interrested in helping out. I know that other people visit ROS and D meetups in munich and could be interrested as well. Cheers, Florian
Re: TickDuration deprecation
On Wednesday, November 22, 2017 12:45:01 Daniel Kozak via Digitalmars-d
wrote:
> Ok I understand why there is no conversion from Duration to float, but
> would be possible to make Duration.total not a member function? So insted
> of:
>
> static mytotal(string unit)(Duration dur)
> {
> return dur.total!unit;
> }
>
> alias msecs = mytotal!"msecs";
>
> I could just add
> alias msecs = total!"msecs";
How would that help anything? You can clearly create an msecs alias right
now, and you could get the same effect using a free function named msecs
instead of an alias. Also, core.time.msecs is already an alias for
core.time.dur!"msecs", so creating your own symbol called msecs (be it an
alias or a free function) could muck with your use of the one from core.time
(though it's certainly possible to disambiguate between the two or to use
dur!"msecs" directly).
And regardless of this specific situation, in general, turning a member
function into a free function risks breaking code, since instead of it being
a member function that automatically wins out with UFCS, it could suddenly
be in conflict with another function of the same name, meaning that the
calling code would have to then disambiguate between them whereas it didn't
before. So, in general, turning member functions into free functions isn't a
great idea if you're not in control over all of the code involved or
otherwise aren't concerned about the potential fallout.
- Jonathan M Davis
Re: Looking for a job in USA
On Monday, 20 November 2017 at 12:48:10 UTC, Satoshi wrote: On Monday, 20 November 2017 at 10:38:59 UTC, user1234 wrote: On Saturday, 18 November 2017 at 08:59:53 UTC, Satoshi wrote: On Saturday, 18 November 2017 at 01:31:09 UTC, Indigo wrote: On Wednesday, 15 November 2017 at 17:32:50 UTC, Satoshi wrote: Hi, as the title says, I'm looking for a job opportunity in the Salary... In US you get $100,000/year as a senior developer or something like that, right? There it's only like $30,000/year. But the price of stuff like cars, grocery and everything what you can buy on amazon, e-bay, etc. is the same. Wait wait wait...the social model is not the same, this explains the difference. Typically in UE you have welfare states, with what this implies ;) In these welfare states you are required to pay health insurance, pension insurance, social insurance which is 30% of your salary. Then, there is a difference between your salary what you negotiated and the money what your employer spend on your salary. He must pay additional 20% to 30% of your salary. Example: I get about 1400e/monthly, my employer pays about 2600e/monthly on my salary. If you are sick, it's better to take home office than be paid from state. This system, especially in Slovakia is designed for poor people not to fall down. And still, it's better to have bigger salary, even if you are paying higher % as a taxes and stuff. There you have small cars, small flats, smaller size of food for the same % of your salary as in the US. e.g. Dodge RAM cost the same price as big house in village 20 minutes from Brno or flat in the Brno. I'm not focusing on material thing or something like that, but my dream is to travel through the world, sailing and work remotely (which is possible as a programmer) for a few years before I hit the age. I don't wanna be the one, who stayed at the same place for his entire life. Y'know, I'd like adventures. I think I'm writing the same code as everyone else in the US, so why shouldn't I have the same salary? You know i understand your POV but as we dont really know each other here i will tell you something: better dying than giving one percent of my workforce to the assholes you wanna work with.
Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?
On Wednesday, 22 November 2017 at 14:51:02 UTC, codephantom wrote: The core language of D does NOT need what C# is proposing - that is my view. "Need"? Perhaps not. But so far, I haven't seen any arguments that refute the utility of mitigating patterns of human error. If, over time, a large number of D programmers have the same laissez-faire approach towards checking for null, as C# programmers, then maybe they'll start demanding the same thing - but even then, I'll argue the same points I've argued thus far. Null references have been a problem in every language that has them. Just because D is much nicer than its predecessors (and contemporaries, IMO) doesn't mean the "bad old days" (still in progress) of C and C++ didn't happen or that we cannot or should not learn from the experience. Tony Hoare doesn't call null his sin and "billion dollar mistake" as just a fit of pique. In other words, "Well don't do that, silly human!" ends up being an appeal to tradition. Perhaps that's why I've never considered nulls to be an issue. I take proactive steps to protect my code, before the compiler ever sees it. And actually, I cannot recall any null related error in any code I've deployed. It's just never been an issue. Oh, that explains it. He's a _robot_! ;) (The IDE thing is entirely irrelevant to this discussion; why did you bring that up?) And that's another reason why this topic interests me - why is it such an issue in the C# community? From Mads blog about it, it seems to be because they're just not doing null checks. And so the language designers are being forced to step in. If that's not the reason, then I've misunderstood, and await the correct explanation. Again, it's never _not_ been a problem. That C# is nearly old enough to vote in general elections but they're only just now finally doing this should be telling. (And I fully expect this conversation has been going for at least half of that time.) It's probably galvanised by the recent proliferation of languages that hold safety to a higher standard and the community realising that the language can and _should_ share the burden of mitigating patterns of human error. -Wyatt
Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?
On Tuesday, 21 November 2017 at 09:12:25 UTC, Ola Fosheim Grostad wrote: Runtime checks are part of the type system though I wouldn't say that, particularly if we are talking about a statically typed language (which Java is).
Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?
On Wednesday, 22 November 2017 at 13:21:05 UTC, Timon Gehr wrote: BTW of course you must realize that you can make the compiler brutally obsolete by just quickly writing down the most efficient possible correct machine code in a hex editor, so I'm not too sure why you participate in a discussion on the forums of a compiled language at all. I've participated in order to counter the proposition put forward in the subject of this thread. The core language of D does NOT need what C# is proposing - that is my view. If, over time, a large number of D programmers have the same laissez-faire approach towards checking for null, as C# programmers, then maybe they'll start demanding the same thing - but even then, I'll argue the same points I've argued thus far. I also think that relying too much on sophisticated IDE's and AI like compilers, really changes the way you think about and write code. I don't rely on either. Perhaps that's why I've never considered nulls to be an issue. I take proactive steps to protect my code, before the compiler ever sees it. And actually, I cannot recall any null related error in any code I've deployed. It's just never been an issue. And that's another reason why this topic interests me - why is it such an issue in the C# community? From Mads blog about it, it seems to be because they're just not doing null checks. And so the language designers are being forced to step in. If that's not the reason, then I've misunderstood, and await the correct explanation.
Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?
On Wednesday, 22 November 2017 at 13:21:05 UTC, Timon Gehr wrote: You do realise, that all of the issues you mention can just be handled by coding correctly in the first place. ... Yes, just like everyone else, I realize that if correct code is written, we end up with correct code, but thanks for pointing it out. You're welcome.
Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?
On Wednesday, 22 November 2017 at 13:21:05 UTC, Timon Gehr wrote: On 22.11.2017 01:19, codephantom wrote: No, I ideally want the type system to point out when the code is not obviously correct. That does not mean I assume that the code is correct when it compiles (given that I'm using a language that does not require me to prove absence of all bugs, and even if it did I'd at most assume that either the language implementation is incorrect or my code is correct, with a certain margin of error due to undetected hardware failures). This is very unwise. ... Thanks for pointing that out. You're welcome.
Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?
On Wednesday, 22 November 2017 at 13:47:19 UTC, Timon Gehr wrote: On 22.11.2017 05:55, codephantom wrote: No, the question should be, what can the compiler prove to be true/false, correct/incorrect about your code, and what effort have you made in your code to assist the compiler to make that determination. If you've made no effort to provide the compiler with the context it needs to make a useful determination, then don't complain when the compiler gets it wrong. That is my first point. My second point, is that it is already possible to provide such context to the compiler, without having to make reference types non nullable, and therefore having to introduce a new nullable reference type. ... It's really not. Your arguments need a little more work.
Re: Looking for a job in USA
On Wednesday, 22 November 2017 at 10:24:52 UTC, Indigo wrote: I have been told by several that Australia is a good place to go and I myself have thought about it. It seems that Australia is probably a rather insulated society in that the rest of the world could kill itself off and they'd be ok(probably a lot to do with it it being so physically isolated and somewhat small. Goods and people can't move as easily between it and the rest so mentally the people are more independent minded and closer knitted society). I've heard though that it is expensive to live there and one it is difficult to stay. Australia is not small. Who told you that? https://www.google.com.au/maps/place/Australia If you want to talk about small, consider the tiny land mass of Indonesia just to our north - it has the 4th largest populated country in the world (260+ million). That's more than 10 times Australia's population, in such a small land mass. Needless to say, that's something our defense forces are keanly aware of, and constantly monitoring. We are also close to the worlds busiest shipping lanes, and goods travel very easily between us and the rest of the world. We are the 23rd largest export economy in the world. In 2016, we exported $159B and imported $181B. So we have a negative trade balance actually, which makes us very vulnerable to what's going on in the rest of the world. As long as China is ok, we're ok. As long as U.S is ok, China is ok..and around around it goes...we all rise together, and we all go down together. https://atlas.media.mit.edu/en/profile/country/aus/ I wouldn't say we are a close knitted society. We are a country built on immigration, and it's very diverse here. But we do share (we'll most of us anyway) certain values that help bind us together - which is not easy when your population is so diverse, or when you have increasing numbers of people coming in, with the completely opposite values. This is our biggest threat I think (i.e. internal stability, not external threats). External threats are easily deterred when you have friends like the U.S. But we are very independent minded, that much you got correct ;-)
Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?
On 22.11.2017 05:55, codephantom wrote: ... >> The question isn't whether we should use the type system to prevent bugs. The question is which set of problems really make sense to prevent with the type system. No, the question should be, what can the compiler prove to be true/false, correct/incorrect about your code, and what effort have you made in your code to assist the compiler to make that determination. If you've made no effort to provide the compiler with the context it needs to make a useful determination, then don't complain when the compiler gets it wrong. That is my first point. My second point, is that it is already possible to provide such context to the compiler, without having to make reference types non nullable, and therefore having to introduce a new nullable reference type. ... It's really not. Which make more sense? Knowing that a reference type could potentially be null, and therefore check for null, You are saying this as if there was always a reasonable thing to do if the reference is in fact null. This is just not the case. I.e. this option sometimes makes no sense. Also, if checking for null is always required, why wouldn't the compiler complain if it is missing? or dealing with all the flow on conquences of making a reference type non nullable by default? Even with such a change, the Goldbach Conjecture still cannot be resolved. If the correctness of a program depends on the Goldbach Conjecture, that's still something one might want to know about. We could then just add the correctness of the Goldbach conjecture as an assumption, and then verify that under the given assumption, the program is actually correct. Once the Goldbach conjecture gets resolved, we can get rid of the assumption.
Re: TickDuration deprecation
On 11/18/17 9:03 AM, Timon Gehr wrote:
(Jonathan M Davis from comment #4)
> TickDuration will soon be deprecated, and none of the other time stuff
> supports floating point. Anyone who wants that functionality can
calculate
> the floating point values from the integral values that the types do
> provide. It's not something that most code should be doing, but the API
> makes it possible for those who care.
"Not something that most code should be doing"? I have never used
StopWatch and then /not/ wanted to do something like to!("seconds",double)!
There seems to be no good reason to break my code beyond requiring a
different import here. What are the perceived shortcomings of the
to!("seconds", double) interface?
My take on this, as someone who has argued extensively NOT to use double
for timing calculations (I was responsible for adding the TimeSpan type
in Tango (the equivalent of Duration) and marginalizing Interval (based
on double) [1]):
1. All OS calls with timing requirements use non-floating point to
represent how long to sleep. After all a CPU uses discrete math, and the
timing implementation is no different.
2. Sometimes it is VERY important to use exact representation for
everything.
Example: I want to sleep for 1 microsecond, if you had a function
that accepts a floating point value, and you pass in 0.000_001, you
might actually sleep for 0 ticks, which is vastly different.
3. Sometimes it is not as important.
Example: if you want to sleep for 1.75 seconds, having a function
that converts the float representation of 1.75 into a Duration is
useful, and reasonably accurate. It isn't going to ruin your application
if the sleep passed to the OS is 1.74999 seconds. Your sleep
probably isn't going to be exactly accurate anyways, as most of use use
non-real-time OSes.
4. There are many libraries, the most obvious one to me is Apple's core
library, which use a double for representing time everywhere. So it's
not without precedent.
5. Responding to Walter's one-liner resistance, if the one liner is
trivial to get right, then sure, don't include it. It could even be
written in-line. But if it's easy to get WRONG, or is annoying to have
to write, then I think it's worth having, even if it's a one-liner.
In my opinion, type conversion is one of those things that falls
into that second category. How can I construct the most accurate
Duration with a given double that is in the form of seconds? You'd have
to know the representation of Duration as hectonanoseconds in order to
get this right. While trivial to write once you *know* that, it's not
trivial to write if you *don't*. Having a library function (even a
one-liner) that says "I'll save you from the implementation details" is
useful.
related: https://github.com/dlang/druntime/pull/1927
Bottom line: one-liner-ness shouldn't be an automatic disqualifier.
---
After having used Apple's SDK quite a bit, I've changed my opinion
slightly since my Tango days. It is useful to have a floating point
representation of time, and can be used to good effect. I would be fine
with a mechanism to convert to/from double with a Duration in druntime
(in fact, Tango kept this), but still want to have the representation be
as accurate as possible when it comes to calling OS functions. All the
public APIs of druntime/phobos should take/return only Durations, not
doubles, and let the user convert if they want to use doubles elsewhere.
-Steve
[1] http://dsource.org/projects/tango/ticket/671
Re: Precise GC state
On Wednesday, 22 November 2017 at 13:23:54 UTC, Nordlöw wrote: On Wednesday, 22 November 2017 at 10:53:45 UTC, Temtaime wrote: Hi all ! https://github.com/dlang/druntime/pull/1603 Only the Win32 build fails as Error: more than 32767 symbols in object file What's wrong? Thats a linker(?) limitation for OMF (or whatever is the win32 object file format).
Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?
On 22.11.2017 02:09, codephantom wrote: On Wednesday, 22 November 2017 at 00:49:02 UTC, Jonathan M Davis wrote: While I definitely don't think that it's generally very hard to avoid bugs with null pointers/references, telling someone to code correctly in the first place isn't very useful. Fair enough...perhaps I'm being too explicit with my argument. However, my point is, that one should not overly rely on some magical compiler for telling you what is 'true'. ... That is not the role of the compiler here. The task of the compiler in this circumstance is to tell you what is obvious, not what is true. How can a compiler know that G is true if it cannot prove that G is true? ... Because you proved it to the compiler. You need to take this into account during your coding. Otherwise the runtime system is your last line of defence. You seem to assume that Rice's theorem applies to compilers, but not programmers. Why is that?
Re: Precise GC state
On Wednesday, 22 November 2017 at 10:53:45 UTC, Temtaime wrote: Hi all ! https://github.com/dlang/druntime/pull/1603 Only the Win32 build fails as Error: more than 32767 symbols in object file What's wrong?
Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?
On 22.11.2017 01:19, codephantom wrote: On Tuesday, 21 November 2017 at 20:02:06 UTC, Timon Gehr wrote: I'm confident that you would be able to use null safe languages properly if that is what had been available for most of your career. You do realise, that all of the issues you mention can just be handled by coding correctly in the first place. ... Yes, just like everyone else, I realize that if correct code is written, we end up with correct code, but thanks for pointing it out. BTW of course you must realize that you can make the compiler brutally obsolete by just quickly writing down the most efficient possible correct machine code in a hex editor, so I'm not too sure why you participate in a discussion on the forums of a compiled language at all. If your program calls 'std.math.log' with an argument of '-123.4', then that's probably NOT a bug. It's more likely to be incorrect code. https://en.wikipedia.org/wiki/Software_bug Why not bounds-check the argument before passing it to the function? ... Walter said NaN is underused, not me. If you access a field of an invalid instance of an object, that's probably NOT a bug. It's more likely to be incorrect code. https://en.wikipedia.org/wiki/Software_bug Before you access a field of an object, check that the object is valid. ... If I know that it is valid, I might not want to check it. Then, if, let's say, you come along and read my code, I do not need you to point out that I didn't check the field access. If you still do, I can now either explain to you why it is unnecessary, which will waste my time and does not guarantee that you will buy it, or I can write the code in a language that requires me to provide the proof up front, such that you will not have to bother me. And even if you still doubt that the proof is actually correct, it will not be my problem, but instead you'll need to take it to the guy who wrote the compiler. This is one of the reasons why Walter does not like non-null types. ;o) Its seems to be, Spelling mistakes can be avoided by just spelling correctly. that you prefer to rely on the type system, during compilation, for safety. No, I ideally want the type system to point out when the code is not obviously correct. That does not mean I assume that the code is correct when it compiles (given that I'm using a language that does not require me to prove absence of all bugs, and even if it did I'd at most assume that either the language implementation is incorrect or my code is correct, with a certain margin of error due to undetected hardware failures). This is very unwise. ... Thanks for pointing that out. btw. what was the last compiler you wrote? Embarrassing questions can be avoided by just coming up with the correct answer yourself.
Re: Precise GC state
On 11/22/17 02:53, Temtaime wrote: Hi all ! https://github.com/dlang/druntime/pull/1603 Can someone investigate and bring it to us ? 4 years passed from gsoc 2013 and there's still no gc. Many apps suffers from false pointers and bringing such a gc will help those who affected by it. It seems all the tests are passed except win32 because of optlink failures. Maybe there's some chance to accelerate this PR ? Thanks all +1 -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: TickDuration deprecation
Ok I understand why there is no conversion from Duration to float, but
would be possible to make Duration.total not a member function? So insted
of:
static mytotal(string unit)(Duration dur)
{
return dur.total!unit;
}
alias msecs = mytotal!"msecs";
I could just add
alias msecs = total!"msecs";
On Wed, Nov 22, 2017 at 11:48 AM, Walter Bright via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On 11/22/2017 1:38 AM, Timon Gehr wrote:
>
>> My claim is not that conversion from time to floating point values
>> associated with a few natural units is "properly part of the time
>> abstraction", just that it should exist. Do you agree with that?
>>
>
> I refer to my reply to Jon Degenhardt which has a substantial answer to
> that.
>
Precise GC state
Hi all ! https://github.com/dlang/druntime/pull/1603 Can someone investigate and bring it to us ? 4 years passed from gsoc 2013 and there's still no gc. Many apps suffers from false pointers and bringing such a gc will help those who affected by it. It seems all the tests are passed except win32 because of optlink failures. Maybe there's some chance to accelerate this PR ? Thanks all
Re: TickDuration deprecation
On 11/22/2017 1:38 AM, Timon Gehr wrote: My claim is not that conversion from time to floating point values associated with a few natural units is "properly part of the time abstraction", just that it should exist. Do you agree with that? I refer to my reply to Jon Degenhardt which has a substantial answer to that.
Re: TickDuration deprecation
On 11/22/2017 1:41 AM, Timon Gehr wrote: Why would the conversion function be linked in if I never use it? Good question. It depends on how the code is written, and how the compiler represents it in the object file, and how the linker deals with unreferenced parts of object files. `format`, for example, dynamically decides whether to use floating point or not, so it is always linked in.
Re: Looking for a job in USA
On Saturday, 18 November 2017 at 08:59:53 UTC, Satoshi wrote: On Saturday, 18 November 2017 at 01:31:09 UTC, Indigo wrote: On Wednesday, 15 November 2017 at 17:32:50 UTC, Satoshi wrote: Hi, as the title says, I'm looking for a job opportunity in the USA (H1B visa sponsorship required). I'm experienced Software Engineer with a demonstrated history of working in the security and investigations industry. Skilled in C, C++, D, C#, SQL, Object-Oriented Programming, Software Development and Electrical Engineering. Strong engineering professional with willingness to further education. Actually I work as a full stack ASP.NET developer for SolarWinds in Brno (Czechia). There are couple of my open source projects what I have done in past. https://github.com/Rikarin If you are interested or you know someone who could hire me, please let me know! Thanks! What is your reasoning for coming to the US? You might want to rethink this as America is collapsing. America will be vastly different in 10 years and not a great a place to be. The amount of corruption in the government and the amount of vitriol that people have for each other are astonishing... and it is only getting worse. Actually, Slovakia (SK) and Czechia (CZ) are two most corrupted countries in the EU. We are paying huge taxes and getting nothing in back. If you are moving to settle down that it would be a bad decision IMO. If it is just temporary thing for a few years thing it might be ok depending on you end up. I wanna try to live in the US for a few years and then decide if I should leave or settle down. Do you mind me asking why you are leaving Czech? I hear there are a lot of pretty females there ;) Is it simply business or is it the country itself? To be honest, I couldn't imagine it being as bad as the US but I do not know much about it. To be honest, I'm curious as to what it is like over there because I plan on moving out of the US at some point and I'm looking for countries that are a bit more stable and not on the decline. Actually, CZ is rising up and getting better, but in business area and salaries it's still worse than in the US. Some places in EU are not safe yet. A lot of immigrants are going there from war zones. They are like groups of anarchists destroying everything, stealing, raping and not respecting the laws. Salary... In US you get $100,000/year as a senior developer or something like that, right? There it's only like $30,000/year. But the price of stuff like cars, grocery and everything what you can buy on amazon, e-bay, etc. is the same. The concept of a money in US seems to be different than in SK. There it's more about survive than enjoying life. People in US seems to be little more opened to strangers than here. That's the reasons why I want to leave. BTW: What's wrong with the US? Um, it's the same! You won't escape it if you come to stay. Just because the shit hasn't hit the fan yet does not mean it's not coming down the pipe. There are many here that seem to believe that ignorance is bliss, that is true, for a while. If you looking in the the US news you will see that there is a major killing happening just about once a week. The politicians are all crooks, provably, and the CEO's of many of the largest companies are in cahoots with them. No different than where you are from. The laws here are so screwed up that law abiding citizens are routinely killed by cops or cops killed by people and it all turns out to be a "mistake", or worse, someone's ego. Again, it sounds like you are experiencing this in your own country now... so, if that is what you are trying to escape, you are just moving in to a bigger pond with the same type of scum. Again, it matters not that some people want to stick their head in the sand. Our healthcare system is probably far more screwed up than your country. There are many Americans who are bankrupt over things like a broken arm, etc... 100k$ bill for 3 hours of work... and these insurance companies make billions in profits and it only goes up. Wealthy and ignorant people(depending who's party is president), of course, love to believe that these are isolated problems and every country has them, etc. Almost 30 years ago OJ Simpson was big news and cop murder(er)s were very rare. This is not to say there was no as much corruption, but the corruption is far different, much more dangerous because there are many people with big bucks who are extremely evil or ruthless(can, at the drop of a dime, create a whole can of worms that takes the country many years to try and fix). So, what this proves is the world is becoming more dangerous and more insane. As time goes on the division lines are ingrained deeper(just as a persons face ages and it's a sign). Everyone knows this because the world is far more dangerous than it was. My point is, do you want to be at the center of the economic nuclear explosion? T
Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?
On Wednesday, November 22, 2017 09:28:47 codephantom via Digitalmars-d wrote: > On Wednesday, 22 November 2017 at 08:55:03 UTC, Petar Kirov > > [ZombineDev] wrote: > > On Wednesday, 22 November 2017 at 00:19:51 UTC, codephantom > > > > wrote: > >> btw. what was the last compiler you wrote? > > > > https://github.com/eth-srl/psi > > https://github.com/tgehr/d-compiler > > touché ;-) LOL. I assumed that you were legitimately asking what the name of his compiler was, because I knew that he was writing a D compiler, whereas you were questioning his knowledge/credentials. Timon is a very smart guy. He knows a lot and has lots of great things to say. I certainly don't always agree with him, but he generally knows what he's talking about. - Jonathan M Davis
Re: object.Exception@generated\gtkd\gtkd\Loader.d(125):Library load failed(libgio-2.0.0.dll)
On Tuesday, 21 November 2017 at 18:32:45 UTC, Mike Wey wrote: On 21-11-17 11:19, PECman wrote: On Sunday, 19 November 2017 at 13:39:39 UTC, Mike Wey wrote: On 19-11-17 08:35, PECman wrote: I complied the D application with gtkD successfully.However,I cant run it successfully.My settings are OK.I dunno why it happened to me:-( Who can help me? That line usually includes the error returned from LoadLibrary which should give an indication of why it failed. I assume you installed the GTK runtime for the architecture you are building for ( 32 or 64 bit ). But the error is the messy code. I have already installed the GTK runtime 32 bit(on Windows 7 32 bit) What shall I do next? That's unfortunate, usually there is some info on why it fails after the `(libgio-2.0-0.dll)`. First check if the `bin` directory of the GTK installation is on the PATH, and if there are any other GTK installs on the PATH, GtkD should try to detect the correct runtime to use but that might have failed. ThanQ, I have already solved this problem.ThanQ Very Much:-)
Re: TickDuration deprecation
On 11/21/2017 11:48 PM, Jon Degenhardt wrote:
Hi Walter - I wonder if there is a miscommunication. My understanding is that
the question is whether there should be a built-in conversion from Duration to
float/double in a specific unit of measure, like milliseconds. It sounds as if
your concern is more to ensure that the time package not be required to support
something other than integral values in its internal operations.
My perspective is that the time package should not deal with floating point at
all. I understand that it is useful in some circumstances to treat them as
floating point values, but this should be a layer added on by the user, not by
the time package.
In the older version of StopWatch, this last step conversion could be done with
a call like:
double ms = sw.peek.to!("msecs", double));
That puts the logic of the double conversion into the time package.
In the new version, a call needs to be something like:
double ms = sw.peek.total!("hnsecs").to!double / 1e+04);
The latter form is more error prone and less clear about intent, etc.
I agree. It is a prime candidate for further encapsulating in a function, such
as:
/* Returns: duration in milliseconds to 4 digits past the decimal point */
double swAsDouble(StopWatch sw) { return sw.peek.total!("hnsecs").to!double
/ 1e+04); }
double ms = swAsDouble(sw);
This function, being a trivial one liner, doesn't really need to be in Phobos.
It could be suitable for inclusion in the time package documentation as an
example on how to get results in a floating point manner.
[As a general philosophy, I oppose Phobos being filled with one liners, a mile
wide and an inch deep. Phobos should be a small number of non-obvious,
orthogonal, deep functions. As an extreme example,
int add2(int i){return i+2;}
should not be in Phobos.]
It sounds
as the rationale for depreciating the previous form of conversion is because the
end user may incur floating point round-off error by performing mathematical
operations on the double value. The user can still perform the conversion, but
must go to greater effort. It sounds as if the other part of the rationale is
that conversion is likely to be rare. In my experience, this is not the case.
It is not the rationale I would use for this case.
It's also true that floating point operations are a minefield with respect to
precision and roundoff decisions. These sorts of decisions should not even be
made by the time package, because they will always be wrong for some users, so
they should rightfully be pushed to the user.
Re: TickDuration deprecation
On 22.11.2017 06:50, Walter Bright wrote: There is another, perhaps obsolete, consideration. Some CPUs do not have floating point units. C, for example, is carefully set up so that when you don't need floating point, it isn't required to have an FPU. This made C usable on cheap processors. It's sorta like "why is the GC linked in even though I never used it?" Why would the conversion function be linked in if I never use it?
Re: TickDuration deprecation
On 22.11.2017 03:22, Walter Bright wrote: On 11/21/2017 1:40 PM, Timon Gehr wrote: Computer clocks have discrete ticks, they are not continuous. That may be true, but the plotting library may still just expect a list of doubles. What's the point of removing the simple conversion function that was already available for such use cases? This is a breaking change with zero benefits. I'm in general opposed to "kitchen sink" abstractions, preferring pluggable component abstractions. But this is orthogonal to my complaint. I don't care which Phobos module contains the conversion functionality. It can be part of std.conv.to, for example. Floating point has no business being in a type that is represented as an integral type. Why would it need to be part of the type? I just want the obvious conversion functionality, to enable further processing where this is appropriate. There are no 0.3 clock ticks, the notion does not exist. ... (Great then. There also is no 0.3 float value. :P) The behavior maps cleanly onto integral math, I'm not doing computations on times. I could just use Duration for that. Time durations are always discrete quanta by the nature of the clock used. ... The plotter or whatever other component consumes the timing data might not care about this. not fuzzy fp math. There is nothing fuzzy about floating point operations, Fuzzy as in inexact. The result is well-defined, it's just rounded. Whether that is exact or not depends on what you expected the result to be, it's not properly part of the floating point abstraction. Integral time computations are always an exact multiple of clock ticks. ... The reason why floating point values are popular is that it is often enough infeasible or unnecessary to do the computation without rounding. The output of a computation might be inexact even if the inputs are not. There needs to be some way to move from one regime to the other. but still, yes, for some use cases, the tiny rounding error will just not matter. Whether the rounding error matters or not should not be decided by the time package, it should be decided by what the user decides to do with the time values. I.e. it is not properly part of the time abstraction. My claim is not that conversion from time to floating point values associated with a few natural units is "properly part of the time abstraction", just that it should exist. Do you agree with that?
Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?
On Wednesday, 22 November 2017 at 08:55:03 UTC, Petar Kirov [ZombineDev] wrote: On Wednesday, 22 November 2017 at 00:19:51 UTC, codephantom wrote: btw. what was the last compiler you wrote? https://github.com/eth-srl/psi https://github.com/tgehr/d-compiler touché ;-) nonetheless. I stand by my arguments.
Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?
On Wednesday, 22 November 2017 at 00:19:51 UTC, codephantom wrote: btw. what was the last compiler you wrote? https://github.com/eth-srl/psi https://github.com/tgehr/d-compiler
