www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Linux power tip: dscript

reply 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
Mar 06 2005
parent 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!
Mar 07 2005