TIL: Tcl-inspired command language on top of D

Thanks! I love the concept of "scripting" (that is a bit different from simply a "dynamic language"). I'm quite aware it's just "yet another programming language" but if I can dream of something is that it serves as some kind of incentive for people to develop more libraries in D.

I mean, if you just want to create a Til module that allows you to serve some Web pages using HTTP/2, it shouldn't be that difficult and, at the same time, it could be the end goal itself: just creating a useful module, not something like "it's a crucial part, besides other five, of this big project X I'm working on" (I believe this kind of situation almost always ends with "nah, I'll just use instead").

> Just wondering is this type based TCL like language similar to Little?

No, it's not. I first heard about Little a couple months ago and it's a very interesting project. But I don't plan, right now, to include any kind of builtin Tcl compatibility layer in Til (although users are free to create its own implementations, of course).

> [2] Will it eventually support compilation similar to Emacs Lisp? [3]

I created the language much more as a tool to learn how to create languages than anything else, but now it's kind of mature enough, I'll confess my dream is to implement JIT compilation, following the steps of LuaJIT (that is an AWESOME project IMHO).

> Personally I'd love to have superset language in D for data science.

That would be nice. Having a autowrap-like way of exposing D code to Til would be even nicer. (https://github.com/atilaneves/autowrap)

> It should be also easily embeddable and support prototyping like Lua.

I believe embedding it is already in a very tolerable state. If you look into the "interpreter" code you'll see it is only 82 lines (actual 69 LOC).

(https://github.com/til-lang/til/blob/master/interpreter/sour...)

And it has a lot of debugging code. Loading a string, parsing it as a "SubProgram" and running it is kind of trivial.

Now, about the prototyping part, I never thought about it, actually...

> On top of that it should have excellent support for array, ndarray and dataframe like R [4].

It's very easy to create new types in Til and they support both "operate" (to apply, you know, operators, like +, -, /, etc) and "extract (to index things or extract information in general from values). I believe it wouldn't be difficult to create a nice module for using these things.

> Since it is based on D, then it can fulfill the requirements for both type A and B data scientists [5].

Maybe. But, I don't know... isn't data scientists all over the world happy and satisfied with Python, already?

Well, I'd like to make it clear that creating a "de facto super set of D" is not my objective, anyway.

But I'd like to say that, although compiled languages are nice and D is really amazing, I don't even dream of using D to create some quick-and-dirty scripts, the same way I don't even dream of using Til to create shell scripts (I never met any general-purpose language that served as a nice shell, Tcl being the closest one, but still - it's not a traditional shell and the experience is only tolerable, IMHO).

Furthermore, it's also not my objective with Til, but I believe, anyway, that a nice scripting language on top of D would prove very beneficial to the language - it's interesting to try it, right? At least to see what happens...

It's a common misconception that programming languages are either fast or expressive - D is both. The rub is probably that you need to know more about programming in the sense that you have to have good aesthetic taste but also a knowledge of what makes programs actually fast to achieve both.

And besides, what is a script? Code. If you're really only going to use a file once, then I guess do what ever you want but most "scripts" end up being programs.

DasBetterC is what its name suggests, it's for C lovers who enjoy programming in C, but:

1. are sick and tired of buffer overflows

2. want to do metaprogramming but realize that metaprogramming with the C preprocessor is barbaric

3. want modules and struct member functions

4. don't want a runtime other than the C standard library

ImportC is a straight up ISO C11 compiler. It's not for programming in (although you can do it easily enough), it's so D can directly access your existing C code, without having to tediously translate it to D.

To that end, ImportC doesn't warn about execrable coding practice, the error messages are utilitarian, and has no extra features. If ISO C11 says it's ok, ImportC stamps it with approval.

A good example might be calling legacy libraries like BLAS and LAPACK. These are battle-tested libraries that represent probably hundreds of millions of dollars of developer time, but Fortran is annoying for IO-heavy tasks (at least in my opinion).

I like that I can spin up a scripting language like python and call into LAPACK for performance and correctness, but still have modern and ergonomic networking or what have you.