141–150 of 178 posts
Also when working with external libraries and dependencies, I found myself resorting to trial and error figuring out the correct syntax because nearly all documentation is written in JS and not CS.
Earlier quoted context omitted.
I sure hope you're wrong. The unnecessary clutter of plain JS is just painful to look at. I can't remember how many times I've looked over a 40 line block of JS searching for a missing. When there are many )} )}; } ; } ; } -- it is just downright frustrating to be be wasting any time on what is effectively irrelevant syntax. With CS, it's indent and be done with it. It's like SASS vs. SCSS. Or Haml vs. ERB. I can't,…
> "With CS, it's indent and be done with it" As others have said, it's all fun and games until two people edit the same source file, one of whom has the dangerously incorrect opinion that tabs are better than spaces :-) I use a lot of semantic whitespace languages (CS, Haskell, Python), and it's a tradeoff: you gain in terms of redundancy, true, but there's an additional human overhead of making sure everyone's got t…
Earlier quoted context omitted.
> Python's lambda semantics are limited due to the syntatic limitations created by Python's significant identation. (nitpick: you seem to consistently use "identation" in place of "indentation".) I'm pretty sure that plenty of proposals consistent with Python's significant indentation have been proposed; python's lambda syntax is limited due to the BDFL not being convinced of the utility of more capable lambdas over…
> nitpick: you seem to consistently use "identation" in place of "indentation". Consequence of English not being my first language, and "indentation" being way too similar in it. I just can't spot the change. I've seen a couple of proposals, yes they'd work, but they seem to be always ugly. But the problem is not that significant indentation makes it hard to create lambdas (Haskell's ones, for example are fine), but…
Sure they do.
> To minimise some Python code you need almost an entire Python parser.
I don't think source-to-source transformations requiring a parser for the source is an indication that it is problematic for computers to handle something. I mean, to execute the source code you need a parser, too, and no one says that needing a parser for execution is a sign that computers don't handle a language well.
> Assembling Python code from small pieces (something that is really important for Javascript) is a frightening problem.
Sure, assembling by cut-and-paste is a problem with significant indentation, especially when using media (like the web) which do not respect indentation well.
OTOH, using significant amount of cut-and-paste coding (rather than reuse by library code) is a sign of a problem with the language, development process, and/or execution environment, anyway, so I don't see it as a particular problem that a language structure isn't friendly to copy-paste coding.
Earlier quoted context omitted.
Significant indentation is a good thing. Haskell and Python do it too. It's much easier to read indentation than it is to match up pairs of brackets in your head. In other languages, if the indentation doesn't match the brackets, you'll naturally read the indentation first and get the wrong impression of what the code does. In those languages, the indentation is supposed to match the brackets anyway. Why be redundant…
Significant indentation is enough for me to avoid Python. It just doesn't have enough to offer vs. the available alternatives without significant indentation. It's much easier to read indentation than unindented/badly indented pairs of brackets, but you're setting up a strawman - it's not either or - and then you tear down the strawman yourself by pointing out we match the indentation anyway. My code generally is pro…
Folks, this was always part of the plan ;) CoffeeScript is a fun little experiment in what's possible when you take JavaScript semantics and try to boil down the user interface to a minimalist surface. But JavaScript will always keep on rolling onwards — and to the extent that future versions of JavaScript take any minor inspiration or reference or overlap with things that CoffeeScript already does, the more the bett…
Earlier quoted context omitted.
How much of this beauty will be fixed in ES6? http://wtfjs.com
Some of those problems are with the DOM and browsers, not JavaScript.
Earlier quoted context omitted.
...two people edit the same source file, one of whom has the dangerously incorrect opinion that tabs are better than spaces Commit hooks will help you: http://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks The bigger your team, the more you need them.
For open source projects, that's less of an option, but regardless, an individual's opinions about tabs and spaces are moot when working on a multi-dev project. You follow the project's conventions, or your changes don't get merged.
Why not both? This makes a good argument for ES6, but CoffeeScript's fundamental changes to syntax are just preferred by some.
Some reasons why I will stick with CS: * Optional braces and parenthesis. Results in visually cleaner and more compact code, especially when dealing with large objects. * Requiring backticks to do string interpolation seems like an ugly hack. * CS uses dots to slice and splice ranges: host?.split(".")[-1..][0] == "dns" BTW, notice in the example above two additional CS features that don't exist in ES6: * The existent…
This seemingly minor feature is so huge for me. Accessing deep objects?.is?.a?.horrible?.pain?.sometimes?()