YAML is an even bigger turn-off for me than CoffeeScript. It’s (borderline) human-readable, but I don’t find it human-writeable. The spec is enormous compared to JSON, it’s far fussier about precise syntax, and its complexity of deserialization has led to security exploits.
Well. The way atom’s CSON parser currently works (eval) is just as bad as the YAML issues of old
I also agree with the ES6 comment, there’s very few things that coffeescript really gives you on top of what we’ll have as a standard soon, so this seems like a bullet to the foot really.
I agree with @visionmedia. It seems logical if the closed source part was in coffeescript (or any other technology), but there seems too much dependence on coffeescript. For example: I couldn’t run
test spechelper was looking for files ending
-spec.coffee only (Apm test and *.js specs)
I’m personally a fan of the coffeescript. I find it interesting that every time a large, public app, framework or library is written in coffeescript, haters crawl out of the woodwork to complain. @visionmedia , is there a conversation anywhere on the internet dissing coffeescript that you haven’t been part of?
Contributions are great, and the lifesblood of any project that attempts to be in whole or in part open source, but if the project is useful and well-made, contributions will come regardless of the language that it is written in.
If the editor is really good people will use it, and people will contribute. Let’s leave the devs to decide what to write it in. Then they will be happier and more productive, and we’ll be far more likely to get that amazing editor.
And sure, there are people right now saying stuff like:
I saw coffeescript and immediately threw my hands up.
But you know what, if that guy falls in love with the editor because it is awesome, and some bug in it begins to bother him enough, I’d bet 9 times out of 10, he’ll dive into the code anyways.
I also have to call
I’m willing to bet, in respect to the docs, that with little effort they could allow one to choose between JS and Coffeescript in doc code examples by simply showing compiled JS. It’s not as pretty as hand crafted JS, but it’s both a learning resource (one could switch between CS and JS) and a way to lower the barrier somewhat.
I’m pretty excited Coffeescript is preferred, because it’s just better. Additionally, @edubkendo 's comment pretty much slays the issue.
I personally really like the choice and think the core and packages have very clean/readable code due to using Coffeescript.
I certainly wouldn’t be afraid of writing a little bit of coffeescript if I needed to (half the fun of being a programmer is learning new things!). However, according to the below quote, it might lead to less contributions:
The above quote is taken from the Discourse thread about Discourse linked to by @sam
A valid concern, however, that was what, a year ago now? Coffeescript is growing like mad. Combine that with the
And l can only agree with this, CoffeeScript is everywhere now:
But in the end, I think edubkendo’s argument against complaining about CoffeeScript already wins this discussion anyhow (although I would have preferred a less aggressive tone :)). It’s Github’s language of choice, this is Github’s project, they should be allowed to use what they like best to develop it.
Is this discussion really providing value? CoffeeScript is company policy for the creators, isn’t difficult to learn, is completely optional for plugin authors, and the project is open source and can be forked/rewritten in ES6 if anyone has that kind of time. I doubt the Atom authors would be inclined to start over, so I’m not sure what is to gain here other than voicing preferences, and that’s done already.
I am curious though… For those of you that do like coffeescript, what other languages do you use? Or what languages did you use previously?
Way too many to write down here, but I can tell you my favorite languages of all time apart from CoffeeScript: REBOL, Smalltalk-80, Objective-C, Ruby and Clojure. Other languages I used a lot (due to work or because it was the best tool for the job) are: Java, C++, Python, PHP and Real Basic. Languages I’m trying out right now but am still unsure about are Google’s Dart and Go.
Interesting. I thought maybe it had to do with people having a background in a language in something like ruby or maybe python.
I personally will take plain JS any day over coffeescript, and I have wrote a lot of CS at work, I just find JS less ambiguous and easier to read. But that is just my opinion.
The thing is that it doesn’t really matter a lot, I wish they have chosen JS but I can see why they use CS, at the end of the day if you can write JS you can also write CS.
Github should look at their own data, seriously.
I like the idea of Atom, and I like what it represents, but I’m turned off by the current documentation and plugin examples which are all written in CoffeeScript. I don’t think I’m competent enough to judge GitHub’s choice of programming language due to my unfamiliarity with CS, but with the current documentation, I’m helpless when it comes to writing anything but the most basic of plugins.
My current editor of choice is Chocolat. It’s a bit obscure and there aren’t that many plugins for it, but when I need something, I can extend it myself, even though the documentation leaves a lot to be desired. Still, since the plugins (or mixins, as they’re called) are JS, I can figure it out on my own. As a side note, I also like its Tern implementation (something that didn’t work out so well with the ST2/3).
I think it would be wonderful if GitHub would supply us with a couple of example core plugins and maybe some kind of documentation (which I’m sure is coming once things normalize a bit) that is JS-oriented. I don’t think that would be too much to appease CoffeeScript haters/avoiders/illiterates. JS plugin examples might be even more important than documentation because a lot of us like learning stuff by taking things apart.
I think that’s a fairly simple way of ending a potentially volatile discussion (bordering on feud), not to mention that it would increase the number of potential contributors. Programmers can often be really particular about what they use and how they use it, and I find the best way to avoid conflicts is to offer them a choice, something that should be a no-brainer in this case.
Edit: Oh, @mokkabonna, the data on the number of CoffeeScript repos could be slightly off, because the way I understand it, GitHub categorizes repos based on the most dominant language inside the repo. Since a lot of CS repos also include compiled JS code, they could end up showing as JS repos because the amount of generated JS is usually longer than the original CS code. Somebody, please correct me if I’m wrong.
@aaronogle The language I currently work in is ruby, I have also written quite a bit of java (maybe more java than anything else) and a decent chunk of coffeescript. I’m currently learning go, and I’ve written a half dozen Sublime Text plugins in python.
Definitely dislike curly brackets though. I find they add a lot of noise and do nothing to clarify that proper indentation and empty lines can’t do just as well. Also, I really hate semi-colons. I try to avoid those in both English and code.