131–140 of 209 posts
and one thing Golang has made inroads is there's only one way to do something.
and ruby is pleasurable because the interface is consistent i.e everything is an object.
Earlier quoted context omitted.
I have some experience in computer language design. The issue here is that `a==b==c` expression is magical - that is it does not follow from extending comparison binary operator. Specifically, `==` is a binary operator that that compares an expression before and after and returns a boolean. In this case, A==B==C is a trinary comparison operator. This is normally ok, except it's rare and the symbol it is using is over…
> the symbol it is using is overloaded with binary comparison operator, so the people will be confused I think most people would expect expressions like `5 < x < 10` to work as they do in math, without necessarily thinking about it in terms of being an overloaded binary operator. The result in other languages that `5 < 12 < 10` = `true < 10` = `true` is more surprising, just that we've (perhaps by being bitten by it…
I know the point of the piece is the python syntax here, but I got stuck on: "judge things like code quality / speed / conciseness etc." Do people generally write concise code on right off the bat when confronted with a new problem? I've always taken the same approach I would with writing: get something that works; refactor for concision. Maybe everyone else is playing 3D chess and I'm still on Chutes and Ladders?
There are degrees of conciseness. I've seen real code that looks like if(bool_var == false) { other_bool_field = true; } else if(bool_var == true) { other_bool_field = false; } Which I suppose could be called anti-concise.
The risk is that you may end with such concise code that nobody understands what it does. I went that dark path with perl 20 years ago, form "oh what a cool language for someone who comes from C" to "let's squeeze that in half a line, and either do no understand what it does, or add three lines of comments to explain".
But yes, there is a good middle-groud somewhere
If you know nothing about Python or coding, and you see a=b=c, you'd think that's true when all three a,b,c are the same. Python does that beautifully here, and that's the intent. It's not Python that's confusing, it's your previous experience with other languages that's confusing you.
Yet another way in which Lisp is vastly superior to any and all blub languages: (= 2 (+ 1 1) (sqrt 4)) ; => t ( t
Earlier quoted context omitted.
> I really don't want to have to pull out an operator precedence chart in order to read your code Hard disagree here. I write code for people who can read the language. This includes operator precedence.
>I write code for people who can read the language Programming languages often have syntax that's acknowledged as a source of confusion and bugs and better avoided. The line is not hard and fast, but I write C++ and there's "C++", and then there's "the C++ subset that you should use" (I probably couldn't write C++ code without tools slapping me for using the wrong parts). Operator precedence is debatable but our tool…
People unfamiliar with programming will assume that "if a == b == c" is only true if all three things are the same, and people familiar with Python will know that that is, indeed, what it means.
I know the point of the piece is the python syntax here, but I got stuck on: "judge things like code quality / speed / conciseness etc." Do people generally write concise code on right off the bat when confronted with a new problem? I've always taken the same approach I would with writing: get something that works; refactor for concision. Maybe everyone else is playing 3D chess and I'm still on Chutes and Ladders?
Do people generally write concise code on right off the bat when confronted with a new problem? As someone who has been on the interviewer side: this is an indicator of how much the interviewee "thinks first"; the ones who immediately start spewing tons of code are usually those who don't really have a good understanding of what they're trying to do.
Think first, code second.
Earlier quoted context omitted.
> the symbol it is using is overloaded with binary comparison operator, so the people will be confused I think most people would expect expressions like `5 < x < 10` to work as they do in math, without necessarily thinking about it in terms of being an overloaded binary operator. The result in other languages that `5 < 12 < 10` = `true < 10` = `true` is more surprising, just that we've (perhaps by being bitten by it…
Yeah, but should that math equivalence hold for programming though? Programming is different. x=x+1 is perfectly legal in programming but does not make sense in algebra math and could confuse mathematicians.
x = x + 1 sounds wrong if you are in math mode
x := x + 1 is uncommon in math and you can take it to mean "set x to whatever is currently x, plus one"
But it's also true that you need to be able to accept certain conventions when changing fields.