delluminatus

Even many of your examples of "technical" questions seem at least partly political to me (which just reinforces your point, I think). For example:

* Language bindings: The decision to create and maintain an API binding in a particular language is mostly a political decision based on what your API consumers want. It is a trade-off between convenience for the consumer and extra work for the API developers. You will probably develop bindings for popular languages. But what if a language is very popular but also one that developers are unfamiliar with, so it would be a high cost to learn the language and develop the binding? Both the developer and the consumers are invested in the resulting decision, which makes it political.

* Performance characteristics: This can be political as well, because in a sense it's a negotiation between the developer and the consumer. How much extra work should the developer do to save the consumer some time? How much of the computation should be done "behind" the API, and how much should be pushed onto the API consumers?

* Protocols: Each protocol has costs and benefits for the API developers and for the consumers. For example Apple chose to expose their push notification service over TCP, not HTTP. This has costs for the consumers because now they have to use a 3rd party library to handle a new TCP protocol (or implement it themselves). On the other hand, Android's push notification service uses HTTP POST, which is more developer-friendly. I would argue this is a political decision (and a deliberate one on Google's part).

* Latency: Typically reducing latency costs the API maintainers more dollars, but it makes the consumers' applications more performant. This is also, in my eyes, a case of a political negotiation. How fast can we make it so that consumers are satisfied, while spending the least money? Or from the consumer's perspective, how much latency is "acceptable"? This embodies a political trade-off as well.

You could probably make similar arguments for almost every other API characteristic. The simple fact is that almost everything that involves multiple people with selfish interests is at least somewhat political.

ClojureScript is probably not the best language to use if you want few layers of abstraction. I personally love it, though.

The best way to think about this development is that it is a client-side compiler for ClojureScript. In client-side development, you are constrained by the limitation that all code must be in JavaScript to be executed by the Web browser, which is why this compiler "compiles to" JavaScript instead of machine code. JavaScript is the assembly of the Web, right now (until things like WebAssembly get more useful and popular). Once the ClojureScript is compiled to JavaScript, the JS can be executed by the browser (which of course involves an additional JIT compilation step). This might sound "dirty" if you are used to thinking about non-Javascript development, because it involves two separate compilation steps, but it is unavoidable, once again until something like WebAssembly becomes popular.

So, this is a client-side compiler for ClojureScript. A server-side compiler already exists, which is what you would use if you wanted Emacs/Slime support, or if you were developing a "real" Web application for deployment, because in that case you would want to pre-compile to JavaScript on the server, and distribute the compiled JS to the client.

It doesn't really make sense to talk about Emacs/Slime running on the client, until someone makes Web app for it. You could use a socket-based REPL to communicate from the client to the server but I don't really see the benefit, when you could just use the server-side compilation model and avoid the network overhead.

Thank you for the reply. I am beginning to understand what you mean about how there is not enough research to make general statements about side effects or medical efficacy, because there are just so many potential factors that could have an influence on how cannabis affects an individual.

I can see why one would hesitate to make recommendations, especially as a doctor, when it's simply uncertain if a user would get medical benefits, or whether they would have negative side-effects. As unlikely as side effects may be on average, for people with specific conditions a negative effect might be predictable if that condition and its interaction with cannabis was isolated in a study.

It sounds like you are reasonably well informed in this field, whereas I can barely parse the abstract for the linked paper. I was hoping you could give me an educated opinion about negative effects of cannabis use in non-adolescents. It seems like papers are mostly finding negative effects for adolescents only.

Also, the particular paper you mention seems to be studying adolescents with "Cannabis Use Disorder (CUD)". Is this just a roundabout way of saying they are a pot smoker, or is there a difference between cannabis use and "cannabis use disorder"?

For example, consider a non-adolescent who uses cannabis sporadically but does not have a "disorder" (i.e. no addictive tendencies). Do you have an opinion about cannabis use for that individual?

Sorry to say, it's nothing React-specific. I understand that there is a React Developer Tools addon for Chrome that might be of interest [0].

As for me, I just turned on Javascript CPU profiling in Firefox Developer Tools, scrolled a bit, and checked what JS calls were causing the slowdown. Because the unminified source for the website is available on Github, you can quickly find and examine the functions' code directly [1].

[0]: https://chrome.google.com/webstore/detail/react-developer-to...

[1]: https://github.com/casesandberg/react-context/blob/gh-pages/...

No (edit: kinda). It looks like the site calls setState() on the root React component every time the scroll event is fired.

For those not familiar with React, setState() is a function that is used to update mutable state, and it is not a very cheap function, because it propagates the state through all child components, re-renders some virtual DOM, and potentially also causes actual DOM reflowing. Calling this in the scroll handler is what causes the noticeable delay.

edit: it seems like the lib itself does also call setState on scroll [0]. I don't think this is the source of the issue on the site itself, which has additional scroll handlers (for the magic non-scrolling sidebar), but it could cause similar performance problems, depending on how many child components are in your Context.

[0]: https://github.com/casesandberg/react-context/blob/master/sr...

It's not exactly the same, which is what I thought was interesting. My first example did use a generator expression inside the dict() constructor, but in that case you need to specify the key and value in a tuple or a list.

With the dictionary comprehension you can just separate the key and value with a colon, which is more natural. It might just be sugar on top of a generator expression but it is definitely a special case, syntactically speaking.

Even knowing a lot about FP, I still found this worth skimming for the esoteric Python syntax. When it comes to constructing dictionaries with list comprehensions, I would always do something like this:

  dict([n, 2 ** n] for n in range(5))

But they pointed out an actual "dict comprehension" that I didn't even realize existed:

  { n: n ** 2 for n in range(5) }

And there is a similar "set comprehension":

  { n ** 2 for n in range(5) }

Always amazes me how you can use Python for so many years and still encounter new features in the language.

Depends on how basic you're imagining. Khan Academy [0] is a fairly well-regarded free resource for high-school and undergraduate level mathematics video lectures. They have probability and statistics as well as linear algebra courses.

If you prefer textbooks, I have heard good things about "Linear Algebra Done Right," [1] but I would not recommend it unless you are "math literate" at an undergraduate level already.

[0] https://www.khanacademy.org/math/probability

[1] http://www.amazon.com/dp/3319110799

Not the parent, but Angular apps often involve rendering different views based on the URL fragment. This is intended to give you "bookmarkability". So for example instead of bookmarking something like this:

http://example.com/users/1234

it would be something like this:

http://example.com/#!/users/1234

Personally, I have found that for SPAs with centralized state, you can serialize the entire application state into the URL fragment. This means that no matter where the user is in the application, they can bookmark that URL and it would return them to exactly the same place that they were (authentication aside). The disadvantage is that the fragment doesn't necessarily "make sense" to the user, and the URL is too long to be conveniently remembered or retyped manually.

What support libraries would you recommend?

GraphQL is a query language. It's protocol-independent. It just so happens that HTTP POST is a convenient way to deliver queries. Instead of using an HTTP endpoint, you could just as correctly implement GraphQL directly over TCP, or messaging queues, or whatever you want.

I think extension methods in C# are basically a way to work around the fact that you can't just stick a method on the prototype like you can in Javascript. I also like the C# solution, actually, I just love C#. It's a great "daily driver" language in my book.

If you took the function bind syntax to its natural extreme, you end up with a model like Python or Nim, where all instance methods accept their "this" as a first parameter, and "a.call(b)" is equivalent to "call(a, b)". Personally I always thought that was a particularly elegant way of implementing instance methods, because it doesn't require inheritance or modifying the original type.

In Nim it even lets you do some very interesting method chaining to replace nested calls, like "toInt(sqrt(toFloat(num)))" can be equivalently written "num.toFloat.sqrt.toInt"

I could see how that's a legitimate concern, it reminds me of some of the complaints I hear about C++ having too many features (I don't use C++, so this is just hearsay). But Javascript is still a much smaller and simpler language than almost anything else out there. Sure, it has some semantic quirks, but the syntax is fundamentally minimal. I think it will be a long time yet before we reach the point of being really overcomplicated.

I think the uncertainty around Javascript (and I do agree that there seems to be a real sense of confusion in the community when you look at the explosion of libraries and frameworks) is more related to the fact that we are trying to solve hard problems in a language that really gives us no help. We get no type checking, no good concurrency APIs, no immutability, no good sequence abstractions until iterators, just a fairly low-level and extremely hackable language with an unusual prototypal inheritance system.

Well, who knows. I would personally like to see some more stuff be standardized in the language or the official APIs so we don't end up with four competing libraries implementing "map" and "reduce", or promises, or whatever other thing.

I disagree. I think that extending and improving a language is good, and it's certainly not a Javascript-only phenomenon.

Off the top of my head, other languages that are considering and implementing syntax extensions include Python (e.g. "yield from"), C# (e.g. "async/await"), and Java (lambda expressions).

I actually think that it's pretty low to accuse ECMAScript of "mangling" JS syntax when they are just trying to add modern extensions that make common patterns easier. Of course this function bind syntax is just a proposal and hasn't been accepted into the standard yet. But what about it bothers you so much? What about iterators or shorter function definitions, are those also nightmarish manglings of syntax? I mean, really. The usage of Javascript is evolving from simple embedded scripts to gigantic client/server applications. It's no surprise that the language itself will evolve as well.

They actually address this point specifically on their Nutrition page. I am not an expert so I have no basis for comparing your claims to theirs, but it seems like they are at least sensitive to the issue, as it were.

Fats: Those worried about saturated fat content should be assured that our saturated fat (and cholesterol) content derives from healthy sources, not industrially produced fats. Milk, eggs, cocoa butter, and sunflower seeds; these are nutrient-dense and healthy sources of energy. All our sources of fat have shown numerous benefits in long term studies. Lacto-ovo vegetarians have significantly extended life spans compared to people eating normal diets, vegans, and even regular vegetarians. Dark chocolate lowers blood pressure as well as being an antioxidant and nutrient source. Sunflower seeds are a rich source of vitamin E and demonstrate anti-inflammatory properties. Most of our polyunsaturated fat derives from raw sunflower seeds. Given the very high vitamin E content of sunflower seeds, we are confident that our polyunsaturated fat is stable, not oxidized. We will be sourcing our sunflower seeds from the high oleic acid varieties to reduce polyunsaturated fat content further.

It is possible (and, I think, a rather clever idea).

You could, for example, use a part-of-speech tagged corpus (a large collection of text where each word was tagged with its PoS by a grad student). Just train a Markov model on the parts of speech instead of the words themselves, and you would be able to generate English-like mad-libs.

I only found out about these recently because my company uses them in their custom RPC protocol, which was created about 15 years ago I think.

IMO, there are ups and downs to using unprintable characters in your protocol. On one hand, yeah, you don't need to worry about someone putting a tab in a TSV field and messing up the format. On the other hand, it can make debugging a lot harder because what you see isn't necessarily what you get, and obviously it becomes harder to hand-write requests.

Of course, OP ended up using unprintable characters anyway, so I think they might as well use the ASCII ones. But even if you know about and use those characters, I think there is still a place for [CT]SV.

I'm glad you brought them up though, because I think the nonprintable ASCII characters occupy a very interesting place in computer science -- (almost) universally supported, but (almost) never used.

I was curious to see how something like this could "trash an installation".

It seems like the issue is that the Skype installation maintains a chat history. If this poison string is in your chat history, something crashes the client (presumably a procedure intended to linkify URLs in chat).

You can delete your chat history, but it is synced from the server on startup, at which point the client crashes again. That's why your only option is to downgrade to a version without the bug.

I actually have a tip for async programming on small projects. Consider storing as much of your state as possible in a central location if it's feasible for your application. As much as possible, avoid relying on closures except for data hiding. This makes it easier to think about what is going on in your application even if the code flow is not exactly linear.

For example use a global object called State that contains information about the list of build tasks to be run and the state of each of the stages for the tasks.

I'm not sure, maybe it's just the overhead of having so many function calls and Set accesses? My guess is that the Haskell one could be made quite a bit more efficient if you used a low-level mutable array.

To add another benchmarking data point, I have a simple sieve of Eratosthenes written in Nim using an array that can generate 10,000 primes in less than a millisecond.

I think you're confused about the strings. Python 3 uses UTF8 strings by default. The u"xx" syntax is only needed in python 2.x. In Python 3.x it's only supported for backwards compatibility.

I like this post a lot, because it reminds me a lot of myself. I have spent a long time thinking about how the deluge of easy entertainment and shallow articles on the Internet has affected the way people operate. I've even done a similar experiment in the past, except in my case it was banning the Internet except for a specific set of use cases. It was certainly an interesting experience.

One warning I will throw out for those considering entertainment/distraction deprivation: you will need something to spend your time on. Instead of just taking away, use the same opportunity to try to cultivate a productive habit (hey, you're going to be suffering anyway -- might as well).

Also, you need to think about whether this really addresses the issues that cause you to be "mediocre"/lazy/unproductive. It's easy to blame external factors like the Internet for providing easy entertainment, but it's also important to look inward and see if you have mental roadblocks that are inhibiting you -- perhaps you are mentally exhausted from work, or maybe you just aren't interested. Also, I've started to think that some people are just flat out less productive than others. Or to put it another way, some people are abnormally productive. After all, productivity is really more of a means than an end. If you're not sure where you are going, it doesn't matter how fast you get there. And if you do have a goal, abstract ideas like quality or productivity are quickly redefined in more concrete terms to fit your new intention.

Definitely. Try clicking through to the article:

We generally use web pages as our canvases and paint content on the x– and y-axises. This is our tangible abstraction of reality. Here we are going to explore what happens when we introduce z-axis to content presentation. Instead of stripping down reality to a plane, we are going to simplify it, keeping our three physical dimensions but only their minimal essence.

He actually mentions it in the article:

Note: a drawback that comes with miter-joined lines is sharp edges. When the angle connecting two segments is very sharp, the miter length grows exponentially toward infinity, and causes huge artifacts in rendering. In some applications this may not be a problem, in others you might want to limit the miter or fall back to another join (i.e. bevel) when the angle is too sharp.

I believe this is a direct quotation from Murakami's memoir, What I Talk About When I Talk About Running. The whole book is worth a read, especially if you liked this article.

If you want to read an actual novel by him, I highly recommend 1Q84, which is an engaging and somewhat surreal story.

I don't know about Underscore, but lo-dash [0] supports lazy execution of a chained query without generating intermediate arrays (see docs [1]). It offers something pretty similar to LINQ queries on collections (except you don't get the benefit of strong typing).

[0]: https://lodash.com/

[1]: https://lodash.com/docs#_

I think you're right, that does seem like a possibility. It seems unlikely to me that our wage-paying jobs will be phased out by automation that rapidly, especially if you consider the whole global economy. Of course, I could be completely wrong -- I guess a true Singularity could invalidate almost all labor in a matter of years or even months, depending on what form the AI takes and what it invents.

I think this is a more legitimate concern than the fear of the "Matrix outcome" that some people seem to have.

But, what you're describing is the process of people being replaced by technology. Generally speaking, this will probably not be a problem for a free-market economy, although it will certainly result in some unemployment.

The key point is that replacing humans with machines does not only cause unemployment, but it also reduces cost of production, which stimulates capital investment and/or reduces prices in the industry in question. In the general economy, this reduced cost and increased production should offset the lost "purchasing power" from the now-unemployed parties. The stimulus reduces costs in other industries which promotes job growth.

The end result is likely to be that the same number of people are employed, but they are employed in a more efficient manner of production. The cost of labor will decrease relative to the amount of production, however because this is tied to a decrease in cost of production, the real value of the labor (in terms of things you can buy) should not decrease.

Of course there will be some disenfranchised individuals, especially those who have particular skills that are replaced my mechanization. However, this is more likely to affect skilled laborers (like cooks) than those who are not paid for their skills (like janitors or cashiers).

In the end, I guess my point is that a free-market economy naturally balances these factors due to the relationship between supply and demand. However, it's possible that we will reach a point, especially if we truly do hit a Singularity, where we will have to reconsider the use of a scarcity-based economy at all, as production becomes completely divorced from any human action. Hopefully though, at that point the cost of goods will have naturally fallen to such a degree that the transition can be performed peacefully.

A fairly broad latitude? If the ends justify the means and yet the ends themselves are kept completely hidden, then the latitude, as you put it, is completely unconstrained. An intelligence agency operating under those principles can literally do anything claiming that it is for the greater good.

In short, it sounds like you are advocating for an agency which can take arbitrary extralegal action at its own discretion, without providing reason or explanation, and without providing any demonstrable benefit to anybody, because it's secret.

Frankly, I find the idea terrifying. I understand that intelligence agencies need some quantity of secrecy and some degree of latitude. Like you have repeatedly stated, there are no easy answers. But that doesn't mean we shouldn't ask the question. What the hell are these people doing, and should we let them continue? What is growing in our intelligence sector -- is it an institution that will be found to have brought the world benefit, like Bletchley Park, or will it be seen to have become a thin facade over a malignant, self-interested organization, potentially culminating in something like a secret police?