I'm not even a JavaScript hater, but: its relation to C is merely syntactic, and is to its detriment, frankly. And, simple? Assuming a hypothetical comprehensive encoding of programming language semantics, I can't imagine that JS would be anywhere near the top of the list for shortest complete descriptions of same. That and the constant churn of libraries du jour in the JS world makes me think that it is far from an optimal language for the beginning programmer.
I'm a git user, but the one killer feature that Mercurial has that I'd love to see appear in Git some day is revsets [1]. It's a DSL for selecting commits from the repo's history that match a predicate, and you can easily create complex predicates with it that would be much more difficult or impossible to specify with git's brittle command line options.
It's added a lot of small features, like dynamic comment updating and edit windows, but most of the new development has gone into new sub-sites. They're pretty conservative about changing the core commenting dynamic, especially given their informal policy against undertaking technical solutions to social problems, which I think has been a beneficial policy for the quality of discussion there.
> I’m quite fond of languages with minimal syntax.
Maybe this is the Lisp enthusiast in me, but as someone who does the bulk of their workaday programming in Python I still feel compelled to say that it's a perverse worldview that holds up Python as an instance of "minimal syntax."
Of course, but I'm not talking about mere interpersonal politeness so much as having friendliness be a central component of your branding. Chick-Fil-A, for all its vaunted good cheer, still has all the trappings of a commercial transaction, whereas Lyft tries to downplay that in favor of appearing as merely a facilitator of intra-community interactions. That part, specifically, is the part that I wonder about.
What I wonder about Lyft is the extent to which friendliness scales. That it has scaled so far is obviously due to the fact that they can simply project that sense of friendliness and then rely on individual drivers to actually do the work of giving that impression to customers, but what if they want to expand their business into domains where friendliness is unimportant or even a downside (an example might be something like the bike messaging that Uber is getting into in NYC, where prompt service basically requires the service provider to be brusque)? In such a market, the company wouldn't be able to trade on their reputation as the friendly alternative and in fact might be even harmed by the expectation that they would be that. Is friendliness a straightjacket in the making?
Yes, that's a basic fact that I'm well aware of. To hopefully express what I'm saying more clearly: Assume your open strings on a guitar are tuned perfectly in the standard way: the A string is 110 Hz, the low E string is 110 * 2^-5/12 Hz, the D string is 110 * 2^5/12 Hz, and so forth. This will allow you to play an in-tune E minor chord on the open strings, but other chords will not be in tune (again, with reference to the equally-tempered pitch space) to the same degree because of the fact that the strings have different densities and widths. You could imagine accounting for this by tuning the strings such that some other chord was in tune, but then your original E minor chord would no longer be in tune. Thus my point that even though the guitar's design is predicated on equal temperament, it still requires per-key adjustments to be in tune for an arbitrary chord, unless you're using one of the guitars I linked to above.
It's worth noting that the perfect fourth, when it involves the bass, is considered a dissonance in Common Practice music,* and even in the freer harmonic contexts of twentieth century music it's a bit of a cipher: it acts as a dissonance in relatively consonant contexts and as a consonance in relatively dissonant contexts.
* If you read Schoenberg's Harmonielehre, he has some pretty idiosyncratic but somewhat plausible theories about why the 6/4 chord is dissonant, involving the overtones of the bass being diatonic (say we're talking about C 6/4 and the relevant overtones being B and D) but also dissonant with regards to the nominal root of C. That the 6/3 chord is relatively consonant is explained by the fact that the overtones of the bass in that arrangement suggest a sufficiently distant key so as not to plausibly oppose the sounding fundamentals. I think the more likely explanation is the historical one, which treats the 6/4 as the reification of the frequently used motif of a suspension from the pre-dominant harmony over the dominant bass that then passes downward to the goal tones (in C major, the archetypal lines would be A -> G -> F -> E and F -> E -> D -> C over a bassline like F (or D) -> G -> G -> C). The 6/4 chord's dissonance, then, is merely a result of the fact that its appearance came to unequivocally imply a certain resolution.
Right, I'm aware. Maybe I misread the last line of the grandparent, but I assumed that was exactly the problem being referred to -- the vagaries of details like string width and action height mean that even an instrument nominally designed with equal temperament in mind requires per-key adjustments to sound in tune by the standards of equal temperament.
Padgett's cognitive transformation is real, even if the mathematically-illiterate reporting on it obscures the nature of that transformation. Berit Brogaard, who's a professor of philosophy and neuroscience at the University of Missouri St. Louis, has done a lot of studies with Padgett in the course of her work on synesthesia [1]. I haven't read any of her papers involving Padgett myself, but people looking for a more rigorous treatment of his condition might find something of interest in her writing.
Apple's goto-related SSL vulnerability this week is a blatant, high-profile reminder of how harmful unbraced conditionals are. The same bug could have happened with two return statements in a row.
Does OCaml do any sort of structural sharing behind the scenes? This is always the thing that bothers me about the functional JavaScript movement, since mutable state everywhere makes such sharing infeasible, meaning that I have to worry a lot more about space complexity when I'm doing something like a map over a collection. How does OCaml fare in that regard?
> shouldn't two of most widely used languages be included in an argument about static vs dynamic typing?
No, because the affordances and limitations of static typing are not the same as the affordances and limitations of static typing as implemented in Java/C++. You can't infer very much about static typing from statements made about those languages, and you can't infer much about those languages from statements made about static typing, so it follows that you can't freely substitute one for the other in these discussions.
Maybe I'm misunderstanding you, but empirical data on human behavior is notoriously more difficult to both collect and control for than data on more basic processes. I think it's glib to suggest that the effect here should be easily measurable. I also don't think the actual effect is relevant in the first case: no reasonable ethical accounting would gauge the immorality of the act in proportion to its final impact on wages.
> Part of the problem here is what is meant by "math"... it is a shame that someone could get as far as second year university math in the US and still see it as a field where you simplify things to the point where you can apply a formula to arrive at the one right answer. In Ross Hunter's defense, he didn't say that's all that math is, he said "People who are good at math are good at breaking problems down into parts, recognizing patterns, and applying known formulae to those parts to arrive at the one right answer."
I think it's reasonable to assume, given what he stated, that Ross does in fact conceive of math that way. It blows my mind that one can get through a discrete math class and still think of math as basically computational in nature, since as far as I know most curricula treat the course as an opportunity to introduce the sort of concepts that typically figure into an introduction-to-higher-mathematics-type course, such as proof techniques, basic number theory, and so on.
I think it depends on your level of experience. For someone who's a beginner to Clojure and functional programming but wants to use Clojure as their home environment for working through the concepts presented in the book, I suspect they would face some challenges translating the semantics of certain examples in the book, such as streams, to their closest Clojure representation. If you're primarily concerned with just working through the material in the book, you may not want to have to deal with that overhead straight away.
He's making a good point in the abstract, but I think Horowitz is too close to the matter to understand that a lot of the negativity he cites is a natural reaction to the totally overblown rhetoric of the start-up scene. He inadvertently proves this by referencing such epoch-defining inventions as the telephone and the internet. Many tech start-ups are creating interesting, useful, and sometimes even novel products, but it's nonetheless annoying to anyone with a sense of perspective to hear from every angle that Start-up X is going to change the world by revolutionizing, you know, shoe-resoling.
While I think the grandparent is focussed on a non-issue (the two phrases offered are obviously metonymic, not literal), I have to note that this is a much stronger claim than you might gather from a glib programming analogy made by an armchair philosopher. Linguistic relativity is a thing [1], but statements like this widely overstate the extent to which language molds cognition. More importantly, though, I don't think the notion is relevant to the discussion at hand. We're not talking about alternative phrasings of the same idea, but different ideas entirely: yes and no. That different ideas expressed differently carry different semantic payloads is hardly a controversial assertion.
Human reproduction doesn't occur asexually, but you wouldn't know that from reading your comment. Why does the responsibility for this decision rest entirely upon the mother in your conception?
I've never worked with Node and probably never will, but it's pretty dishonest to conflate the sense of "blocking" as in "postponed execution" with "blocking" as in "executing an intensive CPU-bound job" to make a point that shouldn't be surprising to anyone who's paying attention.
I don't know, I'm kind of skeptical that your language reflects statistical realities at all times. Have you never described something with the adverb "probably" that actually had a less than fifty percent chance of occurring? If not, I'm not sure what it is about this particular usage that merits the increased scrutiny.
Thanks, this is wonderful. The foreword mentions a set of exercises that are only loosely coupled with the lectures themselves -- are these freely available anywhere?
They (specifically neural networks trained on the cross-entropy error, with the logistic function as your activation function) work very well in classification tasks where you want to interpret the output as a probability, which is useful when you're more concerned with predicting across datasets rather than individual instances. My lab uses neural networks towards this end in predicting pharmacological activity across large libraries of molecules and all the prospective validation we've done indicates that neural networks are far and away the best-performing option out there for this domain as compared to e.g. SVMs or random forests.
I believe when articles like this one talk about "listening to Mozart," they are indeed referring to active listening, which taxes recall (with regards to things like ongoing restatements of a prominent motive) and working memory (with regards to things like key changes or thematic development). In my intuitive experience, it tends to be a task that requires a certain threshold of concentration to even happen at all, like juggling. As with juggling, you could probably learn to combine another activity with it, but the benefits seem like they would be tenuous.
Out of curiosity, why the switch? I went with gevent pretty early on because it seemed like eventlet had some weird quirks, but I have to admit never really giving it a close look.
> I think the first thing that should be mentioned in any introductory article on Python threads is that Python threads work great for IO concurrency but they won't help with CPU concurrency. Things like downloading files, sending data over a socket will work nicely.
Python's threads certainly work acceptably for IO-bound purposes, but given the overhead of creating a real OS thread and the potential for GIL thrashing when using Python 2.x on a multicore machine, I'm not sure why you wouldn't favor a greenlet-based solution in most such cases, especially since you don't even really have to drop the threading idiom to do so.