Skip to Content.
Sympa Menu

sm-sorcery - Re: [SM-Sorcery]Language wars...

sm-sorcery AT lists.ibiblio.org

Subject: Discussion of Sorcery related topics

List archive

Chronological Thread  
  • From: Sergey A Lipnevich <sergeyli AT pisem.net>
  • To: Tony Smith <tony AT smee.org>
  • Cc: sm-sorcery AT lists.ibiblio.org
  • Subject: Re: [SM-Sorcery]Language wars...
  • Date: Mon, 07 Oct 2002 11:59:02 -0400

One of the things neglected about Sorcery is that it relies on the file
system as its primary storage, a kind of database. Spell name's primary
source is its directory name, /not/ the name in DETAILS, so your first
example is wrong. If DETAILS has the spell name different from its
directory name, it's a bug. So, in your example 1, there is no need to
parse DETAILS files at all.

The choice of language is second to the choice of environment. By
environment I mean the space where all the variables are stored during
execution. Currently, it's bash environment, and any language capable of
storing a variable in there, will do. If you can `export VAR=value' in
Python, use Python right now, with good reasoning I doubt anyone would
through a stone at you. That's how our code snippets talk to each other.
Environment is one of the components of the application platform, so,
however unusual that may sound, bash is our application platform,
because it is our tool of maintaining state during execution. Note that,
using Perl, you have to change the structure of sorcery to at least have
a central script that runs everything, otherwise your execution state is
gone whenever the script finishes -- Perl's VM doesn't stay in memory
after the script has finished, bash does. If we choose Mono, this will
be our application platform, but it requires a server, for the same
purpose -- maintain execution state.

That's why bash is better than anything as a lightweight application
platform -- it stays between script executions, Perl, Python, C++, etc,
do not have such advantage without extra effort. It has many programming
disadvantages, but believe it or not, it's not the worst infrastructure
we may have.

How's that for language wars :-)?

Sergey.

Tony Smith wrote:

>All,
>
>I wanted to pass on a suggestion for the future direction of sorcery on the
>premise that if you don't speak up, you'll never be heard :-)
>
>I know that we regularly endure the round of language wars and it seems that
>Perl is under consideration for the future (2.0/3.0) but I have an idea which
>would allow us to stay true to our roots and address some of the problems
>with the current architecture.
>
>What if the DETAILS file was not written in bash, but just a simple tag=value
>format text file that could be easily grep'd or parsed? (Just the DETAILS
>file, not the rest)
>
>1. No need for sorcery to source every details file in a tree to find a spell:
>
> find . -NAME DETAILS | xargs grep -l "SPELL=$SPELL"
>
>would be an easy implementation of "gaze where". All commands that work on
>sets of spells would benefit from this.
>
>2. The CONFIGURE/BUILD etc. etc. scripts can still be bash so we get all the
>benefits of having a build system based on the tools that you'd use to build
>these packages interactively. [This is one area where I can see real
>problems for a Perl/Python/Ruby/... implementation]
>
>Thoughts?
>
>Tony.
>
>
>_______________________________________________
>SM-Sorcery mailing list
>SM-Sorcery AT lists.ibiblio.org
>http://lists.ibiblio.org/mailman/listinfo/sm-sorcery
>
>
>






Archive powered by MHonArc 2.6.24.

Top of Page