Date: Tue, 23 Jul 2002 15:16:29 -0400 From: "Brian F. Feldman" <green@freebsd.org> To: Mark Valentine <mark@thuvia.demon.co.uk> Cc: naddy@mips.inka.de (Christian Weisgerber), freebsd-arch@freebsd.org Subject: Re: Scripting languages (was: Re: Package system flaws?) Message-ID: <200207231916.g6NJGTj47459@green.bikeshed.org> In-Reply-To: Your message of "Tue, 23 Jul 2002 19:35:26 BST." <200207231835.g6NIZQ7Y055643@dotar.thuvia.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Mark Valentine <mark@thuvia.demon.co.uk> wrote: > > From: "Brian F. Feldman" <green@freebsd.org> > > Date: Tue 23 Jul, 2002 > > Subject: Re: Scripting languages (was: Re: Package system flaws?) > > > Mark Valentine <mark@thuvia.demon.co.uk> wrote: > > > I think many of the issues regarding maintaining an arbitrary third party > > > scripting environment in the base system would be mitigated by fairly minor > > > enhancements to existing facilities. > > > > No. No, they wouldn't. > > Your reasoning didn't quite convince me. ;-) > > > I advise VERY strongly against trying to do things > > with sh which it is bad at. Korn gets that very wrong and makes ksh do a > > lot of nice things > > I'm not advocating growing /bin/sh into quite such a monster. > > Most of my scripting is still done in a _portable subset_ of Bourne shell. > > I use a more suitable language (whatever is available and has the desired > feature set) for the minority of tasks which require a more powerful scripting > language yet don't warrant being written in C. > > If I could use sh for that middle stuff, my life would be that bit more > complete. So far all we've identified that's truely missing are better > array/list handling and extensibility via dynamically loadable modules. It's not just a question of if you could, though; the question is if everyone else is willing to live with the rest of the shell's shortcomings for it to be used as a secondary /systems/ programming language for anything moderately _complex_. > > but couples with a syntax which is _BAD_ for a > > general-purpose language. > > I don't consider it any worse than most others. What's more, it's *familiar* > (yes, overdoing extensions would go against that advantage, so should be > avoided). > > I value minimal syntactic verbosity in a scripting language, and the Bourne > shell doesn't do too badly there (but stuff too much into it and you get to > Perl). > > You didn't say why you considered it _BAD_. I have lots of reasons. There were the compromises made by inability/ unwillingness to initially support any form of either built-ins or syntactical constructs. It's not a lack of syntactic verbosity; it doesn't have a normal syntax. Cleanliness was compromised in order to have something that was easy to implement as a bunch of external commands. Function call syntax is painful at best, as well as default global scoping for variables, no ability to separate environment variable space from normal variable space. > > There are _so_ many small, perfectly good > > scripting languages that could be used instead, and are tremendously easier > > to learn (much easier than learning how to do weird magic in sh). > > I already know how to do weird magic in sh, thanks, and most folks should > know it to some extent (except those who latched onto a "newer" scripting > language early on and simply can't survive unless their favourite tool is > installed). Like typing? Typing could either possibly be implemented in your shell, in any number of ways, or it could not be implemented and you'd have to find some other way to define what a variable is... > > The solution probably isn't to maintain yet another scripting language in > > the tree. It's also not to use a Bourne shell. Maybe it is acceptable to > > write something totally new, I don't know. It shouldn't look anything like > > sh, though. > > Attempts to maintain another scripting language failed twice already, and > NIH doesn't sound like a solution either (or I'd try to sell you on the > design of _my_ ideal scripting language ;-). Please, do share! :-D > /bin/sh has served us well over the years (at least after it grew functions), > and it wouldn't take much for it to be useful for significant additional > purposes. > > All in all, it's an issue of functionality rather than one of taste, though. There's room for a real language instead of just extending sh. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org <> bfeldman@tislabs.com \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200207231916.g6NJGTj47459>