views:

74

answers:

4

Hi all,

I've recently started developing a new scripting language. It uses a single interpreter and so far works pretty well. It's a mixture of C, C#, Ruby, Python, Perl and even some PHP.
Normally I wouldn't have bothered with such an idea, but to make pen testing and linux administration easier I just had to. All of the above languages can perform these two, but I find some things easier from, say, Perl, then some from Ruby and some of these look good from PHP, if you know what I mean. Anyway, to make my life easier I created one and working on having functions for something that would normally take 50 lines of Ruby, then neatly packages it in a hash table for you. A WORKING example is below titled dnscheck.cx. It basically takes a domain name the user specifies from the command arguments and checks the MX records - priority and name, then the nameserver for the domain. There is some simple error checking in there also. func main() is always the constructor for this language and argv[], argc is automatically passed to it. You'll notice the ns_* functions. ns_mx() will get the MX records and add them to a hash table in the format of hostname => priority and ns_ns() will get the nameserver records - nameserver => ipaddr. It also uses is_ip() which will validate an ip address for you. Obviously it has others that aren't listed here like md5(), sha2(), is_mail() and many others. Because they are held in hashes you can quite easily iterate through them with foreach.

Basically, I'm just wondering if anyone thinks this project is a good idea, or a complete waste of time.

I understand other languages have frameworks and modules, but with this language it's all-in-one; no imports, no rubygems, no requires, no CPAN etc. Any input is welcomed - Positive, or otherwise. Thanks a lot, and the working sample for dnscheck is below.

func runScan(domain)
{
     Console.Printf("* Checking MX Records...\n");
     mhash = ns_mx(domain);
     if (!mhash)
     {
         Console.Printf("Problem getting mail records for %s\n", domain);
         System.exit(1);
     }
     foreach(mhash as s,p)
     {
         Console.Printf("%d - %s\n",p,s);
     }
     Console.Printf("* Checking Nameservers...\n");
     nhash = ns_ns(domain);
     if (!nhash)
     {
         Console.Printf("Could not retrieve nameservers for %s\n", domain);
         System.exit(1);
     }
     foreach(nhash as n,a)
     {
         Console.Printf("%s - %s\n",n,str(a));
     }
}

func doCheck(addr)
{
    if (is_ip(addr))
    {
        runScan(host(addr));
    } else {
        runScan(addr);
    }
}

func main()
{
    if (argc < 2)
    {
        Console.Printf("Usage: %s <host/ip>\n",argv[0]);
        System.exit(1);
    } else {
        doCheck(argv[1]);
    }
}
+3  A: 

Sounds like you've made a fair effort. If you want reality-based comments you should provide a link to the source for your interpreter.

By the way, there's a reason that all those other languages don't build everything into the base interpreter / library - it's because if I want to use some language extension foo in my scripts, it's an awful lot more convient to say require foo or similar than patch and recompile my interpreter.

But hey, if it solves a problem for you, then that's great.

caf
+1 I wrote the same thing but used 3 times the words
Nifle
I'd prefer the interpreter spec over the interpreter source.
C4H5As
A: 

You might want to have a look at the Blue programming language, its author is going in a similar direction. Blue is like Python with a shorter learning curve for someone used to C/PHP. Its also very easy to extend.

I think he's looking for more collaborators who aren't afraid to dig in and hack a parser. It may interest you.

Tim Post
+1  A: 

Developing a new language is almost always a waste of time. But if every developer took this point of view, there would be no more interesting new languages. Of course, the world is awash in uninteresting new programming languages, but if you develop a healthy ego and a thick skin, maybe yours won't be among them.

I wish you every success.


P.S. I can't resist quoting the definition of Scheme:

Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.

Norman Ramsey
A: 

I think it's great when somebody views compiler construction as just another program, rather than some magic art that only wizards can create.

Often, though, it's not a very efficient layer of abstraction, in terms of programmer time. To answer the question of whether it's efficient in your case, just look at the size of the compiler. Consider how much Ruby code you would write to do the same thing natively in Ruby, for example (possibly including a shell script do the requires for you, if that's a concern). If the compiler is less work, then hurray, big win.

Historically, though, the compiler is almost always a big loser: they can be both complex and very big. Today, I think the answer is not so clear: for a specific purpose, written in a high-level language, using some of the countless free libraries which will do a lot of the work for you, and excluding a native code generator (since you probably don't care about raw performance here), writing a compiler is going to be a whole lot easier.

Even if it doesn't work out, you'll have learned a lot. Yegge says compiler construction is the second most important CS class you can take, after typing.

Ken