Re: This is why I don't use D.
On Wednesday, 5 September 2018 at 00:49:36 UTC, Everlast wrote: Really, D wins on very few metrics but the D fanboys will only focus on those. If D wants to survive it better get people willing to help it, making their lives more difficult when there are far better options out there will only starve D of what it needs(investing). All those that think D is just fine, you are cutting your own throats... Eventually D will become defunct and you'll have to move on. Might be 10 years, 20 years, 30 years... but when Walter and Andrew are done with D in a few years there will be no one who will keep it alive(maybe a fork will occur but doubtful it would get anywhere). And of course every single one of these threads descends right into the same rampant myopic pedantry. "I'm a new user and I like some things about this, but half the time it was broken and all people tell me to do is fix it myself. If D wants to grow large and replace other languages, it needs normal users who do not have tons of experience or who don't have the time to contribute to it, and their experience needs to be a smooth one." "Go away and stop using D. Now, if only we had more experienced users with lots of time to contribute to the compiler..." *10 pages of nitpicking over specific features, forgetting entirely to address or empathize with the OP's position*
Re: Found on proggit: simple treap language benchmark, includes D
On Sunday, 20 May 2018 at 15:30:37 UTC, Nerve wrote: I'll see if I can get it included so they can test it on their specific setup. Sorry for double-posting, but I've included a GC-enabled solution based on their Java solution, and have a pull request up that's a bit more idiomatic, pulling unnecessary static methods out as functions. It scores VERY HIGH across the board on their "naive" benchmark. High expressivity, high maintainability, extremely fast, moderately low memory usage. This is the sort of thing that will convince people of D. Benchmarks involving GC and lots of allocations that still have it way ahead of the competition, with clean code! For any other language, this is front-page, first-glance material.
Re: Found on proggit: simple treap language benchmark, includes D
On Saturday, 19 May 2018 at 15:09:38 UTC, Joakim wrote: D does well, comes in second on Mac/Win/linux: https://github.com/frol/completely-unscientific-benchmarks https://www.reddit.com/r/programming/comments/8jbfa7/naive_benchmark_treap_implementation_of_c_rust/ The results in these tests are blazing fast, but they all forego the GC for manual allocation. In the Issues section of the repo, I included some simple, vanilla D translated from their Java implementation and made for use with the GC and runtime. I also included some raw sample times that are competitive with desktop i7 times of Rust and ref-counted C++ on...get this...a much slower laptop i5. This sort of thing needs to be shouted from the rooftops by the Foundation. I'll see if I can get it included so they can test it on their specific setup.
Re: auto: useful, annoying or bad practice?
On Monday, 30 April 2018 at 21:11:07 UTC, Gerald wrote: So I'm curious, what's the consensus on auto? Speaking for myself: 1) I find auto to be useful when instantiating objects locally; eliminates redundancy, noise, and line size. 2) I avoid auto functions and despise them in API documentation. It’s difficult to work with the return type of a function when the definition is auto and the author didn’t follow up by describing exactly what was returned. 3) I avoid auto for primitive types because their type names are short, and declaring them C- and Ada-style at the beginning of a local block helps massively clarify what a function is about to do. So basically only for object instantiations. I’ve yet to find a great use for it outside of that.
Re: Favorite GUI library?
On Monday, 23 April 2018 at 14:56:37 UTC, Zoadian wrote: If we are talking binary size: then yes, I agree. But it is a lot easier to maintain & write than QT-Widgets/GTK based code. Users don't care how easy it is for you to maintain your code. If the user experience sucks, they'll never come back. When code readability, size, and maintenance gains all coincide with performance, it's a rare thing indeed, but in most cases developers have to make a tradeoff. I agree with TheGag96 that Discord is probably the only application with a feature set that justifies the tradeoffs. Mailboxes, taskers, and text editors consuming 150 Mb of RAM, multiple processes, spare CPU cycles, and battery life rendering a blinking cursor is an instant uninstall. The user DOES NOT CARE how easy it is for you to maintain your codebase.
Reddit Post: Overview of the Efficient Programming Languages (v.3)
Overview of the Efficient Programming Languages (v.3): C++, Rust, Swift, Scala, Dlang, Kotlin, Nim, Julia, Golang, Python. http://reddit.com/r/programming/comments/8cw2xn/overview_of_the_efficient_programming_languages/
Re: Quora: Why hasn't D started to replace C++?
On Thursday, 1 February 2018 at 15:27:02 UTC, Benny wrote: Suggestion: Is it maybe not better to have one "front-end" compiler visible that people download Example: D run main.d D run main.d --compiler ldc ( not installed? Auto download and compile using dub ) D run main.d --compiler ldc --options -o3 D run main.d --compiler gdc ( not installed? Auto ...) D package install web-d Seen this layout with a some other compilers where everything is clean integrated. - Compiler ( default ) -- Run -- Test - Package -- Install -- Remove -- Update - Tools --- Format --- Check - Language server? No dub, no ldc, gdc, no confusion, just one clean interface. What happens behind the interface is nobody there business. It just presents better. Dub already does half this work with the compiler option but its a package manager not the "face of D". Hard to explain... Anyway, too much off-topic? DUB can fill this role quite well. What it needs is clearer documentation on how to switch compilers. Better yet, outright compiler switches from the command line to designate a compiler, compile debug code, or run unittest code. On another note, I do want to put in my two cents about this controversial thread, and the continuing GC threads that pop up. People that use D find it highly productive and performant in their domains. C and C++ programmers, ostensibly the target audience of D, continue to reject GC as some kind of albatross they'll never get over. dlang.org needs front-page, clear as day examples of the speed benefits of optimized D code. Show that there is minimal or no impact from the GC is most modern use cases (i.e. within components of a web framework, within a database, within a desktop application). Compare performance of real solutions. And, if it can be done, show how maximally performant embedded code with no GC can be run on constrained real-time hardware with a significant gain in code readability. tl;dr EXAMPLES EXAMPLES EXAMPLES SHOW the world why the GC is not only not a big deal, but a good thing, and STOP trying to TELL them by playing defense in discussion threads around the Internet.
Re: Maybe D is right about GC after all !
On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright wrote: "C, Python, Go, and the Generalized Greenspun Law" http://esr.ibiblio.org/?p=7804 I would simply add that the strongest vocalizations come from those with objections. The silent majority that is perfectly okay with GC and gets huge development complexity reductions thanks to it rarely spare the energy to argue againts the constant GC complaints.
Re: Built-in RAII in D
On Sunday, 28 May 2017 at 18:38:21 UTC, Moritz Maxeiner wrote: All in all, I see little to no benefit to what you propose, while requiring significant work on the language spec. Point taken. My only remaining reservation then is the communication problem D has with the wider prospective programming world in conveying that the GC has alternatives that work. Otherwise, this thread can die.
Built-in RAII in D
Thanks to Walter Bright's recent comments at Dconf about memory
safety, and my own lamentations about the continued use of C in
all contexts where memory safety is crucial by overconfident
programmers who believe they can do no wrong, I've decided to
propose a baked-in RAII implementation for D. I would like to
submit a DIP, but first I'd like to run it by the forum community
and see what improvements need to be made, possibly due to my own
naivety on the subject.
To qualify that, I am nowhere near an expert on memory
management. But, I've spent enough time absorbing discussion on
the topic through osmosis and reading on it due to the D
community's concerns about it that I may as well make myself
heard and be shot down if I'm wrong.
I understand if many people are resistant to building it into the
language. Phobos already has it, and there's the automem library
by Atila Neves. However, I think the perception shift gained by
baking in these features will benefit D enormously. D users can
run around all day trying to convince people that different
library implementations of RAII exist so one need not use the GC,
but the only thing that is going to convince the programming
world at large is a giant announcement on Reddit, HackerNews, and
other places that "Hey, D has RAII now!" This will also drive
many new eyes to the language that never would have looked
otherwise.
There are also the obvious syntactical benefits. Referencing an
RAII object and its members would be literally no different than
referencing a GC heap object. No need to fiddle with library
constructs to extract one's reference.
Without further adieu, let's get started.
--- refcounted ---
Keyword "refcounted" allocates an object on the heap, and
therefore uses an allocator. By default, a built-in malloc()
implementation is used.
@nogc void main()
{
auto refCountedObject = refcounted Object();
} // References go to 0, object is destroyed
The allocation method used by refcounted can be overloaded. The
overload is a function which expects a type and a set of
parameters that were passed to the constructor. One can allocate
the object however they choose, call the passed constructor, and
then the function expects a return of a reference to the
allocated object.
Forgive my ignorance, I'm unsure how to handle a collection of
parameters. Haven't had to do it yet.
ref T opRefCounted(T)(params)
{
T* object = malloc(sizeof(T));
object.this(params);
return ref object;
}
opRefCounted() is ALWAYS UNSAFE SYSTEM CODE! This could manifest
as a compiler warning whenever it is present that must be
suppressed by a flag so the developer must acknowledge they have
used a custom allocation scheme. There are, of course, other
options for handling this, I'm just stating the most obvious.
--- unique ---
Keyword "unique" allocates an object on the stack. It is only
accessible to the given scope, child scopes, or functions it is
explicitly passed to. Therefore, it does not use an allocator.
@nogc void main()
{
auto scopedObject = unique Object();
} // Fall out of scope, object destroyed
--- How new and GC fit in ---
Keyword "new", which allocates to the heap for the D garbage
collector, may not be used with the @nogc attribute. Only
refcounted and unique. No objects, functions, methods, or any
other code within the scope of, or called from the scope of, a
@nogc context, may allocate using new.
@nogc void main()
{
auto refCountedObject = refcounted Object(); // Okay
auto scopedObject = unique Object(); // Okay
auto tracedObject = new Object();// Error!
{
auto refCountedObject = refcounted Object(); // Okay
auto scopedObject = unique Object(); // Okay
auto tracedObject = new Object();// Error!
}
}
More examples using called functions.
void refCountedUsed()
{
auto refCountedObject = refcounted Object();
}
void uniqueUsed()
{
auto scopedObject = unique Object();
}
void newUsed()
{
auto tracedObject = new Object();
}
@nogc void main()
{
refCountedUsed(); // Okay
uniqueUsed(); // Okay
newUsed();// Error!
}
void main()
{
refCountedUsed(); // Okay
uniqueUsed(); // Okay
newUsed();// Okay
}
All of these methods are legal when the GC is allowed.
void main()
{
auto refCountedObject = refcounted Object(); // Okay
auto scopedObject = unique Object(); // Okay
auto tracedObject = new Object();// Okay
{
auto refCountedObject = refcounted Object(); // Okay
auto scopedObject = unique Object(); // Okay
auto tracedObject = new Object();// Okay
}
}
I may be missing some things, but I've left out some exhaustive
details since I'm sure many of you are already experienced in the
subject and aren't looking for complete documentation in a
proposal like this.
Feel free to level criticism, and let me
Re: Thoughts on a Future Garbage Collector
On Thursday, 3 December 2015 at 18:36:22 UTC, Jakob Jenkov wrote: My experience from Java is that one size never really fits all. Open it up instead. Let the community "plug in" and I am sure D will get a wealth of memory management strategies fast. Not just 1 garbage collector, but N garbage collectors. One approach might be to allow for memory management with better primitives that simplify the design of manually managed software. I've been greatly enjoying Jonathan Blow's video blogs on the design of his own language, Jai. It's targeted at game programmers, and as such he's gone to great pains to ensure language primitives remove the friction from manually allocating and deallocating memory, while still providing the full power of such a system. I wonder what Walter and Andrei think of potentially overhauling those elements in D. Right now all of the manual memory management is basically ripped from C and C++ with no changes, and no insights into how to improve such a system. But I do see why they went that route. Type safety is a top concern.
Re: Please vote for the DConf logo
On Wednesday, 4 November 2015 at 09:30:30 UTC, Andrei Alexandrescu wrote: 3) by anonymous: PNG: http://imgur.com/GX0HUFI SVG: https://gist.github.com/anonymous/4ef7282dfec9ab327084 3 with font tweaks.
Re: I have this game engine...
On Sunday, 1 November 2015 at 02:35:49 UTC, Manu wrote: In terms of what I've used commercially, Fuji is the platform abstraction and core concept implementation that lives below the layer that the high-level interacts with. Editors and tooling (I feel this is what you're talking about when you start using words like 'Unity' or 'Unreal') typically impose particular design decisions wrt scene-graph, physics implementations, etc. The goal of Fuji is not to be Unity, it's intended to be the platform which you could build Unity above, and all commercial engines I've had contact with do have such a layer. I'm not sure if that answers your question. For what it's intended to be, Fuji is quite comprehensive. As a full-game-engine a-la Unity/Unreal, it needs all the high-level stuff built on top. The reason I didn't touch that, is because that layer is extremely subjective, and there are no right/wrong answers there. I also change my mind on that stuff every year or 2. Whereas the lower level is a lot less subjective, and it's been more-or-less constant since I started Fuji in 2003. I still wouldn't do it differently today, although I have a lot more experience and console generations to draw wisdom from. Nonono, you're fine, what I'm looking for is a lightweight engine that ISN'T like Unity or Unreal and the sophisticated nature of their tools. Often, their engine design decisions back me into a corner when it comes to how I want to organize my own project, and they're oftentimes overkill. About the only thing I would want to keep from those two monster engines is some live compilation feature where changes in source, assets, or UI scripting are immediately apparent in-game. But that takes a massive amount of work, I understand if it's not a priority. You have to port the thing to D in the first place, a significant undertaking in and of itself. What you have seems to be great, so I'll follow it eagerly.
Re: I have this game engine...
On Sunday, 1 November 2015 at 07:30:57 UTC, Manu wrote: I actually wrote that exact thing at Remedy (for Quantum Break) which runtime compiles D code, and hot-swaps the new code into the live data... if only I could liberate the source >_< Wow, I had no idea D was being used for such a massive project, especially on a current-gen console. If I might ask before taking the thread too far off-topic, what tools did you guys use to maintain productivity and organization in such a huge project? (Debuggers, editors, IDEs, etc.)
Re: I have this game engine...
On Sunday, 1 November 2015 at 01:33:29 UTC, Manu wrote: I have this game engine (https://github.com/TurkeyMan/fuji), it's lived for about 12 years now (first commit in 2004, and it existed prior before source control). I called it 'Fuji' (a modest, yet pleasing and attractive mountain). It supports (or has supported) shit-loads of platforms; I'm a game-engine dev for life, and I have a fetish for portability, and niche platform support. Needless to say, it has had a LOT of time and energy put into it, and I would say it's infrastructurally better than most proprietary commercial game-engines I've worked with (although there are some missing features, I just implement what I need), mainly in that I have the luxury to aggressively refactor when design decisions turned out to be mistakes, and no deadlines to meet. It is a very good example of what we use in real-world AAA gamedev. I would be very, very interested in this. I've been yearning for something in D that supports some lighter 3D with texturing, animated sprites, and lighting on both. Something flexible and light that can also have modules pulled independently for drawing and sound if possible. Unfortunately, DGame really only supports 2D, and Dash has all its weight behind being a full-featured 3D engine a la Unity/Unreal. Would Fuji fit the bill?
Re: Option types and pattern matching.
On Sunday, 25 October 2015 at 05:53:32 UTC, Rikki Cattermole wrote: I'm pretty sure e.g. opEquals/opCmp should work here. Shouldn't need to switch upon a primitive type. Theoretically could do it on a e.g. struct. Which has the special comparison that you want. Hm...these are boolean operators. This means we can only compare two cases at a time, does it not? Negates the strength of a switch/pattern match, unless there's something I'm missing. What are these variable length structs you mention, and their special comparisons? How would we use them?
Re: Option types and pattern matching.
On Sunday, 25 October 2015 at 06:22:51 UTC, TheFlyingFiddle wrote:
You can do something very similar to that. With slightly
different syntax.
import std.traits;
import std.conv;
import std.variant;
struct CMatch(T...) if(T.length == 1)
{
alias U = typeof(T[0]);
static bool match(Variant v)
{
if(auto p = v.peek!U)
return *p == T[0];
return false;
}
}
auto ref match(Handlers...)(Variant v)
{
foreach(handler; Handlers)
{
alias P = Parameters!handler;
static if(P.length == 1)
{
static if(isInstanceOf!(CMatch, P[0]))
{
if(P[0].match(v))
return handler(P[0].init);
}
else
{
if(auto p = v.peek!(P[0]))
return handler(*p);
}
}
else
{
return handler();
}
}
assert(false, "No matching pattern");
}
unittest
{
Variant v = 5;
string s = v.match!(
(CMatch!7) => "Lucky number seven",
(int n)=> "Not a lucky number: " ~ n.to!string,
() => "No value found!");
writeln(s);
}
That is actually freaking incredible. It evaluates to a value,
unwraps values, matches against the None case...I guess the only
thing it doesn't do is have compiler-enforced matching on all
cases. Unless I'm just slow this morning and not thinking of
other features a pattern match should have.
Re: Option types and pattern matching.
On Sunday, 25 October 2015 at 05:05:47 UTC, Rikki Cattermole
wrote:
Since I have no idea what the difference between Some(_), None
and default. I'll assume it's already doable.
_ represents all existing values not matched. In this case,
Some(_) represents any integer value that is not 7. None
specifically matches the case where no value has been returned.
We are, in most languages, also able to unwrap the value:
match x {
Some(7) => "Lucky number 7!",
Some(n) => "Not a lucky number: " ~ n,
None => "No value found"
}
Or something to that effect. The equivalent switch statement
right now would be:
if (x.hasValue()) {
switch (*x.peek!(int)) {
case 7:writeln("Lucky number seven!"); break;
default: writeln("Not a lucky number: ",
*x.peek!(int)); break;
}
} else {
writeln("No value.");
}
This does not return a value (is a procedural structure); the
switch cannot match null; in order to unwrap, we must call peek()
again; and between the extra if-else and the break statements,
this is not as clean.
As a note, pattern matching could almost be considered an
extended form of the ?: operator, which matches over value cases
rather than boolean truthiness.
Apologies if this is all below you, I'm not in Andrei's or
Walter's league, just an interested party trying to make
suggestions to better the language.
Option types and pattern matching.
Hello D community! First time poster, I'm utterly fascinated with
this language's mix of features. It's powerful and expressive.
There are just two conveniences I'd like to see out of D. The
first is pattern matching, a functional construct which can
unwrap tuples or other containers, usually evaluates to a value
(in most languages), and which almost always idiomatically
enforces the programmer to match over every possible case of a
given type.
While ML-inspired languages like F# and OCaml have some good
pattern matching syntax, it's not syntax which would fit in to D;
I suggest taking inspiration of Rusts's matching construct.
match x {
Some(7) => "Lucky number 7!",
Some(_) => "No lucky number.",
None => "No value found"
}
From that bit of code, we can see another feature at work: The
Option type. It wraps another type (i.e. Option int, Option Car)
and represents a wrapped presence of a value of that type
(Some(n), Some(aCar)) or an absence of that type (None).
Combined with pattern matching, we end up with a safe, functional
construct which can replace a switch statement in most cases,
returns a value, is incredibly compact and readable, and can be
used with Options to ensure that we always account for the
possibility of a value not present, eliminating a whole class of
errors when we use it judiciously.
My only concern is that switch statements, while horrendous
syntactically, are extremely performant and essentially compile
to a series of branches.
Are there any counter-arguments for the implementation of these
two features? Is D in a state where language additions have come
to a stop?
