greghendershott

I'd say that Google's job is to show the search results that _each_ user is actually looking for. (Not an aggregate user with 2.5 children.)

Come to think of it, doesn't Google aspire to personalized search? But in any case, at least I'd like old-fashioned quoted search -- i.e. I want "this phrase" exactly -- to give useful results.

Another way to feel better about dilution is to realize that the valuation after every round is a mutually agreed abstraction. Until some actual liquidity event puts cash in hand, you have valuation not value.

The only meaningful dilution is the one where the founders become minority shareholders. Although loss of control isn't necessarily bad and can eventually pay off, unlike valuation it is not abstract, it's tangible.

I sometimes put a `help-wanted` tag on GitHub issues I think are especially well-bounded items someone could contribute. It looks like other people use that tag, too: https://github.com/search?l=&p=2&q=state%3Aopen+label%3Ahelp...

You can further filter that by language, or other criteria.

Same here. I spend nearly all my time in Firefox and Emacs. My main laptop has been a MBPr, but more for the hardware than for OS X per se. Lately I've been trying a 1st gen Chromebook Pixel. So far the experiment is going really well. If that continues I might upgrade to a Chromebook Pixel 2 LS as my new main machine.

Basically I want a Linux laptop that "just works", with MBPr quality (or better) build, screen, and keyboard. One obvious choice is the updated XPS 13. A perhaps less-obvious choice is the Pixel.

Having said all that, Emacs for ChromeOS could have some advantages, e.g. battery life, not needing to "break the security seal" by putting a Chromebook in developer mode, and not needing to chroot (although that's quite easy and ~30 minutes).

I think Shriram would point out he is one of many people responsible for the development of Racket.

Is it their own money? I thought the general partners are using money from limited partners. As the article put it: "I would love to ask the investment officers at a firefighter’s pension fund in Wyoming what they think of venture capital GPs using their money to fund their colleagues’ personal projects."

It's nice that New York didn't get much snow, as predicted by the GFS model but not the other two.

Did GFS predict 2-3 feet of snow for Boston? Because west of Boston they're at 30 inches already, and it's expected to fall at 1 inch per hour for the next 5-6 hours. As forecast.

Also Nantucket has lost all electricity and cell coverage, after hurricane-force gusts to 77 mph.

With storms like this, although false positives are annoying and expensive, false negatives are worse. It would have been interesting for the article to discuss how GFS fared in that respect.

Although I'm not a fan of the left-offset main keyboard and trackpad (I'd prefer leaving out the numeric keypad section), it looks really nice otherwise.

Hopefully I'm being Captain Obvious, but:

Using hackathons as a hiring tactic doesn't seem like a very smart idea, given how self-evidently discriminatory it is on the axes the OP describes.

I didn't expect my blog post to be on the front page of HN. Here's a TL;DR summary:

For many languages this is a significant and distracting degradation in the presentation.

I could understand GitHub removing highlighting completely because they feel speed is the overriding priority. That would be even faster than what they're doing now. Languages would look "plain" instead of "wrong". Not my first choice, but a reasonable choice.

The situation now is that they've replaced a library that had been handling highlighting thoroughly, with a variety of text-editor lexers that mostly are not. People like me who already contributed to Pygments, aren't feeling motivated to do this all over again for no good reason. So it seems likely the lexers will remain poor for quite a long time. Which is unfortunate.

Finally, at the time I wrote my blog post, I was speculating about the motivation because GitHub hadn't explained why, yet. Someone later did explain ("because speed") in the issue thread.

Thanks for sharing that. It's helpful to understand it from your perspective.

To share my perspective, outside Google:

A similar "error/ad" appears for other some other Google features. Such as trying to edit a picture in Google+ -- I've seen that example for so long now, it seems there's no intent ever to change it.

With each such example, the cumulative effect is to remind me of bad days in the past. My feeling isn't snarky, it's unease. I've seen stuff like Prodigy and CompuServe. I saw Microsoft pivot MSN 1.0 from being another such service, to instead be a web site.

And ever since, I've seen a succession of attempts to "put the open internet genie back in the bottle", including but not limited to Internet Explorer. So far these attempts have failed... but they haven't been from a company as powerful as Google.

So as someone who had loved Google for many years as a supporter of the open internet, it makes me unhappy and confused to see more examples of "Download Chrome!" as an error message in Firefox.

Having said all that, I'm happy to hear that you plan to address this at least for Inbox on Firefox.

Sorry to be slow to notice this and to reply.

First, I think Geiser is wonderful and you made a great choice.

For whatever reason, as a Racket beginner some years ago Geiser just didn't "click" for me, and scheme-mode seemed to have a lot of stuff that was confusingly N/A for Racket.

Part of the motivation is I think Racket deserves a mode dedicated to it, these days, for those who may prefer that.

Although partly that's about perception, it also means freedom to do Racket-only things.

For example racket-mode has commands to tidy or trim `require`s, or even to convert a file from `#lang racket` to `#lang racket/base`, adjusting the requires as needed. It's OK to add things like this without considering and implementing whatever the analog, if any, is in Guile Scheme (which Geiser also supports).

Or more basically, racket-mode has an obvious way to "run" your program in a predictable way, much like DrRacket.

Thanks to the head start provided by gcr, recently I added the equivalent of geiser's support for images in the REPL, to racket-mode.

As for supporting WXME format files: Although that sounds very cool, I don't think that's within the scope of what I want to attempt for racket-mode (or have time to do) now.

p.s. The video of my demo at RacketCon was posted recently: https://www.youtube.com/watch?v=QWiteH8PARQ&list=LLoI3ip0MG_...

p.p.s. My "30 year old technology" comment was re the previous speaker. I am definitely not begin derogatory about Emacs. :)

Well, the original markdown.pl heavily uses regexps.

From having tilted at this windmill a little myself, I think:

1. It's tricky enough to handle correctly all the under-specified corner cases of basic markdown -- not to mention the popular extensions to it. The cognitive load of doing it with complex regexps gets heavy, quickly.

2. I'm incredibly impressed with all the work that John MacFarlane has put into the problem, for example in [Pandoc] and [Cheapskate].

[Pandoc]: https://github.com/jgm/pandoc

[Cheapskate]: https://github.com/jgm/cheapskate

Exactly. If I ever say this, what I mean to be saying is something more positive. More like: "Good news! This is something that's actually simple to fix/do. Even if you find it difficult at first (I sure did), someday you'll look back on this and think it's really easy."

Because although programming is something I enjoy, it hasn't necessarily always come easily to me. I'm not a natural. I learned to be good(ish) at it by slogging away doggedly.

So to me, it's a long -- and never-ending -- journey of things that are difficult... until they become easy. Being confused about something is a constant fact of life, for me. But so is a growing list of things that, in hindsight, now seem easy.

I wish I knew some pithy, quick way to say that to people, so that it's the positive message I mean.

This is important advice for consumer-ish software. But in other areas, it works differently. A product "grows up" as its original user cohort grows up, and that's OK.

I saw this in the music creation software space. Products start simple out of necessity. They are a good fit for a cohort of users with simple needs. But as the user cohort advances, they need and want more powerful features. Typically companies add the features to create a "more professional" product, rather than see their existing users jump to a competitor.

Of course after (say) 5 years of this, the product is no longer such a great fit for "beginners". So it creates space for a new product to step in, and with a fresh approach. Of course that new product will eventually accrete more features, too. Some manage it better than others, but they all become more complex. And so the wheel turns again.

At the same time, plugins provide a safety valve, as well as a way to form partnerships. Plugins can be a way to give certain features an "audition" before maybe rolling them into the product itself (or bundling the plugin, maybe with somewhat tighter integration than before).

TL;DR Products have a natural cohort of users. If the users grow up, the products do, too. Also plugins.

Confession: I used s-expressions only because even I could figure out how to parse that. I didn't appreciate Lisp in any meaningful sense.

Fast forward to a few years ago. I wanted to learn a lisp, finally. I gravitated toward Scheme. PLT Scheme seemed like the best choice. Today it's known as Racket.

For example, threading macros in Racket: https://github.com/greghendershott/rackjure/blob/master/rack...

Racket has a documentation system called Scribble.

Which is actually one of the most interesting features of Racket -- that it lets you implement a `#lang scribble` which does not even use s-expression syntax, but you still have the full power of Racket if you need it.

The default `#lang racket` is a wonderful modern lisp, and you can use Racket as "only" that. But Racket is also a system for making languages.