Hacker News new | comments | show | ask | jobs | submit | roryokane's comments login

Posted as a GitHub issue: https://github.com/nolanlawson/pokedex.org/issues/10

I had the back button problem too. The solution is for the app to add routing, which is tracked in this issue: https://github.com/nolanlawson/pokedex.org/issues/2.

The balance in someone’s checking account. A checking account is the bank account that written checks take money from, as opposed to a savings account.

I think the author is talking about minor variations on Lisp syntax that include indentation-sensitivity, not about different languages that are homoiconic. Such variant syntaxes include i-expressions (http://srfi.schemers.org/srfi-49/srfi-49.html) and sweet-expressions (http://readable.sourceforge.net/), which the author mentions in the Acknowledgements. For example, here are some sweet-expressions:

  define factorial(n)
    if {n <= 1}
      * n factorial(- n 1)
This desugars to:

  (define (factorial n)
    (if (<= n 1)
      (* n (factorial (- n 1)))))
I think the Lisp power that the author is referring to is homoiconicity, and the corresponding ease of writing macros. For example, i-expressions sacrifice homoiconicity in some contexts.

But the author seems to have overlooked that sweet-expressions, which were developed later, do not sacrifice homoiconicity. A human reader can still easily understand the AST from reading sweet-expression syntax. The real reasons that sweet-expressions have faltered relate more to the increased difficulty of collaborating with other developers, the lack of editor plugins that highlight sweet-expressions correctly, and incompatibility with Clojure syntax.


danneu wasn’t necessarily saying that Sublime is better than Emacs overall. He was referring to Sublime’s specific comparative advantage over Emacs. The relevant advantage here is that Sublime is better at being easy to learn by new users, because it follows conventions used by the OS and by other programs.


Sublime Text’s advantage in this context is the advantage that all GUI text editors share, including Atom and GEdit. This advantage is a combination of being more familiar and having better defaults.

Some ways that Sublime is more familiar are that it uses the OS-standard editing hotkeys, such as moving by words with Ctrl-arrows or Option-arrows. It also uses OS-standard terminology, like “close window” instead of “kill buffer” and “paste” instead of “yank”. The result is that new users don’t have to learn anything to be productive – they just edit as if they are in Microsoft Word, while enjoying the programming-specific features of a text editor such as syntax highlighting and block folding.

The better defaults include easily creating more than one scratch buffer (just run “New File” multiple times), automatically balancing parens when you type, support for pixel-by-pixel smooth scrolling, and scrollbars that don’t confusingly shrink when you start scrolling past the end of the buffer. I’m sure Emacs supports all these things, but you have to manually configure it to do so first. Many users are scared off from Emacs after seeing that it requires up-front investment to get features that other editors already provide with no work.


> more familiar

To whom? There is still a huge number of incompatible text editor cultures. Mac bindings, Microsoft bindings, Wordstar, etc.

> better defaults.

There are dozens of "better" .emacs pre-cooked packages. Choose any. No need to stick to the out of the box defaults.

> OS-standard

Which OS?

> he result is that new users don’t have to learn anything to be productive

The "new" users had to learn all those "OS default" bindings and terminology first. Not that "new" in my book then.

> it requires up-front investment

They simply forgot their up-front investment into learning the defaults of their chosen OS. I understand that - I still cannot use Microsoft Office, can't be bothered to learn it.

So, the only advantage is familiarity to those who already invested a lot of time into learning something else. Nothing of a value for the new users.


Yes, pre-cooked packages of defaults make things a lot easier for new users, but not quite equivalent to GUI text editors. I don’t get the impression that most people being introduced to Emacs are told to use a package of defaults. I think a lot of users will want to try out Emacs, so they download Emacs, then try to configure some things they don’t like by Googling the specific issues. After they have too big a list of things they don’t like about the defaults, they go back to their old editor, without ever learning of the existence of defaults packages. Which is a shame.

Apart from defaults, I agree that GUI text editors provide no advantage to completely new users. But I’m not sure that “new users” of text editors, unfamiliar with OS conventions, is a category worth talking about – I think it’s really small. It shouldn’t take more than a year for a new computer user to absorb the OS conventions while browsing the web and writing documents. And how many people might want to try out Emacs within their first year of using a computer?

I guess that about 10% of eventual programmers started trying out programming in their first year of computer use – the other programmers started later in life. The number of fledgling programmers who care about editors enough to look into Emacs has to be even less than that – it’s probably something like 1% of all programmers. The other 99% of programmers will find GUI editors more familiar than Emacs, because they have already internalized the conventions.


> GUI text editors

Emacs is a GUI text editor too, btw.

I can be wrong, but my impression was the opposite - all the new tutorials I saw recommended one or another starter pack with all the bells and whistles out of the box.

> while browsing the web and writing documents

I'm not sure if a proportion of users who write documents in a specialised software (like Word) is significant enough. And web browsing is largely clicking, no hot keys are used in general, so no habits to be picked up.

Another thing to consider is that now more and more users are coming from mobile platforms, without any desktop exposure whatsoever. For them, any desktop conventions are equally alien.


Good point, I hadn’t considered the new generation of mobile-first users.

> I'm not sure if a proportion of users who write documents in a specialised software (like Word) is significant enough.

I thought that most computer users learn to use computers while in school, for which they use a word processor to write essays and reports for the teachers. From around 2004 to my graduation in 2009, my middle and high school’s teachers even required essays to be typed and printed, so that they wouldn’t have to struggle to read students’ handwriting.

I guess some students prefer writing essays on paper, but those students probably wouldn’t become potential Emacs users.

Am I missing a common backstory for programmers that doesn’t involve using computers to write reports for school?


To be honest, I'm not quite aware of the current school requirements here, in my days all reports were hand written. But I've seen quite a lot of young people (here in the UK, do not know about the other countries) who obviously got no defining exposure to any desktop software at all. It is almost funny to see people discovering the copy and paste idea for the first time.

And with all the tablets and smartphones, even the basic touch typing skill is now extremely rare among the young.


Probably Floobits: https://github.com/Floobits/floobits-neovim


I don’t have an audio snippet, but I can transcribe what the voice says on different runs. It usually pronounces random letters individually, but sometimes pronounces syllables with letters missing:

“L-W-R-D”, “L-L-W-R-L”, “hell-erl”, “H-L-er-D””, “eor-D”, “H-L-L-erl”, “L-L-W-L-R-D”, “H-L-W-R-L”, “hell-W-R”


Here’s a sketch of some potential syntax to simplify your TypeScript so it’s like that Haskell code.

  class GraphQuery extends Query {
    static parse(object: any): Try<GraphQuery> {
      return TimeRange.parse(object.over)
        .combinedWith(() => Filter.parse(object.where) )
        .combinedWith(() => GroupBy.parse(object.by) )
        .withCombinedValues((timeRange, filter, groupBy) => {
          return new Success(new GraphQuery(filter, groupBy, timeRange));
In this design, `combinedWith` is a lot like `then` when using promises. It’s a bit more complicated because `then` assumes that arguments are always passed directly from the previous function, so you need special support to store the return value and retrieve them later as arguments.

If the type system requires it for some reason, you could add a `.startCombining()` call at the end of the first line within the method, so that `combinedWith` is sure to be possible.


The EV of all insurance policy is negative when measured in absolute dollars. But the EV can be positive if the value of dollars to you doesn’t scale linearly.

For example, if you have to spend $10,000 on medical bills, that might be 1 unit of disutility. But if you have to spend $100,000 on medical bills, that might be 30 units of disutility, not 10, because you just don’t have that kind of money and you will go bankrupt and your quality of life will go way down. With this reasoning, health insurance might have a positive EV for utility, even though it has a premium that gives you a negative EV for money.

This reasoning is less likely to apply to life insurance, because people are less likely to care about what happens after they die. But for people whose beneficiaries would suffer a lot from losing their income – perhaps they would be evicted – life insurance can be worth it.



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact