781–790 of 887 posts
Earlier quoted context omitted.
string[0] === string[0].toUpperCase() && string[0].toUpperCase() != string[0].toLowerCase();
typeof string == "string" && string.length && string[0] == string[0].toUpperCase() && string[0].toUpperCase() != string[0].toLowerCase();
Earlier quoted context omitted.
I'm very hesitant to answer this, as i know it will bring on angry comments and people telling me i'm wrong, but i'll give it a shot (this is all literally off the top of my head right now, so if you are going to poke holes in it, cut me some slack) This got a lot bigger than i thought, so strap in! * The lack of "private" anything. This sounds like a bad idea, but I firmly believe it was a major reason for JS's succ…
Interestingly to me, a lot of your points apply to my own favourite language, Lisp. Regarding a lack of private anything, it's possible to monkey-patch any Lisp package or class however one wants. And of course, one can get true privacy in JavaScript if one wants, by using closures — the same trick applies in Common Lisp. Lisp debugging is great: one can set up all sorts of condition handlers and restarts, and invoke…
The only thing i have to add is that while callback hell sucks, there have been some pretty recent (in the grand scheme of things) additions to the async programming field. Async/await is beautiful, and it has made me fall in love with async programming all over again.
Earlier quoted context omitted.
Spoken like someone who doesn't have a tight deadline.
That's true, I don't. But if your deadline is too tight to do it right, maybe you need to reevaluate your project plan. I mean, I can certainly see using more dependencies than I'm using. Mail is a great example of something that probably should be handled by dedicated, well-tested code. But to carelessly dump piles of third-party dependencies in your project to save a few minutes, as talked about in this article...…
Holy moly-- is-positive-integer/index.js: var passAll = require('101/pass-all') var isPositive = require('is-positive') var isInteger = require('is-integer') module.exports = passAll(isPositive, isInteger) I retract my previous statements that Javascript programmers are going down the same enterprise-y mess that Java programmers went down a decade ago. They've already taken it to an entirely different level of insani…
Relevant: '"The Excel development team will never accept it," he said. "You know their motto? 'Find the dependencies -- and eliminate them.' They'll never go for something with so many dependencies." In-ter-est-ing. I hadn't known that. I guess that explained why Excel had its own C compiler.' http://www.joelonsoftware.com/articles/fog0000000007.html
Earlier quoted context omitted.
The equivalent in C would then be replacing #include and "-lm" with #include #include #include #include … and "-lsin -lcos -ltan -lsinh …" Which is nuts no matter what language you are coding in.
> #include #include #include #include I've written worse - at least those cover multiple variations each (or overloads in C++ for float/double/std::complex?/...) While I'm not a fan of the enforced java route of 1 file = 1 class, I do trend towards 1 file ~ 1 (main, public) thing - which might be a single function with no overloads. #include ? Better than #include , which I see far too often... I don't have to figure…
Earlier quoted context omitted.
It's interesting to me that people find this convincing. I find it to be complete insanity. People need their libraries, but putting everything in tiny buckets is just not working. Why aren't people working on good utility libraries instead? There's even some guy calling for a "micro-lodash". To me, as a Python engineer, lodash [1] is already a tiny utility library. I guess it's also about the fact that JS is a prett…
There is a practical reason for tiny modules in client-side JS that doesn't exist with Python: page load times. If your base layer is going to have third-party dependencies, they better be tiny and do only and exactly what you need. That said, lodash core is only 4KB, and lodash gives you the ability to build it with only the categories or exact functions you want, so I don't understand what the purpose of a "micro-l…
Earlier quoted context omitted.
Is Node.js itself appropriate for packaging? I think maybe not. It changes really quickly, and has done for some time. Anyone coding in Node installs the particular versions she needs without regard to the distro. Most Node modules are just libraries installed in and for particular projects. There are tools written in node, but for the most part they focus on coding-related tasks that also tie them to particular proj…
I'm not talking about packaging node libraries for developers. No node developers are going to use system packages to install their libraries. What I mean is packaging applications written in node for end users. For example, you can install Wordpress on Arch with `pacman -S wordpress' and you'll have a managed wordpress installation in /usr/share/webapps/wordpress. Then you just edit some wordpress config files, set…
I'm sure if I look hard enough there are some silly idiosyncratic steps one might take to install this module. Suffice it to say that it's not installing the "npm way", so it's misguided to blame npm for packaging difficulties.
More generally, I can certainly understand distro packagers' refusal to recreate towering pyramids of node dependencies in their own package system. Some lines have to be drawn somewhere, and "major" modules must bundle many of their dependencies when packaged for distros. If module maintainers don't do this, and distro packagers can't, then the modules can't be packaged.
Earlier quoted context omitted.
I thought the problem was callback hell. I've sat through a bunch of promise talks and the problem was never 'JS should be more compositional'.
Yes, uncompositionality of callbacks leads to callback hell. Or to reinventing every single thing but for callbacks. Like array.map (which works with promises) or array.forEach (also works with promises) or every single synchronous function (they all work when passed to promises).
It seems you're defining callback hell as 'whatever promises solves' rather than it's common definition of over-nesting.