A Haskell Programmer Tries to Learn Racket - <AUTHOR> http://artyom.me/learning-racket-1 <comment><USER4> "...but nothing beyond that. As long as Node.js exists in this world, I can't truly hate anything else."

I found this hilarious. I am also rather underwhelmed (to be nice) with Nodejs and a little bothered at its wide adoption.

I have also been learning racket recently; my formal language and functional programming class uses it. I had some previous experience with common lisp but the raw nature of scheme still pleasantly surprised me a little bit.

EDIT: From what I remember, javascript was "inspired" by scheme. Obviously that when well...

<comment><USER5> I keep flipping back and forth, thinking I don't get it, then thinking others don't get it. Single-threaded JS with callbacks. OK? What am I missing?

The only thing Node has going for it is a lot of networking libraries. It's not fast, the async style leads to callback hell, JS is a terrible language, and their package management system is slow and bloated (or at least the packages are)[1]. Yet people think it's some new kind of thing that's just so awesome, despite MS doing server-side JS in the mid-90s.

Sure, people can use whatever makes them happy. I'm just confused as to why anyone is particularly impressed with Node or JS.

1: Seriously, to automate builds, I ended up saving the node_modules directory then symlinking it in to the build environment. Otherwise a simple CSS/JS/etc. grunt build took 15 minutes instead of 1. And it seems every module pulls in its own copy of dependencies, so you end up with 300-character deep paths. There's no apparent reason it needs to be like this.

<comment><USER6> Straight from the horse's mouth:

"Node is popular because it allows normal people to do high concurrency servers. It's not the fastest or leanest or even very well put together - <USER2> it makes good trade offs in terms of cognitive overhead, simplicity of implementation, and performance. I have a lot of problems with Node myself - but the single event loop per process is not one of them. I think that is a good programming model for app developers. I love Go so much (SO MUCH), but I cannot get past the fact that goroutines share memory or that it's statically typed. I love Erlang but I cannot get the past the syntax. I do not like the JVM because it takes too long to startup and has a bad history of XML files and IDE integration - which give me a bad vibe. Maybe you don't care about Erlang's syntax or static typing but this is probably because you're looking at it from the perspective of an engineer trying to find a good way to implement your website today. This is the source of our misunderstanding - <USER3> am not an app programmer arguing what the best platform to use for my website --I'm a systems person attempting to make programming better. Syntax and overall vibe are important to me. I want programming computers to be like coloring with crayons and playing with duplo blocks. If my job was keeping Twitter up, of course I'd using a robust technology like the JVM. Node's problem is that some of its users want to use it for everything? So what? I have no interest in educating people to be well-rounded pragmatic server engineers, that's Tim O'Reilly's job (or maybe it's your job?). I just want to make computers suck less. Node has a large number of newbie programmers. I'm proud of that; I want to make things that lots of people use. The future of server programming does not have parallel access to shared memory. I am not concerned about serialization overhead for message passing between threads because I do not think it's the bottleneck for real programs." [https://news.ycombinator.com/item?id=4310723](https://news.ycombinator.com/item?id=4310723)

<comment><USER7> > The future of server programming does not have parallel access to shared > memory.

Yeah but it could be IO parallelism. There could be two instances of callback chains of sequence C1->C2->C3 started such that the the second starts before the first one finished. As in C1->C2 ran then C1 gets called again. If in those callbacks you update a data structure (a database record?), you now accessed that data in parallel. So you have to protect against that with some kind of a lock/mutex. Yeah context switching doesn't potentially happen at every assembly instruction, the granularity is much higher, but it is still there.

<comment><USER8> There's some need to synchronize, but hot damn is it simpler when you're dealing with sensible blocks of high-level statements than when you're dealing with out-of-order parts of assembly instructions.

<comment><USER9> That's true, but personally I still don't find this model ideal because the synchronization points are implicit. The cleanest concept I know of for dealing with synchronization is transactions.

</comment></comment></comment></comment></comment></comment><comment><USER10> This sums up quite a lot about Lisps in general. I'm amazed OP got so fast to this "insight" :)

        (And this is probably Lisp's greatest weakness as well – with this level of
        possible diversity, everyone has to use the "common lowest denominator"
        simply because nobody can agree on what alternative syntax / library / etc.
        is better and should be used.)

        Off-topic: it's not enough to give everyone opportunity to improve the
        language; you have to choose the winners and promote them heavily. The rules
        of free market don't work here; people won't use the best thing, they'll use
        the one which is available out of the box and which is used by their peers.

<comment><USER11> I dream of a modular language in which languages, or _dialects_ , can be built from a small base language, which can then be extended, and so on. Of the languages that I've seen, Racket looks the most promising. Forth might be good for this, too, but to build large hierarchies of languages seems the antithesis of Forth - or at least, Chuck Moore's - philosophy.

On the other hand, such a language might just end up as an incredibly fragmented mess of different languages, with little interoperability between languages - some one makes a 'typed' version of the language, another takes that version and tunes it just enough for it to be incompatible with the original version and, in turn, all languages that are built on top of that original typed language, and so on.

Maybe incredible modularity is fundamentally at odds with (social) interoperability.

<comment><USER12> It's ironic that Haskell _is_ such a language: it grows from a tight, small core into larger and greater abilities as you learn it even without using its extensions.

I agree that Common Lisp a very powerful language, but I can't live with all that power uncontrollably thrown on me. Common Lisp grossly lacks self- discipline and self-limitation when it's needed.

<comment><USER13> I suspect the parent thread was dreaming of a framework where languages with arbitrary syntax can be mixed and matched in user-defined ways.

Haskell isn't necessarily that language, partly because it still requires centralized coordination of development of these "extensions" to ensure they're interoperable - that is, there is only one _parser_ for the language and its supported extensions, and many of them are build into the compiler rather than added as libraries, except those extensions which are done through quasi-quotation, such as with MetaHaskell, or some EDSL. Even that has it's own problems, and you'll have issues parsing if your quoted language happens to have delimiters which conflict with Haskell's quasiquoting delimiters `[| |]` - producing syntax which cannot be parsed unambiguously (perhaps very rare or unlikely though).

Perhaps the biggest hurdle of having a modular language is that we do not understand how unambiguously parse the combination of two or more syntaxes. We only know that composition of two CFGs results in another CFG, but with no guarantee of unambiguity, and other parsers such as PEG rely on ordered choice, where the computer can't decide which choice you really want.

What makes lisps great for composition of languages (or "EDSLs" in market speak), is that it bypasses the parsing problem by asking you to just write your language directly in terms of the syntax tree which a parser would generate - and perhaps use macros or other functions to simplify the use of that tree. Instead of a language being vocabulary+syntax, we create new vocabulary for what would be done through syntax in other languages - and we can thus refer to it unambiguously. Similar can be done in haskell too, through regular functions and quotation.

The parse problem is only really a problem because we're stuck with this silly model of "sequential text files" to describe code, and we're required to limit our languages such that a parser can take one of these text files and make sense of it. When we break out of this model, and use intelligent editors, we can reach the point where syntaxes can be composed arbitrarily, because we can indicate where each new syntax begins and ends. Diekmann and Tratt have demonstrated how this can be done while still appearing much like traditional text editing, which they call Language Boxes.[1][2]

Language Boxes only provide the means to compose syntaxes, but handling the semantic composition of languages is left to the authors of the languages which are being composed. Haskell is perhaps a good choice of language for providing the kind of glue needed here, where we can decide where languages can be composed based on the types returned by their parsers.

[1]:[https://www.youtube.com/watch?v=LMzrTb22Ot8](https://www.youtube.com/watch?v=LMzrTb22Ot8), [2]:[http://lukasdiekmann.com/pubs/diekmann_tratt__parsing_compos...](http://lukasdiekmann.com/pubs/diekmann_tratt__parsing_composed_grammars_with_language_boxes.pdf)

<comment><USER14> I don't think the problem stops at syntax. It's possibly an even bigger issue that mixing different language semantics can be awkward. As a big obvious example, a language where all objects are nullable will interface awkwardly with one that only has option types. Similarly, interfacing with something like Smalltalk (which uses methods for flow control) or Forth (which…is Forth) would be awkward from a language that's more like C++.

Even in an environment like the JVM which specifies a lot of stuff for you, it's awkward to call into Clojure from Java because of the semantic differences.

<comment><USER13> I wasn't implying there is no problem with the semantics, just that it's much easier to deal with when you already have the parsed trees, because they're easier to reason about with code - and we can project them unambiguously.

We already do write tools for such language interoperability for specific pairs of languages, which is often really awkward because it requires us to re-implement the parsers, and only deals with entire code files rather than specific productions in the syntax.

It's pointless composing languages unless it makes sense semantically, which would need to be done on a per-language basis (or per-production rule), which is where I was hinting with using Haskell as the glue for such interoperability - because if we encode the semantics into the type system, such that one syntax expects a language box of type T in it's grammar, then one should be able to use any other language whose parser returns a T, and the semantics will be well-defined for it.

It could also provide the glue for converting between nullable types and option types for example too, by requiring that a language returning a "Nullable T" be wrapped in some function "ToOption", which converts "Nullable T" into "Option T". Attempting to use the Nullable where an Option is expected would fail to parse. How ToOption is implemented is left to the author of the code.

It's much easier to have interoperability between individual production rules in different languages (which share many parts in common) versus "whole text files" which we currently have, which basically require the languages be almost equivalent to convert between them.

Also as a result of storing the semantic information as opposed to sequential text, it would be possible for the user to chose his preferred syntax for any semantic elements in the tree, since they're just working on a pretty-printed version. Most of the concerns about "code style" disappear because they're detatched from the actual meaning that is stored.

</comment></comment></comment></comment></comment></comment><comment><USER15> Is this... a Let's Play of learning a programming language? Because it's surprisingly effective. I learned and I was entertained.

<comment><USER16> I would definitely watch a video series in which an experienced and talented programmer tried out various programming languages for an hour and gave first impressions, comparisons, etc as they hacked something together during the video.

<comment><USER17> The idea of a twitch.tv stream sounds interesting, with viewers throwing small problems at the coder to solve as they fumble around with a new language.

<comment><USER18> In this vein I've been pondering doing a livestream of a LFS install for a while, just for funsies. I wonder if anyone would actually watch it.

<comment><USER19> I'd watch it!

</comment></comment></comment></comment></comment><comment><USER20> As others have said, this does justice to the idea of actually learning a new language...or perhaps because it is Racket a new family or ecosystem of languages. Anyway, if you're still curious about pairs verus lists and why anyone would use dotted pairs, I like to think about it as where Lisps show that they are from the age when running close to the metal was a given.

And it all goes back to _car_ and _cdr_ and the fact that they are (or rather were) embedded assembly language and there to give raw access to Lisp's linked memory model (as opposed to the sequential memory model of Fortran). A dotted pair has two efficiency advantages over a proper list and both stem from the fact that the last cell of the last pair of a proper list contains 'nil (or 'null in Racket).

Storing two values in a proper list requires two cons cells - the first with the first value and a pointer to the second cons cell and a second cons cell containing the second value and a null pointer. In contrast, a dotted pair holds two values in a single cons cell - halving the memory requirement.

The second advantage is that when there are only two values there's no need to walk the list and test for 'null (or 'nil) on the _cdr_. This saves an instruction step.

Philosophically, dotted pairs allow for _car_ and _cdr_ to be used symmetrically. Calling _cdr_ on a dotted pair returns the second value directly just as calling _car_ on any list returns the first value directly. Lastly, one of the things that is awesome about Lisp is the way in which lists can model data structures, and in the case of a dotted pairs their efficiencies are available to all those structures which consist of or rely on paired values.

Of course, this may be obvious and on a machine with 10+ GB of RAM not really applicable, but I find it fun to think about anyway.

<comment><USER21> My question is, given the cons pair is not a meaningful primitive datatype to modern CPUs (can't fit in a register unless you're using 32 bit atoms on a 64 bit CPU, the individual cells cannot be meaningfully manipulated while packed into a single register even in that case...), is there a good reason to use an unrestricted pair/2-tuple/2 element vector for the sexp representation? Would it be "wrong" to remove dotted pair notation and make sexps a restricted type whose cdr could only be another pair or the empty list? You'd have to give up alists, but those would probably be better served by doing as Clojure does and introducing a hash table syntax.

Other than alists, simplifying the implementation[1], and tradition, I can't think of a good reason to keep improper lists and dotted pair notation around. They aren't really that useful, confuse newcomers, and encourage the use of inefficient data structures. I haven't written much Lisp, but when I see a dotted pair (usually in the context of an alist or some hideous approximation of a struct[2]), it comes across as a "code smell" to me, like "this person is taking SICP too literally."

[1] You pay for extra reader syntax, but gain uniformity in your treatment of the car and cdr cells. On the other hand, maybe you could optimize the cdr cell a bit if it only needed to address pairs and not arbitrary atoms.

[2]

      ;; barfage
      (define (make-thing a b c) (cons a (cons b c))) ; barf
      (define (thing-field-a x) (car x))
      (define (thing-field-b x) (cadr x))
      (define (thing-field-c x) (cddr x)) ; more barf

<comment><USER20> Going a little Abelson&Sussman, the utility of _cons_ persists because it is a powerful abstraction. Fitting into registers was, as a scholastic might say, an as accidental feature as the input line voltage of a toaster [110 @ 60Hz makes things easier in this part of the world but isn't intrinsic to making crisp English muffins].

 _cons_ is useful for dealing with linked memory structures, including singlely linked lists and particularly singly linked lists where the stored value in each list element is a pointer because it abstracts over all the pointers. Writing code to process and manipulate and pass pointers is idiomatic in C. Using pointers is idiomatic Lisp.

Your barfing code shows why _cdr_ and _car_ persist. They are also powerful abstractions due to their rules of combination and probably because their rules of combination aren't constrained by a bias toward English language. There ain't no synonyms for "caddr" and "cdddr" in English or Python.

The idea that lists should be everywhere replaced by structs is assembly in any language thinking (also known as C). Lists provide a standard interface. Each struct definition creates a new data type.

 _It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures._ Alan J. Perlis, Epigram 9.

<comment><USER14> I think the question is more along the lines of "Should the core data type be the cons cell rather than the list?" Clojure takes the approach the GP was talking about. It has lists with heads and tails, but it does not have dotted pairs. The tail of a list is always a list.

</comment></comment></comment></comment><comment><USER22> I like the approach you took to writing this post. This wasn't the typical attempt to summarize an entire programming language in a page (which IMO is done too often, too poorly), but rather an exploration. As you went through each section, I could see how you were approaching various problems and learned a lot about Racket in the process. I would love to see more of this style of post.

<comment><USER23> Of course I couldn't summarize Racket in a page – I don't know it! And there's _so_ much to learn about it that I could probably write half a hundred posts of this length and still consider myself a beginner.

</comment></comment><comment><USER24> This is how I usually implemented quicksort in Racket:

        (define (quicksort xs)
        (if (null? xs)
        xs
        (let*
            ([hd (car xs)]
             [tail (cdr xs)]
             [smaller (filter (lambda (x) (< x hd)) tail)]
             [bigger (filter (lambda (x) (>= x hd)) tail)])
          (append (quicksort smaller) (list hd) (quicksort bigger))))

It's great to see a hugely superior implementation, and I love that people are writing about and using Racket like this because the more people do that the more resources there will be for people like me to learn from.

</comment><comment><USER25> I love Scheme. And I love Clojure, which is IMHO Scheme plus some great ideas from Haskell.

I regret there's no Scheme or Clojure running on LLVM, which I think is a much better platform than the JVM. Julia, that resembles Dylan (another Lisp), is the perfect example.

<comment><USER26> I too wish there was such a thing as a JIT compiled Clojure on LLVM. The JVM is amazing but it only seems to be amazing for long running processes. LLVM, IMO, is far more versatile in its amazingness.

<comment><USER27> There was an attempt at it, [https://github.com/halgari/clojure- metal](https://github.com/halgari/clojure-metal)

</comment></comment></comment><comment><USER28> That was intellectually honest. Good read.

</comment><comment><USER29> It seems as if several of the author's problems come, oddly for someone who's used both strict (Pascal) and non-strict (Haskell) langauges, from being confused about Racket's strictness. Why is time a special form? Because otherwise (time (expensive)) would just get the result of (expensive). Why doesn't (list 1 (2 3) 4) work? Because list isn't a special form, it's a function. Why doesn't quote turn '(list 1 2 3) into '(1 2 3)? (Well, this one isn't about evaluation order, admittedly.) Because if it did it ... wouldn't be quote.

<comment><USER23> Pascal is strict, but it still has stuff like "move(var1, var2)", out parameters, etc., so it's also call-by-reference.

I didn't know at the time that Racket was call-by-value.

Quote was confusing at first, yes.

</comment></comment><comment><USER30> A friend of a friend has considerably code in Scheme, Common Lisp and Clojure, when you ask him which is the true Lisp, guess what will he answer? Haskell!

Haskell does really create a big impact on some developers.

Just an anecdote ;)

<comment><USER8> I think it can't be "the true Lisp" without cleaner macros. Of course, that doesn't stop Haskell from being a great Haskell.

<comment><USER31> I do prefer Racket macros to Template Haskell, but you can do some of the same kind of things in Template Haskell. Go ahead and play with it for it for a bit.

Mostly, you need to have the data-structure it defines for the parse tree, and it's harder to convert than syntax->datum. Also there's the Q monad, to generate new safe names. But it works pretty well.

<comment><USER8> I'm not sure there's anything you _can 't_ do in TH, but it feels messier than Lisp macros. I'm hoping typed TH will improve things (not in precisely the same direction as lisp, of course).

</comment></comment></comment></comment><comment><USER32> One note:

> Racket's default IDE is better than GHCi and probably on par with Emacs (you > almost certainly can configure Emacs to be better than anything, but it's > not trivial and people don't bother, while DrRacket provides autocompletion > and documentation out of the box).

Last I used it (a few years ago), DrRacket was very laggy, so I would find it very hard to use for a serious project. YMMV, maybe it's improved.

<comment><USER20> I find DrRacket sufficiently fast and sufficiently frustrating.

It's very useful for interactive debugging but dependent on the mouse and many Emacs key combinations simply cannot be mapped because of it's CUA interface...and so far as I can tell there is no key-combination that switches focus between the REPL pane and the Editor pane short of closing the other pane.

The syntax analysis gets to be a bit much too.

On the other hand, that's just the price of an IDE over a text editor, and for a batteries included IDE, it's pretty good even if I wish that the effort would have been put into Emacs support while knowing that doing so would not meet the needs of the PLT group's target audience of students.

<comment><USER33> I think you can switch panes with C-x C-o, same as the Emacs combo.

<comment><USER34> That's C-x o; C-x C-o in Emacs runs delete-blank-lines, and I'm not sure what it does in DrRacket.

</comment></comment></comment></comment><comment><USER35> I love the play by play of exactly what you're thinking as you're doing something new. I find them quite informative.

</comment><comment><USER36> Web apps are a hack on a hack, yes. But it's kind of ironic he hates Javascript so much when Javascript is a pretty cool programming language heavily influenced by Scheme, which is awfully similar to Racket.

But hey, I like people who call it like they see it, and there certainly are some drawbacks to Javascript too.

<comment><USER37> Javascript is a pretty cool programming language heavily influenced by Scheme. -> I couldn't agree with you more.

There is a Lisp-to-JS compiler (ParenJS). [https://bitbucket.org/ktg/parenjs](https://bitbucket.org/ktg/parenjs)

</comment></comment><comment><USER38> he will be amazed when he discovers custodians. [http://docs.racket- lang.org/reference/eval-model.html#%28par...](http://docs.racket- lang.org/reference/eval-model.html#%28part._custodian-model%29)

<comment><USER39> There are many cool features that Racket has out of the box, like very nice module system, delimited continuations, objects and classes and of course macros (both hygienic define-syntax-rule, syntax-case and unhygienic defmacro) and more.

But if I had to show one feature of Racked to make someone amazed, it wouldn't be any of those. It would be a simple program composed of a couple of files, and every file would start with different #lang. Like #lang racket, #lang lazy, #lang typed/racket, #lang datalog.

It's sufficiently mind-blowing that there are this many languages on top of Racket, but the real "killer app" is how seamlessly they integrate with each other.

The next thing I'd show would probably be Danny Yoo tutorial on how _you_ can create even more languages like this: [http://hashcollision.org/brainfudge/](http://hashcollision.org/brainfudge/)

<comment><USER25> It's almost like a practical Mozart/Oz with all Lisp awesomeness. CTM shows how programming with many different paradigms can be extremely powerful.

</comment></comment></comment><comment><USER40> "Someone who knows Haskell learns some Racket"

"Tonight at 11: this rose gardener learns to plant tulips"

<comment><USER23> Which is exactly why I was very surprised when it got posted to Reddit and wasn't immediately downvoted.

</comment></comment><comment><USER41> Nicely written, and a fun exploration.</comment>


Show HN: Bradezone News – a speedy treemap display of Google News - <AUTHOR> http://news.bradezone.com/

<comment><AUTHOR> I've always enjoyed Newsmap.jp, but it uses Flash, is kinda slow, and seems out of sync with what actually appears on Google News. So I built a super-fast version that uses D3.js for data viz. Hope you enjoy!</comment>


Measuring customer satisfaction - <AUTHOR> https://hiverhq.com/blog/measuring-customer-satisfaction/?y=yc <comment><USER2> This may seem overly picky, but this really is just a list of ways to measure customer satisfaction, with next to no commentary on why you might focus on one, or which ones are valid.</comment>


Show HN: Snapp – Windows-Like Window Snapping for OS X - <AUTHOR> https://github.com/gbrueckner/Snapp <comment><USER2> Awesome! I was looking for something like this a little while ago and ended up using better touch tool, which does a lot of other things in addition to window snapping, but all I wanted was the window snapping.

I noticed that it doesn't want to maximize the window when I have an external display set up to be stacked above my laptop display. That's my default setup so I won't be able to use it, but still neat!

<comment><AUTHOR> Hey Alex, thanks for trying Snapp!

> I noticed that it doesn't want to maximize the window when I have an > external display set up to be stacked above my laptop display.

Do I understand correctly that you are trying to maximize the window on your laptop display? If so, I just tried this myself: the mouse has to be dragged into the topmost row of pixels of the display, which is not very practical if the mouse can move further up onto your external display...

Maybe it would be better if the window was maximized when the mouse is dragged into the upper half of the menubar, not just the topmost row of pixels?

<comment><USER2> Yea exactly! That sounds like a good solution

</comment></comment></comment><comment><USER3> Lovely. I would like to see more attempt at window manager for OS X. Currently Amethyst is working well for me.

<comment><AUTHOR> I wonder why Apple doesn't simply implement the same window snapping as Windows and most Linuxes - it has pretty much become a standard UI metaphor.

Instead, they built Split View, which I think isn't very intuitive.

</comment></comment><comment><USER4> Very cool -- tremendously useful, thank you!</comment>


Tech News Site Received Death and Rape Threats  - <AUTHOR> http://arabcrunch.com/2012/01/arabcrunch-team-member-received-death-and-rape-threats.html

<comment><AUTHOR> The site was offered bribes from the US government shortly after it exposed sourceforge blocking of syria, sudan, cuba, iran and n. korea [http://acleaks.blogspot.com/2011/12/leaked-email-us-state- de...](http://acleaks.blogspot.com/2011/12/leaked-email-us-state-department- offers.html)</comment>


How to read Korean in 15 minutes - <AUTHOR> http://ryanestradadotcom.tumblr.com/post/20461267965#notes <comment><USER2> People overestimate the difficulty in learning different alphabets (and the assumed difficulty of the languages which use them).

I'm on vacation in Israel this week and learned the Hebrew alphabet with standard flash cards in 2 hours (incidentally by doing something similar to this post by remembering the names based on something the character looks like). At various points I've learned the Arabic, Cyrillic and Greek alphabets in a similar amount of time.

The real difficulty is, naturally, actually learning the language. The additional burden of it using a separate regular alphabet is negligible in comparison.

<comment><USER3> Agreed. When you don't know the language, knowing the alphabet is pretty useless. In Israel I recall being able to read signs.. and have no idea what I was actually reading.

On the other hand you do have languages like Chinese where learning the written language actually is the majority of the work. Spoken Chinese is probably one of the easier languages out there for a person coming from a random language.

<comment><USER4> > _When you don't know the language, knowing the alphabet is pretty useless._

Knowing the Japanese hiragana and katakana means you can work out some menus in Japanese games - "startu"; "opshun"; etc. (This is not romaji, because they're using English words and a Japanese alphabet. So what's that called?)

<comment><USER5> Careful with gairaigo. Most of the time it doesn't mean what you think it means. Ever seen an ad for a mansion? In Japanese that refers to a type of apartment. I challenge anyone who has no prior knowledge to guess what 'Delivery Health' means.

<comment><USER6> Transliterated English is actually very useful for learning Korean, even if the meaning is a little twisted sometimes. Fully 25% of my Korean knowledge is transliterated English. It helps that Korea is probably the country with the highest English-fever in Asia.

<comment><USER7> It also helps with being able to read menus and direction signs and such as the transliteration into English can be spotty.

</comment></comment></comment></comment></comment></comment><comment><USER8> Wow. That is really neat.

I've always believed that spoken languages that are constructed/contrived are doomed to failure (esperanto, klingon, etc). I'm not saying that Korean itself is contrived, but it's fascinating that the alphabet was created like that.

<comment><USER9> The Cyrillic script[1] and the Armenian alphabet[2] were also devised in similar fashion, and probably many more. It is not unusual for writing systems or alphabets to find widespread usage in this manner.

[1]<http://en.wikipedia.org/wiki/Cyrillic_script#History>

[2][http://en.wikipedia.org/wiki/Armenian_alphabet#History_and_d...](http://en.wikipedia.org/wiki/Armenian_alphabet#History_and_development)

<comment><USER10> The Canadian Aboriginal Syllabics is another one. It was developed by a missionary that noticed that when aboriginal where written in latin script the result was often long and awkward.

<http://en.wikipedia.org/wiki/Canadian_Aboriginal_syllabics>

</comment></comment></comment><comment><USER11> Having an alphabet, as it does, Korean indeed isn't hard to learn to read and write. The difficulty is learning how to pronounce it properly—it has a number of distinct consonants that are treated as the same consonant in most other languages and that therefore are extremely difficult for non-native speakers to distinguish and produce properly.

For example, it has three distinct unvoiced velar stops [1] which are all considered the same sound in English: normal [k], aspirated [kʰ], and faucalized [k͈].

We use both the normal and aspirated [2] unvoiced velar stops in English as positional allophones [3], meaning we consider them the same sound but they're actually different and we distinguish between them unconsciously depending on where the sound occurs in a word. For example, /k/ is aspirated in word- initial position in words like _cam_ but unaspirated after word-initial /s/ in words like _scam_. If you listen closely enough you realize that you turbulently expire a lot of air after the _c_ in _cam_ but don't do so in _scam_. Despite using both phones [4] in English, you consider them more or less the same hard _k_ sound—if you pronounce _cam_ with an unaspirated /k/ it may sound slightly odd but you'll still consider it the same word _cam_. The problem is that in Korean doing so would result in two different words—so it makes it hard for English speakers to perceive distinct words in Korean that differ this way, and to pronounce the correct word that they intend when talking.

This is true for many languages because phoneme inventories never overlap, but it's especially difficult for English learners of Korean because Korean has a third /k/ sound—the faucalized [5] one—and it doesn't occur at all in English. I know phonologists—people who are trained in the study of human speech categories—who have an extremely difficult time discerning between [k] and [k͈].

Peter Ladefoged, one of the world's foremost phoneticians, has a fantastic website to accompany his phonetics textbook and it has recordings of all the sounds known to be produced in human languages. You can listen to the distinctions between the Korean consonants here:

[http://phonetics.ucla.edu/appendix/languages/korean/korean.h...](http://phonetics.ucla.edu/appendix/languages/korean/korean.html)

The /k/ sounds I've been discussing are the third row down ( _weight of measure_ , _rope_ , and _large_ ). As an English speaker try to hear a difference between how the consonant is pronounced—it's extremely difficult to notice.

Our sensitivity to these phonemic distinctions develops at an extremely early age: by one month old infants already begin to stop distinguishing between different sounds that their language slots into the same category as the same "sound" [6]. Infants don't even babble at this age never mind produce or understand adult speech, but they have already stopped noticing certain differences in speech—that's how deeply ingrained the way we perceive and produce speech is, and why it's almost impossible to speak a non-native language without an accent.

(I am only tangentially familiar with Korean phonology so I might be getting some of the details slightly wrong here—please correct me if I've misstated anything.)

###

[1] <http://en.wikipedia.org/wiki/Unvoiced_velar_stop>

[2] <http://en.wikipedia.org/wiki/Aspirated_consonant>

[3] <http://en.wikipedia.org/wiki/Allophone>

[4] <http://en.wikipedia.org/wiki/Phone_(phonetics)>

[5] <http://en.wikipedia.org/wiki/Faucalized_voice>

[6] <http://www.sciencemag.org/content/171/3968/303> & [http://home.fau.edu/lewkowic/web/Eimas%20infant%20speech%20d...](http://home.fau.edu/lewkowic/web/Eimas%20infant%20speech%20discrim%20Science%201971.pdf)

<comment><USER12> I am afraid this will be a trivial question now, but does that mean that Korean pronunciation is much harder to learn than Japanese? I often heard that they are very similar languages, and they can certainly sound similar to the uninitiated.

<comment><USER11> Japanese and Korean are actually not phylogenically related. In fact they're both generally considered to be language isolates, which means they don't seem to be related to any other languages. This may not be strictly true and there are proposals that there could be a link through a hypothetical language family called Altaic—they're usually considered unrelated, though.

The "difficulty" of learning any particular language in relation to another is a bit of a meaningless comparison in my opinion. Ultimately, it appears to be the case that all human languages operate according to a common underlying linguistic mechanism—the seeming differences between particular languages are in fact probably actually just different surface realizations of the underlying mechanism with particular options twiddled in various combinations coupled with an idiosyncratic lexicon (i.e., a relatively unique but ultimately arbitrary vocabulary). The nature of the underlying mechanism is the subject of debate, as well as the list of the particular options available, but it seems pretty clear that all languages are utilizing a common underlying cognitive architecture.

That being said, it would seem to me if you define a relative acquisition difficulty metric as something like

      D(x, y) = a*O(x, y) + b*P(x, y) + c*L(y) - d*C(x, y)

      O(x, y) = cardinality of the set of differences between the language "settings" of x and y
      P(x, y) = cardinality of the set of phonemic distinctions present in y but not x
      L(x)    = cardinality of the lexicon of x
      C(x, y) = cardinality of the set of cognates shared by the lexicons of x and y

where _a_ , _b_ , _c_ , and _d_ are scaling factors, then that might give you some semi-reasonable rough correlation in the form of a "distance" between two languages along various axes. The exact definition of _O_ ( _x_ , _y_ ) is far from clear, however. And even just having knocked this out I'm realizing that there's almost an infinite number of other things you could throw in here that you would arguably need to know to claim to have "learned" a language: phonological processes, knowledge of and relative productivity of morphological processes, pragmatics, etc. This is why I'm of the mind that any such measure is of dubious utility, because you would need to take into account a lot of factors—most of which we still don't fully understand.

There's probably work done on this somewhere but second language acquisition isn't my area of expertise.

<comment><USER13> First of all, Korean and Japanese _are_ very similar. They're in different language families because they are not believed to have been evolutionarily related (more closely than other languages in other families), but they are in fact incredibly similar. This might be partly a result of tons of historical contact between Korea and Japan and/or of both sending scholars to China in ancient times, but the mechanism of their coevolution had to be more involved than that. I don't know enough about it, and I'm not sure if linguists do either. However, the fact remains that the two languages in their current forms are closely related, which is what gurkendoktor was asking about in regards to learning time. While the closed class words and inflectional suffixes don't have related pronunciation, the general structure of the languages are ridiculously similar. Word order is identical in many sentences, both use particles or postpositions to mark the function of nouns, both use topics instead of subjects, both allow you to omit the topic if it can be inferred through context, both have a respect hierarchy built into the grammar, both have tons of pronouns and related categories of family words, both have the adversative passive of Chinese, both are agglutinative in the sense that they allow you to add a noun after a verb phrase to form a relative clause that modifies the noun, both have lots of similarly-pronounced Chinese- derived open class words, both have the rare alveolo-palatal fricatives and affricates in their sound inventories as is found in Mandarin, both make the /h/ consonant a voiceless palatal fricative before [i] or [j], etc. Those are just the similarities I can think of off the top of my head. I don't know much Korean, but I'm sure there are a lot more similarities.

As for pronunciation difficulty, I can tell you that from the standpoint of a native speaker of American English who can also articulate every consonant and vowel in Mandarin Chinese, Japanese phonology is far easier for me than Korean phonology. Japanese really only has one consonant whose place of articulation doesn't exist in English or Mandarin (a voiceless bilabial fricative, which is essentially an /f/ but with two lips instead of the bottom lip against the upper teeth) and five monophthong vowels (their position in the mouth stays the same for the duration of the sound), most of which are pretty standard among languages whose vowels are monophthongs. While Japanese does have pitch accent, so does Korean, and unlike Chinese, pitch almost never affects the meaning of a word in the Japanese spoken in Tokyo (there are a couple exceptions) or in the Korean spoken in Seoul. If you want to sound native, you'll have to spend about the same amount of time in either language learning the pitch contour of each word.

Korean on the other hand has more vowels than Japanese, one of which is now pronounced as a diphthong that is very difficult for most English speakers to pronounce correctly (although it's easy for anyone who knows French and easy enough for anyone who can pronounce /y/). The real issue is that Korean has those tense consonants whose specific manner of articulation doesn't exist in any other language. It's the one part of Korean phonology I do not pronounce correctly. Interestingly, I just came across this on Wikipedia:

'An alternative analysis[2] proposes that the "tensed" series of sounds are (fundamentally) regular voiceless, unaspirated consonants; that the "laxed" sounds are voiced consonants which become devoiced initially; and that the primary distinguishing feature between word-initial "laxed" and "tensed" consonants is that initial laxed sounds cause the following vowel to assume a low-to-high pitch contour – a feature reportedly associated with voiced consonants in many Asian languages – whereas tensed (and also aspirated) consonants are associated with a uniformly high pitch.'

So maybe there is hope for us non-Koreans! But yeah, Korean pronunciation is more difficult for most native speakers of English. Also, the grammar requires a little more memorization than Japanese does since there are more inflectional forms in Korean. On the other hand, the Korean writing system is far simpler than that of Japanese since Koreans don't really use Chinese characters anymore at all. It might also take you a few hours or days longer to learn the Japanese syllabaries than the Korean alphabet. As this thread shows, it's incredibly easy to learn to read and write Hangeul.

</comment></comment></comment></comment><comment><USER14> This is why I love Hacker News. Even though this doesn't really have anything to do with startups or technology in general, it's still something that interests the types of people who read Hacker News. One of the big reasons I love HN is the community that contributes to it.

</comment><comment><USER15> I've just returned from a 15 days trip to Korea. Being able to read Hangul was helpful, especially when trying to read menus, but in most places, road and subway signs were bilingual (English & Korean). In many ways, the country seemed to be light years ahead of other places (I'm from Switzerland).

By the way, Korea is absolutely worth a visit. I think I'm infatuated with it right now. In the short time I got to know a couple of very wonderful people.

<comment><USER16> Did you know the meaning of the words that you translated from writings to "words"? I mean, I could read korean letters and words if I know the alphabet (somewhat) but I dont know what it means anyways.

<comment><USER7> There's a surprising amount that's in English, and survival words are relatively simple.

e.g. 화장실 - bathroom. You don't need to make a complicated sentence when asking where one is. Just 화장실? is enough and everybody knows you're a foreigner anyways and will know what you mean.

Hello, goodbye, thank you, your welcome, are similarly easy.

Food words are relatively simple and regular and if you drink alcohol there's relatively few to learn about.

</comment></comment></comment><comment><USER17> Hindi is also a pretty straightforward language; by which I mean that the written alphabet corresponds _exactly_ to the sounds made when speaking it. When I was in Korea, I used to write korean words in hindi (I did not know the korean alphabet then) because transliterating to english would screw up the pronunciation and unless you get the pronunciation exactly right, the locals just don't understand what you are saying.

<comment><USER11> Hey, would you be kind enough to email me? My address is in my profile. I've been looking for a Hindi speaker of Korean for a while. I'd love to ask you a few questions if you have a moment!

</comment></comment><comment><USER18> I put together a cheat sheet a while ago:

<http://www.flickr.com/photos/spullara/2629936/>

Not as entertaining but tries to show you how the various parts are derived from one another. Interesting that n is half of m.

</comment><comment><USER19> Cool! 15 minutes sounds about right. I learned it over a single pint on my last trip to Seoul. I can tell you navigating the city becomes easier when you start to understand signs like _megchu_ (beer) and _tsikin_ (chicken) :-)

(sorry for the quick transliterations)

</comment><comment><USER20> I am not familiar with many languages, but something that is unique about Korean "alphabets" is that alphabets combine to form a character.

This makes sentences more compact in appearance, but it also creates difficulty in creating fonts, since a single alphabet looks slightly different in combination with different alphabets. (For example, Gulim font, a standard sans-serif font, contains 49,284 glyphs according to this Wikipedia article: <http://en.wikipedia.org/wiki/New_Gulim.>)

<comment><USER21> According to the web page, New Gulim includes all of CJK, for Koreans this means Hanja, which are thousands of Chinese characters that haven't really been used to write Korean since the 19th century.

The actual Hangul (Korean syllabary) characters require about 30 consonants/clusters and 21 vowels/dipthongs which can appear in characters in 9 different layouts. It's much more work than the 26 latin characters, but most of the font design is going to be copy/paste.

So you could say the purpose of New Gulim is not to create a "Korean font" in the sense that a font you can write Korean with, but rather the sense that Koreans can use it to write Korean mixed with Latin, Chinese, Japanese, Cyrillic, and Greek characters with a unified design _between scripts_. That's a tall order.

<comment><USER22> > It's much more work than the 26 latin characters, but most of the font > design is going to be copy/paste.

Not quite. While the minimal Hangul font design requires two sets of initial consonants, one set of vowels and two sets of final consonants (often called 2x1x2), it would be very quirky. Many bitmap fonts used the 8x4x8 design or its variant, the commercially available TrueType/OpenType fonts now have more than 30 sets of subtly differing glyphs. It is easier than drawing all 11,172+ glyphs but not much.

<comment><USER21> But you would still copy/paste to create subtly different glyphs, right? Just like I can copy and paste parts of Han characters to make 村 校 林 枚 様 機 横 (look at the left half), with slight modifications as necessary. (At a quick glance, I suspect the font I use has four variations of the 木 radical among those seven characters).

<comment><USER22> Right. Even worse, a grass radical (艸/艹) has more than several dozens of possible glyphs.

</comment></comment></comment></comment></comment><comment><USER23> The other thing interesting about the Korean alphabet is that the symbols take "notches" also have the same mouth formation. The notch is an indication to use the same mouth shape, but to use a "harder" sound. So the G sound and K sound have a similar mouth shape, as well as the D sound and the T sound, the J and CH sounds.

My understanding, also, is that there are no exceptions to the rules, so it makes it very easy to read and write, which is awesome.

<comment> guard-of-terra There are some exceptions. 입니다 is [imnida]. Complex vowels can be produced in various ways. There are dialectal things too, so I've heard.

Still it is very straightforward.

<comment><USER24> Another exception is 시 being pronounced [shi].

<comment> guard-of-terra That's no more exception than st in german being pronounced [scht].

"It doesn't produce minimal pairs".

<comment><USER24> Whenever pronunciation of a letter depends on the surrounding context, you have an exception.

<comment> guard-of-terra There is no way for a pronunciation to not depend on the surrounding context. You do not spell words letter by letter.

Thus minimal pairs are the king.

</comment></comment></comment></comment></comment></comment><comment> throwaway54-762 Yup. I happen to be an American, English-only speaker, and a friend was able to teach me the Korean alphabet during highschool AP chemistry (oh, and I still managed to get a 5 on the exam). It's really that easy.

<comment> guard-of-terra Most alphabets are trivial. It is only latin that tends to be hard, especially french or english latin (german to lesser intent), because of loose correlation between letters and sounds.

Cyrillic is pretty straightforward, for example.

<comment><USER25> I wouldn't put English and French in the same category of phoneticism. English is all over the place[1], French pronunciation is fairly systematic.

[1] Not that that's in any way surprising, considering its messy Saxon-Norman- Viking-... history.

<comment><USER26> Ideally there is a one-to-one mapping between text and speech. To me at least French is more difficult in thespeech-to-text direction (because of all those mute letters at the end of most words esp. verb forms that sound the same parler, parlez, parlais, parlaient, parlai, parlé) while English is more difficult in the text-to-speech

<comment><USER25> This is definitely true, though not such a big deal for basic understanding in practice, as the near-homophones usually have only subtly different meanings. I also don't often find myself having to transcribe stuff, and if I do, I can usually ask the speaker to check my spelling. On the other hand, reading something and immediately being able to pronounce it with some accuracy is very helpful, but attempting that with English words and especially names ("Cholmondeley" anyone?) often leads to unintentionally bizarre results.

(FWIW I speak English to a level that native speakers can't tell it's not my first language unless I trip over words I only know from reading - People ask me, "so where in England are you from" all the time. My French is just about passable - I can get by for basic everyday conversations as long as the other person doesn't speak too fast and they don't mind explaining/rephrasing the occasional sentence. I'd agree that perfecting your French is a lot harder than perfecting your English despite what I've said above.)

</comment></comment></comment></comment></comment><comment><USER27> There is a similar guide to hangul with information arranged in the shape of the periodic table of elements, the "periodic table of hangul": <http://www.aboutletters.com/pfaq.html>. I found it to be a reasonably handy reference that logically compiles all the information in one image as opposed to this guide's gradual introduction of vowels and consonants mixed in batches.

The author no longer authorizes distribution of the image over the internet, however copies can be found with a google search.

</comment><comment><USER28> Well this explains how my Korean friend in college could type touch type in Korean and English on an American keyboard. I didn't know that Korean had an alphabet, I thought it was pictograms or whatever.

<comment><USER29> Modern Korean has 24 alphabets, plus 2 letters (ㅐ,ㅔ) each of which is technically a combination of two other letters but usually treated as a single letter. Guess how many keys the American keyboard reserves for English alphabets? 26. No need to shift keys around or rely on complicated modifier keys, unlike even some European keyboards.

Korean alphabet + American keyboard = a match made in heaven.

</comment></comment><comment><USER30> Some scripts are surprisingly easy to pick up. If anyone is interested in the Japanese scripts (hiragana/katakan), this book[1] will truly teach them to you in 6 hours, total. I started reading it, and thought it moronic, but as I started writing a review of why it sucked, I realised that I could recall everything perfectly...

1: [http://www.amazon.com/Remembering-Kana-Reading-Japanese- Syll...](http://www.amazon.com/Remembering-Kana-Reading-Japanese- Syllabaries/dp/0824831640/ref=sr_1_1?ie=UTF8&qid=1335218962&sr=8-1)

</comment><comment><USER31> Next I want to learn how to read and write the kanji in fifteen minutes. Okay, oaky. I'm willing to invest as long as twenty minutes.

</comment><comment><USER32> This is indeed surprisingly easy. Now, where's the cheat sheet for 'understanding' what we read (other than proper nouns)?!

<comment><USER33> Korean (letter) is easy. Korean (language) is quite difficult. There are many irregular syntax and postposition. Also, there are many rules for a prolonged sound.

<comment><USER22> Modern Korean no longer distinguishes a prolonged sound at least in the written form. Virtually all words that cannot be set apart without a prolonged sound have been changed to those that can. For example, a short 이 ("teeth") and a long 이 ("two") are now homonym in most dialects of Korean; the former 이 has many synonyms like 이빨 or 치아 however, so they can be often distinguished without a context.

</comment></comment></comment><comment><USER34> You can learn to read Vietnamese much faster

<http://en.wikipedia.org/wiki/Vietnamese_alphabet>

<comment><USER27> Only if you don't go cross-eyed from the diacritics and cross-tongued from the tones first...

</comment></comment><comment><USER35> I misread the title as "how to read Koran in 15 minutes".

....I would be quite interested in _that_.

</comment><comment><USER7> Hangul is an astonishingly good alphabet. If it has a problem it's that it's too tightly coupled to its host language.

as codyrobbins already alluded to <http://news.ycombinator.com/item?id=3881388>

it expresses the particulars of Korean extremely well, while only so-so mapping to the particulars of other languages. English, as a common example, is a mess in Hangul. It's readable, sometimes with a bit of effort, but completely obliterates certain sounds that have important meanings, or is forced to add other sounds where there simply is none in English (consonant consonant groupings in English end up rendered as consonant vowel consonant in many cases, usually with the all purpose ㅡ (eu) vowel).

I've also long wondered how much of the verbal features of modern Korean is merely a reflection of written Hangul. Much like how English speakers will overemphasize the 't' in 'water' when the spoken form is really a soft 'd'. The hard coupling of spoken Korean to Hangul may help overemphasize certain language features that may not have existed in earlier forms.

Despite all this there's an effort to try and adapt Hangul to languages with similar vowel consonant features. <http://en.wikipedia.org/wiki/Cia- Cia_language>

If you think that's strange, regard Latin, Greek, Arabic and Chinese w/r to Western Europe, Eastern Europe & Russia, the Middle East and Central Asia and East Asia respectively.

Some other interesting notes, modern Hangul is a little simpler than the original form. There's quite a few consonants that have been dropped, and various consonant clusters (many of which make more sense when transliterating foreign languages into Korean as noted above, so it's sad they're gone). However, this makes learning it far easier.

It's alleged that King Sejong created and funded what we'd know today as a linguistic R&D program as a way of improving literacy and education in the country after a plague killed a great number of his subjects. The connection? A treatment for the plague was printed and disseminated throughout the country but the low literacy rate (you had to know how to read and speak Chinese to understand the information) resulted in low adoption of the treatment.

However, for quite some time (a few hundred years) it was overcome by politics and never adopted as the official written form of the language, not really being standardized or formalized to fit the modern dialect until the early 20th century!

It's really worthwhile to learn it if you travel to Korea, or even live in an area with a large Korean population. Why? Once you learn the names of a few foods, it's much easier to read them in Hangul and learning new words (and how to pronounce them) is _much_ easier than learning them via transliteration.

</comment><comment><USER36> This kind of reminds me of the classic Tim Ferriss article:

[http://www.fourhourworkweek.com/blog/2007/11/07/how-to- learn...](http://www.fourhourworkweek.com/blog/2007/11/07/how-to-learn-but- not-master-any-language-in-1-hour-plus-a-favor/)

</comment><comment><USER37> 안녕하세요

</comment><comment><USER38> Korean is actually one of the most easiest languages to learn in the world.</comment>


Oslo creates world's first 'highway' to protect endangered bees - <AUTHOR> http://www.theguardian.com/environment/2015/jun/25/oslo-creates-worlds-first-highway-to-protect-endangered-bees <comment><USER2> Old (2008) Newsweek article on China's use of human bees: [http://www.newsweek.com/stung-bees-91351](http://www.newsweek.com/stung- bees-91351)

</comment><comment><USER3> I think one dilemma of nature preservation is that people with environmental concerns are concentrated in cities, because people are generally living in a higher density in cities.

This leads to protection areas being near to cities. They're usually small and hinder development. Mind that I specially mean protected zones for the sake of nature not as a recreation ground. Most rural places get no protection at all and people are more often seduced to harm much more nature for little own gain.

</comment><comment><USER4> > Oslo's "bee highway" aims to give the insects a safe passage through the > city, lined with relays providing food and shelter – the first such system > in the world, according to the organisers.

This reads like the bees are going somewhere? Like they are stopping off to feed on their way somewhere? AFAIK bees have about a 3km forage radius from their hives - when the find food they bring it back to the hive.

<comment><USER5> There are also solitary bees that don't form hives and are important pollinators.</comment></comment>


This game supports more than two players - <AUTHOR> http://blueplz.blogspot.com/2014/08/this-game-supports-more-than-two-players.html

<comment><AUTHOR> I hope this is not off-topic for HN. This is a commentary on recent events that happened on social networks in the gaming community, but it is relevant to much more; situations we have probably all encountered just too regularly, including most countries' politics.

It is a bit long so if you would prefer to listen to it, the author reads it on Soundcloud here: [https://soundcloud.com/totalbiscuit/this-game-supports- more-...](https://soundcloud.com/totalbiscuit/this-game-supports-more-than- two-players-jazz-edition)</comment>


Design tip: Never use black (2012) - <AUTHOR> http://ianstormtaylor.com/design-tip-never-use-black <comment><USER3> The last time this was submitted, I noted it down as something to test in the future in my site. I did a multifactorial A/B test (fg/bg: #303C3C/white/black/#FCFCFC ) measuring reading time: [http://www.gwern.net/AB%20testing#text-background- color](http://www.gwern.net/AB%20testing#text-background-color)

At _n_=231,599, when I stopped it, the best-performing version was... white background, black foreground.

So for my site, seems like pure black isn't so bad.

<comment><USER4> Hmm interesting. My guess would be that the typeface on your site is so small (you're running that one now still?) that the lighter font might have made it harder to read. It would be interesting to see if these single-variable changes actually keep you in a local maximum. For example, imagine that:

\- pure black fonts are actually bad for conversion, and conversion gets worse the more pure black that is exposed (ie. the size of the type).

\- small font sizes are also bad for conversion.

\- long line lengths are also bad for conversion.

\- tall paragraphs (in number of lines) are also bad for conversion.

Now I'd imagine (purely on design instincts) that the best possible reading experience (which I'm assuming also means more reading time) would be to have off-black-colored type, at a size around 16px, with a line length of 70-80 characters, and an average paragraph height of around 4-5.

Couldn't it be that changing all four variables at once will make for a big boost in conversion, but changing one at a time runs into the limitations of the others? For example, increasing font-size by itself will lead to taller paragraphs and more black exposed.

<comment><USER3> > My guess would be that the typeface on your site is so small (you're running > that one now still?) that the lighter font might have made it harder to > read.

Well, except that the bigger fonts are performing noticeably worse, and it's a pretty linear relationship. You can see it in the current simplified-model estimate of -0.002, but it jumps out when plotted: [http://i.imgur.com/SKw3ScN.png](http://i.imgur.com/SKw3ScN.png) The 100% group performs best, and it just gets worse, even though you wouldn't think, say, 105% would be much different from 100%.

> Couldn't it be that changing all four variables at once will make for a big > boost in conversion, but changing one at a time runs into the limitations of > the others? For example, increasing font-size by itself will lead to taller > paragraphs and more black exposed.

Yes, that's entirely possible. Actually, it's probable that the fitness landscape looks like that. There's no reason to expect features to be independent and design so easily optimizable.

The problem is, it's hard to explore a high-dimensional landscape. Factorial designs, where you test every possible combination and estimate interactions, let you do this, but things can increase, well, factorially. 2x2 isn't too bad, but let's take just your 3 variables which can be tweaked by CSS: if I use just 4 differing shades of black, 5 font sizes (like the one I'm running now), and 5 differing line lengths (something like `max-width:`), then that gives me 4x5x5=100 different variants to run, and each one will need something like 1000 page views to start to become accurate, so it would take quite a while to accumulate 100,000 page views. (To put this in perspective, getting to #1 on the HN front page is worth ~20,000 page views.)

And that's just with 3 changes each with relatively few possible choices. You can see the problem. If you are really worried about interactions and decide to do a full factorial design to explore them, you can quickly get into infeasible sample sizes.

<comment><USER4> Right, which is why I don't recommend designing by A/B testing single-variable changes in the first place. Instead of assuming that your site does better with extremely long lines of tiny type, even thought that goes against pretty much every typographer's recommendation, I'd assume that you started at a small local maximum if the results really do suggest you are best optimized.

                       _
                      / \
                     /   \
        you?        /     \
         _         /       \
      __/ \_______/         \_______________

Another thing that came to mind: read time could actually be working against you, how do you know people are leaving because they can't read the type vs. they are leaving because it was so easy to read they finished earlier ;)

<comment><USER3> > Instead of assuming that your site does better with extremely long lines of > tiny type, even thought that goes against pretty much every typographer's > recommendation

It's not really an assumption though, I've already looked at long lines with the `max-width` variable, and the very wide/long versions performed pretty well; see [http://www.gwern.net/AB%20testing#max- width](http://www.gwern.net/AB%20testing#max-width) & [http://www.gwern.net/AB%20testing#max-width- redux](http://www.gwern.net/AB%20testing#max-width-redux)

<comment><USER4> That was a single-variable test, right? I just talked about that...

</comment></comment></comment></comment></comment></comment><comment><USER5> Argument: Don't use black because nothing in nature is actually black.

False Conclusion: Don't use black on a web page because nothing in nature is actually black.

False Assumption: The black on a web page is actually pure black.

True Conclusion: Use black if you want to - it won't be pure black, it will simply be the darkest you can get.

PS. This is also true for paint: Black paint is also not pure black.

<comment><USER4> The real difference between blacks in nature and on the screen is about relative darkness. Dark values appear much darker next to a very light value (true everywhere). For example, you can make a dark gray look black by surrounding it with bright white. (Look up Josef Albers if you want to learn more about that.)

The thing about screens is that they are very bright, unnaturally bright compared to other things you see daily, because they are light _emitting_ instead of _reflecting_. (They are very purposefully brighter than your surroundings so that you can still read them even if the room you are in is bright.) That means that when you put a bright white next to a dark black on the screen you're going to get a much higher contrast ratio than the same values in print. Yes, technically you could achieve the same values in print if you wanted to, but the fact is people interact with those higher ratios much less frequently.

So, yes, if you really want, you can make this your conclusion:

> Use black if you want to - it won't be pure black, it will simply be the > darkest you can get.

But that's a pretty useless conclusion for anyone who wants to learn about what's going on. Instead, realize that in _most_ cases the pure black you're using in an interface will feel unnaturally dominant, and will actually do more harm than good if you don't purposefully mean for it to be pure black.

<comment><USER6> Depends on the lighting conditions. Compared to paper reflecting indirect sunlight, computer screens are quite dim.

</comment></comment></comment><comment><USER7> You know what else isn't black? The #000000 pixels on my laptop. For me #000000 usually the best for reading. I use this bookmarklet all the time to turn text black.

[https://gist.github.com/chrismealy/7075460](https://gist.github.com/chrismealy/7075460)

I do like a nice gray, though.

<comment><USER8> As a designer it's really useful to be able to save that #000000 for e.g. an emphasized section on your body text.

<comment> Tuna-Fish The big problem with off-black text is that the designers who advocate them rarely test their sites on monitors that are like the ones the consumers actually use. Something like 90% of the people looking at your website will do it through a monitor that has a crappy TN panel and an even more crappy backlight. Designers tend to gravitate towards good IPS panels because their colors are much more lifelike -- but this means that the designer never sees the site like most of his users do.

If you do web design you absolutely have to own a 2-3 year old TN panel with a CCFL backlight, and use it on stock settings, simply because that's what your customers use. #000000 on that is usually equivalent to #303030 or something on a good monitor. And #303030 is indistinguishable from your background color.

</comment></comment></comment><comment><USER9> oof. this is awful advice, even as a rule of thumb.

obviously, absolute black is impossible to create, but there are plenty of examples in art and design where truer blacks are intentional and used effectively.

Here's some beautiful photography of LA architecture: [http://cope1.com/ARCHITECTURE](http://cope1.com/ARCHITECTURE) eyedrop some of the shadows and you'll notice that many of them are #000000.

Or look at Svpply or VSCO Cam — two very well-design mobile apps. #000000 is used extensively in both.

[http://a2.mzstatic.com/us/r1000/083/Purple/v4/94/fb/c6/94fbc...](http://a2.mzstatic.com/us/r1000/083/Purple/v4/94/fb/c6/94fbc657-48bb-b6d3-f1c7-0e8a1a694a19/mzl.wyodoypv.1136x1136-75.jpg)

[http://static.squarespace.com/static/5006a00824ac21f35d8e2de...](http://static.squarespace.com/static/5006a00824ac21f35d8e2de9/51bca157e4b0008f24e5be90/51bca15ee4b0b3d30b8630cb/1371317105053/vsco- cam-sidebar-menu05.PNG)

Not to say that off-blacks are ineffective, but to claim that one should avoid black based on a couple cherry-picked examples is simply misinformed.

<comment><USER10> As a rule of thumb the advice is correct. Nature rarely produces pure blacks and that's all the author is trying to say. To look natural is to not use black.

Your LA architecture link is a perfect example of that -- the photographer captured very striking _unnatural_ structures with aggressive, sharp edges and used a very _unnatural_ pure black as emphasis. It works. But it's absolutely not a point against the author's argument.

<comment><USER9> No, it's not correct. The author's argument is that you _absolutely should not_ use pure black in design because it's "unnatural". The false assumption he's making is that artwork and designed objects or interfaces should be _natural_ , and even that is based on a very specific definition of natural. What's natural about a computer or an LCD display? Even the best devices are comprised of "very striking unnatural structures with aggressive, sharp edges".

The author supports his argument with artwork, photography, and applications that are no more natural or effective than the ones I linked (oh, and how about Ansel Adams [http://www.anseladams.com/](http://www.anseladams.com/)? A legendary _nature_ photographer — his images are full of deep blacks.) It's a matter of personal preference. Telling inexperienced designers to "Never Use Black" just isn't sound advice. I would sooner advise designers to work only in black and white. Design a great application in black and white, and then begin working with color and tone when black and white aren't enough. A more appropriate, though less provocative title for this article would be, "Shadows Aren't Always Black".

<comment><USER11> Creating successful "unnatural" imagery is very difficult and often not the case for artists, and almost never for designers.

In regards to LCD screens and other devices not being "natural," RGB linear color transformations don't create natural color palettes--the real world is far different than our digital recreations.

<comment><USER9> Your first statement is just plain false. Much of the contemporary art world (and Modernism and Postmodernism) can be characterized by a rejection of realism and strict representations of nature. Have you been to a contemporary art show recently? The same goes for the design world.

Your second statement supports my argument.

</comment></comment></comment></comment></comment><comment><USER12> Replace the word 'black' with any other color you can think of in this article and it's pretty clear how dogmatic this is. I'm all for setting rules and constraints for a given design project, but trying to set universal rules apart from the context of the project with these arguments is fallacious since one can easily give strong counter arguments in favor of pure black. In fact, OLED screens are as black as they come since a pure black OLED won't draw any power. This is a wonderful aspect of it's function that results in incredible _saturated_ graphics like those found on the op-1 synth display: [http://www.teenageengineering.com/products/op-1/overview](http://www.teenageengineering.com/products/op-1/overview)

</comment><comment><USER13> From last year (219 comments): [https://news.ycombinator.com/item?id=4357002](https://news.ycombinator.com/item?id=4357002)

</comment><comment><USER14> By the same token, don't use this mantra to use low-contrast text like that used with this article. Absolute black may be a no-no, but this doesn't mean all of 'dark' is a no-no. Low-contrast text is poor form.

<comment><USER11> Although I agree that everyone needs to watch out for low contrast type scenarios, I don't exactly see how this article exemplifies one in any way. Can you point out anything in particular?

<comment><USER15> It have a poor contrast for text.

<comment><USER16> No, it doesn't, the foreground color is #57534a and background is #ffffff which gives a ratio of 7.7:1

WCAG 2.0 requires a contrast of 7:1 to reach AAA levels. [1]

you can test it yourself with a bunch of tools but I couldn't find link to results on any of them [2][3][4].

[1] [http://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio- contr...](http://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast7)

[2] [http://webaim.org/resources/contrastchecker/](http://webaim.org/resources/contrastchecker/)

[3] [http://snook.ca/technical/colour_contrast/colour.html](http://snook.ca/technical/colour_contrast/colour.html)

[4] [http://contrastchecker.com/](http://contrastchecker.com/)

<comment><USER15> My eyes prefer better contrast. I've read WCAG 2.0 and 7:1 is a minimum contrast, not optimum. The logic is that it's a minimum contrast for a user with 20/80 vision.

</comment></comment></comment></comment></comment><comment><USER17> Every time I hear or read some absolute statement about something related to perception (mostly visual), I think about "The blue boy" ([http://en.wikipedia.org/wiki/The_Blue_Boy](http://en.wikipedia.org/wiki/The_Blue_Boy)).

Never use blue as a foreground colour...

There goes another principle.

</comment><comment><USER18> I remember when this was discussed the first time around. I somewhat agree with not using black, I don't remember the last time I used black in a design nor saw it really used. These days it's all about the greys. A fine substitute for black I've been using for as long as I can remember is #111111 it's close enough to black it's dark, but it's further away from black that it is somewhat noticeably different.

It's all a matter of taste and preference. Keep in mind #000000 will not always be black, colour profiles, brightness and contrast settings of individual monitors and devices means there will always be a difference. One colour is generally like a million colours. As always, think for yourself and don't readjust your workflow because of posts like this.

<comment><USER4> [http://paulgraham.com/taste.html](http://paulgraham.com/taste.html)

<comment><USER19> or The Judgment of Taste [http://plato.stanford.edu/entries/aesthetic- judgment/#1](http://plato.stanford.edu/entries/aesthetic-judgment/#1)

</comment></comment></comment><comment><USER20> As a painter I've been fanatically attached to the use of black probably longer than the article user has been alive. That said I say in his defense that there isn't a pure black available no matter what you do. Secondly a little goes a very long way and it is extremely easy for it to do a visual 'crash the party' on your design efforts so his cautions are right on the money. If anyone gives a damn, I've a painting gallery on my web site, [http://www.sdragons.org](http://www.sdragons.org) to show what I mean by my own use of black. Warning, prolonged exposure may deepen existing depression :)

</comment><comment><USER8> I have to continually beat this argument into my boss's brain, who insists things should always be black.

I follow the same principle for white. Keep #ffffff for the highlight on the really light thing you want to show.

Also I find asking most displays to show #ffffff often pushes them too far into the nonlinear, which ends up causing some odd artefacts when used with e.g. gradients.

</comment><comment><USER21> The article makes good points about the (over)use of black in UI designs, but uses just one example to show how saturated color can be used in shadows, therefore concluding that black isn't that necessary at all. Wayne Thiebaud really paints astonishingly beautiful shadows, but there are some very good examples of black in art as well, that I thought increases the level of the discussion "to black or not to black".

Pierre Soulages is worth mentioning here. Better seen in person (because of the textures and reflections), even on screen his all black paintings are amazing.

[http://en.wikipedia.org/wiki/Pierre_Soulages](http://en.wikipedia.org/wiki/Pierre_Soulages)

</comment><comment><USER22> I like to think of this somewhat differently.

By using extreme values you are limiting your options. If you use #FFFFFF in a design you can't select a brighter color and you can't select a color with the same brightness that's warmer or colder etc.

The same goes for black and for strongly saturated colors. You can't make something more saturated than #FF0000 and you can't create a brighter color without decreasing saturation.

Using these "extreme" colors can increase contrast and might help make details in a design pop, but that is only possible if you limit their usage overall. Do use black, white and saturated colors, but be aware of what you are sacrificing.

</comment><comment><USER23> Previously on HN with 789 points, and lots of discussion (216 comments), so for those interested the topic dont miss:

[https://news.ycombinator.com/item?id=4357002](https://news.ycombinator.com/item?id=4357002)

</comment><comment><USER24> I find the body text color on his site too light for comfort. You don't have to go #000, but #333 would've made it a lot more legible.

Not everybody uses IPS panels with glossy coating.

</comment><comment><USER25> General tip: Never say never. Op has a good point there that shadows are not usually black in tint but the opposite hue from highlights. Black has its uses though when you are not painting a painting.

</comment><comment><USER26> Or use black on your website and win an Apple design award: [http://www.bohemiancoding.com/sketch/](http://www.bohemiancoding.com/sketch/)

<comment><USER27> Couldn't be sure if your comment was snarky but if so - Correlation and causation. Sketch is an amazing native app and from my experience with definitely deserves that award.

<comment><USER26> Oh yeah absolutely, they do deserve that award. My point was: Never use black, unless you know what you are doing. The sketch website is a great example of a good website with background-color: black;

</comment></comment></comment><comment><USER28> We talked about this before. There's no such thing as black. The actual residual reflectiveness of 'black' depends on the medium.

</comment><comment><USER29> Better design tip: Never use 'never'.

</comment><comment><USER30> By using grey for backgrounds you can still use black for shadows, as both the Sublime and Calendar examples do.

edit - <USER2>

</comment><comment><USER31> this has been discussed back in August 2012. Somebody please add "(2012)" to title.

</comment><comment><USER32> Try telling that to the guys who designed Windows Phone.

</comment><comment> sTevo-In-VA I use black so my lines can show up when photocopied.

</comment><comment><USER33> segment.io needs more pure black. It seriously looks really dull.

</comment><comment><USER34> white supremacist propaganda; move along... no, was good read; love that Wayne Thiebaud sf hills piece.</comment>


Ask HN: Do you get annoyed with GSearch Results ads disguised as organic result? - <AUTHOR> <comment><USER2> I distinctly remember early Google executives _swearing_ that they would never do this.

<comment><USER3> And calling it deceiving and banning sites that displayed the ads in the same colors as the site. The ads must be clearly visible! yeah...

</comment></comment><comment><USER4> Google Trends or other year-end reports on popular queries don't include navigational queries. For example searching for nytimes to go to nytimes.com. When I worked at a competing web search engine the (real) top 100 was full of navigational queries (and lot of queries that will also never show up in official reports, like 'sex').

When I watch family members I think it gets worse every year. Every brand name is typed into the browser URL bar and instead of just adding .com (or .fr or .de depending on country) it goes to Google and they click the first result. Often enough that's an ad and Google earned a few cents by users not typing in .com

</comment><comment><AUTHOR> Interesting thread raised by Jason Fried last week: [https://twitter.com/jasonfried/status/1168986962704982016](https://twitter.com/jasonfried/status/1168986962704982016)

<comment><USER5> Is that Jason Fried from Newsweek?

</comment></comment><comment><USER6> Yea well Google doesn't care about your feelings. They care about how much money they can squeeze out of a rock.

</comment><comment><USER7> I never see them courtesy of uBlock Origin.</comment>


Sending Cat Pictures Over The Phone (2015) - <AUTHOR> https://github.com/jpf/dial-a-cat <comment><USER2> Robot36 and SSTV Encoder are simple, ad-free, free (Apache License) Android apps for decoding and encoding SSTV with a complementary and extensive mode- set.

That said, Dial-A-Cat is a bit blurry due to Martin 2's short transmission time and the cellular connection. There might also be a frequency shift preventing header detection in Robot36.

<comment><AUTHOR> It's been years since I wrote this code. As I recall the main constraints that went into picking Martin M2 were: what was supported by the SSTV decoders that were available at the time, what was supported by Python libraries, and the time it took to transmit the image.

</comment></comment><comment><USER3> Tangential but arguably related: what phone numbers around the world are still hooked to modems? What's out there that I can [still] dial in to?

The reason I emphasize "around the world" is that I want to play with an old modem I have here, I want to use my actual landline for the testing, I live in Australia, and long-distance calling doesn't really appeal because, besides the costs, it'll probably kill 56k throughput.

I've noted some old dialin lines used by ISPs, because that'll at least get me to "right, PPP's complaining but that means it's working", but it would be very nice to go a bit further.

<comment><USER4> The problem is that some interconnects between carriers use codecs optimised for voice and voice only, and your modem will most likely not work at all. The days of fully analog landlines are long gone - even if you get a phone jack, nothing guarantees it's not being digitised and then compressed with the aforementioned codecs down the line.

</comment></comment><comment><USER5> I was lucky enough to see JF demo this, really cool work.

</comment><comment><USER6> Sometimes I feel like maybe this is actually the best timeline

</comment><comment><USER4> Boring.

TLDR: he's just using Twilio to play back an audio file of an SSTV transmission of a cat picture to incoming callers.

I was expecting something more exiting, like an actual modem that could work over mobile phone calls (conventional 56k modems don't work as the voice codecs used in legacy non-VoLTE phone networks are exclusively optimised for voice).

<comment><AUTHOR> If you press "8" at the prompt, you'll be served a fresh image from The Cat API that is rendered on-the-fly: [https://github.com/jpf/dial-a- cat/blob/master/app.py#L107-L1...](https://github.com/jpf/dial-a- cat/blob/master/app.py#L107-L133)

To get this to work, I had to serve the WAV samples to Twilio as they were generated, this is described just below the first block of code in this section of the README: [https://github.com/jpf/dial-a-cat#transmitting-sstv- images-o...](https://github.com/jpf/dial-a-cat#transmitting-sstv-images-over- the-telephone)

The reason I serve a pre-rendered audio file by default is that not every image you get from the Cat API results in an image that is recognizable after Martin M2 is done with it.

<comment><USER4> I wasn't criticising the fact that you use a pre-rendered audio file (in fact that's the proper way to do it, as there's no need to recompute the SSTV audio every single time), merely the fact that it's just one-way SSTV instead of something more exciting like implementing an actual modem.

<comment><USER7> Looking forward to you completing your non-boring modem project!</comment></comment></comment></comment>


Looking into the future: Can AIDS be cured? - <AUTHOR> http://www.economist.com/node/21559594?fsrc=scn/tw/te/ar/lookingintothefuture

<comment><USER2> Whatever happened to the virus killer: DRACO?

<http://en.wikipedia.org/wiki/DRACO_(antiviral)> <http://www.ll.mit.edu/news/DRACO.html>

I don't see it in the top google links, but not long ago there was some correspondence with one of the lead MIT scientists that said that after the media hype in August 2011, no one else really contacted them to look at funding the research.

It seems like UNAID would at least contact the MIT researchers and consider their approach.

</comment><comment><USER3> Given the results reported in this article, HN might be the only forum on the web that will ignore the circumstantial, irrelevant and associative connection between circumcision and religion, eschew silly polemics, and proceed to discuss the real issues at hand. (Fingers crossed...)

<comment><USER4> Hear, hear. Real issue #1: how can Africa leverage its foreskin surplus to its advantage?</comment></comment>


Mosquito army released in Zika fight in Brazil and Colombia - <AUTHOR> http://www.bbc.com/news/health-37773274 <comment><AUTHOR> "Wolbachia is a naturally occurring bacterium that infects 60% of insect species worldwide, but scientists say it does not harm humans." -What does that mean for honeybee population ?</comment>


I Just Logged In As You - <AUTHOR> http://www.codinghorror.com/blog/archives/001262.html

<comment><USER2> People here are very critical of Jeff Atwood. I realize that he has some shortcomings, and is sometimes flat-out wrong about things, but I'd like to point out a couple of things in his defense:

1\. His blog and podcasts are pretty entertaining, even if he is wrong sometimes.

2\. He created Stack Overflow, which is a pretty nice site. At least, I like it.

3\. He admitted and blogged about an extremely embarrassing oversight on his part today. Which takes some backbone.

That being said, I don't think we need a link to him on every single blog entry. This particular entry is more interesting from a Hacker News perspective though.

<comment><USER3> I'm one of those who is often critical of Atwood, and the point is not that he is "wrong sometimes", but rather, that a) he tends to carelessly dismiss those things he doesn't understand, and b) this includes much of the discipline of computer science.

As Dennis Forbes so aptly put it, "Be careful diving in [to CodingHorror] headfirst, though, as the technical depth is generally so shallow you'll be hitting the bottom before you've even broken through the surface tension."

<comment><USER4> I think this is the key point. Atwood is overly dismiss and has even written flat out anti-intellectual diatribes (see the "fireman" post).

<comment><USER5> Interesting. I was about to impulse-comment on a previous comment, but then say yours.

Makes me wonder about the ways of being wrong, and who do people here think tend to be wrong in a good or valuable way?

E.g., making conjectures that at least posit novel interaction of events and ideas, or are wrong due to lack of current knowledge and over-optimistic conjecture, not because of willful ignorance or bias.

(I suppose that describes any good sci-fi writer; I'm thinking more of bloggers or essayists.)

</comment></comment></comment></comment><comment><USER6> Funny, I had a similar incident on Friday. I had an error on my web server from a bug (fixed now of course). I was curious about the IP that generated the error because I had just attended a networking event and wanted to know which contact I talked to now had a bad impression of my site.

I put the source IP in my browser and came up with a XAMPP administration page which had a link to phpMyAdmin, which gave me admin access to all the databases on that server.

I poked around long enough to get a contact email for the server admin and sent him a polite email explaining everything. He was grateful for the email and explained that he never thought anyone would try to access his raw IP. I don't think he checks his logs much. ;)

</comment><comment><USER7> My favourite Atwood screw-up of all time was on the recent stack overflow podcast. Joel referred to a digital clock on the wall, which Jeff corrected him, and said it was an analog clock. Joel did his customary 'Jeff said what?' pause, and then pointed out "I'm pretty sure I can see digits on that clock, so it's digital." Jeff was still not immediately convinced.

That said, I enjoy listening to the podcast, even if sometimes because I get to laugh at the things Jeff said. But as someone else said here, it's hard to be too down on someone who was a key factor in making a site like Stack Overflow. He also makes some good points. Sometimes.

But objectively, about 90% of the time I agree with Joel when the two have a disagreement. Guess that means I shouldn't apply for a job at Fog Creek :-).

<comment><USER4> Yeah, the podcast has a lot of that. It's very ironic. It's quite common for Jeff to say something wrong, Joel to correctly correct him, and Jeff a) not be convinced and b) yield in the sort of "I know more than you do about this but I'm just going to be nice" way. I think it's delightfully, if not irritatingly, ironic.

</comment></comment><comment><USER8> Isn't 1Password a solid way of avoiding the whole one-password-multiple-logins problem? Most of my logins are 8 or more randomly generated characters. The best passwords I end up memorizing anyway, but I don't use the same PW twice anywhere on the internet. Am I secure?

<comment><USER9> Try 1Password plus dropbox to sync passwords across multiple machines.

<comment><USER10> I've been using 1Password, but I've noticed it's "auto fill" and "auto save" options get confused easily, especially if I have multiple logins for one site (for example I set up a new gmail account for every project I run, and tie in any third party services to that gmail). This means that I could have 10-20 gmail logins saved. 1Password often tries to save passwords that it already has saved. Make sense? Anyone else run into this problem? I've started to migrate over to using Wallet.

</comment></comment></comment><comment><USER4> He is so pretentious. He goes on about how great Open ID is and yet talks about how he has all these different passwords and uses a "throwaway" password for admin access to his application. Great. Then he posts something about how "brute for is for dummies" when using bad passwords is really what's for dummies.

<comment><USER11> I think he even had a post about how passphrase is better than a password. But I may be mistaken and I am just to lazy at the moment to search for it :(

<comment><USER12> Passwords vs. Pass Phrases: <http://www.codinghorror.com/blog/archives/000342.html>

_Easier on the user, harder for hackers: that's a total no-brainer. I've adopted passphrases across the board on all the systems I use._

I guess the anonymous person discovered his passphrase?

<comment><USER13> I think so, and I think the passphrase included dictionary words which is why the anonymous person said as much.

</comment></comment></comment></comment><comment><USER14> "I've talked about this exact sort of vulnerability several times on this very blog."

You talked about it but didn't implement it? Yikes.

<comment><USER15> Maybe Joel interrupted him when he was talking about it once and he forgot about it and hence forgot to implement whatever important security practice he overlooked for stackoverflow.

Good thing stackoverflow is a tech help site and not porn/gambling, eh?

<comment><USER4> Perhaps. Perhaps Joel was mesmerizing Jeff with his vague knowledge of Psychology 101.

</comment></comment></comment><comment><USER16> I'd like to jump all over Jeff for having a weak password, but somehow that seems like blaming the victim. Sure, he's supposed to be an elite hacker programmer blogger authority something-or-other, but is everyone in the world supposed to become an authority on choosing strong passwords?

Stepping back for a moment, why are we using passwords for authentication and security in 2009?

<comment><USER17> Because there are not better alternatives? Unless you'd like to trust some company with biometric details about yourself. But biometrics aren't notably better than passwords anyway.

And in answer to your question, yes. Everyone is supposed to become an authority on choosing strong passwords. I fail to see why this is unreasonable.

<comment><USER16> > Everyone is supposed to become an authority on choosing strong passwords. I > fail to see why this is unreasonable.

peopel have been saying this for decades, that users should get with it and learn how to create passwords like "as723HASD-23", to change it every month, to use a different one for each system, to never write it down, and so on and so on.

And for decades users haven't been doing this.

So. Are we to blame the rest of the universe for not doing what we tell it? Or decide for ourselves that _This doesn't work and we as programmers must think of something else?_

If none of the alternatives appeal to you, think up a new one and get some YC funding going :-)

<comment><USER17> The point is that there are no alternatives. This isn't a design problem that as programmers we can fix. There are plenty of existing security systems that fit the bill. It's a human problem.

For example, one technical fix is a widely deployed public key authentication system. It would take a company as large as Google to force people to adopt it, however. Plus operating systems would have to start shipping the software to make the average user understand it. Private key creation would need to be integrated into the create user process of Windows and Mac OS X. That's not realistic because there is little profit for the companies involved.

<comment><USER18> _It would take a company as large as Google to force people to adopt it, however._

I think we'd see quite a bit of progress if OpenID providers just started using PKI.

<comment><USER19> How many non-technical people are actually using OpenID? (For that matter, how many _technical_ people are using it?) Actually using it, not having some OpenID thing that they don't know about...

<comment><USER18> Why does it matter?

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> from another perspective, i wonder how much time is wasted by the average person choosing, memorizing, and resetting random passwords that no one will ever try to crack.

i wonder if the value saved by well-protecting a user's data is a net gain or loss on the whole... <http://qzip.in/nX>

<comment><USER21> And that link sends me to a post from back in 2006 at www.securitywonk.com ...whose Home Page's _latest_ post is also from 2006.

More 'wonk' than security at that site, I'd wager.

</comment></comment><comment><USER22> Especially amusing since he wrote in January( <http://www.codinghorror.com/blog/archives/001206.html>):

"If you're a moderator or administrator it is especially negligent to have such an easily guessed password."

Actually, I find just the apparent fact that he uses a 3rd party openid provider (whichever one it is) for his StackOverflow admin account disturbing. The OpenID provider has the credentials - they can therefore log in as him any time they like. Only their integrity / reputation prevents them from doing that. I think it's fine for individuals using the system to trust a 3rd party like that but I don't think it's fine for someone with admin powers to do so.

* Ignore this whole comment if he runs his own OpenID provider :-)

</comment><comment><USER23> Lame excuses do not a proper apology make...

A perfect complement to NoScript's proper apology article.

<comment><USER24> I'm not really sure what he has to apologize for. He didn't even really need to post this article or the email.

<comment><USER23> When you run a site with many users, you have a responsibility to safeguard your users' data. Part of this is having reasonable security, and part of that is having a reasonable admin password.

As far as not "really" needing to post this, that's true of any breach of security with no obvious user-observable consequences, regardless of the kind or degree of the breach.

edit: Besides, as is the case with the softcore porn in a technical presentation, I'm more worried about the fact he says it's no big deal than the actual security problem. I think "I screwed up totally and apologize for having failed you, this will not happen again" would have been more appropriate than (paraphrase) "I screwed up but this is pretty inconsequential."

</comment></comment></comment><comment><USER25> It's better to modify your site to accept only modified usernames/email adresses (e.g you must always login by adding a - to your username) for the user accounts that are more important (has more rights) then normal accounts. A hacker will have problems bruteforcing these accounts..

</comment><comment><USER26> I am a Jeff Atwood fan. Totally enjoy the podcast and I think stackoverflow is pretty useful.

</comment><comment><USER27> I have a simple method to prevent to be cracked for %100.

I choose a word, for example if it's Hacker News, then i choose hacker and then add random number to it while they are complex chrachters.

Just look on your keyboard, there are numbers that matches chr, like 1 -> & and 2 -> é

so i write é(hackerénews while i memorize 25hacker2news

i think in such way it's 98% impossible to crack it

</comment><comment><USER28> _how do you think this person discovered my password?_

Well this may be a stab in the dark, but I'm guessing it has something to with the fact that you are NOT a great programmer. Learn some C you average coder!</comment>