71–80 of 126 posts
Earlier quoted context omitted.
Should ternaries be left or right associative?
Right associative! It's just one of the many rites of passage for people working with PHP to get bitten by its left associative ternaries. Naked nested ternaries are deprecated now, but maybe one day, PHP can have right associative ternaries.
Earlier quoted context omitted.
One thing I have learnt very well from rewriting a legacy PHP code written by amateur teams is: never ever nest ternary operations. maybe it's only me, but it's really hard to reason about this.
Unfortunately there is no if-expression in JS so sometimes it's awkward _not_ to use ternaries in multi-line statements - for instance, when writing in an expression only context like a string interpolation or JSX. It's also just annoying to not be able to assign conditionally without using it, instead of a more clear and readable if/else. It's one of the more annoying nits of the Algol legacy. Oh, but fully agreed,…
"Languages do not differ in what they make possible, but in what they make easy."
Earlier quoted context omitted.
Nothing but when you nest them a whole bunch they are far harder to read and understand that if/else.
I frankly find it hard to imagine an expression form of if...else that's more readable than either the JS or Scheme versions of the code. In fact, I believe the problem with the JS example's readability is the formatting. Here's how I'd format the same code, and I find this quite readable: function deriv(exp, variable) { return is_number(exp) ? 0 : is_variable(exp) ? is_same_variable(exp, variable) ? 1 : 0 : is_sum(e…
function deriv(exp,v){
//v = variable;
if(is_number(exp) ){ return 0 }
if(is_variable(exp){ return is_same_variable(exp,v) * 1 }
if(is_sum(exp)){
a = deriv(addend(exp),v);
return make_sum(a,a)
}
if(is_product(exp)){
m = multiplier(exp);
c = multiplicand(exp);
a = make_product(m,deriv(c,v));
b = make_product(deriv(m,v),c));
return make_sum(a,b)
}
return error(exp, "unknown expression type -- deriv");
}Earlier quoted context omitted.
What's deterring me from pulling the trigger on the Scheme version is the price. CAD$87 seems a bit steep for a paperback edition that's almost 30 years old. The JavaScript version is CAD$20 cheaper.
Seeing a lot of $25-45 (USD) used price. Used books are awesome. I have north of 500 books and I doubt more than 50 were purchased new. Only that many because some of my relatives want Christmas and birthday wishlists every year, but won't shop anywhere but Amazon and think it's weird to buy someone a used book as a gift (I'd rather have 2-3x as many books for the same money, but hey, I'm not the one paying, so whate…
What I loved most about my class based on SICP was that I learned a whole new way to reason about code, and that came from using Scheme. They changed the intro class at Berkeley to use Python a while back, when the folks who knew lisp/scheme retired, and I think it made the class much worse. This is really the death knell of SICP isn't it?
You know how people love to repeat that old saw about how computer science is no more about computers than astronomy is about telescopes (or whatever it is)? Well ironically (because it's the same exact people but this time on the other side of the misunderstanding) SICP is no more about scheme/lisp than computer science is about computers.
Sure you can use a spectrum scan or the output of a radio telescope, but it's really not the same as looking at in a telescope.
Same thing here -- SICP just isn't the same if it's not in scheme or lisp.
What I loved most about my class based on SICP was that I learned a whole new way to reason about code, and that came from using Scheme. They changed the intro class at Berkeley to use Python a while back, when the folks who knew lisp/scheme retired, and I think it made the class much worse. This is really the death knell of SICP isn't it?
You know how people love to repeat that old saw about how computer science is no more about computers than astronomy is about telescopes (or whatever it is)? Well ironically (because it's the same exact people but this time on the other side of the misunderstanding) SICP is no more about scheme/lisp than computer science is about computers.
It seems like they have attempted to write scheme using JavaScript syntax to avoid having to make any significant changes to the non-code sections of the book. Here is an excerpt, it's not good: function deriv(exp, variable) { return is_number(exp) ? 0 : is_variable(exp) ? is_same_variable(exp, variable) ? 1 : 0 : is_sum(exp) ? make_sum(deriv(addend(exp), variable), deriv(augend(exp), variable)) : is_product(exp) ? m…
The whole point of SCIP was mathematical beauty. Losing that in translation is not good.
Earlier quoted context omitted.
What's deterring me from pulling the trigger on the Scheme version is the price. CAD$87 seems a bit steep for a paperback edition that's almost 30 years old. The JavaScript version is CAD$20 cheaper.
Seeing a lot of $25-45 (USD) used price. Used books are awesome. I have north of 500 books and I doubt more than 50 were purchased new. Only that many because some of my relatives want Christmas and birthday wishlists every year, but won't shop anywhere but Amazon and think it's weird to buy someone a used book as a gift (I'd rather have 2-3x as many books for the same money, but hey, I'm not the one paying, so whate…
Earlier quoted context omitted.
If you want the equivalent of if-expression in JS, I think it is much better to make a separate function with a number of returns. In this case the function is already there: function deriv(exp, variable) { if (is_number(exp)) { return 0; } if (is_variable(exp)) { if (is_same_variable(exp, variable)) { return 1; } else { return 0; } } if (is_sum(exp)) { return make_sum(deriv(addend(exp), variable), deriv(augend(exp),…
It's subjective, but seconded (switch statements are also great for this because they make fall-through logic more obvious). I'll add a couple of things onto this: early returns are very helpful for me in avoiding nesting if statements (although that's less applicable in this specific example). function op(cond) { if (cond) { //do something } } function op (cond) { if (!cond) { return; } //do something } And it's goo…
Earlier quoted context omitted.
If you want the equivalent of if-expression in JS, I think it is much better to make a separate function with a number of returns. In this case the function is already there: function deriv(exp, variable) { if (is_number(exp)) { return 0; } if (is_variable(exp)) { if (is_same_variable(exp, variable)) { return 1; } else { return 0; } } if (is_sum(exp)) { return make_sum(deriv(addend(exp), variable), deriv(augend(exp),…
if (is_same_variable(exp, variable)) { return 1; } else { return 0; } should be return +is_same_variable(exp, variable)