www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Google's Go

reply Steve Teale <steve.teale britseyeview.com> writes:
I see that Go has now usurped D's former place at #13 in Tiobe - which I
realize of course does not mean anything. But I'd be interested to hear what
the D aficionados think of Go.

It probably would not suit Andrei.
Jan 23 2010
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sat, Jan 23, 2010 at 12:00:04PM -0500, Steve Teale wrote:
 I see that Go has now usurped D's former place at #13 in Tiobe - which I
realize of course does not mean anything. But I'd be interested to hear what
the D aficionados think of Go.

There's been a couple threads about it before. My opinion: it is garbage. It has maybe two or three good ideas in there, but on the whole, it is a very poor showing. The arrogant developers didn't do any research into prior art when designing it, and it shows - good ideas are absent without even a mention. Bad ideas remain in there saying "this is the best we could do". The only reason it gets any attention at all is because of the names attached to it. -- Adam D. Ruppe http://arsdnet.net
Jan 23 2010
next sibling parent Bane <branimir.milosavljevic gmail.com> writes:
... Some old farts use D1 because they 
 highly respect the D-man art and Walter's ability to co-operative and 
 communicate with the community (which indeed feels really good if you 
 have zero experience on other language communities). They do not fancy 
 the new D2 features that much. And let's be honest, D1 is terribly 
 similar to a native port of C# 3.5.

Hey! This old fart here prefers D1 instead of D2 because: - it has enough features to satisfy his needs, both in language and in Phobos - it is known how it works, it works correct, and there are docs describing it - there are less things in it, so it is easier to learn and play with it Hell, if C is useful tool and you cant get simpler than it (asembler excluded), then D1 is full fledged corporate tool with great std lib. So please, don't flame D1, or youll have some angry old men on your back :)
Jan 23 2010
prev sibling parent reply grauzone <none example.net> writes:
Adam D. Ruppe wrote:
 On Sat, Jan 23, 2010 at 12:00:04PM -0500, Steve Teale wrote:
 I see that Go has now usurped D's former place at #13 in Tiobe - which I
realize of course does not mean anything. But I'd be interested to hear what
the D aficionados think of Go.

There's been a couple threads about it before. My opinion: it is garbage. It has maybe two or three good ideas in there, but on the whole, it is a very poor showing. The arrogant developers didn't do any research into prior art when designing it, and it shows - good ideas are absent without even a mention. Bad ideas remain in there saying "this is the best we could do".

Oh well, D isn't that great either. While it doesn't have such big names attached on it (although "Andrei" is not that small of a name), it had more time. What worries one most is how D rushes "to completion", just because of the deadline of that one book. It's obvious that some features are half cooked at best. Just look at the features added in D 2.038 (auto ref, DIP2): terrible hacks to get some broken language features barely to work before the deadline is over. Also notice how the compiler, after all these years, still chokes up on basic language features. The struggling of the QtD developers is a major sign for this. I wonder what the heck is wrong with dmd's internal design that the situation is that bad. I mean, Walter could get a freaking C++ compiler right, why not the compiler for his own language? /rant
 The only reason it gets any attention at all is because of the names attached
 to it.
 

Jan 23 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
grauzone wrote:
 Adam D. Ruppe wrote:
 On Sat, Jan 23, 2010 at 12:00:04PM -0500, Steve Teale wrote:
 I see that Go has now usurped D's former place at #13 in Tiobe - 
 which I realize of course does not mean anything. But I'd be 
 interested to hear what the D aficionados think of Go.

There's been a couple threads about it before. My opinion: it is garbage. It has maybe two or three good ideas in there, but on the whole, it is a very poor showing. The arrogant developers didn't do any research into prior art when designing it, and it shows - good ideas are absent without even a mention. Bad ideas remain in there saying "this is the best we could do".

Oh well, D isn't that great either. While it doesn't have such big names attached on it (although "Andrei" is not that small of a name), it had more time. What worries one most is how D rushes "to completion", just because of the deadline of that one book. It's obvious that some features are half cooked at best. Just look at the features added in D 2.038 (auto ref, DIP2): terrible hacks to get some broken language features barely to work before the deadline is over.

Meh. It's all so subjective, calling some language design "a hack" is nonfalsifiable. That reminds me of some of the Walter/Bartosz/me discussions. The first person to call something a hack usually won any argument because there was no way to counter that label sensibly. Prepend "terrible" and we have a winner. Andrei
Jan 24 2010
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Andrei Alexandrescu wrote:
 Meh. It's all so subjective, calling some language design "a hack" is
 nonfalsifiable. That reminds me of some of the Walter/Bartosz/me
 discussions. The first person to call something a hack usually won any
 argument because there was no way to counter that label sensibly.
 Prepend "terrible" and we have a winner.
 
 
 Andrei

The solution is obvious: "The use of 'hack' or 'terrible hack' to describe something is a terrible hack." That'll either end the argument or cause everyone to stackfault.
Jan 24 2010
parent Walter Bright <newshound1 digitalmars.com> writes:
Daniel Keep wrote:
 "The use of 'hack' or 'terrible hack' to describe something is a
 terrible hack."

Ah, for the good ol' days when things were simply described as a "kludge" or a "super kludge."
Jan 24 2010
prev sibling parent reply grauzone <none example.net> writes:
Andrei Alexandrescu wrote:
 grauzone wrote:
 Adam D. Ruppe wrote:
 On Sat, Jan 23, 2010 at 12:00:04PM -0500, Steve Teale wrote:
 I see that Go has now usurped D's former place at #13 in Tiobe - 
 which I realize of course does not mean anything. But I'd be 
 interested to hear what the D aficionados think of Go.

There's been a couple threads about it before. My opinion: it is garbage. It has maybe two or three good ideas in there, but on the whole, it is a very poor showing. The arrogant developers didn't do any research into prior art when designing it, and it shows - good ideas are absent without even a mention. Bad ideas remain in there saying "this is the best we could do".

Oh well, D isn't that great either. While it doesn't have such big names attached on it (although "Andrei" is not that small of a name), it had more time. What worries one most is how D rushes "to completion", just because of the deadline of that one book. It's obvious that some features are half cooked at best. Just look at the features added in D 2.038 (auto ref, DIP2): terrible hacks to get some broken language features barely to work before the deadline is over.

Meh. It's all so subjective, calling some language design "a hack" is nonfalsifiable. That reminds me of some of the Walter/Bartosz/me discussions. The first person to call something a hack usually won any argument because there was no way to counter that label sensibly. Prepend "terrible" and we have a winner.

I guess that's true. I also don't want to start a discussion about "taste" or whatever. Let me just say that those are unorthogonal, single-trick-pony features. They don't add too much value to the language, and are specially designed to cover for some annoying corner cases of other features. Please tell me how auto ref template parameters are universally useful? Or how inout(T) isn't just a shortcut to avoid writing const/immutable-aware code 3 times or putting it into a template? What's the use of auto ref returns, other than a small performance optimization? (Though I admit that min() example in the spec is cute.) Especially inout(T) seems to be only useful in one specialized situation. Could be that I'm lacking foresight, but then those questions above should be simply to answer. I don't quite get your point about non-falsifiability: you could put any optional feature into a language with that argument.
 
 Andrei

Jan 24 2010
next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Steven Schveighoffer wrote:
 On Sun, 24 Jan 2010 04:25:21 -0500, grauzone <none example.net> wrote:
 
 Or how inout(T) isn't just a shortcut to avoid writing 
 const/immutable-aware code 3 times or putting it into a template?

The benefits are: - Single implementation where all that is different is the type qualifier. (also allows the function to be virtual) - No propogation of contract through an accessor. In other words, using an inout accessor on an object or struct does not alter the caller's contract with the data itself. The latter function is almost essential for properties, for without such a mechanism, you are forced to write your property definitions in triplicate. i.e. class C {} struct S { C c; } immutable s1 = S(new C); S s2 = S(new C); immutable c1 = s1.c; C c2 = s2.c; Now, change S.c into a property. The first line of thinking is, "well, accessing c doesn't change the object itself, so it should be const." But that means you must return a const(C), so it breaks defining c1 and c2 (can't assign immutable or mutable from const). So, you say, "I'll just define it without const," but then you can't call the property unless S is a mutable type, so that only works in c2's case Maybe you think you can get away with just mutable and immutable, but again, it doesn't work if the whole object is const, since you can't call either function from there. Templates won't work here, you cannot template the 'this' pointer. So you end up with 3 identical implementations, and *no* const guarantee on the mutable one: property C c() { return _c; } property const(C) c() const { return _c; } property immutable(C) c() immutable { return _c; }

Out of curiosity: How does inout(T) fix this? I thought inout was all about transporting the const-ness of the input type to the return type, and in this example there are no input parameters. -Lars
Jan 25 2010
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
grauzone wrote:
 Andrei Alexandrescu wrote:
 grauzone wrote:
 Adam D. Ruppe wrote:
 On Sat, Jan 23, 2010 at 12:00:04PM -0500, Steve Teale wrote:
 I see that Go has now usurped D's former place at #13 in Tiobe - 
 which I realize of course does not mean anything. But I'd be 
 interested to hear what the D aficionados think of Go.

There's been a couple threads about it before. My opinion: it is garbage. It has maybe two or three good ideas in there, but on the whole, it is a very poor showing. The arrogant developers didn't do any research into prior art when designing it, and it shows - good ideas are absent without even a mention. Bad ideas remain in there saying "this is the best we could do".

Oh well, D isn't that great either. While it doesn't have such big names attached on it (although "Andrei" is not that small of a name), it had more time. What worries one most is how D rushes "to completion", just because of the deadline of that one book. It's obvious that some features are half cooked at best. Just look at the features added in D 2.038 (auto ref, DIP2): terrible hacks to get some broken language features barely to work before the deadline is over.

Meh. It's all so subjective, calling some language design "a hack" is nonfalsifiable. That reminds me of some of the Walter/Bartosz/me discussions. The first person to call something a hack usually won any argument because there was no way to counter that label sensibly. Prepend "terrible" and we have a winner.

I guess that's true. I also don't want to start a discussion about "taste" or whatever. Let me just say that those are unorthogonal, single-trick-pony features. They don't add too much value to the language, and are specially designed to cover for some annoying corner cases of other features. Please tell me how auto ref template parameters are universally useful?

Sorry, I forgot to answer these questions earlier. First off, going from unwarranted presuppositions to actual questions is definite progress. Auto ref is a long-standing need that D has had and has particular applications to SafeD. An example is getopt(): string user, site; getopt("user", &user, "site", &site); This call has a mix of rvalues and pointers in the call. In SafeD there is pressure for eliminating pointers, so ideally getopt() should be rewritten to accept: getopt("user", user, "site", site); In that case, getopt() must properly deal with mixed by-value and by-reference arguments. Another issue is perfect forwarding. If you have a function fun you can't define another function gun that forwards to fun and has the same effect. This is the hallmark of functional composition, and in a language with the option of passing by reference is a big challenge. C++ does not allow perfect forwarding, which turned out to be a crippling problem that has spurred a Sisyphic quest for partially assuaging that problem. Without auto ref and auto ref returns, D did not have perfect forwarding, and much nontrivial code was in a world of pain. A simple example was that ranges that enhance other ranges can't forward front() to the ranges they manage. I mentioned this before - just search this file: http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/range.d for "mixin". I'd mentioned this rationale once.
 Or how inout(T) isn't just a shortcut to avoid writing 
 const/immutable-aware code 3 times or putting it into a template?

I don't even understand the question. You're asking "how motherhood and apple pie aren't just great things?" I'm glad Steve took the time to answer that in detail.
 What's 
 the use of auto ref returns, other than a small performance 
 optimization? (Though I admit that min() example in the spec is cute.) 

See above.
 Especially inout(T) seems to be only useful in one specialized situation.

It's a family of situation that experience with C++ has made clear is a big issue.
 Could be that I'm lacking foresight, but then those questions above 
 should be simply to answer.

I wouldn't put it on lack of foresight more than attitude. The questions above are indeed simple to answer, and the answer does occur easily to the willing. Andrei
Jan 25 2010
prev sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
Steven Schveighoffer wrote:
 On Sun, 24 Jan 2010 04:25:21 -0500, grauzone <none example.net> wrote:

 Templates won't work here, you cannot template the 'this' pointer.  So
 you end up with 3 identical implementations, and *no* const guarantee on
 the mutable one:

  property C c() { return _c; }
  property const(C) c() const { return _c; }
  property immutable(C) c() immutable { return _c; }

Is there a known bug in 2.039 about this feature? It doesn't seem to consider the hidden this parameter: class C {} struct S { C _c; property inout(C) c() inout { return _c; } } Error: inout on return means inout must be on a parameter as well for inout inout(C)() Ali
Jan 25 2010
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steve Teale wrote:
 I see that Go has now usurped D's former place at #13 in Tiobe - which I
realize of course does not mean anything. But I'd be interested to hear what
the D aficionados think of Go.
 
 It probably would not suit Andrei.

What wouldn't? (Honest question - I don't understand.) Andrei
Jan 23 2010
parent Steve Teale <steve.teale britseyeview.com> writes:
Andrei Alexandrescu Wrote:

 Steve Teale wrote:
 I see that Go has now usurped D's former place at #13 in Tiobe - which I
realize of course does not mean anything. But I'd be interested to hear what
the D aficionados think of Go.
 
 It probably would not suit Andrei.

What wouldn't? (Honest question - I don't understand.) Andrei

I just meant no templates - forgive me ;=)
Jan 23 2010
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Steve Teale (steve.teale britseyeview.com)'s article
 I see that Go has now usurped D's former place at #13 in Tiobe - which I
realize

aficionados think of Go.
 It probably would not suit Andrei.

Well, Go's garbage collector clearly isn't very good because the language doesn't delete itself. Seriously, it may eventually evolve into a decent language, but right now it's just too minimalistic to be at all practical. Just off the top of my head from reading about it a few months ago, the lack of asserts, exceptions and Windows support is enough to turn me off to it. Multiple return values are a horrible substitute for exceptions, because they require the programmer to explicitly check the return value. (When's the last time you checked the return value of printf, or even malloc?) IMHO the best thing about exceptions is that they provide a sane default for error handling: If you don't handle them then you've effectively asserted that they can't happen in your situation. If this "assertion" fails, then our program fails fast and with an error message that massively narrows down where the problem is. I flat-out refuse to program in a language where the default is for errors to be ignored and I have to constantly write explicit error-checking boilerplate even if I don't care about handling the error.
Jan 23 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
dsimcha:
 Multiple return values are a horrible substitute for exceptions,

But I am waiting for multiple return values in D3, because they are quite handy if implemented with a nice syntax :-) Bye, bearophile
Jan 23 2010
parent bearophile <bearophileHUGS lycos.com> writes:
retard:
 You can write a string mixin that converts a string like:
   (a,b) = fun_call(c,d);
 into
   fun_call(c,d,a,b);

That's silly. Bye, bearophile
Jan 23 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Sat, 23 Jan 2010 14:16:47 -0500, bearophile wrote:

 dsimcha:
 Multiple return values are a horrible substitute for exceptions,

But I am waiting for multiple return values in D3, because they are quite handy if implemented with a nice syntax :-) Bye, bearophile

You can write a string mixin that converts a string like: (a,b) = fun_call(c,d); into fun_call(c,d,a,b); and another one that converts a string for defining functions: (int, int) fun_call(int c, int d) { ... } into void fun_call(int c, int d, out int ret1, out int ret2) { ... } I've personally used the import expression and string mixins + ctfe instead of ordinary D imports to implement rather nice language extensions by parsing the language on module level.
Jan 23 2010
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
dsimcha wrote:
 IMHO the best thing
 about exceptions is that they provide a sane default for error handling:  If
you
 don't handle them then you've effectively asserted that they can't happen in
your
 situation.  If this "assertion" fails, then our program fails fast and with an
 error message that massively narrows down where the problem is.

It's even better than that. Since the default handling for exceptions is to print a pretty message, like "cannot open file xxxxx", for many utility programs that is all you need. You don't have to write any error handling code, and yet your program handles errors correctly and gracefully reports them to the user.
Jan 23 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 dsimcha wrote:
 IMHO the best thing
 about exceptions is that they provide a sane default for error 
 handling:  If you
 don't handle them then you've effectively asserted that they can't 
 happen in your
 situation.  If this "assertion" fails, then our program fails fast and 
 with an
 error message that massively narrows down where the problem is.

It's even better than that. Since the default handling for exceptions is to print a pretty message, like "cannot open file xxxxx", for many utility programs that is all you need. You don't have to write any error handling code, and yet your program handles errors correctly and gracefully reports them to the user.

I wouldn't go that far. Unfortunately, writing even exception-neutral code still changes the way one writes code even if you don't need to handle errors explicitly (fortunately scope statements help with that). Andrei
Jan 23 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 Walter Bright wrote:
 Since the default handling for exceptions 
 is to print a pretty message, like "cannot open file xxxxx", for many 
 utility programs that is all you need. You don't have to write any 
 error handling code, and yet your program handles errors correctly and 
 gracefully reports them to the user.

I wouldn't go that far. Unfortunately, writing even exception-neutral code still changes the way one writes code even if you don't need to handle errors explicitly (fortunately scope statements help with that).

I agree that scope statements are only necessary if you need to recover from errors. I don't know what you mean by how it changes the way one writes code.
Jan 23 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 Andrei Alexandrescu wrote:
 Walter Bright wrote:
 Since the default handling for exceptions is to print a pretty 
 message, like "cannot open file xxxxx", for many utility programs 
 that is all you need. You don't have to write any error handling 
 code, and yet your program handles errors correctly and gracefully 
 reports them to the user.

I wouldn't go that far. Unfortunately, writing even exception-neutral code still changes the way one writes code even if you don't need to handle errors explicitly (fortunately scope statements help with that).

I agree that scope statements are only necessary if you need to recover from errors. I don't know what you mean by how it changes the way one writes code.

I mean even if ostensibly you don't want to handle errors, you still need to mind the multiple hidden exit paths in your code to achieve even the most intuitive guarantees (such as temporarily changing a global for the duration of a function). Such a style of coding blindsides old-style SESE programmers (and is the main reason for which I unrecommend SESE). Andrei
Jan 23 2010
parent Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 I mean even if ostensibly you don't want to handle errors, you still 
 need to mind the multiple hidden exit paths in your code to achieve even 
 the most intuitive guarantees (such as temporarily changing a global for 
 the duration of a function). Such a style of coding blindsides old-style 
 SESE programmers (and is the main reason for which I unrecommend SESE).

I agree. That makes sense.
Jan 23 2010
prev sibling next sibling parent reply grauzone <none example.net> writes:
dsimcha wrote:
 Multiple return values are a horrible substitute for exceptions, because they
 require the programmer to explicitly check the return value.  (When's the last
 time you checked the return value of printf, or even malloc?)  IMHO the best
thing
 about exceptions is that they provide a sane default for error handling:  If
you
 don't handle them then you've effectively asserted that they can't happen in
your
 situation.  If this "assertion" fails, then our program fails fast and with an
 error message that massively narrows down where the problem is.  I flat-out
refuse
 to program in a language where the default is for errors to be ignored and I
have
 to constantly write explicit error-checking boilerplate even if I don't care
about
 handling the error.

Exception handling in D (or C++/Java for that matter) isn't that great either. In D, you don't even know what exceptions a function may throw. It's completely dynamic. You may even accidentally catch unknown exceptions, because your catch-filter isn't "narrow" enough. Java has checked exceptions, but they are misdesigned, get in the programmers way, and generally suck. Feels almost like D copied the standard Java feature by the letter, removing checked exceptions, and call that an improvement. Also, let's have a look how exceptions improve the robustness of most Java code: try { something(); } catch (Exception e) { Logger.getLogger().log(e); } I guess D programmers are just better than D programmers, which makes this example out of place, of course. Or they just let it fall through, until it gets catched by a similar catch-all statement. Generally, exceptions as they are implemented in some popular languages seem to give the impression that you don't need to care about error handling. That isn't always true and probably only works in small command line tools.
Jan 23 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
grauzone wrote:
 dsimcha wrote:
 Multiple return values are a horrible substitute for exceptions, 
 because they
 require the programmer to explicitly check the return value.  (When's 
 the last
 time you checked the return value of printf, or even malloc?)  IMHO 
 the best thing
 about exceptions is that they provide a sane default for error 
 handling:  If you
 don't handle them then you've effectively asserted that they can't 
 happen in your
 situation.  If this "assertion" fails, then our program fails fast and 
 with an
 error message that massively narrows down where the problem is.  I 
 flat-out refuse
 to program in a language where the default is for errors to be ignored 
 and I have
 to constantly write explicit error-checking boilerplate even if I 
 don't care about
 handling the error.

Exception handling in D (or C++/Java for that matter) isn't that great either. In D, you don't even know what exceptions a function may throw. It's completely dynamic. You may even accidentally catch unknown exceptions, because your catch-filter isn't "narrow" enough. Java has checked exceptions, but they are misdesigned, get in the programmers way, and generally suck. Feels almost like D copied the standard Java feature by the letter, removing checked exceptions, and call that an improvement.

For my money, D2 exceptions (as designed and described in TDPL) are better than all other exception frameworks, by a mile. This is mainly because D offers a practical methods of handling collateral exceptions (exceptions thrown during the stack unwinding caused by other exceptions).
 Also, let's have a look how exceptions improve the robustness of most 
 Java code:
 
 try { something(); } catch (Exception e) { Logger.getLogger().log(e); }
 
 I guess D programmers are just better than D programmers, which makes 
 this example out of place, of course. Or they just let it fall through, 
 until it gets catched by a similar catch-all statement.
 
 Generally, exceptions as they are implemented in some popular languages 
 seem to give the impression that you don't need to care about error 
 handling. That isn't always true and probably only works in small 
 command line tools.

I agree! I'd put it even stronger. Andrei
Jan 24 2010
prev sibling parent reply Justin Johansson <no spam.com> writes:
dsimcha wrote:
 
 Multiple return values are a horrible substitute for exceptions, because they
 require the programmer to explicitly check the return value.  (When's the last
 time you checked the return value of printf, or even malloc?)  IMHO the best
thing
 about exceptions is that they provide a sane default for error handling:  If
you
 don't handle them then you've effectively asserted that they can't happen in
your
 situation.  If this "assertion" fails, then our program fails fast and with an
 error message that massively narrows down where the problem is.  I flat-out
refuse
 to program in a language where the default is for errors to be ignored and I
have
 to constantly write explicit error-checking boilerplate even if I don't care
about
 handling the error.

Well, back in C++ land, as an occasional alternative to using exceptions, I use a templated "checked_value" structure for returning an error code / function result pair. The C++ templated structure is shown below. A function returning a "checked_value" uses the first constructor form to return a valid result and the second form to return an erroneous result (using an enum to designate the error condition). If client code tries to access the value (via the overloaded cast operator, or you could have a getter function for the value instead), and an error is in effect that you didn't check for, then shit (an assert or other severity) happens. I'm sure there will be lots of religious comments about this idiom, but it works well for me by forcing a check for an error result before otherwise using the return value. Of course, this idiom only works if the function in question "returns something", a value, that the client code would by necessity have to use. It wouldn't (and couldn't) work if ValueType is "void". In the exceptional case (pun intended) of functions returning void, one may have to resort to throwing an exception instead to signal an error. So to counter the dsimcha's point, my solution does not assume a default situation of ignoring errors. The thrust of my argument is that exceptions are not an all-or-nothing approach in sane dealing in errors. template <typename ValueType> struct checked_value { public: checked_value( ValueType value) : _value( value), _rcode( RC_OK) {} checked_value( resultCode_t rcode) : _value( ValueType::PROP_INIT), _rcode( rcode) {} operator ValueType() const { // The value should not be accessible if the function failed. // Choose your poison with either assert or something // more severe in release compile if you don't like asserts // being preprocessed out. assert(!failed()); return _value; } int failed() const { return (_rcode < RC_OK); } resultCode rcode() const { return _rcode; } private: ValueType const _value; ResultCode const _rcode; }; Cheers Justin Johansson
Jan 26 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Justin Johansson:
 So to counter the dsimcha's point, my solution does
 not assume a default situation of ignoring errors. The thrust
 of my argument is that exceptions are not an all-or-nothing
 approach in sane dealing in errors.

In GCC there is also the "warn_unused_result" function attribute that raises a compile time warning if you don't use the return value of a function: http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#index-g_t_0040code_007bwarn_005funused_005fresult_007d-attribute-2444 You can use it to be more sure you are reading and using an error return value. Ideally you can invent a similar "error_unused_result" that raises an error instead. (Some other of those GCC attributes can be useful in D2). Bye, bearophile
Jan 26 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:
 In GCC there is also the "warn_unused_result" function attribute that
 raises a compile time warning if you don't use the return value of a
 function: 

That may wind up suffering similar problems as checked exceptions do - just do a quick and dirty assign the return value to a hastily declared temp and ignore it, meaning to fix it later. Of course, it doesn't actually get fixed later. Even worse, during code reviews, it will look like the code is paying attention to the error code, but it won't be.
Jan 26 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 That may wind up suffering similar problems as checked exceptions do - 
 just do a quick and dirty assign the return value to a hastily declared 
 temp and ignore it, meaning to fix it later.

Oh, I agree that exceptions are generally better (but that warn_unused_result of GCC can be used in C too where you don't have D-like exceptions). Regarding exceptions, I don't think you can find many of them in game engines written in C++, where performance matters.
 Of course, it doesn't actually get fixed later. Even worse, during code 
 reviews, it will look like the code is paying attention to the error 
 code, but it won't be.

Something similar can happen with exceptions, you can wrap something in a try-catch to silence the possible exceptions. Bye, bearophile
Jan 26 2010
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 bearophile wrote:
 In GCC there is also the "warn_unused_result" function attribute that
 raises a compile time warning if you don't use the return value of a
 function: 

That may wind up suffering similar problems as checked exceptions do - just do a quick and dirty assign the return value to a hastily declared temp and ignore it, meaning to fix it later. Of course, it doesn't actually get fixed later. Even worse, during code reviews, it will look like the code is paying attention to the error code, but it won't be.

I'd think in a code review a variable assigned and subsequently never used is bound to raise a red flag. Andrei
Jan 26 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 Walter Bright wrote:
 bearophile wrote:
 In GCC there is also the "warn_unused_result" function attribute that
 raises a compile time warning if you don't use the return value of a
 function: 

That may wind up suffering similar problems as checked exceptions do - just do a quick and dirty assign the return value to a hastily declared temp and ignore it, meaning to fix it later. Of course, it doesn't actually get fixed later. Even worse, during code reviews, it will look like the code is paying attention to the error code, but it won't be.

I'd think in a code review a variable assigned and subsequently never used is bound to raise a red flag.

I agree, if it was noticed. For me, int result = foo(); in the code implies that 'result' is later used. I'd have to search to see if it wasn't, which is harder than noticing that: foo(); ignores the result. This goes back to my theory that a feature that encourages the programmer to insert misleading dead code to shut the compiler up is a misfeature.
Jan 26 2010
parent reply "John D" <jdean googling.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hjni3o$r26$1 digitalmars.com...
 Andrei Alexandrescu wrote:
 Walter Bright wrote:
 bearophile wrote:
 In GCC there is also the "warn_unused_result" function attribute 
 that
 raises a compile time warning if you don't use the return value of a
 function:

That may wind up suffering similar problems as checked exceptions do - just do a quick and dirty assign the return value to a hastily declared temp and ignore it, meaning to fix it later. Of course, it doesn't actually get fixed later. Even worse, during code reviews, it will look like the code is paying attention to the error code, but it won't be.

I'd think in a code review a variable assigned and subsequently never used is bound to raise a red flag.

I agree, if it was noticed. For me, int result = foo(); in the code implies that 'result' is later used. I'd have to search to see if it wasn't, which is harder than noticing that: foo(); ignores the result. This goes back to my theory that a feature that encourages the programmer to insert misleading dead code to shut the compiler up is a misfeature.

A programmer who does the above is not a good programmer. That said, a compiler that doesn't warn that variables or arguments have gone unused in a function is not a good compiler. That said, a language that doesn't enforce return val checking is not a good programming language.
Jan 29 2010
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
John D wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 This goes back to my theory that a feature that encourages the 
 programmer to insert misleading dead code to shut the compiler up is a 
 misfeature.


The reality is, even the best programmers will do such things if it is convenient to, even if they preach against it and know it is wrong.
 That said, a 
 compiler that doesn't warn that variables or arguments have gone unused 
 in a function is not a good compiler. That said, a language that doesn't 
 enforce return val checking is not a good programming language. 

I often have unused variables and such when developing and debugging code, and when using conditional compilation, and having the compiler nag me about them would be very irritating.
Jan 30 2010
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hk1v87$1pem$1 digitalmars.com...
 John D wrote:
 That said, a compiler that doesn't warn that variables or arguments have 
 gone unused in a function is not a good compiler. That said, a language 
 that doesn't enforce return val checking is not a good programming 
 language.

I often have unused variables and such when developing and debugging code, and when using conditional compilation, and having the compiler nag me about them would be very irritating.

Only if they're fatal conditions. As non-fatal warnings that irritation dissapears.
Jan 30 2010
prev sibling parent reply "John D" <jdean googling.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hk1v87$1pem$1 digitalmars.com...
 John D wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message
 This goes back to my theory that a feature that encourages the 
 programmer to insert misleading dead code to shut the compiler up is 
 a misfeature.


The reality is, even the best programmers will do such things if it is convenient to, even if they preach against it and know it is wrong.

That is oxymoronic: can't be "the best" without discipline and self-control. Also "know thyself" is important: if a programmer really doesn't feel like programming and would rather be out playing softball, he should go out and play software instead of just hacking. IMO, but ideals and abstract discussions like this, especially in text, are not very useful, so let's end what I started.
 That said, a compiler that doesn't warn that variables or arguments 
 have gone unused in a function is not a good compiler. That said, a 
 language that doesn't enforce return val checking is not a good 
 programming language.

I often have unused variables and such when developing and debugging code, and when using conditional compilation, and having the compiler nag me about them would be very irritating.

So you are indeed saying that the D compiler gives no such warnings, or that you programming at a lower warning level? Personally, I always program with the highest warning level turned on. I don't regularly generate so many warnings, but rather errors and that seems somehow correct to me. If I made a compiler for my proprietary business, there would be no switching to a lower warning level, but then I'm a hard-ass director I guess. Please don't assume that I'm suggesting that others should use my methods, for I am not. I'm just stating what I do and what I would/will require of others working for me ("with" me is a whole new ballgame for me).
Jan 30 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
John D wrote:
 So you are indeed saying that the D compiler gives no such warnings,

That's right.
Jan 30 2010
parent "John D" <jdean googling.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hk3bjj$1k1q$1 digitalmars.com...
 John D wrote:
 So you are indeed saying that the D compiler gives no such warnings,

That's right.

Because it is "D" ?
Jan 31 2010
prev sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from John D (jdean googling.com)'s article
 A programmer who does the above is not a good programmer. That said, a
 compiler that doesn't warn that variables or arguments have gone unused
 in a function is not a good compiler. That said, a language that doesn't
 enforce return val checking is not a good programming language.

Think about it for a minute. When is the last time you checked the return value for printf() in C? Would you really want the compiler nagging you about something like this?
Jan 30 2010
parent "John D" <jdean googling.com> writes:
"dsimcha" <dsimcha yahoo.com> wrote in message 
news:hk24v0$23di$1 digitalmars.com...
 == Quote from John D (jdean googling.com)'s article
 A programmer who does the above is not a good programmer. That said, a
 compiler that doesn't warn that variables or arguments have gone 
 unused
 in a function is not a good compiler. That said, a language that 
 doesn't
 enforce return val checking is not a good programming language.

Think about it for a minute. When is the last time you checked the return value for printf() in C? Would you really want the compiler nagging you about something like this?

I have thought about it that's why I stated it instead of writing it as a question. (I'm being a little bit facetious, cuz there is more than one way to solve a problem). I can restate it as a Q though, for it is a language design question: Requiring that all return values must be checked by the developer and having it enforced by the language specification and compiler: good or bad?
Jan 30 2010
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hjnd9r$dtp$1 digitalmars.com...
 bearophile wrote:
 In GCC there is also the "warn_unused_result" function attribute that
 raises a compile time warning if you don't use the return value of a
 function:

That may wind up suffering similar problems as checked exceptions do - just do a quick and dirty assign the return value to a hastily declared temp and ignore it, meaning to fix it later.

It it were an error (or treated as an error or a D-style "warning"), then yes. But as a true warning, not so much.
Jan 26 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Nick Sabalausky wrote:
 It it were an error (or treated as an error or a D-style "warning"), then 
 yes. But as a true warning, not so much. 

Many shops require that warnings be treated as hard errors. Furthermore, a warning that is not an error tends to become ignored background noise over time. (The infamous Windows Vista permission box is a fine example of that.)
Jan 26 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hjnidq$s0p$1 digitalmars.com...
 Nick Sabalausky wrote:
 It it were an error (or treated as an error or a D-style "warning"), then 
 yes. But as a true warning, not so much.

Many shops require that warnings be treated as hard errors.

In which case it's no longer a "true warning", so that doesn't really affect what I said. Besides, if a shop does make that a hard-and-fast requirement, then by doing so they are the creating the situation you described of causing programmers to hide problems in code without verifying first that it's not actually a problem. So a compiler like DMD obviously doesn't do a damn thing to change that. In fact, it just encourages that scenario in not just those shops, but in all the other ones as well. Sure, those other shops could just leave warnings off, but then you're recreating the scenario where the warnings become background noise, except it's worse because nobody even has a chance to pay attention to them.
 Furthermore, a warning that is not an error tends to become ignored 
 background noise over time. (The infamous Windows Vista permission box is 
 a fine example of that.)

I *do* investigate and handle all my warnings before checking code in (note that that's significantly different from warnings being unoptionally coerced into errors by the compiler, because in the latter case I may need to silence a warning because I'm momentarily in the middle of trying to deal with something else). And even if a time constraint requires me to just get it checked in before I can deal with the warnings, I still make damn sure to get around to it (and, to date, I always have). When I investigate a warning, if it turns out to be a problem, then I fix the problem. If it turns out to not be a problem, then I do go and do what I need to halt the warning, *but* it's perfectly fine because *I've already verified there's no problem being covered up*. Any time any coder compiles their code and sees a stream of white noise warnings, that should be a red flag that they're approaching development wrong. Now yes, that *does* happen, and many coders *do* ignore that stuff, and yes, if there is something we can do to improve that situation without causing additional problems, then we should. But DMD's approach *doesn't actually do a damn thing to improve the situation*. In fact, it just *encourages* it: DMD's philosophy with warnings: It's bad to go blindly covering up warnings because they might be indicating a real problem, and it's bad to ignore your warnings as white noise for the same reason. Therefore, we should provide the user with two options: Use "-w" to be forced to silence the warnings before proceeding, and thus be provided with *more* motivation/temptation to blindly cover them up, or omit "-w" to make it even easier to ignore all warnings. Ie, all the problems you've identified with warnings are valid concerns, but DMD's "solution" clearly exacerbates those problems rather than alleviating them.
Jan 26 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Nick Sabalausky wrote:
 I *do* investigate and handle all my warnings before checking code in (note 
 that that's significantly different from warnings being unoptionally coerced 
 into errors by the compiler, because in the latter case I may need to 
 silence a warning because I'm momentarily in the middle of trying to deal 
 with something else). And even if a time constraint requires me to just get 
 it checked in before I can deal with the warnings, I still make damn sure to 
 get around to it (and, to date, I always have). When I investigate a 
 warning, if it turns out to be a problem, then I fix the problem. If it 
 turns out to not be a problem, then I do go and do what I need to halt the 
 warning, *but* it's perfectly fine because *I've already verified there's no 
 problem being covered up*.

You might know that, but the maintainer wouldn't. Furthermore, when such warnings pop up in code you didn't write and don't understand but was dumped in your lap, you'd do what everyone else does in such situations, which is throw in the minimal code necessary to get rid of the warning, and move on. I agree that a conscientious and careful developer would never do such things. But they do. Even the ones who write articles and books saying "do not do this" will admit to doing it. When it's convenient and easy to do the wrong thing, people will do it. Even the ones who know better, and promise themselves they won't do it, do it. The language should be designed as much as possible so that the right thing is the easy and convenient thing to do. Using exceptions for error handling fits right in with that. There's no incentive in D, for example, of doing the Java thing of "swallow and ignore all exceptions."
Jan 26 2010
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hjnr0l$1jl5$1 digitalmars.com...
 Nick Sabalausky wrote:
 I *do* investigate and handle all my warnings before checking code in 
 (note that that's significantly different from warnings being 
 unoptionally coerced into errors by the compiler, because in the latter 
 case I may need to silence a warning because I'm momentarily in the 
 middle of trying to deal with something else). And even if a time 
 constraint requires me to just get it checked in before I can deal with 
 the warnings, I still make damn sure to get around to it (and, to date, I 
 always have). When I investigate a warning, if it turns out to be a 
 problem, then I fix the problem. If it turns out to not be a problem, 
 then I do go and do what I need to halt the warning, *but* it's perfectly 
 fine because *I've already verified there's no problem being covered up*.

You might know that, but the maintainer wouldn't.

Informing maintainers of things that aren't obvious from the code is what comments are for. And yes, yes, yes, comments don't always get made or updated, but 1. that's a different issue, and much more importantly, 2. there's nothing about DMD's philosophy of warnings that gets around that problem anyway. Sure, D designs things to avoid the need for a warning in the first place, whenever possible (and that's great), but the problem is, it's not always possible. And for the cases when it isn't possible, and the need for a warning does arise, and the original coder gets that warning, verifies that it's ok, and then quiets it to prevent future warnings from being overlooked in misdst of a pile of old-but-ok warnings (which is exactly what he should do in that situation), then we're still right back to "There isn't a damn thing that can be done to help the maintainer know that besides hoping an approptiate comment was made".
 Furthermore, when such warnings pop up in code you didn't write and don't 
 understand but was dumped in your lap, you'd do what everyone else does in 
 such situations, which is throw in the minimal code necessary to get rid 
 of the warning, and move on.

I might be tempted to do that *if* warnings are both fatal and non-optional, but other than that, I can't imagine why in the world I, or even any random lazy programmer for that matter, would go around blindly silencing non-fatal warnings in unfamiliar code. There's no potential benefit in doing that, not even a perceived benefit.
 I agree that a conscientious and careful developer would never do such 
 things. But they do. Even the ones who write articles and books saying "do 
 not do this" will admit to doing it.

 When it's convenient and easy to do the wrong thing, people will do it. 
 Even the ones who know better, and promise themselves they won't do it, do 
 it.

Yes, that's bad, and it's a problem. But as I already explained, forcing all warnings to be either fatal or disabled can do nothing but *encourage* such bad practices even *more*.
 The language should be designed as much as possible so that the right 
 thing is the easy and convenient thing to do.

Right, which is why the language/compiler shouldn't make it *more* tempting to blindly silence warnings by preventing the programmer from continuing their immediate task until all warnings are either hidden (ie turned off) or squelched.
 Using exceptions for error handling fits right in with that.
 There's no incentive in D, for example, of doing the Java thing of 
 "swallow and ignore all exceptions."

I absolutely agree with that. The thing I was originally objecting to was the idea that GCC's warn_unused_result warning, when used *as* as warning (ie, not in a "warnings are/must be treated as errors" context) "may wind up suffering similar problems as checked exceptions do". Then I guess I got sidetracked on DMD's warnings philosophy.
Jan 26 2010
prev sibling parent reply Rainer Deyke <rainerd eldwood.com> writes:
Walter Bright wrote:
 When it's convenient and easy to do the wrong thing, people will do it.
 Even the ones who know better, and promise themselves they won't do it,
 do it.

WRT warnings, DMD doesn't just make it convenient and easy to do the wrong thing, it /forces/ you to do the wrong thing. -- Rainer Deyke - rainerd eldwood.com
Jan 26 2010
parent Don <nospam nospam.com> writes:
Rainer Deyke wrote:
 Walter Bright wrote:
 When it's convenient and easy to do the wrong thing, people will do it.
 Even the ones who know better, and promise themselves they won't do it,
 do it.

WRT warnings, DMD doesn't just make it convenient and easy to do the wrong thing, it /forces/ you to do the wrong thing.

Except that DMD doesn't really have any incorrect warnings any more. The only time that you get a warning that isn't necessarily a bug in your code is with implicit conversions. Once the range-tracking implicit conversion rules for arithmetic operations are fully implemented, all of the warnings could be turned into errors, and DMD could lose the -w switch.
Jan 27 2010
prev sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Justin Johansson (no spam.com)'s article
 dsimcha wrote:
 Multiple return values are a horrible substitute for exceptions, because they
 require the programmer to explicitly check the return value.  (When's the last
 time you checked the return value of printf, or even malloc?)  IMHO the best
thing
 about exceptions is that they provide a sane default for error handling:  If
you
 don't handle them then you've effectively asserted that they can't happen in
your
 situation.  If this "assertion" fails, then our program fails fast and with an
 error message that massively narrows down where the problem is.  I flat-out
refuse
 to program in a language where the default is for errors to be ignored and I
have
 to constantly write explicit error-checking boilerplate even if I don't care
about
 handling the error.

exceptions, I use a templated "checked_value" structure for returning an error code / function result pair. The C++ templated structure is shown below. A function returning a "checked_value" uses the first constructor form to return a valid result and the second form to return an erroneous result (using an enum to designate the error condition). If client code tries to access the value (via the overloaded cast operator, or you could have a getter function for the value instead), and an error is in effect that you didn't check for, then shit (an assert or other severity) happens. I'm sure there will be lots of religious comments about this idiom, but it works well for me by forcing a check for an error result before otherwise using the return value. Of course, this idiom only works if the function in question "returns something", a value, that the client code would by necessity have to use. It wouldn't (and couldn't) work if ValueType is "void". In the exceptional case (pun intended) of functions returning void, one may have to resort to throwing an exception instead to signal an error. So to counter the dsimcha's point, my solution does not assume a default situation of ignoring errors. The thrust of my argument is that exceptions are not an all-or-nothing approach in sane dealing in errors. template <typename ValueType> struct checked_value { public: checked_value( ValueType value) : _value( value), _rcode( RC_OK) {} checked_value( resultCode_t rcode) : _value( ValueType::PROP_INIT), _rcode( rcode) {} operator ValueType() const { // The value should not be accessible if the function failed. // Choose your poison with either assert or something // more severe in release compile if you don't like asserts // being preprocessed out. assert(!failed()); return _value; } int failed() const { return (_rcode < RC_OK); } resultCode rcode() const { return _rcode; } private: ValueType const _value; ResultCode const _rcode; }; Cheers Justin Johansson

Nice. This is probably a good idea in situations where it **always** makes sense for the immediate caller to handle the error. Only problem is that Go! doesn't have asserts either.
Jan 26 2010
parent reply Justin Johansson <no spam.com> writes:
dsimcha wrote:
 == Quote from Justin Johansson (no spam.com)'s article
 dsimcha wrote:
 Multiple return values are a horrible substitute for exceptions, because they
 require the programmer to explicitly check the return value.  (When's the last
 time you checked the return value of printf, or even malloc?)  IMHO the best
thing
 about exceptions is that they provide a sane default for error handling:  If
you
 don't handle them then you've effectively asserted that they can't happen in
your
 situation.  If this "assertion" fails, then our program fails fast and with an
 error message that massively narrows down where the problem is.  I flat-out
refuse
 to program in a language where the default is for errors to be ignored and I
have
 to constantly write explicit error-checking boilerplate even if I don't care
about
 handling the error.

exceptions, I use a templated "checked_value" structure for returning an error code / function result pair. The C++ templated structure is shown below. A function returning a "checked_value" uses the first constructor form to return a valid result and the second form to return an erroneous result (using an enum to designate the error condition). If client code tries to access the value (via the overloaded cast operator, or you could have a getter function for the value instead), and an error is in effect that you didn't check for, then shit (an assert or other severity) happens. I'm sure there will be lots of religious comments about this idiom, but it works well for me by forcing a check for an error result before otherwise using the return value. Of course, this idiom only works if the function in question "returns something", a value, that the client code would by necessity have to use. It wouldn't (and couldn't) work if ValueType is "void". In the exceptional case (pun intended) of functions returning void, one may have to resort to throwing an exception instead to signal an error. So to counter the dsimcha's point, my solution does not assume a default situation of ignoring errors. The thrust of my argument is that exceptions are not an all-or-nothing approach in sane dealing in errors. template <typename ValueType> struct checked_value { public: checked_value( ValueType value) : _value( value), _rcode( RC_OK) {} checked_value( resultCode_t rcode) : _value( ValueType::PROP_INIT), _rcode( rcode) {} operator ValueType() const { // The value should not be accessible if the function failed. // Choose your poison with either assert or something // more severe in release compile if you don't like asserts // being preprocessed out. assert(!failed()); return _value; } int failed() const { return (_rcode < RC_OK); } resultCode rcode() const { return _rcode; } private: ValueType const _value; ResultCode const _rcode; }; Cheers Justin Johansson

Nice.

 This is probably a good idea in situations where it **always** makes sense
 for the immediate caller to handle the error.

at hand. AAMOF, I use it as a static function in a class wrapping the constructor to prevalidate arguments passed to the constructor. Now (1) For some reason (possibly valid only in an historic context), I have this great aversion to throwing exceptions from inside C++ constructors. From memory, I once threw an exception from inside a constructor with an early C++ compiler and wound up with stack corruption or something like that, and consequently I developed the practice of forever more avoiding throwing from inside a C++ constructor. (2) Also, and this might be urban myth, I'm of the belief that a try block does not come for free at runtime even if an exception is not thrown (i.e. there's a cost to establishing the try block itself), that for performance critical code the old fashion return and check error code idiom is faster. I wonder if our resident C++ compiler writer can shine any truth on (1). With (2), can people either confirm (A) that it is true that try{} is not completely and absolutely free, or (B) that (2) is urban myth.
 Only problem is that Go! doesn't have asserts either.

in which the word "Go" translates to "joke" in English. I tried it for a few days when it was first announced and no matter how much I tried to give Go a "fair go", as we say in Australia, the experience felt like going back 30 years in terms of it's language maturity. Cheers Justin Johansson
Jan 26 2010
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Justin Johansson wrote:
 (1) For some reason (possibly valid only in an historic context), I have 
 this great aversion to throwing exceptions from inside C++ constructors. 
  From memory, I once threw an exception from inside a constructor
 with an early C++ compiler and wound up with stack corruption or 
 something like that, and consequently I developed the practice of 
 forever more avoiding throwing from inside a C++ constructor.

I'm a believer in the methodology that a constructor should be "trivial" in that it cannot fail (i.e. cannot throw). I'm probably in the minority with that view, but you shouldn't feel like you're doing the wrong thing when you stick to such a style. C++ constructors throwing should work according to the C++ standard.
 (2) Also, and this might be urban myth, I'm of the belief that a try
 block does not come for free at runtime even if an exception is not 
 thrown (i.e. there's a cost to establishing the try block itself),
 that for performance critical code the old fashion return and check
 error code idiom is faster.

With 32 bit Windows, there is a small penalty even when not throwing. With Linux and 64 bit Windows, there is no penalty. dmd will attempt to optimize away try blocks if the statements in them are all nothrow.
Jan 26 2010
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Justin Johansson wrote:
 (1) For some reason (possibly valid only in an historic context), I have
 this great aversion to throwing exceptions from inside C++ constructors.
  From memory, I once threw an exception from inside a constructor
 with an early C++ compiler and wound up with stack corruption or
 something like that, and consequently I developed the practice of
 forever more avoiding throwing from inside a C++ constructor.

in that it cannot fail (i.e. cannot throw). I'm probably in the minority with that view, but you shouldn't feel like you're doing the wrong thing when you stick to such a style.

I've never understood the recommendation not to put complex logic in the constructor. If you need complex logic to establish the class's invariant, or need to initialize complicated immutable data structures, where else is that logic supposed to go?
Jan 26 2010
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
dsimcha wrote:
 I've never understood the recommendation not to put complex logic in the
 constructor.

Complex logic is fine, just logic that cannot fail.
 If you need complex logic to establish the class's invariant, or
 need to initialize complicated immutable data structures, where else is that
logic
 supposed to go?

For example, allocating resources that might fail, can be done with a separate initialization function: auto c = new Class; c.create();
Jan 26 2010
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hjnt03$1od9$1 digitalmars.com...
 dsimcha wrote:
 I've never understood the recommendation not to put complex logic in the
 constructor.

Complex logic is fine, just logic that cannot fail.
 If you need complex logic to establish the class's invariant, or
 need to initialize complicated immutable data structures, where else is 
 that logic
 supposed to go?

For example, allocating resources that might fail, can be done with a separate initialization function: auto c = new Class; c.create();

But then you're right back into manual-resource-management-land (yes, I know, not for the GCed memory used to store the object, but besides that, yea, manual-resource-management-land). More specifically, you'll need to (or at least, *should*) set up a way for the object to keep track of whether or not it's been properly initialized, and then have all other accesses to it throw exceptions or something until it is properly inited. And since it's useless until it's inited (or at least not fully-useful), plus the fact that those "accessed an uninited Foo" exceptions will be popping up in places *other* than where you tried-to-create-the-Foo-but-forgot-to-init (which is where you'd ideally want the exception to origninate from because that's where the real problem is), this means we should ideally create a factory function to encapsulate both the instatiation and initilization. And the constructor and init function should now be private to force all instantiations through the safer factory function. And now, finally, our reward for all that work: We've reinvented the wheel^H^H^H^H^H^H constructor! And with a syntax that's inconsistent with all the other classes! Wheee!!!
Jan 26 2010
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 dsimcha wrote:
 I've never understood the recommendation not to put complex logic in the
 constructor.

Complex logic is fine, just logic that cannot fail.
 If you need complex logic to establish the class's invariant, or
 need to initialize complicated immutable data structures, where else 
 is that logic
 supposed to go?

For example, allocating resources that might fail, can be done with a separate initialization function: auto c = new Class; c.create();

I think this approach is stilted. Andrei
Jan 26 2010
prev sibling parent reply "John D" <jdean googling.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hjnt03$1od9$1 digitalmars.com...
 dsimcha wrote:
 I've never understood the recommendation not to put complex logic in 
 the
 constructor.

Complex logic is fine, just logic that cannot fail.
 If you need complex logic to establish the class's invariant, or
 need to initialize complicated immutable data structures, where else 
 is that logic
 supposed to go?

For example, allocating resources that might fail, can be done with a separate initialization function: auto c = new Class; c.create();

Commonly called "2 step construction". But you forgot to add the check on the return val from c.create().
Jan 29 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
John D wrote:
 Commonly called "2 step construction". But you forgot to add the check on 
 the return val from c.create(). 

No need to - c.create() should throw if it fails.
Jan 30 2010
parent reply "John D" <jdean googling.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hk1uso$1omt$2 digitalmars.com...
 John D wrote:
 Commonly called "2 step construction". But you forgot to add the check 
 on the return val from c.create().

No need to - c.create() should throw if it fails.

What's the point of doing 2-step construction if not to avoid exceptions?
Jan 30 2010
next sibling parent "Nick Sabalausky" <a a.a> writes:
"John D" <jdean googling.com> wrote in message 
news:hk33sm$186d$1 digitalmars.com...
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:hk1uso$1omt$2 digitalmars.com...
 John D wrote:
 Commonly called "2 step construction". But you forgot to add the check 
 on the return val from c.create().

No need to - c.create() should throw if it fails.

What's the point of doing 2-step construction if not to avoid exceptions?

To avoid having a constructor that throws exceptions...Although I still fail to see how it's useful to avoid that in D.
Jan 30 2010
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
John D wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:hk1uso$1omt$2 digitalmars.com...
 John D wrote:
 Commonly called "2 step construction". But you forgot to add the check 
 on the return val from c.create().


What's the point of doing 2-step construction if not to avoid exceptions?

It's so the default initialization cannot fail, which is handy in cases where dealing with failure is problematic.
Jan 30 2010
parent reply "John D" <jdean googling.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hk3bld$1k1q$2 digitalmars.com...
 John D wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:hk1uso$1omt$2 digitalmars.com...
 John D wrote:
 Commonly called "2 step construction". But you forgot to add the 
 check on the return val from c.create().


What's the point of doing 2-step construction if not to avoid exceptions?

It's so the default initialization cannot fail, which is handy in cases where dealing with failure is problematic.

Pffft. Said the backend compiler writer. So let it be written.
Jan 31 2010
parent "Nick Sabalausky" <a a.a> writes:
"John D" <jdean googling.com> wrote in message 
news:hk3f9m$1t0f$1 digitalmars.com...
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:hk3bld$1k1q$2 digitalmars.com...
 John D wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:hk1uso$1omt$2 digitalmars.com...
 John D wrote:
 Commonly called "2 step construction". But you forgot to add the check 
 on the return val from c.create().


What's the point of doing 2-step construction if not to avoid exceptions?

It's so the default initialization cannot fail, which is handy in cases where dealing with failure is problematic.

Pffft. Said the backend compiler writer. So let it be written.

Why are you even here?
Jan 31 2010
prev sibling parent Justin Johansson <no spam.com> writes:
dsimcha wrote:
 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Justin Johansson wrote:
 (1) For some reason (possibly valid only in an historic context), I have
 this great aversion to throwing exceptions from inside C++ constructors.
  From memory, I once threw an exception from inside a constructor
 with an early C++ compiler and wound up with stack corruption or
 something like that, and consequently I developed the practice of
 forever more avoiding throwing from inside a C++ constructor.

in that it cannot fail (i.e. cannot throw). I'm probably in the minority with that view, but you shouldn't feel like you're doing the wrong thing when you stick to such a style.

I've never understood the recommendation not to put complex logic in the constructor. If you need complex logic to establish the class's invariant, or need to initialize complicated immutable data structures, where else is that logic supposed to go?

I do (especially when working with immutable value classes). A good use of OO classes is to bind/glue/cement a few pieces of your programming task jigsaw puzzle together. This you do with a constructor meaning that once you have a few pieces of the puzzle nutted out (and prevalidated), you use a constructor to associate the pieces together under the umbrella of a single object which can be thought of as a tuple of values or a row in a table. It would be unusual in relational DB terms to create a new row in a table and validate the columns after the event. Forms are filled out, fields validate and only when all's good does one commit that to a database (by creating a new row in a table). The same philosophy holds in an OO programming language. At best, it's a hint of code that could be better refactored, and, at worse, it's a sure sign of a bad design to check any of the following after the event (that's is after deciding to create a new instance of a class, tuple or row as the case may be): (1) parameters passed to a constructor inside constructor (2) individual values in a constructed tuple (3) columns in the row of a DB table (4) attribute values of an object inside constructor This argument is programming language agnostic, and leans on the acknowledged benefits of immutable structures and functional programming. Furthermore, and I think this is the most compelling point for not throwing exceptions in constructors is when a class is declared with const members. When declaring such a class, the const members of the class need to be assigned up front from the arguments passed to the constructor. This means that there would not be any opportunity to throw an exception anyway until execution enters the body of the constructor code. In C++ it's done like this (and surely in D it's similar .. I forget not having D for six months) ... class Foo { public: Bar const bar; // const means need to write // : bar( aBar) after constructor // argument list. // cannot write bar = aBar in ctor body Foo( Bar aBar) : bar( aBar) { // Do "complex logic" here and // check Bar value now for validity (after // it's already been assigned to member) // and throw an exception now if it's no // good the devil asks? } } Cheers Justin Johansson
Jan 26 2010
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Walter Bright wrote:
 Justin Johansson wrote:
 (1) For some reason (possibly valid only in an historic context), I 
 have this great aversion to throwing exceptions from inside C++ 
 constructors.  From memory, I once threw an exception from inside a 
 constructor
 with an early C++ compiler and wound up with stack corruption or 
 something like that, and consequently I developed the practice of 
 forever more avoiding throwing from inside a C++ constructor.

I'm a believer in the methodology that a constructor should be "trivial" in that it cannot fail (i.e. cannot throw). I'm probably in the minority with that view, but you shouldn't feel like you're doing the wrong thing when you stick to such a style.

auto x = new BigInt(someString); How do you implement BigInt's constructor without being able to throw an exception? Or would you do it like: auto x = BigInt.fromString(someString); to be able to throw? (just to obey the "no throw in constructors"... but that's not as trivial as the previous form)
Jan 26 2010
next sibling parent reply Justin Johansson <no spam.com> writes:
Ary Borenszweig wrote:
 Walter Bright wrote:
 Justin Johansson wrote:
 (1) For some reason (possibly valid only in an historic context), I 
 have this great aversion to throwing exceptions from inside C++ 
 constructors.  From memory, I once threw an exception from inside a 
 constructor
 with an early C++ compiler and wound up with stack corruption or 
 something like that, and consequently I developed the practice of 
 forever more avoiding throwing from inside a C++ constructor.

I'm a believer in the methodology that a constructor should be "trivial" in that it cannot fail (i.e. cannot throw). I'm probably in the minority with that view, but you shouldn't feel like you're doing the wrong thing when you stick to such a style.

auto x = new BigInt(someString); How do you implement BigInt's constructor without being able to throw an exception? Or would you do it like: auto x = BigInt.fromString(someString); to be able to throw? (just to obey the "no throw in constructors"... but that's not as trivial as the previous form)

A factory method is the way to go. Different languages give you different means for achieving this design pattern but nevertheless all such means make for the better factoring of code. In C++ there are three means :- (1) Use of static class member, so your example would like like this: BigInt x = BitInt::fromString( someString); (2) Use of () function call operator overload on a factory class so your example would now look like this BigIntFactory bigIntFactory; // may be statically declared BigInt x = bigIntFactory( someString); (3) Global function, which I won't discuss any futher for obvious reasons. In D, similar to C++, though function call () operator overload is effected in much cleaner fashion with D's absolutely wonderful static opCall. So your example would look something like this (as said earlier I haven't done D for 6 months so pls forgive any error in detail) : class BigInt { static BigInt opCall( someString) { if (!validate( someString)) throw someError; // extract data for BitInt instance somehow // from string .. maybe tied into validate function byte[] bigIntData = ... return new BigInt( bigIntData); } this( byte[] bigIntData) { this.bigIntData = bigIntData; } private: byte[] bigIntData; // other BigInt methods ... } Now in D, BigInt x = BigInt( someString); In Java, well, let's not discuss that here. :-) In Scala you have "companion classes" that go hand-in-hand with the regular class. Scala uses companion classes to reduce the noise that the static class members introduce in other languages. (Example anybody?) Summary for D: It really isn't that much work to use D's static opCall() to good effect and, IMHO, complex designs do end up a lot cleaner. As they say, necessity is the mother of invention. It seems to me that both Scala and D have been driven by necessity in the design of companion classes and static opCall respectively. Cheers Justin Johansson
Jan 26 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Justin Johansson" <no spam.com> wrote in message 
news:hjo31b$275o$1 digitalmars.com...
 Ary Borenszweig wrote:
 Walter Bright wrote:
 Justin Johansson wrote:
 (1) For some reason (possibly valid only in an historic context), I 
 have this great aversion to throwing exceptions from inside C++ 
 constructors.  From memory, I once threw an exception from inside a 
 constructor
 with an early C++ compiler and wound up with stack corruption or 
 something like that, and consequently I developed the practice of 
 forever more avoiding throwing from inside a C++ constructor.

I'm a believer in the methodology that a constructor should be "trivial" in that it cannot fail (i.e. cannot throw). I'm probably in the minority with that view, but you shouldn't feel like you're doing the wrong thing when you stick to such a style.

auto x = new BigInt(someString); How do you implement BigInt's constructor without being able to throw an exception? Or would you do it like: auto x = BigInt.fromString(someString); to be able to throw? (just to obey the "no throw in constructors"... but that's not as trivial as the previous form)

A factory method is the way to go. Different languages give you different means for achieving this design pattern but nevertheless all such means make for the better factoring of code.

Still within the context of this D BigInt example, what benefit does using a factory method provide over a throwing constructor? I've always seen factories as falling into one of two categories: 1. A hack to get around a limitation in a language's constructor feature. or 2. Part of a helper API (I guess the kids are calling those "facades" these days...) for pre-configuring a new instance in a commonly-useful, but non-default way.
Jan 26 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick Sabalausky wrote:
 "Justin Johansson" <no spam.com> wrote in message 
 news:hjo31b$275o$1 digitalmars.com...
 Ary Borenszweig wrote:
 Walter Bright wrote:
 Justin Johansson wrote:
 (1) For some reason (possibly valid only in an historic context), I 
 have this great aversion to throwing exceptions from inside C++ 
 constructors.  From memory, I once threw an exception from inside a 
 constructor
 with an early C++ compiler and wound up with stack corruption or 
 something like that, and consequently I developed the practice of 
 forever more avoiding throwing from inside a C++ constructor.

in that it cannot fail (i.e. cannot throw). I'm probably in the minority with that view, but you shouldn't feel like you're doing the wrong thing when you stick to such a style.

How do you implement BigInt's constructor without being able to throw an exception? Or would you do it like: auto x = BigInt.fromString(someString); to be able to throw? (just to obey the "no throw in constructors"... but that's not as trivial as the previous form)

different means for achieving this design pattern but nevertheless all such means make for the better factoring of code.

Still within the context of this D BigInt example, what benefit does using a factory method provide over a throwing constructor? I've always seen factories as falling into one of two categories: 1. A hack to get around a limitation in a language's constructor feature. or 2. Part of a helper API (I guess the kids are calling those "facades" these days...) for pre-configuring a new instance in a commonly-useful, but non-default way.

Factories are mostly (imho) important in the fourth scenario: when you want to create an object from data. Andrei
Jan 26 2010
parent reply "John D" <jdean googling.com> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:hjo75f$2g30$1 digitalmars.com...
 Nick Sabalausky wrote:
 "Justin Johansson" <no spam.com> wrote in message 
 news:hjo31b$275o$1 digitalmars.com...
 Ary Borenszweig wrote:
 Walter Bright wrote:
 Justin Johansson wrote:
 (1) For some reason (possibly valid only in an historic context), 
 I have this great aversion to throwing exceptions from inside C++ 
 constructors.  From memory, I once threw an exception from inside 
 a constructor
 with an early C++ compiler and wound up with stack corruption or 
 something like that, and consequently I developed the practice of 
 forever more avoiding throwing from inside a C++ constructor.

"trivial" in that it cannot fail (i.e. cannot throw). I'm probably in the minority with that view, but you shouldn't feel like you're doing the wrong thing when you stick to such a style.

How do you implement BigInt's constructor without being able to throw an exception? Or would you do it like: auto x = BigInt.fromString(someString); to be able to throw? (just to obey the "no throw in constructors"... but that's not as trivial as the previous form)

different means for achieving this design pattern but nevertheless all such means make for the better factoring of code.

Still within the context of this D BigInt example, what benefit does using a factory method provide over a throwing constructor? I've always seen factories as falling into one of two categories: 1. A hack to get around a limitation in a language's constructor feature. or 2. Part of a helper API (I guess the kids are calling those "facades" these days...) for pre-configuring a new instance in a commonly-useful, but non-default way.

Factories are mostly (imho) important in the fourth scenario: when you want to create an object from data.

I vote for #3: Factories are most important for getting interfaces out of dynamic libraries.
Jan 29 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"John D" <jdean googling.com> wrote in message 
news:hk0mph$2dt6$1 digitalmars.com...
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:hjo75f$2g30$1 digitalmars.com...
 Nick Sabalausky wrote:
 Still within the context of this D BigInt example, what benefit does 
 using a factory method provide over a throwing constructor?

 I've always seen factories as falling into one of two categories: 1. A 
 hack to get around a limitation in a language's constructor feature. or 
 2. Part of a helper API (I guess the kids are calling those "facades" 
 these days...) for pre-configuring a new instance in a commonly-useful, 
 but non-default way.

Factories are mostly (imho) important in the fourth scenario: when you want to create an object from data.

I vote for #3: Factories are most important for getting interfaces out of dynamic libraries.

Can you elaborate on this?
Jan 30 2010
parent reply "John D" <jdean googling.com> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:hk3bij$1k4q$1 digitalmars.com...
 "John D" <jdean googling.com> wrote in message 
 news:hk0mph$2dt6$1 digitalmars.com...
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:hjo75f$2g30$1 digitalmars.com...
 Nick Sabalausky wrote:
 Still within the context of this D BigInt example, what benefit does 
 using a factory method provide over a throwing constructor?

 I've always seen factories as falling into one of two categories: 1. 
 A hack to get around a limitation in a language's constructor 
 feature. or 2. Part of a helper API (I guess the kids are calling 
 those "facades" these days...) for pre-configuring a new instance in 
 a commonly-useful, but non-default way.

Factories are mostly (imho) important in the fourth scenario: when you want to create an object from data.

I vote for #3: Factories are most important for getting interfaces out of dynamic libraries.

Can you elaborate on this?

I can. But I shouldn't have to. So shut up.
Jan 31 2010
parent "Nick Sabalausky" <a a.a> writes:
"John D" <jdean googling.com> wrote in message 
news:hk3f9n$1t0f$2 digitalmars.com...
 "Nick Sabalausky" <a a.a> wrote in message 
 news:hk3bij$1k4q$1 digitalmars.com...
 "John D" <jdean googling.com> wrote in message 
 news:hk0mph$2dt6$1 digitalmars.com...
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:hjo75f$2g30$1 digitalmars.com...
 Nick Sabalausky wrote:
 Still within the context of this D BigInt example, what benefit does 
 using a factory method provide over a throwing constructor?

 I've always seen factories as falling into one of two categories: 1. A 
 hack to get around a limitation in a language's constructor feature. 
 or 2. Part of a helper API (I guess the kids are calling those 
 "facades" these days...) for pre-configuring a new instance in a 
 commonly-useful, but non-default way.

Factories are mostly (imho) important in the fourth scenario: when you want to create an object from data.

I vote for #3: Factories are most important for getting interfaces out of dynamic libraries.

Can you elaborate on this?

I can. But I shouldn't have to. So shut up.

I see we have another superdan on our hands. If it even is another...This screwball did show up around the time superdan disappeared.
Jan 31 2010
prev sibling parent Yigal Chripun <yigal100 gmail.com> writes:
On 27/01/2010 02:57, Justin Johansson wrote:
 Ary Borenszweig wrote:
 Walter Bright wrote:
 Justin Johansson wrote:
 (1) For some reason (possibly valid only in an historic context), I
 have this great aversion to throwing exceptions from inside C++
 constructors. From memory, I once threw an exception from inside a
 constructor
 with an early C++ compiler and wound up with stack corruption or
 something like that, and consequently I developed the practice of
 forever more avoiding throwing from inside a C++ constructor.

I'm a believer in the methodology that a constructor should be "trivial" in that it cannot fail (i.e. cannot throw). I'm probably in the minority with that view, but you shouldn't feel like you're doing the wrong thing when you stick to such a style.

auto x = new BigInt(someString); How do you implement BigInt's constructor without being able to throw an exception? Or would you do it like: auto x = BigInt.fromString(someString); to be able to throw? (just to obey the "no throw in constructors"... but that's not as trivial as the previous form)

A factory method is the way to go. Different languages give you different means for achieving this design pattern but nevertheless all such means make for the better factoring of code. In C++ there are three means :- (1) Use of static class member, so your example would like like this: BigInt x = BitInt::fromString( someString); (2) Use of () function call operator overload on a factory class so your example would now look like this BigIntFactory bigIntFactory; // may be statically declared BigInt x = bigIntFactory( someString); (3) Global function, which I won't discuss any futher for obvious reasons. In D, similar to C++, though function call () operator overload is effected in much cleaner fashion with D's absolutely wonderful static opCall. So your example would look something like this (as said earlier I haven't done D for 6 months so pls forgive any error in detail) : class BigInt { static BigInt opCall( someString) { if (!validate( someString)) throw someError; // extract data for BitInt instance somehow // from string .. maybe tied into validate function byte[] bigIntData = ... return new BigInt( bigIntData); } this( byte[] bigIntData) { this.bigIntData = bigIntData; } private: byte[] bigIntData; // other BigInt methods ... } Now in D, BigInt x = BigInt( someString); In Java, well, let's not discuss that here. :-) In Scala you have "companion classes" that go hand-in-hand with the regular class. Scala uses companion classes to reduce the noise that the static class members introduce in other languages. (Example anybody?) Summary for D: It really isn't that much work to use D's static opCall() to good effect and, IMHO, complex designs do end up a lot cleaner. As they say, necessity is the mother of invention. It seems to me that both Scala and D have been driven by necessity in the design of companion classes and static opCall respectively. Cheers Justin Johansson

Factories are a hack to overcome limitations of the language, mainly the fact that constructors aren't virtual. The above solution(s) have two main drawbacks: testability and Multi-threading will be affected.
Jan 31 2010
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Ary Borenszweig wrote:
 auto x = new BigInt(someString);
 
 How do you implement BigInt's constructor without being able to throw an 
 exception?

I presume you mean how can it work without allocating memory. In D, a memory allocation failure is generally not a recoverable exception, it's a fatal exception. A better example would be one that attempted to open a file in the constructor.
Jan 26 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hjo5t3$2dqq$1 digitalmars.com...
 Ary Borenszweig wrote:
 auto x = new BigInt(someString);

 How do you implement BigInt's constructor without being able to throw an 
 exception?

I presume you mean how can it work without allocating memory. In D, a memory allocation failure is generally not a recoverable exception, it's a fatal exception. A better example would be one that attempted to open a file in the constructor.

I think he meant that passing it something like "Hello, Fred." should be disallowed.
Jan 26 2010
parent Ary Borenszweig <ary esperanto.org.ar> writes:
Nick Sabalausky wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:hjo5t3$2dqq$1 digitalmars.com...
 Ary Borenszweig wrote:
 auto x = new BigInt(someString);

 How do you implement BigInt's constructor without being able to throw an 
 exception?

I presume you mean how can it work without allocating memory. In D, a memory allocation failure is generally not a recoverable exception, it's a fatal exception. A better example would be one that attempted to open a file in the constructor.

I think he meant that passing it something like "Hello, Fred." should be disallowed.

Yes, that. I don't see another way rather than throwing an exception. Or maybe just do like ruby, when you do "hello".to_i it gives you zero but then you have to check it later. I don't like factory methods like BigInt.fromString. If I want to create a BigInt from a string I should use the constructor, why not?
Jan 27 2010
prev sibling parent "John D" <jdean googling.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hjnrej$1kpc$1 digitalmars.com...
 Justin Johansson wrote:
 (1) For some reason (possibly valid only in an historic context), I 
 have this great aversion to throwing exceptions from inside C++ 
 constructors. From memory, I once threw an exception from inside a 
 constructor
 with an early C++ compiler and wound up with stack corruption or 
 something like that, and consequently I developed the practice of 
 forever more avoiding throwing from inside a C++ constructor.

I'm a believer in the methodology that a constructor should be "trivial" in that it cannot fail (i.e. cannot throw).

Me too. (It's not "a methodology" though, just a style or coding guideline/requirement).
 I'm probably in the minority with that view,

C++ is called a "multi-paradigm language", but one of the most widely used paradigms of C++ is never included in the list along will OO, generic, procedural, etc. The one curiously omitted from the lists is RAII. That "lil thing" will PERMEATE a program's architecture. I'm of the persuasion that Initialization Is Not Resource Aquisition (IINRA). At the very least, RAII violates the principle of Separation of Concerns. More of a problem though is that RAII paradigm FORCES you to use exceptions rather than another/other error handling technique(s): it takes away your choice and sucks in a complex language feature and all its surrounding issues.
 but you shouldn't feel like you're doing the wrong thing when you stick 
 to such a style.

(That's better: "style" instead of "methodology").
Jan 29 2010
prev sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Justin Johansson wrote:
 (1) For some reason (possibly valid only in an historic context), I hav=

 this great aversion to throwing exceptions from inside C++ constructors=

  From memory, I once threw an exception from inside a constructor
 with an early C++ compiler and wound up with stack corruption or
 something like that, and consequently I developed the practice of
 forever more avoiding throwing from inside a C++ constructor.
=20
 (2) Also, and this might be urban myth, I'm of the belief that a try
 block does not come for free at runtime even if an exception is not
 thrown (i.e. there's a cost to establishing the try block itself),
 that for performance critical code the old fashion return and check
 error code idiom is faster.
=20
 I wonder if our resident C++ compiler writer can shine any truth on (1)=

=20
 With (2), can people either confirm (A) that it is true that try{}
 is not completely and absolutely free, or (B) that (2) is urban myth.
=20

then the destructor is never called and you risk leaking like crazy. Regarding point (2), it depends on your compiler. Recent g++ versions may use something called "DWARF exception unwinding" which costs nothing so long as you don't throw. Older versions (or when there is a risk that some stack frames won't be in the right format, like on windows) use setjmp and longjmp. In that case, the try block costs a setjmp (plus whatever is required for making the jmp_buf thread-local). I don't know how other compilers handle it. Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jan 26 2010
next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
Jérôme M. Berger wrote:
 	Throwing exception inside constructors should be avoided because
 then the destructor is never called and you risk leaking like crazy.

That's necessarily so, because calling the destructor on the incomplete object might cause other troubles. On the other hand, the destructors of all of the constructed members are called when the encapsulating object's constructor throws. Exception-safe programming in C++ consists of a handful of guidelines that takes care of throwing from constructors. Ali
Jan 26 2010
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Ali =C3=87ehreli wrote:
 J=C3=A9r=C3=B4me M. Berger wrote:
     Throwing exception inside constructors should be avoided because
 then the destructor is never called and you risk leaking like crazy.

That's necessarily so, because calling the destructor on the incomplete=

 object might cause other troubles.
=20
 On the other hand, the destructors of all of the constructed members ar=

 called when the encapsulating object's constructor throws.
=20

Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jan 27 2010
parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

J=C3=A9r=C3=B4me M. Berger wrote:
 Ali =C3=87ehreli wrote:
 J=C3=A9r=C3=B4me M. Berger wrote:
     Throwing exception inside constructors should be avoided because
 then the destructor is never called and you risk leaking like crazy.



 object might cause other troubles.

 On the other hand, the destructors of all of the constructed members a=


 called when the encapsulating object's constructor throws.

=20

Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jan 27 2010
prev sibling next sibling parent Rainer Deyke <rainerd eldwood.com> writes:
Jérôme M. Berger wrote:
 	Throwing exception inside constructors should be avoided because
 then the destructor is never called and you risk leaking like crazy.

That's not an issue if you properly encapsulate your resources. One class, one responsibility. Consider (C++): class C { C() { ... } Resource a, b, c; }; If any of the resource constructors throw, construction of the 'C' object is aborted and the any Resource objects that have already been constructed are properly destroyed. By the time the body of the 'C' constructor is entered, all the resource already exist and are guaranteed to be properly disposed of. If you have a struct/class that performs more than one logical action in its constructor and/or destructor, refactor it into several structs/classes. -- Rainer Deyke - rainerd eldwood.com
Jan 26 2010
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
""Jrme M. Berger"" <jeberger free.fr> wrote in message 
news:hjnrhv$1l0k$1 digitalmars.com...
Throwing exception inside constructors should be avoided because
then the destructor is never called and you risk leaking like crazy.

That's a risk outside of constructors too. Hence: scope(failure) {}
Jan 26 2010
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Nick Sabalausky wrote:
 ""J=EF=BF=BDr=EF=BF=BDme M. Berger"" <jeberger free.fr> wrote in messag=

 news:hjnrhv$1l0k$1 digitalmars.com...
 Throwing exception inside constructors should be avoided because
 then the destructor is never called and you risk leaking like crazy.

That's a risk outside of constructors too. Hence: =20 scope(failure) {} =20

- Outside of constructor, there is no problem because the destructor is called. Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jan 27 2010
parent reply "Nick Sabalausky" <a a.a> writes:
Nick Sabalausky wrote:
 ""J?r?me M. Berger"" <jeberger free.fr> wrote in message
 news:hjnrhv$1l0k$1 digitalmars.com...
 Throwing exception inside constructors should be avoided because
 then the destructor is never called and you risk leaking like crazy.

That's a risk outside of constructors too. Hence: scope(failure) {}


Well, I was really only talking about D. I guess the answer to "Should throwing exceptions in a constructor be avoided?" is "Depends on the language." For C++, constructors have historically had a number of tricky edge cases (though I couldn't really remember what), so I'm not surprised that throwing exceptions is one of them. For D though, I'm not sure I see that there's a problem.
- Outside of constructor, there is no problem because the destructor
is called.

1. Not always true in D (though that's a more general problem with D destructors). 2. There can be times when some cleanup would be needed that isn't in a destructor (especially in D since destructors can't be relied on actually being called.)
Jan 27 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick Sabalausky wrote:
 Nick Sabalausky wrote:
 ""J?r?me M. Berger"" <jeberger free.fr> wrote in message
 news:hjnrhv$1l0k$1 digitalmars.com...
 Throwing exception inside constructors should be avoided because
 then the destructor is never called and you risk leaking like crazy.

scope(failure) {}


Well, I was really only talking about D. I guess the answer to "Should throwing exceptions in a constructor be avoided?" is "Depends on the language." For C++, constructors have historically had a number of tricky edge cases (though I couldn't really remember what), so I'm not surprised that throwing exceptions is one of them. For D though, I'm not sure I see that there's a problem.

The edge cases involve member initialization that throws. The root of the matter is that in C++ you can't have a type with a guaranteed nothrow constructor. That makes a lot of things very difficult when it comes to object composition. I've aired a number of times the idea that the parameterless constructor should not throw. That would simplify many issues, but there are still cases when that doesn't work (nonull!!!) Andrei
Jan 27 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Sat, 23 Jan 2010 12:11:37 -0500, Adam D. Ruppe wrote:

 On Sat, Jan 23, 2010 at 12:00:04PM -0500, Steve Teale wrote:
 I see that Go has now usurped D's former place at #13 in Tiobe - which
 I realize of course does not mean anything. But I'd be interested to
 hear what the D aficionados think of Go.

There's been a couple threads about it before. My opinion: it is garbage. It has maybe two or three good ideas in there, but on the whole, it is a very poor showing. The arrogant developers didn't do any research into prior art when designing it, and it shows - good ideas are absent without even a mention. Bad ideas remain in there saying "this is the best we could do". The only reason it gets any attention at all is because of the names attached to it.

Now this is a valuable comment - thanks for sharing it :) I wonder how much D rides on Walter's and your fame. I mean the "D marketing" I see all over the web doesn't often build on facts. People just like the C++ look'n'feel so they can write the same (P)OOP code on native level to gain a constant efficiency bonus. Some old farts use D1 because they highly respect the D-man art and Walter's ability to co-operative and communicate with the community (which indeed feels really good if you have zero experience on other language communities). They do not fancy the new D2 features that much. And let's be honest, D1 is terribly similar to a native port of C# 3.5. In other words, the professional developers often know what to expect from a tool and D2 is pretty awesome tool for a professional. But the large masses gather around languages that allow implementing buggy, sub- optimal toy projects easily. If we look at e.g. Haskell, building a simple tic tac toe turns out to be impossible for most programmers. Even a hello world seems rather complex since you need to understand the monads. Go isn't especially good for building large enterprise software or operating systems, but you can easily build a text mode tictactoe game, and a large company supports the language ecosystem. That draws a lot of attention.
Jan 23 2010
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Steve Teale" <steve.teale britseyeview.com> wrote in message 
news:hjf9uk$1trp$1 digitalmars.com...
I see that Go has now usurped D's former place at #13 in Tiobe - which I 
realize of course does not mean anything. But I'd be interested to hear 
what the D aficionados think of Go.

 It probably would not suit Andrei.

It's a gimped, obfuscated and immature imitation of D. It's little more than a concurrency-model experiment masquerading as a real language. Also: - As far as I'm concerned, its real name is "Issue 9" (search "google go issue 9"). - It's the Buick/Cadillac/Oldsmobile of computer languages: Garbage that gets attention solely because of the name(s) attached. - Does nothing to change my opinion that Google has done nothing noteworthy outside of search engines and maybe their ad service.
Jan 23 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:hjff0j$27i2$1 digitalmars.com...
 - Does nothing to change my opinion that Google has done nothing 
 noteworthy outside of search engines and maybe their ad service.

And their maps, of course. But then again, how google, of all companies, can't manage to get the non-JS fallback to work cleanly and reliabily is beyond me (or how they can't manage to *start* the map centered around the search point instead of starting it elsewhere and slowing scrolling it to the center as it does now, or can't figure out that not everybody needs that damn pop-up bubble on the search point *every* single time they do a map search). Even mapquest was able to pull that stuff off years ago.
Jan 23 2010
parent grauzone <none example.net> writes:
Nick Sabalausky wrote:
 "Nick Sabalausky" <a a.a> wrote in message 
 news:hjff0j$27i2$1 digitalmars.com...
 - Does nothing to change my opinion that Google has done nothing 
 noteworthy outside of search engines and maybe their ad service.

And their maps, of course. But then again, how google, of all companies, can't manage to get the non-JS fallback to work cleanly and reliabily is

I don't think Google _wants_ it to work. Whenever I use something from Google (other than the web search), I get the feeling they want to force me to enable JS. Maybe disabling JS gets into the way of their ad- and data mining features, or they want to force Web 2.0 on everyone.
 beyond me (or how they can't manage to *start* the map centered around the 
 search point instead of starting it elsewhere and slowing scrolling it to 
 the center as it does now, or can't figure out that not everybody needs that 
 damn pop-up bubble on the search point *every* single time they do a map 
 search). Even mapquest was able to pull that stuff off years ago. 
 
 

Jan 23 2010
prev sibling next sibling parent reply Bane <branimir.milosavljevic gmail.com> writes:
Nick Sabalausky Wrote:

 "Steve Teale" <steve.teale britseyeview.com> wrote in message 
 news:hjf9uk$1trp$1 digitalmars.com...
I see that Go has now usurped D's former place at #13 in Tiobe - which I 
realize of course does not mean anything. But I'd be interested to hear 
what the D aficionados think of Go.

 It probably would not suit Andrei.

It's a gimped, obfuscated and immature imitation of D. It's little more than a concurrency-model experiment masquerading as a real language. Also: - As far as I'm concerned, its real name is "Issue 9" (search "google go issue 9"). - It's the Buick/Cadillac/Oldsmobile of computer languages: Garbage that gets attention solely because of the name(s) attached. - Does nothing to change my opinion that Google has done nothing noteworthy outside of search engines and maybe their ad service.

It looks like to me they are making Google Goo for prestige. Search engine, browser, now programming language... Whats next? OS? Laptops? Fast food franchise?
Jan 23 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bane wrote:
 Nick Sabalausky Wrote:
 
 "Steve Teale" <steve.teale britseyeview.com> wrote in message 
 news:hjf9uk$1trp$1 digitalmars.com...
 I see that Go has now usurped D's former place at #13 in Tiobe - which I 
 realize of course does not mean anything. But I'd be interested to hear 
 what the D aficionados think of Go.

 It probably would not suit Andrei.

It's little more than a concurrency-model experiment masquerading as a real language. Also: - As far as I'm concerned, its real name is "Issue 9" (search "google go issue 9"). - It's the Buick/Cadillac/Oldsmobile of computer languages: Garbage that gets attention solely because of the name(s) attached. - Does nothing to change my opinion that Google has done nothing noteworthy outside of search engines and maybe their ad service.

It looks like to me they are making Google Goo for prestige. Search engine, browser, now programming language... Whats next? OS? Laptops? Fast food franchise?

I don't understand all the criticism behind Google's product. Of corporate software producers, Apple and Google are the two ones making products that work reliably and are carefully designed. Besides, there's not much conspiracy going on. People at Google go off and do their own projects all the time. I don't see Go part of a careful ploy. (For one thing it would be much more polished in that case.) It is also known inside Google circles that Go's authors are not language designers, and that is visible in the quality of the language. (That could change any time; Google does employ quite a few good language designers who may contribute to Go in the future.) I think Tiobe's method of measuring language popularity is rather noisy. Go is unfinished on Unix, not present on Windows, and all around severely lacking in vision and originality. There's no way in hell it would be the world's #13th popular language. (For the record, I also don't think D ever was #13, but with luck that's going to change starting this year.) Andrei
Jan 23 2010
next sibling parent reply Roman Ivanov <isroman-del ete-km.ru> writes:
Andrei Alexandrescu Wrote:

 Bane wrote:
 Nick Sabalausky Wrote:
 
 "Steve Teale" <steve.teale britseyeview.com> wrote in message 
 news:hjf9uk$1trp$1 digitalmars.com...
 I see that Go has now usurped D's former place at #13 in Tiobe - which I 
 realize of course does not mean anything. But I'd be interested to hear 
 what the D aficionados think of Go.

 It probably would not suit Andrei.

It's little more than a concurrency-model experiment masquerading as a real language. Also: - As far as I'm concerned, its real name is "Issue 9" (search "google go issue 9"). - It's the Buick/Cadillac/Oldsmobile of computer languages: Garbage that gets attention solely because of the name(s) attached. - Does nothing to change my opinion that Google has done nothing noteworthy outside of search engines and maybe their ad service.

It looks like to me they are making Google Goo for prestige. Search engine, browser, now programming language... Whats next? OS? Laptops? Fast food franchise?

I don't understand all the criticism behind Google's product. Of corporate software producers, Apple and Google are the two ones making products that work reliably and are carefully designed.

They get lots and lots of undeserved attention. Even when the final products are not that great, and occasionally when the people praising them would be hostile towards the same kinds of products from smaller companies. Reception often border on being an outright hysteria. It's mostly the fault of the people who react this way, but both companies put a lot of effort in creating this effect via various kind of marketing too.
Jan 23 2010
parent reply Roman Ivanov <isroman-del ete-km.ru> writes:
Roman Ivanov Wrote:

 Andrei Alexandrescu Wrote:
 
 Bane wrote:
 Nick Sabalausky Wrote:
 
 "Steve Teale" <steve.teale britseyeview.com> wrote in message 
 news:hjf9uk$1trp$1 digitalmars.com...
 I see that Go has now usurped D's former place at #13 in Tiobe - which I 
 realize of course does not mean anything. But I'd be interested to hear 
 what the D aficionados think of Go.

 It probably would not suit Andrei.

It's little more than a concurrency-model experiment masquerading as a real language. Also: - As far as I'm concerned, its real name is "Issue 9" (search "google go issue 9"). - It's the Buick/Cadillac/Oldsmobile of computer languages: Garbage that gets attention solely because of the name(s) attached. - Does nothing to change my opinion that Google has done nothing noteworthy outside of search engines and maybe their ad service.

It looks like to me they are making Google Goo for prestige. Search engine, browser, now programming language... Whats next? OS? Laptops? Fast food franchise?

I don't understand all the criticism behind Google's product. Of corporate software producers, Apple and Google are the two ones making products that work reliably and are carefully designed.

They get lots and lots of undeserved attention. Even when the final products are not that great, and occasionally when the people praising them would be hostile towards the same kinds of products from smaller companies. Reception often border on being an outright hysteria. It's mostly the fault of the people who react this way, but both companies put a lot of effort in creating this effect via various kind of marketing too.

Also, a lot of Google's recent software initiatives are really weird stuff with highly questionable value. However, because of the reception mentioned above, they kind of bend the existing software infrastructure and culture around themselves. Not in a good way too. For example, I really don't like the idea that Wave is going to be a replacement for the aging email infrastructure. (Which might not happen, but that's how it's marketed.) I don't like the idea of an 8-gig operating system that's designed to run one application. (Not entirely true, but close enough to reality.) Those things might be of high quality, they may be reliable in their own way, while still having negative effect on software industry as a whole.
Jan 23 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Roman Ivanov" <isroman-del ete-km.ru> wrote in message 
news:hjftkk$3up$1 digitalmars.com...
 Roman Ivanov Wrote:
 They get lots and lots of undeserved attention. Even when the final 
 products are not that great, and occasionally when the people praising 
 them would be hostile towards the same kinds of products from smaller 
 companies.

 Reception often border on being an outright hysteria. It's mostly the 
 fault of the people who react this way, but both companies put a lot of 
 effort in creating this effect via various kind of marketing too.

Also, a lot of Google's recent software initiatives are really weird stuff with highly questionable value. However, because of the reception mentioned above, they kind of bend the existing software infrastructure and culture around themselves. Not in a good way too. For example, I really don't like the idea that Wave is going to be a replacement for the aging email infrastructure. (Which might not happen, but that's how it's marketed.) I don't like the idea of an 8-gig operating system that's designed to run one application. (Not entirely true, but close enough to reality.) Those things might be of high quality, they may be reliable in their own way, while still having negative effect on software industry as a whole.

Agreed on all the above. And personally, I'd add a few more points: 1. I'd add "cloud computing" to the list of questionable initiatives (or at least questionable outside of certain niche use-cases that I'm sure probably do exist). 2. Their software generally reminds me of Apple software (no offense, or bait, intended to any Mac-users here) in that, IMO: 2.1. They tend to have lousy attention to detail (Google Code looks clean and pretty, and maybe it's reliable, but trying to use it absolutely drives me nuts. Plus, the stuff I mentioned about google maps in another post). 2.2. They're annoyingly slim on configurable settings (stuff I mentioned about google maps in another post, and why in the world they think I should be force-fed a non-standard custom skin in Chrome). 2.3. For their desktop apps, they like to force useless always-resident services onto my system. 3. Heck, Google is a web-oriented company, and I just hate modern web technology. ;)
Jan 23 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick Sabalausky wrote:
 "Roman Ivanov" <isroman-del ete-km.ru> wrote in message 
 news:hjftkk$3up$1 digitalmars.com...
 Roman Ivanov Wrote:
 They get lots and lots of undeserved attention. Even when the final 
 products are not that great, and occasionally when the people praising 
 them would be hostile towards the same kinds of products from smaller 
 companies.

 Reception often border on being an outright hysteria. It's mostly the 
 fault of the people who react this way, but both companies put a lot of 
 effort in creating this effect via various kind of marketing too.

with highly questionable value. However, because of the reception mentioned above, they kind of bend the existing software infrastructure and culture around themselves. Not in a good way too. For example, I really don't like the idea that Wave is going to be a replacement for the aging email infrastructure. (Which might not happen, but that's how it's marketed.) I don't like the idea of an 8-gig operating system that's designed to run one application. (Not entirely true, but close enough to reality.) Those things might be of high quality, they may be reliable in their own way, while still having negative effect on software industry as a whole.

Agreed on all the above. And personally, I'd add a few more points: 1. I'd add "cloud computing" to the list of questionable initiatives (or at least questionable outside of certain niche use-cases that I'm sure probably do exist). 2. Their software generally reminds me of Apple software (no offense, or bait, intended to any Mac-users here) in that, IMO: 2.1. They tend to have lousy attention to detail (Google Code looks clean and pretty, and maybe it's reliable, but trying to use it absolutely drives me nuts. Plus, the stuff I mentioned about google maps in another post).

Google and Apple on which planet are you referring to? Far as I can tell they set the _standard_ on attention to detail, and Microsoft and others are desperately catching up!
 2.2. They're annoyingly slim on configurable settings (stuff I mentioned 
 about google maps in another post, and why in the world they think I should 
 be force-fed a non-standard custom skin in Chrome).

Well yeah a better maps application is... oh, wait. Google maps is the best by a huge margin.
 2.3. For their desktop apps, they like to force useless always-resident 
 services onto my system.

 3. Heck, Google is a web-oriented company, and I just hate modern web 
 technology. ;)

3 contradicts 2.3. Did you mean to be sarcastic? Andrei
Jan 23 2010
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Andrei Alexandrescu wrote:
 2.2. They're annoyingly slim on configurable settings (stuff I 
 mentioned about google maps in another post, and why in the world they 
 think I should be force-fed a non-standard custom skin in Chrome).

Well yeah a better maps application is... oh, wait. Google maps is the best by a huge margin.

Not to mention the blessed calendar. Google calendar is the best, though Yahoo's is pretty mean as well. Since recently I need to use Outlook Calendar and it's like time travel to 1997. "Look, we can offer html rendering of your calendar! It has _colors_ in it!!" Andrei
Jan 23 2010
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:hjgopn$1i7g$1 digitalmars.com...
 Nick Sabalausky wrote:
 "Roman Ivanov" <isroman-del ete-km.ru> wrote in message 
 news:hjftkk$3up$1 digitalmars.com...
 Roman Ivanov Wrote:
 They get lots and lots of undeserved attention. Even when the final 
 products are not that great, and occasionally when the people praising 
 them would be hostile towards the same kinds of products from smaller 
 companies.

 Reception often border on being an outright hysteria. It's mostly the 
 fault of the people who react this way, but both companies put a lot of 
 effort in creating this effect via various kind of marketing too.

stuff with highly questionable value. However, because of the reception mentioned above, they kind of bend the existing software infrastructure and culture around themselves. Not in a good way too. For example, I really don't like the idea that Wave is going to be a replacement for the aging email infrastructure. (Which might not happen, but that's how it's marketed.) I don't like the idea of an 8-gig operating system that's designed to run one application. (Not entirely true, but close enough to reality.) Those things might be of high quality, they may be reliable in their own way, while still having negative effect on software industry as a whole.

Agreed on all the above. And personally, I'd add a few more points: 1. I'd add "cloud computing" to the list of questionable initiatives (or at least questionable outside of certain niche use-cases that I'm sure probably do exist). 2. Their software generally reminds me of Apple software (no offense, or bait, intended to any Mac-users here) in that, IMO: 2.1. They tend to have lousy attention to detail (Google Code looks clean and pretty, and maybe it's reliable, but trying to use it absolutely drives me nuts. Plus, the stuff I mentioned about google maps in another post).

Google and Apple on which planet are you referring to? Far as I can tell they set the _standard_ on attention to detail, and Microsoft and others are desperately catching up!

First of all, I never said that MS or other companies were good at attention-to-detail, so let's not get into that strawman. Apple *used to* set the standard on attention to detail (or so I've heard), but that era was over when OSX came around. Also, any current attention-to-detail from either Google or Apple is typically limited to visual style. Just some off-the-top-of-my-head examples of shitty attention-to-detail from Apple and Google: Apple: - iPods have a Power button, but they cannot be turned off via the so-called Power button. They are turned off by holding "Up" for a few seconds. Easily wins the lifetime award for "Dumbest Interface Design Choice I've Ever Seen". - How long did it take the iPhone to get basic copy/paste? (I'm not sure, but I know it was a ridiculously long time for such a basic feature. Handspring, for instance, had smartphones with copy/paste from day one, and that was years before the iPhone was ever announced.) - Last I looked, OSX didn't have any way to set up a light-on-dark color scheme, or any color scheme for that matter, at least not beyond wallpaper and selection-color. - iTunes installs an iPod service which it restarts whenever it detects it's not running (and it polls for it every few seconds), and there's no clean way to for people who never use an iPod on their system to permanently disable it. - iTunes: Right-click a song, and "Show in Windows Explorer" opens *two* explorer windows to the given directory (with the second one opened roughly 10 seconds or so after the first). That's persisted for quite a while, and I've never seen it in any other program that launches an explorer window. - iTunes: Took forever before it finally supported audio CDs that had data for Track 1. (Ex: Many early CD-based videogames). Never saw another CD player (software or hardware) that had that problem. - "Error code -(some number here)" - The "Hover Zoom" dock effect that Apple's been so proud of essentially amounts to turning some of the most frequently-used-buttons into moving targets. They obviously didn't think that one through. Google: - Google web-apps in general: There's been many times I've had that "Loading" box at the top of the page (the one google often uses on their web-apps) just hang without ever loading a thing. - Maps: Search for an address, and when it shows up, it will be centered wrong. *Then* it will slowly scroll to the correct orientation. Unbelievably hacky "solution" to a trivial bug, and it's persisted for a long time. - Maps: Cannot switch between JS version and non-JS version without going through contortions to force a new session. I've never seen a non-google website have that problem. Everywhere else, all that's needed is a page refresh. - Maps: If I search for one address, and get one tick-mark result, why would I want a quarter of the resulting map to be obscured by a bubble telling me exactly what I already know darn well that I *just* searched for? And why do I need that to happen *every single time*? At the very least they could have had the sense to provide a user setting to disable obnoxiousness like that, but...nope, can't have that either. - Code: See the wonderful attention-to-detail in this screenshot (been like this for quite awhile): http://www.semitwist.com/download/GoogleCode.png - Code: Has "search within" constraints for all issues, open issues, and any of your own issues that are still open, but there's nothing in that box for just simply searching your own issues (which is what I want 90% of the time I do a ticket search on a Googe Code project). Also, just plain can't search on closed issues without also searching open ones (or if you can do it, the UI makes it pretty damn obscure). - Code: When the results of a ticket search span multiple pages, there are no links to get to any page other than "Next" and "Prev". No "Last", no "Page 3", just "Next". Those are pretty damn standard links for paged results, but Google Code doesn't have them. - Code: A number of very-trivial-to-get-right things are broken when JS is off. Submitting a ticket, for example, is rather buggy with JS off even though there's nothing needed beyond the same damn HTML forms that even novices have been able to write ever since the 90's. There other things for both Apple and Google, but those are just the (non-hardware) ones from off-top-top-of-my-head.
 2.2. They're annoyingly slim on configurable settings (stuff I mentioned 
 about google maps in another post, and why in the world they think I 
 should be force-fed a non-standard custom skin in Chrome).

Well yeah a better maps application is... oh, wait. Google maps is the best by a huge margin.

Since when does "best" automatically imply "good"? And sure, I'll grant there *is* a lot of good about google maps (although most of the good stuff has already been copied by the competitors by now), but there's also a lot that's not good (see above).
 2.3. For their desktop apps, they like to force useless always-resident 
 services onto my system.

 3. Heck, Google is a web-oriented company, and I just hate modern web 
 technology. ;)

3 contradicts 2.3.

Let's not get overly literal. "Google is *primarily* a web-oriented company" Better now?
Jan 24 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:hjgopn$1i7g$1 digitalmars.com...
 - iPods have a Power button, but they cannot be turned off via the so-called 
 Power button. They are turned off by holding "Up" for a few seconds. Easily 
 wins the lifetime award for "Dumbest Interface Design Choice I've Ever 
 Seen".

http://www.macnn.com/articles/06/05/25/apple.wins.dad.awards/
 - How long did it take the iPhone to get basic copy/paste? (I'm not sure, 
 but I know it was a ridiculously long time for such a basic feature. 
 Handspring, for instance, had smartphones with copy/paste from day one, and 
 that was years before the iPhone was ever announced.)

http://www.appletell.com/apple/comment/apple-wins-eight-product-design-awards-at-cebit/ Brownie points for not going with the mainstream opinion. Andrei P.S. Never heard of Handspring.
Jan 24 2010
parent "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:hjhl98$932$1 digitalmars.com...
 Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:hjgopn$1i7g$1 digitalmars.com...
 - iPods have a Power button, but they cannot be turned off via the 
 so-called Power button. They are turned off by holding "Up" for a few 
 seconds. Easily wins the lifetime award for "Dumbest Interface Design 
 Choice I've Ever Seen".

http://www.macnn.com/articles/06/05/25/apple.wins.dad.awards/
 - How long did it take the iPhone to get basic copy/paste? (I'm not sure, 
 but I know it was a ridiculously long time for such a basic feature. 
 Handspring, for instance, had smartphones with copy/paste from day one, 
 and that was years before the iPhone was ever announced.)

http://www.appletell.com/apple/comment/apple-wins-eight-product-design-awards-at-cebit/ Brownie points for not going with the mainstream opinion.

"Gone With The Wind" won prestigious awards too. I still hated every minute of it.
 P.S. Never heard of Handspring.

They were one of the biggest manufacturers of third-party PalmOS devices (I miss PalmOS PDAs). My first PDA was a Handspring Visor. Handspring's Treo was one of the earliest smartphones, although that was before people were calling them smartphones.
Jan 24 2010
prev sibling next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Steven E. Harris (seh panix.com)'s article
 retard <re tard.com.invalid> writes:
 Has Windows really improved that much on that area?

of Windows I had used

It was pretty good. I know this because back then mice weren't all that reliable and you had to be able to operate Windows with just the keyboard to fix your mouse driver when something went wrong.
Jan 24 2010
prev sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On Jan 24, 10 23:46, Steven E. Harris wrote:
 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>  writes:

 Far as I can tell they set the _standard_ on attention to detail, and
 Microsoft and others are desperately catching up!

One point comes to mind: keyboard shortcuts. OSX is maddeningly inconsistent and patchy with being able to use applications using just the keyboard. Windows (and, hence, Microsoft) is the best in this area. There's usually some way to do everything with the keyboard in a given application. In OSX, there's usually some way to do /something/ with the keyboard.

Users can reassign most keyboard shortcut in Mac OS X.
Jan 24 2010
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-01-26 22:34:38 -0500, "Steven E. Harris" <seh panix.com> said:

 KennyTM~ <kennytm gmail.com> writes:
 
 Users can reassign most keyboard shortcut in Mac OS X.

That's not what I mean. There are applications where it's not possible to bind any key to certain essential operations, such as "move the cursor from the tree pane thing on the left to the list-like pane in the center, and back again". I played with iCal for a while in the Apple Store one day, amusing myself with punishment. There's a keyboard shortcut to bring up a small "go to date" dialog, which allows one to type in a date. But the enter key doesn't "confirm" the dialog. I could not find any keystroke that had the same effect as pressing "OK", or whatever the accepting button is labeled. Is that a cruel joke?

That looks like an oversight. It looks like the date entry field eats all keyboard events. I agree it's particularly bad, especially since it's the typical interface element you'd want to access with the keyboard. But I must also say I don't see that often in OS X applications. There's still a way out with the keyboard: activate the VoiceOver spoken interface (Cmd-Fn-F5), then use its shortcuts (Ctrl-Alt-Arrows) to navigate to the control you want. But it's definitely overkill for something that should just work. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 27 2010
prev sibling parent reply Bane <branimir.milosavljevic gmail.com> writes:
 I don't understand all the criticism behind Google's product. Of 
 corporate software producers, Apple and Google are the two ones making 
 products that work reliably and are carefully designed.
 
 Besides, there's not much conspiracy going on. People at Google go off 
 and do their own projects all the time. I don't see Go part of a careful 
 ploy. (For one thing it would be much more polished in that case.) It is 
 also known inside Google circles that Go's authors are not language 
 designers, and that is visible in the quality of the language. (That 
 could change any time; Google does employ quite a few good language 
 designers who may contribute to Go in the future.)
 

I naively and firmly believe, from my standpoint as a individual, that any large corporation is evil. Google is no exception. My understanding is that maybe when they were startup, they were idealistic. Once they grew to a certain size, and amounted certain cash, everything goes the same way as with M$ or any other company. Lots of money comes with lots of power, people attracted to it etc. Game is to stay on top, which means eating smaller fishes and expanding to other areas (Google burger anyone?). If not so, then they would not be No1 and some bigger fish would eat them. Thats capitaljism, as Arnold from Red Heat would say. There is a silly movie I watched long time ago, with a big evil corporation named EES (Everything Except Shoes). They did just that. Wonder what will Google do in 10 yrs. Anyway, Go might be one few-good-ideas-but-lots-of-crap-recognized-from-the-beginning language, and that would not be problem itself, there are many languages like that, more or less known. But it is the 'Google' prefix that hurts my eyes. Does this makes Go any better? Nope. More advertised? Hell yes. It doesn't matters if author is doing it in their spare time. Similarly, there was Chrome pushed by Google as better-than-rest-but-nobody-asked-for-it-browser, as 'we make world better place with this'. But there were some issues with privacy and copyright for people who use it, and after reading enough about it, i decided not to use it. So, what we have here, i think, is one powerful corporation, advertising itself as 'we are not evil as M$', with lot of influence, pushing lot of things and recruiting lot of people for their projects, for their goals. Somebody finances all that. And I bet they have some long term plans with it. And I don't think they plan to lose money doing it, and i think that is theirs priority. So, conspiracy? Maybe. As far for Go being crappy because its designers are not good enough for the task, and possibility that Google will at certain point say 'ok, enough embarrassment, here comes our crack team of developers to help fix it' - I don't think its likely. If something is crappy from the begining, it is easier to start again from the scratch than fix it much latter.
Jan 23 2010
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Bane" <branimir.milosavljevic gmail.com> wrote in message 
news:hjfvv2$85c$1 digitalmars.com...
 I naively and firmly believe, from my standpoint as a individual, that any 
 large corporation is evil. Google is no exception.

Hear hear!
 My understanding is that maybe when they were startup, they were 
 idealistic. Once they grew to a certain size, and amounted certain cash, 
 everything goes the same way as with M$ or any other company. Lots of 
 money comes with lots of power, people attracted to it etc. Game is to 
 stay on top, which means eating smaller fishes and expanding to other 
 areas (Google burger anyone?). If not so, then they would not be No1 and 
 some bigger fish would eat them. Thats capitaljism, as Arnold from Red 
 Heat would say.

Yea, something I find quite interesting is that, originally, I liked Google very much. They made the smartest and best web search engine out there, and married it with what, to this day, I consider one of the best examples of web interface design around. But then as soon as they had their IPO they started pumping out 95% junk (ie, at least Google Maps has some good points) but were hailed by everyone anyway because "Hey! It's the same great company as before!". The hell it is.
Jan 23 2010
prev sibling next sibling parent reply Rainer Deyke <rainerd eldwood.com> writes:
Bane wrote:
 I naively and firmly believe, from my standpoint as a individual,
 that any large corporation is evil. Google is no exception.

I think there is some truth to that, in the same way as all governments, political parties, and other large organizations are evil. Still, this doesn't mean that are governments or all large corporations are morally equivalent. I'll take the evil of a secular liberal democracy over the evil of a fundamentalist theocratic dictatorship any day. Google provides free products and services, uses unobtrusive advertising, promotes open standards, and contributes to open source projects. Compared to other corporations of a similar size, they're practically saints. Even if I don't care for their products, or for the direction in which they are trying to push the computer industry. -- Rainer Deyke - rainerd eldwood.com
Jan 23 2010
parent "Nick Sabalausky" <a a.a> writes:
"Rainer Deyke" <rainerd eldwood.com> wrote in message 
news:hjg5gp$i7p$1 digitalmars.com...
 Bane wrote:
 I naively and firmly believe, from my standpoint as a individual,
 that any large corporation is evil. Google is no exception.

I think there is some truth to that, in the same way as all governments, political parties, and other large organizations are evil. Still, this doesn't mean that are governments or all large corporations are morally equivalent. I'll take the evil of a secular liberal democracy over the evil of a fundamentalist theocratic dictatorship any day. Google provides free products and services, uses unobtrusive advertising, promotes open standards, and contributes to open source projects. Compared to other corporations of a similar size, they're practically saints. Even if I don't care for their products, or for the direction in which they are trying to push the computer industry.

That is a good point. (FWIW, The only reason I feel compelled to "me too" this post is as a disclaimer for all my other Google-bashing posts here.)
Jan 23 2010
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bane wrote:
 I naively and firmly believe

How could these ever go together? I literally stopped reading here. Yet I saw snippets in the reply-to posts and - well I can't tell much about firmness but the naivety is there. Andrei
Jan 23 2010
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:hjgof3$1gqe$2 digitalmars.com...
 Bane wrote:
 I naively and firmly believe

How could these ever go together?

Humor. Deliberate irony. Humility. Disclaimer.
 I literally stopped reading here. Yet I saw snippets in the reply-to posts 
 and - well I can't tell much about firmness but the naivety is there.

Did I miss the memo for National Take-Everything-Literally Day?
Jan 24 2010
prev sibling parent reply Bane <branimir.milosavljevic gmail.com> writes:
Andrei Alexandrescu Wrote:

 Bane wrote:
 I naively and firmly believe

How could these ever go together? I literally stopped reading here. Yet I saw snippets in the reply-to posts and - well I can't tell much about firmness but the naivety is there. Andrei

Well, i am naive when it comes to all that stuff, I havent been CO or lawyer of any large corporation so i dont have first hand info, so I might be wrong or too simplistic. So yep, naive=humble. On the other hand, what I feel/believe is dictated by my guts, and it says there is nasty shit going on, so I believe it firmly, just because my gut detector is pretty reliable. So, my firmly belief is my choice based on what i know and trust - my gut. So Andrei, you say naive people cant have strong beliefs, or just that strong beliefs cant be based on assumptions that are naive? If we put aside topic here, this might easily become religious discussion.
Jan 24 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bane wrote:
 Andrei Alexandrescu Wrote:
 
 Bane wrote:
 I naively and firmly believe

Yet I saw snippets in the reply-to posts and - well I can't tell much about firmness but the naivety is there. Andrei

Well, i am naive when it comes to all that stuff, I havent been CO or lawyer of any large corporation so i dont have first hand info, so I might be wrong or too simplistic. So yep, naive=humble. On the other hand, what I feel/believe is dictated by my guts, and it says there is nasty shit going on, so I believe it firmly, just because my gut detector is pretty reliable. So, my firmly belief is my choice based on what i know and trust - my gut. So Andrei, you say naive people cant have strong beliefs, or just that strong beliefs cant be based on assumptions that are naive? If we put aside topic here, this might easily become religious discussion.

Good point. I guess I said that only because often my own naive beliefs tend to lack strength. I might be wrong here, but naivety and lack of evidence kind of go together. Andrei
Jan 24 2010
parent Bane <branimir.milosavljevic gmail.com> writes:
 Good point. I guess I said that only because often my own naive beliefs 
 tend to lack strength. I might be wrong here, but naivety and lack of 
 evidence kind of go together.
 
 Andrei

Lot of rock solid or fanatical stuff is based on lack of evidence, so you can call it naive. Religions are one thing. Mathematics come to my mind (axioms are things that are taken granted as truth, cant be proven, so there are definitely lack of evidence). And most extreme of all is zen, that (in my understanding) states that, whatever conclusion or belief you come up with, be 100% fanatical about it and forget anything else. Wanna call some religious freak, nobel prize mathematician or angry samurai naive? :D Well, I contributed enough to off topic making philosophical waste. Srry guys :)
Jan 24 2010
prev sibling parent "John D" <jdean googling.com> writes:
"Bane" <branimir.milosavljevic gmail.com> wrote in message 
news:hjfvv2$85c$1 digitalmars.com...

 I naively and firmly believe, from my standpoint as a individual, that 
 any large corporation is evil.

If you remove "naively" and change "corporation" to "institution" or even "organization", I would be inclined to agree with you. If you want to do more research on that, go interview some people from the countries of Europe who are faced with the threat of an European Union and I think you will find many who will echo similar sentiments ("We're losing our individuality", etc.).
Jan 29 2010
prev sibling parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Bane wrote:

 It looks like to me they are making Google Goo for prestige. Search
 engine, browser, now programming language... Whats next? OS?

Google has designed two operating systems already.
 Laptops?

Google Laptops, Google Phones. Sure. They're just not building the hardware themselves. I myself have a Google Experience phone.
 Fast food franchise?

I was at a programming contest once where Google sponsored the catering. Does that count? :-) -- Michiel Helvensteijn
Jan 23 2010
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Michiel Helvensteijn wrote:
 Bane wrote:
 
 It looks like to me they are making Google Goo for prestige. Search
 engine, browser, now programming language... Whats next? OS?

Google has designed two operating systems already.

They also made GWT, which is not a language but a compiler. They are not just engine and browser. :-P
Jan 24 2010
parent reply Bane <branimir.milosavljevic gmail.com> writes:
Ary Borenszweig Wrote:

 Michiel Helvensteijn wrote:
 Bane wrote:
 
 It looks like to me they are making Google Goo for prestige. Search
 engine, browser, now programming language... Whats next? OS?

Google has designed two operating systems already.

They also made GWT, which is not a language but a compiler. They are not just engine and browser. :-P

OMG! (Didn't know that!) They are everywhere! Oh well, they can't be good at everything they do... Either tasty catering or good language, cant have both...
Jan 23 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Bane" <branimir.milosavljevic gmail.com> wrote in message 
news:hjg0i8$97j$1 digitalmars.com...
 Ary Borenszweig Wrote:

 Michiel Helvensteijn wrote:
 Bane wrote:

 It looks like to me they are making Google Goo for prestige. Search
 engine, browser, now programming language... Whats next? OS?

Google has designed two operating systems already.

They also made GWT, which is not a language but a compiler. They are not just engine and browser. :-P

OMG! (Didn't know that!) They are everywhere! Oh well, they can't be good at everything they do... Either tasty catering or good language, cant have both...

You know, even though I'm one of the resident Google-haters here, I have to admit, I saw a thing on TV about Google's company cafeteria, and - OMG, I'm jealous of it! So yea, "Yay Google! Kind of Cafeterias!" Heh :)
Jan 23 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Nick Sabalausky wrote:
 You know, even though I'm one of the resident Google-haters here, I have to 
 admit, I saw a thing on TV about Google's company cafeteria, and - OMG, I'm 
 jealous of it!

I've eaten at the Google cafeteria. It's very nice, and would be a compelling perq to work there. BTW, while I understand your concern about corporations inevitably growing in size until they rule the world, the historical experience is otherwise. Once they reach a certain size, they tend to collapse from inefficiency and bureaucratic ossification. For example, GM! I could list dozens of others.
Jan 23 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hjg3b0$elr$1 digitalmars.com...
 Nick Sabalausky wrote:
 You know, even though I'm one of the resident Google-haters here, I have 
 to admit, I saw a thing on TV about Google's company cafeteria, and - 
 OMG, I'm jealous of it!

I've eaten at the Google cafeteria. It's very nice, and would be a compelling perq to work there.

Speaking of good corporate cafeterias, I had an internship a number of years ago at Progressive Insurance, and say what you will about insurance (I know I sure do ;) ), but I loved that cafeteria. But then again, from what I've seen of Google's cafeteria, that Google one even puts Progressive's to shame. And having worked both there and at places that had no cafeteria (not even a third-party one nearby) I feel fairly strongly that the benefits of having something that reliable for lunches, instead of, on a daily basis, having to worry about "where/when I am going to be able to grab something?" or spending the time to prepare one's own lunches cannot be over-emphasized. (But then again, I can be a bit of a worry-wart anyway ;) )
 BTW, while I understand your concern about corporations inevitably growing 
 in size until they rule the world,

Well, I can't speak for other people, but that's not quite the [ethical] problem I have with large corporations. In fact, it's not so much "large corporations" per se that I take issue with as it is "publically-traded corporations". I just find that the whole idea of businesses being literally owned by people whose sole interest in the company is purely financal (not to mention laws that essentially mandate that the corporation hold shareholder financial interests above all other concerns) to be a recipe for social irresponsibility. (Not that I'm socialist or communist or anything like that though, I haven't studied or been around such systems enough to form any coherent opinion on them.)
 the historical experience is otherwise. Once they reach a certain size, 
 they tend to collapse from inefficiency and bureaucratic ossification.

 For example, GM! I could list dozens of others.

Well, yea, that is another problem with big corporations. By the way, did you spell that right? That wasn't supposed to be "bureaucratic assification"? ;)
Jan 23 2010
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Nick Sabalausky wrote:
 By the way, did you spell that right? That wasn't supposed to be 
 "bureaucratic assification"? ;)

"ossification" means turn to stone.
Jan 23 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 "ossification" means turn to stone.

It means turning into bone, for example when you don't move a hand for months and the joints cartilage starts to turn into bone (os means bone in latin, and today oss-like sounds mean bone in Spanish, Italian, French, etc). Bye, bearophile
Jan 24 2010
prev sibling parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Walter Bright wrote:
 Nick Sabalausky wrote:
 By the way, did you spell that right? That wasn't supposed to be
 "bureaucratic assification"? ;)

"ossification" means turn to stone.

It's a joke dude ;)
Jan 24 2010
prev sibling parent reply Bane <branimir.milosavljevic gmail.com> writes:
 By the way, did you spell that right? That wasn't supposed to be 
 "bureaucratic assification"? ;)
 
 

Am I only Freud person here seeing ass and not the oss in above statement?
Jan 24 2010
parent "Nick Sabalausky" <a a.a> writes:
"Bane" <branimir.milosavljevic gmail.com> wrote in message 
news:hjh7o9$2f4h$1 digitalmars.com...
 By the way, did you spell that right? That wasn't supposed to be
 "bureaucratic assification"? ;)

Am I only Freud person here seeing ass and not the oss in above statement?

I'm Sabalausky, not Freud, but I just love the new word "assification" :) (And yes, I know what you meant by Freud. Just another bad joke on my part. ;) )
Jan 24 2010
prev sibling parent reply "John D" <jdean googling.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hjg3b0$elr$1 digitalmars.com...
 Nick Sabalausky wrote:
 You know, even though I'm one of the resident Google-haters here, I 
 have to admit, I saw a thing on TV about Google's company cafeteria, 
 and - OMG, I'm jealous of it!

I've eaten at the Google cafeteria. It's very nice, and would be a compelling perq to work there. BTW, while I understand your concern about corporations inevitably growing in size until they rule the world, the historical experience is otherwise.

 Once they reach a certain size,

And what size is that? And more importantly, how long does it take?
 they tend to collapse from inefficiency and bureaucratic ossification.

 For example, GM! I could list dozens of others.

Is that supposed to be consolation to the little sapling that couldn't grow or have a life because the big tree's roots sucked up all the nutrients and ominous branches blocked the sun?
Jan 29 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
John D wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:hjg3b0$elr$1 digitalmars.com...
 Nick Sabalausky wrote:
 You know, even though I'm one of the resident Google-haters here, I 
 have to admit, I saw a thing on TV about Google's company cafeteria, 
 and - OMG, I'm jealous of it!

compelling perq to work there. BTW, while I understand your concern about corporations inevitably growing in size until they rule the world, the historical experience is otherwise.

 Once they reach a certain size,

And what size is that? And more importantly, how long does it take?

I don't have the list handy, but take a look at the largest companies in America (by market capitalization) for each decade. You don't have to go very far back before you stop even recognizing the names.
 they tend to collapse from inefficiency and bureaucratic ossification.

 For example, GM! I could list dozens of others.

Is that supposed to be consolation to the little sapling that couldn't grow or have a life because the big tree's roots sucked up all the nutrients and ominous branches blocked the sun?

The book "The Innovators' Dilemma" lists many stories about small companies successfully competing with established dominant ones. http://www.amazon.com/exec/obidos/ASIN/0060521996/classicempire
Jan 30 2010
next sibling parent reply Bane <branimir.milosavljevic gmail.com> writes:
 Definitely.  As soon as a company gets beyond a certain size it is
 pretty much inevitable that they spend a significant amount of their
 efforts protecting their current business model.  This will almost
 always mean they will fail to react fast enough to compete with two
 guys in a garage with a really good idea.
 
 --bb

Exactly the reason big companies should relocate their employees from cubicles to garages and force them to surf the net whole day.
Jan 30 2010
parent "Nick Sabalausky" <a a.a> writes:
"Bane" <branimir.milosavljevic gmail.com> wrote in message 
news:hk2302$2017$1 digitalmars.com...
 Definitely.  As soon as a company gets beyond a certain size it is
 pretty much inevitable that they spend a significant amount of their
 efforts protecting their current business model.  This will almost
 always mean they will fail to react fast enough to compete with two
 guys in a garage with a really good idea.

 --bb

Exactly the reason big companies should relocate their employees from cubicles to garages and force them to surf the net whole day.

I like it! Sign me up for one of those big companies!
Jan 30 2010
prev sibling parent "John D" <jdean googling.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hk1uqu$1omt$1 digitalmars.com...
 John D wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:hjg3b0$elr$1 digitalmars.com...
 Nick Sabalausky wrote:
 You know, even though I'm one of the resident Google-haters here, I 
 have to admit, I saw a thing on TV about Google's company cafeteria, 
 and - OMG, I'm jealous of it!

compelling perq to work there. BTW, while I understand your concern about corporations inevitably growing in size until they rule the world, the historical experience is otherwise.

 Once they reach a certain size,

And what size is that? And more importantly, how long does it take?

I don't have the list handy,

Your "theory" is quite the strawman. Don't worry about it, I'm not calling you out on it. You can "have the last word" if it makes you feel good.
 but take a look at the largest companies in America (by market 
 capitalization) for each decade. You don't have to go very far back 
 before you stop even recognizing the names.

Well, I don't care to continue this line of discussion, for this is a tech group, but doing the "referring thing" rather than addressing the key points is worse than not saying anything, FYI. Your weak "theory" just dropped to zero. (No offense). (It's not actually your "theory" that I have issue with, but rather that you take some surface statistics, like a manager that just reads the reports of numbers each month and bases decisions on those "controls", when that has little relative meaning compared to real major issues and how to solve problems or make things better or knowing things).
Jan 30 2010
prev sibling next sibling parent "Steven E. Harris" <seh panix.com> writes:
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

 Far as I can tell they set the _standard_ on attention to detail, and
 Microsoft and others are desperately catching up!

One point comes to mind: keyboard shortcuts. OSX is maddeningly inconsistent and patchy with being able to use applications using just the keyboard. Windows (and, hence, Microsoft) is the best in this area. There's usually some way to do everything with the keyboard in a given application. In OSX, there's usually some way to do /something/ with the keyboard. -- Steven E. Harris
Jan 24 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Sun, 24 Jan 2010 10:46:34 -0500, Steven E. Harris wrote:

 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
 
 Far as I can tell they set the _standard_ on attention to detail, and
 Microsoft and others are desperately catching up!

One point comes to mind: keyboard shortcuts. OSX is maddeningly inconsistent and patchy with being able to use applications using just the keyboard. Windows (and, hence, Microsoft) is the best in this area. There's usually some way to do everything with the keyboard in a given application. In OSX, there's usually some way to do /something/ with the keyboard.

Has Windows really improved that much on that area? I use Linux + xmonad + vim/emacs + mostly command line applications on xterms. Web browsing is one of the only tasks that seems to require some kind of pointing device because of flash crap and crazy navigation systems.
Jan 24 2010
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
retard <re tard.com.invalid> wrote:

 Web browsing is
 one of the only tasks that seems to require some kind of pointing device
 because of flash crap and crazy navigation systems.

Use Opera, then. a/q to move between links, tab to change between input fields, shift+arrow keys for spatial navigation. And bunches and bunches of other shortcuts. http://www.opera.com/browser/tutorials/nomouse/ -- Simen
Jan 24 2010
prev sibling next sibling parent "Steven E. Harris" <seh panix.com> writes:
retard <re tard.com.invalid> writes:

 Has Windows really improved that much on that area?

I don't recall the keyboard support in Windows 3.1 -- the first version of Windows I had used -- but from Windows 95 onward, the basic system and then situation have been the same: better than anything else I've tried. You mentioned Web browsers. I can drive Firefox very well with just the keyboard. Sometimes pointing with the mouse is more convenient, but it's never made necessary by the browser. -- Steven E. Harris
Jan 24 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Sun, 24 Jan 2010 21:34:56 +0100, Simen kjaeraas wrote:

 retard <re tard.com.invalid> wrote:
 
 Web browsing is
 one of the only tasks that seems to require some kind of pointing
 device because of flash crap and crazy navigation systems.

Use Opera, then. a/q to move between links, tab to change between input fields, shift+arrow keys for spatial navigation. And bunches and bunches of other shortcuts. http://www.opera.com/browser/tutorials/nomouse/

Flash applets can't convert key presses into mouse events. Often the applet also needs to be activated by clicking on it with the mouse.
Jan 24 2010
prev sibling next sibling parent downs <default_357-line yahoo.de> writes:
Nick Sabalausky wrote:
 - Does nothing to change my opinion that Google has done nothing noteworthy 
 outside of search engines and maybe their ad service.
 
 

Google Maps (not sure if you counted that under search); but their real strength is context-aware integration of different services. Like the way you can get Google Maps results for local business from a google query that includes a streetname.
Jan 25 2010
prev sibling next sibling parent "Steven E. Harris" <seh panix.com> writes:
KennyTM~ <kennytm gmail.com> writes:

 Users can reassign most keyboard shortcut in Mac OS X.

That's not what I mean. There are applications where it's not possible to bind any key to certain essential operations, such as "move the cursor from the tree pane thing on the left to the list-like pane in the center, and back again". I played with iCal for a while in the Apple Store one day, amusing myself with punishment. There's a keyboard shortcut to bring up a small "go to date" dialog, which allows one to type in a date. But the enter key doesn't "confirm" the dialog. I could not find any keystroke that had the same effect as pressing "OK", or whatever the accepting button is labeled. Is that a cruel joke? -- Steven E. Harris
Jan 26 2010
prev sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Sat, Jan 30, 2010 at 10:46 AM, Walter Bright
<newshound1 digitalmars.com> wrote:
 John D wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message
 news:hjg3b0$elr$1 digitalmars.com...
 Nick Sabalausky wrote:
 You know, even though I'm one of the resident Google-haters here, I have
 to admit, I saw a thing on TV about Google's company cafeteria, and - OMG,
 I'm jealous of it!

I've eaten at the Google cafeteria. It's very nice, and would be a compelling perq to work there. BTW, while I understand your concern about corporations inevitably growing in size until they rule the world, the historical experience is otherwise.

 Once they reach a certain size,

And what size is that? And more importantly, how long does it take?

I don't have the list handy, but take a look at the largest companies in America (by market capitalization) for each decade. You don't have to go very far back before you stop even recognizing the names.
 they tend to collapse from inefficiency and bureaucratic ossification.

 For example, GM! I could list dozens of others.

Is that supposed to be consolation to the little sapling that couldn't grow or have a life because the big tree's roots sucked up all the nutrients and ominous branches blocked the sun?

The book "The Innovators' Dilemma" lists many stories about small companies successfully competing with established dominant ones.

Definitely. As soon as a company gets beyond a certain size it is pretty much inevitable that they spend a significant amount of their efforts protecting their current business model. This will almost always mean they will fail to react fast enough to compete with two guys in a garage with a really good idea. --bb
Jan 30 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Sat, 23 Jan 2010 14:38:20 -0500, Bane wrote:

... Some old farts use D1 because they
 highly respect the D-man art and Walter's ability to co-operative and
 communicate with the community (which indeed feels really good if you
 have zero experience on other language communities). They do not fancy
 the new D2 features that much. And let's be honest, D1 is terribly
 similar to a native port of C# 3.5.

Hey! This old fart here prefers D1 instead of D2 because: - it has enough features to satisfy his needs, both in language and in Phobos - it is known how it works, it works correct, and there are docs describing it - there are less things in it, so it is easier to learn and play with it Hell, if C is useful tool and you cant get simpler than it (asembler excluded), then D1 is full fledged corporate tool with great std lib. So please, don't flame D1, or youll have some angry old men on your back :)

Please don't take my posts too seriously =)
Jan 23 2010
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Steve Teale wrote:
 But I'd be
 interested to hear what the D aficionados think of Go.

http://www.digitalmars.com/d/archives/digitalmars/D/Go_rant_103530.html
Jan 23 2010
parent Steve Teale <steve.teale britseyeview.com> writes:
Walter Bright Wrote:

 Steve Teale wrote:
 But I'd be
 interested to hear what the D aficionados think of Go.

http://www.digitalmars.com/d/archives/digitalmars/D/Go_rant_103530.html

Thanks Walter, but I've had my fill now. I started a thread on golang-nuts asking for a poll on the most irritating feature of Go syntax - got a very defensive response. So we can all participate - that would be fun ;=)
Jan 23 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 24 Jan 2010 04:25:21 -0500, grauzone <none example.net> wrote:

 Or how inout(T) isn't just a shortcut to avoid writing  
 const/immutable-aware code 3 times or putting it into a template?

The benefits are: - Single implementation where all that is different is the type qualifier. (also allows the function to be virtual) - No propogation of contract through an accessor. In other words, using an inout accessor on an object or struct does not alter the caller's contract with the data itself. The latter function is almost essential for properties, for without such a mechanism, you are forced to write your property definitions in triplicate. i.e. class C {} struct S { C c; } immutable s1 = S(new C); S s2 = S(new C); immutable c1 = s1.c; C c2 = s2.c; Now, change S.c into a property. The first line of thinking is, "well, accessing c doesn't change the object itself, so it should be const." But that means you must return a const(C), so it breaks defining c1 and c2 (can't assign immutable or mutable from const). So, you say, "I'll just define it without const," but then you can't call the property unless S is a mutable type, so that only works in c2's case Maybe you think you can get away with just mutable and immutable, but again, it doesn't work if the whole object is const, since you can't call either function from there. Templates won't work here, you cannot template the 'this' pointer. So you end up with 3 identical implementations, and *no* const guarantee on the mutable one: property C c() { return _c; } property const(C) c() const { return _c; } property immutable(C) c() immutable { return _c; } Repeat this for all the properties in your object and you have a freaking mess. You can't even compose these into a common implementation unless you are willing to do some casting. The inout solution is simple to understand, does exactly what you want, and provides the most efficient binary representation (1 compiled function instead of 3 identical compiled functions). It works because const and immutable are *compile-time* restrictions, not runtime restrictions. I came up with the idea because I was trying to port Tango to D2, and I realized with the amount of properties and object use that Tango has, it would be a nightmare. It is not a hack, it is a complete, elegant solution to a very nasty problem. I'm actually quite surprised that something like this was possible, and how easy it would be to use. I predict that most functions where you would normally write const, you should write inout, and for free you get implementations for mutable, const, and immutable that work exactly how you want them to (and guarantee exactly what you want them to guarantee). -Steve
Jan 25 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 25 Jan 2010 09:05:11 -0500, Lars T. Kyllingstad  
<public kyllingen.nospamnet> wrote:

 Steven Schveighoffer wrote:
 On Sun, 24 Jan 2010 04:25:21 -0500, grauzone <none example.net> wrote:

 Or how inout(T) isn't just a shortcut to avoid writing  
 const/immutable-aware code 3 times or putting it into a template?

- Single implementation where all that is different is the type qualifier. (also allows the function to be virtual) - No propogation of contract through an accessor. In other words, using an inout accessor on an object or struct does not alter the caller's contract with the data itself. The latter function is almost essential for properties, for without such a mechanism, you are forced to write your property definitions in triplicate. i.e. class C {} struct S { C c; } immutable s1 = S(new C); S s2 = S(new C); immutable c1 = s1.c; C c2 = s2.c; Now, change S.c into a property. The first line of thinking is, "well, accessing c doesn't change the object itself, so it should be const." But that means you must return a const(C), so it breaks defining c1 and c2 (can't assign immutable or mutable from const). So, you say, "I'll just define it without const," but then you can't call the property unless S is a mutable type, so that only works in c2's case Maybe you think you can get away with just mutable and immutable, but again, it doesn't work if the whole object is const, since you can't call either function from there. Templates won't work here, you cannot template the 'this' pointer. So you end up with 3 identical implementations, and *no* const guarantee on the mutable one: property C c() { return _c; } property const(C) c() const { return _c; } property immutable(C) c() immutable { return _c; }

Out of curiosity: How does inout(T) fix this? I thought inout was all about transporting the const-ness of the input type to the return type, and in this example there are no input parameters.

inout is applied to the hidden input parameter -- this: property inout(C) inout {return _c; } -Steve
Jan 25 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 25 Jan 2010 09:26:55 -0500, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:

 inout is applied to the hidden input parameter -- this:

  property inout(C) inout {return _c; }

Wow, forgot the function name there :) property inout(C) c() inout {return _c;} -Steve
Jan 25 2010
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 25 Jan 2010 22:45:10 -0500, Ali Çehreli <acehreli yahoo.com> wrote:

 Steven Schveighoffer wrote:
  > On Sun, 24 Jan 2010 04:25:21 -0500, grauzone <none example.net> wrote:

  > Templates won't work here, you cannot template the 'this' pointer.  So
  > you end up with 3 identical implementations, and *no* const guarantee  
 on
  > the mutable one:
  >
  >  property C c() { return _c; }
  >  property const(C) c() const { return _c; }
  >  property immutable(C) c() immutable { return _c; }

 Is there a known bug in 2.039 about this feature? It doesn't seem to  
 consider the hidden this parameter:

 class C {}

 struct S
 {
     C _c;

       property inout(C) c() inout
      {
          return _c;
      }
 }

 Error: inout on return means inout must be on a parameter as well for  
 inout inout(C)()

Yes, this is a bug. inout is so fundamentally broken right now, I didn't bother reporting all the deficiencies in bugzilla, but I did mention them on the announce newsgroup. I hope within the next couple releases, it is addressed. In fact, if it is not addressed in the next release, I should probably report all the issues to bugzilla. -Steve
Jan 26 2010