digitalmars.D - Go Programming talk [OT]

bearophile <bearophileHUGS lycos.com> writes:
A recent talk about Go, Google I/O 2010 - Go Programming, the real talk stops

At 9.30 you can see the switch used on a type type :-)
You can see a similar example here:
http://golang.org/src/pkg/exp/datafmt/datafmt.go
Look for the line
switch t := fexpr.(type) {

Originally Go was looking almost like a toy language, I thought Google was
thinking of it as a toy, but I now think Google is getting more serious about
it, and I can see Go has developed some serious features to solve/do the basic
things.

So maybe Andrei was wrong, you can design a good flexible language that doesn't
need templates.

Compared to Go D2 is way more complex. I don't know if people today want to
learn a language as complex as D2.

Go target flexibility and performance is not C++-class one (but probably it's
not too much difficult to build a compiler able to produce very efficient Go
programs).

In the talk they show some interfaces and more things done with free functions,
I don't know those things get compiled in assembly.

Bye,
bearophile

Jun 06 2010
bearophile <bearophileHUGS lycos.com> writes:
Slides:


Jun 06 2010
On 6/6/10, bearophile <bearophileHUGS lycos.com> wrote:
At 9.30 you can see the switch used on a type type :-)
You can see a similar example here:
http://golang.org/src/pkg/exp/datafmt/datafmt.go

That example looks really similar to the D1 "D-style Variadic
Functions" example here: http://digitalmars.com/d/1.0/function.html

Of course, the D1 thing there is an if/else/if chain instead of a
switch, but they really look to operate basically the same.

Jun 06 2010
Kagamin <spam here.lot> writes:
Leandro Lucarella Wrote:

It looks like Go now have scope (exit) =)

http://golang.org/doc/go_spec.html#DeferStmt

// f returns 1
func f() (result int) {
defer func() {
result++
}()
return 0
}

Jun 06 2010
Walter Bright <newshound1 digitalmars.com> writes:
Adam Ruppe wrote:
That sucks hard. I prefer it to finally{} though, since finally
doesn't scale as well in code complexity (it'd do fine in this case,
but not if there were nested transactions), but both suck compared to
the scalable, beautiful, and *correct* elegance of D's scope guards.

I agree. D's scope statement looks fairly innocuous and one can easily pass it
by with "blah, blah, another statement, blah, blah" but the more I use it the
more I realize it is a

game changer

in how one writes code. For example, here's the D1 implementation of

-------------------------------------------------------------
/********************************************
* Throws:
*      FileException on error.
*/

{
HANDLE h;

if (useWfuncs)
{
wchar* namez = std.utf.toUTF16z(name);
FILE_ATTRIBUTE_NORMAL |
FILE_FLAG_SEQUENTIAL_SCAN,cast(HANDLE)null);
}
else
{
char* namez = toMBSz(name);
FILE_ATTRIBUTE_NORMAL |
FILE_FLAG_SEQUENTIAL_SCAN,cast(HANDLE)null);
}

if (h == INVALID_HANDLE_VALUE)
goto err1;

auto size = GetFileSize(h, null);
if (size == INVALID_FILE_SIZE)
goto err2;

auto buf = std.gc.malloc(size);
if (buf)
std.gc.hasNoPointers(buf.ptr);

goto err2;

goto err2;

if (!CloseHandle(h))
goto err;

return buf[0 .. size];

err2:
CloseHandle(h);
err:
delete buf;
err1:
throw new FileException(name, GetLastError());
}
----------------------------------------------------------

Note the complex logic to recover and unwind from errors (none of the called
functions throw exceptions), and the care with which this is constructed to
ensure everything is done properly. Contrast this with D2's version written by
Andrei:

-----------------------------------------------------------
void[] read(in char[] name, size_t upTo = size_t.max)
{
FILE_ATTRIBUTE_NORMAL | FILE_FLAG_SEQUENTIAL_SCAN,
HANDLE.init)
defaults;
auto h = useWfuncs
? CreateFileW(std.utf.toUTF16z(name), defaults)
: CreateFileA(toMBSz(name), defaults);

cenforce(h != INVALID_HANDLE_VALUE, name);
scope(exit) cenforce(CloseHandle(h), name);
auto size = GetFileSize(h, null);
cenforce(size != INVALID_FILE_SIZE, name);
size = min(upTo, size);
auto buf = GC.malloc(size, GC.BlkAttr.NO_SCAN)[0 .. size];
scope(failure) delete buf;

return buf[0 .. size];
}
--------------------------------------------------------

The code is the same logic, but using scope it is dramatically simplified.
There's not a single control flow statement in it! Furthermore, it is correct
even if functions like CloseHandle throw exceptions.

Jun 07 2010
"Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message
news:hujd7m$11gj$1 digitalmars.com...
That sucks hard. I prefer it to finally{} though, since finally
doesn't scale as well in code complexity (it'd do fine in this case,
but not if there were nested transactions), but both suck compared to
the scalable, beautiful, and *correct* elegance of D's scope guards.

I agree. D's scope statement looks fairly innocuous and one can easily
pass it by with "blah, blah, another statement, blah, blah" but the more I
use it the more I realize it is a

game changer

in how one writes code. For example, here's the D1 implementation of

-------------------------------------------------------------
/********************************************
* Throws:
*      FileException on error.
*/

{
HANDLE h;

if (useWfuncs)
{
wchar* namez = std.utf.toUTF16z(name);
h =
FILE_ATTRIBUTE_NORMAL |
FILE_FLAG_SEQUENTIAL_SCAN,cast(HANDLE)null);
}
else
{
char* namez = toMBSz(name);
h =
FILE_ATTRIBUTE_NORMAL |
FILE_FLAG_SEQUENTIAL_SCAN,cast(HANDLE)null);
}

if (h == INVALID_HANDLE_VALUE)
goto err1;

auto size = GetFileSize(h, null);
if (size == INVALID_FILE_SIZE)
goto err2;

auto buf = std.gc.malloc(size);
if (buf)
std.gc.hasNoPointers(buf.ptr);

goto err2;

goto err2;

if (!CloseHandle(h))
goto err;

return buf[0 .. size];

err2:
CloseHandle(h);
err:
delete buf;
err1:
throw new FileException(name, GetLastError());
}
----------------------------------------------------------

Looking at that, if I didn't know better, I would think you were a VB
programmer ;)

Jun 07 2010
Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
Hmm, but I can actually understand your code.  :-(

Yeah, but how long would it take you to be sure that it is handling all errors
correctly and cleaning up properly in case of those errors? It'd probably take
me at least 5 intensive minutes. But in the scope version, once you're
comfortable with scope and enforce, it wouldn't take half that.

Jun 07 2010
Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
Probably so.  What's cenforce do anyway?

private T cenforce(T, string file = __FILE__, uint line = __LINE__)
(T condition, lazy const(char)[] name)
{
if (!condition)
{
throw new FileException(
text("In ", file, "(", line, "), data file ", name), .getErrno);
}
return condition;
}

Jun 07 2010
Walter Bright <newshound1 digitalmars.com> writes:
Adam Ruppe wrote:
On 6/7/10, Bill Baxter <wbaxter gmail.com> wrote:
Hmm, but I can actually understand your code.  :-(

The confusing part is probably cenforce, which is a little helper
function in the std.file module.

cenforce(condition, filename) is the same as

The tldr version of what cenforce does is convert a C-style error code return
into an exception. Hence the "C" in enforce.

Jun 07 2010
=?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
Leandro Lucarella wrote:

Go doesn't have exceptions, so scope(failure/success) makes no sense.
You can argue about if not having exceptions is good or bad (I don't
have a strong opinion about it, sometimes I feel exceptions are nice,
sometimes I think they are evil), though.

Just to compare the two styles...

Without exceptions, every step of the code must be checked explicitly:

// C code:
int foo()
{
int err = 0;

// allocate resources

err = bar();
if (err) goto finally;

err = zar();
if (err) goto finally;

err = car();
if (err) goto finally;

finally:
// do cleanup

return err;
}

(Ordinarily, the if(err) checks are hidden inside macros like
check_error, check_error_null, etc.)

With exceptions, the actual code emerges:

// C++ or D code
void foo()
{
// allocate resources

bar();
zar();
car();
}

Ali

Jun 07 2010
=?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Leandro Lucarella wrote:
Ali =C3=87ehreli, el  7 de junio a las 14:41 me escribiste:
Leandro Lucarella wrote:

Go doesn't have exceptions, so scope(failure/success) makes no sense.=

You can argue about if not having exceptions is good or bad (I don't
have a strong opinion about it, sometimes I feel exceptions are nice,=

sometimes I think they are evil), though.

Without exceptions, every step of the code must be checked explicitly:=

// C code:
int foo()
{
int err =3D 0;

// allocate resources

err =3D bar();
if (err) goto finally;

err =3D zar();
if (err) goto finally;

err =3D car();
if (err) goto finally;

finally:
// do cleanup

return err;
}

(Ordinarily, the if(err) checks are hidden inside macros like
check_error, check_error_null, etc.)

With exceptions, the actual code emerges:

// C++ or D code
void foo()
{
// allocate resources

bar();
zar();
car();
}

You are right, but when I see the former code, I know exactly was it
going on, and when I see the later code I don't have a clue how errors
are handled, or if they are handled at all. And try adding the try/catc=

statements, the code is even more verbose than the code without
exceptions.
=20
Is a trade-off. When you don't handle the errors, exceptions might be
a win, but when you do handle them, I'm not so sure. And again, I'm not=

saying I particularly like one more than the other, I don't have a
strong opinion =3D)
=20

of the time, people just write the second one with or without
exceptions and don't bother about error checking if there are no
exceptions. You are a lot more likely to get them to handle errors
properly with exceptions than without (particularly with D's scope
statements).

Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr

Jun 08 2010
Bane <branimir.milosavljevic gmail.com> writes:
Jérôme M. Berger Wrote:

Leandro Lucarella wrote:
Ali Çehreli, el  7 de junio a las 14:41 me escribiste:
Leandro Lucarella wrote:

Go doesn't have exceptions, so scope(failure/success) makes no sense.
You can argue about if not having exceptions is good or bad (I don't
have a strong opinion about it, sometimes I feel exceptions are nice,
sometimes I think they are evil), though.

Without exceptions, every step of the code must be checked explicitly:

// C code:
int foo()
{
int err = 0;

// allocate resources

err = bar();
if (err) goto finally;

err = zar();
if (err) goto finally;

err = car();
if (err) goto finally;

finally:
// do cleanup

return err;
}

(Ordinarily, the if(err) checks are hidden inside macros like
check_error, check_error_null, etc.)

With exceptions, the actual code emerges:

// C++ or D code
void foo()
{
// allocate resources

bar();
zar();
car();
}

You are right, but when I see the former code, I know exactly was it
going on, and when I see the later code I don't have a clue how errors
are handled, or if they are handled at all. And try adding the try/catch
statements, the code is even more verbose than the code without
exceptions.

Is a trade-off. When you don't handle the errors, exceptions might be
a win, but when you do handle them, I'm not so sure. And again, I'm not
saying I particularly like one more than the other, I don't have a
strong opinion =)

of the time, people just write the second one with or without
exceptions and don't bother about error checking if there are no
exceptions. You are a lot more likely to get them to handle errors
properly with exceptions than without (particularly with D's scope
statements).

Jerome
--
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr

Being lazy as I am, exceptions are faster and easier to use than manual error
checking. There will always be some unchecked return value, with exceptions it
can't happen. In a way same as GC vs manual memory handling.

Each thread of program I make I always enclose in try catch, so everything is
cought.


Jun 08 2010
Pelle <pelle.mansson gmail.com> writes:
On 06/09/2010 01:04 AM, Leandro Lucarella wrote:
Bane, el  8 de junio a las 14:42 me escribiste:
Is a trade-off. When you don't handle the errors, exceptions might be
a win, but when you do handle them, I'm not so sure. And again, I'm not
saying I particularly like one more than the other, I don't have a
strong opinion =)

of the time, people just write the second one with or without
exceptions and don't bother about error checking if there are no
exceptions. You are a lot more likely to get them to handle errors
properly with exceptions than without (particularly with D's scope
statements).

Being lazy as I am, exceptions are faster and easier to use than
manual error checking. There will always be some unchecked return
value, with exceptions it can't happen. In a way same as GC vs manual
memory handling.

Each thread of program I make I always enclose in try catch, so
everything is cought.

Yes, I agree that "safety" is the best argument in favour of exceptions
(as explicitness is the best argument in favour of no-exceptions). The
Python Zen put it this way:

Errors should never pass silently.
Unless explicitly silenced.

That's what I like the most about exceptions. I think try/catch is
really ugly though. There has to be something better.

Careful use of scope(exit) and simply avoiding catching exceptions works
well for me. Except when you have to catch, of course. :)

Jun 09 2010
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/09/2010 06:28 AM, Pelle wrote:
On 06/09/2010 01:04 AM, Leandro Lucarella wrote:
Bane, el 8 de junio a las 14:42 me escribiste:
Is a trade-off. When you don't handle the errors, exceptions might be
a win, but when you do handle them, I'm not so sure. And again, I'm
not
saying I particularly like one more than the other, I don't have a
strong opinion =)

of the time, people just write the second one with or without
exceptions and don't bother about error checking if there are no
exceptions. You are a lot more likely to get them to handle errors
properly with exceptions than without (particularly with D's scope
statements).

Being lazy as I am, exceptions are faster and easier to use than
manual error checking. There will always be some unchecked return
value, with exceptions it can't happen. In a way same as GC vs manual
memory handling.

Each thread of program I make I always enclose in try catch, so
everything is cought.

Yes, I agree that "safety" is the best argument in favour of exceptions
(as explicitness is the best argument in favour of no-exceptions). The
Python Zen put it this way:

Errors should never pass silently.
Unless explicitly silenced.

That's what I like the most about exceptions. I think try/catch is
really ugly though. There has to be something better.

Careful use of scope(exit) and simply avoiding catching exceptions works
well for me. Except when you have to catch, of course. :)

Same here. I think a good application only has few try/catch statements,
so the fact that try is a relatively heavy statement is not very important.

Andrei

Jun 09 2010
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/09/2010 11:14 AM, Leandro Lucarella wrote:
Andrei Alexandrescu, el  9 de junio a las 09:52 me escribiste:
That's what I like the most about exceptions. I think try/catch is
really ugly though. There has to be something better.

Careful use of scope(exit) and simply avoiding catching exceptions works
well for me. Except when you have to catch, of course. :)

Same here. I think a good application only has few try/catch
statements, so the fact that try is a relatively heavy statement is
not very important.

I don't feel the same, but that's probably because I mostly write
programs that need to take good care of errors.

I'm not sure that few try/catch statements imply there's some sloppy
approach to errors going on. Exception are all about centralized error
handling, so too many try/catch statements indicates a failure to
centralize error handling.

Andrei

Jun 09 2010
Bane <branimir.milosavljevic gmail.com> writes:
Andrei Alexandrescu Wrote:

On 06/09/2010 06:28 AM, Pelle wrote:
On 06/09/2010 01:04 AM, Leandro Lucarella wrote:
Bane, el 8 de junio a las 14:42 me escribiste:
Is a trade-off. When you don't handle the errors, exceptions might be
a win, but when you do handle them, I'm not so sure. And again, I'm
not
saying I particularly like one more than the other, I don't have a
strong opinion =)

of the time, people just write the second one with or without
exceptions and don't bother about error checking if there are no
exceptions. You are a lot more likely to get them to handle errors
properly with exceptions than without (particularly with D's scope
statements).

Being lazy as I am, exceptions are faster and easier to use than
manual error checking. There will always be some unchecked return
value, with exceptions it can't happen. In a way same as GC vs manual
memory handling.

Each thread of program I make I always enclose in try catch, so
everything is cought.

Yes, I agree that "safety" is the best argument in favour of exceptions
(as explicitness is the best argument in favour of no-exceptions). The
Python Zen put it this way:

Errors should never pass silently.
Unless explicitly silenced.

That's what I like the most about exceptions. I think try/catch is
really ugly though. There has to be something better.

Careful use of scope(exit) and simply avoiding catching exceptions works
well for me. Except when you have to catch, of course. :)

Same here. I think a good application only has few try/catch statements,
so the fact that try is a relatively heavy statement is not very important.

Andrei

In my experience exceptions have one great advantage that they are far easier
to add/remove to existing codebase without changing lot of things. They require
much less coding and do not obfuscate code flow.

So for what they offer and for what price - they are extremely worth it.

Jun 09 2010
"Nick Sabalausky" <a a.a> writes:
"Leandro Lucarella" <llucax gmail.com> wrote in message
news:20100609162223.GC16920 burns.springfield.home...
BTW, here is a PhD thesis with a case against exceptions. I didn't read
it (just have a peek) and it's rather old (1982), so it might be not
that interesting, but I thought posting it here as the thread became
mostly about exceptions and someone might be interested =)

http://web.cecs.pdx.edu/~black/publications/Black%20D.%20Phil%20Thesis.pdf

I didn't have time to read the whole thing, but I read the Abstract,
Introduction, and roughly the first half of the Conclusion. But I did ignore
all the sections where he yapps on about what a programming language is,
what their point is and what makes a good one (Maybe in his next paper he'll
take a stab at P=NP while making sure to explain in perfect detail why 2 + 2
is 4.)

Regarding what he said about exceptions: Some things struck me as things
that may have seemed to make reasonable sense back in 1982 when it was
written, but don't anymore. Other times, the guy seemed completely out of
his mind.

I did take a [very] brief skim through chapters 5 and 6, though, where he
explains his alternative to exceptions. I could be wrong, but it looks like
what he's describing amounts to using algebraic data types and/or tagged
unions along with having the concept of "error" be a value of it's own
strong type that works similar to propagated NANs or the propagated "error"
expressions Walter recently implemented in DMD to improve error-reporting.
Ie, something like this:

--------------------------------
// Singleton, and vaguely similar to the "null object" idiom.
class Error
{
public static Error error;
public static this() { error = new Error(); }
private this() {}
}

alias Algebraic!(double, Error) doubleOrErr;

doubleOrErr divide(doubleOrErr a, doubleOrErr b)
{
if(a == Error.error || b == Error.error || b == 0)
return Error.error;

return a/b;
}
--------------------------------

I think that's an interesting idea that might be worth looking into.
Although it would seem to bloat the memory usage and maybe speed of a
program since just about anything would have to be an Algebraic.

My analysis of what I saw as his main points about exceptions:

In the Abstract:

"The very real problems of survival after a component violates its
specification [ie, general fault-tolerance] is not addressed by exception
handling. [(He appears to be talking about things that are addressed by
redundant systems, watchdogs, fail-safes, etc.)]"

True. But neither do the things exceptions are used to replace. And
exceptions at least make it possible in a few small cases (moreso than the
things exceptions are used to replace).

In the Introduction:

"[People think exceptions are a cure-all for program errors. They're not,
and thinking that they do is dangerous.]"

back then, but I don't think anyone does now. It's kind of as if he were
saying "GC is worse than manual memory management because it makes people
believe they never have to think about memory management issues".
Programmers, of course, have already figured out that's not the case.

"On practical grounds, too, exception handling handling seems to be poorly
motivated..."

The paragraph that starts with that sentence (in the introduction) seems to
be nothing but a bunch of hand-waving.

"[A compiler that supports exceptions] is likely to be larger, slower, more
prone to bugs, and less explicit with its error messages."

Probably would have been true in 1982, when the paper was written, but these
days the difference would be minimal.

"Each nested recovery compartment represents a frame of reference in which
progressively more disastrous events are anticipated, but progressively less
comprehensive recovery is attempted."

That's completely dependent on the exception-handling code. What the system
allows, and he seems to be ignoring, is an in-process version of a watchdog.
Not as reliable as an out-of-process one, granted, but it can help.

In the Conclusion, under the hading "8.1 Exception Handling is Unnecessary":

"...abstract specifications can be written without abstract errors..."

I'd have to read the chapter he cites to have anything meaningful to say

"...a programming language exception mechanism neither prevents the
construction of erroneous programs nor provides a way of dealing with errors
that absolves the programmer from thinking about them."

Straw-man. I don't know what the programming climate was like in 1982, but
I've never heard anyone claim that exceptions do either of those things.
However, they *do* improve what had ended up becoming a very bad situation,
so the idea that they're "unnecessary" is, at best, an overstatement.

"[Bugs (ie, cases where the program deviates from its specification)] should
be corrected before the program is delivered, not handled while it is being
run."

HA HA HA HA HA!!! (/Wipes tear/) AHH HA HA HA HA HA!!!!

Translation: He seems to be living in lala-bizarro-land where the waterfall
model produces good, reliable results and one can simply "choose" to find
all bugs before shipping. Also, everybody is always happy, there is no
disease, and everyone spends all day frolicking in the daisies, climbing
rainbows and playing "Kumbayah" on their guitars.

Then there's a big convoluted, meandering three-paragraph rant involving
illegal states but doesn't appear have any obvious point I can discern. My
best guess is he's trying to say that exceptions are part of the
specification of the program, therefore they don't technically qualify as
actually being "exceptions" at all, which, of course, is just useless
semantic bickering. But frankly, I'm not sure even he knows what the hell
his point in those paragraphs is.

"Exception handling mechanisms are unnecessary because they can always be
replaced by [he lists some other things here]"

A thoroughly pointless pedantic argument as most useful programming language
constructs can be replaced by other ones. So exceptions can be, too. Who is
surprised? Who the hell cares?

In the Conclusion, under the hading "8.2 Exception Handling is Undesirable":

"The reason that exception handling mechanisms are undesirable is that,
whereas they are irrelevant to the correction of erroneous programs, the
difficulties they introduce are very real."

I really did go into this paper with an open mind, but the deeper I get, the
deeper the hyperbole seems to get. I can certainly grant that there are
difficulties introduced by exceptions, but what bugs me is the implication
that exceptions are undesirable purely because "they are irrelevant to the
correction of erroneous programs" (and have other drawbacks). There are two
way you can take that "irrelevant to the correction of erroneous programs"
part, and either way leads to the argument becoming a big pile of bullcrap:

A. You can interpret it literally and pedantically, in which case it might
be *technically* true, but conveniently ignores other benefits of exceptions
(ex, they are relevant *and* useful for managing and mitigating problems
caused by certain types of programmer/user/system/hardware errors, and for
keeping high-level intent clear while doing so).

B. You can interpret it more liberally, in which case it's just a plain load
of hyperbolic crap right at face value.

Then he lists the difficulties he sees exceptions as introducing:

"(i) They permit non-local transfers of protocol, re-introducing the dangers
of the goto and the problem of clearing up."

The only such things they introduce that aren't already comparable to
"return", "if", and "while", have been solved by "finally" and scope guards
(and the occasional RAII helps too).

I'm not going to re-type or refute this one as I'm not really sure what he's
getting at anyway.

"(iii) If "functions" are allowed to generate exceptions, a rift is
introduced between the concepts of "function" in the programming language
and in mathematics. This complicates the semantics of the language and makes

I don't know about 1982, but I've been programming since the late 80's, and
as far back as I can remember, the rift between the languages of math and
programming (particularly imperative) has always been a mile wide. He may as
well complain that chemical "equations" don't behave the same as they do in
algebra.

"(iv) Recursive exception handling () is extremely complex."

It's certainly an issue, but I don't know about it being "extremely"
complex. Things like linked exceptions (ie, an exception with a "next")
certainly help.

"(v) An exception handling mechanism may be used to deliver information to a
level of abstraction where it ought not to be available, violating the
principle of information hiding."

You can violate information hiding with an ordinary function, too. Or with
pointers. So what? It may make it easier than to accidentally leek some
information, but I've used exceptions extensively and have never found it to
be particularly problematic in actual practice. Actually, such problems are
pretty easy to avoid if you just consider anything you throw to be "public".

"(vi) [checked exceptions are a PITA]..."

Agreed.

"(vi) ...On the other hand, if exceptions are not specified then the dangers
of using them are increased, and many of the advantages of strong typing are
lost."

I haven't a clue why he feels the advantages of strong typing would be lost.

As for dangers of using exceptions being increased, that may be true to a
small extent, but I think he's overstating the dangers. Also, there's
nothing preventing the creation of a code-analysis tool that checks what
exceptions can be thrown (directly or indirectly) from each function (in
fact this has always been one of my arguments against checked exceptions).
That would provide the best of both worlds.

Jun 09 2010
Bane <branimir.milosavljevic gmail.com> writes:
 "[Bugs (ie, cases where the program deviates from its specification)] should
be corrected before the program is delivered, not handled while it is being
run."

HA HA HA HA HA!!! (/Wipes tear/) AHH HA HA HA HA HA!!!!

Translation: He seems to be living in lala-bizarro-land where the waterfall
model produces good, reliable results and one can simply "choose" to find
all bugs before shipping. Also, everybody is always happy, there is no
disease, and everyone spends all day frolicking in the daisies, climbing
rainbows and playing "Kumbayah" on their guitars.

Sounds to me that guy never ever have written program that was used for
anything other than lecturing.

Jun 09 2010
"Jer" <jersey chicago.com> writes:
Nick Sabalausky wrote:
"Leandro Lucarella" <llucax gmail.com> wrote in message
news:20100609162223.GC16920 burns.springfield.home...
BTW, here is a PhD thesis with a case against exceptions. I didn't
read it (just have a peek) and it's rather old (1982), so it might
be not that interesting, but I thought posting it here as the thread
became mostly about exceptions and someone might be interested =)

http://web.cecs.pdx.edu/~black/publications/Black%20D.%20Phil%20Thesis.pdf

I didn't have time to read the whole thing, but

But he noted you 28 years ago. I wonder if that student now has made
millions of dollars on the web.

Introduction, and roughly the first half of the Conclusion. But I did
ignore all the sections where he yapps on about what a programming
language is,

I don't remember that, but you seem to take offense to it. Should I go
back and read those parts? (rhetorical).

what their point is and what makes a good one (Maybe in
his next paper he'll take a stab at P=NP while making sure to explain
in perfect detail why 2 + 2 is 4.)

In what you have "said" thus far, makes you look like someone flustered
that your snakeoil is just what it is. (At least it is the feeling I get
straight away).

Regarding what he said about exceptions: Some things struck me as
things that may have seemed to make reasonable sense back in 1982
when it was written, but don't anymore.

As you are obviously flustered and about to go off on a rant, I'll just
sit back and enjoy the show. ;)

Other times, the guy seemed
completely out of his mind.

Oh yeah, now you sound "objective"! LOL!

I did take a [very] brief skim through chapters 5 and 6, though,
where he explains his alternative to exceptions. I could be wrong,
but it looks like what he's describing amounts to using algebraic
data types and/or tagged unions

[blah, blah and Walter]

Nuff said, no comment to your affiliations. I hear that "grouping" is
"good".

My analysis of what I saw as his main points about exceptions:

In the Abstract:

"The very real problems of survival after a component violates its
specification [ie, general fault-tolerance] is not addressed by
exception handling. [(He appears to be talking about things that are
addressed by redundant systems, watchdogs, fail-safes, etc.)]"

No, he refers to such. Hello. We're all "big boys" here. We know about
real-time systems concepts (though most of "us" are probably (?) not
oblivious to it and then comment on it. Nor use it as a vehicle to show
you know the elements of it. Nuff said: stop wasting bandwidth with your
personal issues.

True. But neither do the things exceptions are used to replace. And
exceptions at least make it possible in a few small cases (moreso
than the things exceptions are used to replace).

The point, may have been, and surely was (like I have time to read such a
WORDY thing word-for-word, mind you), that a LARGE amount of complexity
is not justified for incremental and debatable gain. You seem to be
playing politics in the "in-between the line" space, in which, of course,
you are completely just outright being a "liar" (for lack of the better
term).
In the Introduction:

"[People think exceptions are a cure-all for program errors. They're
not, and thinking that they do is dangerous.]"

exceptions back then, but I don't think anyone does now.

I don't 100% know, but I think that is still true and because I am alive
today and can assess the programming languages of today and see that they
"don't get it". "big ships turn slowly"-syndrome. Could a 1982 "rant
thesis" be relevant in 2010! "Hypocrasy!" is outcried!

It's kind of
as if he were saying "GC

Ah. Can't have a thread of discussion in a D NG without interjecting GC.
Sounds like where one bugs out of other religions.

"On practical grounds, too, exception handling handling seems to be
poorly motivated..."

The paragraph that starts with that sentence (in the introduction)
seems to be nothing but a bunch of hand-waving.

document. Get a grip dude.

"[A compiler that supports exceptions] is likely to be larger,
slower, more prone to bugs, and less explicit with its error
messages."
Probably would have been true in 1982, when the paper was written,
but these days the difference would be minimal.

You are arguing FOR complexity, while he argues for simplicity. See the
point now?

"Each nested recovery compartment represents a frame of reference in
which progressively more disastrous events are anticipated, but
progressively less comprehensive recovery is attempted."

That's completely dependent on the exception-handling code.

No, no... hang on.. what "exception handling code"? Godwin's law? If you
start out with the mindset that "exceptions are..." and then conclude "so
see, exceptions are", you haven't said anything.

In the Conclusion, under the hading "8.1 Exception Handling is
Unnecessary":
"...abstract specifications can be written without abstract errors..."

I'd have to read the chapter he cites to have anything meaningful to

I didn't remember that as key, but it was a long read. Certainly it is
too abstract! ;)

"...a programming language exception mechanism neither prevents the
construction of erroneous programs nor provides a way of dealing with
errors that absolves the programmer from thinking about them."

Straw-man.

Not at all. He said: 1.  a programming language exception mechanism does
not prevent the construction of erroneous programs. 2. a programming
language exception mechanism curtails the programmer from considering all
possible consequences of action.

I don't quote him. (2) is what is embodied in the thesis and to single
out the passage and not realize what was meant, is to be 1. lazy 2.
unknowledgeable 3. political. Which are you: lazy, unknowledgeable or
political?

"ain't no strawman"... except for your thoughts on the topic.

I don't know what the programming climate was like in
1982, but I've never heard anyone claim that exceptions do either of
those things.

Hello. It doesn't require such harkening.

However, they *do* improve what had ended up becoming a
very bad situation, so the idea that they're "unnecessary" is, at
best, an overstatement.

Now THAT is a strawman! You are a funny guy!

"[Bugs (ie, cases where the program deviates from its specification)]
should be corrected before the program is delivered, not handled
while it is being run."

HA HA HA HA HA!!! (/Wipes tear/) AHH HA HA HA HA HA!!!!

Well that must be an "inside secret" then. Show me, then laugh and maybe
I'll laugh with you.

Translation: He seems to be living in lala-bizarro-land where the
waterfall model produces good, reliable results and one can simply
"choose" to find all bugs before shipping. Also, everybody is always
happy, there is no disease, and everyone spends all day frolicking in
the daisies, climbing rainbows and playing "Kumbayah" on their
guitars.

He actually seems to be THINKING about programming rather than just doing
it as instructed. (Ha ha on me, cuz I wouldn't hire anyone to program for
me but other than MY way).

Then there's a big convoluted, meandering three-paragraph rant
involving illegal states but doesn't appear have any obvious point I
can discern.

You seem to be deeply and emotionally entranced by the document. Like

My best guess

is he's trying to say that exceptions are
part of the specification of the program,

OK, I see you studying under him. You're trying to figure it out (?). (I
think you have a paradigm though). He has stated many times that no one
know what an "exception" is. Hello.

therefore they don't
technically qualify as actually being "exceptions" at all, which, of
course, is just useless semantic bickering. But frankly, I'm not sure
even he knows what the hell his point in those paragraphs is.

Obviously YOU don't. (And keep ME out of this please, it's between you
and him, not me).

"Exception handling mechanisms are unnecessary because they can
always be replaced by [he lists some other things here]"

A thoroughly pointless pedantic argument as most useful programming
language constructs can be replaced by other ones.

No. You are playing a semantic game, ignoring the context of the thesis.
It doesn't make much sense to go on and on in a conversation (or, duh,
money... or on a (false) date with a woman). Him (in context): I did it
this way to same effect. You: Wait!, I'll generalize to a level above and
"win"!. See how you are just a boy and not a man?

In the Conclusion, under the hading "8.2 Exception Handling is
Undesirable":
"The reason that exception handling mechanisms are undesirable is
that, whereas they are irrelevant to the correction of erroneous
programs, the difficulties they introduce are very real."

I really did go into this paper with an open mind, but the deeper I
get, the deeper the hyperbole seems to get.

And the more your snakeoil sales can climb! huh. Dude, he called you
snakeoil from his grave (I surely hope he went on to do things that make
him happy).

I can certainly grant

Oh? How much? I don't talk to anyone who can't grant more than a million.
THINK before you speak.

that there are difficulties introduced by exceptions,

THAT is a strawman.

but what bugs
me

That is an indication of paradigm or politics.

is the implication that exceptions are undesirable purely because

That is the godwin defense.

Then he lists the difficulties he sees exceptions as introducing:

"(i) They permit non-local transfers of protocol, re-introducing the
dangers of the goto and the problem of clearing up."

The only such things they introduce that aren't already comparable to
"return", "if", and "while", have been solved by "finally" and scope
guards (and the occasional RAII helps too).

Hello. Your stock price just went to 0.

I'm not going to re-type or refute this one as I'm not really sure
what he's getting at anyway.

Then why mention it? His thesis disrupted your whole life and now you
(Good luck with that idiocy).

"(iii) If "functions" are allowed to generate exceptions, a rift is
introduced between the concepts of "function" in the programming
language and in mathematics. This complicates the semantics of the
language and makes reasoning about programs more difficult."

I don't know about 1982, but I've been programming since the late
80's, and as far back as I can remember, the rift between the
languages of math and programming (particularly imperative) has
always been a mile wide. He may as well complain that chemical
"equations" don't behave the same as they do in algebra.

He was saying NOTHING about programming and math. Dude: in 1982 there was
the lingering of math, before that there was Coperincus.

"(iv) Recursive exception handling () is extremely complex."

It's certainly an issue, but I don't know about it being "extremely"
complex.

You fix it, I may use it. ('may' is the keyword).

Things like linked exceptions (ie, an exception with a
"next") certainly help.

I wouldn't know. ;)

"(v) An exception handling mechanism may be used to deliver
information to a level of abstraction where it ought not to be
available, violating the principle of information hiding."

that't true, obviously. In how many pages of context was this little
passage? The guy was a STUDENT dude. Get a grip.

"(vi) [checked exceptions are a PITA]..."

Agreed.

How do you mean? The thesis asked you for an alternative, eh? Pfft, never

It can happen in humanity time, but it can't in computer time. Real-time
programming should come before any other type of programming instruction.

"(vi) ...On the other hand, if exceptions are not specified then the
dangers of using them are increased, and many of the advantages of
strong typing are lost."

I haven't a clue why he feels the advantages of strong typing would
be lost.

;) You are "too learned".

As for dangers of using exceptions being increased, that may be true
to a small extent, but I think he's overstating the dangers.

But he presented a thesis. I await yours. (No, no offense, I won't wait).

Also,
there's nothing preventing the creation of a code-analysis tool that
checks what exceptions can be thrown (directly or indirectly) from
each function (in fact this has always been one of my arguments
against checked exceptions). That would provide the best of both
worlds.

Sure. Market it. Sell it. I dare you.

Jun 10 2010
"Jer" <jersey chicago.com> writes:
Leandro Lucarella wrote:
Leandro Lucarella, el  9 de junio a las 11:37 me escribiste:
Pelle, el  9 de junio a las 13:28 me escribiste:
Yes, I agree that "safety" is the best argument in favour of
exceptions (as explicitness is the best argument in favour of
no-exceptions). The Python Zen put it this way:

Errors should never pass silently.
Unless explicitly silenced.

That's what I like the most about exceptions. I think try/catch is
really ugly though. There has to be something better.

Careful use of scope(exit) and simply avoiding catching exceptions
works well for me. Except when you have to catch, of course. :)

I'm talking precisely about the case when you have to catch. In that
case I think the resulting code is uglier and more convoluted than
the code to manage errors by returning error codes or similar.

BTW, here is a PhD thesis with a case against exceptions. I didn't
read it (just have a peek) and it's rather old (1982), so it might be
not that interesting, but I thought posting it here as the thread
became mostly about exceptions and someone might be interested =)

http://web.cecs.pdx.edu/~black/publications/Black%20D.%20Phil%20Thesis.pdf

Thanks. I was feeling kinda lonely. Circa 1982, np.

Jun 10 2010
Leandro Lucarella <llucax gmail.com> writes:
Bane, el  8 de junio a las 14:42 me escribiste:
Is a trade-off. When you don't handle the errors, exceptions might be
a win, but when you do handle them, I'm not so sure. And again, I'm not
saying I particularly like one more than the other, I don't have a
strong opinion =)

of the time, people just write the second one with or without
exceptions and don't bother about error checking if there are no
exceptions. You are a lot more likely to get them to handle errors
properly with exceptions than without (particularly with D's scope
statements).

Being lazy as I am, exceptions are faster and easier to use than
manual error checking. There will always be some unchecked return
value, with exceptions it can't happen. In a way same as GC vs manual
memory handling.

Each thread of program I make I always enclose in try catch, so
everything is cought.

Yes, I agree that "safety" is the best argument in favour of exceptions
(as explicitness is the best argument in favour of no-exceptions). The
Python Zen put it this way:

Errors should never pass silently.
Unless explicitly silenced.

That's what I like the most about exceptions. I think try/catch is
really ugly though. There has to be something better.

--
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Que barbaridad, este país se va cada ves más pa' tras, más pa' tras...
-- Sidharta Kiwi

Jun 08 2010
On 6/8/10, Leandro Lucarella <llucax gmail.com> wrote:
That's what I like the most about exceptions. I think try/catch is
really ugly though. There has to be something better.

Isn't there actually a function buried somewhere in Phobos that
translates exceptions into return values?

Yes, there is: http://dpldocs.info/std.contracts.collectException

Still not the most beautiful thing ever, but perhaps something along
that idea line would be better for you?

Jun 08 2010
Leandro Lucarella <llucax gmail.com> writes:
Adam Ruppe, el  6 de junio a las 19:06 me escribiste:
On 6/6/10, bearophile <bearophileHUGS lycos.com> wrote:
At 9.30 you can see the switch used on a type type :-)
You can see a similar example here:
http://golang.org/src/pkg/exp/datafmt/datafmt.go

That example looks really similar to the D1 "D-style Variadic
Functions" example here: http://digitalmars.com/d/1.0/function.html

Of course, the D1 thing there is an if/else/if chain instead of a
switch, but they really look to operate basically the same.

It looks like Go now have scope (exit) =)

http://golang.org/doc/go_spec.html#DeferStmt

--
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Hay manos capaces de fabricar herramientas
con las que se hacen máquinas para hacer ordenadores
que a su vez diseñan máquinas que hacen herramientas
para que las use la mano

Jun 06 2010
On 6/6/10, Leandro Lucarella <llucax gmail.com> wrote:
It looks like Go now have scope (exit) =)

Not quite the same (defer is apparently only on function level), but
definitely good to have. The scope statements are awesome beyond
belief.

Jun 06 2010
Leandro Lucarella <llucax gmail.com> writes:
Pelle, el  9 de junio a las 13:28 me escribiste:
Yes, I agree that "safety" is the best argument in favour of exceptions
(as explicitness is the best argument in favour of no-exceptions). The
Python Zen put it this way:

Errors should never pass silently.
Unless explicitly silenced.

That's what I like the most about exceptions. I think try/catch is
really ugly though. There has to be something better.

Careful use of scope(exit) and simply avoiding catching exceptions
works well for me. Except when you have to catch, of course. :)

I'm talking precisely about the case when you have to catch. In that
case I think the resulting code is uglier and more convoluted than the
code to manage errors by returning error codes or similar.

--
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Si por el chancho fuera, se autocomería con chimichurri Worshestershire!

Jun 09 2010
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/06/2010 05:13 PM, bearophile wrote:
A recent talk about Go, Google I/O 2010 - Go Programming, the real
talk stops at about 33 minutes:

At 9.30 you can see the switch used on a type type :-) You can see a
similar example here:
http://golang.org/src/pkg/exp/datafmt/datafmt.go Look for the line
switch t := fexpr.(type) {

Originally Go was looking almost like a toy language, I thought
Google was thinking of it as a toy, but I now think Google is getting
more serious about it, and I can see Go has developed some serious
features to solve/do the basic things.

So maybe Andrei was wrong, you can design a good flexible language
that doesn't need templates.

Which part of the talk conveyed to you that information?

Compared to Go D2 is way more complex. I don't know if people today
want to learn a language as complex as D2.

Go target flexibility and performance is not C++-class one (but
probably it's not too much difficult to build a compiler able to
produce very efficient Go programs).

In the talk they show some interfaces and more things done with free
functions, I don't know those things get compiled in assembly.

Bye, bearophile

I'm surprised you found the talk compelling, as I'm sure you know
better. The talk uses a common technique - cherry-picking examples and
avoiding to discuss costs and tradeoffs - to make the language look
good. In addition, the talk put Go in relation with the likes of Java,
C++, and Python but ignores the fact that Go's choices have been made by
other languages as well, along with the inherent advantages and

The reality is that in programming language design decisions that are
all-around wins are few and far apart; it's mostly tradeoffs and
compromises. Structural conformance and implicit, run-time checked
Flat, two-level hierarchies with interfaces and implementations are also
an honest discussion - as I hope is the tone in TDPL - serves the
language and its users better than giving half of the story.

Andrei

Jun 07 2010
Kagamin <spam here.lot> writes:
Andrei Alexandrescu Wrote:

I think
an honest discussion - as I hope is the tone in TDPL - serves the
language and its users better than giving half of the story.


Jun 07 2010
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/07/2010 06:36 AM, Kagamin wrote:
Andrei Alexandrescu Wrote:

I think an honest discussion - as I hope is the tone in TDPL -
serves the language and its users better than giving half of the
story.

TDPL is the first one. There're many features in other languages no
speak of costs, and every forgotten cost is a lie.

Agreed. Well, we'll see. I try to discuss costs, tradeoffs, and
alternative approaches that were considered and rejected (and why) for
all major features of D.

For example, few books give a balanced view of dynamic polymorphism; in
some you'll find the nice parts, in others you'll find the not-so-nice
parts. I tried to discuss both in TDPL:

====================
\dee's  reference  semantics approach  to  handling  class objects  is
similar  to  that  found  in many  object-oriented  languages.   Using
reference semantics and \idx{garbage collection} for class objects has
both positive and negative consequences, among which the following:

\begin{itemize*}
\item[+]\index{polymorphism}\emph{\textbf{Polymorphism.}}   The  level
of indirection  brought by the consistent use  of references enables
support for \idx{polymorphism}.  All  references have the same size,
but related objects  can have different sizes even  though they have
ostensibly  the same  type (through  the use  of  inheritance, which
we'll  discuss  shortly).  Because  references  have  the same  size
regardless of the  size of the object they refer  to, you can always
substitute  references to  derived  objects for  references to  base
objects.  Also, arrays of objects work properly even when the actual
objects in the array have  different sizes.  If you've used C++, you
sure   know   about   the   necessity   of   using   pointers   with
\idx{polymorphism},  and  about  the  various  lethal  problems  you
encounter when you forget to.
\item[+]\emph{\textbf{Safety.}}    Many   of   us   see   \idx{garbage
collection}  as  just a  convenience  that  simplifies coding  by
relieving the programmer  of managing memory.  Perhaps surprisingly,
however,  there is  a very  strong connection  between  the infinite
lifetime model (which  \idx{garbage collection} makes practical) and
memory  safety.   Where  there's  infinite lifetime,  there  are  no
dangling  references, that is,  references to  some object  that has
gone out of existence and has had its memory reused for an unrelated
object.  Note that  it would be just as safe  to use value semantics
throughout (have  \cc{auto a2 =  a1;} duplicate the  A   object that
a1   refers to  and  have  a2   refer  to the  copy).  That  setup,
however, is hardly interesting  because it disallows creation of any
referential  structure  (such  as  lists, trees,  graphs,  and  more
generally shared resources).
\item[--]\emph{\textbf{Allocation  cost.}}   Generally, class  objects
must reside in the \index{garbage collection}garbage-collected heap,
which generally  is slower and eats  more memory than  memory on the
stack.  The  margin has diminished quite  a bit lately  but is still
nonzero.
\item[--]\emph{\textbf{Long-range  coupling.}}   The  main  risk  with
using  references  is  undue  aliasing.  Using  reference  semantics
throughout makes  it all too easy  to end up with  references to the
same   object  residing   in   different---and  unexpected---places.
In~Figure~\vref{fig:aliasing},  a1  and   a2  may be arbitrarily far
from each  other as far as  the application logic  is concerned, and
additionally there may be many other references hanging off the same
object.   Interestingly, if  the referred  object is  immutable, the
problem vanishes---as  long as nobody modifies the  object, there is
no  coupling.  Difficulties  arise  when one  change  effected in  a
certain context  affects surprisingly and dramatically  the state as
seen  in  a different  part  of  the  application.  Another  way  to
alleviate this  problem is explicit duplication, often  by calling a
special  method   clone ,  whenever  passing  objects  around.   The
downside of  that technique  is that it  is based on  discipline and
that  it  could  lead  to   inefficiency  if  several  parts  of  an
application  decide to  conservatively  clone objects  just to  be
sure.''
\end{itemize*}

Contrast reference semantics with  value semantics \a~la  int . Value
semantics has advantages, notably equational reasoning: you can always
substitute  equals  for equals  in  expressions  without altering  the
result.   (In contrast,  references that  use method  calls  to modify
underlying objects  do not  allow such reasoning.)   Speed is  also an
important advantage  of value semantics,  but if you want  the dynamic
generosity of \idx{polymorphism}, reference semantics is a must.  Some
languages tried to accommodate both,  which earned them the moniker of
impure,'' in contrast to  pure object-oriented languages that foster
reference semantics  uniformly across all  types.  \dee is  impure and
up-front  about it.   You get  to choose  at design  time  whether you
use~OOP for  a particular  type, in which  case you  use \kidx{class};
otherwise, you go with  struct  and forgo the particular~OOP amenities
that go hand in hand with reference semantics.
====================

Andrei

Jun 07 2010
Kagamin <spam here.lot> writes:
Andrei Alexandrescu Wrote:

You get  to choose  at design  time  whether you
use~OOP for  a particular  type, in which  case you  use \kidx{class};
otherwise, you go with  struct  and forgo the particular~OOP amenities
that go hand in hand with reference semantics.


Jun 07 2010
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/07/2010 09:02 AM, Kagamin wrote:
Andrei Alexandrescu Wrote:

You get  to choose  at design  time  whether you use~OOP for  a
particular  type, in which  case you  use \kidx{class}; otherwise,
you go with  struct  and forgo the particular~OOP amenities that go
hand in hand with reference semantics.

made by the language designer, so if you want a feature, you're
forced to choose between languages. Well, I'm not sure whether such
book can be "about just D".

The book includes honest discussions of language design decisions,
including merits of approaches D decided to diverge from. Example:

====================
Now what  happens when  the compiler sees  the improved  definition of
find ?   The  compiler faces  a  tougher  challenge  compared to  the
int[]  case because  now\sbs  T  is not known  yet---it could be just
about any  type.  And different  types are stored  differently, passed
around differently, and  sport different definitions of~ == .  Dealing
with this  challenge is important because type  parameters really open
up possibilities and  multiply reusability of code.  When  it comes to
generating code for type  parameterization, two schools of thought are
prevalent today~\cite{pizza}:

\begin{itemize*}
\item\emph{Homogeneous  translation:}  Bring  all  data  to  a  common
format, which allows compiling only  one version of  find  that will
work for everybody.
\item\emph{Heterogeneous  translation:} Invoking   find   with various
type arguments (e.g.,  int  versus  double  versus  string ) prompts
the compiler to generate as many specialized versions of  find .
\end{itemize*}

In homogeneous  translation, the language must offer  a uniform access
interface  to data  as  a  prerequisite to  presenting  it to   find .
Heterogeneous translation  is pretty much  as if you had  an assistant
writing one special  find  for each  data format you may come up with,
all  built  from the  same  mold.   Clearly  the two  approaches  have
passionate  debates in  various  languages' communities.   Homogeneous
translation favors uniformity, simplicity, and compact generated code.
For example, traditional functional languages favor putting everything
in list  format, and many traditional  object-oriented languages favor
However,  the  disadvantages of  homogeneous  translation may  include
rigidity, lack  of expressive  power, and inefficiency.   In contrast,
heterogeneous translation favors specialization, expressive power, and
speed of generated code.  The  costs may include bloating of generated
code,  increases in  language complexity,  and an  awkward compilation
model (a frequently aired argument against heterogeneous approaches is
that they're glorified macros [gasp]; and ever since~C gave such a bad
reputation  to macros,  the  label evokes  quite  a powerful  negative
connotation).

A  detail worth  noting  is an  inclusion relationship:  heterogeneous
translation  includes homogeneous  translation for  the  simple reason
that   many   formats''   includes   one  format,''   and   many
implementations'' includes one implementation.'' Therefore it can be
argued (all other issues left aside) that heterogeneous translation is
more powerful than homogeneous translation.  If you have heterogeneous
translation  means at  your disposal,  at least  in  principle there's
nothing stopping  you from  choosing one unified  data format  and one
unified function when  you so wish. The converse  option is simply not
available  under  a  homogeneous   approach.   However,  it  would  be
oversimplifying   to  conclude   that  heterogeneous   approaches  are
better'' because aside from expressive power there are, again, other
arguments that need to be taken into consideration.

\dee~uses heterogeneous translation  with (warning, incoming technical
terms flak) statically scoped symbol lookup and deferred typechecking.
This  means  that  when  the~\dee  compiler sees  the  generic   find
definition, it parses and saves the body, remembers where the function
was defined, and does nothing  else until  find  gets called.  At that
point,  the  compiler fetches  the  parsed  definition  of  find   and
attempts to  compile it with  the type that  the caller chose  in lieu
of\sbs  T .  When the function uses symbols, they are looked up in the
context in which the function was defined.
====================

Andrei

Jun 07 2010
bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

Which part of the talk conveyed to you that information?

(as usual) wrong, I was trolling: I didn't know what I was talking about. I am
sorry. I have not even programmed in Go.

Bye,
bearophile

Jun 07 2010
Leandro Lucarella <llucax gmail.com> writes:
Adam Ruppe, el  6 de junio a las 21:24 me escribiste:
On 6/6/10, Leandro Lucarella <llucax gmail.com> wrote:
It looks like Go now have scope (exit) =)

Not quite the same (defer is apparently only on function level), but
definitely good to have. The scope statements are awesome beyond
belief.

Yes, they are not implemented exactly the same, but the concept is very
similar. And I agree that scope is really a life saver, it makes life
much easier and code much more readable.

--
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
For a minute there
I lost myself, I lost myself.
Phew, for a minute there,
I lost myself, I lost myself.

Jun 07 2010
Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el  9 de junio a las 09:52 me escribiste:
That's what I like the most about exceptions. I think try/catch is
really ugly though. There has to be something better.

Careful use of scope(exit) and simply avoiding catching exceptions works
well for me. Except when you have to catch, of course. :)

Same here. I think a good application only has few try/catch
statements, so the fact that try is a relatively heavy statement is
not very important.

I don't feel the same, but that's probably because I mostly write
programs that need to take good care of errors. Maybe the vast majority
of programs can afford exiting with a nice error message catching any
exception at main level (or simply letting the runtime print the
error/stack trace for you).

--
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Vivimos en una época muy contemporánea, Don Inodoro...
-- Mendieta

Jun 09 2010
Leandro Lucarella <llucax gmail.com> writes:
Leandro Lucarella, el  9 de junio a las 11:37 me escribiste:
Pelle, el  9 de junio a las 13:28 me escribiste:
Yes, I agree that "safety" is the best argument in favour of exceptions
(as explicitness is the best argument in favour of no-exceptions). The
Python Zen put it this way:

Errors should never pass silently.
Unless explicitly silenced.

That's what I like the most about exceptions. I think try/catch is
really ugly though. There has to be something better.

Careful use of scope(exit) and simply avoiding catching exceptions
works well for me. Except when you have to catch, of course. :)

I'm talking precisely about the case when you have to catch. In that
case I think the resulting code is uglier and more convoluted than the
code to manage errors by returning error codes or similar.

BTW, here is a PhD thesis with a case against exceptions. I didn't read
it (just have a peek) and it's rather old (1982), so it might be not
that interesting, but I thought posting it here as the thread became
mostly about exceptions and someone might be interested =)

http://web.cecs.pdx.edu/~black/publications/Black%20D.%20Phil%20Thesis.pdf

--
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Every 5 minutes an area of rainforest the size of a foot ball field
Is eliminated

Jun 09 2010
On 6/7/10, Leandro Lucarella <llucax gmail.com> wrote:
Yes, they are not implemented exactly the same, but the concept is very
similar. And I agree that scope is really a life saver, it makes life
much easier and code much more readable.

There is one important difference though: Go doesn't seem to have
scope(failure) vs scope(success). I guess it doesn't have exceptions,
so it is moot, but it looks to me like suckage.

Take some recent code I wrote:

void bid(MySql db, Money amount) {
db.query("START TRANSACTION");
scope(success) db.query("COMMIT");
scope(failure) db.query("ROLLBACK");

// moderate complex logic of verifying and storing the bid, written
as a simple linear block of code, with the faith that the scope guard
and exceptions keep everything sane
}

Just beautiful, that scales in complexity and leaves no error
unhandled. Looks like in Go, you'd be stuck mucking up the main logic
with return value checks, then use a goto fail; like pattern, which is
bah. It works reasonably well, but leaves potential for gaps in the
checking, uglies up the work code, and might have side effects on
variables. (The Go spec says goto isn't allowed to skip a variable
declaration... so when I do:

auto result = db.query();
if(result.failed) goto error; // refuses to compile thanks to the next line!
auto otherResult = db.query();

error:

Ew, gross.).

That sucks hard. I prefer it to finally{} though, since finally
doesn't scale as well in code complexity (it'd do fine in this case,
but not if there were nested transactions), but both suck compared to
the scalable, beautiful, and *correct* elegance of D's scope guards.

That said, of course, Go's defer /is/ better than nothing, and it does
have goto, so it is a step up from C. But it is leagues behind D.

Jun 07 2010
Bill Baxter <wbaxter gmail.com> writes:
--000e0cd5d1824fbefa04887526d3
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Jun 7, 2010 at 11:19 AM, Walter Bright
<newshound1 digitalmars.com>wrote:

That sucks hard. I prefer it to finally{} though, since finally
doesn't scale as well in code complexity (it'd do fine in this case,
but not if there were nested transactions), but both suck compared to
the scalable, beautiful, and *correct* elegance of D's scope guards.

I agree. D's scope statement looks fairly innocuous and one can easily pass
it by with "blah, blah, another statement, blah, blah" but the more I use it
the more I realize it is a

game changer

in how one writes code. For example, here's the D1 implementation of

-------------------------------------------------------------
...

----------------------------------------------------------

Note the complex logic to recover and unwind from errors (none of the
called functions throw exceptions), and the care with which this is
constructed to ensure everything is done properly. Contrast this with D2's
version written by Andrei:

...
The code is the same logic, but using scope it is dramatically simplified.
There's not a single control flow statement in it! Furthermore, it is
correct even if functions like CloseHandle throw exceptions.

Hmm, but I can actually understand your code.  :-(

--bb

--000e0cd5d1824fbefa04887526d3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Mon, Jun 7, 2010 at 11:19 AM, Walter Bright <=
span dir=3D"ltr">&lt;<a href=3D"mailto:newshound1 digitalmars.com">newshoun=
d1 digitalmars.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"=

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
That sucks hard. I prefer it to finally{} though, since finally<br>
doesn&#39;t scale as well in code complexity (it&#39;d do fine in this case=
,<br>
but not if there were nested transactions), but both suck compared to<br>
the scalable, beautiful, and *correct* elegance of D&#39;s scope guards.<br=

<br>
I agree. D&#39;s scope statement looks fairly innocuous and one can easily =
pass it by with &quot;blah, blah, another statement, blah, blah&quot; but t=
he more I use it the more I realize it is a<br>
<br>
=A0 =A0 =A0 =A0game changer<br>
<br>
in how one writes code. For example, here&#39;s the D1 implementation of st=
<br>
-------------------------------------------------------------<br>...</block=
quote><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
-----------------------------------<br>

<br>
Note the complex logic to recover and unwind from errors (none of the calle=
d functions throw exceptions), and the care with which this is constructed =
to ensure everything is done properly. Contrast this with D2&#39;s version =
written by Andrei:<br>

<br>...<br>
The code is the same logic, but using scope it is dramatically simplified. =
There&#39;s not a single control flow statement in it! Furthermore, it is c=
orrect even if functions like CloseHandle throw exceptions.<br>
</blockquote></div><br><div><br></div><div>Hmm, but I can actually understa=

--000e0cd5d1824fbefa04887526d3--

Jun 07 2010
Bill Baxter <wbaxter gmail.com> writes:
On Mon, Jun 7, 2010 at 12:25 PM, Walter Bright
<newshound1 digitalmars.com> wrote:
Bill Baxter wrote:
Hmm, but I can actually understand your code. =A0:-(

Yeah, but how long would it take you to be sure that it is handling all e=

ably take me at least 5 intensive minutes. But in the scope version, once y=
ou're comfortable with scope and enforce, it wouldn't take half that.

Probably so. =A0What's cenforce do anyway?
--bb

Jun 07 2010
On 6/7/10, Bill Baxter <wbaxter gmail.com> wrote:
Hmm, but I can actually understand your code.  :-(

The confusing part is probably cenforce, which is a little helper
function in the std.file module.

cenforce(condition, filename) is the same as

if( ! condition)
throw new FileException(filename, __FILE__, __LINE__, GetLastError());

So the new read() does still have control statements, but they are
hidden in that helper function template so you don't have to repeat
them all over the main code.

Then, of course, the scope guards clean up on the event of those
exceptions, so you don't have to worry about the special error labels,
which is what allows the helper function to actually be useful!

Jun 07 2010
Leandro Lucarella <llucax gmail.com> writes:
Adam Ruppe, el  7 de junio a las 11:30 me escribiste:
On 6/7/10, Leandro Lucarella <llucax gmail.com> wrote:
Yes, they are not implemented exactly the same, but the concept is very
similar. And I agree that scope is really a life saver, it makes life
much easier and code much more readable.

There is one important difference though: Go doesn't seem to have
scope(failure) vs scope(success). I guess it doesn't have exceptions,
so it is moot, but it looks to me like suckage.

Go doesn't have exceptions, so scope(failure/success) makes no sense.
You can argue about if not having exceptions is good or bad (I don't
have a strong opinion about it, sometimes I feel exceptions are nice,
sometimes I think they are evil), though.

--
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
La esperanza es una amiga que nos presta la ilusión.

Jun 07 2010
Jesse Phillips <jessekphillips+D gmail.com> writes:
On Sun, 06 Jun 2010 18:13:36 -0400, bearophile wrote:

At 9.30 you can see the switch used on a type type :-) You can see a
similar example here:
http://golang.org/src/pkg/exp/datafmt/datafmt.go Look for the line
switch t := fexpr.(type) {

...

Bye,
bearophile

That isn't a type type. Untested D code

void fun(T, U)(T op, U y) {

switch(typeof(y)) {
case "immutable(char)[]":
case "int":
}
}

Jun 07 2010
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/07/2010 07:44 PM, Jesse Phillips wrote:
On Sun, 06 Jun 2010 18:13:36 -0400, bearophile wrote:

At 9.30 you can see the switch used on a type type :-) You can see a
similar example here:
http://golang.org/src/pkg/exp/datafmt/datafmt.go Look for the line
switch t := fexpr.(type) {

...

Bye,
bearophile

That isn't a type type. Untested D code

void fun(T, U)(T op, U y) {

switch(typeof(y)) {
case "immutable(char)[]":
case "int":
}
}

Actually the uses are not equivalent. A closer example is:

class A {}

void main() {
Object a = new A;
switch (typeid(a).name) {
case "object.Object":
writeln("it's an object");
break;
case "test.A":
writeln("yeah, it's an A");
break;
default:
writeln("default: ", typeid(a).name);
break;
}
}

Go stores the dynamic types together with objects, so what looks like a
simple typedef for int is in fact a full-fledged class with one data
member. Those objects are stored on the garbage-collected heap.

Andrei

Jun 07 2010
bearophile <bearophileHUGS lycos.com> writes:
Jesse Phillips:

Thanks, the important thing to note is that D can do what Go was doing in
the example, Sorry bearophile.

First, don't be sorry, I am using D2 instead of Go. If you show me D2 is better
I am happy :-)

Second, saying that D2 can do something is not so interesting, because D2 is a
wide language, so you can do many things with it. What's important is not just
being able to do something in D, but also if such thing is idiomatic (this
means most D programmers do it).

Bye,
bearophile

Jun 08 2010
Jesse Phillips <jessekphillips+D gmail.com> writes:
Thanks, the important thing to note is that D can do what Go was doing in
the example, Sorry bearophile.

On Mon, 07 Jun 2010 19:55:06 -0500, Andrei Alexandrescu wrote:

On 06/07/2010 07:44 PM, Jesse Phillips wrote:
On Sun, 06 Jun 2010 18:13:36 -0400, bearophile wrote:

At 9.30 you can see the switch used on a type type :-) You can see a
similar example here:
http://golang.org/src/pkg/exp/datafmt/datafmt.go Look for the line
switch t := fexpr.(type) {

...

Bye,
bearophile

That isn't a type type. Untested D code

void fun(T, U)(T op, U y) {

switch(typeof(y)) {
case "immutable(char)[]":
case "int":
}
}

Actually the uses are not equivalent. A closer example is:

class A {}

void main() {
Object a = new A;
switch (typeid(a).name) {
case "object.Object":
writeln("it's an object");
break;
case "test.A":
writeln("yeah, it's an A");
break;
default:
writeln("default: ", typeid(a).name); break;
}
}

Go stores the dynamic types together with objects, so what looks like a
simple typedef for int is in fact a full-fledged class with one data
member. Those objects are stored on the garbage-collected heap.

Andrei


Jun 07 2010
Leandro Lucarella <llucax gmail.com> writes:
Ali Çehreli, el  7 de junio a las 14:41 me escribiste:
Leandro Lucarella wrote:

Go doesn't have exceptions, so scope(failure/success) makes no sense.
You can argue about if not having exceptions is good or bad (I don't
have a strong opinion about it, sometimes I feel exceptions are nice,
sometimes I think they are evil), though.

Just to compare the two styles...

Without exceptions, every step of the code must be checked explicitly:

// C code:
int foo()
{
int err = 0;

// allocate resources

err = bar();
if (err) goto finally;

err = zar();
if (err) goto finally;

err = car();
if (err) goto finally;

finally:
// do cleanup

return err;
}

(Ordinarily, the if(err) checks are hidden inside macros like
check_error, check_error_null, etc.)

With exceptions, the actual code emerges:

// C++ or D code
void foo()
{
// allocate resources

bar();
zar();
car();
}

You are right, but when I see the former code, I know exactly was it
going on, and when I see the later code I don't have a clue how errors
are handled, or if they are handled at all. And try adding the try/catch
statements, the code is even more verbose than the code without
exceptions.

Is a trade-off. When you don't handle the errors, exceptions might be
a win, but when you do handle them, I'm not so sure. And again, I'm not
saying I particularly like one more than the other, I don't have a
strong opinion =)

--
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Qué sabía Galileo de astronomía, Mendieta! Lo que pasa es que en este
país habla cualquiera.
-- Inodoro Pereyra

Jun 07 2010
nobody <someone somewhere.com> writes:
Linus Torvalds shows his opinion about why he chooses C here:

He wants a language that context-free, simple, down to the metal.
He dislikes C++ b/c it has many abstraction.

I think some D experts should post some comments.

Jun 10 2010
Walter Bright <newshound1 digitalmars.com> writes:
nobody wrote:
Linus Torvalds shows his opinion about why he chooses C here:
http://www.realworldtech.com/forums/index.cfm?action=detail&id=110618&thre
did=110549&roomid=2

He wants a language that context-free, simple, down to the metal.
He dislikes C++ b/c it has many abstraction.

I think some D experts should post some comments.

I posted a comment. We'll see.


Jun 10 2010
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/10/2010 12:36 PM, Walter Bright wrote:
nobody wrote:
Linus Torvalds shows his opinion about why he chooses C here:

He wants a language that context-free, simple, down to the metal.
He dislikes C++ b/c it has many abstraction.

I think some D experts should post some comments.

I posted a comment. We'll see.

I fear that's not going to go anywhere interesting. Linus makes a
sensible point. You do, too, but understanding that requires knowing a

Andrei

Jun 10 2010
Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
On 06/10/2010 12:36 PM, Walter Bright wrote:
I posted a comment. We'll see.

http://www.realworldtech.com/forums/index.cfm?action=detail&id=110634&thre
did=110549&roomid=2

I fear that's not going to go anywhere interesting. Linus makes a
sensible point. You do, too, but understanding that requires knowing a

I agree Linus has a good point. He may already have looked at D and have an
opinion about it. In any case, my post needed to be very short or nobody will
read it, so I am reduced to just a few teaser points.

Jun 10 2010
"Jer" <jersey chicago.com> writes:
Andrei Alexandrescu wrote:
On 06/10/2010 12:36 PM, Walter Bright wrote:
nobody wrote:
Linus Torvalds shows his opinion about why he chooses C here:

He wants a language that context-free, simple, down to the metal.
He dislikes C++ b/c it has many abstraction.

I think some D experts should post some comments.

I posted a comment. We'll see.

I fear

I believe you. Everyone is.

Jun 10 2010
bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
I posted a comment. We'll see.

This is a part of what Linus said about C++:
It tries to solve all the wrong problems, and
does not tackle the right ones. The things C++ "solves"
are trivial things, almost purely syntactic extensions to
C rather than fixing some true deep problem.

Do you know what "right" and "true deep" problems he is talking about? This can
become material to improve D3.

Bye,
bearophile

Jun 10 2010
Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
bearophile Wrote:

Walter Bright:
I posted a comment. We'll see.

This is a part of what Linus said about C++:
It tries to solve all the wrong problems, and
does not tackle the right ones. The things C++ "solves"
are trivial things, almost purely syntactic extensions to
C rather than fixing some true deep problem.

Do you know what "right" and "true deep" problems he is talking about? This
can become material to improve D3.

Bye,
bearophile

And when D3 comes out, you'll be waiting for D4?

I don't understand your posts mentioning D3. I mean, D2 isn't even finalized
yet (right?), and you're already treating the language like it came out 50
years ago and needs to be abandoned.

Just my two cents..

Jun 10 2010
"Jer" <jersey chicago.com> writes:
Andrej Mitrovic wrote:
bearophile Wrote:

Walter Bright:
I posted a comment. We'll see.

This is a part of what Linus said about C++:
It tries to solve all the wrong problems, and
does not tackle the right ones. The things C++ "solves"
are trivial things, almost purely syntactic extensions to
C rather than fixing some true deep problem.

Do you know what "right" and "true deep" problems he is talking
about? This can become material to improve D3.

Bye,
bearophile

And when D3 comes out, you'll be waiting for D4?

I don't understand your posts mentioning D3. I mean, D2 isn't even
finalized yet (right?), and you're already treating the language like
it came out 50 years ago and needs to be abandoned.

Leave him alone.

Just my two cents..

That used to be parking meter coin when we used to... nevermind. It
matters. Shut up.

Jun 10 2010
BCS <none anon.com> writes:
Hello Andrej,

And when D3 comes out, you'll be waiting for D4? I don't understand
your posts mentioning D3. I mean, D2 isn't even finalized yet
(right?), and you're already treating the language like it came out 50
years ago and needs to be abandoned.

I get the impression that some of the people here are more interested in
the development *of* D than development *in* D. In some ways, that's a good
thing, as long as we don't just produce a toy for language developers.

--
... <IXOYE><

Jun 12 2010
"Jer" <jersey chicago.com> writes:
bearophile wrote:
Walter Bright:
I posted a comment. We'll see.

This is a part of what Linus said about C++:
It tries to solve all the wrong problems, and
does not tackle the right ones. The things C++ "solves"
are trivial things, almost purely syntactic extensions to
C rather than fixing some true deep problem.

Do you know what "right" and "true deep" problems he is talking
about? This can become material to improve D3.


Jun 10 2010
"Jer" <jersey chicago.com> writes:
Walter Bright wrote:
nobody wrote:
Linus Torvalds shows his opinion about why he chooses C here:

He wants a language that context-free, simple, down to the metal.
He dislikes C++ b/c it has many abstraction.

I think some D experts should post some comments.

I posted a comment. We'll see.

Well what is the price for you to be free and go on with your life?

Jun 10 2010
Kagamin <spam here.lot> writes:
Walter Bright Wrote:

I posted a comment. We'll see.

Linus wants a readable language. D is designed to be writable. You gave him the
wrong tool.

Jun 11 2010
Jonathan M Davis <jmdavisProg gmail.com> writes:
Walter Bright wrote:

nobody wrote:
Linus Torvalds shows his opinion about why he chooses C here:

He wants a language that context-free, simple, down to the metal.
He dislikes C++ b/c it has many abstraction.

I think some D experts should post some comments.

I posted a comment. We'll see.

He seems to particularly dislike function overloading which is not only part
of D but pretty integral to object-oriented programming in general, so my
guess is that he wouldn't be all that enthused with any object-oriented
language. At minimium, it would have to give him something that he thought
While D certainly improves greatly on C++ (including in how it deals with
function overloading), it's close enough to C++ that I suspect that he
wouldn't like it either. But of course, he'd have to actually look at D and
then tell us what he thought for us to know for sure.

- Jonathan M Davis

Jun 11 2010
Walter Bright <newshound1 digitalmars.com> writes:
Jonathan M Davis wrote:
He seems to particularly dislike function overloading which is not only part
of D but pretty integral to object-oriented programming in general, so my
guess is that he wouldn't be all that enthused with any object-oriented
language. At minimium, it would have to give him something that he thought
While D certainly improves greatly on C++ (including in how it deals with
function overloading), it's close enough to C++ that I suspect that he
wouldn't like it either. But of course, he'd have to actually look at D and
then tell us what he thought for us to know for sure.

I don't expect him to switch to anything. When you've built up such a store in
one language, it would take an incredible push to change.

Nevertheless, D has some features, such as transitive immutability and purity,
scope guard and memory safety, which are a nice fit for his style of
programming.

What would be more likely is D features moving into C.

Jun 11 2010
Alex Makhotin <alex bitprox.com> writes:
Walter Bright wrote:

When you've built up such a
store in one language, it would take an incredible push to change.

Linux kernel is a large monolithic monster, one single bug can bring the
system down.
So considering this, Linus is right. He afraid of one single language
feature may be the source of myriad of bugs, just because the language
allows to use it, and assuming the worst case - everybody will misuse
the feature as they always do.

--
Alex Makhotin,
the founder of BITPROX,
http://bitprox.com

Jun 11 2010
Walter Bright <newshound1 digitalmars.com> writes:
Alex Makhotin wrote:
Walter Bright wrote:
When you've built up such a store in one language, it would take an
incredible push to change.

Linux kernel is a large monolithic monster, one single bug can bring the
system down.
So considering this, Linus is right. He afraid of one single language
feature may be the source of myriad of bugs, just because the language
allows to use it, and assuming the worst case - everybody will misuse
the feature as they always do.

I agree that there's no freakin' way the Linux kernel could be moved to another
language, regardless of the merits of that language. However, other independent
utilities could be.

Jun 11 2010
Walter Bright <newshound1 digitalmars.com> writes:
nobody wrote:
Linus Torvalds shows his opinion about why he chooses C here:
http://www.realworldtech.com/forums/index.cfm?action=detail&id=110618&thre
did=110549&roomid=2

He wants a language that context-free, simple, down to the metal.
He dislikes C++ b/c it has many abstraction.

I think some D experts should post some comments.

This showed up on reddit:


Jun 10 2010
"Jer" <jersey chicago.com> writes:
Walter Bright wrote:
nobody wrote:
Linus Torvalds shows his opinion about why he chooses C here:

He wants a language that context-free, simple, down to the metal.
He dislikes C++ b/c it has many abstraction.

I think some D experts should post some comments.

This showed up on reddit:

That's a long thing. Care to sum it up? And what is your value anyway? Do
tell. Can I buy you? How much! Can I skip college? I have a car. Hello.

Jun 10 2010
Alex Makhotin <alex bitprox.com> writes:
nobody wrote:
Linus Torvalds shows his opinion about why he chooses C here:
http://www.realworldtech.com/forums/index.cfm?action=detail&id=110618&thre
did=110549&roomid=2

He wants a language that context-free, simple, down to the metal.
He dislikes C++ b/c it has many abstraction.

I think some D experts should post some comments.

I think the context problem comes from the wrong understanding of the
OOP. The C programmers when try to write C++ object-oriented code still
continue to think in procedural and everything available(global) way.
But, object-oriented way assumes the programmer to actually think in
abstract manner.

Sure, when it comes to reading the C++ code of not mature C++
past practical experience(and he knows it works!, why abandon it?) with
OOP...
It's hard to understand what he means by writing inconsistent code.

Plus, adding poor documentation to this. Yes, to understand C++ code can
be very difficult.

My opinion on the topic is that the abstraction comes at a cost of
hidden implementation. Such hidden implementation must have good, proper
documentation, or readable interface. If programming with OOP, the
programmer must think in OOP, not C procedural way.

And few words about interfacing again.
When I agitate for the interfaces I usually mean by this: OK, your code
is good at what it does and does it well(or you think it does well),
give me proper and documented interface so that I can understand how to
use it and apply in real life.
If you do not do this, I must read your code(oh no!) and understand how
it works(isn't it the problem that your code is aimed to solve?!!), so
that I make interface in my imagination(!) on how to use your code,
eventually I will not remember all the imagined picture and therefore
dissatisfy with the code, it can even drive me not to use your code any
more, or C++ code in general.

--
Alex Makhotin,
the founder of BITPROX,
http://bitprox.com

Jun 11 2010
Walter Bright <newshound1 digitalmars.com> writes:
nobody wrote:
Linus Torvalds shows his opinion about why he chooses C here:
http://www.realworldtech.com/forums/index.cfm?action=detail&id=110618&thre
did=110549&roomid=2

He wants a language that context-free, simple, down to the metal.
He dislikes C++ b/c it has many abstraction.

This is another interesting point of view by Linus:


Jun 11 2010
Don <nospam nospam.com> writes:
Walter Bright wrote:
nobody wrote:
Linus Torvalds shows his opinion about why he chooses C here:
http://www.realworldtech.com/forums/index.cfm?action=detail&id=110618&thre
did=110549&roomid=2

He wants a language that context-free, simple, down to the metal.
He dislikes C++ b/c it has many abstraction.

This is another interesting point of view by Linus:

http://www.realworldtech.com/forums/index.cfm?action=detail&id=110699&thre
did=110549&roomid=2

Most of his complaints seem to be about OOP. I particularly like the line:
"Complicated problems don't have some simple strictly hierarchical data
structures."

I've read comments from Stepanov which criticise OOP and many of the
other features of C++, for exactly the same reasons which Linus gives.
It's interesting that their conclusions are so different.
`
Jun 16 2010