Earlier quoted context omitted.
> Consider these stats : the last three versions of the program — each 420,000 lines long-had just one error each. What exactly do they mean by this? If each of the 3 versions had exactly one bug, isn't this just a weird way of saying the first 2 fixes either didn't work or introduced a new bug?
Regressions are not implied by that statement. A bug doesn’t exist in the human realm until a human observes it.
Please do not attempt to simplify this code
121–130 of 327 posts
Re: Please do not attempt to simplify this code
#122Earlier quoted context omitted.
Well over 100 successful missions carrying a bunch of people and gear up into outer space and then bringing them back home. I hold it in a good light now, and will likely continue to feel that way. As far as human progress and net good, it was a success.
100 success and 2 failures. About a 1.6% failure rate from memory. That’s not a great record. Sure it’s a complex field, and it’s not as dangerous as say being US President, but a failure rate of >1% is not something to write home about.
Not saying the Shuttle's success rate was awesome; I'm glad we demand more nowadays. But it still represented a pretty decent crew safety improvement for the USA's human spaceflight program.
Re: Please do not attempt to simplify this code
#123Earlier quoted context omitted.
2k lines is a whole widely used and feature filled open source library in many languages.
Yes, but often density is at odds with readability.
It's very easy to lose context and the big picture when you're scrolling around code written in a non dense language.
(I'm talking the difference between say... Java and F#. I can't say much for the more extreme differences like COBOL and APL)
Re: Please do not attempt to simplify this code
#124Earlier quoted context omitted.
Well over 100 successful missions carrying a bunch of people and gear up into outer space and then bringing them back home. I hold it in a good light now, and will likely continue to feel that way. As far as human progress and net good, it was a success.
100 success and 2 failures. About a 1.6% failure rate from memory. That’s not a great record. Sure it’s a complex field, and it’s not as dangerous as say being US President, but a failure rate of >1% is not something to write home about.
Challenger blew up on launch because of a booster failure due to a faulty O-ring seal.
Columbia burned up on re-entry because a piece of insulating foam broke off from the external tank during launch, damaging the heat tiles on its left wing.
See also: https://en.wikipedia.org/wiki/List_of_spaceflight-related_ac...
Re: Please do not attempt to simplify this code
#125Re: Please do not attempt to simplify this code
#126Earlier quoted context omitted.
In the statement/expression-oriented axis of languages, Go is a statement oriented language (like C, Pascal, Ada, lots of others). This is in contrast to expression oriented languages like the Lisp family, most, if not all, functional languages, Ruby, Smalltalk and some others. Expressions produce a value, statements do not. That's the key distinction. In C, if statements do not produce a value. In Lisp, if expressio…
A simple example for anyone who might not appreciate why this can be so nice. In languages where if is a statement (aka returns no value), you'd write code like int value; if(condition) { value = 5; } else { value = 10; } Instead of just int value = if(condition) {5} else {10} Some languages leave ifs as statements but add trinary as a way to get the same effect which is an acceptable workaround, but at least for me…
int value1 = 0;
int value2 = 0;
if (condition) {
value1 = 8;
value2 = 16;
} else {
value1 = 128;
value2 = 256;
}
Would I have to repeat the if expression twice? int value1 = if (condition) { 8 } else { 128 };
int value2 = if (condition) { 16 } else { 256 };Re: Please do not attempt to simplify this code
#127Earlier quoted context omitted.
In the statement/expression-oriented axis of languages, Go is a statement oriented language (like C, Pascal, Ada, lots of others). This is in contrast to expression oriented languages like the Lisp family, most, if not all, functional languages, Ruby, Smalltalk and some others. Expressions produce a value, statements do not. That's the key distinction. In C, if statements do not produce a value. In Lisp, if expressio…
A simple example for anyone who might not appreciate why this can be so nice. In languages where if is a statement (aka returns no value), you'd write code like int value; if(condition) { value = 5; } else { value = 10; } Instead of just int value = if(condition) {5} else {10} Some languages leave ifs as statements but add trinary as a way to get the same effect which is an acceptable workaround, but at least for me…
Re: Please do not attempt to simplify this code
#128Earlier quoted context omitted.
A simple example for anyone who might not appreciate why this can be so nice. In languages where if is a statement (aka returns no value), you'd write code like int value; if(condition) { value = 5; } else { value = 10; } Instead of just int value = if(condition) {5} else {10} Some languages leave ifs as statements but add trinary as a way to get the same effect which is an acceptable workaround, but at least for me…
How would this work if I need to update multiple variables? int value1 = 0; int value2 = 0; if (condition) { value1 = 8; value2 = 16; } else { value1 = 128; value2 = 256; } Would I have to repeat the if expression twice? int value1 = if (condition) { 8 } else { 128 }; int value2 = if (condition) { 16 } else { 256 };
let (value1, value2) = if (condition) { (8, 16) } else { (16, 256) }
Or else you’d just use some other sort of compound value like a struct or something. Tuple is just convenient for doing it on the fly.
Re: Please do not attempt to simplify this code
#129Earlier quoted context omitted.
A simple example for anyone who might not appreciate why this can be so nice. In languages where if is a statement (aka returns no value), you'd write code like int value; if(condition) { value = 5; } else { value = 10; } Instead of just int value = if(condition) {5} else {10} Some languages leave ifs as statements but add trinary as a way to get the same effect which is an acceptable workaround, but at least for me…
How would this work if I need to update multiple variables? int value1 = 0; int value2 = 0; if (condition) { value1 = 8; value2 = 16; } else { value1 = 128; value2 = 256; } Would I have to repeat the if expression twice? int value1 = if (condition) { 8 } else { 128 }; int value2 = if (condition) { 16 } else { 256 };
So like I believe you can do this in Rust (haven't written it in a while, I know it has destructuring of tuples)
let (a, b) = if (condition) { (1, "hello") } else { (3,"goodbye") }
Re: Please do not attempt to simplify this code
#130// ================================================================== // PLEASE DO NOT ATTEMPT TO SIMPLIFY THIS CODE. // KEEP THE SPACE SHUTTLE FLYING. // ================================================================== // // This controller is intentionally written in a very verbose style. You will // notice: // // 1. Every 'if' statement has a matching 'else' (exception: simple error // checks for a client API ca…