On 29/07/2010 19:49, Walter Bright wrote:
Don wrote:
I agree with Walter's statement that ALL of the components are
unreliable, and I think it's important to realize that proofs are the
same. Even in the case where the program perfectly implements the
algorithm, there can be bugs in the proof.
Don nos...@nospam.com wrote in message
news:i2rk4b$2je...@digitalmars.com...
Jim Balter wrote:
Walter Bright newshou...@digitalmars.com wrote in message
news:i2nkto$8u...@digitalmars.com...
bearophile wrote:
You have to think about proofs as another (costly) tool to avoid
bugs/bangs,
but
dsimcha dsim...@yahoo.com wrote in message
news:i2rvar$6o...@digitalmars.com...
== Quote from Don (nos...@nospam.com)'s article
Jim Balter wrote:
Walter Bright newshou...@digitalmars.com wrote in message
news:i2nkto$8u...@digitalmars.com...
bearophile wrote:
You have to think about proofs
retard r...@tard.com.invalid wrote in message
news:i2smf3$2lt...@digitalmars.com...
Thu, 29 Jul 2010 13:22:35 +, dsimcha wrote:
== Quote from Don (nos...@nospam.com)'s article
Jim Balter wrote:
Walter Bright newshou...@digitalmars.com wrote in message
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message
news:i2snsk$1p9...@digitalmars.com...
retard wrote:
I really love digitalmars.D because this is one of the few places where
99% of the community has zero experience with other languages, other
paradigms (non-imperative),
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message
news:i34op7$2hb...@digitalmars.com...
On 08/01/2010 05:44 AM, retard wrote:
Sat, 31 Jul 2010 23:38:17 +, BCS wrote:
Hello retard,
Has anyone except the almighty
Andrei ever even downloaded a theorem prover?
Yes, ACL2.
Jonathan M Davis jmdavisp...@gmail.com wrote in message
news:mailman.50.1280425209.13841.digitalmar...@puremagic.com...
On Thursday, July 29, 2010 03:11:21 Don wrote:
I have to disagree with that. Correctness proofs are based on a total
fallacy. Attempting to proving that a program is correct
Mon, 02 Aug 2010 23:47:49 -0700, Jim Balter wrote:
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message
news:i34op7$2hb...@digitalmars.com...
On 08/01/2010 05:44 AM, retard wrote:
Sat, 31 Jul 2010 23:38:17 +, BCS wrote:
Hello retard,
Has anyone except the almighty
Andrei
Jim Balter wrote:
Jonathan M Davis jmdavisp...@gmail.com wrote in message
news:mailman.50.1280425209.13841.digitalmar...@puremagic.com...
On Thursday, July 29, 2010 03:11:21 Don wrote:
I have to disagree with that. Correctness proofs are based on a total
fallacy. Attempting to proving that a
Tue, 03 Aug 2010 10:43:44 +0200, Don wrote:
Jim Balter wrote:
Jonathan M Davis jmdavisp...@gmail.com wrote in message
news:mailman.50.1280425209.13841.digitalmar...@puremagic.com...
On Thursday, July 29, 2010 03:11:21 Don wrote:
I have to disagree with that. Correctness proofs are based on a
== Quote from Don (nos...@nospam.com)'s article
If you have two buggy pieces of code,
but they are completely independent, their bugs will manifest on
different inputs. So you can achieve extremely high reliability even on
code with a very high bug density.
I find it particularly interesting
Hello Jim,
Don nos...@nospam.com wrote in message
news:i2rk4b$2je...@digitalmars.com...
Jim Balter wrote:
Walter Bright newshou...@digitalmars.com wrote in message
news:i2nkto$8u...@digitalmars.com...
bearophile wrote:
You have to think about proofs as another (costly) tool to avoid
Don wrote:
Hence Walter's assertion, that the most effective way to deal with this
is to have _independent_ redundant systems. Having two identical copies
doesn't improve reliability much. If you have two buggy pieces of code,
but they are completely independent, their bugs will manifest on
Jim Balter wrote:
Ad hominem argument. If you disagree that it looks like a mess, you
should argue that. If you concur, then it doesn't matter who pointed it
out.
Yes, and most of the time that's the case. But sometimes a person uses anonymity
in order to engage in trolling, or so they can
Walter Bright:
On the other hand, people posting under pseudonyms have to work harder to
earn
respect, and that's fair, too.
Sometimes I am polemical, very often wrong, nearly always partially wrong, and
often I don't have enough experience. But I hope to have gained a bit of your
respect
bearophile wrote:
Walter Bright:
On the other hand, people posting under pseudonyms have to work harder to
earn respect, and that's fair, too.
Sometimes I am polemical, very often wrong, nearly always partially wrong,
and often I don't have enough experience. But I hope to have gained a bit
BCS wrote:
I once had a fire hydrant installed on my property. The city required
an engineering analysis, which ran to quite a stack of paper. After
approval, the workers came by to install it. They never looked at the
analysis, or even the drawings, they just dug up the water main and
stuck a
Sat, 31 Jul 2010 23:38:17 +, BCS wrote:
Hello retard,
Has anyone except the almighty
Andrei ever even downloaded a theorem prover?
Yes, ACL2.
http://www.dsource.org/projects/scrapple/browser/trunk/backmath
Now I know why that sort of thing isn't done more often.
Learning how to
Hello retard,
Sat, 31 Jul 2010 23:38:17 +, BCS wrote:
Hello retard,
Has anyone except the almighty
Andrei ever even downloaded a theorem prover?
Yes, ACL2.
http://www.dsource.org/projects/scrapple/browser/trunk/backmath
Now I know why that sort of thing isn't done more often.
On 08/01/2010 02:35 AM, Walter Bright wrote:
BCS wrote:
I once had a fire hydrant installed on my property. The city required
an engineering analysis, which ran to quite a stack of paper. After
approval, the workers came by to install it. They never looked at the
analysis, or even the drawings,
On 08/01/2010 05:44 AM, retard wrote:
Sat, 31 Jul 2010 23:38:17 +, BCS wrote:
Hello retard,
Has anyone except the almighty
Andrei ever even downloaded a theorem prover?
Yes, ACL2.
http://www.dsource.org/projects/scrapple/browser/trunk/backmath
Now I know why that sort of thing isn't
Andrei Alexandrescu wrote:
On 08/01/2010 05:44 AM, retard wrote:
Sat, 31 Jul 2010 23:38:17 +, BCS wrote:
Hello retard,
Has anyone except the almighty
Andrei ever even downloaded a theorem prover?
Yes, ACL2.
http://www.dsource.org/projects/scrapple/browser/trunk/backmath
Now I know
Jeff Nowakowski wrote:
On 08/01/2010 02:35 AM, Walter Bright wrote:
BCS wrote:
I once had a fire hydrant installed on my property. The city required
an engineering analysis, which ran to quite a stack of paper. After
approval, the workers came by to install it. They never looked at the
Hello Don,
Jérôme M. Berger wrote:
Don wrote:
I have to disagree with that. Correctness proofs are based on a
total
fallacy. Attempting to proving that a program is correct (on a real
machine, as opposed to a theoretical one) is utterly ridiculous.
I'm genuinely astonished that such an
Hello Jonathan,
On Thursday, July 29, 2010 12:34:35 Don wrote:
The reason I think it's absurd is that (AFAIK) no other modern
engineering discpline has attempted to rely on correctness proofs.
Really, the reason that you even _can_ attempt such proofs is because
computer science is
BCS wrote:
Every engineering discipline I have any experience with gets a heck of a
lot closer to producing formal proofs of correctness than programing.
Mechanical engineering designs also tend to be a lot simpler than programs,
although the environment they work in is far more complex.
Walter Bright newshou...@digitalmars.com wrote in message
news:i31qr6$4m...@digitalmars.com...
BCS wrote:
Every engineering discipline I have any experience with gets a heck of a
lot closer to producing formal proofs of correctness than programing.
Mechanical engineering designs also tend
Hello dsimcha,
Oh, I forgot to mention memory allocation issues:
stack overflows
just plain running out of memory
Easy to account for
heap fragmentation
Not so easy but if you can show the maximum size of the allocated memory
you might be able to prove there is no allocation of the n-1
Hello retard,
Has anyone except the almighty
Andrei ever even downloaded a theorem prover?
Yes, ACL2.
http://www.dsource.org/projects/scrapple/browser/trunk/backmath
Now I know why that sort of thing isn't done more often.
--
... IXOYE
Hello Walter,
BCS wrote:
Every engineering discipline I have any experience with gets a heck
of a lot closer to producing formal proofs of correctness than
programing.
Mechanical engineering designs also tend to be a lot simpler than
programs, although the environment they work in is far
Hello dsimcha,
Yea, here's a laundry list of stuff that theory doesn't account for
that can go wrong on real machines:
overflow
Theory can
rounding error
Theory has:
A mechanically checked proof of the AMD5K 86 floating-point division program:
BCS wrote:
Hello Walter,
BCS wrote:
Every engineering discipline I have any experience with gets a heck
of a lot closer to producing formal proofs of correctness than
programing.
Mechanical engineering designs also tend to be a lot simpler than
programs, although the environment they work
Hello Walter,
BCS wrote:
Hello Walter,
BCS wrote:
Every engineering discipline I have any experience with gets a heck
of a lot closer to producing formal proofs of correctness than
programing.
Mechanical engineering designs also tend to be a lot simpler than
programs, although the
Hello Don,
I agree with Walter's statement that ALL of the components are
unreliable, and I think it's important to realize that proofs are the
same.
That's where automatic proof checkers come in...
--
... IXOYE
retard wrote:
I really love digitalmars.D because this is one of the few places where
99% of the community has zero experience with other languages, other
paradigms (non-imperative), automatic theorem provers, or anything not
related to D. There's a whole choir against theorem proving now.
Don wrote:
You can certainly catch bugs with that technique, but the word proof
has no business being there. It's like the unsinkable Titanic.
(I think it's really similar, actually. Apparently the only reason the
Titanic sank was that many of the rivets were defective).
Actually, the
Jim Balter wrote:
Walter Bright newshou...@digitalmars.com wrote in message
news:i2nkto$8u...@digitalmars.com...
bearophile wrote:
You have to think about proofs as another (costly) tool to avoid
bugs/bangs,
but not as the ultimate and only tool you have to use (I think
dsimcha was
trying
Thu, 29 Jul 2010 12:11:21 +0200, Don wrote:
Jim Balter wrote:
Walter Bright newshou...@digitalmars.com wrote in message
news:i2nkto$8u...@digitalmars.com...
bearophile wrote:
You have to think about proofs as another (costly) tool to avoid
bugs/bangs,
but not as the ultimate and only
== Quote from Don (nos...@nospam.com)'s article
Jim Balter wrote:
Walter Bright newshou...@digitalmars.com wrote in message
news:i2nkto$8u...@digitalmars.com...
bearophile wrote:
You have to think about proofs as another (costly) tool to avoid
bugs/bangs,
but not as the ultimate and
dsimcha:
overflow
Good provers take in account integral overflows too.
rounding error
Interval (floating point) arithmetic can be used to face a large part of this
problem. I hope to see a good Interval arithmetic lib for D in few years.
compiler bugs
OS bugs
Those software too can be
== Quote from bearophile (bearophileh...@lycos.com)'s article
dsimcha:
overflow
Good provers take in account integral overflows too.
rounding error
Interval (floating point) arithmetic can be used to face a large part of this
problem. I hope to see a good Interval arithmetic lib for D in
On Thursday, July 29, 2010 03:11:21 Don wrote:
I have to disagree with that. Correctness proofs are based on a total
fallacy. Attempting to proving that a program is correct (on a real
machine, as opposed to a theoretical one) is utterly ridiculous.
I'm genuinely astonished that such an absurd
retard wrote:
Thu, 29 Jul 2010 12:11:21 +0200, Don wrote:
Jim Balter wrote:
Walter Bright newshou...@digitalmars.com wrote in message
news:i2nkto$8u...@digitalmars.com...
bearophile wrote:
You have to think about proofs as another (costly) tool to avoid
bugs/bangs,
but not as the ultimate
Don wrote:
I have to disagree with that. Correctness proofs are based on a total
fallacy. Attempting to proving that a program is correct (on a real
machine, as opposed to a theoretical one) is utterly ridiculous.
I'm genuinely astonished that such an absurd idea ever had any traction.
Don wrote:
I agree with Walter's statement that ALL of the components are
unreliable, and I think it's important to realize that proofs are the
same. Even in the case where the program perfectly implements the
algorithm, there can be bugs in the proof.
Also, the hardware running the correct
Jérôme M. Berger wrote:
Don wrote:
I have to disagree with that. Correctness proofs are based on a total
fallacy. Attempting to proving that a program is correct (on a real
machine, as opposed to a theoretical one) is utterly ridiculous.
I'm genuinely astonished that such an absurd idea ever
Thu, 29 Jul 2010 13:22:35 +, dsimcha wrote:
== Quote from Don (nos...@nospam.com)'s article
Jim Balter wrote:
Walter Bright newshou...@digitalmars.com wrote in message
news:i2nkto$8u...@digitalmars.com...
bearophile wrote:
You have to think about proofs as another (costly) tool to
On Thursday, July 29, 2010 12:34:35 Don wrote:
The reason I think it's absurd is that (AFAIK) no other modern
engineering discpline has attempted to rely on correctness proofs.
Really, the reason that you even _can_ attempt such proofs is because computer
science is effectively applied
retard wrote:
I really love digitalmars.D because this is one of the few places where
99% of the community has zero experience with other languages, other
paradigms (non-imperative), automatic theorem provers, or anything not
related to D. There's a whole choir against theorem proving now. The
== Quote from retard (r...@tard.com.invalid)'s article
I really love digitalmars.D because this is one of the few places where
99% of the community has zero experience with other languages, other
paradigms (non-imperative), automatic theorem provers, or anything not
related to D. There's a
retard wrote:
Has anyone except the almighty Andrei ever even downloaded
a theorem prover?
That's *A*lmighty Andrei, note the caps. Please show due respect.
Hello Walter,
bearophile wrote:
You have to think about proofs as another (costly) tool to avoid
bugs/bangs, but not as the ultimate and only tool you have to use (I
think dsimcha was trying to say that there are more costly-effective
tools. This can be true, but you can't be sure that is
Walter Bright newshou...@digitalmars.com wrote in message
news:i2nkto$8u...@digitalmars.com...
bearophile wrote:
You have to think about proofs as another (costly) tool to avoid
bugs/bangs,
but not as the ultimate and only tool you have to use (I think dsimcha
was
trying to say that there
Jim Balter wrote:
You're being religious about this and arguing against a strawman. While
all parts are unreliable, they aren't *equally* unreliable.
They don't have to have equal reliability in order for redundancy to be very
effective.
Unit tests,
contract programming, memory safe
Wed, 28 Jul 2010 11:48:42 -0700, Walter Bright wrote:
Jim Balter wrote:
You're being religious about this and arguing against a strawman. While
all parts are unreliable, they aren't *equally* unreliable.
They don't have to have equal reliability in order for redundancy to be
very
Mon, 26 Jul 2010 14:04:53 -0700, Walter Bright wrote:
retard wrote:
Tue, 27 Jul 2010 04:10:14 +0800, KennyTM~ wrote:
On Jul 27, 10 02:42, Walter Bright wrote:
retard wrote:
I think the Java/C# developers gave up X % of the execution speed to
avoid hard crashes (exceptions instead of
retard wrote:
http://www.drdobbs.com/blog/archives/2009/10/safe_systems_fr.html
http://www.drdobbs.com/blog/archives/2009/11/designing_safe.html
Sadly, it's a topic that has not penetrated software engineering
instructional materials, and programmers have to learn it the hard way
again and
Lerdorf's quote strikes me as actually being somewhat close to what
Walter is talking about. Web applications don't focus on making a
thing that never fails, but instead achieve reliability by having an
external watchdog switch to backups - that is, a fresh copy of the
program - when something
Adam Ruppe wrote:
Lerdorf's quote strikes me as actually being somewhat close to what
Walter is talking about. Web applications don't focus on making a
thing that never fails, but instead achieve reliability by having an
external watchdog switch to backups - that is, a fresh copy of the
program
Walter Bright:
That misses the point about reliability. Again, you're approaching from the
point of view that you can make a program that cannot fail (i.e. prove it
correct). That view is WRONG WRONG WRONG and you must NEVER NEVER NEVER rely
on
such for something important, like say your
== Quote from bearophile (bearophileh...@lycos.com)'s article
Walter Bright:
That misses the point about reliability. Again, you're approaching from the
point of view that you can make a program that cannot fail (i.e. prove it
correct). That view is WRONG WRONG WRONG and you must NEVER
J. M. Berger:
Plus, how do you prove the proof? I know of at least two examples
of software that were proven formally and that AFAIK worked
perfectly to spec and yet failed spectacularly.
You have to think about proofs as another (costly) tool to avoid bugs/bangs,
but not as the
Tue, 27 Jul 2010 12:02:36 -0700, Walter Bright wrote:
retard wrote:
Mon, 26 Jul 2010 14:04:53 -0700, Walter Bright wrote:
That misses the point about reliability. Again, you're approaching from
the point of view that you can make a program that cannot fail (i.e.
prove it correct). That view
dsimcha wrote:
But the point is that redundancy is probably the **cheapest, most efficient**
way
to get ultra-high reliability.
It also works incredibly well. Airliners use a dual path system, which means
that no single failure can bring it down. If it didn't work, the skies would be
bearophile wrote:
You have to think about proofs as another (costly) tool to avoid bugs/bangs,
but not as the ultimate and only tool you have to use (I think dsimcha was
trying to say that there are more costly-effective tools. This can be true,
but you can't be sure that is right in general).
On Tuesday, July 27, 2010 15:00:20 Walter Bright wrote:
bearophile wrote:
You have to think about proofs as another (costly) tool to avoid
bugs/bangs, but not as the ultimate and only tool you have to use (I
think dsimcha was trying to say that there are more costly-effective
tools. This
Walter Bright:
I want to re-emphasize the point that keeps getting missed.
Building reliable systems is not about trying to make components that cannot
fail. It is about building a system that can TOLERATE failure of any of its
components.
It's how you build safe systems from UNRELIABLE
bearophile wrote:
Each of those parts must be pretty reliable if you want to design a globally
reliable system. Space Shuttle control systems are redundant as you say, and
probably each single point of failure has a backup, but each software system
is pretty reliable by itself, probably they
bearophile bearophileh...@lycos.com wrote in message
news:i2ibqm$2gs...@digitalmars.com...
One important problem of C# generics can be solved adding IArithmeticT:
http://www.osnews.com/story/7930
That's one of the reasons I've pretty much given up on C# despite having
initially been
Walter Bright:
I think a better article is here:
http://windowsdevcenter.com/pub/a/oreilly/windows/news/hejlsberg_0800.html
Thank you for the link.
I see they talk about the importance of 'events', and later they say:
Indeed, if Foo is a reference type, and if we do the design right, we can
Walter Bright Wrote:
bearophile wrote:
Andrei Alexandrescu:
In my humble opinion, the design of Java, C#, and Go is proof that their
authors didn't get the STL. Otherwise, those languages would be very
different.
I don't believe you. Among the designers of Java, C# and Go there are
Sun, 25 Jul 2010 20:21:05 -0500, Andrei Alexandrescu wrote:
On 07/25/2010 04:54 PM, bearophile wrote:
Andrei Alexandrescu:
In my humble opinion, the design of Java, C#, and Go is proof that
their authors didn't get the STL. Otherwise, those languages would be
very different.
I don't
But then their containers and algorithms are markedly inferior to STL's.
They are toxic to the programmers who have only been exposed to them. So
Java and C# got STL and decided to not go with it, I'm sure they would
have at least gotten a few good bits from it. But no - the entire e.g.
Java
bearophile wrote:
Walter Bright:
I think a better article is here:
http://windowsdevcenter.com/pub/a/oreilly/windows/news/hejlsberg_0800.html
Thank you for the link.
You're welcome, it took me a fair bit of work to find. It's an important
historical document.
levenshtein wrote:
At least the hype around Go shows that the language's authors enjoy a huge
respect.
Not only the authors, but the respect for Google itself. It gives Go an enormous
and enviable head start. But, eventually, Go will have to deliver.
retard wrote:
I think the Java/C# developers gave up X % of the execution speed to
avoid hard crashes (exceptions instead of segfaults)
1. segfaults *are* exceptions.
2. D offers a memory safe subset, and D's ranges and algorithms are memory safe.
On 26/07/2010 05:32, Sean Kelly wrote:
C# generics are a heck of a lot nicer than Java generics, but there also I think there
were other practical reasons for the decision that they didn't fully address. C# is
effectively the native language for .NET, and so its libraries should be as useful
Bruno Medeiros Wrote:
On 26/07/2010 05:32, Sean Kelly wrote:
C# generics are a heck of a lot nicer than Java generics, but there also I
think there were other practical reasons for the decision that they didn't
fully address. C# is effectively the native language for .NET, and so its
Walter Bright:
1. segfaults *are* exceptions.
Aren't exceptions objects?
Bye,
bearophile
On Jul 27, 10 02:42, Walter Bright wrote:
retard wrote:
I think the Java/C# developers gave up X % of the execution speed to
avoid hard crashes (exceptions instead of segfaults)
1. segfaults *are* exceptions.
2. D offers a memory safe subset, and D's ranges and algorithms are
memory safe.
Tue, 27 Jul 2010 04:10:14 +0800, KennyTM~ wrote:
On Jul 27, 10 02:42, Walter Bright wrote:
retard wrote:
I think the Java/C# developers gave up X % of the execution speed to
avoid hard crashes (exceptions instead of segfaults)
1. segfaults *are* exceptions.
2. D offers a memory safe
bearophile bearophileh...@lycos.com wrote:
Walter Bright:
1. segfaults *are* exceptions.
Aren't exceptions objects?
That's Exception, not exception. The latter may be a hardware thing.
--
Simen
KennyTM~ wrote:
On Jul 27, 10 02:42, Walter Bright wrote:
retard wrote:
I think the Java/C# developers gave up X % of the execution speed to
avoid hard crashes (exceptions instead of segfaults)
1. segfaults *are* exceptions.
2. D offers a memory safe subset, and D's ranges and algorithms
On 2010-07-26 14:42:54 -0400, Walter Bright newshou...@digitalmars.com said:
1. segfaults *are* exceptions.
At the processor level, yes. They're exceptions at the language level
only on Windows, which I'd consider 'implementation defined', so not
exceptions as far as the language is
retard wrote:
Tue, 27 Jul 2010 04:10:14 +0800, KennyTM~ wrote:
On Jul 27, 10 02:42, Walter Bright wrote:
retard wrote:
I think the Java/C# developers gave up X % of the execution speed to
avoid hard crashes (exceptions instead of segfaults)
1. segfaults *are* exceptions.
2. D offers a
bearophile wrote:
Walter Bright:
1. segfaults *are* exceptions.
Aren't exceptions objects?
That's an implementation detail.
Michel Fortin wrote:
On 2010-07-26 14:42:54 -0400, Walter Bright newshou...@digitalmars.com
said:
1. segfaults *are* exceptions.
At the processor level, yes. They're exceptions at the language level
only on Windows, which I'd consider 'implementation defined', so not
exceptions as far as
bearophile bearophileh...@lycos.com wrote in message
news:i2knnc$1ft...@digitalmars.com...
Walter Bright:
1. segfaults *are* exceptions.
Aren't exceptions objects?
Bye,
bearophile
Not at all -- exceptions are system-generated events that are implemented in
modern languages by the
Walter Bright Wrote:
Justin Johansson wrote:
It sounds like the D PL has invented the range idiom unlike any other PL.
Pointer programming is deeply embedded into the C++ culture, and iterators
segue
nicely into that culture. For D, however, programming revolves around arrays,
and
On 25/07/10 12:11 PM, levenshtein wrote:
Walter Bright Wrote:
Justin Johansson wrote:
It sounds like the D PL has invented the range idiom unlike any other PL.
Pointer programming is deeply embedded into the C++ culture, and iterators segue
nicely into that culture. For D, however,
Peter Alexander Wrote:
On 25/07/10 12:11 PM, levenshtein wrote:
Walter Bright Wrote:
Justin Johansson wrote:
It sounds like the D PL has invented the range idiom unlike any other PL.
Pointer programming is deeply embedded into the C++ culture, and iterators
segue
nicely into
levenshtein wrote:
Peter Alexander Wrote:
On 25/07/10 12:11 PM, levenshtein wrote:
Walter Bright Wrote:
Justin Johansson wrote:
It sounds like the D PL has invented the range idiom unlike any other PL.
Pointer programming is deeply embedded into the C++ culture, and iterators segue
nicely
== Quote from Don (nos...@nospam.com)'s article
levenshtein wrote:
Peter Alexander Wrote:
On 25/07/10 12:11 PM, levenshtein wrote:
Walter Bright Wrote:
Justin Johansson wrote:
It sounds like the D PL has invented the range idiom unlike any other
PL.
Pointer programming is
dsimcha wrote:
Basically, my take as a practical programmer rather than a theoretical comp-sci
researcher is Who cares if it's been done before if it's not implemented in any
practical language?.
There's rarely anything truly new in programming. I agree with you that turning
an idea into
On 07/24/2010 08:36 AM, Justin Johansson wrote:
It sounds like the D PL has invented the range idiom unlike any other PL.
Since the dawn of PL's, which must be about 50 years now since Lisp
for example, it is hard to imagine a new PL inventing a completely
new idiom as ranges seem to purport.
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
Personally I'm not as much amazed about the time taken, as about the
fact that many people _today_ don't figure what's good about the STL. My
theory (which I expanded in my article On Iteration) is that STL
requires
Andrei Alexandrescu wrote:
On 07/24/2010 08:36 AM, Justin Johansson wrote:
It sounds like the D PL has invented the range idiom unlike any other PL.
Since the dawn of PL's, which must be about 50 years now since Lisp
for example, it is hard to imagine a new PL inventing a completely
new idiom
Andrei Alexandrescu wrote:
I strongly believe Walter got the STL and generic programming in
general. He might be fuzzy about some minor details, but he is plenty
good at plenty other things and always had a good listening ear for the
importance of genericity.
To be fair, it took me many
Andrei Alexandrescu:
In my humble opinion, the design of Java, C#, and Go is proof
that their authors didn't get the STL. Otherwise, those languages would
be very different.
I don't believe you. Among the designers of Java, C# and Go there are people
that are both experts and smart. C#
bearophile wrote:
Andrei Alexandrescu:
In my humble opinion, the design of Java, C#, and Go is proof
that their authors didn't get the STL. Otherwise, those languages would
be very different.
I don't believe you. Among the designers of Java, C# and Go there are people
that are both experts
1 - 100 of 109 matches
Mail list logo
