T-R

Sorry, I just noticed that I didn't really properly respond there. "Reading" can mean "pronouncing" or "comprehending" - I'm arguing that overall comprehension (including both word identification and reading speed) is easier in languages like Chinese or Japanese than in English. Just from personal anecdote, I feel that many English speakers learning Japanese that have trouble with reading comprehension have issues not because of the language itself, but because they try to study vocabulary as if it's a phonetic language, as many classes are taught that way - memorization focus is on how characters or words sound, rather than the meaning of the characters or radicals they're composed from. The situation may be worse with Chinese if it's as common as the author implies for students to still have trouble reading newspapers after 10 years of study.

Familiarity with a character is a lot like familiarity with a latin root word in English - if you know most or all of the characters that compose a word, you can usually do a pretty good job guessing the meaning of it. Certainly there are exceptions (and there may be more in Chinese than Japanese, which I'm more familiar with, as Chinese uses non-phonetic characters explicitly), but I'd still argue that it's quite useful. In Korean, which has a phonetic alphabet (though based on the same characters), I can always sound out a word, but I'll often have no idea what it means, whereas in Japanese, often I can't read a word out loud, but I know exactly what it means. For every "uptight", there are a dozen 心電図 (心:heart + 電:electric + 図:map = electrocardiogram). It works with spoken language as well, though - often times I'll hear someone say a new word, and I'll ask "is this the right character/syllable breakdown?", and if it is, then I already know what it means.

Edit: To your point regarding English having both connection to meaning and pronunciation - that's definitely true, it's just not as immediately clear/visually identifiable, and not as dense. One could certainly argue that, if native speakers are having serious issues learning pronunciation in a language, then the language makes a poor tradeoff with density there.

I can't really speak to the utility of using the characters in practice, but looking back on when I was studying Japanese and Korean, it frustrates me that more emphasis wasn't put on the characters, as learning the roots of the words was incredibly helpful in learning vocabulary, in the same way that learning Latin roots would be helpful in studying English. It was, though, much more of an issue in Japanese, where you run into the characters everywhere. Because of the heavy conversational emphasis in most foreign language classes, I didn't learn about character composition (radicals), or the phonetic element to characters until I took a bit of Chinese. When I did finally learn these things, my reading comprehension got a very significant boost.

I'd maybe argue that the use of Chinese characters in Japanese allows me to read much faster than if all writing were in Hiragana, particularly since people tend to identify words more by their shape, but Hangul does this quite well on its own, so I think maybe there's not as strong of a need for it in Korean.

While what the author says is true, I feel like there's a hint of ethnocentrism - his complaints all (over)emphasize the use of the link between the pronunciation of a word and its written representation. Whenever the author discusses things like writing the word "president" or forgetting how to spell "tin can", implicit and unmentioned is that the hypothetical person knows the pronunciation of the word, and is attempting to translate it into writing, which, of course, is a natural thing for someone coming from a phonetic language to assume the importance of. Yes, more logographic languages like Chinese have a weaker link between pronunciation and written form, but this is a tradeoff, not simply bad design. One could similarly make an argument about English speakers forgetting what words mean (or for that matter, just that it takes forever to say anything in English).

I'm not sure whether or not it's the case with Korean, but in Japanese, many homophones are tonal, though not often explicitly acknowledged as such. words like 神 (kami: god) and 紙 (kami: paper), or 席 (seki: seat) and 咳 (seki: cough) are fairly consistently spoken with a particular distinguishing intonation, which helps, along with context, to disambiguate them from eachother.

> The idea that this composability is unique to Haskell is false. Java's streams are an example of exactly the same thing in another, non-functional, language. The Gang of Four "decorator", "composite", and "chain of responsibility" patterns are further general examples.

Certainly the concept of composability isn't unique to the Haskell community, no one's implying that it is. In fact, part of the point is that even these specific abstractions aren't unique to Haskell, but available anywhere, as they've been borrowed from mathematics. Composability and consistency are things that the mathematics community does exceedingly well, and the Haskell community has chosen to learn from them, while most other language communities do these things poorly, as they've chosen to reinvent the wheel. The GoF Design Patterns, in particular, are a rather verbose reinventing-the-wheel of well-known concepts like partial application, but with inconsistent vocabulary and implemented with regards to the limitations of some specific language's semantics, and do a poor job isolating the minimal set of constraints necessary to get the intended emergent properties. Calling a person or community arrogant for trying to highlight the utility of learning these lessons isn't helpful to anyone.

These are not patterns unique to Haskell. In fact, it's just the opposite: these are mathematical abstractions, and so they can be used anywhere that you have use of function application, in stark contrast to the alternatives. By using these patterns instead of Ruby or Javascript-specific, Application-specific, or Object Oriented-specific patterns, you can be more confident that your abstractions will be consistent with eachother, and as a result, more composable.

Case in point: I'm currently developing in Javascript, but I use these patterns (Monad, Applicative Functor, etc) to manage things like asynchronous code and error handling, because they're far more flexible/composable and reliable (in terms of not having side effects) than the other offerings on hand, and I know that will always be the case, because these abstractions were designed with the constraint of composability in mind: in fact, they are, by definition, the minimum set of constraints required to get these emergent properties. The benefit that Haskell itself offers is that it can check at compile time that these constraints hold true.

I hardly found any in Paris, myself. A bunch near the Google offices in Mountain View and Roppongi - maybe it's using past visited location data?

Their new audience isn't quite as easily convinced to invest hundreds of dollars on a piece of dedicated hardware.

Worst case with Facebook:

     - It would signal a shift toward gimmicky experiences targeting a
       casual market that wouldn't spend several hundred dollars on a
       piece of esoteric hardware.
     - It would spoil an opportunity to partner with a company that has
       much more experience in hardware, gaming, dev tools, or anything
       else Oculus could use to take off.
     - The likely integration with Facebook's authentication and social
       services will cause the product to suffer from all the ill will and
       distrust Facebook has generated within parts of its userbase and
       the developer community. Branding is important, and to these
       communities - the ones Oculus likely needs to take off - Facebook's is poison.

An acquisition by Zynga or Gree might've been almost as bad, but any of the other companies mentioned wouldn't have signaled such a shift, and such a betrayal of the intent of the initial kickstarter investors and hopes of its supporters. Oculus appears to gain nothing but money from this deal. I'd say the announcement alone squanders Oculus' only relevant lead over Sony and others.

This is a terrible move for Oculus, though. The reaction from their core audiences - hardcore gamers and developers - seems to be largely negative, at a time right after Sony - a company that caters to that audience - announced its competing "Project Morpheus". It's not being taken as a signal of Facebook's innovation, but as Oculus moving toward a casual audience, and their fan base feels abandoned. Do they really feel that whatever plans they have with Facebook are so low-risk and high return that they no longer need that audience?

This was a fantastic talk. Sad that you have to log in to view it now. That was definitely not the case a few months ago.

I've not gotten a chance to play around with it yet, but there's plv8x (https://github.com/clkao/plv8x), for managing plv8 functions.

True, but that's not at all uncommon. Perhaps it was submitted by the same person? Still, that'd hardly be a reason to shut down the conversation.

Java (at least prior to Java 7), has some severe limitations in how code can be abstracted. As an example, it doesn't allow you to pass functions as arguments to other functions directly. As a result, the canonical way to handle situations where you would do this (such as passing a comparison operator to a sort function), is to declare an interface, define the function in a class that implements that interface (command pattern, etc.), and then instantiate an instance of the class and pass that. Closures are imitated by explicitly passing data to class constructors and storing it in member variables, and currying imitated through patterns like the onerous abstract factory pattern.

Additionally, the abstraction features Java does offer are implemented with some heavy language syntax, and often can't be generated at runtime or pre-compile time, at least not easily, and so there's a limit to the abstraction, even taking into account Java Generics. That's something where homoiconic languages like Clojure have a particular advantage.

As a result, abstracting things in these ways (which in other languages is incredibly common) gets to be painfully verbose. Often, things that would be beautifully abstracted in these ways are just left unabstracted (as in-line boilerplate) - the verbosity introduced makes the code less readable, rather than more, and so there's a stigma against "over-abstracted" code. The result is that code that does, or could, make use of these things takes exceedingly more code in Java than in a language like Clojure. Of course, conventions in Java of, e.g., giving each curly brace its own line aren't helping its case in line counts, either.

One of the nice benefits of writing for an old console like the NES is that emulators are often the first things ported to new platforms - you effectively get all the portability of writing for a virtual machine, along with the ease of running on only one type of hardware. Most of the hardware/compatibility concerns (Can I maintain a proper framerate on this hardware? Is the screen large enough? What kind of controller does the user have?) are on the person porting the emulator, not the developer. Also, for the user, this means any configuration only needs to be done once for all of the games on that platform.

As for hardware, if you can't find an NES, you can always use a third-party retro console, like the Retron 3.[1]

Also, if you're worried about compatibility, Byuu's cycle-accurate SNES emulator[2] has been expanded to run NES, Gameboy, and Gameboy Advance games, so testing on actual hardware is a lot less necessary than it used to be.

[1] http://www.thinkgeek.com/product/13f8/ [2] http://byuu.org/higan/

We're trying to cover exactly those kinds of questions - http://www.slant.co/topics/871/~best-linux-distribution

Not trying to compete with SO, but we think those questions need a home, and share eterm's view that maybe they're not a good fit for SO's format.

King of the shrines?

As a data point, when I worked in Japan, most of the code was written in English (variable names included - the language was mostly Java or PHP), with heavy commenting in Japanese. Granted, this may have been swayed from the fact that they often worked with Indian developers, but also, a lot of technical language in Japanese is adopted from English. Popular languages there are the same as anywhere else - Ruby's creator is Japanese, and a high school student I know there was being subjected to COBOL.

There is a Japanese programming language, Mind, which is a stack language written entirely in Japanese, though I don't think it ever gained popularity. It's kind of sad there hasn't been more exploration into this - there's a lot less impedance mismatch in going from Japanese (or Korean) to postfix than there is going from English to prefix.

http://en.wikipedia.org/wiki/Non-English-based_programming_l...

Sorry for the trouble, working on getting it back up.

Thanks for the feedback!

We'll definitely be iterating on how we rank and present viewpoints to try to reduce bias. We don't want to remove indicators of popularity entirely, though, since that would reduce the utility of the site for readers who are still trying to decide. We do intend, though, to at least provide enough information for users to judge where there may be bias for themselves, and we'll try to eliminate it where we can.

We've got a topic on it over on Slant -

http://slant.co/topics/446/~what-is-the-best-alternative-to-...

The difference is that the first works with all of the native list functions, as well as all of those in e.g., underscore, without any extra work. The latter doesn't. Now, the latter certainly offers some other features, but my point was that, in specifically building an HTTP server, it's been my experience that those features aren't of as much use as being able to use the native list functions to, say, map a log function onto the list of functions, or reduce while halting execution under particular conditions.

Just plain-old native functions - that's the whole point.

I think his point is that there's usually a very strict ordering to the events on an HTTP server - you parse and sanitize your input, make some database calls, and generate a response - at best, letting something else do the sequencing and composition for you doesn't gain you much, as it might in a reactive GUI. At worst it leaves room for subtle bugs or code that's less clear (arising from the statefulness of the Promse object itself).

Using a Promises, as opposed to reducing a list of computations async-style, also limits you to the Promise object's interface, so you lose (or at least add cruft to) the flexibility and composability of using native lists. By sequencing computations with lists, if I want some insight into what's happening, I just List.map(apply compose, logFunc). With promises, I have some work to do.

Promises have their uses, but it's definitely a tradeoff, and for most HTTP servers, I'd argue that their utility does seem a bit limited. I'd similarly say that making a point of using FRP to build a server would probably be a bit overkill for the task.

Does Heroku Postgres support PLV8 now? In the questions section of the presentation, he doesn't mention it as unsupported, but as recently as Sept 2012, it wasn't [1] - has that changed?

[1] http://stackoverflow.com/questions/12593080/heroku-hosted-po...

Not sure why you're so insistent this is a non-problem (to the point of implying that I or my housemates have personality issues, much less) - it's not like we haven't tried cash. It sucked, so my housemate made an app, and it's awesome.

> Do they go grocery shopping?

Not really - in college most people relied on the meal plan. At the house, we make heavy use of Amazon and Instacart. Those who do shop still don't enjoy having to remember to get cash and make change.

> Sounds like a personality issue

People forget, or just forget to grab cash, because it's not something they normally do, and no one enjoys playing debt collector. WePay can hold balances, too, so the app is basically just a more convenient version of the whiteboard, but with the extra feature of saving a trip to the ATM.

If obtaining cash was somehow related to a personality issue, but that person was otherwise a good housemate, it'd be worth it to throw some technology at the problem and make it a non-issue.

> checks

People are more likely to have a computer, so there's no need to add paper and OCR into the mix when there are better options.

> and then pays 4%

Only if the retailer is passing the transaction fee onto the customer, in which case they can pay with some other method.

People paying debts can link a bank account, so their transaction fee is maybe 50 cents.

Yeah, really. For one, no one in the house carries cash, and no one wants to - that was even more true in college when a lot was paid for via campus ID. Not everyone has transportation to an ATM, either.

More importantly though, when people are splitting bills more than twice a week (often with different subsets of the group), getting paid back isn't just a pain, it gets to be a source of tension in the house - really quickly no one wants to split bills, because no one wants to have to harass their friends about money.

With the bill split app, the person who pays racks up reward points on their credit card, and all they have to do is type in how much everyone owes, and that's the end of it. Everyone else clicks a button and they're paid up.

You can opt to connect a bank account to WePay instead of using a credit card, dramatically reducing the transaction fee.

Bill split apps are really nice if you live in a shared housing/dorm type situation. At our hacker house, we're always going out for dinner together, or sending someone out to get food, or ordering groceries on Instacart - saves so much time not having to use cash, or keep track of who got what beforehand. Really wish this was an option while I was in college.

We've been using Split&Pay ( https://itunes.apple.com/us/app/splitandpay/id593386557 ) - payment is really smooth (just click the button in the e-mail and you're done), particularly since we all already have WePay accounts, since that's how we organize our rent payments.

Full disclosure: Author of the app is one of my housemates, and founding engineer of WePay.