|Subject:||Re: proposal to make null string handling more emacs-y|
|Date:||Fri, 27 Apr 2012 12:05:32 -0700|
> Date: Thu, 26 Apr 2012 21:17:36 -0700
> From: Steve Yegge <address@hidden>
> Cc: Eli Zaretskii <address@hidden>, address@hidden
>This is Lisp, not C++ or even Java. Some Lisp code is never compiled
> But type errors are for *developers*. They are supposed to happen at
> compile time. When you're running the byte compiler or the unit tests, you
> want it to fail loudly and early.
at all. A notable example is the code you put in .emacs.
> But when you ship the software, and it's in the hands of end-usersI don't think you can have an interpreted language without runtime
> who may not be able to debug it, then unless it's running a nuclear
> reactor or an airplane, you want the software to be robust. Your
> browser shouldn't crash because of a misbehaved site; your web page
> shouldn't fail to load because of a misbehaved widget; your CAD
> program shouldn't stop functioning because of a misbehaved polygon.
> Yes, the resulting bug will be annoying, but it's far less annoying
> than having your work interrupted altogether.
exceptions. In Lisp, if you want robust programs, you need to catch
exceptions and do something reasonable. Asking to avoid exceptions
altogether is IMO impractical.
> Similarly, I see a whole bunch of file-name manipulation functions thatThe usual Emacs semantics for an empty file name is that it stands for
> accept the empty string as an argument. But the empty string has no
> semantic meaning whatsoever as a valid filename. Without any semantic
> meaning, it's arguably a bug to pass one in.
the current directory.
|[Prev in Thread]||Current Thread||[Next in Thread]|