www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - A proper language comparison...

reply "Xinok" <xinok live.com> writes:
Once in a while, a thread pops up in the newsgroups pitting D 
against some other language. More often than not, these 
comparisons are flawed, non-encompassing, and uninformative. Most 
recently with the article comparing D with Go and Rust, the 
community pointed out a few flaws involving a late addition of 
one of the D compilers, build configurations (-noboundscheck?), 
and the random number generator used.

Then when I think about how web browsers are compared, there are 
conventional measures and standard benchmarking tools (e.g. 
sunspider). They measure performance for javascript, rendering, 
HTML5, etc. They also measure startup times (hot/cold boot), 
memory usage, etc. Finally, there are feature comparisons, such 
as what HTML5 features each browser supports.

These are the type of comparisons I'd like to see with 
programming languages. For starters, there should be standard 
"challenges" (algorithms and such) implemented in each language 
designed to measure various aspects of the language, such as 
sorting, number crunching, and string processing. However, rather 
than leave it to a single individual to implement the algorithm 
in several different languages, it should be left to the 
community to collaborate and produce an "ideal" implementation of 
the algorithm in their language. We could analyze factors other 
than performance, such as the ease of implementation (how many 
lines? does it use safe/unsafe features? Was it optimized using 
unsafe / difficult features?).


What can we do about it? I propose we come together as a 
community, design challenges that are actually relevant and 
informative, and release the first implementations in D. Then we 
let the battle commence and invite other communities to 
contribute their own implementations in other languages. I think 
we should give it a try; start off small with just a few moderate 
challenges (not too simple or complex) and see where it goes from 
there.
Jul 25 2013
next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Thursday, 25 July 2013 at 18:23:19 UTC, Xinok wrote:

 Once in a while, a thread pops up in the newsgroups pitting D 
 against some other language. More often than not, these 
 comparisons are flawed, non-encompassing, and uninformative. 
 Most recently with the article comparing D with Go and Rust, 
 the community pointed out a few flaws involving a late addition 
 of one of the D compilers, build configurations 
 (-noboundscheck?), and the random number generator used.

 Then when I think about how web browsers are compared, there 
 are conventional measures and standard benchmarking tools (e.g. 
 sunspider). They measure performance for javascript, rendering, 
 HTML5, etc. They also measure startup times (hot/cold boot), 
 memory usage, etc. Finally, there are feature comparisons, such 
 as what HTML5 features each browser supports.

 These are the type of comparisons I'd like to see with 
 programming languages. For starters, there should be standard 
 "challenges" (algorithms and such) implemented in each language 
 designed to measure various aspects of the language, such as 
 sorting, number crunching, and string processing. However, 
 rather than leave it to a single individual to implement the 
 algorithm in several different languages, it should be left to 
 the community to collaborate and produce an "ideal" 
 implementation of the algorithm in their language. We could 
 analyze factors other than performance, such as the ease of 
 implementation (how many lines? does it use safe/unsafe 
 features? Was it optimized using unsafe / difficult features?).


 What can we do about it? I propose we come together as a 
 community, design challenges that are actually relevant and 
 informative, and release the first implementations in D. Then 
 we let the battle commence and invite other communities to 
 contribute their own implementations in other languages. I 
 think we should give it a try; start off small with just a few 
 moderate challenges (not too simple or complex) and see where 
 it goes from there.


Sounds somewhat like Rosetta Code.

http://rosettacode.org/wiki/Rosetta_Code

Bearophile spends a lot of time adding D entries there.
Jul 25 2013
prev sibling next sibling parent reply "qznc" <qznc web.de> writes:
On Thursday, 25 July 2013 at 18:23:19 UTC, Xinok wrote:

 Once in a while, a thread pops up in the newsgroups pitting D 
 against some other language. More often than not, these 
 comparisons are flawed, non-encompassing, and uninformative. 
 Most recently with the article comparing D with Go and Rust, 
 the community pointed out a few flaws involving a late addition 
 of one of the D compilers, build configurations 
 (-noboundscheck?), and the random number generator used.

 Then when I think about how web browsers are compared, there 
 are conventional measures and standard benchmarking tools (e.g. 
 sunspider). They measure performance for javascript, rendering, 
 HTML5, etc. They also measure startup times (hot/cold boot), 
 memory usage, etc. Finally, there are feature comparisons, such 
 as what HTML5 features each browser supports.

 These are the type of comparisons I'd like to see with 
 programming languages. For starters, there should be standard 
 "challenges" (algorithms and such) implemented in each language 
 designed to measure various aspects of the language, such as 
 sorting, number crunching, and string processing. However, 
 rather than leave it to a single individual to implement the 
 algorithm in several different languages, it should be left to 
 the community to collaborate and produce an "ideal" 
 implementation of the algorithm in their language. We could 
 analyze factors other than performance, such as the ease of 
 implementation (how many lines? does it use safe/unsafe 
 features? Was it optimized using unsafe / difficult features?).


Sounds very much like this: 
http://benchmarksgame.alioth.debian.org/

You can compare code size, memory need, execution time for 
various programs and lots of languages. Safety is not considered 
though, but how would you measure that?

It is called a "game", because you can adapt the weights until 
your favorite language is the winner. ;)

D entries were provided, but removed at some point, because it 
looked like the C code.
Jul 25 2013
parent Manfred Nowak <svv1999 hotmail.com> writes:
"qznc" <qznc web.de> wrote in news:buxislkfauizlnrvoyzv forum.dlang.org:


 until your favorite language is the winner.


This is a wrong path.

The winner should be found by weighting the results in such a way that all 
tested languages are at least close to equal.

If such equality can be achieved by some canonical weighting, then they are 
all equal in respect to the test battery, because all fell into the same 
equivalence class.

Only if there is more than one equivalence class, at least one extreme 
participant can be declared, which might be the winner---or the looser as 
well.

-manfred
Jul 25 2013
prev sibling next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Thursday, 25 July 2013 at 18:23:19 UTC, Xinok wrote:

 These are the type of comparisons I'd like to see with 
 programming languages. For starters, there should be standard 
 "challenges" (algorithms and such) implemented in each language 
 designed to measure various aspects of the language, such as 
 sorting, number crunching, and string processing. However, 
 rather than leave it to a single individual to implement the 
 algorithm in several different languages, it should be left to 
 the community to collaborate and produce an "ideal" 
 implementation of the algorithm in their language. We could 
 analyze factors other than performance, such as the ease of 
 implementation (how many lines? does it use safe/unsafe 
 features? Was it optimized using unsafe / difficult features?).


The problem is all those last bits:

- Line counts aren't a good measure of anything.
- What's safe and unsafe is very subjective.
- What's difficult is even more subjective.

There's also other variables:

- How idiomatic is the code?
- How well does it scale?
- How much headroom is there for more optimisation?
- How predictable is the performance?
- How well do you need to know the language's implementation to 
do optimisations?

For example, optimised Haskell will often added strict evaluation 
hints, and strict type hints, but these are very non-idiomatic, 
and work against the lazy nature of the language.

D on the other hand does quite well with all these variables: 
idiomatic D code is generally quite fast, and its abstractions 
scale quite well. Performance is predictable and the language has 
plenty of features allowing you to do unsafe things for more 
performance if you so desire.

The problem with measuring all this stuff is that it's very 
subjective, so I don't think there can be any standardised way of 
assessing language performance.
Jul 25 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Peter Alexander:


 - What's safe and unsafe is very subjective.


There are large bodies of people that count bugs in code, and 
correlate them with coding practices. They have created language 
subsets like C for automotive industry, C++ for aviation, code 
for space missions, Ada language and its successive refinements 
like Ada2012, SPARK subset of Ada. There are lot of people trying 

dependent typing (ATS language), and so on and on, even Haskell 
variants. Lot of this stuff is not based on statistical data, but 
there is also some hard data that has shaped some of those very 
strict coding guidelines. There are several serious studies in 
the field of coding safety. Dismissing all that decades old work 
with a 'very subjective' is unjust.

As usual D code safety is mostly correlated to the coding style 
you are using, how you write your unittests and code contracts, 
how much good are your code reviews, how much careful your 
programmers are, etc. But the language design is also a factor. 
To me D safety looks about intermediate between C and Ada-SPARK. 
D code normally has undetected integral overflows, it doesn't 
help a lot against null pointers (Nullable is not so good yet), 
there is no significant stack overflow protection, no 
variable-sized stack-allocated arrays that help a bit created 
bounded collections, the management of reference escaping is 
planned but not yet implemented (scope), and so on. Overall to me 
D coding seems significantly safer than C coding, and perhaps 
it's a little safer than C++11 coding too. I know no studies 
about the safety of D code compared to C++11 code or Ada2012 
code, or compared to other languages.

Bye,
bearophile
Jul 25 2013
next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Thursday, 25 July 2013 at 20:28:54 UTC, bearophile wrote:

 Peter Alexander:


 - What's safe and unsafe is very subjective.


 There are large bodies of people that count bugs in code, and 
 correlate them with coding practices. They have created 
 language subsets like C for automotive industry, C++ for 
 aviation, code for space missions, Ada language and its 
 successive refinements like Ada2012, SPARK subset of Ada. There 
 are lot of people trying sideways solutions, at Microsoft 

 and so on and on, even Haskell variants. Lot of this stuff is 
 not based on statistical data, but there is also some hard data 
 that has shaped some of those very strict coding guidelines. 
 There are several serious studies in the field of coding 
 safety. Dismissing all that decades old work with a 'very 
 subjective' is unjust.


Allow me to put it another way by way of analogy: health. We know 
from medical studies what kinds of things are healthy, and what 
things are unhealthy. However, if I were to present 10 people, 
and witness their actions for a week, would anyone be able to 
accurately order them on their "healthiness"? Would every medical 
expert arrive at the same ordering?

Maybe subjective is the wrong word to use. Maybe what I meant was 
"difficult to quantify".
Jul 25 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/25/2013 1:28 PM, bearophile wrote:

 there is no significant stack overflow protection,


It's done by the hardware (putting a "no-access" page at the end of the stack). 
There's nothing unsafe about it.



 no variable-sized stack-allocated arrays that help a bit
 created bounded collections,


I don't see how that is a safety issue.
Jul 25 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:


 It's done by the hardware (putting a "no-access" page at the 
 end of the stack). There's nothing unsafe about it.



 no variable-sized stack-allocated arrays that help a bit
 created bounded collections,


 I don't see how that is a safety issue.


In my opinion where you allocate your data influences the 
"safety" of your program, but it's not easy for me to tell 
exactly in what direction such influence is.

If you allocate too much data on the stack this could cause stack 
overflow. As you say a stack overflow is memory safe, but if your 
program is doing something important, a sudden crash could be 
regarded as dangerous for the user. You don't want a stack 
overflow in the code that controls your car brakes (this is not a 
totally invented example).

Having variable-sized stack-allocated arrays encourages you to 
put more data on the stack, increasing the risk of stack 
overflows.

On the other hand, if you only have fixed-sized stack-allocated 
arrays, you could allocate a fixed size array on the stack and 
then use only part of it. This waste of stack space increases the 
probability of stack overflow. A variable-sized stack-allocated 
array allows you to waste no stack space, and avoid those stack 
overallocations.

If you are using a segmented stack as Rust, stack overflows 
become less probable (it becomes more like a malloc failure), 
because the stack is able to become very large when needed. I 
think Rust needs that elastic stack because in such language it's 
easy to allocate all kind of stuff on the stack (unlike in D).

- - - - - - - - - -

Ada is safer compared to D for other things. One of them is the 
little mess of integer division that D has inherited from C.

This is how the Ada compiler forces you to write a certain 
division:

procedure Strong_Typing is
   Alpha : Integer := 1;
   Beta : Integer := 10;
   Result : Float;
begin
   Result := Float (Alpha) / Float (Beta);
end Strong_Typing;


In D you could write:

int a = 1;
int b = 10;
double r = a / b;

and in r you will not see the 0.1 value. This is a C design 
mistake that I have seen bite even programmers with more than 2 
years of programming experience with C-like languages. Perhaps 
having "/" and "div" for floating point and integer divisions in 
D could avoid those bugs.

Another mistake is D inheriting the C99 semantics of % that is 
suboptimal and bug-prone.
(Both mistakes are fixed in Python3, by the way, despite I don't 
fully like the Python3 division).

- - - - - - - - - -

In Ada there is 'others' to define the value of the array items 
that you are not specifying, this removes the bugs discussed in 
Issue 3849:

declare
   type Arr_Type is array (Integer range <>) of Integer;
   A1 : Arr_Type := (1, 2, 3, 4, 5, 6, 7, 8, 9);
begin
   A1 := (1, 2, 3, others => 10);
end;


'others' is usable even for struct literals, when you don't want 
to specify all fields:

type R is record
   A, B : Integer := 0;
   C : Float := 0.0;
end record;
V3 : R => (C => 1.0, others => <>);



For D I suggested array syntax like:

int[$] a1 = [1, 2, 3];
int[10] a2 = [1, 2, 3, ...];
void main() {}

where the "..." tells the compiler the programmer wants it to 
fill those missing values with their default init.


Ada Concurrency is quite refined, and it's kind of safe.

Bye,
bearophile
Jul 25 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/25/2013 7:19 PM, bearophile wrote:

 If you allocate too much data on the stack this could cause stack overflow. As
 you say a stack overflow is memory safe, but if your program is doing something
 important, a sudden crash could be regarded as dangerous for the user. You
don't
 want a stack overflow in the code that controls your car brakes (this is not a
 totally invented example).


If you are writing a program that, if it fails will cause your car to crash, 
then you are a bad engineer and you need to report to the woodshed.

As I've written before, imagining you can write a program that cannot fail, 
coupled with coming up with a requirement that a program cannot fail, is BAD 
ENGINEERING.

ALL COMPONENTS FAIL.

The way you make a system safe is design it so that it can withstand failure 
BECAUSE THE FAILURE IS GOING TO HAPPEN. I cannot emphasize this enough.


 Having variable-sized stack-allocated arrays encourages you to put more data on
 the stack, increasing the risk of stack overflows.

 On the other hand, if you only have fixed-sized stack-allocated arrays, you
 could allocate a fixed size array on the stack and then use only part of it.
 This waste of stack space increases the probability of stack overflow. A
 variable-sized stack-allocated array allows you to waste no stack space, and
 avoid those stack overallocations.


On the other hand, fixed size stack allocations are more predictable and hence
a 
stack overflow is more likely to be detected during testing.



 If you are using a segmented stack as Rust, stack overflows become less
probable
 (it becomes more like a malloc failure), because the stack is able to become
 very large when needed. I think Rust needs that elastic stack because in such
 language it's easy to allocate all kind of stuff on the stack (unlike in D).


Segmented stacks are a great idea for 20 years ago. 64 bit code has rendered
the 
idea irrelevant - you can allocate 4 billion byte stacks for each of 4 billion 
threads. You've got other problems that'll happen centuries before that limit
is 
reached.

(Segmented stacks are also a performance problem, and don't interact well with 
compiled C code.)
Jul 25 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jul 25, 2013 at 07:39:15PM -0700, Walter Bright wrote:

 On 7/25/2013 7:19 PM, bearophile wrote:

If you allocate too much data on the stack this could cause stack
overflow. As you say a stack overflow is memory safe, but if your
program is doing something important, a sudden crash could be
regarded as dangerous for the user. You don't want a stack overflow
in the code that controls your car brakes (this is not a totally
invented example).




And how does stack overflow differ from heap overflow? Either way, your
program can't continue normal execution (e.g., issue a command to engage
all brakes).



 If you are writing a program that, if it fails will cause your car to
 crash, then you are a bad engineer and you need to report to the
 woodshed.
 
 As I've written before, imagining you can write a program that
 cannot fail, coupled with coming up with a requirement that a
 program cannot fail, is BAD ENGINEERING.
 
 ALL COMPONENTS FAIL.
 
 The way you make a system safe is design it so that it can withstand
 failure BECAUSE THE FAILURE IS GOING TO HAPPEN. I cannot emphasize
 this enough.


How would a D program recover from stack overflow?


[...]

If you are using a segmented stack as Rust, stack overflows become
less probable (it becomes more like a malloc failure), because the
stack is able to become very large when needed. I think Rust needs
that elastic stack because in such language it's easy to allocate all
kind of stuff on the stack (unlike in D).


 
 Segmented stacks are a great idea for 20 years ago. 64 bit code has
 rendered the idea irrelevant - you can allocate 4 billion byte
 stacks for each of 4 billion threads. You've got other problems
 that'll happen centuries before that limit is reached.


[...]

Isn't it possible to allocate the stack at the far end of the program's
address space, so that it can grow as needed?

Apparently Linux doesn't do that, though. Or at least, not by default.

I can sorta guess why: allowing the stack to grow arbitrarily large has
the possibility of a buggy program consuming all memory resources before
getting terminated by running out of memory (say the program has an
infinite loop allocating huge gobs of stack space per iteration). On a
moderately-sized stack, the program will get killed by stack overflow
before it can do much harm; a program with unconstrained stack size may
well take down the system with it by eating up all memory (both RAM
*and* swap) before it crashes.  The system will likely grind to a halt
as it starts thrashing from lack of RAM, and then overflowing the swap,
and basically make a mess of everything before the OS finally kills off
the buggy program (assuming that the OS can recover, of course). Not
unlike a fork bomb in some ways.  :-P


T

-- 
I am Ohm of Borg. Resistance is voltage over current.
Jul 25 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/25/2013 8:39 PM, H. S. Teoh wrote:

 How would a D program recover from stack overflow?


The program doesn't. In a safe system, there'd be a backup in case the main 
program failed (which it inevitably will).


 Isn't it possible to allocate the stack at the far end of the program's
 address space, so that it can grow as needed?


That works until you have more than one thread.
Jul 25 2013
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 26 July 2013 at 02:39:15 UTC, Walter Bright wrote:

 ALL COMPONENTS FAIL.

 The way you make a system safe is design it so that it can 
 withstand failure BECAUSE THE FAILURE IS GOING TO HAPPEN. I 
 cannot emphasize this enough.


So very true, this is a rule number one for designing high 
availability systems. One must assume that any single program is 
always doomed to fail and focus on designing whole system that 
will not. Duplication, various heartbeat watchdogs and fast 
recovery times for processes are key here.

Also nothing that is powered from the same power source can't be 
considered fail-safe. ;)
Jul 26 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/26/2013 4:28 AM, Dicebot wrote:

 Also nothing that is powered from the same power source can't be considered
 fail-safe. ;)


Yup!

I had to laugh at the New Orleans practice of putting emergency generators in 
the basements.

Q. When do you need the emergency generators?
A. When the power grid goes down.

Q. What does the power grid power?
A. The pumps that keep the basements from flooding.

Q. When is the power grid most likely to fail?
A. When there's a storm that's likely to flood the basements.

Ya gotta just cry at the logic.

The basement of my house is designed so gravity will drain water out of it 
rather than requiring a sump pump. A sump pump was cheaper than the trenching 
required for a gravity drain, but losing everything in the basement would be
far 
more expensive than trenching.
Jul 26 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:


 As I've written before, imagining you can write a program that 
 cannot fail, coupled with coming up with a requirement that a 
 program cannot fail, is BAD ENGINEERING.

 ALL COMPONENTS FAIL.

 The way you make a system safe is design it so that it can 
 withstand failure BECAUSE THE FAILURE IS GOING TO HAPPEN. I 
 cannot emphasize this enough.


I agree. On the other hand in important system you usually also 
try to use more reliable single components, like military-grade 
resistors able to stand bigger temperature fluctuations. Safety 
must be pursued at all levels. That's why in both automotive and 
aeronautics for certain safety-critical routines they forbid 
recursion and require a static analysis of the max stack space 
the subprogram will require in all possible usages, to reduce a 
lot the probability of stack overflows.

In some situations stack overflows are a security problem. 
Several persons have written programs to analyse the stack usage 
of Ada-SPARK programs. Ignoring the safety hazards caused by 
stack overflows, and ignoring the tools to avoid them in 
critical-purpose routines, is very bad engineering.



 On the other hand, fixed size stack allocations are more 
 predictable and hence a stack overflow is more likely to be 
 detected during testing.


I agree. Here the interactions are not linear :-)



 Segmented stacks are a great idea for 20 years ago. 64 bit code 
 has rendered the idea irrelevant - you can allocate 4 billion 
 byte stacks for each of 4 billion threads. You've got other 
 problems that'll happen centuries before that limit is reached.


Rust designers should comment on this :-) I am not expert enough 
on this.



 (Segmented stacks are also a performance problem, and don't 
 interact well with compiled C code.)


I don't know the current situation on this, but I think they are 
trying to solve this problem in Rust, with some workaround.

Bye,
bearophile
Jul 26 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/26/2013 5:28 AM, bearophile wrote:

 I agree. On the other hand in important system you usually also try to use more
 reliable single components, like military-grade resistors able to stand bigger
 temperature fluctuations. Safety must be pursued at all levels. That's why in
 both automotive and aeronautics for certain safety-critical routines they
forbid
 recursion and require a static analysis of the max stack space the subprogram
 will require in all possible usages, to reduce a lot the probability of stack
 overflows.


Yes, and that's why your analysis of Rust's stack usage is inadequate in 
demonstrating it is safer.



 In some situations stack overflows are a security problem. Several persons have
 written programs to analyse the stack usage of Ada-SPARK programs. Ignoring the
 safety hazards caused by stack overflows, and ignoring the tools to avoid them
 in critical-purpose routines, is very bad engineering.


You can't have an undetected stack overflow if you use guard pages.



 I don't know the current situation on this, but I think they are trying to
solve
 this problem in Rust, with some workaround.


I'll add that segmented stacks are a compiler feature, not a language feature.
A 
D compiler could support segmented stacks without changing the language, 
provided calling C functions still works.

But I see no point. 32 bit code is already dead on OSX, and is rapidly dying on 
Linux and Windows. I hear from more and more outfits that they've transitioned 
to 64 bits and are not looking back.
Jul 26 2013
next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
On 7/26/13 12:50 PM, Walter Bright wrote:

 On 7/26/2013 5:28 AM, bearophile wrote:


 In some situations stack overflows are a security problem. Several persons have
 written programs to analyse the stack usage of Ada-SPARK programs. Ignoring the
 safety hazards caused by stack overflows, and ignoring the tools to avoid them
 in critical-purpose routines, is very bad engineering.


 You can't have an undetected stack overflow if you use guard pages.


If you use guard pages AND guarantee that no object exceeds the size of the
guard page.  Without the 
latter, you can only catch a subset (though a large subset).
Jul 26 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/26/2013 2:18 PM, Brad Roberts wrote:

 On 7/26/13 12:50 PM, Walter Bright wrote:

 On 7/26/2013 5:28 AM, bearophile wrote:


 In some situations stack overflows are a security problem. Several persons have
 written programs to analyse the stack usage of Ada-SPARK programs. Ignoring the
 safety hazards caused by stack overflows, and ignoring the tools to avoid them
 in critical-purpose routines, is very bad engineering.


 You can't have an undetected stack overflow if you use guard pages.


 If you use guard pages AND guarantee that no object exceeds the size of the
 guard page.  Without the latter, you can only catch a subset (though a large
 subset).


True. I've often thought it would be reasonable to restrict object sizes on the 
stack.
Jul 26 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/26/2013 2:42 PM, Walter Bright wrote:

 On 7/26/2013 2:18 PM, Brad Roberts wrote:

 On 7/26/13 12:50 PM, Walter Bright wrote:

 On 7/26/2013 5:28 AM, bearophile wrote:


 In some situations stack overflows are a security problem. Several persons have
 written programs to analyse the stack usage of Ada-SPARK programs. Ignoring the
 safety hazards caused by stack overflows, and ignoring the tools to avoid them
 in critical-purpose routines, is very bad engineering.


 You can't have an undetected stack overflow if you use guard pages.


 If you use guard pages AND guarantee that no object exceeds the size of the
 guard page.  Without the latter, you can only catch a subset (though a large
 subset).


 True. I've often thought it would be reasonable to restrict object sizes on the
 stack.


No, I was wrong. False. Stack frames larger than 4K are sequentially "probed"
so 
they'll fault on overflow.
Jul 26 2013
parent reply Brad Roberts <braddr puremagic.com> writes:
On 7/26/13 2:43 PM, Walter Bright wrote:

 On 7/26/2013 2:42 PM, Walter Bright wrote:

 On 7/26/2013 2:18 PM, Brad Roberts wrote:

 On 7/26/13 12:50 PM, Walter Bright wrote:

 On 7/26/2013 5:28 AM, bearophile wrote:


 In some situations stack overflows are a security problem. Several persons have
 written programs to analyse the stack usage of Ada-SPARK programs. Ignoring the
 safety hazards caused by stack overflows, and ignoring the tools to avoid them
 in critical-purpose routines, is very bad engineering.


 You can't have an undetected stack overflow if you use guard pages.


 If you use guard pages AND guarantee that no object exceeds the size of the
 guard page.  Without the latter, you can only catch a subset (though a large
 subset).


 True. I've often thought it would be reasonable to restrict object sizes on the
 stack.


 No, I was wrong. False. Stack frames larger than 4K are sequentially "probed"
so they'll fault on
 overflow.


Are or could be?
Jul 26 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/26/2013 3:32 PM, Brad Roberts wrote:

 No, I was wrong. False. Stack frames larger than 4K are sequentially "probed"
 so they'll fault on overflow.


 Are or could be?


Yes and yes.

https://github.com/D-Programming-Language/dmd/blob/master/src/backend/cod3.c#L3050
Jul 26 2013
parent reply Brad Roberts <braddr puremagic.com> writes:
On 7/26/13 5:38 PM, Walter Bright wrote:

 On 7/26/2013 3:32 PM, Brad Roberts wrote:

 No, I was wrong. False. Stack frames larger than 4K are sequentially "probed"
 so they'll fault on overflow.


 Are or could be?


 Yes and yes.

 https://github.com/D-Programming-Language/dmd/blob/master/src/backend/cod3.c#L3050


Um.. unless I'm reading that maze of #if's and conditionals wrong.. that's only
being done in a few 
cases, specifically never on linux.  And either way, are you asserting that all
compilers do that?
Jul 26 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/26/2013 11:20 PM, Brad Roberts wrote:

 Um.. unless I'm reading that maze of #if's and conditionals wrong.. that's only
 being done in a few cases, specifically never on linux.  And either way, are
you
 asserting that all compilers do that?


No. I'm asserting that it is a compiler issue, and an easily dealt with one,
not 
a language issue.

As for why the backend does it for some platforms and not for others, I was 
merely mimicking what other compilers did for each platform. I know that Win32 
requires this behavior, I was unsure about Linux. We can certainly investigate 
turning it on for Linux.
Jul 26 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:


 Yes, and that's why your analysis of Rust's stack usage is 
 inadequate in demonstrating it is safer.


There I was not talking about Rust, but about more constrained 
systems (where maybe Rust someday will run, but it will need some 
changes).

In desktop PCs usually there is plenty of RAM to grow a stack for 
lot of time, safely. So I think Go and Rust programs have a low 
risk of stack overflows if you run them on normal PCs.



 You can't have an undetected stack overflow if you use guard 
 pages.


They don't care about this much. For those high integrity systems 
they remove stack overflows from happening, sizing the stack with 
a careful static analysis, because for those software usages a 
stack overflow is dangerous :-) Their main problem is not 
detecting it, it's avoiding it. And for other systems a stack 
overflow can be a nuisance/problem.



 I'll add that segmented stacks are a compiler feature, not a 
 language feature. A D compiler could support segmented stacks 
 without changing the language, provided calling C functions 
 still works.


I see.



 But I see no point.


I have never asked for having a segmented stack in D. But both Go 
and Rust developers are smart people, running code mostly on 64 
bit systems, and both have designed their languages in recent 
years with segmented stacks. So perhaps you could go read their 
motivations. My guess is that Rust programs can allocate lot of 
stuff on the stack, and just like a heap a larger input data 
causes a larger stack to be used. Having an extensible stack 
probably avoids stack from exhausting too much easily on normal 
PCs. But parallelism could be another cause (that you already 
answered).

Bye,
bearophile
Jul 26 2013
prev sibling parent reply "Jacob Carlborg" <doob me.com> writes:
On Friday, 26 July 2013 at 19:50:22 UTC, Walter Bright wrote:


 But I see no point. 32 bit code is already dead on OSX, and is 
 rapidly dying on Linux and Windows. I hear from more and more 
 outfits that they've transitioned to 64 bits and are not 
 looking back.


32bit is far from dead on ARM.

--
/Jacob Carlborg
Jul 27 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/27/2013 3:24 AM, Jacob Carlborg wrote:

 On Friday, 26 July 2013 at 19:50:22 UTC, Walter Bright wrote:


 But I see no point. 32 bit code is already dead on OSX, and is rapidly dying
 on Linux and Windows. I hear from more and more outfits that they've
 transitioned to 64 bits and are not looking back.


 32bit is far from dead on ARM.


True - and DMD is far from an ARM back end :-)
Jul 27 2013
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 26 July 2013 at 02:39:15 UTC, Walter Bright wrote:

 If you are writing a program that, if it fails will cause your 
 car to crash, then you are a bad engineer and you need to 
 report to the woodshed.

 As I've written before, imagining you can write a program that 
 cannot fail, coupled with coming up with a requirement that a 
 program cannot fail, is BAD ENGINEERING.

 ALL COMPONENTS FAIL.

 The way you make a system safe is design it so that it can 
 withstand failure BECAUSE THE FAILURE IS GOING TO HAPPEN. I 
 cannot emphasize this enough.


You emphasis it quite well, and that is certainly true for a car, 
a plane, or anything potentially dangerous.

Different tradeoff apply when you talk about a video game, a 
media player or and IRC client.
Jul 26 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/26/2013 10:25 AM, deadalnix wrote:

 You emphasis it quite well, and that is certainly true for a car, a plane, or
 anything potentially dangerous.

 Different tradeoff apply when you talk about a video game, a media player or
and
 IRC client.


Of course.

There is a cost of failure, though, to things like video games and media 
players. Annoying your customers. I've dumped using many media players because 
of their tendency to freeze up. I like to set my music on in the morning and
run 
it all day. Having to regularly restart it means "abandon it and try a
different 
one."

My current media player freezes about once every couple weeks. It's infrequent 
enough to be tolerable. The Ubuntu one dies about once an hour. I gave up on 
that long ago.
Jul 26 2013
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jul 26, 2013 at 12:54:57PM -0700, Walter Bright wrote:

 On 7/26/2013 10:25 AM, deadalnix wrote:

You emphasis it quite well, and that is certainly true for a car, a
plane, or anything potentially dangerous.

Different tradeoff apply when you talk about a video game, a media
player or and IRC client.


 
 Of course.
 
 There is a cost of failure, though, to things like video games and
 media players. Annoying your customers. I've dumped using many media
 players because of their tendency to freeze up. I like to set my
 music on in the morning and run it all day. Having to regularly
 restart it means "abandon it and try a different one."


Yeah, I had that experience with my old iPod. There was no (obvious) way
to control what's running, so every once in a while, some wayward app
would start consuming all system resources and the music would start to
skip and eventually the thing would freeze. It was very annoying,
especially since there was no way to tell *what* was causing the
problem. I stopped using the iPod as a music player (sigh...).

On my new Android phone, things a slightly better -- at least there's a
task manager that I can use to kill off misbehaving programs or apps
known to exhibit erratic behaviour, before I set up the music to play
all day. That way, things are less likely to fail.



 My current media player freezes about once every couple weeks. It's
 infrequent enough to be tolerable. The Ubuntu one dies about once an
 hour. I gave up on that long ago.


That sounds pretty bad. I think my HTC phone only ever froze once since
late last year when I first got it. Every couple weeks sounds almost as
bad as my iPod (which I no longer use).


T

-- 
Computers are like a jungle: they have monitor lizards, rams, mice, c-moss,
binary trees... and bugs.
Jul 26 2013
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 26 July 2013 at 19:54:58 UTC, Walter Bright wrote:

 On 7/26/2013 10:25 AM, deadalnix wrote:

 You emphasis it quite well, and that is certainly true for a 
 car, a plane, or
 anything potentially dangerous.

 Different tradeoff apply when you talk about a video game, a 
 media player or and
 IRC client.


 Of course.

 There is a cost of failure, though, to things like video games 
 and media players. Annoying your customers. I've dumped using 
 many media players because of their tendency to freeze up. I 
 like to set my music on in the morning and run it all day. 
 Having to regularly restart it means "abandon it and try a 
 different one."


This kind of software can leverage way to recovers that would be 
untolerable in an airplane (for instance because they only work 
most of the time, or would produce an erratic behavior for a 
short period of time, like an audio glitch).

D right now is not very friendly to such use cases as it is 
designed to crash hard as soon as something wrong happens.


 My current media player freezes about once every couple weeks. 
 It's infrequent enough to be tolerable. The Ubuntu one dies 
 about once an hour. I gave up on that long ago.


On linux, I uses audacious for music, it is never crashing.
Jul 27 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/27/2013 12:40 AM, deadalnix wrote:

 This kind of software can leverage way to recovers that would be untolerable in
 an airplane (for instance because they only work most of the time, or would
 produce an erratic behavior for a short period of time, like an audio glitch).

 D right now is not very friendly to such use cases as it is designed to crash
 hard as soon as something wrong happens.


I think you're seriously mistaken about this not being "friendly". I don't
think 
there's anything "friendly" about a program that goes wild and keeps on
running. 
My experience with such programs (DOS programs would not crash, they'd just run 
wild) is universally unfriendly.

The way to deal tolerantly with errant processes is to have an "executive" 
process that spawns the worker process. It monitors the worker, and if the 
worker crashes, the executive simply respawns it. This is a reasonably friendly 
way to do things. Continuing to run already crashed programs is a very bad idea.

After all, what if your corrupted program now proceeds to corrupt all your 
user's profile data? I don't think the user would consider that friendly. What 
if your media player scrambles the playlists? (Happened to me.) Oh joy, I loved 
that one.

No thanks.

(I've been arguing for decades against the idea that somehow crashed programs 
should keep on running. I keep hearing all kinds of explanations for why
zombies 
should keep on running, even though you have no idea what they will do (except 
that it will be bad).)
Jul 27 2013
prev sibling parent reply "Jacob Carlborg" <doob me.com> writes:
On Friday, 26 July 2013 at 19:54:58 UTC, Walter Bright wrote:


 My current media player freezes about once every couple weeks. 
 It's infrequent enough to be tolerable. The Ubuntu one dies 
 about once an hour. I gave up on that long ago.


Then you should use a Mac. They're (in)famous for when the whole 
computer freezes the music keeps playing.

--
/Jacob Carlborg
Jul 27 2013
next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Saturday, 27 July 2013 at 10:31:10 UTC, Jacob Carlborg wrote:

 On Friday, 26 July 2013 at 19:54:58 UTC, Walter Bright wrote:


 My current media player freezes about once every couple weeks. 
 It's infrequent enough to be tolerable. The Ubuntu one dies 
 about once an hour. I gave up on that long ago.


 Then you should use a Mac. They're (in)famous for when the 
 whole computer freezes the music keeps playing.

 --
 /Jacob Carlborg


Or, in one memorable case for me, freezing and entering some sort 
of feedback loop, ending with my sub shaking things off my desk.
Jul 27 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/27/2013 3:31 AM, Jacob Carlborg wrote:

 On Friday, 26 July 2013 at 19:54:58 UTC, Walter Bright wrote:


 My current media player freezes about once every couple weeks. It's infrequent
 enough to be tolerable. The Ubuntu one dies about once an hour. I gave up on
 that long ago.


 Then you should use a Mac. They're (in)famous for when the whole computer
 freezes the music keeps playing.


I use a Turtlebeach Audiotron.
Jul 27 2013
parent reply "Meta" <jared771 gmail.com> writes:
On Saturday, 27 July 2013 at 17:52:20 UTC, Walter Bright wrote:

 I use a Turtlebeach Audiotron.


That may be your problem right there. Turtle Beach seems to make 
high-quality products, but in reality the quality is extremely 
poor. I have 5 (5!) friends now, as well as myself, who bought a 
Turtle Beach product, and had it break within a year and a half 
(conveniently for Turtle Beach, the warranty only lasts a year), 
or even be DOA. I would never buy a Turtle Beach product again, 
ever.
Jul 27 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/27/2013 11:50 AM, Meta wrote:

 On Saturday, 27 July 2013 at 17:52:20 UTC, Walter Bright wrote:

 I use a Turtlebeach Audiotron.


 That may be your problem right there. Turtle Beach seems to make high-quality
 products, but in reality the quality is extremely poor. I have 5 (5!) friends
 now, as well as myself, who bought a Turtle Beach product, and had it break
 within a year and a half (conveniently for Turtle Beach, the warranty only
lasts
 a year), or even be DOA. I would never buy a Turtle Beach product again, ever.


I've been running the Audiotron for maybe 12 years now, all day every day. I 
like it enough that I've bought two others. I look for a replacement now and 
then, but none offer the Audiotron's mix of features:

1. operable from the front panel or a remote
2. provides a web interface so it can be controlled from any computer on the LAN
3. does not require a server demon - it can simply read shared directories on 
the LAN for the music
4. it is very low power
5. plays internet radio stations too
6. has shuffle

For example, the Roku box I have can play music it sucks from the LAN. However,

1. need to connect it to a TV in order to control it
2. no web interface
3. can't use Roku remote without a TV display
4. requires a server demon
5. does not have shuffle

13 years after the Audiotron, the Roku is apparently the zenith of loser 
technology. I mean, it doesn't have shuffle? What the hell?
Jul 27 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/25/2013 7:19 PM, bearophile wrote:

 You don't want a stack overflow in the code that controls your car brakes
(this is not a
 totally invented example).


Sadly, it isn't:

http://www.forbes.com/sites/andygreenberg/2013/07/24/hackers-reveal-nasty-new-car-attacks-with-me-behind-the-wheel-video/

Software controlled brakes with no override? Madness!
Jul 25 2013
next sibling parent reply "Max Samukha" <maxsamukha gmail.com> writes:
On Friday, 26 July 2013 at 05:13:37 UTC, Walter Bright wrote:

 On 7/25/2013 7:19 PM, bearophile wrote:

 You don't want a stack overflow in the code that controls your 
 car brakes (this is not a
 totally invented example).


 Sadly, it isn't:

 http://www.forbes.com/sites/andygreenberg/2013/07/24/hackers-reveal-nasty-new-car-attacks-with-me-behind-the-wheel-video/

 Software controlled brakes with no override? Madness!


Only death statistics for a sufficiently long usage period could 
tell whether software + override is safer than purely software. 
Note that software + override is significantly more complex, 
which means a decrease in reliability of the system in whole.
Jul 26 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/26/2013 3:54 AM, Max Samukha wrote:

 Only death statistics for a sufficiently long usage period could tell whether
 software + override is safer than purely software. Note that software +
override
 is significantly more complex, which means a decrease in reliability of the
 system in whole.


Airliners make comprehensive use of overrides and redundancy. The proof that 
works is how incredibly overall reliable they are, despite regular failures of 
individual components.

Note that before the software brake madness, there were 3 redundant braking 
systems on a typical car. The front and back brakes were independent - one
could 
lose all fluid and the other would still work. A third independent system was 
the mechanical emergency brake.

This system has been in place for 50 years and works great.

Hell, even if all three failed, you could still put the car in gear and turn
the 
ignition off. It'll slow down pretty rapidly.
Jul 26 2013
parent reply "Chris Cain" <clcain uncg.edu> writes:
On Friday, 26 July 2013 at 19:24:44 UTC, Walter Bright wrote:

 Hell, even if all three failed, you could still put the car in 
 gear and turn the ignition off. It'll slow down pretty rapidly.


I wouldn't recommend turning the ignition off. Most cars lose 
power steering in that situation which is can be just as bad as 
or worse than losing brakes.

Most cars (including automatics) allow you to manually switch to 
lower gears which will also slow you down.
Jul 26 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/26/2013 12:30 PM, Chris Cain wrote:

 I wouldn't recommend turning the ignition off. Most cars lose power steering in
 that situation which is can be just as bad as or worse than losing brakes.


The power steering is driven by a belt connected to the crankshaft. You won't 
lose power steering with the ignition off if the engine is turning.

But you need to be careful not to engage the steering lock. That would be a big 
problem.

And also, I suggest this as a last resort if your other braking systems all
failed.


 Most cars (including automatics) allow you to manually switch to lower gears
 which will also slow you down.


I have little experience with automatics.
Jul 26 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jul 26, 2013 at 01:58:33PM -0700, Walter Bright wrote:

 On 7/26/2013 12:30 PM, Chris Cain wrote:

I wouldn't recommend turning the ignition off. Most cars lose power
steering in that situation which is can be just as bad as or worse
than losing brakes.


 
 The power steering is driven by a belt connected to the crankshaft.
 You won't lose power steering with the ignition off if the engine is
 turning.
 
 But you need to be careful not to engage the steering lock. That
 would be a big problem.
 
 And also, I suggest this as a last resort if your other braking
 systems all failed.
 

Most cars (including automatics) allow you to manually switch to
lower gears which will also slow you down.


 
 I have little experience with automatics.


I think most automatics lock the steering wheel upon power off (probably
as some kind of safety guard, maybe against inadvertent damage by some
parts that expect power to be running when the wheel is turned?).

I also use manual downshifting on my car (auto transmission) to force it
to slow down -- e.g., down a hill, when the automatic transmission will
often blindly shift to a high gear and you'll find yourself having to
burn up much of your brakes to keep the speed under control. My car has
a button that locks the maximum gear to 3rd, which is useful for keeping
within city street limits when going downhill. It also has gear
positions to force a switch to 2nd or 1st gear, though I rarely use
those since at lower speeds there's generally no need to bother with
them. In an emergency situation, forcing it to 1st gear would help
reduce the speed. (But it does take a few seconds before the auto
transmission kicks in to effect the switch -- and a few extra seconds at
high speed can be too long in an emergency situation.)

I think the one time when forcing 1st gear proved useful was when I had
to drive downhill after a heavy snowstorm -- you do *not* want to go any
higher in that situation otherwise you could easily lose friction and
slide down to a nasty crunch at the bottom. (Well, the general advice
is, don't drive in such conditions in the first place -- but then guys
like me are often rather foolhardy. :-P)


T

-- 
2+2=4. 2*2=4. 2^2=4. Therefore, +, *, and ^ are the same operation.
Jul 26 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/26/2013 2:15 PM, H. S. Teoh wrote:

 I think most automatics lock the steering wheel upon power off (probably
 as some kind of safety guard, maybe against inadvertent damage by some
 parts that expect power to be running when the wheel is turned?).


It's an anti-theft feature.



 I also use manual downshifting on my car (auto transmission) to force it
 to slow down -- e.g., down a hill, when the automatic transmission will
 often blindly shift to a high gear and you'll find yourself having to
 burn up much of your brakes to keep the speed under control. My car has
 a button that locks the maximum gear to 3rd, which is useful for keeping
 within city street limits when going downhill. It also has gear
 positions to force a switch to 2nd or 1st gear, though I rarely use
 those since at lower speeds there's generally no need to bother with
 them. In an emergency situation, forcing it to 1st gear would help
 reduce the speed. (But it does take a few seconds before the auto
 transmission kicks in to effect the switch -- and a few extra seconds at
 high speed can be too long in an emergency situation.)


Although commonplace, it is poor practice to use the engine to slow the car
down 
(unless you're dealing with brake fade from overheating).

1. Brake pads are cheap compared with engine rebuilds.

2. Using the engine as a brake can cause unburned gas to wash the oil off of
the 
cylinder walls, resulting in excessive wear.

3. The engine is not designed to be a brake. Use the brakes. Brake pads are not 
precious :-)



 I think the one time when forcing 1st gear proved useful was when I had
 to drive downhill after a heavy snowstorm -- you do *not* want to go any
 higher in that situation otherwise you could easily lose friction and
 slide down to a nasty crunch at the bottom. (Well, the general advice
 is, don't drive in such conditions in the first place -- but then guys
 like me are often rather foolhardy. :-P)


I prefer a manual trans in slippery conditions - more control.
Jul 26 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/26/13 3:52 PM, Walter Bright wrote:

 Although commonplace, it is poor practice to use the engine to slow the
 car down (unless you're dealing with brake fade from overheating).


I know next to nothing about cars so take this destruction with a grain 
of salt.


 1. Brake pads are cheap compared with engine rebuilds.


My understanding is that engine brake does not destroy the engine. It 
does not involve friction. Indeed Wikipedia agrees: 
http://en.wikipedia.org/wiki/Engine_braking and even mentions "Engine 
braking is a generally accepted practice and can help save wear on 
friction brakes".


 2. Using the engine as a brake can cause unburned gas to wash the oil
 off of the cylinder walls, resulting in excessive wear.


[citation needed]


 3. The engine is not designed to be a brake. Use the brakes. Brake pads
 are not precious :-)


Engine brake is a natural artifact of its design. I don't think you can 
build an argument around "wasn't design to do that, so don't". Engine 
braking is a widespread and common technique.

I use engine braking most of the time (I always drive manual so that's 
easy). Saves gas and I've never had a mechanic tell me "you better go 
easy with that engine brake, look at them cylinder walls!" My brake pads 
reach a state of immortality.


Andrei
Jul 26 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/26/2013 4:07 PM, Andrei Alexandrescu wrote:

 On 7/26/13 3:52 PM, Walter Bright wrote:

 Although commonplace, it is poor practice to use the engine to slow the
 car down (unless you're dealing with brake fade from overheating).


 I know next to nothing about cars so take this destruction with a grain of
salt.


 1. Brake pads are cheap compared with engine rebuilds.


 My understanding is that engine brake does not destroy the engine. It does not
 involve friction.


It's news to me that engines are frictionless! (The braking effect is only 
partially due to engine friction - the pumping of the air is most of it. But
the 
engine WEAR is due to friction.)


 Indeed Wikipedia agrees:
 http://en.wikipedia.org/wiki/Engine_braking and even mentions "Engine braking
is
 a generally accepted practice and can help save wear on friction brakes".


Of course it saves wear on the brakes. The issue is do you prefer wear on your 
engine?



 2. Using the engine as a brake can cause unburned gas to wash the oil
 off of the cylinder walls, resulting in excessive wear.


 [citation needed]


Mechanics at the dealer told me this. They had no reason to lie to me.



 3. The engine is not designed to be a brake. Use the brakes. Brake pads
 are not precious :-)


 Engine brake is a natural artifact of its design. I don't think you can build
an
 argument around "wasn't design to do that, so don't". Engine braking is a
 widespread and common technique.


I agree it is widespread and commonplace. That's why the mechanics felt it 
necessary to tell me not to do it. I was also told not to do it when I took two 
different courses in track driving - the Bob Bondurant and Skip Barber ones.



 I use engine braking most of the time (I always drive manual so that's easy).
 Saves gas and I've never had a mechanic tell me "you better go easy with that
 engine brake, look at them cylinder walls!" My brake pads reach a state of
 immortality.


The object isn't to save brake pads, it's to reduce the wear and tear on your 
engine.
Jul 26 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/26/13 4:25 PM, Walter Bright wrote:

 On 7/26/2013 4:07 PM, Andrei Alexandrescu wrote:

 On 7/26/13 3:52 PM, Walter Bright wrote:

 Although commonplace, it is poor practice to use the engine to slow the
 car down (unless you're dealing with brake fade from overheating).


 I know next to nothing about cars so take this destruction with a
 grain of salt.


 1. Brake pads are cheap compared with engine rebuilds.


 My understanding is that engine brake does not destroy the engine. It
 does not
 involve friction.


 It's news to me that engines are frictionless! (The braking effect is
 only partially due to engine friction - the pumping of the air is most
 of it. But the engine WEAR is due to friction.)


 Indeed Wikipedia agrees:
 http://en.wikipedia.org/wiki/Engine_braking and even mentions "Engine
 braking is
 a generally accepted practice and can help save wear on friction brakes".


 Of course it saves wear on the brakes. The issue is do you prefer wear
 on your engine?



 2. Using the engine as a brake can cause unburned gas to wash the oil
 off of the cylinder walls, resulting in excessive wear.


 [citation needed]


 Mechanics at the dealer told me this. They had no reason to lie to me.



 3. The engine is not designed to be a brake. Use the brakes. Brake pads
 are not precious :-)


 Engine brake is a natural artifact of its design. I don't think you
 can build an
 argument around "wasn't design to do that, so don't". Engine braking is a
 widespread and common technique.


 I agree it is widespread and commonplace. That's why the mechanics felt
 it necessary to tell me not to do it. I was also told not to do it when
 I took two different courses in track driving - the Bob Bondurant and
 Skip Barber ones.



 I use engine braking most of the time (I always drive manual so that's
 easy).
 Saves gas and I've never had a mechanic tell me "you better go easy
 with that
 engine brake, look at them cylinder walls!" My brake pads reach a
 state of
 immortality.


 The object isn't to save brake pads, it's to reduce the wear and tear on
 your engine.


I stand by my opinion and practice, and I consider yours completely 
unsubstantiated, to the extent it doesn't need further rebuttal. FWIW 
I've heard stuff from mechanics (about e.g. how ABS works) that would 
make a physicist blush.

Andrei
Jul 26 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/26/2013 4:45 PM, Andrei Alexandrescu wrote:

 I stand by my opinion and practice, and I consider yours completely
 unsubstantiated, to the extent it doesn't need further rebuttal.


It's your car!


 FWIW I've heard
 stuff from mechanics (about e.g. how ABS works) that would make a physicist
blush.


I've heard **** from mechanics, too.
Jul 26 2013
prev sibling parent reply Jordi Sayol <g.sayol yahoo.es> writes:
On 27/07/13 01:25, Walter Bright wrote:

 On 7/26/2013 4:07 PM, Andrei Alexandrescu wrote:

 On 7/26/13 3:52 PM, Walter Bright wrote:

 Although commonplace, it is poor practice to use the engine to slow the
 car down (unless you're dealing with brake fade from overheating).


 I know next to nothing about cars so take this destruction with a grain of
salt.


 1. Brake pads are cheap compared with engine rebuilds.


 My understanding is that engine brake does not destroy the engine. It does not
 involve friction.


 
 It's news to me that engines are frictionless! (The braking effect is only
partially due to engine friction - the pumping of the air is most of it. But
the engine WEAR is due to friction.)
 

 Indeed Wikipedia agrees:
 http://en.wikipedia.org/wiki/Engine_braking and even mentions "Engine braking
is
 a generally accepted practice and can help save wear on friction brakes".


 
 Of course it saves wear on the brakes. The issue is do you prefer wear on your
engine?
 
 

 2. Using the engine as a brake can cause unburned gas to wash the oil
 off of the cylinder walls, resulting in excessive wear.


 [citation needed]


 
 Mechanics at the dealer told me this. They had no reason to lie to me.


This absolutely true. About twenty years ago my friend's car broke down in a
remote location. To bring the car to the nearest mechanic (2 or 3 kilometers),
tied it to another car with a rope and used engine braking without ignition
(engine was damaged) to prevent the spring effect. Result, pistons melted by
excessive friction. This was due to the effect that Walter's mechanics clearly
explained.


 
 

 3. The engine is not designed to be a brake. Use the brakes. Brake pads
 are not precious :-)


 Engine brake is a natural artifact of its design. I don't think you can build
an
 argument around "wasn't design to do that, so don't". Engine braking is a
 widespread and common technique.


 
 I agree it is widespread and commonplace. That's why the mechanics felt it
necessary to tell me not to do it. I was also told not to do it when I took two
different courses in track driving - the Bob Bondurant and Skip Barber ones.
 
 

 I use engine braking most of the time (I always drive manual so that's easy).
 Saves gas and I've never had a mechanic tell me "you better go easy with that
 engine brake, look at them cylinder walls!" My brake pads reach a state of
 immortality.


 
 The object isn't to save brake pads, it's to reduce the wear and tear on your
engine.
 
 


-- 
Jordi Sayol
Jul 26 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/26/13 11:23 PM, Jordi Sayol wrote:

 On 27/07/13 01:25, Walter Bright wrote:

 2. Using the engine as a brake can cause unburned gas to wash
 the oil off of the cylinder walls, resulting in excessive
 wear.


 [citation needed]


 Mechanics at the dealer told me this. They had no reason to lie to
 me.


 This absolutely true. About twenty years ago my friend's car broke
 down in a remote location. To bring the car to the nearest mechanic
 (2 or 3 kilometers), tied it to another car with a rope and used
 engine braking without ignition (engine was damaged) to prevent the
 spring effect. Result, pistons melted by excessive friction. This was
 due to the effect that Walter's mechanics clearly explained.


Thanks for this anecdote. It's at the very best circumstantial. (With 
the engine off, the oil pump wasn't even started!)

I've asked Walter for one credible source on the entire Internet 
documenting the case against engine braking. He was unable to produce 
one. Instead, he attempted to explain how an increase in hysteresis can 
cause additional wear on the engine (the parts not worn under forward 
use). However, this is what one poster in http://goo.gl/Ys099U had to 
say about that:

=================
Most of the time when you drive, you're putting a load (and causing 
wear) on what I'm going to call the "forward" face of each tooth on each 
gear in your drivetrain. The front of a tooth on the crankshaft pushes 
against the back of a tooth on the next gear in line, which pushes the 
next gear, etc. When you use "engine braking", all you are doing is 
engaging the teeth in the opposite direction, and putting force and wear 
on the faces that normally are just along for the ride.

Now, does that mean you're wearing your engine out faster? Marginally... 
but the parts you're wearing out would normally have to be replaced (if 
at all) because they'd worn out from the other side; you're wearing 
surfaces that would usually be thrown out with hardly any wear at all. 
To borrow a phrase from the medical field, your engine/transmission will 
die with that wear, not of it.
=================

Of course, that's just some guy on the Internet. That's why I am asking 
for a _credible_ source (e.g. expert mechanic, respected auto magazine 
etc) that explains why and how engine brake causes problems. I for one 
looked for a while without finding one. On the contrary, many vehicle 
manuals (I've seen Audi and Honda) advise using engine brake.


Andrei
Jul 30 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/30/2013 11:18 AM, Andrei Alexandrescu wrote:

 Thanks for this anecdote. It's at the very best circumstantial. (With the
engine
 off, the oil pump wasn't even started!)


The oil pump is driven by the crankshaft, so if the engine is turning, the oil 
pump is. (There are some highly specialized race engines with an electric oil 
pump, but that is highly unlikely here.)

I was told by U-Haul that when towing a car long distance, you couldn't just
put 
the manual transmission in neutral. You had to take the driveshaft out, because 
the transmission was designed to circulate the oil based on the front shaft 
turning, not the back shaft. It would sieze after a while if you only turned
the 
back shaft.


 I've asked Walter for one credible source on the entire Internet documenting
the
 case against engine braking. He was unable to produce one. Instead, he
attempted
 to explain how an increase in hysteresis can cause additional wear on the
engine
 (the parts not worn under forward use). However, this is what one poster in
 http://goo.gl/Ys099U had to say about that:

 =================
 Most of the time when you drive, you're putting a load (and causing wear) on
 what I'm going to call the "forward" face of each tooth on each gear in your
 drivetrain. The front of a tooth on the crankshaft pushes against the back of a
 tooth on the next gear in line, which pushes the next gear, etc. When you use
 "engine braking", all you are doing is engaging the teeth in the opposite
 direction, and putting force and wear on the faces that normally are just along
 for the ride.

 Now, does that mean you're wearing your engine out faster? Marginally... but
the
 parts you're wearing out would normally have to be replaced (if at all) because
 they'd worn out from the other side; you're wearing surfaces that would usually
 be thrown out with hardly any wear at all. To borrow a phrase from the medical
 field, your engine/transmission will die with that wear, not of it.
 =================


I also pointed out the "hammering" effect of alternately forward driving then 
back driving the rotating parts, as the parts forcefully take up the slack of 
hysteresis.

I also pointed out the effect of unburned gas from backdriving washing oil off 
of the cylinder walls causing undue wear. This definitely happens with 
carbureted cars, but with modern fuel injection the fuel is shut off when 
backdriving.
Jul 30 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/30/13 11:35 AM, Walter Bright wrote:

 On 7/30/2013 11:18 AM, Andrei Alexandrescu wrote:

 Thanks for this anecdote. It's at the very best circumstantial. (With
 the engine
 off, the oil pump wasn't even started!)


 The oil pump is driven by the crankshaft, so if the engine is turning,
 the oil pump is. (There are some highly specialized race engines with an
 electric oil pump, but that is highly unlikely here.)

 I was told by U-Haul that when towing a car long distance, you couldn't
 just put the manual transmission in neutral. You had to take the
 driveshaft out, because the transmission was designed to circulate the
 oil based on the front shaft turning, not the back shaft. It would sieze
 after a while if you only turned the back shaft.


So that invalidates the anecdote.


 I also pointed out the "hammering" effect of alternately forward driving
 then back driving the rotating parts, as the parts forcefully take up
 the slack of hysteresis.


I guess any brisk adjustment of throttle would be unadvisable, one 
direction or another (i.e. releasing the clutch with a large difference 
in rotation). Back driving, however, happens as soon as one just lifts 
the foot off the pedal - the inertia of the car pushes on the engine.


 I also pointed out the effect of unburned gas from backdriving washing
 oil off of the cylinder walls causing undue wear. This definitely
 happens with carbureted cars, but with modern fuel injection the fuel is
 shut off when backdriving.


That's my understanding as well. With fuel injection, essentially 
backdriving is rolling on zero gas consumption while preserving some 
mechanical energy - aweee-sooome.


Andrei
Jul 30 2013
next sibling parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Tue, 30 Jul 2013 12:02:46 -0700, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 On 7/30/13 11:35 AM, Walter Bright wrote:

 On 7/30/2013 11:18 AM, Andrei Alexandrescu wrote:

 Thanks for this anecdote. It's at the very best circumstantial. (With
 the engine
 off, the oil pump wasn't even started!)


 The oil pump is driven by the crankshaft, so if the engine is turning,
 the oil pump is. (There are some highly specialized race engines with an
 electric oil pump, but that is highly unlikely here.)

 I was told by U-Haul that when towing a car long distance, you couldn't
 just put the manual transmission in neutral. You had to take the
 driveshaft out, because the transmission was designed to circulate the
 oil based on the front shaft turning, not the back shaft. It would sieze
 after a while if you only turned the back shaft.


 So that invalidates the anecdote.


 I also pointed out the "hammering" effect of alternately forward driving
 then back driving the rotating parts, as the parts forcefully take up
 the slack of hysteresis.


 I guess any brisk adjustment of throttle would be unadvisable, one  
 direction or another (i.e. releasing the clutch with a large difference  
 in rotation). Back driving, however, happens as soon as one just lifts  
 the foot off the pedal - the inertia of the car pushes on the engine.


 I also pointed out the effect of unburned gas from backdriving washing
 oil off of the cylinder walls causing undue wear. This definitely
 happens with carbureted cars, but with modern fuel injection the fuel is
 shut off when backdriving.


 That's my understanding as well. With fuel injection, essentially  
 backdriving is rolling on zero gas consumption while preserving some  
 mechanical energy - aweee-sooome.


 Andrei


Back driving ("compression braking" in the automotive world) is indeed a  
recommend procedure in modern cars. My dad (ASE Master Tech) recommends it  
as a way to save wear on the brakes and is as you've noted, quite an  
efficient use of energy. Heck, it's one of the first things he taught me  
how to do when I was learning how to drive.

Toyota took it one step further and built a capability into the Prius  
where the electric driveline reverses it's polarity and uses motors to  
slow down the car while simultaneously recharging the battery as the car  
slows down instead of using the brakes. It's called regenerative braking.  
Needless to say, we don't do brakes very often on Prius'.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
Jul 30 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jul 30, 2013 at 12:16:11PM -0700, Adam Wilson wrote:
[...]

 Toyota took it one step further and built a capability into the
 Prius where the electric driveline reverses it's polarity and uses
 motors to slow down the car while simultaneously recharging the
 battery as the car slows down instead of using the brakes. It's
 called regenerative braking. Needless to say, we don't do brakes
 very often on Prius'.


[...]

I got a Prius when renting a car once, and it was incredibly
fuel-efficient. I had it for a week, and drove it all over the place
including from LAX all the way to Irvine and back, and the tank was
still half full by the time I returned the car. I found that when
braking, the dashboard display shows that the battery is recharging. It
even has a diagram to show you how efficient your driving is, and from
experimentation, I found that gradual acceleration/braking resulted in
the highest efficiency (keeps the battery bar near the top) -- probably
because it was maximally postponing fuel consumption and using
regenerative braking instead of the brake pads.

My only regret was paying for the fuel plan (full tank of gas), because
I underestimated the car's efficiency, when I could've just let them
fill up half the tank at the end for a lower total price instead.


T

-- 
If you think you are too small to make a difference, try sleeping in a
closed room with a mosquito. -- Jan van Steenbergen
Jul 30 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/30/13 1:01 PM, H. S. Teoh wrote:

 My only regret was paying for the fuel plan (full tank of gas), because
 I underestimated the car's efficiency, when I could've just let them
 fill up half the tank at the end for a lower total price instead.


Yah, never do that. Whoever came up with that idea was a marketing 
genius. Must have made a bunch of extra $ to the rental companies.

Andrei
Jul 30 2013
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 30 July 2013 at 21:58:04 UTC, Andrei Alexandrescu 
wrote:

 On 7/30/13 1:01 PM, H. S. Teoh wrote:

 My only regret was paying for the fuel plan (full tank of 
 gas), because
 I underestimated the car's efficiency, when I could've just 
 let them
 fill up half the tank at the end for a lower total price 
 instead.


 Yah, never do that. Whoever came up with that idea was a 
 marketing genius. Must have made a bunch of extra $ to the 
 rental companies.

 Andrei


What exactly is the "fuel plan"? Every time I've ever rented a 
car, it was "here is a car with a full tank. You must return it 
with a full tank. (or pay for the missing fuel)".
Jul 31 2013
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jul 31, 2013 at 12:18:34PM +0200, monarch_dodra wrote:

 On Tuesday, 30 July 2013 at 21:58:04 UTC, Andrei Alexandrescu wrote:

On 7/30/13 1:01 PM, H. S. Teoh wrote:

My only regret was paying for the fuel plan (full tank of gas),
because I underestimated the car's efficiency, when I could've just
let them fill up half the tank at the end for a lower total price
instead.


Yah, never do that. Whoever came up with that idea was a marketing
genius. Must have made a bunch of extra $ to the rental companies.

Andrei


 
 What exactly is the "fuel plan"? Every time I've ever rented a car,
 it was "here is a car with a full tank. You must return it with a
 full tank. (or pay for the missing fuel)".


Like Andrei said, it's a marketing genius' idea. Basically they say, pay
us a full tank of gas up front, and you can bring the car in without
worrying about filling up at the end. Of course, nobody would fall for
it if they don't also include a discounted gas price for the full tank.
The temptation then becomes trying to run the tank as low as possible
before returning it in order to "get your money's worth".


T

-- 
Just because you survived after you did it, doesn't mean it wasn't stupid!
Jul 31 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/30/2013 12:16 PM, Adam Wilson wrote:

 Back driving ("compression braking" in the automotive world) is indeed a
 recommend procedure in modern cars. My dad (ASE Master Tech) recommends it as a
 way to save wear on the brakes and is as you've noted, quite an efficient use
of
 energy. Heck, it's one of the first things he taught me how to do when I was
 learning how to drive.

 Toyota took it one step further and built a capability into the Prius where the
 electric driveline reverses it's polarity and uses motors to slow down the car
 while simultaneously recharging the battery as the car slows down instead of
 using the brakes. It's called regenerative braking. Needless to say, we don't
do
 brakes very often on Prius'.


If the engine *is designed for it*, that's a different story entirely. The 
engines I work on were not designed for it.
Jul 30 2013
parent "Adam Wilson" <flyboynw gmail.com> writes:
On Tue, 30 Jul 2013 15:43:36 -0700, Walter Bright  
<newshound2 digitalmars.com> wrote:


 On 7/30/2013 12:16 PM, Adam Wilson wrote:

 Back driving ("compression braking" in the automotive world) is indeed a
 recommend procedure in modern cars. My dad (ASE Master Tech) recommends  
 it as a
 way to save wear on the brakes and is as you've noted, quite an  
 efficient use of
 energy. Heck, it's one of the first things he taught me how to do when  
 I was
 learning how to drive.

 Toyota took it one step further and built a capability into the Prius  
 where the
 electric driveline reverses it's polarity and uses motors to slow down  
 the car
 while simultaneously recharging the battery as the car slows down  
 instead of
 using the brakes. It's called regenerative braking. Needless to say, we  
 don't do
 brakes very often on Prius'.


 If the engine *is designed for it*, that's a different story entirely.  
 The engines I work on were not designed for it.


Well Toyota's Prius engine is just a simple powerplant with no connection  
to the road whatsoever, it's just a really cool technology. And electric  
motors are very different beasts from IC motors. :-)

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
Jul 30 2013
prev sibling parent Jordi Sayol <g.sayol yahoo.es> writes:
On 30/07/13 21:02, Andrei Alexandrescu wrote:

 On 7/30/13 11:35 AM, Walter Bright wrote:

 On 7/30/2013 11:18 AM, Andrei Alexandrescu wrote:

 Thanks for this anecdote. It's at the very best circumstantial. (With
 the engine
 off, the oil pump wasn't even started!)


 The oil pump is driven by the crankshaft, so if the engine is turning,
 the oil pump is. (There are some highly specialized race engines with an
 electric oil pump, but that is highly unlikely here.)

 I was told by U-Haul that when towing a car long distance, you couldn't
 just put the manual transmission in neutral. You had to take the
 driveshaft out, because the transmission was designed to circulate the
 oil based on the front shaft turning, not the back shaft. It would sieze
 after a while if you only turned the back shaft.


 
 So that invalidates the anecdote.


I feel guilty...


 

 I also pointed out the "hammering" effect of alternately forward driving
 then back driving the rotating parts, as the parts forcefully take up
 the slack of hysteresis.


 
 I guess any brisk adjustment of throttle would be unadvisable, one direction
or another (i.e. releasing the clutch with a large difference in rotation).
Back driving, however, happens as soon as one just lifts the foot off the pedal
- the inertia of the car pushes on the engine.
 

 I also pointed out the effect of unburned gas from backdriving washing
 oil off of the cylinder walls causing undue wear. This definitely
 happens with carbureted cars, but with modern fuel injection the fuel is
 shut off when backdriving.


 
 That's my understanding as well. With fuel injection, essentially backdriving
is rolling on zero gas consumption while preserving some mechanical energy -
aweee-sooome.
 
 
 Andrei
 


-- 
Jordi Sayol
Jul 30 2013
prev sibling parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Tue, 30 Jul 2013 11:35:08 -0700, Walter Bright  
<newshound2 digitalmars.com> wrote:


 On 7/30/2013 11:18 AM, Andrei Alexandrescu wrote:

 Thanks for this anecdote. It's at the very best circumstantial. (With  
 the engine
 off, the oil pump wasn't even started!)


 The oil pump is driven by the crankshaft, so if the engine is turning,  
 the oil pump is. (There are some highly specialized race engines with an  
 electric oil pump, but that is highly unlikely here.)

 I was told by U-Haul that when towing a car long distance, you couldn't  
 just put the manual transmission in neutral. You had to take the  
 driveshaft out, because the transmission was designed to circulate the  
 oil based on the front shaft turning, not the back shaft. It would sieze  
 after a while if you only turned the back shaft.


That depends entirely on your specific car and how you want to tow it.  
Four-down towing is the preferred method and since all four wheels are  
touching the ground all you need to do is make sure that the transmission  
is self lubricating. For example, my wife's Manual 2002 Honda CR-V is  
ideal for towing even though it's AWD because both the transmission and  
rear differential are self-lubricating. You have to change the fluid more  
often, 40k instead of 120k, but that's about it. There are whole websites  
devoted to which cars are best for this and how to do it in the RV world.  
:-)


 I've asked Walter for one credible source on the entire Internet  
 documenting the
 case against engine braking. He was unable to produce one. Instead, he  
 attempted
 to explain how an increase in hysteresis can cause additional wear on  
 the engine
 (the parts not worn under forward use). However, this is what one  
 poster in
 http://goo.gl/Ys099U had to say about that:

 =================
 Most of the time when you drive, you're putting a load (and causing  
 wear) on
 what I'm going to call the "forward" face of each tooth on each gear in  
 your
 drivetrain. The front of a tooth on the crankshaft pushes against the  
 back of a
 tooth on the next gear in line, which pushes the next gear, etc. When  
 you use
 "engine braking", all you are doing is engaging the teeth in the  
 opposite
 direction, and putting force and wear on the faces that normally are  
 just along
 for the ride.

 Now, does that mean you're wearing your engine out faster?  
 Marginally... but the
 parts you're wearing out would normally have to be replaced (if at all)  
 because
 they'd worn out from the other side; you're wearing surfaces that would  
 usually
 be thrown out with hardly any wear at all. To borrow a phrase from the  
 medical
 field, your engine/transmission will die with that wear, not of it.
 =================


 I also pointed out the "hammering" effect of alternately forward driving  
 then back driving the rotating parts, as the parts forcefully take up  
 the slack of hysteresis.

 I also pointed out the effect of unburned gas from backdriving washing  
 oil off of the cylinder walls causing undue wear. This definitely  
 happens with carbureted cars, but with modern fuel injection the fuel is  
 shut off when backdriving.


My dad has been an ASE Master Technician for my entire life and teaches  
Emissions Certification classes for our state. What I am about to say is  
based stuff I've picked up from him.

I would go one step further and point out that in modern vehicles, those  
made after the EPA catalytic converter and air quality mandates of the  
early 80's, that any oil in the combustion chamber is a Very Bad Thing.  
Unburned hydrocarbons are highly destructive to catalytic converters and  
oil never burns completely during combustion. In fact we rebuilt the  
engine on my 1996 Honda Accord in 2010 precisely because it was starting  
to burn oil. And indeed, a year later the catalytic converter failed  
anyway due to the excessive strain placed on it by the partially burned  
oil that was forced through it prior to the rebuild.

My dad actually recommended engine braking (the correct term is  
"compression braking" btw, Thanks Dad!) as a way to reduce wear on the  
brakes. The google poster is correct in this statement that all you're  
doing is putting strain on parts that aren't used that way much, unless  
you reverse a lot. We see cars ranging from the early 80's on up,  
including carbureted, and we've NEVER once seen a car with a transmission  
or engine that died because of compression braking. Given our sample size  
of somewhere over 10,000 ... :-)

The automotive industry has spent obscene amounts of money getting the  
absolute cleanest burn they can to meet CAFE standards, and the very first  
thing they did was get the oil out of the combustion chamber. I'll also  
say that based on my dad's experience's with the Emissions class that even  
competent techs are having a VERY difficult time understanding this stuff,  
the chemistry involved is Ph.D stuff, and now ignition system are getting  
they way too. My dad has often lamented that working on cars is now more  
about understanding the computer control systems than it is the mechanics  
of it. Your average dealer tech probably has no clue what they are talking  
about since they have no reason to invest in learning this stuff. They  
don't see the car again after the warranty runs out and these systems  
rarely fail in five years. At least that's been my dad's experience with  
them.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
Jul 30 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/30/2013 12:06 PM, Adam Wilson wrote:

 My dad has been an ASE Master Technician for my entire life and teaches
 Emissions Certification classes for our state. What I am about to say is based
 stuff I've picked up from him.

 I would go one step further and point out that in modern vehicles, those made
 after the EPA catalytic converter and air quality mandates of the early 80's,
 that any oil in the combustion chamber is a Very Bad Thing. Unburned
 hydrocarbons are highly destructive to catalytic converters and oil never burns
 completely during combustion. In fact we rebuilt the engine on my 1996 Honda
 Accord in 2010 precisely because it was starting to burn oil. And indeed, a
year
 later the catalytic converter failed anyway due to the excessive strain placed
 on it by the partially burned oil that was forced through it prior to the
rebuild.

 My dad actually recommended engine braking (the correct term is "compression
 braking" btw, Thanks Dad!) as a way to reduce wear on the brakes. The google
 poster is correct in this statement that all you're doing is putting strain on
 parts that aren't used that way much, unless you reverse a lot. We see cars
 ranging from the early 80's on up, including carbureted, and we've NEVER once
 seen a car with a transmission or engine that died because of compression
 braking. Given our sample size of somewhere over 10,000 ... :-)


How would you know if excessive wear was caused by engine braking or not? 
Excessive wear can be caused by all kinds of things, like not letting the
engine 
warm up before driving it hard, or running long between oil changes, shifting 
prematurely or too late, etc.



 The automotive industry has spent obscene amounts of money getting the absolute
 cleanest burn they can to meet CAFE standards, and the very first thing they
did
 was get the oil out of the combustion chamber. I'll also say that based on my
 dad's experience's with the Emissions class that even competent techs are
having
 a VERY difficult time understanding this stuff, the chemistry involved is Ph.D
 stuff, and now ignition system are getting they way too. My dad has often
 lamented that working on cars is now more about understanding the computer
 control systems than it is the mechanics of it. Your average dealer tech
 probably has no clue what they are talking about since they have no reason to
 invest in learning this stuff. They don't see the car again after the warranty
 runs out and these systems rarely fail in five years. At least that's been my
 dad's experience with them.


I'll have to add that my knowledge of these things is pre-1990. So are the cars 
I work on :-)
Jul 30 2013
parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Tue, 30 Jul 2013 15:40:52 -0700, Walter Bright  
<newshound2 digitalmars.com> wrote:


 On 7/30/2013 12:06 PM, Adam Wilson wrote:

 My dad has been an ASE Master Technician for my entire life and teaches
 Emissions Certification classes for our state. What I am about to say  
 is based
 stuff I've picked up from him.

 I would go one step further and point out that in modern vehicles,  
 those made
 after the EPA catalytic converter and air quality mandates of the early  
 80's,
 that any oil in the combustion chamber is a Very Bad Thing. Unburned
 hydrocarbons are highly destructive to catalytic converters and oil  
 never burns
 completely during combustion. In fact we rebuilt the engine on my 1996  
 Honda
 Accord in 2010 precisely because it was starting to burn oil. And  
 indeed, a year
 later the catalytic converter failed anyway due to the excessive strain  
 placed
 on it by the partially burned oil that was forced through it prior to  
 the rebuild.

 My dad actually recommended engine braking (the correct term is  
 "compression
 braking" btw, Thanks Dad!) as a way to reduce wear on the brakes. The  
 google
 poster is correct in this statement that all you're doing is putting  
 strain on
 parts that aren't used that way much, unless you reverse a lot. We see  
 cars
 ranging from the early 80's on up, including carbureted, and we've  
 NEVER once
 seen a car with a transmission or engine that died because of  
 compression
 braking. Given our sample size of somewhere over 10,000 ... :-)


 How would you know if excessive wear was caused by engine braking or  
 not? Excessive wear can be caused by all kinds of things, like not  
 letting the engine warm up before driving it hard, or running long  
 between oil changes, shifting prematurely or too late, etc.


Personally, I wouldn't. :-) But my Dad studied metallurgy as a minor at UW  
and let's just say that he enjoys Metal Failure Analysis WAY more than one  
could charitably consider normal for a human.

Aviation Sidebar: His favorite metallurgy class was taught by an active  
duty Boeing incident response team member and his favorite story was his  
teacher dragging the failed main gear bogey of a 727 into the room and  
asking the class to figure out what went wrong.

If my dad says he has never seen that type of problem, he probably hasn't.  
Based on watching do failure analysis' on cars, my guess is that there  
would be telltales that clue him into what was happening. As far as the  
combustion chamber goes, when we rebuilt my 96 Accord it had some minor  
pitting from the repeated explosions but nothing else of note at at 225k.  
We resurfaced the barrels and moved on. And I'm a commensurate compression  
braker. :-)

Indeed, the other things you listed are quite evil on the internals of the  
engine. Particularly going too long between oil changes. But compression  
braking isn't on the list from an engineering standpoint. The components  
of the transmission and engine and much beefier than they strictly need to  
be. No manufacturer wants THAT recall at 5k per repair. Essentially, it's  
not any different than driving forward, you are just reversing the stress  
on components that were engineered to handle it moving forward. And in the  
case of automatics, the Torque Converter acts as a buffer between the  
engine and transmission at cruising speeds (varying by model) until it  
hits the lock-up.


 The automotive industry has spent obscene amounts of money getting the  
 absolute
 cleanest burn they can to meet CAFE standards, and the very first thing  
 they did
 was get the oil out of the combustion chamber. I'll also say that based  
 on my
 dad's experience's with the Emissions class that even competent techs  
 are having
 a VERY difficult time understanding this stuff, the chemistry involved  
 is Ph.D
 stuff, and now ignition system are getting they way too. My dad has  
 often
 lamented that working on cars is now more about understanding the  
 computer
 control systems than it is the mechanics of it. Your average dealer tech
 probably has no clue what they are talking about since they have no  
 reason to
 invest in learning this stuff. They don't see the car again after the  
 warranty
 runs out and these systems rarely fail in five years. At least that's  
 been my
 dad's experience with them.


 I'll have to add that my knowledge of these things is pre-1990. So are  
 the cars I work on :-)


Hehe, Emissions Control only really got complicated in the last 15 years  
or so. And most people drive cars newer than 15 years, unlike the Crazy  
Leader of D Who Shall Remain Nameless. ;-)

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
Jul 30 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/30/2013 4:22 PM, Adam Wilson wrote:

 Indeed, the other things you listed are quite evil on the internals of the
 engine. Particularly going too long between oil changes. But compression
braking
 isn't on the list from an engineering standpoint. The components of the
 transmission and engine and much beefier than they strictly need to be.


Eh, I'm less convinced about that. I've had two transmissions shatter going 
steady speed at 30 mph. I doubled the horsepower in my dodge, the first thing 
that needed upgrading was the transmission (replaced the whole thing). I also 
upgraded the springs, driveshaft, bell housing (don't want my feet cut off), 
flywheel & clutch, brakes, and mounts. Not to mention everything inside the 
engine is upgraded, such as going from a cast to a forged crank (3x stronger).

I didn't upgrade the differential and rear axle. Those do tend to be beefier 
than necessary.

If I went to more than double the power, I'd have to do things like weld extra 
bracing into the frame, "tub" the rear chassis, go to fat tires, put in a roll 
cage, etc.



 No manufacturer wants THAT recall at 5k per repair. Essentially, it's not any
 different than driving forward, you are just reversing the stress on components
 that were engineered to handle it moving forward.


It also assumes that the profile of the gears and the hardening on them is 
symmetric. It probably is - but I don't know that for a fact.



 And most people drive cars newer than 15 years, unlike the Crazy Leader of D
Who
 Shall Remain Nameless. ;-)


There's just something about a hotrodder doing it by reflashing the SD memory 
that leaves me cold :-)

I just don't care for new cars. The only ones that piqued my interest are the 
retro Mustang and the retro Challenger. Not even the new Ferraris look 
interesting. I'll rent cars on trips, and I can't even recall what brand they 
were. Zzzzzzz.

I'll just conclude with a video on why electric cars will always suck and why 
Detroit has never made anything worth buying since 1972:

http://www.youtube.com/watch?v=PsUnBQE8jhE
Jul 30 2013
next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Tue, 30 Jul 2013 18:14:25 -0700, Walter Bright  
<newshound2 digitalmars.com> wrote:


 On 7/30/2013 4:22 PM, Adam Wilson wrote:

 Indeed, the other things you listed are quite evil on the internals of  
 the
 engine. Particularly going too long between oil changes. But  
 compression braking
 isn't on the list from an engineering standpoint. The components of the
 transmission and engine and much beefier than they strictly need to be.


 Eh, I'm less convinced about that. I've had two transmissions shatter  
 going steady speed at 30 mph. I doubled the horsepower in my dodge, the  
 first thing that needed upgrading was the transmission (replaced the  
 whole thing). I also upgraded the springs, driveshaft, bell housing  
 (don't want my feet cut off), flywheel & clutch, brakes, and mounts. Not  
 to mention everything inside the engine is upgraded, such as going from  
 a cast to a forged crank (3x stronger).


Huh, I can't recall a story of that ever happening to a Honda or Toyota.  
We've had people install towkits on Minivans without the required oil  
cooler and set their transmissions on fire. But never shattering... Now  
the Japanese tend to source higher quality metal than the American  
manufacturers do, so that might be it...


 I didn't upgrade the differential and rear axle. Those do tend to be  
 beefier than necessary.

 If I went to more than double the power, I'd have to do things like weld  
 extra bracing into the frame, "tub" the rear chassis, go to fat tires,  
 put in a roll cage, etc.



 No manufacturer wants THAT recall at 5k per repair. Essentially, it's  
 not any
 different than driving forward, you are just reversing the stress on  
 components
 that were engineered to handle it moving forward.


 It also assumes that the profile of the gears and the hardening on them  
 is symmetric. It probably is - but I don't know that for a fact.



 And most people drive cars newer than 15 years, unlike the Crazy Leader  
 of D Who
 Shall Remain Nameless. ;-)


 There's just something about a hotrodder doing it by reflashing the SD  
 memory that leaves me cold :-)


It's kind of hard to be proud of 5 minutes of effort. :-D


 I just don't care for new cars. The only ones that piqued my interest  
 are the retro Mustang and the retro Challenger. Not even the new  
 Ferraris look interesting. I'll rent cars on trips, and I can't even  
 recall what brand they were. Zzzzzzz.


I have to admit the tech in new cars is very appealing to me. But at this  
point now we're talking about taste, which I try not to debate people on.  
:-)


 I'll just conclude with a video on why electric cars will always suck  
 and why Detroit has never made anything worth buying since 1972:

 http://www.youtube.com/watch?v=PsUnBQE8jhE


I'm with you on the electric cars. I'll proudly drive my oil burning  
pollution machines till I die. But if we want to make money in the  
automotive maintenance world, we gotta follow the crowd... *sigh*

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
Jul 30 2013
prev sibling parent reply Jeff Nowakowski <jeff dilacero.org> writes:
On 07/30/2013 09:14 PM, Walter Bright wrote:

 There's just something about a hotrodder doing it by reflashing the SD
 memory that leaves me cold :-)

 I just don't care for new cars. The only ones that piqued my interest
 are the retro Mustang and the retro Challenger. Not even the new
 Ferraris look interesting. I'll rent cars on trips, and I can't even
 recall what brand they were. Zzzzzzz.

 I'll just conclude with a video on why electric cars will always suck
 and why Detroit has never made anything worth buying since 1972:

 http://www.youtube.com/watch?v=PsUnBQE8jhE


Grow up, Walter. You're not a teenager anymore. Driving a noisy, 
inefficient car doesn't make you cool. It makes you a pathetic man 
trying to recapture his youth while annoying the neighbors and making a 
fool of himself.
Aug 01 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/1/2013 3:52 AM, Jeff Nowakowski wrote:

 Grow up, Walter. You're not a teenager anymore. Driving a noisy, inefficient
car
 doesn't make you cool. It makes you a pathetic man trying to recapture his
youth
 while annoying the neighbors and making a fool of himself.


One advantage to growing older is ceasing to care what others think about the 
things I enjoy.

You might be amused to know that I've been driving muscle cars since I was a 
kid, and was the only one at college with one, the only one at any of the 
companies I've worked for, the only one in my neighborhood, etc. Motorheads are 
few and far between. The only time I run into others is at a meet or the drag 
strip. I'd drive my other car on dates because girls didn't like them. It's 
pretty rare to see one on the road. You could say those cars were never cool 
among my peers, who'd often just look at the car blankly, and pine for a BMW or 
Porsche.

BTW, you don't think the Prius is a status symbol? :-)
Aug 01 2013
parent reply Jeff Nowakowski <jeff dilacero.org> writes:
On 08/01/2013 02:14 PM, Walter Bright wrote:

 BTW, you don't think the Prius is a status symbol? :-)


Nope, they're an affordable and practical car, and quite common these 
days. Tesla, now that's a status symbol.
Aug 01 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/1/2013 11:37 AM, Jeff Nowakowski wrote:

 On 08/01/2013 02:14 PM, Walter Bright wrote:

 BTW, you don't think the Prius is a status symbol? :-)


 Nope, they're an affordable and practical car, and quite common these days.
 Tesla, now that's a status symbol.


"as long as the hybrid remains a symbol of a driver’s commitment to the 
environment, especially among the nation’s wealthiest, the future of the
Prius 
should be secure."

http://www.forbes.com/sites/eco-nomics/2012/08/09/is-the-toyota-prius-the-latest-status-symbol-of-the-wealthy/


The Prius isn't very green, either:

"When you factor in all the energy it takes to drive and build a Prius it takes 
almost 50% more energy than a Hummer. In a study by CNW Marketing called "Dust 
to Dust", researchers discovered that the Prius costs and average of $3.25 per 
mile driven over a lifetime of 100,000 miles (the expected lifespan of a 
hybrid). On the other hand the Hummer costs $1.95 per mile over an expected 
300,000 miles. Which means that the Hummer will last three times as long and
use 
less energy than the Prius."

http://www.thetorquereport.com/2007/03/toyotas_prius_is_less_efficien.html


It's not easy being green :-)
Aug 01 2013
next sibling parent "Tofu Ninja" <emmons0 purdue.edu> writes:
On Thursday, 1 August 2013 at 18:56:03 UTC, Walter Bright wrote:

 It's not easy being green :-)


ALL I CAN THINK ABOUT IS THE CHEETOS COMMERCIALS!

"It's not easy being cheesy"
Aug 01 2013
prev sibling next sibling parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Thu, 01 Aug 2013 11:56:02 -0700, Walter Bright  =

<newshound2 digitalmars.com> wrote:


 On 8/1/2013 11:37 AM, Jeff Nowakowski wrote:

 On 08/01/2013 02:14 PM, Walter Bright wrote:

 BTW, you don't think the Prius is a status symbol? :-)


 Nope, they're an affordable and practical car, and quite common these=




  =


 days.
 Tesla, now that's a status symbol.


 "as long as the hybrid remains a symbol of a driver=E2=80=99s commitme=


nt to the  =


 environment, especially among the nation=E2=80=99s wealthiest, the fut=


ure of the  =


 Prius should be secure."

 http://www.forbes.com/sites/eco-nomics/2012/08/09/is-the-toyota-prius-=


the-latest-status-symbol-of-the-wealthy/

 The Prius isn't very green, either:

 "When you factor in all the energy it takes to drive and build a Prius=


  =


 it takes almost 50% more energy than a Hummer. In a study by CNW  =



 Marketing called "Dust to Dust", researchers discovered that the Prius=


  =


 costs and average of $3.25 per mile driven over a lifetime of 100,000 =


 =


 miles (the expected lifespan of a hybrid). On the other hand the Humme=


r  =


 costs $1.95 per mile over an expected 300,000 miles. Which means that =


 =


 the Hummer will last three times as long and use less energy than the =


 =


 Prius."

 http://www.thetorquereport.com/2007/03/toyotas_prius_is_less_efficien.=


html

 It's not easy being green :-)


If we've learned anything at the shop it's that people can't be bothered=
  =

with the facts. They seriously don't care if you have studies backing up=
  =

the environmental damage, they believe they are green and will take thos=
e  =

beliefs to their graves. Ideology is funny that way. :-)

-- =

Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
Aug 01 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/1/13 12:05 PM, Adam Wilson wrote:

 If we've learned anything at the shop it's that people can't be bothered
 with the facts. They seriously don't care if you have studies backing up
 the environmental damage, they believe they are green and will take
 those beliefs to their graves. Ideology is funny that way. :-)


You betcha. Related, you destroyed the myth that engine braking is any 
bad, but I bet money nobody changed opinions.

About green driving, Prius, and Tesla - it's all about what industry you 
want to sustain. Everything that stands behind the Hummer as a road car 
is an abomination, pure and simple. Of course I'd agree plenty of Prius 
drivers are as snooty as it gets in a different way. Yet the reality 
remains that the Hummer is an evolutionary dead end, and hybrids are a 
stepping stone to a better future.

My current car is a nice and economic Honda Fit. It is the very last 
internal combustion engine I'll ever own - I hope my next car will be a 
Tesla (regardless of what anyone thinks about it being a status symbol). 
Buying a dinosaur juice-based engine at this point is as much fail as 
buying a carriage with horses in 1915. I predict that internal 
combustion engines will be seen in less than a hundred years as weird 
inefficient contraptions, like we think of steam engines today.

Also, there is a beauty about electrical engines - their theoretical 
efficiency is 100%, they are simple, principled, entropy-neutral, and 
work on conservative laws. (Batteries are more unwieldy though.)


Andrei
Aug 01 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/1/2013 12:39 PM, Andrei Alexandrescu wrote:

 You betcha. Related, you destroyed the myth that engine braking is any bad, but
 I bet money nobody changed opinions.


For an engine designed for it, sure. For an engine not designed for it, no. A 
carbureted engine is still going to have the unburned gas problem (and you're 
not going to be very green pumping out semi-burned hydrocarbons out the 
tailpipe). I don't know at what point injected systems began shutting off the 
fuel when backdriving.


 Also, there is a beauty about electrical engines - their theoretical efficiency
 is 100%, they are simple, principled, entropy-neutral, and work on conservative
 laws. (Batteries are more unwieldy though.)


You're right, it's all about the batteries. They're a gigantic problem that, 
while there are incremental improvements, is still far from a solution. But 
gasoline engines are also getting incremental improvements. Modern ones are
way, 
way better than the ones from the 60's in just about every aspect.

There's an inherent efficiency in gas cars in that the energy is generated on 
site. For electric cars, the energy is generated elsewhere (at the power
plant), 
and then you're faced with all the losses from transmitting the energy, storing 
it, and recovering it. It's a tough hill to climb. Gasoline is pretty
remarkable 
in its energy density and portability.

BTW, with a manual trans, you can get quite a bit better mileage than the EPA 
ratings. Google "hypermiling" for ways. I do that stuff routinely.
Aug 01 2013
next sibling parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Thu, 01 Aug 2013 13:17:51 -0700, Walter Bright  
<newshound2 digitalmars.com> wrote:


 On 8/1/2013 12:39 PM, Andrei Alexandrescu wrote:

 You betcha. Related, you destroyed the myth that engine braking is any  
 bad, but
 I bet money nobody changed opinions.


 For an engine designed for it, sure. For an engine not designed for it,  
 no. A carbureted engine is still going to have the unburned gas problem  
 (and you're not going to be very green pumping out semi-burned  
 hydrocarbons out the tailpipe). I don't know at what point injected  
 systems began shutting off the fuel when backdriving.


I think most manufacturers made that change in the early 80's with all the  
EPA mandates. So basically anything still on the road that isn't a  
Classic. :-)


 Also, there is a beauty about electrical engines - their theoretical  
 efficiency
 is 100%, they are simple, principled, entropy-neutral, and work on  
 conservative
 laws. (Batteries are more unwieldy though.)


 You're right, it's all about the batteries. They're a gigantic problem  
 that, while there are incremental improvements, is still far from a  
 solution. But gasoline engines are also getting incremental  
 improvements. Modern ones are way, way better than the ones from the  
 60's in just about every aspect.


And getting better every year. We're starting to see widespread use of  
Gasoline Direct Injection and better ignition technologies. The reason we  
aren't seeing major improvement in gas mileage is because every year new  
government safety mandates add an average of 30lbs to the car.


 There's an inherent efficiency in gas cars in that the energy is  
 generated on site. For electric cars, the energy is generated elsewhere  
 (at the power plant), and then you're faced with all the losses from  
 transmitting the energy, storing it, and recovering it. It's a tough  
 hill to climb. Gasoline is pretty remarkable in its energy density and  
 portability.


In fact, in raw terms, Gasoline has significantly higher energy density  
than batteries. And that matters more than you'd think. The Prius for  
example weighs something like 2900lbs where the typical gasoline powered  
car of the same size weighs around 2000lbs. This is due to the need for a  
large array of batteries and carrying around both a gasoline motor and  
electrical motors. That has a direct effect on the amount of energy  
required to move it's mass. So per pound, Gasoline has Batteries  
thoroughly beaten, and according to a friend of mine who works in the  
field (he designs the inverters that convert battery energy to energy  
usable by things like automotive electric motors) this will remain so for  
the foreseeable future. (AKA, nothing groundbreaking on the horizon.)


 BTW, with a manual trans, you can get quite a bit better mileage than  
 the EPA ratings. Google "hypermiling" for ways. I do that stuff  
 routinely.


You did forget to mention that you piss off everyone behind though... ;-P

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
Aug 01 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/1/2013 1:53 PM, Adam Wilson wrote:

 You did forget to mention that you piss off everyone behind though... ;-P


I do pay attention to what's behind me when doing it. I'll hypermile much more 
aggressively when there's nobody behind me.
Aug 01 2013
parent "Adam Wilson" <flyboynw gmail.com> writes:
On Thu, 01 Aug 2013 14:11:03 -0700, Walter Bright  
<newshound2 digitalmars.com> wrote:


 On 8/1/2013 1:53 PM, Adam Wilson wrote:

 You did forget to mention that you piss off everyone behind though...  
 ;-P


 I do pay attention to what's behind me when doing it. I'll hypermile  
 much more aggressively when there's nobody behind me.


That just makes you a very rare person. ;-)

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
Aug 01 2013
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Aug 01, 2013 at 01:17:51PM -0700, Walter Bright wrote:
[...]

 There's an inherent efficiency in gas cars in that the energy is
 generated on site. For electric cars, the energy is generated
 elsewhere (at the power plant), and then you're faced with all the
 losses from transmitting the energy, storing it, and recovering it.
 It's a tough hill to climb. Gasoline is pretty remarkable in its
 energy density and portability.


[...]

Your comparison isn't totally accurate. Gasoline stores energy in the
form of chemical bonds, and batteries store energy in the form of
electrical charge.  Both release the energy on site.

The advantage of gasoline is that chemical bonds in gasoline are far
more persistent than the electrical charge in batteries, and they are
also denser in terms of units of energy per volume than batteries made
with current technology. That's why gasoline is so much easier to store,
transport, and have very high efficiency.

The disadvantage of gasoline is that in a sense we're "cheating",
because the energy stored in it was built up over millions of years by
ancient organisms that have long decayed, and we're only now discharging
all that build-up. We didn't pay anything to put that energy there,
that's why it's so economical. If we had to live on synthetic gasoline,
it'd be a totally different story (it *is* possible to synthesize this
stuff, y'know, and attain the same efficiency, if not better; the
problem is that this costs far too much to compete with the stuff we
"stole" from ancient organisms).


T

-- 
People tell me that I'm skeptical, but I don't believe it.
Aug 01 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/1/2013 2:30 PM, H. S. Teoh wrote:

 The disadvantage of gasoline is that in a sense we're "cheating",
 because the energy stored in it was built up over millions of years by
 ancient organisms that have long decayed, and we're only now discharging
 all that build-up. We didn't pay anything to put that energy there,
 that's why it's so economical.


Yet the electric power to charge the batteries comes from burning coal and 
natural gas :-)

Yeah, I know, solar, wind, etc. But that's still way off in providing base
power.

Like I said, it ain't easy being green. It's hard to do a "dust to dust" 
analysis, and most of the time people simply choose to ignore costs that are 
hard to calculate.
Aug 01 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Aug 01, 2013 at 02:40:57PM -0700, Walter Bright wrote:

 On 8/1/2013 2:30 PM, H. S. Teoh wrote:

The disadvantage of gasoline is that in a sense we're "cheating",
because the energy stored in it was built up over millions of years
by ancient organisms that have long decayed, and we're only now
discharging all that build-up. We didn't pay anything to put that
energy there, that's why it's so economical.


 
 Yet the electric power to charge the batteries comes from burning coal
 and natural gas :-)
 
 Yeah, I know, solar, wind, etc. But that's still way off in providing
 base power.


The ancient organisms conveniently collected all that solar energy for
us in a convenient, easy-to-use, highly efficient form. We're still
"cheating" if we're merely diverting some of that pre-collected energy
into another form just so we can make convincing presentations about
being green.



 Like I said, it ain't easy being green. It's hard to do a "dust to
 dust" analysis, and most of the time people simply choose to ignore
 costs that are hard to calculate.


The bottom line is that to be truly green, we have to spend millions of
years building up reservoirs of fuel built from solar energy. The rate
at which we're burning up energy in today's society is simply untenable
in the long run. (Well, there's always nuclear energy, of which there is
plenty to go around, but it comes with other disadvantages. :-P  Some
days you win, most days you lose.)


T

-- 
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald Knuth
Aug 01 2013
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 1 August 2013 at 21:52:19 UTC, H. S. Teoh wrote:

 The bottom line is that to be truly green, we have to spend 
 millions of
 years building up reservoirs of fuel built from solar energy.
 The rate
 at which we're burning up energy in today's society is simply 
 untenable
 in the long run.


I don't believe this is true. It's a technological hurdle, but I 
don't see any reason that it's an insurmountable one.


 (Well, there's always nuclear energy, of which there is
 plenty to go around, but it comes with other disadvantages. :-P
  Some
 days you win, most days you lose.)


 T


Surely you mean most days you win, some days you lose? Nuclear is 
great 99.9% of the time, the someone doesn't do their job 
properly and wooops....

My hopes are with fusion. Specifically ITER. My research is on 
diagnostics/data analysis for tokamaks, working with the guys at 
Culham, UK (MAST and JET). They are cautiously optimistic.
Aug 01 2013
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Thursday, 1 August 2013 at 22:10:07 UTC, John Colvin wrote:

 My hopes are with fusion. Specifically ITER. My research is on 
 diagnostics/data analysis for tokamaks, working with the guys 
 at Culham, UK (MAST and JET). They are cautiously optimistic.


When you read about fusion energy, you *can't* not be optimistic 
about it. At times though, it feels like its *such* a 
technological and *financial* hurdle, that the question is more 
like "Will we have mastered this technology before gas prices get 
so high a global recession will prevent us from ever financing 
the research?"
Aug 01 2013
parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 2 August 2013 at 06:50:46 UTC, monarch_dodra wrote:

 On Thursday, 1 August 2013 at 22:10:07 UTC, John Colvin wrote:

 My hopes are with fusion. Specifically ITER. My research is on 
 diagnostics/data analysis for tokamaks, working with the guys 
 at Culham, UK (MAST and JET). They are cautiously optimistic.


 When you read about fusion energy, you *can't* not be 
 optimistic about it. At times though, it feels like its *such* 
 a technological and *financial* hurdle, that the question is 
 more like "Will we have mastered this technology before gas 
 prices get so high a global recession will prevent us from ever 
 financing the research?"


When I say they are cautiosly optimistic, I mean that they are 
optimistic that ITER will be the last big pre-prototype Tokamak. 
Next step prototype powerplant.
Aug 02 2013
prev sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Thursday, 1 August 2013 at 21:40:57 UTC, Walter Bright wrote:

 On 8/1/2013 2:30 PM, H. S. Teoh wrote:

 The disadvantage of gasoline is that in a sense we're 
 "cheating",
 because the energy stored in it was built up over millions of 
 years by
 ancient organisms that have long decayed, and we're only now 
 discharging
 all that build-up. We didn't pay anything to put that energy 
 there,
 that's why it's so economical.


 Yet the electric power to charge the batteries comes from 
 burning coal and natural gas :-)

 Yeah, I know, solar, wind, etc. But that's still way off in 
 providing base power.

 Like I said, it ain't easy being green. It's hard to do a "dust 
 to dust" analysis, and most of the time people simply choose to 
 ignore costs that are hard to calculate.


That's in the US. Most of Europe is on nuclear power.

If we set aside controversies on the dangers of plant meltdown 
(BTW, Fukushima was hit by a mag 9 *and* a tidal wave, just 
saying), it *is* about over 9000 times greener.

IMO, nuclear power is like airplanes: Spectacular when an 
accidents happen, but at the end of the day (IMO) safer: Coal 
miners die by the 100's when a cave in happens, and thousands of 
people die in china due to coal pollution.
Aug 01 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/1/2013 11:46 PM, monarch_dodra wrote:

 That's in the US. Most of Europe is on nuclear power.

 If we set aside controversies on the dangers of plant meltdown (BTW, Fukushima
 was hit by a mag 9 *and* a tidal wave, just saying), it *is* about over 9000
 times greener.

 IMO, nuclear power is like airplanes: Spectacular when an accidents happen, but
 at the end of the day (IMO) safer: Coal miners die by the 100's when a cave in
 happens, and thousands of people die in china due to coal pollution.


I know. The problems with nukes are political, not technological.

All the plant safety problems can be solved.

I also don't really understand the issue with radiation that lasts 10,000
years. 
It, by definition, will be extremely weak radiation.
Aug 02 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/1/2013 12:39 PM, Andrei Alexandrescu wrote:

 (regardless of what anyone thinks about it being a status symbol).


Nobody admits that they select a car based on its status signals, even the 
people who pick anti-status symbols, as that's its own status signal!

Reminds me of that old Dr. Pepper commercial: "Join the non-conformists!"
Aug 01 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/1/13 1:29 PM, Walter Bright wrote:

 On 8/1/2013 12:39 PM, Andrei Alexandrescu wrote:

 (regardless of what anyone thinks about it being a status symbol).


 Nobody admits that they select a car based on its status signals, even
 the people who pick anti-status symbols, as that's its own status signal!


Good point.

Andrei
Aug 01 2013
prev sibling next sibling parent "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
On Thursday, 1 August 2013 at 19:40:36 UTC, Andrei Alexandrescu
wrote:
clip


 My current car is a nice and economic Honda Fit. It is the very 
 last internal combustion engine I'll ever own - I hope my next 
 car will be a Tesla (regardless of what anyone thinks about it 
 being a status symbol). Buying a dinosaur juice-based engine at 
 this point is as much fail as buying a carriage with horses in 
 1915. I predict that internal combustion engines will be seen 
 in less than a hundred years as weird inefficient contraptions, 
 like we think of steam engines today.


clip

If you really want to go green, you should get an electric bike
and ride that :o) Then no one can accuse you of buying it as a
status symbol, but of course you will likely be killed by one of
the Hummer drivers.

Craig
Aug 01 2013
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Thu, 01 Aug 2013 12:39:52 -0700, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 On 8/1/13 12:05 PM, Adam Wilson wrote:

 If we've learned anything at the shop it's that people can't be bothered
 with the facts. They seriously don't care if you have studies backing up
 the environmental damage, they believe they are green and will take
 those beliefs to their graves. Ideology is funny that way. :-)


 You betcha. Related, you destroyed the myth that engine braking is any  
 bad, but I bet money nobody changed opinions.


Indeed. :-)


 About green driving, Prius, and Tesla - it's all about what industry you  
 want to sustain. Everything that stands behind the Hummer as a road car  
 is an abomination, pure and simple. Of course I'd agree plenty of Prius  
 drivers are as snooty as it gets in a different way. Yet the reality  
 remains that the Hummer is an evolutionary dead end, and hybrids are a  
 stepping stone to a better future.


The most efficient/effective method would be to power the roads and then  
have cars draw energy from that. With battery storage for where the roads  
are unpowered. That way you could draw on the power generation capacities  
of Fission or Fusion devices without needing to stick one in every car.  
That would greatly reduce the amount of battery capacity needed for the  
average trips.


 My current car is a nice and economic Honda Fit. It is the very last  
 internal combustion engine I'll ever own - I hope my next car will be a  
 Tesla (regardless of what anyone thinks about it being a status symbol).  
 Buying a dinosaur juice-based engine at this point is as much fail as  
 buying a carriage with horses in 1915. I predict that internal  
 combustion engines will be seen in less than a hundred years as weird  
 inefficient contraptions, like we think of steam engines today.


Personally, I am hoping for Zero-Point Energy powered cars, or if not  
that, then at least a Mr. Fusion (apologies to all who don't get the  
somewhat dated cultural reference).


 Also, there is a beauty about electrical engines - their theoretical  
 efficiency is 100%, they are simple, principled, entropy-neutral, and  
 work on conservative laws. (Batteries are more unwieldy though.)


 Andrei



-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
Aug 01 2013
prev sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 08/01/2013 12:39 PM, Andrei Alexandrescu wrote:


 you destroyed the myth that engine braking is any bad, but I bet money
 nobody changed opinions.


You owe Adam a dollar! :)

I have been engine braking since the day I started driving. Then I 
started following the AudiWorld forums, where I learned that "brakes 
were for stopping and the engine was for going." There were a lot of 
anecdotes told.

Anyway, I am consciously readjusting to engine braking again after 
reading this thread.

Ali

[OT OT] While I have the microphone, let me rant about automatic 
transmissions: They are undrivable for me because they are not 
responsive and because they never know that the imminent road condition 
requires shifting down, now. Every time I have to drive an automatic I 
have to try to soothe myself. :)
Aug 01 2013
prev sibling parent reply Jeff Nowakowski <jeff dilacero.org> writes:
On 08/01/2013 02:56 PM, Walter Bright wrote:

 "as long as the hybrid remains a symbol of a driver’s commitment to the
 environment, especially among the nation’s wealthiest, the future of the
 Prius should be secure."

 http://www.forbes.com/sites/eco-nomics/2012/08/09/is-the-toyota-prius-the-latest-status-symbol-of-the-wealthy/


I wonder how old most of those cars are, because these days there are 
lots of alternative hybrids, with the Prius being one of the cheaper 
ones. I think this meme has an expiration date, and is already starting 
to taste sour.


 The Prius isn't very green, either:

 "When you factor in all the energy it takes to drive and build a Prius
 it takes almost 50% more energy than a Hummer. In a study by CNW
 Marketing called "Dust to Dust", researchers discovered that the Prius
 costs and average of $3.25 per mile driven over a lifetime of 100,000
 miles (the expected lifespan of a hybrid). On the other hand the Hummer
 costs $1.95 per mile over an expected 300,000 miles. Which means that
 the Hummer will last three times as long and use less energy than the
 Prius."

 http://www.thetorquereport.com/2007/03/toyotas_prius_is_less_efficien.html


 It's not easy being green :-)


http://google.com/search?q=prius+hummer
--> 
http://www.thecarconnection.com/tips-article/1010861_prius-versus-hummer-exploding-the-myth

"But Toyota also says that the study uses an unrealistically low 
estimated lifetime for hybrids, and that there's no data to support its 
assumptions in this. For instance, according to the study the average 
Prius is expected to go 109,000 miles over its lifetime, while a Hummer 
H1 would go 379,000 miles. CNW says about hybrids: “…these are generally 
secondary vehicles in a household OR they are driven in restricted or 
short range environments such as college campuses or retirement 
neighborhoods.”"

So even assuming CNW is correct about the buyer and usage, if that same 
buyer had bought a Hummer instead it would have been driven the same 
miles as the Prius. There are a lot of other disputes pointed out in the 
article. The CNW study looks like a hit piece.
Aug 01 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/1/2013 5:17 PM, Jeff Nowakowski wrote:

 On 08/01/2013 02:56 PM, Walter Bright wrote:

 http://www.forbes.com/sites/eco-nomics/2012/08/09/is-the-toyota-prius-the-latest-status-symbol-of-the-wealthy/


 I think this
 meme has an expiration date, and is already starting to taste sour.


The article is a year old, not that ancient. It's far from the only one on the 
topic. Google "prius status symbol". Even South Park famously did an episode on
it.



 "But Toyota also says that the study uses an unrealistically low estimated
 lifetime for hybrids, and that there's no data to support its assumptions in
 this. For instance, according to the study the average Prius is expected to go
 109,000 miles over its lifetime, while a Hummer H1 would go 379,000 miles. CNW
 says about hybrids: “…these are generally secondary vehicles in a
household OR
 they are driven in restricted or short range environments such as college
 campuses or retirement neighborhoods.”"


So the prius is more cost effective because you drive it less?



 So even assuming CNW is correct about the buyer and usage, if that same buyer
 had bought a Hummer instead it would have been driven the same miles as the
 Prius. There are a lot of other disputes pointed out in the article. The CNW
 study looks like a hit piece.


The Hummer is the poster boy for polluting Americans, and the Prius the poster 
boy for enlightened environmental consciousness. The truth is a lot harder to 
get at than that.

What does work is, of course, orienting your life so you drive less. Like
living 
closer to work, combining errands into one trip, carpooling, biking, using 
Amazon instead of going to the mall, etc.
Aug 01 2013
next sibling parent reply Jeff Nowakowski <jeff dilacero.org> writes:
On 08/01/2013 09:24 PM, Walter Bright wrote:

 The article is a year old, not that ancient.It's far from the only
 one on the topic. Google "prius status symbol".


That's why I wondered how old the cars were. You don't buy cars like
groceries. If the same stat was true in 5-10 years I'd be surprised.


 Even South Park famously did an episode on it.


Yes, in 2006! The market has changed a lot since then, from many more 
hybrid models to choose from, to all-electric vehicles. If you want to 
flaunt wealth and eco-smugness, get a Tesla.


 So the prius is more cost effective because you drive it less?


It's about an apples-to-apples comparison. There's a lot of upfront cost
to creating a car. If you drove it for a year and trashed it your
environmental numbers would look horrible. Alternatively, you
could put a lot more miles on the Prius if you wanted to. The Prius has
taxis with over 200,000 miles on them.

And that was just one point of contention. You don't seem very
interested in looking critically at this report, instead going for Glenn
Beck level analysis.


 The Hummer is the poster boy for polluting Americans, and the Prius
 the poster boy for enlightened environmental consciousness. The
 truth is a lot harder to get at than that.

 What does work is, of course, orienting your life so you drive less.
 Like living closer to work, combining errands into one trip,
 carpooling, biking, using Amazon instead of going to the mall, etc.


So here you are advocating to drive less, unlike the 379,000 mile
Hummer. Make up your mind.
Aug 01 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/1/2013 9:46 PM, Jeff Nowakowski wrote:

 So here you are advocating to drive less, unlike the 379,000 mile
 Hummer. Make up your mind.


We could go on for weeks back and forth with clever ripostes. I don't really 
care to, this is the wrong forum for that.
Aug 01 2013
parent reply Jeff Nowakowski <jeff dilacero.org> writes:
On 08/02/2013 01:30 AM, Walter Bright wrote:

 We could go on for weeks back and forth with clever ripostes. I don't
 really care to, this is the wrong forum for that.


I wasn't interested in "clever ripostes". I was interested in 
intellectual honesty.

And while this is certainly the wrong forum, it hasn't stopped you 
before when discussing other off-topic stuff. Of course, you need not 
reply, or you could invoke your ownership privs and either delete my 
posts or demand I make no further ones.
Aug 02 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/2/13 12:23 AM, Jeff Nowakowski wrote:

 On 08/02/2013 01:30 AM, Walter Bright wrote:

 We could go on for weeks back and forth with clever ripostes. I don't
 really care to, this is the wrong forum for that.


 I wasn't interested in "clever ripostes". I was interested in
 intellectual honesty.

 And while this is certainly the wrong forum, it hasn't stopped you
 before when discussing other off-topic stuff. Of course, you need not
 reply, or you could invoke your ownership privs and either delete my
 posts or demand I make no further ones.


Whoa, what's the matter here?

Andrei
Aug 02 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 2 August 2013 at 01:24:31 UTC, Walter Bright wrote:

 What does work is, of course, orienting your life so you drive 
 less. Like living closer to work, combining errands into one 
 trip, carpooling, biking, using Amazon instead of going to the 
 mall, etc.


Good luck with that in a country where cars are religious 
material.
Aug 01 2013
prev sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 26 July 2013 at 05:13:37 UTC, Walter Bright wrote:

 On 7/25/2013 7:19 PM, bearophile wrote:

 You don't want a stack overflow in the code that controls your 
 car brakes (this is not a
 totally invented example).


 Sadly, it isn't:

 http://www.forbes.com/sites/andygreenberg/2013/07/24/hackers-reveal-nasty-new-car-attacks-with-me-behind-the-wheel-video/

 Software controlled brakes with no override? Madness!


I presume you always had some override system with anything 
critical at Boeing?


P.S. I don't suppose you happened to work with Bogdan Hnat there? 
It's a long shot as I think you would have left before he started.
Jul 26 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/26/2013 4:10 AM, John Colvin wrote:

 On Friday, 26 July 2013 at 05:13:37 UTC, Walter Bright wrote:

 Software controlled brakes with no override? Madness!


 I presume you always had some override system with anything critical at Boeing?


ALWAYS! This was hammered into us. Millions of flights without fatalities? That 
couldn't possibly happen without such systematic design.

I am continually amazed at critical systems design in Fukushima and Deep Water 
Horizon that have no backups or overrides.

I'd fire any engineer that came to me the second time with a critical system 
design he argues "can't fail" and doesn't need a backup/override.



 P.S. I don't suppose you happened to work with Bogdan Hnat there? It's a long
 shot as I think you would have left before he started.


I left Boeing around 1982. I've never heard of Bogdan Hnat, and I think I would 
have remembered an unusual name like that :-)
Jul 26 2013
parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Friday, 26 July 2013 at 19:38:06 UTC, Walter Bright wrote:

 I am continually amazed at critical systems design in Fukushima 
 and Deep Water Horizon that have no backups or overrides.


I hope I'm not being unfair, but my impression was that the very 
impressive modern safety record of air travel is at least partly 
down to lessons learned from some major historical catastrophes. 
The one that always springs to mind is the De Havilland jets 
breaking apart mid-flight due to metal fatigue.

The number of flights and resulting near misses surely helps to 
battle test safely procedures and designs. That volume of 
learning opportunities can't readily be matched in many other 
industries.

That's not to defend the examples you cite -- the holes in safety 
provision in both of them were pretty shocking.
Jul 26 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/26/2013 3:03 PM, Joseph Rushton Wakeling wrote:

 I hope I'm not being unfair, but my impression was that the very impressive
 modern safety record of air travel is at least partly down to lessons learned
 from some major historical catastrophes.


Designers make mistakes even in redundant systems - sometimes they turn out to 
be coupled so a failure in one causes a failure in the backup. Sometimes
certain 
failure modes are not anticipated.

But one thing they do NOT do is assume that component X cannot fail.



 The one that always springs to mind is
 the De Havilland jets breaking apart mid-flight due to metal fatigue.


Boeing's fix for that not only involved fixing the particular fatigue problem, 
but designing the structure so WHEN IT DOES CRACK the crack will not bring the 
airplane down.

This design has been proven through a handful of incidents where an airliner
has 
lost whole panels due to cracking and yet the structure remained sound.



 The number of flights and resulting near misses surely helps to battle test
 safely procedures and designs. That volume of learning opportunities can't
 readily be matched in many other industries.


The most important lesson learned from aviation accidents is that all
components 
can and will fail, so you need layers of redundancy. The airplane is far too 
complicated to rely on crash investigations to identify problems.

I watched a show on the Concorde the other day, and was shocked to learn that 
there'd been an earlier incident where a tire burst on takeoff, the tire parts 
had penetrated the wing fuel tank, and the fuel drained away. The industry 
decided to ignore fixing it - and a few years later, it happened again, but
this 
time the leak caught fire and killed everybody.
Jul 26 2013
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 07/27/2013 01:39 AM, Walter Bright wrote:

 Designers make mistakes even in redundant systems - sometimes they turn out to
 be coupled so a failure in one causes a failure in the backup. Sometimes
certain
 failure modes are not anticipated.
 
 But one thing they do NOT do is assume that component X cannot fail.
 

 The one that always springs to mind is
 the De Havilland jets breaking apart mid-flight due to metal fatigue.


 
 Boeing's fix for that not only involved fixing the particular fatigue problem,
 but designing the structure so WHEN IT DOES CRACK the crack will not bring the
 airplane down.
 
 This design has been proven through a handful of incidents where an airliner
has
 lost whole panels due to cracking and yet the structure remained sound.


I have to say, one of these days I'd really like to buy you a beer (or two, or
three...) and have a long, long conversation about these (and other) aspects of
aerospace engineering.  I imagine it would be fascinating. :-)

But I do think I'm correct in asserting that the particular disaster with the
Comet didn't just result in learning about a new mode of failure and how to cope
with it, but in an awful lot of new knowledge about designing safety procedures,
analysing faults and crash data, and so on?


 The number of flights and resulting near misses surely helps to battle test
 safely procedures and designs. That volume of learning opportunities can't
 readily be matched in many other industries.


 
 The most important lesson learned from aviation accidents is that all
components
 can and will fail, so you need layers of redundancy. The airplane is far too
 complicated to rely on crash investigations to identify problems.
 
 I watched a show on the Concorde the other day, and was shocked to learn that
 there'd been an earlier incident where a tire burst on takeoff, the tire parts
 had penetrated the wing fuel tank, and the fuel drained away. The industry
 decided to ignore fixing it - and a few years later, it happened again, but
this
 time the leak caught fire and killed everybody.


I want to stress that I never suggested relying on crash investigations!  I said
"near misses" ... :-)

What I mean is that I would have thought that with the number of flights taking
place, there would be a continuous stream of data available about individual
component failures and other problems arising in the course of flights, and that
tracking and analysing that data would play a major role in anticipating
potential future issues, such as modes of failure that hadn't previously been
anticipated.  The example you give with the concorde is exactly the sort of
thing that one would expect _should_ have prevented the later fatal accident.

My point was that this volume of data isn't necessarily available in other
engineering situations, so one might anticipate that in these areas it's more
likely that minor failures will be overlooked rather than learned from, as they
are rarer and possibly not numerous enough to build up enough data to make
predictions.

Of course, even if sufficient data was available, it wouldn't save them if the
design (or management) culture didn't take into account the basic principles
you've described.
Jul 30 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/30/2013 5:16 PM, Joseph Rushton Wakeling wrote:

 I have to say, one of these days I'd really like to buy you a beer (or two, or
 three...) and have a long, long conversation about these (and other) aspects of
 aerospace engineering.  I imagine it would be fascinating. :-)


So there, Andrei!



 But I do think I'm correct in asserting that the particular disaster with the
 Comet didn't just result in learning about a new mode of failure and how to
cope
 with it, but in an awful lot of new knowledge about designing safety
procedures,
 analysing faults and crash data, and so on?


The disaster did usher in the modern era of crash investigation.



 What I mean is that I would have thought that with the number of flights taking
 place, there would be a continuous stream of data available about individual
 component failures and other problems arising in the course of flights, and
that
 tracking and analysing that data would play a major role in anticipating
 potential future issues, such as modes of failure that hadn't previously been
 anticipated.  The example you give with the concorde is exactly the sort of
 thing that one would expect _should_ have prevented the later fatal accident.


You're right in that there's a flood of service data coming back, and there's
an 
engineering team that is constantly improving the parts based on that service 
data. They track every single part, where it came from, what batch it was in, 
who inspected it, it's service history, what airplane it's on, etc.



 My point was that this volume of data isn't necessarily available in other
 engineering situations, so one might anticipate that in these areas it's more
 likely that minor failures will be overlooked rather than learned from, as they
 are rarer and possibly not numerous enough to build up enough data to make
 predictions.


I know that car companies will buy cars out of junkyards and take them apart 
looking for service issues, but yeah, tracking everything is too expensive for
them.



 Of course, even if sufficient data was available, it wouldn't save them if the
 design (or management) culture didn't take into account the basic principles
 you've described.


Boeing (and every other airframe company) would be out of business if they 
didn't have that culture. What I find surprising is that other industries seem 
completely unaware of this methodology. They're stuck in the naive "the design 
requires that this part cannot fail" mindset.
Jul 30 2013
prev sibling parent reply "SomeDude" <lovelydear mailmetrash.com> writes:
On Thursday, 25 July 2013 at 20:03:52 UTC, Peter Alexander wrote:

 The problem is all those last bits:

 - Line counts aren't a good measure of anything.


That's why some people prefer to compare a gzipped version of the 
source code. The gzipped version gives a more fair account of the 
code size.
Jul 26 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jul 26, 2013 at 08:21:45PM +0200, SomeDude wrote:

 On Thursday, 25 July 2013 at 20:03:52 UTC, Peter Alexander wrote:

The problem is all those last bits:

- Line counts aren't a good measure of anything.


 
 That's why some people prefer to compare a gzipped version of the
 source code. The gzipped version gives a more fair account of the
 code size.


That's not true. Comments, esp. extensive DDoc comments, can carry a lot
of information that isn't part of the code itself. That will contribute
to the gzipped size. At the very least, you'd have to strip out comments
before compressing to get an accurate idea of "how much code" there is.

The idea of using compression to quantify the amount of code is a clever
one, though. Perhaps one way to improve it might be to have the compiler
serialize the AST of the completely-parsed code, then we compress that
serialized AST.

Still, it's hard to get from this (or any other) measurement of code
size to the "expressiveness" of the language. An inexperienced coder
might write rather verbosely where an expert coder would write in just a
few concise lines; the quantity of code would differ in each case, so
without knowing the level of mastery the coder has over the language,
it's still difficult to quantify expressivity.

Furthermore, one could deliberately code in such a way as to maximize
(or minimize) whatever chosen measure is used to evaluate the language,
but that by no means reflects the *typical* usage of the language.

And even then, we have to deal with the problem space: not all languages
are best at addressing all classes of programming challenges. It would
be unfair, for example, to judge Java on the basis of how well one could
write an OS in it, since the language just isn't designed for that sort
of thing. You'd be running into all sorts of roadblocks everywhere that
aren't present when you write other applications that Java is more
suitable for.


T

-- 
Never step over a puddle, always step around it. Chances are that whatever made
it is still dripping.
Jul 26 2013
parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
On Friday, 26 July 2013 at 18:46:06 UTC, H. S. Teoh wrote:

 ...for example, to judge Java on the basis of how well one 
 could write an OS in it


http://jos.sourceforge.net/
Jul 26 2013
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jul 26, 2013 at 08:58:27PM +0200, Tofu Ninja wrote:

 On Friday, 26 July 2013 at 18:46:06 UTC, H. S. Teoh wrote:

...for example, to judge Java on the basis of how well one could
write an OS in it


 
 http://jos.sourceforge.net/


Wait... that's an OS that runs in a JVM? Wouldn't it need another OS to
act as host?  My mind is boggled...


T

-- 
Always remember that you are unique. Just like everybody else. -- despair.com
Jul 26 2013
prev sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Thursday, 25 July 2013 at 18:23:19 UTC, Xinok wrote:

 Once in a while, a thread pops up in the newsgroups pitting D 
 against some other language. More often than not, these 
 comparisons are flawed, non-encompassing, and uninformative. 
 Most recently with the article comparing D with Go and Rust, 
 the community pointed out a few flaws involving a late addition 
 of one of the D compilers, build configurations 
 (-noboundscheck?), and the random number generator used.

 Then when I think about how web browsers are compared, there 
 are conventional measures and standard benchmarking tools (e.g. 
 sunspider). They measure performance for javascript, rendering, 
 HTML5, etc. They also measure startup times (hot/cold boot), 
 memory usage, etc. Finally, there are feature comparisons, such 
 as what HTML5 features each browser supports.

 These are the type of comparisons I'd like to see with 
 programming languages. For starters, there should be standard 
 "challenges" (algorithms and such) implemented in each language 
 designed to measure various aspects of the language, such as 
 sorting, number crunching, and string processing. However, 
 rather than leave it to a single individual to implement the 
 algorithm in several different languages, it should be left to 
 the community to collaborate and produce an "ideal" 
 implementation of the algorithm in their language. We could 
 analyze factors other than performance, such as the ease of 
 implementation (how many lines? does it use safe/unsafe 
 features? Was it optimized using unsafe / difficult features?).


 What can we do about it? I propose we come together as a 
 community, design challenges that are actually relevant and 
 informative, and release the first implementations in D. Then 
 we let the battle commence and invite other communities to 
 contribute their own implementations in other languages. I 
 think we should give it a try; start off small with just a few 
 moderate challenges (not too simple or complex) and see where 
 it goes from there.


I have learned to be wary of comparisons like that. Any language 
that is sponsored or owned by a big company always "outperforms" 
other languages, and at the end of the day they only want to bind 
you to their products, no matter how "open source" they are. You 
can basically proof whatever you want. Most of the discussions I 
have had don't revolve around whether the language is good or 
not, it's about what people have heard/read, "Who uses it?", 
"I've heard ..." "Someone said ..." I once told a guy about D. He 
said "Ah, D, old-fashioned!" and he showed me a link that said
Jul 26 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jul 26, 2013 at 03:18:03PM +0200, Chris wrote:
[...]

 I have learned to be wary of comparisons like that. Any language
 that is sponsored or owned by a big company always "outperforms"
 other languages, and at the end of the day they only want to bind
 you to their products, no matter how "open source" they are.


+1.

I'm skeptical of attempts to reduce everything down a single number or
three, that can serve as a basis for numerical (or hand-waving)
comparisons. As if programming languages were that simple that one could
place them neatly on what is effectively a scale of 1 to 10!



 You can basically proof whatever you want. Most of the discussions I
 have had don't revolve around whether the language is good or not,
 it's about what people have heard/read, "Who uses it?", "I've heard
 ..." "Someone said ..." I once told a guy about D. He said "Ah, D,

 modern feature ... bla bla". How ... scientific!


I get that a lot from Java fanboys. They make bold-sounding statements
like "Java is the future!", "Java is the best!", "D sucks, nobody uses
it!", "Java will get you a job easily!". But I've yet to hear some
factual evidence to back up these claims. Well, maybe except the last
one -- it's true that given Java's popularity, it has a high chance of
landing you a job. But the point is, just because it will land you a job
doesn't necessarily make it a *good* language, it merely shows that it's
a *popular* one.  Popular doesn't imply good.


T

-- 
"I'm running Windows '98."
"Yes."
"My computer isn't working now."
"Yes, you already said that."
-- User-Friendly
Jul 26 2013
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 26 July 2013 at 14:05:12 UTC, H. S. Teoh wrote:

 On Fri, Jul 26, 2013 at 03:18:03PM +0200, Chris wrote:
 [...]

 I have learned to be wary of comparisons like that. Any 
 language
 that is sponsored or owned by a big company always 
 "outperforms"
 other languages, and at the end of the day they only want to 
 bind
 you to their products, no matter how "open source" they are.


 +1.

 I'm skeptical of attempts to reduce everything down a single 
 number or
 three, that can serve as a basis for numerical (or hand-waving)
 comparisons. As if programming languages were that simple that 
 one could
 place them neatly on what is effectively a scale of 1 to 10!



 You can basically proof whatever you want. Most of the 
 discussions I
 have had don't revolve around whether the language is good or 
 not,
 it's about what people have heard/read, "Who uses it?", "I've 
 heard
 ..." "Someone said ..." I once told a guy about D. He said 
 "Ah, D,

 more
 modern feature ... bla bla". How ... scientific!


 I get that a lot from Java fanboys. They make bold-sounding 
 statements
 like "Java is the future!", "Java is the best!", "D sucks, 
 nobody uses
 it!", "Java will get you a job easily!". But I've yet to hear 
 some
 factual evidence to back up these claims. Well, maybe except 
 the last
 one -- it's true that given Java's popularity, it has a high 
 chance of
 landing you a job. But the point is, just because it will land 
 you a job
 doesn't necessarily make it a *good* language, it merely shows 
 that it's
 a *popular* one.  Popular doesn't imply good.


 T


Yep. And I think that someone who knows D or any other language 
that is not mainstream is seriously into programming. If you know 
Java or Python, what does that mean? That you are a good 
programmer? If you know how to program, you can learn any 
language you want. The question is usually not "I wonder if I can 
write the program." the question is usally "I know what I have to 
do. But how do I do it in D, C, Java ...?" It's the how, not the 
if.
Jul 26 2013
parent "Chris" <wendlec tcd.ie> writes:
On Friday, 26 July 2013 at 14:17:45 UTC, Chris wrote:

 On Friday, 26 July 2013 at 14:05:12 UTC, H. S. Teoh wrote:

 On Fri, Jul 26, 2013 at 03:18:03PM +0200, Chris wrote:
 [...]

 I have learned to be wary of comparisons like that. Any 
 language
 that is sponsored or owned by a big company always 
 "outperforms"
 other languages, and at the end of the day they only want to 
 bind
 you to their products, no matter how "open source" they are.


 +1.

 I'm skeptical of attempts to reduce everything down a single 
 number or
 three, that can serve as a basis for numerical (or hand-waving)
 comparisons. As if programming languages were that simple that 
 one could
 place them neatly on what is effectively a scale of 1 to 10!



 You can basically proof whatever you want. Most of the 
 discussions I
 have had don't revolve around whether the language is good or 
 not,
 it's about what people have heard/read, "Who uses it?", "I've 
 heard
 ..." "Someone said ..." I once told a guy about D. He said 
 "Ah, D,

 more
 modern feature ... bla bla". How ... scientific!


 I get that a lot from Java fanboys. They make bold-sounding 
 statements
 like "Java is the future!", "Java is the best!", "D sucks, 
 nobody uses
 it!", "Java will get you a job easily!". But I've yet to hear 
 some
 factual evidence to back up these claims. Well, maybe except 
 the last
 one -- it's true that given Java's popularity, it has a high 
 chance of
 landing you a job. But the point is, just because it will land 
 you a job
 doesn't necessarily make it a *good* language, it merely shows 
 that it's
 a *popular* one.  Popular doesn't imply good.


 T


 Yep. And I think that someone who knows D or any other language 
 that is not mainstream is seriously into programming. If you 
 know Java or Python, what does that mean? That you are a good 
 programmer? If you know how to program, you can learn any 
 language you want. The question is usually not "I wonder if I 
 can write the program." the question is usally "I know what I 
 have to do. But how do I do it in D, C, Java ...?" It's the 
 how, not the if.


If I think about it, learning and knowing languages makes you a 
better programmer. If you know D, you become a better programmer 
in general. If you learn Objective-C or C or whatever, you become 
a better programmer. You learn new concepts and know what works 
and what doesn't, rather than sheepishly following rules as if 
they were universal laws. Ok, that's a bit off topic now.
Jul 26 2013