Re: Adding Modules to C in 10 Lines of Code
On Monday, 6 June 2022 at 05:48:14 UTC, Ali Çehreli wrote: Now, that is trolling. Ali juvenalian satire, perhaps. I'd accept that. But trolling? Really?
Re: Adding Modules to C in 10 Lines of Code
On Monday, 6 June 2022 at 05:48:14 UTC, Ali Çehreli wrote: Now, that is trolling. Ali Well, I could argue, correctly, that trolling is when someone picks only part of your argument, and uses only that part to support their own agenda - which is to destroy your argument by making it out to be something it is not.
Re: Adding Modules to C in 10 Lines of Code
On Monday, 6 June 2022 at 03:28:07 UTC, zjh wrote: On Monday, 6 June 2022 at 03:17:34 UTC, forkit wrote: Some new languages have even gone out of there way to get rid of the class type completely! At least D hasn't gone that far.. yet. I suspect there are many in the D community that would welcome that ;-) I don't know many other languages,I am not used to them. `Rust` seems no class. These people are too radical. Rust did not set out to be a multi-paradigm language. For Rust, I suspect they got of rid of the class, because they were setting out to be a high-performace, systems-level, programming language, and so decided that the class abstraction had to go. Ok. Fair enough. D likes to think of itself as a high-performace, systems-level, programming language, as well, but it also claims to be a multi-paradigm language. I have no doubt that many in the D community would also love to remove the class abstraction from the langauge, completely, and then they could force people into thinking 'the D way'. I guess they want us to be grateful, that they have provided us with a pseudo class type. How nice of them. The addidtion of a little character, @, to word private, could change this: @private // Compiler says: oh. so you really want private to mean private? ok. I'll do it for you. no problem. But I think even that is asking too much of the D community ;-)
Re: Adding Modules to C in 10 Lines of Code
On Monday, 6 June 2022 at 00:19:16 UTC, zjh wrote: On Sunday, 5 June 2022 at 22:41:41 UTC, Walter Bright wrote: Because it's fun to be first! Yes, `'d'` is always independent. For example, `'d'` is the `first one` without `class encapsulation`. To be fair, the encapsulation of a class can be encapsulated within a module, but not in a class (as one might reasonably expect, if they come from any other main stream language that uses a class type). This implies (to me at least) that D does not consider a class to be a real type, like other main stream languages do. Some new languages have even gone out of there way to get rid of the class type completely! At least D hasn't gone that far.. yet. I suspect there are many in the D community that would welcome that ;-) Even an int type gets better recognition 'as a type', in D. But yes, as far as i know, D is the first to do this - i.e. turn the class into a pseudo type, that cannot have encapsulation unless it is put into a super type (the module), all by its self (with no friends). @private could change that. D could be the first indeed, for turning a pseudo class type, back into an first class type. C'mon D. Be the first!
Re: Adding Modules to C in 10 Lines of Code
On Friday, 22 April 2022 at 19:54:13 UTC, Walter Bright wrote: On 4/17/2022 1:12 PM, Walter Bright wrote: https://nwcpp.org/ An online presentation. Monday at 7PM PST. Slides: https://nwcpp.org/talks/2022/modules_in_c.pdf Video: https://www.youtube.com/watch?v=2ImfbGm0fls Here is the answer to the 2 questions you posed in your presentation: (1) why nobody has done this in 40 years? (2) what went on with C++ for 20 years? It's simple. Rational choice theory tell us, that the reward of the action must outweigh the costs incurred.
Re: D Language Foundation Monthly Meeting for February 2022
On Monday, 7 March 2022 at 08:47:00 UTC, Mike Parker wrote: On Monday, 7 March 2022 at 08:07:11 UTC, forkit wrote: "If it ain't broke, don't fix it!" Well.. There's 'fixing it' and there's 'improving it'. They are not the same thing. In my opinion, gitlab is not an improvement. I agree ;-) I just wanted to point out, that using 'if it ain't broke, don't fix it' is not a useful rebuttal to suggestions for 'improvement'.
Re: D Language Foundation Monthly Meeting for February 2022
On Saturday, 5 March 2022 at 14:03:38 UTC, Mike Parker wrote: But my point was, GitHub has worked well for us for years. There's no desire to move away that I'm aware of. If it ain't broke, don't fix it! "If it ain't broke, don't fix it!" Well.. There's 'fixing it' and there's 'improving it'. They are not the same thing.
Re: Google Summer of Code -- An Apology
On Monday, 7 March 2022 at 07:25:54 UTC, bauss wrote: Don't worry about it, it's only human to forget things. It's impossible to remember everything, if you're already booked up with a lot of other stuff that has to be done. 'forgetting to set a reminder' ahhh.. technology's not that 'smart' afterall.
Re: Beta 2.099.0
On Wednesday, 16 February 2022 at 06:55:57 UTC, Rainer Schuetze
wrote:
yep. working just fine now :-)
// --- compile with -betterC
import core.stdc.stdio;
extern(C):
FILE* __acrt_iob_func(int hnd);
FILE* stdin()() { return __acrt_iob_func(0); }
FILE* stdout()() { return __acrt_iob_func(1); }
FILE* stderr()() { return __acrt_iob_func(2); }
int main()
{
fprintf(stdout, "Enter a character: ");
int ch;
ch = getc(stdin);
if (ch == '\n')
{
fprintf(stderr, "You didn't enter a character.\n");
}
else
{
printf("You entered %c \n", ch);
}
return 0;
}
// ---
Re: Beta 2.099.0
On Wednesday, 16 February 2022 at 04:14:01 UTC, max haughton wrote: On Wednesday, 16 February 2022 at 01:38:08 UTC, forkit wrote: On Tuesday, 15 February 2022 at 13:06:47 UTC, Martin Nowak wrote: I was so hoping I could now begin using -betterC on Windows... but no .. :-( i.e. stdout, stdin, stderr ...still cannot link... Can you not define them yourself in the meantime? err.. howdy doody dat?
Re: Beta 2.099.0
On Tuesday, 15 February 2022 at 13:06:47 UTC, Martin Nowak wrote: I was so hoping I could now begin using -betterC on Windows... but no .. :-( i.e. stdout, stdin, stderr ...still cannot link...
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Wednesday, 9 February 2022 at 17:54:17 UTC, rikki cattermole wrote: On 10/02/2022 5:21 AM, Paul Backus wrote: - C (gcc/clang): __attribute__((warn_unused_result)) C23 will also have [[nodiscard]] Not only will it have that on functions, but also support a string too. Unfortunately its looking like we have chosen to diverge from C, and therefore won't be completely C compatible soon. Will be exciting as to what kind of bugs crop up because of this! Exactly. So now C++ and C will have nodiscard, and when those developers come over to D (the developers most targetted by D btw), someone will have to explain why D decided on a different color for the bikeshed.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Wednesday, 9 February 2022 at 17:40:31 UTC, jmh530 wrote: On Wednesday, 9 February 2022 at 16:21:24 UTC, Paul Backus wrote: [snip] In D, there is no existing word for this, so from that perspective both "mustuse" and "nodiscard" are equally valid. In other languages, there are multiple existing words: - C++17: [[nodiscard]] - C (gcc/clang): __attribute__((warn_unused_result)) - Rust: #[must_use] If you are used to C++, then you will find "nodiscard" natural, and "mustuse" will require you to learn a new word. If you are used to Rust, then you will find "mustuse" natural, and "nodiscard" would have required you to learn a new word. But what color should the bike shed be? ;) Color is a perceptual experience, and its impact on psychological functioning has been well researched.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Tuesday, 8 February 2022 at 21:28:06 UTC, claptrap wrote:
Probably @noignore would be a better name. You're not really
trying to dictate what people do with the result, just that
they dont ignore it.
I'd like to see an option to annotate such an attribute.
Something like this:
@mustuse("or else this could occur")
Then the compiler could return that message, rather than some
generic message that provides no real insight into why that
attribute was used in the first place.
Similar to C++20's: [[nodiscard("check if not null")]])
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Tuesday, 8 February 2022 at 02:57:29 UTC, forkit wrote: I would prefer @must_use over @mustUse, for example (althouhgh i prefer @mustuse to both of these, since the underscore is not really needed in this case). my argument for the above, is: The problem with using camelCase on @attributes, is that it implies nothing special about it (the attribute), at all. It is common practice to use camelCase for things like variables, function names, etc... i.e. things that hold something, or do something. Whereas an @attribute is essentially a predicate. You are proclaiming a static declaration, that will apply to what follows. As such, it deserves to stand out, with a different naming convention. That is: all @lowercase, but when required, @snake_case.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Tuesday, 8 February 2022 at 02:21:37 UTC, Paul Backus wrote: I guess core.attribute.gnuAbiTag sneaked in behind your back, huh? Anyway, I'm happy to change it if that's your call, although it would have been nice to have caught this before the DIP was officially accepted. actually, I wish camelCase was not a requirement of user defined attributes. I would prefer @must_use over @mustUse, for example (althouhgh i prefer @mustuse to both of these, since the underscore is not really needed in this case). Don't be discouraged though, the proposal is sound. But ideas that might help it become more acceptable to programmers (and the langauge), is still not worthy of being excluded from discussion (I think I got enough negations in there ;-)
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Tuesday, 8 February 2022 at 01:53:17 UTC, forkit wrote: also, the use of the word 'must' in any programming language, needs careful consideration. 'mustuse' has the potential to invite mass 'mustuse' demonstrations! 'nodiscard' suggests somewhat more 'autonomy', and would achieve a more-or-less similiar outcome.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Tuesday, 8 February 2022 at 01:40:38 UTC, forkit wrote: I often say to my cat 'what are you doing' .. but what i really mean is 'don't do that'. by avoiding negation, I'm probably just confusing my cat as to what i really meant. mustuse -> I must use it? Why must i use it? How must I use it? What happens if i don't use it. nodiscard -> don't discard it. nice and simple (just like 'don't do that'). I guess the question really is: What it the most important concept you are relaying to the programmer by the use of that term? That they 'must use it'. Or, that they 'cannot discard it'. They seem like two different concepts to me. I don't believe that using nodiscard in C++, means you must use it. If in D, it means you must use it, then 'mustuse' makes more sense. If not, then stick with what people already know, is my advice.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Tuesday, 8 February 2022 at 01:25:52 UTC, Walter Bright wrote: Sorry, all those negations made my brain explode. P.S. English has examples of negation issues, such as: "I could care less." which makes no sense at all, until you realize it's just a shortened version of "I couldn't care less." The addition or subtraction of the negation does not change the meaning, as the brain doesn't do a good job recognizing it. The phrases "not no-way", and "not no-how" use multiple negations to emphasize, rather than negate. I often say to my cat 'what are you doing' .. but what i really mean is 'don't do that'. by avoiding negation, I'm probably just confusing my cat as to what i really meant. mustuse -> I must use it? Why must i use it? How must I use it? What happens if i don't use it. nodiscard -> don't discard it. nice and simple (just like 'don't do that').
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Monday, 7 February 2022 at 23:38:11 UTC, Walter Bright wrote:
Anytime you find yourself writing not-nohow, not-noway, etc.,
it's time to redesign the state of the variables. Try to
organize logic so ! is not necessary. I mean, try to organize
logic so ! is absent.
But sometimes that requires too much effort ;-)
e.g.
!debug { do this }
My brain decided this form of logic without me really thinking at
all.
Now I have to 'rethink', in order to find the correct form of
that logic that doesn't require the use of !
nodiscard is better than mustuse for the same reason.
Suppose I don't want to 'use it'. That should be allowed, as long
as I don't discard it. With mustuse, I'm being told I can't
discard it, and that i must use it.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Monday, 7 February 2022 at 23:38:11 UTC, Walter Bright wrote: Andrei once asked me for scientific evidence that negations are cognitively more difficult for human brains to understand. I didn't have it at the time, but did eventually find it and forwarded it to Andrei, who was satisfied with it. I didn't keep a copy, though. It's not just my opinion that negations are to be avoided, there's research justifying it. .. I certainly don't discount such research. However, I expect there is also research that says something different ;-) Also, I expect you're talking about linguistics, and not programming languages. Truths may hold in one, and not other. Regardless, the research I am familiar with, tells me that we are psychologically biased towards cognitive schemas that we already hold. Changing ones cognitive schemas is not effortless, and, since D is very much focused on attracting programmers from the C++ world, the existing schemas those users hold should always be factored into ones thinking when implementing change in D.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Monday, 7 February 2022 at 13:55:40 UTC, Paul Backus wrote: I've seen similar sentiments expressed many times before, in other contexts. Every time, there are some who insist that the new name will never feel natural to them, and they will never let go of the old name. And every time, history proves them wrong. The fact is, human brains are quite plastic and adaptable. You'll get used to @mustUse, just like I did, and so will everyone else. First, I'm not 'insisting' on anything. I'm just expressing a view. nodiscard is already used by more programmers that D is likely to ever adopt. Indeed, it's these programmers that D is trying to adopt. I'm not sure forcing such people to adapt is necessarily the right approach. that is my point. it's not necessary. you making it necessary ;-)
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Monday, 7 February 2022 at 05:09:23 UTC, Paul Backus wrote: On Monday, 7 February 2022 at 05:05:27 UTC, forkit wrote: my only concern is the capital U, in @mustUse This seems a little inconsistent with current attributes?? e.g: nogc nothrow inout https://dlang.org/spec/attribute.html also, nodiscard would actually seem more logical, given the above as well. I bet you, people will be thinking nodiscard, but will have to remember to type, @mustuse, only to have the compiler complain, that its' actually @mustUse See my previous replies on this topic: https://forum.dlang.org/post/xgdwevkxqapljcvyj...@forum.dlang.org https://forum.dlang.org/post/yxoinjtarkuotnlnc...@forum.dlang.org no amount of replies will change anything ;-) .. people will still 'think' @nodiscard, but have to 'remember' it's actually @mustuse, but oops.. no... it's @mustUse.. I do not expect anything from my feedback ;-) .. I'm just saying..humans are humans..
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Friday, 28 January 2022 at 13:07:13 UTC, Mike Parker wrote: my only concern is the capital U, in @mustUse This seems a little inconsistent with current attributes?? e.g: nogc nothrow inout https://dlang.org/spec/attribute.html also, nodiscard would actually seem more logical, given the above as well. I bet you, people will be thinking nodiscard, but will have to remember to type, @mustuse, only to have the compiler complain, that its' actually @mustUse
Re: D Language Quarterly Meeting Summary for January 2021
On Sunday, 23 January 2022 at 03:24:04 UTC, Paul Backus wrote:
The way I envision it, `std` would be the "rolling release"
namespace that allows breaking changes, and if you wanted
stability, you'd have to explicitly depend on `std.vN`. What we
currently call `std` would be renamed to `std.v1`.
module test;
@require("std.v2");
import std.stdio; // std is now std.v2
void main(){ }
Re: D Language Quarterly Meeting Summary for January 2021
On Sunday, 23 January 2022 at 00:07:17 UTC, forkit wrote: I'd like to argue, that an introduction of 'phobos versioning' is a good idea, but should not be allowed in D2, but would warrant a D3 release. In D3, std phobos would always be the latest and greatest. By using D3, you agree to this, including any breaking changes introduced into that lastest and greatest version. But since each version of phobos released in D3 would have it's own version, you can always opt back into that version that works for you, at any time. This frees up phobos to be innovative, and not worry too much about breaking changes, while also not confusing new users of D, as to which version they should be using.
Re: D Language Quarterly Meeting Summary for January 2021
On Saturday, 22 January 2022 at 05:43:55 UTC, Paul Backus wrote: (I think it would also be ideal if the namespace `std` were reserved for the latest stable release... wouldn't this prevent breaking changes from being allowed in a newer version of phobos? by using phobos versioning, you're free of that constraint, and people can opt in or not to a particular version of phobos. of course, then you have the problem of 'std' forever being some version.. from long..long..long ago... is this what they call 'a hard problem' ;-)
Re: Why I Like D
On Friday, 14 January 2022 at 14:50:50 UTC, H. S. Teoh wrote: IMO, 'autonomy' isn't the notion you're looking for. The word I prefer to use is *empowerment*. A programming language should be a toolbox filled with useful tools that you can use to solve your problem. It should not be a straitjacket that forces you to conform to what its creators decided is good for you (e.g., Java), nor should it be a minefield full of powerful but extremely dangerous explosives that you have to be very careful not to touch in the wrong way (e.g., C++). It should let YOU decide what's the best way to solve a problem -- and give you the tools to help you on your way. Yes, trying to reduce a concept into a word, can be tricky. Even so, 'autonomy' is the right word I think: 'the capacity of an agent to act in accordance with an objective'. I've found the D programming language 'empowers' me to be more 'autonomous' (or at least, to more 'easily' be autonomous. I don't feel like D restricts me, before I even begin (like other languages often do, or the learning curve associated with their syntax does). So I far less concerned about features, and more interested in how a programming language empowers autonomy.
Re: Why I Like D
On Friday, 14 January 2022 at 02:13:48 UTC, H. S. Teoh wrote: How is using D "losing autonomy"? Unlike Java, D does not force you to use anything. You can write all-out GC code, you can write @nogc code (slap it on main() and your entire program will be guaranteed to be GC-free -- statically verified by the compiler). You can write functional-style code, and, thanks to metaprogramming, you can even use more obscure paradigms like declarative programming. I'm talking about the 'perception of autonomy' - which will differ between people. Actual autonomy does not, and cannot, exist. I agree, that if a C++ programmer wants the autonomy of chosing between GC or not, in their code, then they really don't have that autonomy in C++ (well, of course they do actually - but some hoops need to be jumped through). My point is, that a C#/Java programmer is more likely to be attracted to D, because D creates a perception of there being more autonomy (than that provided by C#/Java). I'm not saying it's the only thing people consider. Obviously their choice is also reflected by the needs of their problem domain, their existing skill set, the skillset of those they work with, the tools they need, the extent to which their identity is attached to a language or community, etc..etc. And I'm just talking about probability - that is, people are more likely to be attracted to something new, something that could benefit them, if it also enhances their perception of autonomy, or at least, does not not seek to diminish their existing autonomy (e.g a C programmer might well be attracted to betterC, for example). D should really focus more on marketing one of its biggest strenghts - increased autonomy (well, the perception of). Getting back to the subject of this thread, that's why 'I' like D.
Re: Why I Like D
On Thursday, 13 January 2022 at 21:32:15 UTC, Paul Backus wrote: Actually, I think *self*-government has very little to do with it. I'm not so sure. Presumably, C++ provides a programmer with much greater autonomy over their code than D? C provides even greater autonomy over both C++ and D. And I'd argue, that's why C remains so useful, and so popular (for those problems where such a level of autonomy is needed). By, 'autonomy', I mean a language provided means, for choosing what code can do, and how it does it. A language that makes you jump through loops to get that autonomy, will serve a niche purpose (like Java for example). An aversion to losing that autonomy, I believe, is a very real reason as to why larger numbers of C++ programmers do not even consider switching to D. Of course, even if they did consider D, there are other considerations at play as well. It think this is also why D (in contrast to C++ programmers) tends to attract programmers from the C# and Java like world. That is, D provides greater autonomy (which should translate to greater freedom to innovate and be creative with code). Of course autonomy is not something that is real. Only the 'perception of autonomy' can be real ;-)
Re: Why I Like D
On Thursday, 13 January 2022 at 11:30:40 UTC, zjh wrote: On Thursday, 13 January 2022 at 03:10:14 UTC, zjh wrote: I'm a `GC phobia`. "A phobia is an irrational fear of something that's unlikely to cause harm." "A phobia is a type of anxiety disorder defined by a persistent and excessive fear of an object or situation." "A phobia is an excessive and irrational fear reaction." " phobias .. are maladaptive fear response" plz... go get some help ;-)
Re: Why I Like D
On Wednesday, 12 January 2022 at 20:41:56 UTC, Walter Bright wrote: My experience with people who don't want to use a product I've worked on is: 1. they'll give reason X, which is usually something that sounds convenient 2. I fix X, they can use it now! 3. they then give reason Y, after thinking about it for a minute What's happening is neither X nor Y is the real reason. They just don't want to tell me the real reason, usually because it's an emotional one. Yes, emotions come into play, but the 'emotion argument' on its own explains nothing. The 'real reason' is that people are by nature, aversive to losses. This impacts how people evaluate a choice. e.g. an aversion to losing an existing skill set... what you need to do, is argue you're case in a way that produces more dopamine neurons to activate ;-) https://en.wikipedia.org/wiki/Loss_aversion
Re: Why I Like D
On Wednesday, 12 January 2022 at 16:14:54 UTC, Steven Schveighoffer wrote: I wonder if there is just so much fear of the GC vs people who actually tried to use the GC and it failed to suit their needs. I've never been afraid of the GC in my projects, and it hasn't hurt me at all. -Steve No. Fear is irrelevant. Fear of GC is just a catch-all-phrase that serves no real purpose, and provides no real insight into what programmers are thinking. It's all about autonomy and self-government (on the decision of whether to use GC or not, or when to use it, and when not to use it. Programmers want the right of self-government, over their code. This is not politics. It's human psychology. It is, to a large extent I believe, what attracts people to D. I don't believe people are attracted to D because it has GC. There are better languages, and better supported languages, with GC. D should not spend time promoting 'GC', but rather promote how programmers can have this autonomy. Also, the idea that 'GC' means you never have to think about memory management... is just a ridiculous statement.. ..Every programmer *should* be thinking about memory management.
Re: Why I Like D
On Wednesday, 12 January 2022 at 06:27:47 UTC, forkit wrote: surely this article needs to be balanced, with another article, titled 'why I don't like D' ;-) (..but written by someone who really knows D). oh. btw. I'd love to see Walter (or Andrei, or both) write this article ;-)
Re: Why I Like D
On Wednesday, 12 January 2022 at 02:37:47 UTC, Walter Bright wrote: "Why I like D" is on the front page of HackerNews at the moment at number 11. https://news.ycombinator.com/news surely this article needs to be balanced, with another article, titled 'why I don't like D' ;-) (..but written by someone who really knows D). IMO... the next generation programming language (that will succeed) will be defined by it's tooling, and not just the language. Language complexity increases the demands on tooling. I remember Scott Meyers.. the last thing D needs.. 2014 talk. We really need him now.. more than ever ;-)
Re: Beta 2.098.1
On Monday, 13 December 2021 at 13:03:53 UTC, Martin Nowak wrote: On Sunday, 12 December 2021 at 22:22:34 UTC, Adam Ruppe wrote: On Sunday, 12 December 2021 at 22:01:57 UTC, Martin Nowak wrote: http://dlang.org/changelog/2.098.1.html 404'd! Yes sorry, it's tricky for me to wait with the announcement till the website PR & deployment. btw. do you keep any stats on number of regression fixes, number of bug fixes, per release (and organised into dcompiler vs druntime vs phobos)? (or do I need to view the change log of each release manually?)
Re: DConf Online 2021 Links
On Friday, 19 November 2021 at 10:10:11 UTC, Mike Parker wrote: See you there! Well, you won't see me there, as I'd have to get up too early in the morning. But have really enjoyed watching the broadcasts on youtube. btw. Andrei Alexandrescu... no show??... is he still part of the D Foundation or involved in D in any way, anymore?
