• Georg Wrede (6/6) Mar 06 2005 Hi.
• Georg Wrede (69/77) Mar 07 2005 Bit terse the above, had to take a nap! So here's more.

Georg Wrede <georg.wrede nospam.org> writes:

Hi.

I have a solution for those who wish to use D program source for the 
kinds of work you normally use shell scripts.

I'd be interested in bugs, suggestions, and ideas.

The file dscript.tzg is attached.

georg

Georg Wrede <georg.wrede nospam.org> writes:

Georg Wrede wrote:
 Hi.
 
 I have a solution for those who wish to use D program source for the 
 kinds of work you normally use shell scripts.
 
 I'd be interested in bugs, suggestions, and ideas.
 
 The file dscript.tzg is attached.

Bit terse the above, had to take a nap! So here's more.

The idea of dscript has been around, for quite some time. IIRC, it was 
suggested already for some years ago. Earlier this year I tried to 
harass Walter into incorporating it into the compiler, and lately it was 
brought up again, by Ben Hinkle. (I think?)

There are actually two totally separate ways of "using dscript". (We 
really have to coin a more appropriate term for this!) So there are 
really two totally different ways of using them -- so we'd need two names!

dscript A actually _exists_ as source files. Just like shell scripts or 
Perl, Lua, and the like. Visible and accessible.

dscript A may be for the following:

o   You write short D programs.
o   You write use-once programs.
o   Get the speed of Genuine Binaries(tm)
     -- and the ease of text-only programs (like .BAT files)!
o   You try out different parts of the language.
o   You "ask the compiler" what's right.
o   It's so easy you'll write more, and end up doing Real D Programming!
o   You don't want to manage sources and binaries separately.
o   You are teaching programming to beginners.
o   At universities I see lots of non-programmer with programming needs.
o   Quite a few non-IT professionals need self-made apps to do things.
o   For a young person compiling seems a chore -- should be invisible.
o   Never loose the source again for your own app"lets".
o   No need to know all about unix to get things done there too.
o   Code is where app is! Just use Find or Grep!
o   Architecture independent by default. But you _can_ do dependent.
o   Bring your own app"lets" when you switch to linux! Tweaking is less
     than rewriting them all.
o   Own nice classes, with test and demo code -- instantly runnable!
o   -- your idea here --

This is impossible to do in C++. Or in C. Perl starts a battleship every 
time. Java is too big, startup is slow.


dscript B exists as binaries. This paradigm is quite different from 
dscript A. We have compiled binaries, where their own source code is 
packed inside the runtime file. Uses and strengths are different.

o   (Marginally) faster than current implementation of dscript A.
o   Files can be distributed to those who don't bother to see the code.
o   Easy to hide the code with password (kind of between source
     distribution and binary only distribution). There are places
     for this too, you know.
o   Load and run times _exactly_ the same as with regular D.
o   Recipient does not need to have DMD installed.
o   Even years later the source code is around! Never loose it!
o   Governments and spooks may want to examine the code before use.
o   Perfect for source Escrow, only access password needs to be at
     third party. Physically, code stays with customer.
o   IT staff, teachers, hobbyists may want to see code, but not
     have it around gathering dust and getting lost anyway.
o   Theoretically doable in C++ too, but who wants to read it?

I have implemented dscript A for unix systems. I believe it should
run off-the box on pretty much any modern unix, or linux. (Of course, 
GDC is slow, so probably it's not time yet for the other unices. But now 
we have the concept live, and the day DMD gets available for Sun, HP, 
etc., dscript is there!)

I leave it to somebody interested, to tweak up a Microsoft compatible 
version. I didn't bother.

Cygwin may work already?

As to dscript B, I have figured out how to do that, too. And I have a 
few unrelated things that may not add, but multiply the value and 
utility, for both programmers and users. I will take a couple of weeks 
on this.

What is interesting, is that the current dscript A implementation lets 
you redirect, so having dscripts do pipes and filters is just trivial. 
That was not something I ever took for granted. But at the end, it came 
quite easily.

------------------

I just can't wait to see what you guys say after trying this for a while!