Steve Yegge and Grok (opens in new tab)

I get irritated by words too (for example, Twitter's use of "tweet" bugs me) so sympathize in general, plus I suppose "grok" is rather unpleasant sounding. But the reason I like it, and why I suspect it (sort of) caught on, is that English doesn't have any other word for this. "Understand" is too general. "Grok" means to understand something intuitively, in its essence and as a whole. Perhaps a synonym would be "get" as in "to get it". But "get" is so overloaded that there's room for a more specific alternative.

(Actually the above isn't what "grok" originally meant, but I think it means that now.)

I'm curious, Why? I have no problem with grok as long as anyone that uses the term has actually read 'Stranger in a Strange Land'. Honestly if there ever was a word that needed to be tossed out with the bathwater I believe it would be hacker.

You are not alone, it's a horrible horrible word.

> I was hoping [grok] would eventually lose favor among us geeks

Yet you do not seem to mind the word "geek".

He has been an Emacs fan for a long time now. You should probably check out his "Effective Emacs" article. Lots of good advice there.

The fact that he's such a Emacs fan makes me skeptical about project Grok, to be honest. There is only so far you can take Emacs and for statically typed languages, IDE's leave Emacs in the dust.

I with he were more knowledgeable on IDE's (IDEA, Eclipse, Visual Studio, XCode) so he had a better idea of what modern developers expect from their tools.

I'm hoping Grok will succeed, but I wouldn't be surprised if in the coming year, it gets completely canceled.

I don't know about you but getting real autocomplete and refactoring in Emacs for M languages is a dream come true for me. I don't want a different IDE for each language. I want one Editor to Rule Them All.

Making the infrastructure to understand a programming language shareable between all the ways to edit/refactor/analyze code in that language is far from dumb. It's something Eclipse/IntelliJ/VisualStudio should have done a long long time ago. Heck I once attempted to pick apart the tooling in Eclipse into something I could use headless without booting the entire thing and the code was so tightly integrated into their GUI I gave up in disgust. I mean this is architecture 101. Clear API's and division of labor should have been on everyone's mind but instead the whole thing is a pile of spaghetti code.

Even something as simple as a CLI interface to your IDE's language support features so I could integrate them into editor of my choice would have been smart. But no one did that. I work with 4 different languages minimum every day at work. I'm not going to context switch my editor/IDE for each one of them. For this reason I'm cheering Yegge on like mad.

(Full disclosure: I work at google same as Yegge. I've had these opinions for longer than I've worked there though.)

You can do stuff that's quite a bit more amazing than that (though I guess this goes against his point of "manage expectations"):

For any given C++ refactoring (rename method + swap args), propagate that refactoring automatically to every caller of the refactored function, such that upgrading to a new version of the library is automatically refactored correctly.

Parse this Python function and emit it as C, for optimization. Parse this C function and emit it as Python, for readability.

Cross-layer data-flow analysis - so you could track that a lock that's taken out in Java and released in C++ code would never produce deadlocks.

Can't wait for to refactor a library and have pull requests auto generated for all the code that depends on it.

This is why I have high hopes for the Kotlin language. I think it makes a lot of sense to design a language with tooling in mind from the beginning to avoid nightmares like C++.

I think nobody really understands the pitfalls of language tooling better than the Jetbrains guys.

From Eric Lippert's blog posts about this, the Roslyn project most definitely doesn't seem like a one-person-getting-inspired kind of thing. I was talking to a guy in the Roslyn team last week, and the project scope, and the way they have decided to implement it, is quite frankly astonishing. I mean, a dynamic parser/lexer with all the underlying data structures immutable [1]? Impressive.

[1] http://blogs.msdn.com/b/ericlippert/archive/2012/06/08/persi...

> Was someone at Microsoft inspired by Yegge's vision and decided to implement it for the .Net Common Language Runtime?

I feel a bit obligated to point out that co-incidental invention/discovery is very possible, especially when trying to solve a problem large numbers of smart people would have exposure to.

"The fact that he is talking publicly about an internal project, apparently without authorisation, may mean he is looking for the emergency exit sign over the door..."

From everything said publicly it seems like "grok" isn't a secret for Google, the team members just haven't talked about it much because it is so likely to fail or at least fall short of its goals given how ambitious it is.

The fact that the project wouldn't be explicitly secret is perfectly believable, just look at Go or Dart which have been developed fully in the open. Like those projects, grok seems like the sort of thing that could potentially help Google and everyone but isn't seen as a competitive advantage for advertising/social, so it is perfectly reasonable to believe they aren't trying to keep it a secret.

Thanks for sharing. The first article is really interesting. The author worked 3 months as an intern at Google, and his much under-appreciated works saved Steve Yegge's Grok team that has been struggling for years.

EDIT: Found another gem from the same author: http://yinwang0.wordpress.com/2012/04/09/reinvent-y/

> Today I found that I forgot how to derive the defintion of the Y combinator. I learned it several years ago from an online article, but now the search term “Y combinator” gives me all the news about startups (sigh).

I'll take a stab at it. (That is to say, "I think I understand how the phrase is being used, at least to a degree that it makes perfect sense to me. I may, of course, be wrong. But I'll try to translate my understanding.")

At any level above the trivial, the code we write (or work with) is very often not a direct set of instructions for the machine to carry out. Here, I don't simply mean a high-level language is not machine code or assembly. I think it's safe to assume that we all get that much at least.

Rather, it's a lot like everyday conversation, but with Lewis Carrol's Humpty Dumpty character. There will be common (and less-than-common) cultural references, along with a whole bunch of private definitions for things. Actually understanding the conversation means not only having those cultural references in common[1], but also having access to the private definitions[2] (such as "glory" meaning "a nice knock-down argument").

So the text on the screen (or in the file) is not the actual code, or even a complete description of the code, that the machine will run. It's only a sort of short-hand representation, a language we created along the way to talk about the instructions (even if, at the basic level of the language facilities, the operators and keywords are directly translatable). Simply working with the text content, then, as one would do with a simple parser, or as a human programmer would do with a single text file in isolation, is insufficient; the person or tool would have to have a much deeper understanding of the implications of the text in order to make any real sense of it.[3] For a tool to offer useful help (beyond the simple matter of altering text), it has to be able to "understand" what the text means, and that , in turn, means looking beyond the simple arrangement of text characters.

[1] It might help to think about the Darmok episode of Start Trek TNG. Library calls are very much like the metaphorical language of the Tamarians, in that they make perfect sense if we know the "story" being referenced, but not knowing means either the reference is meaningless or can even be misleading.

[2] That applies as much to preprocessing directives like constant definitions as it does to things like function/method calls.

[3] We do this is natural languages as well. Every time you've run across a cant, an argot or a jargon specific to one field of endeavor, you either understand it because you are familiar with the displaced vocabulary, or you're left in that uncomfortable state of knowing (or thinking you know) what most of the words mean, but failing entirely to understand what's being said.