Another of those billion dollar mistakes D2 will not be able to avoid!
http://www.microsoft.com/technet/security/advisory/979352.mspx
>Our investigation so far has shown that Internet Explorer 5.01 Service Pack 4
>on Microsoft Windows 2000 Service Pack 4 is not affected, and that Internet
>Expl
Tim Matthews:
> The article points out "going beyond haskell" with maybe as a
> generator. I don't get this bit because in haskell all lists are monads
> and a single element list is just like the 'maybe' so this can be done
> already and empty lists can be pattern matched on if the extra
> assuran
Walter Bright:
> Also, if you're only writing a few K of code, D's advantages aren't that
> compelling over C (and neither are C++'s). It's when the size of the
> program increases that D's strengths really begin to dominate.
I don't agree at all. D is (and has to be) fitter for short programs t
On Mon, 18 Jan 2010 12:04:15 -0500
bearophile wrote:
> Just found this blog page. Fortress is a language quite different
> from D because it tries to be innovative (while D tries to be mostly
> a collection of well known good solutions) but it author Guy Steele
> is a good language designer, so s
bearophile wrote:
> This discussion clearly shows that the current semantics of the "auto" is not
> clean enough and it needs to be improved.
> To improve it D needs to adopt the strategy of using all attributes in a more
> tidy and semantically clean way, as Java does. Java doesn't compile "use
Lars T. Kyllingstad wrote:
> retard wrote:
>> Mon, 18 Jan 2010 19:43:54 +, BCS wrote:
>>
>>> It might be a case of NIH, but that doesn't handle fractional units (for
>>> example MPa*m^1/2 is used in fracture mechanics and I suspect that they
>>> are fairly common as intermediate values in solvi
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
> Also, if you're only writing a few K of code, D's advantages aren't that
> compelling over C (and neither are C++'s). It's when the size of the
> program increases that D's strengths really begin to dominate.
For small proj
On Mon, Jan 18, 2010 at 4:25 PM, Walter Bright
wrote:
> Denis Koroskin wrote:
>>
>> What do you think? I understand it is unlikely to make its way into D2
>> (D3?), but is it sound? Do you think it's useless, or do you think that
>> additional consistency (and functionality) is worthwhile?
>
> Wha
Hello Walter,
Denis Koroskin wrote:
What do you think? I understand it is unlikely to make its way into
D2 (D3?), but is it sound? Do you think it's useless, or do you think
that additional consistency (and functionality) is worthwhile?
What this means is that classes will be usable as a val
Denis Koroskin wrote:
What do you think? I understand it is unlikely to make its way into D2
(D3?), but is it sound? Do you think it's useless, or do you think that
additional consistency (and functionality) is worthwhile?
What this means is that classes will be usable as a value type, like in
On 01/18/2010 11:31 PM, Walter Bright wrote:
Jérôme M. Berger wrote:
Embedded x86 is an oxymoron. Yes, I know, it exists (and btw, 8
years ago they were still selling 486s as "embedded" processors) but
mostly it doesn't need any special support (except possibly on the
binary size front and even
dsimcha wrote:
This is a great point and deserves to be highlighted: D was meant to be a
better
C++, not a better C. If someone won't use C++ instead of C (apparently there
are
a decent amount of these people), then there's not a snowball's chance in hell
they'd use D, even if we fixed the bi
Jérôme M. Berger wrote:
Andrei Alexandrescu wrote:
Andrei Alexandrescu wrote:
Nick Sabalausky wrote:
[snip]
It's been no worse at threading than C/C++ for quite some time. It's
just starting to have a threading model that kicks the crap out of
the threading in the vast majority of languages ou
I was playing with D's function pointers and immutability and ran into
some trouble. It's probably because function pointers are treated just
like data pointers when it comes to immutability. To mend this, function
pointers should be treated as values. It may sound odd but makes sense --
yo
== Quote from "J�r�me_M._Berger" (jeber...@free.fr)'s article
> PS: At work, we mustn't use C++ because:
> - It's slow;
> - Its standard library is too big (100k);
> - In a future product, we might want to reuse this module and not
> have C++ (Oh, yes I didn't tell you that we *do* have the C++ std
Jérôme M. Berger wrote:
Embedded x86 is an oxymoron. Yes, I know, it exists (and btw, 8
years ago they were still selling 486s as "embedded" processors) but
mostly it doesn't need any special support (except possibly on the
binary size front and even there 80k is nothing to the XXX megaby
Bill Baxter Wrote:
> On Mon, Jan 18, 2010 at 12:44 PM, Eldar Insafutdinov
> wrote:
> > Denis Koroskin Wrote:
> >
> >> You know, I'm not usually a guy who proposes radical changes to the
> >> language. I like the way D is, but there are a few proposals that keep
> >> popping up once in a while wit
Walter Bright:
> Yes, but it would break every other line of code already written in D.<
Is this a lot of D2 code? How much time does it need?
Bye,
bearophile
bearophile Wrote:
> myself). If this is true then a syntax like:
> auto immutable x = y * 2;
>
> can be seen as too much long and boring to write all the time, so the
> "immutable" keyword may need to be changed again :-) For example into "val"
> (also as "retard" has said), so it becomes short
Andrei Alexandrescu wrote:
> Andrei Alexandrescu wrote:
>> Nick Sabalausky wrote:
>> [snip]
>>> It's been no worse at threading than C/C++ for quite some time. It's
>>> just starting to have a threading model that kicks the crap out of
>>> the threading in the vast majority of languages out there.
Walter Bright wrote:
> Nick Sabalausky wrote:
>> Right, but like I had said below that, D isn't really usable for
>> embedded ATM, so until that happens (and I'm *really* anxious to see
>> that happen), D is still desktop-only, and even on the lowest-end
>> desktops 80k is nothing.
>
> I didn't kn
Sean Kelly:
> Fortunately, the "auto" keyword can be left out.<
The point of my post was that I think that's bad. And I have tried to explain
why.
Bye,
bearophile
Hello retard,
I also have a Core i7. Jeff Atwood has one
(http://www.codinghorror.com/ blog/archives/001316.html) - and he
represents the average Joe Six-pack developer.
That's fine as long as you are writing code for developers. If you are writing
code for users (the other 599M people in the
Hello bearophile,
BCS:
http://www.dsource.org/projects/scrapple/browser/trunk/units
With a little more compiler support to improve the syntax this stuff
can be more usable.
Is the usage of units common enough and important enough to deserve a
bit of compiler/language support? (I don't know
bearophile Wrote:
> Walter Bright:
> > Andrei introduced me to that style, and I'm starting to use it more and
> > more. I like it for the reasons you state.
>
> I'm not using it because I'm not using D2 much yet, but I have read that a
> good number of people are adopting that style in other l
On Mon, Jan 18, 2010 at 12:44 PM, Eldar Insafutdinov
wrote:
> Denis Koroskin Wrote:
>
>> You know, I'm not usually a guy who proposes radical changes to the
>> language. I like the way D is, but there are a few proposals that keep
>> popping up once in a while without a good rationale, and this si
On Mon, 18 Jan 2010 15:35:17 -0500, dsimcha wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
Leandro Lucarella wrote:
> Do you remember when people asked for default immutability? I do :)
Yes, but it would break every other line of code already written in D.
> I like t
"Walter Bright" wrote in message
news:hj2ef2$4e...@digitalmars.com...
> Nick Sabalausky wrote:
>> Right, but like I had said below that, D isn't really usable for embedded
>> ATM, so until that happens (and I'm *really* anxious to see that happen),
>> D is still desktop-only, and even on the lo
Denis Koroskin Wrote:
> You know, I'm not usually a guy who proposes radical changes to the
> language. I like the way D is, but there are a few proposals that keep
> popping up once in a while without a good rationale, and this simple idea
> stroke my head solves many of the issues that wer
BCS wrote:
Hello bearophile,
Daniel:
I also kind of hoped we'd see standard real world unit types in D.<
A mostly std lib solution can be acceptable,
Here's my (compile time) run at this:
http://www.dsource.org/projects/scrapple/browser/trunk/units
I'd be happy to fix up the ownership/l
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
> Leandro Lucarella wrote:
> > Do you remember when people asked for default immutability? I do :)
> Yes, but it would break every other line of code already written in D.
> > I like the idea of making x := y an alias for immutable
On Mon, 18 Jan 2010 15:08:56 -0500, Lars T. Kyllingstad
wrote:
Steven Schveighoffer wrote:
I think conversion from a reference to a pointer should be available
via a cast, but I'm not sure whether the compiler should allow class
pointers. My gut feeling is no.
Isn't this already possib
On Mon, 18 Jan 2010 21:08:57 +0300, Trass3r wrote:
How is that confusing to people with a C background?
Foo* foo = new Foo;
would make people think foo is a pointer to an instance of Foo, not a
reference.
What's the difference?
Furthermore it would be inconsistent with normal pointers
Steven Schveighoffer wrote:
On Mon, 18 Jan 2010 13:35:01 -0500, Bill Baxter wrote:
I think one can argue it would be better for pointer arithmetic to
require a more in-your-face notation, since pointer arithmetic isn't
usually needed and won't even be allowed in SafeD.
It isn't really standar
Leandro Lucarella wrote:
Do you remember when people asked for default immutability? I do :)
Yes, but it would break every other line of code already written in D.
I like the idea of making x := y an alias for immutable x = y (or even
enum x = y). That would make this style much more attract
retard wrote:
Mon, 18 Jan 2010 19:43:54 +, BCS wrote:
Hello Walter,
Daniel wrote:
I also kind of hoped we'd see standard real world unit types in D.
Like sqft, meters, ohms, kg, L, Hz, seconds,
etc. native to D. Being able to intrinsically convert types between
these things would make
Nick Sabalausky wrote:
I can totally accept that 486 in particular is pretty much dead, but unless
there's some specific advantage that can be only be gained by breaking 486
support, I see no reason for "It supports 486" to be something worth whining
about.
The compiler does a pretty good job
Nick Sabalausky wrote:
Right, but like I had said below that, D isn't really usable for embedded
ATM, so until that happens (and I'm *really* anxious to see that happen), D
is still desktop-only, and even on the lowest-end desktops 80k is nothing.
I didn't know you were an embedded systems dev
Mon, 18 Jan 2010 19:43:54 +, BCS wrote:
> Hello Walter,
>
>> Daniel wrote:
>>
>>> I also kind of hoped we'd see standard real world unit types in D.
>>> Like sqft, meters, ohms, kg, L, Hz, seconds,
>>>
>>> etc. native to D. Being able to intrinsically convert types between
>>> these things
On Mon, 18 Jan 2010 13:35:01 -0500, Bill Baxter wrote:
I think one can argue it would be better for pointer arithmetic to
require a more in-your-face notation, since pointer arithmetic isn't
usually needed and won't even be allowed in SafeD.
It isn't really standard arithmetic to begin with, s
Hello Walter,
Daniel wrote:
I also kind of hoped we'd see standard real world unit types in D.
Like sqft, meters, ohms, kg, L, Hz, seconds,
etc. native to D. Being able to intrinsically convert types between
these things would make D the most
approachable General Programming Language for re
"downs" wrote in message
news:hj1m0r$1k3...@digitalmars.com...
> Justin Johansson wrote:
>> Happy New Year 2010 Everybody.
>>
>> Having resumed C++ nationality for the last few months, I kind of miss
>> D's auto keyword.
>>
>
> If you're on gcc or a compiler that allows the typeof extension:
>
>
"retard" wrote in message
news:hj1hfe$1bp...@digitalmars.com...
> Mon, 18 Jan 2010 02:05:14 -0500, Nick Sabalausky wrote:
>
>> "Daniel" wrote in message
>> news:hj0pvc$2si...@digitalmars.com...
>>>
>>>
>> Haven't we already had enough posts about "I don't like D2 because it
>> doesn't add *enoug
On Mon, Jan 18, 2010 at 9:30 AM, Steven Schveighoffer
wrote:
> On Mon, 18 Jan 2010 12:12:06 -0500, Steven Schveighoffer
> wrote:
>
>> I think we are too late for D2, the book is pretty much finished except
>> for the concurrency chapter. It is a great idea though, I would have loved
>> to see th
Denis Koroskin wrote:
You know, I'm not usually a guy who proposes radical changes to the
language. I like the way D is, but there are a few proposals that keep
popping up once in a while without a good rationale, and this simple
idea stroke my head solves many of the issues that were found in
Leandro Lucarella Wrote:
> Walter Bright, el 17 de enero a las 14:45 me escribiste:
> > dsimcha wrote:
> > >Furthermore, I think that less verbosity encourages good practices. I've
> > >gotten
> > >into the habit of declaring all my stack variables immutable when writing a
> > >function, unless
How is that confusing to people with a C background?
Foo* foo = new Foo;
would make people think foo is a pointer to an instance of Foo, not a
reference.
Furthermore it would be inconsistent with normal pointers (int*, ...)
On Mon, 18 Jan 2010 12:12:06 -0500, Steven Schveighoffer
wrote:
I think we are too late for D2, the book is pretty much finished except
for the concurrency chapter. It is a great idea though, I would have
loved to see this happen before D2 was released. Maybe D3 can have this
change.
Andrei Alexandrescu wrote:
Nick Sabalausky wrote:
[snip]
It's been no worse at threading than C/C++ for quite some time. It's
just starting to have a threading model that kicks the crap out of the
threading in the vast majority of languages out there.
BTW, that effort is going quite well. For
On Mon, 18 Jan 2010 11:17:53 -0500, Michel Fortin
wrote:
On 2010-01-18 10:08:34 -0500, "Denis Koroskin" <2kor...@gmail.com> said:
It's as simple as that: require '*' to denote reference type. What does
it give?
It works like that in Objective-C where object variables must always be
po
Just found this blog page. Fortress is a language quite different from D
because it tries to be innovative (while D tries to be mostly a collection of
well known good solutions) but it author Guy Steele is a good language
designer, so some of the ideas of Fortress are nice. This post is about th
On 2010-01-18 10:50:58 -0500, Trass3r said:
Using * would heavily confuse people coming from C.
I like the way it is now, class being reference and struct a value type.
I don't follow this reasoning. C has pointers. D has pointers and
reference types (objects). If you remove reference types
On 2010-01-18 10:08:34 -0500, "Denis Koroskin" <2kor...@gmail.com> said:
It's as simple as that: require '*' to denote reference type. What does
it give?
It works like that in Objective-C where object variables must always be
pointer to objects (enforced by the compiler), and it's not so bad
Using * would heavily confuse people coming from C.
I like the way it is now, class being reference and struct a value type.
Nick Sabalausky wrote:
[snip]
It's been no worse at threading than C/C++ for quite some time. It's just
starting to have a threading model that kicks the crap out of the threading
in the vast majority of languages out there.
BTW, that effort is going quite well. For example, a producer-consume
(I moved that part to a different letter so that people don't concentrate
on it too much, since it is more controvertial)
What else would it *optionally* provide (subject to discuss, could be
implemented later, because it's an additional functionality that D
currently lacks)?
I stress it
You know, I'm not usually a guy who proposes radical changes to the
language. I like the way D is, but there are a few proposals that keep
popping up once in a while without a good rationale, and this simple idea
stroke my head solves many of the issues that were found in previous
proposals
Walter Bright, el 17 de enero a las 14:45 me escribiste:
> dsimcha wrote:
> >Furthermore, I think that less verbosity encourages good practices. I've
> >gotten
> >into the habit of declaring all my stack variables immutable when writing a
> >function, unless I really need them to be mutable. Thi
Am 18.01.2010, 12:08 Uhr, schrieb Walter Bright
:
Here it is:
// by Oskar Linde Aug 2006
// This is just a quick hack to test
// IFTI operators opMul and opDel
Wow that looks very neat.
Couldn't/Shouldn't that be added to phobos?
Trass3r wrote:
Quoting Andrei in his "Short list with things to finish for D2" post
(2009-11-19):
* Loop fusion that generalizes array-wise operations. This idea of
Walter is, I think, very good because it generalizes and democratizes
"magic". The idea is that, if you do
a = b + c;
and b +
Quoting Andrei in his "Short list with things to finish for D2" post
(2009-11-19):
* Loop fusion that generalizes array-wise operations. This idea of
Walter is, I think, very good because it generalizes and democratizes
"magic". The idea is that, if you do
a = b + c;
and b + c does not m
Justin Johansson wrote:
> Happy New Year 2010 Everybody.
>
> Having resumed C++ nationality for the last few months, I kind of miss D's
> auto keyword.
>
If you're on gcc or a compiler that allows the typeof extension:
#define DECL(A, B) typeof(B) A = B
:)
Mon, 18 Jan 2010 02:05:14 -0500, Nick Sabalausky wrote:
> "Daniel" wrote in message
> news:hj0pvc$2si...@digitalmars.com...
>>
>>
> Haven't we already had enough posts about "I don't like D2 because it
> doesn't add *enough* stuff"? Fuck, people, this shit takes time!
>
>> D still takes 80kb jus
Daniel wrote:
I also kind of hoped we'd see standard real world unit types in D. Like sqft,
meters, ohms, kg, L, Hz, seconds,
etc. native to D. Being able to intrinsically convert types between these
things would make D the most
approachable General Programming Language for real world problem
Nick Sabalausky Wrote:
> "Daniel" wrote in message
> news:hj0pvc$2si...@digitalmars.com...
> >
>
> Haven't we already had enough posts about "I don't like D2 because it
> doesn't add *enough* stuff"? Fuck, people, this shit takes time!
>
> > D still takes 80kb just to print "hello world" to
BCS:
> http://www.dsource.org/projects/scrapple/browser/trunk/units
With a little more compiler support to improve the syntax this stuff can be
more usable.
Is the usage of units common enough and important enough to deserve a bit of
compiler/language support? (I don't know yet what a nice synta
dsimcha wrote:
As a side note, why isn't this allowed? It seems like a perfectly reasonable
thing to have:
float[] c = a[] + b;
create a new array. The semantics of what this would do are unambiguous, it
doesn't interact poorly (or at all) with the rest of the language in any way I
can
think
Trass3r wrote:
As a side note, why isn't this allowed? It seems like a perfectly
reasonable thing to have:
float[] c = a[] + b;
Can't think of any point against it as well.
Add
writeln(a[] + b[])
as a case where one would expect a new array to be created.
Also, see bug 2549
(http://d
Daniel wrote:
I don't think I like D 2.0 over 1.0. Before you all run out to get me some
tissue, I figured I'd explain my
rationale.
[snip]
Things D missed:
cent and ucent should be available via SSE. Over 97% of computers now have it
and I still can't even assign to an
SSE register?
SSE
69 matches
Mail list logo
