Bad user experience depends on the user. Personally I very much enjoy the somewhat lower price of less-beefy models of smartphones and tablets — as I'm not obsessed with taking pictures, don't play blockbuster video games on mobile, and prefer my books as text, instead of audio files.
The title of the post is similar to saying e.g. "ARM CPU is bad UX", and complain that you can't mine Bitcoin effectively on ARM.
The counterargument would be that your usage patterns are the niche ones. I suppose that's an empirical question. Does anyone have any numbers either way?
Presently there is no additional cost to choosing a smartphone with the right amount of memory for one's specific usage pattern, so who's being "niche" makes no difference. Linux on desktop is arguably also niche, yet no one is hurt by the fact that PCs actually support it.
If Apple were producing just the 16GB model, then usage numbers would probably be in order. As of now, things are just at their optimal state, where everyone can get what they want.
This saddens me personally, as I once worked with this guy; he is very productive and talented developer. Imagine how god-awful he feels now, threatened by police and forced to stop committing to his very own projects.
I'd like its source code to be extremely hackable and easy to understand / build / debug, quite unlike Mozilla's present day codebase (which I personally find very hard to figure out).
Nothing wrong with spontaneously hugging at work to relieve stress, assuming that all parties understand the purely Platonic meaning of the act (after all, we're grown-ups).
I also tend to close my (less serious) working emails with stuff like "Love, kisses, [Name]" — and no one ever got offended by that, albeit the majority of my team would probably dislike some random bearded guy actually kissing them.
Awkwardness is in the eye of the beholder. Working with adults (with no serious mental health issues) alleviates the need for a prohibitive, mildly disgusting CoC, like the one discussed in this thread.
I actually managed to contribute to it once, via the mailing list. This doesn't really invalidate (1), but maybe they just don't want GitHub-style forks ("modifying the supplied code 'in place' is something that we discourage").
It's unavoidable with open source. Take any project with daily tarballs and mailing list diffs and you can probably even code a solution that will transform it to a git repo. Actually a git repo is not that different from a tarball webshare with a shell client for diffs etc.
You mean in theory it will happen. I think the real question is, "Does it work in practice?" We'd have to look at software like these to see how many got forked versus similar software with repo's and such. My guess: I bet it does work for a good many of them because of developers being too lazy to go through the trouble. If the functionality is useful enough, then it won't work because the maintenance is easier than duplicating their work.
Still, I'm not sure of the value in doing this kind of thing. The licensing schemes where you can't use the projects name in derivatives made sense: poor knockoffs can hurt image and adoption. Yet, people not wanting code to be used so easily probably shouldn't be open licensing it in the first place. These people are weird lol...
Of course for small projects it won't happen. But for big ones it happens for sure. And then it doesn't matter if that (or these) repos are by the original author or not. If you can rely on regular updates to that repo then people will use it just as if it would be the original source and will spread just as far as any other repo based FOSS project. So I think for major projects the limitation you can achieve that way is minimal.
I don't have a photographic memory. If "learning the language" means rote memorization of an inconsistent set of rules for how the fucking code is parsed, then you're goddamn right I'd rather mindlessly insert a character that obviates that.
> They aren't needed at all. Semicolons in JS are optional.
So they're not really optional. What they are is necessary and if omitted the engine attempts to put them in automatically. The rules for automatic semicolon insertion are in section 7.9 of the ECMAScript 5 standard (http://www.ecma-international.org/publications/files/ECMA-ST...).
This means you're omitting something that is required by the engine but not necessarily required in the syntax which boils down to you losing control of where semicolons end up possibly making your code do something you did not intend because you either misunderstood the rules of automatic semicolon insertion or there was a bug in the syntax parser being used.
You're only "losing control" if you don't know how ASI works, which is well-defined in the ECMAScript standard.
Bad programmers that can't understand ASI will be also confused by the floating point semantics, promises and other basic concepts — there are many ways of "making your code do something you did not intend" in JS, but that's no excuse for bashing language features.
Fact check: ASI is a fully legitimate part of the language (as in, it's in standard, it's documented, and supported across the board), so demonizing it is every bit as silly as e.g. deprecating C macros.
Learning the language helps with the the issues you outlined, while magical thinking (uguuu, semicolons good, no semicolons bad, uguuu) for the most part doesn't.
> Bad programmers that can't understand ASI will be also confused by the floating point semantics, promises and other basic concepts — there are many ways of "making your code do something you did not intend" in JS, but that's no excuse for bashing language features.
This is a terrible attitude. There is no reason you may not understand every case in which a semi colon is automatically inserted but can still understand floating point, promises and other things. Automatic semicolon insertion isn't really a "basic concept"; it's a convenience for those who elide them and nothing more (the ECMAScript 5 standard even states this).
> Fact check: ASI is a fully legitimate part of the language (as in, it's in standard, it's documented, and supported across the board), so demonizing it is every bit as silly as e.g. deprecating C macros.
I'm not "demonizing" it but if you look at the standard the engine still requires semicolons it just fills them in for you if you miss them. This is vastly different than your deprecation of C macros example. Yes it's documented but it's non-obvious unless you've literally looked it up to learn it. I'm also not sure why you insisted on letting me know it's a "fully legitimate part of the language (as in, it's in standard, it's documented, and supported across the board" when I linked to the standard and stated exactly where to look for its definition...
> Learning the language helps with the the issues you outlined, while magical thinking (uguuu, semicolons good, no semicolons bad, uguuu) for the most part doesn't.
Sigh. Automatic semicolon insertion is only documented. There are no errors or warnings or other information. Many developers, who understand more advanced topics, may not even know about it. The language does nothing to help with this. It's far better to be more explicit than assuming everyone who looks at your code understands the full ECMAScript 5 standard.
It's the same reason that, yes, you can put "var x" in an if-block, but it's bad practice because it misleads the reader (even one who knows that Javascript is function scoped) into thinking that x is block-scoped.
Javascript never should've had C-like syntax if it was to have the feature set it does. Its syntax descends from a tradition of languages that have none of its actual features. Most other C-like languages have block scope[0]. So the syntax PLUS the terrible, awful, no-good very bad name lead you to believe it's more-or-less dynamic Java, when nothing could be further from the truth.
[0] ...and require declaration before usage, and have sensible 'this' semantics, and are class-based, and have function parameters that are more than just syntactic sugar, and have ACTUAL arrays, and...
In the worst case, you can do something along the lines of
[file1, file2, file3].join(';\n')
albeit if you're using any kind of post-processing tool, like UglifyJS or Google's Closure compiler, then everything just works, as these tools actually parse JavaScript. There's usually no need to explicitly concatenate the code prior to minification or other processing.
The title of the post is similar to saying e.g. "ARM CPU is bad UX", and complain that you can't mine Bitcoin effectively on ARM.