Live data from Hacker News

Replace CoffeeScript with ES6

robots.thoughtbot.com

131–140 of 178 posts

Re: Replace CoffeeScript with ES6

#131

Earlier quoted context omitted.

The things I hate most about CoffeeScript are the dash rockets and white-space significance. These are just opinions though. There are things I like about CS as well, like destructuring assignment and splats. Sometimes when I'm writing JS, I miss is, unless, etc... That said, I'd put my money on ES6 in the long run, though it doesn't really matter. People should use whatever makes them (and their team) happy and prod…

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…

Python's lambda semantics are limited due to the syntatic limitations created by Python's significant identation. That's not an universal problem of significant identation, but Python's syntax has it. I don't know, CS, so I don't know if it creates any such limitation.

Also, computers don't deal well with it. It's a smaller problem than people don't dealing well with it (the alternative), but it's still a problem. Anyway, this is much more relevant to scripts that run inside a browser.

Re: Replace CoffeeScript with ES6

#132

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…

Python's lambda semantics are limited due to the syntatic limitations created by Python's significant identation. That's not an universal problem of significant identation, but Python's syntax has it. I don't know, CS, so I don't know if it creates any such limitation. Also, computers don't deal well with it. It's a smaller problem than people don't dealing well with it (the alternative), but it's still a problem. An…

> 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 using named functions enough to want to make Python's syntax more complicated to achieve it.

> Also, computers don't deal well with it.

Computers deal fine with it.

Re: Replace CoffeeScript with ES6

#133

What CoffeeScript did was lodge the idea in people's heads that JavaScript can be treated as an assembly language to compile higher-level languages into. I'll bet many programmers' attitudes toward ES6 are: someone will write a compiler for my language, and I'll just use that. It seems better to treat JavaScript as admittedly not being the most powerful language in the world, and to treat the standard as a kind of RF…

In fact, maybe Javascript is too powerfull. It would be interesting to get a stack machine emulation in the browser, with an standard set of libraries/tools for native access to the DOM and emulators for most interpreted languages out there.

Kind of a Java plugin that runs on web, instead of just tunneling through it.

Re: Replace CoffeeScript with ES6

#134

The reason that I like CoffeeScript is that it removes, what I consider, the unnecessary boilerplate of JavaScript and replaces it with a shorthand equivalent and good conventions. I feel that CoffeeScript is better at representing the intent of JS than JS. I can visually sift through CoffeeScript and understand the code much quicker than normal JavaScript, which in my opinion leads to more maintainable code. I'm not…

The things I hate most about CoffeeScript are the dash rockets and white-space significance. These are just opinions though. There are things I like about CS as well, like destructuring assignment and splats. Sometimes when I'm writing JS, I miss is, unless, etc... That said, I'd put my money on ES6 in the long run, though it doesn't really matter. People should use whatever makes them (and their team) happy and prod…

[deleted]

Re: Replace CoffeeScript with ES6

#135
post #100

Earlier quoted context omitted.

> "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…

...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.

Re: Replace CoffeeScript with ES6

#136

Earlier quoted context omitted.

Because one day ES6 will run in browsers without a build step.

I'm not sure that's a convincing argument – you will in almost every conceivable case have a build pipeline in place anyway, so there's not really a cost there.

You're partially right, but every build step has a cost when you're working on a large project.

Re: Replace CoffeeScript with ES6

#137

CoffeeScript syntax is better and cleaner than the ES6 syntax. It's a fun language, and I've been using it everyday since it came out. On small projects, it's top-notch. But the future of CoffeeScript is bleak because many software designers are beginning to understand the value of type systems, e.g. TypeScript and Flow, for building maintainable Javascript code bases, and this means CoffeeScript is out of the pictur…

Variable shadowing sounds like a hacky way to solve problems caused by function scoping, which is solved in ES6 by introducing lexical scoping (i.e. the same scoping rules as in every other language).

It's also worth pointing out that CS and ES6 aren't really comparable technologies. ES6 isn't some newfangled preprocessor that simplifies syntax, it's an update to the standard which JS adheres to. CS is fundamentally limited because it compiles to ES5.1. When ES6 is implemented in browsers, CS will be able to do more.

Re: Replace CoffeeScript with ES6

#138
post #94

Earlier quoted context omitted.

Then you've done it wrong. Very, very wrong. You should be able to replicate your live environment locally and not being able to is a sign of a very broken development process. I just cannot emphasise this enough. One of my skills is debugging, everywhere I've worked I've been one of the top debuggers if not the top debugger. Never, ever debug on live. If you can't recreate the problem locally, you don't understand t…

> Never, ever debug on live. If you can't recreate the problem locally, you don't understand the problem yet. I am guessing you have not been exposed to highly complex live environments. What you say is largely true but you state it as an absolute fact, which is a bit naive. Live environments tend to be far more complex than test or local environments and sometimes that complexity is what creates the bug. Sometimes t…

For 99% of programmers who aren't ever going to deal with the really tricky problems, it should be gospel.

I'm not naive, I did actually say "almost always" and "There's a class of problems where this isn't necessarily true", but perhaps you can't read?

Re: Replace CoffeeScript with ES6

#139

Earlier quoted context omitted.

Python's lambda semantics are limited due to the syntatic limitations created by Python's significant identation. That's not an universal problem of significant identation, but Python's syntax has it. I don't know, CS, so I don't know if it creates any such limitation. Also, computers don't deal well with it. It's a smaller problem than people don't dealing well with it (the alternative), but it's still a problem. An…

> 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 that it's hard to think about rules that won't create some kind of problem. On Python it's lambdas, on Haskell it's that they are often actually harder to write than explicit blocks (good thing Haskell has explicit blocks too).

And no, computers don't deal fine with it. To minimise some Python code you need almost an entire Python parser. Assembling Python code from small pieces (something that is really important for Javascript) is a frightening problem.

Re: Replace CoffeeScript with ES6

#140
post #98

Earlier quoted context omitted.

Then you've done it wrong. Very, very wrong. You should be able to replicate your live environment locally and not being able to is a sign of a very broken development process. I just cannot emphasise this enough. One of my skills is debugging, everywhere I've worked I've been one of the top debuggers if not the top debugger. Never, ever debug on live. If you can't recreate the problem locally, you don't understand t…

Sometimes your problem turns out to be a problem with production hardware or wiring, or depending on interaction with external partners who may not be able to replicate their interactions accurately for your dev/test environment, or otherwise impossible for you to replicate in dev/testing without already having figured out what the problem is. While I agree with your overall sentiment, in any kind of remotely complex…

Bollocks, even in complex environments you should be able to test it outside. You can hook dev machines up to external partners, so there's absolutely no good reason to be using live environments for those problems.

I have seen production hardware or wiring be the problem once in my entire career. And I used to work for a company that ran and supported enterprise software on hundreds of different client-owned servers.

Most people these days will be running a few web servers at most.

EDIT: Worse still, we're talking about debugging javascript here, which makes what you're saying even more preposterous. Wiring, indeed.

Post reply on HN