On 3/1/2012 10:12 AM, Loup Vaillant wrote:
BGB wrote:
there is also, at this point, a reasonable lack of "industrial strength
scripting languages".
there are a few major "industrial strength" languages (C, C++, Java, C#,
etc...), and a number of scripting languages (Python, Lua, JavaScript,
...), but not generally anything to "bridge the gap" (combining the
relative dynamic aspects and easy of use of a scripting language, with
the power to "get stuff done" as in a more traditional language).

What could you possibly mean by "industrial strength scripting language"?

When I hear about an "industrial strength" tool, I mostly infer that the tool:
 - spurs low-level code (instead of high-level meaning),
 - is moderately difficult to learn (or even use),
 - is extremely difficult to implement,
 - has paid-for support.

expressiveness is a priority (I borrow many features from scripting languages, like JavaScript, Scheme, ...). the language aims to have a high-level of dynamic abilities in most areas as well (it supports dynamic types, prototype OO, lexical closures, scope delegation, ...).

learning curve or avoiding implementation complexity were not huge concerns (the main concession I make to learning curve is that it is in many regards "fairly similar" to current mainstream languages, so if a person knows C++ or C# or similar, they will probably understand most of it easily enough).

the main target audience is generally people who already know C and C++ (and who will probably keep using them as well). so, the language is mostly intended to be used mixed with C and C++ codebases. the default syntax is more ActionScript-like, but Java/C# style declaration syntax may also be used (the only significant syntax differences are those related to the language's JavaScript heritage, and the use of "as" and "as!" operators for casts in place of C-style cast syntax).

generally, its basic design is intended to be a bit less obtuse than C or C++ though (the core syntax is more like that in Java and ActionScript in most regards, and more advanced features are intended mostly for special cases).

the VM is intended to be free, and I currently have it under the MIT license, but I don't currently have any explicit plans for "support". it is more of a "use it if you want" proposition, provided "as-is", and so on.

it is currently "given on request via email", mostly due to my server being offline and probably will be for a while (it is currently 1600 miles away, and my parents don't know how to fix it...).

but, what I mostly meant was that it is designed in such a way to hopefully deal acceptably well with writing largish code-bases (like, supporting packages/namespaces and importing and so on), and should hopefully be competitive performance-wise with similar-class languages (still needs a bit more work on this front, namely to try to get performance to be more like Java, C#, or C++ and less like Python).

as-is, performance is less of a critical failing though, since one can put most performance critical code in C land and work around the weak performance somewhat (and, also, my projects are currently more bound by video-card performance than CPU performance as well).

in a few cases, things were done which favored performance over strict ECMA-262 conformance though (most notably, there are currently differences regarding default floating-point precision and similar, due mostly to the VM presently needing to box doubles, and generally double precision being unnecessary, ... however, the VM will use double precision if it is used explicitly).

If you meant something more positive, I think Lua is a good candidate:
 - Small (and hopefully reliable) tools.
 - Fast implementations.
 - Widely used in the gaming industry.
 - Good C FFI.
 - Spurs quite higher-level meaning.

Lua is small, and fairly fast (by scripting language terms).

its use in the gaming industry is moderate (it still faces competition against several other languages, namely Python, Scheme, and various engine-specific languages).

not everyone (myself included) is entirely fond of its Pascal-ish syntax though.

I also have doubts how well it will hold up to large-scale codebases though.

its native C FFI is "moderate" (in that it could be a lot worse), but AFAIK most of its ease of use here comes from the common use of SWIG (since SWIG shaves away most need for manually-written boilerplate).

the SWIG strategy though is itself a tradeoff IMO, since it requires some special treatment on the part of the headers, and works by producing intermediate glue code.

similarly, it doesn't address the matter of potential semantic mismatches between the languages (so the interfaces tend to be fairly basic).

in my case, a similar system to SWIG is directly supported by the VM, does not generally require boilerplate code (but does require any symbols to be DLL exports on Windows), and the FFI is much more tightly integrated with the core language (which itself can work directly with most C structures and data-types, such as pointers and C-style arrays).

in many regards, it is an experience a little closer to using 'extern "C" { ... }' in C++ (and is generally bidirectional, supporting both importing from C, and exporting to C, though the latter case requires using a code-generating tool).

as-is, this interface can be used for accessing things like the Win32 API and OpenGL and so on, but generally this is not what I use it for.

sadly, it is not currently possible to directly make use of C++ classes, as these pose more complex issues (which I have not yet tried to address), so it is necessary for fall back to a C-style cross-language interface (all this is on an eventual "to do" list though, among fixing up some remaining limitations with the C FFI, ...).

or such...

fonc mailing list

Reply via email to