Re: Why D is not popular enough?
On 20/08/2016 6:08 PM, Bill Hicks wrote: On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran wrote: For years, i was travelling along Golang, Rust, Perl, Ruby, Python, PHP, JScript, JVM Languages. Lastly Crystal Lang and Nimrod, Julia, Haskell, Swift and many more that i can't remember. I'm 24 years old, my first lang was PHP and VBasic then C,C++ and i first heard about D after 2005 when i was 14-15 years old. I always ignored D, i prejudiced that D failed, because nobody were talking about it. I decided to check it yesterday, it has excellent documentation, i almost covered all aspects. I think D is much better than the most of the other popular langs. It's clear as JScript, Swift, Julia and PHP, also it's capable enough as C,C++. I think D deserves a bigger community. Why people need NodeJS, Typescript etc, when there is already better looking lang? Everyone talking about how ugly is Golang. So why people are going on it? Performance concerns? Why languages that are not backed up by huge companies are looking like they failed? F*CK, here we go again. D is not popular because it is a failed language (i.e, failed design, implementation, and everything else). How many times do we need to repeat that before people get it? Move on, get over it, and be happy. There are far better programming languages out there for any problem domain. And yet it is steadily growing.
Re: Why D is not popular enough?
On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran wrote: For years, i was travelling along Golang, Rust, Perl, Ruby, Python, PHP, JScript, JVM Languages. Lastly Crystal Lang and Nimrod, Julia, Haskell, Swift and many more that i can't remember. I'm 24 years old, my first lang was PHP and VBasic then C,C++ and i first heard about D after 2005 when i was 14-15 years old. I always ignored D, i prejudiced that D failed, because nobody were talking about it. I decided to check it yesterday, it has excellent documentation, i almost covered all aspects. I think D is much better than the most of the other popular langs. It's clear as JScript, Swift, Julia and PHP, also it's capable enough as C,C++. I think D deserves a bigger community. Why people need NodeJS, Typescript etc, when there is already better looking lang? Everyone talking about how ugly is Golang. So why people are going on it? Performance concerns? Why languages that are not backed up by huge companies are looking like they failed? F*CK, here we go again. D is not popular because it is a failed language (i.e, failed design, implementation, and everything else). How many times do we need to repeat that before people get it? Move on, get over it, and be happy. There are far better programming languages out there for any problem domain.
Re: Checked integrals is in reviewable state
On Friday, 19 August 2016 at 23:59:43 UTC, Andrei Alexandrescu wrote: Code: https://github.com/dlang/phobos/pull/4613 Docs: http://dtest.thecybershadow.net/artifact/website-e0b2b4609f1a8e4010ccbe9492ab4af3e3fdd2fb-ab9e77dd6d78136b1f0172e60f7b4f43/web/phobos-prerelease/std_experimental_checkedint.html New policies implement NaN and saturation with relative ease. I think it shouldn't be too hard to add bounds checks in a future iteration. Anyhow, reviews would be very welcome. Andrei Hook hook hOok Op cooK hOOk oP Kook HOOK ... say it three times. I wanna hear you say it in your accent. Yet another D masterpiece with those nice ass member names. I think you should retire and go play poker (the stock market, or whatever it is white capitalist do to reach nirvana).
Re: How about a special null template parameter?
On Fri, 19 Aug 2016 23:43:05 +, Engine Machine wrote:
> then the only question is can the current compiler interpret ^n
> unambiguously and without undue complexity. If it can, and such a
> syntactic rewrite is useful, then it should be implemented.
No. You must weigh the added complexity against the benefits. The less
frequently a feature will be used, the more surprise you will inflict on
people when they encounter it. The less like other things in the language
this new feature is, the more awkward it will be for users.
You called your suggestion "syntactic sugar", but if we can call it that,
we can say the same of templates. Your implication that it is a simple
change is incorrect.
Your proposal clashes with existing features. It's even a breaking
change. It's implemented easily enough by hand with:
class SomeFoo {
// common fields and methods, possibly abstract
}
class Foo(T) : SomeFoo {
// everything else
}
The by-hand implementation is also more obvious.
You would have to change the proposed syntax, show that this can't be
reasonably done in a library, and show what it gives you that's
appreciably better than what's currently there.
Re: Why D is not popular enough?
On Saturday, 20 August 2016 at 00:19:30 UTC, Daniel wrote: On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran wrote: Hope this helps, Daniel BTW, I'm not the guy in that Gravatar image... ;-) Daniel
Re: Why D is not popular enough?
On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran wrote: I always ignored D, i prejudiced that D failed, because nobody were talking about it. I decided to check it yesterday, it has excellent documentation, i almost covered all aspects. I think D is much better than the most of the other popular langs. It's clear as JScript, Swift, Julia and PHP, also it's capable enough as C,C++. I think D deserves a bigger community. Why people need NodeJS, Typescript etc, when there is already better looking lang? Everyone talking about how ugly is Golang. So why people are going on it? Performance concerns? Why languages that are not backed up by huge companies are looking like they failed? I lurk this forum every so often, since the time when there was this funny guy who ranted like a rude drunkard. At work I developed in dBase, Turbo Pascal, Delphi, Visual Basic, ASP, Java, C# and PHP, roughly in that temporal order, but most of my few hobby project and freelance work have been in Delphi, then Lazarus. D seems to have enhanced a lot, and I have even downloaded dlangide source once to try compiling and running it. I ran into some dub dependency problem and forgot about it. I guess, bundling the tools, ide and a couple good demos into an easily downloadable installation package (or package repo as in Debian) could be of some help. See for example: https://sourceforge.net/projects/lazarus/files/ http://www.oracle.com/technetwork/java/javase/downloads/jdk-netbeans-jsp-142931.html?ssSourceSiteId=otnes Hope this helps, Daniel
Checked integrals is in reviewable state
Code: https://github.com/dlang/phobos/pull/4613 Docs: http://dtest.thecybershadow.net/artifact/website-e0b2b4609f1a8e4010ccbe9492ab4af3e3fdd2fb-ab9e77dd6d78136b1f0172e60f7b4f43/web/phobos-prerelease/std_experimental_checkedint.html New policies implement NaN and saturation with relative ease. I think it shouldn't be too hard to add bounds checks in a future iteration. Anyhow, reviews would be very welcome. Andrei
Re: How about a special null template parameter?
On Friday, 19 August 2016 at 22:20:29 UTC, Lodovico Giaretta
wrote:
On Friday, 19 August 2016 at 21:51:38 UTC, Engine Machine wrote:
On Friday, 19 August 2016 at 19:19:35 UTC, Lodovico Giaretta
wrote:
1) `null` has a very precise meaning: it is the only valid
value of an unnamed type only known as `typeof(null)`, which
implicitly converts to any class/pointer/dynamic
array/associative array type. Thus this thing should have a
different name.
null as many interpretations. It is ok to expand the meaning.
It is done all the time. If it confuses you are creates a
semantic difficulty, I don't mind what it is called. It could
be called Boomfurkasufasdf.
In this case, defining it to be null fits in semantically
though. If it creates some compiler issue then, again,
anything else could be used. I'd prefer Null or NULL or Aleph
or something short and meaningless.
The problem is that null is a valid value to instantiate an
alias template parameter with. So using it to do something
completely different may create ambiguity (does that null means
"parent template" or is it a valid instantiation? Who knows).
But as you said, this is just a matter of finding a name.
Yes, but in this case it is used in a very specific and exact
sense, so it is not arbitrarily ambiguous. Again, if it is, then
just use some other syntax.
2) What about this case:
```
class Type(T): Type
{
static if (T is Dog)
int y;
else
float z;
}
```
What should be inside the base?
z.
This is wrong. If Type has to be the base class of every
Type!T, then it cannot contain z, as there is one Type!T
(namely Type!Dog) which does not contain z. So in this case the
base class Type should be empty. As you see it is not that
simple.
Yeah, T should be empty. This is not a good example though
because one wouldn't compose such things like this. It is quite
simple when one follows the logical guidelines. The code would
"work" but the inheritance hierarchy would not be correct and the
compiler would spit out errors, as it should.
So, even if I mis-reasoned about it(quickly glanced over it
without thinking), it doesn't change anything though.
Base would be empty and technically we would have two types of
derived types. One of Dog with y in it and everything else with z
in it, call it E.
Dog and E would just be derived types of Type.
It is no different than
class Type(T): Type
{
static if (T is Dog)
int y;
else static if (T !is Dog)
float z;
}
which is semantically equivalent to
class Type(T): Type
{
static if (T is Dog)
int y;
else static if (T is E)
float z;
}
Where E is everything that is not a Dog.
4) I think that the value of this addition is little wrt. the
amount of work the compiler should do to implement it (which
at first sight would be a lot). But this is of course just my
opinion.
It is just syntactic sugar and requires no complex compiler
modifications. The benefit is reduced visual complexity and
that is always a bonus. That is the point we don't write in
0's and 1's... everything else is just syntactic sugar. In
this case, it is a very simple rewrite rule. A few lines of
code would be all that is required.
I'm not an expert, but I think this requires *a lot* of
compiler work: it has to analyze every symbol in the class to
find out whether it must be part of the "uninstantiated" base
or not. And this kind of analysis may not be easy (it may be
masked by the use of traits, template mixins, string mixins and
so on). Even humans can easily get it wrong (see my previous
example).
Yes, it might. But if it is truly just semantic sugar, then it
shouldn't pose any problem because it's just a rewrite. Obviously
I am not suggesting it just be written up in a New York minute
and thrown in the code. It needs to be properly analyzed and such.
Also, I thought of other problems:
- Interaction with non-class templates: how should they behave?
Or are we just introducing a special case for class templates?
(Special cases are very bad, we should limit them).
- Interaction with base classes and interfaces: how is this
"uninstantiated base class" inserted into the graph of classes
and interfaces? Are interfaces considered implemented by this
base class? Is this base class inserted between the templated
class and the "original" base class?
I think you are making it too complicated. This is a grammar
transformation. If the syntax is grammatically equivalent to
something already implementable in the language, then one only
has to make sure the new syntactic sugar does not collide with
pre-existing semantic evaluations.
Basically, if the compiler can always transform it in to valid
code and the new syntax doesn't create ambiguous or wrong
interpretations, then it is valid.
Since I've already said that basically it is a simplification of
the type system for classes, and have hinted at the rewrite
rules(o
Re: How about a special null template parameter?
On Friday, 19 August 2016 at 23:12:39 UTC, Engine Machine wrote:
On Friday, 19 August 2016 at 22:20:09 UTC, Enamex wrote:
On Friday, 19 August 2016 at 18:25:06 UTC, Engine Machine
wrote:
[...]
Something like this:
class Type(T: typeof(null)) { //< L1 (specialization)
int x;
}
class Dog {}
class Type(T) : Type!(typeof(null)) { //< L2 (`typeof(null)`)
static if(is(T: Dog)) //< L3 (`is(MyType: IntendedType)`
or `is(MyType == ExactType)`)
int y;
}
What you're looking for is "specialization", on line "L1".
Also some corrections on lines "L2" and "L3"
How is this any different, besides adding meaningless
complexity, to inheritence as it already is?
Um, not sure what you mean. This isn't suggesting adding
anything; it's already legal/compiles.
Re: How about a special null template parameter?
On Friday, 19 August 2016 at 22:20:09 UTC, Enamex wrote:
On Friday, 19 August 2016 at 18:25:06 UTC, Engine Machine wrote:
[...]
Something like this:
class Type(T: typeof(null)) { //< L1 (specialization)
int x;
}
class Dog {}
class Type(T) : Type!(typeof(null)) { //< L2 (`typeof(null)`)
static if(is(T: Dog)) //< L3 (`is(MyType: IntendedType)` or
`is(MyType == ExactType)`)
int y;
}
What you're looking for is "specialization", on line "L1". Also
some corrections on lines "L2" and "L3"
How is this any different, besides adding meaningless complexity,
to inheritence as it already is?
Re: How about a special null template parameter?
On Friday, 19 August 2016 at 21:51:38 UTC, Engine Machine wrote:
On Friday, 19 August 2016 at 19:19:35 UTC, Lodovico Giaretta
wrote:
1) `null` has a very precise meaning: it is the only valid
value of an unnamed type only known as `typeof(null)`, which
implicitly converts to any class/pointer/dynamic
array/associative array type. Thus this thing should have a
different name.
null as many interpretations. It is ok to expand the meaning.
It is done all the time. If it confuses you are creates a
semantic difficulty, I don't mind what it is called. It could
be called Boomfurkasufasdf.
In this case, defining it to be null fits in semantically
though. If it creates some compiler issue then, again, anything
else could be used. I'd prefer Null or NULL or Aleph or
something short and meaningless.
The problem is that null is a valid value to instantiate an alias
template parameter with. So using it to do something completely
different may create ambiguity (does that null means "parent
template" or is it a valid instantiation? Who knows). But as you
said, this is just a matter of finding a name.
2) What about this case:
```
class Type(T): Type
{
static if (T is Dog)
int y;
else
float z;
}
```
What should be inside the base?
z.
This is wrong. If Type has to be the base class of every Type!T,
then it cannot contain z, as there is one Type!T (namely
Type!Dog) which does not contain z. So in this case the base
class Type should be empty. As you see it is not that simple.
I am after simplifying class design.
Fair enough. Though I'm not sure this is the right way to go.
4) I think that the value of this addition is little wrt. the
amount of work the compiler should do to implement it (which
at first sight would be a lot). But this is of course just my
opinion.
It is just syntactic sugar and requires no complex compiler
modifications. The benefit is reduced visual complexity and
that is always a bonus. That is the point we don't write in 0's
and 1's... everything else is just syntactic sugar. In this
case, it is a very simple rewrite rule. A few lines of code
would be all that is required.
I'm not an expert, but I think this requires *a lot* of compiler
work: it has to analyze every symbol in the class to find out
whether it must be part of the "uninstantiated" base or not. And
this kind of analysis may not be easy (it may be masked by the
use of traits, template mixins, string mixins and so on). Even
humans can easily get it wrong (see my previous example).
Also, I thought of other problems:
- Interaction with non-class templates: how should they behave?
Or are we just introducing a special case for class templates?
(Special cases are very bad, we should limit them).
- Interaction with base classes and interfaces: how is this
"uninstantiated base class" inserted into the graph of classes
and interfaces? Are interfaces considered implemented by this
base class? Is this base class inserted between the templated
class and the "original" base class?
Re: How about a special null template parameter?
On Friday, 19 August 2016 at 18:25:06 UTC, Engine Machine wrote:
So we can create types relationships easier:
class Type(T) : Type!null
{
int x;
static if (T is Dog)
int y;
}
Type == Type!null (!null implicit, only if defined in the above
way. Essentially an alias is created for us automatically)
Type(T) : Type!nullinherits only if T is not null(or a type
that inherits from itself, which would then be valid).
Type!Dog inherits from Type/Type!null.
Type!T inherits from Type/Type!null as long as T != null.
Members in base(null) are not re-included in derived(e.g., int
x; isn't include in Type!Dog because it's already there from
base).
Something like this:
class Type(T: typeof(null)) { //< L1 (specialization)
int x;
}
class Dog {}
class Type(T) : Type!(typeof(null)) { //< L2 (`typeof(null)`)
static if(is(T: Dog)) //< L3 (`is(MyType: IntendedType)` or
`is(MyType == ExactType)`)
int y;
}
What you're looking for is "specialization", on line "L1". Also
some corrections on lines "L2" and "L3"
Re: How about a special null template parameter?
On Friday, 19 August 2016 at 21:07:42 UTC, Timon Gehr wrote:
On 19.08.2016 20:25, Engine Machine wrote:
So we can create types relationships easier:
class Type(T) : Type!null
{
int x;
static if (T is Dog)
int y;
alias Seq(T...)=T;
template TypeParent(T...) if(T.length==1){
static if(is(typeof(T[0])==typeof(null))) alias TypeParent
= Seq!();
else alias TypeParent = Seq!(Type!null);
}
class Type(T...): TypeParent!T if(T.length==1){
int x;
static if (T is Dog)
int y;
}
This is a bit verbose and not quite right (T is Dog should be
something like T[0], or whatever).
It does essentially work. My only complaint is that it would be
nice to be able to export an alias to Type!() = Type; in the
namespace of the type being created. Doubt that D can do that!?
If it can, then it should be an adequate solution.
That is
It would be nice to have something like
alias Type = Type!();
class Type(T...): TypeParent!T if(T.length==1){
int x;
static if (T is Dog)
int y;
}
Again, I don't think D will allow this.
alias Seq(T...)=T;
template TypeParent(T...) {
static if(is(typeof(T[0])==typeof(null))) alias TypeParent =
Seq!();
else alias TypeParent = Seq!(Type!null);
}
class Type(T...) : TypeParent!T
{
int x;
static if(T.length == 1)
{
static if (T[0] is Dog)
int y;
}
}
(note I removed the length checks, so we can create the base type
and such)
I guess a such a method is nice to create compound types though:
Type!(Animal, Dog, Chihuahua)
and have a inheritance chain.
e.g.,
class Type(T...) : TypeParent!T
{
int x;
static if(T.length >= 1)
{
static if (T[0] is "Animal")
{
int z;
static if (T[1] is "Dog")
int y;
}
}
}
void main()
{
Type!("Animal", "Dog") t;
}
I don't know if all this obeys inheritance though but it looks
like it should.
Thanks!
Re: Why D is not popular enough?
On 8/19/2016 8:19 AM, Adam D. Ruppe wrote: You're working with float anyway, so I believe the price is paid even by today's C rules. Nope, the operands of integral sub-expressions are not promoted to float. The intermediates might be different though, I'm not sure.
Re: How about a special null template parameter?
On Friday, 19 August 2016 at 19:19:35 UTC, Lodovico Giaretta
wrote:
On Friday, 19 August 2016 at 18:25:06 UTC, Engine Machine wrote:
So we can create types relationships easier:
class Type(T) : Type!null
{
int x;
static if (T is Dog)
int y;
}
Type == Type!null (!null implicit, only if defined in the
above way. Essentially an alias is created for us
automatically)
Type(T) : Type!nullinherits only if T is not null(or a type
that inherits from itself, which would then be valid).
Type!Dog inherits from Type/Type!null.
Type!T inherits from Type/Type!null as long as T != null.
Members in base(null) are not re-included in derived(e.g., int
x; isn't include in Type!Dog because it's already there from
base).
This simple syntactic sugar allows us to create multiple
classes to create simple inheritance hierarchy.
It replaces the current method of having to define a
non-templated class and a templated class.
e.g.,
class Type
{
int x;
}
class Type(T) : Type
{
static if (T is Dog)
int y;
}
vs
class Type(T) : Type!null
{
int x;
static if (T is Dog)
int y;
}
1) `null` has a very precise meaning: it is the only valid
value of an unnamed type only known as `typeof(null)`, which
implicitly converts to any class/pointer/dynamic
array/associative array type. Thus this thing should have a
different name.
null as many interpretations. It is ok to expand the meaning. It
is done all the time. If it confuses you are creates a semantic
difficulty, I don't mind what it is called. It could be called
Boomfurkasufasdf.
In this case, defining it to be null fits in semantically though.
If it creates some compiler issue then, again, anything else
could be used. I'd prefer Null or NULL or Aleph or something
short and meaningless.
2) What about this case:
```
class Type(T): Type
{
static if (T is Dog)
int y;
else
float z;
}
```
What should be inside the base?
z.
3) I guess that you may find this useful to write functions
that accept any type this way:
```
void myFunction(Type val)
{
// only use fields in common between all Type instantiations
}
```
But you can already do that this way, which is way more
flexible:
```
void myFunction(T)(Type!T val)
{
// use fields in common between all instantiation,
// but also fields specific to a certain instantiation,
// using static if
}
```
Well, that is not really what I'm after. I am after simplifying
class design.
4) I think that the value of this addition is little wrt. the
amount of work the compiler should do to implement it (which at
first sight would be a lot). But this is of course just my
opinion.
It is just syntactic sugar and requires no complex compiler
modifications. The benefit is reduced visual complexity and that
is always a bonus. That is the point we don't write in 0's and
1's... everything else is just syntactic sugar. In this case, it
is a very simple rewrite rule. A few lines of code would be all
that is required.
Re: Why D is not popular enough?
On 8/18/2016 7:59 PM, Adam D. Ruppe wrote: Alas, C insisted on making everything int all the time and D followed that :( One would have to be *really* sure of their ground in coming up with allegedly better rules.
Re: How about a special null template parameter?
On Friday, 19 August 2016 at 19:13:10 UTC, Jack Applegame wrote:
On Friday, 19 August 2016 at 18:25:06 UTC, Engine Machine wrote:
It replaces the current method of having to define a
non-templated class and a templated class.
e.g.,
class Type
{
int x;
}
class Type(T) : Type
{
static if (T is Dog)
int y;
}
What are you talking about? This code doesn't compile. Because
you can't define a class and a template with the same name.
It doesn't matter. That is just a defect of D/language.
If it confuses you, call it Type_Special_X, or, if that confuses
you, call it something else. Don't get caught up in the words old
padawan.
Re: How about a special null template parameter?
On 19.08.2016 20:25, Engine Machine wrote:
So we can create types relationships easier:
class Type(T) : Type!null
{
int x;
static if (T is Dog)
int y;
alias Seq(T...)=T;
template TypeParent(T...) if(T.length==1){
static if(is(typeof(T[0])==typeof(null))) alias TypeParent = Seq!();
else alias TypeParent = Seq!(Type!null);
}
class Type(T...): TypeParent!T if(T.length==1){
int x;
static if (T is Dog)
int y;
}
std.datetime: converting AM/PM to 24 hour format
Not that it's hard to do, but would be nice to have this in std.datetime, just ran into some data that was using AM/PM. eg: if(AMPM == "PM" && hours<12) hours = hours+12; if(AMPM == "AM" && hours==12) hours = hours-12;
Re: How about a special null template parameter?
On Friday, 19 August 2016 at 18:25:06 UTC, Engine Machine wrote:
So we can create types relationships easier:
class Type(T) : Type!null
{
int x;
static if (T is Dog)
int y;
}
Type == Type!null (!null implicit, only if defined in the above
way. Essentially an alias is created for us automatically)
Type(T) : Type!nullinherits only if T is not null(or a type
that inherits from itself, which would then be valid).
Type!Dog inherits from Type/Type!null.
Type!T inherits from Type/Type!null as long as T != null.
Members in base(null) are not re-included in derived(e.g., int
x; isn't include in Type!Dog because it's already there from
base).
This simple syntactic sugar allows us to create multiple
classes to create simple inheritance hierarchy.
It replaces the current method of having to define a
non-templated class and a templated class.
e.g.,
class Type
{
int x;
}
class Type(T) : Type
{
static if (T is Dog)
int y;
}
vs
class Type(T) : Type!null
{
int x;
static if (T is Dog)
int y;
}
1) `null` has a very precise meaning: it is the only valid value
of an unnamed type only known as `typeof(null)`, which implicitly
converts to any class/pointer/dynamic array/associative array
type. Thus this thing should have a different name.
2) What about this case:
```
class Type(T): Type
{
static if (T is Dog)
int y;
else
float z;
}
```
What should be inside the base?
3) I guess that you may find this useful to write functions that
accept any type this way:
```
void myFunction(Type val)
{
// only use fields in common between all Type instantiations
}
```
But you can already do that this way, which is way more flexible:
```
void myFunction(T)(Type!T val)
{
// use fields in common between all instantiation,
// but also fields specific to a certain instantiation,
// using static if
}
```
4) I think that the value of this addition is little wrt. the
amount of work the compiler should do to implement it (which at
first sight would be a lot). But this is of course just my
opinion.
Re: How about a special null template parameter?
On Friday, 19 August 2016 at 18:25:06 UTC, Engine Machine wrote:
It replaces the current method of having to define a
non-templated class and a templated class.
e.g.,
class Type
{
int x;
}
class Type(T) : Type
{
static if (T is Dog)
int y;
}
What are you talking about? This code doesn't compile. Because
you can't define a class and a template with the same name.
How about a special null template parameter?
So we can create types relationships easier:
class Type(T) : Type!null
{
int x;
static if (T is Dog)
int y;
}
Type == Type!null (!null implicit, only if defined in the above
way. Essentially an alias is created for us automatically)
Type(T) : Type!nullinherits only if T is not null(or a type that
inherits from itself, which would then be valid).
Type!Dog inherits from Type/Type!null.
Type!T inherits from Type/Type!null as long as T != null.
Members in base(null) are not re-included in derived(e.g., int x;
isn't include in Type!Dog because it's already there from base).
This simple syntactic sugar allows us to create multiple classes
to create simple inheritance hierarchy.
It replaces the current method of having to define a
non-templated class and a templated class.
e.g.,
class Type
{
int x;
}
class Type(T) : Type
{
static if (T is Dog)
int y;
}
vs
class Type(T) : Type!null
{
int x;
static if (T is Dog)
int y;
}
Re: [OT] of [OT] I am a developer and I hate documentation
On Friday, 19 August 2016 at 15:10:55 UTC, Marco Leise wrote: Guys if you have too much free time, go fix some compiler bugs. :D First we'll have to generate the documentation for it :)
Re: Why D is not popular enough?
On Friday, 19 August 2016 at 15:01:58 UTC, Marco Leise wrote: Float math is slow compared to integer math and precision loss occurs when this rule is also applied to (u)int and (u)long with only the deprecated (as per amd64 spec) real type being large enough for 64-bit integers. You're working with float anyway, so I believe the price is paid even by today's C rules. The intermediates might be different though, I'm not sure.
Re: [OT] of [OT] I am a developer and I hate documentation
On 08/19/2016 02:50 AM, karabuta wrote: >> Sigh. Eventually we're just reinventing Markdown in ddoc. Why can't >> we just use Markdown (with some ddoc extensions) in the first place? >> >> >> T > > That will be way better, don't know why markdown is not used already. There is https://github.com/kiith-sa/harbored-mod which supports markdown in addition to base ddoc. We are actually switching to it as a standard internal documentation generator at Sociomantic. signature.asc Description: OpenPGP digital signature
Re: [OT] of [OT] I am a developer and I hate documentation
Am Fri, 19 Aug 2016 07:34:51 -0700
schrieb "H. S. Teoh via Digitalmars-d"
:
> On Fri, Aug 19, 2016 at 10:50:20AM +, Chris via Digitalmars-d wrote:
> > On Thursday, 18 August 2016 at 17:23:09 UTC, H. S. Teoh wrote:
> > > On Thu, Aug 18, 2016 at 04:56:32PM +, ketmar via Digitalmars-d
> > > wrote:
> > > > On Thursday, 18 August 2016 at 16:17:15 UTC, H. S. Teoh wrote:
> > > > > if the stub reads:
> > > > > > /**
> > > > >* THE PROGRAMMER WAS TOO LAZY TO FILL THIS IN
> > > > >* Params:
> > > > >* x = THE PROGRAMMER WAS TOO LAZY TO FILL THIS IN
> > > > >* y = THE PROGRAMMER WAS TOO LAZY TO FILL THIS IN
> > > > >* Returns: THE PROGRAMMER WAS TOO LAZY TO FILL THIS IN
> > > > >*/
> > > > > int myFunc(int x, int y) { ... }
> > > > > > :-P
> > > > i assure you that programmers will still be too lazy to fill the
> > > > docs. but they *will* spend alot of time rebuilding (or
> > > > hex-editing if there is no source) their IDE to replace the
> > > > message.
> > >
> > > Haha, too true!
> > >
> > >
> > > T
> >
> > It is true. After all, it's all about writing code and hacking. "Look
> > now it says 'THE PROGRAMMER IS COOL'! It only took me 3 hours to
> > figure out how to replace the message. I'll write a blog about it! =>
> > reddit => flame war => please mark as OT ..."
> [...]
>
> And if the pro-doc-ers are equally "cool", there would be an arms race
> where the stub is encrypted with strong encryption to prevent tampering,
> and the programmers would figure out ways of bypassing it, and develop
> an entire subculture of IDE-cracking and doc avoidance. :-P
>
>
> T
>
Guys if you have too much free time, go fix some compiler
bugs. :D
--
Marco
Re: Why D is not popular enough?
Am Fri, 19 Aug 2016 13:36:05 + schrieb Adam D. Ruppe : > On Friday, 19 August 2016 at 08:31:39 UTC, Marco Leise wrote: > > If we hypothetically switched to a ubyte+ubyte=ubyte semantic, > > then code like this breaks silently: > > However, if it took the entire statement into account, it could > handle that... by my rule, it would see there's a float in there > and thus automatically cast a and b to float before doing > anything. Float math is slow compared to integer math and precision loss occurs when this rule is also applied to (u)int and (u)long with only the deprecated (as per amd64 spec) real type being large enough for 64-bit integers. -- Marco
Re: [OT] of [OT] I am a developer and I hate documentation
On Fri, Aug 19, 2016 at 10:50:20AM +, Chris via Digitalmars-d wrote:
> On Thursday, 18 August 2016 at 17:23:09 UTC, H. S. Teoh wrote:
> > On Thu, Aug 18, 2016 at 04:56:32PM +, ketmar via Digitalmars-d
> > wrote:
> > > On Thursday, 18 August 2016 at 16:17:15 UTC, H. S. Teoh wrote:
> > > > if the stub reads:
> > > > > /**
> > > > * THE PROGRAMMER WAS TOO LAZY TO FILL THIS IN
> > > > * Params:
> > > > * x = THE PROGRAMMER WAS TOO LAZY TO FILL THIS IN
> > > > * y = THE PROGRAMMER WAS TOO LAZY TO FILL THIS IN
> > > > * Returns: THE PROGRAMMER WAS TOO LAZY TO FILL THIS IN
> > > > */
> > > > int myFunc(int x, int y) { ... }
> > > > > :-P
> > > i assure you that programmers will still be too lazy to fill the
> > > docs. but they *will* spend alot of time rebuilding (or
> > > hex-editing if there is no source) their IDE to replace the
> > > message.
> >
> > Haha, too true!
> >
> >
> > T
>
> It is true. After all, it's all about writing code and hacking. "Look
> now it says 'THE PROGRAMMER IS COOL'! It only took me 3 hours to
> figure out how to replace the message. I'll write a blog about it! =>
> reddit => flame war => please mark as OT ..."
[...]
And if the pro-doc-ers are equally "cool", there would be an arms race
where the stub is encrypted with strong encryption to prevent tampering,
and the programmers would figure out ways of bypassing it, and develop
an entire subculture of IDE-cracking and doc avoidance. :-P
T
--
Never trust an operating system you don't have source for! -- Martin Schulze
Re: [OT] of [OT] I am a developer and I hate documentation
On Friday, 19 August 2016 at 02:52:54 UTC, Adam D. Ruppe wrote: Yeah. I'm being a bit facetious there: I actually already did it and the result is on my dpldocs.info site. There's still a few rough edges that I'm working on slowly but surely, but the bulk of the work has been done for a while. I remember looking at this before and thinking those docs looked really good.
Re: Why D is not popular enough?
On Friday, 19 August 2016 at 08:31:39 UTC, Marco Leise wrote: If we hypothetically switched to a ubyte+ubyte=ubyte semantic, then code like this breaks silently: However, if it took the entire statement into account, it could handle that... by my rule, it would see there's a float in there and thus automatically cast a and b to float before doing anything. The compiler would parse Assign(float, Multiply(float, Parenthetical(Add(a, b In a semantic transformation step, it would see that since the lhs is float, the rhs is now casted to float, then it does that recursively through it all and a and b get promoted to float so the bits are never lost. I really do think that would work. Alas, I don't see D ever changing anyway, this is too deep in its C bones.
Re: [OT] of [OT] I am a developer and I hate documentation
On Thursday, 18 August 2016 at 17:23:09 UTC, H. S. Teoh wrote:
On Thu, Aug 18, 2016 at 04:56:32PM +, ketmar via
Digitalmars-d wrote:
On Thursday, 18 August 2016 at 16:17:15 UTC, H. S. Teoh wrote:
> if the stub reads:
>
> /**
> * THE PROGRAMMER WAS TOO LAZY TO FILL THIS IN
> * Params:
> * x = THE PROGRAMMER WAS TOO LAZY TO FILL THIS IN
> * y = THE PROGRAMMER WAS TOO LAZY TO FILL THIS IN
> * Returns: THE PROGRAMMER WAS TOO LAZY TO FILL THIS IN
> */
>int myFunc(int x, int y) { ... }
>
> :-P
i assure you that programmers will still be too lazy to fill
the docs. but they *will* spend alot of time rebuilding (or
hex-editing if there is no source) their IDE to replace the
message.
Haha, too true!
T
It is true. After all, it's all about writing code and hacking.
"Look now it says 'THE PROGRAMMER IS COOL'! It only took me 3
hours to figure out how to replace the message. I'll write a blog
about it! => reddit => flame war => please mark as OT ..."
But it is like everything else: nice to have, even if you don't
use it _all the time_.
Re: Why D is not popular enough?
Am Mon, 15 Aug 2016 10:54:11 -0700
schrieb Ali Çehreli :
> On 08/14/2016 07:07 AM, Andrei Alexandrescu wrote:
> > On 08/14/2016 01:18 AM, Shachar Shemesh wrote:
>
> >> Also, part of our
> >> problems with this is that introspection also does not see refs, which
> >> causes the following two functions to report the same signature:
> >>
> >> void func1(int arg);
> >> void func2(ref int arg);
> >
> > I actually think you can do introspection on any argument to figure
> > whether it has "ref".
>
> Yes, it exists. However, I tried std.traits.Parameters but that wasn't
> it. A colleague reminded us that it's std.traits.ParameterStorageClassTuple:
>
>http://dlang.org/phobos/std_traits.html#ParameterStorageClassTuple
>
> Ali
>
In fact, std.traits.Parameters _retains_ ref as long as you
don't unpack the tuple:
void foo(ref int);
void bar(Parameters!foo args);
'bar' is now "void function(ref int)"
You can then access 'args.length' and 'args[n]' to get at each
argument or pass 'args' on as is to the next function.
You can also create a ref argument for 'T' out of thin air by
writing:
alias RefArg = Parameters!((ref T) {});
Just remember that 'RefArg' is again a tuple and you
always need to access args[0] to use it.
--
Marco
Re: Why D is not popular enough?
Am Thu, 18 Aug 2016 22:50:27 + schrieb John Smith : > Well you could say the same for the same for int. Why isn't "int > + int = long"? Right now it is following the rule "int + int = > int". I believe in C, int reflects the native machine word that the CPU always uses to perform arithmetics. Together with undefined overflow behavior (due to allowing different HW implementations) of signed types I suppose it was the best bet to at least widen smaller types to that type. Even on today's amd64 CPUs int/uint remain the most efficient integral type for multiplication and division. If we hypothetically switched to a ubyte+ubyte=ubyte semantic, then code like this breaks silently: ubyte a = 210; ubyte b = 244; float f = 1.1 * (a + b); Or otherwise instead of casting uints to ubytes you now start casting ubytes to uints all over the place. What we have is the guarantee that the result will reliably be at least 32-bit in D. -- Marco
Re: [OT] of [OT] I am a developer and I hate documentation
On Friday, 19 August 2016 at 02:52:54 UTC, Adam D. Ruppe wrote: Yeah. I'm being a bit facetious there: I actually already did it and the result is on my dpldocs.info site. There's still a few rough edges that I'm working on slowly but surely, but the bulk of the work has been done for a while. Haven't look at it for a while, but you did a pretty good job! Any chance of it becoming official?
