I see this comment every time for many of years in almost every discussion about using JSON for configuration and while YAML is certainly used by many projects most of the people still continue to use JSON and I think that's because YAML sometimes feels like Scala of serialization markups when people just want something like Python. I personally think that TOML[0] is not only more simple but also as easy to read as YAML and we use it in our projects without any issues.
I'd with the design would be more dense, it's a nice design and I understand that designers did it deliberately because they know whitespace does matters, but when it comes to web sites like Github I think the most important thing is functionality and not the cute and modern look. With the old design on my 13 inch MBP I could see 6 repos with the new design - only 5
I think that's not a problem with significant whitespace, but the problem with CoffeeScript syntax. I'm programming in Python and had been programming in Coffescript and I always found Coffescript code much harder to read than code in Python. I don't know exactly what causes this, but my guess is that indented blocks of code in CoffeScript can appear after any line, so you don't have visual anchors that will indicate where one block begins and other ends. In Python however, indentation is always comes after keywords like def, if, class, for etc... and those are always highlighted by your editor so your eyes can always catch the block start very quickly.
Yeah, I have this issue too, though I'm using stable Chrome, I thought that if this is a bug it must be already reported, the funny thing is that I tried to google it and all I got was some articles about web-fonts and icon fonts rendering problems.
Usually most of the people realise the need for this kind of tools when they are facing a need/requirement to develop a single page web application (SPA). If you don't need to make one then it's ok to use jquery or even add some PJAX to make your web site look more snappy. But if you have to develop a SPA, then you can't go far with jQuery because it just wasn't created for this type of things, you have to think about models, templates, about application state management and all other stuff, this is where frameworks like Ember and Angular shine.
It is exactly the point where our interests collide - when I'm using your library, I want to have a control over your library, because I'm using it. I don't want you library to control me an the way I use it. It's a tail wagging the dog analogy.
For example I use your library and everything goes great until I'm stuck because I need to have an information hidden in a private field, if I'm in Python I would do it and add a note, fixme, todo, whatever that this is a hack and things may break in a future, but my code would work right now. And I can fork your library later and submit changes. If this is a language with real private support the only way is to use hacks (reflection) which is the same as using the field directly like in python just with some additional PITA, or to fork your library and maintain it until you merge changes, or if you not, I have to maintain it forever.
Well, that depends on your starting point, if you're a private state proponent then it may be a hack for you. I'm more of a control freak and I'm on a side of 'everything is public, lets code by interface', so for me private state is a bit of a hack that some languages have because some other languages have it and and some other languages have because it was introduced in languages before them. My point was that the lack of private state in Python didn't made impossible to separate inner implementation from public interface.
Why not make everything global? For obvious reasons - modularity, memory consumption, and inconvenience of lengthy variables names.
Why hide it completely? What about exposing your interface by convention like in Python? Never heard anyone suffering from inability to make methods and fields private in Python.
Well if they use your private members thats all in theirs responsibility. What if they just want to make the thing work, ship the product, whatever else, and don't care about new versions.
I always wanted to know why would anyone want to hide their code at all? If you making a library you would never know how people going to use it. Why don't expose public interface using naming conventions and let the people freedom to break it when they really want to. I sometimes found myself using methods and variables that intended to be private because I wouldn't achieve needed functionality without touching them.
Just imagine what if Backbone had all model's attributes private - that practically means that you wouldn't be able to extend a model or to inspect the model's attributes in the console. Of course you can say that adequate programmer would never do that, but that's exactly my point - you have to rely on programmer's ability to write decent code, while if everything was public you would also rely on your ability to hack things, yes this can be messy and you can shoot your leg, we all know that, but we all grown ups and we know what we are doing.
When I read about symbols in upcoming ES6 I can't get rid off the sense of anxiety because I fear thing would get worse, the only hope is that browser vendors would implement some means to inspect private state of the objects that use Symbols.
Am I the only one who don't like this new trend when every second website now is designed with the low contrast and native OS antialiasing disabled? I'm 24 and I just can't read the summaries on this site. Just compare the two versions on this screenshot [1]: default on the top, and native antialiasing on the bottom with the slightly darker text (#67707c)
