It 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.
The Emacs Problem
21–30 of 41 posts
Re: The Emacs Problem
#22TextMate/Ruby = Emacs/Elisp
(How hard can it be to select blocks on double-click? Even Terminal.app does it!)
Re: The Emacs Problem
#23It 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
#24Earlier quoted context omitted.
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.
So, what have you written in Elisp?
Probably the biggest reason I don't like it, however, is this: http://www.emacswiki.org/emacs/WhyDoesElispSuck#toc4
(-:
Re: The Emacs Problem
#25Did 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.
The CL-PCRE and Java regular expression engines don't have those somewhat expensive checks, and so are much more likely to encounter catastrophic behavior.
Re: The Emacs Problem
#26Earlier quoted context omitted.
So, what have you written in Elisp?
Mostly stuff for my own personal use inside Emacs; i.e., nothing important. I'm sure that disqualifies me from ever speaking of it again, but there are objective reasons I dislike it (the dead horse of "lack of lexical scoping" comes to mind). Probably the biggest reason I don't like it, however, is this: http://www.emacswiki.org/emacs/WhyDoesElispSuck#toc4 (-:
Some parts of Emacs are made quite convenient with dynamic scoping, in fact. It's nice to be able to say "(let ((inhibit-read-only t))" and run a bunch of editing commands that ignore the fact that the buffer is read-only. If you had to take the Java-style approach of passing the "inhibit-read-only" flag to every buffer modification function, writing an editing function would be quite tedious. And, you'd have to remember to include the "inhibit-read-only" option on any composite functions you would write, otherwise you'd be deleting features from Emacs (for future users), just because you're lazy. Not good.
In general, programmers are taught that everyone using and maintaining their code is dumber than them, and to make sure that nothing unanticipated is ever possible. Programming for Emacs is the opposite, though -- you have to keep all possibilities open, because the next programmer is smarter than you, and understands the ramifications of what he wants to do. (Because if something fucks up, it only takes a few keystrokes to fix it. The user of your programming tool is very different than the user of your web app. He's a programmer in an environment that's meant to be programmed -- breakage can be corrected immediately.)
Anyway, people like to repeat "guh, global variables suck" over and over again, but the reality is that lexical scoping is not that important of a feature. When it's added (which it already is), it's not going to suddenly be easier to write extensions. You will just have one less possibility to think about when debugging, and many opportunities to accidentally make Emacs harder to program, by removing opportunities for future programmers to tweak the behavior of your code.
Re: The Emacs Problem
#27Earlier quoted context omitted.
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.
Furthermore the 5.8 engine is pretty much the 5.6 engine, which was significantly slower than the 5.005 engine. Why the slow-down? Because 5.6 has logic to check when regular expressions are matching slowly, and then to add tracing when it is. This makes many of the exponential slowdowns that Mastering Regular Expressions describes be automatically caught and handled fairly quickly. The CL-PCRE and Java regular expre…
OK, maybe I'm too cynical...
Re: The Emacs Problem
#28Earlier quoted context omitted.
Mostly stuff for my own personal use inside Emacs; i.e., nothing important. I'm sure that disqualifies me from ever speaking of it again, but there are objective reasons I dislike it (the dead horse of "lack of lexical scoping" comes to mind). Probably the biggest reason I don't like it, however, is this: http://www.emacswiki.org/emacs/WhyDoesElispSuck#toc4 (-:
Lexical scoping is mostly for defensive reasons; its absence shouldn't prevent you from writing code. It only prevents a very narrow category of bugs -- a type of bug that is especially uncommon in elisp, because most variables are bound with let, rather than set with ... uh ... set. That means, even if you accidentally use a variable name that the caller has, you still don't clobber the caller. Some parts of Emacs a…
Re: The Emacs Problem
#29Earlier quoted context omitted.
Lexical scoping is mostly for defensive reasons; its absence shouldn't prevent you from writing code. It only prevents a very narrow category of bugs -- a type of bug that is especially uncommon in elisp, because most variables are bound with let, rather than set with ... uh ... set. That means, even if you accidentally use a variable name that the caller has, you still don't clobber the caller. Some parts of Emacs a…
You're arguing two separate things. "Dynamic scope is an important tool" by no means implies that lexical scope is not important.
Re: The Emacs Problem
#30Earlier quoted context omitted.
Mostly stuff for my own personal use inside Emacs; i.e., nothing important. I'm sure that disqualifies me from ever speaking of it again, but there are objective reasons I dislike it (the dead horse of "lack of lexical scoping" comes to mind). Probably the biggest reason I don't like it, however, is this: http://www.emacswiki.org/emacs/WhyDoesElispSuck#toc4 (-:
Lexical scoping is mostly for defensive reasons; its absence shouldn't prevent you from writing code. It only prevents a very narrow category of bugs -- a type of bug that is especially uncommon in elisp, because most variables are bound with let, rather than set with ... uh ... set. That means, even if you accidentally use a variable name that the caller has, you still don't clobber the caller. Some parts of Emacs a…
As to your point about "global variables suck", people say a lot of misinformed things. The problem with global variables has always been the inability to detect their access. If a variable has a value you didn't expect, it's not lexical so you can't just read the code and it's not dynamic so you can't just check the stack for the culprit.
Ironically, the main thing our OO saviour has really brought us is the ability to limit the scope of our global (member) variables. With big classes you still have the issue of figuring out what in-scope method changed the member variable, and I've sorely missed dynamic scoping for member varialbes many time (e.g. anytime you use a finally block to make sure the variable gets set back, you could have just used dynamic scoping).