Re: D is dead
On Thursday, 23 August 2018 at 12:03:59 UTC, Walter Bright wrote: I'd appreciate a list of bugzilla issues you regard as critical to your operations. Sorry to weasle in, but https://issues.dlang.org/show_bug.cgi?id=2043 Sorry for childish behaviour in bugzilla (my last comment), but this bug makes me radiate in gamma-rays, because the current D behaviour is stupid and invalid, the workarounds (hacks) are incredibly ugly, and, on top of that, the bug is 10 years old. There are also tons of other bugs, inconsistencies etc. that I stumble upon regularly, they all were in bugzilla long before my "discoveries". Ok, let me be brutally honest. These types of things really piss me off in D. IMHO top-tier devs are not focused on really important things. For me, a long-term D user, proper closures are much more relevant than D/C++ Kama Sutra. I don't have any C++ code and I don't intend to write any. I want to and do write D code and I want it to work *at least* correctly. But Walter, our compiler-fu black belt master (not making fun of him, I really respect his expertise), is more concerned about "poor" C++ users (which have all the luxuries) than about peasants like me with their puny #2043's, which he could solve by a single roundhouse kick (and maybe a restomp of the groin). But I get it, it's a community-driven project, so "if you want it, DIY or get lost". I choose the latter, because my compiler-fu is rather weak, if exists at all. I still love D, but more like a good book, than a reliable tool. It's funny and sad at the same time, that I regularly find nightly Rust more reliable than stable D. So the obvious move for me is to stop arguing with the Party and simply choose other party that better represents and addresses my needs. Don't get me wrong, I'm not ditching or D or saying it's crap, I'm still using it from time to time, but I will likely not choose it for any "serious" project (even hobby). Just tired of stomping on all the occasional caltrops, which are well-known, marked on the maps, but not being removed because children starve in Africa.
Re: #dbugfix Issue 2043
On Wednesday, 7 February 2018 at 07:15:36 UTC, Mike Franklin wrote: It's a really old bug, and top-voted in bugzilla... And a really frustrating one. That's a shame we had to launch a special campaign to finally notice this bug, despite it being the top-voted one. And I hope this time Walter has a better idea than what he proposed in 2015. Anyway, what's the current status, is anyone working on it?
Re: D compiles fast, right? Right??
Atila laid it out pretty clear: he doesn't care about the differences, he wants the work to be done. And I'm with him on that. Go and it's standard library may be way simpler, but it get's the job done (which is trivial in both cases, by the way) almost instantaneously, which is a much bigger deal than it seems to be. When your edit-compile cycle is that fast, it changes the way you write code, you develop a habit of writing smaller pieces of code and testing them more frequently. Remember that Linus Torvalds' talk about Git at Google? https://www.youtube.com/watch?v=4XpnKHJAok8=3025 H. S. Teoh is not the only one here cringing at "fast code fast" on the main page. I use D from time to time for over 10 years now, and even used it at work and it was a relatively positive experience, thanks to vibe.d. But compilation times are just horrible - minimum 3 seconds for a 1500 lines project (on a 8-core 4GHz CPU with 16 GB RAM), and that's after I ditched std.regex, made all imports qualified (didn't help that much, though) and switched to ld.gold. And I would be ok with slow compilation if DMD was smart enough, doing some graph magic, like extensive control flow analysis, and insane optimizations, but it doesn't. For example, Rust compilation times are no picnic either, but it's obvious why - you get nice good-looking error messages, tons of useful warnings and very fast programs free of memory corruption bugs. It's not the case with DMD, though. The language may be better than C++, but it's fastest compiler is slower and produces worse code? I'd rather not boast about speed at the main page in this situation. And god save us from ridicule by Goers.
Re: Should we warn if we detect null derefernces or void value uses ?
On Monday, 5 December 2016 at 04:41:55 UTC, Stefan Koch wrote:
Hi Guys,
What is your opinion, should we warn if we unambiguously detect
something that is clearly unwanted ?
int fn(int y)
{
int x = void;
++x;
return x+y;
}
This requires data-flow analysis (The same kind that tells you
if you are skipping a statement)
And will slow down compilation a little if we enable such a
warning.
Yes, but we should issue an error, like Andrei said. A language
is only as useful as it's best implementation, so diagnostics
like that are essential. Data-flow analysis shouldn't even be
optional or lacking in any modern compiler.
Re: the best language I have ever met(?)
On Monday, 21 November 2016 at 12:44:47 UTC, Jonathan M Davis wrote: Someone could create a DIP for it though and argue for it. If they did that convincingly enough, maybe it would become a feature. I suspect that the response will be though that since it's easy enough to just create a template to do the same thing, it's not worth adding to the language. - Jonathan M Davis That's definitely what Walter would say. But I think it shouldn't be the only argument to not add a feature to the language itself: if some pattern is useful/frequent, and users implement it themselves every time, it should be either implemented in the compiler or in the standard library. Besides that, it just seems inconsistent that D lacks this particular feature: fixed-sized arrays are there, type deduction is there, so where's type deduction for fixed-sized arrays? Though I would argue that it's better to use '_' instead of '$' to denote deduced fixed size, it seems more obvious to me: int[_] array = [ 1, 2, 3 ];
Re: [OT] Music to Program Compilers To
Nice to see fellow metalheads here. Here are some of my favourite bands: Aghora Animals as Leaders Between The Buried And Me Children of Bodom Cynic Dan Swano Gorod Iron Maiden In Flames Killswitch Engage Kovenant Lamb Of God Lye By Mistake Nar Mattaru (the Russian one) Parkway Drive Pessimist Revocation Son Of Aurelius The Black Dahlia Murder For me, good music is much like good code - technical and beautiful at the same time. And it so happens that metal very often matches both criteria. However, there are also some non-metal bands and artists worth mentioning: Counts Of The Netherworld Jimi Hendrix KBB KMFDM Lindsey Stirling Nine Inch Nails Primus
Re: Why D isn't the next "big thing" already
On Wednesday, 27 July 2016 at 10:41:54 UTC, ketmar wrote: On Wednesday, 27 July 2016 at 10:39:52 UTC, NX wrote: Lack of production quality tools like? no, "refactoring" and other crap is not "production quality tools", they are only useful to pretend that you are doing something useful, so you will look busy for your boss. Why do you use D then? C++ already exists and you can do anything in it. Oh, D is more convenient and robust? Well, "Refactoring" is more convenient and robust than sed -i 's/.../.../g'.
Re: DConf 2016 on YouTube
Excellent, thanks to all people involved! DConfs are my favourite conferences: great speakers and very interesting topics. I wish Adam Ruppe had a talk at this one, I absolutely love his presentation style and sense of humour.
Re: new cpuid is ready for comments
AMD FX 8350 test https://gist.github.com/burjui/a661499a2daa93302395d136b6c99152 cpuinfo https://gist.github.com/burjui/8c10924284c1c1f9cce33bcd2b71d863
Re: how to mark an extern function @nogc?
On Wednesday, 13 July 2016 at 02:20:58 UTC, anonymous wrote: On Tuesday, 12 July 2016 at 14:04:55 UTC, Seb wrote: D is entirely driven by highly motivated volunteers. (this will change soon with the new D foundation) With the fundation, volunteers wont be highly motivated anymore. Fundations are real motivation-killers. I disagree. Volunteers will be motivated more, because D will now be more reliable as a thing they put their effort into and rely upon. Right now D is moving at relatively slow pace, because everybody works on it in their spare time. That also means they don't have spare time anymore. Somebody has to work on it full-time.
Re: Vision for the D language - stabilizing complexity?
On Sunday, 10 July 2016 at 11:21:49 UTC, Walter Bright wrote: On 7/9/2016 7:44 PM, Ola Fosheim Grøstad wrote: Scheme is a simple functional language which is easy to extend. If they have to extend it, it isn't Scheme anymore. You misunderstand the meaning of "extend" in respect to Scheme due to your lack of experience with it. Macros are the way of extending Scheme, you don't need to hack the compiler for that. From Wikipedia: --- Invocations of macros and procedures bear a close resemblance — both are s-expressions — but they are treated differently. When the compiler encounters an s-expression in the program, it first checks to see if the symbol is defined as a syntactic keyword within the current lexical scope. If so, it then attempts to expand the macro, treating the items in the tail of the s-expression as arguments without compiling code to evaluate them, and this process is repeated recursively until no macro invocations remain. If it is not a syntactic keyword, the compiler compiles code to evaluate the arguments in the tail of the s-expression and then to evaluate the variable represented by the symbol at the head of the s-expression and call it as a procedure with the evaluated tail expressions passed as actual arguments to it. --- For example, an "if expression" is written as follows: ; Returns either settings or an error, depending on the condition (if (authenticated) (load-settings) (error "cannot load settings, authentication required")) Either branch is an expression, and the false-branch can be omitted (then a Scheme's "null" equivalent will be returned instead). If you need a "block", a sequence of expressions, you could write this: (if (authenticated) (begin (display "loading settings") (load-settings)) (begin (display "something went wrong") (error "cannot load settings, authentication required"))) When you specify true-branch only, it's tedious to wrap your sequence in "begin" expression. But you can write a "when" macro, which takes a condition and a sequence of expressions and generates the code for you: (define-syntax when (syntax-rules () ((when pred exp exps ...) (if pred (begin exp exps ...) Now you can use it just as an ordinary "if": (when (authenticated) (save-settings) (display "Saved settings")) What about the false-branch-only "if"? (define-syntax unless (syntax-rules () ((unless pred exp exps ...) (if (not pred) (begin exp exps ...) (unless (dead) (display "walking") (walk)) The only syntax Scheme has is S-expressions, which are used to represent both data and code, so there's nothing to be extended in the language itself. You just write a macro that generates the code you want. Macros are effectively AST transformers, it just happens so that in Scheme everything is represented in S-expressions, so the code you write is already the AST. So if you "extend" Scheme by writing a macro, it's still Scheme. You can think of macros as of D string mixins, but without the ugly stringiness.
Re: Vision for the D language - stabilizing complexity?
On Saturday, 9 July 2016 at 08:57:18 UTC, Observer wrote: constant if durable if persistent if adamant if unalterable if immutable if Okay, that last one is a joke, considering that we're talking about keyword overloading. But the effort did spark some other brain cells to fire. So we could have had any of these: exactly if strictly if only if I'm sorry, but these examples are horrible, except maybe "constant if", because none give a clue about compile-time and they are not even synonyms. The last three are just plain nonsense, especially "strictly if" which implies that ordinary "if" is somehow not reliable. You didn't even think about it, just picked the words from a book. "static if" is perfectly fine, if you just try to imagine what in "if" could be dynamic, because the only meaningful answer is: "The condition". If there is a context where "static" really needs to be replaced by a synonym, it's definitely not "static if".
Re: Beta release DUB 1.0.0-beta.1
On Wednesday, 8 June 2016 at 12:21:57 UTC, Jacob Carlborg wrote: It's just that since the language support other styles of comments one could think that all comments are supported and it will cause confusion if only one style is supported. That reason alone is enough. Restricting DUB special comments to only /++/ will put users off, because now they know that there's a cool feature in DUB, but it only works with certain types of comments, that nobody wants to remember (why should they?), so they will decide that this feature is either broken or unfinished and will hardly use it at all. We could make users' lives easier, if we allowed them to just specify the dependencies in Gradle style on a single line: #!/usr/bin/env dub // dependencies: "color:~>0.0.3", "vibe.d:~>0.7.28"
Re: Killing the comma operator
On Wednesday, 11 May 2016 at 13:29:56 UTC, Gopan wrote:
int x;
while( scanf("%d", ), x!= 0) // until user input 0.
{
//do something with x
}
Does anybody think that this is a useful case of comma operator?
Well, it is, but judging from my experience, comma operator is
the most rarely used part of the language. I hardly ever needed
it in C and C++, where it originated, same with D and Java. In
fact, I had to check if it works in Java at all - turned out,
it's only allowed in "for" loops. Just never used it and forgot
about it.
The comma operator does more harm than good, is very rarely used
and is far less usable than tuples, so I'm all for killing it
(except in "for" loops).
Re: d-vulkan, automatically generated D bindings for Vulkan
On Sunday, 20 March 2016 at 00:52:48 UTC, Alex Parrill wrote:
If I import a xcb_connection_t from some bindings,
it ties d-vulkan to those bindings, which I'd rather not do.
By the magic of D:
version (Linux)
{
import xcb.xcb;
}
...
version (Linux)
{
xcb_connection_t* con;
}
Also you can make xcb-d dependency optional in DUB.
Re: Why do some attributes start with '@' while others done't?
On Friday, 22 January 2016 at 18:28:31 UTC, Wyatt wrote: If you need an IDE to work comfortably in a language, something has clearly gone wrong. Oh come on, not that "Vim/Emacs vs IDEs" crap again. Please stop being so black and pretentious. Have you ever tried IntelliJ IDEA? It's the best IDE I know, and it saves me a lot of time by automating tasks I'm not interested in, e.g. reindenting the code, maintaining project files in Git, renaming things within their contexts etc., while proving an excellent debugger, a decent unit test runner and and integrated lint. I spend much less time messing with these things and have more time for actually writing the code and experimenting. If you consider all these conveniences unnecessary, good for you. You can continue using your favorite screwdriver, but most professionals prefer a screw gun, because it saves time. You may have big powerful hands, but you don't have to brag about it and point fingers: "Just look at this pussy with a screw gun, he clearly has never been to gym." By the way, it's perfectly normal to make screws that hold things tight, but not easily screwed in by hand.
Re: Walter on his experience as a dev, on running an open source project and D
On Wednesday, 20 January 2016 at 03:13:38 UTC, deadalnix wrote: https://www.reddit.com/r/programming/comments/41sdzj/walter_bright_on_being_a_developer_running_an/ I also prefer to work at night, mainly because of silence. A simple test: listen to a song in your headphones at day, then listen to it on the same volume level at night. Recently I almost stopped listening to music (even ambient) while I write code, because it turns out I do less mistakes and overlook things not so often, when I code in silence. It makes coding less entertaining, but more productive.
Re: Functions that return type
On Wednesday, 20 January 2016 at 04:27:27 UTC, blm768 wrote: It's not very far along, though. Right now, I have a "compiler" that parses integers and parentheses. ;) That's alright. Parsing and AST construction are trivial with S-expressions (Lisp-like syntax), so if you use them for the early stages of development, you can focus on the type system. When you're done with types, you can switch to making a better grammar for your language.
Re: Damage Control: An homage to Rampart (Alpha)
On Wednesday, 6 January 2016 at 02:39:08 UTC, rcorre wrote: I'll have to look into that. If you're saying D does that by default for debug builds -- the alpha release _is_ a debug build Sorry, it was a bit unclear. I meant that: - A console window is only meaningful in debug builds, so it should be disabled in release builds. - Debug binaries should not be published, as they are meant for development only. They execute contracts, unittests and code in "debug" statements, which slow down the app and are useless for an end-user. DMD makes a console application by default, no matter what build profile is used. Here's a relevant thread: http://www.digitalmars.com/d/archives/digitalmars/D/learn/Hide_console_of_gui_program_coded_by_gtkD_41799.html It's suggested there to use "-L/SUBSYSTEM:WINDOWS" switch in DMD command line when linking under Windows.
Re: Damage Control: An homage to Rampart (Alpha)
Nice game! On Monday, 4 January 2016 at 02:34:37 UTC, rcorre wrote: Right now even having a single tile enclosed counts -- which actually may be too lenient. Not at all, sometimes it's the only way to win, it often depends on generosity of the embedded Tetris. 6 missiles is not that much, and if your tetris-fu is not enough to join an another base, you're pretty much screwed on the next round, unless you quickly enclose a small area during rebuild. Cursor speed is pretty low, so you can't react quickly and in the 3rd round your base always looks like Swiss cheese. Also, it would be really nice to use Enter for confirmation and Escape for going back by default, since these are standard. I cannot reassign the "cancel" action, because app crashes if I press Escape. Found some minor issues: - On Windows, it shows a console window on launch. It may be useful for debugging, but since game doesn't output anything, it's useless and should be shown only in debug builds anyway - On the title screen, it says "v0.0 (alpha)", but I'm actually using v0.2 - A typo: Options -> Shake: "Taseteful" Anyway, I played the game for an hour and enjoyed it. It needs some tuning and some kind of an introductory tutorial mode, but it's playable and fun. Also, kudos for composing music in LMMS :)
Re: Implementing a Programming Language in D: Lexical Analysis
On Tuesday, 29 December 2015 at 05:57:34 UTC, Ali Çehreli wrote:
I've realized that with a nested anonymous enum, there is no
need to (and no way of) mentioning the enum type inside a
user-defined type. This can simplify the implementation:
Only if you intend to use enum members as manifest constants,
otherwise you're losing the type safety and explicitness
offered by named enums.
For example, I wouldn't use an anonymous enum for lexeme types.
enum {
a,
ulong b = 42, c, // b and c are ulong
s = "hello", // an inferred string between integrals!
x = 7, y, z
}
For me, it's a clear example of unnecessary over-engineering.
However, move 's' to the end of the list or remove it
altogether,
then x, y, and z become ulong! Weird.
It's even worse than that: x, y and z will still be int (inferred
from 7).
This code
void main()
{
enum {
a,
ulong b = 42, c, // b and c are ulong
x = 7, y, z
}
import std.stdio, std.typecons;
tuple!(typeof(b), typeof(c), typeof(x)).writeln;
}
will print
Tuple!(ulong, ulong, int)(0, 0, 0)
which is somewhat counter-intuitive. I would suggest to remove
this feature
as useless and bug-prone. The following is much clearer IMHO,
even though it's more verbose:
enum { a }
enum: ulong { b = 42, c }
enum { s = "hello" }
enum { x = 7, y, z }
Even more than that, I would also suggest to remove anonymous
auto-typed enums
without an initial value from which type can be inferred, e.g.:
enum { a } // a is an int implicitly
Again, the following is not much harder to write, but the type of
'a' is immediately clear:
enum: int { a } // a = int.init, obviously
Although I understand that these are breaking changes,
and D is too mature to break anything (almost not being
sarcastic).
Re: DMD is slow for matrix maths?
On Tuesday, 27 October 2015 at 05:27:22 UTC, Jack Stouffer wrote: My intentions are to call things as they are. If people are demoralized after learning that one person working in his spare time can't match the productivity of several people working full time, then they need a reality check. Can't agree more. It's unrealistic to expect Walter work on the backend full-time just to catch up with GCC and LLVM teams, let alone support architectures other than x86 as well.
Re: It's a class! It's a struct! It's ... SuperStruct!
On Tuesday, 20 October 2015 at 15:22:41 UTC, Vladimir Panteleev wrote: "This video is not available from your location". I haven't been able to find a mirror that's watchable from here either. Same here, though I finally googled out it's key phrase: "It's a floor wax and a dessert topping!" Pretty much explains Walter's suggestion :D
Re: 1st Ever Artificial Consciousness to be Written in D Language
On Wednesday, 30 September 2015 at 06:55:47 UTC, Grand_Axe wrote: I am slightly behind schedule with the coding. The main logic is only getting completed today. The system should be ready for first looks by the 9th of October. Surprise, dlang hacker! :) Let me guess: you'll spend all October and most likely much more time debugging your AI and the result will be far from what you promised, assuming you're just too naive and confident, and not trying to bullshit us. I'll be the first to apologize if you'll *ever* reach your declared goals, let alone 9th October. Meh
Re: Operator overloading or alternatives to expression templates
On Sunday, 13 September 2015 at 17:16:40 UTC, Daniel N wrote:
int opCmp(Foo rhs)
{
return (id > rhs.id) - (id < rhs.id);
}
IMO, subtracting boolean values is bad code style, it's better to
be explicit about your intention:
(id > rhs.id ? 1 : 0) - (id < rhs.id ? 1 : 0)
Re: Programming in D – Tutorial and Reference
On Monday, 31 August 2015 at 01:22:58 UTC, puming wrote: Can we post a text without link and people could copy/paste the address? Will HN check that also? There's no way for them to do that, since all they will have access to is the URL. But if you click the link, your browser will add a "Referer" (sic) header to the HTTP request: https://en.wikipedia.org/wiki/List_of_HTTP_header_fields
Re: 1st Ever Artificial Consciousness to be Written in D Language
On Sunday, 6 September 2015 at 22:49:17 UTC, jqb wrote: verging on racism with talk of "Nigerian software" The term has nothing to do with racism. See https://en.wikipedia.org/wiki/419_scams AFAIK, in Russia, my home, this type of scam is commonly known as "Nigerian letters": https://ru.wikipedia.org/wiki/Нигерийские_письма I assume you're an American, because Americans are obsessed with racism and overly sensitive in general, they like to bring such things up. Funny fact: in Russia, we call black people negros, and it's completely normal, just like calling Chinese or Georgian people asian. On the other hand, pointing out skin color _is_ racist here, no matter if it's black, yellow or white. All this stuff is completely culture-dependent, after all. On the topic: I agree that being rude is not the way do discuss things, especially in an IT community (we strive to be smarter than the majority of people, don't we?). But I understand the skepticism in comments. Best scientists study inner workings of human brain and are working on theory of consciousness if you will, but current results are far from even understanding it completely, let alone building an AI. And then GrandAxe pops up with this revolutionary software, claiming that Okeuvo company built an AI. However, that claim is not supported by anything and reminds me of the Unlimited Detail technology by Euclideon, which was announced in a similar manner, promising a revolution in graphics rendering. As you can see, it's far from it, despite the fact they were given $2 million by the Australian government. It seems like this revolution takes a little bit more effort, than was anticipated :) And there's no reason to think Okeuvo's technology is different in that sense. In general, I tend to not trust people, who claim that their technology _will_ do this and that, revolutionize something and so on. Show me a working technology first, sell it later. Otherwise it's nothing but promises, and I'm not interested in that, because everybody can create a website and make promises. This thread should be posted at the release date, with "will do something" replaced by "does something", supported by a working demo that anybody can download without giving up their social security number, sexual preferences and whatnot. And in this particular case, it should be also supported by scientific papers, since they claim to solve such a huge scientific problem of the 21th century.
Re: Rant after trying Rust a bit
On Thursday, 6 August 2015 at 12:33:33 UTC, Kagamin wrote: On Thursday, 6 August 2015 at 11:33:29 UTC, Ola Fosheim Grøstad wrote: DOA. http://www.acronymfinder.com/DOA.html (Degenerate Overclockers Anonymous?) http://www.urbandictionary.com/define.php?term=DOA Without this great site it would often be hard to understand what people from USA are talking about.
Re: Points of Failure
On Wednesday, 29 July 2015 at 16:00:35 UTC, Alex Parrill wrote: `git clone` can take awhile with large repositories, like mono. Also not all people have a decent Internet connection, so it's just impractical to wait 10 minutes just for one file. For example, the only option I have at home is 4 Mbit ADSL, and it sucks big-time these days. The general principle applies to everything, not only to browsing sources: the less networking you have to deal with, the better. So being able to view a single file online instead of cloning the whole repository is a win, as well as downloading individual packages in a package manager instead of downloading recent system images. And of course, you can get a single file from a Git repository, *if it's explicitly enabled in there* : http://stackoverflow.com/a/1126333/888720 But do you really want to type something like: $ git archive --remote=g...@github.com:foo/bar.git --prefix=path/to/ HEAD:path/to/ | tar xvf - ? Obvious stuff is so obvious.
Re: Points of Failure
On Tuesday, 28 July 2015 at 23:29:42 UTC, Walter Bright wrote: Having it viewable on github also makes it very convenient to embed links to specific source lines. Indeed. Also GitHub makes it easy to contribute (at least small fixes), because you can fork, edit and make a pull request all in one place. BTW, is it worth so much discussion? It's only 5 points :)
Re: DMD memory management
On Monday, 15 June 2015 at 22:25:27 UTC, Tofu Ninja wrote: I think fork just does copy on write, so all the garbage that is no longer being referenced off in random pages shouldn't get copied. Only the pages that get written are actually copied. You are correct. fork() guarantees separate address spaces for the parent and the child processes, but there's a note in it's man page: NOTES Under Linux, fork() is implemented using copy-on-write pages, so the only penalty that it incurs is the time and memory required to duplicate the parent's page tables, and to create a unique task structure for the child.
