Live data from Hacker News

The Emacs Problem

sites.google.com

1–10 of 41 posts

The Emacs Problem

#1
It's a rhetorical question. The answer is patently obvious at this point: Lisp is evil, and you'd damned well better write all your code in C++ and XML and JavaScript and PL*SQL and CSS and XSLT and regular expressions and all those other God-fearing red-blooded manly patriotic all-American languages from now on. No more of this crazy Lisp talk, ya hear?>>

The Emacs Problem
sites.google.com

Re: The Emacs Problem

#3
You could even trivially convert it to XML and use XSLT, if you were silly enough. But Lisp is directly executable, so you could simply make the tag names functions that automatically transform themselves. It'd be a lot easier than using XSLT, and less than a tenth the size.

And now anyone who can modify your log can execute arbitrary code in the reader process…

Re: The Emacs Problem

#4
One solution that Steve didn't discuss is JSON. To be fair, JSON wasn't that popular in 2005, but it's still a great solution.

The way it works is that their are no mandatory newline characters in JSON. Whitespace between lexical elements is ignored, and any embedded newlines in strings can be escaped (i.e. as \n). So a log format that a few people are using today is like this:

{'kind': 'foo', 'id': 1, 'msg': 'hi'} {'kind': 'bar', 'id': 2, 'msg': 'there'}

Each log message takes up a single line in the file. You can trivially deserialize any line to a real data structure in your language of choice. You can (mostly) grep the lines, and they're human readable. I do this at work, and frequently have scripts like this:

scribereader foo | grep 'some expression' | python -c 'code here'

In this case we're storing logs in the format described above (a single JSON message per line), and scribereader is something that groks how scribe stores log files and outputs to stdout. The grep expression doesn't really understand JSON, but it catches all of the lines that I actually want to examine, and the false positive rate is very low (I feel like this is a pretty good compromise between greppability, human readability, and the ability to programatically manipulate log data.

Re: The Emacs Problem

#5
post #4

One solution that Steve didn't discuss is JSON. To be fair, JSON wasn't that popular in 2005, but it's still a great solution. The way it works is that their are no mandatory newline characters in JSON. Whitespace between lexical elements is ignored, and any embedded newlines in strings can be escaped (i.e. as \n). So a log format that a few people are using today is like this: {'kind': 'foo', 'id': 1, 'msg': 'hi'} {…

Err, my formatting got messed up. Pretend like there's a newline between the two log entries I described.

Re: The Emacs Problem

#7
post #4

One solution that Steve didn't discuss is JSON. To be fair, JSON wasn't that popular in 2005, but it's still a great solution. The way it works is that their are no mandatory newline characters in JSON. Whitespace between lexical elements is ignored, and any embedded newlines in strings can be escaped (i.e. as \n). So a log format that a few people are using today is like this: {'kind': 'foo', 'id': 1, 'msg': 'hi'} {…

"XML is better if you have more text and fewer tags. And JSON is better if you have more tags and less text. Argh! I mean, come on, it’s that easy. But you know, there’s a big debate about it." — Steve Yegge

http://simonwillison.net/2008/Jun/15/steveys/

That's the problem with discussing old articles. Information gets updated

Re: The Emacs Problem

#8
Did anyone else think of CL-PPCRE as they read through the "lisp does not have regular expression support" implications? That was answered by the comparison of elisp to modern Common Lisp, and I wonder if anyone has done any work to make CL-PPCRE work for elisp. In spite of being someone's library, it is much faster than perl's built-in regex support.

There is a point to be made for the idea that you are solving the wrong problem with the log parsing. On the other hand, if you are trying to interface with other developers' popular engines, you may not have a choice.

Re: The Emacs Problem

#9
post #2

It would be interesting to see an emacs implementation in language better suited for text manipulation like Ruby or Perl.

Hell, even Scheme would be a lot nicer than Emacs Lisp. Actually, if I could even get Yi ( http://www.haskell.org/haskellwiki/Yi ) to work, I'd use that. Elisp sucks.

Re: The Emacs Problem

#10
post #5
post #4

One solution that Steve didn't discuss is JSON. To be fair, JSON wasn't that popular in 2005, but it's still a great solution. The way it works is that their are no mandatory newline characters in JSON. Whitespace between lexical elements is ignored, and any embedded newlines in strings can be escaped (i.e. as \n). So a log format that a few people are using today is like this: {'kind': 'foo', 'id': 1, 'msg': 'hi'} {…

Err, my formatting got messed up. Pretend like there's a newline between the two log entries I described.

Indent the code two spaces. http://news.ycombinator.com/formatdoc
Post reply on HN