On Friday, 23 August 2013 at 03:47:00 UTC, H. S. Teoh wrote:
On Fri, Aug 23, 2013 at 05:06:01AM +0200, Ramon wrote:
On Thursday, 22 August 2013 at 23:59:59 UTC, H. S. Teoh wrote:
Or rather, I *will* be happy as can be once I find a suitable
replacement for a browser. Browsers are by far the
On Thu, Sep 05, 2013 at 11:11:14AM +0200, Chris wrote:
On Friday, 23 August 2013 at 03:47:00 UTC, H. S. Teoh wrote:
On Fri, Aug 23, 2013 at 05:06:01AM +0200, Ramon wrote:
On Thursday, 22 August 2013 at 23:59:59 UTC, H. S. Teoh wrote:
Or rather, I *will* be happy as can be once I find a
On Thu, Sep 05, 2013 at 08:57:51PM +0200, John Colvin wrote:
On Thursday, 5 September 2013 at 18:13:42 UTC, H. S. Teoh wrote:
On Thu, Sep 05, 2013 at 11:11:14AM +0200, Chris wrote:
[...]
I've been testing xombrero for a few days now and I really like it.
It's fast and it's up to most of the
On Thursday, 5 September 2013 at 18:13:42 UTC, H. S. Teoh wrote:
On Thu, Sep 05, 2013 at 11:11:14AM +0200, Chris wrote:
On Friday, 23 August 2013 at 03:47:00 UTC, H. S. Teoh wrote:
On Fri, Aug 23, 2013 at 05:06:01AM +0200, Ramon wrote:
On Thursday, 22 August 2013 at 23:59:59 UTC, H. S. Teoh
On Thursday, 5 September 2013 at 19:17:54 UTC, H. S. Teoh wrote:
On Thu, Sep 05, 2013 at 08:57:51PM +0200, John Colvin wrote:
On Thursday, 5 September 2013 at 18:13:42 UTC, H. S. Teoh
wrote:
On Thu, Sep 05, 2013 at 11:11:14AM +0200, Chris wrote:
[...]
I've been testing xombrero for a few days
On 08/30/2013 01:35 AM, Timon Gehr wrote:
bool isPrime(int x){ return iota(3,x).all!(a=!!(x%a)); }
bool isPrime(int x){ return 1x iota(3,x).all!(a=!!(x%a)); }
On Friday, 30 August 2013 at 08:10:24 UTC, Timon Gehr wrote:
On 08/30/2013 01:35 AM, Timon Gehr wrote:
bool isPrime(int x){ return iota(3,x).all!(a=!!(x%a)); }
bool isPrime(int x){ return 1x iota(3,x).all!(a=!!(x%a)); }
iota(3, to!int(sqrt(x)))
On 26/08/13 18:17, Zach the Mystic wrote:
I'm kind of glad I didn't know this until now. Too much information can get in
the way of a good metaphor, in my opinion!
That one about the boiling frog is a bit dodgy as well ... :-)
On 08/30/2013 11:14 AM, deadalnix wrote:
On Friday, 30 August 2013 at 08:10:24 UTC, Timon Gehr wrote:
On 08/30/2013 01:35 AM, Timon Gehr wrote:
bool isPrime(int x){ return iota(3,x).all!(a=!!(x%a)); }
bool isPrime(int x){ return 1x iota(3,x).all!(a=!!(x%a)); }
iota(3, to!int(sqrt(x)))
On Sun, 25 Aug 2013 17:06:27 +0200
bearophile bearophileh...@lycos.com wrote:
Probably working even more you can make the D entry a bit more
statically safe (eventually you could reach the level of Ada code) but
the amount of work and code becomes excessive, and the resulting D
code becomes
On Thursday, 29 August 2013 at 13:33:52 UTC, Gour wrote:
On Sun, 25 Aug 2013 17:06:27 +0200
bearophile bearophileh...@lycos.com wrote:
Probably working even more you can make the D entry a bit more
statically safe (eventually you could reach the level of Ada
code) but
the amount of work and
On Thursday, 29 August 2013 at 14:13:07 UTC, John Colvin wrote:
This could be a lot more generic than it is. Redesigning
Restricted to hold a pointer to a function that does the check
would be one way.
Sorry, should read Limited not Restricted there
On 29/08/13 16:13, John Colvin wrote:
struct Limited(T, T lower, T upper)
{
T _t;
mixin Proxy!_t; //Limited acts as T (almost)
invariant()
{
enforce(_t = lower _t = upper);
}
this(T t)
{
_t = t;
}
}
Is the invariant() not going to be
Joseph Rushton Wakeling:
Is the invariant() not going to be stripped out at compile time
if you use -release ?
Right. assert is enough there. Use enforce() only in special
cases, when you need it. Better to minimize the usage of
enforce() in library code that has to be called many times.
On Thursday, 29 August 2013 at 14:37:10 UTC, bearophile wrote:
Joseph Rushton Wakeling:
Is the invariant() not going to be stripped out at compile
time if you use -release ?
Right. assert is enough there. Use enforce() only in special
cases, when you need it. Better to minimize the usage of
On Thursday, 29 August 2013 at 14:34:37 UTC, Joseph Rushton
Wakeling wrote:
On 29/08/13 16:13, John Colvin wrote:
struct Limited(T, T lower, T upper)
{
T _t;
mixin Proxy!_t; //Limited acts as T (almost)
invariant()
{
enforce(_t = lower _t = upper);
}
this(T t)
On 29/08/13 16:41, John Colvin wrote:
sadly, yes. We need a release version of them, just like we have enforce and
assert. Unfortunately in this case it won't be a library solution and will need
compiler support.
You missed my recent thread here, then, and the responses ... :-)
I was going to
On Thu, 29 Aug 2013 16:13:06 +0200
John Colvin john.loughran.col...@gmail.com wrote:
just something I whipped up in a few mins:
[...]
Thanks. So, it's possible, but (maybe) it's not as elegant.
Sincerely,
Gour
--
A person is said to be established in self-realization and is called a
yogī
On Thursday, 29 August 2013 at 14:50:58 UTC, Joseph Rushton
Wakeling wrote:
On 29/08/13 16:41, John Colvin wrote:
sadly, yes. We need a release version of them, just like we
have enforce and
assert. Unfortunately in this case it won't be a library
solution and will need
compiler support.
On 29/08/13 17:03, John Colvin wrote:
opDispatch isn't enough, you need to add to all the operators too. Shouldn't be
too hard.
Ahh, you mean all the other op*'s? :-)
I guess as you say not hard, I find it a shame that it seems quite finnicky and
there is quite a lot of manual work involved.
W dniu 29.08.2013 15:33, Gour pisze:
On Sun, 25 Aug 2013 17:06:27 +0200
bearophile bearophileh...@lycos.com wrote:
Probably working even more you can make the D entry a bit more
statically safe (eventually you could reach the level of Ada code) but
the amount of work and code becomes
On Thursday, 29 August 2013 at 14:50:18 UTC, Gour wrote:
On Thu, 29 Aug 2013 16:13:06 +0200
John Colvin john.loughran.col...@gmail.com wrote:
just something I whipped up in a few mins:
[...]
Thanks. So, it's possible, but (maybe) it's not as elegant.
Now, let's be fair. While the point
Piotr Szturmaj:
These are refinement types (I call them 'views') and I have
half-written DIP for this. However, I doubt that it will be
accepted.
I'll be quite interested by such DIP. Even if your DIP will be
refused, it could still produce several useful consequences.
Bye,
bearophile
On 08/29/2013 09:17 PM, bearophile wrote:
Piotr Szturmaj:
These are refinement types (I call them 'views') and I have
half-written DIP for this. However, I doubt that it will be accepted.
I'll be quite interested by such DIP. Even if your DIP will be refused,
it could still produce several
On Monday, 26 August 2013 at 18:33:55 UTC, Zach the Mystic wrote:
On Monday, 26 August 2013 at 09:29:18 UTC, Chris wrote:
I don't agree. I first used D exactly because it is an
all-rounder. For me built-in UTF support was as important a
factor as native machine code (performance). The reasons
On Sunday, 25 August 2013 at 23:26:19 UTC, Ramon wrote:
But then, maybe D's beauty in part lies in the fact that it
offers a lot regarding safety/reliabilty - and - very nice
performance, too ;)
One of the theories as to why there are no bears to be found on
the African continent is that
On Monday, 26 August 2013 at 07:32:53 UTC, Zach the Mystic wrote:
On Sunday, 25 August 2013 at 23:26:19 UTC, Ramon wrote:
But then, maybe D's beauty in part lies in the fact that it
offers a lot regarding safety/reliabilty - and - very nice
performance, too ;)
One of the theories as to why
On 26/08/13 09:32, Zach the Mystic wrote:
One of the theories as to why there are no bears to be found on the African
continent is that they are omnivores - i.e. generalists - which in a hugely
competitive environment such as Africa, there is no niche in which they will not
be beat out by a more
On Monday, 26 August 2013 at 08:01:51 UTC, deadalnix wrote:
On Monday, 26 August 2013 at 07:32:53 UTC, Zach the Mystic
wrote:
On Sunday, 25 August 2013 at 23:26:19 UTC, Ramon wrote:
But then, maybe D's beauty in part lies in the fact that it
offers a lot regarding safety/reliabilty - and -
On 26/08/13 10:01, deadalnix wrote:
Human come from Africa. You'll a significant amount of monkey as well.
With the caveat that I'm not an evolutionary biologist, palaeontologist or other
appropriate expert, I'd be surprised if generalism vs. specificity was _the_
reason for the lack of
On Monday, 26 August 2013 at 07:32:53 UTC, Zach the Mystic wrote:
One of the theories as to why there are no bears to be found on
the African continent is that they are omnivores - i.e.
generalists - which in a hugely competitive environment such as
Africa, there is no niche in which they
Zach the Mystic:
One of the theories as to why there are no bears to be found on
the African continent is that they are omnivores - i.e.
generalists - which in a hugely competitive environment such as
Africa, there is no niche in which they will not be beat out by
a more specifically adapted
On Monday, 26 August 2013 at 08:18:02 UTC, Joseph Rushton
Wakeling wrote:
There were bears in North Africa at least, but they died out
fairly recently due to human hunting and other bloodsports:
https://en.wikipedia.org/wiki/Atlas_Bear
I'm kind of glad I didn't know this until now. Too much
On Monday, 26 August 2013 at 09:29:18 UTC, Chris wrote:
I don't agree. I first used D exactly because it is an
all-rounder. For me built-in UTF support was as important a
factor as native machine code (performance). The reasons why
people would perfer C++ to D are probably habit and
Ramon:
One obious (or seemingly obvious) solution was Ada. Well, no,
it wasn't. Maybe, even probably, if I had to develop low level
stuff for embedded stuff but not for a large application. And,
that was a killer for me, Ada does not really support easily
resizable arrays. To make things
On Sunday, 25 August 2013 at 15:06:28 UTC, bearophile wrote:
Ramon:
One obious (or seemingly obvious) solution was Ada. Well, no,
it wasn't. Maybe, even probably, if I had to develop low level
stuff for embedded stuff but not for a large application. And,
that was a killer for me, Ada does
Well, I had good reason not to mention Ariane5. Looking at that
particular problem, D would have helped, too and roughly in the
same way as Eiffel that is, by doing some debug runs with the
current (Ariane5) values; then dbc could have helped spot the
problem.
I did, btw, not at all intend to
Nice! I cannot anymore go through all the over 100 replies to
this, sorry if someone else has suggested this:
You should write this article (tidied up a bit) in a blog or
somewhere more public on the web! Here in this forum, things are
not as public as they could be!
But thanks for sharing
On 8/21/2013 9:50 AM, Ramon wrote:
I am *not* against keeping an eye on performance, by no means. Looking at
Moore's law, however, and at the kind of computing power available nowadays even
in smartphones, not to talk about 8 and 12 core PCs, I feel that the importance
of performance is way
On Sunday, 25 August 2013 at 22:00:23 UTC, Walter Bright wrote:
On 8/21/2013 9:50 AM, Ramon wrote:
I am *not* against keeping an eye on performance, by no means.
Looking at
Moore's law, however, and at the kind of computing power
available nowadays even
in smartphones, not to talk about 8 and
On 8/25/2013 3:13 PM, Ramon wrote:
You are, of course, perfectly right and my professional background would testify
you to be correct.
It's also clear to me that unless D achieves performance parity with C++, D is
not going to be considered for a lot of applications.
The good news is that I
On 8/25/13 3:00 PM, Walter Bright wrote:
On 8/21/2013 9:50 AM, Ramon wrote:
I am *not* against keeping an eye on performance, by no means. Looking at
Moore's law, however, and at the kind of computing power available
nowadays even
in smartphones, not to talk about 8 and 12 core PCs, I feel that
Ramon:
As for language comparisons or shoot outs, I don't care that
much.
In your first post of this thread you have listed some things you
like, some things you don't like, listed points (Arrays, Strings,
DBC, modern concurrency, GUI, defer mechanism, Genericity) you
have even assigned
Walter Bright:
The good news is that I believe that D is technically capable
of beating C++ on performance.
Some suggestions for D to increase its performance:
- The frequency of heap allocations (like for arrays and small
class instances) of idiomatic D programs should decrease;
- The
On Sunday, 25 August 2013 at 22:27:30 UTC, Walter Bright wrote:
It's also clear to me that unless D achieves performance parity
with C++, D is not going to be considered for a lot of
applications.
The good news is that I believe that D is technically capable
of beating C++ on performance.
On Sunday, 25 August 2013 at 23:00:21 UTC, bearophile wrote:
Ramon:
As for language comparisons or shoot outs, I don't care that
much.
In your first post of this thread you have listed some things
you like, some things you don't like, listed points (Arrays,
Strings, DBC, modern
On Fri, 23 Aug 2013 15:35:19 +0200
Ramon s...@thanks.no wrote:
If GUI is very important to you it might also be useful to look
at a small GUI (like lus'a IUP) and tinker along the lines of how
this would, could, and should be done in D and at how it was
actually done e.g. with the gtk
On Thursday, 22 August 2013 at 23:59:59 UTC, H. S. Teoh wrote:
On Thu, Aug 22, 2013 at 10:10:36PM +0200, Ramon wrote:
[...]
Probably making myself new enemies I dare to say that gui,
colourful
and generally graphics is the area of lowest quality code.
All areas are bad, given the way
Walter Bright wrote:
The structure of the ASTs would need to match
You may be right:
http://www.cs.brown.edu/publications/jgaa/accepted/99/Eppstein99.3.3.pdf
-manfred
On Mon, 19 Aug 2013 22:18:04 +0200
Ramon s...@thanks.no wrote:
Sorry, this is a long and big post. But then, so too is my way
that led me here; long, big, troublesome. And I thought that my
(probably not everyday) set of needs and experiences might be
interesting or useful for some others,
On Thursday, 22 August 2013 at 19:28:42 UTC, Nick Sabalausky
wrote:
On Wed, 21 Aug 2013 18:50:35 +0200
Ramon s...@thanks.no wrote:
I am *not* against keeping an eye on performance, by no means.
Looking at Moore's law, however, and at the kind of computing
power available nowadays even in
On Friday, 23 August 2013 at 05:28:22 UTC, Tyler Jameson Little
wrote:
I assume this is something that can be done at runtime:
int[] a = [1, 2, 3];
int[] b = [2, 2, 2];
auto c = a[] * b[]; // dynamically allocates on the stack;
computes w/SIMD
writeln(c); // prints [2, 4, 6]
On Thursday, 22 August 2013 at 20:10:37 UTC, Ramon wrote:
[...]
Probably making myself new enemies I dare to say that gui,
colourful and generally graphics is the area of lowest quality
code. Simplyfying it somewhat and being blunt I'd state:
Chances are that your server will hum along years
On Friday, 23 August 2013 at 07:15:49 UTC, Gour wrote:
On Mon, 19 Aug 2013 22:18:04 +0200
Ramon s...@thanks.no wrote:
Sorry, this is a long and big post. But then, so too is my way
that led me here; long, big, troublesome. And I thought that
my (probably not everyday) set of needs and
On Friday, 23 August 2013 at 10:34:08 UTC, Chris wrote:
On Thursday, 22 August 2013 at 20:10:37 UTC, Ramon wrote:
[...]
Probably making myself new enemies I dare to say that gui,
colourful and generally graphics is the area of lowest quality
code. Simplyfying it somewhat and being blunt I'd
On Friday, 23 August 2013 at 14:14:47 UTC, Ramon wrote:
Listen: Your reference is quality, realiability, even elegance
(an excellent indicator), maybe performance and yourself
knowing you did it well. Don't give Joe and Mary any power they
wouldn't know how to use anyway.
And btw: Probably
On Friday, 23 August 2013 at 14:30:06 UTC, Chris wrote:
On Friday, 23 August 2013 at 14:14:47 UTC, Ramon wrote:
Listen: Your reference is quality, realiability, even elegance
(an excellent indicator), maybe performance and yourself
knowing you did it well. Don't give Joe and Mary any power
On Fri, Aug 23, 2013 at 08:33:55AM +0200, PauloPinto wrote:
On Thursday, 22 August 2013 at 23:59:59 UTC, H. S. Teoh wrote:
On Thu, Aug 22, 2013 at 10:10:36PM +0200, Ramon wrote:
[...]
Probably making myself new enemies I dare to say that gui, colourful
and generally graphics is the area of
On Thursday, 22 August 2013 at 05:22:17 UTC, deadalnix wrote:
On Wednesday, 21 August 2013 at 17:45:29 UTC, Ramon wrote:
Moor's law is kaput, finish, niet, we don't know how to use
the extra transistor.
Even if that were true, we have gone quite some distance. Not
even talking about Sparc T4
On 08/21/2013 07:12 PM, Andrei Alexandrescu wrote:
The deduper would be insensitive to alpha renaming, e.g. int a = 10;
and int b = 10; would be identical.
This is not alpha renaming, it is just renaming. :o)
Eg. {int a = 10; foo(a);} and {int b = 10; foo(b);} would be identical.
On 08/21/2013 07:17 PM, deadalnix wrote:
You want no bugs ? Go for Haskell.
If you want no bugs, go for formal correctness proof.
But you'll get no convenience
Yes you do. A lot.
or performance.
Let's say easily predictable performance.
The good thing if that if it does compile, you
On Wednesday, 21 August 2013 at 16:21:47 UTC, Ramon wrote:
As for generics, let me put it this way:
In Eiffel generics have been an integral part of the language
design from the beginning. In D ways and mechanisms are
provided to achieve what quite usually is the goal of generics,
namely
On Thursday, 22 August 2013 at 07:59:56 UTC, qznc wrote:
On Wednesday, 21 August 2013 at 16:21:47 UTC, Ramon wrote:
As for generics, let me put it this way:
In Eiffel generics have been an integral part of the language
design from the beginning. In D ways and mechanisms are
provided to
On Wednesday, 21 August 2013 at 17:48:49 UTC, Andrei Alexandrescu
wrote:
No random access. I didn't know about drop-last though - does
it work in O(1)?
There is nth
http://clojure.github.io/clojure/clojure.core-api.html#clojure.core/nth
but the O(n) cited there is rather disturbing.
More
On Thursday, 22 August 2013 at 02:06:13 UTC, Tyler Jameson Little
wrote:
- array operations (int[] a; int[]b; auto c = a * b;)
- I don't think these are automagically SIMD'd, but there's
always hope =D
That isn't allowed. The memory for c must be pre-allocated, and
the expression then
On Thursday, 22 August 2013 at 07:59:56 UTC, qznc wrote:
On Wednesday, 21 August 2013 at 16:21:47 UTC, Ramon wrote:
As for generics, let me put it this way:
In Eiffel generics have been an integral part of the language
design from the beginning. In D ways and mechanisms are
provided to
On Thursday, 22 August 2013 at 12:37:50 UTC, Ramon wrote:
Well in an OO language the actual type(s) is/are known. So real
genericity boils done to whether an object has the required
functions or not.
Polymorphism say no, you don't know the actual type, and this is
the whole point of OOP :
On Thursday, 22 August 2013 at 05:22:17 UTC, deadalnix wrote:
Just read this this :
ftp://ftp.cs.utexas.edu/pub/dburger/papers/ISCA11.pdf and come
back informed.
Well, I can give you a link to some paper that says that the
world will break down and stop next tuesday. Interested?
A vast
On Thursday, 22 August 2013 at 05:22:17 UTC, deadalnix wrote:
On Wednesday, 21 August 2013 at 17:45:29 UTC, Ramon wrote:
On another perspective: Consider this question Would you be
willing to have all your software (incl. OS) running 10% or
even 20% slower but without bugs, leaks, (unintended)
On Thursday, 22 August 2013 at 07:59:56 UTC, qznc wrote:
There are basically two ways to implement generics. Type
erasure (Java,Haskell) or template instantiation (C++,D).
Instantiation provides better performance, but sacrifices error
messages (fixable?), binary code size, and compilation
On Thursday, 22 August 2013 at 14:18:09 UTC, Brian Rogoff wrote:
See this brief discussion from Greg Morrisett on the topic,
with a finer subdivision of approaches
http://www.eecs.harvard.edu/~greg/cs256sp2005/lec15.txt
that confirms your bad news that monomorphization (C++/D
templates) and
http://www.eecs.harvard.edu/~greg/cs256sp2005/lec15.txt
I have quickly looked over that paper and find it quite worthless
for a couple of reasons (I will not elaborate on, except one: All
these scientific elaborations are nice and all but we have real
problems here in the real world.
On Thursday, 22 August 2013 at 15:50:50 UTC, John Colvin wrote:
On Thursday, 22 August 2013 at 15:42:15 UTC, Ramon wrote:
One (OK, not very creative) example that comes to mind is to
have less experienced programmers to work in safe mode only,
which anyway is good enough for pretty everything
On Thursday, 22 August 2013 at 15:42:15 UTC, Ramon wrote:
One (OK, not very creative) example that comes to mind is to
have less experienced programmers to work in safe mode only,
which anyway is good enough for pretty everything the average
app needs, and to limit system mode to seasoned
On Thu, Aug 22, 2013 at 05:50:49PM +0200, John Colvin wrote:
On Thursday, 22 August 2013 at 15:42:15 UTC, Ramon wrote:
One (OK, not very creative) example that comes to mind is to have
less experienced programmers to work in safe mode only, which
anyway is good enough for pretty everything the
On Thursday, 22 August 2013 at 14:37:21 UTC, Dicebot wrote:
On Thursday, 22 August 2013 at 14:18:09 UTC, Brian Rogoff wrote:
See this brief discussion from Greg Morrisett on the topic,
with a finer subdivision of approaches
http://www.eecs.harvard.edu/~greg/cs256sp2005/lec15.txt
that
On Thursday, 22 August 2013 at 16:46:46 UTC, H. S. Teoh wrote:
On Thu, Aug 22, 2013 at 05:50:49PM +0200, John Colvin wrote:
On Thursday, 22 August 2013 at 15:42:15 UTC, Ramon wrote:
One (OK, not very creative) example that comes to mind is to
have
less experienced programmers to work in safe
On Thursday, 22 August 2013 at 17:16:13 UTC, John Colvin wrote:
On Thursday, 22 August 2013 at 16:46:46 UTC, H. S. Teoh wrote:
On Thu, Aug 22, 2013 at 05:50:49PM +0200, John Colvin wrote:
On Thursday, 22 August 2013 at 15:42:15 UTC, Ramon wrote:
One (OK, not very creative) example that comes
On Thu, Aug 22, 2013 at 07:16:09PM +0200, John Colvin wrote:
On Thursday, 22 August 2013 at 16:46:46 UTC, H. S. Teoh wrote:
On Thu, Aug 22, 2013 at 05:50:49PM +0200, John Colvin wrote:
[...]
If I was managing a D based team, I would definitely make use of
safe/system for code reviews. Any
On Wed, 21 Aug 2013 18:50:35 +0200
Ramon s...@thanks.no wrote:
I am *not* against keeping an eye on performance, by no means.
Looking at Moore's law, however, and at the kind of computing
power available nowadays even in smartphones, not to talk about 8
and 12 core PCs, I feel that the
On Thu, Aug 22, 2013 at 03:28:34PM -0400, Nick Sabalausky wrote:
On Wed, 21 Aug 2013 18:50:35 +0200
Ramon s...@thanks.no wrote:
I am *not* against keeping an eye on performance, by no means.
Looking at Moore's law, however, and at the kind of computing
power available nowadays even in
On Thursday, 22 August 2013 at 19:28:42 UTC, Nick Sabalausky
wrote:
On Wed, 21 Aug 2013 18:50:35 +0200
Ramon s...@thanks.no wrote:
I am *not* against keeping an eye on performance, by no means.
Looking at Moore's law, however, and at the kind of computing
power available nowadays even in
On Thu, Aug 22, 2013 at 10:10:36PM +0200, Ramon wrote:
[...]
Probably making myself new enemies I dare to say that gui, colourful
and generally graphics is the area of lowest quality code.
Simplyfying it somewhat and being blunt I'd state: Chances are that
your server will hum along years
Walter Bright wrote:
semantically identical
This would be equivalent to finding plagiarisms and result in a semantical
compression of a software base---and seems to be computational intractable
unless severely restricted.
-manfred
On Thursday, 22 August 2013 at 23:59:59 UTC, H. S. Teoh wrote:
Or rather, I *will* be happy as can be once I find a suitable
replacement for a browser. Browsers are by far the most
ridiculously
resource-consuming beasts ever, given that all they do is to
display
some text and graphics and let
On Fri, Aug 23, 2013 at 05:06:01AM +0200, Ramon wrote:
On Thursday, 22 August 2013 at 23:59:59 UTC, H. S. Teoh wrote:
Or rather, I *will* be happy as can be once I find a suitable
replacement for a browser. Browsers are by far the most ridiculously
resource-consuming beasts ever, given that
On 8/22/2013 7:52 PM, Manfred Nowak wrote:
Walter Bright wrote:
semantically identical
This would be equivalent to finding plagiarisms and result in a semantical
compression of a software base---and seems to be computational intractable
unless severely restricted.
I don't think it would be
On Thursday, 22 August 2013 at 10:34:58 UTC, John Colvin wrote:
On Thursday, 22 August 2013 at 02:06:13 UTC, Tyler Jameson
Little wrote:
- array operations (int[] a; int[]b; auto c = a * b;)
- I don't think these are automagically SIMD'd, but there's
always hope =D
That isn't allowed. The
On 8/21/13, Jesse Phillips jesse.k.phillip...@gmail.com wrote:
I don't frown on copy-paste code because it's the thing to do
or because it causes more typing. copy-paste is bad because your
logic is now duplicated and requires twice (on a good day) the
updates.
Speaking of which someone
On 20/08/13 22:43, Andrei Alexandrescu wrote:
It's a common omission to equate D's ranges with pipes/filters. That misses the
range categorization, which is inspired from C++ iterators.
A relatively accurate characterization of D ranges is a unification of C++
iterators with pipes/filters.
On 20/08/13 23:43, H. S. Teoh wrote:
And now I know who to blame^W I mean, praise, for the names of .front
and .back:
http://forum.dlang.org/post/gaf59c$on7$1...@digitalmars.com
In any case, I'm impressed by the sheer volume of bikeshedding going on
in that thread! It almost puts to
On Wednesday, 21 August 2013 at 17:45:29 UTC, Ramon wrote:
On Wednesday, 21 August 2013 at 17:17:52 UTC, deadalnix wrote:
You want no bugs ? Go for Haskell. But you'll get no
convenience or performance. The good thing if that if it does
compile, you are pretty sure that it does the right
On Thursday, 22 August 2013 at 02:06:13 UTC, Tyler Jameson Little
wrote:
It also has generics, which are runtime generics if I'm not
mistaken.
Both.
Tyler Jameson Little:
It also has generics, which are runtime generics if I'm not
mistaken.
- templates instead of generics (little reason to take a
performance hit)
As far as I know Rust uses monomorphization just like C++ and D
for generics. The difference in generics between D and Rust
On Wednesday, 21 August 2013 at 17:45:29 UTC, Ramon wrote:
Moor's law is kaput, finish, niet, we don't know how to use
the extra transistor.
Even if that were true, we have gone quite some distance. Not
even talking about Sparc T4 or 8-core X86, my smartphone is
more powerful than what I had
On 2013-08-19 23:17, H. S. Teoh wrote:
Yeah, in this day and age, not having native Unicode support is simply
unacceptable. The world has simply moved past the era of ASCII (and the
associated gratuitously incompatible locale encodings). Neither is the
lack of built-in strings
On 2013-08-20 00:14, Walter Bright wrote:
Note the holding back of std.serialization until it has full support for
ranges.
I guess we won't see any std.serialization then. It cannot fully support
ranges until the backend does, in this case std.xml.
--
/Jacob Carlborg
On 2013-08-19 22:18, Ramon wrote:
An added major plus is D's bluntly straight interface to C. And a vital
one, too, because let's face it, not being one of the major players in
languages basically means to either not have a whole lot of major and
important libraries or else to (usually
On 8/20/2013 12:02 AM, Jacob Carlborg wrote:
On 2013-08-20 00:14, Walter Bright wrote:
Note the holding back of std.serialization until it has full support for
ranges.
I guess we won't see any std.serialization then. It cannot fully support ranges
until the backend does, in this case
On Tuesday, 20 August 2013 at 07:08:08 UTC, Jacob Carlborg wrote:
You can use this tool to automatically generate bindings to C
libraries:
https://github.com/jacob-carlborg/dstep
Great stuff, Jacob! Congratulations.
One thing that is usually not mentioned in articles about D is
that you
1 - 100 of 154 matches
Mail list logo
