Re: scsh.net broken link(s)
Ebzzry <[email protected]> Sun, 8 Mar 2009 04:27:40 +0800
| Newsgroups | gmane.lisp.scheme.scsh |
|---|---|
| Message-ID | <[email protected]> |
On Sat, Mar 7, 2009 at 8:51 PM, Andreas Bernauer <[email protected]> wrote: > Anthony Carrico wrote: >> Nunez Steve wrote: >>> Whilst I'm here, is there any active development of this shell going on? >> >> I don't know. Sunterlib has been dormant for a long time. I don't use >> scsh much these days because of a lack of 64bit support. > > Besides the lack of 64bit support, I summarized my reasons, why I don't use scsh > any more in this rant: > http://www.lysium.de/blog/archives/215-Why-I-dont-use-scsh-as-a-scripting-language-anymore.html I don't see the relevance of that blog post regarding the issue of not being able to have 64-bit support. > > As a short summary, writing and debugging scripts written with scsh is awful: > lots of quirky extra syntax to remember to write a script and error messages > with no line numbers and contexts. I can't argue with how you view it, but IMNSHO, it's not really that awful. There may be some quirks on the ways Scsh parses its arguments, but those alone are not enough to give it such label(s). I haven't fully explored Scsh error display facility, but for all the past years that I've been writing non-trivial scripts in it, the so-called "errors don't tell you where they come from" was not enough to deter me. At the back of my mind, I knew what I was writing and I knew how it would come out, even better when I read and understood the relevant sources of information regarding the matter at hand, e.g. some X procedure described in the manual. > > > There are more viable alternatives than scsh out there to write scripts, which > also allow functional-style programming and access to the OS. It's sad, but > that's the way it is (at least for me). It depends on what you may call "viable." That statement is very subjective. There may or may not, but bear in mind that since it's a Scheme system, you have all the flexibility and power of such, especially if you know how to maximize it. Some arguments you have listed may be valid, but in my case, they're trivial and/or can be worked around with. Scsh in its current or future, "improved" state (if that's how people want to label it) is still viable and has plenty of room for improvement. It may continue as "Scsh" or become forked and/or mutated into something else, but what's certain is that it is a beautiful system and we can learn a lot from it. > > -- > Andreas. > > -- Rommel M. Martinez [email protected] http://www.bespin.org/~ebzzry