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: Tue, 08 Oct 2002 09:09:10 -0400


Tony Smith wrote:

On Monday 07 October 2002 4:59 pm, Sergey A Lipnevich wrote:

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.


Good point. OK. A more real-world example then. Write a script to figure out the versions of all the spells in the current grimoire. With a non-executable DETAILS file that would be trivial. With an executable DETAILS file it's not.


The choice of language is second to the choice of environment.


Err.... the tail wags the dog?


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.

You can export vars in almost any language you care to name.

So why don't use use such a language right away with hash-bang syntax?



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.

In the current implementation. You are assuming it always has to be that way. I'm not saying it shouldn't, but it doesn't have to be.
I'm not assuming this.


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.

Huh? The environment of a perl process is no different to that of any other process including bash. Both environments die with the process. It's got nothing to do with choice of language and everything to do with the fork()/exec() model. The environment is passed down across a fork()/exec().

If you're talking about "dotting" a ( ". my.sh" ) script then that's roughly the same as a perl/python/ruby "eval"

That's my point. Use perl now if you care. Except for non-executable files which /would/ require a parser and we'll have to be stuck with one or another. Use Perl now. Write DETAILS in it. Executable DETAILS gives you thif freedom.


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 :-)?


Well, the argument was weak, but I liked the conclusion :-)

The argument was not well conveyed, and appears to be different from what you thought it is :-).


Tony








Archive powered by MHonArc 2.6.24.

Top of Page