81–90 of 137 posts
Earlier quoted context omitted.
> Use "log_file" for log files; use "logarithm" or "Math.log" for inverse exponentation. Just clarifying; are you actually suggesting this, or was that sarcasm?
It's a serious suggestion. Instead of introducing four top-level variables (log, sin, cos, and tan), just introduce one (Math) that wouldn't possibly conflict with a local.
Earlier quoted context omitted.
Thanks for this! Way better explanation than the blog post :) Is there anyway to make the scope explicit in coffeescript?
Yes, create the variable as a function argument.
Earlier quoted context omitted.
The concern is that because Coffeescript automatically scopes variables to the scope of their first reference, it can introduce maintenance issues. Consider the following: foo = -> bar = "woot!" console.log bar This compiles to: var foo; foo = function() { var bar; bar = "woot!"; return console.log(bar); }; bar is locally scoped to foo(). Now, 2 weeks later and 200 lines earlier, you come along and define: bar = -> a…
The inconsistency doesn't stop there; `for` variables are specialcased: bar = -> alert "Holy crap cheese is awesome!" foo = -> for bar of bars console.log bar return ↓ var bar, foo; bar = function() { return alert("Holy crap cheese is awesome!"); }; foo = function() { var bar; for (bar in bars) { console.log(bar); } };
Earlier quoted context omitted.
The inconsistency doesn't stop there; `for` variables are specialcased: bar = -> alert "Holy crap cheese is awesome!" foo = -> for bar of bars console.log bar return ↓ var bar, foo; bar = function() { return alert("Holy crap cheese is awesome!"); }; foo = function() { var bar; for (bar in bars) { console.log(bar); } };
That makes plenty of sense to me; when do you ever want to leak a for loop counter to an outer scope?
Not to mention that loop counters are no different than other `var`iables in JS.
Earlier quoted context omitted.
I think it has already been proven that there is no obvious correlation between being capable in mathematics and being a talented programmer. Thats so 1950's
Not a direct coorelation, but there is certainly a dependence on being capable in mathematics. A math wizard does not make a good programmer, but one cannot be hopelessly average in math and be a talented programmer.
The common ground between math and programming is the requirement of a very good capacity to manipulate abstract concepts in a defined frame of known validity. But it pretty much stops here. In mathematics, you define all your abstracts concepts and frame of validity, in programming, you are given a (very shaky and detailed) frame of validity on which you build up abstract concepts.
The ones that are good in approaching the discipline through the study of details to build up stuff that will work on top of it will make the developers. The ones that needs a strong and well defined frame for their work, for it brings a much more powerful ground and enable to reach very high levels of abstraction, will feel more comfortable on mathematics.
No wonder why those that can combines both of those approaches can yield stunning results.
@mitsuhiko Not gonna happen ;) Forbidding shadowing altogether is a huge win, and a huge conceptual simplification. How arrogant! You'd think he'd step back for a second and consider the suggestion, but it sounds like he's on autopilot.
Poppycock. It doesn't get simpler than
a. newly bound variables are new
b. any variable which wasn't bound in the present scope must be bound in a enclosing scope.
Of course, it's kind of socially acceptable to get wrong because a lot of language designers didn't think it through and used the same operator for both binding and reassigning a variable (i.e. '=').
If you need global variables, it's sensible to just adopt a simple naming convention, like prepending g_ (or whatever pleases you) to all your variables. I already did that with plain JS and it's well worth the "effort".
Earlier quoted context omitted.
Perhaps you are being too hard on yourself. The majority (more than half) of the well known programmers truly are "superstars". It's all very subjective, though. Where is the standard for complexity or even cleverness? How is it different than simply being esoteric. Maybe I am personally fascinated with regular expressions and after much study, can belt out a half page of parse and extract 'magic' that would make the…
How is it different than simply being esoteric. Maybe I am personally fascinated with regular expressions and after much study, can belt out a half page of parse and extract 'magic' that would make the uninitiated shake their head and crown me a genius. Sounds interesting, tell me more. Personally, I would say that a truly talented programmer is simply someone who is very capable in mathematics and can produce a work…
Earlier quoted context omitted.
I agree with this wholeheartedly--Scheme use an extremely simple scoping model that is nonetheless more expressive than Python (before 3, I guess) and CoffeeScript's. In fact, I only really completely understood JavaScript's model--and realized that, even if a little awkward, it was fundamentally elegant--after writing a Scheme interpreter.
I think Python's is deliberately unexpressive, forcing you to use local variables pretty much everywhere. This tends to decouple stuff, which is usually good. The model is "everything you do is local, unless you know better, and want to jump through a lot of hoops". Coffeescript works a similar way. Javascript seems to have the model "everything you do is global, unless you know better". I'm not a big Javascript hate…
Python went for a more complicated scheme of having every variable in a function be a new binding when first assigned, and then it's just mutation (i.e. 'local'), unless explicitly declared to be nonlocal, but it still makes sense with their... penchant for mutable state.
And Coffescript instead went over to PHP to have some of the glue it was eating.
"""
Sorry, folks, but I'm afraid I disagree completely with this line of reasoning -- let me explain why:
Making assignment and declaration two different "things" is a huge mistake. It leads to the unexpected global problem in JavaScript, makes your code more verbose, is a huge source of confusion for beginners who don't understand well what the difference is, and is completely unnecessary in a language. As an existence proof, Ruby gets along just fine without it.
However, if you're not used to having a language without declarations, it seems scary, for the reasons outlined above: "what if someone uses my variable at the top of the file?". In reality, it's not a problem. Only the local variables in the current file can possibly be in scope, and well-factored code has very few variables in the top-level scope -- and they're all things like namespaces and class names, nothing that risks a clash.
And if they do clash, shadowing the variable is the wrong answer. It completely prevents you from making use of the original value for the remainder of the current scope. Shadowing doesn't fit well in languages with closures-by-default ... if you've closed over that variable, then you should always be able to refer to it.
The real solution to this is to keep your top-level scopes clean, and be aware of what's in your lexical scope. If you're creating a variable that's actually a different thing, you should give it a different name.
Closing as a wontfix, but this conversation is good to have on the record.
"""