It would be interesting to see an emacs implementation in language better suited for text manipulation like Ruby or Perl.
Perfect Emacs Reimplementation Language
Another Reimplementation Conundrum?
The Emacs Problem
11–20 of 41 posts
Re: The Emacs Problem
#12It would be interesting to see an emacs implementation in language better suited for text manipulation like Ruby or Perl.
As an emacs newbie with a nagging desire to learn Perl, I would gladly commit to switching to an emacs implementation in Perl.
Re: The Emacs Problem
#13You 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…
People always say that. Fortunately someone figured that out on the order of 34 years ago
[ http://en.wikipedia.org/wiki/Capability-based_security ]
(for a more recently active discussion, try http://en.wikipedia.org/wiki/Domain_Specific_Language)
Re: The Emacs Problem
#14One 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'} {…
JSON is great, but the thing that bugs me about this usage is that it is essentially a bloated version of a "normal log". You don't need the field names, braces, :, quotes or in-fact most of the characters there, just single character delimited columns (traditionally comma, space or tab) with rows delimted by some other character (traditionally newline), some rules for escaping (or not) and the first row as the field names (if they are not obvious). Its more human readable, more machine readable and shorter than JSON - and actually, its already the unofficial standard so you don't need to convince anyone of anything.
Re: The Emacs Problem
#15It would be interesting to see an emacs implementation in language better suited for text manipulation like Ruby or Perl.
As an emacs newbie with a nagging desire to learn Perl, I would gladly commit to switching to an emacs implementation in Perl.
If you think emacs lisp is hard to read now... ;)
Re: The Emacs Problem
#16TextMate/Ruby = Emacs/Elisp
Re: The Emacs Problem
#17Did 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…
Most of those benchmarks are against Perl 5.8, the version of Perl released in 2002. 5.10 had major regexp engine improvements, and 5.12 had minor improvements. Anything is fast when you compare it to 10 years ago.
Re: The Emacs Problem
#18It would be interesting to see an emacs implementation in language better suited for text manipulation like Ruby or Perl.
I've written a lot of Emacs Lisp and a lot of Perl. Perl is better for bulk text processing, but that's not what editors do. The Emacs API is great for text editing. Once you are willing to treat blocks of text as buffers, everything gets very easy with Emacs Lisp. But most people are afraid to do that, because they are used to working with big opaque text objects and big batch transforms.
(Say you want to prefix every sentence with the expression "And then he said, ". The perl way: replace every empty space after a period or the beginning of the string with "And then he said, ". Emacs way: While there are sentences, go to the beginning of the next sentence and insert "And then he said, ". Same result, different way of thinking.)
Modify your way of thinking, and the Emacs model is wonderful. (Why do you think there are so many more Emacs extensions than Eclipse extensions, even though you can pretty much use any JVM langauge to customize Eclipse? It's because customizing Emacs is fast and easy.)
Re: The Emacs Problem
#19One 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'} {…
JSON is great, but the thing that bugs me about this usage is that it is essentially a bloated version of a "normal log". You don't need the field names, braces, :, quotes or in-fact most of the characters there, just single character delimited columns (traditionally comma, space or tab) with rows delimted by some other character (traditionally newline), some rules for escaping (or not) and the first row as the field…
Sure, if my data is tabular I always end up with a CSV-like arrangement, usually space-separated. The original article however talks about how data always ends up hierarchical and tree-like. JSON represents tree-like data very succinctly and very readably.
Still, the real XML-killer for me is YAML. It's even more readable than JSON, and allows many documents in a single file. This makes it excellent for logs, or for any application where your files get big and you want to stream records off them without having to parse the whole file into memory at once. Sure, you can do this with XML and parser hooks, but it's so much more of a pain than just iterating over top-level YAML documents.
Another killer feature is that it's simple enough that I've been able to ask clients to provide me with information in YAML format just by giving them an example record to follow. They're non-technical, but they can read it as easily as me. That's a pretty big win.
Re: The Emacs Problem
#20Uuugh... XML... how I hate you. Everyone should need to learn Lisp, even if you never ever program it, simply to avoid developing some of these poisonous XML-flavored tools. He mentions Ant specifically. Let me tell you, as an unwilling Microsoft Build expert, XML should be NOWHERE NEAR your build system. He puts down Makefiles, but as someone who wrote a Makefile for the first time after years of Ant and MSBuild, it was like a breath of fresh air. The intentional lack of power is what makes it so great. If anything, Makefiles are too powerful and too close to turing complete.
Here is what a make file should look like:
1) vpath statements for various file extensions
2) Phony targets for logical build units, including "all"
3) Generic rules for mapping .abc to .xyz; these rules should have exactly one line of code which executes an external script/tool
4) A list of edges in the dependency graph
5) A few variables as necessary to eliminate redundant edges
If you put any logic in your Makefiles, you are doing it wrong.
If your builds are slow, add empty dummy files for larger culling by timestamps. If timestamps are insufficient, codify early out logic into tools.
Not having logic in my Makefiles enables parallel execution and strong support for incremental builds. If I were to use Lisp as a build system, I'd create a DSL that had these same properties; forbidding arbitrary logic in my dependency graph. It's about finding the right balance to inject expressiveness without losing desirable properties of the DSL. This is why every developer needs to understand more about programming language design. Anytime you create any type of file format, you are doing it. And anytime you are writing any type of file format, you are reverse engineering it. Understanding the intended separation of logic for Makefiles helps me write better Makefiles.